Monero over VPN: hvilken av de tre nettverksveiene endres?

Åpne lommeboken, start daemonen og tegn tre piler før du aktiverer noe. Én pil går fra lommeboken til RPC-porten til en node, én bærer daemonens peer-synkronisering, og én bærer lokalt innsendte transaksjoner mot en videresendingsvei. Dette er forskjellige forbindelser med forskjellig konfigurasjon, og en VPN eller et anonymitetsnett kan dekke én, to eller ingen av dem.

Gå gjennom veiene i den rekkefølgen programvaren åpner dem. Å merke hver pil med destinasjon og transport er det som gjør den senere personvernpåstanden etterprøvbar. Rekkefølgen betyr noe, fordi den senere påstanden vanligvis bare dekker én av dem.

Begynn med å tegne forbindelsen fra lommeboken til noden

En lommebok som snakker med en ekstern node, sender RPC-forespørsler til den nodens adresse og port. En lommebok med en lokal daemon snakker i stedet med loopback-grensesnittet. Dette er forskjellige tillitsforhold, selv om begge i dagligtale kalles «noden».

Skriv ned adressen, porten og transporten som lommeboken er konfigurert til å bruke. Hvis lommeboken har sin egen proxy-innstilling, noter den atskilt fra daemonens innstillinger; å konfigurere én prosess konfigurerer ikke den andre.

Det er også her et offentlig RPC-endepunkt blir fristende. Å eksponere nodens RPC-tjeneste for å forenkle diagrammet bytter en nettverksvei mot et angrepsareal. Hold forbindelsen fra lommeboken til noden på en privat vei eller loopback-grensesnittet, og dokumenter hvilken det er. Et diagram som skjuler den eksponeringen, er verre enn ingen diagram.

Deretter følger du daemonens peer-trafikk

En synkroniserende daemon åpner utgående forbindelser til peers og utveksler kjedadata over sin peer-til-peer-port. Den trafikken er ikke lommebokens RPC-forbindelse, og den rutes ikke automatisk gjennom lommebokens proxy. Den følger daemonens egne nettverksinnstillinger og vertens rutingtabell.

Noter peer-porten, antallet forbindelser og om daemonen er konfigurert til å bruke en proxy for peer-trafikk. Sjekk deretter vertens rute for en eksempel-peer-adresse. Hvis VPN-en fanger standardruten, bruker peer-forbindelsene den sannsynligvis; hvis daemonen er bundet til et bestemt grensesnitt, gjør de kanskje ikke det. De to fakta avgjør pilen.

Observatørspørsmålet endres med denne veien. En VPN skjuler peer-forbindelsene for det lokale aksessnettet, men VPN-endepunktet og peerne selv ser et annet bilde. Ingen av de to observasjonene beviser at lommebokens forespørsler tok samme rute.

Isoler deretter videresendingsveien for transaksjoner

Lokalt innsendte transaksjoner kan videresendes mot nettverket gjennom en konfigurert relay eller proxy. I gjeldende dokumentasjon for Monero-daemonen sender det alternativet bare den transaksjonsvideresendingstrafikken du peker på proxyen. Det gjør ikke hver RPC-, lommebok- og synkroniseringsforbindelse til trafikk via proxy.

Prosjektets dokumentasjon om anonymitetsnett beskriver Tor- og I2P-integrasjonen som eksperimentell og avgrenser videresendingsatferden. Les dokumentasjonen for versjonen du faktisk kjører, fordi eldre diskusjoner bruker navn som Kovri og beskriver komponenter som ikke finnes i samme form lenger.

Hold videresendingsveien atskilt i diagrammet. En transaksjon som går ut gjennom en proxy mens lommebokens saldoforespørsler bruker en ekstern node, har to forskjellige observatører, og at transaksjonen ble sendt via proxy sier ingenting om forespørselsveien.

Legg til VPN-en først etter at de tre veiene er merket

Med pilene tegnet, marker hvilke VPN-en faktisk bærer. En full-tunnel-VPN fanger vertens standardrute, så forbindelser som følger standardruten bruker den. En delt tunnel, et bundet grensesnitt eller en proxy som går ut gjennom en bestemt adresse kan la noen piler bli stående utenfor tunnelen.

Nå angi observatørmodellen eksplisitt. I et design der en anonymitetsnettforbindelse kjører inne i VPN-en, ser det lokale aksessnettet den ytre VPN-forbindelsen, mens VPN-siden ser den videre forbindelsen. Det er en endring av observatør, ikke bevis for at identifiserende signaler forsvinner.

Sjekk feilatferden som en del av samme gjennomgang. Hvis VPN-en faller, faller daemonen da tilbake til en direkte peer-forbindelse, fortsetter lommeboken å spørre den eksterne noden, og feiler videresendingsproxyen lukket? Med mindre blokkering er konfigurert, betyr en gjenoppkobling vanligvis et nytt direkte forsøk i stedet for stillhet.

Bekreft veiene du tror du har konfigurert

Bruk vertens egne verktøy: les ruten for hver destinasjon, undersøk de lyttende og etablerte socketene, og bekreft hvilken prosess som eier hver forbindelse. Gjør dette mens lommeboken, daemonen og videresendingen alle kjører, fordi en vei som bare finnes ved oppstart kan forsvinne etter en gjenoppkobling.

Gjenta etter en VPN-gjenoppkobling og etter en omstart av daemonen. Sammenlign destinasjonene og transportene med diagrammet. Hvis en pil flyttet seg, flyttet personvernmodellen seg med den, selv om hver prosess fortsatt rapporterer at den er sunn.

Noter de tre destinasjonene, transporten for hver og observatøren du vil skjule dem for. Et kort veikart med navngitte observatører er nyttigere enn én enkelt VPN-indikator når flere uavhengige klienter kjører på samme maskin.