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.

Procedimento resumido: Planear separadamente a rede de destino interna e os endpoints externos, guardar o tipo adequado em Network > IP tunnels > Add e adicionar a rota, a rota de retorno e uma regra restrita para o tráfego interno. Em seguida, testar uma nova sessão da aplicação e verificar separadamente o encapsulamento externo, o desencapsulamento e a Rule ID. Save confirma a configuração, não um caminho de dados testado com sucesso.

⚠️ 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.

A ajuda do SFOS 23 explica o mecanismo automático com mais precisão: 6to4 deriva o prefixo IPv6 do endereço IPv4 público local. Não se configura um endpoint remoto; o gateway de destino é determinado automaticamente a partir do endereço IPv6 de destino. Em contrapartida, 6rd utiliza prefixos IPv6 e gateways de relay fornecidos pelo ISP. A firewall determina automaticamente o gateway de relay fornecido pelo ISP. Para isso, o ISP tem de disponibilizar um serviço 6rd adequado; se houver IPv6 nativo, este deve ser preferido. Estes mecanismos não alteram o aviso abaixo sobre a tecnologia legada.

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.

Em 6to4, também é necessário distinguir o mecanismo unicast ainda definido do mecanismo de relay anycast público. A IETF descontinuou o anycast 6to4 devido aos seus problemas operacionais e recomenda que os routers mantenham o 6to4 desativado por predefinição (RFC 7526). Por isso, não se deve ativar 6to4 para uma nova ligação à Internet. No máximo, deve ser usado num desenho unicast existente e expressamente coordenado; conectividade IPv6 nativa, 6rd gerido pelo operador ou um peer 6in4 fixo são alternativas mais controláveis.

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 e as regras de firewall devem corresponder à arquitetura real. Device access controla o acesso aos serviços da própria firewall e não substitui uma regra para tráfego aplicacional encaminhado.

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.

A infraestrutura tem de transportar um protocolo IP encapsulado, não uma porta TCP ou UDP. 6in4, 6to4 e 6rd usam IPv6-em-IPv4 com o número de protocolo IPv4 41 (RFC 4213); 4in6 segue o modelo de túnel IPv6 da RFC 2473 e identifica o pacote IPv4 interno no cabeçalho IPv6 externo com o valor Next Header 4 registado pela IANA. Antes da implementação, é necessário confirmar este caminho de dados exato com o operador, a firewall a montante e qualquer dispositivo NAT. Abrir uma porta não substitui esta verificação.

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.

Nas outras definições é apresentado este nome de interface personalizável, não o Hardware name imutável.

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.

A lista completa de restrições documentadas para Hardware name no SFOS 22 e 23 é: all, gre, oct, mv-pcimux0, mvmgmt0, pport_, lo, ipsec0, tun, ppp, imq, ifb, mast, sit, WWAN1, _ppp, vxlan, xfrm, USB, erspan0, Port, MGMT, eth, GE, gretap0, ip6tnl0, host, reds, wlnet, WLAN, Sophos, GuestAP, spq, Halink. O nome não pode conter nenhum destes fragmentos; a proibição não se limita a nomes completos idênticos. Mantêm-se as grafias documentadas, sem deduzir como são verificadas as maiúsculas e minúsculas.

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 designação Remote endpoint segue a ajuda do SFOS 22. A ajuda do SFOS 23 chama ao campo Remote gateway: aceita um endereço IPv4 ou FQDN para 6in4, e um endereço IPv6 ou FQDN para 4in6. Um FQDN é o nome DNS completo do peer, não o prefixo interno de destino. Para Local endpoint, o SFOS 23 descreve um endereço associado a uma interface (6in4/6to4), explicitamente um endereço IPv4 associado para 6rd, e uma interface IPv6 para 4in6. A família de endereços local mantém-se como descrito abaixo. As diferenças na ajuda não demonstram em que versão exata começou o suporte em execução.

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 nem um valor predefinido na página de ajuda. Por isso, devem registar-se os valores iniciais apresentados no próprio formulário e alterá-los apenas quando um requisito concreto da infraestrutura ou de QoS o exigir.

