Onion-Dienst versus VPN-Dienst: unterschiedliche Zugangsmodelle

Menschen beschreiben einen Onion-Dienst und einen nur über VPN erreichbaren Dienst als zwei Spielarten derselben Idee: den Port verbergen, die geheime Adresse teilen. Sie unterscheiden sich darin, woran die Adresse gebunden ist, wer sie erreichen kann und was geschehen muss, bevor eine Anfrage ankommt. Das eine ist ein Treffpunkt innerhalb von Tor, das andere eine Route innerhalb eines privaten Netzes. Sie als austauschbar zu behandeln erzeugt Entwürfe, die weder privat noch wartbar sind.

Der Mythos: Beide Entwürfe sind nur eine versteckte Tür

Die gemeinsame Eigenschaft ist real, aber dünn: Keiner der Entwürfe legt die Verwaltungsschnittstelle auf einen direkt erreichbaren öffentlichen Port. Alles danach geht auseinander. Eine Onion-Adresse wird aus dem eigenen Schlüssel des Dienstes abgeleitet, deshalb ist der Name an eine Identität gebunden; eine VPN-Adresse ist nur eine Adresse in einem Netz, in das man aufgenommen wurde. Das eine verbirgt den Dienst in einem Overlay, das andere lässt einen in eine private Topologie. Das zweite als Synonym für das erste zu halten, ist der Anfang der Verwirrung.

Keine der beiden Eigenschaften ist eine Sicherheitskontrolle für die Anwendung selbst. Ein versteckter Ort schließt die Software dahinter nicht, und eine private Route fügt der Anmeldeseite keine Authentifizierung hinzu. Beide Entwürfe brauchen weiterhin die eigenen Berechtigungen der Anwendung, und beide brauchen weiterhin jemanden, der für Aktualisierungen und Wiederherstellung verantwortlich ist.

Worauf eine Onion-Adresse tatsächlich zeigt

Eine Onion-Adresse der Version v3 kodiert den öffentlichen Schlüssel des Dienstes, weshalb niemand eine Adresse für einen Dienst wählen kann, den er nicht kontrolliert. Der Client verbindet sich über Tor zu einem Treffpunkt, und der Dienst erreicht denselben Punkt von seiner Seite; kein gewöhnlicher Exit-Knoten trägt diese Verbindung zum Dienst. Der Name ist eine Identität, kein DNS-Eintrag.

dig +short example.onion
curl --socks5-hostname 127.0.0.1:9050 http://example.onion/
systemctl status tor

Deshalb bringt es nichts, eine Route oder einen hosts-Eintrag für einen onion-Namen hinzuzufügen. Die Auflösung ist nicht der Mechanismus; der Tor-Client und seine Schaltkreise sind es. Ist der Dienst für einen kleinen Personenkreis gedacht, kann die Onion-Client-Autorisierung einen Schlüssel verlangen, bevor die Verbindung angenommen wird, aber das ist noch keine Anwendungsanmeldung. Die Adresse zu veröffentlichen ist ebenfalls eine bewusste Handlung, denn jeder, der sie erfährt, kann eine Verbindung versuchen, sofern Sie sie nicht eingeschränkt haben.

Halten Sie inne, wenn der einzige Grund für den Onion-Entwurf ist, die Einrichtung von Authentifizierung zu vermeiden. Das Overlay leistet das nicht, und Sie werden sie später ohnehin bauen.

Was eine VPN-Route tatsächlich gewährt

Ein VPN lässt ein Gerät in ein Netz und gibt ihm eine Route zu einem Gateway oder einem Subnetz. Der Dienst hinter diesem Gateway sieht eine Adresse aus dem Tunnelpool und wendet die Autorisierung an, die er hat. Die Route sagt nichts darüber, wer der Nutzer ist; sie sagt, wohin Pakete gehen dürfen.

ip route get 10.20.30.40
wg show
curl -sv https://files.internal.example/ -o /dev/null

Dieses Modell passt zu einer bekannten Gruppe mit verwalteten Geräten, weil das Gateway den Gerätezustand erzwingen kann und das Netz prüfbar ist. Es passt schlecht zu anonymen oder spontanen Besuchern, die zuerst aufgenommen werden müssten. Die eigene Anmeldung der Anwendung entscheidet weiterhin, was ein verbundener Nutzer lesen darf. Erreichbarkeit mit Berechtigung zu verwechseln, ist der Weg, auf dem ein VPN am Ende ein ganzes Subnetz an alle vergibt, die sich verbinden können.

Halten Sie inne, wenn das Publikum unbekannt ist oder sich ständig ändert. Fremde in ein privates Netz aufzunehmen, um ihnen eine Seite zu zeigen, ist eine große Verpflichtung im Vergleich zum Veröffentlichen eines Dienstes.

Die Wahl zwischen beiden und was gleich bleibt

Wählen Sie das Onion-Modell, wenn das Publikum technisch ist, der Dienst überhaupt keine öffentliche Adresse haben darf und Sie Tors Client-Anforderungen akzeptieren können. Wählen Sie das VPN-Modell, wenn das Publikum eine definierte Gruppe ist, deren Geräte Sie verwalten und deren Zugriff Sie auf Netzwerkebene protokollieren wollen. Keine der beiden Wahlmöglichkeiten beseitigt die Notwendigkeit von Anwendungsauthentifizierung, Patches oder eines Wiederherstellungswegs. Keine ist automatisch privater in dem Sinn, der für Ihre Nutzer zählt.

Schreiben Sie in beiden Entwürfen auf, wer den Dienst erreichen kann, wie sie identifiziert werden und was geschieht, wenn ein Zugangsdatum verloren geht. Die Antwort für einen Onion-Dienst umfasst seine Client-Autorisierungsschlüssel und die Adresse selbst; die Antwort für ein VPN umfasst das Konto, das Gerät und die Gateway-Richtlinie. Das sind unterschiedliche Verzeichnisse, und nur eines davon wird dem nächsten Administrator offensichtlich sein.

Der Vergleich endet dort, wo die Anwendung beginnt. Eine versteckte Adresse und eine private Route sind Transportentscheidungen, und die Anwendung muss weiterhin entscheiden, was eine Anfrage tun darf. Halten Sie diese Entscheidungen in getrennten Dokumenten fest, und keiner der Entwürfe wird stillschweigend die Aufgabe des anderen übernehmen.