Ja, es ist durchaus möglich, dass Ihre Firewall den Erfolg der Traceroute blockiert. Um zu verstehen, warum dies fehlschlägt, konsultieren Sie am besten die tracerouteManpage.
Auszug
Dieses Programm versucht, die Route zu verfolgen, der ein IP-Paket zu einem Internet-Host folgen würde, indem es Testpakete mit einem kleinen ttl (Time to Live) startet und dann auf eine ICMP-Antwort von einem Gateway wartet, bei der die Zeit überschritten wurde.
Wir starten unsere Sonden mit einem ttl von eins und erhöhen sie um eins, bis wir einen ICMP- "Port nicht erreichbar" (oder TCP-Reset) erhalten, was bedeutet, dass wir zum "Host" gelangen oder ein Maximum erreichen (standardmäßig 30 Hops).
Bei jeder ttl-Einstellung werden (standardmäßig) drei Sonden gesendet, und es wird eine Zeile gedruckt, in der ttl, die Adresse des Gateways und die Umlaufzeit jeder Sonde angegeben sind. Der Adresse können auf Anfrage zusätzliche Informationen folgen. Wenn die Sondenantworten von verschiedenen Gateways stammen, wird die Adresse jedes antwortenden Systems gedruckt. Wenn innerhalb von 5,0 Sekunden keine Antwort erfolgt (Standard), wird für diese Sonde ein "*" (Sternchen) gedruckt.
Die Sternchen, die Sie sehen, sind Server, über die Ihre Pakete weitergeleitet werden und deren Zeitüberschreitung (5,0+ Sekunden) abläuft. Daher wird traceroutestandardmäßig das gedruckt *.
Die andere Sache, die nicht traceroutefunktioniert, ist, wenn ein Server / Router auf dem Weg so konfiguriert ist, dass er nicht auf ICMP-Pakete (auch bekannt als Ping-Pakete) antwortet. Ohne auf Pings zu antworten, schlägt der Trick von `traceroute, jeden Server durch Inkrementieren der TTL (Time To Live) für jedes Paket, das an das tatsächliche Ziel gesendet wird, zu induzieren, fehl.
HINWEIS: Es gibt sogar eine Warnung dazu in der tracerouteManpage.
Auszug
In der modernen Netzwerkumgebung können die traditionellen Traceroute-Methoden aufgrund der weit verbreiteten Verwendung von Firewalls nicht immer angewendet werden. Solche Firewalls filtern die "unwahrscheinlichen" UDP-Ports oder sogar ICMP-Echos. Um dies zu lösen, werden einige zusätzliche Tracerouting-Methoden implementiert (einschließlich TCP), siehe LISTE DER VERFÜGBAREN METHODEN unten. Solche Methoden versuchen, ein bestimmtes Protokoll und einen bestimmten Quell- / Zielport zu verwenden, um Firewalls zu umgehen (von Firewalls nur als Start des zulässigen Typs einer Netzwerksitzung zu sehen).
Je nachdem, wie Sie es konfigurieren traceroute, werden möglicherweise ICMP-, UDP- oder sogar TCP-Pakete verwendet, um eine Antwort von den verschiedenen Systemen auszulösen, die das Routing Ihrer Pakete von Punkt A nach Punkt B übergeben.
Wieder Anhörung des tracerouteMannes Seite Beachten Sie diese 3 Möglichkeiten:
-I, --icmp
Use ICMP ECHO for probes
-T, --tcp
Use TCP SYN for probes
-U, --udp
Use UDP to particular destination port for tracerouting (instead
of increasing the port per each probe). Default port is 53 (dns).
Es gibt natürlich noch mehr, die vollständige Liste finden Sie in der LISTE DER VERFÜGBAREN METHODEN .
Was ist also mit Locken?
Wie so oft bei Grenzfirewalls wie in einem Unternehmen oder einer Universität dürfen nur Traffic-Targeting-Ports 80 (HTTP) und 443 (HTTPS) austreten. Es ist sehr wahrscheinlich, dass die ICMP ECHO_REQUEST- Pakete von der Universitäts-Firewall verworfen werden. Dies würde erklären, warum Sie die Sternchen erhalten, wenn Sie Server außerhalb des Universitätsnetzwerks erreichen.
Mit dem Austritt von Paketen über Port 80 können Sie dies traceroutenutzen und TCP über einen bestimmten Port, in diesem Fall 80, verwenden, um das zu erhalten, was Sie möchten.
Beispiel
$ sudo traceroute -T -p 80 www.google.com
traceroute to www.google.com (173.194.46.81), 30 hops max, 60 byte packets
1 byers.bubba.net (192.168.1.6) 3.265 ms 3.236 ms 3.213 ms
2 * * *
3 24.93.10.17 (24.93.10.17) 21.359 ms 35.414 ms 48.045 ms
4 rdc-72-230-153-79.wny.east.twcable.com (72.230.153.79) 48.064 ms 48.044 ms 54.523 ms
5 rdc-72-230-153-243.wny.east.twcable.com (72.230.153.243) 70.067 ms 70.013 ms 73.312 ms
6 be35.cr0.chi10.tbone.rr.com (107.14.19.104) 73.201 ms be45.cr0.chi10.tbone.rr.com (107.14.19.106) 62.289 ms be35.cr0.chi10.tbone.rr.com (107.14.19.104) 65.485 ms
7 ae0.pr1.chi10.tbone.rr.com (107.14.17.192) 62.056 ms 48.685 ms ae1.pr1.chi10.tbone.rr.com (107.14.17.194) 32.193 ms
8 * * *
9 209.85.254.130 (209.85.254.130) 42.624 ms 45.159 ms 42.777 ms
10 * * *
11 ord08s11-in-f17.1e100.net (173.194.46.81) 48.036 ms 42.543 ms 44.751 ms