Estas bases de TTL/TOS seguem a ajuda do SFOS 22. A ajuda do SFOS 23 explica TTL como o número máximo de routers que um pacote encapsulado pode atravessar antes de ser descartado. Este limite ajuda a evitar ciclos de routing. Também aqui não é indicado um valor numérico predefinido para TTL ou ToS.

Para 4in6, o SFOS 23 descreve ainda estas definições avançadas:

• Inherit ToS é opcional e utiliza o valor ToS do pacote interno.
• MTU é o maior tamanho de pacote em bytes que pode atravessar o túnel sem fragmentação. O valor predefinido documentado é a MTU da interface física menos 48 bytes; a redução tem em conta a sobrecarga do encapsulamento 4in6.
• Override MSS é opcional e permite especificar manualmente a MSS. MSS é a maior carga útil TCP em bytes num único pacote TCP sem fragmentação. O ajuste permite evitar fragmentação ou ter em conta os limites de Path MTU. O valor predefinido documentado é o valor MTU menos 40 bytes.

Estas fórmulas são valores documentados, não cálculos próprios da sobrecarga do protocolo nem resultados de laboratório. Não se afirma um estado de ativação predefinido para as caixas de seleção opcionais. Qualquer ajuste continua a depender do caminho real.

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.

API do SFOS 23: esquema e validação

Esta secção descreve a documentação da API para Add IP Tunnel / Edit IP Tunnel, não o procedimento do WebAdmin nem um pedido testado. Em comparação com a documentação do SFOS 22, a tabela de parâmetros do SFOS 23 acrescenta quatro campos opcionais do tipo SCALAR:

• MSS: INTEGER, intervalo permitido 536–8912, no máximo quatro dígitos.
• MTU: INTEGER, intervalo permitido 576–8952, no máximo quatro dígitos.
• LocalInterface: STRING para a interface local do túnel; a célula Default está vazia. Isto não confirma um valor predefinido em execução.
• InheritToS: valores permitidos Disable e Enable.

A tabela não confirma a aplicação de cada campo a cada tipo de túnel, a precedência entre LocalInterface e LocalEndPoint, as combinações obrigatórias de campos nem a versão em que começou o suporte em execução. As indicações do WebAdmin sobre endpoints e FQDN não são transferidas como garantia de compatibilidade com a API.

Estado 541 da API em Add e Edit

Para ambas as operações, o SFOS 23 documenta o estado 541 com a mensagem MTU and MSS must not exceed the local interface values. MTU e MSS não podem, portanto, exceder os valores correspondentes da interface local. Antes de alterar qualquer valor, comparam-se os valores MTU/MSS enviados, a interface local associada e a respetiva configuração registada. Esta validação da API não mede a MTU do caminho de dados nem confirma uma relação geral de cálculo entre MTU e MSS.

Os valores predefinidos contraditórios continuam por esclarecer

A tabela da API indica literalmente Default: Enable para MSS, embora descreva o campo como INTEGER com um intervalo numérico. Para InheritToS, indica literalmente Default: off, embora enumere apenas Disable e Enable como valores permitidos. Estes valores contraditórios da documentação não são valores recomendados para um payload e não são corrigidos nem reinterpretados como outros tokens.

A API indica ainda 1500 como MTU predefinida e descreve a herança de ToS da interface local. A ajuda do WebAdmin para 4in6 indica, pelo contrário, a MTU da interface física menos 48 bytes, MSS igual a MTU menos 40 bytes e herança de ToS do pacote interno. A correspondência entre estas interfaces continua por esclarecer; as fórmulas corretas e os controlos opcionais do WebAdmin acima permanecem inalterados.

Continuam excluídas as instruções de automatização diretamente aplicáveis que pressuponham estes valores predefinidos, regras de herança ou prioridades entre campos. Por isso, não é disponibilizado aqui um payload de API executável. É necessário um esclarecimento da Sophos ou um teste expressamente autorizado na versão correspondente do SFOS; as informações documentadas sobre o esquema e o estado não constituem um teste do produto.

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.

