Monero over VPN: hvilken af de tre netværksveje ændrer sig?

Åbn tegnebogen, start daemonen og tegn tre pile, før du aktiverer noget. Den ene pil løber fra tegnebogen til en nodes RPC-port, den anden bærer daemonens peer-synkronisering, og den tredje bærer lokalt indsendte transaktioner mod en videresendelsesvej. Det er forskellige forbindelser med forskellig konfiguration, og en VPN eller et anonymitetsnetværk kan dække en, to eller ingen af dem.

Gå vejene igennem i den rækkefølge, softwaren åbner dem. At mærke hver pil med sin destination og transport er det, der gør den senere privathedspåstand efterprøvbar. Rækkefølgen er vigtig, fordi den senere påstand normalt kun dækker én af dem.

Begynd med at tegne tegnebogens forbindelse til noden

En tegnebog, der taler med en fjern node, sender RPC-anmodninger til den nodes adresse og port. En tegnebog med en lokal daemon taler i stedet med loopback-grænsefladen. Det er forskellige tillidsforhold, selv om begge i daglig tale kaldes “noden”.

Skriv adressen, porten og transporten ned, som tegnebogen er konfigureret til at bruge. Hvis tegnebogen har sin egen proxyindstilling, skal du notere den separat fra daemonens indstillinger; at konfigurere den ene proces konfigurerer ikke den anden.

Det er også her, et offentligt RPC-endepunkt bliver fristende. At eksponere nodens RPC-tjeneste for at forenkle diagrammet bytter en netværksvej for et angrebsareal. Hold tegnebogens forbindelse til noden på en privat vej eller loopback-grænsefladen, og dokumentér hvilken det er. Et diagram, der skjuler den eksponering, er værre end intet diagram.

Følg derefter daemonens peer-trafik

En synkroniserende daemon åbner udgående forbindelser til peers og udveksler kædedata over sin peer-til-peer-port. Den trafik er ikke tegnebogens RPC-forbindelse og bliver ikke automatisk sendt gennem tegnebogens proxy. Den følger daemonens egne netværksindstillinger og værtens routingtabel.

Noter peer-porten, antallet af forbindelser og om daemonen er konfigureret til at bruge en proxy til peer-trafik. Tjek derefter værtens rute for en eksempel-peeradresse. Hvis VPN'en opsnapper standardruten, bruger peer-forbindelserne sandsynligvis den; hvis daemonen er bundet til en bestemt grænseflade, gør de måske ikke. De to forhold afgør pilen.

Observatørspørgsmålet ændrer sig med denne vej. En VPN skjuler peer-forbindelserne for det lokale adgangsnetværk, men VPN-endepunktet og peerne selv ser et andet billede. Ingen af de to observationer beviser, at tegnebogens anmodninger tog samme rute.

Isolér derefter transaktionernes videresendelsesvej

Lokalt indsendte transaktioner kan videresendes mod netværket gennem en konfigureret relay eller proxy. I den aktuelle dokumentation for Monero-daemonen sender den indstilling kun den transaktionsvideresendelsestrafik, du peger på proxyen. Den gør ikke hver RPC-, tegnebogs- og synkroniseringsforbindelse til proxet trafik.

Projektets dokumentation om anonymitetsnetværk beskriver Tor- og I2P-integration som eksperimentel og afgrænser videresendelsens adfærd. Læs dokumentationen for den version, du faktisk kører, fordi ældre diskussioner bruger navne som Kovri og beskriver komponenter, der ikke findes i samme form længere.

Hold videresendelsesvejen adskilt i diagrammet. En transaktion, der forlader gennem en proxy, mens tegnebogens saldosopgør bruger en fjern node, har to forskellige observatører, og det faktum, at transaktionen blev proxet, siger intet om forespørgselsvejen.

Tilføj først VPN'en, når de tre veje er mærket

Når pilene er tegnet, skal du markere, hvilke VPN'en faktisk bærer. En full-tunnel-VPN opsnapper værtens standardrute, så forbindelser, der følger standarden, bruger den. En split tunnel, en bundet grænseflade eller en proxy, der går ud gennem en bestemt adresse, kan efterlade nogle pile uden for tunnelen.

Angiv nu observatørmodellen udtrykkeligt. I et design, hvor en anonymitetsnetværksforbindelse kører inde i VPN'en, ser det lokale adgangsnetværk den ydre VPN-forbindelse, mens VPN-siden ser den videre forbindelse. Det er en ændring af observatør, ikke bevis for at identificerende signaler forsvinder.

Tjek fejladfærden som en del af samme gennemgang. Hvis VPN'en falder, falder daemonen så tilbage til en direkte peer-forbindelse, fortsætter tegnebogen med at spørge den fjernnode, og fejler videresendelsesproxyen lukket? Medmindre blokering er konfigureret, betyder en genopkobling normalt et nyt direkte forsøg frem for tavshed.

Bekræft de veje, du tror, du har konfigureret

Brug værtens egne værktøjer: læs ruten for hver destination, undersøg de lyttende og etablerede sockets, og bekræft, hvilken proces der ejer hver forbindelse. Gør det, mens tegnebogen, daemonen og videresendelsen alle kører, fordi en vej, der kun findes ved opstart, kan forsvinde efter en genopkobling.

Gentag efter en VPN-genopkobling og efter en genstart af daemonen. Sammenlign destinationerne og transporterne med diagrammet. Hvis en pil flyttede sig, flyttede privathedsmodellen sig med den, selv om hver proces stadig rapporterer, at den er sund.

Noter de tre destinationer, transporten for hver og den observatør, du vil skjule dem for. Et kort vejkort med navngivne observatører er mere nyttigt end én enkelt VPN-indikator, når flere uafhængige klienter kører på samme maskine.