Configurar e testar um túnel GRE na Sophos Firewall

Um túnel GRE liga dois endpoints IP e transporta tráfego encaminhado entre eles. Na Sophos Firewall, é criado na Device Console com system gre. É adequado, por exemplo, para um acesso a um fornecedor, um caminho overlay simples ou um transporte que exija expressamente GRE.

Resposta curta

Para uma implementação segura, começam por se documentar os endpoints WAN exteriores, os IPs interiores do túnel e as redes remotas. Seguem-se estes passos:

1. Verificar a conectividade underlay dos dois endpoints WAN e o protocolo IP 47.
2. Criar o túnel GRE de forma espelhada em ambas as firewalls com system gre tunnel add.
3. Verificar nomes, endpoints, IPs do túnel e estado com system gre tunnel show.
4. Associar as redes remotas ao túnel com system gre route add.
5. Criar regras de firewall restritas e com logging entre LAN e VPN.
6. Testar separadamente o GRE no caminho WAN, a rota interior, a Rule ID, o tráfego útil e o caminho de retorno.

⚠️ O GRE não fornece, por si só, encriptação nem autenticação. Numa rede não fidedigna, o GRE só deve ser utilizado quando o transporte não encriptado tiver sido expressamente aceite no desenho de segurança. Se for necessária confidencialidade ou autenticação do peer, uma VPN IPsec site-to-site é normalmente mais adequada.

Distinguir endpoints GRE, IPs do túnel e rotas

Uma configuração GRE é composta por várias camadas:

• Local gateway: a interface WAN local da Sophos Firewall, por exemplo Port2.
• Remote gateway: o endereço IPv4 exterior do peer.
• Local IP e Remote IP: os endereços point-to-point interiores do túnel GRE.
• Rota GRE: associa um host remoto ou uma rede de destino ao túnel.
• Regra de firewall: permite o fluxo de dados concreto entre as zonas e as redes.
• Caminho de retorno: envia os pacotes de resposta de volta pelo túnel espelhado.

O GRE sobre IPv4 utiliza o protocolo IP 47. Não é TCP nem UDP e não deve ser confundido com a porta 47. Um router a montante, um filtro do fornecedor ou uma cloud security list tem, por isso, de transportar o protocolo IP entre os dois endpoints exteriores.

Um estado de túnel visível como Enabled confirma que a configuração GRE está guardada e ativa. Ainda não prova que o peer responde, que a rota está correta ou que uma aplicação funciona.

Quando o GRE é adequado e quando o IPsec faz mais sentido

O GRE é simples e transporta tráfego encaminhado entre dois endpoints definidos. É adequado quando um fornecedor ou uma plataforma exige GRE, quando apenas é necessário encapsulamento ou quando um caminho underlay fidedigno já está protegido separadamente.

Em contrapartida, o GRE não substitui uma ligação encriptada entre locais. Para ligações normais através da Internet pública, o route-based IPsec é geralmente o ponto de partida mais adequado. Uma combinação de GRE e IPsec exige um desenho próprio, testado em ambos os dispositivos; este procedimento básico não cria um caminho GRE-over-IPsec não validado.

Este artigo aborda um túnel IPv4 point-to-point estático. Multicast, PIM-SM, BGP sobre GRE e túneis Anycast específicos de fornecedores são extensões possíveis, mas só devem ser planeados depois de o caminho unicast básico funcionar.

Planear a topologia de exemplo

O exemplo liga duas Sophos Firewalls:

• Local A WAN: Port2 com 192.0.2.10
• Local A LAN: 10.10.10.0/24
• Local A, IP do túnel: 10.255.255.1
• Local B WAN: Port2 com 198.51.100.20
• Local B LAN: 10.20.20.0/24
• Local B, servidor de teste: 10.20.20.10
• Local B, IP do túnel: 10.255.255.2
• Rede do túnel: 10.255.255.0/30
• Serviço de teste: HTTPS, ou seja, TCP 443

