Кантэйнер 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 і схему ідэнтычнасці ў нататках разгортвання. Менавіта гэтыя тры факты стануць прадметам наступнага збою.

Падобныя артыкулы