Die Tage habe ich VPN-Anbieter verrissen und nun hier die Einrichtung von OpenVPN. Wie passt das zusammen?
Ganz einfach VPN ist nicht vom Prinzip her unsinnig sondern ein virtuelles privates Netzwerk hat durchaus seine Daseinsberechtigung. Damit kann man von überall auf der Welt auf sein eigenes Netzwerk inklusiv freigegebener Verzeichnisse wie z.B. einen Netzwerkspeicher (NAS), lokale Dienste, lokale Drucker usw. zugreifen. Ein Rechner der über ein VPN verbunden ist verhält sich exakt genauso als wäre er dort im Netzwerk obwohl er weit entfernt und übers Internet über eine verschlüsselte Verbindung dort eingewählt ist. Der Rechner hat daher zwei IP-Adressen – eine IP-Adresse für die Internetverbindung und eine IP-Adresse aus der IP-Range von dem Netzwerk mit dem er per VPN verbunden ist.
In dieser mehrteiligen Serie will ich beschreiben wie man eine solchen Dienst einrichtet und die VPN-Verbindung herstellt. Dabei ist es egal ob die des sich um eine VPN eines Rechners oder eines Smartphone handelt. Eine VPN-Verbindung ist von der Geschwindigkeit einer direkten Verbindung hoffnungslos unterlegen und taugt nicht dazu um Mediendateien wie Filme darüber abzuspielen aber kann einem durchaus den Hintern retten wenn man irgendwo auswärts eine Datei benötigt die nur auf seinem lokalen NAS liegt und man vergessen hat die aktuelle Version auf den USB-Stick zu kopieren.
Üblicherweise ist sein lokales Netzwerk per Router und NAT (network address translation) angebunden. Das heißt man hat genau eine öffentliche IP-Adresse nämlich die des Routers und alle Rechner dahinter haben eine private IP-Adresse (oft im Schema wie beispielsweise 192.168.1.34 oder 10.0.3.44). Diese privaten IP-Adressen werden per Definition nicht geroutet – sprich über den Router geleitet – sondern der Router manipuliert die Datenpakete so, dass sie seine öffentliche IP als Absenderadresse bekommen und merkt sich für die Antwortpakete an welche private IP-Adresse das Antwortpaket endgültig ausgeliefert werden muss. Daher sind solche Netzwerke üblicherweise nicht von außen erreichbar.
Aufgrund des bisher aufgeführten scheint es unmöglich zu sein Dienste wie VPN, die sich im lokalen Netzwerk befinden, von außen erreichbar zu machen. Wir haben hier zwei Probleme:
- Normalerweise hat man vom Internetprovider eine dynamische IP-Adresse welche sich regelmäßig (meist innerhalb von 24 Stunden) ändert und damit nicht per Domainnamen erreichbar ist
- Durch das NAT, wie oben erläutert prallt jede Anfrage von außen am Router ab
Für beides gibt es Lösungen. Das Problem mit den Domainnamen kann man durch die Nutzung eines DynDNS-Anbieters lösen. Viele Hersteller von Routern bieten dafür mehr oder minder vorgefertigte Lösungen in ihrer Routerfirmware an. Man erhält von DynDNS-Anbieter eine Subdomain nach dem Muster example.dyndns.com wobei der Teil dyndns.com auf den DynDNS-Anbieter verweist und dieser löst die Subdomain example auf die eigene IP-Adresse auf. Die Routerfirmware aktualisiert bei jedem wechsel der IP-Adresse die Datenbank des DynDNS-Anbieters.
Falls man eine Fritzbox sein eigen nennt und eine eigene Domain besitzt gibt es jedoch noch eine elegantere Lösung die unabhängig von DynDNS-Anbietern funktioniert denn diese Anbieter wollen auch Geld verdienen und bieten oft nur kostenfrei einen minimalen oder werbeverseuchten Dienst an. Jede moderne Fritzbox hat jedoch die Möglichkeit einer myfritz-Subdomain in wenn man das einrichtet. Zur Einrichtung hat der Hersteller AVM eine Anleitung verfasst. Diese myfritz-Subdomains sind allerdings alles andere als irgendwie generisch oder handlich. Das kann man jedoch auch ändern wenn man eine normale Internetdomain wie example.org hat denn man braucht hier nur in die DNS-Einstellungen seines Domainanbieters gehen und dort eine Subdomain wie heim.example.org anlegen und diese dann als C-Name auf seine myfritz-Adresse verweisen. Diese Lösung ist eine sehr kostenarme Lösung da man eigentlich nicht auf kostenpflichtige Dienste angewiesen ist und auch nicht darauf vertrauen muss das es auch so bleibt. Sein Heimnetz ist nun immer unter beispielsweise heim.example.org zu erreichen.
Das zweite Problem ist an genau der Stelle lösbar an der es entsteht. Alle Internetdienste werden über sogenannte Ports mit den Protokollen TCP oder UDP angesprochen. Die Portnummern sind standardisiert. Man finden auf jedem Linux oder Unix-Rechner eine solche Liste mit Standardports unter /etc/services. So ist der Dienst http regulär immer unter Port 80 und https unter Port 443 und ssh unter Port 22 und alles TCP erreichbar. Die Unterschiede zwischen TCP und UDP sind zwar elementar aber soll in diesem Zusammenhang nicht diskutiert werden da wir hier nur mit den Standardeinstellungen der Dienste arbeiten werden. Änderungen der Standardports sind zwar möglich und in manchen Fällen auch sinnvoll bzw. nötig oder werden aus security-through-obscurity-Gründen für nötig gehalten.
Die Lösung für das Problem was oben geschildert wurde führt nun über die Ports denn genau diese kann man über den Router auf einen anderen Rechner im lokalen Netzwerk weiterleiten. Sprich man kann den Port 80 an einen Webserver unter der lokalen IP-Adresse 192.168.10.20 weiterleiten und dort einen Webserver betreiben. Von außen sieht das so aus, als würde auf dem Router ein Webserver laufen aber tatsächlich läuft der auf einer völlig anderen Hardware. Wenn man ein Portforwarding, so ist der Fachbegriff für diese Technik, einrichtet muss man sicherstellen, dass sein Zielgeräte auf dem aktuellen Patchstatus ist und völlig sicher betrieben werden kann denn so schafft man sich ein Einfallstor für Angreifer wenn man einen unsicheren Rechner dahinter betreibt. Manche Dienste wie Dateifreigaben beispielsweise sollte man überhaupt nicht so betreiben da sie potentiell unsicher sind und ebenfalls keine Dienste wie beispielsweise einen Email-Server der darauf angewiesen ist das sowohl der DNS-Eintrag richtig ist, was wir sichergestellt haben, aber auch darauf das die umgekehrte Richtung (reverse lookup), Auflösung von IP-Adresse in die Domain, funktioniert. Letzteres kann man mit einer dynamischen IP-Adresse aber nicht erreichen da wir dafür einen Zugang zum DNS-Server des Internetproviders bräuchten.
