Czasem mamy sytuacje, gdy klient płacze, że jego zdaniem jakiś tam port jest zablokowany. Zwykle usłyszy, iż ma sobie sprawdzić własne ustawienia firewall gdyż u nas takowych blokad niema.
A co w przypadku, gdy blokadę ma założony nasz dostawca? Wtedy sprawa się trochę komplikuje, należy bawić się tcpdumpem generować pakiety z innych sieci itp.
Można to sprawdzić znacznie prościej, mianowicie przy pomocy programu tcptraceroute, który trasuje drogę pakietu przy pomocy pakietów TCP ze zdefiniowanym portem docelowym.
Wiec do dzieła, w Debianie:
apt-get install tcptraceroute
Teraz możemy przystąpić do testu:
# tcptraceroute wp.pl
Selected device eth0, address 213.227.72.110, port 40978 for outgoing packets
Tracing the path to wp.pl (212.77.100.101) on TCP port 80 (www), 30 hops max
1 ck-gw–z-ZA-ATM.gl.digi.pl (213.227.72.157) 1.944 ms 3.944 ms 11.346 ms
2 * * *
3 G-CK-r2-rc.silweb.pl (157.158.254.163) 14.913 ms 19.941 ms 15.468 ms
4 K-PSE-r2-rc.SILWEB.PL (157.158.254.166) 10.234 ms 10.345 ms 5.898 ms
5 * * *
6 ci-wp-rtr.wp.pl (153.19.102.1) 22.658 ms 20.737 ms 22.352 ms
7 zew.rtrd2.adm.wp-sa.pl (212.77.105.29) 22.787 ms 22.823 ms 26.751 ms
8 www.wp.pl (212.77.100.101) [open] 27.452 ms 22.194 ms 20.748 ms
Jak widać do wp.pl port 80 dociera bez żadnego problemu.
Sprawdźmy port zgłaszany przez klienta:
#tcptraceroute wp.pl 139 -w 1
Selected device eth0, address 213.227.72.110, port 40988 for outgoing packets
Tracing the path to wp.pl (212.77.100.101) on TCP port 139 (netbios-ssn), 30 hops max
1 ck-gw–z-ZA-ATM.gl.digi.pl (213.227.72.157) 4.063 ms !A 6.858 ms !A 1.993 ms !A
Jak widać port 139 blokuje nasz dostawca (test wykonany z routera brzegowego). Co prawda ten port powinien każdy blokować, ale do testów się nadał.
Jako iż dodatkowo widzimy czas dostępu pakietów to bardzo łatwo możemy także określić czy jakiś port nie jest celowo ograniczany po drodze. Np. celem spowolnienie działania programów p2p.