IP-Tunnel

IP-Tunnel
Niklas Meinzer
Lehrstuhl für Kommunikationssysteme
Zusammenfassung In dieser Proseminarausarbeitung werden die theoretischen Hintergründe
und praktischen Möglichkeiten von IP-Tunneln behandelt. Es wird beschrieben, wie
sich mit Generic Routing Encapsulation(GRE) lokale Netzwerke über das Internet miteinander
verbinden lassen. Dabei wird der Sicherheitsaspekt ausgeblendet, um die Funktionsweise
eines einfachen Tunnels klarer zu machen. Praktische Anwendung finden IP-Tunnel bei der
Umstellung von IPv4 auf IPv6, dabei werden IPv6-Pakete durch ein bestehendes IPv4-Netz
getunnelt. Darüber hinaus lassen sich mit Hilfe von Tunneln auch Firewalls umgehen.
1 Einleitung und Motivation
Als Tunnel oder Kapselung wird in der Netzwerktechnik ein System bezeichnet, bei dem Pakete
(oder Datagramme, Segmente) eines Protokolls als Payload eines anderen Protokolls verschickt
werden. In Abbildung 1 ist anhand eines Beispiels dargestellt, wie der TCP/IP-Protokollstapel
Kapselung verwendet.
Anwendung
Transport
Netzwerk
Bitübertragung
SMTP (E-Mail)
TCP
IP
Ethernet
Abbildung 1. Der TCP/IP Protokollstapel (links) und je ein Beispielprotokoll für jede Schicht. Für die
Datenübertragung werden die Pakete eines Protokolls in Pakete des nächst tieferen eingepackt.
In diesem Paper geht es um IP-Tunnel oder IP-in-IP Kapselungen, also um Systeme, bei denen
die Payload eines IP-Paketes wieder ein IP-Paket ist. Übersetzt in die bekannte Postpaket-Analogie,
bei der das Postpaket ein IP-Paket und sein Inhalt die Payload darstellt, würde das bedeuten, dass
ein komplett versandfertiges Postpaket in ein weiteres eingepackt wird und dieses dann verschickt
wird. Es gibt einige Szenarien, für die diese Konstellation Sinn ergibt:
a) Ein Paket soll in eine Stadt verschickt werden, die vom lokalen Paketdienst nicht bedient wird.
Das Paket könnte dann in ein weiteres Paket eingepackt und in eine dritte Stadt zu einem
anderen Paketdienst geschickt werden, der die gewünschte Zielstadt bedient und das Paket
schließlich dorthin verschickt.
b) Der lokale Paketdienst verschickt keine Postkarten. Eine Postkarte könnte also in ein Paket
eingepackt werden und an einen zweiten Paketdienst geschickt werden, der Postkarten befördert
und die Postkarte aus dem Paket somit an den Empfänger zustellen kann.
Analoge Probleme aus der Netzwerktechnik werden in diesem Paper behandelt. Das Beispiel a)
entspricht in etwa einer Problematik, die bei der Umstellung von IPv4 auf IPv6 entstehen kann:

2 Niklas Meinzer
Verschiedene IPv6-Netze sollen über das Internet, das größtenteils noch mit IPv4 funktioniert,
miteinander verbunden werden. Hier besteht die Möglichkeit der IPv6-in-IPv4-Kapselung, die in
Abschnitt 3 behandelt wird.
Es gibt die Möglichkeit den Internetzugang eines lokalen Netzes über eine Firewall zu leiten. Dabei
können bestimmte Ports gesperrt werden, um die normalerweise über diese Ports kommunizierenden
Dienste nicht zuzulassen. Dieses Setup entspräche dem aus Beispiel b). IP-Tunnel können
eingesetzt werden um solche Sperren zu umgehen und die gesperrten Dienste dennoch zu nutzen.
Die theoretischen Grundlagen und die praktische Anwendung auf einem Linux-System werden in
Abschnitt 4 betrachtet.
2 Grundlagen von Tunneln
In Abbildung 2 sind zwei Netze abgebildet, die jeweils an das Internet angeschlossen sind, aber
intern über private Adressen verfügen.
Firmennetz A
10.1.*.*
Internet
Firmennetz B
10.2.*.*
Abbildung 2. Zwei verschiedene Standorte einer Firma verfügen über ein LAN, das jeweils über einen
Router per NAT an das Internet angeschlossen ist. Die Rechner aus den Netzen A und B sollen jedoch
untereinander kommunizieren können.
In diesem Beispiel soll der Rechner mit der Adresse 10.1.100.1 aus Netz A mit dem Rechner
mit der Adresse 10.2.100.1 kommunizieren können, ohne die Verbindung über das Internet berücksichtigen
zu müssen.
Diese Funktion lässt sich mit dem Generic Routing Encapsulation Protokoll realisieren.
2.1 Generic Routing Encapsulation (GRE)
Mit Hilfe des GRE Protokolls lassen sich verschiedene Protokolle in andere einpacken. Der Header
sieht folgendermaßen aus:
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
C reserved0 Ver protocol type
checksum(optional) reserved1(optional)
Tabelle 1. Der GRE-Header [2]: Das erste Bit (Checksum present) legt fest, ob die Felder checksum
und reserved1 vorhanden sind. Die Felder reserved0 und reserved1 finden in der aktuellen Version keine
Verwendung. Das version Feld beinhaltet die benutze GRE-Version und das protocol type Feld den Typ
des verpackten Protokolls.
In einem GRE-Tunnel wird ein Paket eines anderen Protokolls – wie in Abbildung 3 ein IP-Paket
– samt Payload mit einem GRE-Header versehen und in ein IP-Paket verpackt. Im GRE-Header

