Configurar NAT64 na Sophos Firewall com Direct Web Proxy

Um cliente só IPv6 pode aceder, através do Direct Web Proxy da Sophos Firewall, a um site que possui apenas um endereço IPv4. O SFOS resolve o nome de destino no proxy e estabelece a ligação seguinte através de IPv4. Para isso são necessárias duas regras de firewall: uma regra IPv6 do cliente para o proxy e uma regra IPv4 do proxy para o destino.

Isto não é NAT64 geral de layer 3 para protocolos arbitrários. Funciona apenas para ligações HTTP e HTTPS que browsers ou aplicações enviam explicitamente para o web proxy. Neste procedimento não é criada uma regra NAT64 normal em Rules and policies > NAT rules.

A classificação completa está em Suporte IPv6 e limites na Sophos Firewall com SFOS 22. O SFOS suporta este percurso NAT64 baseado em proxy, mas indica DNS64 como não suportado; isto não cria uma transição geral para outros protocolos.

⚠️ As duas regras têm funções diferentes. Para endpoints só IPv6, a Web Policy e a associação de utilizadores pertencem à regra IPv6. Application Control, IPS e outras funções de proteção da ligação IPv4 de saída pertencem à regra IPv4. Uma única regra ampla não torna esta separação visível de forma fiável.

NAT64 através do proxy em oito passos

Selecionar um cliente piloto só IPv6 gerido e um destino web A-only controlado.
Verificar o endereço IPv6, DNS, FQDN do proxy e listener TCP do Direct Web Proxy.
Preparar a configuração base do Direct Web Proxy, Device Access e do ficheiro PAC ou política do browser.
Na vista IPv6, criar uma regra com registo da rede piloto para a porta do proxy com a zona de destino WAN.
Definir a Web Policy e, se necessário, Match known users nesta regra IPv6.
Na vista IPv4, criar uma segunda regra com registo do proxy para o destino IPv4 com HTTP/HTTPS.
Testar com um destino sem registo AAAA e verificar ambos os Firewall Rule IDs e a decisão do filtro web.
Adicionar mais clientes apenas após testes positivos e negativos; validar separadamente rollback, HA e SD-WAN.

Porque são necessárias duas regras de firewall

O caminho dos dados muda de versão IP no proxy:

O cliente liga-se através de IPv6 ao listener do proxy da firewall.
A regra IPv6 avalia cliente, utilizador, nome de destino, porta do proxy e Web Policy.
O proxy resolve o hostname solicitado.
Se o destino tiver apenas um registo A, o proxy cria uma nova ligação IPv4.
A regra IPv4 avalia este segundo segmento e aplica, por exemplo, Application Control ou IPS.

A segunda ligação já não é o pacote IPv6 original do cliente. Por isso, a regra IPv4 não deve ser desenhada como se o endereço IPv6 do cliente tivesse de aparecer como origem. Ao mesmo tempo, uma regra IPv6 bem-sucedida, por si só, ainda não demonstra que o proxy consegue realmente alcançar o destino IPv4.

A Sophos denomina esta arquitetura um cenário NAT64. No entanto, ao contrário de um gateway NAT64 clássico, não é encaminhado um prefixo IPv6 para destinos IPv4 arbitrários. Aplicações sem suporte de proxy explícito, UDP, ICMP e outro tráfego que não passe pelo proxy não são traduzidos por este procedimento.

Configurar Direct Web Proxy com um ficheiro PAC explica a configuração geral do listener, PAC, Device Access e rollback. Este artigo pressupõe que o caminho base do proxy funciona e acrescenta apenas a transição de IPv6 para IPv4.

Exemplo e valores a substituir

O procedimento utiliza um pequeno piloto:

Cliente só IPv6: CLIENT6-PROXY-01
Rede piloto: 2001:db8:20:30::/64
Endereço IPv6 da firewall na rede do cliente: 2001:db8:20:30::1
FQDN do proxy: fw01.corp.example
Porta do proxy: TCP 3128
Destino A-only controlado: v4-test.corp.example
Endereço de destino de documentação: 192.0.2.80
Regra IPv6: LAN6_DirectProxy_to_IPv4
Regra IPv4: Proxy_IPv4_Egress_Pilot
Web Policy: Web_Standard_IPv6_Pilot

