Tunnel Setup: Unterschied zwischen den Versionen

Version vom 3. Februar 2009, 04:20 Uhr

Wie setz' ich eine Tunnel auf?

Grundlegendes

 ACHTUNG ANLEITUNG VERALTET , so gehts nicht ! 
 
 NEUE ANLEITUNG FOLGT DEMNÄCHST 

(Anmerkung zumindest Server IP adressen sind schon aktualisiert) Relativ einfache Einrichtung des Tunnels mit Web Interface siehe hier

• Wozu ein Tunnel?
  • Primär um anders nicht erreichbare Teile des Netzes über das Internet anzubinden, z.B. funkmäßig nicht erreichbare (sogenannte) 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 existieren 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 subway.funkfeuer.at (genauer: 78.41.115.16), der andere auf einem beliebigen lokalen Host. Die einzige Voraussetzung ist eine "normale" Internet-Verbindung vom Host zu tunnel.wien.funkfeuer.at (bzw. eigentlich 78.41.115.16). Dabei sind ppp, Masquerading/NAT und ähnliche Besonderheiten kein Problem oder besondere Einschränkung. siehe auch openvpn-webif

  Beispiel:
  
  eth0:     193.238.156.126
  tap0:     193.238.156.126 (gleiche ip auf mehreren interfaces des selben geräts stört nicht!)
  tapX:     193.238.158.128
  subway: 78.41.115.16
  port:     5026
  
     ((Oo.oO))     ((Oo.oO))
         v             v
   eth0-> \           /                    subway:5026      #---<-> 0xFF 193.238.156.0/22
           \_________/                       |  ____________ /
           | linksys |                       \ |            /|
           |         |         openvpn        \|           / |
           |____tap0============================tapX <->OLSR |
                 |                             |___________\_|
                 |                                          \         
               OLSR routed!                                  #---<--> internet 0.0.0.0/0
  

• Sonstiges
  • Der Tunnel ist ein unverschlüsselter IP-Tunnel, d.h. man kann drüber alles mitsniffen. Das liegt daran, daß
    • am subway.funkfeuer.at nicht genug Rechenpower für viele bis alle verschlüsselte Tunnels zur Verfügung steht und
    • auf einem typischen LinkSys nicht genug Rechenpower für einen verschlüsselten Tunnel zur Verfügung steht (wenn man auf nennenswerte Bandbreite nicht verzichten will) 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 Desktop 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 Security-mäßig) gar nichts.

Installation

Rahmenbedingungen für die Konfiguration

• Fixe IP-Adresse auf dem WAN Interface einstellbar (wenn bei einer DHCP-Adresse am WAN-Interface ein Default-Gateway mitkommt ist das schlecht); diese Adresse kann eine private IP (hinter einem Router) oder eine öffentliche IP im Internet (an einer Standleitung; keine 0xff-IP) sein
• UDP-Port für den Tunnel - diese bekommt man über ein Mail an die Mailingliste discuss@lists.funkfeuer.at.
• IP-Adresse im 0xff-Netzwerk und einen fertig installierten Router
• Funkfeuer-Paketserver konfiguriert

Installation der Pakete

Das Paket '0xff-openvpn-webif' installiert die notwendigen Pakete mit. Mit

 ipkg info 0xff-openvpn-webif 

können die Abhängigkeiten dieses Paketes angezeigt werden.

Installation über das Webinterface

Unter "Software 2" auf der Weboberfläche das Paket '0xff-openvpn-webif' suchen und installieren drücken.

Installation über SSH

 ipkg install 0xff-openvpn-webif 

Konfiguration des Tunnels

Konfiguration über das Webinterface

WAN-Interface Konfiguration

frame|none|Screenshot Konfiguration WAN Hier wird die IP-Adresse am WAN-Interface konfiguriert. Diese kann eine

• private Adresse (zB 192.168.x.x) oder
• eine öffentliche Adresse zB einer Standleitung

sein. Die Bedeutung der Netzmaske wird hier erklärt.

Ist der Tunnel in Betrieb darf kein Default-Gateway ("WAN-Default-Route") angegeben werden!

OpenVPN Konfiguration

frame|none|Screenshot Konfiguration OpenVPN Hier wird der Tunnel konfiguriert.

• Die remote IP ist die IP-Adresse des Tunnel-Servers.
• Das remote port ist das Port, das man von den Tunnel-Admins zugeteilt bekommt.
• Die VPN-IP ist die gleiche IP wie die IP, die für das Funk-Interface verwendet wird - die VPN-Netzmaske ist auch die gleiche wie beim Funk-Interface.
• Die VPN Gateway IP ist der eigentliche Gateway auf dem WAN-Interface.

Probleme?

Das ganze klingt natürlich fantastisch, nur können wie immer auch hier Probleme auftreten:

zB:

