Was ein VPN wirklich tut — und der Satz, den die meisten Erklärungen auslassen
Ein VPN verschlüsselt Ihren Traffic und schickt ihn an einen Server, der ihn entschlüsselt und weiterleitet. Die Folge ist nicht, dass Ihr Traffic unsichtbar wird. Es ist, dass sich die Gruppe der Leute ändert, die ihn sehen kann. Vorher: das WLAN im Café, das Hotel, der Mobilfunkanbieter, Ihr ISP zu Hause und die jeweilige nationale Middlebox darüber — sie alle sehen, welche Seiten Sie erreichen und ungefähr, wie viel Sie dort tun. Nachher: Sie sehen einen einzigen langlebigen verschlüsselten Datenstrom zu einer Adresse, und nichts darüber, was darin steckt. Im Gegenzug übernimmt jetzt das Netzwerk, in dem Ihr Server sitzt, die Position, die sie aufgegeben haben.
Das ist der gesamte Mechanismus, und es lohnt sich, das offen auszusprechen, denn die Marketingversion — „online unsichtbar sein" — lässt Leute einen Schutz erwarten, den das Design gar nicht bietet. Ein VPN ist ein Wechsel des Beobachtungspunkts. Ob das hilft, hängt vollständig davon ab, ob der neue Beobachtungspunkt für genau das, worüber Sie sich Sorgen machen, besser ist als der alte. Den Beobachter von einem Hotelnetzwerk, von dem Sie noch nie gehört haben, in ein selbst gewähltes Rechenzentrum zu verschieben, in einem selbst gewählten Land, mit selbst konfigurierter Software, ist meist ein sehr guter Tausch. Ihn von Ihrem heimischen ISP zu einem Unternehmen zu verschieben, das in Podcasts wirbt, ist ein anderer Tausch — und ein weniger offensichtlicher.
Self-Hosting ändert nur die zweite Hälfte dieses Satzes, sonst nichts. Die Kryptografie ist identisch — WireGuards Design-Paper beschreibt denselben Handshake, egal ob der Peer Ihnen oder einem Anbieter gehört. Was sich ändert, ist, wer am anderen Ende den privaten Schlüssel hält, wer protokollieren könnte, wenn er wollte, wessen Kundendatenbank existiert, und wer sich sonst noch Ihre Exit-Adresse teilt. Diese vier Unterschiede sind das gesamte Argument für und gegen den eigenen Betrieb, und sie zeigen nicht alle in dieselbe Richtung.
Eigener Exit oder ein kommerzieller: der Kompromiss, den Sie tatsächlich eingehen
Der Instinkt sagt einem, Self-Hosting als die strikt privatere Option zu behandeln, und für die meisten Bedrohungsmodelle stimmt das auch. Es gibt keinen Anbieter, der einen Kontoeintrag hält, keine gemeinsam genutzte Infrastruktur, die wegen jemand anderes Konto beschlagnahmt werden könnte, keine Datenschutzrichtlinie, der man einfach glauben muss, und keine Möglichkeit einer Protokollierungsänderung, von der man nichts erfährt. Sie halten den Schlüssel. Niemandem muss vertraut werden, weil niemand in der Position ist, Sie zu verraten.
Es gibt aber eine Dimension, in der ein kommerzielles VPN klar gewinnt, und das ist keine kleine. Deren Exit-Adresse wird gleichzeitig von Hunderten oder Tausenden Menschen geteilt, sodass eine Website, die eine Anfrage von dort sieht, kaum erfährt, wer von ihnen sie geschickt hat. Ihre eigene Exit-Adresse wird nur von Ihnen geteilt. Sie ist stabil, gehört einem einzigen Kunden, und jede Seite, die Sie darüber besuchen, sieht denselben Bezeichner — genau wie bei einer heimischen IP-Adresse, nur in einem anderen Land. Wenn Sie in einer Menge untertauchen wollen, bringt eine Menge aus einer Person das nicht.
| Dimension | Eigener VPS | Kommerzielles VPN | Wer gewinnt |
|---|---|---|---|
| Wer sonst noch Ihre Exit-IP nutzt | Niemand — sie gehört nur Ihnen | Hunderte bis Tausende, ständig wechselnd | Kommerziell, klar |
| Wer Ihren Traffic protokollieren könnte | Sie selbst, und nur wenn Sie es konfigurieren | Der Anbieter, gemäß einer Richtlinie, die Sie nicht prüfen können | Selbst gehostet |
| Erforderliches Vertrauen | Keines — Sie halten den privaten Schlüssel | Vollständig, nur durch externe Audits abgemildert | Selbst gehostet |
| Was eine Anfrage an den Betreiber liefert | Was auch immer Ihr Host über Ihr Konto vorhält | Ein Konto, eine Zahlungsspur, Sitzungsmetadaten | Kommt darauf an, wie Sie beides gekauft haben |
| Kosten pro Monat | $8.50 für einen ganzen Server, beliebig viele Geräte | $5–13 pro Abo, gerätebeschränkt | Selbst gehostet ab mehr als einem Gerät |
| Das Ausstiegsland wählen | Eines — das, in dem Sie bereitgestellt haben | Dutzende, mit einem Klick wechselbar | Kommerziell |
| Streaming und geo-gesperrte Dienste | Blockiert als Rechenzentrums-IP | Blockiert als bekannter VPN-Bereich | Ehrlich gesagt: keiner von beiden |
| Eine nationale Firewall überstehen | Ihre Adresse ist unbekannt und nicht gelistet | Anbieter-Bereiche sind erfasst und blockiert | Selbst gehostet, eindeutig |
Lesen Sie diese Tabelle als zwei verschiedene Fragen statt als eine einzige Punktzahl. Wenn Ihr Angreifer das Netzwerk ist, in dem Sie gerade sitzen — ein ISP, der Browserdaten verkauft, ein Arbeitgeber, der TLS aufbricht, ein Café, ein Hotel, eine zensierende Firewall —, gewinnt Self-Hosting auf jeder Zeile, die zählt, weil das, wovor Sie sich verstecken, oberhalb des Tunnels sitzt und nicht hindurchsehen kann. Wenn Ihr Angreifer die Website ist, die Sie besuchen, die versucht, die heutige Sitzung mit der vom letzten Monat zu verknüpfen, dann ist die Menge der Schutz, und ein privater Exit ist schlechter als nutzlos. Nur sehr wenige Menschen befinden sich tatsächlich in der zweiten Situation, und die meisten von ihnen sollten eher über Tor lesen als über VPNs.
Der Grund, warum die beiden verwechselt werden, ist, dass die Branche ein Produkt unter zwei Beschreibungen verkauft. Der einzige echte, verteidigbare Anspruch eines kommerziellen VPNs ist die Menge. Alles andere im Werbeversprechen — das No-Logs-Versprechen, die Audits, das Gründungsrechtsgebiet — ist ein Versuch, auszugleichen, dass Sie Ihren Traffic einem Unternehmen übergeben. Self-Hosting entfernt das Unternehmen. Es kann keine Menge herstellen.
Wann Self-Hosting die richtige Antwort ist
Der klarste Fall ist ein Netzwerk, das Sie weder kontrollieren noch dem Sie vertrauen können. Konferenz-WLAN, Hotels, Flughäfen, die gemeinsame Verbindung eines Vermieters, mobiles Roaming in einem Land mit einem aggressiven Überwachungsregime. In all diesen Fällen ist die Bedrohung lokal und passiv, und ein Tunnel zu irgendwo anders entfernt sie vollständig. Dass das der am wenigsten glamouröse Anwendungsfall ist, macht ihn nicht zum am wenigsten wertvollen — es ist der, der für fast jeden gilt, fast jede Woche.
Der zweite ist das Rechtsgebiet. Ein Tunnel, der in Zürich endet, bedeutet, dass der austretende Traffic Schweizer Recht unterliegt, von einem Schweizer Transit-Anbieter getragen wird und außerhalb der Reichweite dessen liegt, was auch immer für Ihre eigene Verbindung gilt. Das ist keine Abstraktion für Menschen in Ländern, in denen der ISP verpflichtet ist, Browserverlaufsdaten zu speichern und herauszugeben. Das Ausstiegsland bewusst zu wählen, ist eine der wenigen Datenschutzentscheidungen mit einer sauberen, nachvollziehbaren Wirkung, und es lohnt sich, den Rechtsgebietsvergleich vor der Bereitstellung zu lesen statt danach.
Der dritte ist Zensur. Nationale Firewalls blockieren kommerzielle VPNs, indem sie deren Adressbereiche erfassen, was einfach ist, weil diese Bereiche veröffentlicht, verkauft und stark genutzt werden. Eine einzelne VPS-Adresse in einem Hosting-Netzwerk steht auf keiner solchen Liste — nicht weil sie besonders raffiniert ist, sondern weil niemand einen Grund hatte, sie zu katalogisieren. Deshalb waren die zuverlässigsten Umgehungslösungen schon immer klein und persönlich statt groß und kommerziell, und das ist der eine Ort, an dem die Menge aktiv zum Nachteil wird.
Der vierte ist, dass Sie einen stabilen, sauberen, kontrollierbaren Exit für etwas anderes als Browsen wollen: ein Homelab von außen erreichen, einem kleinen Team Zugriff auf interne Dienste geben, ohne sie offenzulegen, einen Dienst betreiben, der eine vorhersagbare Quelladresse braucht, oder eine langlebige Sitzung auf einer Adresse halten, die einem nicht unter der Hand wechselt. Das sind Netzwerk-Engineering-Probleme, die ein kommerzielles VPN überhaupt nicht lösen kann und die ein VPS für $8.50 an einem Nachmittag löst. Die Seite zur VPN-Workload behandelt die Dimensionierung und die Netzwerkdetails.
Und das Argument dagegen: Wer einen Server nicht gepatcht halten kann, sollte keinen betreiben. Ein ungepflegter VPS mit offenem SSH-Port ist ein schlechteres Datenschutzergebnis als jedes kommerzielle VPN, weil ein kompromittierter Exit alles sieht und jemand anderem Rechenschaft schuldet. Self-Hosting tauscht ein Vertrauensproblem gegen ein Betriebsproblem. Das ist nur dann ein guter Tausch, wenn Sie den Betrieb auch tatsächlich leisten — was der letzte Abschnitt dieses Leitfadens auf etwa zehn Minuten im Monat reduziert.
WireGuard in zehn Minuten: die komplette Konfiguration
WireGuard ist klein genug, um es einfach durchzulesen. Es lebt im Linux-Kernel, spricht einen einzigen UDP-Port, nutzt einen fest vorgegebenen Satz moderner Primitiven ohne jede Aushandlung, und seine gesamte Konfigurationsoberfläche besteht aus zwei Arten von Blöcken: einem [Interface], das diese Maschine beschreibt, und einem [Peer] pro Gerät, das sich verbinden darf. Es gibt keine Zertifizierungsstellen, keine Cipher-Suites, die man falsch wählen könnte, und keinen Daemon zum Justieren. Dieser Minimalismus ist der Grund, warum es so schwer ist, es gefährlich fehlzukonfigurieren, und der Grund, warum es die Alternativen fast überall verdrängt hat.
Beginnen Sie damit, das Paket zu installieren und ein Schlüsselpaar zu erzeugen. Setzen Sie zuerst umask 077, damit der private Schlüssel nicht für alle lesbar geschrieben wird — wg-quick beschwert sich lautstark, falls doch, und das zu Recht. wg genkey erzeugt den privaten Schlüssel, wg pubkey leitet daraus die öffentliche Hälfte ab. Machen Sie dasselbe auf jedem Client. Die öffentlichen Schlüssel werden ausgetauscht; die privaten Schlüssel verlassen nie die Maschine, die sie erzeugt hat.
Schreiben Sie dann /etc/wireguard/wg0.conf. Die folgende Tabelle ist die vollständige Datei für einen funktionierenden Server — nichts wurde der Kürze halber weggelassen.
| Direktive | Was sie tut | Was schiefgeht, wenn Sie es falsch machen |
|---|---|---|
[Interface] | Eröffnet den Block, der diesen Server beschreibt | — |
Address = 10.66.66.1/24, fd42:42:42::1/64 | Die Adresse des Servers innerhalb des Tunnels, für beide Familien | Fehlt die v6-Zeile, haben Clients kein v6 im Tunnel und nutzen womöglich das echte v6 außerhalb davon |
ListenPort = 51820 | Der einzige UDP-Port, auf dem der Server antwortet | Von einer vorgelagerten Firewall blockiert, und nichts verbindet sich; es gibt keinen TCP-Fallback |
PrivateKey = <server.key> | Der private Schlüssel des Servers, direkt eingefügt | Für alle lesbare Datei, und wg-quick weigert sich zu starten |
PostUp = ...masquerade... | Richtet Source-NAT ein, damit Tunnel-Pakete über das öffentliche Interface hinauskönnen | Fehlt das, kommen die Pakete am Server an und werden verworfen — der Tunnel verbindet sich, aber nichts lädt |
PostDown = ...delete... | Entfernt dieselbe Regel wieder, wenn das Interface heruntergefahren wird | Veraltete NAT-Regeln sammeln sich über Neustarts hinweg an |
[Peer] | Eröffnet einen Block für ein Client-Gerät | — |
PublicKey = <client.pub> | Identifiziert und authentifiziert dieses Gerät | Das ist das gesamte Zugriffskontrollmodell — der Schlüssel ist das Konto |
AllowedIPs = 10.66.66.2/32, fd42:42:42::2/128 | Auf dem Server: die Adressen, die dieser Peer nutzen darf | Zu weit gefasst, und ein Client kann sich als ein anderer ausgeben; auf dem Client bedeutet es etwas völlig anderes |
Zwei Dinge außerhalb der Datei müssen ebenfalls stimmen. Der Kernel muss bereit sein zu forwarden: Setzen Sie net.ipv4.ip_forward=1 und net.ipv6.conf.all.forwarding=1, und schreiben Sie es in /etc/sysctl.d/, damit es einen Neustart übersteht. Und die NAT-Regel in PostUp muss das echte öffentliche Interface benennen — auf den meisten Cloud-Images ist das eth0, aber prüfen Sie es mit ip route get 1.1.1.1, statt es einfach anzunehmen. Ein falscher Interface-Name ist der mit Abstand häufigste Grund, warum ein erstes WireGuard-Setup sich verbindet und dann nirgendwohin führt.
Fahren Sie es hoch mit wg-quick up wg0, bestätigen Sie mit wg show, dass das Interface existiert und Ihre Peers auflistet, und aktivieren Sie dann systemctl enable --now wg-quick@wg0, damit es nach einem Neustart wiederkommt. Auf der Client-Seite ist die Datei fast identisch, mit drei Unterschieden, die zählen: AllowedIPs wird zu 0.0.0.0/0, ::/0 — was alles hier durchrouten bedeutet statt diese Quellen akzeptieren —, eine Endpoint-Zeile zeigt auf die öffentliche Adresse und den Port des Servers, und PersistentKeepalive = 25 hält die Zuordnung durch Heimrouter am Leben, die sie sonst per Timeout verwerfen würden. Führen Sie bei Smartphones die Client-Konfiguration durch qrencode -t ansiutf8 und scannen Sie sie vom Terminal aus. Schicken Sie Konfigurationsdateien nicht über eine Messaging-App; der private Schlüssel steckt darin.
Die vier Lecks, die den Tunnel umgehen
Ein Tunnel, der Traffic transportiert, ist nicht dasselbe wie ein Tunnel, der allen Traffic transportiert, und in der Lücke zwischen beiden lebt jedes reale VPN-Versagen. Jedes der folgenden vier ist ein Fall, in dem der Tunnel einwandfrei funktioniert und Ihr Traffic trotzdem daran vorbeiläuft, und keiner von ihnen meldet sich von selbst. Man muss hinsehen.
DNS. Wenn der Client weiter den Resolver benutzt, den das lokale Netzwerk vergeben hat, transportiert der Tunnel zwar Ihren Traffic, während der DHCP-Server des Cafés weiterhin live jede Domain mitbekommt, die Sie nachschlagen. Allein die Namen ergeben schon fast das ganze Bild. Beheben Sie das mit einer expliziten DNS =-Zeile in der Client-Konfiguration, oder, besser noch, betreiben Sie auf dem VPS einen an die Tunnel-Adresse gebundenen Resolver und weisen Sie die Clients dorthin — dann laufen auch die Abfragen durch den Tunnel und enden auf einer Maschine, die Ihnen gehört. Prüfen Sie das vom Client aus, nicht vom Server, mit einem beliebigen DNS-Leck-Test; Sie sollten genau einen Resolver sehen, und der sollte Ihrer sein.
IPv6. Der klassische stille Fehlschlag. Wenn AllowedIPs auf dem Client nur 0.0.0.0/0 angibt, haben Sie dem Betriebssystem gesagt, IPv4 durch den Tunnel zu routen, und über IPv6 nichts gesagt. In einem Dual-Stack-Netzwerk — was heute für die meisten Heim- und Mobilfunknetze gilt — wird jede Seite mit einem AAAA-Eintrag über Ihre echte Adresse erreicht, außerhalb des Tunnels, während ein Leck-Test, der nur v4 prüft, meldet, alles sei in Ordnung. Fügen Sie entweder ::/0 hinzu und vergeben Sie v6-Adressen innerhalb des Tunnels, oder deaktivieren Sie IPv6 auf dem Client komplett. Keins von beidem zu tun ist die Standardeinstellung, und die Standardeinstellung ist kaputt.
Der fehlende Kill-Switch. Wenn der Tunnel abbricht — das Laptop geht in den Ruhezustand, das Handy wechselt zwischen Funkmasten, der Server startet für ein Kernel-Update neu —, macht das Betriebssystem das vermeintlich Hilfreiche und fällt auf das lokale Netzwerk zurück. Traffic, von dem Sie annahmen, er sei getunnelt, ist es nicht, und niemand sagt es Ihnen. Unter Linux schließt wg-quick mit der Standard-Routingtabelle bei den meisten Traffic bereits ab, aber die verlässliche Lösung ist eine explizite Firewall-Regel, die alles verwirft, was nicht über wg0 hinausgeht. Aktivieren Sie unter Android und iOS dauerhaft aktives VPN und Verbindungen ohne VPN blockieren. Prüfen Sie bei Desktop-Clients, ob es diese Einstellung überhaupt gibt, bevor Sie davon ausgehen.
MTU. Kein Datenschutz-Leck, aber der Grund, warum Leute aufgeben. WireGuards Kapselung kostet 60 Byte bei IPv4 und 80 Byte bei IPv6, sodass die Standard-Interface-MTU von 1420 in einen normalen 1500-Byte-Pfad passt. Über PPPoE, manche Mobilfunknetze oder einen zweiten Tunnel ist der echte Pfad kleiner, und das Symptom ist eigenartig: Pings funktionieren, kleine Seiten laden, und große TLS-Handshakes hängen für immer. Wenn das beschreibt, was Sie sehen, setzen Sie die MTU auf dem Client auf 1380 oder 1280 herunter, und es funktioniert einfach.
| Prüfung | Wie Sie es verifizieren | Wie ein Bestehen aussieht |
|---|---|---|
| IPv4-Exit | Öffentliche Adresse von einem beliebigen Echo-Dienst abrufen | Die Adresse des Servers, nicht Ihre eigene |
| IPv6-Exit | Dasselbe noch einmal explizit über IPv6 abrufen | Die v6-Adresse des Servers — oder gar keine v6-Route |
| DNS | Ein beliebiger DNS-Leck-Test, vom Client aus ausgeführt | Ein Resolver, der von Ihnen konfigurierte |
| Fail-Closed | Tunnel stoppen und eine Seite neu laden | Die Seite schlägt fehl; sie lädt nicht klammheimlich doch |
| MTU | Eine große Seite über TLS im schlechtesten Netzwerk laden, das Sie nutzen | Sie lädt fertig, statt hängen zu bleiben |
| Aktualität des Handshakes | wg show auf dem Server | Ein aktueller Handshake für jeden erwarteten Peer |
Eine Sache kann ein VPN nicht reparieren, und das sollte man klar sagen, damit man es nicht erwartet: Ein Beobachter, der beide Enden gleichzeitig sehen kann, kann sie anhand von Timing und Volumen korrelieren, Tunnel hin oder her. Verschlüsselung verbirgt Inhalte, nicht die Form eines Gesprächs. Sich gegen diesen Angreifer zu verteidigen erfordert, den eigenen Traffic mit dem anderer Leute über mehrere Relays zu vermischen — genau dafür ist Tor da, und genau das ist ein Single-Hop-VPN strukturell nicht. Wenn das Ihr Bedrohungsmodell ist, ist ein selbst gehostetes VPN das falsche Werkzeug, und keine Konfiguration davon wird es zum richtigen machen.
Wie sich die Exit-Adresse in freier Wildbahn schlägt
Die Adresse, aus der Ihr Tunnel austritt, gehört einem Hosting-Netzwerk, und ein großer Teil des modernen Web sortiert Adressen in privat und Rechenzentrum, bevor entschieden wird, wie Sie behandelt werden. Streaming-Kataloge, manche Banken, Ticketverkaufsseiten und ein gutes Stück Antifraud-Software behandeln alles aus einem Hosting-Netzwerk standardmäßig als verdächtig. Das behebt keine Konfigurationsänderung — es ist eine Eigenschaft davon, wo der Server steht, und das gilt für einen selbst gehosteten Tunnel genauso wie für jedes kommerzielle VPN auf dem Markt. Wer etwas anderes verspricht, beschreibt ein Katz-und-Maus-Spiel, das er gerade verliert.
Was tatsächlich unterscheidet, ist, auf welchen Listen Ihre Adresse landet. Bereiche kommerzieller VPNs werden erfasst, veröffentlicht und als Feeds verkauft, gerade weil sie groß, statisch und geteilt sind; eine Seite, die VPNs blockieren will, kauft die Liste. Eine einzelne Adresse in einem allgemeinen Hosting-Netzwerk steht nicht darauf. In der Praxis heißt das: Selbst gehostete Exits kommen durch einen überraschend großen Teil des gewöhnlichen Web, das kommerzielle Anbieter rundweg blockiert, stoßen aber trotzdem bei den speziellen Diensten an eine Wand, die jeglichen Rechenzentrums-Traffic blockieren. Rechnen Sie mit dem gelegentlichen zusätzlichen CAPTCHA und nicht mehr.
Ein paar Dinge lohnen sich einmalig. Setzen Sie einen schlichten, unauffälligen Reverse-DNS-Eintrag auf die Adresse, statt es beim Anbieter-Standard zu belassen — viele Reputationssysteme lesen den PTR, und ein generischer Hostname schneidet besser ab als etwas, das nach Infrastruktur klingt. Lassen Sie den Tunnel komplett von Port 25 fern; ausgehende Mail von einer frischen Hosting-Adresse landet im Spam-Ordner, ganz gleich, was Sie tun, und das Zustellbarkeitsproblem ist ein eigenes, mehrwöchiges Projekt für sich. Und falls die Adresse doch einmal verbrannt ist — geerbt von einem Vormieter oder wegen etwas, das einer Ihrer eigenen Peers getan hat —, bitten Sie um eine neue IP, statt dagegen anzukämpfen. Wir verschieben Kunden kostenlos auf eine frische Adresse im selben Präfix; öffnen Sie ein Ticket im Panel, und es ist innerhalb eines Tages erledigt.
Die letzte Überlegung ist, wer sonst noch hinter Ihrem Tunnel steckt. Weil sich jeder Peer eine Exit-Adresse teilt, wird das Verhalten einer Person zur Reputation aller. Ein Haushalt ist unproblematisch. Eine Gruppe von zwanzig Bekannten, bei denen Sie nicht wissen, was die Hälfte von ihnen treibt, ist genau so, wie aus einer sauberen Adresse eine blockierte wird und wie eine Missbrauchsmeldung mit Ihrem Kontonamen darauf ankommt. Wenn Sie Peer-Zugänge an Leute vergeben, für die Sie nicht bürgen würden, geben Sie ihnen stattdessen eine eigene Instanz — bei $8.50 im Monat ist das die günstigere Antwort als die Alternative.
Die Schicht, die niemand konfiguriert: Wie Sie die Kiste bezahlt haben
Hier kommt das Versagen, das alles oben Genannte zunichtemacht, und es hat nichts mit WireGuard zu tun. Traffic verlässt Ihre Exit-Adresse. Die Adresse gehört einem Server. Der Server gehört zu einem Konto. Das Konto wurde mit einer E-Mail-Adresse eröffnet und mit einer Karte auf Ihren Namen bezahlt. An diesem Punkt ist die Kette vom Traffic zurück zu Ihnen vier Hops lang, vollständig dokumentiert, und liegt in der Abrechnungsdatenbank eines Anbieters, bereit darauf, dass jemand danach fragt. Sie haben keinen Beobachter entfernt — Sie haben ihn irgendwohin verschoben, wo besser Buch geführt wird.
Das ist der Unterschied zwischen einem VPN, das Ihre Position im Netzwerk ändert, und einem VPN, das Ihre Exponiertheit ändert — und entschieden wird das an der Kasse, nicht in der Konfigurationsdatei. Wenn der Grund für einen privaten Exit ist, dass Ihr ISP oder Ihr Staat Ihren Browserverlauf nicht haben sollte, und der Server unter Ihrer echten Identität per Kartenzahlung gemietet wird, funktioniert das Setup trotzdem — der ISP kann tatsächlich nicht durch den Tunnel sehen. Aber es ist eine Datenschutzverbesserung gegen einen einzelnen, bestimmten Beobachter, nicht gegen einen entschlossenen. Machen Sie sich klar, was Sie hier eigentlich kaufen.
Diese Lücke zu schließen heißt, dass weder das Konto noch die Zahlung Sie identifizieren können. Das bedeutet keine Identitätsprüfung bei der Anmeldung — eine Wegwerf-E-Mail-Adresse und sonst nichts, was in der Praxis genau das ist, was Hosting ohne KYC bedeutet —, und eine Zahlung über eine Schiene, die Ihren Namen nicht trägt. Monero ist die saubere Antwort, weil Beträge und Parteien überhaupt nicht auf einem öffentlichen Ledger stehen; die Anleitung dauert von Anfang bis Ende etwa fünf Minuten. Bitcoin funktioniert, ist aber ein dauerhaft öffentlicher Datensatz, also nur so privat wie die Coins, die hineinfließen, und der Vergleich zwischen beiden lohnt sich zu lesen, bevor Sie entscheiden, dass es keine Rolle spielt.
Dann ist da noch das Rechtsgebiet, das bestimmt, was überhaupt jemand erzwingen könnte, selbst wenn er fragen würde. Ein Anbieter, der außerhalb der 14-Eyes-Sphäre inkorporiert ist, mit Rechenzentren in Ländern, deren Speicherpflicht keine Traffic-Aufzeichnungen verlangt, ist strukturell unfähig, einen Browserverlauf herauszugeben, den er nie gesammelt hat. Das ist eine stärkere Garantie als ein Versprechen, nicht hinzusehen. Für die vollständige Version dieses Arguments — was an einem gemieteten Server wirklich rückverfolgbar ist und was nicht — steht die ehrliche Antwort hier, einschließlich der Teile, die weniger beruhigend sind als das Marketing.
Dimensionierung: Wie wenig Server ein Tunnel tatsächlich braucht
WireGuard ist bemerkenswert günstig im Betrieb. Es lebt im Kernel, sodass Pakete nie in den Userspace kopiert werden müssen; es nutzt ChaCha20-Poly1305, was auf jeder CPU schnell ist und nicht auf AES-Beschleunigung angewiesen ist, um schnell zu bleiben; und es hält pro Peer nur ein paar Kilobyte Zustand und sonst nichts. Ein einzelner moderner Kern schafft irgendwo um ein Gigabit verschlüsselten Durchsatz, und Arbeitsspeicher ist so gut wie nie der Engpass. Die praktische Grenze bei einem VPS-Tunnel ist der Uplink, nicht der Prozessor.
Das heißt, die meisten Leute wählen ihren Tarif aus dem falschen Grund. Ein Haushalt mit fünf Geräten, die den ganzen Tag browsen, streamen und Videotelefonate führen, ist meilenweit von den Grenzen der kleinsten Stufe entfernt — die CPU liegt brach, und die Bandbreite ist unbegrenzt. Gehen Sie eine Stufe höher, wenn Sie viele gleichzeitige Peers haben, die zeitgleich echten Traffic erzeugen, oder wenn Sie mehr Reserven beim Uplink wollen — nicht, weil sich ein Tunnel anfühlt, als müsste er anspruchsvoll sein.
| Was Sie betreiben | Gleichzeitige Peers | Stufe | Der tatsächliche Engpass |
|---|---|---|---|
| Persönliche Nutzung — Laptop, Handy, Tablet | 1–5 | Starter, $8.50/Mo. | Keiner. Die CPU liegt brach, und 1 Gbps ist unbegrenzt. |
| Ein Haushalt oder ein kleines Team | 5–20 | Starter oder Growth, $13.50/Mo. | Bandbreite bei Spitzenlast, nie die CPU. |
| Eine größere Gruppe, dauerhafter Traffic | 20–80 | Growth oder Business, $20/Mo. | Uplink bei 2.5–5 Gbps; die CPU hat noch Luft. |
| Egress-as-a-Service für eine Community | 80–250 | Business oder Pro, $27.50/Mo. | Jetzt zählt die CPU, und ebenso, dass das Verhalten eines Peers zur Reputation aller wird. |
| Verschlüsselung in Line-Rate für einen einzelnen Host | Beliebig | Scale, $34.50/Mo. | 10 Gbps unbegrenzt, mehrere Kerne, um die Kryptografie darauf zu verteilen. |
Für das Gefühl beim Nutzen des Tunnels zählt der Standort mehr als die Hardware. Jedes Paket, das Sie senden, macht einen Umweg über den Server, sodass Ihre Latenz zu allem zur Latenz zum Server plus dessen Latenz von dort aus weiter wird. Wählen Sie ein Rechenzentrum in Ihrer Nähe, wenn der Tunnel dauerhaft läuft und Ihnen Reaktionsschnelligkeit wichtig ist; wählen Sie eines nahe dem Ziel, das Sie erreichen wollen, wenn nicht. Amsterdam bietet den kürzesten Weg zurück in die meisten Teile Europas, Zürich und Reykjavík tauschen ein paar Millisekunden gegen Rechtsgebiete mit stärkerem Datenschutzrecht, und Bukarest liegt in beider Hinsicht dazwischen.
Noch etwas, das sich zu wissen lohnt, bevor Sie wählen: WireGuards Handshake hat auf der Leitung eine wiedererkennbare Form, und eine Firewall mit Deep Packet Inspection kann ihn erkennen und verwerfen, ohne irgendetwas über das Ziel zu wissen. In den meisten Teilen der Welt spielt das nie eine Rolle. In einer Handvoll Netzwerke bedeutet es, dass WireGuard allein sich nicht verbindet und Sie einen verschleiernden Transport davor brauchen — Shadowsocks, einen xray- oder v2ray-Stack, oder einen der WireGuard-Forks, die den Handshake auffüllen. Sie alle laufen auf derselben Instanz; es ist eine zusätzliche Schicht obendrauf, kein anderer Tarif.
Jahrelang laufen lassen, ohne darüber nachzudenken
Der operative Aufwand für einen persönlichen WireGuard-Endpunkt liegt nahe null, aber eben nicht wirklich bei null, und genau dieser Unterschied trennt einen privaten Exit von einem kompromittierten. Alles Folgende ist einmalig einzurichten, bis auf den letzten Punkt, der etwa zehn Minuten im Monat kostet.
Sichern Sie zuerst die Haustür. SSH nur mit Schlüsseln — PasswordAuthentication no, PermitRootLogin prohibit-password — und eine Firewall, die aus dem Internet genau zwei Dinge akzeptiert: den WireGuard-UDP-Port und SSH. Wenn Sie es gründlich machen wollen, verlegen Sie SSH so, dass es nur noch auf der Tunnel-Adresse lauscht — dann ist der einzige erreichbare Dienst auf dem öffentlichen Interface WireGuard selbst, und WireGuard beantwortet nicht authentifizierte Pakete überhaupt nicht. Ein Portscan der Kiste liefert dann gar nichts zurück, eine wirklich ungewöhnliche Eigenschaft für einen aus dem Internet erreichbaren Server.
Schalten Sie unbeaufsichtigte Sicherheitsupdates ein und lassen Sie sie laufen. Der Kernel spielt hier eine Rolle, die er auf den meisten Servern nicht spielt, weil die WireGuard-Implementierung Teil von ihm ist. Starten Sie neu, wenn ein Kernel-Update eintrifft; wg-quick@wg0 unter systemd bringt den Tunnel von allein zurück, und Clients mit PersistentKeepalive verbinden sich innerhalb von Sekunden neu, ohne dass jemand eingreifen muss.
Behandeln Sie Schlüssel wie Konten, denn genau das sind sie. Ein Schlüsselpaar pro Gerät, nie zwischen zweien geteilt. Zugriff zu entziehen bedeutet, diesen [Peer]-Block zu löschen und wg syncconf wg0 <(wg-quick strip wg0) auszuführen, was die Änderung übernimmt, ohne die Sitzung von irgendjemand anderem zu kappen. Sichern Sie /etc/wireguard/ irgendwo verschlüsselt und abseits der Maschine — geht es verloren, müssen Sie jedes Gerät von Hand neu einrichten. Wenn der Server noch etwas anderes enthält, das Ihnen wichtig ist, ist Festplattenverschlüsselung eine sinnvolle Ergänzung, auch wenn es bei einem reinen Tunnel auf der Platte kaum etwas gibt, das es wert wäre, über dieses eine Verzeichnis hinaus verschlüsselt zu werden.
Überwachen, ohne zu protokollieren. wg show gibt Ihnen die Zeit des letzten Handshakes für jeden Peer — genug, um jede operative Frage zu beantworten, die tatsächlich auftaucht: Läuft es, ist dieses Gerät verbunden, wann hat es sich zuletzt gemeldet. Widerstehen Sie dem Drang, Traffic-Zählung oder Verbindungsprotokolle hinzuzufügen: Sie haben das genau deshalb gebaut, damit niemand Buch darüber führt, wohin Ihr Traffic geht, und die Person, die dieses Buch am ehesten führen würde, sind jetzt Sie selbst. Auf unserer Seite gibt es nichts abzuschalten — kein Netflow, kein Port-Mirroring, keinerlei Traffic-Erfassung, und ARP-Tabellen, die nach 24 Stunden verfallen, was auf der Datenschutzseite dokumentiert ist und nicht nur im Footer versprochen wird.
Das ist die ganze Arbeit. Fünfzehn Zeilen Konfiguration, eine Firewall, Sicherheitsupdates nach Zeitplan und ein monatlicher Blick auf wg show. Der schwierige Teil eines selbst gehosteten VPNs war nie das VPN selbst — es ist, sich daran zu erinnern, dass der Tunnel den Beobachter nur verschiebt, und dass alles, was diese Verschiebung wert ist, davon abhängt, dass die vier Lecks von oben geschlossen sind und das Konto darunter nicht zu Ihnen zurückführt.