2001:db8::/32, 192.0.2.0/24 e .example são intervalos de documentação. Não funcionam como endereços de produção e devem ser substituídos pelo prefixo IPv6 da organização, pelo endereço real da firewall e por um nome DNS controlado. O cliente piloto deve usar realmente apenas IPv6; um caminho IPv4 ativo em paralelo invalidaria o teste.

O destino de teste necessita de um registo A, mas não pode ter um registo AAAA. Um pequeno web server próprio ou um virtual host de teste controlado é a melhor opção. Um site público escolhido ao acaso não é adequado, pois o seu operador pode ativar IPv6 ou alterar as respostas DNS a qualquer momento.

Configurar IPv6 Prefix Delegation explica como o prefixo WAN, Router Advertisement e DHCPv6 funcionam em conjunto. NAT64 não corrige a ausência de endereçamento IPv6 na rede do cliente.

Verificar os pré-requisitos

Antes de criar as regras, quatro bases distintas devem funcionar:

O cliente possui um endereço IPv6 válido, uma default route e DNS funcional.
fw01.corp.example devolve, na rede do cliente, a resposta AAAA prevista da firewall.
Direct Web Proxy está a escutar na porta documentada em Web > General settings > Web proxy configuration, 3128 neste exemplo.
A firewall possui um caminho WAN IPv4 funcional para o destino.

Em Administration > Device access, Web proxy deve estar acessível para a origem concreta do cliente e para o endereço previsto da firewall. Uma permissão ampla para toda a zona LAN ou Wi-Fi não é necessária para um piloto. O limite do proxy continua a ser importante: um cliente autorizado pode alcançar por este caminho serviços HTTP/HTTPS locais da firewall. Por isso, os destinos de gestão são testados explicitamente como casos negativos, tal como descrito no artigo base.

O cliente recebe o FQDN e a porta do proxy através de uma política de browser gerida, uma definição do sistema operativo ou um ficheiro PAC. O FQDN deve estar acessível através de IPv6 a partir do cliente só IPv6. Um cliente só IPv6 não consegue usar como primeiro hop um endereço de proxy que possui apenas um registo A.

Documentar as regras de firewall, Web Policies, autenticação, TLS Inspection e SD-WAN Routes existentes. Posicionar as duas regras piloto suficientemente acima para serem avaliadas antes de uma regra geral correspondente, sem ultrapassar de forma descontrolada as regras de proteção existentes.

Criar a regra IPv6 para o proxy

Em Rules and policies > Firewall rules, selecionar primeiro IPv6 e criar uma regra através de Add firewall rule > New firewall rule:

Rule name: LAN6_DirectProxy_to_IPv4
Action: Accept
Log firewall traffic: ativo
Source zones: LAN
Source networks and devices: rede piloto IPv6 ou cliente piloto individual
Destination zones: WAN
Destination networks: destino FQDN controlado ou, para o rollout posterior, o conjunto de destinos planeado de forma consciente
Services: serviço TCP próprio para 3128
Match known users: apenas com autenticação já funcional e os utilizadores ou grupos previstos
Web filtering > Web policy: Web_Standard_IPv6_Pilot

A zona de destino WAN parece inicialmente invulgar, porque tecnicamente o cliente liga-se a um endereço da firewall. Contudo, a Sophos exige WAN ou Any para entregar o tráfego ao componente proxy. Segundo o fabricante, isto também se aplica quando o web server final está em LAN ou DMZ. Por isso, a zona de destino não deve ser alterada por suposição para a zona física do servidor.

A Sophos também permite Any em Services. A porta concreta do listener é mais clara para um piloto e evita uma permissão desnecessariamente ampla. Se a Web proxy listening port for alterada, o serviço, a definição PAC/browser, Device Access e os testes devem usar o mesmo valor.

Para endpoints só IPv6, configurar utilizadores e grupos nesta regra IPv6. A Web Policy também se aplica aqui. O guia sobre regras de firewall explica a ordem, logging e associação de utilizadores; as categorias e ações são planeadas nas Web Protection Policies.

Criar a regra IPv4 do proxy para o destino

Em seguida, mudar para IPv4 em Rules and policies > Firewall rules e criar a segunda regra:

