Доступ до 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 і схему ідентичності в нотатках про розгортання. Саме ці три факти стануть предметом наступного збою.