Přístup UNC v kontejnerech Windows: nejprve jméno, potom identita

Kontejner Windows, který potřebuje sdílenou složku na druhé straně tunelu, selhává dvěma nezávislými způsoby a Průzkumník na hostiteli neprokazuje ani jeden z nich. Kontejner má vlastní síťový koncový bod a vlastní identitu procesu. Jméno, které se přeloží na ploše, a relace, kterou tam souborový server přijme, popisují plochu, nikoli pracovní zátěž.

Průzkumník na hostiteli není důkaz

Otevření sdílené složky na hostiteli používá DNS klienta hostitele, směrovací tabulku hostitele a účet, pod kterým je hostitel přihlášen. Proces kontejneru nic z toho implicitně nedědí, ani když kontejner běží na stejném stroji a VPN klient tam běží také. První hranicí je síťová cesta: dokáže kontejner přeložit jméno a dokáže otevřít TCP relaci na port SMB. Druhou je identita: přijímá souborový server to, co kontejner předkládá, s oprávněními, která pracovní zátěž potřebuje.

Přístup k nim jako k jednomu problému vytváří známou smyčku rozšiřování pravidel firewallu, aby se opravilo to, co je ve skutečnosti odpověď o odepřeném přístupu ze sdílené složky.

Sledujte vlastní požadavek kontejneru

Sítě kontejnerů Windows spravuje Host Networking Service, která vytváří koncové body s vlastním síťovým jmenným prostorem. Zvolený režim určuje, zda se koncový bod překládá, přemostuje, nebo připojuje k síti sdílené s hostitelem. Toto rozhodnutí mění dvě věci najednou: co kontejner dokáže přeložit a jakou zdrojovou adresu vidí souborový server.

Než cokoli změníte, ověřte, co pozoruje sám kontejner. Jméno, které se přeloží venku, může uvnitř selhat, protože konfigurace DNS kontejneru není konfigurací hostitele, a přeložený koncový bod může předložit zdroj, který pravidla souborového serveru neočekávají.

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"

Pokud překlad selže, opravte DNS v konfiguraci sítě místo nahrazení adresy. Nahrazení jména IP adresou může změnit chování ověřování a identity serveru, což z jednoho problému dělá dva. Vlastní zásada VPN klienta je další věc ke kontrole, protože může zacházet odlišně s procesy hostitele a provozem pocházejícím z kontejneru.

Identita je samostatné rozhodnutí

Písmeno jednotky namapované interaktivním uživatelem není rozhraní aplikace. Existuje v jedné přihlašovací relaci a proces kontejneru do ní nepatří. Použijte cestu UNC a dejte pracovní zátěži identitu, kterou model nasazení podporuje. Kde to doména podporuje, skupinový spravovaný servisní účet (gMSA) poskytuje spravovanou identitu prostřednictvím specifikace přihlašovacích údajů.

Microsoftova příručka ke gMSA v kontejnerech popisuje toto uspořádání specifikace přihlašovacích údajů a jeho předpoklady, mezi něž patří členství v doméně a hostitel schopný údaje načíst. Účet, načtení, identita procesu uvnitř kontejneru a oprávnění ke sdílené složce musí vše ladit. Přihlášení VPN není touto identitou a zapečení hesla do image, aby se napodobila relace uživatele hostitele, vytváří trvalé ohrožení.

Udržujte selhávající fázi viditelnou

Selhání překladu, odmítnutí spojení a odepření přístupu potřebují různé důkazy. Jsou to postupně otázka DNS, otázka směrování nebo filtrování a otázka ověřování nebo oprávnění. Čtěte odpověď, kterou kontejner dostal, nikoli obecnou chybu aplikace.

Testujte s vlastní identitou pracovní zátěže a otestujte i odepření.

Plánujte opětovné připojení

VPN cesty padají. Když se tunel vrátí, koncový bod se může vrátit s jinou přeloženou adresou a existující relace SMB může být mrtvá, aniž by si toho aplikace všimla. Řešte to v aplikaci: obnovte cestu i identitu, zkuste operaci znovu a sladěte souborovou operaci s neznámým výsledkem, místo abyste předpokládali, že se nic nestalo.

Zapište síťový režim, zdroj DNS a uspořádání identity do poznámek k nasazení. Právě o těchto třech faktech bude příští selhání.