OpenVPN remote-random: ordine mescolato, un solo tunnel

L’ipotesi è che aggiungere remote-random trasformi un profilo in un pool rotante, così ogni connessione esce da un indirizzo diverso. Ciò che la direttiva fa davvero è mescolare l’elenco dei remote una volta, quando il client inizia a connettersi, e poi provarli in questo nuovo ordine. Il tunnel che alla fine sale termina comunque su un solo endpoint e vi resta per tutta la durata della sessione.

Questa differenza conta sia per i test sia per le affermazioni sulla privacy.

Cosa cambia l’opzione al momento della connessione

Un profilo client può contenere più righe remote, ciascuna con il proprio nome host e la propria porta. Senza la direttiva vengono provate nell’ordine del file; con essa, l’elenco viene permutato una volta all’inizio della sessione e vince il primo indirizzo che risponde. Gli altri restano soluzioni di riserva per questo tentativo, non percorsi paralleli. Un profilo con un solo remote non dà nulla da mescolare alla direttiva, ed è il modo più rapido per vedere se può avere importanza.

Il manuale di OpenVPN documenta l’opzione come influente sull’ordine dei tentativi di connessione, ed è esattamente la portata da attendersi nel comportamento.

Una riconnessione avvia un nuovo ciclo di selezione, quindi una sessione successiva può finire altrove. Il tunnel attivo non si sposta finché è in piedi.

Mito: ogni richiesta ottiene un nuovo server

Una volta stabilito, il tunnel porta tutto il traffico di quella sessione al peer scelto. Non c’è riselezione per richiesta, e la direttiva non è un bilanciatore di carico per le singole connessioni: mescola i candidati, non distribuisce i pacchetti. Ogni applicazione che condivide quel tunnel condivide lo stesso peer. Qualunque cosa un browser riporti sulla propria uscita appartiene alla sessione, non a una singola richiesta.

Se un test mostra due uscite diverse, cerca due sessioni separate invece di un’opzione astuta. Questa distinzione spiega anche perché un test del browser e un test di download possono discordare quando tra loro è avvenuta una riconnessione.

A cosa serve remote-random-hostname

Una seconda direttiva dal nome simile cambia il nome host usato per la risoluzione, non l’ordine dell’elenco dei remote. Esiste per distribuzioni in cui un nome si risolve in più indirizzi tramite DNS round-robin, e va usata solo quando il servizio è costruito per questo. Cambia solo il passaggio di risoluzione; l’ordine dell’elenco dei candidati no.

Attivarla perché i nomi sembrano correlati è un errore comune. Un certificato wildcard o una configurazione DNS che non si aspetta il nome modificato semplicemente non risolverà o non convaliderà.

Leggi l’endpoint selezionato dal registro

Annota quale peer una sessione ha realmente usato prima di trarre conclusioni. L’output dettagliato indica l’indirizzo in prova, e il profilo stesso mostra quanti candidati esistono. Confronta quel numero con l’indirizzo nel registro prima di dare la colpa al mescolamento.

grep -c '^remote ' client.ovpn
openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'attempting|peer connection'
openvpn --help | grep -A2 remote-random
head -20 client.ovpn

Per un confronto delle prestazioni, fissa l’endpoint commentando gli altri remote, così che la variabile in prova sia il protocollo o il client anziché il percorso. Per una questione di privacy, valuta l’identità del servizio e la sua registrazione nel loro insieme; una prima scelta mescolata non cancella i cookie, non rimuove l’accesso all’account e non rende equivalenti due operatori.

Tieni insieme il materiale di fiducia fornito e l’insieme di endpoint supportati. Il rimescolamento cambia solo l’ordine in cui tale insieme viene provato.