Monero über VPN: Welcher der drei Netzwerkpfade ändert sich?

Öffnen Sie die Wallet, starten Sie den Daemon und zeichnen Sie drei Pfeile, bevor Sie irgendetwas aktivieren. Ein Pfeil läuft von der Wallet zum RPC-Port eines Nodes, einer trägt die Peer-Synchronisierung des Daemons, und einer trägt lokal eingereichte Transaktionen in Richtung eines Weiterleitungspfads. Das sind unterschiedliche Verbindungen mit unterschiedlicher Konfiguration, und ein VPN oder Anonymitätsnetz kann eine, zwei oder keine davon abdecken.

Gehen Sie die Pfade in der Reihenfolge durch, in der die Software sie öffnet. Jeden Pfeil mit Ziel und Transport zu beschriften macht die spätere Datenschutzaussage überprüfbar. Die Reihenfolge ist wichtig, weil die spätere Aussage meist nur eine davon abdeckt.

Beginnen Sie mit der Verbindung von der Wallet zum Node

Eine Wallet, die mit einem entfernten Node spricht, sendet RPC-Anfragen an dessen Adresse und Port. Eine Wallet mit lokalem Daemon spricht stattdessen die Loopback-Schnittstelle an. Das sind unterschiedliche Vertrauensverhältnisse, auch wenn beide im Alltag “der Node” genannt werden.

Notieren Sie Adresse, Port und Transport, für die die Wallet konfiguriert ist. Hat die Wallet eine eigene Proxy-Einstellung, halten Sie sie getrennt von den Einstellungen des Daemons fest; einen Prozess zu konfigurieren konfiguriert den anderen nicht.

Hier wird auch ein öffentlicher RPC-Endpunkt verlockend. Den RPC-Dienst des Nodes offenzulegen, um das Diagramm zu vereinfachen, tauscht einen Netzwerkpfad gegen eine Angriffsfläche. Halten Sie die Verbindung von Wallet zu Node auf einem privaten Pfad oder der Loopback-Schnittstelle und dokumentieren Sie, welche es ist. Ein Diagramm, das diese Offenlegung verbirgt, ist schlechter als keines.

Verfolgen Sie als Nächstes den Peer-Verkehr des Daemons

Ein synchronisierender Daemon öffnet ausgehende Verbindungen zu Peers und tauscht Kettendaten über seinen Peer-to-Peer-Port aus. Dieser Verkehr ist nicht die RPC-Verbindung der Wallet und läuft nicht automatisch über deren Proxy. Er folgt den eigenen Netzwerkeinstellungen des Daemons und der Routing-Tabelle des Hosts.

Notieren Sie den Peer-Port, die Anzahl der Verbindungen und ob der Daemon einen Proxy für Peer-Verkehr nutzt. Prüfen Sie dann die Host-Route für eine Beispiel-Peer-Adresse. Fängt das VPN die Standardroute ab, nutzen die Peer-Verbindungen sie wahrscheinlich; ist der Daemon an eine bestimmte Schnittstelle gebunden, möglicherweise nicht. Diese zwei Fakten entscheiden den Pfeil.

Die Beobachterfrage ändert sich mit diesem Pfad. Ein VPN verbirgt die Peer-Verbindungen vor dem lokalen Zugangsnetz, aber der VPN-Endpunkt und die Peers selbst sehen ein anderes Bild. Keine der beiden Beobachtungen beweist, dass die Anfragen der Wallet denselben Weg genommen haben.

Isolieren Sie dann den Weiterleitungspfad der Transaktionen

Lokal eingereichte Transaktionen lassen sich über einen konfigurierten Relay oder Proxy in Richtung Netzwerk weiterleiten. In der aktuellen Dokumentation des Monero-Daemons schickt diese Option nur den Transaktionsweiterleitungsverkehr durch den Proxy, den Sie darauf zeigen. Sie macht nicht jede RPC-, Wallet- und Synchronisierungsverbindung zu proxied Verkehr.

Die Anonymitätsnetzwerk-Dokumentation des Projekts beschreibt die Tor- und I2P-Integration als experimentell und grenzt das Weiterleitungsverhalten ab. Lesen Sie die Dokumentation für die Version, die Sie tatsächlich betreiben, denn ältere Diskussionen verwenden Namen wie Kovri und beschreiben Komponenten, die es in dieser Form nicht mehr gibt.

Halten Sie den Weiterleitungspfad im Diagramm getrennt. Eine Transaktion, die über einen Proxy hinausgeht, während die Kontostandsabfragen der Wallet einen entfernten Node nutzen, hat zwei verschiedene Beobachter, und die Tatsache, dass die Transaktion über einen Proxy lief, sagt nichts über den Abfragepfad aus.

Fügen Sie das VPN erst hinzu, nachdem die drei Pfade beschriftet sind

Markieren Sie mit den gezeichneten Pfeilen, welche das VPN tatsächlich trägt. Ein Full-Tunnel-VPN fängt die Standardroute des Hosts ab, also nutzen Verbindungen, die der Standardroute folgen, es auch. Ein Split-Tunnel, eine gebundene Schnittstelle oder ein Proxy, der über eine bestimmte Adresse hinausgeht, können einige Pfeile außerhalb des Tunnels lassen.

Formulieren Sie nun das Beobachtermodell ausdrücklich. In einem Entwurf, in dem eine Anonymitätsnetzwerk-Verbindung innerhalb des VPNs läuft, sieht das lokale Zugangsnetz die äußere VPN-Verbindung, während die VPN-Seite die weiterführende Verbindung sieht. Das ist ein Wechsel des Beobachters, kein Beweis, dass identifizierende Signale verschwinden.

Prüfen Sie das Fehlerverhalten als Teil desselben Durchgangs. Fällt das VPN aus, fällt der Daemon dann auf eine direkte Peer-Verbindung zurück, fragt die Wallet weiter den entfernten Node ab, und schließt der Weiterleitungsproxy im Fehlerfall? Ohne konfigurierte Blockierung bedeutet eine Neuverbindung meist einen neuen direkten Versuch statt Stille.

Prüfen Sie die Pfade, die Sie konfiguriert zu haben glauben

Nutzen Sie die Werkzeuge des Hosts selbst: Lesen Sie die Route für jedes Ziel, sehen Sie sich lauschende und aufgebaute Sockets an und bestätigen Sie, welcher Prozess welche Verbindung besitzt. Tun Sie das, während Wallet, Daemon und Weiterleitung alle laufen, denn ein Pfad, der nur beim Start existiert, kann nach einer Neuverbindung verschwinden.

Wiederholen Sie das nach einer VPN-Neuverbindung und nach einem Neustart des Daemons. Vergleichen Sie Ziele und Transporte mit dem Diagramm. Hat sich ein Pfeil verschoben, hat sich das Datenschutzmodell mitverschoben, selbst wenn jeder Prozess weiterhin gesund meldet.

Notieren Sie die drei Ziele, den Transport für jedes und den Beobachter, vor dem Sie sie verbergen wollen. Eine kurze Pfadkarte mit benannten Beobachtern ist nützlicher als eine einzelne VPN-Anzeige, wenn mehrere unabhängige Clients auf einer Maschine laufen.