[gull] question NAT
Leopoldo Ghielmetti
Leopoldo.Ghielmetti at a3.epfl.ch
Fri Oct 8 12:05:03 CEST 2004
On Fri, 2004-10-08 at 10:19, Marc SCHAEFER wrote:
> On Thu, Oct 07, 2004 at 04:58:50PM +0200, Leopoldo Ghielmetti wrote:
> > 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
>
> oui et non.
>
> ping ouvre un socket local. L'adresse du socket est déterminée au
> départ. Faire des tcpdump -i ppp0 -n 'icmp' pour voir comment sont
> envoyés ces paquets (adresse interne?).
>
> En ce qui concerne le NAT/PAT stateful, même des protocoles non
> connectés peuvent être vus comme partie d'une même session (d'un même
> nexus).
>
> Si tcpdump te montre que les paquets sortent avec une adresse interne
> p.ex., alors il peut être utile de modifier le comportement.
>
> schaefer at defian:/proc% find . -name '*dyn*' 2>/dev/null
> ./sys/net/ipv4/ip_dynaddr
ça valeur est déjà à 1.
> C'est peut-être celui-là.
>
> Ou alors c'est
>
> ip route flush
il repond:
"ip route flush" requires arguments.
Si je lui donne en argument l'adresse IP qui m'intéresse, il l'efface de
la table de routage et plus aucun paquet ne sort.
> Mais si tu ne donnes pas un peu de traces réseau, on risque d'aller dans
> la mauvaise direction. Précise aussi sur quelle machine est fait le
> ping.
Alors, mon réseau est composé d'un réseau interne (divisé en
sous-réseaux) et d'une DMZ. On à un firewall Hardware (je ne me rappelle
plus le modèle mais je ne crois pas que ce soit important).
Les adresses internes sont en 10.122.x.x, les adresses de la DMZ sont
192.168.1.x.
Les clients ont des adresses en 10.x.x.x (et parfois en 192.168.x.x)
tandis que le firewall d'un des client est en 172.16.x.x.
Actuellement je suis en train de tester la connexion en appelant mon
modem à la maison, et j'ai configuré ma machine pour répondre aux IP
192.168.0.1 et 10.10.10.10.
Ensuite j'ai demandé à l'administrateur réseaux de router les adresses
192.168.3.x vers la machine connecté avec le modem. De façon à avoir la
configuration suivante:
+---------------+ +---------+ +---------------+
| mon PC | | routeur | | firewall |
| +----->| de mon +----->| 10.122.18.252 +---> internet
| 10.122.3.45 | | subnet | | 192.168.1.252 |
+---------------+ +---------+ +-------+-------+
| route pour 192.168.3.x
v
+---------------+
| routeur modem |
| |
| 192.168.1.253 |
+-------+-------+
|
modem
|
+---------------+
| maison |
| 10.10.10.10 |
| 192.168.0.1 |
+---------------+
Mon PC à la maison sera ensuite visible depuis les PC de la boîte avec
l'adresse 192.168.3.100 (et 192.168.3.140).
J'ai configuré le route de la façon suivante:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.3.100 * 255.255.255.255 UH 0 0 0 tap1
192.168.255.254 * 255.255.255.255 UH 1 0 0 tap1
192.168.0.1 * 255.255.255.255 UH 0 0 0 tap1
10.10.10.10 * 255.255.255.255 UH 0 0 0 tap1
192.168.3.140 * 255.255.255.255 UH 0 0 0 tap1
192.168.3.0 * 255.255.255.0 U 0 0 0 *
192.168.0.0 * 255.255.254.0 U 0 0 0 eth0
default 192.168.1.252 0.0.0.0 UG 0 0 0 eth0
(Il y a beaucoup de règle car je suis en train de tester différentes
solutions, en théorie il suffit d'ajouter les deux règles pour la 3.100
et la 3.140 vers le tap1).
iptables contient seulement la définition du MASQUERADE:
Chain PREROUTING (policy ACCEPT 472 packets, 35881 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 210 packets, 14659 bytes)
pkts bytes target prot opt in out source destination
568 47640 MASQUERADE all -- * ppp+ 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 203 packets, 14095 bytes)
pkts bytes target prot opt in out source destination
Le ifconfig me renvoie:
eth0 Link encap:Ethernet HWaddr 00:50:8B:69:DB:09
inet addr:192.168.1.253 Bcast:192.168.1.255 Mask:255.255.254.0
inet6 addr: fe80::250:8bff:fe69:db09/10 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:50633 errors:0 dropped:0 overruns:0 frame:0
TX packets:24545 errors:0 dropped:0 overruns:0 carrier:0
collisions:12 txqueuelen:100
RX bytes:6661648 (6.3 Mb) TX bytes:2932594 (2.7 Mb)
Interrupt:16 Base address:0x1000 Memory:fc500000-fc500038
tap1 Link encap:Ethernet HWaddr FE:FD:00:00:00:00
inet addr:192.168.255.126 Bcast:0.0.0.0 Mask:255.255.255.255
inet6 addr: fe80::fcfd:ff:fe00:0/10 Scope:Link
UP BROADCAST RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:469 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:46440 (45.3 Kb)
Interrupt:5
Si depuis ma machine 10.122.3.45 je ping 192.168.3.100 la connexion
monte et j'obtiens la configuration suivante:
route:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.3.100 * 255.255.255.255 UH 0 0 0 ppp0
192.168.0.1 * 255.255.255.255 UH 0 0 0 ppp0
192.168.0.1 * 255.255.255.255 UH 0 0 0 ppp0
10.10.10.10 * 255.255.255.255 UH 0 0 0 ppp0
192.168.3.140 * 255.255.255.255 UH 0 0 0 ppp0
192.168.3.0 * 255.255.255.0 U 0 0 0 *
192.168.0.0 * 255.255.254.0 U 0 0 0 eth0
default 192.168.1.252 0.0.0.0 UG 0 0 0 eth0
(les deux règles 192.168.0.1 sont dus au fait que diald route
automatiquement vers 192.168.0.1 (qui est l'adresse avec laquelle mon PC
à la maison s'annonce) et que mon script de routage l'ajoute une
deuxième fois car 192.168.3.140 est NATté vers 192.168.0.1. Mais ceci ne
dérange pas le routage).
iptables:
Chain PREROUTING (policy ACCEPT 476 packets, 36193 bytes)
target prot opt in out source destination
DNAT all -- * * 0.0.0.0/0 192.168.3.100 to:10.10.10.10
DNAT all -- * * 0.0.0.0/0 192.168.3.140 to:192.168.0.1
Chain POSTROUTING (policy ACCEPT 213 packets, 14866 bytes)
target prot opt in out source destination
MASQUERADE all -- * ppp+ 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 205 packets, 14218 bytes)
target prot opt in out source destination
DNAT all -- * * 0.0.0.0/0 192.168.3.100 to:10.10.10.10
DNAT all -- * * 0.0.0.0/0 192.168.3.140 to:192.168.0.1
ifconfig:
ppp0 Link encap:Point-to-Point Protocol
inet addr:192.168.0.250 P-t-P:192.168.0.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:5 errors:2 dropped:0 overruns:0 frame:0
TX packets:59 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:72 (72.0 b) TX bytes:4614 (4.5 Kb)
le tcpdump -i ppp0 sur le "routeur modem" donne:
11:41:12.320788 10.122.3.45 > 192.168.3.100: icmp: echo request (DF)
...
le tcpdump -i ppp0 sur le pc à la maison donne:
11:41:12.477763 10.122.3.45 > 192.168.3.100: icmp: echo request (DF)
...
Ensuite je lance un nouveau ping 192.168.3.100 et j'obtiens une réponse.
le tcpdump -i ppp0 sur le "routeur modem" donne:
11:42:50.507091 192.168.0.250 > 10.10.10.10: icmp: echo request (DF)
11:42:50.812689 10.10.10.10 > 192.168.0.250: icmp: echo reply
...
le tcpdump -i ppp0 sur le pc à la maison donne:
11:42:50.658851 192.168.0.250 > 10.10.10.10: icmp: echo request (DF)
11:42:50.658879 10.10.10.10 > 192.168.0.250: icmp: echo reply
...
Ce qui est parfaitement ok. La même chose si je ping sur 192.168.3.140
(la se sera 192.168.0.1 qui va répondre).
Si j'arrête le ping, après un timeout la connexion est arrêtée et la
configuration reviens à son point de départ, prête pour une nouvelle
requête de connexion.
J'espère que tu as toutes les informations nécessaires.
Si tu veux des logs supplémentaires dis-le moi.
Pour le moment je ne vois pas de solution, il semble que la mise en
place du NAT ne reroute pas les paquets du ping en cours (comme tu dis,
ils sont vu comme appartenant au même stream). Mais je ne sais pas
comment interrompre ce stream pour qu'il se reconnecte.
Si je fais:
iptables -t filter -A FORWARD -d 192.168.3.100 -j REJECT
J'obtiens du ping:
From 192.168.1.253 icmp_seq=58 Destination Port Unreachable
et si ensuite je reétablis la connexion:
iptables -t filter -D FORWARD -d 192.168.3.100 -j REJECT
Le ping reviens à l'état d'avant et le tcpdump me confirme que les
paquets ne sont pas NATtés.
Je ne sais pas comment forcer le reroutage des connexions.
ciao, Leo
> _______________________________________________
> 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/20041008/cd891a4f/attachment.pgp>
More information about the gull
mailing list