Due dispositivi, un solo Wi-Fi, uscite VPN diverse: cosa lo decide

Due portatili sullo stesso router di casa possono raggiungere Internet attraverso uscite VPN diverse, e il Wi-Fi condiviso non ha nulla da dire al riguardo. Ciò che decide il risultato è dove gira il tunnel e quale politica sceglie il percorso per ogni richiesta. La convinzione opposta è altrettanto comune e altrettanto sbagliata: due dispositivi con profili separati non producono automaticamente due indirizzi pubblici. Entrambi gli errori nascono dal trattare un indirizzo come se fossero tre.

Tre indirizzi, e solo uno di essi esce

Un portatile ha un indirizzo sulla LAN di casa che lo identifica sul segmento locale, e può avere anche un indirizzo di tunnel assegnato all’interno della VPN. Nessuno dei due è visibile a un servizio remoto. Ciò che quel servizio registra è l’indirizzo di uscita pubblico del dispositivo che alla fine invia il pacchetto, dopo qualsiasi traduzione lungo il percorso.

La RFC 3022 traccia la distinzione che spiega gran parte della confusione qui. Il NAT tradizionale mappa indirizzi interni su indirizzi pubblici, mentre la traduzione delle porte consente a molti indirizzi interni di condividere un solo indirizzo pubblico contemporaneamente. Una famiglia con un indirizzo pubblico e diversi dispositivi è il secondo caso, ed è il valore predefinito quasi ovunque.

Conta gli indirizzi pubblici, non i profili. Due client con indirizzi di tunnel diversi e la stessa politica di uscita producono un solo indirizzo osservato, e un singolo client con un’uscita instradata diversamente può produrne un altro. Quell’unico confronto è tutta la prova. Tutto il resto è un’ipotesi sull’estremità remota.

Che cosa rende davvero diverse due uscite

Un’uscita è diversa quando l’ultimo dispositivo prima di Internet usa un indirizzo pubblico diverso per quel traffico. Può accadere perché la VPN termina in un altro luogo, perché il pool di uscita assegna un altro indirizzo, o perché il fornitore instrada la richiesta attraverso un’altra uscita. Tutte e tre sono decisioni di politica prese all’estremità remota, e nessuna è visibile dal router di casa.

Due dispositivi che eseguono ciascuno il proprio client con lo stesso profilo finiscono di solito nello stesso pool e spesso ricevono la stessa uscita per una data sessione. Non è un difetto, è il comportamento normale di un pool condiviso. Ottenere uscite distinte di solito significa chiedere al servizio assegnazioni distinte invece di configurare il client due volte.

Leggi i termini del servizio sulle connessioni simultanee prima di progettare intorno a una garanzia. Un secondo accesso è un permesso a connettersi, non una promessa di indirizzo esclusivo. Se i termini tacciono, chiedi al fornitore invece di supporre. La risposta cambia il progetto più di qualsiasi impostazione del client.

Perché profili separati non sono uscite separate

Un profilo descrive come raggiungere la VPN e come autenticarsi, e non dice quasi nulla su ciò che accade dopo. L’uscita è scelta dall’estremità remota, dove vivono l’instradamento, i pool di indirizzi e la politica di traduzione. Duplicare un profilo su una seconda macchina duplica la configurazione del client, non la decisione del server.

Vale anche il contrario. Un server VPN può presentare più di un’uscita pubblica quando il suo instradamento e la sua politica di traduzione sono costruiti così, mentre server separati possono alimentare un’unica uscita a valle. Quindi il numero di nomi di server nella configurazione non dice nulla sul numero di indirizzi. Per questo la configurazione è il posto sbagliato in cui cercare questa risposta.

L’unica risposta affidabile viene da una richiesta fatta attraverso la disposizione che intendi usare. Tutto il resto è inferenza.

Dove mettere la separazione

Un tunnel sul router copre l’intera famiglia, il che è comodo e produce esattamente un’uscita condivisa per ogni dispositivo dietro di esso. Un client su ogni dispositivo ti dà controllo per dispositivo, ma richiede che ogni dispositivo sia approvvigionato e resti tale. Un router capace di politiche sta nel mezzo, sceglie un percorso per dispositivo, e funziona solo se riesce a identificare i dispositivi in modo affidabile attraverso riconnessioni e cambi DHCP.

Creare un altro lease DHCP privato sul router non è lo stesso che creare un altro indirizzo pubblico. Cambia la vista locale e lascia l’uscita intatta. La separazione vive nella politica di uscita, sia che quella politica stia sul router sia nel servizio VPN.

Qualunque forma scegli, annota la proprietà: chi approvvigiona un dispositivo, chi ruota le sue credenziali e chi nota quando smette di usare il percorso previsto.

Verifica l’uscita che hai effettivamente ottenuto

Fai la verifica dall’applicazione che conta, e confronta la stessa famiglia di indirizzi su entrambi i dispositivi. Un risultato IPv4 da uno e un risultato IPv6 dall’altro non provano nulla su nessuno dei due. Poi ripeti la verifica dopo una riconnessione, perché l’assegnazione del pool può cambiare tra le sessioni.

Eseguilo da un terminale dentro la politica del tunnel, non da un dispositivo che la aggira. L’host sbagliato produce una risposta sbagliata e sicura.

curl -4 -sS https://api.ipify.org; echo
curl -6 -sS https://api64.ipify.org; echo
ip route get 1.1.1.1

Se entrambi i dispositivi stampano lo stesso indirizzo IPv4, condividono un’uscita indipendentemente da quanti tunnel sono attivi. Poi decidi cosa succede quando il tunnel fallisce: un client che ricade sul percorso diretto riporta entrambi i dispositivi sull’indirizzo di casa, e la separazione scompare senza errori. Conferma quel comportamento di ricaduta prima di descrivere la disposizione come due uscite, e ricorda che indirizzi diversi sono un risultato di rete e non due identità anonime.