Nom de point de terminaison VPN contre nom de service privé : deux responsables

Deux noms peuvent décrire la même agence et répondre à des questions totalement différentes. vpn.branch.example indique à un pair distant où trouver le point de terminaison VPN, et il doit être résolu avant que le moindre tunnel existe. inventory.branch.example indique à un utilisateur autorisé où vit une application privée, et il ne compte qu’une fois le tunnel monté. Entretenir l’un ne fait rien pour l’autre.

Nommez les deux enregistrements avant de déboguer l’un ou l’autre

Notez les deux avec leurs responsables. Pour le point de terminaison, consignez qui met à jour l’adresse publique et comment le client VPN rafraîchit sa réponse. Pour le service, consignez qui possède l’adresse privée, quelle zone détient l’enregistrement et quels résolveurs sont censés répondre pour lui.

Cette courte liste évite le diagnostic erroné le plus courant dans ce domaine : redémarrer un tunnel d’agence qui fonctionne pour réparer un enregistrement qui vit entièrement à l’intérieur. Le tunnel est le transport du nom de service ; il n’en est pas l’autorité.

Quand un changement est proposé, demandez lequel des deux enregistrements il touche. Si personne ne peut répondre, le changement n’est pas prêt à être planifié.

Le point de terminaison doit être résolu avant que le moindre tunnel existe

Supposons que la connexion internet de l’agence reçoive une nouvelle adresse publique. Le programme de mise à jour du point de terminaison publie la nouvelle adresse, et l’implémentation VPN distante doit pouvoir lire la réponse modifiée. Quel que soit le résolveur qui fournit cette réponse, il doit être joignable sans le tunnel, sinon le client court après un nom qu’il ne peut résoudre qu’après s’être connecté à ce qu’il ne trouve pas.

Cette dépendance d’amorçage mérite d’être dite clairement, car elle se crée facilement par accident quand tous les résolveurs internes sont derrière le VPN. Gardez un chemin pré-tunnel pour la recherche du point de terminaison et confirmez le comportement de reconnexion du client au lieu de supposer qu’une nouvelle réponse est prise en compte immédiatement.

Le DNS dynamique a aussi des limites que la mise à jour d’enregistrement ne peut franchir. Mettre à jour un enregistrement n’ouvre aucun port de pare-feu, ne crée aucune correspondance NAT et ne prouve aucune identité de pair. Une adresse publiée avec un port fermé donne un client qui résout correctement et ne peut toujours se connecter à rien.

Enfin, un client en cours d’exécution peut continuer d’utiliser un point de terminaison en cache jusqu’à sa reconnexion. Séparez la publication, le cache et la politique de reconnexion dans vos notes, afin qu’un pair périmé ne soit pas pris pour un programme de mise à jour défaillant.

Le nom de service décrit où vit l’application

Supposons maintenant que le tunnel reste sain mais que le serveur d’inventaire passe de 172.26.14.20 à 172.26.14.35. L’enregistrement public du point de terminaison n’est pas touché, tandis que l’enregistrement privé du service doit changer. Utiliser une adresse réservée à ce service, ou une attribution statique, rend cela plus rare ; un chemin de mise à jour autorisé couvre les fois où c’est intentionnel.

Deux mécanismes de mise à jour sont confondus ici. RFC 2136 définit un protocole pour ajouter et supprimer des enregistrements DNS dans une zone, alors qu’un fournisseur commercial de DNS dynamique peut exposer une API HTTP complètement différente pour un autre usage. Utiliser l’un n’implique pas que l’autre existe dans votre environnement. Vérifiez quel mécanisme votre zone accepte réellement avant d’écrire un programme de mise à jour contre lui.

Une réponse privée correcte n’est que la première condition. Pour qu’un appelant distant l’utilise, le client a besoin d’un résolveur qui porte la zone privée, d’une politique qui autorise les requêtes vers ce résolveur et d’un transfert pour l’adresse qui revient. Un nom qui résout vers une adresse que le client ne peut atteindre produit un délai d’attente qui ressemble à une panne de serveur.

Testez les deux chemins séparément

Vérifiez le point de terminaison depuis l’extérieur du tunnel et le service depuis l’intérieur, et conservez les résultats comme deux faits indépendants :

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

Si la première requête échoue, le problème vient de la publication publique ou du chemin de résolution pré-tunnel, et aucun changement interne n’aidera. Si la deuxième renvoie une adresse mais que la troisième ne montre aucune route par le tunnel, la couche DNS est correcte et la politique de transfert ne l’est pas.

Lancez la paire après chaque changement d’adresse et notez quel enregistrement a bougé. Une passation qui dit seulement « le DNS a été mis à jour » laisse l’ingénieur suivant deviner lequel des deux cycles de vie s’est réellement exécuté.