Betreiben Sie Ihr eigenes VPN auf einem Offshore-VPS

Kommerzielle VPNs verlangen, dass Sie einer No-Log-Richtlinie vertrauen, die von deren Marketingabteilung verfasst wurde. Ihr eigener VPS protokolliert nur, was Sie konfigurieren. Hier ist die vollständige WireGuard-Einrichtung — und eine ehrliche Liste der Kompromisse.

Warum selbst gehostet besser ist als ein kommerzielles VPN

Das „No-Logs“ eines kommerziellen VPNs ist eine Richtlinie. Das No-Logs Ihres eigenen VPS ist eine Architektur. Dieser Unterschied zählt mehr als jedes Audit-Abzeichen:

• Ein VPN-Anbieter sieht standardmäßig alles. Der Traffic Tausender Nutzer endet auf Servern, die das Unternehmen vollständig kontrolliert. Eine versiegelte Anordnung plus eine still geänderte Protokollierung sind für Sie unsichtbar — und das ist schon passiert, bei Anbietern, von denen Sie gehört haben.
• Auf Ihrem eigenen VPS kontrollieren Sie den gesamten Stack. Ihre sshd, Ihre Festplatte, Ihre WireGuard-Konfiguration. Wir führen nichts innerhalb Ihrer Gastinstanz aus und speichern keine Aktivitäts- oder Verbindungsprotokolle auf der Netzwerkseite. Wir können nicht in Ihren VPS hineinsehen; ein VPN-Unternehmen ist dadurch definiert, dass es in seinen Tunnel hineinsieht.
• Die Jurisdiktion arbeitet für Sie. Ihr Exit befindet sich dort, wo Sie ihn bereitstellen — außerhalb der Überwachungsallianzen, wenn Sie das wählen, geregelt durch die Gerichte der Hosting-Jurisdiktion statt durch das Heimatland eines VPN-Unternehmens.

Und das ehrliche Gegengewicht: ein selbst gehostetes VPN hat eine dedizierte IP, die nur Ihnen gehört. Websites werden es nicht als VPN kennzeichnen (eine echte Verbesserung der Lebensqualität), aber der gesamte Datenverkehr teilt eine Adresse — Sie mischen sich nicht unter eine Menge von Tausenden. Wenn Anonymität durch Masse die Anforderung ist, nutzen Sie Tor. Wenn vertrauenswürdige Infrastruktur die Anforderung ist, schlägt nichts eine Box, die Sie kontrollieren.

Was wir aufbauen

Telefon und Laptop → WireGuard-Tunnel → ein SV-Pro an Ihrem gewählten Standort → das offene Internet. IPv4-Weiterleitung mit NAT auf dem Server, Full-Tunnel-Routing auf den Clients (0.0.0.0/0), DNS über 9.9.9.9. Beispiel-Server-IP durchgehend: 185.220.101.14 — ersetzen Sie sie durch Ihre eigene. Das Basis-Betriebssystem ist Debian 13; wenn Sie die Box noch nicht gehärtet haben, erledigen Sie zuerst die 30-Minuten-Checkliste , dann kommen Sie zurück.

Server-Einrichtung auf Debian 13

Installieren und Schlüssel generieren

Copyapt update && apt install -y wireguard qrencode

cd /etc/wireguard
umask 077

# server keypair
wg genkey | tee server.key | wg pubkey > server.pub

# one keypair per client device (laptop shown; repeat for phone)
wg genkey | tee laptop.key | wg pubkey > laptop.pub

Das Generieren von Client-Schlüsseln auf dem Server ist für eine erste Einrichtung akzeptabel, da Sie Konfigurationen ohnehin über SSH übertragen. Für strengere Hygiene generieren Sie Schlüssel auf jedem Gerät und fügen nur die öffentlichen Schlüssel in die Server-Konfiguration ein.

wg0.conf schreiben

Copy# /etc/wireguard/wg0.conf
[Interface]
Address    = 10.10.0.1/24
ListenPort = 51820
PrivateKey = <contents of server.key>
PostUp     = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown   = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

# laptop
[Peer]
PublicKey  = <contents of laptop.pub>
AllowedIPs = 10.10.0.2/32

# phone — repeat the block with 10.10.0.3/32

Überprüfen Sie den Namen Ihrer Uplink-Schnittstelle mit ip route | grep default — auf VPSRento-Images ist es eth0, aber wenn Ihrer abweicht, passen Sie die MASQUERADE-Zeilen an.

Weiterleitung aktivieren und starten

Copy# turn on IPv4 forwarding, persist across reboots
echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/99-wireguard.conf
sysctl -p /etc/sysctl.d/99-wireguard.conf

