OpenVPN se connecte mais rien ne passe : trouver la couche où le paquet tombe

OpenVPN annonce connecté et aucun trafic ne circule, une phrase qui couvre au moins cinq pannes sans rapport. Modifier des règles de pare-feu avant de savoir quelle couche échoue multiplie les inconnues et laisse un désordre à l’ingénieur suivant. Travaillez plutôt du processus vers l’extérieur, car chaque étape ci-dessous soit dégage un étage, soit resserre l’endroit où le paquet meurt. L’ordre compte ici : une capture prise avant de savoir quelle adresse est liée prouvera quelque chose, mais pas ce dont vous avez besoin.

La socket est liée ou elle ne l’est pas

Un service qui se dit actif peut encore être lié à une adresse ou à un transport que vous n’aviez jamais prévu. Interrogez la socket elle-même : ss -lunp liste les écouteurs UDP et ss -ltnp les TCP, et la colonne qui vaut la peine d’être lue est l’adresse locale, pas l’état.

Une réponse vide signifie généralement l’une de trois choses : le processus s’est arrêté après le démarrage, il a chargé un autre fichier de configuration, ou il écoute sur une adresse différente de celle qui est appelée.

ss -lunp | grep 1194
ss -ltnp | grep 1194

Une directive local fixe l’écouteur sur une seule adresse, si bien qu’un client visant ailleurs sur le même hôte est refusé tandis que le service, vu de l’extérieur, semble toujours sain. Un nom d’instance peut aussi pointer vers un fichier que vous n’avez jamais modifié, ce qui arrive sur des hôtes faisant tourner deux profils côte à côte.

Capturez le paquet extérieur, pas le tunnel

Filtrez sur l’interface physique et le port réel, avec votre propre interface substituée : tcpdump -ni eth0 udp port 1194. Les paquets sortants sans rien qui revienne désignent ce qui se trouve en amont : filtrage du fournisseur, un appareil NAT ou une adresse distante qui n’est pas celle que vous croyez. Le silence dans les deux sens désigne le routage du client ou un pare-feu local. Les réponses qui arrivent sans progression du tunnel désignent le canal de contrôle, donc un désaccord de clé ou de chiffrement, pas le filtrage.

Capturez les deux sens et gardez le fichier court. Une longue capture enterre les trois secondes intéressantes, et la réponse se trouve presque toujours dans le premier échange.

D’abord les compteurs, la trace seulement quand ils mentent

Commencez par les compteurs, car ils ne coûtent rien. Soit nft list ruleset, soit iptables -L -n -v répond à la seule question qui compte ici : la règle a-t-elle correspondu ? L’ordre décide du résultat, car la première correspondance gagne, c’est pourquoi un DROP large avant un ACCEPT ultérieur laisse cet ACCEPT mort et pourquoi ajouter une règle répare si rarement quelque chose.

La propriété fait aussi trébucher. Le noyau attribue les paquets générés localement au processus qui a ouvert la socket, et OpenVPN tourne normalement en root, si bien qu’une règle liée à un identifiant d’utilisateur ordinaire ne voit jamais le trafic du tunnel lui-même. Vérifiez l’UID propriétaire avant de décider que la règle est fausse.

Ce n’est que lorsque les compteurs restent ambigus qu’un journal vaut le bruit, et encore pour une tranche étroite : une règle iptables qui limite le débit et préfixe ses lignes, ou une règle nftables portant meta nftrace set 1 avec nft monitor trace en cours d’exécution. Une trace nomme la chaîne et la règle qui a accepté ou rejeté le paquet. Retirez les deux ensuite et gardez la journalisation de charge hors de tout cela.

Vérifiez aussi le transport. Un service de pare-feu limité à TCP ne dit rien d’un écouteur UDP sur ce numéro, si bien qu’une règle correctement lue peut encore rejeter chaque paquet.

Routage et chemin de retour

Un paquet accepté qui disparaît encore exige l’examen de son chemin de destination. ip route get indique la route choisie pour une adresse, et le filtrage du chemin inverse peut rejeter une réponse qui arrive par une interface que la table principale ne choisirait jamais. Le symptôme ressemble exactement à un rejet du pare-feu, c’est pourquoi cette vérification vient avant une autre règle NAT.

Sur une passerelle, inspectez le transfert et la chaîne forward plutôt que la chaîne input. Confirmez ensuite que le côté distant sait comment atteindre l’adresse source, car un chemin sortant qui fonctionne sans rien qui revienne est du silence dans les deux cas.

Ce que la note doit dire

Pour chaque changement, notez l’étape testée, la preuve lue et la valeur du compteur de part et d’autre. Cette note est ce qui rend « ça marche maintenant » survivable à la prochaine revue.

Deux raccourcis gardent la note honnête. Un paquet qui n’a jamais quitté l’hôte n’a pas pu être rejeté par une règle ailleurs, aussi convaincante soit la configuration du côté distant. Un paquet qui est parti et revenu déplace la question au-dessus de la couche réseau, où les compteurs du pare-feu n’ont plus rien à vous dire.