Traceroute ICMP

Mit "Ping" überprüfen sie generell die Erreichbarkeit einer Gegenstelle, wenn nicht eine Firewall die verwendeten Pakete behindert. Mit "TraceRoute" können Sie aber auch den Weg der Pakete vom Absender zum Ziel erfassen. Wobei diese Aussage zu relativieren ist. Diese Seite beschreibt die Funktion und Einschränkungen von Traceroute.

Funktionsweise

Das klassische "PING"-Kommando sendet ein Paket an die Gegenstelle und wartet auf die Antwort. Die Daten werden über das IPv4 oder IPv6-Protokoll (Layer3) übertragen. Auf OSI-Layer4 kommt aber bei Windows nicht eine gesicherte TCP-Verbindung mit Ports oder eine ungesicherte UDP-Verbindung zum Einsatz sondern das Protokoll ICMP (Internet Control Message Protocol). Bei ICMP gibt es keine Ports o.ä. und neben dem ICMP ECHO, der von Ping genutzt wird, wird ICMP auch für andere Benachrichtigungen genutzt, z.B. wenn ein Port nicht Erreichbar ist (3 = Destination Unreachable) oder Pakete zu lange unterwegs sind (11 = Time Exceeded) und einige mehr. Selbst Tracert hat einen eigenen Typ (30).

Es wird also nicht nur ein Paket mit einem langen TTL gesendet auf das dann viele Stationen "antworten würden. Der Sender schickt gleich mehrere Pakete mit einem aufsteigenden TTL auf die Reise und wertet die "ICMP not Reachable" aus.

Genauso können Sie das dann auch in Wireshark nachvollziehen. Sie sehen hier aber, dass ein Windows Tracert jedes Paket dreimal sendet:

Bei diesem Ansatz gibt es aber drei Einschränkungen:

  • Redundante Wege sind nicht eindeutig
    Der Absender kann nicht den Weg vorgeben und da das Internet ja ein "vermaschtes" Netzwerk ist, ist es zwar wahrscheinlich, dass ein Paket zum gleichen Ziel auch immer den gleichen Weg nimmt aber es ist nicht garantiert. Es gibt sogar Programme, die ganz viele ICMP-Pakete absenden um genau das zu ermitteln. Das sieht dann wie folgt aus

    Siehe auch End2End-Ping
  • ICMP ist geblockt
    PING ist ein essentielles Mittel um zu sehen, ob das IP-Routing korrekt ist. Dennoch gibt es immer noch Firewalls, die ICMP blockieren oder verfälschen. Man kann mit ausreichender Menge an Pings natürlich schon versuchen eine Karte der Netzwerke, Router und sogar erreichbarer Endpunkte zu erstellen, die man dann weiter untersuchen könnte. Das kann man so sehen, aber nur weil es keine Straßenschilder gibt, ist das noch lange kein Schutz gegen Einbrecher. Dennoch sind die Daten hier nicht immer zuverlässig, wie sie hier sehen können.

    Natürlich kann ich Outlook Online nutzen, auch wenn der Traceroute (grün) mit Aussetzern kämpft. Interessant auch, dass der vierte Hop mit zwar ein "ICMP TTL Exceeded" sendet aber er auf einen direkten PING nicht antwortet.
  • Keine Diensterreichbarkeit
    Sie habe aber auch schon gesehen, dass eine mangelnde Erreichbarkeit per ICMP nicht bedeutet, dass der Service selbst nicht erreichbar ist.
  • QoS
    Und natürlich hat ein ICMP-Paket nicht die gleiche QoS-Klasse wie ein VoIP oder HTTP-Paket. Insofern kann ein ICMP auch nicht sinnvoll für eine Bandbreitenmessung oder Durchsatz-Messung herangezogen werden.

Das klassische Traceroute unter Windows ist also ein Werkzeug, dessen Ergebnisse aber mit Vorbehalt zu bewerten sind.

