Configurar um túnel IP Sophos Firewall com 6in4, 6to4, 6rd ou 4in6

Em Network > IP tunnels, a Sophos Firewall cria túneis que encapsulam um protocolo de rede noutro. Isto permite transportar IPv6 sobre uma infraestrutura IPv4 ou IPv4 sobre uma infraestrutura IPv6. O SFOS disponibiliza 6in4, 6to4, 6rd e 4in6 para estes cenários.

Esta função não é o túnel GRE da Device Console nem uma VPN IPsec. Um túnel IP encapsula pacotes, mas não os encripta nem autentica automaticamente.

⚠️ Um túnel IP só deve atravessar uma infraestrutura não fidedigna quando o desenho de segurança aceitar expressamente a falta de confidencialidade e autenticação do peer. Para ligações protegidas entre locais, IPsec site-to-site costuma ser o melhor ponto de partida.

Que tipo de túnel escolher?

Os quatro tipos não resolvem o mesmo problema:

• 6in4 liga duas redes IPv6 através de um backbone IPv4. Os endpoints IPv4 local e remoto são configurados manualmente. A Sophos recomenda este tipo para ligações ponto a ponto.
• 6to4 transporta IPv6 sobre IPv4 e destina-se a desenhos ponto a multiponto. A source IPv4 local é definida manualmente, enquanto o endereço de destino pode ser obtido automaticamente.
• 6rd amplia o 6to4 com um prefixo fornecido pelo operador. Só é adequado quando o ISP fornece os valores 6rd necessários.
• 4in6 liga duas redes IPv4 através de um backbone IPv6. Os endpoints externos local e remoto são endereços IPv6, e o tipo destina-se a ligações ponto a ponto.

Para uma ligação controlada com endpoints fixos, 6in4 ou 4in6 é mais fácil de compreender. Não se deve escolher 6to4 ou 6rd apenas porque o SFOS pode criar uma rota automaticamente. O endereçamento e o desenho do operador têm de corresponder exatamente a esse mecanismo.

O artigo Suporte de IPv6 na Sophos Firewall resume os limites de IPv6 no SFOS. Um túnel GRE, pelo contrário, transporta tráfego IP encaminhado através de um processo separado na Device Console e não é intercambiável com estes quatro tipos do WebAdmin.

Planear o exemplo e os requisitos

O exemplo utiliza um túnel 6in4 estático entre dois locais:

• Nome apresentado: HQ-IPv6-via-IPv4
• Hardware name: v6hq01
• Endereço WAN IPv4 local: 192.0.2.10
• Endpoint IPv4 remoto: 198.51.100.20
• Rede IPv6 local: 2001:db8:100::/64
• Rede IPv6 remota: 2001:db8:200::/64
• Servidor de teste: 2001:db8:200::20
• Zona da interface de túnel: VPN no exemplo

192.0.2.0/24, 198.51.100.0/24 e 2001:db8::/32 são intervalos de documentação. Devem ser substituídos, juntamente com nomes, zona e prefixos, pelos valores reais. A zona VPN é uma escolha compreensível para o exemplo, não um requisito do produto. O modelo de zonas, as regras de firewall e o Device Access devem corresponder à arquitetura real.

Antes de criar o túnel, ambos os endpoints externos têm de estar acessíveis pela infraestrutura. Em ambos os lados são necessários um túnel simétrico, redes internas únicas, um caminho de retorno e uma regra de firewall para o tráfego real. Prefixos sobrepostos, um valor do operador em falta para 6rd ou uma configuração do peer desconhecida são condições para parar.

Uma cópia de segurança, uma janela de manutenção e um acesso de gestão independente também fazem parte do plano de recuperação. O túnel não deve ser criado como experiência na única ligação de produção.

Criar o túnel IP no WebAdmin

Em Network > IP tunnels > Add, começa-se por definir a identidade e o tipo de túnel, seguindo-se os endpoints e os valores IP avançados.

Distinguir Name de Hardware name

