Vpn03

Aus wiki.freifunk.net
Wechseln zu: Navigation, Suche

Berliner VPN-Server

Animation aus FF Video 2013

Der Berliner VPN-Server wird vom Verein freie Netze e.V. betrieben und steht allen Freifunker_innen zur Verfügung. Sinn des VPNs ist, die Störerhaftungs-Problematik für alle diejenigen zu entschärfen, die Internet auf ihren Freifunk-Routern anbieten wollen.

Zugang beantragen und einrichten

Einen Zugang zum VPN kannst du unter https://ca.berlin.freifunk.net beantragen. Um einen Zugang generieren zu können, brauchen wir eine (deine) E-Mail-Adresse als "Kümmerer-Kontakt" und einen Tunnel-Namen. Die E-Mail Adresse darf dabei nicht länger als 40 Zeichen sein. Der Tunnel-Name muss auf dem Vpn03-Server eindeutig sein und sollte den Tunnel beschreiben, z.B. berlin-musterstr42. Du bekommst die Zugangsdaten dann per E-Mail zugeschickt.

Die Berliner Firmware wird mit der .crt und der .key-Datei, die du bekommen hast, eingerichtet wie im Berliner HowTo beschrieben.

Für andere Firmwares gibt es Anleitungen der jeweiligen Freifunk-Community und weitere Anleitungen in der Kategorie:Tutorials.

Details

Ein Skript erzeugt die OpenVPN-Client-Konfig. Diese wird per E-Mail verschickt. Die E-Mail-Adresse ist außerdem Teil der Konfiguration - die E-Mail-Adresse ist auch im Klient-Zertifikat hinterlegt. Mit der E-Mail-Adresse können wir später mal wenn z.B. der Dienst umzieht oder eine allgemeine Konfigurationsänderung ansteht mit allen Kontakt aufnehmen. Mit dem Tunnelnamen identifiziert sich der Router bzw. der OpenVPN-Klient beim Server. Ein Zusammenhang zwischen übertragenen Daten und E-Mail-Adresse bzw. Tunnelnamen wird auf dem VPN-Server nicht gespeichert.

Wenn du also eine Konfiguration bekommst, ist diese in einem *.tgz-Archiv enthalten. Darin sind folgende Dateien enthalten ("tunnel-test" wurde als Tunnelname angegeben):

Datei Erläuterung
freifunk-ca.crt Diese Datei beweist, dass die ausgegebenen *.crt / *.key vom OpenVPN-Server stammen. Ist wie ein Pubkey, darf also gerne veröffentlicht werden.
freifunk_tunnel-test-android.p12 Das ist ein Experiment mit IPSec. Diese Datei kann in den Android / Windows-Keystore importiert werden um damit L2TP oder XAuth-VPN-Verbindungen anzulegen. Das mit dem IPSec ist allerdings grausam zu konfigurieren, fehlerbehaftet und der entsprechende Daemon ("racoon") ist derzeit ausgeschaltet. Kennwort für diese Datei ist "freifunc".
freifunk_tunnel-test.crt freifunk_tunnel-test.key Diese Dateien enthalten den Klient-Schlüssel und eine Echtheitsbestätigung desselben. Diese Dateien bitte nicht veröffentlichen.
freifunk_tunnel-test-tcp.ovpn Konfigurationsdatei für eine sichere Verbindung. Diese Konfiguration nur im Ausnahmefall verwenden, z.B. aus dem unsicheren Ausland heraus oder wenn du dem DSL-Provider nicht traust.
freifunk_tunnel-test-udp.ovpn Konfigurationsdatei für eine schnelle unverschlüsselte Verbindung. Diese Konfiguration im Regelfall verwenden. Die OpenWRT-Router sind nicht so schnell und Verschlüsselung kostet CPU und damit Übertragungsbandbreite.
readme.txt Kurztext zur Erläuterung

