UNC juurdepääs Windowsi konteinerites: enne nimi, siis identiteet

Windowsi konteiner, mis vajab sinu tunnelist teisel pool asuvat jagatud kausta, ebaõnnestub kahel sõltumatul viisil ja hosti Explorer ei tõesta kumbagi neist. Konteineril on oma võrgu lõpp-punkt ja oma protsessi identiteet. Nimi, mis töölaual laheneb, ja seanss, mille failiserver seal vastu võtab, kirjeldavad töölauda, mitte töökoormust.

Hosti Explorer ei ole tõestus

Jagatud kausta avamine hostil kasutab hosti DNS-klienti, hosti marsruutimistabelit ja hostile sisse logitud kontot. Konteineri protsess ei päri neist midagi vaikimisi, isegi kui konteiner töötab samas masinas ja VPN-klient töötab seal samuti. Esimene piir on võrgutee: kas konteiner suudab nime lahutada ja kas ta suudab avada TCP-seansi SMB pordile. Teine on identiteet: kas failiserver võtab vastu selle, mida konteiner esitab, õigustega, mida töökoormus vajab.

Nende käsitlemine ühe probleemina tekitab tuntud ahela, kus tulemüüri reegleid laiendatakse, et parandada seda, mis on tegelikult jagatud kaustalt tulnud juurdepääsu keelamise vastus.

Jälgige konteineri enda päringut

Windowsi konteinerite võrku haldab Host Networking Service, mis loob lõpp-punktid oma võrgu nimeruumiga. Valitud režiim otsustab, kas lõpp-punkt tõlgitakse, sillatakse või ühendatakse hostiga jagatud võrku. See otsus muudab kahte asja korraga: mida konteiner suudab lahutada ja millist lähteaadressi failiserver näeb.

Enne millegi muutmist kinnitage, mida konteiner ise täheldab. Väljaspool lahenev nimi võib sees ebaõnnestuda, sest konteineri DNS-konfiguratsioon ei ole hosti oma, ja tõlgitud lõpp-punkt võib esitada allikat, mida failiserveri reeglid ei oota.

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"

Kui lahutamine ebaõnnestub, parandage DNS võrgu konfiguratsioonis, mitte ärge asendage aadressi. Nime IP-ga asendamine võib muuta autentimise ja serveri identiteedi käitumist, mis muudab ühe probleemi kaheks. VPN-kliendi enda poliitika on järgmine asi, mida kontrollida, sest see võib kohelda hosti protsesse ja konteinerist lähtuvat liiklust erinevalt.

Identiteet on eraldi otsus

Interaktiivse kasutaja kaardistatud draivi täht ei ole rakenduse liides. See eksisteerib ühes sisselogimisseansis ja konteineri protsess ei ole selle osa. Kasutage UNC-teed ja andke töökoormusele identiteet, mida juurutamismudel toetab. Kui domeen seda toetab, pakub grupi hallatav teenusekonto (gMSA) hallatud identiteeti volituste spetsifikatsiooni kaudu.

Microsofti konteineri-gMSA juhend kirjeldab seda volituste spetsifikatsiooni korraldust ja selle eeldusi, mille hulka kuuluvad domeeniliikmelisus ja host, mis suudab volituse hankida. Konto, hankimine, konteinerisisene protsessi identiteet ja jagatud kausta õigused peavad kõik kokku sobima. VPN-sisselogimine ei ole see identiteet, ja parooli kujutisse sisse küpsetamine hosti kasutaja seansi taasesitamiseks loob püsiva riski.

Hoidke ebaõnnestuv etapp nähtavana

Lahutamise ebaõnnestumine, ühenduse keeldumine ja juurdepääsu keeldumine vajavad erinevaid tõendeid. Need on vastavalt DNS-i küsimus, marsruutimise või filtreerimise küsimus ning autentimise või õiguste küsimus. Lugege vastust, mille konteiner sai, mitte rakenduse üldist viga.

Testige töökoormuse enda identiteediga ja testige ka keeldumist.

Planeerige uuesti ühendamine

VPN-teed katkevad. Kui tunnel naaseb, võib lõpp-punkt naasta teise tõlgitud aadressiga ja olemasolev SMB-seanss võib olla surnud, ilma et rakendus seda märkaks. Käsitlege seda rakenduses: taastage tee ja identiteet, proovige toimingut uuesti ning sobitage failitoimingut tundmatu tulemusega, selle asemel et eeldada, et midagi ei juhtunud.

Märkige võrgurežiim, DNS-i allikas ja identiteedi korraldus juurutamismärkmetesse. Just need kolm fakti on järgmise ebaõnnestumise teema.