IP-Tunnel 3
wird der Typ des verpackten Paketes eingetragen und im IP-Paket das Feld protocol mit dem
Wert 47 (GRE) belegt. Das IP-Paket wird zum Ende des Tunnels übertragen. Dort wird der GRE-
Header entfernt, eventuell eine Prüfsumme berechnet und das verpackte Paket an das in protocol
type festgelegte Protokoll übergeben. Wie in Abbildung 3 anhand eines Beispiels gezeigt, wird
dabei der TCP/IP-Protokollstapel durch zusätzliche Schichten ergänzt. [3] [2]
SMTP (E-Mail)
TCP
IP
GRE
Ethernet IP
SMTP (E-Mail)
TCP
IP
GRE
IP
Ethernet
Abbildung 3. Im GRE-Tunnel werden in den Protokollstapel zwei zusätzliche Schichten eingezogen.
2.2 GRE Tunnel unter Linux
Unter Linux lässt sich ein GRE-Tunnel (sofern das Kernelmodul ip gre geladen ist) mit Hilfe des
Programmes ip einrichten. Um zum Beispiel die beiden Netzwerke aus Abbildung 2 durch einen
GRE-Tunnel miteinander zu verbinden, muss wie folgt vorgegangen werden.
Es wird angenommen, dass die beiden Router, die die LAN’s mit dem Internet verbinden, an der
Internetschnittstelle die Adressen 172.10.100.1 (Router A) und 172.123.10.2 (Router B) haben.
Konfiguration auf Router A:
ip tunnel add gretunnel
mode gre local 172.10.100.1 remote 172.123.10.2 ttl 64 dev eth0
ip link set gretunnel up
ifconfig gretunnel 10.111.111.1/24
ip route add -net 10.2.0.0/16 gw 10.111.111.2 dev gretunnel
Der erste Befehl erstellt einen neuen Tunnel mit dem Namen gretunnel. Dabei werden die lokale
Adresse und die Adresse des Tunnelendes bezüglich des zu durchtunnelnden Netzwerkes angegeben.
Weiterhin wird ein Time-to-Live-Wert festgelegt und das Interface, über das die verpackten Pakete
rausgeschickt werden sollen. Die nächsten beiden Befehle aktivieren das neue Interface gretunnel
und weisen diesem eine Adresse zu. Schließlich wird ein neuer Eintrag in der Routingtabelle erstellt,
der Pakete an IP-Adressen der Form 10.2.*.* durch den Tunnel schickt. Dabei wird angenommen,
dass das Tunnelinterface auf Router B die Adresse 10.111.111.1/24 erhalten hat.
Analog dazu wird Router B konfiguriert.
Die Hosts aus den Netzen A und B können nun untereinander IP-Pakete austauschen, indem sie
ihre lokalen IP-Adressen verwenden. Die Existenz des Tunnels ist für sie nicht ersichtlich. Für die
Knoten, die das Paket auf seinem Weg durch das Internet weiterleiten, sieht es so aus, als ob sich
die Router A und B gegenseitig Pakete schicken (Abbildung 4). [4] [5]
2.3 Sicherheit
GRE bietet keinerlei Möglichkeiten Pakete zu verschlüsseln oder auf andere Weise vor unbefugtem
Zugriff zu schützen. Auf ihrem Weg durch das Internet könnten die Pakete daher abgefangen
und ausgewertet werden. Für das Verbinden verschiedener Firmennetzwerke ist GRE somit in der
Praxis nicht geeignet. Eine sichere Alternative wäre ein VPN.