192.0.2.0/24 e 198.51.100.0/24 são redes de documentação e não são utilizadas em produção. Ambos os endereços WAN, interfaces, IPs do túnel, redes LAN e o servidor de teste são substituídos em conjunto pelos valores reais. Os IPs do túnel têm de formar uma rede point-to-point própria, planeada de forma idêntica nos dois lados, e não podem sobrepor-se a redes existentes.

O exemplo utiliza os nomes de túnel gre_branch no local A e gre_hq no local B. Os nomes são de escolha livre, mas, segundo a API atual do SFOS 22, não podem exceder 15 carateres.

Antes da alteração, são necessários um backup da configuração, uma janela de manutenção e um acesso de gestão independente como caminho de recuperação. Devem também ser registadas as Static Routes e SD-WAN Routes existentes, as regras NAT e de firewall e as redes sobrepostas.

Verificar os requisitos do caminho exterior

Os dois endpoints WAN têm de conseguir alcançar-se através do underlay. A configuração básica utiliza endereços IPv4 estáticos em ambos os lados. Se o endereço WAN local for obtido por PPPoE ou DHCP, este procedimento não deve ser continuado: instruções oficiais mais antigas da Sophos para GRE excluem interfaces WAN locais dinâmicas, enquanto a API atual do SFOS 22 apenas documenta DDNS para o Remote Gateway. O suporte tem, por isso, de ser esclarecido para a build e a ligação concretas.

Antes de configurar o túnel, verificam-se os seguintes pontos:

• O endereço WAN remoto é encaminhado através do gateway WAN esperado.
• Routers a montante, fornecedores e ACLs na cloud permitem o protocolo IP 47 entre os dois endpoints.
• Não existe uma configuração CGNAT ou NAT cujo comportamento com GRE não esteja esclarecido.
• Os IPs interiores do túnel e as redes LAN não se sobrepõem local nem remotamente.
• O peer utiliza, de forma espelhada, os mesmos valores exteriores e interiores.
• Está planeado um caminho de retorno para ambas as redes LAN.

Um ping ao peer público pode apoiar a validação do caminho underlay, mas não prova o suporte de GRE. Da mesma forma, permitir a porta TCP ou UDP 47 não ajuda, porque o GRE não é um protocolo de transporte baseado em portas.

Criar o túnel GRE em ambas as firewalls

A configuração é efetuada através da CLI no menu 4. Device Console. A página de ajuda atual da Sophos contém fragmentos de sintaxe renderizados incorretamente. Por isso, antes da alteração, confirma-se na build utilizada com Tab ou ? se os parâmetros seguintes estão disponíveis.

Configurar o local A

Na firewall A, introduzem-se a porta WAN local Port2, o peer exterior 198.51.100.20 e o par interior do túnel:

system gre tunnel add name gre_branch local-gw Port2 remote-gw 198.51.100.20 local-ip 10.255.255.1 remote-ip 10.255.255.2

Em seguida, faz-se apenas uma leitura:

system gre tunnel show

A entrada tem de mostrar corretamente gre_branch, Port2, o endereço WAN remoto e os dois IPs do túnel. Um erro de digitação não deve ser ocultado por uma segunda configuração com um nome semelhante.

Configurar o local B de forma espelhada

Na firewall B, os valores locais e remotos são invertidos:

system gre tunnel add name gre_hq local-gw Port2 remote-gw 192.0.2.10 local-ip 10.255.255.2 remote-ip 10.255.255.1

Também aqui se segue a verificação apenas de leitura:

system gre tunnel show

Nesta fase, Enabled é apenas uma verificação intermédia. A validação só termina com um fluxo de dados real entre as LAN.

Encaminhar redes remotas através de GRE

Para o caminho fixo simples, cria-se uma rota GRE em cada firewall. O local A envia a LAN do local B através de gre_branch:

system gre route add net 10.20.20.0/255.255.255.0 tunnelname gre_branch

O local B recebe o caminho de retorno espelhado:

system gre route add net 10.10.10.0/255.255.255.0 tunnelname gre_hq

Em seguida, leem-se as associações configuradas em ambos os dispositivos:

system gre route show

A rota não pode competir com um caminho estático, SD-WAN, VPN ou diretamente ligado com o mesmo comprimento ou mais específico. A Route Precedence global não é alterada por tentativa. Primeiro, é necessário comprovar a rota realmente correspondida e o caminho dos pacotes.

