Faut-il appliquer du SNAT à une redirection de port vers un sous-réseau VPN ?

Rediriger un port vers un hôte situé derrière le client VPN du routeur échoue d'une manière qui ressemble à un problème de pare-feu, car la requête arrive clairement. Le service journalise une connexion, le client attend, et rien ne revient. La traduction de destination a fait son travail ; le paquet de retour est la partie qui a disparu. Une règle NAT source sélective sur le routeur corrige cela, et la partie intéressante consiste à décider à quel point cette règle peut être étroite.

Pourquoi la réponse prend un autre chemin

Une redirection de port réécrit où va un paquet, jamais d'où il vient. L'adresse du client internet reste dans le champ source pendant tout le tunnel, donc le service distant voit un inconnu et répond de la seule manière qu'il connaît : via sa propre passerelle par défaut. Cette passerelle est le concentrateur VPN de l'autre côté, qui n'a aucune route de retour vers une adresse publique arbitraire.

Regardez une capture sur l'interface du tunnel et l'asymétrie est évidente : des paquets de requête sortants, rien en entrant. La chaîne de redirection a autorisé le flux et le tunnel l'a transporté, donc la chute se produit après que l'hôte distant a déjà choisi un chemin de retour.

Une règle source assez étroite pour être fiable

Faites du routeur la source à laquelle l'hôte distant répond. Dans cette configuration, l'adresse WAN est 203.0.113.24, le LAN est 192.168.88.0/24, l'adresse du tunnel du routeur est 172.20.5.1, et le service répond sur 172.20.5.40:8443. La règle ci-dessous correspond au paquet après la traduction de destination, c'est pourquoi elle nomme l'adresse traduite et non la publique. Rien en elle ne dépend de l'adresse du client, et c'est exactement le point.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

Chaque correspondance de cette ligne existe pour garder la réécriture locale à un service sur un tunnel. Retirez l'interface ou le port et vous réécrivez plus de trafic que le problème ne l'exige, et c'est ainsi qu'un correctif ciblé devient une énigme pour la personne suivante.

Quand un masque global est le choix honnête

Si le routeur redirige de nombreux services vers le même sous-réseau VPN, une règle par service devient une liste que personne ne maintient. Masquer tout ce qui quitte l'interface du tunnel est plus simple et prévisible, au prix de cacher le client d'origine à chaque hôte de l'autre côté. Choisissez-le lorsque les journaux là-bas ne servent pas à l'attribution ; gardez la règle étroite lorsqu'ils servent.

Les deux options échouent aussi différemment. Une règle étroite manquante casse un service ; un masque large qui correspond à trop de choses peut réécrire silencieusement du trafic qui fonctionnait déjà, y compris les connexions sortantes du routeur lui-même.

Vérifiez les compteurs avant de publier

Les règles qui ne correspondent jamais sont identiques aux règles qui fonctionnent jusqu'à ce que vous comptiez les paquets. Relisez la table avec les compteurs d'octets avant qu'un client ne se connecte, puis connectez-vous depuis un réseau qui n'est pas le LAN et relisez-la. Deux lectures sont ce qui transforme une supposition en fait. Ne publiez la redirection qu'après que la seconde a bougé.

iptables -t nat -L POSTROUTING -v -n --line-numbers

Un compteur à zéro sur la règle source après une connexion réelle signifie que la correspondance est fausse, généralement parce que la destination ou le port ne correspond pas au paquet après traduction. Si le compteur grimpe mais que le client expire encore, le chemin de retour est corrigé et autre chose abandonne la réponse, alors regardez ensuite la politique de redirection de l'autre côté. L'accès en épingle depuis l'intérieur du LAN est un problème distinct et nécessite sa propre règle, pas une version plus large de celle-ci.