4 Niklas Meinzer
10.1.93.13
IP
Dest: 10.2.100.12
Src: 10.1.93.13
Local: 10.1.0.1
Global: 172.10.100.1
IP
Dest: 172.123.10.2
Src: 172.10.100.1
GRE
Protocol Type: IP
IP
Dest 10.2.100.12
Src: 10.1.93.13
Local: 10.2.0.1
Global: 172.123.10.2
IP
Dest: 10.2.100.12
Src: 10.1.93.13
LAN A Internet LAN B
Abbildung 4. Der Weg eines IP-Paketes von Host zu Host durch einen GRE-Tunnel.
3 IPv6-in-IPv4
10.2.100.12
Ein wichtiges Feld, in dem IP-Tunnel praktische Anwendung finden, ist die Umstellung von IPv4
auf IPv6. Als IPv6 entwickelt wurde, um IPv4 abzulösen, war der Vorgänger bereits soweit etabliert,
dass ein weltweiter Umstieg bis heute nicht erfolgt ist und auch in naher Zukunft nicht zu erwarten
ist. Um es einzelnen Firmen oder Privatanwendern trotzdem möglich zu machen in lokalen Netzen
IPv6 zu verwenden und dennoch nicht von der Außenwelt abgeschnitten zu sein, gibt es zahlreiche
Methoden die beiden IP-Versionen koexistieren zu lassen.
Einige davon – insbesondere die Möglichkeit des IPv6-in-IPv4-Tunnelings – werden im Request for
Comments Nr.4213 [6] der Internet Engeneering Task Force (IETF) vorgestellt.
Beim IPv6-in-IPv4 Tunneling werden IPv6-Pakete in IPv4-Paket eingepackt und über ein IPv4-
Netzwerk versandt. Folgende Situationen sind möglich:
Router to Router Ein IP-Tunnel zwischen zwei Routern könnte zum Beispiel die IPv6-Netzwerke
zweier Firmenfilialen miteinander durch das Internet verbinden.
Host to Router Ein Rechner in einem IPv4-Netz könnte mit Hosts aus einem IPv6-Netz hinter
einem IPv4/IPv6-Router kommunizieren, indem die Pakete den Weg bis zu dem Router durch
einen Tunnel zurücklegt.
Host to Host Theoretisch können auch zwei Hosts durch ein IPv4-Netz kommunizieren, indem
sie einen IPv6-Tunnel nutzen.
Router to Host Und schließlich kann ein Router auch IPv6-Pakete aus einem IPv6-Netz durch
einen Tunnel an einzelne Host in einem IPv4-Netz leiten.
Für alle diese Arten von Tunneln gilt, dass er für Sender und Empfänger “unsichtbar” ist. Das
heißt, der gesamte Tunnel zählt nur als ein Hop, auch wenn er in Wirklichkeit über mehrere Hops
verläuft. Die Beschaffenheit und Funktionsweise eines Tunnels wird bestimmt durch seine beiden
Endpunkte, den verpackenden und den entpackenden Knoten.

