Melohelyen van egy mezei NATolo gep. 2 halokartya, UPC net be, majd ezt szetoszt a belso halozatra.
Ezen a gepen epp frissitettem 3.0.0-s kernelre es arra a furcsasagra lettem figyelmes, hogy a belso halozatban levo gepek eleg erdekes dolgokat irnak ki ha traceroutolok.
tveger@szerk2:~$ traceroute index.hu
traceroute to index.hu (217.20.130.97), 30 hops max, 60 byte packets
1 sportgeza.hu (217.20.130.97) 0.069 ms 0.051 ms 0.052 ms
2 * * *
3 catv-89-135-211-237.catv.broadband.hu (89.135.211.237) 13.458 ms 14.099 ms 14.170 ms
4 catv-89-135-220-238.catv.broadband.hu (89.135.220.238) 14.633 ms 14.636 ms 14.619 ms
5 84.116.240.106 (84.116.240.106) 21.977 ms 22.168 ms 22.172 ms
6 TE-1-1.core0.interware.hu (193.188.137.25) 23.111 ms 19.677 ms 19.114 ms
7 sportgeza.hu (217.20.130.97) 19.613 ms 19.524 ms 19.478 ms
tveger@szerk2:~$
mtr ezt produkalja:
My traceroute [v0.75]
szerk2 (0.0.0.0) Thu Aug 4 13:28:49 2011
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. sportgeza.hu 95.0% 21 0.1 0.1 0.1 0.1 0.0
Lenyege, hogy a 192.168.1.1-es IP helyett rogton a cel IPt irja ki az elso helyen.
A net erdekes modon tokeletesen mukodik minden gepen a regi es az uj kernellel is.
Van erre valakinek valami otlete?
- 1888 megtekintés
Hozzászólások
Wireshark vagy tcpdump programmal érdemes lenne megnézni a forgalmat, miközben fut a traceroute.
A tcpdumpot elindíthatod úgy, hogy csak az ICMP-t figyelje:
tcpdump icmp
Kiváncsi lennék, hogy a tcpdump mit ír ki.
Szerk.: van még egy ötletem. Próbáld ki a traceroute-ot ICMP-vel is:
traceroute -I index.hu
- A hozzászóláshoz be kell jelentkezni
Wiresharkkal most nincs lehetosegem megnezni, de ICMP-vel megneztem a tracerouteot:
root@szerk3:/home/tveger# traceroute -I index.hu
traceroute to index.hu (217.20.130.97), 30 hops max, 60 byte packets
1 sportgeza.hu (217.20.130.97) 0.125 ms 0.116 ms 0.114 ms
2 catv-89-134-239-254.catv.broadband.hu (89.134.239.254) 8.346 ms 8.361 ms 8.362 ms
3 catv-89-135-211-237.catv.broadband.hu (89.135.211.237) 8.291 ms 8.639 ms 8.637 ms
4 catv-89-135-220-238.catv.broadband.hu (89.135.220.238) 9.289 ms 9.255 ms 9.264 ms
5 84.116.240.106 (84.116.240.106) 55.035 ms 55.026 ms 55.026 ms
6 TE-1-1.core0.interware.hu (193.188.137.25) 17.766 ms 16.877 ms 16.986 ms
7 sportgeza.hu (217.20.130.97) 16.944 ms 16.938 ms 18.064 ms
root@szerk3:/home/tveger#
-------------------
http://www.rtvstat.hu/ - A legtöbb magyar rádió és TV egy helyen!
- A hozzászóláshoz be kell jelentkezni
a nat-ot végző gép ping-re válaszol rendesen?:)
Ezek alapján úgy tűnik, hogy belehazudik az ip fejlécbe icmp csomagok esetében.
Ha csak ebbe sikít bele, akkor ezt leszámítva nagyobb bajok nem lesznek, ha másba is, akkor az esetleges udp csomagok bánhatják a dolgot.
De mivel ahogy nézem, csak magáról hazudik, nem valószínű, hogy bármi gond legyen belőle.
Mindenesetre érdekes feature;)
- A hozzászóláshoz be kell jelentkezni
Érdekes, így is ugyanezt csinálja.
Pedig az 1. állomás szerintem biztos, hogy a te routered, már csak az alacsony válaszidő miatt is. Így ránézésre szerintem bugos lehet a traceroute, hogy helyette az index szerverét írja ki. A tcpdumpal szerintem ez kiderülne. Amint lesz rá lehetőséged, futtasd le, kiváncsian várom az eredményt.
- A hozzászóláshoz be kell jelentkezni
Lefuttattam:
16:34:21.913574 IP 192.168.1.11.48597 > 213.46.246.51.53: 63984+ A? index.hu. (26)
16:34:21.913582 IP 192.168.1.11.48597 > 213.46.246.51.53: 15874+ AAAA? index.hu. (26)
16:34:21.930817 IP 213.46.246.51.53 > 192.168.1.11.48597: 63984 1/0/0 A 217.20.130.97 (42)
16:34:21.930839 IP 213.46.246.51.53 > 192.168.1.11.48597: 15874 0/1/0 (78)
16:34:21.930950 IP 192.168.1.11 > 217.20.130.97: ICMP echo request, id 2094, seq 1, length 40
16:34:21.930954 IP 192.168.1.11 > 217.20.130.97: ICMP echo request, id 2094, seq 2, length 40
16:34:21.930956 IP 192.168.1.11 > 217.20.130.97: ICMP echo request, id 2094, seq 3, length 40
16:34:21.930959 IP 192.168.1.11 > 217.20.130.97: ICMP echo request, id 2094, seq 4, length 40
16:34:21.930962 IP 192.168.1.11 > 217.20.130.97: ICMP echo request, id 2094, seq 5, length 40
16:34:21.930969 IP 192.168.1.11 > 217.20.130.97: ICMP echo request, id 2094, seq 6, length 40
16:34:21.930971 IP 192.168.1.11 > 217.20.130.97: ICMP echo request, id 2094, seq 7, length 40
16:34:21.930975 IP 192.168.1.11 > 217.20.130.97: ICMP echo request, id 2094, seq 8, length 40
16:34:21.930977 IP 192.168.1.11 > 217.20.130.97: ICMP echo request, id 2094, seq 9, length 40
16:34:21.930984 IP 192.168.1.11 > 217.20.130.97: ICMP echo request, id 2094, seq 10, length 40
16:34:21.930986 IP 192.168.1.11 > 217.20.130.97: ICMP echo request, id 2094, seq 11, length 40
16:34:21.930988 IP 192.168.1.11 > 217.20.130.97: ICMP echo request, id 2094, seq 12, length 40
16:34:21.930990 IP 192.168.1.11 > 217.20.130.97: ICMP echo request, id 2094, seq 13, length 40
16:34:21.930992 IP 192.168.1.11 > 217.20.130.97: ICMP echo request, id 2094, seq 14, length 40
16:34:21.930999 IP 192.168.1.11 > 217.20.130.97: ICMP echo request, id 2094, seq 15, length 40
16:34:21.931002 IP 192.168.1.11 > 217.20.130.97: ICMP echo request, id 2094, seq 16, length 40
16:34:21.931039 IP 217.20.130.97 > 192.168.1.11: ICMP time exceeded in-transit, length 68
16:34:21.931048 IP 217.20.130.97 > 192.168.1.11: ICMP time exceeded in-transit, length 68
16:34:21.931065 IP 217.20.130.97 > 192.168.1.11: ICMP time exceeded in-transit, length 68
16:34:21.931098 IP 192.168.1.11 > 217.20.130.97: ICMP echo request, id 2094, seq 17, length 40
16:34:21.931120 IP 192.168.1.11 > 217.20.130.97: ICMP echo request, id 2094, seq 18, length 40
16:34:21.931137 IP 192.168.1.11 > 217.20.130.97: ICMP echo request, id 2094, seq 19, length 40
16:34:21.940117 IP 89.135.211.237 > 192.168.1.11: ICMP time exceeded in-transit, length 36
16:34:21.940126 IP 192.168.1.11 > 217.20.130.97: ICMP echo request, id 2094, seq 20, length 40
16:34:21.940594 IP 89.134.239.254 > 192.168.1.11: ICMP time exceeded in-transit, length 68
16:34:21.940633 IP 192.168.1.11 > 217.20.130.97: ICMP echo request, id 2094, seq 21, length 40
16:34:21.940737 IP 89.134.239.254 > 192.168.1.11: ICMP time exceeded in-transit, length 68
16:34:21.940758 IP 89.134.239.254 > 192.168.1.11: ICMP time exceeded in-transit, length 68
16:34:21.940761 IP 89.135.211.237 > 192.168.1.11: ICMP time exceeded in-transit, length 36
16:34:21.940766 IP 192.168.1.11 > 217.20.130.97: ICMP echo request, id 2094, seq 22, length 40
16:34:21.940816 IP 192.168.1.11 > 217.20.130.97: ICMP echo request, id 2094, seq 23, length 40
16:34:21.940824 IP 89.135.211.237 > 192.168.1.11: ICMP time exceeded in-transit, length 36
16:34:21.940833 IP 192.168.1.11 > 217.20.130.97: ICMP echo request, id 2094, seq 24, length 40
16:34:21.940854 IP 192.168.1.11 > 217.20.130.97: ICMP echo request, id 2094, seq 25, length 40
16:34:21.941662 IP 89.135.220.238 > 192.168.1.11: ICMP time exceeded in-transit, length 36
16:34:21.941665 IP 89.135.220.238 > 192.168.1.11: ICMP time exceeded in-transit, length 36
16:34:21.941688 IP 89.135.220.238 > 192.168.1.11: ICMP time exceeded in-transit, length 36
16:34:21.941708 IP 192.168.1.11 > 217.20.130.97: ICMP echo request, id 2094, seq 26, length 40
16:34:21.941725 IP 192.168.1.11 > 217.20.130.97: ICMP echo request, id 2094, seq 27, length 40
16:34:21.941747 IP 192.168.1.11 > 217.20.130.97: ICMP echo request, id 2094, seq 28, length 40
16:34:21.948568 IP 84.116.240.106 > 192.168.1.11: ICMP time exceeded in-transit, length 36
16:34:21.948608 IP 192.168.1.11 > 217.20.130.97: ICMP echo request, id 2094, seq 29, length 40
16:34:21.948881 IP 84.116.240.106 > 192.168.1.11: ICMP time exceeded in-transit, length 36
16:34:21.948897 IP 84.116.240.106 > 192.168.1.11: ICMP time exceeded in-transit, length 36
16:34:21.948902 IP 192.168.1.11 > 217.20.130.97: ICMP echo request, id 2094, seq 30, length 40
16:34:21.948923 IP 192.168.1.11 > 217.20.130.97: ICMP echo request, id 2094, seq 31, length 40
16:34:21.949867 IP 217.20.130.97 > 192.168.1.11: ICMP echo reply, id 2094, seq 19, length 40
16:34:21.950178 IP 193.188.137.25 > 192.168.1.11: ICMP time exceeded in-transit, length 36
16:34:21.950182 IP 193.188.137.25 > 192.168.1.11: ICMP time exceeded in-transit, length 36
16:34:21.950199 IP 193.188.137.25 > 192.168.1.11: ICMP time exceeded in-transit, length 36
16:34:21.957649 IP 217.20.130.97 > 192.168.1.11: ICMP echo reply, id 2094, seq 20, length 40
16:34:21.957667 IP 217.20.130.97 > 192.168.1.11: ICMP echo reply, id 2094, seq 21, length 40
16:34:21.957670 IP 217.20.130.97 > 192.168.1.11: ICMP echo reply, id 2094, seq 22, length 40
16:34:21.957694 IP 217.20.130.97 > 192.168.1.11: ICMP echo reply, id 2094, seq 23, length 40
16:34:21.957710 IP 217.20.130.97 > 192.168.1.11: ICMP echo reply, id 2094, seq 24, length 40
16:34:21.957725 IP 217.20.130.97 > 192.168.1.11: ICMP echo reply, id 2094, seq 25, length 40
16:34:21.961100 IP 217.20.130.97 > 192.168.1.11: ICMP echo reply, id 2094, seq 26, length 40
16:34:21.961118 IP 217.20.130.97 > 192.168.1.11: ICMP echo reply, id 2094, seq 27, length 40
16:34:21.961121 IP 217.20.130.97 > 192.168.1.11: ICMP echo reply, id 2094, seq 28, length 40
16:34:21.965589 IP 217.20.130.97 > 192.168.1.11: ICMP echo reply, id 2094, seq 29, length 40
16:34:21.965608 IP 217.20.130.97 > 192.168.1.11: ICMP echo reply, id 2094, seq 30, length 40
16:34:21.965610 IP 217.20.130.97 > 192.168.1.11: ICMP echo reply, id 2094, seq 31, length 40
Sima ping egyebkent jol mukodik a gw-re.
Ha a regi 2.6.38-as kernellel bootolok a gw-n akkor jo a traceroute.
Szerintem amugy ez barki szamara reprodukalhato, mivel otthon is ugyanez a jelenseg.
-------------------
http://www.rtvstat.hu/ - A legtöbb magyar rádió és TV egy helyen!
- A hozzászóláshoz be kell jelentkezni
Látom, hogy itt is úgy tűnik, mintha az index szerveréről jönne vissza a csomag. Mcsiv-nek van igaza, belehazudik az IP fejlécbe. De hogy miért van ez az érdekes "feature", azt nem tudom.
- A hozzászóláshoz be kell jelentkezni
Ezt találtam. Remélem, hogy hamarosan kijavítják a hibát.
- A hozzászóláshoz be kell jelentkezni
Csak miert kell elrontani valamit ha egyszer jol mukodott... :P
-------------------
http://www.rtvstat.hu/ - A legtöbb magyar rádió és TV egy helyen!
- A hozzászóláshoz be kell jelentkezni
láttam ilyet énis mostanában: valami ismeretlen tűzfal 2 gép között szűrte a forgalmat, és a SYN csomagra ICMP destination unreachable jött vissza, ahol a feladó a célgép IP-je volt, holott a request el sem jutott már hozzá, így ilyen ICMP errort se küldhetett vissza.
- A hozzászóláshoz be kell jelentkezni
de, az ICMP destination unreachable-t a legközelebbi GW küldheti neked. Az esetében ez azt takarja, hogy nem tudja hova továbbítani a csomagodat (pl a gateway másik lába elpatkolt).
Ebben az esetben a cél gép IP-je kell hogy legyen a fejlécben, hogy ne kelljen várni a default 2000ms timeout-ra, ehhez nem kötelező eljutnia a csomagnak a célgépig
- A hozzászóláshoz be kell jelentkezni
+1, ebbe én is belefutottam, tettem is vissza a régi kernelt azonnyomban.
hozzáteszem, más problémám is volt a 3.0-val, mégpedig a jelenség olyan volt, mint amikor túl nagy az MTU (kis csomagok átmentek, nagy csomagok akadoztak. ping, ssh oké, amíg web és ftp nem) a bibi csak annyi volt, hogy a béka segge alá csökkentett MTU-val is ugyanez jelentkezett.
downgrade, és újra lőn bódottá'...
- A hozzászóláshoz be kell jelentkezni
lolkernál
- A hozzászóláshoz be kell jelentkezni
Frissitettem 3.0.1-es kernelre, de a jelenseg meg mindig ugyanaz.
-------------------
http://www.rtvstat.hu/ - A legtöbb magyar rádió és TV egy helyen!
- A hozzászóláshoz be kell jelentkezni