Für einen ersten Test kannst du das *.tgz auspacken und gleich verwenden. Unter Android in /sdcard/openvpn/ auspacken und mit OpenVPN-Settings-App verwenden (braucht "root"). Unter Windows in C:\Progra~1\OpenVPN\Config auspacken und mit der OpenVPN-GUI-App verwenden (braucht "Administrator"). Unter Linux irgendwohin auspacken und mit "sudo openvpn --config *-udp.ovpn" starten (braucht "sudo").

Hintergründe

Geschichte

Ende 2011 / Anfang 2012 hat der Verein freie Netze e.V. auf seiner Jahreshauptversammlung beschlossen, einen VPN-Server für alle Freifunker anzubieten. Der Verein ist vom Status her Access-Provider. Es war Konsens, dass wir diesen Status nutzen wollen, um die Störerhaftungs-Problematik für alle diejenigen zu entschärfen, die Internet auf ihren Freifunk-Routern anbieten wollen.

Ende 2014: Über das letzte Jahr hat sich der Verkehr durchaus verstärkt. Wir haben generell immer über 100 Tunnel in Betrieb und je nach Tageszeit waren so um die 2500 IPv4-Adressen sichtbar, die jeweils in der letzten Stunde eine IPv4-Internet-Verbindung über den VPN03a-Server aufgebaut haben. Der generelle Tagesverbrauch belief sich auf etwa ein Terabyte.

Zur Lastverteilung ist Anfang Dezember 2014 darum ein weiterer VPN-Server in Betrieb gegangen: vpn03b. Dieser Server ist sehr ähnlich konfiguriert. Die Verteilung von VPN-Clients bewerkstelligen wir über Round-Robin-DNS. Unter vpn03.berlin.freifunk.net sind dazu 4 IPv4-Adressen (Stand Oktober 2015) registiert. Derzeit ist es so, dass noch eine größere Anzahl von Clients eine fest eingetragenen IPv4-IP-Adresse verwendet, weswegen der vpn03b weniger ausgelastet ist.

Bekannte Fehler sind:

  • Das hier ist immer noch ein SPOF. Wir haben zwar mehrere Server, aber gegen einen "organisatorischen" Ausfall sind noch keine zusätzlichen Vorkehrungen getroffen.
  • Wir haben mittlerweile natives IPv6, dies ist allerdings noch nicht auf beiden VPN-Servern in Betrieb.
  • Die Integration in die Firmwares schreitet voran, ist aber verbesserungswürdig.

Personen

Technik

Wir haben mehrere VMs, die unter vpn03.berlin.freifunk.net erreichbar sind (DNS-Round-Robin). Dort ist jeweils ein OpenVPN installiert. Eingehende Pakete werden in das Internet weitergeroutet (NAT). Wir haben auf den Servern je 64 IP-Adressen für diesen Zweck. Es gibt eine weitere VM, die freundlicherweise von [Funkfeuer] in Wien betrieben wird: vpn03-backup.berlin.freifunk.net. Diese kann immer nur dann verwendet werden, wenn die Haupt-Server nicht erreichbar sind.