• Ist für die initiale Installation das WAN-Interface auf DHCP (bekommt also einen Default-Gateway), dann wird dieser Gateway als default für den Router genommen. Das ist gut - hat man aber auch das Funk-Interface aktiviert, dann will der Router für den Range der auf dem Funk-Interface konfigurierten IP dieses Interface als Ausgang benutzen; aber der ipkg-server ist möglicherweise auch in diesem Range und kann dann nicht erreicht werden --> Funk-Interface während der Tunnel-Einrichtung abschalten. (Dieses Problem tritt nicht auf, wenn man mit dem Funknetz verbunden ist, weil dann kommt man ja eh ins Internet und der Router auch auf den ipkg-Server)

ALT - Installation

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

• Im Funkfeuer Frontend legt man sich einen "Tunnel" an. Dem werden 2 Geräte-IP-Adressen zugeteilt - eine für jede Seite. Analog zu den Richtantennen kann man die auch zweckmäßig-nett benennen, also z.B. subwaytodig8tun und dig8tosubwaytun und kann auch gleich jede Seite eindeutig adressieren.

• 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 subway.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-Adressen (subwaytodig8tun wäre das im obigen Beispiel) bekannt, damit sie am subway.funkfuer.at am Tunnelendpunkt konfiguriert werden kann.
  • 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. Im Prinzip kann man am Node eine beliebige andere Portnummer verwenden, aber dem Autor fällt kein besonderer Grund, warum man dieses tun wollte.
  • Dann ist die eine Tunnelseite soweit fertig.

Node-seitig

Am lokalen Host muß man jetzt OpenVPN starten sowie die geeigneten Routing-Rahmenbedingungen schaffen. Bei allen Varianten braucht man folgendes:

• 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:

  ip route add 78.41.115.16 via 1.2.3.4 dev eth0

78.41.115.16 ist die IP-Adresse, über die netz-seitig die OpenVPN Deamons arbeiten. Die IP-Adresse ist nicht aus dem eigentlichen 0xFF-Netz, um Routingprobleme möglichts zu vermeiden. 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.

Insbesondere darf es keine explizite Hostroute (nur eine automatische über den olsrd) zu 193.238.156.2 (subway.funkfeuer.at) oder "193.238.157.16" (marvin.funkfeuer.at) oder 193.238.157.5 (tema.lo-res.org) geben: Auf dem Server läuft auch ein Nameserver, den aus dem 0xFF-Netz jeder benutzen kann (und soll) und dazu muß der Request über den Tunnel kommen - der Nameserver verweigert rekursive Anfragen (wie sie normale Resolver machen) aus dem (restlichen) Internet.

Low-Level/Barebones/Step-by-step/The old Method

ist auf Alte Konfigurationsmethode zu finden.

Der Autor dieser Seite findet sie mühsamer und fehlerträchtiger wie die folgenden Konfigurationsfilemethode.

Mit einem OpenVPN Konfigurationsfile

Obige Schritte kann OpenVPN auch alle selber machen. Entweder man spezifiert eine lange Liste korrekter Optionen oder man packt die Optionen in ein Konfigurationsfile unter /etc/openvpn, wo es die meisten Linuxdistributionen auch finden werden. Am subway.funkfeuer.at heißen die per Konvention tap<n>-<node>.conf. .conf am Ende brauchen die Startup-Scripts und mit den Namen davor finden sich die Admins leichter zurecht. Das Node-seitige Konfigurationsfiles des Autors dieser Seite enthält folgende Zeilen:

  #
  # dig8 tunnel
  #
  # '#' or ';' may be used to delimit comments.
  #
  dev             tap0
  proto           udp
  remote          78.41.115.16
  port            5011
  ifconfig        193.238.156.57  255.255.252.0
  route-up        /etc/openvpn/kill-route.sh
  daemon
  #secret          /etc/openvpn/dig8-priv.secret
  #auth            sha1
  #cipher          none

Die meisten erklären sich von selbst bzw. haben dieselbe Bedeutung wie die Optionen weiter oben. Die letzten 3 Zeilen sind der 1. Schritt zu autentifizierten (aber nicht verschlüsselten) Verbindungen, damit nicht irgendwer den eigenen Tunnel "übernehmen" kann. Um es an die eigenen Bedürfnisse anzupassen, muß man nur den Devicenamen, die Portnummer und IP-Adressen geeignet anpassen.

Das Script kill-route.sh schaut folgendermaßen aus:

  #!/bin/sh
  #
  # Kill the useless openvpn route
  #
  /sbin/ip route del "193.238.156.0/22" dev "$dev"

Authentifizierte Tunnels

Obig konfigurierte Tunnels verlassen sich auf die Korrektheit der beteiligten IP-Addressen. Sollte jemand ein passende IP-Adresse konfigurieren und der eigene Tunnel deaktiviert sein, könnte dieser jemand den Tunnel "übernehmen", indem er die passende Konfiguration einstellt.

Das läßt sich durch (kryptographisch sichere) einfache Authentifizierung mittels eines "Shared Secrets" verhindern.

