Un seul Pi, deux instances OpenVPN : ce que lit chaque unité
Deux démons OpenVPN sur un Pi lisent des fichiers de configuration différents et sortent par des hooks différents. Cartographiez chaque instance, puis testez le chemin de la charge utile séparément.
Comptez les processus OpenVPN avant de toucher à un profil. Un Pi qui accueille des utilisateurs itinérants et compose aussi vers un service amont fait tourner deux démons, et chacun lit un fichier de configuration choisi par le nom d’instance que vous avez saisi. Les modèles fournis donnent ensuite à chaque démon son propre répertoire de travail, son propre fichier d’état d’exécution et son propre périphérique de tunnel. Si vous vous trompez dans cette séparation, vous passerez une soirée à modifier un réglage correct dans un fichier que le processus en cours n’ouvre jamais.
Chaque nom d’instance choisit son propre fichier
Dans les fichiers d’unité livrés avec OpenVPN 2.6, les arguments de démarrage portent un espace réservé d’instance qui est rempli par le texte situé après le signe @. Le modèle serveur s’exécute depuis le répertoire de configuration du serveur et résout son argument contre %i.conf là, tandis que le modèle client fait de même depuis le répertoire client. Ainsi, [email protected] lit admits.conf dans le répertoire serveur, et [email protected] lit uplink.conf dans le répertoire client, et aucun des deux noms n’a de sens dans l’autre répertoire.
Confirmez la correspondance sur la machine au lieu de supposer que le paquet a conservé les valeurs par défaut d’amont. Un drop-in de distribution est autorisé à remplacer purement et simplement le répertoire de travail ou l’argument de configuration.
systemctl cat [email protected]
systemctl cat [email protected]Lisez la ligne WorkingDirectory et l’argument de configuration dans cette sortie, car l’unité activée est la seule chose qui décide quel fichier se charge. Un drop-in qui ajoute --config à ExecStart l’emporte sur le modèle même lorsque le chemin du modèle semble correct. Demandez les chemins du fragment et du drop-in quand vous voulez savoir si une substitution locale est en jeu. Si les deux rôles aboutissent à un seul fichier, vous avez un seul processus qui tente d’être à la fois serveur et client, et la dernière option de ce fichier l’emporte silencieusement.
Le transport local et la charge utile transférée touchent des hooks différents
La connexion chiffrée du serveur vers chaque utilisateur itinérant est générée sur le Pi lui-même, donc ses réponses extérieures sortent par le hook de sortie local. La connexion du client vers son pair amont est aussi une sortie générée localement, même si elle atteint un réseau distant. La charge utile transférée est une troisième catégorie, et le noyau ne la fait correspondre qu’après avoir déjà choisi un périphérique de sortie pour le paquet.
| Flow | Hook that sees it | What to inspect |
|---|---|---|
| Roaming user handshakes to the server | Local input and local output | Listener socket, bind address, rule admitting the UDP port |
| User payload leaving through the upstream tunnel | Forward | IPv4 forwarding switch, selected route, permission rule, any translation |
| Pi's own connection to the upstream peer | Local output | Underlay route to the provider endpoint, not the tunnel route |
Une règle qui correspond à une interface de sortie à l’intérieur d’une chaîne de transfert peut autoriser ou rejeter un paquet que le routage a déjà affecté à cette interface, mais elle ne choisit jamais l’interface. Quand un hôte termine un tunnel et en origine un autre, la politique qui envoie la charge utile des utilisateurs dans le tunnel amont et la politique qui protège les réponses chiffrées du Pi sont des décisions distinctes. Elles atterrissent par hasard sur la même carte réseau physique, et c’est pourquoi on les confond.
Cette distinction explique un demi-échec courant. Les utilisateurs se connectent, la poignée de main se termine, et leur trafic sort toujours par le mauvais chemin, parce que la poignée de main était locale et la charge utile transférée, et que seule l’une des deux choses avait jamais été testée.
Une route importée peut avaler les réponses à vos utilisateurs
Le réglage de sécurité du profil client décide de ce que l’amont peut pousser dans la table de routage du Pi, et une redirection large est l’option qui transforme un hôte à double rôle fonctionnel en hôte cassé. Si la route poussée couvre les adresses publiques des utilisateurs itinérants, les réponses que le serveur génère vers eux peuvent suivre la nouvelle route dans le tunnel amont au lieu de sortir par la couche sous-jacente. Les gens vérifient souvent que le tunnel vers le fournisseur fonctionne encore et s’arrêtent là, parce que ce trafic est le transport propre du tunnel et qu’il continue de circuler pendant que tout le reste se comporte mal.
Une politique fondée sur la source ou sur une marque est la façon de maintenir les deux flux séparés. L’option de marque sous Linux d’OpenVPN marque les paquets chiffrés propres au démon avec une marque de pare-feu, qu’une règle de routage peut ensuite envoyer vers une table dédiée. Les adresses source fonctionnent tout aussi bien lorsque les réponses extérieures du serveur partent toujours d’une seule adresse de couche sous-jacente. L’une ou l’autre approche exige des routes valides dans la table qu’elle choisit et une exception pour le point de terminaison du fournisseur, sinon le tunnel lui-même cesse de monter.
Demandez au noyau quel chemin une réponse prendrait réellement avant d’écrire la moindre règle. Les adresses ci-dessous sont des espaces réservés pour une adresse de couche sous-jacente du Pi et l’adresse publique d’un utilisateur itinérant.
ip rule show
ip route get 198.51.100.7 from 192.0.2.10Vérifiez la séparation, puis arrêtez un rôle à la fois
Testez trois flux séparément, car une poignée de main qui fonctionne ne prouve rien sur les deux autres. Acceptez une nouvelle connexion entrante, envoyez une application autorisée par la sortie amont et confirmez que les deux processus atteignent toujours leurs propres pairs.
Arrêtez ensuite le rôle client et observez ce que le rôle serveur conserve. C’est le moyen le moins coûteux de trouver une règle de route ou de marque qui était destinée à une instance et a été appliquée aux deux.
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerCe que vous voulez voir, c’est l’écouteur toujours lié, le périphérique de tunnel toujours présent et le journal exempt de nouvelles erreurs pendant que le rôle client est arrêté. Si l’arrêt du client coupe aussi les réponses du serveur aux utilisateurs existants, les deux rôles partagent quelque chose qui aurait dû être limité à l’un d’eux. Notez quelle instance, quel fichier de configuration et quel propriétaire de flux chaque changement a touchés, car la prochaine personne qui débogue cet hôte répétera sinon la même découverte depuis zéro.