Come il tunnel diviso decide quale traffico usa la VPN

Il tunnel diviso è una politica di instradamento espressa come un insieme di regole, e il client è solo ciò che le installa. La separazione avviene in due punti: regole di corrispondenza che scelgono un percorso per ogni pacchetto, e associazioni che tengono un'applicazione su un'interfaccia qualunque cosa dica la tabella. Su quale meccanismo si basa il vostro client spiega la maggior parte delle sorprese che le persone segnalano.

Una politica che potete enunciare in una riga è verificabile. Una politica descritta come navigazione più veloce non lo è, e non vi dirà quale regola cambiare quando una richiesta prende la direzione sbagliata.

Il client installa le regole, il kernel fa la scelta

Quando il tunnel sale, il client aggiunge rotte e spesso regole di politica alla stessa tabella che usano le altre vostre interfacce. Ogni pacchetto raggiunge poi una ricerca che confronta la sua destinazione con ogni prefisso candidato e conserva la corrispondenza più specifica, mentre la priorità risolve i pareggi tra regole che puntano a tabelle diverse. Nulla in quella ricerca sa che il pacchetto è arrivato da una scheda del browser e non da un processo di backup. La regola che vince è quella che imposta il percorso, e potete leggerla prima e dopo la modifica.

Per questo un tunnel diviso può sembrare arbitrario. Due destinazioni nella stessa applicazione possono prendere percorsi diversi solo perché un prefisso è più stretto dell'altro.

La stessa scelta esiste su ogni piattaforma, anche se i nomi cambiano. Windows spinge la decisione nella sua piattaforma di filtri, Android espone un elenco di autorizzati per applicazione tramite il suo servizio VPN, e macOS collega il tunnel a un dispositivo che obbedisce ancora alla tabella di instradamento. Le note di instradamento di Microsoft meritano una lettura per il caso Windows, e una guida scritta per una piattaforma raramente si trasferisce senza modifiche a un'altra.

L'associazione per applicazione e i prefissi di destinazione sono strumenti diversi

Una politica di destinazione chiede dove va il pacchetto e consulta la tabella delle rotte o una regola di politica. Una politica per applicazione chiede quale programma ha aperto il socket, e la piattaforma tiene quel programma sull'interfaccia del tunnel anche quando una rotta più specifica punta altrove. La seconda è più forte perché sopravvive ai cambi di tabella, ma copre solo i processi che la piattaforma può attribuire. Un processo ausiliario, un browser incorporato o un servizio che apre la propria connessione può non ereditare l'associazione che avete supposto.

Nessuno dei due approcci sopravvive a una politica basata sui nomi senza aiuto. Gli indirizzi dei siti grandi ruotano tra reti di contenuti, quindi fissare un nome host a pochi prefissi produce una regola che smette silenziosamente di corrispondere. Una politica che deve seguire i nomi ha bisogno di un componente consapevole del resolver invece di una rotta statica.

Il DNS e l'interruttore di sicurezza seguono le proprie regole

La risoluzione dei nomi è una decisione separata dall'instradamento dei pacchetti, e un tunnel diviso di solito vuole due resolver: quello aziendale per i nomi interni, quello locale per tutto il resto. Il client può installare impostazioni DNS per interfaccia, consegnare le query a un resolver intermedio o lasciare invariato il valore predefinito del sistema. Un browser con il proprio resolver cifrato aggira tutte e tre le disposizioni. Provate una ricerca invece di presumere che il resolver abbia seguito la rotta.

Un interruttore di sicurezza aggiunge un filtro sopra, e quel filtro non sempre distingue un'esclusione voluta da una fuga accidentale. Alcuni client bloccano tutto fuori dal tunnel mentre altri consentono le esclusioni dichiarate dalla politica, quindi leggete quale comportamento implementa il vostro prima di affidarvi all'uno o all'altro.

Controllate la separazione da entrambi i lati

Provate il percorso incluso e il percorso escluso separatamente, e giudicate il risultato dal nome dell'interfaccia invece che da un indirizzo pubblico. Questi comandi presuppongono un host Linux con il dispositivo del tunnel già attivo. Sostituite 203.0.113.10 con una destinazione che la vostra politica instrada verso l'interno, e 198.51.100.25 con una che manda verso l'esterno.

ip route get 203.0.113.10
ip route get 198.51.100.25
resolvectl query intranet.example.com
curl -s --interface tun0 https://example.com -o /dev/null -w '%{http_code}\n'

Leggete insieme le prime due risposte, perché l'interfaccia nominata in ciascuna mostra se la separazione ha messo quella destinazione sul tunnel. La query al resolver mostra quale server ha risposto al nome interno, e l'ultimo comando dimostra che il dispositivo del tunnel può trasportare una richiesta. Un errore sulla seconda riga mentre la prima riesce significa che la politica fa esattamente ciò che le è stato detto.

Ripetete l'insieme dopo una riconnessione e dopo un cambio di rete. Il rinnovo del lease e il movimento delle interfacce sono i punti in cui una separazione smette di corrispondere all'intento per cui è stata costruita, e un output salvato di ogni esecuzione rende evidente la deriva.