Tunnel Setup: Unterschied zwischen den Versionen
Bernd (Diskussion | Beiträge) (→Grundlegendes) |
Bernd (Diskussion | Beiträge) (→FAQs) |
||
Zeile 106: | Zeile 106: | ||
== FAQs == | == FAQs == | ||
− | + | ; Frage: | |
Ich benutze die FreifunkFirmware ab 1.23 und bekomme | Ich benutze die FreifunkFirmware ab 1.23 und bekomme | ||
<blockquote><tt> | <blockquote><tt> | ||
Zeile 117: | Zeile 117: | ||
ip link set dev tap0 address 00:01:02:03:04:05 | ip link set dev tap0 address 00:01:02:03:04:05 | ||
</tt></blockquote> | </tt></blockquote> | ||
− | + | : Antwort: | |
− | + | ||
Ab der aktuellen Version von Freifunk 1.23 fehlt ifconfig, route usw, da | Ab der aktuellen Version von Freifunk 1.23 fehlt ifconfig, route usw, da | ||
sie Speicherplatz sparen wollten. Ich habe das schlicht und einfach nicht | sie Speicherplatz sparen wollten. Ich habe das schlicht und einfach nicht |
Version vom 27. Mai 2006, 23:18 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?
- 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
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 zusandwich.funkfeuer.at
(bzw. eigentlich 193.239.188.20). Dabei sind ppp, Masquerading/NAT und ähnliche Besonderheiten kein Problem oder besondere Einschränkung.
- Ein Tunnelendpunkt ist konkret am
- 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 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.
- am
- Der Tunnel ist ein unverschlüsselter IP-Tunnel, d.h. man kann drüber alles mitsniffen. Das liegt daran, daß
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.
- Dabei gibst du eine der erhaltenden IP-Addressen bekannt, damit sie am
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 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/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 sandwich.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 193.239.188.20 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 miitels 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/dig8-priv.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 sandwich.funkfeuer.at
auch vertrauenswürdig sind.
Abschluß
- Als letzten Schritt brauchen wir noch einen laufenden olsrd, der die Routen alle richtig verwaltet.
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 aktuellen Version von Freifunk 1.23 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.