Avviare una seconda VPN sostituisce lo stato della prima

Due client, due icone collegate e la convinzione che il traffico ora passi attraverso entrambi. Confrontate questa convinzione con ciò che ogni piattaforma consente davvero. Un telefono di solito ha esattamente uno slot per un servizio VPN; un desktop può eseguire diversi client che si contendono le stesse rotte e lo stesso resolver. La differenza tra queste due situazioni spiega la maggior parte delle segnalazioni di VPN che cade quando ne parte un’altra.

Le icone descrivono processi, non una catena.

Uno slot sul telefono, diversi pretendenti sul desktop

Su Android la piattaforma offre un modello di servizio VPN con un solo VPN attivo per profilo utente, quindi avviarne un secondo ferma il primo. È il sistema che applica la propria regola, non un bug in uno dei client. Su un desktop diversi client possono restare in esecuzione contemporaneamente, e allora si contendono la tabella di routing, le regole di policy, la configurazione del resolver e le interfacce virtuali. Entrambi gli esiti sono la piattaforma che funziona come previsto.

Nessuno dei due esiti produce da solo un tunnel annidato. Una catena richiede che un tunnel trasporti i pacchetti cifrati dell’altro, e questa è architettura, non una coincidenza di ordine.

Cosa sovrascrive il secondo client

Il secondo client di solito installa una rotta predefinita, aggiunge le proprie regole e impone il proprio resolver. Il primo può sopravvivere come processo senza traffico, o mantenere una rotta che non vince più. Le rotte specifiche di dominio sono la vittima abituale, ed è per questo che alcune destinazioni continuano a funzionare mentre altre falliscono. Il sintomo visibile è una disconnessione, e lo stato reale è una sostituzione parziale.

Un controllo dell’IP di uscita non lo rivelerà. Riporta un indirizzo per una destinazione e non dice nulla su quali rotte siano state sovrascritte o quale resolver risponda ora. Per vedere il danno, leggete la tabella di routing e lo stato del resolver.

L’annidamento è un progetto, non un ordine di clic

Se l’annidamento è l’intenzione, documentate il percorso esterno di ogni endpoint, la sua politica di errore e le conseguenze sulla MTU. Decidete cosa succede quando il tunnel esterno cade mentre quello interno crede ancora di essere connesso. Avviare i client in un ordine fortunato non è una configurazione, perché il prossimo aggiornamento o la riconnessione li riordina. Un assetto annidato richiede la stessa cura di qualsiasi altra topologia.

Quando una connessione è per il lavoro e un’altra è personale, affidatevi all’isolamento o all’assetto gestito che la piattaforma supporta. Strappare i controlli aziendali non è una strategia di separazione.

Verificate con l’applicazione, non con l’icona

Esercitate le applicazioni che contano davvero, da ogni contesto che intendete usare, e includete nel test il comportamento del resolver e le riconnessioni. Un indirizzo di uscita finale non può identificare ogni rotta sovrascritta, e un’icona verde non può identificarne nessuna. Annotate chi possiede la connessione e quale combinazione è realmente supportata.

Se un prodotto non supporta esplicitamente la coesistenza con un altro, un cambiamento casuale di rotta o di autorizzazione non produrrà una distribuzione mantenibile. Ne produrrà una che funziona fino al prossimo aggiornamento.

Annotate quale client possiede la rotta predefinita, quale resolver risponde e cosa succede quando ciascuno si ferma.