Kommerzielle VPN-Anbieter suggerieren oft in YouTube-Videos, dass VPNs unverzichtbar für Sicherheit und Privatsphäre sind, besonders in unsicheren WLANs. Jedoch ist diese Botschaft nicht nur größtenteils irreführend, sondern ein VPN kann die Sicherheit und Privatsphäre in vielen Situationen eher beeinträchtigen, wie dieser Beitrag erklärt. Trotzdem gibt es gelegentlich Szenarien, in denen ein VPN sinnvoll ist. Hier erfährst du, wie man in solchen Fällen einen eigenen VPN-Server einrichten kann.
Zuerst sehen wir uns exemplarisch an, was genau passiert, wenn wir beispielsweise in einem McDonalds-WLAN die Website resch.cloud aufrufen:
User tippt resch.cloud in den Browser am Laptop
Browser fragt DNS-Server des McDonalds-Netzwerks (Lokaler Router), wie die IP-Adresse von resch.cloud lautet
DNS-Server des Netzwerks weiß es nicht und fragt einen öffentlichen DNS-Server (z.B. 8.8.8.8 von Google)
Dieser, nehmen wir an, kennt die Antwort und sendet sie an den DNS-Server des Netzwerks: resch.cloud hat die Adresse 188.40.30.46
DNS Server des Netzwerks speichert die Antwort und gibt sie dem Browser weiter
Browser baut eine HTTPS-Verbindung zu der genannten IP-Adresse auf
Jetzt besteht eine verschlüsselte Verbindung zwischen dem Laptop und der Website resch.cloud und alle weiteren Daten werden innerhalb dieser Verbindung ausgetauscht
Ruft der User eine andere Website auf, beginnt dieser Prozess von vorne
VPN steht für Virtual Private Network und ist technisch gesehen nichts anderes als eine Tunnelverbindung zwischen einem Endgerät (z.B. Laptop) und einem VPN-Server. Eine Tunnelverbindung kann man sich wie ein Verlängerungskabel durch das Internet vorstellen, an dem man von außen nicht erkennen kann, welche Daten darin übertragen werden. Skizzieren wir also obigen Prozess erneut, nur diesmal mit VPN:
User aktiviert VPN am Laptop
Laptop fragt DNS-Server des McDonalds-Netzwerks, wie die IP-Adresse des VPN-Servers vpnserver.example.com lautet
DNS-Server des Netzwerks weiß es nicht und fragt einen öffentlichen DNS-Server (z.B. 8.8.8.8 von Google)
Dieser, nehmen wir an, kennt die Antwort und sendet sie an den DNS-Server des Netzwerks: vpnserver.example.com hat die Adresse 1.2.3.4
DNS Server des Netzwerks speichert die Antwort und gibt sie dem Laptop weiter
Laptop baut VPN-Tunnel zum VPN-Server auf. Alle Daten, die der Laptop sendet, gehen nun durch diesen verschlüsselten Tunnel
User tippt resch.cloud in den Browser am Laptop
Browser fragt DNS-Server des VPN-Providers, wie die IP-Adresse von resch.cloud lautet
DNS-Server des VPN-Providers weiß es nicht und fragt einen öffentlichen DNS-Server (z.B. 8.8.8.8 von Google)
Dieser, nehmen wir an, kennt die Antwort und sendet sie an den DNS-Server des VPN-Providers: resch.cloud hat die Adresse 188.40.30.46
DNS Server des VPN-Providers speichert die Antwort und gibt sie dem Browser weiter
Browser baut eine TLS-Verbindung (HTTPS) zu der genannten IP-Adresse durch den VPN-Tunnel auf
Jetzt besteht innerhalb des Tunnels eine verschlüsselte Verbindung zwischen dem Laptop und der Website resch.cloud und alle weiteren Daten werden innerhalb dieser Verbindung ausgetauscht
Ruft der User eine andere Website auf, beginnt dieser Prozess ab Punkt 7 erneut
Zusätzlich sei noch erwähnt, dass der Webserver resch.cloud im ersten Fall (ohne VPN) die Absender-IP-Adresse des McDonalds-Netzwerks sieht und im zweiten Fall (mit VPN) die Absender-IP-Adresse des VPN-Servers. Außerdem ändert der VPN-Tunnel nichts an der Verbindung zwischen dem VPN-Server und dem Webserver.
Also fassen wir zusammen, wer nun welche Daten des Users kennt:
OHNE VPN
MIT VPN
McDonalds
– Adresse der Website – Dauer der Verbindung zu dieser – Menge der übertragenen Daten – Zeitpunkt der Verbindung – Hersteller meines Endgeräts
– Adresse des VPN-Providers – Dauer der Verbindung zu diesem – Menge der übertragenen Daten – Zeitpunkt der Verbindung – Hersteller meines Endgeräts
VPN-Provider
– Klarname des Users – Zahlungsmittel – evtl. Adresse – Adresse der Website – Dauer der Verbindung zu dieser – Menge der übertragenen Daten – Zeitpunkt der Verbindung – Hersteller meines Endgeräts – Standort (McDonalds-IP-Adresse)
Website-Provider
– Art des Browsers und des Endgeräts – Dauer der Verbindung – Menge der übertragenen Daten – Inhalt der übertragenen Daten – Zeitpunkt der Verbindung
– Art des Browsers und des Endgeräts – Dauer der Verbindung – Menge der übertragenen Daten – Inhalt der übertragenen Daten – Zeitpunkt der Verbindung – Adresse, und damit Identität, des VPN-Providers
Wie man also auf den ersten Blick erkennen kann, fallen bei der Nutzung eines VPN wesentlich mehr Daten an mehr verschiedenen Stellen an. Des Weiteren existiert beim VPN-Provider, bei dem man sich üblicherweise anmelden muss und auch Zahlungsdaten hinterlegen muss, eine direkte Verknüpfung zwischen den Nutzungsdaten und den echten persönlichen Daten des Users. Außerdem fällt auf, dass die eigentlichen Nutzdaten, also beispielsweise Logindaten oder E-Mails, ohnehin innerhalb der TLS-Verbindung (HTTPS) verschlüsselt übertragen werden. Für normalsterbliche Menschen ist die Nutzung eines kommerziellen VPN im Sinne von Datenschutz oder Privatsphäre also weitgehend sinnlos, wenn nicht sogar kontraproduktiv.
Natürlich gibt es trotzdem gute Gründe, einen VPN-Dienst zu nutzen oder sogar selbst einen VPN-Server zu betreiben: Änderung der eigenen externen IP-Adresse und damit des scheinbaren Standorts, um beispielsweise Inhalte zu konsumieren, die nur in bestimmten Ländern verfügbar sind oder um Produkte oder Leistungen zu günstigeren Preisen zu erwerben (Mietwagen, Hotels, Streaming-Abos) oder Umgehung von Netzfiltern, Zensurmaßnahmen oder einfach übertriebener Überwachung indem man einen Tunnel aus dem Schul- oder Firmennetz oder sogar aus dem Land hinaus aufbaut, sodass die Verwaltung dieser Netze keine Möglichkeit hat, beispielsweise bestimmte Websites oder Dienste zu blockieren.
Daher erkläre ich hier, wie man ohne große Vorkenntnisse einen eigenen VPN-Server aufsetzt und konfiguriert.
VPN-Server aufsetzen
Hosting-Provider auswählen
Zuallererst muss man sich über den Standort des Servers Gedanken machen, da dieser über dessen öffentliche IP-Adresse und damit über den scheinbaren Standort bestimmt. Viele große Hosting-Anbieter haben Rechenzentren an unterschiedlichen Standorten, die man bei der Erstellung des Servers auswählen kann. Ich nutze wie immer Hetzner, der Standorte in Deutschland, Finnland und den USA hat (Empfehlungslink für 20 € Guthaben). Da ich persönlich gerne Inhalte aus deutschen TV-Mediatheken konsumieren will, die in Österreich nicht zur Verfügung stehen, wähle ich für dieses Beispiel ein deutsches Rechenzentrum. Abgesehen von der Erstellung des Servers unterscheidet sich der folgende Vorgang aber nicht, wenn man einen anderen Anbieter wählt.
Server erstellen
Unter https://console.hetzner.cloud/projects erstelle ich ein neues Projekt. Darin erstelle ich einen neuen Server des kleinsten Typs CAX11 am Standort Falkenstein. Als Betriebssystem wähle ich Ubuntu 22.04. Weitere Konfigurationen sind nicht nötig.
Die IP-Adressen und das root-Passwort kommen per Mail, sofern man bei der Erstellung keinen SSH-Key hinterlegt hat. Jetzt kann man sich mit einem beliebigen SSH-Client zum Server verbinden. Ich verwende dazu MobaXTerm.
Falls man auf die Sicherheit der Daten, die am eigenen Server anfallen werden, besonders großen Wert legt, kann man den gesamten Cloud Server auch verschlüsseln. Damit ist es auch dem Hosting-Anbieter nicht mehr möglich, auf das Dateisystem und damit z.B. Logs zuzugreifen. Dieser Schritt muss vor der Installation geschehen. Wie das bei Hetzner geht, ist hier erklärt: https://community.hetzner.com/tutorials/install-ubuntu-2004-with-full-disk-encryption
Betriebssystem vorbereiten
Bei Hetzner muss man zuerst das Passwort ändern. Anschließend könnte man einen neuen User anlegen und mit diesem weiterarbeiten oder einfach weiterhin root verwenden.
Ich aktualisiere das Betriebssystem und alle Pakete:
apt update && apt upgrade
Folgende Befehle aktivieren die Firewall, erlauben aber weiterhin Zugriff auf den Server per SSH:
ufw allow ssh
ufw enable
Wireguard
WireGuard ist ein modernes, schlankes und schnelles Tunnelprotokoll. Es verwendet asymmetrische Kryptographie zur Authentifizierung und Transportverschlüsselung. Jeder Endpunkt ist gegenüber seiner Gegenstelle(n) ein „Peer“ und es gibt keine feste Server-Client-Architektur. Die Identifikation der Endpunkte erfolgt anhand der zugewiesenen IP-Adresse(n) und des Public Keys. Im Gegensatz zu manchen anderen Tunnelprotokollen ist es daher auch möglich, dass sich mehrere Peers von derselben öffentlichen IP-Adresse zu derselben Gegenstelle verbinden. Wireguard ist ein quelloffenes Protokoll.
In WireGuard-Ordner wechseln (oder mit mkdir -m 700 /etc/wireguard erstellen, falls der Ordner noch nicht existiert)
cd /etc/wireguard/
Schlüsselpaar für WireGuard erstellen
umask 077
wg genkey > private
wg pubkey < private
umask 077 bedeutet, dass Prozesse, die nach Ausführung des Befehls Dateien erstellen, die mit 077 definierten Berechtigungs-bits NICHT setzen dürfen. Konkret heißt das: Wenn Wireguard die Schlüssel erstellt, werden dafür höchstens die Berechtigungen 700 gesetzt (Owner darf alles, andere dürfen nichts). Alternativ könnte man auch nach der Erstellung der Datei private mittels chmod 700 private oder chmod 600 private zum selben Ergebnis gelangen. Tipp: https://chmod-calculator.com
Öffentlichen Schlüssel (public key) notieren. Dieser wird später benötigt. Außerdem exportiere ich den privaten Schlüssel, den ich im nächsten Schritt brauchen werde. Dieser sollte aber keinesfalls irgendwo notiert und aufbewahrt werden!
cat private
Konfiguration
Zuerst erstelle ich mit nano /etc/wireguard/wg0.conf eine Konfigurationsdatei und befülle sie wie folgt.
[Interface]
# Adressen, die das Wireguard-Interface des Servers bekommen soll.
# Das IPv6-Präfix sind die ersten vier Gruppen der öffentlichen IPv6-Adresse des Servers.
Address = 172.16.42.1/24, <IPV6_PREFIX>::42:1/112
ListenPort = 51234
PrivateKey = <Kpriv Server>
SaveConfig = false
# Scripts, die beim (De-)aktivieren des Interfaces ausgeführt werden sollen:
PostUp = /etc/wireguard/add-nat-routing.sh
PostDown = /etc/wireguard/remove-nat-routing.sh
Linux-Server zum Router machen
Damit der Linux-Server als Router agiert, müssen zuerst ein paar Firewall-Einstellungen getroffen werden. Das mache ich mittels zweier Scripts, die Ausgeführt werden, sobald das WireGuard-interface aktiviert bzw. deaktiviert wird.
Mit nano /etc/wireguard/add-nat-routing.sh erstelle ich das erste Script und füge folgenden Inhalt ein. Es erzeugt Firewall-Regeln, die WireGurad-Verbindungen zum Router sowie Datenverkehr zum und durch den Router zulassen. Außerdem wird Masquerading (NAT) aktiviert, sodass der Router bei ausgehenden Verbindungen die tatsächlichen Quelladressen durch die eigenen öffentlichen Adressen ersetzt.
Die Zeile $IPT6 -t nat -I POSTROUTING 1 -s $SUB_NET_6 -o $IN_FACE -j MASQUERADE ist funktional nicht erforderlich, da in der Welt von IPv6 ohnehin jeder Client eine öffentliche Adresse haben kann. Sie dient aber dazu, dass für einen Webserver die unterschiedlichen Clients nicht unterscheidbar sind, da die Verbindungen immer von der Adresse des Servers ausgehen.
Mit nano /etc/wireguard/remove-nat-routing.sh erstelle ich das zweite Script und füge folgenden Inhalt ein, der die Firewall-Regeln wieder entfernt, sobald das WireGuard-Interface down geht.
wg-quick ist ein Teil des Pakets wiregurd-tools und automatisiert die Erstellung von Tunnelinterfaces anhand von Konfigurationsdateien und kümmert sich darum, dass bei Systemstart alles wieder korrekt aktiviert wird.
Client hinzufügen
Der VPN-Server ist nun weitestgehend fertig. Um ihn zu nutzen, muss man natürlich zumindest einen Client einrichten. Ich erkläre den Prozess am Beispiel der Wireguard-App für Windows, das Schema ist aber auch bei anderen Betriebssystemen fast identisch. Unter https://www.wireguard.com/install/ kann man die gewünschte Anwendung herunterladen.
Anwendung öffnen –> Tunnel hinzufügen –> Einen leeren Tunnel hinzufügen...
Es öffnet sich ein Fenster, das den Namen der Verbindung, den öffentlichen Schlüssel des Clients und die Konfigurationsdatei, enthält. Letztere beinhaltet bereits zwei Zeilen. Ich ergänze sie wie folgt:
[Interface]
PrivateKey = <Kpriv Server>
# Eindeutige Adressen aus den zuvor definierten Adressbereichen:
Address = 172.16.42.101/24, <IPV6_PREFIX>::42:101/112
DNS = 9.9.9.9, 2620:fe::10
[Peer]
# Public Key des Servers:
PublicKey = <Kpub Server>
AllowedIPs = 0.0.0.0/0, ::/0
# Öffentliche Adresse oder Hostname und zuvor definierter Port des Servers:
Endpoint = <SERVER-IP>:51234
PersistentKeepalive = 15
Die Adressen unter Addresses sind beispielsweise so zu wählen, dass der erste Client …101 bekommt, der zweite Client …102 usw. Falls man den Server auch als DNS-Resolver (z.B. mit Pihole) konfiguriert hat, so sind bei DNS die Adresse des Servers anzugeben. Die Option Blockiere Verkehr außerhalb des Tunnels sollte aktiviert werden.
Im letzten Schritt muss man am Server noch erlauben, dass sich dieser Client auch anmelden darf. Das passiert, indem man erneut die Konfigurationsdatei wg0.conf bearbeitet:
nano /etc/wireguard/wg0.conf
Am Ende der Datei ist für jeden Client folgendes anzufügen. AllowedIPs definiert dabei, welche Absenderadressen am anderen Ende des Tunnels erlaubt werden sollen. Diese sind als einzelne Adressen (/32 bzw. /128 anzugeben):
Viel Pflege braucht so ein VPN-Server nicht, es sind aber unbedingt regelmäßige Updates zu installieren. Das geht ganz einfach mit apt update && apt upgrade.
Fazit und weitere Möglichkeiten
Wenn man nun den Tunnel am Client aktiviert (In Windows z.B. mittels Rechtsklick auf das Tray-Icon), fließt sämtlicher Netzwerkverkehr durch den Tunnel zum Server und gelangt erst von dort aus ins „öffentliche“ Internet. Überprüfen kann man das, indem man beispielsweise wtfismyip.com aufruft. Dort sollten die öffentlichen Adressen des Servers zu sehen sein, sobald der Tunnel aktiv ist.
Der Vollständigkeit halber sei noch erwähnt, dass natürlich auch im hier dargestellten Fall eine Zuordnung des Servers und damit der IP-Adressen zu der Person, die den Hosting-Account bezahlt möglich ist. Wer besonders auf Anonymität angewiesen ist, sollte immer mit einem Dienst arbeiten, den man ohne den Austausch personenbezogener Daten nutzen kann. Hier kann man beispielsweise Mullvad VPN empfehlen, wo man tatsächlich auch mit Bargeld bezahlen kann. Zusätzlich zu einem VPN sollte man dann auch das Tor-Netzwerk nutzen.
Natürlich bietet es sich an, den Server auch für andere Dinge zu verwenden. Beispielsweise könnte man ihn mittels Pihole (und Unbound) zu einem DNS-Resolver mit integriertem Werbeblocker machen:
Wenn du Feedback loswerden möchtest, nutze bitte das Kontaktformular.
Falls dir mein Beitrag weitergeholfen hat, würde ich mich sehr über einen kleinen Kaffee freuen. Oder du nutzt einen meiner Empfehlungslinks und sparst dir damit etwas Geld: Tesla (500€ Rabatt), Hetzner Cloud (20€ Guthaben), Ufodrive (30€ Rabatt). Außerdem habe ich eine Wunschliste bei Amazon.