Netzwerk-Details

  • NAT passiert grundsätzlich auf dem VPN-Server. Es gibt einen Pool von Outgoing-IPs.
    • Das ist sinnvoll, damit die Rückrouten angepasst werden können, sobald der jeweilige Client über eine andere Route/SmartGW reinkommt. Bei NAT auf den Freifunk-Knoten würden alle Clients beim Wechsel ihres Gateways die Verbindung zeitweise verlieren, da der VPN-Server die echten Client-IPs nicht sieht und dementsprechend keine (Neu-)Zuordnung vornehmen kann.
  • Rückroute über Tunnel gibt es automatisch, wenn eine Incoming-IP entdeckt wird.
  • Generell: IPs (auch DHCP-IPs) nur aus 6.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12.
  • Doppelte IPs vermeiden (sonst togglen die Rückrouten). Berlin -> neue IP-Vergabe unter config.berlin.freifunk.net.
  • Tunnel sind nicht (nur) für einzelne Freifunk-Knoten, sondern auch für Community-Router mit ganzen Mesh-Netzen dahinter.
  • Schlüssel nur einmal gleichzeitig verwendbar. Neuer Router-mit-Internet, neuer Schlüssel. Wenn die OpenVPN-Verbindung alle Minute beendet und wieder aufgebaut wird ist höchstwahrscheinlich der Schlüssel durch eine andere OpenVPN-Instanz benutzt.
  • Wenn gleichzeitig andere VPNs betrieben werden sollen, z.B. BBB-VPN für Berlin, braucht es eine manuell gesetzte Host-Route für den zweiten VPN-Server. Andernfalls wird der Datenverkehr des zweiten VPNs über das Internet-VPN erfolgen. Das funktioniert, ist aber langsam und sollte nicht sein.
  • Wieso eigentlich der Name Vpn03? Ganz einfach: das hier ist nicht der erste VPN-Dienst, den wir anbieten. Bisher waren diese allerdings eher "interne" Dienste, das hier wird mehr "Public". Immmerhin haben wir ein fetziges Reklamevideo, wo genau diese Ausleitung von Internet-Datenverbindungen versprochen wird. Also sollte es auch das passende Angebot geben.
  • Nicht mehr zutreffend:
    • Kein NAT auf den Tunneln, sonst Zwangsproxy für alle Router-Nutzer zusammen.
    • Ungewöhnlich viele Verbindungen zu verschiedenen Rechnern -> Zwangsproxy(4h).
    • Tipp: VPN-Server hostet Opkg's (OpenVPN+SSL) für OpenWRT-Router mit wenig Platz.

Stapelzertifikate

Bei Diskussionen rund um Ausfallsicherheit und Migration bestehender VPN-Server kam die Frage auf, ob Stapelzertifikate (engl. Stacked Certificates) mit OpenVPN laufen. Das funktioniert sowohl mit der OpenSSL-basierten OpenVPN-Variante als auch mit PolarSSL-Variante.

Hintergrund: wir möchten beispielsweise einen zweiten OpenVPN-Server nutzen, der immer dann verwendet wird wenn der erste OpenVPN-Server mal ausfällt. Damit das funktioniert, müssen beide Server den Verbindungswunsch eines Clients akzeptieren. Man hat also entweder genau eine zentrale Stelle, die RSA-Keys herausgibt (wieder ein SPOF). Oder man macht etwas mit Haupt-CA und Unter-CA (kompliziert, fehleranfällig). Am einfachsten wäre es, wenn ein Server einfach Keys von Dritten akzeptiert. Und das geht mit Stapelzertifikaten.

Und so geht es (Server):

  • Du nimmst die unter der "ca" Option angegeben *.crt zweier Server.
  • Einfach zusammenkopieren: "cat erster-ca.crt zweiter-ca.crt > stacked-ca.crt".
  • Die "ca" Option in der Serverkonfiguration anpassen.

Und jetzt noch einmal (Client):

  • In den erhaltenen Konfigurationen für zwei OpenVPN-Server sind ja *-ca.crt enthalten.
  • Auch hier die CA-Zertifikate zusammenkopieren "cat a-ca.crt b-ca.crt > stacked-ca.crt".
  • Dann noch die "ca" Option in der Clientkonfiguration auf die neue Datei anpassen.

Das war es schon. Und das beste: die CA-Zertifkate kann man einfach veröffentlichen. Da ist nichts geheimes enthalten, die entsprechenden Dateien sind in jeder Client-Konfiguration enthalten (unseres steht hier [3]). Auf dem Server müsste mal allerdings überlegen, von wem bzw. welche CA-Zertifikate man akzeptieren bzw. hinzufügen will.

IPv6

Der OpenVPN-Tunnel zum Server kann auch über IPv6 aufgebaut werden (also: OpenVPN-Transport über IPv6). Dazu ist der DNS-Name des Servers (vpn03.berlin.freifunk.net) mit einem passenden AAAA-Eintrag versehen (2002:4d57:300a:ffff::1). Das funktioniert mit udp6 (Port 1194) und tcp6 (Port 443). Leider gibt es mit IPv6 kein Port-Forwarding, daher funktionieren die mit IPv4 nutzbaren Ausweich-Ports (UDP-53 bzw. TCP-80) nicht mit IPv6.

Troubleshooting

