Redirection de port vers un peer WireGuard derrière NAT : DNAT plus SNAT

Un navigateur demande https://203.0.113.10:8443, le proxy accepte la connexion et le service sur le peer WireGuard ne répond jamais. La règle DNAT fait son travail ; c’est la réponse qui échoue. Suivez le paquet dans les deux traductions et la règle manquante devient évidente. Le correctif est une instruction NAT de plus dans le bon hook, pas un nouveau tunnel.

Suivez une requête de bout en bout

La requête arrive sur l’interface publique du proxy avec l’adresse publique du client comme source et l’adresse du proxy comme destination. Dans nat PREROUTING, la règle DNAT réécrit la destination vers l’adresse du tunnel du peer, 10.90.0.2. La décision de routage envoie ensuite le paquet par wg0, et le chemin de transfert est complet.

Sur le peer, le paquet porte désormais l’adresse source publique d’origine, car rien ne l’a réécrite. Le service accepte la connexion et envoie sa réponse à sa propre passerelle par défaut, qui est le routeur domestique devant le peer. Ce routeur n’a aucun état pour un flux qu’il n’a jamais vu et soit il abandonne le paquet, soit il le traduit vers sa propre adresse publique, ce que le client n’acceptera pas.

L’asymétrie est tout le problème : la requête passe par le proxy et la réponse essaie d’aller directement. Le suivi des connexions du proxy n’aide que si la réponse revient par le proxy, et elle ne peut pas y revenir tant que l’adresse source pointe encore vers le client d’origine.

Ajoutez la traduction de retour

Réécrivez la source du flux transféré vers l’adresse du tunnel du proxy avant qu’il ne parte vers le peer. Le service répond alors à 10.90.0.1, le proxy le reçoit et le suivi des connexions inverse les deux traductions avant que le paquet ne revienne au client.

iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

La règle POSTROUTING est délibérément étroite : elle correspond à la destination traduite et à l’interface du tunnel, donc elle ne réécrit pas le trafic sans rapport qui sort par wg0. Une règle masquerade large masquerait aussi l’adresse du client, mais elle le ferait pour chaque flux et rendrait la table NAT plus difficile à auditer.

Placez les règles là où le tunnel existe

Les règles qui référencent l’adresse ou l’interface du tunnel doivent s’exécuter après que wg-quick l’a configuré. L’interface est créée avant PreUp, mais les adresses, le MTU, le DNS et les routes sont appliqués ensuite, et PostUp s’exécute une fois tout cela en place. Mettez les ajouts dans PostUp et les suppressions dans PreDown.

PostUp = iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PostUp = iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1
PreDown = iptables -t nat -D PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PreDown = iptables -t nat -D POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

Les suppressions doivent correspondre aux ajouts jeton pour jeton, y compris les correspondances multiport et d’interface. Une suppression qui diffère d’une correspondance ne supprime rien, et la reconnexion suivante ajoute une seconde copie de la règle. Après quelques reconnexions, la table contient des doublons difficiles à attribuer à une ligne de configuration.

Vérifiez le résultat avec iptables -t nat -S après une reconnexion. Si la même règle apparaît deux fois, la ligne PreDown ne correspond pas et le nettoyage échoue silencieusement.

Transfert, filtrage et l’autre NAT

Activez le transfert IPv4 de façon permanente, puis autorisez le flux transféré dans la table de filtrage. DNAT se produit avant la chaîne FORWARD, donc la règle de filtrage correspond à la destination traduite et non à l’adresse publique. Si UFW gère le pare-feu, exprimez l’autorisation comme une règle de route ; une règle d’hôte simple ne couvre pas le trafic transféré.

Deux autres couches NAT peuvent encore casser le chemin même lorsque les règles du proxy sont correctes. Sur une connexion domestique, l’adresse publique appartient au routeur, et ouvrir le port dans son pare-feu n’est pas la même chose que créer une entrée de redirection de port qui envoie ce port au proxy. Un port qui semble ouvert de l’extérieur alors que rien ne répond manque souvent exactement cette correspondance.

Sur un VPS NAT, le fournisseur mappe un port public vers une adresse privée. Le mappage doit correspondre au port que vous annoncez, et une discordance ressemble exactement à un tunnel cassé. Confirmez le mappage du fournisseur avant de modifier la configuration WireGuard.

Vérifiez le chemin de retour et acceptez le coût

Connectez-vous depuis un réseau qui n’est pas le LAN du proxy, puis inspectez la paire de traductions pendant que la connexion est ouverte :

conntrack -L -p tcp --dport 8080
tcpdump -ni any tcp port 8080

L’entrée conntrack devrait afficher le tuple d’origine, le tuple traduit et la direction de la réponse. Si la réponse manque, le peer n’envoie pas par le tunnel, ce qui signifie généralement que la règle SNAT n’a pas été appliquée ou que le pare-feu propre au peer a rejeté le flux.

Redémarrez une fois pour prouver que PostUp réapplique les règles, puis arrêtez le tunnel et confirmez que PreDown les a supprimées. Les règles mortes qui survivent à une déconnexion sont la raison pour laquelle un changement ultérieur se comporte de façon imprévisible.

Enfin, acceptez ce que le SNAT coûte. Le service voit chaque requête comme venant du proxy, donc les journaux d’accès, les limites de débit par client et les listes d’adresses autorisées ne distinguent plus les utilisateurs. Le cas hairpin a besoin de sa propre traduction de source pour les clients du LAN du proxy. Si le peer a besoin des vraies adresses des clients, l’alternative est une route de retour vers le réseau client, ce qui demande plus de travail mais conserve l’information.