Aksesi UNC në kontejnerët Windows: së pari emri, pastaj identiteti

Një kontejner Windows që ka nevojë për një ndarje në anën tjetër të tunelit tuaj dështon në dy mënyra të pavarura, dhe Explorer-i i hostit nuk vërteton asnjërën. Kontejneri ka pikën e vet të skajit të rrjetit dhe identitetin e vet të procesit. Një emër që zgjidhet në desktop dhe një sesion që serveri i skedarëve pranon atje përshkruajnë desktopin, jo ngarkesën e punës.

Explorer-i i hostit nuk është provë

Hapja e ndarjes në host përdor klientin DNS të hostit, tabelën e rrugëtimit të hostit dhe llogarinë me të cilën hosti është i identifikuar. Një proces kontejneri nuk trashëgon asgjë nga këto në mënyrë të nënkuptuar, edhe kur kontejneri ekzekutohet në të njëjtën makinë dhe klienti VPN ekzekutohet gjithashtu atje. Kufiri i parë është rruga e rrjetit: a mundet kontejneri ta zgjidhë emrin, dhe a mund të hapë një sesion TCP drejt portës SMB. I dyti është identiteti: a e pranon serveri i skedarëve atë që paraqet kontejneri, me lejet që i nevojiten ngarkesës së punës.

Trajtimi i tyre si një problem i vetëm prodhon ciklin e njohur të zgjerimit të rregullave të murit të zjarrit për të rregulluar atë që në të vërtetë është një përgjigje e aksesit të refuzuar nga ndarja.

Ndiqni kërkesën e vetë kontejnerit

Rrjeti i kontejnerëve Windows menaxhohet nga Host Networking Service, e cila krijon pika skaji me hapësirën e tyre të emrave të rrjetit. Modaliteti që keni zgjedhur vendos nëse pika e skajit përkthehet, lidhet me urë ose lidhet me një rrjet të përbashkët me hostin. Ky vendim ndryshon dy gjëra njëherësh: çfarë mund të zgjidhë kontejneri dhe cilën adresë burimore sheh serveri i skedarëve.

Konfirmoni atë që vëzhgon vetë kontejneri përpara se të ndryshoni çdo gjë. Një emër që zgjidhet jashtë mund të dështojë brenda, sepse konfigurimi DNS i kontejnerit nuk është ai i hostit, dhe një pikë skaji e përkthyer mund të paraqesë një burim që rregullat e serverit të skedarëve nuk e presin.

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"

Nëse zgjidhja dështon, rregulloni DNS-në në konfigurimin e rrjetit në vend që të zëvendësoni një adresë. Zëvendësimi i emrit me një IP mund të ndryshojë sjelljen e vërtetimit dhe identitetit të serverit, gjë që e kthen një problem në dy. Politika e vetë klientit VPN është gjëja tjetër për t'u kontrolluar, sepse mund t'i trajtojë ndryshe proceset e hostit dhe trafikun që buron nga kontejneri.

Identiteti është një vendim i veçantë

Një shkronjë disku e lidhur nga një përdorues interaktiv nuk është ndërfaqe aplikacioni. Ajo ekziston në një sesion të vetëm identifikimi, dhe një proces kontejneri nuk është pjesë e tij. Përdorni rrugën UNC dhe jepini ngarkesës së punës një identitet që modeli i vendosjes mbështet. Aty ku domeni e mbështet, një llogari shërbimi e menaxhuar nga grupi (gMSA) ofron një identitet të menaxhuar përmes një specifikimi kredencialesh.

Udhëzuesi i Microsoft për gMSA në kontejnerë përshkruan këtë rregullim të specifikimit të kredencialeve dhe parakushtet e tij, duke përfshirë anëtarësimin në domen dhe një host të aftë ta marrë kredencialin. Llogaria, marrja, identiteti i procesit brenda kontejnerit dhe lejet e ndarjes duhet të përputhen të gjitha. Një identifikim VPN nuk është ai identitet, dhe futja e një fjalëkalimi në një imazh për të riprodhuar sesionin e përdoruesit të hostit krijon një ekspozim të përhershëm.

Mbajeni të dukshëm fazën që dështon

Dështimi i zgjidhjes, refuzimi i lidhjes dhe refuzimi i aksesit kërkojnë prova të ndryshme. Ato janë përkatësisht një pyetje DNS, një pyetje rrugëtimi ose filtrimi dhe një pyetje vërtetimi ose lejesh. Lexoni përgjigjen që mori kontejneri, jo gabimin e përgjithshëm të aplikacionit.

Testoni me identitetin e vetë ngarkesës së punës dhe testoni gjithashtu një refuzim.

Planifikoni rilidhjen

Rrugët VPN bien. Kur tuneli kthehet, një pikë skaji mund të kthehet me një adresë tjetër të përkthyer, dhe një sesion SMB ekzistues mund të jetë i vdekur pa e vënë re aplikacioni. Trajtojeni këtë në aplikacion: rivendosni rrugën dhe identitetin, riprovoni operacionin dhe barazoni një operacion skedari me rezultat të panjohur në vend që të supozoni se nuk ndodhi asgjë.

Regjistroni modalitetin e rrjetit, burimin e DNS-së dhe rregullimin e identitetit në shënimet e vendosjes. Pikërisht këto tre fakte do të jenë tema e dështimit të ardhshëm.