Exception UFW pour le VPN quand l’adresse du point de sortie change

Le client tente de se reconnecter et rien ne sort de la machine, alors que le même profil fonctionnait la semaine dernière. Le nom d’hôte du point de sortie se résout désormais vers une autre adresse, et l’exception sortante nomme encore l’ancienne. Cette seule autorisation périmée suffit à transformer un kill switch fonctionnel en panne totale, et elle reste invisible dans chaque indicateur d’état du bureau. La réparation est un petit flux de travail, pas une modification d’une ligne.

Le tunnel se reconnecte, puis plus rien ne sort

Une règle sortante qui nomme une adresse de destination est un instantané, et les réponses DNS ne le sont pas. Quand le fournisseur fait tourner une adresse, le paquet que le client envoie vers le nouveau pair ne correspond à rien et le refus par défaut le supprime. Le client signale alors un délai d’attente dépassé, ce qui ressemble à un problème de serveur plutôt qu’à un problème de pare-feu.

Figer l’adresse que renvoie une recherche publique fait fonctionner aujourd’hui et laisse demain cassé. C’est une modification ponctuelle, pas une politique de maintenance.

Décrivez l’exception que vous visez réellement

Commencez par noter les quatre valeurs dont la règle a besoin : le nom ou l’ensemble d’adresses du point de sortie approuvé, le transport, le port de destination et l’interface par laquelle le paquet sort. Toutes quatre font partie de l’autorisation, et n’importe laquelle peut être fausse alors que la règle paraît encore plausible. Une règle correcte sur trois d’entre elles échoue exactement comme une règle fausse sur les quatre. Notez-les avant de taper la commande, car une règle ne vaut que ce que vaut la description qui la sous-tend.

La commande ci-dessous montre la forme pour un point de sortie IPv4 UDP sur un lien filaire. Remplacez les deux valeurs par celles que vous avez vérifiées contre le déploiement.

sudo ufw allow out on enp3s0 proto udp to 192.0.2.44 port 1194
sudo ufw status verbose

Cette autorisation n’autorise pas de destinations arbitraires sur le même port, ne crée pas d’écoute et ne couvre pas TCP. La page de manuel d’UFW décrit comment l’adresse, l’interface et le protocole restreignent une règle, et cette restriction est tout l’enjeu.

Rafraîchissez-la comme un seul flux de travail

Traitez l’exception comme une ressource avec un propriétaire et une transition, pas comme une commande dont quelqu’un se souvient. Obtenez d’abord un candidat auprès du résolveur et de l’inventaire des points de sortie du déploiement, et définissez délibérément comment ce nom se résout avant que le tunnel existe. Validez ensuite le candidat contre le protocole, le port et la famille d’adresses prévus avant de toucher au jeu de règles.

Installez d’abord la nouvelle autorisation étroite et confirmez qu’elle est chargée, car demander au client d’utiliser une adresse que le pare-feu bloque encore produit un échec qui ressemble à une panne serveur. Laissez les règles sans rapport intactes pendant le changement.

Observez la transition du client par son chemin de reconnexion pris en charge et confirmez quelle adresse distante il a choisie. La mise à jour du DNS seule ne déplace pas une socket existante, et un réglage de persistance du point de sortie peut maintenir le client sur l’ancien pair longtemps après le changement d’enregistrement.

Enfin, retirez l’autorisation obsolète à dessein, en laissant la fenêtre de chevauchement approuvée tant qu’une ancienne session est encore active. Supprimer l’ancienne entrée trop tôt produit une brève panne ; la garder indéfiniment laisse une autorisation que personne ne peut expliquer.

Retirez l’ancienne autorisation à dessein

La suppression concentre l’essentiel du risque, car l’ancienne règle est la seule chose qui fonctionne actuellement. Si l’installation du candidat a échoué, n’allez pas plus loin et ne supprimez pas l’entrée qui porte encore du trafic. Si la suppression elle-même échoue, consignez l’autorisation périmée comme périmée au lieu de déclarer la politique à jour.

Répétez toute la revue lorsque le lien passe d’Ethernet à Wi-Fi, lorsque le transport change ou lorsqu’un service tourne sur plusieurs adresses. Une règle propre à une interface est censée cesser de correspondre après un changement de réseau, et ce comportement est correct même s’il ressemble à une régression.

Prouvez ensuite le contrat avec un trafic inoffensif. Le point de sortie approuvé doit être joignable pendant l’installation, l’application protégée doit fonctionner une fois connectée, et le trafic direct sans rapport doit rester bloqué pendant une panne. Incluez les deux familles d’adresses et une tentative de mise à jour volontairement ratée, car une connexion qui réussit après une seule modification d’adresse figée ne prouve aucun de ces cas.