Adresses de confidentialité IPv6 ou liste d'autorisation RDP : choisissez le compromis

L'accès au bureau à distance a fonctionné pendant un mois, puis la liste d'autorisation a cessé de correspondre sans raison visible. L'hôte n'avait pas bougé et rien dans le pare-feu n'avait été modifié. Windows continue de former des adresses temporaires IPv6 avec des identifiants d'interface aléatoires et de les retirer, si bien que l'adresse source que le serveur voit un jour donné peut être une que personne n'a écrite dans la règle. Désactiver ce comportement corrige la correspondance et transforme en même temps l'hôte en identifiant durable. Pesez les alternatives avant d'accepter la seconde moitié.

Pourquoi la règle a cessé de correspondre

La RFC 4941 décrit les adresses temporaires : l'hôte crée des adresses supplémentaires avec des identifiants aléatoires et les retire, ce qui empêche un observateur de corréler un hôte d'une visite à l'autre. Windows implémente ce comportement, donc l'adresse source d'hier n'est pas nécessairement celle d'aujourd'hui. L'adresse prévisible existe toujours sur l'interface ; ce n'est simplement pas celle qu'une connexion sortante préfère.

C'est pourquoi la panne paraît intermittente plutôt que totale. La règle correspond pendant un temps après la création de l'adresse, cesse de correspondre lorsqu'elle est retirée, et recommence à correspondre après que quelqu'un l'a modifiée. La supervision regroupée par adresse source et les contrôles de licence liés à une adresse d'hôte cassent au même rythme. Une règle qui fonctionne juste après avoir été modifiée et échoue trois semaines plus tard est généralement cela, pas un rechargement du pare-feu.

Option une : une adresse stable, moins de confidentialité

La réparation habituelle désactive les deux mécanismes de rotation sur l'hôte : netsh interface ipv6 set privacy state=disabled store=persistent et netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent. Ajoutez store=active si vous voulez que le changement prenne effet sans attendre un redémarrage, et acceptez d'avoir rendu l'identifiant prévisible d'un réseau à l'autre.

Cette prévisibilité est exactement ce que les extensions ont été conçues pour empêcher. Une adresse qui suit l'hôte du café au bureau puis à la maison est une clé de filtrage commode et une clé de suivi tout aussi commode, et la seconde propriété survit au ticket qui a demandé la première.

Option deux : autoriser un préfixe ou un nom

Autoriser le /64 plutôt que l'adresse complète préserve la rotation et correspond à une affirmation plus faible mais souvent honnête : cette machine est sur mon réseau domestique. Elle cesse de suffire dès que ce préfixe contient des hôtes que vous n'admettriez pas, ce qui, sur une connexion grand public, est généralement un ensemble plus petit qu'on ne le suppose. Un nom publié via DNS dynamique est plus simple à exploiter, car l'enregistrement suit l'hôte et la politique se lit comme une identité plutôt que comme une plage qui grandit à chaque appareil ajouté.

Les deux options ont besoin d'un résolveur auquel le serveur peut faire confiance et d'un nom qui ne se falsifie pas trivialement, alors traitez-les comme une décision de politique sur l'identité et non comme un changement cosmétique de la règle. Notez quel résolveur répond à ce nom, car la règle n'est fiable que tant que l'enregistrement derrière elle l'est.

Option trois : laissez le tunnel attribuer l'adresse

Si la connexion traverse un VPN que vous contrôlez, le serveur peut distribuer l'adresse depuis son propre pool, et la liste d'autorisation référence alors une valeur que le serveur choisit plutôt qu'une que le client préfère. Cela fonctionne bien pour les clients gérés et mal pour tout ce que le client peut outrepasser, alors vérifiez quel côté l'emporte réellement dans votre déploiement.

Déplacer la décision entièrement hors de l'adresse, vers un certificat client ou une passerelle authentifiée, est l'option qui passe à l'échelle, car elle cesse de dépendre d'une valeur que le système d'exploitation a le droit de changer.

Choisissez en gardant le coût de suivi en vue

Écrivez les quatre options face à l'exigence réelle, et choisissez-en une plutôt que de les combiner. Si vous désactivez quand même la confidentialité, limitez-la à l'hôte qui en a besoin, documentez la raison à côté de la règle, et envisagez l'adressage stable-confidentiel de la RFC 7217 là où la plateforme le prend en charge, puisqu'il conserve un identifiant par préfixe sans exposer celui dérivé du matériel. Réactivez les extensions lorsque la liste d'autorisation est remplacée.

Consignez le changement à côté de la règle qu'il soutient. Sans cette note, l'administrateur suivant trouve un hôte avec les extensions de confidentialité désactivées et sans explication, et les réactive lors d'un nettoyage.