Le client OpenVPN atteint le serveur mais pas les hôtes du LAN : liste de vérification

Le client dit connecté, l’adresse du tunnel répond au ping et rien sur le LAN du bureau ne répond. Je vois cela après presque chaque mise à jour du client, et le premier réflexe est d’ouvrir le pare-feu, ce qui est généralement le mauvais geste : le tunnel est bon et la coupure se situe sur l’un des trois sauts que le paquet doit franchir. Parcourez le chemin dans l’ordre que suit le paquet, d’abord la route du client, puis le transfert sur le serveur, puis le trajet retour, et vous trouverez le responsable de la panne en quelques minutes.

Première étape : observez la décision de routage du client

Avant de toucher au serveur, prouvez que le client envoie le paquet dans le tunnel. Demandez au noyau quelle interface il utiliserait pour un hôte du LAN précis, au lieu de lire toute la table :

ip route get 192.168.50.10

Si la réponse nomme votre adaptateur physique et la passerelle du bureau, aucun changement côté serveur ne peut aider. OpenVPN ne distribue des routes que lorsque le serveur les pousse, cherchez donc push "route 192.168.50.0 255.255.255.0" dans la configuration du serveur, puis reconnectez le client ensuite. La plupart des clients appliquent les routes poussées à la connexion, pas lorsque vous rechargez le profil.

Sous Windows, la même question a une autre commande. Find-NetRoute -RemoteIPAddress 192.168.50.10 imprime l’interface et le prochain saut que la pile choisirait, et route print -4 montre si le préfixe poussé existe tout court.

Deuxième étape : confirmez que le serveur transférera le paquet

Si la route du client est correcte, le paquet atteint le serveur et le serveur doit accepter de le transférer. L’interrupteur du noyau est la première porte, et sysctl net.ipv4.ip_forward doit renvoyer 1. Le régler avec echo 1 > /proc/sys/net/ipv4/ip_forward fonctionne jusqu’au prochain redémarrage, et c’est exactement pourquoi la même plainte revient des semaines plus tard.

Notez-le quelque part qui survit à un redémarrage :

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

La deuxième porte est la table de filtrage. Un hôte équipé de Docker porte souvent une politique FORWARD à DROP, et le tunnel hérite de cette décision. iptables -L FORWARD -v -n montre à la fois la politique et les compteurs de paquets ; si la politique est DROP, le transfert nécessite une autorisation explicite pour le sens tunnel vers LAN et une pour la réponse.

Troisième étape : suivez le paquet jusqu’au LAN et cherchez la réponse

Surveillez les deux côtés du serveur en même temps. Capturez sur le tunnel et sur l’interface LAN, filtré sur un client et un hôte pour que la sortie reste lisible :

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

Les requêtes qui apparaissent sur tun0 puis de nouveau sur eth0 avec une source 10.8.0.x, suivies d’un silence, signifient que le paquet est arrivé et que la réponse est partie ailleurs. L’hôte du LAN répond à sa passerelle par défaut, cette passerelle n’a pas de route pour le pool VPN, et la réponse meurt sur le routeur du LAN. Faire un ping à l’hôte du LAN depuis le serveur ne prouve rien sur ce chemin, car ce trafic ne traverse jamais le tunnel.

Quatrième étape : choisissez entre traduction et route de retour

Deux réparations bouchent le trou, et le choix a des conséquences au-delà du fait que le ping fonctionne. La traduction de source fait du serveur l’expéditeur apparent :

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Limitez la règle au pool et à l’interface LAN, puis rendez-la permanente, sinon le prochain rechargement du pare-feu supprime discrètement votre correctif. Le coût est l’identité : chaque client ressemble au serveur VPN dans les journaux du LAN et les règles d’accès, et per-client policy becomes guesswork.

Une route statique pour 10.8.0.0/24 sur le routeur du LAN, pointant vers le serveur VPN, garde les adresses des clients visibles et constitue la meilleure réponse à long terme quand ce routeur est le vôtre. Beaucoup de sites font tourner les deux un moment, NAT pour la réparation immédiate et la route une fois la politique du pare-feu écrite. Si le serveur est un pair site à site plutôt qu’un pool, le côté serveur a aussi besoin d’un iroute pour le sous-réseau distant, sinon la route du pair existe mais le trafic des clients n’y est jamais associé.

Cinquième étape : vérifiez depuis le client et notez ce qui a changé

Bouclez depuis le client, pas depuis le serveur. Connectez-vous à un vrai service sur l’hôte du LAN, puis confirmez que les compteurs de traduction ont bougé avec iptables -t nat -L POSTROUTING -v -n, car une règle sans paquet est une règle qui n’a jamais correspondu. conntrack -L -s 10.8.0.5 montre le flux et son état quand vous avez besoin de la preuve que le sens retour est suivi.

Laissez une note dans la configuration du serveur : quel sous-réseau, quelle interface, quelle règle, et si le routeur du LAN porte une route de retour. La prochaine fois qu’une mise à jour du client efface une route poussée, cette note transforme une séance de pompiers en correction d’une ligne.