[gull] question NAT

Leopoldo Ghielmetti Leopoldo.Ghielmetti at a3.epfl.ch
Thu Oct 7 16:20:02 CEST 2004


Voilà, pour le moment j'ai trouvé une solution effectivement beaucoup
plus facile que celle de commencer à patcher kernel+iptables.
Merci pour le conseil.

La solution consiste à rediriger les adresses internes sur les
différentes interfaces tap crées par diald. Ensuite quand l'interface
est up un script se charge de faire le NAT entre les adresses internes
concernés par l'interface sur les adresses externes, et d'implémenter
les routes nécessaires. Le NAT et les routes sont détruites dès que la
connexion tombe.
Ceci me permet de rediriger uniquement les adresses internes qui
m'intéressent.
Comme solution n'est pas trop mal tant qu'on à un seul modem.
ça peut par contre poser des problèmes si on veut avoir plusieurs
connexion en même temps et avec des clients avec les mêmes numéros IP.
ça peut même poser des problèmes si on veut se connecter chez un client
qui a la même adresse IP que le PC depuis lequel on veut se connecter
(mais ce cas peut être facilement reconnu et évité).

Par contre j'ai maintenant un autre problème.

Je commence la connexion en faisant un ping, mais même si la connexion
monte je n'obtiens aucune réponse. Il faut l'arrêter et le relancer et à
ce moment les paquets seront routes correctement.
Il semblerait que même en changeant les routes via le script au moment
que la connexion monte, le routage ne se fait correctement. Comme si le
paquets étaient toujours dirigés vers l'interface tap au lieu de
l'interface ppp. Seul les nouvelles connexions (et les nouveaux ping)
sont correctement routes. ça fait maintenant 2 jours que j'essaie de
comprendre ce phénomène, mais je n'ai pas réussi.

Quelqu'un à une idée?

ciao, Leo

On Fri, 2004-10-01 at 17:20, Marc SCHAEFER wrote:
> On Fri, Oct 01, 2004 at 04:21:10PM +0200, Leopoldo Ghielmetti wrote:
> > Seulement que iptables fait le DNAT puis le routing et ensuite le SNAT
> > et il n'y a pas moyen de faire l'inverse. Et qui plus est il n'y a pas
> 
> Si, c'est possible. Voir les commandes ip rule et ip route. On peut
> créer plusieurs tables de routage, activées en fonction de règle de
> marquage du firewall.
> 
> Par exemple (exemple compliqué, peut-être n'est-il pas nécessaire
> d'aller jusque-là). Ce que ça fait: les paquets provenant de la machine
> locale sont routées en fonction de l'adresse source. Les paquets
> traversants sont marqués à l'entrée en fonction de leur adresse source,
> puis à la sortie la marque est utilisée.
> 
> La seule particularité est qu'on utilise un patch à iptables qui permet
> de rendre les marques *persistantes* sur un nexus (si tu veux une
> `connexion' au sens du firewall stateful iptables: pas forcément du TCP).
> Sans ce patch `--save-mark' est impossible.
> 
> Sans ce patch il est difficile de router correctement les paquets en
> retour dans le cas général.
> 
> Je ne suis pas sûr que tu as besoin d'une solution si complexe, mais
> peut-être que cela te mettra dans la bonne direction (tables de routage
> multiples décidées en fonction d'une marque du firewall).
> 
> # New routing table
> ip route add default via 192.168.2.1 table 4
> 
> # For local host both ways
> ip rule add from 192.168.2.10/32 table 4
> 
> # No martians
> echo 0 >  /proc/sys/net/ipv4/conf/eth1/rp_filter
> 
> iptables -t mangle -F
> 
> iptables -A PREROUTING \
>          -i eth0 -s 192.168.3.0/24 -p tcp --sport 25 \
>          -t mangle -j CONNMARK --restore-mark
> 
> iptables -A PREROUTING \
>          -i eth0 -s 192.168.3.0/24 -p tcp --sport 25 \
>          -m mark --mark 2 \
>          -t mangle -j MARK --set-mark 4
> 
> iptables -A PREROUTING -t mangle -m mark ! --mark 0 -j ACCEPT
> 
> iptables -A PREROUTING \
>          -i eth1 -d 192.168.2.10/32 -p tcp --dport 25 \
>          -t mangle -j MARK --set-mark 2
> 
> iptables -A PREROUTING \
>          -i eth1 -d 192.168.2.10/32 -p tcp --dport 25 \
>          -t mangle -j CONNMARK --save-mark
> 
> # Special routing depending on mark
> ip rule add fwmark 4 table 4
> 
> _______________________________________________
> gull mailing list
> gull at lists.alphanet.ch
> http://lists.alphanet.ch/mailman/listinfo/gull
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://forum.linux-gull.ch/pipermail/gull/attachments/20041007/747ad1b1/attachment.pgp>


More information about the gull mailing list