Split tunneling basato sull'app o sulla destinazione: quale scegliere

Lo split tunneling basato sull'app e quello basato sulla destinazione non sono due impostazioni per lo stesso compito. Uno chiede quale processo sta inviando un pacchetto; l'altro chiede dove sta andando quel pacchetto. Una regola costruita per la prima domanda fallisce in silenzio quando il traffico arriva da un processo ausiliario, e una regola costruita per la seconda fallisce quando un nome host si risolve in un indirizzo che non avete mai elencato. Scegliete l'oggetto che corrisponde al requisito, poi dimostratelo con due pacchetti di prova: uno che deve usare il tunnel e uno che non deve.

Le due regole agiscono a livelli diversi

Una regola per app viene applicata sopra il livello di rete, contro l'identità che il sistema operativo assegna al mittente. Su Android è l'UID dietro un pacchetto, e il servizio VPN decide per UID se il traffico entra nel tunnel. Non viene chiesto nulla sulla destinazione, quindi l'app scelta può raggiungere qualsiasi cosa e nessun'altra app può raggiungere la rete interna.

Una regola per destinazione viene applicata sul pacchetto stesso. L'interfaccia del tunnel possiede un insieme di prefissi, la tabella di routing vi invia il traffico corrispondente e il processo mittente è irrilevante. Per questo una regola per destinazione copre un servizio, una stampante o un processo batch che nessuno si è ricordato di elencare, e per questo non può essere espressa come proprio questo programma su una piattaforma il cui client non guarda mai il processo.

Le regole per app si adattano ai client mobili e agli agenti gestiti

Android espone la scelta direttamente: VpnService.Builder.addAllowedApplication() e addDisallowedApplication() accettano nomi di pacchetto e applicano la decisione per UID, come descritto nella guida per sviluppatori VPN di Android. iOS ha un equivalente tramite regole VPN per app basate sugli identificatori di bundle, di solito distribuite da un profilo MDM anziché digitate a mano.

I client desktop sono il punto debole. La maggior parte dei client VPN per Windows e macOS instrada per destinazione e non offre alcun selettore per processo, perché il driver del tunnel vede pacchetti, non processi. Se il vostro piano dipende dal tunnel per una sola applicazione su un portatile, verificate le capacità reali del client prima di progettare attorno a questo; forse state scegliendo tra un elenco di destinazioni e una seconda macchina.

Un corollario che molti trascurano: non potete imitare una regola per app con le rotte su quelle piattaforme. Aggiungere una rotta host per il server dell'app incanala il traffico di tutti verso quel server, compresi il browser e l'aggiornatore.

Le regole per destinazione si adattano agli elenchi di sottoreti e alla raggiungibilità dei siti

WireGuard rende esplicito il modello. AllowedIPs è routing a chiave crittografica: un pacchetto interno la cui destinazione cade nell'elenco di un peer viene cifrato verso quel peer, e tutto il resto esce in chiaro lungo il percorso normale. Non c'è alcun processo da nominare e nessuna ambiguità su ciò che è incluso.

OpenVPN arriva allo stesso punto tramite la tabella di routing inviata. route-nopull impedisce al server di dettare le rotte, dopodiché una route 10.20.0.0 255.255.0.0 vpn_gateway lato client copre esattamente il prefisso dell'ufficio. IPv6 è un'istruzione separata in ciascuno di questi client, e dimenticarla è il modo più comune per perdere traffico attorno a uno split IPv4 che sembra corretto.

Un nome host non è una rotta. Se il profilo offre un campo dominio, trattatelo come un nome che il client risolve una volta, non come un intervallo di indirizzi permanente; le reti di distribuzione dei contenuti e i bilanciatori di carico domani forniranno indirizzi diversi.

Dove cedono entrambi i modelli: ausiliari, servizi condivisi, resolver

I processi ausiliari rompono le regole per app in un modo che sembra un guasto del server. L'aggiornatore di un browser, un segnalatore di crash, un servizio di sincronizzazione eseguito come SYSTEM e una WebView incorporata in un altro pacchetto sono identità separate, quindi incanalare il browser può lasciare la richiesta reale fuori dal tunnel. Il contrario è altrettanto confuso: un'app esclusa che chiama una libreria condivisa dentro un processo incanalato vede comunque il proprio traffico passare nel tunnel.

Le regole per destinazione si rompono sui servizi condivisi e sui nomi. Le condivisioni file, le stampanti, il DNS interno e il server delle licenze vivono su indirizzi, quindi un tunnel per una sola app dà accesso al browser mentre l'unità mappata resta morta. Questa differenza di copertura non è un difetto di nessuno dei due modelli, ma è il motivo per cui un tunnel per una sola app produce così spesso che la VPN è attiva e la condivisione è sparita.

I resolver tagliano entrambi. Se il client imposta server DNS interni ma il sistema operativo usa DNS su HTTPS verso un resolver pubblico, la risposta arriva da fuori dal tunnel e la regola per destinazione potrebbe non corrispondere mai. Controllate quale resolver ha risposto davvero prima di concludere che la regola è sbagliata, e confermate lato client se ha installato il resolver del tunnel. Uno split che lascia il DNS fuori dal tunnel sembra perfetto nella tabella di routing e fallisce comunque su ogni nome interno.

Procedura: scegliere, applicare, verificare

Partite dal requisito, non dal menu. Se l'obiettivo è solo questa app può usare il tunnel, servono regole per app e una piattaforma che le supporti. Se l'obiettivo è queste reti sono raggiungibili attraverso il tunnel, servono prefissi. Se la risposta è entrambe, implementatele come due controlli separati e annotate quale possiede quale guasto.

Applicate la forma più stretta che riuscite a esprimere, poi verificate interrogando la tabella di routing invece dell'icona di stato del client:

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

Le prime due righe nominano l'interfaccia che userebbe una destinazione reale; wg show stampa l'elenco dei prefissi configurato; su Windows, Find-NetRoute risponde alla stessa domanda a cui risponderà lo stack quando il pacchetto viene inviato. Se l'interfaccia è il tunnel, la regola ha corrisposto.

Poi provate un secondo pacchetto che dovrebbe essere escluso, da un'altra applicazione, verso la stessa destinazione. Annotate nel ticket la versione del client, il tipo di regola, l'elenco dei prefissi o dei pacchetti e i due risultati osservati. È quella coppia di risultati a dire all'ingegnere successivo se la policy è configurata male o se il traffico non le è mai appartenuto.