On Sun, 10 Feb 2008, Edgar Bonet wrote:
> Le dimanche 10 février, Dr P Dupre a écrit :
>> netstat depuis la machine qui ne recoit pas les ssh lorsque qu'il y a
>> un tunneling [...]
>
> Bon, j'essaye de comprendre à partir des infos fragmentaires que tu nous
> livres. J'imagine que tu essayes de communiquer entre deux réseaux
> NATés. J'aboutis au schéma ci-dessous (désolé pour les lignes trop
> longues). Tu peux le compléter et corriger. Les paquets qui vont du
> client vers le serveur passent par le chemin du haut. Les paquets en
> sens inverse passent par le vlan en bas :
>
> client passerelle routeur NAT1 serveur
> 144.32.52.29 144.32.52.142 172.26.2.10 82.3.201.160 192.168.0.1 192.168.0.xx
> `-- 144.32.52.0/24 --´ `-- Internet --´ `-- 192.168.0.0/24 --´ /
> `-- 144.32.0.0/16 --. /
> 144.32.196.175 172.26.2.10 --------- vlan ----------------´
> routeur NAT2
Je ne connait que tres mal le fonctionnement et schema des reseaux
Mais cela ressemble a se que je peux imaginer:
J'ai la main sur les 2 machines aux extremites (et sur le routeur NAT1
mais il n'y a que peu de choses que je puisse faire, c'est un routeur
TRENDNET) sur lesquelles il ne se passe grand chose !
Si on accepte le schema que tu proposes, peut-on essaye une manip sur le
prouver ? Eventuellement une solution !
Autre, je ne sais cela paut aider.
Depuis une autre machine (sun) : 144.32.196.246
je peux faire un traceroute 82.3.201.160, mais cela n'a pas l'air
d'aboutir sur 82.3.201.160 (rien dans le log).
Voici la trace et le netstat:
traceroute to 82.3.201.160 (82.3.201.160), 30 hops max, 40 byte packets
1 144.32.196.1 (144.32.196.1) 0.454 ms 0.293 ms 0.251 ms
2 csvrsdr2 (144.32.129.98) 0.357 ms 0.318 ms 0.263 ms
3 sentry3b-x (144.32.142.111) 0.791 ms 1.079 ms 0.768 ms
4 194.81.1.2 (194.81.1.2) 1.599 ms 1.855 ms 2.083 ms
5 so-1-1-0.leed-sbr1.ja.net (146.97.42.25) 2.524 ms 2.275 ms 2.028 ms
6 so-2-2-0.lond-sbr4.ja.net (146.97.33.30) 6.574 ms 6.547 ms 6.738 ms
7 po1-0.lond-sbr6.ja.net (146.97.33.14) 7.143 ms 6.701 ms 6.590 ms
8 tele-ic-1-ge-100-207.inet.ntl.com (212.250.14.33) 6.673 ms 7.295 ms
7.144 ms
9 nth-bb-b-as0-0.inet.ntl.com (62.253.184.1) 12.318 ms 8.729 ms 9.036
ms
10 lee-bb-a-so-010-0.inet.ntl.com (62.253.185.102) 12.935 ms 12.416 ms
12.139 ms
11 leed-t3core-1a-so-000-0.inet.ntl.com (213.105.175.66) 12.976 ms
13.917 ms 12.769 ms
12 * * *
13 ubr01york-ge01.inet.ntl.com (80.0.54.58) 21.747 ms 22.817 ms 22.409
ms
14 * * *
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ---------- ---------
172.26.2.10 144.32.196.109 UGHD 1 1
144.32.196.0 144.32.196.246 U 1 1914 ge0:5
224.0.0.0 144.32.196.246 U 1 0 ge0:5
default 144.32.196.1 UG 1 189410
127.0.0.1 127.0.0.1 UH 3 974 lo0:5
>
> Si c'est bien ça, je peux imaginer le scénario suivant :
> - client envoie une requête (en fait un SYN) à NAT1 (82.3.201.160:22) ;
> - NAT1 le forwarde au serveur ;
> - le serveur envoie la réponse par le vlan ;
> - NAT2 change l'adresse source pour mettre la sienne (144.32.196.175)
> et forwarde la réponse au client ;
> - le client voit une réponse venant d'une adresse IP qui n'est pas
> celle à laquelle il a envoyé la requête.
>
> Voilà, c'est juste une hypothèse que je livre à ta réflexion. Pour aller
> plus loin il faudrait savoir aussi ce que font NAT1 et NAT2, sur quelles
> machines tu peux faire tourner un sniffer...
>
> Ciao,
>
> Edgar.
>
>
>
--
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Patrick Dupré pd520@???
University of York Department of Chemistry
Heslington, York YO10 5DD United Kingdom
Phone: +44-(0)-1904-434384 Fax: +44-(0)-1904-432516
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
