Nat Loopback : pourquoi je suis un peu boulet…

Suite de mon précédent article sur le Nat Loopback et pourquoi j’en ai eu besoin vu mes configurations.

I – Je suis un boulet …

En relisant et en corrigeant, je constate que ce problème, tel que je vous l’explique, il apparait par ma faute.

Le Natloopback pourrait se faire sans soucis si ma règle de postrouting était simplement celle ci:

iptables -t nat -A POSTROUTING -s 10.10.1.0/24 -p tcp -m multiport --dports 80,443 -j SNAT --to IP.EXTERNE

( A condition qu’on veuille bien évidement que ce réseau puisse sortir sur le net…)

Ce « blocage » (impossibilité pour 10.10.1.0/24 de contacter 10.10.1.0/24 en passant par l’IP Externe), comme un idiot, je l’impose ici :

iptables -t nat -A POSTROUTING -s 10.10.1.0/24 ! -d 10.10.1.0/24 -p tcp -m multiport --dports 80,443 -j SNAT --to IP.EXTERNE

Comme en réalité, j’ai d’autres réseaux (10.20.XX.XX, les vpns, les autres réseaux d’admins, etc..) mes règles sont en fait bien plus compliquées et du coup, la simplification pour l’article sur juste 10.10.1.0/24 pose alors soucis.

En vrai, j’ai plutôt ce genre de chose :

iptables -t nat -A POSTROUTING -s 10.168.1.0/24 ! -d 10.0.0.0/8 -j SNAT --to IP.EXTERNE
iptables -t nat -A POSTROUTING -s 10.100.1.0/24 ! -d 10.0.0.0/8 -j SNAT --to IP.EXTERNE

Le réseau 10.168.1.0, c’est mon réseau interne Xen mais à domicile. Celui ci est lié à mon réseau Xen Dedibox via un tunnel IPSEC (strongswan, un article à venir….)
Le réseau 10.100.1.0 c’est mon réseau pour les clients Openvpn (quand j’utilise mon VPN par exemple)

Entre eux, aucun nat : 10.20.1.XXX peut contacter 10.100.1.XXX, 10.168.1.XXX peut contacter 10.20.1.XXX,etc…

Si j’ai ces règles, ce que j’autorise les machines de ces réseaux à pouvoir sortir (et donc à voir l’adresse source modifiée).

Premier truc particulier, mes vpns ne sont pas sur mes gateways. Et ensuite, je force les flux à traverser les routeurs

Par exemple, un machine 10.168.1.XXX, si elle cherche à joindre 10.20.1.XXX, va  faire :
10.168.1.XXX-> Routeur Domicile 10.168.1.1 -> Vpn Domicile 10.168.1.2.
Et en arrivant sur le vpn coté Dédibox : VPN Dedi 10.20.1.20 / Routeur Dedi 10.20.1.1 / VM destination 10.20.1.10…
Le passage par le routeur est forcé au niveau du VPN (source routing)

Dans tous les cas, le routeur voit le paquet (qu’il soit pour l’interne ou l’externe)

Et donc, si je laisse ma règle ainsi :

iptables -t nat -A POSTROUTING -s 10.168.1.0/24  -j SNAT --to IP.EXTERNE

Un paquet venant de 10.168.1.0/24 sera « snater » également s’il est à destination de 10.20.0/24. Ce que je ne veux pas.
Pour éviter le snat si le paquet est pour l’interne, je rajoute donc :

iptables -t nat -A POSTROUTING -s 10.168.1.0/24 ! -d 10.0.0.0/8 -j SNAT --to IP.EXTERNE

Et du coup, je dois bien rajouter cette règle :

iptables -t nat -A POSTROUTING -s 10.168.1.0/24 -d IP.INTERNE.WEB -p tcp -m multiport --dports 80,443 -j SNAT --to IP.EXTERNE

si je veux que le réseau 10.168.1.0/24 puisse voir le postrouting se faire si la destination est le serveur WEB.

Pour être honnête, ce fonctionnement (de forcer le passage dans les routeurs) je l’ai abandonné , j’explique pourquoi dans la série sur Strongswan.

On peut aussi noter que :

iptables -t nat -A POSTROUTING -s 10.168.1.0/24 ! -d 10.0.0.0/8 -j SNAT --to IP.EXTERNE

pourrait être remplacé par :

iptables -t nat -A POSTROUTING -s 10.168.1.0/24 -o eth0  -j SNAT --to IP.EXTERNE

La, comme la règle ne s’applique que pour les paquets qui sortent par eth0, les paquet de 10.168.10/24 à destination de 10.10.1.0/24 (donc sur -o vlan10), ne sont donc pas concernés.

Comme souvent, on peut faire de plusieurs façons.

Mon « erreur » m’aura fait prendre conscience que j’ai des règles à retravailler dans Iptables (depuis que j’ai simplifié mon VPN), ce sera je pense un futur article.
Du coup, désolé pour le « temps perdu », mais au moins, on aura réviser un peu.

Si au moins une personne apprend un truc, je n’aurais pas fait ça pour rien 😉

II – Histoire d’apprendre un truc en plus

Allez pour le curieux qui se demanderait,  pourquoi le DNAT se fait en PREROUTING et le SNAT en POSTROUTING ?

Une règle Prerouting avec toutes ses options :

iptables -t nat -A PREROUTING -d IP.EXTERNE -i eth0 -p tcp -m multiport --dports 80,443 -j DNAT --to-destination IP.INTERNE.WEB

Prerouting concerne les paquets qui entrent , l’option -i  xxx (si non présente, toutes les interfaces sont concernées) en est témoin.

Côté Interne -> Externe, rien à faire.

Par contre, Externe -> Interne, le routeur doit modifier l’adresse de destination.
Et comme de la destination découle le routage, le changement doit bien avoir lieu en prerouting, avant les décisions de routage.

Une règle Postrouting avec toutes ses options :

iptables -t nat -A POSTROUTING -s 10.10.1.0/24 -o eth0 -p tcp -m multiport --dports 80,443 -j SNAT --to IP.EXTERNE

La, on travaille sur les paquets qui quittent le routeur, option -o …

Postrouting pouvant faire des choses différentes en fonction de l’interface, cette fameuse option -o, Il faut donc bien connaitre l’interface de sortie, et ce donc, après les décisions de routages en Postrouting.

Au final, et comme d’habitude, c’est logique.