icedream
/
its-dokumentationen
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
its-dokumentationen/02-Kittelberger_Carl_IP.md

7.9 KiB
Raw Blame History

author date title institute lang babel-lang babel-otherlangs polyglossia-lang classoption colorlinks documentclass fontsize logo mainfont papersize sansfont tables template toc header-includes
Carl Kittelberger 2018-03-01 ITS: IP und ICMP Ferdinand-von-Steinbeis Berufsschule de-DE ngerman
english
name options
german
spelling=new
oneside true report 12pt img/steinbeis.png Arial a4 Arial true template.tex true
\usepackage{xcolor}
\usepackage{fancyhdr}
\usepackage{graphicx}
\pagestyle{fancy}
\fancyhf{}
\fancyhead[L]{\large{\textit{\textbf{ITS} \ IP und ICMP}}}
\fancyhead[R]{\raisebox{-0.1\height}{\includegraphics[height=32pt]{img/steinbeis.png}}}
\fancyfoot[L]{\textcolor{gray}{Carl Kittelberger}}
\fancyfoot[R]{\textcolor{gray}{\bfseries{Seite \thepage}}}
\renewcommand{\headrulewidth}{0.4pt}
\renewcommand{\footrulewidth}{0.4pt}
\setlength\headheight{36pt}
\fancypagestyle{plain}{}
\lstset{basicstyle=\footnotesize\ttfamily,breaklines=true}
\lstset{framextopmargin=50pt}

\newpage

Analyse eines Pings

Im Folgenden wurde die IP-Adresse 8.8.8.8 als Ziel für die Pinganfragen verwendet, die untersucht werden. Die Pinganfragen wurden von einer VM mit Netzwerkbrücke auf einem Ethernetadapter durchgeführt und Wireshark wurde zur Aufzeichnung innerhalb der VM verwendet.

Im ersten Screenshot lässt sich ablesen, dass die IP-Adresse des Computers von dem die Pinganfrage verschickt wurde 192.168.188.52 lautet.

Der Typ des IP-Pakets ist als Wert 1 (ICMP) angegeben.

Im IP-Paket sind insgesamt laut Wireshark 84 Bytes enthalten, davon belegt der IP-Header 20 Bytes, die restlichen 64 Bytes sind die tatsächliche Nutzlast des IP-Pakets, die aus der ICMP-Nachricht besteht.

Die Roundtrip Time (RTT) ist der Zeitabstand zwischen Versand des Anfragepakets und Erhalten des Antwortpakets. Im Screenshot sieht man als Interval für die erste Anfrage (Pakete 1 und 2) etwa 15,05 Millisekunden.

Die Identifikationsnummern lauten laut Wireshark für das IP-Paket selbst 0x7566 (30054) und das ICMP-Paket selbst hat die Identifikationsnummern im Big-Endian-Format (BE) 3533 oder 0x0dcd bzw. im Little-Endian-Format (LE) 52493 oder 0xcd0d. Im zweiten Screenshot sieht man, dass die Identifikationsnummern für das Antwortpaket genau gleich sind. Wären diese Nummern verschieden, könnte die Antwort der Anfrage nicht mehr zugeordnet werden.