Para rotas IPv6 adicionais depois de guardar 6to4 ou 6rd, o SFOS 23 identifica no pop-up os campos Destination IP (IPv6) e Gateway (IPv6). Introduzir destino e gateway de acordo com o desenho e selecionar Save; escolher Cancel se não for necessária outra rota. Estes campos IPv6 não se aplicam à rota IPv4 interna de um túnel 4in6. Continua a ser importante o aviso do SFOS 22 sobre a configuração guardada ao utilizar Cancel.

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.

Para o exemplo 6in4, aceder a Rules and policies > Firewall rules, selecionar IPv6 e depois Add firewall rule > New firewall rule. Definir Action: Accept, os valores reais de Source zones, Source networks and devices, Destination zones, Destination networks e Services, e ativar Log firewall traffic. Posicionar a regra para que uma regra mais abrangente não seja aplicada primeiro. As respostas pertencentes a uma ligação stateful permitida não precisam de uma segunda regra. Só se cria uma regra própria e igualmente restrita se o peer tiver de iniciar novas ligações.

Numa ligação normal entre locais mantém-se o endereço source original. Deixar Create linked NAT rule desativado; não se ativa MASQ para compensar um caminho de retorno em falta. O SFOS encaminha sem tradução o tráfego permitido quando nenhuma regra NAT corresponde. Se o desenho exigir realmente tradução, esta deve ser planeada e testada separadamente com os fluxos original e traduzido. O processo está em Configurar regras da Sophos Firewall em segurança.

4in6: transportar tráfego IPv4 sobre IPv6

Em 4in6, não muda apenas o tipo de túnel em relação ao exemplo 6in4. Os endpoints externos são IPv6, enquanto as redes encaminhadas e as regras de firewall são IPv4. Um exemplo de planeamento separado utiliza 10.10.10.0/24 como rede local, 10.20.20.0/24 como rede remota e 10.20.20.20 como servidor de teste. O endereço externo da interface local é 2001:db8:10::10 e o endereço do gateway remoto é 2001:db8:20::20. As redes IPv4 privadas e os endereços IPv6 de documentação devem ser substituídos por redes internas únicas e não sobrepostas e por endpoints IPv6 efetivamente acessíveis pela infraestrutura.

1. Verificar previamente o caminho da infraestrutura IPv6 até 2001:db8:20::20. A rota para o peer externo tem de passar pela infraestrutura, não pelo túnel que se pretende estabelecer com esse mesmo peer. Um ping bem-sucedido, por si só, não comprova o transporte dos pacotes IPv4 encapsulados.
2. Em Network > IP tunnels > Add, selecionar 4in6, definir um nome e um Hardware name únicos e atribuir a Zone prevista. No SFOS 23, selecionar em Local endpoint a interface IPv6 com o endereço local previsto e introduzir em Remote gateway o endereço IPv6 remoto. No peer, os endpoints local e remoto são invertidos. Continuam a aplicar-se as definições do SFOS 23 para MTU, Override MSS e Inherit ToS descritas acima.
3. Depois de Save, criar em Routing > Static routes uma rota IPv4 para 10.20.20.0/24 através da nova interface de túnel. No peer, configurar a rota de retorno para 10.10.10.0/24. Os campos IPv6 da caixa de diálogo de rotas adicionais de 6to4/6rd não servem de modelo para esta configuração.
4. Em Rules and policies > Firewall rules, selecionar IPv4. Permitir apenas as ligações necessárias da rede IPv4 local para a rede IPv4 remota, definir as zonas e os serviços reais e ativar Log firewall traffic. Os endereços da infraestrutura IPv6 não devem substituir as redes IPv4 internas nesta regra de tráfego. Se não houver uma tradução de endereços prevista, mantém-se o endereço source.
5. Verificar 10.20.20.20 com Diagnostics > Tools > Route lookup e, em seguida, iniciar a partir do cliente de teste local uma nova ligação permitida a esse servidor. No peer, verificar o desencapsulamento e o caminho de retorno. Depois de terminar a sessão de teste, os endereços IPv4 internos e a Firewall Rule ID esperada têm de aparecer no Log Viewer; durante a sessão, a captura permite verificar diretamente o caminho.
6. Para a captura externa no procedimento descrito abaixo, utilizar o filtro BPF host 2001:db8:10::10 and host 2001:db8:20::20. Para a captura interna separada, voltar a apagar o BPF string e selecionar em Display filter Ethernet type: IPv4 e Destination IP: 10.20.20.20. Capturar apenas um teste de cada vez e parar a captura em seguida. O rollback segue a mesma verificação de dependências descrita abaixo, mas, neste caso, aplica-se às rotas e regras IPv4 criadas especificamente para este túnel.

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. Em Diagnostics > Tools > Route lookup, introduzir o endereço interno 2001:db8:200::20 e confirmar a interface de túnel 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. Em Diagnostics > Packet capture > Configure, introduzir host 192.0.2.10 and host 198.51.100.20 em Enter BPF string para a verificação externa e guardar. Iniciar a captura, gerar exatamente um teste e pará-la. Para uma captura interna separada, apagar o BPF string em Configure e guardar; depois, definir Ethernet type: IPv6 e Destination IP: 2001:db8:200::20 em Display filter e guardar. Iniciar a captura apenas durante um teste e voltar a pará-la.
7. No peer, verificar entrada, desencapsulamento, rota de retorno e endereço source efetivo.
8. Testar uma nova ligação iniciada pelo peer apenas se uma regra própria a permitir; a regra stateful já abrange o tráfego de resposta.

