202 lines
8.0 KiB
Markdown
202 lines
8.0 KiB
Markdown
---
|
|
author: Carl Kittelberger
|
|
date: 2018-03-01
|
|
title: "ITS: IP und ICMP"
|
|
institute: "Ferdinand-von-Steinbeis Berufsschule"
|
|
lang: de-DE
|
|
babel-lang: ngerman
|
|
babel-otherlangs:
|
|
- english
|
|
polyglossia-lang:
|
|
name: german
|
|
options:
|
|
- spelling=new
|
|
#subtitle: "Internet Protocol und Internet Control Message Protocol"
|
|
#classoption: draft
|
|
classoption: oneside
|
|
colorlinks: true
|
|
documentclass: report
|
|
fontsize: 12pt
|
|
logo: img/steinbeis.png
|
|
mainfont: Arial
|
|
papersize: a4
|
|
sansfont: Arial
|
|
tables: true
|
|
template: template.tex
|
|
|
|
toc: true
|
|
|
|
header-includes:
|
|
# For \pageref{LastPage}
|
|
- \usepackage{lastpage}
|
|
|
|
# For \textcolor
|
|
- \usepackage{xcolor}
|
|
|
|
# Long tables (used by pandoc latex template itself)
|
|
#- \usepackage{longtable}
|
|
|
|
# Localization to German for all package injections
|
|
#- \usepackage[ngerman]{babel}
|
|
|
|
# Fancy header!
|
|
- \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{}/\pageref*{LastPage}}}}
|
|
- \renewcommand{\headrulewidth}{0.4pt}
|
|
- \renewcommand{\footrulewidth}{0.4pt}
|
|
- \setlength\headheight{36pt}
|
|
- \fancypagestyle{plain}{}
|
|
|
|
# monospace
|
|
- \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
|
|
|
|
- https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml#icmp-parameters-types
|