Monero via een VPN: welk van de drie netwerkpaden verandert?

Open de wallet, start de daemon en teken drie pijlen voordat je iets inschakelt. Eén pijl loopt van de wallet naar de RPC-poort van een node, één draagt de peernsynchronisatie van de daemon, en één draagt lokaal ingediende transacties richting een doorstuurpad. Het zijn verschillende verbindingen met verschillende configuratie, en een VPN of anoniem netwerk kan er één, twee of geen ervan dekken.

Doorloop de paden in de volgorde waarin de software ze opent. Elke pijl labelen met zijn bestemming en transport is wat de latere privacybewering testbaar maakt. De volgorde is belangrijk, omdat de latere bewering meestal maar één ervan dekt.

Begin met het tekenen van de verbinding van de wallet naar de node

Een wallet die met een externe node praat, stuurt RPC-verzoeken naar het adres en de poort van die node. Een wallet met een lokale daemon praat in plaats daarvan met de loopback-interface. Dat zijn verschillende vertrouwensrelaties, ook al worden ze in gewone taal allebei “de node” genoemd.

Noteer het adres, de poort en het transport waarvoor de wallet is geconfigureerd. Heeft de wallet een eigen proxy-instelling, leg die dan apart vast van de instellingen van de daemon; het configureren van het ene proces configureert het andere niet.

Hier wordt een openbaar RPC-eindpunt ook verleidelijk. De RPC-dienst van de node blootleggen om het diagram te vereenvoudigen, ruilt een netwerkpad in voor een aanvalsoppervlak. Houd de koppeling van de wallet naar de node op een privépad of de loopback-interface, en documenteer welke het is. Een diagram dat die blootstelling verbergt, is slechter dan geen diagram.

Volg daarna het peerverkeer van de daemon

Een synchroniserende daemon opent uitgaande verbindingen naar peers en wisselt ketengegevens uit via zijn peer-to-peer-poort. Dat verkeer is niet de RPC-koppeling van de wallet, en het wordt niet automatisch via de proxy van de wallet gerouteerd. Het volgt de eigen netwerkinstellingen van de daemon en de routingtabel van de host.

Noteer de peer-poort, het aantal verbindingen en of de daemon is geconfigureerd om een proxy voor peerverkeer te gebruiken. Controleer daarna de host-route voor een voorbeeldpeeradres. Als de VPN de standaardroute onderschept, gebruiken de peerverbindingen die waarschijnlijk; als de daemon aan een specifieke interface is gebonden, misschien niet. Die twee feiten bepalen de pijl.

De waarnemersvraag verandert met dit pad. Een VPN verbergt de peerverbindingen voor het lokale toegangsnetwerk, maar het VPN-eindpunt en de peers zelf zien een ander beeld. Geen van beide waarnemingen bewijst dat de verzoeken van de wallet dezelfde route namen.

Isoleer daarna het doorstuurpad van transacties

Lokaal ingediende transacties kunnen via een geconfigureerde relay of proxy naar het netwerk worden doorgestuurd. In de huidige documentatie van de Monero-daemon stuurt die optie alleen het transactiedoorstuurverkeer via de proxy dat je erop richt. Het maakt niet elke RPC-, wallet- en synchronisatieverbinding tot verkeer via een proxy.

De documentatie van het project over anonieme netwerken beschrijft Tor- en I2P-integratie als experimenteel en begrenst het gedrag van het doorsturen. Lees de documentatie voor de versie die je daadwerkelijk draait, want oudere discussies gebruiken namen als Kovri en beschrijven componenten die niet meer in dezelfde vorm bestaan.

Houd het doorstuurpad apart in het diagram. Een transactie die via een proxy vertrekt terwijl de balansvragen van de wallet een externe node gebruiken, heeft twee verschillende waarnemers, en het feit dat de transactie via een proxy ging, zegt niets over het pad van de vraag.

Voeg de VPN pas toe nadat de drie paden zijn gelabeld

Markeer met de getekende pijlen welke de VPN werkelijk draagt. Een full-tunnel-VPN onderschept de standaardroute van de host, dus verbindingen die de standaard volgen, gebruiken die. Een split-tunnel, een gebonden interface of een proxy die via een specifiek adres naar buiten gaat, kunnen sommige pijlen buiten de tunnel laten.

Formuleer nu het waarnemersmodel expliciet. In een ontwerp waarin een anoniem-netwerkverbinding binnen de VPN loopt, ziet het lokale toegangsnetwerk de buitenste VPN-verbinding, terwijl de VPN-kant de verdergaande verbinding ziet. Dat is een verandering van waarnemer, geen bewijs dat identificerende signalen verdwijnen.

Controleer het faalgedrag als onderdeel van dezelfde doorloop. Als de VPN wegvalt, valt de daemon dan terug op een directe peerverbinding, blijft de wallet de externe node pollen, en faalt de doorstuurproxy gesloten? Tenzij blokkering is geconfigureerd, betekent opnieuw verbinden meestal een nieuwe directe poging in plaats van stilte.

Verifieer de paden waarvan je denkt dat je ze hebt geconfigureerd

Gebruik de eigen hulpmiddelen van de host: lees de route voor elke bestemming, bekijk de luisterende en gevestigde sockets, en bevestig welk proces elke verbinding bezit. Doe dit terwijl de wallet, de daemon en het doorsturen allemaal draaien, want een pad dat alleen bij het opstarten bestaat, kan na een herverbinding verdwijnen.

Herhaal na een VPN-herverbinding en na een herstart van de daemon. Vergelijk de bestemmingen en de transporten met het diagram. Als een pijl is verschoven, is het privacymodel meeverschoven, ook al meldt elk proces nog steeds dat het gezond is.

Noteer de drie bestemmingen, het transport voor elk en de waarnemer voor wie je ze wilt verbergen. Een korte padkaart met benoemde waarnemers is nuttiger dan één VPN-indicator wanneer er meerdere onafhankelijke clients op één machine draaien.