Clients OpenVPN pontés sans internet ? Vérifiez la règle NAT

Le serveur ponté est actif, la règle masquerade est présente, et le navigateur du client tourne toujours. Tout semble devoir fonctionner, et c’est pourquoi la première heure passe à vérifier le tunnel et les identifiants. Ensuite vous lisez le compteur de la règle NAT et trouvez un zéro qui n’a pas bougé. Une règle qui n’a jamais compté un paquet n’en a jamais croisé un, et sur un serveur ponté la raison est structurelle : le trafic du client sort par le périphérique virtuel tap, alors que la règle nomme la carte physique que vous avez copiée d’un ancien guide.

Le compteur est la preuve, pas la ligne du tableau

Les règles qui existent et les règles qui correspondent sont deux choses différentes, et le compteur les sépare. Listez la table NAT avec des compteurs détaillés et lisez les nombres à côté de chaque règle avant de changer quoi que ce soit. Un compteur figé à zéro alors que le trafic circule signifie que la règle a été ignorée, aussi raisonnables que paraissent ses adresses. Un compteur qui monte alors que la connexion échoue toujours vous envoie ailleurs : le transfert, le chemin de retour ou l’extrémité distante.

iptables -t nat -L POSTROUTING -v -n

Lisez d’abord le compteur à côté de la correspondance d’interface. Si la plage source est correcte et le côté sortie faux, la correction tient en un mot dans la règle, pas en une règle entièrement nouvelle.

Trouvez le nom que le noyau enregistre réellement

Identifiez le périphérique du tunnel par son nom avant d’écrire la règle, en utilisant la liste des interfaces plutôt que votre mémoire. Sur une installation OpenVPN pontée, le périphérique est généralement une interface tap créée par le serveur, et son nom fait partie de votre configuration locale, ce n’est pas une constante universelle. Confirmez qu’il existe pendant que le tunnel est actif, car un périphérique qui n’apparaît qu’après la connexion d’un client fera passer un test antérieur pour un problème de règle.

ip -brief link

Notez le nom. Chaque commande suivante de ce diagnostic s’y réfère, et une faute de frappe ici produit exactement le même compteur nul que l’erreur d’origine.

Réécrivez la règle pour le périphérique du tunnel

Pointez la règle vers le périphérique du tunnel et gardez la plage client comme condition de correspondance, afin qu’elle couvre le trafic du tunnel et laisse intactes les connexions propres de l’hôte. Remplacez par votre propre plage et le nom de votre périphérique, car les deux exemples ci-dessous sont des exemples et aucun n’est transposable d’une installation à l’autre.

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

Vérifiez ensuite les deux autres conditions que le même symptôme masque. Vérifiez si le transfert est activé et, s’il ne l’est pas, activez-le dans la configuration de la distribution plutôt qu’avec un echo qui disparaît au redémarrage. Lisez aussi les compteurs de la chaîne forward et, si elle rejette le trafic du tunnel, autorisez précisément cette interface et laissez la politique de la chaîne tranquille.

Lire la chaîne forward avec des compteurs coûte une commande et écarte la moitié des possibilités restantes avant de toucher une autre règle.

Pourquoi la carte physique ne correspond jamais

Un pont est un commutateur logiciel composé du périphérique tap et d’une interface physique. La trame du client entre dans ce commutateur et en sort vers le réseau physique comme membre du pont, non comme paquet sur la carte. Le noyau attribue donc le paquet au pont et à son port, et c’est pourquoi la carte à laquelle vous pensiez n’apparaît jamais dans la correspondance. L’interface physique n’a rien de cassé ; elle n’est simplement pas le périphérique auquel le noyau attribue ce paquet.

Le problème suivant que les gens rencontrent vient de la même structure : le filtrage de trames sur un pont est un mécanisme distinct du filtrage IP. Si l’exigence est une restriction au niveau des trames, elle relève du filtrage du pont, pas d’une règle de table IP.

Prouvez-le de bout en bout, puis rendez-le permanent

Montez un seul client et faites un ping vers quelque chose sur le LAN du serveur ; ce chemin exerce le transfert sans aucune traduction. Demandez ensuite quelque chose de public pour que la règle masquerade doive servir, et relisez le compteur : il devrait bouger pour ce test et pas pour le précédent. Une capture prise sur le périphérique du tunnel montre à la fois où la trame apparaît et quelle adresse elle porte.

Dernière étape : mettez les règles qui fonctionnent dans la configuration qu’un redémarrage lit, et notez le nom du périphérique que le pont de cet hôte utilise réellement. Tout ce qui est tapé à la main disparaît après un redémarrage, et la même panne revient sans rien pour l’expliquer.

Si le compteur ne bouge toujours pas après la réécriture, comparez la plage source de la règle à l’adresse que le client a réellement reçue, car un serveur ponté peut distribuer des adresses d’une plage que vous ne visiez pas.