Das IP-Paket der Anfrage wurde nicht fragmentiert. Fragmentiert ist ein Paket erst dann, wenn es beim Versenden in mehrere Teile aufgespalten wurde und der entsprechende Flag für die Fragmentierung im IP-Header gesetzt wurde, was hier nicht der Fall ist (der Flag ist 0x4000 was Wireshark entsprechend als Don't fragment anzeigt).

Analyse eines fragmentierten Pings

Ping mit 2000 Bytes Inhalt

Die IP-Adressen haben sich nicht geändert.

Der IP-Header enthält als Typ ebenso noch den gleichen Wert.

Die Headergröße hat sich ebenfalls nicht verändert, aber die Größe der Nutzlast ist jetzt auf 1500 Bytes angewachsen. Die restlichen 500 Bytes finden sich in einem Folgepaket das aufgrund der Fragmentierung mitgeschickt wurde.

Die Roundtrip Time beträgt jetzt 16,93 Millisekunden (Unterschied Paket 1 zu 3).

Ping mit 3500 Bytes Inhalt

Die Änderungen sind ähnlich wie oben, außer dass die Nutzlast des ersten Pakets sich nicht mehr ändert und 1500 Bytes beträgt. Dafür ist ein weiteres Teilpaket dazugekommen, bei dem der zusätzliche Inhalt angehängt wurde.

Die Roundtrip Time beträgt jetzt 15,80 Millisekunden (Unterschied Paket 1 zu 4).

\clearpage

Analyse der Fragmentierung

In dieser Analyse scheinen Daten über 1500 Bytes fragmentiert zu werden. Beide Pakete (2000 Bytes und 3500 Bytes) wurden in max. 1500 Bytes große Datenteile aufgespalten und dann nacheinander verschickt.

Die wichtige Identifikationsnummer für fragmentierte Pakete ist die Identification im IP-Header, nicht die Identifier-Felder im ICMP-Paket, denn dieses wurde in mehrere Teile zerspaltet und um das Paket zusammensetzen zu können muss stattdessen die Quelle mehrere Pakete mit dem gleichen Identifizierer verschicken. Entsprechend sehen wir im obigen Screenshot, dass die IP-ID der Folgepakete in der Übersicht die gleiche ID haben wir der IP-Header des ersten Pakets.

Während der Analyse konnten wir kaum wertvolle Informationen zur Änderung der Roundtrip Time abhängig von der Fragmentierung gewinnen. In der Theorie braucht es länger, größere Datenmengen zu verschicken, vor allem wenn diese vorher in mehrere Teile aufgespalten wurden und für jeden Teil ein weiterer Header mitverschickt wird. Die Übertragung läuft jedoch hier in der Praxis so schnell ab, dass andere Abweichungen in der Übertragung sich stärker in der RTT abbilden.

\clearpage

Analyse einer Routenverfolgung

Im Folgenden wurde reutlingen.de explizit über IPv4 als Ziel für die Routenverfolgung verwendet. Das Tool das eingesetzt wurde ist tracepath (mit entsprechendem -4 Flag).

Wireshark registriert eine Sequenz von Paketen vom Typ DNS, UDP und meistens ICMP als Antwort. Die Pakete der eigentlichen Anfragen zur Routenverfolgung werden über UDP versendet. Dabei fällt auf, dass die UDP-Pakete von oben nach unten beginnend von einer Time-To-Live (TTL) von 1 inkrementierend größere Werte (2, dann 3, usw.) zugewiesen bekommen.

Die Antwort auf alle Pakete ist immer ein ICMP-Paket. Alle Antworten bis auf das letzte Paket sind ein ICMP-Paket mit der Nachricht "Time-to-live exceeded". Diese Antwort wird von dem jeweiligen routenden Knotenserver selbst verschickt und daran misst tracepath die Zeit und die Reaktionsfähigkeit des jeweiligen Knotens.

Die ersten beiden Knotenpunkte in diesem Fall sind:

  • 192.168.188.1 (fritz.box) - der Router im lokalen Netzwerk.
  • 62.214.63.94 (i59F4DCE4.versanet.de) - der erste externe Router aus dem ISP-Netzwerk.

\clearpage

ICMP

Ein ICMP-Paket ist wie folgt aufgebaut:

  • Type - ein Wert der die Art der ICMP-Nachricht angibt, z. B. 8 für eine Echo-Anfrage oder 11 für Time-to-live exceeded. Weitere Typen wären:
    • 0 - Echo Reply
    • 3 - Destination Unreachable
    • 5 - Redirect (IP-Umleitung)
    • 9 - Router Advertisement (wird benutzt um einem Rechner den Router bekannt zu machen zur IP-Vergabe). Gegenstück dazu: 10 (Router Solicitation)
    • 12 - Parameter Problem (bei ungültigen Inhalten in einer ICMP-Anfrage)
    • 13 - Timestamp. Gegenstück: 14 (Timestamp Reply)
  • Code - ein separater Code zur Angabe einer Fehlerursache oder eines anderen Details
  • Checksum - ein Hash des Pakets zum Sicherstellen einer korrekten Übertragung
  • Informationen zu ursprünglichen Anfragepaketen, meisten IP-Paket und dessen Inhalt. Aufgrund der Informationen die hier enthalten sind (wie der Identifizierer) weiß der Empfänger der Nachricht basiend auf diesen Informationen auf welche ursprünglich gesendeten Pakete sich diese ICMP-Meldung bezieht.

\clearpage

Quellenangaben