Достъп до UNC в контейнери на Windows: първо името, после самоличността

Контейнер на Windows, на който му трябва споделена папка от другата страна на тунела ви, се проваля по два независими начина и проводникът на хоста не доказва нито един от тях. Контейнерът има собствена мрежова крайна точка и собствена самоличност на процеса. Име, което се разрешава на работния плот, и сесия, която файловият сървър приема там, описват работния плот, а не натоварването.

Проводникът на хоста не е доказателство

Отварянето на споделената папка на хоста използва DNS клиента на хоста, маршрутната таблица на хоста и акаунта, с който е влязъл хостът. Процес на контейнера не наследява нищо от това по подразбиране, дори когато контейнерът работи на същата машина и VPN клиентът също работи там. Първата граница е мрежовият път: може ли контейнерът да разреши името и може ли да отвори TCP сесия към порта на SMB. Втората е самоличността: приема ли файловият сървър това, което контейнерът представя, с правата, които натоварването изисква.

Третирането им като един проблем създава познатия цикъл на разширяване на правилата на защитната стена, за да се поправи това, което всъщност е отговор за отказан достъп от споделената папка.

Следвайте собствената заявка на контейнера

Мрежата на контейнерите на Windows се управлява от Host Networking Service, която създава крайни точки със собствено мрежово пространство от имена. Избраният режим определя дали крайната точка се транслира, свързва чрез мост или се прикача към мрежа, споделена с хоста. Това решение променя две неща наведнъж: какво контейнерът може да разреши и какъв адрес на източника вижда файловият сървър.

Потвърдете какво наблюдава самият контейнер, преди да променяте каквото и да е. Име, което се разрешава отвън, може да се провали отвътре, защото DNS конфигурацията на контейнера не е тази на хоста, а транслирана крайна точка може да представи източник, който правилата на файловия сървър не очакват.

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"

Ако разрешаването се провали, поправете DNS в мрежовата конфигурация, вместо да подменяте адрес. Замяната на името с IP може да промени поведението на удостоверяването и самоличността на сървъра, което превръща един проблем в два. Собствената политика на VPN клиента е следващото, което трябва да проверите, защото тя може да третира различно процесите на хоста и трафика, произхождащ от контейнера.

Самоличността е отделно решение

Буква на устройство, свързана от интерактивен потребител, не е интерфейс за приложение. Тя съществува в една сесия за вход и процес на контейнера не е част от нея. Използвайте UNC пътя и дайте на натоварването самоличност, която моделът на внедряване поддържа. Където домейнът го поддържа, групов управляван сервизен акаунт (gMSA) предоставя управлявана самоличност чрез спецификация на идентификационни данни.

Ръководството на Microsoft за gMSA в контейнери описва тази схема със спецификация на идентификационни данни и нейните предпоставки, които включват членство в домейн и хост, способен да извлече идентификационните данни. Акаунтът, извличането, самоличността на процеса в контейнера и правата върху споделената папка трябва да съвпадат. Влизането през VPN не е тази самоличност, а вграждането на парола в образ, за да се възпроизведе сесията на потребителя на хоста, създава постоянна уязвимост.

Пазете проваления етап видим

Провал в разрешаването, отказ на връзка и отказ на достъп изискват различни доказателства. Те са съответно въпрос на DNS, въпрос на маршрутизация или филтриране и въпрос на удостоверяване или права. Четете отговора, който контейнерът е получил, а не общата грешка на приложението.

Тествайте със собствената самоличност на натоварването и тествайте също и отказ.

Планирайте повторното свързване

VPN пътищата падат. Когато тунелът се върне, крайната точка може да се върне с различен транслиран адрес, а съществуваща SMB сесия може да е мъртва, без приложението да забележи. Обработете това в приложението: възстановете пътя и самоличността, опитайте операцията отново и съгласувайте файлова операция с неизвестен резултат, вместо да предполагате, че нищо не се е случило.

Запишете мрежовия режим, източника на DNS и схемата на самоличност в бележките за внедряване. Именно тези три факта ще бъдат темата на следващия провал.