SNAT, DNAT et Masquerade : ce que fait chaque règle NAT d’un VPN

Placez une capture des deux côtés d’une passerelle VPN et un seul flux peut afficher quatre adresses différentes. Le NAT source réécrit d’où le paquet prétend venir ; le NAT de destination réécrit où il va. Masquerade n’est pas une troisième direction, c’est une règle de NAT source qui prend son adresse sur l’interface sortante au lieu d’une valeur fixe. Nommez laquelle des trois vous sert vraiment et la plupart des tickets « le VPN est cassé » se réduisent à une question sur le chemin de retour.

Ce que chaque règle réécrit

Le NAT source, généralement écrit SNAT, change l’adresse source d’un flux lorsqu’il quitte un routeur ou une passerelle. Le service qui reçoit répond à l’adresse traduite, et la boîte qui traduit annule le changement grâce à l’état qu’elle a gardé pour cette connexion. Sous Linux cet état vit dans conntrack, c’est pourquoi conntrack -L imprime les tuples d’origine et de réponse côte à côte.

Le NAT de destination, DNAT, change la destination à la place. Un paquet adressé à une adresse publique sur UDP 51820 peut être réécrit vers un serveur WireGuard interne à 10.8.0.2:51820. C’est ainsi qu’un routeur domestique ou un répartiteur de charge cloud publie un écouteur VPN, et cela ne dit rien de ce que le tunnel pourra transporter ensuite.

Masquerade appartient à la famille SNAT. La règle ne nomme aucune adresse ; elle utilise celle que porte l’interface sortante au moment où le paquet part. Linux lui donne sa propre cible, et c’est le choix habituel sur une interface WAN qui reçoit son adresse par DHCP ou PPPoE.

Là où vit la correspondance se décide la panne

Notez le tuple à chaque frontière : avant le tunnel, à l’intérieur et sur l’interface publique. Une capture à l’intérieur du tunnel diffère légitimement d’une capture à l’extérieur, et qui compare les deux sans savoir où la traduction a lieu court après le mauvais hôte.

Le trafic de retour doit passer par l’appareil qui détient la correspondance. Si la réponse prend un autre chemin, un second lien montant, une route de politique ou un fournisseur qui n’a jamais entendu parler de votre plage privée, la traduction inverse à état n’a jamais lieu et le client voit du trafic à sens unique. Ajouter du NAT source corrige rarement une route de retour manquante ; cela peut masquer le symptôme sur un flux tout en cassant la politique fondée sur les adresses partout ailleurs.

L’autre erreur courante est d’attendre d’un tunnel qu’il crée de la routabilité. Un client privé dont les paquets sortent vers internet a besoin d’un dispositif de sortie valable : une route par défaut, une passerelle qui transfère et, le plus souvent, une traduction source vers une adresse publique. Le chiffrement seul ne rend pas une adresse privée joignable.

Masquerade ou SNAT explicite

Comparez-les sur ce qu’ils promettent. Masquerade choisit l’adresse de sortie, le SNAT explicite la fixe. Sur une passerelle à adresse publique stable, la fixation donne aux journaux et aux listes d’autorisation partenaires une valeur prévisible. Sur un lien WAN dynamique, une adresse SNAT fixée devient fausse dès que le bail change, et c’est exactement le cas pour lequel Masquerade a été conçu.

La portée compte autant que le choix. Une règle Masquerade qui correspond à chaque paquet quittant la passerelle, sans limite de source ni de destination, traduit aussi du trafic que vous vouliez laisser intact, y compris vers d’autres réseaux privés. Limitez la règle à la plage des clients, à la destination prévue et à l’interface.

C’est avec IPsec fondé sur des politiques que cela mord le plus fort. Le guide de transfert de strongSwan détaille l’activation du transfert IP et l’ajout d’une règle de SNAT source pour les clients, et la même documentation couvre l’exclusion du trafic qui doit garder son adresse d’origine. Traduisez une source avant que la politique de sécurité ne la rencontre et le tunnel peut monter alors que le trafic tombe encore, parce que le paquet ne ressemble plus au sélecteur négocié.

