UNC-aliro en Windows-konteneroj: unue la nomo, poste la identeco

Windows-kontenero, kiu bezonas kunhavatan dosierujon sur la alia flanko de via tunelo, fiaskas laŭ du sendependaj manieroj, kaj la Esplorilo de la gastiganto pruvas neniun el ili. La kontenero havas sian propran retan finpunkton kaj sian propran procesan identecon. Nomo, kiu rezolviĝas sur la labortablo, kaj sesio, kiun la dosier-servilo akceptas tie, priskribas la labortablon, ne la laborŝarĝon.

La Esplorilo de la gastiganto ne estas pruvo

Malfermi la kunhavatan dosierujon sur la gastiganto uzas la DNS-klienton de la gastiganto, la enkursigan tabelon de la gastiganto kaj la konton ensalutitan tie. Kontenera procezo heredas neniun el tiuj implicite, eĉ kiam la kontenero ruliĝas sur la sama maŝino kaj la VPN-kliento ankaŭ ruliĝas tie. La unua limo estas la reta vojo: ĉu la kontenero povas rezolvi la nomon, kaj ĉu ĝi povas malfermi TCP-sesion al la SMB-pordo. La dua estas identeco: ĉu la dosier-servilo akceptas tion, kion la kontenero prezentas, kun la permesoj, kiujn la laborŝarĝo bezonas.

Trakti ilin kiel unu problemon produktas la konatan buklon de larĝigado de fajroŝirmilaj reguloj por ripari tion, kio fakte estas respondo pri rifuzita aliro de la kunhavata dosierujo.

Sekvu la propran peton de la kontenero

La retadon de Windows-konteneroj administras la Gastiganta Reta Servo, kiu kreas finpunktojn kun propra reta nomspaco. La elektita reĝimo decidas, ĉu la finpunkto estas tradukata, pontata aŭ ligata al reto kunhavata kun la gastiganto. Tiu decido ŝanĝas du aferojn samtempe: kion la kontenero povas rezolvi, kaj kiun fontan adreson la dosier-servilo vidas.

Konfirmu, kion observas la kontenero mem, antaŭ ol ŝanĝi ion ajn. Nomo, kiu rezolviĝas ekstere, povas fiaski interne, ĉar la DNS-agordo de la kontenero ne estas tiu de la gastiganto, kaj tradukita finpunkto povas prezenti fonton, kiun la reguloj de la dosier-servilo ne atendas.

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"

Se la rezolucio fiaskas, ripari DNS en la reta agordo anstataŭ anstataŭigi adreson. Anstataŭigi la nomon per IP povas ŝanĝi la konduton de aŭtentikigo kaj servila identeco, kio igas unu problemon du. La propra politiko de la VPN-kliento estas la sekva afero kontrolinda, ĉar ĝi povas trakti malsame gastigantajn procezojn kaj trafikon originantan el la kontenero.

Identeco estas aparta decido

Dosierlitero mapita de interaga uzanto ne estas aplika interfaco. Ĝi ekzistas en unu ensaluta sesio, kaj kontenera procezo ne estas parto de ĝi. Uzu la UNC-vojon kaj donu al la laborŝarĝo identecon, kiun la deplojmodelo subtenas. Kie la domajno subtenas tion, grupa administrata servokonto (gMSA) provizas administritan identecon per specifo de akreditaĵoj.

La gvidilo de Microsoft pri gMSA por konteneroj priskribas tiun aranĝon de specifo de akreditaĵoj kaj ĝiajn antaŭkondiĉojn, kiuj inkluzivas membrecon en domajno kaj gastiganton kapablan elpreni la akreditaĵon. La konto, la elpreno, la procesa identeco ene de la kontenero kaj la permesoj de la kunhavata dosierujo ĉiuj devas kongrui. VPN-ensaluto ne estas tiu identeco, kaj baki pasvorton en bildon por reprodukti la sesion de la gastiganta uzanto kreas daŭran elmeton.

Tenu la fiaskan ŝtupon videbla

Rezolucia fiasko, rifuzita konekto kaj rifuzita aliro bezonas malsamajn pruvojn. Ili estas respektive DNS-demando, enkursiga aŭ filtra demando, kaj aŭtentikiga aŭ permesa demando. Legu la respondon, kiun la kontenero ricevis, anstataŭ la ĝeneralan eraron de la aplikaĵo.

Testu per la propra identeco de la laborŝarĝo kaj testu ankaŭ rifuzon.

Planu la rekonekton

VPN-vojoj falas. Kiam la tunelo revenas, finpunkto povas reveni kun alia tradukita adreso, kaj ekzistanta SMB-sesio povas esti morta sen ke la aplikaĵo rimarku. Traktu tion en la aplikaĵo: restarigu la vojon kaj la identecon, ripetu la operacion kaj akordigu dosieran operacion kun nekonata rezulto anstataŭ supozi, ke nenio okazis.

Notu la retan reĝimon, la DNS-fonton kaj la identecan aranĝon en la deplojnotoj. Ĝuste tiuj tri faktoj estos la temo de la sekva fiasko.