La configuration VPN publique ne fonctionne plus ? Lisez l’étape de défaillance

Le profil fonctionnait mardi, et vendredi le client tourne pendant trente secondes puis abandonne. Rien n’a changé sur votre machine. C’est exactement le point : une configuration téléchargée décrit un hôte à un instant donné, et l’opérateur en face n’a aucune obligation de maintenir cette description vraie. La tentation est de commencer à modifier les paramètres de sécurité jusqu’à ce que le tunnel remonte. C’est précisément cet instinct qui conduit à faire tourner un profil avec la vérification des certificats désactivée, ce qui est pire que de ne pas avoir de tunnel du tout.

Le fichier décrit un instant, pas un contrat

Un fichier de configuration est un ensemble d’assertions : ce nom d’hôte écoute sur ce port avec ce protocole, présente un certificat correspondant à ce nom et accepte ces identifiants. Dès que l’une d’elles cesse d’être vraie, le fichier est périmé et la correction relève du côté opérateur de la frontière, pas de vos réglages.

Les listes de nœuds publiques rendent cela explicite par leur nature même. Les nœuds sont gérés par des bénévoles, ils apparaissent et disparaissent, les adresses sont recyclées et les ports sont bloqués par le réseau derrière lequel ils se trouvent. La liste est un instantané qui est régénéré, et la copie sur votre disque est une photographie d’un instantané plus ancien.

Les services commerciaux changent plus lentement, mais pas jamais. Les autorités de certification tournent, un écouteur passe d’une adresse partagée à une adresse dédiée, un ancien protocole est retiré et une nouvelle liste de chiffrements arrive. Chacun de ces changements est invisible jusqu’à ce que votre client tente de se connecter et reçoive une réponse différente de celle qu’attend le fichier.

Lisez l’étape de défaillance avant de toucher à un réglage

Le message d’erreur indique quelle assertion a échoué, et chaque assertion a une réparation complètement différente. Modifier les chiffrements alors que le nom d’hôte ne résout plus fait perdre un après-midi et n’apprend rien à personne.

dig +short vpn.example.net
curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect}\n' --max-time 8 https://vpn.example.net:443/
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

La ligne du milieu sépare un chemin bloqué d’une poignée de main cassée, et la troisième montre l’émetteur et les dates de validité du certificat réellement présenté. Si cet émetteur n’est pas celui que le profil a épinglé, le certificat a changé, et aucune option côté client ne rendra l’ancienne épingle à nouveau correcte.

Les changements de certificat et d’identité sont les silencieux

La plupart des défaillances s’annoncent. Les changements d’identité non, car un client qui épingle un nom de certificat refusera un certificat neuf parfaitement valable avec un message que beaucoup lisent comme un bug. Le tunnel est intact. L’épingle est périmée.

Cherchez les options d’identité avant de conclure quoi que ce soit :

grep -nE '^(remote|proto|auth|verify-x509-name|tls-crypt|key-direction|ca) ' profile.ovpn
openssl x509 -in profile-ca.crt -noout -subject -dates

Si le profil porte une CA intégrée et que l’opérateur est passé à une nouvelle autorité, l’ancien fichier ne peut pas valider le nouveau serveur. Remplacer le bloc de CA par celui publié par l’opérateur est une correction légitime. Supprimer la directive de vérification ne l’est pas, et ce sont les mêmes frappes avec un résultat très différent.

Une mise à jour du client peut produire le même symptôme sans aucun changement de l’opérateur. Des options tolérées en silence sont désormais refusées, ou un protocole obsolète est retiré. C’est une limite de compatibilité de votre logiciel, et il vaut la peine d’essayer un second profil avec le même client avant d’accuser le serveur.

Seul l’opérateur peut publier un remplacement valide

Quand un nœud disparaît, le remplacement doit venir de la même source que l’original. Un profil qui arrive en message direct parce qu’il « utilise le même nom de serveur » est une configuration non vérifiée venant d’une partie inconnue, et l’importer donne à cette partie le contrôle de votre routage.

La vérification est bon marché. Récupérez le fichier actuel à l’emplacement publié, comparez le point de terminaison et le protocole avec la liste, et confirmez l’empreinte du matériel de CA plutôt que de faire confiance au nom du fichier :

curl -sS -o current.ovpn https://example.org/nodes/current.ovpn
sha256sum current.ovpn profile.ovpn
grep -nE '^(remote|proto) ' current.ovpn

Si les deux empreintes ne diffèrent que par des espaces, vous avez un changement de formatage. Si elles diffèrent sur les points de terminaison, l’opérateur a déplacé quelque chose et le fichier publié fait autorité. Si le fichier publié est plus ancien que celui que vous détenez, vous regardez probablement un cache, et la réponse périmée vous enverra dans la mauvaise direction.

Retirez l’ancienne entrée et consignez ce qui s’est passé

Une fois un remplacement fonctionnel vérifié, supprimez l’ancien profil au lieu de le garder comme solution de repli. Une entrée périmée qui se connecte à moitié est un piège : elle sera sélectionnée pendant une panne, elle échouera lentement, et la personne qui débogue passera les dix premières minutes sur le mauvais fichier.

Tenez un court registre en dehors de la configuration : la date, l’ancien point de terminaison, l’étape de défaillance et ce qui l’a remplacé. Les nœuds publics tournent, et six semaines plus tard la même question revient avec une autre personne. Une ligne dans un fichier de notes y répond en quelques secondes.

Si depuis un réseau tous les nœuds échouent de la même manière et depuis un autre aucun, arrêtez de modifier des profils et regardez le chemin local. Un portail captif, une plage de ports filtrée ou un proxy intercepteur produiront des erreurs identiques chez des fournisseurs sans rapport, et ce schéma est le seul signal que le problème n’a jamais été le fichier.