La vostra regla de VPN per a IPv4 no diu res del trànsit IPv6

Una auditoria troba el túnel filtrat amb força per a IPv4 i completament obert per a IPv6 a la mateixa interfície. No hi havia res mal configurat en el sentit d’una errata; el conjunt de regles simplement descrivia una família i tothom va suposar que l’altra la seguia. Poques vegades ho fa. Tres condicions decideixen si la vostra regla cobreix realment les dues, i la primera tracta de la plataforma, no de la política.

Condició primera: la plataforma té una taula o dues

Alguns filtres de paquets mantenen IPv4 i IPv6 en conjunts de regles completament separats, de manera que una regla afegida a un no té cap efecte sobre l’altre fins que algú la duplica. D’altres ofereixen una família que encaixa amb totes dues i tradueixen les adreces per paquet. Un tercer grup manté un sol llenguatge de política, però hi guarda objectes separats per família.

Llegiu la documentació del filtre que realment executeu, i després llisteu quines taules existeixen i quina ha tocat el vostre canvi. Comptar les regles de la taula IPv4 respon una pregunta que ningú no ha fet. Després llisteu quines taules existeixen i quina ha tocat el vostre canvi.

Condició segona: on s’aplica la política

Hi ha tres llocs que es confonen entre si: l’oient que accepta el túnel, el camí que reenvia el trànsit cap endavant i la interfície normal que el client fa servir quan el túnel no transporta cap flux. Una passarel·la pot acceptar una sessió mentre descarta tot el que se’n reenvia, i això sembla un túnel trencat més que no pas un filtre. Traieu aquesta confusió abans d’escriure res, perquè els tres llocs tenen propietaris i registres diferents. Anomenar-los al registre de canvis és el que evita que una correcció acabi una capa enllà de la fallada.

Anoteu quina de les tres ha de governar la vostra regla. Una regla que protegeix l’oient no protegeix el camí reenviat, i cap de les dues tanca la ruta directa del client. Fixeu-vos qui és el propietari de cada lloc, perquè la resposta és un equip diferent a la majoria d’organitzacions.

Condició tercera: què ha de fer IPv6

Decidiu si IPv6 viatja pel túnel, si es bloqueja mentre la protecció no està disponible o si segueix una excepció documentada. Cada resposta produeix un conjunt de regles diferent, i deixar la pregunta oberta és com un client amb IPv6 nadiu acaba arribant a destinacions fora del túnel que assoleix dins seu per IPv4.

Digueu la resposta en veu alta abans d’escriure regles. Bloquejar és una opció legítima per a un túnel que no transporta IPv6, sempre que sigui deliberat i provat i no el resultat accidental d’una taula buida. Qualsevol cosa no documentada la tornarà a decidir qui toqui les regles després, i normalment amb presses.

ICMPv6 és trànsit de control

El descobriment de veïns i la retroalimentació de camí van tots dos sobre ICMPv6, així que un descart indiscriminat copiat d’un costum d’IPv4 trenca l’adreçament i les transferències grans alhora. Un permís indiscriminat tampoc no és la resposta, perquè lliura un canal que ningú no vigila.

Seguiu les indicacions de filtratge per als tipus de missatge que importen i rebutgeu la resta amb un motiu. La fallada que es diagnostica malament més sovint és un missatge Packet Too Big absent, que es manifesta com una connexió que s’obre i després s’encalla.

Demostrar-ho, una família alhora

Proveu una sol·licitud autoritzada per cada família per separat, i repetiu-ho després de reconnectar si es pretén que la política sobrevisqui a la sessió. Una prova en una xarxa només IPv4 no pot exercitar una ruta IPv6, així que l’èxit no diu res sobre la fuita que intenteu tancar. Mireu els comptadors mentre la prova s’executa, perquè una regla que no coincideix mai no fa el que afirma el seu comentari.

Canvieu una regla delimitada per intent i tingueu a mà la configuració anterior. Quan un perfil gestionat és propietari de la política, involucreu-ne l’administrador abans d’editar localment, perquè la propera comprovació sobreescriurà una correcció local i restaurarà la fuita.