# firewall: one UDP port, nothing else
ufw allow 51820/udp comment 'WireGuard'

# bring it up, now and on boot
systemctl enable --now wg-quick@wg0
wg show

wg show sollte die Schnittstelle, den Listening-Port und Ihre Peers ausgeben. Noch keine Handshake-Zeilen — diese erscheinen, wenn ein Client eine Verbindung herstellt.

Client-Konfiguration

Auf dem Laptop, laptop.conf:

Copy[Interface]
PrivateKey = <contents of laptop.key>
Address    = 10.10.0.2/32
DNS        = 9.9.9.9

[Peer]
PublicKey           = <contents of server.pub>
AllowedIPs          = 0.0.0.0/0, ::/0
Endpoint            = 185.220.101.14:51820
PersistentKeepalive = 25

AllowedIPs = 0.0.0.0/0, ::/0 leitet alles durch den Tunnel – später kannst du auf Split-Tunnel umstellen, falls du das je willst. PersistentKeepalive hält den Pfad durch das heimische NAT am Leben. Für das Telefon tippen Sie nichts: Erzeugen Sie die Konfigurationsdatei des Telefons auf dem Server und geben Sie sie als QR-Code in Ihrem Terminal aus:

Copy# prints a scannable QR in the terminal — scan it with the WireGuard app
qrencode -t ansiutf8 < phone.conf

Aktivieren, dann von jedem Client verifizieren: curl ifconfig.me sollte mit der IP deines VPS antworten, und ein DNS-Leak-Test sollte den Betreiber von 9.9.9.9 zeigen – nicht deinen ISP.

Leistungshinweise

WireGuard lebt im Kernel und spricht ChaCha20 – auf den AMD-EPYC-Knoten bewegt ein einzelner Tunnel realistisch 600–900 Mbit/s durch NAT, das heißt, er sättigt den Port lange bevor er die CPU fordert. Die bindende Grenze ist nie die Chiffre, sondern die Bandbreitenbedingungen des Plans. Ein VPN ist bandbreitenrein: Jedes Gigabyte, das Sie herunterladen, zählt einmal eingehend und einmal ausgehend. Bei Plans mit Volumenbegrenzung zählt diese Rechnung. Beim SV-Pro — $19.99/Monat, unbegrenzt bei 1 Gbit/s – nicht, weshalb der SV-Pro der Plan ist, den wir VPN-Bauern empfehlen. Ein Kunde betreibt ein komplettes Familien-Setup auf einem einzigen SV-Pro in Amsterdam und hat sein Limit noch nicht gefunden.

Multi-Hop: Eintritt in Amsterdam, Austritt in Reykjavik

Für eine zweite Schicht zwei VPS über Jurisdiktionen hinweg verketten. Eintrittsknoten in den Niederlanden (günstige Latenz zu dir), WireGuard-Tunnel zwischen den beiden Servern, Austrittsknoten in Island (die Jurisdiktion, aus der dein Datenverkehr tatsächlich stammen soll). Deine Geräte sehen einen Endpunkt in Amsterdam; das Internet sieht eine IP in Reykjavik; der Eintrittsknoten sieht nur Chiffretext, der durchläuft. Mechanisch sind es dieselben Konfigurationen, die du gerade geschrieben hast, doppelt – ein zweites wg -Interface auf dem Eintrittsknoten, dessen Standardroute auf den Austrittstunnel zeigt. Die Kosten sind etwa 40–60 ms zusätzlicher Latenz und ein weiterer $5.99–6.89 VPS. Das lohnt sich, wenn dein Bedrohungsmodell ein Budget hat; Deko, wenn nicht.

Ehrliche Grenzen

• Du bist jetzt der Betreiber. Updates, Schlüsselrotation und Verfügbarkeit liegen bei dir. unattended-upgrades und die Härtungs-Checkliste decken das meiste ab; der Rest ist ein gelegentliches apt upgrade an einem Sonntag.
• Eine IP ist eine Identität. Beobachter können alles korrelieren, was von deiner Adresse ausgeht. Wenn es darauf ankommt, in einem anderen Standort neu bereitstellen – 55 Sekunden später hast du einen frischen Austritt und eine frische IP, geprüft gegen 40+ Blacklists.
• Ein VPS ist kein Tor. Dieses Setup schützt dich vor deinem ISP, vor feindlichem WLAN und vor VPN-Anbietern. Gegen einen staatlichen Gegner, der beide Enden des Tunnels beobachtet, existiert Zeitkorrelation. Wisse, in welchem Kampf du steckst.