O Name normal pode conter no máximo 58 caracteres e ser alterado posteriormente. Deve identificar a finalidade e o peer, por exemplo HQ-IPv6-via-IPv4.

O Hardware name é técnico e não pode ser alterado depois de guardar. Pode conter no máximo dez caracteres e apenas A-Z, a-z, 0-9 e _. O SFOS também bloqueia muitos nomes e fragmentos de sistema, incluindo gre, ipsec0, sit, tun, xfrm, Port, MGMT, eth, WLAN e Halink. O valor neutro v6hq01 evita estes conflitos.

Um Hardware name incorreto não pode ser renomeado posteriormente. É necessário documentar as dependências e recriar o túnel de forma controlada. Por isso, este valor deve ser verificado com especial cuidado antes de Save.

Definir o tipo, a zona e os endpoints

No exemplo, seleciona-se 6in4. Em Zone, define-se a zona de segurança prevista. Em Local endpoint, introduz-se 192.0.2.10 e, em Remote endpoint, 198.51.100.20.

A família de endereços depende do tipo. Em 6in4, 6to4 e 6rd, o endpoint externo local é IPv4; 6in4 também tem um endpoint IPv4 remoto fixo. Em 4in6, os endpoints externos local e remoto são endereços IPv6. Uma rota de destino interna não deve ser introduzida num campo de endpoint.

Nas definições avançadas, TTL influencia o tempo de vida dos pacotes encapsulados na infraestrutura. TOS atribui ao pacote IP externo um valor de tipo de serviço para prioridade e comportamento de routing. A ajuda atual não indica valores ideais universais. Ambos os campos permanecem, por isso, no valor inicial documentado enquanto um problema de routing ou QoS medido não justificar uma alteração.

Depois de Save, o SFOS confirma a criação e abre a caixa de diálogo de rotas. Para 6to4 e 6rd, a firewall também cria automaticamente uma rota unicast IPv6 estática. Importante: fechar esta janela ou selecionar Cancel não remove o túnel nem as rotas criadas automaticamente.

Adicionar rotas e regras de firewall

Um túnel guardado ainda não constitui um caminho de dados funcional. Para 6in4, adiciona-se uma rota IPv6 estática para o prefixo remoto 2001:db8:200::/64 através da nova interface de túnel. O peer necessita do caminho de retorno simétrico para 2001:db8:100::/64.

Em 4in6, a rota interna conduz a uma rede de destino IPv4. Em 6to4 e 6rd, lê-se a rota IPv6 criada automaticamente e compara-se com o desenho do operador antes de adicionar outras rotas. Cancel na primeira caixa de diálogo de rotas não constitui um rollback.

As rotas adicionais são criadas em Routing > Static routes. Rotas estáticas na Sophos Firewall explica como o prefixo de destino, a interface, a distância, a decisão de routing e um teste real se relacionam.

Em seguida, cria-se entre as zonas envolvidas uma regra de firewall restrita e com logging, utilizando valores reais de source, destination e service. Numa ligação normal entre locais mantém-se o endereço source original; não se ativa MASQ para compensar um caminho de retorno em falta. O processo está em Configurar regras da Sophos Firewall em segurança.

Validar o túnel e o tráfego da aplicação

A validação separa configuração guardada, encapsulamento externo e aplicação interna:

1. Em Network > IP tunnels, comparar Name, Hardware name, tipo, Zone e endpoints com o peer.
2. Em Routing > Static routes, verificar se o prefixo interno remoto aponta para a interface de túnel esperada.
3. Executar Route Lookup para o servidor de teste interno e confirmar a interface prevista.
4. A partir do cliente de teste local, iniciar uma nova ligação a 2001:db8:200::20 através de um serviço expressamente permitido.
5. Em Log Viewer, verificar Source, Destination, Service, Action e Firewall Rule ID.
6. Com Packet Capture, observar primeiro os endpoints externos e depois o endereço de teste interno.
7. No peer, verificar entrada, desencapsulamento, rota de retorno e endereço source efetivo.
8. Repetir o teste no sentido oposto apenas com uma regra destinada a esse sentido.

