Monero a través dun VPN: cal das tres rutas de rede cambia?

Abra a carteira, inicie o demo e debuxe tres frechas antes de activar nada. Unha frecha vai da carteira ao porto RPC dun nodo, outra leva a sincronización de pares do demo e outra leva as transaccións enviadas localmente cara a unha ruta de retransmisión. Son conexións distintas con configuracións distintas, e un VPN ou unha rede de anonimato pode cubrir unha, dúas ou ningunha delas.

Percorra as rutas na orde en que o software as abre. Etiquetar cada frecha co seu destino e o seu transporte é o que fai verificable a afirmación posterior sobre a privacidade. A orde importa, porque a afirmación posterior adoita cubrir só unha delas.

Comece debuxando a conexión da carteira ao nodo

Unha carteira que fala cun nodo remoto envía solicitudes RPC ao enderezo e ao porto dese nodo. Unha carteira cun demo local fala en cambio coa interface de bucle local. Son relacións de confianza distintas, aínda que nunha conversa informal ambas se chamen “o nodo”.

Anote o enderezo, o porto e o transporte que a carteira ten configurados. Se a carteira ten a súa propia configuración de proxy, rexístrea por separado da do demo; configurar un proceso non configura o outro.

Aquí tamén é onde un punto final RPC público se volve tentador. Expor o servizo RPC do nodo para simplificar o diagrama cambia unha ruta de rede por unha superficie de ataque. Manteña a ligazón da carteira ao nodo nunha ruta privada ou na interface de bucle local, e documente cal é. Un diagrama que oculta esa exposición é peor que ningún diagrama.

A continuación, siga o tráfico de pares do demo

Un demo que se sincroniza abre conexións saíntes cara aos pares e intercambia datos da cadea polo seu porto de par a par. Ese tráfico non é a ligazón RPC da carteira e non pasa automaticamente polo proxy da carteira. Segue a configuración de rede propia do demo e a táboa de rutas do servidor.

Anote o porto de pares, o número de conexións e se o demo está configurado para usar un proxy para o tráfico de pares. Despois comprobe a ruta do servidor para un enderezo de par de mostra. Se o VPN captura a ruta predeterminada, as conexións de pares probablemente a usan; se o demo está ligado a unha interface concreta, pode que non. Eses dous feitos deciden a frecha.

A pregunta sobre o observador cambia con esta ruta. Un VPN oculta as conexións de pares da rede de acceso local, pero o extremo do VPN e os propios pares ven unha imaxe distinta. Ningunha das dúas observacións demostra que as solicitudes da carteira tomaran a mesma ruta.

Despois illade a ruta de retransmisión de transaccións

As transaccións enviadas localmente poden reenviarse cara á rede a través dun relé ou un proxy configurado. Na documentación actual do demo de Monero, esa opción envía polo proxy só o tráfico de retransmisión de transaccións que vostede dirixa a el. Non converte cada conexión RPC, de carteira e de sincronización en tráfico intermediado.

A documentación do proxecto sobre redes de anonimato describe a integración de Tor e I2P como experimental e delimita o alcance do comportamento de retransmisión. Lea a documentación da versión que executa realmente, porque debates máis antigos usan nomes como Kovri e describen compoñentes que xa non existen na mesma forma.

Manteña a ruta de retransmisión separada no diagrama. Unha transacción que sae por un proxy mentres as consultas de saldo da carteira usan un nodo remoto ten dous observadores distintos, e o feito de que a transacción pasase por un proxy non di nada sobre a ruta da consulta.

Engada o VPN só despois de etiquetar as tres rutas

Coas frechas debuxadas, marque cales transporta realmente o VPN. Un VPN de túnel completo captura a ruta predeterminada do servidor, así que as conexións que seguen a predeterminada usarana. Un túnel dividido, unha interface ligada ou un proxy que sae por un enderezo concreto poden deixar algunhas frechas fóra do túnel.

Agora expoña o modelo de observador de forma explícita. Nun deseño no que unha conexión de rede de anonimato funciona dentro do VPN, a rede de acceso local ve a conexión VPN exterior, mentres que o lado do VPN ve a conexión cara adiante. Iso é un cambio de observador, non unha proba de que os sinais identificadores desaparezan.

Revise o comportamento ante fallos como parte do mesmo percorrido. Se o VPN cae, o demo volve a unha conexión directa con pares, a carteira segue consultando o nodo remoto e o proxy de retransmisión falla pechado? A non ser que o bloqueo estea configurado, unha reconexión adoita significar un novo intento directo en lugar de silencio.

Verifique as rutas que cre ter configurado

Use as ferramentas do propio servidor: lea a ruta de cada destino, inspeccione os sockets en escoita e establecidos, e confirme que proceso posúe cada conexión. Fágao mentres a carteira, o demo e a retransmisión están todos en marcha, porque unha ruta que só existe no arranque pode desaparecer tras unha reconexión.

Repita tras unha reconexión do VPN e tras reiniciar o demo. Compare os destinos e os transportes co diagrama. Se unha frecha se moveu, o modelo de privacidade moveuse con ela, aínda que cada proceso siga informando de que está san.

Anote os tres destinos, o transporte de cada un e o observador do que pretende ocultalos. Un mapa curto de rutas con observadores nomeados é máis útil que un único indicador de VPN cando hai varios clientes independentes nunha mesma máquina.