UNC-toegang in Windows-containers: eerst de naam, dan de identiteit
Verkenner op de host bewijst noch het DNS-pad van de container noch zijn SMB-identiteit. Controleer naamresolutie en poort 445 in de container voordat u naar rechten kijkt.
Een Windows-container die een share aan de andere kant van uw tunnel nodig heeft, faalt op twee onafhankelijke manieren, en Verkenner op de host bewijst geen van beide. De container heeft zijn eigen netwerkeindpunt en zijn eigen procesidentiteit. Een naam die op de desktop wordt opgelost en een sessie die de fileserver daar accepteert, beschrijven de desktop, niet de workload.
Verkenner op de host is geen bewijs
De share op de host openen gebruikt de DNS-client van de host, de routingtabel van de host en het account waarmee op de host is ingelogd. Een containerproces erft daar niets van impliciet, ook niet wanneer de container op dezelfde machine draait en de VPN-client daar ook draait. De eerste grens is het netwerkpad: kan de container de naam oplossen, en kan hij een TCP-sessie naar de SMB-poort openen. De tweede is identiteit: accepteert de fileserver wat de container presenteert, met de rechten die de workload nodig heeft.
Ze als één probleem behandelen levert de bekende lus op van firewallregels verruimen om te repareren wat in werkelijkheid een antwoord over geweigerde toegang van de share is.
Volg het verzoek van de container zelf
Netwerken voor Windows-containers wordt beheerd door de Host Networking Service, die eindpunten met een eigen netwerknaamruimte maakt. De modus die u koos bepaalt of het eindpunt wordt vertaald, overbrugd of aan een netwerk gekoppeld dat met de host wordt gedeeld. Die beslissing verandert twee dingen tegelijk: wat de container kan oplossen, en welk bronadres de fileserver ziet.
Bevestig wat de container zelf waarneemt voordat u iets wijzigt. Een naam die buiten wordt opgelost kan binnen falen, omdat de DNS-configuratie van de container niet die van de host is, en een vertaald eindpunt kan een bron presenteren die de regels van de fileserver niet verwachten.
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"
Als de resolutie faalt, repareer dan DNS in de netwerkconfiguratie in plaats van een adres te vervangen. De naam door een IP vervangen kan het gedrag van authenticatie en serveridentiteit veranderen, wat één probleem twee maakt. Het eigen beleid van de VPN-client is het volgende dat u moet controleren, omdat het hostprocessen en verkeer dat uit de container komt anders kan behandelen.
Identiteit is een aparte beslissing
Een stationsletter die door een interactieve gebruiker wordt toegewezen is geen applicatie-interface. Hij bestaat in één aanmeldingssessie, en een containerproces maakt daar geen deel van uit. Gebruik het UNC-pad en geef de workload een identiteit die het implementatiemodel ondersteunt. Waar het domein dat ondersteunt, levert een groepsbeheerd serviceaccount (gMSA) een beheerde identiteit via een referentiespecificatie.
De gMSA-handleiding voor containers van Microsoft beschrijft die opzet met referentiespecificatie en de voorwaarden, waaronder domeinlidmaatschap en een host die de referentie kan ophalen. Het account, het ophalen, de procesidentiteit in de container en de rechten op de share moeten allemaal kloppen. Een VPN-aanmelding is die identiteit niet, en een wachtwoord in een image bakken om de sessie van de hostgebruiker na te bootsen, maakt een blijvende blootstelling.
Houd de falende fase zichtbaar
Een mislukte resolutie, een geweigerde verbinding en een geweigerde toegang vragen verschillend bewijs. Het zijn achtereenvolgens een DNS-vraag, een routing- of filtervraag en een authenticatie- of rechtenvraag. Lees het antwoord dat de container kreeg, in plaats van de algemene fout van de applicatie.
Test met de eigen identiteit van de workload en test ook een weigering.
Plan voor het opnieuw verbinden
VPN-paden vallen weg. Wanneer de tunnel terugkomt, kan een eindpunt terugkomen met een ander vertaald adres, en een bestaande SMB-sessie kan dood zijn zonder dat de applicatie het merkt. Behandel dat in de applicatie: herstel het pad en de identiteit, probeer de bewerking opnieuw en verzoen een bestandsbewerking met een onbekend resultaat in plaats van aan te nemen dat er niets is gebeurd.
Leg de netwerkmodus, de DNS-bron en de identiteitsopzet vast in de implementatienotities. Juist die drie feiten zijn waar de volgende fout over zal gaan.