Étapes de la poignée de main VPN : ce qui se passe avant que le trafic circule

Appuyer sur Connecter lance quatre tâches distinctes qui réussissent ou échouent indépendamment. Le client doit atteindre un écouteur, convenir de l’identité du pair, dériver des clés, puis remettre un tunnel fonctionnel au reste du système. La plupart des connexions échouées sont diagnostiquées dans la mauvaise tâche. C’est pourquoi la première erreur compte plus que la troisième tentative.

Atteignez d’abord l’écouteur

Avant tout échange d’identité, le client résout un nom, choisit une route et ouvre un transport vers un port. Un portail captif qui répond à tout, un port fermé et un nom d’hôte erroné échouent tous ici, et aucun des trois n’est un problème d’authentification. Changer un mot de passe ne peut corriger aucun des trois. Lisez la première ligne de l’erreur avant de toucher aux identifiants.

Un délai dépassé, un rejet de certificat et un compte refusé sont trois pannes différentes avec trois vérifications différentes. Les classer d’abord est ce qui empêche un problème réseau d’être débogué comme un problème d’identifiants.

Prouvez le pair, puis dérivez les clés

Chaque protocole a besoin d’un moyen de reconnaître le serveur prévu, que ce soit par une clé publique configurée ou une chaîne de certificats. La connexion utilisateur s’ajoute à cette vérification, elle ne la remplace pas. Un serveur qui accepte votre mot de passe n’a rien prouvé sur sa propre identité. C’est pourquoi un secret partagé saisi dans un client ne remplace pas la vérification de qui a répondu.

L’échange dérive ensuite les clés de trafic à partir des entrées propres au protocole, et le mot de passe de connexion n’est généralement pas la clé apposée sur chaque paquet. Le matériel d’identité à long terme et les clés de session à courte durée ont des durées de vie et des rôles différents. C’est de cette séparation que parle la confidentialité persistante.

Gardez la vérification activée pendant le dépannage, car un tunnel qui se connecte après que vous avez désactivé une vérification n’a rien prouvé sinon que la vérification faisait quelque chose. Notez ce que vous avez changé et remettez-le avant le test suivant.

Trois protocoles, trois conversations

Dans un déploiement OpenVPN basé sur TLS, le canal de contrôle négocie les paramètres de sécurité tandis que le canal de données transporte le trafic du tunnel, si bien qu’une option de canal de données et un problème de certificat vivent à des endroits différents. IKEv2 authentifie les deux participants puis établit des associations de sécurité IPsec avec leurs propres durées de vie. WireGuard dérive les clés par son échange fondé sur Noise et garde la machine d’état délibérément petite. Savoir lequel des trois vous exécutez décide quel journal vaut la peine d’être lu.

Des clients d’apparence similaires n’impliquent pas des messages interchangeables en dessous, et un champ de configuration qui existe dans un produit peut n’avoir aucun équivalent dans un autre. Copier un profil entre eux est une supposition et non une migration.

Ce que la poignée de main ne fait pas

Les routes, la résolution de noms et la politique de destination subsistent toutes ensuite. Un site interne peut rester inaccessible parce que la route de son sous-réseau manque, même si le pair a été authentifié correctement et que le tunnel est actif. Traiter cela comme un chiffrement faible vous envoie chercher dans la mauvaise couche, et cela se termine généralement par un changement de chiffrement qui ne corrige rien.

Le renouvellement des clés et la reconnexion se ressemblent aussi dans la plupart des affichages d’état, et ni l’un ni l’autre ne vous dit si le trafic ordinaire a été bloqué pendant la panne. Seule la politique d’échec du client répond à cette question, alors lisez la politique plutôt que l’icône.

Traitez les étapes dans l’ordre ci-dessus et arrêtez-vous à la première qui produit une erreur. Chaque étape ultérieure hérite de l’état des précédentes, donc un échec à la troisième étape ne dit rien sur la quatrième.

ip -brief address show tun0
ip route get 10.60.7.15
resolvectl query intranet.corp.internal