Deux clients VPN, deux adresses publiques : faites coïncider le SNAT

Deux clients VPN peuvent sortir par deux adresses IPv4 publiques différentes, et la règle qui y parvient est plus courte que la plupart des gens ne l’imaginent. Ce qui la fait fonctionner n’est pas la syntaxe d’iptables mais l’état du paquet lorsqu’il atteint la chaîne de sortie : l’adresse source qui s’y trouve doit encore permettre de distinguer les clients. Si un masquerade antérieur a déjà ramené les deux sur une seule adresse, aucune règle par client ne peut rétablir la distinction. Réglez cette question d’abord, puis écrivez la traduction.

Quelle identité parvient à la passerelle

La règle correspond à l’adresse source du paquet, pas à un nom d’utilisateur VPN ni au nom qu’affiche une application cliente. Tout ce qui traduit le paquet plus tôt sur le chemin détermine ce que votre règle peut encore voir. Exécutez la table nat dans l’ordre et trouvez le point où la source est encore propre à chaque client.

iptables -t nat -S POSTROUTING

Lisez cette liste depuis le haut. Une règle de masquerade près du haut réécrit la source de chaque flux correspondant, et les entrées par client placées après elle correspondent à une adresse qui n’existe plus. Quand deux appareils LAN partagent un tunnel et arrivent comme une seule adresse interne, la conception doit changer avant le pare-feu : gardez leurs plages source distinctes ou donnez à chacun sa propre adresse interne.

Liez l’attribution de l’adresse interne au client authentifié. Remettre cette adresse à un autre appareil remet aussi la politique de sortie, et la traduction de source n’est pas une preuve d’identité à elle seule.

La traduction ne peut pas inventer une adresse

Chaque adresse publique doit être attribuée ou routée vers ce point de sortie, et les réponses doivent retrouver leur chemin jusqu’à lui. Une règle qui envoie du trafic depuis une adresse vers laquelle personne ne route en retour est rejetée à l’extrémité distante ou reçoit une réponse adressée à un hôte qui ne l’a jamais demandée. Une instance de fournisseur cloud voit généralement son adresse publique traduite en adresse d’interface privée avant que le paquet ne parte, donc la source SNAT doit être l’adresse que le fournisseur acceptera, pas la valeur affichée par la console. Lisez le modèle d’adressage du fournisseur et suivez-le au lieu de recopier la valeur publique dans chaque paquet.

En pratique, cela signifie vérifier le préfixe routé dans la console du fournisseur avant de toucher au pare-feu, et utiliser l’adresse d’interface privée comme source de traduction lorsque la correspondance est un pour un. Les adresses des exemples ci-dessous proviennent des plages de documentation, donc la première chose à remplacer est le texte de l’adresse lui-même.

Insérez avant le masquerade générique

Confirmez l’interface de sortie et la chaîne actuelle avant d’ajouter quoi que ce soit. La première décide quels paquets la règle peut correspondre, et la seconde montre ce qui se trouve déjà devant elle.

ip -4 route show default
iptables -t nat -L POSTROUTING -n -v --line-numbers

La première commande nomme l’interface par laquelle un paquet vers Internet sort réellement. La seconde affiche la chaîne avec les numéros de ligne. L’entrée de masquerade générique est la ligne au-dessus de laquelle il faut rester.

iptables -t nat -I POSTROUTING 1 -s 10.88.4.20/32 -o ens3 -j SNAT --to-source 198.51.100.77
iptables -t nat -I POSTROUTING 1 -s 10.88.4.21/32 -o ens3 -j SNAT --to-source 198.51.100.78

Les deux règles ci-dessus correspondent chacune à une adresse interne, limitent la correspondance à l’interface de sortie et fixent la source explicitement. Insérez plutôt que d’ajouter : en position 1, elles sont évaluées avant la ligne de masquerade. L’ordre entre les deux n’a pas d’importance car leurs sources diffèrent. Remplacez ens3 par ce que la commande de route a signalé, et tenez les autres gestionnaires de pare-feu à l’écart des mêmes hooks, car deux outils qui écrivent une même table sont la raison habituelle pour laquelle une règle correcte reste sans effet.

Prouvez la source avec un nouveau flux

Le NAT avec état lie une traduction au début d’un flux et la réutilise pour les paquets suivants, si bien qu’une session ouverte avant le changement conserve son ancienne source après le changement. Seule une connexion nouvellement initiée prouve la règle.

conntrack -L -s 10.88.4.20 -p tcp --dport 443

Lisez la direction de réponse de cette entrée : sa destination est l’adresse que l’extrémité distante voit comme source. Comparez-la à l’adresse publique visée, et considérez une entrée portant l’ancienne adresse comme la preuve d’un flux démarré trop tôt plutôt que d’une règle défectueuse. Demandez au client d’ouvrir une nouvelle connexion, puis répétez la requête. Vider toute la table de suivi pour forcer le test interrompt toutes les autres sessions de la passerelle.

La traduction ne choisit toujours pas la route, ne laisse pas passer le flux dans le filtre et ne publie pas de service entrant. Une route erronée et une règle d’autorisation manquante continuent d’échouer après une règle SNAT parfaite. Vérifiez aussi IPv6 et tout chemin de sortie secondaire, puis notez les paires interne-vers-publique dans la documentation du pare-feu afin que la prochaine modification parte de la correspondance et non du texte de la règle.