Accès UNC dans les conteneurs Windows : d'abord le nom, ensuite l'identité

Un conteneur Windows qui a besoin d'un partage de l'autre côté de votre tunnel échoue de deux manières indépendantes, et l'Explorateur de l'hôte ne prouve ni l'une ni l'autre. Le conteneur possède son propre point de terminaison réseau et sa propre identité de processus. Un nom qui se résout sur le poste de travail et une session que le serveur de fichiers y accepte décrivent le poste de travail, pas la charge de travail.

L'Explorateur de l'hôte n'est pas une preuve

Ouvrir le partage sur l'hôte utilise le client DNS de l'hôte, la table de routage de l'hôte et le compte ouvert sur l'hôte. Un processus de conteneur n'hérite d'aucun de ces éléments de façon implicite, même lorsque le conteneur s'exécute sur la même machine et que le client VPN y tourne aussi. La première frontière est le chemin réseau : le conteneur peut-il résoudre le nom, et peut-il ouvrir une session TCP vers le port SMB. La seconde est l'identité : le serveur de fichiers accepte-t-il ce que le conteneur présente, avec les autorisations dont la charge de travail a besoin.

Les traiter comme un seul problème produit la boucle bien connue d'élargissement des règles de pare-feu pour corriger ce qui est en réalité une réponse d'accès refusé venant du partage.

Suivez la requête du conteneur lui-même

Le réseau des conteneurs Windows est géré par le Host Networking Service, qui crée des points de terminaison dotés de leur propre espace de noms réseau. Le mode que vous avez choisi détermine si le point de terminaison est traduit, ponté ou rattaché à un réseau partagé avec l'hôte. Cette décision change deux choses à la fois : ce que le conteneur peut résoudre et quelle adresse source le serveur de fichiers voit.

Confirmez ce que le conteneur lui-même observe avant de changer quoi que ce soit. Un nom qui se résout à l'extérieur peut échouer à l'intérieur, car la configuration DNS du conteneur n'est pas celle de l'hôte, et un point de terminaison traduit peut présenter une source que les règles du serveur de fichiers n'attendent pas.

docker exec -it app powershell -Command "Resolve-DnsName files.corp.example"
docker exec -it app powershell -Command "Test-NetConnection files.corp.example -Port 445"
docker exec -it app powershell -Command "Get-NetIPConfiguration"

Si la résolution échoue, corrigez le DNS dans la configuration réseau plutôt que de substituer une adresse. Remplacer le nom par une IP peut modifier le comportement de l'authentification et de l'identité du serveur, ce qui transforme un problème en deux. La politique propre au client VPN est la chose à vérifier ensuite, car elle peut traiter différemment les processus de l'hôte et le trafic issu du conteneur.

L'identité est une décision distincte

Une lettre de lecteur mappée par un utilisateur interactif n'est pas une interface applicative. Elle existe dans une seule session d'ouverture et un processus de conteneur n'en fait pas partie. Utilisez le chemin UNC et donnez à la charge de travail une identité que le modèle de déploiement prend en charge. Là où le domaine le permet, un compte de service géré de groupe (gMSA) fournit une identité gérée via une spécification d'informations d'identification.

Le guide gMSA pour conteneurs de Microsoft décrit cet agencement de spécification d'informations d'identification et ses prérequis, dont l'appartenance au domaine et un hôte capable de récupérer l'information d'identification. Le compte, la récupération, l'identité du processus dans le conteneur et les autorisations du partage doivent tous s'aligner. Une connexion VPN n'est pas cette identité, et intégrer un mot de passe dans une image pour reproduire la session de l'utilisateur de l'hôte crée une exposition permanente.

Gardez l'étape défaillante visible

Un échec de résolution, un refus de connexion et un refus d'accès exigent des preuves différentes. Ce sont respectivement une question de DNS, une question de routage ou de filtrage, et une question d'authentification ou d'autorisations. Lisez la réponse reçue par le conteneur plutôt que l'erreur générique de l'application.

Testez avec l'identité propre à la charge de travail et testez aussi un refus.

Prévoyez la reconnexion

Les chemins VPN tombent. Lorsque le tunnel revient, un point de terminaison peut revenir avec une autre adresse traduite, et une session SMB existante peut être morte sans que l'application le remarque. Gérez cela dans l'application : rétablissez le chemin et l'identité, réessayez l'opération et réconciliez une opération de fichier au résultat inconnu au lieu de supposer que rien ne s'est produit.

Consignez le mode réseau, la source DNS et l'agencement d'identité dans les notes de déploiement. Ce sont précisément ces trois faits qui feront l'objet de la prochaine défaillance.