Irgendwas geht immer schief. Damit es bei dir klappt, sind hier ein paar typische Fehlermeldungen und Lösungsvorschläge aufgeschrieben. Wenn du das #OpenWRT_Startscript verwendest einfach mal mit "/etc/init.d/vpn03 debug" starten.

Meldung: write UDPv4: Operation not permitted (code=1)

OpenVPN beschwert sich, dass die Firewall keine Verbindung zum VPN-Server zulässt. Du hast einen konfigurierten WAN-Port, die Internet-Verbindung läuft aber über eine andere Schnittstelle. Lösung: Um z.B. die LAN-Schnittstelle anzugeben führe aus: "/etc/init.d/vpn03 inetvia br-lan". Um die Firewall-Regel zur Verhinderung der Nutzung irgendeines Mesh-Gateways komplett auszuschalten führe aus: "/etc/init.d/vpn03 inetvia disable"

Meldung: VERIFY ERROR: depth=1, error=certificate is not yet valid

Das Datum auf deinem Router stimmt nicht. Ohne Echtzeituhr starten die Geräte mit 1.1.1970. Die Zertifikate und Keys wurden aber alle nach Ende November 2012 erstellt. Lösung: baue in deine Startscripts folgendes ein: "if [ $(date +%s) -lt $(date -d 2012.12.01-00:00:0000000000 +%s) ];then date -s 2012.12.01-00:00:0000000000;fi".

Meldung: Authenticate/Decrypt packet error: cipher final failed

OpenVPN verwendet eine Verschlüsselung, der Vpn03-Server verwendet auf UDP aber keine Verschlüsselung. Lösung: Die fehlende Optionen "cipher none" und evt. auch "comp-lzo no" in deiner OpenVPN-Konfiguration ergänzen.

Meldung: SIGUSR1[soft,ping-restart] received, process restarting (alle Minute)

Der lokale OpenVPN startet regelmäßig neu, wenn die Verbindung zum Vpn03-Server nicht funktioniert. Das kann viele Ursachen haben. Es ist aber auch möglich dass derselbe Client-Schlüssel gleichzeitig noch auf einem anderen Router / Rechner verwendet wird.

Meldung: Keine, aber es geht kein Ping durch den Tunnel

OpenVPN verwendet die LZO-Kompression, der Vpn03-Server verwendet auf UDP aber keine Kompression. Lösung: Die fehlende Option "comp-lzo no" in deiner OpenVPN-Konfiguration ergänzen.

Meldung: Keine, aber internet browsen geht nicht (ausnahme zB openstreetmap geht) normale Pings gehen durch den Tunnel

OpenVPN,(Kabeldeutschland),Vpn03-Server kombinatorisches Problem. Lösung: Derzeit muss du noch selber was editieren aber es wird an einer Lösung gearbeitet. Du musst evtl die Zeile "option mssfix 1355" in deiner OpenVPN-Konfiguration (/etc/config/openvpn) ergänzen.

Meldung: Keine, aber der Tunnel ist zu langsam (nur 100 kByte/sek. bzw. 1 Mbit/s oder so).

Das ist noch nicht ganz 'raus woran das liegen könnte. Aber der Tunnel sollte auf einem Standard-Router etwa 600-900 kByte/sek. übertragen. Evt. hast du die QoS-Scripts in Betrieb: "uci show qos|grep enable". Wenn da "qos.wan.enabled=1" angezeigt wird, musst du auch die Geschwindigkeit deines DSL-Anschlusses korrekt angeben, etwa "uci set qos.wan.upload=10000;uci set qos.wan.download=50000;uci commit" für eine 50Mbit-VDSL.

Note: Geht nicht schneller[4], da das OpenVPN auf dem Router alle Daten user-to-kernel kopieren muss und die Kernel-basierten Tunnelsachen (IPSec und co.) einfach zu kompliziert und fehleranfällig sind. Der VPN-Server hat jedenfalls mind. 10000 kByte/sek bzw. 100 Mbit/s.

Admin Howto

Das Howto findest du auf einer Extra-Wiki-Seite (Vpn03_Admin_Howto).