IP-Tunnel 5
Der verpackende Knoten Der verpackende Knoten, also der Startknoten eines Tunnels, hat
drei Aufgaben zu erfüllen:
1. Er muss ein IPv4-Paket erstellen, das ankommende IPv6-Paket darin verpacken und es an den
Endpunkt des Tunnels schicken.
2. Er muss entscheiden, wie mit Fragmentierung umzugehen ist. Er könnte zum Beispiel die maximale
Größe eines IPv4-Pakets (65515 Byte + 20 Byte Header) als MTU des Tunnels festlegen.
Dies würde zu hoher Fragmentierung innerhalb des Tunnels führen und so den Endpunkt durch
das Zusammenbauen des riesigen Paketes belasten. Dieses Zusammenbauen wird normalerweise
durch den Empfänger erledigt, um die inneren Knoten und somit das gesamte Netz zu entlasten.
Daher wird entweder ein moderater, fester MTU Wert für den Tunnel gewählt (der
RFC schlägt 1280 bis 1480 Byte vor) oder per Path MTU Discovery der tatsächliche Wert des
Tunnels ermittelt, um so Fragmentierung innerhalb des Tunnels ganz zu vermeiden.
3. Er muss entscheiden, was mit ICMPv4 Messages aus dem Tunnel geschieht.Um eine ICMPv4
Fehlermeldung aus dem Tunnel interpretieren zu können, muss der verpackende Knoten wissen,
welches Paket sie hervorgerufen hat. Bei älteren ICMPv4 Implementierungen werden an die
Fehlermeldung nur der Header des verursachenden IPv4 Paketes und die ersten 8 Byte (also
64 Bit) der Payload angehängt. Im Falle eines IPv6-in-IPv4 Tunnels also die ersten 64 Bit des
IPv6 Headers. Die Adresse des Senders wird jedoch in den Bits 65 bis 192 codiert und ist somit
nicht mehr enthalten. Eine solche Fehlermeldung kann also nur verworfen werden, ohne den
Sender zu informieren.
Sollte der Sender rekonstruierbar sein, muss der verpackende Knoten entscheiden, ob er ein
ICMPv6 Paket weiterleitet und wenn ja, welches. Während destination unreachable einfach
weitergeleitet werden kann, würde ein time exceeded Paket den Sender veranlassen das hop
limit zu erhöhen. Da der Tunnel für das IPv6-Paket jedoch nur einen Hop darstellt, wäre dies
nicht zielführend. Stattdessen könnte sich der verpackende Knoten entscheiden, ein destination
unreachable-Paket an den Sender zu schicken und den TTL-Wert der Tunnelpakete zu erhöhen.
Der entpackende Knoten Der entpackende Knoten eines Tunnels, der ein IPv4-Paket mit
dem Eintrag 41 im protocol Feld erhält, muss den IPv4-Header entfernen und das IPv6 Paket
behandeln, als hätte er es ganz normal erhalten und es an den Empfänger weiterleiten. Um Spoofing
zu verhindern, muss überprüft werden, ob der Absender des IPv4-Pakets auch tatsächlich der
Anfangspunkt des Tunnels ist. Wie das genau passiert, wird durch die jeweilige Implementierungen
festgelegt. Bei GRE muss zum Beispiel das andere Ende des Tunnels eim Einrichten mit angegeben
werden.
4 Tunneln durch Firewalls
Eine weitere Anwendung ist das Tunneln durch Firewalls.
Ein Beispiel: Ein Firmennetzwerk ist über einen Router mit Firewall mit dem Internet verbunden.
Diese Firewall verhindert das Senden (SMTP, Port 25) und Empfangen (POP, Port 110) von
E-mails, indem Pakete, in deren Header im destination port Feld der Wert 25 oder 110 steht,
verworfen werden. Ist Port 22 nicht gesperrt, ist es möglich über das Secure Shell Protokoll (SSH)
einen Tunnel zu einem präparierten Host aufzubauen und die SMTP bzw. POP Verbindung durch
diesen hindurch aufzubauen und so die Portsperren zu umgehen. Ein weiterer Vorteil hierbei ist,
dass SSH Verbindungen verschlüsselt sind, somit erreicht man ein höheres Maß an Sicherheit für
den Mailverkehr. Dies gilt natürlich nur innerhalb des Tunnels, die Verbindung vom Tunnelausgang
zum Zielserver profitiert nicht mehr von der SSH Verschlüsselung.
4.1 Theorie
Da ein Tunnel einen Anfangs- und Endpunkt braucht, wird ein Server benötigt, der als Endpunkt
agieren kann und natürlich außerhalb des Firmennetzwerkes liegen sollte. Auf diesem Server muss

