A sua regra de VPN para IPv4 não diz nada sobre o tráfego IPv6

Uma auditoria encontra o túnel filtrado de forma estrita para IPv4 e totalmente aberto para IPv6 na mesma interface. Nada estava mal configurado no sentido de erro de digitação; o conjunto de regras simplesmente descrevia uma família e todos presumiram que a outra a acompanhava. Raramente acompanha. Três condições decidem se a sua regra cobre realmente as duas, e a primeira diz respeito à plataforma e não à política.

Condição um: a plataforma tem uma tabela ou duas

Alguns filtros de pacotes mantêm IPv4 e IPv6 em conjuntos de regras totalmente separados, pelo que uma regra adicionada a um não tem efeito no outro até alguém a duplicar. Outros oferecem uma família que corresponde a ambos e traduz os endereços por pacote. Um terceiro grupo mantém uma única linguagem de política mas guarda atrás objetos separados por família.

Leia a documentação do filtro que realmente executa e depois liste que tabelas existem e qual foi tocada pela sua alteração. Contar as regras da tabela IPv4 responde a uma pergunta que ninguém fez. Depois liste que tabelas existem e qual foi tocada pela sua alteração.

Condição dois: onde se aplica a política

Três locais confundem-se entre si: o ouvinte que aceita o túnel, o caminho que reencaminha o tráfego e a interface normal que o cliente usa quando o túnel não transporta um fluxo. Um gateway pode aceitar uma sessão enquanto descarta tudo o que dela é reencaminhado, e isso parece um túnel avariado e não um filtro. Elimine essa confusão antes de escrever o que quer que seja, porque os três locais têm proprietários e registos diferentes. Nomeá-los no registo de alterações é o que impede uma correção de aterrar uma camada além da falha.

Anote qual dos três a sua regra deve governar. Uma regra que protege o ouvinte não protege o caminho reencaminhado, e nenhuma das duas fecha a rota direta do cliente. Repare em quem é dono de cada local, porque a resposta na maioria das organizações é outra equipa.

Condição três: o que deve fazer IPv6

Decida se IPv6 viaja pelo túnel, é bloqueado enquanto a proteção não está disponível, ou segue uma exceção documentada. Cada resposta produz um conjunto de regras diferente, e deixar a pergunta em aberto é como um cliente com IPv6 nativa acaba por alcançar fora do túnel destinos que alcança dentro dele via IPv4.

Diga a resposta em voz alta antes de escrever regras. Bloquear é uma opção legítima para um túnel que não transporta IPv6, desde que seja deliberado e testado e não o resultado acidental de uma tabela vazia. Tudo o que não estiver documentado será decidido de novo por quem tocar nas regras a seguir, e normalmente com pressa.

ICMPv6 é tráfego de controlo

A descoberta de vizinhos e o feedback de caminho viajam ambos sobre ICMPv6, pelo que um descarte generalizado copiado de um hábito IPv4 quebra o endereçamento e as transferências grandes ao mesmo tempo. Uma permissão generalizada também não é a resposta, porque entrega um canal que ninguém vigia.

Siga as orientações de filtragem para os tipos de mensagem que importam e rejeite os restantes com um motivo. A falha mais frequentemente mal diagnosticada é uma mensagem Packet Too Big em falta, que se manifesta como uma ligação que abre e depois encrava.

Prová-lo, uma família de cada vez

Teste um pedido autorizado em cada família separadamente e repita após uma reconexão se a política deve sobreviver à sessão. Um teste numa rede apenas IPv4 não pode exercitar uma rota IPv6, por isso a aprovação não diz nada sobre a fuga que está a tentar fechar. Observe os contadores enquanto o teste corre, porque uma regra que nunca corresponde não faz o que o seu comentário afirma.

Altere uma regra delimitada por tentativa e tenha a configuração anterior à mão. Onde um perfil gerido é dono da política, envolva o seu administrador antes de editar localmente, porque a verificação seguinte irá sobrescrever uma correção local e repor a fuga.