UNC piekļuve Windows konteineros: vispirms nosaukums, pēc tam identitāte
Resursdatora Explorer nepierāda ne konteinera DNS ceļu, ne tā SMB identitāti. Pirms atļaujām pārbaudiet nosaukumu atrisināšanu un 445. portu konteinera iekšienē.
Windows konteiners, kuram nepieciešams koplietojams direktorijs tuneļa otrā pusē, neizdodas divos neatkarīgos veidos, un resursdatora Explorer nepierāda nevienu no tiem. Konteineram ir savs tīkla galapunkts un sava procesa identitāte. Nosaukums, kas tiek atrisināts darbvirsmu, un sesija, ko tur pieņem failu serveris, raksturo darbvirsmu, nevis darba slodzi.
Resursdatora Explorer nav pierādījums
Koplietojamā direktorija atvēršana resursdatorā izmanto resursdatora DNS klientu, resursdatora maršrutēšanas tabulu un kontu, ar kuru resursdatorā ir pieteikšanās. Konteinera process neko no tā netieši nemanto, pat ja konteiners darbojas tajā pašā mašīnā un VPN klients arī darbojas tur. Pirmā robeža ir tīkla ceļš: vai konteiners var atrisināt nosaukumu un vai tas var atvērt TCP sesiju uz SMB portu. Otrā ir identitāte: vai failu serveris pieņem to, ko konteiners uzrāda, ar atļaujām, kas nepieciešamas darba slodzei.
Abu uzskatīšana par vienu problēmu rada pazīstamo ciklu, kurā ugunsmūra noteikumi tiek paplašināti, lai labotu to, kas patiesībā ir koplietojamā direktorija atbilde par liegto piekļuvi.
Sekojiet paša konteinera pieprasījumam
Windows konteineru tīklu pārvalda Host Networking Service, kas veido galapunktus ar savu tīkla nosaukumtelpu. Izvēlētais režīms nosaka, vai galapunkts tiek pārtulkots, savienots tiltā vai pievienots tīklam, kas kopīgs ar resursdatoru. Šis lēmums maina divas lietas vienlaikus: ko konteiners var atrisināt un kādu avota adresi redz failu serveris.
Pirms kaut kā maiņas pārliecinieties, ko novēro pats konteiners. Nosaukums, kas tiek atrisināts ārpusē, var neizdoties iekšienē, jo konteinera DNS konfigurācija nav resursdatora konfigurācija, un pārtulkots galapunkts var uzrādīt avotu, ko failu servera noteikumi negaida.
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"
Ja atrisināšana neizdodas, labojiet DNS tīkla konfigurācijā, nevis aizstājiet adresi. Nosaukuma aizstāšana ar IP var mainīt autentifikācijas un servera identitātes uzvedību, kas vienu problēmu pārvērš divās. VPN klienta paša politika ir nākamā pārbaudāmā lieta, jo tā var atšķirīgi attiekties pret resursdatora procesiem un satiksmi, kas nāk no konteinera.
Identitāte ir atsevišķs lēmums
Interaktīva lietotāja kartētais diskdziņa burts nav lietojumprogrammas saskarne. Tas pastāv vienā pieteikšanās sesijā, un konteinera process nav tās daļa. Izmantojiet UNC ceļu un piešķiriet darba slodzei identitāti, ko atbalsta izvietošanas modelis. Kur domēns to atbalsta, grupas pārvaldītais pakalpojuma konts (gMSA) nodrošina pārvaldītu identitāti, izmantojot akreditācijas datu specifikāciju.
Microsoft konteineru gMSA pamācība apraksta šo akreditācijas datu specifikācijas izkārtojumu un tā priekšnosacījumus, tostarp domēna dalību un resursdatoru, kas spēj iegūt akreditācijas datus. Kontam, iegūšanai, procesa identitātei konteinera iekšienē un koplietojamā direktorija atļaujām visiem jāsakrīt. VPN pieteikšanās nav šī identitāte, un paroles iestrādāšana attēlā, lai atdarinātu resursdatora lietotāja sesiju, rada pastāvīgu apdraudējumu.
Turiet neizdevušos posmu redzamu
Atrisināšanas neizdošanās, savienojuma atteikums un piekļuves liegums prasa atšķirīgus pierādījumus. Tie ir attiecīgi DNS jautājums, maršrutēšanas vai filtrēšanas jautājums un autentifikācijas vai atļauju jautājums. Lasiet atbildi, ko konteiners saņēma, nevis lietojumprogrammas vispārīgo kļūdu.
Pārbaudiet ar pašas darba slodzes identitāti un pārbaudiet arī atteikumu.
Plānojiet atkārtotu savienojumu
VPN ceļi nokrīt. Kad tunelis atgriežas, galapunkts var atgriezties ar citu pārtulkotu adresi, un esošā SMB sesija var būt mirusi, lietojumprogrammai to nepamanot. Apstrādājiet to lietojumprogrammā: atjaunojiet ceļu un identitāti, mēģiniet darbību vēlreiz un saskaņojiet faila darbību ar nezināmu rezultātu, nevis pieņemiet, ka nekas nav noticis.
Pierakstiet tīkla režīmu, DNS avotu un identitātes izkārtojumu izvietošanas piezīmēs. Tieši par šiem trim faktiem būs nākamā neizdošanās.