Vérifier un VPN sans interface : un flux à la fois, avec des preuves
Une machine sans interface a besoin d’une requête dont vous pouvez lire la réponse. Testez chaque famille d’adresses, chaque contexte et chaque destination, puis notez ce que le résultat n’a pas couvert.
Sur une machine sans interface, il n’y a ni navigateur à ouvrir ni cadenas à regarder : la vérification doit donc être une requête dont vous pouvez lire la réponse. Cela semble trivial jusqu’à ce que vous remarquiez qu’un seul résultat d’adresse de sortie sert à certifier une machine qui fait tourner une douzaine de services, deux familles d’adresses et un proxy. Le parcours ci-dessous construit une preuve bornée à la fois, dans le contexte même où la charge de travail s’exécute réellement.
Décidez ce que le test doit prouver
Avant d’exécuter quoi que ce soit, écrivez l’attente sur une ligne : quel flux, par quelle interface, vers quelle destination, et ce qui devrait être observé à l’autre bout. Un test sans attente énoncée produit un nombre que personne ne peut interpréter.
La version la plus utile nomme un point de terminaison approuvé qui rapporte l’adresse source qu’il a vue.
Ce point de terminaison est la seule partie que vous devez organiser. Tout le reste est une observation côté client, et les observations côté client échouent de façons intéressantes.
Exécutez l’observation dans le bon contexte
Le shell d’un administrateur n’est pas l’environnement de la charge de travail. Il peut porter une autre variable de proxy, une autre table de routage dans un autre espace de noms, ou le fichier d’environnement d’un autre utilisateur. Exécutez le test dans le même contexte d’hôte, de conteneur, d’espace de noms ou de service que ce que vous vérifiez. Sinon, vous mesurez votre shell.
Sur un hôte normal, cela signifie le même utilisateur et la même unité. Dans un parc de conteneurs, cela signifie entrer dans l’espace de noms réseau du conteneur plutôt que de tester depuis l’hôte. Sur un service systemd, cela peut signifier une unité transitoire avec les mêmes réglages.
La requête qui suit n’a de sens qu’une fois que vous êtes dans le bon contexte.
Vérifiez les familles d’adresses séparément
Demandez chaque famille explicitement, car une requête IPv4 réussie n’exerce pas du tout un chemin IPv6. Les sélecteurs --ipv4 et --ipv6 forcent le choix, et la différence entre les deux résultats est elle-même une information.
curl --ipv4 https://probe.example/observed-source
curl --ipv6 https://probe.example/observed-sourceUne requête IPv6 échouée n’est pas la preuve d’un blocage efficace. Elle peut signifier que le point de terminaison n’a pas d’adresse IPv6, que le DNS n’a rien renvoyé d’utilisable, ou que la machine n’a aucun chemin IPv6. Lisez l’échec avant d’en tirer une conclusion. Une requête IPv6 réussie à travers le tunnel est le seul résultat qui prouve que le chemin IPv6 est couvert.
Notez les deux réponses côte à côte. L’une seule est la moitié d’un fait.
Ajoutez les quatre choses qu’une vérification de sortie manque
Une adresse de sortie répond à une question. Quatre autres décident si le tunnel se comporte comme prévu.
| Check | What it proves | What it does not |
|---|---|---|
| Included and excluded destinations | The split behaves as designed for those flows | Coverage of any other destination |
| Resolver path | Where a fresh lookup actually travelled | Where a cached answer came from |
| Tunnel-down behaviour | The failure policy for a new request | What an already open connection does |
| Reconnect and restart | The requirement survives the lifecycle event | Behaviour under load or partial failure |
La politique de destination vient d’abord : testez un flux qui doit être inclus et un qui doit être exclu, quand la conception comporte une séparation. Puis le DNS, où vous inspectez le chemin réel du résolveur plutôt que la valeur configurée, car une réponse en cache ou un réglage imprimé ne dit rien sur l’endroit où est allée une nouvelle requête.
Le comportement en cas de panne exige un plan et un chemin de récupération préservé. Observez une nouvelle requête pendant que le tunnel est indisponible, et rappelez-vous qu’une ancienne connexion ouverte ne prouve rien sur la politique de panne. Le cycle de vie vient en dernier : répétez l’observation après une reconnexion ou un redémarrage du service si ces événements affectent l’exigence.
Consignez des preuves, pas un verdict
Pour chaque résultat, conservez le contexte du processus, la destination, la famille d’adresses, l’heure et la source observée. Cet ensemble est une preuve bornée sur les flux que vous avez exercés, et il est défendable précisément parce qu’il dit ce qu’il a couvert.
Ce n’est pas un audit des registres de l’opérateur VPN, ni un certificat pour chaque application future de la machine.
Écrivez les limites à côté du résultat. Un test qui énonce ce qu’il n’a pas couvert survit à la revue, alors que celui qui affirme que la machine est vérifiée non. Gardez le manuel de curl à côté des sélecteurs de famille utilisés, et gardez le tableau à quatre lignes avec les résultats.