Rule name: Proxy_IPv4_Egress_Pilot
Action: Accept
Log firewall traffic: ativo
Source zones: Any
Source networks and devices: Any
Destination zones: WAN
Destination networks: primeiro o destino A-only controlado, posteriormente apenas o conjunto de destinos realmente necessário
Services: HTTP e HTTPS, ou as portas de destino realmente necessárias
Match known users: neste procedimento só IPv6, não usar como substituto da associação de utilizadores na regra IPv6
Other security features: políticas previstas de Application Control, IPS e, se necessário, Traffic Shaping

O exemplo oficial da Sophos utiliza Any para a zona e rede de origem porque o proxy cria a ligação IPv4. Estes valores não devem ser substituídos incorretamente pela rede do cliente IPv6. Em vez disso, manter a regra piloto limitada através do destino e dos serviços e verificá-la pela respetiva Rule ID.

A Web Policy não é transferida para esta regra IPv4. Pertence ao primeiro segmento do proxy, relacionado com o utilizador. Application Control e IPS protegem, por outro lado, o segmento entre o proxy e o destino IPv4. Uma política de Traffic Shaping na regra IPv4 aplica-se a este egress; a Sophos também documenta que Traffic Shaping não se aplica à ligação direta entre cliente e proxy.

Não criar uma regra NAT64 adicional. O caminho WAN IPv4 normal da firewall deve continuar a funcionar. Se uma regra IPv4 existente já cobrir este egress do proxy de forma controlada, pode continuar a ser utilizada depois de verificar a Rule ID e as políticas; uma segunda regra Any paralela seria pior do que uma regra existente conscientemente documentada.

Testar o caminho real de IPv6 para IPv4

Pré-verificação de DNS e listener

Num cliente piloto Windows, são úteis as seguintes verificações só de leitura:

Resolve-DnsName fw01.corp.example -Type AAAA
Resolve-DnsName v4-test.corp.example -Type A
Resolve-DnsName v4-test.corp.example -Type AAAA
Test-NetConnection fw01.corp.example -Port 3128

O FQDN do proxy deve devolver o endereço IPv6 esperado. O destino de teste deve ter um registo A; no teste AAAA não é esperado qualquer endereço de destino. Test-NetConnection confirma apenas o listener TCP, não a Web Policy, a resolução DNS no proxy nem o egress IPv4.

Validar ambas as regras e camadas de proteção

Abrir uma nova sessão privada do browser no piloto só IPv6.
Verificar o proxy efetivo ou o ficheiro PAC carregado.
Abrir o destino A-only permitido.
Abrir um destino bloqueado intencionalmente por Web_Standard_IPv6_Pilot.
Em Log viewer, verificar a regra IPv6, origem, utilizador, Web Policy, ação e Firewall Rule ID.
Para a ligação seguinte, verificar a regra IPv4, destino IPv4, serviço, Application Control/IPS e o segundo Firewall Rule ID.
Repetir o pedido ao destino sem proxy como teste negativo; o cliente só IPv6 não deve conseguir alcançar diretamente por IPv4 o destino A-only.
Testar uma aplicação sem suporte de proxy e confirmar que não é incorretamente considerada compatível com NAT64.

O sucesso só fica comprovado quando o nome de destino é realmente A-only, o cliente alcança o proxy através de IPv6, ambas as regras esperadas correspondem e os testes web permitido e bloqueado mostram as ações planeadas. Testar sistematicamente regras de firewall explica como correlacionar Rule ID, Log Viewer, Policy Tester e Packet Capture.

Delimitar erros sistematicamente

A porta do proxy não está acessível através de IPv6

Verificar a resposta AAAA do FQDN do proxy, endereço do cliente, default route, Neighbor Discovery, interface da firewall e Web proxy em Device Access. Um teste IPv4 bem-sucedido a partir de outro cliente não demonstra nada sobre o caminho do listener IPv6.

A regra IPv6 corresponde, mas o destino não carrega

Confirmar primeiro que o proxy resolve o nome de destino como registo A e que a própria firewall possui um caminho WAN IPv4 funcional. Depois verificar a regra IPv4, destino, serviço, ordem e Rule ID. A regra IPv6 é apenas a primeira metade.

Apenas funcionam sites dual-stack

O caminho NAT64 ainda não está comprovado. Verificar se o destino de teste possui um registo AAAA. Para a aceitação, usar um destino A-only próprio e excluir um caminho IPv4 ativo no cliente.

