Tunnel complet ou tunnel divisé : les quatre différences

Les étiquettes de tunnel décrivent où va le reste du trafic d'un ordinateur portable, pas à quelle vitesse il va. Avec un tunnel complet, les requêtes publiques traversent la passerelle VPN avant de sortir vers internet. Avec un tunnel divisé, les destinations privées utilisent le tunnel et tout le reste prend le chemin local. Les deux atteignent l'application interne, donc le test d'accessibilité que les gens font d'abord ne dit rien sur la politique déployée.

Testez plutôt la sortie : quelle adresse une page d'écho publique rapporte, et quel résolveur a répondu.

Mythe : le tunnel divisé n'est que l'option la plus rapide

Le tunnel divisé est souvent vendu comme une fonction de performance, et il peut l'être, mais c'est un effet secondaire et non la définition. La définition est une décision de routage sur les destinations qui entrent dans le tunnel. La différence de vitesse n'apparaît que lorsque le chemin direct est réellement meilleur que le détour par le bureau. Sur une liaison domestique encombrée et une passerelle peu chargée, le tunnel complet peut être le plus rapide des deux.

Le cadrage honnête porte donc sur la propriété et le contrôle du chemin, la performance étant quelque chose que l'on mesure ensuite. Une politique choisie pour la vitesse qui déplace silencieusement votre DNS et votre sortie publique a été choisie pour la mauvaise raison.

Ce qui change réellement : la sortie

Avec un tunnel complet, un site web public voit l'adresse de sortie du bureau et le filtrage du bureau voit la requête. Avec un tunnel divisé, le même site voit l'adresse domestique de l'utilisateur et le bureau ne voit rien. Ce sont des modèles de visibilité différents, et aucun n'est automatiquement plus sûr. La question utile est celui que l'organisation peut réellement exploiter.

Vérifiez-le directement au lieu de faire confiance à un badge Connecté. Un écho d'adresse publique montre la sortie, et un test de résolveur montre de qui le DNS a répondu.

Ce que la passerelle doit ensuite porter

Une passerelle qui porte des appels vidéo, des téléchargements et des applications privées a besoin d'une capacité pour une charge de travail très différente de celle qui ne porte que des requêtes internes. La connexion internet du site porte à la fois l'arrivée de l'utilisateur et la sortie publique qui suit, donc deux liens peuvent se saturer en même temps.

La sortie locale supprime cette charge et le détour, et elle ne garantit pas une meilleure expérience, car le chemin direct peut aussi être encombré. Comparez l'application réelle au lieu de traiter une étiquette de routage comme une mesure de performance.

Des exceptions existent sous un tunnel complet

Une route par défaut n'est pas un inventaire de chaque paquet. Des routes plus spécifiques, des autorisations de réseau local, des exclusions d'applications et des règles IPv6 distinctes déplacent toutes du trafic, ce qui explique qu'une politique décrite comme tunnel complet puisse encore fuir. La documentation de routage du système d'exploitation fait cette distinction pour les valeurs par défaut de tunnel forcé, et la liste d'exceptions du client est l'endroit où la fuite vit généralement. Vérifiez le comportement, pas l'intention.

IPv6 mérite un examen propre, car un tunnel qui ne porte que de l'IPv4 laisse toute une pile hors de la politique.

Le DNS est une politique distincte

Les noms internes ont besoin d'un résolveur qui les connaît, et ce résolveur peut n'être joignable que par le tunnel. Un navigateur doté de son propre DNS chiffré peut contourner entièrement le résolveur du système, ce qui produit une division où les noms internes échouent et les publics fonctionnent, ou l'inverse.

Décidez où les recherches doivent aller, puis faites s'accorder le client et le navigateur. Une navigation publique réussie ne teste jamais la résolution des noms internes, c'est donc la mauvaise preuve à citer quand un site intranet disparaît.

Écrivez la politique de panne, puis testez-la

Décidez ce qui se passe quand le tunnel tombe : tout bloquer, bloquer uniquement les ressources privées ou autoriser les connexions directes. La reconnexion automatique ne répond pas à cette question, et un interrupteur d'urgence qui ne couvre que l'interface du tunnel peut laisser les applications exclues parler librement. Testez une déconnexion réelle et un changement de réseau, puis lisez l'état du client, car la documentation décrit le comportement prévu et non celui installé.

Notez les routes privées, la sortie publique, les serveurs DNS, les exceptions locales et le comportement en cas de panne dans une courte note. C'est cette note qui rend la politique vérifiable par quelqu'un qui ne l'a pas écrite.