Ouvrez la page d’état du client, voyez une adresse IPv6 globale, et la tentation est de conclure que le tunnel est devenu facultatif. Cette page montre une adresse, pas une frontière de chiffrement, pas une table de routage privée et pas une décision d’accès. Un VPN assume généralement trois tâches à la fois, et IPv6 ne touche que celle qui concerne le partage d’adresses rares. Parcourir un seul service du client jusqu’à l’écouteur est le seul moyen de voir quelle tâche survit au changement.

Nommez la tâche avant de retirer l’outil

Les gens disent « le VPN » lorsqu’ils veulent dire l’une de trois dispositions, et les trois échouent pour des raisons différentes. Atteindre une application publiée par une équipe est un problème d’accès applicatif. Rejoindre un ensemble défini de réseaux privés pour que plusieurs sites puissent s’atteindre est une relation de routage. Maintenir une couche d’administration stable au-dessus d’une infrastructure que vous ne contrôlez pas entièrement est une disposition d’exploitation avec son propre plan d’adressage.

IPv6 supprime un obstacle de partage d’adresses pour la première disposition, et là il fait un vrai travail, car une adresse directe peut remplacer un traducteur. Pour les deux autres, il ne change rien, puisque l’exigence n’a jamais été la pénurie d’adresses. Notez laquelle des trois vous exploitez réellement avant de toucher à une configuration.

Une adresse publique n’est pas du chiffrement

Une adresse de portée globale vous dit où un hôte est joignable ; elle ne dit rien sur le fait que le trafic qui y arrive soit chiffré ou authentifié. La discussion de sécurité de la RFC 8504 sépare la prise en charge de l’implémentation IPsec du choix plus large entre IPsec, TLS, SSH et d’autres approches, et c’est précisément la distinction qui disparaît quand on lit l’accessibilité comme une protection. Une pile qui prend en charge un mécanisme a seulement prouvé que le mécanisme est disponible, jamais que ce flux l’a traversé. Pour IPsec en particulier, l’association négociée et le trafic qu’elle sélectionne décident de ce qui est protégé, et une famille d’adresses est une propriété du paquet, non une politique pour lui.

L’accessibilité est encore une question distincte. Une adresse publique ne fait pas arriver de trafic non sollicité, car la route, le pare-feu et l’écouteur ont chacun une voix, et retirer NAT retire un filtre plutôt que tous. Décidez lequel des trois le tunnel remplaçait, s’il en remplaçait un.

Ce que la superposition fournit encore

Une superposition continue de mériter sa place dans trois situations. Des utilisateurs distants peuvent avoir besoin d’un ensemble précis de routes plutôt que d’une application, deux sites peuvent avoir besoin d’un accord d’accessibilité privé, et des opérateurs peuvent vouloir un adressage qui ne change pas quand le fournisseur d’accès change. Aucune des trois ne concerne la pénurie d’adresses IPv4.

Les adresses globales ne rendent pas cela sans entretien. Un plan interne bien rangé ne maintient pas le point de terminaison externe en réponse après que le fournisseur l’a changé, et l’authentification, la reconnexion et les mises à jour de noms ont toujours besoin d’un responsable. Décidez comment celles-ci se rétablissent avant que quoi que ce soit soit coupé.

Parcourez le service qui devient public

Partez de l’hôte et listez ce qui écoute réellement, car l’application que vous avez approuvée est rarement la seule chose sur la machine. ss -lntup affiche chaque écouteur TCP et UDP avec son adresse de liaison et ajoute le processus propriétaire là où vos privilèges le permettent, ce qui montre d’un coup d’œil si une interface d’administration se trouve sur une adresse générique ou seulement sur la boucle locale. Répétez-le sous la forme ss -6 -lntup si votre pile garde les sockets IPv6 séparés.

Classez ensuite chaque ligne selon le public. Un port applicatif portant sa propre authentification et sa sécurité de transport peut convenir sur une adresse publique, tandis qu’une interface d’administration, un point de terminaison de métriques et un port de base de données ne le sont généralement pas. Une application approuvée est un jugement sur cette application seule, jamais la permission d’exposer chaque service partageant l’hôte. L’adresse de liaison de chaque ligne vous dit si l’exposition existe déjà ou serait créée par le changement que vous planifiez.

Deux tests, puis décidez quoi couper

Avant de retirer une couche, répondez à deux questions sur papier. Premièrement, l’exigence a-t-elle besoin d’un routage privé, c’est-à-dire d’une accessibilité qu’une adresse publique n’implique pas et que le fournisseur d’accès n’offre pas ? Deuxièmement, a-t-elle besoin d’une frontière de protection, c’est-à-dire du chiffrement et de l’authentification sur un flux qui traverserait autrement un chemin non fiable en clair ? Si les deux réponses sont non pour ce service, le tunnel est candidat au retrait ; si l’une est oui, il reste.

Exécutez le même test sur IPv4 et IPv6 séparément sur un client double pile, car le trafic IPv4 protégé ne décrit rien du chemin IPv6. Une adresse IPv6 globale dans une page d’état n’est pas la preuve d’une fuite, et son absence n’est pas la preuve d’une protection. Ne coupez que les services pour lesquels les deux réponses ont été écrites et sont toujours non, et notez dans le journal des changements quelle question l’a décidé.

Articles similaires