6 Niklas Meinzer
ein SSH-Server laufen, um den Tunnel aufbauen zu können. Wie bei IPv6-in-IPv4-Tunneln soll
der Tunnel von “außen”, also für die beteiligten Programme, nicht sichtbar sein. Da der Mailclient
für den Verbindungsaufbau einen Server mit einer bestimmten IP-Addresse anspricht, ist der SSH-
Client, der den Eingang des Tunnels darstellt, wie ein Server ansprechbar. Er öffnet einen Port auf
dem lokalen Rechner, den der Mailclient dann ansprechen kann. Die übergebenen Pakete werden
vom Client in verschlüsselte SSH Pakete verpackt und an den Server geschickt. Dabei wird der
an SSH zugewiesene Port 22 verwendet. Der SSH-Server entpackt die Pakete wieder, ersetzt die
Absenderadresse durch seine eigene und schickt sie an einen vordefinierten Zielhost. Die Antwort
wird wieder durch den Tunnel geschickt und vom SSH Client an den Mailclient weitergegeben.
4.2 Praxis
Um einen Tunnel einzurichten, muss ein SSH-Client – wie er bei den meißten Linux-Distributionen
schon vorinstalliert ist – mit folgenden Parametern aufgerufen werden.
ssh -L 10025:smtp.mailserver.de:25
-L 10110:pop.mailserver.de:110
user@ssh-server
Die beiden -L Attribute definieren je einen Tunnel für SMTP und POP. Die erste Zahl ist der
Port auf dem lokalen Rechner, der den Eintrittspunkt in den Tunnel darstellt. Hier kann ein
Programm Pakete an den SSH-Client übergeben, der diese dann durch den Tunnel schickt. Nach
dem Doppelpunkt steht die Adresse des Servers, an den die Pakete nach dem Tunnel weitergeleitet
werden sollen, in diesem Fall also die Adresse des Mailservers. Nach dem zweiten Doppelpunkt
schließlich der Port des Zielrechners, an den die Pakete geschickt werden sollen.
Im Mailserver müssen nun die Eingangspunkte der Tunnel, localhost:10025 und localhost:10110,
als SMTP-, bzw POP-Server angegeben werden. Danach funktioniert der Mailverkehr durch den
Tunnel. [7]
4.3 Perspetiven
Der Mailverkehr über den Tunnel sieht aus Sicht des Mailclients, der Firewall und des Mailservers
wie folgt aus:
Aus der Sicht des Mailclients Der Mailclient baut eine Verbindng mit den eingestellten Servern
auf. Da der Eingang des SSH-Tunnels eine IP-Adresse mit Portnummer ist, kann der Mailclient
diese ganz normal ansprechen, es sind keine Plugins nötig. Die Antwort erhält er wieder vom
SSH-Client, somit ist der Tunnel für ihn nicht sichtbar.
Aus der Sicht der Firewall Der eigentliche Zweck des Tunnels ist die Restriktionen der Firewall
zu umgehen, für diese ist es nicht mehr ersichtlich, dass ein Mailserver angesprochen wird.
Sichbar sind die Pakete, die von SSH-Client an den SSH-Server geschickt werden. Sie enthalten die
Empfängeradresse des SSH-Servers und im destination port Feld des Transportschichtprotokolls
(bei SSH wird TCP verwendet) steht der Wert 22. Da dieser Port von der Firewall nicht gesperrt
ist, werden die Pakete ganz normal durchgelassen. Nur aus der Verwendung des Ports 22 lässt sich
auch nicht die Existenz eines Tunnels schließen, da SSH auch viele andere Zwecke erfüllen kann.
Aus der Sicht des Mailsevers Am Ende des Tunnels werden die Pakete des Mailclients entpackt
und auf normalem Wege an den Mailserver geschickt. Dieser empfängt also ganz normale Pakete
und antwortet entsprechend. Für ihn ist die Existenz des Tunnels nicht erkennbar.

Literatur
IP-Tunnel 7
1. Ross, K.W., Kurose, J.F.: Computer Networking. 4th edn. Pearson International (2008)
2. IETF: RFC 2784: Generic routing encapsulation.
http://tools.ietf.org/html/rfc2784 (2000)
3. IETF: RFC 1701: Generic routing encapsulation.
http://tools.ietf.org/html/rfc1701 (1994)
4. The Linux Foundation: Tunneling.
http://www.linuxfoundation.org/collaborate/workgroups/networking/tunneling
(Seitenaufruf 28.11.09) (2009)
5. www.linuxdocs.org: GRE and other tunnels.
http://www.linuxdocs.org/HOWTOs/Adv-Routing-HOWTO-5.html (Seitenaufruf: 28.11.09) (2000)
6. IETF: RFC 4213: Basic ipv6 transition mechanisms.
http://tools.ietf.org/html/rfc1933 (2005)
7. polishlinux.org: SSH tunnels: Bypass (almost) any firewall.
http://polishlinux.org/apps/ssh-tunneling-to-bypass-corporate-firewalls/
(Seitenaufruf: 06.12.09) (2006)