Windows контејнер коме је потребна дељена фасцикла са друге стране вашег тунела не успева на два независна начина, а Explorer на домаћину не доказује ниједан од њих. Контејнер има своју мрежну крајњу тачку и свој идентитет процеса. Име које се разрешава на радној површини и сесија коју тамо прихвата сервер датотека описују радну површину, а не радно оптерећење.

Explorer на домаћину није доказ

Отварање дељене фасцикле на домаћину користи 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-а и уређење идентитета у белешке о распоређивању. Управо ове три чињенице биће тема следећег неуспеха.

Повезани чланци