Un contedor de Windows que precisa un recurso compartido na outra beira do seu túnel falla de dúas maneiras independentes, e o Explorador do host non demostra ningunha delas. O contedor ten o seu propio punto de conexión de rede e a súa propia identidade de proceso. Un nome que se resolve no escritorio e unha sesión que o servidor de ficheiros acepta alí describen o escritorio, non a carga de traballo.

O Explorador do host non é unha proba

Abrir o recurso compartido no host usa o cliente DNS do host, a táboa de rutas do host e a conta coa que se iniciou sesión no host. Un proceso de contedor non herda nada diso de forma implícita, aínda que o contedor se execute na mesma máquina e o cliente VPN tamén se execute alí. A primeira fronteira é a ruta de rede: pode o contedor resolver o nome e pode abrir unha sesión TCP ao porto SMB. A segunda é a identidade: acepta o servidor de ficheiros o que o contedor presenta, cos permisos que a carga de traballo necesita.

Tratalos como un só problema produce o coñecido bucle de ampliar regras de devasa para corrixir o que en realidade é unha resposta de acceso denegado do recurso compartido.

Siga a petición do propio contedor

A rede dos contedores de Windows xestiónao o Host Networking Service, que crea puntos de conexión co seu propio espazo de nomes de rede. O modo que escolleu decide se o punto de conexión se traduce, se ponte ou se conecta a unha rede compartida co host. Esa decisión cambia dúas cousas á vez: que pode resolver o contedor e que enderezo de orixe ve o servidor de ficheiros.

Confirme que observa o propio contedor antes de cambiar nada. Un nome que se resolve fóra pode fallar dentro, porque a configuración DNS do contedor non é a do host, e un punto de conexión traducido pode presentar unha orixe que as regras do servidor de ficheiros non 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"

Se a resolución falla, corrixa o DNS na configuración de rede en lugar de substituír un enderezo. Substituír o nome por unha IP pode cambiar o comportamento da autenticación e da identidade do servidor, o que converte un problema en dous. A propia política do cliente VPN é o seguinte que hai que revisar, porque pode tratar de forma distinta os procesos do host e o tráfico orixinado polo contedor.

A identidade é unha decisión aparte

Unha letra de unidade asignada por un usuario interactivo non é unha interface de aplicación. Existe nunha soa sesión de inicio e un proceso de contedor non forma parte dela. Use a ruta UNC e dea á carga de traballo unha identidade que o modelo de despregamento admita. Onde o dominio o admite, unha conta de servizo xestionada de grupo (gMSA) proporciona unha identidade xestionada mediante unha especificación de credenciais.

A guía de gMSA para contedores de Microsoft describe esa disposición de especificación de credenciais e os seus requisitos previos, que inclúen a pertenza ao dominio e un host capaz de recuperar a credencial. A conta, a recuperación, a identidade do proceso dentro do contedor e os permisos do recurso compartido teñen que encaixar todos. Un inicio de sesión VPN non é esa identidade, e inserir un contrasinal nunha imaxe para reproducir a sesión do usuario do host crea unha exposición permanente.

Manteña visible a etapa que falla

Un fallo de resolución, un rexeitamento de conexión e unha denegación de acceso necesitan probas distintas. Son respectivamente unha cuestión de DNS, unha cuestión de encamiñamento ou filtrado e unha cuestión de autenticación ou permisos. Lea a resposta que recibiu o contedor en lugar do erro xenérico da aplicación.

Probe coa identidade propia da carga de traballo e probe tamén unha denegación.

Planifique a reconexión

As rutas VPN caen. Cando o túnel volve, un punto de conexión pode volver cunha outra dirección traducida, e unha sesión SMB existente pode estar morta sen que a aplicación o note. Xestione isto na aplicación: restableza a ruta e a identidade, reintente a operación e concilie unha operación de ficheiro cun resultado descoñecido en lugar de supoñer que non pasou nada.

Anote o modo de rede, a fonte de DNS e a disposición de identidade nas notas de despregamento. Eses tres feitos serán o tema do próximo fallo.

Artigos relacionados