Mit dem VPN hinter eine Firewall

Ich mag VPNs. Vor allem das P darin. Und wenn man öfter mal in nicht vertrauenswürdigen Netzen unterwegs ist, ist das auch eine tolle Sache. Nun hat sich mein neuer Internet-Provider entschieden, dass ich nur IPv6 „richtig“, aber mit dynamischem Netzpräfix bekomme, IPv4 dafür nur über Carrier-NAT. Wenn ich zuhause sitze und surfe, ist das auch völlig egal. Die Adressumsetzung macht der Provider (so wie es früher meine Fritz!Box getan hat). Das Problem: die meisten DynDNS Provider können auch nach fast 10 Jahren Vorlauf kein IPv6. Und aus einem IPV4-Netz kommt man so einfach nicht an ein IPv6-Only-Netz.

Das Problem

Ich komme nicht mehr an meinen zentralen Messaging-Server, nicht an mein NAS, nicht an meinen Rechner zu hause und wenn ich in fremden (und offenen) WLAN-Netzen unterwegs bin: Keine sichere Verbindung zu nicht-https-Seiten. Und in offenen WLANs mit vielen Gästen traue ich im Zweifel auch nicht mal HTTPS. Da habe ich bisher meinen Raspberry via SSH verwendet.

Erster Anlauf: (auto-)ssh und Reverse Tunnel

Mein erster Ansatz war, einen vServer mit Reverse-Tunnels zu bestücken. Das hat geplappt, war aber insgesamt recht unflexibel und die Verbindung über den Reverse-Tunnel direkt auf den Raspberry war stellenweise einfach zu instabil, so dass keine stabile (direkte) Verbindung in mein Heimnetz (mit Zugriff auf das NAS) möglich war.
Sprich: habe ich vom Raspberry aus via

ssh -R 8080:localhost:22

eine Verbindung erstellt, und dann von (ganz) außen via

ssh vserver -p 8080

darauf zugegriffen, so war die Verbindung in der Regel deutlich instabiler als der Zugriff zum vServer via SSH. Der Zugriff vom vServer auf den Reverse-Tunnel auf den Raspberry war allerdings extrem stabil. Ich bin nicht sicher, ob das Problem nicht bei meinem Putty lag. Allerdings hat das ganze auch Nachteile, wenn es stabil läuft: Ich benutze immer mittels des vServers meinen Raspberry als Proxy. Das ist 1 „Hop“ mehr als notwendig sein sollte. Den vServer als 100Mbit/s-Proxy nutzen und nur den Verkehr ins lokale Netz über den Raspberry routen, das wäre die optimale Lösung. Daher: Ein echtes VPN muss her.

Zweiter Anlauf: OpenVPN, aber mit Anlauf!

OpenVPN LogoOpenVPN. Bewährt, verbreitet, flexibel, unter Linux zuhause. Installation auf Raspian und dem dem Wheezy-vServer: ein einfachen apt-get install openvpn. VPN schön und gut, aber in einem klassischen steht ja der Server ganz oder einbeinig (DMZ) in dem Netz, in welches ich will, bei Unternehmen ist das in der Regel die Firewall, die so etwas anbietet. Astaro/Sophos und Securepoint bieten so etwas z.B. von Haus aus an.

Nun habe ich die Besonderheit, dass mein VPN-Server komplett außerhalb meines Zielnetzes steht, ich aber in das Netz hinter einem bestimmten Client (im Zielnetz) routen will. Die Anleitung „ServerNET zu ClientNET“ hat mich auch schon ein ganzes Stück weitergebracht. Ich konnte vom Raspberry (der Client im lokalen Netz) die VPN-Adresse des Servers pingen, der Server konnte die VPN-Adresse des Raspberrys pingen. Auch vom Server auf die LAN-IP des Raspberrys konnte ich pingen. Aber auf kein anderes Gerät.

Nach viel ausprobieren und gefrage, fand ich dann auf der OpenVPN-Seite die Antwort. Ich bin linuxmäßig bewandeter als in Netzwerktechnik. Ich in davon ausgegangen, dass wie beim NAT der Rückweg einer Verbindung auch bekannt sein sollte. Dem ist nicht so.Ich habe die Route ins 10er (VPN-) Netz dann in der Fritz!Box eingetragen und seitdem geht alles wie es soll. Inklusive Zugriff auf das lokale Netz vom vServer aus.

Nächster Schritt wird dann sein, den Zugriff vom Notebook und Handy soweit hinzubekommen, dass der Verkehr komplett über das VPN und bei Bedarf ins lokale Netz geroutet wird.

7 Antworten auf „Mit dem VPN hinter eine Firewall“

  1. Moinsen,

    es gibt 2 Varianten, die für dich interessant sein könnten.

    1. redirect-gateway per OpenVPN, so dass aller Traffic, außer natürlich der für die VPN-Verbindung, durch den Tunnel zum VServer geleitet wird.
    2. ein Proxy-Server, der alle Verbindungen entgegen nimmt, und dann selbst die Verbindungen zu den Webseiten öffnet.

    Der Vorteil bei Variante 1 ist die Tatsache, dass der Client keine Route kennen muss, da alle Informationen am „neuen“ Gateway verfügbar sind. Dafür ist bei der Variante 2 die Möglichkeit vorhanden, nur bestimmte Verbindungen über den Tunnel zu betreiben, z.B. nur HTTPS-Verbindungen, um diese zusätzlich abzusichern.

    Des weiteren muss man bei „Smartphones“ ein Hindernis beachten. Android-Geräte können zwar OpenVPN, allerdings nur als „Point-to-Point-Verbindung“ (tun-device), wenn also, wie es bei mir eingerichtet ist, eine normale Verbindung genutzt wird (tap-device), so muss für Android-Devices eine eigene OpenVPN-Konfiguration angelegt werden, die etwas schwieriger zu benutzen ist.

    Ich hoffe, ich konnte damit einen kleinen Überblick über die Möglichkeiten geben, bei Fragen bin ich auch gerne bereit, diese möglichst ausführlich zu beantworten.

Kommentare sind geschlossen.