Encadrez la règle SNAT d’OpenVPN avant qu’elle ne casse nginx

Deux pannes arrivent toujours du même type d’hôte. Dans la première, les clients s’authentifient puis n’atteignent rien au-delà du tunnel. Dans la seconde, le VPN monte et le site web du serveur lui-même cesse de répondre, ce qui est le plus alarmant car cela ressemble à un dommage collatéral. Sur un VPS conteneurisé, les deux renvoient généralement à la même courte liste de vérifications, et l’ordre compte : d’abord le périphérique, ensuite la traduction, enfin la portée.

Confirmez que le conteneur peut créer un périphérique tun

Rien d’autre n’importe si l’interface du tunnel ne peut pas exister. Vérifiez que /dev/net/tun est présent et que la création d’un périphérique de test réussit, car beaucoup de fournisseurs désactivent tun dans les conteneurs par défaut. Aucun travail sur le firewall ne compense un périphérique qui n’a jamais été créé.

Si le périphérique manque, seul l’hôte ou le fournisseur peut l’activer. Une autre offre est souvent moins chère qu’un fil de support ouvert qui dure une semaine. Confirmez-le avant de lire une seule ligne du journal d’OpenVPN. Sinon vous passerez la soirée à ajuster des règles qui ne verront jamais un paquet.

Décidez ce que fait MASQUERADE sur cette interface

Sur une machine virtuelle ordinaire, la règle de sortie habituelle est POSTROUTING MASQUERADE de l’interface principale. Dans un conteneur OpenVZ, le périphérique visible est souvent venet0, une interface virtuelle gérée par l’hôte plutôt qu’une carte réseau routée, et MASQUERADE ne s’y comporte pas toujours comme les tutoriels le supposent.

La forme viable est une traduction explicite vers l’adresse que les clients atteignent déjà, avec le transfert autorisé dans les deux sens. Remplacer le pool depuis la configuration du serveur compte autant que remplacer l’adresse. Lisez chaque ligne avant de la coller.

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Sans les règles de transfert, la traduction a toujours lieu et le noyau refuse toujours de transférer. Cette combinaison produit l’état déroutant où les compteurs de la règle NAT montent tandis que le client ne reçoit rien. Les deux lignes FORWARD doivent aussi se trouver avant toute règle drop large dans la même chaîne. L’ordre fait partie de la configuration, ce n’est pas un détail d’implémentation.

Limitez la règle à un pool et une interface

Le second symptôme a une autre cause : une règle POSTROUTING sans restriction de source ni de sortie. Une telle règle réécrit chaque paquet qui quitte l’hôte.

Les services qui dépendent de la source d’origine se comportent alors mal. Un serveur web derrière un proxy local peut cesser de répondre, et le redémarrer ne change rien car la règle est toujours sur le chemin. Le trafic que l’hôte envoie vers sa propre adresse publique est aussi touché, ce qui explique que la panne puisse ressembler à un problème de DNS ou de certificat plutôt qu’à un problème de firewall. La règle a presque certainement été ajoutée pour corriger le premier symptôme.

La solution est de resserrer la correspondance sur le pool du tunnel et l’interface de sortie, puis d’ajouter une règle par pool au lieu d’élargir une seule règle pour en couvrir plusieurs.

Rendez les règles persistantes et découvrez qui d’autre les possède

Les règles ajoutées à la main disparaissent au redémarrage, enregistrez-les donc avec iptables-save ou gérez-les via netfilter-persistent là où il est installé. Confirmez que la restauration s’exécute avant le démarrage d’OpenVPN. Redémarrez ensuite une fois exprès plutôt que de découvrir le manque lors d’un incident.

Sur un hôte conteneurisé, confirmez aussi que le fichier de persistance vit dans un stockage conteneur inscriptible et que le fournisseur ne remplace pas le filtrage au démarrage. Certaines plateformes gèrent la politique hors du conteneur, où les règles locales sont soit ignorées, soit en conflit avec celles de l’hôte.

Vérifiez avec des compteurs et un flux capturé

Depuis un client connecté, vérifiez l’adresse publique qu’un service externe rapporte. Si elle correspond à l’adresse du serveur, la traduction fonctionne ; sinon, le paquet sort par un autre chemin ou ne sort pas du tout. Testez ensuite à la fois un service hébergé sur le serveur et un service sur l’internet public, car ils empruntent des chemins différents à travers le même jeu de règles.

Sur le serveur, lisez les compteurs de paquets des règles NAT et FORWARD avec iptables -t nat -L -v -n et observez un flux dans une capture. Si l’adresse du client apparaît dans la capture et qu’aucune réponse ne suit, le manque est sur le chemin de retour ou dans le filtrage du fournisseur, pas dans le profil du client. Comparez la source capturée avec l’adresse vers laquelle la règle traduit, car un écart signifie qu’une autre règle a correspondu d’abord. Un seul flux observé tranche plus qu’une page de lecture de configuration.

Gardez le pool, l’adresse traduite et le nom de l’interface ensemble dans le journal des modifications. Une règle correcte pour un pool traduit mal la suivante.