Tunnel Setup

Wie setz' ich eine Tunnel auf?

Grundlegendes

• Wozu ein Tunnel?
  • Primär um anders nicht erreichbare Teile des Netzes über das Internet anzubinden, z.B. funkmäßig nicht erreichbare Inseln.
  • Aber auch um redundante Verbindungen zu schaffen.

• Was wird eingesetzt?
  • OpenVPN ist die Implementierung der Wahl. Es kann alles, was man brauchen kann, ist leidlich einfach aufgesetzt und es exisitieren Implementierungen für alle relevante Betriebssysteme.
  • Als Routing-Deamon wird olsrd eingesetzt. Das hat mit OpenVPN nur insoweit etwas zu tun, als daß wir "tap" Interfaces verwenden (müssen), damit der olsrd drüber broadcasten kann.

• Wie funktioniert das?
  • Ein Tunnelendpunkt ist konkret am sandwich.funkfeuer.at (genauer: 193.239.188.20), der andere auf einem beliebigen lokalen Host. Die einzige Voraussetzung ist eine "normale" Internet-Verbindung vom Host zu sandwich.funkfeuer.at (bzw. eigentlich 193.239.188.20). Dabei sind ppp, Masquerading/NAT und ähnliche Besonderheiten kein Problem oder besondere Einschränkung.

• Sonstiges
  • Der Tunnel ist ein unverschlüsselter IP-Tunnel, d.h. man kann drüber alles mitsniffen. Das liegt daran, daß
    • am sandwich.funkfeuer.at nicht genug Rechenpower für verschlüsselte Tunnels zur Verfügung steht und
    • ein verschlüsselter Tunnel ein falsches Gefühl der Sicherheit erzeugen könnte: Der Tunnel terminiert am anderen Tunnelendpunkt und nicht erst am Zielserver, zu dem man eigentlich will. D.h. man muß sowieso zusätzlich sichere/verschlüsselte Protokolle verwenden oder einen sicheren IP-Tunnel vom eigenen Host bis zum Zielserver legen. Für beides bringt ein weiterer "teilweiser" Tunnel drunter nur mehr Latenz (jedes Paket will einmal zusätzlich verschlüsselt und entschlüsselt werden) und verbrauchte CPU-Leistung, aber ansonsten (insbesondere Secruity-mäßig) gar nichts.

Installation

• Auf beiden Enden des Tunnels muß OpenVPN installiert sein. Am sandwich.funkfeuer.at ist das trivialerweise längst der Fall, am lokalen Host (egal wlecher Bauart) muß das der Node-Owner sicherstellen.

• Am Frontend legt man sich einen "Tunnel" an. Dem werden 2 Geräte-IP-Adressen zugeteilt - eine für jede Seite.

• Wir verwenden tap Devices von OpenVPN. Diese tunneln am Layer 2 (d.h. a la Ethernet) und sind daher broadcast-fähig. Außerdem sollte der Tunnel UDP benutzen (und v.a. nicht TCP), da wir auch TCP-Connections drüber haben, die ja automatisch neu zu senden versuchen, wenn es gerade nicht geht. Wenn jetzt die normale Internetverbindung zusammenbricht, versuchen permanent 2 Schichten an TCP-Verbindungen durch Retries etwas zu erreichen und es schaukelt sich auf (d.h. es bringt nichts und erzeugt nur noch mehr sinnlosen Traffic).

Netz-seitig

• Am sandwich.funkfeuer.at muß jemand mit dortigen "root"-Rechten den Tunnelendpunkt (und olsrd) konfigurieren. Diese Leute erreicht man besten über die Mailingliste discuss@lists.funkfeuer.at.
  • Dabei gibst du eine der erhaltenden IP-Addressen bekannt, damit sie am sandwich.funkfuer.at am Tunnelendpunkt konfiguriert werden kann.
  • Du bekommst dabei die zu verwendende Portnummer mitgeteilt. Nachdem am sandwich.funkfeuer.at einige Tunnelendpoints sind, kann man nicht einfach irgendwas verwenden. Außerdem sind die verwendeten Portnummern alle in einer geschlossenen Range - das erleichtert die Verwaltung.
  • Dann ist die eine Tunnelseite soweit fertig.

