Cos'è lo split tunneling — come funziona davvero il routing per app VPN

In breve: una VPN standard instrada il 100% del traffico del dispositivo attraverso il tunnel cifrato. Lo split tunneling rompe questa regola di proposito. Scegli quali app o destinazioni bypassano il tunnel e usano direttamente la connessione normale. Sembra semplice, e concettualmente lo è — ma l'implementazione pratica differisce significativamente tra i sistemi operativi, e i compromessi sulla privacy sono facili da non notare. Un'app di streaming instradata fuori dal tunnel vede ancora il tuo IP reale. Un'app bancaria instradata fuori dal tunnel comunica ancora con la tua banca tramite la tua rete domestica — il che va bene, finché la stessa app non effettua anche una query DNS che trapela attraverso il bypass ed espone un dominio diverso che non intendevi rivelare.

Cosa fa effettivamente il tunneling VPN (la situazione di base)

Prima di capire cosa viene diviso, devi avere chiari gli effetti del tunnel completo. Un client VPN in esecuzione sul tuo dispositivo crea un'interfaccia di rete virtuale — su Linux si chiama tipicamente tun0 o wg0, su macOS si chiama utun, su iOS e Android il sistema operativo la gestisce tramite un'API di estensione per app. La tabella di routing del sistema operativo viene quindi modificata in modo che la route predefinita — la regola che dice "invia i pacchetti senza altra route corrispondente a questo gateway" — punti a quell'interfaccia virtuale invece che alla tua interfaccia Wi-Fi o cellulare fisica.

Da quel momento in poi, ogni pacchetto generato dal tuo dispositivo viene cifrato dal client VPN, avvolto in un nuovo header IP che punta al server VPN, e inviato tramite l'interfaccia fisica come un singolo flusso omogeneo. Il server VPN decifra il pacchetto, lo inoltrano alla sua destinazione reale su internet pubblico, riceve la risposta, la cifra di nuovo e la rispedisce. Il tuo ISP vede solo il flusso cifrato diretto a un singolo IP. I siti di destinazione vedono l'IP del server VPN, non il tuo.

Questo è il comportamento predefinito. Lo split tunneling interviene in questo modello aggiungendo route più specifiche alla tabella di routing — regole che dicono "per il traffico diretto a questa destinazione" o "per il traffico generato da questa app, ignora la route del tunnel predefinita e usa direttamente l'interfaccia fisica".

Cosa cambia lo split tunneling

Concettualmente, lo split tunneling introduce una biforcazione nel flusso di rete. Alcuni pacchetti passano attraverso il tunnel cifrato; altri escono dall'interfaccia diretta. La decisione viene presa dal client VPN in base alle regole che configuri. Esistono tre categorie comuni di regole di split:

• Basata sulle app — "Invia tutto il traffico di Netflix fuori dal tunnel; tutto il resto vai nel tunnel." Implementato taggando i pacchetti con l'UID o il PID del processo originario, quindi prendendo decisioni di routing per tag.
• Basata sulla destinazione — "Invia il traffico verso 10.0.0.0/8 fuori dal tunnel così posso raggiungere il mio NAS di casa; tutto il resto nel tunnel." Implementato puramente con voci nella tabella di routing — la forma più semplice.
• Basata su URL o dominio — "Invia il traffico verso *.bank.com fuori dal tunnel." Questo è fragile perché il layer di routing del sistema operativo non conosce nativamente i domini; richiede che il client VPN intercetti il DNS e riscriva le risposte, oppure mantenga una lista dinamica di IP consentiti che segua le risoluzioni DNS. I vendor la implementano in modo incoerente.

Ecco la visione architetturale, semplificata:

Tunnel completo (senza split):
  [App A] -> [App B] -> [App C]
        \        |        /
         [Interfaccia VPN virtuale]
                 |
         [Tunnel cifrato]
                 |
         [Server VPN] -> internet

Split tunnel (basato su app, App C esclusa):
  [App A] -> [App B]        [App C]
        \        /               \
   [Interfaccia VPN virtuale]   [Wi-Fi fisico]
              |                    |
       [Tunnel cifrato]    [Internet diretto]
              |                    |
        [Server VPN]         diretto alla dest

Lo "split" è il punto di divergenza all'interno del sistema operativo — la scelta tra l'interfaccia virtuale e quella fisica avviene prima della cifratura, quindi un pacchetto che bypassa il tunnel non è mai stato cifrato. Non c'è alcun passaggio di decifratura; lascia semplicemente il dispositivo così com'è.

