O Generic Routing Encapsulation () é o túnel mais simples que uma rede pode montar: você pega um pacote, coloca um header (cabeçalho) pequeno na frente dele, coloca um novo header IP na frente de tudo e manda o resultado para o endpoint do túnel, a outra ponta, que abre o envelope e encaminha o que estava dentro. O protocolo é só isso. Definido na 2784 (com as extensões opcionais de chave e de número de sequência na RFC 2890), o GRE faz, de propósito, menos do que quase qualquer outro túnel, e as situações em que ele ganha são justamente aquelas em que fazer menos é a vantagem.

A anatomia: 24 bytes sobre IPv4

Um pacote GRE sobre IPv4 tem três camadas, uma dentro da outra. O envelope externo é um header IP comum, de 20 bytes, com o valor 47 no campo de protocolo, que é o número registrado para o GRE. Depois vem o header GRE propriamente dito: na forma mínima, que é a mais comum, são só 4 bytes informando o que é o payload (a carga útil), ou seja, o tipo de protocolo, com a mesma numeração que o usa. Por fim, vem o passageiro: o pacote original, intacto.

Vinte mais quatro: esse é o número que vale decorar, 24 bytes de overhead em cada pacote. Parece pouco até o túnel encontrar um caminho de 1.500 bytes: um pacote passageiro de tamanho máximo deixa de caber, e alguma coisa tem de ceder. As saídas são a fragmentação, uma menor no túnel ou o clamping, que limita o tamanho do que os endpoints enviam. Essa conta é importante o bastante para ter um artigo só dela; aqui basta saber que o envelope custa 24 bytes e que essa conta sempre chega.

O que o envelope oferece

O roteamento IP comum entrega o pacote pelo endereço de destino, seguindo o caminho que as tabelas de roteamento escolherem. O GRE quebra essa limitação de um jeito útil: o destino do header externo é o endpoint do túnel, então o passageiro atravessa redes que nunca conseguiriam roteá-lo por conta própria. Endereços privados da RFC 1918 atravessam a internet pública. Tráfego multicast e de protocolos de roteamento, que a maioria das redes de trânsito descarta ou ignora, viaja dentro de envelopes unicast, e é por isso que fechar adjacências de roteamento sobre GRE é um design clássico. Até um protocolo que os equipamentos do meio do caminho nunca viram passa sem problema, porque eles só leem o lado de fora.

O segundo ganho é de topologia: um túnel é uma interface. Dois roteadores com um túnel GRE entre eles se comportam como se estivessem ligados por um cabo, seja qual for a geografia por baixo. Políticas, rotas e medições podem ser aplicadas a esse cabo virtual do mesmo jeito que seriam a um cabo físico.

O que o GRE se recusa a fazer

O GRE não oferece confidencialidade, nem integridade, nem autenticação. O envelope é aberto como um cartão-postal: qualquer um no caminho lê o passageiro com a mesma facilidade com que lê o envelope. Não há handshake nem sessão: o túnel "existe" a partir do momento em que as duas pontas estão configuradas, e um endpoint GRE desencapsula sem reclamar qualquer coisa que chegue dizendo ser protocolo 47. Por isso é importante filtrar nos endpoints.

Ser stateless também significa que o GRE não tem como avisar que caiu. O line protocol continua up mesmo com a outra ponta inalcançável, e o tráfego vai sumindo em silêncio, num blackhole. A solução padrão são os keepalives: um endpoint envia, de tempos em tempos, uma sonda montada para que a outra ponta a devolva; se as respostas param de chegar, o túnel é marcado como down. Onde não há keepalive, o design depende de um protocolo de roteamento ou de uma sonda de (service level agreement, o acordo de nível de serviço) que passe pelo túnel para detectar a falha. A verificação de saúde tem de ser acrescentada, porque o GRE não vem com ela.

Nada disso é defeito. A criptografia de uma VPN (rede privada virtual) custa ciclos de processamento, estado e complexidade; o GRE não gasta nada disso. É por isso que os roteadores encaminham GRE em line rate, no hardware, e é por isso que ele continua sendo a resposta padrão quando o requisito é "leve isto até lá", e não "esconda isto de todo mundo".

A escolha do GRE num exemplo prático

Os serviços de segurança em nuvem que recebem tráfego encaminhado deixam esse trade-off bem concreto. O serviço Internet Access da Zscaler aceita o tráfego das localidades por GRE ou por , e a documentação publicada (conferida em 2026-07-21) mostra a decisão clássica: um túnel GRE é suportado até 1 Gbps, mas só até 250 Mbps se os endereços internos dos endpoints do túnel passarem por source , porque o serviço faz o balanceamento com base nesses endereços internos e o NAT acaba juntando todos num só. Precisa de mais de um gigabit? Acrescente túneis com endereços públicos de origem diferentes: dois primários e dois de backup para 2 Gbps. Os pré-requisitos do GRE também são clássicos: um endereço público de saída fixo e um equipamento que fale GRE; se faltar qualquer um dos dois, entra a alternativa criptografada, e é aí que a história continua com IPsec e IKE.

O que levar daqui: 24 bytes, protocolo 47, nenhum sigilo, nenhuma verificação de saúde embutida e, em troca, velocidade, simplicidade e a capacidade de levar qualquer coisa a qualquer lugar que o header externo alcance.