Custom Gateway e SD-WAN como alternativa

Alguns desenhos de fornecedores utilizam, em vez da rota GRE simples, um Custom Gateway no caminho GRE e selecionam-no numa SD-WAN Route. Isto é adequado quando Source, Service, Failover ou um estado de gateway definido devem influenciar a decisão de encaminhamento.

Neste caso, o IP remoto do túnel é o Next Hop. Health Check, Zone e Probe Target têm de corresponder ao desenho concreto do fornecedor; a monitorização desativada numa instrução do fabricante não é um padrão universal. A relação entre o objeto, a probe e o teste real é explicada em Criar e verificar um Custom Gateway na Sophos Firewall. A seleção do caminho é abordada em Configurar uma SD-WAN Route na Sophos Firewall.

A rota GRE e a SD-WAN Route não são ativadas em paralelo sem controlo para as mesmas redes. Antes da mudança, documenta-se qual mecanismo deve prevalecer e como regressar ao caminho anterior.

Criar regras de firewall sem NAT desnecessário

O túnel GRE e a respetiva rota ainda não permitem tráfego útil. Para uma ligação HTTPS iniciada no local A, é necessária uma regra restrita e com logging em ambas as firewalls.

Na firewall A:

• Source zone: LAN
• Source network: 10.10.10.0/24
• Destination zone: VPN
• Destination network: 10.20.20.10
• Services: HTTPS
• Action: Accept
• Log firewall traffic: ativado

Na firewall B, permite-se o tráfego de túnel recebido para o servidor de teste:

• Source zone: VPN
• Source network: 10.10.10.0/24
• Destination zone: LAN
• Destination network: 10.20.20.10
• Services: HTTPS
• Action: Accept
• Log firewall traffic: ativado

Estas duas regras abrangem a ligação iniciada no local A e o respetivo tráfego de retorno stateful. Se os hosts no local B também puderem iniciar novas ligações para o local A, cria-se adicionalmente o par de regras espelhado LAN para VPN na firewall B e VPN para LAN na firewall A, com as redes e os serviços realmente necessários. Não é necessária uma regra ampla Any para a validação.

Numa ligação normal entre locais, o IP de origem original é preservado. O MASQ não é ativado como uma suposta correção de routing. Se faltar o caminho de retorno, corrige-se a rota no peer. A estrutura geral das regras é explicada em Criar e verificar com segurança regras da Sophos Firewall.

Validar em conjunto o túnel e o tráfego útil

A verificação segue o caminho dos pacotes e separa a configuração do funcionamento real:

1. Executar system gre tunnel show em ambas as firewalls e comparar os endpoints e os IPs do túnel.

2. Verificar com system gre route show a LAN remota correspondente e o nome correto do túnel.

3. Iniciar, a partir do cliente em 10.10.10.0/24, uma nova ligação HTTPS a 10.20.20.10.

4. No Log viewer de ambas as firewalls, verificar Source, Destination, Service, Firewall Rule ID, NAT Rule ID e Zone.

5. Em Diagnostics > Packet capture, no local A, filtrar o caminho GRE exterior:

   host 198.51.100.20 and ip proto 47
   

6. Filtrar separadamente o fluxo de teste interior:

   host 10.20.20.10 and tcp port 443
   

7. Comparar a entrada e a saída em ambas as firewalls e verificar o IP de origem real no servidor de destino.

8. Iniciar um teste de retorno apenas com um serviço permitido para esse efeito.

O capture exterior mostra o encapsulamento entre os endpoints WAN. O capture interior e a Rule ID mostram se o pacote útil passa pela regra e pela rota esperadas. Só a aplicação a funcionar confirma o caminho completo. O procedimento combinado é explicado em mais detalhe em Testar regras de firewall e Utilizar Packet Capture.

Isolar erros por sintoma

Nenhum pacote GRE sai da interface WAN