Uma entrada de túnel verde ou visível não comprova a rota nem o funcionamento do peer. Uma rota criada automaticamente também não comprova que o operador, os dispositivos intermédios e as regras transportem realmente o encapsulamento. Packet Capture na Sophos Firewall explica a captura controlada.

Diagnosticar por sintoma

Não é possível guardar o túnel

Verificar Name e Hardware name separadamente. Hardware name pode ter no máximo dez caracteres, utilizar apenas os caracteres permitidos e não conter um termo de sistema bloqueado. Em seguida, confirmar que o tipo de túnel e a família de endereços dos endpoints local e remoto correspondem.

Um nome apresentado diferente não corrige um Hardware name inválido. Se outra interface já utilizar o valor, deve planear-se um nome técnico único em vez de experimentar repetidamente sufixos aleatórios.

O túnel existe, mas não há rota para a rede de destino

Em 6in4 e 4in6, adiciona-se expressamente a rota estática necessária. Em 6to4 e 6rd, verifica-se se o SFOS criou a rota unicast IPv6 esperada e se o prefixo corresponde ao desenho. Uma janela fechada anteriormente com Cancel não elimina a configuração guardada automaticamente.

Route Lookup e a tabela de routing constituem a evidência seguinte. Route Precedence global não deve ser alterada com base numa suspeita e não deve ser adicionada uma rota blackhole ou fictícia concorrente como auxílio de teste.

Os pacotes externos são visíveis, mas falta o tráfego interno

É frequente não coincidirem o tipo do peer, os endereços de endpoint, o prefixo interno ou a rota de retorno. Comparar ambas as configurações de forma simétrica. Depois, verificar a regra de firewall, a Firewall Rule ID esperada e uma captura dos endereços source e destination internos.

O funcionamento do encapsulamento não comprova que o tráfego da aplicação esteja permitido. Inversamente, uma Rule ID em falta pode significar que o pacote interno nunca foi desencapsulado ou foi tratado por outra rota.

Os pacotes pequenos funcionam, mas as aplicações param

O encapsulamento IP externo adicional reduz o tamanho útil dos pacotes em comparação com a infraestrutura. Em vez de copiar um valor MTU alheio, devem medir-se Path MTU, fragmentação e a aplicação afetada. O processo controlado em Verificar MTU e MSS em problemas de túnel também se aplica a esta análise, mas os valores fixos de IPsec não são transferidos para o túnel IP.

HA, alterações e rollback

As duas páginas de ajuda do SFOS 22 não prometem um estado HA ininterrupto para estes túneis IP. Após uma mudança de funções planeada, voltam a verificar-se a entrada do túnel, Route Lookup, o encapsulamento externo, Firewall Rule ID e uma nova sessão da aplicação. Uma ligação existente não comprova continuidade.

Antes de uma alteração, documentam-se Name, o Hardware name imutável, tipo, Zone, endpoints, rotas criadas automática e manualmente, regras e o último teste real. Assim é possível distinguir uma alteração de configuração de uma mudança no caminho de dados.

Para o rollback, começa-se por parar o tráfego de teste. As regras dependentes e as rotas manuais são desativadas de forma controlada ou restauradas ao estado anterior confirmado. As rotas automáticas de 6to4 ou 6rd são verificadas expressamente. O túnel só é eliminado quando já não existir nenhuma dependência de produção. Por fim, voltam a validar-se o caminho de routing anterior e um fluxo conhecido.

Lista de verificação

• O tipo escolhido corresponde às famílias de endereços interna e externa.
• Ambos os endpoints e prefixos foram acordados com o peer.
• O nome apresentado e o Hardware name imutável estão documentados.
• Zone, rota estática e caminho de retorno correspondem ao desenho de segurança.
• As rotas automáticas de 6to4 ou 6rd foram verificadas.
• Uma regra restrita corresponde à Firewall Rule ID esperada.
• O encapsulamento externo e o tráfego interno foram testados separadamente.
• MTU, HA e rollback foram validados no caminho real.

Perguntas frequentes