OpenVPN pousse encore d'anciennes routes ? Vérifiez ce qu'il a chargé

Vous ajoutez une route, redémarrez le service, vous reconnectez, et la table du client est exactement comme avant. Deux choses différentes peuvent être vraies : le serveur n'a jamais chargé votre modification, ou le client n'a jamais installé ce qu'il a reçu. Elles n'ont en commun que le symptôme, donc la première étape est de savoir laquelle des deux vous avez.

La comparaison ci-dessous part du processus vers l'extérieur, car le processus est la seule autorité sur le fichier qui est en vigueur.

Le fichier que vous avez modifié et le fichier que lit le processus

Commencez par l'unit et la ligne de commande qu'elle a produite. Sur un hôte systemd, systemctl cat openvpn@server imprime la ligne ExecStart, et une unit d'instance déduit généralement son chemin de configuration du nom de l'instance, si bien qu'un démon lancé en tant que openvpn@office lit un autre fichier que celui lancé en tant que openvpn@server. Comparez cela avec l'argv du processus en cours. Un outil de gestion de configuration ajoute une autre façon de perdre la modification : il peut écrire un fichier correct à un endroit que l'unit ne mentionne jamais, et un déploiement vert ressemble alors à rien du tout.

Les horodatages tranchent vite : si le fichier est plus récent que l'heure de démarrage du processus, le processus n'a pas pu le lire. Le firmware du routeur ajoute un troisième cas, car beaucoup de modèles gardent leurs réglages en flash et reconstruisent la configuration au démarrage, ce qui fait d'une édition de fichier sur le disque la mauvaise couche.

Ce que le serveur pousse et ce que le client installe

Une route poussée doit franchir deux filtres. Sur le serveur, elle doit figurer dans la configuration chargée, pas dans un bloc commenté ni dans un fichier propre à un client dont le nom ne correspond pas. Sur le client, pull doit être activé et aucun pull-filter ne doit écarter l'option. Connectez-vous avec verbosity 4 et lisez les options poussées que le client rapporte : si la route figure dans cette liste, le serveur a fait son travail et c'est le client qui choisit de ne pas l'installer.

Les fichiers propres à un client sont une source fréquente de confusion. Un fichier nommé d'après le common name du certificat ne pousse des options qu'à ce client, et un écart d'un caractère arrête la poussée en silence, sans erreur d'un côté comme de l'autre. Le serveur journalise le common name qu'il a vu à la connexion, donc comparez cette valeur au nom du fichier, pas à ce que vous croyez être le nom du client.

Le préfixe poussé et la route de retour sont deux problèmes différents

Un client qui ignore délibérément redirect-gateway pour garder son chemin internet local crée une seconde lacune, sans rapport. Les sondes du serveur atteignent l'adresse du tunnel et les réponses n'arrivent jamais, car une réponse adressée à l'IP du tunnel du serveur est routée par la passerelle par défaut ordinaire du client. La route de sous-réseau poussée n'est pas en cause ici ; ce qui manque est une route qui renvoie le trafic du réseau tunnel du serveur vers le périphérique tunnel.

Ajouter cette route sur le client corrige les réponses aux sondes lancées par le serveur. Elle ne remplace pas la route de sous-réseau poussée, et l'inverse est vrai aussi, car les deux décrivent des sens de circulation opposés.

Comparez les tables aux deux extrémités

Après toute modification, reconnectez-vous et lisez la table du client pour le préfixe poussé et pour le périphérique tunnel. Testez ensuite dans les deux sens : du client vers un hôte du sous-réseau poussé, puis de cet hôte vers le client. Une route qui existe mais ne transporte aucun trafic signifie l'une de trois choses : le côté distant ne transmet pas, un pare-feu jette le flux, ou la réponse n'a pas de chemin de retour.

Gardez trois identifiants ensemble : le chemin de configuration, le nom de l'unit ou de l'instance et l'identité du client avec laquelle vous avez testé.

Ces trois éléments transforment la prochaine occurrence en vérification de cinq minutes plutôt qu'en nouvelle enquête, et c'est ce dont un collègue a besoin quand le tunnel devient le problème de quelqu'un d'autre.

Un problème de routes qui survit à un redémarrage n'est souvent pas un problème de routage du tout ; la panne se situe en amont de la table que vous ne cessez de lire.