Vérifier qu'un tunnel partagé fonctionne : un seul résultat d'IP n'est pas un test

Une seule page de navigateur qui affiche une adresse IP ne prouve presque rien sur un tunnel partagé. Une adresse visible peut être la bonne pour la mauvaise raison, et un flux exclu n'est jamais exercé par elle. Notez le résultat attendu avant de tester : quelle application ou destination doit utiliser le tunnel, laquelle doit rester directe, et ce qui doit s'arrêter quand le tunnel échoue. Sans ce plan, tout chiffre plausible ressemble à un succès.

Le mythe : une requête d'adresse prouve la couverture

La vérification d'IP répond à une question : ce que le monde extérieur voit depuis une application à un instant donné. Elle ne dit rien d'un préfixe interne, d'un second profil de navigateur ou d'un nom qui devrait être résolu en privé. Elle ne dit rien non plus de la défaillance, et c'est la moitié d'une conception de tunnel partagé qui casse en production.

Une page d'adresse ne peut pas non plus montrer la route, le résolveur ou la politique de défaillance. Traitez-la comme une observation, pas comme un verdict.

Testez un flux inclus et un flux exclu

Envoyez une requête inoffensive depuis l'application qui doit être incluse, ou vers le préfixe que vous attendez voir passer par le tunnel, et consignez la source, la destination, la famille d'adresses et le chemin observé. Faites de même pour un flux qui doit rester direct. Le côté exclu est celui que les gens sautent, et c'est la seule preuve que la séparation est délibérée et non accidentelle. Un processus auxiliaire peut porter une identité de politique distincte, alors testez dans le processus qui possède la socket.

flow: Firefox to intranet.example:443, IPv4, source 10.8.0.6, tunneled
flow: Firefox to 1.1.1.1, IPv4, source 192.0.2.20, direct

C'est pourquoi un test exécuté dans la mauvaise application peut montrer l'inverse de ce que la conception prévoit. Notez les quatre champs pour les deux côtés avant de tirer une conclusion.

Ajoutez le DNS et le cas de défaillance

Interrogez le résolveur du système et le résolveur qu'utilise l'application, puis comparez ces réponses à l'adresse de sortie que le site rapporte. Les deux couches peuvent diverger par conception, et une seule requête du navigateur n'exerce pas la politique du système d'exploitation. Un shell rend la comparaison reproductible : Cassez le tunnel exprès, puis faites une requête que le navigateur n'a pas mise en cache ; une page servie depuis le cache ne vous dit rien de la direction prise par le repli. Consignez ce qui s'est réellement produit plutôt que ce que la conception prévoyait.

curl -s https://ifconfig.me
nslookup intranet.example

Un tunnel partagé qui échoue fermé et un autre qui échoue ouvert sont identiques jusqu'à ce que vous cassiez le tunnel exprès. Consignez le comportement que vous avez observé, pas celui que vous attendiez.

Répétez après le changement d'état

Répétez les mêmes observations après une reconnexion, un changement de réseau et une mise à jour applicative pertinente. Une exclusion stockée peut continuer de pointer vers un chemin ou une identité d'application qui n'existe plus, et la conception cesse discrètement de correspondre à sa documentation. Ces trois événements sont là où les tunnels partagés dérivent, et chacun est peu coûteux à retester. Un test qui ne tourne qu'une fois au déploiement décrit une configuration qui n'existe plus.

Si un résultat diffère, trouvez le propriétaire de la règle et l'étape de traitement avant de changer plusieurs réglages à la fois. Changer cinq choses et observer un résultat n'est pas un diagnostic, c'est une nouvelle configuration.

Ce que le résultat doit établir

Rattachez les observations à la politique et à la version du client que vous avez réellement testées. L'objectif est de montrer que ce déploiement correspond à la couverture qu'il revendique, pas que toute application future sera privée. C'est une affirmation plus étroite, et c'est celle que vous pouvez réellement étayer par des preuves. Écrivez l'affirmation, la version et les résultats à quatre champs dans le registre des changements.

Le prochain relecteur pourra alors dire si c'est la conception qui a changé ou le test. Un tunnel partagé est vérifié lorsque les deux côtés, la séparation du résolveur et le comportement en cas de défaillance correspondent à ce que vous avez noté au départ. Un seul résultat d'IP n'en vérifie aucun.