Túneis GRE para IPv4: quando precisa de um e como o configurar

Um túnel permite-lhe usar endereços IPv4 num servidor que de outra forma não os poderia transportar. O bloco é anunciado por uma rede que o pode anunciar, e o túnel leva o seu tráfego até ao seu servidor e de volta. É a resposta quando o seu fornecedor não oferece bring your own IP (BYOIP), quando não tem número AS, ou quando precisa de menos do que os 256 endereços que a Internet encaminha por si só.

O que o túnel faz realmente

Os pacotes para o seu bloco chegam à rede que o anuncia. Aí, cada pacote é envolvido num novo, endereçado ao seu servidor, e enviado pela Internet comum. O seu servidor desembrulha-o e vê o pacote original, como se os endereços estivessem configurados numa interface local.

Original packet:  [IP header | data]
GRE packet:       [outer IP | GRE header | IP header | data]

As respostas fazem o mesmo caminho no sentido inverso: o seu servidor envolve-as, envia-as para a outra ponta do túnel, e essa rede entrega-as. Esse caminho de regresso é o passo em que a maioria das configurações falha, e a configuração abaixo mostra porquê.

Quando um túnel é melhor do que o BYOIP

O BYOIP permite que um fornecedor cloud ou de alojamento anuncie o seu bloco a partir da sua própria rede (que fornecedores o fazem). Onde está disponível e tem pelo menos um /24, é a opção mais limpa: sem salto extra, sem ponto de falha extra, e com toda a largura de banda do fornecedor. Um túnel é a melhor escolha em quatro casos.

• O seu fornecedor não oferece BYOIP. A Scaleway, por exemplo, di-lo claramente na sua documentação, e vários outros só o aceitam a pedido, para alguns dos seus produtos, como a Infomaniak, a TransIP e a UpCloud. Outros, entre eles a Contabo, a Exoscale, a Hostinger e a Akamai Cloud, não publicam procedimento nenhum.
• Precisa de menos de 256 endereços. Um /24 é o menor bloco que as redes aceitam nas suas tabelas de encaminhamento, e o BYOIP de nenhum fornecedor desce abaixo disso. Um túnel pode entregar um /29, ou um único endereço.
• Não tem ASN, e o fornecedor quer um. Alguns fornecedores só aceitam o seu espaço por uma sessão BGP com o seu próprio número AS. Um túnel não precisa de nenhum dos dois.
• Quer os mesmos endereços em vários sítios, ou liberdade para mudar. O anúncio fica onde está; o túnel vai para onde o seu servidor for.

O preço é um desvio. O tráfego viaja até à outra ponta do túnel antes de chegar a si, por isso escolha um endpoint perto do seu servidor, e lembre-se de que é a capacidade do túnel, e não a porta do seu servidor, que impõe o limite.

GRE ou WireGuard

Ambos transportam o mesmo tráfego; diferem no que o caminho entre as duas pontas exige.

A própria lista de plataformas do WireGuard e a documentação do RouterOS da MikroTik indicam onde funciona (verificado a 22 de outubro de 2026).

Se o seu endpoint estiver atrás de NAT, a escolha está feita: WireGuard. O mesmo vale para o Azure, que bloqueia o GRE nas suas redes virtuais.

MTU e MSS: a falha clássica

O encapsulamento acrescenta cabeçalhos, pelo que o maior pacote que cabe dentro do túnel é menor do que os 1500 bytes de uma ligação Ethernet simples: 1476 bytes para GRE sobre IPv4, e o WireGuard funciona habitualmente com 1420. Se errar, vê o sintoma clássico: os pedidos pequenos funcionam, enquanto os downloads grandes e os handshakes TLS ficam pendurados, porque os pacotes que não cabem são descartados e as mensagens que o deviam assinalar são muitas vezes filtradas pelo caminho.

Duas definições evitam-no. Configure o MTU da interface do túnel com o valor certo, e limite o tamanho máximo de segmento TCP (MSS) no tráfego que encaminha pelo túnel, para que ambas as pontas acordem enviar pacotes que caibam. Enviamos os dois valores com cada túnel, e alteramo-los a pedido.

Uma configuração Linux mínima

O exemplo abaixo leva um bloco a um único servidor Linux por GRE. Os endereços são intervalos de documentação: 203.0.113.1 é o endereço público do seu servidor, 198.51.100.1 a outra ponta do túnel, e 192.0.2.0/24 o bloco.

# 1. The tunnel, from your server to the far end
ip tunnel add gre1 mode gre local 203.0.113.1 remote 198.51.100.1 ttl 255
ip link set gre1 mtu 1476 up
ip addr add 10.0.0.2/30 dev gre1

# 2. An address from the block on the server itself
ip addr add 192.0.2.10/32 dev lo

# 3. Replies from the block go back through the tunnel
ip rule add from 192.0.2.0/24 lookup 100
ip route add default via 10.0.0.1 dev gre1 table 100

O passo 3 é o que as pessoas esquecem. Sem ele, as respostas de 192.0.2.10 saem pelo uplink do seu próprio fornecedor, com um endereço de origem que esse fornecedor nunca lhe deu, e os seus filtros anti-spoofing descartam-nas. Se a sua distribuição ativar a filtragem estrita de caminho inverso, defina-a também como loose para o túnel (sysctl -w net.ipv4.conf.gre1.rp_filter=2).

Se o servidor encaminhar o bloco para máquinas virtuais ou contentores, limite o MSS no tráfego que reencaminha:

iptables -t mangle -A FORWARD -o gre1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

BGP pelo túnel

Se tem o seu próprio número AS e quer controlar o anúncio por si, pode correr uma sessão BGP pelo túnel em vez de uma rota estática, com BIRD, FRR ou o daemon do seu próprio router. A maioria dos clientes não precisa disto e fica com a configuração estática. Se anunciar a partir do seu próprio ASN, o ROA tem de indicar esse ASN (RPKI e ROA).

Onde entra a RTM Networks

Anunciamos o bloco e entregamo-lo ao seu servidor por GRE ou WireGuard, onde quer que o servidor esteja. Isso funciona onde o BYOIP não funciona, incluindo para menos de 256 endereços e para fornecedores que não aceitam o seu espaço de todo. Diga-nos onde está o servidor e o que corre nele, e recomendamos GRE ou WireGuard e enviamos a configuração com os valores certos de MTU e MSS (túneis GRE e WireGuard).