Доступ к 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 и схему идентичности в заметки о развёртывании. Именно эти три факта станут предметом следующего сбоя.