Warum VPN meist nutzlos sind und wie man einen eigenen VPN-Server aufsetzt

Lesezeit: 13 Minuten

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.

Einleitung

Zuerst sehen wir uns exemplarisch an, was genau passiert, wenn wir beispielsweise in einem McDonalds-WLAN die Website resch.cloud aufrufen:

  1. User tippt resch.cloud in den Browser am Laptop
  2. Browser fragt DNS-Server des McDonalds-Netzwerks (Lokaler Router), wie die IP-Adresse von resch.cloud lautet
  3. DNS-Server des Netzwerks weiß es nicht und fragt einen öffentlichen DNS-Server (z.B. 8.8.8.8 von Google)
  4. 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
  5. DNS Server des Netzwerks speichert die Antwort und gibt sie dem Browser weiter
  6. Browser baut eine HTTPS-Verbindung zu der genannten IP-Adresse auf
  7. Jetzt besteht eine verschlüsselte Verbindung zwischen dem Laptop und der Website resch.cloud und alle weiteren Daten werden innerhalb dieser Verbindung ausgetauscht
  8. 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:

  1. User aktiviert VPN am Laptop
  2. Laptop fragt DNS-Server des McDonalds-Netzwerks, wie die IP-Adresse des VPN-Servers vpnserver.example.com lautet
  3. DNS-Server des Netzwerks weiß es nicht und fragt einen öffentlichen DNS-Server (z.B. 8.8.8.8 von Google)
  4. 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
  5. DNS Server des Netzwerks speichert die Antwort und gibt sie dem Laptop weiter
  6. Laptop baut VPN-Tunnel zum VPN-Server auf. Alle Daten, die der Laptop sendet, gehen nun durch diesen verschlüsselten Tunnel
  7. User tippt resch.cloud in den Browser am Laptop
  8. Browser fragt DNS-Server des VPN-Providers, wie die IP-Adresse von resch.cloud lautet
  9. DNS-Server des VPN-Providers weiß es nicht und fragt einen öffentlichen DNS-Server (z.B. 8.8.8.8 von Google)
  10. 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
  11. DNS Server des VPN-Providers speichert die Antwort und gibt sie dem Browser weiter
  12. Browser baut eine TLS-Verbindung (HTTPS) zu der genannten IP-Adresse durch den VPN-Tunnel auf
  13. 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
  14. 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 VPNMIT 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.

Installation

apt install wireguard && apt install wireguard-tools

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.

#!/bin/bash
IPT="/sbin/iptables"
IPT6="/sbin/ip6tables"          
 
IN_FACE="eth0"                       # Interface mit Internetzugang
WG_FACE="wg0"                        # Wireguard-Interface 
SUB_NET="172.16.42.0/24"             # Wireguard IPv4-Subnetz
WG_PORT="51234"                      # Wireguard UDP-Port
SUB_NET_6="<IPV6_PREFIX>::42:0/112"  # Wireguard IPv6-Subnetz
 
## IPv4 ##
$IPT -t nat -I POSTROUTING 1 -s $SUB_NET -o $IN_FACE -j MASQUERADE
$IPT -I INPUT 1 -i $WG_FACE -j ACCEPT
$IPT -I FORWARD 1 -i $IN_FACE -o $WG_FACE -j ACCEPT
$IPT -I FORWARD 1 -i $WG_FACE -o $IN_FACE -j ACCEPT
$IPT -I INPUT 1 -i $IN_FACE -p udp --dport $WG_PORT -j ACCEPT
 
## IPv6 ##
$IPT6 -t nat -I POSTROUTING 1 -s $SUB_NET_6 -o $IN_FACE -j MASQUERADE
$IPT6 -I INPUT 1 -i $WG_FACE -j ACCEPT
$IPT6 -I FORWARD 1 -i $IN_FACE -o $WG_FACE -j ACCEPT
$IPT6 -I FORWARD 1 -i $WG_FACE -o $IN_FACE -j ACCEPT
$IPT6 -I INPUT 1 -i $IN_FACE -p udp --dport $WG_PORT -j ACCEPT

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.

#!/bin/bash
IPT="/sbin/iptables"
IPT6="/sbin/ip6tables"          
 
IN_FACE="eth0"                       # Interface mit Internetzugang
WG_FACE="wg0"                        # Wireguard-Interface 
SUB_NET="172.16.42.0/24"             # Wireguard IPv4-Subnetz
WG_PORT="51234"                      # Wireguard UDP-Port
SUB_NET_6="<IPV6_PREFIX>::42:0/112"  # Wireguard IPv6-Subnetz
 
## IPv4 ##
$IPT -t nat -D POSTROUTING 1 -s $SUB_NET -o $IN_FACE -j MASQUERADE
$IPT -D INPUT 1 -i $WG_FACE -j ACCEPT
$IPT -D FORWARD 1 -i $IN_FACE -o $WG_FACE -j ACCEPT
$IPT -D FORWARD 1 -i $WG_FACE -o $IN_FACE -j ACCEPT
$IPT -D INPUT 1 -i $IN_FACE -p udp --dport $WG_PORT -j ACCEPT
 
## IPv6 ##
$IPT6 -t nat -D POSTROUTING 1 -s $SUB_NET_6 -o $IN_FACE -j MASQUERADE
$IPT6 -D INPUT 1 -i $WG_FACE -j ACCEPT
$IPT6 -D FORWARD 1 -i $IN_FACE -o $WG_FACE -j ACCEPT
$IPT6 -D FORWARD 1 -i $WG_FACE -o $IN_FACE -j ACCEPT
$IPT6 -D INPUT 1 -i $IN_FACE -p udp --dport $WG_PORT -j ACCEPT

Mit chmod -v +x /etc/wireguard/*.sh werden diese Scripts ausführbar gemacht.

Anschließend ist noch eine Konfigurationsdatei zu erstellen, damit Linux grundsätzlich Pakete weiterleitet:

nano /etc/sysctl.d/10-wireguard.conf

Die Datei ist mit zwei Zeilen zu befüllen:

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

Damit die Änderungen wirksam werden und das Tunnelinterface bei Systemstart automatisch aktiviert wird, sind noch diese Befehle auszuführen:

sysctl -p /etc/sysctl.d/10-wireguard.conf
sudo systemctl enable wg-quick@wg0
sudo systemctl start wg-quick@wg0

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):

[Peer]
# Client 1:
PublicKey = <Kpub Client1>
AllowedIPs = 172.16.42.101/32,<IPV6_PREFIX>::42:101/128

Wartung und Updates

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 bares Geld: Tesla (500€ Rabatt), Hetzner Cloud (20€ Guthaben), Ufodrive (30€ Rabatt). Außerdem habe ich eine Wunschliste bei Amazon.


Schreibe einen Kommentar