Les tâches VPN qui restaurent le fichier hosts effacent les modifications ultérieures

Une tâche de connexion copie le fichier hosts de Windows, y ajoute une adresse privée, et une tâche de déconnexion recopie la version enregistrée. Cela fonctionne pendant des semaines, puis un après-midi la machine n’atteint plus un site interne qui n’a rien à voir avec le VPN. La restauration a fait exactement ce qu’on lui demandait : elle a remis un fichier d’avant la modification de quelqu’un d’autre. La défaillance est dans le modèle, pas dans la commande de copie.

Tout flux de travail qui fige un fichier partagé puis le restaure hérite de chaque changement survenu entre-temps comme d’une perte.

Une sauvegarde restaurée plus tard n’est pas une sauvegarde du présent

Parcourez une séquence ordinaire. La tâche enregistre le fichier et ajoute une entrée pour le tunnel. Plus tard un administrateur ajoute une correction sans rapport, et un second profil ajoute sa propre entrée. À la déconnexion, la restauration remet l’instantané d’origine, supprimant à la fois l’entrée du second profil et la correction de l’administrateur. Ni l’une ni l’autre n’appartenait au VPN, et les deux ont maintenant disparu.

Un seul nom de fichier de sauvegarde fixe aggrave les choses. Un événement de connexion ultérieur peut copier le fichier déjà modifié par-dessus l’original supposé, si bien que la base de récupération dérive vers l’aspect du fichier au dernier événement.

Chaque événement est une notification, pas une transaction

Une tâche déclenchée par un événement est une notification. Une reconnexion, un arrêt interrompu ou un second profil peuvent remodeler l’état requis pendant qu’une tâche antérieure est encore en train d’écrire. Rien ne sérialise les deux, et rien n’annule un changement à moitié terminé. Un identifiant d’événement seul ne dit pas non plus à quel profil il appartient sans le fournisseur et ses données. Traiter la tâche comme une transaction est l’hypothèse qui échoue.

Les événements de connexion répétés sont l’autre moitié : un ajout sans contrôle crée une seconde entrée identique, et certains résolveurs voient alors deux réponses pour un même nom.

Donnez à chaque mappage un propriétaire

Chaque ligne du fichier hosts associe un nom d’hôte à une adresse et ne dit rien du tunnel qui est actif. Si l’automatisation est inévitable, assignez un propriétaire unique pour les mappages gérés par le VPN. Ce propriétaire ne devrait mettre à jour que ses propres entrées, préserver le contenu actuel sans rapport, éviter les doublons lors d’un événement répété et se réconcilier avec les connexions réellement actives plutôt qu’avec une liste mémorisée.

Quand deux tunnels actifs ont besoin du même mappage, une seule déconnexion ne doit pas le supprimer alors que l’autre propriétaire en a encore besoin. Cela exige un comptage de références ou un enregistrement explicite de propriété, pas un booléen.

Une sauvegarde garde son intérêt pour une récupération revue. Elle ne devrait pas être l’action normale de déconnexion, et elle ne devrait pas être le seul relevé de ce que contenait le fichier.

Quand le DNS conditionnel est le véritable besoin

Si l’exigence réelle est un espace de noms privé qui ne se résout que pendant que le tunnel est actif, hosts est le mauvais mécanisme. Windows NRPT peut choisir un résolveur pour un espace de noms, et elle ne crée pas elle-même l’enregistrement d’adresse ; un résolveur doit tout de même répondre. C’est une conception différente avec un propriétaire différent, et elle supprime entièrement la modification du fichier à chaque transition.

Si hosts est conservé exprès pour un seul service fixe, assurez-vous que son adresse reste joignable par la route prévue et que son nom d’hôte reste stable pour que les contrôles d’identité de l’application continuent de fonctionner. Vider un cache DNS ne peut pas réparer une entrée périmée que la recherche suivante relira.

Testez des connexions répétées, deux profils simultanés et une déconnexion après une modification sans rapport. Le résultat devrait être que le mappage du VPN suit son propriétaire sans rembobiner le reste de la machine.