Tunnel divisé contre politique d’entreprise : quelle règle l’emporte

Cocher une application dans un client à tunnel divisé ressemble à une préférence locale, et sur un appareil géré, cela relève plutôt d’un changement de politique. L’exception détourne le trafic du chemin approuvé, qui peut être le même que celui qui transporte le DNS géré, le filtrage et l’adresse source qu’un service reconnaît. Le client ne se comporte pas mal lorsqu’il annule votre modification ; le déploiement fait son travail.

Avant de discuter de la case à cocher, déterminez quelle propriété la politique existe pour protéger.

La propriété derrière la règle

Certains déploiements routent tout afin que l’ensemble du trafic passe par une passerelle approuvée. D’autres tiennent à la résolution de noms et gardent les requêtes sur le résolveur d’entreprise plutôt que sur celui du réseau local. D’autres encore ont besoin d’une adresse source stable pour que les services internes puissent décider s’ils répondent.

Un quatrième groupe impose la posture du terminal : état du chiffrement du disque, niveau de correctifs, santé de l’agent. Le tunnel divisé n’y change rien, alors qu’un contournement qui évite le trafic de l’agent lui-même le peut.

Ce sont quatre exigences différentes, et chacune est brisée par une exception différente. Lisez l’exigence avant de proposer le changement, car celui qui l’a écrite saura vous dire aussitôt laquelle s’applique. Un changement qui satisfait la mauvaise n’achète rien.

Deux affirmations méritent d’être écartées tôt. Le tunnel complet ne donne pas aux administrateurs toutes les pages en clair, car le chiffrement des applications et les contrôles de terminaux décident de ce qui est visible. Le tunnel divisé n’est pas non plus universellement risqué, car le DNS géré, les politiques par application et les agents de terminaux peuvent tenir indépendamment de la route.

Exécutez les contrôles dans l’ordre

La séquence ci-dessous réduit une exception à la plus petite chose qui a réellement échoué. Arrêtez-vous au premier contrôle qui ne tient pas, car un correctif ultérieur ne compense pas une lacune antérieure.

Demandez quel trafic manque désormais la passerelle approuvée, puis confirmez que la résolution de noms atteint encore le résolveur d’entreprise. Vérifiez si l’application concernée respecte un commutateur d’urgence ou si elle a passé la tentative en échec sur une route directe. Regardez ensuite les services partagés : une visionneuse de documents ou un courtier de mises à jour peut porter l’exception plus loin que ne le suggère la case. Enfin, notez si la politique se réapplique à la reconnexion, car ce comportement décide si une modification locale survit.

Chaque réponse est un fait, et c’est de faits qu’une demande d’exception a besoin. Un débat sur le caractère agaçant du VPN n’en est pas un. Écrivez les réponses avant que la conversation ne commence.

Demandez une exception étroite

Indiquez l’application, la destination et l’opération qui a échoué, dans cet ordre. Une demande de garder un logiciel de mise à jour sur le chemin direct est examinable ; une demande de contourner le tunnel pour tout le navigateur ne l’est pas.

Décrivez ce que vous avez déjà essayé et ce que les journaux ont montré, et adressez-le à l’équipe qui possède le profil plutôt qu’à la personne qui répond au support. Sur un appareil géré, le propriétaire du profil peut généralement créer une exclusion prise en charge qui survit aux mises à jour, alors qu’une modification locale de route ne le peut pas.

Si la réponse est non, traitez-la comme une décision de conception et non comme un obstacle à contourner. La prochaine revue est l’endroit pour la rouvrir, avec l’opération en échec documentée et la raison commerciale jointe. La contourner risque plus que l’exception n’a jamais valu.

Rendez l’exception viable

Après un changement approuvé, confirmez les parties qui fonctionnaient avant, pas seulement celle qui était cassée. Les noms internes devraient encore se résoudre via le résolveur d’entreprise, les ressources privées répondre, et la tâche auparavant en échec aboutir désormais.

resolvectl query intranet.corp.example
curl -sS -o /dev/null -w '%{http_code}
' https://intranet.corp.example/status

La première commande prouve que le résolveur répond encore pour un suffixe interne, et la seconde qu’une requête atteint le service interne depuis la route actuelle. Réexécutez-les après une reconnexion, car une poussée de politique peut annuler en silence un changement qui semblait stable pendant le test. Deux lignes de sortie conservées avec le ticket bouclent la boucle. Sans elles, l’exception repose sur le souvenir de quelqu’un d’une page chargée une fois.

Consignez l’exception, son objet et les composants qu’elle couvre au même endroit que les notes de déploiement. Une exception non documentée devient l’incident du trimestre suivant, et une exception documentée devient la preuve que la conception supporte une charge de travail réelle.