UNC пристап во Windows контејнери: прво името, потоа идентитетот

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 и уредувањето на идентитетот во белешките за распоредување. Токму овие три факти ќе бидат тема на следниот неуспех.