Due VPN su un solo telefono: scegliere la disposizione, non il numero di app

Usare due VPN non è un’unica richiesta. Può significare raggiungere due organizzazioni una dopo l’altra, tenere separate le app di lavoro e quelle personali, oppure far girare un tunnel dentro un altro. Android gestisce questi tre casi in modi del tutto diversi, e il numero di app VPN installate sul telefono non è l’architettura. La domanda che li separa è semplice: due percorsi devono esistere nello stesso momento per la stessa app?

Tre disposizioni, una domanda

Se la risposta è no, perché le due reti sono usate in momenti diversi, si vuole un cambio deliberato. Se la risposta è no perché le app stesse sono separate, si vuole una separazione dei profili, in cui ogni app sta nel contesto che possiede il suo tunnel. Se la risposta è sì, e un percorso deve portare fisicamente l’altro, si vuole una catena, ed è l’unica delle tre in cui l’ordine fa parte del progetto.

Tutto il resto deriva da quella scelta. Il cambio ha una finestra di transizione, la separazione ha un confine di policy, e una catena ha un costo di overhead e di dipendenza. Scegliere quella sbagliata non fallisce in modo pulito; produce un telefono che sembra connesso e un’app che non raggiunge nulla.

Cambiare dentro un solo contesto utente

Android consente un solo servizio VPN attivo per utente. Avviare una seconda app VPN nello stesso contesto sostituisce la prima o viene rifiutato di netto; non compone mai i due insiemi di rotte e di certo non impila la loro cifratura. Dentro un utente, due tunnel sono una sequenza, non una somma.

Ciò è praticabile quando l’accesso è davvero sequenziale. Assegnate nomi ai profili in modo che quello attivo sia ovvio, terminate qualsiasi cosa sensibile prima di cambiare, e aspettatevi una breve finestra in cui nessuno dei due percorsi è pienamente stabilito. Chiudere una scheda del browser non equivale a terminare una sessione: la scheda può conservare lo stato del suo account e semplicemente inviare la richiesta successiva sulla rete appena scelta, ed è esattamente la fuga che la gente nota dopo.

Ciò che il cambio non può dare è una macchina che sia su entrambe le reti nello stesso momento. Se un’app ha bisogno di un indirizzo privato da ciascun lato, nessuna disciplina del client lo produrrà.

Separare per profilo

Un profilo di lavoro gestito è un utente separato con le proprie app, il proprio keystore e la propria policy di rete. Un client di posta di lavoro può usare il tunnel dell’organizzazione mentre un browser personale ne usa uno personale, ed entrambi possono essere connessi contemporaneamente perché non sono nello stesso contesto a contendersi lo slot.

La separazione è anche il limite. Il browser personale non prende in prestito il tunnel di lavoro, non vede i suffissi DNS di lavoro e non raggiunge la rete di lavoro solo perché entrambi i servizi risultano connessi. Quando qualcuno segnala che un link non si apre, controllate quale copia dell’app lo ha gestito e quale profilo possiede quell’account prima di toccare uno dei due VPN.

Trattate il confine come fisso. Creare un secondo profilo o rimuovere un profilo di lavoro per aggirare una decisione di routing del datore di lavoro distrugge proprio la separazione che faceva funzionare la disposizione, e su un dispositivo gestito di solito è una violazione di policy più che una modifica di configurazione.

Una catena, dove l’ordine è il progetto

Una catena è la disposizione che la gente intende di solito quando dice entrambi insieme: il tunnel del telefono viaggia dentro il tunnel del router. Può funzionare, e i vincoli sono specifici. Il provider esterno deve consentire un percorso funzionante verso l’endpoint VPN del telefono, il che per i protocolli basati su UDP significa che il servizio esterno non deve bloccare né limitare quel traffico.

Capite chi vede cosa. Il provider esterno vede una connessione verso l’endpoint interno. Il provider interno riceve il traffico del telefono dall’uscita esterna e lo inoltra. La destinazione finale di solito vede l’uscita del servizio interno, e nessun provider lungo la catena è cieco; gli account delle applicazioni identificano comunque l’utente indipendentemente dal percorso.

Aspettatevi costi pratici. Ogni strato aggiunge incapsulamento, quindi l’MTU effettivo scende e un valore che andava bene per un tunnel ora si frammenta o si blocca finché l’MTU del tunnel interno non viene impostato in modo prudente. Due strati significano anche due dipendenze dai guasti e due insiemi di messaggi di keepalive, e un tunnel interno basato su TCP su un collegamento esterno con perdite può bloccarsi in modi che sembrano un server morto.

Soprattutto, una catena non fonde due reti private. Le rotte, i prefissi sovrapposti, la risoluzione DNS e le regole di accesso restano decisioni separate, e un router che porta un VPN mentre un telefono ne porta un altro non concede al telefono entrambi gli spazi di indirizzi.

Verificate il progetto prima di eseguirne il debug

Scrivete la disposizione in una frase e provatela contro l’app che ha fallito. L’accesso sequenziale dovrebbe mostrare un tunnel alla volta; la separazione dei profili dovrebbe mostrare ogni app nel proprio utente; una catena dovrebbe mostrare il tunnel interno stabilirsi su un’interfaccia esterna anziché su quella fisica.

adb shell ip -br addr
adb shell ip route get 10.20.0.8
adb shell dumpsys connectivity | grep -i vpn

Se la ricerca della rotta nomina l’interfaccia fisica mentre un’app si aspetta il tunnel, il progetto e il contesto dell’app non concordano, e nessuna app VPN aggiuntiva li riconcilierà. La documentazione sui profili gestiti copre le regole di separazione se serve il dettaglio di policy anziché quello di routing.