En Windows-container som skal bruke en delt mappe på den andre siden av tunnelen, kan feile på to uavhengige måter, og Utforskeren på vertsmaskinen beviser ingen av dem. Containeren har eget nettverksendepunkt og egen prosessidentitet. Et navn som løses opp på skrivebordet, og en økt som filserveren godtar der, sier noe om skrivebordet og ikke om arbeidslasten.

Utforskeren på vertsmaskinen er ikke bevis

Når du åpner den delte mappen på vertsmaskinen, brukes vertens DNS-klient, vertens rutetabell og kontoen som er pålogget der. En containerprosess arver ikke noe av dette automatisk, heller ikke når containeren kjører på samme maskin som VPN-klienten. Den første grensen er nettverksveien: klarer containeren å løse opp navnet, og klarer den å åpne en TCP-forbindelse til SMB-porten. Den andre grensen er identitet: godtar filserveren det containeren legger fram, med de tillatelsene arbeidslasten trenger.

Hvis begge behandles som én sak, ender man i den kjente løkka med å utvide brannmurregler for å rette opp det som i virkeligheten er et svar om nektet tilgang fra den delte mappen.

Følg containernes egen forespørsel

Host Networking Service styrer nettverket for Windows-containere og oppretter endepunkter med eget nettverksnavnerom. Modusen du har valgt, bestemmer om endepunktet oversettes, broes eller knyttes til et nettverk som deles med vertsmaskinen. Det valget endrer to ting på én gang: hva containeren kan løse opp, og hvilken kildeadresse filserveren ser.

Finn ut hva containeren selv observerer før du endrer noe. Et navn som løses opp utenfor, kan feile innenfor, fordi containerens DNS-oppsett ikke er vertens, og et oversatt endepunkt kan vise 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 oppslaget feiler, bør DNS rettes i nettverksoppsettet i stedet for å bytte ut adressen. Å erstatte navnet med en IP kan endre hvordan autentisering og serveridentitet oppfører seg, og da blir ett problem til to. Neste punkt er VPN-klientens egen policy, fordi den kan behandle vertsprosesser og trafikk fra containeren forskjellig.

Identitet er en egen avgjørelse

En stasjonsbokstav som en interaktiv bruker har tilordnet, er ikke et programgrensesnitt. Den lever i én påloggingsøkt, og en containerprosess er ikke med i den. Bruk UNC-stien og gi arbeidslasten en identitet som utrullingsmodellen støtter. Der domenet tillater det, gir en gruppestyrt tjenestekonto (gMSA) en administrert identitet via en legitimasjonsspesifikasjon.

Microsofts veiledning for container-gMSA forklarer denne legitimasjonsspesifikasjonen og forutsetningene for den, blant annet domenemedlemskap og en vert som kan hente legitimasjonen. Kontoen, hentingen, prosessidentiteten i containeren og tillatelsene på den delte mappen må henge sammen. En VPN-pålogging er ikke denne identiteten, og et passord bakt inn i et image for å gjenskape vertsbrukerens økt gir en varig eksponering.

Hold det trinnet som feiler synlig

Feilet oppslag, avvist forbindelse og nektet tilgang krever forskjellige bevis. Det er henholdsvis et DNS-spørsmål, et ruting- eller filtreringsspørsmål og et autentiserings- eller tillatelsesspørsmål. Les svaret containeren faktisk fikk, ikke den generelle feilmeldingen fra programmet.

Test med arbeidslastens egen identitet, og test også en nektelse.

Planlegg for ny tilkobling

VPN-veier faller ut. Når tunnelen er tilbake, kan et endepunkt komme tilbake med en annen oversatt adresse, og en SMB-økt som allerede finnes, kan være død uten at programmet oppdager det. Håndter dette i programmet: gjenopprett veien og identiteten, gjenta operasjonen, og avstem en filoperasjon med ukjent resultat i stedet for å anta at ingenting skjedde.

Skriv ned nettverksmodus, DNS-kilde og identitetsoppsett i utrullingsnotatene. Det er disse tre fakta den neste feilen kommer til å handle om.

Relaterte artikler