Liste d’autorisation des points de terminaison VPN : la mise à jour DNS que vous avez oubliée

Saisir vpn.example.com dans une exception de pare-feu donne l’impression de s’abonner au DNS. Ce qui se passe généralement, c’est une traduction au chargement, après quoi la règle conserve des adresses et rien ne les actualise. Deux composants partagent désormais la tâche : le résolveur qui répond et le pare-feu qui stocke. La plupart des pannes de point de terminaison commencent là où ce passage n’a jamais été conçu.

Un nom d’hôte dans une règle n’est pas un abonnement en direct

Certains outils résolvent un nom au chargement de la configuration ; d’autres conservent un nom d’hôte et le résolvent à nouveau selon leur propre calendrier ; d’autres n’acceptent que des adresses. La configuration visible indique rarement laquelle. Les exemples de documentation supposent généralement le cas du chargement, ce qui explique pourquoi la différence surprend lors d’une migration. Lisez le comportement de l’implémentation avant de supposer qu’un changement d’adresse sera remarqué, car une liste d’autorisation obsolète ressemble exactement à une liste qui fonctionne jusqu’à ce que le point de terminaison bouge.

Une règle qui nomme le bon hôte peut encore autoriser la mauvaise adresse. Cet écart est le mythe, pas une faute de frappe.

Le TTL du cache n’est pas le minuteur de votre pare-feu

Les enregistrements DNS ont une durée de vie, et les résolveurs mettent les réponses en cache pendant cette période. La spécification DNS définit ce comportement de cache, mais elle régit les données DNS, non le magasin d’adresses séparé d’un pare-feu. Un TTL court ne crée pas une tâche d’actualisation là où il n’en existe pas. La mise en cache se produit aussi à plusieurs couches, donc la réponse qu’un terminal voit peut ne pas être celle que le pare-feu a vue.

Posez trois questions au produit réel : quand il résout, où il stocke le résultat et ce qui déclenche une mise à jour. Si la réponse n’intervient qu’au démarrage, une session longue peut survivre à l’adresse à laquelle elle a été admise.

dig +short vpn.example.com
resolvectl query vpn.example.com

Concevez l’actualisation et l’échec comme une seule politique

Une exception maintenue exige des réponses explicites : ce qui déclenche une actualisation avant que le client choisisse une nouvelle adresse, comment l’ensemble autorisé change sans ouvrir une large fenêtre temporaire, et quand les entrées obsolètes sont supprimées. Écrivez ces réponses à côté de la règle.

Choisissez délibérément le comportement en cas d’échec. Conserver l’ancienne adresse peut préserver une session et laisser une autorisation obsolète ; vider l’ensemble peut compromettre la récupération. Ni l’un ni l’autre ne devrait être le résultat accidentel d’une résolution échouée. Écrivez le comportement choisi dans le runbook pour que l’opérateur suivant n’improvise pas sous pression.

Gardez aussi le DNS d’amorçage étroit. Une exception inconditionnelle de résolveur public est un chemin DNS direct pour tout ce qu’elle couvre, pas seulement pour le nom du point de terminaison.

Prouvez le changement de point de terminaison, pas la première connexion

Utilisez le gestionnaire pris en charge du client s’il coordonne déjà la résolution et le blocage. Sur un hôte PF géré par le site, conservez la propriété et le plan de récupération du site au lieu de copier la syntaxe de table de noms d’hôte d’une autre plateforme au comportement de cycle de vie différent.

Avec un test approuvé et inoffensif, comparez l’adresse que le client sélectionne avec l’ensemble autorisé actif avant et après un changement contrôlé. Couvrez une résolution échouée, la suppression d’une entrée qui n’est plus valide et, lorsque c’est pris en charge, une autre famille d’adresses. Le tunnel prévu devrait se rétablir tandis que le trafic direct sans rapport reste sous la politique. Une première connexion réussie prouve seulement que la traduction initiale était correcte par hasard.