A súa regra de VPN para IPv4 non di nada do tráfico IPv6

Unha auditoría atopa o túnel filtrado con rigor para IPv4 e completamente aberto para IPv6 na mesma interface. Nada estaba mal configurado no sentido dun erro tipográfico; o conxunto de regras simplemente describía unha familia e todos supuxeron que a outra seguía. Raramente o fai. Tres condicións deciden se a súa regra cobre realmente as dúas, e a primeira ten que ver coa plataforma e non coa política.

Condición primeira: a plataforma ten unha táboa ou dúas

Algúns filtros de paquetes manteñen IPv4 e IPv6 en conxuntos de regras totalmente separados, así que unha regra engadida a un non ten efecto no outro ata que alguén a duplica. Outros ofrecen unha familia que coincide con ambos e traduce os enderezos por paquete. Un terceiro grupo mantén unha soa linguaxe de políticas, pero garda detrás obxectos separados por familia.

Lea a documentación do filtro que executa realmente e despois enumere que táboas existen e cal tocou o seu cambio. Contar as regras da táboa IPv4 responde unha pregunta que ninguén fixo. Despois enumere que táboas existen e cal tocou o seu cambio.

Condición segunda: onde se aplica a política

Tres lugares confúndense entre si: o oínte que acepta o túnel, a ruta que reenvía o tráfico cara adiante e a interface normal que usa o cliente cando o túnel non transporta un fluxo. Unha pasarela pode aceptar unha sesión mentres descarta todo o reenviado desde ela, e iso parece un túnel roto máis que un filtro. Elimine esa confusión antes de escribir nada, porque os tres lugares teñen propietarios e rexistros distintos. Nomealos no rexistro de cambios é o que impide que unha corrección aterrice unha capa máis alá da avaría.

Anote cal dos tres debe gobernar a súa regra. Unha regra que protexe o oínte non protexe a ruta reenviada, e ningunha das dúas pecha a ruta directa do cliente. Fixe quen é o propietario de cada lugar, porque a resposta é outro equipo na maioría das organizacións.

Condición terceira: que debe facer IPv6

Decida se IPv6 viaxa polo túnel, se se bloquea mentres a protección non está dispoñible ou se segue unha excepción documentada. Cada resposta produce un conxunto de regras distinto, e deixar a pregunta aberta é como un cliente con IPv6 nativa acaba chegando a destinos fóra do túnel que alcanza dentro por IPv4.

Diga a resposta en voz alta antes de escribir regras. Bloquear é unha opción lexítima para un túnel que non transporta IPv6, sempre que sexa deliberado e probado e non o resultado accidental dunha táboa baleira. Todo o non documentado volverao decidir quen toque as regras despois, e normalmente con présa.

ICMPv6 é tráfico de control

O descubrimento de veciños e a retroalimentación de ruta viaxan ambos sobre ICMPv6, así que un descarte indiscriminado copiado dun costume de IPv4 rompe o enderezo e as transferencias grandes á vez. Un permiso indiscriminado tampouco é a resposta, porque entrega unha canle que ninguén vixía.

Siga as indicacións de filtrado para os tipos de mensaxe que importan e rexeite o resto cun motivo. O fallo que máis a miúdo se diagnostica mal é unha mensaxe Packet Too Big ausente, que se manifesta como unha conexión que se abre e despois se atasca.

Demostralo, unha familia á vez

Probe unha solicitude autorizada por cada familia por separado e repita despois de reconectar se se supón que a política sobrevive á sesión. Unha proba nunha rede só IPv4 non pode exercitar unha ruta IPv6, así que o éxito non di nada sobre a fuga que intenta pechar. Mire os contadores mentres a proba se executa, porque unha regra que nunca coincide non fai o que afirma o seu comentario.

Cambie unha regra delimitada por intento e teña á man a configuración anterior. Cando un perfil xestionado é dono da política, involucre o seu administrador antes de editar localmente, porque a seguinte comprobación sobrescribirá unha corrección local e restaurará a fuga.