Dostop UNC v vsebnikih Windows: najprej ime, nato identiteta

Vsebnik Windows, ki potrebuje skupno mapo na drugi strani vašega tunela, spodleti na dva neodvisna načina, in Raziskovalec na gostitelju ne dokazuje nobenega od njiju. Vsebnik ima svojo omrežno končno točko in svojo identiteto procesa. Ime, ki se razreši na namizju, in seja, ki jo tam sprejme strežnik datotek, opisujeta namizje, ne delovne obremenitve.

Raziskovalec na gostitelju ni dokaz

Odpiranje skupne mape na gostitelju uporablja odjemalca DNS gostitelja, usmerjevalno tabelo gostitelja in račun, s katerim je gostitelj prijavljen. Proces vsebnika ne podeduje ničesar od tega implicitno, tudi ko vsebnik teče na istem stroju in odjemalec VPN teče tam tudi. Prva meja je omrežna pot: ali lahko vsebnik razreši ime in ali lahko odpre sejo TCP na vrata SMB. Druga je identiteta: ali strežnik datotek sprejme to, kar vsebnik predstavi, s pravicami, ki jih delovna obremenitev potrebuje.

Obravnavanje obeh kot ene težave ustvari znano zanko širjenja pravil požarnega zidu, da bi popravili tisto, kar je v resnici odgovor o zavrnjenem dostopu iz skupne mape.

Sledite lastni zahtevi vsebnika

Omrežje vsebnikov Windows upravlja Host Networking Service, ki ustvarja končne točke z lastnim omrežnim imenskim prostorom. Izbrani način odloča, ali se končna točka prevede, premosti ali priključi na omrežje, deljeno z gostiteljem. Ta odločitev spremeni dve stvari hkrati: kaj lahko vsebnik razreši in kateri izvorni naslov vidi strežnik datotek.

Preden karkoli spremenite, potrdite, kaj opazuje sam vsebnik. Ime, ki se razreši zunaj, lahko znotraj spodleti, ker konfiguracija DNS vsebnika ni gostiteljeva, in prevedena končna točka lahko predstavi vir, ki ga pravila strežnika datotek ne pričakujejo.

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"

Če razreševanje spodleti, popravite DNS v omrežni konfiguraciji, namesto da zamenjate naslov. Zamenjava imena z IP lahko spremeni vedenje preverjanja pristnosti in identitete strežnika, kar eno težavo spremeni v dve. Lastna politika odjemalca VPN je naslednja stvar, ki jo je treba preveriti, ker lahko procese gostitelja in promet, ki izvira iz vsebnika, obravnava drugače.

Identiteta je ločena odločitev

Črka pogona, ki jo preslika interaktivni uporabnik, ni vmesnik aplikacije. Obstaja v eni prijavni seji in proces vsebnika ni njen del. Uporabite pot UNC in dajte delovni obremenitvi identiteto, ki jo model uvajanja podpira. Kjer to domena podpira, skupinski upravljani servisni račun (gMSA) zagotavlja upravljano identiteto prek specifikacije poverilnic.

Microsoftov vodnik za gMSA v vsebnikih opisuje to ureditev specifikacije poverilnic in njene predpogoje, med katerimi so članstvo v domeni in gostitelj, ki lahko pridobi poverilnice. Račun, pridobitev, identiteta procesa v vsebniku in pravice do skupne mape se morajo vse ujemati. Prijava VPN ni ta identiteta, in vgrajevanje gesla v podobo, da bi poustvarili sejo uporabnika gostitelja, ustvarja trajno izpostavljenost.

Ohranite neuspešno stopnjo vidno

Neuspeh razreševanja, zavrnitev povezave in zavrnitev dostopa potrebujejo različne dokaze. To so po vrsti vprašanje DNS, vprašanje usmerjanja ali filtriranja in vprašanje preverjanja pristnosti ali pravic. Preberite odgovor, ki ga je prejel vsebnik, ne splošne napake aplikacije.

Preizkusite z lastno identiteto delovne obremenitve in preizkusite tudi zavrnitev.

Načrtujte ponovno povezavo

Poti VPN odpadejo. Ko se tunel vrne, se lahko končna točka vrne z drugim prevedenim naslovom, obstoječa seja SMB pa je lahko mrtva, ne da bi aplikacija to opazila. To obravnavajte v aplikaciji: ponovno vzpostavite pot in identiteto, znova poskusite z operacijo in uskladite datotečno operacijo z neznanim izidom, namesto da bi domnevali, da se ni zgodilo nič.

Zapišite omrežni način, vir DNS in ureditev identitete v opombe o uvajanju. Prav o teh treh dejstvih bo naslednja napaka.