UNC-adgang i Windows-containere: navnet først, identiteten derefter

En Windows-container, der har brug for en delt mappe på den anden side af din tunnel, fejler på to uafhængige måder, og Stifinder på værten beviser ingen af dem. Containeren har sit eget netværksendepunkt og sin egen procesidentitet. Et navn, der opløses på skrivebordet, og en session, som filserveren accepterer der, beskriver skrivebordet, ikke arbejdsbelastningen.

Stifinder på værten er ikke bevis

Når du åbner den delte mappe på værten, bruges værtens DNS-klient, værtens routetabel og den konto, der er logget på værten. En containerproces arver intet af dette implicit, selv når containeren kører på samme maskine, og VPN-klienten også kører der. Den første grænse er netværksvejen: kan containeren opløse navnet, og kan den åbne en TCP-session til SMB-porten. Den anden er identitet: accepterer filserveren det, containeren præsenterer, med de rettigheder, arbejdsbelastningen har brug for.

Behandler man dem som ét problem, får man den velkendte løkke, hvor firewallregler udvides for at rette det, der i virkeligheden er et svar om nægtet adgang fra den delte mappe.

Følg containerens egen anmodning

Netværk for Windows-containere styres af Host Networking Service, som opretter endepunkter med deres eget netværksnavnerum. Den valgte tilstand afgør, om endepunktet oversættes, brokobles eller knyttes til et netværk, der deles med værten. Den beslutning ændrer to ting på én gang: hvad containeren kan opløse, og hvilken kildeadresse filserveren ser.

Bekræft, hvad containeren selv observerer, før du ændrer noget. Et navn, der opløses udenfor, kan fejle indenfor, fordi containerens DNS-konfiguration ikke er værtens, og et oversat endepunkt kan præsentere en kilde, som filserverens regler ikke forventer.

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"

Hvis opløsningen fejler, skal du rette DNS i netværkskonfigurationen i stedet for at erstatte en adresse. At erstatte navnet med en IP kan ændre adfærden for godkendelse og serveridentitet, hvilket gør ét problem til to. VPN-klientens egen politik er det næste, du bør kontrollere, fordi den kan behandle værtens processer og trafik, der stammer fra containeren, forskelligt.

Identitet er en særskilt beslutning

Et drevbogstav, der tilknyttes af en interaktiv bruger, er ikke en applikationsgrænseflade. Det findes i én logonsession, og en containerproces er ikke en del af den. Brug UNC-stien, og giv arbejdsbelastningen en identitet, som udrulningsmodellen understøtter. Hvor domænet understøtter det, giver en gruppestyret tjenestekonto (gMSA) en administreret identitet via en legitimationsspecifikation.

Microsofts vejledning til container-gMSA beskriver den legitimationsspecifikationsordning og dens forudsætninger, som omfatter domænemedlemskab og en vært, der kan hente legitimationsoplysningerne. Kontoen, hentningen, procesidentiteten inde i containeren og rettighederne på den delte mappe skal alle passe sammen. Et VPN-login er ikke den identitet, og at bage en adgangskode ind i et image for at genskabe værtbrugerens session skaber en permanent eksponering.

Hold det fejlende trin synligt

En opløsningsfejl, en afvist forbindelse og en nægtet adgang kræver forskellige beviser. De er henholdsvis et DNS-spørgsmål, et routing- eller filtreringsspørgsmål og et godkendelses- eller rettighedsspørgsmål. Læs det svar, containeren modtog, i stedet for applikationens generiske fejl.

Test med arbejdsbelastningens egen identitet, og test også en nægtelse.

Planlæg genopkoblingen

VPN-veje falder ud. Når tunnelen vender tilbage, kan et endepunkt komme tilbage med en anden oversat adresse, og en eksisterende SMB-session kan være død, uden at applikationen bemærker det. Håndtér det i applikationen: genopret vejen og identiteten, prøv handlingen igen, og afstem en filhandling med et ukendt resultat i stedet for at antage, at intet skete.

Notér netværkstilstanden, DNS-kilden og identitetsordningen i udrulningsnotaterne. Det er netop de tre fakta, den næste fejl kommer til at handle om.