Monero tramite VPN: quale dei tre percorsi di rete cambia?
Il collegamento RPC del portafoglio, il traffico dei peer del demone e l'inoltro delle transazioni sono connessioni separate. Etichetta ciascuna prima che una VPN cambi quale osservatore la vede.
Apri il portafoglio, avvia il demone e disegna tre frecce prima di attivare qualsiasi cosa. Una freccia va dal portafoglio alla porta RPC di un nodo, una trasporta la sincronizzazione dei peer del demone e una trasporta le transazioni inviate localmente verso un percorso di inoltro. Sono connessioni diverse con configurazioni diverse, e una VPN o una rete di anonimato può coprirne una, due o nessuna.
Percorri i percorsi nell'ordine in cui il software li apre. Etichettare ogni freccia con la sua destinazione e il suo trasporto è ciò che rende verificabile l'affermazione successiva sulla privacy. L'ordine conta, perché l'affermazione successiva di solito ne copre solo uno.
Inizia disegnando la connessione dal portafoglio al nodo
Un portafoglio che parla con un nodo remoto invia richieste RPC all'indirizzo e alla porta di quel nodo. Un portafoglio con un demone locale parla invece con l'interfaccia di loopback. Sono relazioni di fiducia diverse, anche se in una conversazione quotidiana entrambe vengono chiamate “il nodo”.
Annota l'indirizzo, la porta e il trasporto per cui il portafoglio è configurato. Se il portafoglio ha una propria impostazione proxy, registrala separatamente da quelle del demone; configurare un processo non configura l'altro.
È anche qui che un endpoint RPC pubblico diventa tentante. Esporre il servizio RPC del nodo per semplificare lo schema scambia un percorso di rete con una superficie d'attacco. Mantieni il collegamento tra portafoglio e nodo su un percorso privato o sull'interfaccia di loopback, e documenta quale sia. Uno schema che nasconde quell'esposizione è peggiore di nessuno schema.
Poi segui il traffico dei peer del demone
Un demone che si sincronizza apre connessioni in uscita verso i peer e scambia dati della catena sulla sua porta peer-to-peer. Quel traffico non è il collegamento RPC del portafoglio e non passa automaticamente dal proxy del portafoglio. Segue le impostazioni di rete del demone stesso e la tabella di routing dell'host.
Annota la porta dei peer, il numero di connessioni e se il demone è configurato per usare un proxy per il traffico dei peer. Poi controlla la rotta dell'host per un indirizzo peer di esempio. Se la VPN cattura la rotta predefinita, le connessioni dei peer probabilmente la usano; se il demone è legato a un'interfaccia specifica, forse no. Questi due fatti decidono la freccia.
La domanda sull'osservatore cambia con questo percorso. Una VPN nasconde le connessioni dei peer alla rete di accesso locale, ma l'endpoint della VPN e i peer stessi vedono un'immagine diversa. Nessuna delle due osservazioni prova che le richieste del portafoglio abbiano preso la stessa rotta.
Poi isola il percorso di inoltro delle transazioni
Le transazioni inviate localmente possono essere inoltrate verso la rete attraverso un relè o un proxy configurato. Nella documentazione attuale del demone Monero, quell'opzione invia al proxy solo il traffico di inoltro delle transazioni che vi indirizzi. Non trasforma ogni connessione RPC, del portafoglio e di sincronizzazione in traffico intermediato.
La documentazione del progetto sulle reti di anonimato descrive l'integrazione di Tor e I2P come sperimentale e delimita il comportamento dell'inoltro. Leggi la documentazione della versione che esegui davvero, perché discussioni più vecchie usano nomi come Kovri e descrivono componenti che non esistono più nella stessa forma.
Mantieni il percorso di inoltro separato nello schema. Una transazione che esce attraverso un proxy mentre le query sul saldo del portafoglio usano un nodo remoto ha due osservatori diversi, e il fatto che la transazione sia passata da un proxy non dice nulla sul percorso della query.
Aggiungi la VPN solo dopo aver etichettato i tre percorsi
Con le frecce disegnate, segna quali la VPN trasporta davvero. Una VPN a tunnel completo cattura la rotta predefinita dell'host, quindi le connessioni che seguono la predefinita la useranno. Un tunnel diviso, un'interfaccia legata o un proxy che esce attraverso un indirizzo specifico possono lasciare alcune frecce fuori dal tunnel.
Ora esponi esplicitamente il modello di osservatore. In un progetto in cui una connessione di rete di anonimato gira dentro la VPN, la rete di accesso locale vede la connessione VPN esterna, mentre il lato VPN vede la connessione successiva. È un cambio di osservatore, non la prova che i segnali identificativi spariscano.
Controlla il comportamento in caso di guasto come parte dello stesso percorso. Se la VPN cade, il demone torna a una connessione diretta con i peer, il portafoglio continua a interrogare il nodo remoto e il proxy di inoltro fallisce in modo chiuso? A meno che il blocco sia configurato, una riconnessione di solito significa un nuovo tentativo diretto invece del silenzio.
Verifica i percorsi che credi di aver configurato
Usa gli strumenti dell'host stesso: leggi la rotta per ogni destinazione, ispeziona i socket in ascolto e stabiliti, e conferma quale processo possiede ogni connessione. Fallo mentre portafoglio, demone e inoltro sono tutti in esecuzione, perché un percorso che esiste solo all'avvio può sparire dopo una riconnessione.
Ripeti dopo una riconnessione della VPN e dopo un riavvio del demone. Confronta le destinazioni e i trasporti con lo schema. Se una freccia si è spostata, il modello di privacy si è spostato con lei, anche se ogni processo continua a dichiararsi sano.
Annota le tre destinazioni, il trasporto di ciascuna e l'osservatore a cui intendi sottrarle. Una breve mappa dei percorsi con osservatori nominati è più utile di un singolo indicatore VPN quando sulla stessa macchina girano più client indipendenti.