Split tunneling inverso — lista di esclusione vs lista di inclusione

Le configurazioni di split tunneling si presentano in due varianti che sembrano simmetriche ma hanno comportamenti di fallimento predefinito molto diversi:

• Modalità blocklist (il default più comune) — "Usa il tunnel per tutto tranne le app/destinazioni in questa lista." Il default è protetto; solo eccezioni specifiche vengono esposte. Se dimentichi di aggiungere un'app alla lista, rimane protetta.
• Modalità allowlist (chiamata anche split tunneling inverso) — "Usa il tunnel solo per le app/destinazioni in questa lista; tutto il resto va diretto." Il default non è protetto; solo app specifiche vengono tunneizzate. Se dimentichi di aggiungere un'app alla lista, il suo traffico trapela.

La modalità allowlist è la scelta giusta per "voglio che solo il mio browser usi la VPN, tutto il resto può usare la mia connessione normale." La modalità blocklist è la scelta giusta per "voglio che la maggior parte delle cose sia protetta, ma alcune app specifiche hanno bisogno della rete reale." La maggior parte dei consumatori vuole la modalità blocklist. I team Operations e DevOps a volte preferiscono la modalità allowlist perché cercano di esporre servizi specifici attraverso il tunnel senza disturbare il resto del sistema.

Il fallimento della modalità allowlist è grave: se aggiungi una nuova app e dimentichi di aggiungerla alla allowlist, il traffico di quell'app trapela. Il fallimento della modalità blocklist è più lieve: le app dimenticate restano protette — hai solo problemi di compatibilità fastidiosi quando un'app di streaming o bancaria fallisce perché vede l'IP della VPN.

Quando usare lo split tunneling — cinque scenari concreti

Lo split tunneling ha usi legittimi reali. Queste sono le situazioni in cui è lo strumento giusto:

1. Servizi di streaming che rilevano e bloccano gli endpoint VPN

Netflix, Disney+, Hulu e la maggior parte delle emittenti regionali mantengono ampie liste di IP noti di datacenter VPN e si rifiutano di trasmettere quando ne rilevano uno. Puoi disattivare la VPN (perdendo tutta la protezione) oppure fare lo split-tunnel dell'app di streaming in modo che veda il tuo IP reale mentre tutto il resto rimane protetto.

2. App bancarie e finanziarie con rilevamento delle frodi basato sulla posizione

Le banche trattano spesso un improvviso cambio di IP verso un datacenter VPN come un segnale di frode — attivano l'autenticazione a più passaggi, trattengono le transazioni o bloccano temporaneamente il conto. Dividere l'app della banca dal tunnel mantiene il tuo rapporto IP-reale con la banca costante. Si tratta di una soluzione di usabilità, non di un miglioramento della sicurezza — la connessione della banca è già cifrata con TLS, quindi la VPN non aggiungeva molta sicurezza a quella sessione specifica.

3. Risorse di rete locale (NAS, stampante, smart home)

Quando la VPN cattura tutto il traffico, il dispositivo non riesce più a raggiungere la stampante all'indirizzo 192.168.1.50 perché quell'IP non è raggiungibile attraverso il tunnel VPN. Lo split tunneling basato sulla destinazione (escludendo 192.168.0.0/16 e 10.0.0.0/8) ripristina l'accesso locale senza disabilitare la VPN per internet pubblico. Molti client VPN lo fanno automaticamente come impostazione predefinita; altri no.

4. Applicazioni sensibili alla latenza

Il gioco online competitivo, le videoconferenze in diretta e le chiamate vocali subiscono le conseguenze della latenza aggiuntiva introdotta dall'instradamento attraverso un server VPN in una regione distante. Dividere quelle app specifiche può recuperare la latenza mantenendo tutto il resto cifrato. Il compromesso: quelle app sono ora identificabili dal tuo ISP e visibili agli osservatori di rete.

5. VPN di lavoro affiancate a VPN personali

Se il tuo datore di lavoro richiede una VPN aziendale per accedere alle risorse interne, e vuoi il traffico personale attraverso una VPN diversa (orientata alla privacy), lo split tunneling sulla VPN aziendale — inviando solo gli intervalli IP aziendali attraverso di essa — lascia il resto del traffico disponibile per la VPN personale. È una configurazione per utenti avanzati ma è un modo pulito per tenere separati il traffico lavorativo e quello personale.

Quando NON usare lo split tunneling — le insidie sulla privacy

Lo split tunneling rende il comportamento di rete più complesso, e il comportamento di rete complesso trapela in modi non ovvi. I fallimenti più comuni:

