Problema traceroute/mtr

MembruAnonim, pe 15 noiembrie 2018 - 13:57, a scris:

Ok. Dar de ce se comporta diferit accest router cand trasez din exterior ip-ul xx.xx.xx.100 fata de ip-ul meu xx.xx.xx.101?
Ruta e aceeasi.
De aceea intrebam de hops 5 (???) din a doua trasare.

LE. Am inteles ce vrei sa spui, Posibil ca acel router sa nu fie folosit cand pack merge catre xx.100

Totusi problema ramane.

Edited by Xpicolo, 15 November 2018 - 14:11.

Xpicolo, pe 15 noiembrie 2018 - 14:07, a scris:

E folosit. Doar anunta niste agegate nu anunta /32-uri. O sa fac niste teste cand ajung acasa unde am conexiune de la RDS.

Am testat si la mine nu se manifesta situatia de mai sus:

HOST: Timberwolf				  Loss%   Snt   Last   AVG  Best  Wrst StDev
  1.|-- 192.168.100.1			 40.0%	10	0.4   0.4   0.3   0.5   0.0
  2.|-- 10.0.0.1				  40.0%	10	1.1   1.1   0.9   1.7   0.3
  3.|-- 172.19.209.1			   0.0%	10	1.2   1.2   1.0   1.7   0.2
  4.|-- 10.220.132.8			   0.0%	10   16.4  16.8  16.4  17.2   0.2
  5.|-- 213.154.130.234			0.0%	10   36.1  45.7  36.1  57.0   7.1
  6.|-- 74.125.242.225			 0.0%	10   15.4  15.2  14.8  15.5   0.2
  7.|-- 72.14.239.195			  0.0%	10   16.5  16.7  16.3  17.2   0.3
  8.|-- 172.217.16.110			 0.0%	10   17.1  17.9  17.1  19.0   0.5

Eu tot am vaga impresie ca e de la MPLS ce se petrece acolo dar nu am cum sa confirm acest lucru.

ogo, pe 15 noiembrie 2018 - 09:29, a scris:

Am mai studiat putin.
Si cred ca asta se intampla:
Primul router din reteua rds modifica TTL la o valoare mare,
astfel incat celelalte rutere nu au cum sa raspunda cu ICMP TTL expires.

Ati mai intalnit asa ceva?

