Tunnel Setup: Unterschied zwischen den Versionen
Aus FunkFeuer Wiki
(→Installation) |
(→Node-seitig) |
||
Zeile 28: | Zeile 28: | ||
=== Node-seitig === | === Node-seitig === | ||
− | * Am lokalen Host muß man jetzt [http://www.openvpn.org/ OpenVPN] starten sowie die geeigneten Routing-Rahmenbedingungen schaffen. | + | * Am lokalen Host muß man jetzt [http://www.openvpn.org/ OpenVPN] starten sowie die geeigneten Routing-Rahmenbedingungen schaffen. Low-Level technisch formuliert geht das so: |
− | + | ||
** Der [http://www.openvpn.org/ 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: | ** Der [http://www.openvpn.org/ 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'' | ''/sbin/ip route add subway.funkfeuer.at via 1.2.3.4 dev eth0'' |
Version vom 15. November 2005, 00:47 Uhr
Wie setz' ich eine Tunnel auf?
Inhaltsverzeichnis
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?
- 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.
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 mi /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:...]