Wem du vertraust, wenn du den VPN-Server selbst betreibst

Self-Hosting gibt dir die Betreiberrolle: du wählst die Software, die Konfiguration, den Update-Zeitplan und das, was dein eigener Dienst protokolliert. Was es nicht tut, ist die anderen Parteien aus der Verbindung zu entfernen. Dein Zugangsnetz transportiert weiterhin die Pakete, dein Hosting-Anbieter betreibt weiterhin die Maschine, ein Resolver beantwortet weiterhin Anfragen und ein Ziel sieht weiterhin eine Anfrage. Zu wissen, was davon du tatsächlich geändert hast, ist die ganze Übung.

Schritt 1: die Beteiligten erfassen

Liste jede Partei im realen Betrieb auf: dein Gerät, das Netz, an das du dich anbindest, den VPN-Host, den DNS-Resolver und den Zieldienst. Notiere für jede, was sie beobachten kann und welche Einstellungen du kontrollierst.

Diese Tabelle ist nützlicher als jede Aussage über Anonymität, weil sie zeigt, wo sich die Kontrolle tatsächlich geändert hat. Du kontrollierst die Konfiguration und die Protokolle des Hosts. Du kontrollierst nicht die Sicht des Zugangsnetzes auf deine Verbindung, und du kontrollierst nicht, was das Ziel über dein Konto aufzeichnet.

Bei einem Endpunkt zu Hause verlässt der abgedeckte Datenverkehr normalerweise das Zuhause über dessen Zugangsverbindung. Die Exit-Adresse, die dein Ziel sieht, ist die Adresse des Haushalts, was eine Tatsache über die Topologie ist und kein Fehler der Software. Wenn diese Adresse das ist, was du ändern wolltest, kann ein Heimserver das nicht leisten. Du brauchst einen Exit woanders.

Schritt 2: aufschreiben, was du gewonnen hast

Du kannst die eingesetzte Konfiguration einsehen, entscheiden, welche Geräte beitreten dürfen, eine Diagnoserichtlinie festlegen und die Protokolle führen, die du wählst. Das sind echte Kontrollen, wenn du sie pflegst, und sie sind der ehrliche Grund für Self-Hosting.

Sie sind auch bedingt. Eine ungenutzte Standardeinstellung und ein ungetestetes Backup sind keine Eigenschaften, die das Protokoll liefert; es sind Absichten. Schreib die Kontrolle zusammen mit der Prüfung nieder, die sie belegt, oder sie zählt nicht.

Schritt 3: die Wartungsliste annehmen

Die Liste ist kurz und unbarmherzig: das Administratorkonto schützen, die Serverschlüssel schützen, Client-Identitäten bereitstellen und widerrufen, Backups pflegen, verlorene Geräte entfernen und einen Wiederherstellungsweg erhalten, der nicht vom ausfallenden Tunnel abhängt.

Der Widerruf verdient eine eigene Zeile. Ein Gerät, das du aus der Konfiguration entfernt, aber nie widerrufen hast, besitzt weiterhin gültige Anmeldedaten, und der Unterschied zeigt sich erst, wenn jemand sie benutzt. Teste die Entfernung, indem du versuchst, dich mit dem alten Material zu verbinden.

Backups brauchen dieselbe Behandlung. Stelle eine auf einem Ersatzhost wieder her und bestätige, dass der Tunnel mit denselben Identitäten hochkommt. Ein Backup, das du nie wiederhergestellt hast, ist eine Datei und kein Wiederherstellungsplan.

Schritt 4: die Anonymitätsannahme fallen lassen

Einen Server zu betreiben macht deinen Browser nicht anonym. Websites erhalten weiterhin Kontoinformationen und Cookies, und HTTPS schützt Anwendungsdaten auf seinem eigenen Weg unabhängig vom Tunnel.

Es gibt auch einen subtileren Effekt: Eine Adresse, die nur du benutzt, kann zu einem stabilen Signal werden, das mit deiner Nutzung verbunden ist. Ein kommerzieller Exit wird mit Fremden geteilt, was für die Privatsphäre in einer Hinsicht schlecht und in anderer gut ist. Deine eigene Adresse ist einzigartig, was diesen Tausch umkehrt.

Wenn das Ziel ist, schwer korrelierbar zu sein, kann Self-Hosting es eher leichter als schwerer machen. Entscheide, welche Eigenschaft du wirklich willst, bevor du einen Abend darauf verwendest. Einzigartigkeit ist ein Kostenfaktor, kein Merkmal, und sie taucht in den meisten Self-Hosting-Artikeln nicht auf. Schreib sie in die Beteiligten-Tabelle aus Schritt 1, und der Tausch wird sichtbar.

Schritt 5: es aus einem genannten Grund wählen

Privater Zugang zum eigenen Netz, Kontrolle über die Konfiguration, eine besondere Routing-Anforderung oder Unabhängigkeit von der Richtlinie eines Anbieters sind alles gute Gründe. Schreib den auf, der zutrifft, und entwirf den Test, der zeigen würde, dass er funktioniert.

Dann prüfe die langweiligen Teile: Ist der Host gepatcht, sind alte Schlüssel weg, entspricht die Aufbewahrung deiner Dokumentation, und kannst du den Dienst nach einem Ausfall wiederherstellen? Diese vier Antworten beschreiben das Vertrauensmodell weit besser als der Name des Protokolls.

Schritt 6: den Ausstieg planen

Entscheide vorab, wie du vom Host weg migrieren würdest: wo die Konfiguration liegt, wie Client-Profile neu ausgegeben werden und was mit den Protokollen geschieht, die du behalten hast. Ein selbst betriebener Dienst ohne Ausstiegsplan wird zu einer Abhängigkeit, die du nicht los wirst.

Das gemeinsames Verantwortungsmodell von AWS ist auch außerhalb von AWS eine nützliche Vorlage, weil es dieselbe Frage erzwingt: Welche Schicht ist deine und welche gehört jemand anderem. Beantworte sie für jede Partei aus Schritt 1, und das Vertrauensmodell hört auf, ein Slogan zu sein.