[mightythor]

kuna turvalisuse huvides on UDP ja ICMP ECHO paketid paljudes tulemüürides keelatud, siis huvi pärast tahtsin näha teekonda enda arvutist aadressi 212.7.7.132 juurde. Sain sellise tulemuse:

[airm]

http://en.wikipedia.org/wiki/Internet_Control_Message_Protocol

ja selle "alam-tyype" ja neid tyype saab eraldi keelata iptablesiga näiteks.
Sellelt lingilt näed neid messageid ja tyype.

[mightythor]

[Andrus Luht]

Vastus on ju sul esimeses kirjas:

[Dogbert]

Huvitav, mul vastavad tcptraceroute kasutamisel kõik ruuterid, vähemalt kui Eesti aadressidega piirdun. Ometi on väga vähestel neist TCP port 80 lahti, kui üldse. Midagi selles teoorias ei klapi.

[airm]

ehk on see selline värk, et kontrollid lõppjaama 80 porti, aga teekonda vaatad ikkagi icmp -ga

[kpihus]

tcptraceroute saadab syn paketi ja ootab syn ack vastust. Selleks, et vahepeale masin syn ackiga vastaks peab tal input olema lubatud, kui input on keelatud, siis saadakse vastu reset, või halvemal juhul lihtsalt pakett kdropitakse ära. See et tcptraceroute vastust ei saa aga tegelikult liiklus käib sealt läbi ei ole jällegi argument, sest forward ahela paketid ei läbi input ahelat ja vastupidi. Vähemasti mitte linuxi ja iptablesiga.

[pppd]

tcptraceroute erineb oma "tavalistest" alternatiividest tegelikult ainult sellepoolest, et kasutab proovipakettidena TCP SYN'e, seda siis ICMP Echo või UDP mis-iganes-porti asemel, kogu TTL-iga mängimise skeem on aga täiesti sama (mis ongi tegelikult traceroute aluseks).
Nüüd tuletame natuke põhitõdesid meelde - traceroute saadab sihtmärgi suunas järjest suureneva TTL-iga proovipakette, kui paketil tee peal TTL otsa saab (iga ruuter võtab sellest teatavasti ühe maha), siis peaks see ruuter kelle käes TTL otsa sai, vastama paketi saatjale ICMP TTL exceeded teatega. Suur osa ruutereid on aga konfitud ICMP-d mitte saatma (ning just see ongi ka tava-traceroute väljundisse tärnide tekkimise põhjuseks, mitte mingi tuim ICMP-filtreerimine kuskil tee peal) ning nendelt ei jõua saatjani mitte midagi, seega vahepealsete ruuterite avastamise osas on tcptraceroute täiesti võrdväärne tavalise traceroutega. Alles siis kui proovipaketid jõuavad sihtmärgini, tuleb mängu üks tcptraceroute eripäradest - kui ICMP Echole või suvalisse porti saadetud UDP-le (tava-traceroute proovipaketid!) ei pruugi sihtmärk mitte midagi vastata (serveri teenusteprofiiliga mittesobivad paketid lihtsalt dropitakse vaikselt), siis mingi toimiva teenuse porti saadetud SYN-i peale see server väga tõenäoliselt siiski reageerib ning selle järgi saab proovija teada, et jõuti sihtmärgini ning võib traceroute lõpetada, tava-traceroute tiksusks sellisel juhul lihtsalt vaikselt piirini (tavaliselt 30) ning proovija ei saakski kunagi teada, mitme hopi kaugusel sihtmärk tegelikult asub. Pluss muidugi veel see nüanss et kui teepeal tõepoolest on mingi tulemüür mis väljuvat ICMP'd või kahtlaste portidega UDP-liiklust filtreerib, siis TCP SYN'id mingisse tuntud porti pääsevad tõenäolisemalt läbi. Vahepealsete ruuterite peal jooksvad või mittejooksvad teenused ei puutu üldse asjasse, kuna proovipaketid pole nendele adresseeritud siis ruuterid nendele ei reageeri, vaid teevad seda milleks nad mõeldud on - saadavad need paketid edasi sinna suunas, kus nende arvates sihtmärk asub või siis vastavad, et nad ei saa paketti enam millegipärast edasi saata. Või siis ei vasta.