A Web Policy ou o utilizador está incorreto

Verificar a associação na regra IPv6. O SFOS avalia Match known users em ambas as regras para endpoints só IPv6, mas a Sophos atribui explicitamente estas definições à regra IPv6. Uma correspondência de utilizador na regra IPv4 não deve substituir o contexto de utilizador em falta no primeiro segmento.

Application Control ou IPS não se aplica

Verificar estas funções na regra IPv4, não apenas na regra IPv6. Depois confirmar através da IPv4 Rule ID que esta regra processa realmente o egress do proxy. Uma decisão correta do filtro web não comprova Application Control nem IPS.

Destinos internos ou locais comportam-se de forma inesperada

Mesmo quando o destino final está em LAN ou DMZ, a regra IPv6 exige WAN ou Any para entregar o tráfego ao proxy. A zona de destino real é representada na regra IPv4. Verificar também a exposição de serviços de gestão locais causada pelo acesso ao proxy e as respostas DNS internas.

SD-WAN, HA e rollback

Uma SD-WAN Route com os serviços HTTP e HTTPS não corresponde à ligação do cliente à porta de proxy 3128. No primeiro segmento deve usar-se a porta real do listener ou, conscientemente, Any. O egress do proxy também necessita de um gateway WAN funcional ou de um caminho de retorno estático. Configurar e testar SD-WAN Routes explica estes casos especiais.

Em HA, não se deve prometer a continuação sem interrupções de uma ligação proxy existente. Após um failover controlado, abrir uma nova sessão do browser e voltar a verificar o registo AAAA do proxy, IPv6 Rule ID, Web Policy, IPv4 Rule ID e acesso ao destino. Para procurar logs, conta o node que processou o tráfego correspondente.

Para o rollback:

Desativar as regras piloto ou repor o estado anterior documentado.
Remover a exceção Device Access dedicada ao piloto, se tiver sido criada apenas para este teste.
Retirar do piloto a definição PAC, GPO ou proxy do browser.
Restaurar a ordem anterior das regras IPv4/IPv6 e a configuração SD-WAN.
Voltar a verificar o acesso IPv6 direto, o tráfego proxy existente e os serviços de gestão locais.

Não eliminar as duas regras antes de documentar o caminho anterior e de existir uma sessão de administração aberta ou acesso de gestão alternativo.

Checklist de aprovação

O cliente é comprovadamente só IPv6.
O FQDN do proxy devolve o endereço AAAA esperado.
O destino de teste possui um registo A, mas nenhum registo AAAA.
Direct Web Proxy e Device Access estão limitados ao piloto.
A regra IPv6 utiliza a zona de destino WAN, a porta real do listener, logging e Web Policy.
A associação de utilizadores, se necessária, passou testes positivos e negativos na regra IPv6.
A regra IPv4 processa o egress do proxy com as portas de destino e funções de proteção planeadas.
Ambos os Firewall Rule IDs e ambas as versões IP estão comprovados no teste.
A exposição de serviços de gestão, tráfego não proxy, SD-WAN e HA estão conscientemente delimitados.
Rollback, responsável e data de revisão estão documentados.

Perguntas frequentes

O NAT64 na Sophos Firewall necessita de uma regra NAT normal?

Não para este procedimento documentado do web proxy. O SFOS disponibiliza acesso de IPv6 para IPv4 dentro do caminho do proxy explícito. São necessárias uma regra de firewall IPv6 e outra IPv4, mas nenhuma regra NAT64 geral em Rules and policies > NAT rules.

Esta configuração NAT64 funciona para todas as aplicações?

Não. Aplica-se a HTTP/HTTPS de clientes e aplicações que utilizam explicitamente Direct Web Proxy. Tráfego que não passa pelo proxy, UDP, ICMP ou aplicações sem suporte de proxy necessitam de outra transição IPv6/IPv4 ou de manter conectividade nativa.

Porque não basta uma única regra de firewall?

O proxy termina a ligação IPv6 do cliente e cria depois uma nova ligação IPv4 para o destino A-only. A Web Policy e a associação de utilizadores são avaliadas no segmento IPv6; Application Control e IPS para o egress no segmento IPv4. Ambos os caminhos têm de ser permitidos, registados e testados separadamente.