Es gibt leistungsfähigere Programme wie Visual TraceRoute von IPSwitch, die den Weg und die Laufzeiten schön grafisch aufzeigen:

Tracert mit UDP/TCP

Ein Traceroute unter Unix nutzt hingegen UDP mit einem beliebigen Port, der vermutlich nicht erreichbar ist. Auch hier erwartet das absendende Traceroute die Rückantworten in Form von "ICMP TTL Expired" oder vom Ziel-Host dann ein "ICMP not reachable", wenn auf dem angesprochenen Port niemand lauscht.

An einem T-DSL-Anschluss habe ich ein recht seltsames Verhalten gesehen. Beim Traceroute kam nach der Fritz!Box keine Antwort vom nächsten Hop. Erst der dritte Hop liefert wieder eine Antwort:

#

Das kann ja durchaus gewollt sein, dass ein Router nicht auf einen ICMP-Request reagiert. Also habe ich mal schnell ein UDP-Paket mit einem aufsteigenden TTL versendet:

$udpClient = new-Object system.Net.Sockets.Udpclient($sourceudpport) 
[string]$buffer = "SendUDP Message by msxfaq"
[int]$remoteudpport=3478
[string]$remoteip = "13.107.8.2"
$byteBuffer = [System.Text.Encoding]::ASCII.GetBytes($Buffer)

1..10 | %{
   $udpclient.ttl = $_;`
    start-sleep -Milliseconds 400; `
   $sentbytes = $udpClient.Send($byteBuffer, $byteBuffer.length, $remoteip, $remoteudpport)`
} 

Aber selbst hier war zu sehen, dass der nächste Hop nach der Fritz!Box keinerlei Reaktion liefert. Er meldet also nicht einmal ein TTL-Exceeded

 

Das ist dabei schon etwas bedenklich, so einen Absender im unklaren zu lassen. Sagt die RFC 1812 dazu doch:

RFC 1812 : 4.3.3.1 Destination Unreachable
...A router MUST generate a Time Exceeded message Code 0 (In Transit) when it discards a packet due to an expired TTL field. A router MAY have a per-interface option to disable origination of these messages on that interface, but that option MUST default to allowing the messages to be originated.
Quelle: RFC 1812 Requirements for IP Version 4 Routers https://www.ietf.org/rfc/rfc1812.txt

RFC 1812 : 5.3.1 Time to Live (TTL)
If the TTL is reduced to zero (or less), the packet MUST be discarded, and if the destination is not a multicast address the router MUST send an ICMP Time Exceeded message, Code 0 (TTL Exceeded in Transit) message to the source
Quelle: RFC 1812 Requirements for IP Version 4 Routers https://www.ietf.org/rfc/rfc1812.txt

Das Verhalten ist zumindest nicht sauber aber im Regelfall sollte es ihren Betrieb nicht stören. Sie können nur ihrem Provider nicht etwas genauer auf die Finger schauen, wie er die Pakete routet und wie schnell Teilstrecken sind. Vielleicht ist es dem Provider peinlich, dass schon auf den ersten drei Hops über 20ms vergehen.

Es gibt sogar Tools, die TCP-Ports nutzen, z.B. 80/TCP oder 443/TCP und hoffen damit nicht gleich an Firewalls hängen zu bleiben. Allerdings sind all diese Tools natürlich nicht über einen HTTP-Proxy oder SOCKS-Proxy zu nutzen. Zudem sind die Ergebnisse auch hier nicht immer zuverlässig, da auf ein ausgehendes UDP/TCP Paket ein ICMP-Paket zurück kommt. Auch hier hängen Sie natürlich von der Mitarbeit der Zwischenstationen ab.

Hinweis
Per PowerShell u.a. kann ich mit UDP problemlos einen TTL vorgeben. Bei TCP gibt es das Property auch aber anscheinend ignoriert dies der TCP-Stack, denn ich bekomme keinen Fehler aber Wireshark zeigt klar, dass der TTL nicht angepasst wurde.

Weitere Links