UNC-åtkomst i Windows-containrar: namnet först, identiteten sedan
Utforskaren på värden bevisar varken containerns DNS-väg eller dess SMB-identitet. Kontrollera namnmatchning och port 445 inuti containern innan du tittar på behörigheter.
En Windows-container som behöver en delad mapp på andra sidan av din tunnel misslyckas på två oberoende sätt, och Utforskaren på värden bevisar inget av dem. Containern har sin egen nätverksändpunkt och sin egen processidentitet. Ett namn som löses upp på skrivbordet och en session som filservern accepterar där beskriver skrivbordet, inte arbetsbelastningen.
Utforskaren på värden är inte bevis
Att öppna den delade mappen på värden använder värdens DNS-klient, värdens routingtabell och kontot som värden är inloggad med. En containerprocess ärver inget av detta implicit, även när containern körs på samma maskin och VPN-klienten också körs där. Den första gränsen är nätverksvägen: kan containern lösa upp namnet, och kan den öppna en TCP-session mot SMB-porten. Den andra är identitet: accepterar filservern det containern presenterar, med de behörigheter arbetsbelastningen behöver.
Att behandla dem som ett problem ger den välbekanta slingan av att vidga brandväggsregler för att åtgärda det som egentligen är ett svar om nekad åtkomst från den delade mappen.
Följ containerns egen begäran
Nätverket för Windows-containrar hanteras av Host Networking Service, som skapar ändpunkter med eget nätverksnamnrymd. Det läge du valde avgör om ändpunkten översätts, bryggas eller kopplas till ett nätverk som delas med värden. Det beslutet ändrar två saker samtidigt: vad containern kan lösa upp, och vilken källadress filservern ser.
Bekräfta vad containern själv observerar innan du ändrar något. Ett namn som löses upp utanför kan misslyckas inuti, eftersom containerns DNS-konfiguration inte är värdens, och en översatt ändpunkt kan presentera en källa som filserverns regler inte förväntar sig.
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"
Om uppslagningen misslyckas, åtgärda DNS i nätverkskonfigurationen i stället för att byta ut en adress. Att ersätta namnet med en IP kan ändra beteendet för autentisering och serveridentitet, vilket gör ett problem till två. VPN-klientens egen policy är nästa sak att kontrollera, eftersom den kan behandla värdprocesser och trafik som kommer från containern olika.
Identitet är ett eget beslut
En enhetsbokstav som en interaktiv användare mappar är inte ett programgränssnitt. Den finns i en enda inloggningssession, och en containerprocess är inte en del av den. Använd UNC-sökvägen och ge arbetsbelastningen en identitet som distributionsmodellen stöder. Där domänen stöder det ger ett grupphanterat tjänstekonto (gMSA) en hanterad identitet via en autentiseringsspecifikation.
Microsofts vägledning för container-gMSA beskriver den autentiseringsspecifikationsordningen och dess förutsättningar, bland annat domänmedlemskap och en värd som kan hämta autentiseringsuppgiften. Kontot, hämtningen, processidentiteten inuti containern och behörigheterna på den delade mappen måste alla stämma. En VPN-inloggning är inte den identiteten, och att baka in ett lösenord i en avbild för att återskapa värdanvändarens session skapar en bestående exponering.
Håll det misslyckade steget synligt
Misslyckad uppslagning, avvisad anslutning och nekad åtkomst kräver olika bevis. De är i tur och ordning en DNS-fråga, en routing- eller filtreringsfråga och en autentiserings- eller behörighetsfråga. Läs svaret containern fick, inte programmets allmänna fel.
Testa med arbetsbelastningens egen identitet och testa även en nekad åtkomst.
Planera för återanslutningen
VPN-vägar faller. När tunneln kommer tillbaka kan en ändpunkt komma tillbaka med en annan översatt adress, och en befintlig SMB-session kan vara död utan att programmet märker det. Hantera det i programmet: återupprätta vägen och identiteten, försök igen med operationen och stäm av en filoperation med okänt resultat i stället för att anta att ingenting hände.
Notera nätverksläget, DNS-källan och identitetsordningen i distributionsanteckningarna. Det är just dessa tre fakta nästa fel kommer att handla om.