Tunnel completo o tunnel diviso: le quattro differenze

Le etichette del tunnel descrivono dove va il resto del traffico di un portatile, non quanto veloce va. Con un tunnel completo, le richieste pubbliche attraversano il gateway VPN prima di uscire verso internet. Con un tunnel diviso, le destinazioni private usano il tunnel e tutto il resto prende il percorso locale. Entrambi raggiungono l'applicazione interna, quindi il test di raggiungibilità che le persone fanno per primo non dice nulla su quale criterio sia distribuito.

Verificate invece l'uscita: quale indirizzo riporta una pagina di eco pubblica e quale resolver ha risposto.

Mito: il tunnel diviso è solo l'opzione più veloce

Il tunnel diviso viene spesso venduto come funzione di prestazioni, e può esserlo, ma è un effetto collaterale e non la definizione. La definizione è una decisione di instradamento su quali destinazioni entrano nel tunnel. La differenza di velocità appare solo quando il percorso diretto è davvero migliore del giro attraverso l'ufficio. Su un collegamento domestico congestionato e un gateway poco carico, il tunnel completo può essere il più veloce dei due.

Quindi l'inquadramento onesto riguarda la proprietà e il controllo del percorso, con le prestazioni come qualcosa che si misura dopo. Un criterio scelto per la velocità che sposta silenziosamente il vostro DNS e la vostra uscita pubblica è stato scelto per il motivo sbagliato.

Cosa cambia davvero: l'uscita

Con un tunnel completo, un sito web pubblico vede l'indirizzo di uscita dell'ufficio e il filtraggio dell'ufficio vede la richiesta. Con un tunnel diviso, lo stesso sito vede l'indirizzo domestico dell'utente e l'ufficio non vede nulla. Sono modelli di visibilità diversi e nessuno è automaticamente più sicuro. La domanda utile è quale l'organizzazione possa davvero gestire.

Verificatelo direttamente invece di fidarvi di un badge Connesso. Un'eco di indirizzo pubblico mostra l'uscita, e un test del resolver mostra di chi era il DNS che ha risposto.

Cosa deve poi portare il gateway

Un gateway che porta videochiamate, download e applicazioni private ha bisogno di capacità per un carico di lavoro molto diverso da quello che porta solo richieste interne. La connessione internet del sito porta sia l'arrivo dell'utente sia l'uscita pubblica successiva, quindi due collegamenti possono saturarsi contemporaneamente.

L'uscita locale rimuove quel carico e il giro, e non garantisce un'esperienza migliore, perché anche il percorso diretto può essere congestionato. Confrontate l'applicazione reale invece di trattare un'etichetta di instradamento come misura delle prestazioni.

Esistono eccezioni sotto un tunnel completo

Una rotta predefinita non è un inventario di ogni pacchetto. Rotte più specifiche, autorizzazioni di rete locale, esclusioni di applicazioni e regole IPv6 separate spostano tutte traffico, ed è per questo che un criterio descritto come tunnel completo può ancora perdere. La documentazione di instradamento del sistema operativo fa questa distinzione per le impostazioni predefinite di tunnel forzato, e l'elenco delle eccezioni del client è dove di solito vive la perdita. Verificate il comportamento, non l'intenzione.

IPv6 merita uno sguardo proprio, perché un tunnel che porta solo IPv4 lascia un intero stack fuori dal criterio.

Il DNS è un criterio separato

I nomi interni hanno bisogno di un resolver che li conosca, e quel resolver può essere raggiungibile solo attraverso il tunnel. Un browser con il proprio DNS cifrato può aggirare del tutto il resolver di sistema, il che produce una divisione in cui i nomi interni falliscono e quelli pubblici funzionano, o il contrario.

Decidete dove devono andare le ricerche, poi fate concordare il client e il browser. La navigazione pubblica riuscita non verifica mai la risoluzione dei nomi interni, quindi è la prova sbagliata da citare quando un sito intranet scompare.

Scrivete il criterio di guasto, poi provatelo

Decidete cosa succede quando il tunnel cade: bloccare tutto, bloccare solo le risorse private o consentire connessioni dirette. La riconnessione automatica non risponde a questa domanda, e un interruttore di emergenza che copre solo l'interfaccia del tunnel può lasciare le applicazioni escluse parlare liberamente. Provate una disconnessione reale e un cambio di rete, poi leggete lo stato del client, perché la documentazione descrive il comportamento previsto e non quello installato.

Annotate le rotte private, l'uscita pubblica, i server DNS, le eccezioni locali e il comportamento in caso di guasto in una breve nota. È quella nota che rende il criterio verificabile da chi non l'ha scritto.