Cristian Grigoriu wrote:
>
>>un tcpdump pe masina 72.100 ce zice ?
>
> > in special pachetele generate ar fi interesante.
>
> Pe masina 72.100 nu se poate face tcpdump in schimb se poate snifa
> traficul inspre/de la 72.100. Acolo se vad toate pachetele dinspre 1.30
> atat UDP cat si ICMP dar nici un pachet spre 1.30 (cum era si normal).
> Am facut asta mai devreme, din pacate nu mai am dump-urile. Credeti-ma
> pe cuvant.
>
> Un tcpdump pe 1.30 arata asa (am pastrat fragmente relevante):
>
> 17:45:15.546014 192.168.1.30 > 172.16.72.100: icmp: echo request (ttl 5,
> id 24082, len 38)
> 17:45:15.596916 192.168.1.30 > 172.16.72.100: icmp: echo request (ttl 5,
> id 24083, len 38)
> 17:45:15.650843 192.168.1.30 > 172.16.72.100: icmp: echo request (ttl 5,
> id 24084, len 38)
> 17:45:15.706386 192.168.1.30 > 172.16.72.100: icmp: echo request (ttl 6,
> id 24085, len 38)
> 17:45:15.764137 172.16.72.100 > 192.168.1.30: icmp: time exceeded
> in-transit [tos 0x80] (ttl 250, id 21778, len 56)
> 17:45:15.764625 192.168.1.30 > 172.16.72.100: icmp: echo request (ttl 6,
> id 24086, len 38)
> 17:45:15.814686 172.16.72.100 > 192.168.1.30: icmp: time exceeded
> in-transit [tos 0x80] (ttl 250, id 21779, len 56)
> 17:45:15.814761 192.168.1.30 > 172.16.72.100: icmp: echo request (ttl 6,
> id 24087, len 38)
> 17:45:15.880483 172.16.72.100 > 192.168.1.30: icmp: time exceeded
> in-transit [tos 0x80] (ttl 250, id 21783, len 56)
>
>
> 17:45:17.842414 192.168.1.30 > 172.16.72.100: icmp: echo request (ttl
> 12, id 24105, len 38)
> 17:45:17.930584 172.16.72.100 > 192.168.1.30: icmp: time exceeded
> in-transit [tos 0x80] (ttl 244, id 40455, len 56)
> 17:45:17.930655 192.168.1.30 > 172.16.72.100: icmp: echo request (ttl
> 13, id 24106, len 38)
> 17:45:22.930054 192.168.1.30 > 172.16.72.100: icmp: echo request (ttl
> 13, id 24107, len 38)
> 17:45:27.930057 192.168.1.30 > 172.16.72.100: icmp: echo request (ttl
> 13, id 24108, len 38)
> 17:45:32.930070 192.168.1.30 > 172.16.72.100: icmp: echo request (ttl
> 14, id 24109, len 38)
> 17:45:37.930056 192.168.1.30 > 172.16.72.100: icmp: echo request (ttl
> 14, id 24110, len 38)
> 17:45:42.930057 192.168.1.30 > 172.16.72.100: icmp: echo request (ttl
> 14, id 24111, len 38)
>
>
>>># ping 172.16.72.100
>>>PING 172.16.72.100 (172.16.72.100) from 192.168.1.30 : 56(84) bytes of data.
>>>
>>>--- 172.16.72.100 ping statistics ---
>>>7 packets transmitted, 0 received, 100% loss, time 6015ms
>>>
>>>
>>
>>$IPT -A INPUT -p icmp --icmp-type echo-reply -i $EXTERNAL_INTERFACE1 -j DROP
>>$IPT -A INPUT -p icmp --icmp-type time-exceeded -i $EXTERNAL_INTERFACE1
>>-j ACCEPT
>>si o sa ai traceroute fara a avea ping reply.
>
>
> Corect, am uitat sa precizez ca nu exista nici un fel de filtrare pe
> 72.10. Din reteaua 172.16.72.0, 72.100 raspunde la ping.
>
din fragmentul de tcpdump reiese ca la hop-ul 6 raspunde un "ceva", de
la 12 incolo nu.daca interpretez corect, probabil la hopul 6 e ultimul
router care stie sa raspunda.
partea cu snifatul traficului pe parcurs e frumoasa, dar nu intotdeauna
relevanta. ma interesa ce se intimpla exact pe interfata de iesire a lui
72.100. fara un tcpdump facut macar pe o masina din reteaua 172.16.72.0
care sa fie configurata (din pct de vedere al rutarii si, pe cit
posibil, al firewall-ului) identic cu 72.100, recunosc ca nu imi dau
seama de ce ai reply la mtr. in esenta mtr nu face decit sa genereze
icmp-echo-request cu TTL variabil si apoi sa interpreteze si contorizeze
raspunsurile primite.
singura explicatie care imi mai trece prin cap ar fi un arp proxy sau
ceva de genul asta, facut pe routerul de deasupra.
ai mai putea incerca in loc de mtr si ceva de genul
for i in `seq 1 15` '; do ping -c1 -t $i 172.16.72.100; done
eventual variind si lungimea pachetului (optiunea -s la ping, respectiv
-p la mtr ) . poate se fac totusi niste filtrari ale pachetelor ICMP, in
functie de lungime. reminiscinte de la virusii de win...
--
If everything seems to be going well, you have obviously overlooked
something.
---
Detalii despre listele noastre de mail: http://www.lug.ro/
