Acesso UNC em contêineres do Windows: primeiro o nome, depois a identidade

Um contêiner do Windows que precisa de um compartilhamento do outro lado do seu túnel falha de duas maneiras independentes, e o Explorador do host não prova nenhuma delas. O contêiner tem seu próprio ponto de extremidade de rede e sua própria identidade de processo. Um nome que se resolve na área de trabalho e uma sessão que o servidor de arquivos aceita ali descrevem a área de trabalho, não a carga de trabalho.

O Explorador do host não é prova

Abrir o compartilhamento no host usa o cliente DNS do host, a tabela de rotas do host e a conta com a qual o host está conectado. Um processo de contêiner não herda nada disso implicitamente, mesmo quando o contêiner é executado na mesma máquina e o cliente VPN também é executado ali. A primeira fronteira é o caminho de rede: o contêiner consegue resolver o nome e consegue abrir uma sessão TCP para a porta SMB. A segunda é a identidade: o servidor de arquivos aceita o que o contêiner apresenta, com as permissões de que a carga de trabalho precisa.

Tratá-los como um único problema produz o conhecido ciclo de ampliar regras de firewall para corrigir o que na verdade é uma resposta de acesso negado vinda do compartilhamento.

Siga a solicitação do próprio contêiner

A rede dos contêineres do Windows é gerenciada pelo Host Networking Service, que cria pontos de extremidade com seu próprio namespace de rede. O modo escolhido decide se o ponto de extremidade é traduzido, ligado por ponte ou conectado a uma rede compartilhada com o host. Essa decisão muda duas coisas ao mesmo tempo: o que o contêiner consegue resolver e qual endereço de origem o servidor de arquivos vê.

Confirme o que o próprio contêiner observa antes de mudar qualquer coisa. Um nome que se resolve fora pode falhar dentro, porque a configuração de DNS do contêiner não é a do host, e um ponto de extremidade traduzido pode apresentar uma origem que as regras do servidor de arquivos não esperam.

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 resolução falhar, corrija o DNS na configuração de rede em vez de substituir um endereço. Substituir o nome por um IP pode alterar o comportamento de autenticação e de identidade do servidor, o que transforma um problema em dois. A própria política do cliente VPN é a próxima coisa a verificar, porque pode tratar de forma diferente os processos do host e o tráfego originado pelo contêiner.

A identidade é uma decisão separada

Uma letra de unidade mapeada por um usuário interativo não é uma interface de aplicação. Ela existe em uma única sessão de logon, e um processo de contêiner não faz parte dela. Use o caminho UNC e dê à carga de trabalho uma identidade que o modelo de implantação suporte. Onde o domínio suporta, uma conta de serviço gerenciada de grupo (gMSA) fornece uma identidade gerenciada por meio de uma especificação de credenciais.

O guia de gMSA para contêineres da Microsoft descreve esse arranjo de especificação de credenciais e seus pré-requisitos, que incluem a associação ao domínio e um host capaz de recuperar a credencial. A conta, a recuperação, a identidade do processo dentro do contêiner e as permissões do compartilhamento precisam estar alinhadas. Um logon de VPN não é essa identidade, e inserir uma senha em uma imagem para reproduzir a sessão do usuário do host cria uma exposição permanente.

Mantenha visível o estágio que falha

Uma falha de resolução, uma recusa de conexão e uma negação de acesso precisam de evidências diferentes. São respectivamente uma pergunta de DNS, uma pergunta de roteamento ou filtragem e uma pergunta de autenticação ou permissões. Leia a resposta que o contêiner recebeu em vez do erro genérico da aplicação.

Teste com a identidade da própria carga de trabalho e teste também uma negação.

Planeje a reconexão

Os caminhos de VPN caem. Quando o túnel volta, um ponto de extremidade pode voltar com outro endereço traduzido, e uma sessão SMB existente pode estar morta sem que a aplicação perceba. Trate isso na aplicação: restabeleça o caminho e a identidade, repita a operação e reconcilie uma operação de arquivo com resultado desconhecido em vez de supor que nada aconteceu.

Registre o modo de rede, a fonte de DNS e o arranjo de identidade nas notas de implantação. São exatamente esses três fatos que o próximo erro vai envolver.