• Zuerst stellt man den eigenen Tunnel auf obige "Konfigurationsfilevariante" um.

• Dann generieren wir (d.h. eigentlich nur der Nodeowner) einen Shared Key mit

  openvpn --genkey --secret /etc/openvpn/tap0-dig8.secret

Der Filename sollte dabei einen passenderen Namen wie oben bekommen (so heißt das File am dig8 Knoten).

• Dann schickt der Nodeowner eine Email mit passendem Text und dem erzeugten File als Attachment an bernd@firmix.at.

• Das Problem bei der Installation ist, daß man das auf beiden Seiten zugleich aktivieren muß, weil sonst die jeweils nicht-authentifizierte Seite nicht mehr verbinden kann/darf. D.h. es wird ausgemacht, wann das passiert und bernd@firmix.at stellt das server-seitig um (indem er obige 3 Zeilen am Ende des .conf Files auskommentiert). Gleichzeitig muß auch auf der Node-seite die entsprechenden Zeilen eingefügt werden.

Der Verkehr selber ist unverschlüsselt - eben aus den viel weiter oben angeführten Gründen. Und das ganze basiert natürlich darauf, daß bernd@firmix.at sowie alle andere "root"s am subway.funkfeuer.at auch vertrauenswürdig sind.

Abschluß

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

entweder dem OLSRd direkt mitteilen, dass er nun auch auf dem Tunnelinterface lauschen soll mit

olsrd -i tap0

bei 1.2.5 hat mir (datacop) damit der olsrd automatisch auch das config file richtig verändert, somit muss man das nach jedem neustarten nicht nochmal eingeben, wie das bei neueren Versionen ist weis ich (noch) nicht wie das ist

wenn es nicht funktioniert kann man noch immer das local.olsrd.conf file ändern wie folgt:

# Add your addons (e.g. plugins) to olsrd.conf here,
# addons for interfaces in /etc/local.olsrd.conf.eth1
Interface "tap0"
{
        HelloInterval           5.0
        HelloValidityTime       90.0
        TcInterval              2.0
        TcValidityTime          270.0
        MidInterval             15.0
        MidValidityTime         90.0
        HnaInterval             15.0
        HnaValidityTime         90.0
}

 siehe [http:... leider ein b0rken link]

FAQs

• Frage:

Ich benutze die FreifunkFirmware ab 1.23 und bekomme

The ifconfig command is replaced with the ip command.
For link layer settings refer to "ip link help"; For
ip adress settings refer to "ip addr help". Examples:
ip link set dev tap0 up
ip link set dev tap0 down
ip link set dev tap0 mtu 1500
ip link set dev tap0 address 00:01:02:03:04:05

• Antwort:

  Ab der Version 1.23 von Freifunk fehlt ifconfig, route usw, da
  sie Speicherplatz sparen wollten. Ich habe das schlicht und einfach nicht
  bemerkt, da ich ja jedesmal eine Rückmeldung erhalten habe wenn ich ifconfig
  eingegeben habe.

Mit

  ipkg install freifunk-openwrt-compat

können die nachinstalliert werden.

• Frage:

Ich habe durch meinen normalen Internetanschluß bereits ein Default-Route. Muß ich die löschen, wenn ich einen Funkfeuer-openvpn-Tunnel habe?

• Antwort:

Nein. Am entsprechenden Host des Autors sieht das so aus:

1#/sbin/ip route show | egrep -w '^default'
default via 62.178.36.1 dev eth1
default via 193.238.156.50 dev tap0 metric 1

Damit sind 2 Default-Routen mit verschiedenen "Metriken" vorhanden ("metric 1" und die nicht angezeigte "metric 0"). De facto wird die Route mit der Metrik 1 nie verwendet, weil die Hostrouten durch die schmälerer Netzmaske präferiert und die "normale" Default-Route durch die kleinere Metrik bevorzugt werden. Nur wenn es keine Hostroute zu einem Funkfeuer-Host gibt, wird der Weg über das Internet (ohne Tunnel) gewählt. Das sollte zum einen sowieso nicht sein und zum anderen sollte es nach Meinung des Autors (nachdem er es nicht ausprobiert hat) nicht signifikant schaden.

• Frage:

Kann ich dann alles machen?

• Antwort:

Node-seitig geht alles. Das einzige im Moment noch ungelöste Problem ist: Wenn man von außerhalb des 0xFF-Netzes eine 0xFF-IP-Adresse am Node erreichen will, kommen die IP-Pakete zwar an und die Antwortpakete zurück, aber die werden verworfen, weil - durch das Masquerading über die Default-Route - die Source-IP-Adresse verändert wird. Und damit verweigert der sendende Host die Annahme der Pakete.

Die Lösung ist: Man verwendet mehrere Routing-Tabellen, um auf Grund der Source-Adresse die Antwortpakete über den Tunnel zu Routen. Das kann der olsrd im Moment nicht.