[gull] question NAT

Thu Oct 7 17:00:04 CEST 2004

Mise à jour.

Apparemment ce n'est pas le routing, mais le NAT j'avais cherché dans la
mauvaise direction. :-(
Il semble que les paquets ne soit pas soumis au NAT.

donc:
- je ping l'adresse interne, p.e. 192.168.3.100
- les paquet arrivent au routeur qui établit la connexion
- la connexion monte et la route + le NAT sont mis en place
- les paquets sont forwardés chez le serveur distant qui reçoit
192.168.3.100 comme adresse pour le ping en cours et la bonne adresse,
p.e. 10.1.2.3 pour toutes les connexions suivantes (mêmes des pings).

Donc finalement le ping qui a servi à établir la connexion n'est pas
NATté correctement.

Moi je croyais que le ping était non connecté, donc je m'imaginais de
voir router indépendamment chaque paquet (et de même pour le NAT). Mais
apparemment le ping ouvre une connexion ICMP avec la machine distante et
envoie toutes les requêtes sur cette connexion. La chose me parait très
bizarre sinon impossible (car comment peut on établir une connexion ICMP
pour un ping alors que la destination n'est parfois même pas up?).

Il y à quelque part quelque chose que je n'ai pas complètement compris
sur le fonctionnement du ping. Je ne connais pas de tool pour tester le
UDP, donc je n'ai pas pu tester un protocole qui est sûrement pas
connecté.
Le TCP (testé avec telnet et ssh) souffrent du même problème, mais là je
comprends, si le paquet SYN n'est pas routé correctement il est
impossible que la connexion s'établisse.

Le but du ping est justement celui de lancer la connexion et de voir
quand elle monte grâce aux paquets reçus en retour.

ciao, Leo

On Thu, 2004-10-07 at 16:19, Leopoldo Ghielmetti wrote:
> 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/f4c8214f/attachment.pgp>