OpenVPN mit Knoten
3. Juli 2016 um 22:08 Uhr von Atari-Frosch
Nachdem ich mich vorgestern mit einem verknoteten Mailsystem herumgeschlagen habe, war heute der Umzug des OpenVPN auf den neuen Server dran. Da hatte ich auch erstmal einige Knoten. Teils im System, teils im Gehirn 😉
Es wäre echt zu leicht gewesen, nach der Installation, der Erzeugung der Zertfikate und Keys und der Anpassung der Client-Konfiguration da jetzt einfach über das neue VPN routen zu können. Aber: Obwohl die Verbindung zum neuen Server stand wie eine Eins, ging nichts durch. Also, gar nichts. Ich konnte zu keinem anderen System verbinden als dem Server selbst, zu allen anderen Systemen hieß es: „network not reachable“.
Der generelle Haken bei solchen Dingen besteht darin, daß ich solche Dienste nur alle paar Jubeljahre mal neu einrichten muß. Also mußte ich wieder auf die Suche gehen: Wie war das nochmal? Und warum funktioniert das auf dem alten Server?
Die meisten Anleitungen, die man so im Netz findet, beziehen sich nur auf das Paket openvpn und vielleicht noch easy-rsa, berücksichtigen aber nicht das Routing auf dem Hostsystem. Entweder gehen sie davon aus, daß der Host schon richtig konfiguriert sein werde, oder davon, daß man doch einfach weiß, was man im System noch einstellen muß, damit das OpenVPN auch nutzbar wird.
Also, was macht man nun, wenn die Verbindung als solche perfekt funktioniert, aber einfach keine Daten durchrouten will?
Das erste ist: Überhaupt erstmal Routing freischalten. Das ist auf einem neu installierten Debian-System nicht automatisch der Fall – vermutlich aus Sicherheitsgründen. Leider wird das auch mit der Installation von OpenVPN nicht geändert, obwohl es dafür doch unbedingt notwendig ist.
Also:
seelilie:~# echo 1 > /proc/sys/net/ipv4/ip_forward
seelilie:~# echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
Zwar habe ich IPv6 für das OpenVPN generell noch nicht aktiviert, aber dem System kann man's ja schonmal verklickern.
Damit war's allerdings leider noch nicht getan. Erst ein Blogartikel von Allan McRae mit dem Titel Routing Traffic With OpenVPN brachte mich auf den richtigen Weg. In seinem Step #3 widmet er sich nämlich iptables, der Firewall. Der muß man noch ein paar Dinge beibiegen, damit OpenVPN auch tatsächlich den Traffic seiner Clients routen kann. Gegenüber Allans Beschreibung habe ich nur das Device verändert; er verwendet das tun-Device, ich dagegen tap. Außerdem verwende ich nicht den Standard-Port 1194, lasse diesen hier aber trotzdem stehen:
seelilie:~# iptables -A INPUT -i eth0 -m state --state NEW -p udp --dport 1194 -j ACCEPT
seelilie:~# iptables -A INPUT -i tap+ -j ACCEPT
seelilie:~# iptables -A FORWARD -i tap+ -j ACCEPT
seelilie:~# iptables -A FORWARD -i tap+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
seelilie:~# iptables -A FORWARD -i eth0 -o tap+ -m state --state RELATED,ESTABLISHED -j ACCEPT
Die zusätzliche, optionale Zeile, die er noch weiter unten erwähnt, brauchte ich hier nicht.
Nach der Änderung mußte ich nur noch OpenVPN neu starten, sowohl auf dem Server als auch auf dem Client, und endlich ging alles durch. Bis auf IPv6, das ist noch eine offene Baustelle. Später.
Ich hoffe, der Kram, der jetzt noch auf dem alten Server übrig ist, kostet mich nicht auch jeweils noch einen ganzen Abend pro Dienst …
5. Juli 2016 at 10:08
Falls die Verbindung über IPv6 aufgebaut werden soll, dann sollte man auch an die entsprechenden ip6tables-Regeln denken (sowie „proto udp6“, „remote foo.example.com 1194 udp6“).
Wenn dann noch die Verbindung trotzdem nicht richtig aufgebaut wird oder hängenbleibt, dann kann man auch noch Spaß mit MTU/MSS haben … Hatte so dann auch ein paar Stunden gebraucht für das letzte Setup. 🙂
Empfehlenswert ist m.E. übrigens „remote-cert-tls server“ zu nutzen und „cipher AES-256-CBC“ explizit vorzugeben, wenn möglich (für manches ist evtl. OpenVPN 2.1+ notwendig).