Le proxy reste-t-il sur l’ancienne adresse du tunnel après une reconnexion VPN ?

Redémarrer le client VPN prouve seulement que le tunnel est revenu. Cela ne dit rien du proxy à qui l’on avait demandé de sortir par lui. Squid, tinyproxy et la plupart des autres redirecteurs conservent l’adresse source locale qu’ils ont résolue au démarrage jusqu’à ce que quelque chose les force à se recharger. Quand une reconnexion attribue une nouvelle adresse de tunnel, le redirecteur échoue à chaque connexion sortante ou commence à sortir par votre route ordinaire.

Cette seconde défaillance est la dangereuse : le tunnel est opérationnel, les pages se chargent et seule l’adresse de sortie est fausse.

Commencez par l’écouteur, pas par le tunnel

Trois adresses sont en jeu, et une reconnexion n’en déplace que certaines. L’écouteur est l’endroit où pointe votre navigateur, généralement 127.0.0.1 ou une adresse de réseau local, et peu lui importe que le tunnel ait changé. La source locale sortante est ce que le redirecteur demande au noyau d’utiliser lorsqu’il compose le saut suivant, et elle est liée à l’appareil du tunnel. La sortie publique est ce qu’un serveur web journalise, et elle peut être une adresse traduite à plusieurs sauts de distance.

Une recherche d’IP publique ne répond qu’à la dernière question. Elle ne peut pas vous dire à quelle adresse locale un redirecteur doit se lier, car une seule sortie publique peut masquer plusieurs sources internes. Lisez l’adresse chez celui qui possède la connexion : la sortie d’état du client, l’interface elle-même ou l’espace de noms où vit le tunnel. Prendre la première interface dont le nom ressemble à un tunnel donne la mauvaise réponse dès qu’un second profil existe.

Les agencements en conteneurs et en espaces de noms brisent silencieusement cette hypothèse. Un redirecteur dans un espace de noms réseau ne peut pas se lier à un tunnel qui existe dans un autre, et aucune quantité d’édition de configuration n’y remédie.

Quatre vérifications avant de modifier quoi que ce soit

Parcourez-les dans l’ordre. La première vérification qui échoue est l’endroit où vous vous arrêtez, car les suivantes supposent que les précédentes tiennent.

1. Confirmez que le tunnel utilisé est le profil autour duquel le proxy a été construit, et non un second profil qui s’est connecté tout seul.
2. Affichez l’adresse actuellement présente sur cet appareil et comparez-la à l’adresse de la configuration en cours d’exécution.
3. Demandez au redirecteur quelle source il a résolue, plutôt que ce que prétend le fichier sur le disque.
4. Confirmez que le trafic du redirecteur est réellement soumis à la politique de routage et de pare-feu que vous attendez.

L’adresse de l’appareil est simple : ip -4 addr show dev tun0 affiche l’actuelle, et ip -4 route get 1.1.1.1 montre quelle interface le noyau choisirait pour cette destination. Un redirecteur qui lie une adresse exacte échoue bruyamment lorsque l’adresse disparaît. Un redirecteur qui lie un appareil, ou retombe sur la source par défaut, continue de fonctionner et fuit, et c’est là le résultat silencieux.

Faites correspondre la documentation à la version que vous exécutez, pas au premier résultat de recherche. La directive d’adresse sortante de Squid est documentée pour v7 et antérieur, et la documentation v8 indique clairement que la directive n’y est pas disponible, si bien qu’un script bâti autour d’elle ne survit pas à cette frontière (voir la référence Squid tcp_outgoing_address). Validez avec l’analyseur du produit lui-même avant tout rechargement : squid -k parse signale les erreurs et se termine sans toucher au processus en cours.

Numérotez chaque tunnel et écartez les permutations périmées

Une reconnexion est un transfert, et les transferts exigent un ordre. Étiquetez chaque connexion observée avec un compteur ou un horodatage qui augmente à chaque établissement réussi, puis transportez cette étiquette dans la configuration candidate. Quand l’étiquette d’un candidat est plus ancienne que l’actuelle, écartez le candidat au lieu de l’appliquer, car une mise à jour lente écrite pour le tunnel précédent écraserait sinon les réglages du tunnel actuel. Fusionnez les rafales d’événements afin qu’un lien qui oscille produise une transition au lieu de quinze.

Ordonnez le travail en quatre mouvements : invalidez l’ancien état de sortie, attendez que le propriétaire de la connexion signale l’achèvement, construisez uniquement le fragment géré, puis validez et activez via le gestionnaire de services. Régénérer tout le fichier à partir de deux valeurs d’adresse est la façon dont les restrictions d’écouteur, l’authentification et la politique de destination disparaissent en silence. Respectez aussi un arrêt délibéré. Un assistant qui continue de composer un tunnel que l’utilisateur a éteint est un défaut, pas une résilience.

Les sockets ouverts ne suivront pas la nouvelle adresse

Reconfigurer le redirecteur ne dit rien des connexions déjà établies. Qu’elles se vident ou meurent dépend du produit, donc observez le comportement au lieu de le supposer.

Une requête servie par un socket ouvert avant la permutation sort encore par l’ancien chemin, même lorsque la nouvelle configuration est correcte. Si cela compte, décidez explicitement : autorisez une courte fenêtre de vidage et cessez d’admettre du travail nouveau, ou fermez les anciens sockets et acceptez les erreurs. Testez ensuite avec une connexion neuve et gardez ce résultat séparé de la vérification de vidage. Lier la source n’est pas non plus une frontière de sécurité. Quand le trafic ne doit jamais toucher la route ordinaire, imposez-le par des marques et des règles de pare-feu, DNS et IPv6 compris, afin qu’un rechargement raté laisse le proxy explicitement arrêté plutôt qu’ouvert.

Prouvez la nouvelle sortie avec une requête neuve

Ce qui compte est une requête ouverte après l’activation, pas un ping et pas une page déjà en cache. Demandez au proxy une URL réelle et lisez l’adresse de sortie que rapporte l’extrémité distante, puis comparez-la à la vue que le client a du tunnel lorsque le fournisseur en expose une.

Gardez l’analyse, le rechargement et la requête comme des commandes distinctes afin qu’un échec pointe un seul pas. Les deux premières ne changent rien lorsqu’elles échouent, et c’est précisément pourquoi elles s’exécutent avant le redémarrage.

squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.com

Si le rechargement échoue, arrêtez le service et réparez le fragment ; un proxy qui sert avec une sortie périmée est pire qu’une courte interruption. Si le rechargement réussit mais que la requête neuve sort encore quelque part d’inattendu, revenez à la vérification du routage au lieu de modifier à nouveau les adresses. Notez la génération de tunnel par rapport à laquelle vous avez validé, afin que la prochaine reconnexion ait quelque chose de concret à comparer.