Votre règle VPN pour IPv4 ne dit rien du trafic IPv6

Un audit constate que le tunnel est filtré de façon stricte pour IPv4 et grand ouvert pour IPv6 sur la même interface. Rien n’était mal configuré au sens d’une faute de frappe ; le jeu de règles décrivait simplement une famille et tout le monde supposait que l’autre suivait. Elle le fait rarement. Trois conditions décident si votre règle couvre réellement les deux, et la première concerne la plateforme plutôt que la politique.

Première condition : la plateforme a-t-elle une table ou deux

Certains filtres de paquets gardent IPv4 et IPv6 dans des jeux de règles totalement séparés, si bien qu’une règle ajoutée à l’un n’a aucun effet sur l’autre tant que quelqu’un ne la duplique pas. D’autres proposent une famille qui correspond aux deux et traduit les adresses paquet par paquet. Un troisième groupe garde un seul langage de politique mais stocke derrière des objets séparés par famille.

Lisez la documentation du filtre que vous exploitez réellement, puis listez quelles tables existent et laquelle votre changement a touchée. Compter les règles de la table IPv4 répond à une question que personne n’a posée. Listez ensuite quelles tables existent et laquelle votre changement a touchée.

Deuxième condition : où la politique s’applique

Trois endroits se confondent : l’écouteur qui accepte le tunnel, le chemin qui transfère le trafic plus loin et l’interface ordinaire que le client utilise quand le tunnel ne porte aucun flux. Une passerelle peut accepter une session tout en rejetant tout ce qui en est transféré, et cela ressemble à un tunnel cassé plutôt qu’à un filtre. Supprimez cette confusion avant d’écrire quoi que ce soit, car les trois endroits ont des propriétaires et des journaux différents. Les nommer dans le journal des changements est ce qui empêche un correctif d’atterrir une couche plus loin que la panne.

Notez lequel des trois votre règle est censée régir. Une règle qui protège l’écouteur ne protège pas le chemin transféré, et aucune des deux ne ferme la route directe du client. Notez à qui appartient chaque endroit, car la réponse est une autre équipe dans la plupart des organisations.

Troisième condition : que doit faire IPv6

Décidez si IPv6 passe par le tunnel, s’il est bloqué tant que la protection n’est pas disponible, ou s’il suit une exception documentée. Chaque réponse produit un jeu de règles différent, et laisser la question ouverte est la façon dont un client doté d’IPv6 natif finit par joindre hors du tunnel des destinations qu’il joint à l’intérieur via IPv4.

Dites la réponse à voix haute avant d’écrire des règles. Bloquer est un choix légitime pour un tunnel qui ne transporte pas d’IPv6, à condition que ce soit délibéré et testé et non le résultat accidentel d’une table vide. Tout ce qui n’est pas documenté sera redécidé par celui qui touchera les règles ensuite, et généralement dans la hâte.

ICMPv6 est du trafic de contrôle

La découverte de voisins et le retour d’information sur le chemin passent tous deux par ICMPv6, si bien qu’un rejet massif copié d’une habitude IPv4 casse l’adressage et les transferts volumineux en même temps. Une autorisation massive n’est pas la réponse non plus, car elle livre un canal que personne ne surveille.

Suivez les consignes de filtrage pour les types de messages qui comptent et rejetez le reste avec un motif. La panne la plus souvent mal diagnostiquée est un message Packet Too Big manquant, qui se manifeste par une connexion qui s’ouvre puis se bloque.

Le prouver, une famille à la fois

Testez une requête autorisée sur chaque famille séparément, puis répétez après une reconnexion si la politique est censée survivre à la session. Un test sur un réseau IPv4 uniquement ne peut pas exercer une route IPv6, donc la réussite ne dit rien de la fuite que vous cherchez à fermer. Surveillez les compteurs pendant le test, car une règle qui ne correspond jamais ne fait pas ce que prétend son commentaire.

Changez une règle délimitée par tentative et gardez la configuration précédente à portée de main. Là où un profil géré possède la politique, impliquez son administrateur avant de modifier localement, car le prochain contrôle écrasera un correctif local et rétablira la fuite.