Tunnel Setup: Unterschied zwischen den Versionen

Version vom 15. November 2005, 00:57 Uhr

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-Damon wird olsrd eingesetzt.

• Wie funktioniert das?
  • Ein Tunnelendpunkt ist konkret am subway.funkfeuer.at, der andere auf einem beliebigen lokalen Host. Die einzige Voraussetzung ist eine "normale" Internet-Verbindung vom Host zum subway.funkfeuer.at. Dabei sind ppp, Masquerading und ähnliche Besonderheiten kein Problem oder gar besondere Einschränkung.

• Sonstiges
  • Der Tunnel ist ein unverschlüsselter IP-Tunnel, d.h. man kann drüber alles mitsniffen. Das liegt primär daran, daß am subway.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 (das am anderen Tunnelendpunkt terminiert und nicht erst am Server. D.h. man muß sowieso sichere/verschlüsselte Protokolle verwenden oder einen sicheren Tunnel vom eigenen Node bis zum Server legen. Für beides bringt ein weiterer "teilweiser" Tunnel drunter nur mehr Latency, aber sonst nichts).

Installation

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

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

• Wir verwenden tap Devices von OpenVPN. Diese tunneln an sich 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.

Netz-seitig

• Am subway.funkfeuer.at muß jemand mit dortigen root-Rechten den Tunnelendpunkt konfigurieren. Diese Leute erreicht man besten über die discuss@lists.funkfeuer.at Mailingliste.
  • Du bekommst dabei die zu verwendende Portnummer mitgeteilt. Nachdem am subway.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. Low-Level technisch formuliert geht das so:
  • Der OpenVPN Tunnel geht direkt zum subway.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 subway.funkfeuer.at via 1.2.3.4 dev eth0

eth0 ist dabei das Netzwerk-Device, über das die Default-Route geht und 1.2.3.4 ist das 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 läuft hat man mehrere.

• • 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 namesn tap0, daß man mit

  /sbin/ip addr /show

auch sehen kann.

• • Dann muß man den OpenVPN Tunnel aufbauen:

  /usr/sbin/openvpn --dev tap0 --remote subway.funkfeuer.at --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.Ü. auch lokal verwendet. Der OpenVPN Prozeß verzieht sich dabei in guter alter Unix-Manier für Daemons 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 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 aufenden OLSRD, der die Routen alle richtig verwaltet.

  siehe [http:...]