Acces UNC în containerele Windows: mai întâi numele, apoi identitatea

Un container Windows care are nevoie de o partajare de cealaltă parte a tunelului eșuează în două moduri independente, iar Explorer-ul de pe gazdă nu dovedește niciunul dintre ele. Containerul are propriul punct de capăt de rețea și propria identitate de proces. Un nume care se rezolvă pe desktop și o sesiune acceptată acolo de serverul de fișiere descriu desktopul, nu sarcina de lucru.

Explorer-ul de pe gazdă nu este o dovadă

Deschiderea partajării pe gazdă folosește clientul DNS al gazdei, tabela de rutare a gazdei și contul cu care gazda este conectată. Un proces de container nu moștenește nimic din acestea implicit, chiar și când containerul rulează pe aceeași mașină și clientul VPN rulează și el acolo. Prima graniță este calea de rețea: poate containerul să rezolve numele și poate să deschidă o sesiune TCP către portul SMB. A doua este identitatea: acceptă serverul de fișiere ce prezintă containerul, cu permisiunile de care are nevoie sarcina de lucru.

Tratarea lor ca o singură problemă produce binecunoscutul ciclu de lărgire a regulilor de firewall pentru a repara ceea ce este de fapt un răspuns de acces refuzat din partea partajării.

Urmați cererea containerului însuși

Rețeaua containerelor Windows este administrată de Host Networking Service, care creează puncte de capăt cu propriul spațiu de nume de rețea. Modul ales decide dacă punctul de capăt este tradus, punte sau conectat la o rețea partajată cu gazda. Această decizie schimbă două lucruri simultan: ce poate rezolva containerul și ce adresă sursă vede serverul de fișiere.

Confirmați ce observă containerul însuși înainte de a schimba ceva. Un nume care se rezolvă afară poate eșua înăuntru, pentru că configurația DNS a containerului nu este cea a gazdei, iar un punct de capăt tradus poate prezenta o sursă pe care regulile serverului de fișiere nu o așteaptă.

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"

Dacă rezolvarea eșuează, corectați DNS-ul în configurația de rețea în loc să înlocuiți o adresă. Înlocuirea numelui cu un IP poate schimba comportamentul autentificării și al identității serverului, ceea ce transformă o problemă în două. Politica proprie a clientului VPN este următorul lucru de verificat, pentru că poate trata diferit procesele gazdei și traficul care provine din container.

Identitatea este o decizie separată

O literă de unitate mapată de un utilizator interactiv nu este o interfață de aplicație. Ea există într-o singură sesiune de conectare, iar un proces de container nu face parte din ea. Folosiți calea UNC și dați sarcinii de lucru o identitate pe care modelul de implementare o susține. Acolo unde domeniul o susține, un cont de serviciu administrat de grup (gMSA) oferă o identitate administrată printr-o specificație de acreditări.

Ghidul Microsoft pentru gMSA în containere descrie acest aranjament al specificației de acreditări și condițiile sale, care includ apartenența la domeniu și o gazdă capabilă să recupereze acreditarea. Contul, recuperarea, identitatea procesului din container și permisiunile partajării trebuie să se alinieze toate. O conectare VPN nu este acea identitate, iar includerea unei parole într-o imagine pentru a reproduce sesiunea utilizatorului gazdei creează o expunere permanentă.

Păstrați vizibilă etapa care eșuează

O eșuare a rezolvării, un refuz de conexiune și un refuz de acces au nevoie de dovezi diferite. Sunt respectiv o întrebare de DNS, o întrebare de rutare sau filtrare și o întrebare de autentificare sau permisiuni. Citiți răspunsul primit de container, nu eroarea generică a aplicației.

Testați cu identitatea proprie a sarcinii de lucru și testați și un refuz.

Planificați reconectarea

Căile VPN cad. Când tunelul revine, un punct de capăt poate reveni cu o altă adresă tradusă, iar o sesiune SMB existentă poate fi moartă fără ca aplicația să observe. Gestionați asta în aplicație: restabiliți calea și identitatea, reîncercați operația și reconciliați o operație de fișier cu rezultat necunoscut în loc să presupuneți că nu s-a întâmplat nimic.

Notați modul de rețea, sursa DNS și aranjamentul identității în notele de implementare. Exact aceste trei fapte vor fi subiectul următoarei erori.