Acceso UNC en contenedores de Windows: primero el nombre, después la identidad

Un contenedor de Windows que necesita un recurso compartido al otro lado de su túnel falla de dos maneras independientes, y el Explorador del host no demuestra ninguna de las dos. El contenedor tiene su propio extremo de red y su propia identidad de proceso. Un nombre que se resuelve en el escritorio y una sesión que el servidor de archivos acepta allí describen el escritorio, no la carga de trabajo.

El Explorador del host no es una prueba

Abrir el recurso compartido en el host usa el cliente DNS del host, la tabla de rutas del host y la cuenta con la que se ha iniciado sesión en el host. Un proceso de contenedor no hereda nada de eso de forma implícita, ni siquiera cuando el contenedor se ejecuta en la misma máquina y el cliente VPN también se ejecuta allí. La primera frontera es la ruta de red: puede el contenedor resolver el nombre y puede abrir una sesión TCP al puerto SMB. La segunda es la identidad: acepta el servidor de archivos lo que el contenedor presenta, con los permisos que la carga de trabajo necesita.

Tratarlos como un solo problema produce el conocido bucle de ampliar reglas de cortafuegos para arreglar lo que en realidad es una respuesta de acceso denegado del recurso compartido.

Siga la petición del propio contenedor

La red de los contenedores de Windows la gestiona el Host Networking Service, que crea extremos con su propio espacio de nombres de red. El modo que eligió decide si el extremo se traduce, se puentea o se conecta a una red compartida con el host. Esa decisión cambia dos cosas a la vez: qué puede resolver el contenedor y qué dirección de origen ve el servidor de archivos.

Confirme qué observa el propio contenedor antes de cambiar nada. Un nombre que se resuelve fuera puede fallar dentro, porque la configuración DNS del contenedor no es la del host, y un extremo traducido puede presentar un origen que las reglas del servidor de archivos no esperan.

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ón falla, corrija el DNS en la configuración de red en lugar de sustituir una dirección. Sustituir el nombre por una IP puede cambiar el comportamiento de la autenticación y de la identidad del servidor, lo que convierte un problema en dos. La propia política del cliente VPN es lo siguiente que hay que revisar, porque puede tratar de forma distinta los procesos del host y el tráfico originado por el contenedor.

La identidad es una decisión aparte

Una letra de unidad asignada por un usuario interactivo no es una interfaz de aplicación. Existe en una sola sesión de inicio y un proceso de contenedor no forma parte de ella. Use la ruta UNC y dé a la carga de trabajo una identidad que el modelo de despliegue admita. Donde el dominio lo admite, una cuenta de servicio administrada de grupo (gMSA) proporciona una identidad administrada mediante una especificación de credenciales.

La guía de gMSA para contenedores de Microsoft describe esa disposición de especificación de credenciales y sus requisitos previos, que incluyen la pertenencia al dominio y un host capaz de recuperar la credencial. La cuenta, la recuperación, la identidad del proceso dentro del contenedor y los permisos del recurso compartido tienen que encajar todos. Un inicio de sesión VPN no es esa identidad, y hornear una contraseña en una imagen para reproducir la sesión del usuario del host crea una exposición permanente.

Mantenga visible la etapa que falla

Un fallo de resolución, un rechazo de conexión y una denegación de acceso necesitan pruebas distintas. Son respectivamente una cuestión de DNS, una cuestión de enrutamiento o filtrado y una cuestión de autenticación o permisos. Lea la respuesta que recibió el contenedor en lugar del error genérico de la aplicación.

Pruebe con la identidad propia de la carga de trabajo y pruebe también una denegación.

Planifique la reconexión

Las rutas VPN caen. Cuando el túnel vuelve, un extremo puede volver con otra dirección traducida, y una sesión SMB existente puede estar muerta sin que la aplicación lo note. Gestiónelo en la aplicación: restablezca la ruta y la identidad, reintente la operación y concilie una operación de archivo con un resultado desconocido en lugar de suponer que no pasó nada.

Anote el modo de red, la fuente de DNS y la disposición de identidad en las notas de despliegue. Esos tres hechos serán el tema del próximo fallo.