Accés UNC als contenidors de Windows: primer el nom, després la identitat

Un contenidor de Windows que necessita un recurs compartit a l'altre costat del túnel falla de dues maneres independents, i l'Explorador de l'amfitrió no demostra cap de les dues. El contenidor té el seu propi punt de xarxa i la seva pròpia identitat de procés. Un nom que es resol a l'escriptori i una sessió que el servidor de fitxers hi accepta descriuen l'escriptori, no la càrrega de treball.

L'Explorador de l'amfitrió no és cap prova

Obrir el recurs compartit a l'amfitrió fa servir el client DNS de l'amfitrió, la taula d'encaminament de l'amfitrió i el compte amb què s'ha iniciat sessió a l'amfitrió. Un procés de contenidor no n'hereta cap d'aquests de manera implícita, fins i tot quan el contenidor s'executa a la mateixa màquina i el client VPN també s'hi executa. La primera frontera és el camí de xarxa: pot el contenidor resoldre el nom i pot obrir una sessió TCP al port SMB. La segona és la identitat: accepta el servidor de fitxers el que el contenidor presenta, amb els permisos que la càrrega de treball necessita.

Tractar-los com un sol problema produeix el bucle conegut d'ampliar regles de tallafocs per arreglar el que en realitat és una resposta d'accés denegat del recurs compartit.

Seguiu la petició del propi contenidor

La xarxa dels contenidors de Windows la gestiona el Host Networking Service, que crea punts finals amb el seu propi espai de noms de xarxa. El mode que heu triat decideix si el punt final es tradueix, es pont o s'uneix a una xarxa compartida amb l'amfitrió. Aquesta decisió canvia dues coses alhora: què pot resoldre el contenidor i quina adreça d'origen veu el servidor de fitxers.

Confirmeu què observa el mateix contenidor abans de canviar res. Un nom que es resol fora pot fallar dins, perquè la configuració DNS del contenidor no és la de l'amfitrió, i un punt final traduït pot presentar un origen que les regles del servidor de fitxers no esperen.

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 resolució falla, corregeu el DNS a la configuració de xarxa en lloc de substituir una adreça. Substituir el nom per una IP pot canviar el comportament de l'autenticació i de la identitat del servidor, cosa que converteix un problema en dos. La política pròpia del client VPN és la següent cosa que cal comprovar, perquè pot tractar de manera diferent els processos de l'amfitrió i el trànsit originat pel contenidor.

La identitat és una decisió a part

Una lletra d'unitat assignada per un usuari interactiu no és una interfície d'aplicació. Existeix en una sola sessió d'inici i un procés de contenidor no en forma part. Feu servir el camí UNC i doneu a la càrrega de treball una identitat que el model de desplegament admeti. On el domini ho admet, un compte de servei gestionat de grup (gMSA) proporciona una identitat gestionada mitjançant una especificació de credencials.

La guia de gMSA per a contenidors de Microsoft descriu aquesta disposició d'especificació de credencials i els seus requisits previs, que inclouen la pertinença al domini i un amfitrió capaç d'obtenir la credencial. El compte, l'obtenció, la identitat del procés dins del contenidor i els permisos del recurs compartit han d'encaixar tots. Un inici de sessió VPN no és aquesta identitat, i incrustar una contrasenya en una imatge per reproduir la sessió de l'usuari de l'amfitrió crea una exposició permanent.

Manteniu visible l'etapa que falla

Un error de resolució, un refús de connexió i una denegació d'accés necessiten proves diferents. Són respectivament una qüestió de DNS, una qüestió d'encaminament o filtratge i una qüestió d'autenticació o permisos. Llegiu la resposta que ha rebut el contenidor en lloc de l'error genèric de l'aplicació.

Proveu amb la identitat pròpia de la càrrega de treball i proveu també una denegació.

Planifiqueu la reconnexió

Els camins VPN cauen. Quan el túnel torna, un punt final pot tornar amb una altra adreça traduïda, i una sessió SMB existent pot ser morta sense que l'aplicació se n'adoni. Gestioneu-ho a l'aplicació: restabliu el camí i la identitat, torneu a intentar l'operació i reconcilieu una operació de fitxers amb un resultat desconegut en lloc de suposar que no ha passat res.

Anoteu el mode de xarxa, la font de DNS i la disposició d'identitat a les notes de desplegament. Aquests tres fets són el tema del proper error.