Perdite DNS attraverso il percorso di bypass

Anche quando il traffico TCP di un'app viene instradato fuori dal tunnel, le sue query DNS potrebbero comunque essere configurate per usare il resolver DNS della VPN — o peggio, potrebbero tornare al resolver DNS dell'ISP se il client VPN non gestisce attentamente il DNS di sistema. Il risultato: un'app che dovrebbe essere invisibile al tuo ISP diventa parzialmente visibile. L'ISP vede la query DNS per banking.example.com anche se la successiva connessione TCP ha seguito un altro percorso. Abbiamo un approfondimento su come la cifratura DNS si inserisce in questo nella nostra guida al DNS-over-HTTPS.

Confusione app-dominio

Lo split tunneling basato sulle app instrada per identità del processo, ma le app moderne si connettono a molti domini. La tua "app di streaming" probabilmente carica annunci, telemetria, API di raccomandazione e endpoint di analytics da dozzine di domini diversi — alcuni dei quali sono condivisi con app che vuoi invece tunneizzare. Escludere l'intera app significa escludere tutte quelle connessioni. Lo split tunneling basato sul dominio ha il problema opposto: una singola app potrebbe caricare lo stesso dominio CDN sia per il video in streaming (che vuoi non protetto) sia per contenuti che preferiresti non rivelare.

Perdite IPv6

Molte implementazioni di split-tunnel sono state progettate quando IPv4 era l'unica preoccupazione di routing. Se la tua rete ha connettività IPv6 e le regole di split-tunnel non includono esplicitamente le route IPv6, i pacchetti che dovrebbero essere tunneizzati potrebbero uscire via IPv6 fuori dal tunnel. Questa è una delle perdite VPN più comuni nel 2026 ed è quasi sempre causata da una configurazione incompleta delle regole di split-tunnel. Testa la perdita con un test di perdita IPv6 dopo aver abilitato lo split tunneling.

Interazioni con il kill switch

Un kill switch è progettato per bloccare tutto il traffico se la VPN cade, in modo che nulla trapeli non protetto. Con lo split tunneling abilitato, la logica del kill switch diventa più difficile — il kill switch dovrebbe comunque consentire alle app con split-tunnel di comunicare, ma solo quelle, e solo quando la VPN stessa è anche inattiva. Molti client VPN hanno bug in cui il kill switch non riesce a bloccare le app tunneizzate quando la VPN cade, o blocca erroneamente le app con split-tunnel che dovrebbero continuare a funzionare. Testa la combinazione esplicitamente.

Confronto tra le modalità di split tunneling

Come funziona lo split tunneling su ogni sistema operativo

iOS — limitato e indiretto

iOS non espone una vera API di split tunneling alle app VPN di terze parti. Il framework NetworkExtension consente di configurare una VPN come di sistema (tutto il traffico) o per singola app (solo le app esplicitamente registrate tramite un profilo MDM). Il vero routing split per app richiede NEAppProxyProvider di Apple con un profilo di configurazione distribuito tramite MDM — il che significa uno scenario di dispositivo gestito. Le app VPN consumer su iOS che pubblicizzano lo "split tunneling" tipicamente implementano esclusioni basate sulla destinazione (ad esempio escludendo specifici intervalli IP dal tunnel) o utilizzano l'API delle regole on-demand per attivare condizionalmente la VPN in base all'SSID Wi-Fi o alla corrispondenza del dominio. Lo split tunneling basato sulle app per gli utenti iOS consumer non è davvero disponibile.

Android — supporto nativo

L'API VpnService di Android supporta il routing per app in modo nativo. Il client VPN può chiamare addAllowedApplication() o addDisallowedApplication() per specificare quali app passano attraverso il tunnel. Il sistema operativo gestisce il routing per app in modo trasparente — il client VPN non ha bisogno di fare il tagging a livello di pacchetto. Android supporta anche l'impostazione di sistema "VPN sempre attiva" con l'opzione "Blocca connessioni senza VPN", che combina il comportamento del kill switch con la configurazione per app: le app tunneizzate passano attraverso, le non tunneizzate vanno diretto, e se la VPN cade, le app tunneizzate vengono bloccate.

macOS — implementazione variabile

macOS supporta lo split tunneling attraverso diversi meccanismi: il framework NetworkExtension (simile a iOS, con maggiore flessibilità), i filtri di pacchetti configurati tramite regole pf, o la manipolazione della tabella di routing da parte di client VPN con privilegi elevati. Lo split tunneling basato sulle app su macOS è praticabile ma richiede che il client VPN interroghi il kernel per le mappature socket-processo. Lo split basato sulla destinazione è semplice e affidabile.

