Serveur ou client : quelle unité OpenVPN sur un Pi à double rôle

Deux processus OpenVPN tournent sur un Pi qui accueille à la fois des utilisateurs nomades et atteint un fournisseur en amont, et ils ne partagent presque rien hormis le matériel. L’un écoute les tunnels entrants tandis que l’autre se connecte vers l’extérieur. Chacun lit son propre répertoire, et chacun a son propre mode de défaillance. Redémarrer le mauvais est la façon la plus courante pour qu’une correction du client finisse par faire basculer l’écouteur à la place.

Faites correspondre le nom de l’unité au répertoire qu’elle charge

Upstream 2.6 fournit deux unités modèles, [email protected] et [email protected]. Le modèle serveur démarre dans /etc/openvpn/server et charge %i.conf depuis cet endroit. Le modèle client démarre dans /etc/openvpn/client. Une instance nommée roaming peut exister aux deux endroits à la fois, en serveur et en client, avec deux configurations sans rapport et aucun lien entre elles au-delà de la chaîne.

Interrogez systemd plutôt que le système de fichiers, car les empaqueteurs ajoutent des fichiers supplémentaires qui peuvent changer le répertoire de travail ou les arguments que reçoit le binaire.

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

La première commande liste chaque unité instanciée, y compris celles qui ont échoué et sont restées chargées. La deuxième affiche le fichier de l’unité avec toute substitution. La troisième est le moyen le plus rapide de voir les deux faits qui tranchent la question : le répertoire dans lequel le processus démarre, et le chemin de configuration qui lui a été remis.

Décidez par la direction des paquets, pas par le nom de l’interface

Une instance serveur possède une socket d’écoute et accepte les connexions. Son transport chiffré est une entrée locale et une sortie locale sur le Pi, tandis que le trafic qu’elle transmet pour les utilisateurs suit le chemin de transmission et répond à un autre jeu de règles. Une instance client n’a pas d’écouteur en ce sens : elle compose un pair, donc son transport chiffré est une sortie locale vers la couche inférieure.

Cette différence vous dit à quoi appartient une règle. Une règle qui correspond à une interface dans une chaîne de transmission ne permet que le trafic que le routage a déjà choisi ; elle ne choisit jamais la route. Quand les paquets d’un utilisateur nomade sortent par le mauvais chemin, la chaîne à examiner est forward, pas output.

Regardez les sockets avant de théoriser. Un serveur lié à udp/1194 montre une socket d’écoute. Le client montre une association à l’adresse du fournisseur et rien qui écoute.

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

La route par défaut d’une instance peut capturer les réponses de l’autre

Un redirect-gateway poussé par le client amont installe une route par défaut qui concurrence tout le reste de la machine, y compris les réponses que le serveur envoie aux utilisateurs nomades. OpenVPN réserve une exception à sa propre adresse de pair pour que le tunnel reste joignable, mais cette exception ne dit rien d’un téléphone sur un réseau d’hôtel.

Le symptôme est généralement asymétrique. La poignée de main se termine, le client signale qu’il est connecté, et le trafic meurt après le premier paquet de réponse. Le routage par politique basé sur la source, ou une marque de paquet posée sur l’instance serveur avec --mark, garde les deux flux séparés ; ni l’un ni l’autre n’est un jeu de règles complet à lui seul, et les deux ont besoin de routes valides dans la table qu’ils choisissent.

Testez la décision locale plutôt que l’état du tunnel, car le noyau choisit la source et l’interface avant qu’OpenVPN ne voie le paquet.

ip route get 203.0.113.44
ip rule show

Redémarrez un rôle et prouvez que l’autre a survécu

L’ordre compte quand les deux rôles dépendent de la même couche inférieure. Redémarrez le client d’abord si la route amont doit exister avant que le trafic des utilisateurs puisse être transmis, et redémarrez le serveur d’abord quand vous ne changez que son écouteur ou son pool. Dans tous les cas, confirmez les deux unités ensuite, car un redémarrage raté peut laisser l’autre rôle tourner sur un état périmé.

Écrivez la condition d’arrêt avant le changement : la perte du tunnel amont bloque-t-elle les utilisateurs nomades, ou retombe-t-on sur l’uplink propre du Pi ? DNS et IPv6 ont aussi besoin d’une réponse explicite, car un résolveur poussé survit souvent à la route qui l’a rendu utile.

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

N’acceptez le changement que lorsque trois choses tiennent à la fois : une nouvelle connexion entrante aboutit, une application transmise atteint sa destination par la sortie prévue, et les deux processus signalent encore leur pair attendu. Si l’une des trois échoue, vous avez changé la mauvaise instance ou la mauvaise route, et l’étape suivante est de relire l’unité plutôt que de redémarrer autre chose.