Due app VPN insieme: quale kill switch si applica davvero?
Un secondo client VPN non eredita mai il kill switch del primo. Tre condizioni decidono quale criterio si applica e come verificare il vostro.
Due client VPN possono funzionare affiancati, ma i loro kill switch non si fondono in un’unica policy. Ogni client installa regole per il proprio tunnel e nessuno dei due sa che l’altro esiste. Mi è capitato con un client aziendale connesso per primo: la seconda app non riusciva a completare l’handshake, è rimasta su «Connecting» per dieci minuti e il primo tunnel ha portato tutto in silenzio. Se la seconda app venga protetta dipende da tre condizioni, non dal fatto che entrambe le icone dicano Connesso.
A cosa è realmente circoscritto un kill switch
Niente nel sistema operativo ha un singolo flag di kill switch. Un client che ne pubblicizza uno installa un insieme di regole: scarta tutto ciò che non esce dal mio tunnel e spesso applica fail closed quando il tunnel scompare. Su Linux di solito è una catena nftables o iptables, su Windows un insieme di filtri Windows Filtering Platform, su Android e iOS il routing proprio del servizio tunnel più l’impostazione di sistema che blocca le connessioni senza VPN. La guida VPN di Android descrive quel modello di servizio se volete il punto di vista della piattaforma.
L’ambito è la parte che conta. Una regola del tipo «consenti solo i pacchetti sull’interfaccia di uscita wg0» non si cura che esista un secondo tunnel. Se un altro client attiva wg1, le regole del primo client trattano quei pacchetti come traffico ordinario: di solito scartati, talvolta consentiti. In ogni caso decide il primo client, e non ha idea che una seconda app stia aspettando.
Tre condizioni che decidono chi viene coperto
Non serve enumerare ogni combinazione. Tre domande lo chiariscono in pochi minuti.
- La piattaforma consente almeno un secondo tunnel? La maggior parte dei telefoni Android e degli iPhone accetta un solo servizio VPN attivo per profilo utente, quindi la seconda app non tiene mai un tunnel e non impone mai nulla. Si ottiene una sola policy, quella dell’app che ha vinto lo slot.
- Quale processo possiede la rotta predefinita? Windows, macOS e Linux portano volentieri due tunnel. La rotta predefinita appartiene al client che l’ha configurata per ultimo o con la metrica migliore, e l’altro client è connesso ma inattivo. Su Linux la modalità rotta predefinita di wg-quick usa il policy routing con una tabella privata e una regola fwmark, così un secondo tunnel wg-quick aggiunge una regola concorrente invece di sostituire la prima.
- Il secondo client riesce a raggiungere il proprio server? Se il primo kill switch è in deny by default, l’endpoint esterno della seconda app è solo un’altra destinazione scartata. Riprova in silenzio e non segnala mai un errore.
La versione breve, per i thread di supporto:
| Setup | What you actually get |
|---|---|
| Second client cannot hold a tunnel | One active policy; the other app only reports that it is waiting |
| Both tunnels up, second took the default route | The first kill switch blocks traffic it never meant to touch; the connection dies, or leaks if its rules are broad |
| First kill switch allows only its own endpoint and interface | Second client never connects; first tunnel unaffected |
| Both up, DNS written by whichever client ran last | Name resolution breaks for one side when either tunnel drops |
Due di quelle righe sembrano identiche dall’icona nella tray, ed è per questo che l’icona è la prova peggiore disponibile qui.
Cosa fallisce per primo, e come si presenta
Un client bloccato su Connecting mentre l’altro è sano è quasi sempre fame di endpoint: il kill switch attivo scarta l’handshake del secondo client verso il proprio server. Confermatelo a poco prezzo mettendo in pausa le regole di blocco del primo client per un tentativo. Se il secondo si connette subito, la domanda è risolta.
Il DNS è il secondo guasto. I client impostano la configurazione del resolver per la propria interfaccia, e alcuni sovrascrivono del tutto l’elenco globale. Con entrambi i tunnel attivi, le query possono uscire da un lato mentre il resolver appartiene all’altro. Disconnettete una delle due app e la superstite mantiene un nameserver irraggiungibile: le pagine si bloccano per un minuto e poi risolvono di nuovo, mentre la VPN continua a mostrarsi connessa.
Il terzo è il flapping delle rotte. Le riconnessioni riordinano la rotta predefinita, e un kill switch legato a un’interfaccia non la segue. Il traffico che un attimo fa era nel tunnel ora corrisponde a una regola di scarto, il che dal lato utente si legge come una VPN che smette di funzionare a caso.
Verificare quale policy è davvero in vigore
Fatelo con traffico innocuo, non con qualcosa che vi mancherebbe.
Su Linux chiedete al kernel chi vince e a cosa si lega il firewall. ip -4 route show default indica il tunnel che possiede l’uscita. ip rule show mostra se è in gioco il policy routing. sudo nft list ruleset | grep -n oifname mostra se gli scarti sono legati a un nome di interfaccia, a un mark o all’intera catena di output.
Su Windows la stessa storia sta nella metrica di rotta e nell’elenco dei filtri: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric e Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". Su macOS, netstat -rn -f inet | head -5 e scutil --dns | head -20.
Poi fate il passo che la gente salta: fermate il tunnel di proposito e confermate che il traffico che vi aspettate fallisca fallisca davvero. Un’icona connessa è uno stato dell’interfaccia, non un’applicazione della regola.
Quando due client sono il progetto sbagliato
Se l’unico requisito dietro la seconda app è più protezione, rimuovetela. Due policy di blocco che interagiscono sono meno prevedibili di una, e ogni riconnessione è un’occasione di finire in uno stato che nessun fornitore testa.
Se avete davvero bisogno di concatenamento, per esempio un gateway aziendale raggiunto tramite un hop commerciale, scegliete un progetto con un unico punto di applicazione. Di solito significa un router o un singolo client che supporta la catena, non due app desktop che si contendono la stessa rotta predefinita. Su un dispositivo gestito tenete il client autorizzato e considerate tutto il resto fuori ambito, qualunque cosa mostri nella tray.
Checklist prima di tenerli entrambi
Percorrete questa lista in ordine; il primo punto che fallisce è quello da correggere.
- Confermate che esattamente un client possiede la rotta predefinita e il resolver.
- Se volete il secondo client attivo, consentite esplicitamente l’endpoint del suo server e ricontrollate dopo ogni aggiornamento del client.
- Annotate l’esito atteso quando uno dei due tunnel cade, poi provate proprio quel caso.
- Controllate il percorso di guasto dopo un riavvio, quando l’ordine di avvio è diverso.
- Su un profilo gestito fermatevi e chiedete al proprietario prima di aggiungere qualcosa.
Se il terzo passo fallisce, la risposta onesta è che solo un client vi sta dando una policy. Decidete di quale vi fidate e lasciate andare l’altro.