Windows — la piattaforma più comune per lo split tunneling

I client VPN Windows utilizzano lo split tunneling da oltre un decennio. La Windows Filtering Platform (WFP) fornisce l'ispezione dei pacchetti a livello kernel e l'API per le decisioni di routing su cui i client VPN si agganicano. Lo split tunneling per app su Windows è ben supportato e ampiamente distribuito. La maggior parte delle implementazioni VPN aziendali usa lo split tunneling di Windows per garantire che il traffico aziendale passi attraverso il tunnel aziendale mentre il traffico internet generale va diretto — in parte per le prestazioni, in parte per ridurre il carico sui concentratori VPN aziendali.

Errori comuni nella configurazione dello split tunneling

Osservare come le persone configurano erroneamente lo split tunneling rivela alcuni pattern ricorrenti. Se lo imposti, controlla la tua configurazione rispetto a questa lista:

• Non testare le perdite DNS dopo averlo abilitato. Esegui un test di perdita (dnsleaktest.com o simile) dopo ogni modifica alla configurazione. Se vedi il resolver DNS del tuo ISP elencato per un'app che dovrebbe essere tunneizzata, il bypass sta perdendo DNS.
• Dimenticare che i browser sono speciali. Un browser che esegue un'app di streaming web instrada sia il video in streaming che le altre schede attraverso lo stesso processo. Escludere il browser esclude tutta la navigazione. Usa un profilo browser separato o un'app diversa per il caso dello streaming.
• Non gestire IPv6. Disabilita completamente IPv6 se il tuo client VPN non lo gestisce esplicitamente. Il tasso di perdita dalle regole di split-tunnel IPv6 dimenticate è alto.
• Usare regole basate sul dominio per decisioni critiche per la sicurezza. Lo split tunneling basato sul dominio va bene per modifiche di usabilità. Non è abbastanza affidabile per imporre "questa app sensibile deve sempre passare attraverso la VPN" — per questo, usa regole basate sulle app con l'app esplicitamente tunneizzata, idealmente in modalità allowlist.
• Non rivedere le regole periodicamente. Le app vengono aggiunte e rimosse; le nuove app dello stesso sviluppatore non ereditano nulla da quelle vecchie. Controlla periodicamente il tuo set di regole di split-tunnel.

Il verdetto onesto sullo split tunneling

Lo split tunneling è genuinamente utile per problemi specifici — app di streaming che rilevano le VPN, app bancarie che segnalano i login VPN, accesso alla rete locale — e ha una lunga storia di utilizzo legittimo in ambienti aziendali. Per i consumatori, il quadro onesto è che è uno strumento di usabilità prima e uno strumento di privacy secondo. Ogni regola di split-tunnel indebolisce il modello di protezione in un modo specifico, e il compromesso sulla sicurezza vale solo quando la protezione non avrebbe comunque aiutato quel traffico (ad esempio, una sessione bancaria già cifrata con TLS e diretta a un'unica destinazione nota).

Se il tuo modello di minaccia è "voglio una VPN sulle reti Wi-Fi pubbliche ostili in modo che l'operatore della rete locale non possa osservare il mio traffico", un tunnel completo è la risposta giusta. Non abilitare lo split tunneling solo perché il client VPN lo offre — ogni esclusione è un buco. Se il tuo modello di minaccia è "voglio la maggior parte del traffico protetto ma alcune app specifiche hanno bisogno della rete reale", lo split tunneling è lo strumento giusto, ma configuralo con attenzione, testa le perdite DNS e IPv6 successivamente, e rivedi le regole periodicamente. Il riferimento tecnico nella documentazione quickstart di WireGuard mostra come funzionano le decisioni di routing sottostanti a livello di protocollo.

Casper's Cloak usa un'architettura a tunnel completo per impostazione predefinita perché il modello di minaccia che stiamo proteggendo — reti ostili, sorveglianza ISP, tracciamento ad-tech — trae vantaggio dal modello più semplice "tunnelizza tutto". Abbiniamo questo al filtraggio dei tracker a livello DNS e al rilevamento AI delle minacce per le destinazioni note come malevole, quindi il tunnel completo sta anche eseguendo un filtraggio attivo — non solo routing. Per i casi limite di streaming e banche, la mossa giusta di solito è disconnettersi brevemente piuttosto che mantenere un insieme permanente di esclusioni di split-tunnel che finirai per dimenticare.