Monero per VPN: quin dels tres camins de xarxa canvia?

Obriu el moneder, inicieu el dimoni i dibuixeu tres fletxes abans d'activar res. Una fletxa va del moneder al port RPC d'un node, una altra porta la sincronització d'igualots del dimoni i una tercera porta les transaccions enviades localment cap a un camí de retransmissió. Són connexions diferents amb configuracions diferents, i una VPN o una xarxa d'anonimat pot cobrir-ne una, dues o cap.

Recorreu els camins en l'ordre en què el programari els obre. Etiquetar cada fletxa amb la seva destinació i el seu transport és el que fa verificable l'afirmació posterior sobre la privadesa. L'ordre importa, perquè l'afirmació posterior normalment només en cobreix un.

Comenceu dibuixant la connexió del moneder al node

Un moneder que parla amb un node remot envia peticions RPC a l'adreça i el port d'aquell node. Un moneder amb un dimoni local parla en canvi amb la interfície de bucle local. Són relacions de confiança diferents, encara que en una conversa informal totes dues s'anomenin “el node”.

Anoteu l'adreça, el port i el transport que el moneder té configurats per utilitzar. Si el moneder té la seva pròpia configuració de servidor intermediari, registreu-la per separat de la del dimoni; configurar un procés no configura l'altre.

Aquí és també on un punt final RPC públic es torna temptador. Exposar el servei RPC del node per simplificar el diagrama bescanvia un camí de xarxa per una superfície d'atac. Mantingueu l'enllaç del moneder al node en un camí privat o a la interfície de bucle local, i documenteu quin és. Un diagrama que amaga aquesta exposició és pitjor que cap diagrama.

A continuació, seguiu el trànsit d'igualots del dimoni

Un dimoni que se sincronitza obre connexions sortints cap als igualots i intercanvia dades de la cadena pel seu port d'igual a igual. Aquest trànsit no és l'enllaç RPC del moneder i no passa automàticament pel servidor intermediari del moneder. Segueix la configuració de xarxa pròpia del dimoni i la taula d'encaminament de l'amfitrió.

Anoteu el port d'igualots, el nombre de connexions i si el dimoni està configurat per fer servir un servidor intermediari per al trànsit d'igualots. Després comproveu la ruta de l'amfitrió per a una adreça d'igualot de mostra. Si la VPN captura la ruta per defecte, les connexions d'igualots probablement la fan servir; si el dimoni està lligat a una interfície concreta, potser no. Aquests dos fets decideixen la fletxa.

La qüestió de l'observador canvia amb aquest camí. Una VPN amaga les connexions d'igualots de la xarxa d'accés local, però el punt final de la VPN i els mateixos igualots veuen una imatge diferent. Cap de les dues observacions no demostra que les peticions del moneder hagin seguit la mateixa ruta.

Després aïlleu el camí de retransmissió de transaccions

Les transaccions enviades localment es poden reenviar cap a la xarxa a través d'un relé o un servidor intermediari configurat. A la documentació actual del dimoni de Monero, aquesta opció només envia el trànsit de retransmissió de transaccions que dirigiu al servidor intermediari. No converteix cada connexió RPC, del moneder i de sincronització en trànsit intermediat.

La documentació del projecte sobre xarxes d'anonimat descriu la integració de Tor i I2P com a experimental i delimita l'abast del comportament de retransmissió. Llegiu la documentació de la versió que realment executeu, perquè debats més antics fan servir noms com Kovri i descriuen components que ja no existeixen en la mateixa forma.

Mantingueu el camí de retransmissió separat al diagrama. Una transacció que surt per un servidor intermediari mentre les consultes de saldo del moneder fan servir un node remot té dos observadors diferents, i el fet que la transacció passés pel servidor intermediari no diu res sobre el camí de la consulta.

Afegiu la VPN només després d'etiquetar els tres camins

Amb les fletxes dibuixades, marqueu quines transporta realment la VPN. Una VPN de túnel complet captura la ruta per defecte de l'amfitrió, així que les connexions que segueixen la ruta per defecte la faran servir. Un túnel dividit, una interfície lligada o un servidor intermediari que surt per una adreça concreta poden deixar algunes fletxes fora del túnel.

Ara exposeu el model d'observador explícitament. En un disseny en què una connexió de xarxa d'anonimat funciona dins de la VPN, la xarxa d'accés local veu la connexió VPN exterior, mentre que el costat de la VPN veu la connexió cap endavant. Això és un canvi d'observador, no una prova que els senyals identificadors desapareguin.

Comproveu el comportament davant de fallades com a part del mateix recorregut. Si la VPN cau, el dimoni torna a una connexió directa amb els igualots, el moneder continua consultant el node remot i el servidor intermediari de retransmissió falla tancat? Llevat que el bloqueig estigui configurat, una reconnexió normalment significa un nou intent directe en lloc de silenci.

Verifiqueu els camins que creieu haver configurat

Feu servir les eines de l'amfitrió: llegiu la ruta de cada destinació, inspeccioneu els sòcols en escolta i establerts, i confirmeu quin procés posseeix cada connexió. Feu-ho mentre el moneder, el dimoni i la retransmissió estan tots en marxa, perquè un camí que només existeix a l'inici pot desaparèixer després d'una reconnexió.

Repetiu-ho després d'una reconnexió de la VPN i després de reiniciar el dimoni. Compareu les destinacions i els transports amb el diagrama. Si una fletxa s'ha mogut, el model de privadesa s'ha mogut amb ella, encara que cada procés segueixi informant que està sa.

Anoteu les tres destinacions, el transport de cada una i l'observador del qual voleu amagar-les. Un mapa curt de camins amb observadors nomenats és més útil que un sol indicador de VPN quan hi ha diversos clients independents en una mateixa màquina.