LE. Cam ciudat ca cineva sa fie interesat sa nu vezi prin ce echipamente treci. Nu?
Cred ca este echipamentul din hop-ul 5 cand dau trace din exterior. (din postul #17)

Edited by Xpicolo, 16 November 2018 - 08:42.

Nop. RDS nu fac astfel de operatiuni.

şi eu sunt tot pe fo de la rds... drept este ca este un ip static. dar traceroute arata normal:

traceroute to google.ro (216.58.209.163), 30 hops max, 60 byte packets
1  gateway (192.168.23.1)  1.159 ms  1.169 ms  1.227 ms
2  10.0.0.1 (10.0.0.1)  2.665 ms  2.786 ms  2.673 ms
3  * 10.30.4.129 (10.30.4.129)  4.557 ms  4.150 ms
4  static-10-220-134-188.rdsnet.ro (10.220.134.188)  9.261 ms static-10-220-128-70.rdsnet.ro (10.220.128.70)  9.218 ms static-10-220-128-64.rdsnet.ro (10.220.128.64)  8.888 ms
5  213-154-130-234.rdsnet.ro (213.154.130.234)  10.199 ms  9.049 ms  10.531 ms
6  74.125.242.241 (74.125.242.241)  9.737 ms  8.089 ms  7.837 ms
7  66.249.94.123 (66.249.94.123)  9.197 ms  9.551 ms  7.969 ms
8  bud02s21-in-f163.1e100.net (216.58.209.163)  10.216 ms  10.450 ms  10.126 ms

Am pus tcpdump -vvv intr-o alta fereastra. Asa arata un mtr -r -c 1 google.com in tcpdump.

10:53:52.132746 IP ttl 1   proto ICMP 192.168.0.233 > prg02s12-in-f14.1e100.net: ICMP echo request
10:53:52.133451 IP ttl 128 proto ICMP 192.168.0.1 > 192.168.0.233: ICMP time exceeded

10:53:52.232847 IP ttl 2   proto ICMP 192.168.0.233 > prg02s12-in-f14.1e100.net: ICMP echo request
10:53:52.249739 IP ttl 128 proto ICMP prg02s12-in-f14.1e100.net > 192.168.0.233: ICMP echo reply

10:53:52.332950 IP ttl 3   proto ICMP 192.168.0.233 > prg02s12-in-f14.1e100.net: ICMP echo request
10:53:52.351632 IP ttl 128 proto ICMP prg02s12-in-f14.1e100.net > 192.168.0.233: ICMP echo reply

Eu sunt 192.168.0.233 iar 192.168.0.1 este routerul Netis WF2419 din locatie.
Interesant, nu?

Dupa cum am spus e ceva MPLS implicat acolo dar nu stiu de ce nu apar routerele de border ale celor de operatori, RDS si Google in trace.

LE: Pe IPv6 se comporta la fel?

PS: In ce zona a tarii esti? Ca  in Bucuresti nu se manifesta acest comportament cel putin pe zona in care ma aflu eu.

In Pitesti este IP-ul.
Nu am cum sa testez V6.
Uite ce test am mai facut:

In alta locatie (IP2) din tara am dat tcpdump pentru pack care vin de la IP1 (cu problema).

Din locatia cu IP1 am dat tcptraceroute  IP2. (tcp pentru ca nu pot sa trec cu ICMP prin routerul din locatia IP2).
Packetele ajung cu TTL=125.

apoi am dat tot din IP1 tcptraceroute -f 30 IP2 ( ttl initial 30)
Packetele ajung tot cu TTL=125.

Nu cred ca este MPLS implicat.
Eu zic ca sigur este modificare de TTL la primul router provider: orice TTL initial pun, la destinatie am TTL= 125. (banuiesc ca 128 pune routerul pricinos, si se scad inca 3 hopuri pina la IP2).
(125 in cazul in care am facut tcpdump in IP2 , cand am ales alta destinatie si am pus dump acolo am de exemplu mereu TTL=122)

Edited by Xpicolo, 17 November 2018 - 12:22.

MembruAnonim, pe 17 noiembrie 2018 - 11:41, a scris:

Și la mine pierde pachete ICMP imediat după ce iese din Kaon. Am și schimbat cablurile degeaba.

KyKyKyKy, pe 17 noiembrie 2018 - 12:02, a scris:

Nu cred are legatura cu problema expusa.
Am explicat mai sus. La mine nu apar stelute * * * la hops intermediare sau packete pierdute.

Edited by Xpicolo, 17 November 2018 - 12:20.

@Xpicolo: Da-mi pe PM IP-ul tau sa vad daca pot face niste verificari. Sigur nu e de la RDS, nu au de ce sa modifice TTL la pachetele clientilor.  Doar daca e ceva wrong pe un router.

Şi eu zic că undeva este o prb. cu un router.
Investigaţia este una academică doar atâta vreme cât nu afectează cu nimic viteza conexiunii...

Nu pare sa afecteaze functionarea internetului.
Poate doar daca incerc sa dau de un IP inexistent (rutat gresit de fapt) iar pe traseu abia dupa 128 de hops, un router va face drop la packet si va trimite ICMP time exceeded ....

La mine s-a cam terminat stiinta.

Me bad. Dap pare ca e vorba de un echipament care modifica TTL-ul la ceva != de ce e setat de catre aplicatie / host. Posibil sa fie ceva eronat pe ONT daca e folosit ca si CPE sau pe GW-ul din LAN:
Traceroute in dns google:

┌(ghost)─(Timberwolf)─(4.19.2-arch1-1-ARCH)
└─(~)─(3 files, 160KB)─ $ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1  google-public-dns-a.google.com (8.8.8.8)  14.082 ms  14.746 ms  15.193 ms

Regula iptables care modifica TTL la 128 daca destinatia este dns google:

Chain POSTROUTING (policy ACCEPT 67 packets, 7578 bytes)
pkts bytes target	 prot opt in	 out	 source			   destination		
   20  1296 TTL		all  --  *	  *	   0.0.0.0/0			8.8.8.8			  TTL set to 128

tcpdump laptop, test facut cu modificarea TTL-ului pe router si destinatie 8.8.4.4:

2018-11-18 14:23:44.928289 IP (tos 0x0, ttl 6, id 7388, offset 0, flags [none], proto UDP (17), length 60)
	192.168.100.3.53117 > 8.8.4.4.33449: [udp sum ok] UDP, length 32
2018-11-18 14:23:44.939914 IP (tos 0x4, ttl 121, id 52813, offset 0, flags [none], proto ICMP (1), length 88)
	8.8.4.4 > 192.168.100.3: ICMP 8.8.4.4 udp port 33436 unreachable, length 68
		IP (tos 0x80, ttl 248, id 7375, offset 0, flags [none], proto UDP (17), length 60)
	192.168.100.3.39810 > 8.8.4.4.33436: [udp sum ok] UDP, length 32

Scuze, aveam impresia ca e de la MPLS desi nu intelegeam de ce se comporta cum se comporta. Insa da e de la TTL. Ceva modifica TTL-ul, intrebarea este cum e topologia in locatie? ONT RDS - router local - PC / laptop / server? sau ONT RDS CPE - PC / laptop / server?

Daca e un router in locatie in afara de ONT-ul RDS atunci acel router modifica TTL-ul la pachete.
Trace in 8.8.8.8

┌(ghost)─(Timberwolf)─(4.19.2-arch1-1-ARCH)
└─(~)─(3 files, 160KB)─ $ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1  _gateway (192.168.100.1)  1.092 ms  0.974 ms  0.919 ms
2  google-public-dns-a.google.com (8.8.8.8)  15.739 ms  14.661 ms  15.053 ms

Firewall pe laptop:

┌(ghost)─(Timberwolf)─(4.19.2-arch1-1-ARCH)
└─(~)─(3 files, 160KB)─ $ sudo iptables -t mangle -vnL
Chain PREROUTING (policy ACCEPT 79 packets, 7741 bytes)
pkts bytes target	 prot opt in	 out	 source			   destination		
	0	 0 DROP	   all  --  *	  *	   0.0.0.0/0			0.0.0.0/0			ctstate INVALID
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			tcp flags:!0x17/0x02 ctstate NEW
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			ctstate NEW tcpmss match !536:65535
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			tcp flags:0x3F/0x00
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			tcp flags:0x03/0x03
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			tcp flags:0x06/0x06
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			tcp flags:0x03/0x03
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			tcp flags:0x05/0x05
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			tcp flags:0x11/0x01
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			tcp flags:0x30/0x20
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			tcp flags:0x11/0x01
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			tcp flags:0x18/0x08
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			tcp flags:0x3F/0x3F
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			tcp flags:0x3F/0x00
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			tcp flags:0x3F/0x29
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			tcp flags:0x3F/0x2B
	0	 0 DROP	   tcp  --  *	  *	   0.0.0.0/0			0.0.0.0/0			tcp flags:0x3F/0x37
	0	 0 DROP	   all  -f  *	  *	   0.0.0.0/0			0.0.0.0/0		  
Chain INPUT (policy ACCEPT 79 packets, 7741 bytes)
pkts bytes target	 prot opt in	 out	 source			   destination		
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target	 prot opt in	 out	 source			   destination		
Chain OUTPUT (policy ACCEPT 99 packets, 14223 bytes)
pkts bytes target	 prot opt in	 out	 source			   destination		
Chain POSTROUTING (policy ACCEPT 99 packets, 14223 bytes)
pkts bytes target	 prot opt in	 out	 source			   destination

Firewall pe router:

root@Takeyuuki:~# iptables -vnL -t mangle
Chain PREROUTING (policy ACCEPT 199 packets, 23087 bytes)
pkts bytes target	 prot opt in	 out	 source			   destination		
Chain INPUT (policy ACCEPT 40 packets, 2864 bytes)
pkts bytes target	 prot opt in	 out	 source			   destination		
Chain FORWARD (policy ACCEPT 150 packets, 19683 bytes)
pkts bytes target	 prot opt in	 out	 source			   destination		
	0	 0 TCPMSS	 tcp  --  *	  eth1.2  0.0.0.0/0			0.0.0.0/0			tcp flags:0x06/0x02 /* !fw3: Zone wan MTU fixing */ TCPMSS clamp to PMTU
   62  3720 TCPMSS	 tcp  --  *	  pppoe-wan  0.0.0.0/0			0.0.0.0/0			tcp flags:0x06/0x02 /* !fw3: Zone wan MTU fixing */ TCPMSS clamp to PMTU
Chain OUTPUT (policy ACCEPT 38 packets, 5095 bytes)
pkts bytes target	 prot opt in	 out	 source			   destination		
Chain POSTROUTING (policy ACCEPT 188 packets, 24778 bytes)
pkts bytes target	 prot opt in	 out	 source			   destination		
   95 14085 TTL		all  --  *	  pppoe-wan  0.0.0.0/0			0.0.0.0/0			TTL set to 255

Se vede ultima linie care modifica TTL-ul la pachetele ce ies pe interfata pppoe-wan la 255. De asemenea mai sus trace-ul este identic ca al tau, adica vad doar router-ul meu si ultimul hop.