Node-seitig

Am lokalen Host muß man jetzt OpenVPN starten sowie die geeigneten Routing-Rahmenbedingungen schaffen.

• Der OpenVPN Tunnel geht direkt zum sandwich.funkfeuer.at über die normale (bzw. sonstige) Internet-Verbindung. Um diese Verbindung durch spätere Routen nicht zu gefährden, setzen wir eine explizite Hostroute:

  /sbin/ip route add 193.239.188.20 via 1.2.3.4 dev eth0

193.239.188.20 ist die IP-Adresse, über die netz-seitig die OpenVPN Deamons arbeiten. Die IP-Adresse ist nicht aus dem eigentlichen 0xFF-Netz, weil es sonst Routingprobleme gibt. eth0 ist dabei das Netzwerk-Device, über das die Default-Route geht und 1.2.3.4 ist das normale Default Gateway/Next Hop. Die Default-Route(n) kann man mit /sbin/ip route show | fgrep default sehen. Normalerweise sieht man genau eine, wenn der olsrd bereits läuft, sieht man mehrere.

Low-Level/Barebones/The old Method

Low-Level technisch formuliert geht das so:

• Dann legt man das OpenVPN Device an:

  openvpn --mktun --dev tap0

Wenn tap0 schon belegt ist, nimmt man das nächste freie (tap1, 'tap2, ...). Im folgenden geh ich davon aus, daß tap0 verwendet wird. Voila, wir haben eine neues Netzwerk-Device namens tap0, daß man mit

  /sbin/ip addr /show

auch sehen kann.

• Dann muß man den OpenVPN Tunnel aufbauen:

  /usr/sbin/openvpn --dev tap0 --remote 193.239.188.20 --port port --daemon --writepid /var/run/openvpn-tap0.pid --cd /var/tmp

Dabei muß als Parameter für port der Port, den man oben mitgeteilt hat verwendet werden - der wird i.Ü. der Einfachheit auch lokal verwendet. Der OpenVPN Prozeß verzieht sich dabei in guter alter Unix-Manier für Deamons in den Hintergrund, schreibt seine Prozess-Id in das File /var/run/openvpn-tap0.pid (das man verwenden kann, um den Prozeß wieder zu terminieren) und sagt ihm, er soll ins Directory "/var/tmp" wechseln (dann blockiert er sonst nichts). Voila, wir haben einen Tunnel - der steht noch nicht, weil noch nichts drüber geschickt wurde.

• Unser tap0 Device braucht eine IP-Adresse - und zwar die andere der 2 aus dem Frontend.

  /sbin/ip addr add ip broadcast + dev tap0

ip ist dabei eben jene 2. IP-Adresse (inklusive Netzmaske - z.B. /22). Mit

  /sbin/ip addr show

kann man sich den Erfolg jetzt ansehen.

• Allerdings haben wir jetzt ein Problem (FIXME: auch auf nicht-Linuxens?). Wir haben vom Linux-Kernel eine Netzroute geschenkt bekommen, die wir nicht brauchen und wollen. Die entsorgen wir gleich wieder:

  /sbin/ip route del 193.238.156.0/22 dev tap0

Die Zeile kann man (u.U. bis aufs "tap0" Device) 1:1 kopieren, weil im Moment alle 0xFF-IP-Adressen aus dem gleichen Netz (193.238.156.0/22) sind.

• Und jetzt aktivieren wir das Interface:

  /sbin/ip link set tap0 up

• Als letzten Schritt brauchen wir noch einen laufenden olsrd, der die Routen alle richtig verwaltet.

 siehe [http:...]