Su regla de VPN para IPv4 no dice nada sobre el tráfico IPv6

Una auditoría descubre el túnel filtrado con rigor para IPv4 y completamente abierto para IPv6 en la misma interfaz. Nada estaba mal configurado en el sentido de una errata; el conjunto de reglas simplemente describía una familia y todos supusieron que la otra seguía. Rara vez lo hace. Tres condiciones deciden si su regla cubre realmente ambas, y la primera tiene que ver con la plataforma y no con la política.

Condición primera: la plataforma tiene una tabla o dos

Algunos filtros de paquetes mantienen IPv4 e IPv6 en conjuntos de reglas totalmente separados, así que una regla añadida a uno no surte efecto en el otro hasta que alguien la duplica. Otros ofrecen una familia que coincide con ambos y traduce las direcciones por paquete. Un tercer grupo mantiene un solo lenguaje de políticas, pero guarda detrás objetos separados por familia.

Lea la documentación del filtro que ejecuta realmente y después enumere qué tablas existen y cuál tocó su cambio. Contar las reglas de la tabla IPv4 responde una pregunta que nadie hizo. Después enumere qué tablas existen y cuál tocó su cambio.

Condición segunda: dónde se aplica la política

Tres lugares se confunden entre sí: el oyente que acepta el túnel, la ruta que reenvía el tráfico hacia adelante y la interfaz normal que usa el cliente cuando el túnel no transporta un flujo. Una pasarela puede aceptar una sesión mientras descarta todo lo reenviado desde ella, y eso parece un túnel roto más que un filtro. Elimine esa confusión antes de escribir nada, porque los tres lugares tienen propietarios y registros distintos. Nombrarlos en el registro de cambios es lo que impide que una corrección aterrice una capa más allá de la avería.

Anote cuál de los tres debe gobernar su regla. Una regla que protege al oyente no protege la ruta reenviada, y ninguna de las dos cierra la ruta directa del cliente. Fíjese en quién es el propietario de cada lugar, porque la respuesta es otro equipo en la mayoría de las organizaciones.

Condición tercera: qué debe hacer IPv6

Decida si IPv6 viaja por el túnel, se bloquea mientras la protección no está disponible o sigue una excepción documentada. Cada respuesta produce un conjunto de reglas distinto, y dejar la pregunta abierta es como un cliente con IPv6 nativa acaba llegando a destinos fuera del túnel que alcanza dentro por IPv4.

Diga la respuesta en voz alta antes de escribir reglas. Bloquear es una opción legítima para un túnel que no transporta IPv6, siempre que sea deliberado y probado y no el resultado accidental de una tabla vacía. Todo lo no documentado lo volverá a decidir quien toque las reglas después, y normalmente con prisa.

ICMPv6 es tráfico de control

El descubrimiento de vecinos y la retroalimentación de ruta viajan ambos sobre ICMPv6, así que un descarte indiscriminado copiado de una costumbre de IPv4 rompe el direccionamiento y las transferencias grandes a la vez. Un permiso indiscriminado tampoco es la respuesta, porque entrega un canal que nadie vigila.

Siga las indicaciones de filtrado para los tipos de mensaje que importan y rechace el resto con un motivo. El fallo que más a menudo se diagnostica mal es un mensaje Packet Too Big ausente, que se manifiesta como una conexión que se abre y luego se atasca.

Demostrarlo, una familia a la vez

Pruebe una solicitud autorizada por cada familia por separado y repita después de reconectar si se supone que la política sobrevive a la sesión. Una prueba en una red solo IPv4 no puede ejercitar una ruta IPv6, así que el éxito no dice nada sobre la fuga que intenta cerrar. Mire los contadores mientras la prueba se ejecuta, porque una regla que nunca coincide no hace lo que afirma su comentario.

Cambie una regla delimitada por intento y tenga a mano la configuración anterior. Cuando un perfil gestionado es dueño de la política, involucre a su administrador antes de editar localmente, porque la siguiente comprobación sobrescribirá una corrección local y restaurará la fuga.