• Verificar o Remote Gateway e o local-gw local no túnel.
• Verificar a rota underlay para o endereço WAN remoto e o gateway WAN selecionado.
• Confirmar que o fluxo de teste corresponde efetivamente à rota GRE ou à SD-WAN Route prevista.
• Comparar os nomes e a associação com system gre tunnel show e system gre route show.
• Não criar uma permissão de porta TCP/UDP em substituição do protocolo IP 47.

O GRE sai do local A, mas não chega ao local B

• Verificar o protocolo IP 47 no fornecedor, nos routers a montante, nas ACLs da cloud e em possíveis trajetos NAT.
• Fazer simultaneamente um capture no local B com o filtro WAN exterior.
• Comparar os endereços exteriores de origem e destino com a configuração do peer.
• Perante WAN dinâmico, CGNAT ou NAT não esclarecido, parar e não ocultar a configuração com regras amplas.

O GRE é visível nos dois lados WAN, mas falta o tráfego interior

• Local IP e Remote IP têm de estar espelhados nas duas firewalls.
• Comparar, caráter a caráter, a rota GRE, a rede de destino e o nome do túnel.
• Verificar a regra de firewall e a Rule ID esperada em ambos os lados.
• Excluir redes sobrepostas, NAT e um caminho de retorno em falta.
• Não interpretar Enabled como prova da rota interior ou da aplicação.

Só funciona num sentido

• Verificar a rota GRE para a rede de retorno no local B.
• Confirmar se o local B deve iniciar novas ligações e se precisa de uma regra de firewall própria.
• Verificar no servidor de destino o Default Gateway, a firewall local do host e o IP de origem real.
• Comparar rotas SD-WAN ou estáticas assimétricas em ambos os lados.

Pacotes pequenos funcionam, mas ligações grandes ficam bloqueadas

O GRE adiciona um cabeçalho IP exterior e um cabeçalho GRE. Isto reduz o tamanho útil dos pacotes em relação ao underlay. Não se adota um valor fixo de MTU ou MSS sem validação: primeiro medem-se a MTU do underlay, o Path MTU Discovery, a fragmentação e a aplicação afetada. O procedimento controlado é explicado em Verificar MTU e MSS em problemas de VPN.

Testar HA e operação com cuidado

A documentação pública atual da Sophos não garante failover HA sem interrupções nem estado do túnel sincronizado para GRE. Por isso, uma mudança de função controlada só é efetuada numa janela de manutenção e com acesso de gestão independente.

Depois da mudança, voltam a verificar-se system gre tunnel show, system gre route show, o capture GRE exterior, uma nova ligação do cliente, a Rule ID e o caminho de retorno. Uma ligação TCP existente não é considerada prova de continuidade.

Em operação, documentam-se o responsável, ambos os endpoints WAN, IPs e nomes dos túneis, redes remotas, mecanismo de routing, regras de firewall, limite MTU esperado e último teste real. Depois de alterações em WAN, fornecedor, NAT, SD-WAN, Route Precedence ou peer, o caminho completo é novamente validado.

Efetuar um rollback seguro

O desmantelamento é coordenado em ambas as firewalls:

1. Parar o tráfego de teste e guardar o último estado com system gre tunnel show e system gre route show.

2. Desativar as novas regras de firewall e uma SD-WAN Route eventualmente criada.

3. Se tiver sido utilizado, retirar o Custom Gateway do caminho apenas depois de verificar Object usage.

4. No local A, remover a rota GRE concreta:

   system gre route del net 10.20.20.0/255.255.255.0 tunnelname gre_branch
   

5. No local B, remover a rota de retorno:

   system gre route del net 10.10.10.0/255.255.255.0 tunnelname gre_hq
   

6. Verificar com system gre route show que apenas desapareceram as entradas pretendidas.

7. Em seguida, eliminar no local A o túnel especificamente pelo nome:

   system gre tunnel del name gre_branch
   

8. No local B, eliminar apenas o túnel desse local:

   system gre tunnel del name gre_hq
   

9. Terminar com system gre tunnel show e um teste do caminho de routing anterior.

Não se utiliza del All. Se a sintaxe ou o nome do objeto não forem claros na build utilizada, confirma-se com Tab ou ? antes da eliminação, sem adivinhar.

Perguntas frequentes