O filtro externo por host também captura outro tráfego entre os endpoints. Por isso, no exemplo 6in4, devem procurar-se pacotes com os endereços IPv4 externos esperados e protocolo IP 41; um ping ICMP entre os mesmos hosts não comprova o encapsulamento. Para 4in6, verifica-se, de forma equivalente, um pacote IPv6 externo com um pacote IPv4 interno. Só a comparação com a captura interna e com a sessão da aplicação efetivamente bem-sucedida comprova o caminho completo. Os dados da captura podem conter dados de aplicação e só devem ser armazenados de forma protegida ou anonimizados antes de serem partilhados.

Uma entrada de túnel não comprova a rota nem a acessibilidade 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.

O tráfego de teste não aparece na captura externa

Começar por comparar os filtros de captura e de visualização ativos com os endpoints externos efetivamente utilizados. Se Remote gateway for um FQDN, verificar se a firewall consegue resolver o nome para o endereço esperado do peer, na família de endereços correspondente ao tipo de túnel: IPv4 para 6in4, IPv6 para 4in6. A opção FQDN, por si só, não comprova um intervalo específico de atualização DNS nem um failover sem interrupções quando o endereço muda.

Em seguida, verificar se o cliente de teste está efetivamente a enviar tráfego para o destino interno e se este chega à firewall através do gateway do cliente. Na firewall, a decisão de routing para esse destino tem de selecionar a interface de túnel. Se o encapsulamento adequado for visível localmente, mas não no peer, deve verificar-se o caminho da infraestrutura e as permissões dos protocolos no operador e nos dispositivos a montante. As regras não devem ser alargadas indiscriminadamente para Any, nem se deve ativar NAT a título experimental para substituir esta análise. Se a causa continuar por esclarecer, a versão do SFOS, as configurações de ambos os endpoints, as rotas e as capturas sincronizadas de ambos os lados constituem a base para o escalamento.

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.

Segundo a ajuda do SFOS 23, eliminar um túnel 6to4 ou 6rd elimina também a respetiva rota unicast IPv6 estática criada automaticamente. Esta expectativa não substitui as verificações de dependências nem a comparação antes/depois. Não abrange todas as rotas adicionadas manualmente nem é aplicada ao SFOS 22 apenas com base na ajuda do SFOS 23.

Para o rollback, começa-se por parar o tráfego de teste e desativar a nova regra de firewall. Eliminam-se apenas as rotas manuais criadas para este túnel ou repõem-se as rotas alteradas no estado inicial registado. As rotas automáticas de 6to4 ou 6rd são comparadas expressamente com o registo anterior e posterior. O túnel só é eliminado quando já não existir nenhuma dependência de produção; em seguida, elimina-se individualmente qualquer rota automática que tenha permanecido. Por fim, confirma-se o caminho anterior com Route lookup e testa-se novamente 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