Pourquoi le sous-réseau derrière un client OpenVPN est-il inaccessible ?

Les pings vers l'adresse du tunnel du serveur aboutissent, la table de routage du client semble correcte, et le LAN derrière ce client reste inaccessible. La table de routage du client semble correcte, le serveur a une route vers le tunnel, et les paquets disparaissent toujours. C'est le symptôme classique d'un tunnel layer-3 qui ignore que l'un de ses clients est aussi une passerelle.

Une interface tun n'a pas de prochain saut par client. Le noyau voit une seule interface avec de nombreux pairs, donc la décision de savoir quel client doit recevoir un paquet pour un LAN distant doit être prise à l'intérieur du processus OpenVPN. Cette décision se configure avec iroute, et sans elle le paquet n'a nulle part où aller.

Le serveur route par client, pas par interface

Quand le serveur doit envoyer un paquet à l'adresse du tunnel d'un client, la réponse est sans ambiguïté : l'adresse appartient à la session de ce client. Quand la destination est tout un sous-réseau derrière ce client, l'adresse n'appartient à personne que le serveur connaisse, et la route du noyau vers le tunnel dit seulement "par cette interface", sans préciser quel pair.

OpenVPN résout cela avec une table de routage interne qui associe un préfixe de destination à un client précis. Cette table est construite à partir des entrées iroute, c'est pourquoi une route ordinaire sur l'hôte serveur ne suffit pas. La route du noyau amène le paquet à l'interface du tunnel ; l'association interne décide quelle session le reçoit. C'est aussi pourquoi la réparation n'apparaît jamais dans la sortie des routes du noyau.

Si l'association manque, le paquet arrive au serveur, correspond à la route du tunnel et est abandonné parce qu'aucun client ne revendique la destination. Rien ne consigne d'erreur claire, c'est pourquoi la panne ressemble à un trou noir silencieux plutôt qu'à une boucle de routage.

Écrire l'entrée iroute qui nomme le client

iroute vit dans un fichier de configuration propre au client, pas dans la configuration principale du serveur. Pointez le serveur vers un répertoire avec l'option client-config-dir, puis créez un fichier dont le nom est le nom commun du certificat du client et placez-y le préfixe.

Pour une succursale dont le LAN est 10.20.0.0/24 et dont le nom commun du certificat est branch-router, le fichier à ce chemin contient une ligne comme iroute 10.20.0.0 255.255.255.0. La configuration principale n'a besoin que de l'option de répertoire ; le préfixe vit chez le client.

Le nom commun est la partie fragile. Un certificat émis avec un autre sujet, ou un déploiement qui authentifie les utilisateurs par nom d'utilisateur alors que le fichier est nommé d'après le certificat, produit un fichier qui n'est jamais lu. Vérifiez le nom que le serveur rapporte réellement pour la session, et envisagez l'option qui fait échouer un client non concordant au lieu de le connecter silencieusement sans ses routes. Renommer le fichier pour qu'il corresponde au certificat est une correction de cinq minutes qui évite une très longue soirée.

Un client peut posséder plusieurs préfixes. Ajoutez une ligne iroute par réseau et gardez la liste à côté du reste des réglages de ce client pour que l'association reste auditable.

Construire le chemin de retour dans les deux sens

Amener les paquets au LAN distant est la moitié du travail. Le client doit aussi envoyer le trafic de ce LAN dans le tunnel, ce qui se fait normalement en poussant une route au client : une ligne comme push "route 10.8.0.0 255.255.255.0" indique à chaque client comment atteindre le réseau côté serveur. Pour la succursale, la route équivalente pointe vers le tunnel pour tout ce qu'elle doit atteindre côté serveur.

Le sens de retour a besoin d'un propriétaire côté distant. De ce côté, quelqu'un doit connaître le chemin du retour : une route statique sur le routeur du LAN qui pointe le pool VPN vers le serveur, ou la traduction d'adresses sur le serveur avant que le trafic n'entre dans le LAN. La route statique garde les adresses d'origine visibles dans les journaux et les règles d'accès, mais exige la coopération du propriétaire du LAN ; la traduction est autonome mais cache qui s'est réellement connecté.

Le transfert doit être activé sur l'hôte serveur. Sans cela, le noyau accepte le paquet depuis le tunnel et refuse de le transmettre à l'interface LAN, ce qui, du point de vue du client, ressemble exactement à une iroute manquante.

Vérifier l'accessibilité avec les bonnes sondes

Testez par couches au lieu de pinger l'extrémité distante et de deviner. Depuis le serveur, vérifiez que l'association interne du préfixe existe et que la route du noyau pointe vers le tunnel. Depuis le client, confirmez que la route poussée est installée et que son chemin par défaut vers l'adresse du LAN est le tunnel.

Observez ensuite les paquets. Une capture sur l'interface du tunnel montre si le serveur émet vers le client, et une capture sur l'interface du LAN montre s'il transfère. Si la première montre des paquets et la seconde rien, le problème est le transfert ou un filtre ; si aucune ne montre rien, la recherche a échoué plus tôt.

Deux serveurs reliés par un tunnel répètent la même règle des deux côtés : chacun a besoin d'une iroute pour le pool de l'autre, et chacun a besoin de la route et du transfert qui rendent le chemin symétrique. Routage et politique sont des questions distinctes ici. Le routage décide où un paquet peut aller, tandis qu'une règle FORWARD décide s'il le peut, donc un client avec deux lignes iroute atteint les deux préfixes sauf si un filtre dit le contraire.