OpenVPN tombe après un renouvellement DHCP : gardez la route du point de sortie

Le tunnel se connecte, puis un renouvellement de bail sur la liaison d’accès le tue, et le journal accuse un délai d’attente plutôt qu’une route. Rien n’a changé dans la configuration du VPN, et c’est justement l’indice : quelque chose à l’extérieur a changé. Un événement DHCP a réécrit l’adresse ou la passerelle, et la route d’hôte qui gardait le point de sortie du tunnel joignable pointe désormais vers un saut suivant qui n’existe plus. C’est un problème de propriété avant d’être un problème de routage.

Comparez le symptôme aux demi-routes par défaut

Avec redirect-gateway def1, OpenVPN installe 0.0.0.0/1 et 128.0.0.0/1 au lieu de remplacer la route par défaut. Ensemble, ces deux routes couvrent tout l’espace d’adressage, et elles battent 0.0.0.0/0 rien que par la longueur du préfixe. Toute destination sans correspondance plus spécifique entre donc dans le tunnel.

Le point de sortie a besoin d’une exception. OpenVPN ajoute une route d’hôte vers l’adresse du serveur via la passerelle d’accès d’origine avant que les demi-routes n’entrent, afin que les paquets encapsulés puissent sortir. Quand cette exception disparaît, ou conserve un saut suivant qui n’existe plus, les propres paquets extérieurs du tunnel correspondent à une demi-route et sont renvoyés dans le tunnel. Le résultat est une connexion qui meurt au keepalive ou à la poignée de main suivante, sans rien dans le journal qui ressemble à une erreur de routage.

Confirmez la forme de la table avant de toucher à quoi que ce soit d’autre. ip route show devrait lister les deux moitiés plus une route d’hôte pour l’adresse du serveur ; quand la route d’hôte manque, le reste de l’enquête a un point de départ évident.

Pourquoi les demi-routes gagnent sans changer de métrique

Une métrique plus basse ne bat pas un préfixe plus long. Les routes /1 gagnent parce que le noyau fait d’abord correspondre la route la plus spécifique, donc relever une métrique sur la route par défaut ne change rien à l’endroit où va le trafic destiné au tunnel. Courir après les métriques est le faux pas le plus courant dans ce diagnostic.

Vérifiez la sélection avec ip route get 203.0.113.10, en y mettant la véritable adresse du serveur. La réponse nomme l’interface et le saut suivant que le noyau utiliserait réellement, ce qui est plus instructif que de lire une table et de raisonner dessus.

Exécutez cette commande avant le démarrage du tunnel, pendant qu’il tourne et après l’événement de bail. Trois réponses pour une seule commande, et le point de divergence devient visible.

Prenez trois instantanés, pas un

Recueillez l’adresse d’accès, la passerelle d’accès, la destination du point de sortie, la route choisie et toute règle de politique à trois moments : après la configuration de la liaison d’accès, après la connexion du VPN et après l’événement de bail ou d’opérateur. Chaque instantané est une poignée de commandes, et ils n’ont de sens qu’ensemble. Un seul instantané après la panne enregistre l’état plutôt que la transition. Écrivez les commandes dans un petit script pour que chaque instantané soit pris de la même manière.

Gardez les instantanés dans un seul fichier avec des horodatages, car la question intéressante plus tard est l’ordre. L’événement DHCP est-il arrivé avant ou après que OpenVPN a rafraîchi sa route ? La réponse décide qui doit le corriger. Un horodatage venu d’une horloge fausse est pire que pas d’horodatage, alors prenez-le sur l’hôte qui possède la table de routage.

Quand le point de sortie est configuré comme un nom plutôt qu’une adresse, résolvez-le aussi dans chaque instantané. Un changement DNS sur la liaison d’accès peut déplacer le point de sortie sans qu’aucune route soit touchée.

Décidez quel composant rafraîchit l’exception

Sur un système dhcpcd, les hooks s’exécutent depuis le répertoire des hooks et depuis le hook de sortie, et le mode gestionnaire diffère en portée du mode par interface. Quoi que fasse le hook, il doit être idempotent, car les renouvellements peuvent arriver par rafales.

Le propriétaire fiable est l’intégration qui connaît déjà les deux côtés : un gestionnaire de réseau qui gère la connexion VPN, ou une unité ordonnée après la montée de la liaison d’accès. Une route statique ajoutée par un hook fonctionne jusqu’au prochain changement de passerelle, puis échoue exactement de la même façon. Si vous utilisez malgré tout un hook, faites-lui lire la passerelle actuelle à l’exécution au lieu de coder en dur celle que vous avez vue aujourd’hui.

Consignez le propriétaire dans la configuration. La prochaine personne qui débogue une reconnexion doit savoir que c’est un hook, et non le VPN, qui est responsable de la route d’exception.

Testez le cycle de vie, pas seulement la reconnexion

Forcez un renouvellement avec dhcpcd -n eth0 ou en libérant et renouvelant le bail, puis vérifiez de nouveau ip route get pour le point de sortie. Faites-le deux fois, car la seconde passe attrape les hooks qui ajoutent des routes en double. Redémarrez ensuite, car la persistance est une propriété différente de l’exactitude.

Un tunnel qui survit à un renouvellement et à un redémarrage a un propriétaire et une exception fonctionnelle. Celui qui ne survit qu’à un redémarrage manuel n’a ni l’un ni l’autre, et échouera au prochain événement que vous ne pouvez pas planifier.