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.

A função WebAdmin Network > IP tunnels é separada. Utiliza 6in4, 6to4, 6rd ou 4in6 para transportar IPv6 sobre IPv4 ou IPv4 sobre IPv6. Túneis IP na Sophos Firewall explica o tipo adequado, os campos de endpoint e o comportamento especial da caixa de diálogo de rotas.

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. Antes da alteração, confirma-se na build utilizada com Tab ou ? o comando completo e se os parâmetros seguintes estão disponíveis por esta ordem. Os exemplos são transcrições de referência e não foram testados em laboratório numa firewall; não devem ser executados se a ajuda instalada for diferente.

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.

Alterar TTL, estado e DDNS de forma controlada

A API de túneis GRE do SFOS 22 define dados adicionais para TTL, estado e DDNS: TTL de 0 a 255, estado Enabled ou Disabled e DDNS On ou Off. Também permite um endereço IP ou um nome DDNS para Remote Gateway. Estes são valores do modelo de dados da API, não uma confirmação da sintaxe da Device Console.

Estes valores da API não devem ser convertidos por suposição em sintaxe da Device Console. Na build instalada, introduzir system gre tunnel e utilizar Tab ou ? para confirmar a sequência de comandos apresentada. Guardar system gre tunnel show antes e depois de alterar exatamente um valor e, em seguida, testar o caminho GRE exterior e tráfego útil real. Um TTL demasiado baixo pode impedir que o pacote GRE exterior chegue ao peer. O DDNS também acrescenta uma dependência de DNS ao estabelecimento do túnel que deve ser monitorizada durante a operação.

Encaminhar redes remotas através de GRE

Para o caminho fixo simples, cria-se uma rota GRE em cada firewall. O comando completo é verificado com Tab ou ? antes de alterar qualquer uma das firewalls. 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. Abrir o Log viewer no canto superior direito, selecionar o módulo Firewall e verificar Source, Destination, Service, Firewall Rule ID, NAT Rule ID e Zone em ambas as firewalls.

5. No local A, abrir Diagnostics > Packet capture > Configure, introduzir a expressão seguinte em Enter BPF string, guardá-la, ativar Packet capture e 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. No capture interior, comparar também In interface, Out interface, Rule ID, NAT ID, Status e, em caso de descarte, Reason. Introduzir os filtros de capture como expressões BPF. Uma sessão de firewall é normalmente registada quando recebe o evento Destroy. Se uma ligação ainda aberta não apresentar uma entrada, usar primeiro o capture em curso; depois fechar a ligação de forma controlada e atualizar o Log viewer. 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. Para a nova configuração aqui descrita, a eliminação dos objetos recém-criados é o caminho de retorno predefinido. Se tiver sido alterada uma regra, SD-WAN Route, Custom Gateway ou opção de túnel existente, restauram-se os valores anteriores concretos registados antes da alteração; não se adivinham valores predefinidos desconhecidos. Em seguida, volta a validar-se o mesmo caminho de pacotes utilizado na aceitação.

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