Décidez aussi ce que l’extrémité distante doit voir. Après traduction un service voit la passerelle, pas le client individuel. Cela simplifie le routage de retour et, en même temps, aplatit les journaux et neutralise les listes d’autorisation par client. Si conserver les adresses des clients compte, prévoyez un chemin de retour routé plutôt que de les masquer pour faire passer un test.

Lire les règles sur une passerelle Linux

Une passerelle d’accès distant avec des clients sur 10.8.0.0/24 et une interface WAN nommée eth0 a besoin du transfert activé et d’une politique de filtrage qui autorise le flux avant que la moindre règle NAT puisse aider. La version iptables tient les deux directions dans la table nat :

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 51820 \
  -j DNAT --to-destination 10.8.0.2:51820

La forme nftables utilise les mêmes deux points d’ancrage avec une interface nommée et une chaîne explicite :

nft add rule ip nat postrouting ip saddr 10.8.0.0/24 oifname "eth0" masquerade
nft add rule ip nat prerouting iifname "eth0" udp dport 51820 dnat to 10.8.0.2:51820

Les deux extraits supposent que la chaîne de filtrage accepte déjà le flux transféré. NAT n’est pas une règle d’autorisation, et un paquet correctement traduit peut encore être rejeté une table plus loin. Confirmez la correspondance vivante avec conntrack -L, confirmez ce qui est chargé avec nft list ruleset ou iptables-save -t nat, puis capturez sur les deux interfaces pour voir l’adresse changer réellement.

Les modes de panne qui ressemblent à une mauvaise règle

Le trafic en épingle est le classique. Un client interne qui joint un serveur interne par l’adresse publique du serveur a besoin du DNAT à l’entrée et d’une traduction source à la sortie retour, sinon le serveur répond directement au client et la réponse est rejetée. Le correctif est une seconde règle, plus étroite, pour ce cas interne-vers-public, pas une règle Masquerade plus large pour tout.

La double traduction est la silencieuse. Un client déjà derrière un NAT d’opérateur arrive sur votre passerelle avec une adresse que vous ne pouvez pas router en retour, alors vous traduisez de nouveau. Cela marche, mais les journaux portent désormais deux sauts d’adressage privé et toute enquête a besoin des deux correspondances. IPsec fondé sur des politiques ajoute un troisième tour : traduisez avant la correspondance de politique et vous obtenez une SA montée sans trafic qui passe, ce qui se lit comme un bug de pare-feu plutôt que de NAT.

Il y a ensuite le test qui passe et le déploiement qui échoue. Lancer la commande NAT à la main prouve le mécanisme, pas la configuration. Une règle ajoutée à chaud disparaît au redémarrage ou au prochain événement d’interface, et une règle Masquerade liée à une interface qui change de numéro peut modifier silencieusement l’adresse que voit l’extrémité distante. Mettez la règle dans la configuration du pare-feu propriétaire et retestez après une reconnexion.

Liste de contrôle avant d’enregistrer la règle

Nommez d’abord la direction : source, destination, ou les deux. Identifiez ensuite qui doit détenir l’état — la passerelle, le routeur en amont ou le pair IPsec — et confirmez que le chemin de retour revient par là. Limitez la règle à la plage de clients, à la destination et à l’interface que vous visez réellement, et décidez à l’avance si l’extrémité distante doit voir la passerelle ou l’adresse d’origine du client.

Testez depuis un client, pas depuis la passerelle. Un navigateur sur la passerelle elle-même peut contourner entièrement la règle de traduction des clients, donc une page qui y fonctionne ne prouve rien sur le tunnel. Envoyez une requête originaire du client, observez les compteurs et la table conntrack, et recommencez après une reconnexion du tunnel et un changement d’adresse WAN si l’un ou l’autre est possible là où vous travaillez.