Pag-access sa UNC sa mga container ng Windows: pangalan muna, pagkakakilanlan pagkatapos

Ang isang Windows container na nangangailangan ng share sa kabilang panig ng iyong tunnel ay nabigo sa dalawang magkahiwalay na paraan, at hindi pinapatunayan ng Explorer sa host ang alinman sa mga ito. May sariling network endpoint at sariling process identity ang container. Ang pangalang nalulutas sa desktop at ang session na tinatanggap doon ng file server ay naglalarawan sa desktop, hindi sa workload.

Ang Explorer sa host ay hindi ebidensya

Ang pagbubukas ng share sa host ay gumagamit ng DNS client ng host, routing table ng host at account na naka-log on sa host. Ang process ng container ay walang namamana sa mga ito nang implicit, kahit tumatakbo ang container sa parehong makina at tumatakbo rin doon ang VPN client. Ang unang hangganan ay ang network path: malulutas ba ng container ang pangalan, at makakabukas ba ito ng TCP session sa port ng SMB. Ang pangalawa ay ang identity: tinatanggap ba ng file server ang inihaharap ng container, kasama ang mga pahintulot na kailangan ng workload.

Ang pagtrato sa dalawa bilang isang problema ay nagbubunga ng pamilyar na ikot ng pagpapalawak ng firewall rules para ayusin ang talagang sagot na access denied mula sa share.

Sundin ang sariling kahilingan ng container

Ang networking ng Windows container ay pinamamahalaan ng Host Networking Service, na gumagawa ng mga endpoint na may sariling network namespace. Ang mode na pinili mo ang nagpapasya kung ang endpoint ay isinasalin, ginagawang bridge, o ikinakabit sa network na ibinabahagi sa host. Binabago ng desisyong iyon ang dalawang bagay nang sabay: kung ano ang malulutas ng container, at kung aling source address ang nakikita ng file server.

Tiyakin kung ano ang naoobserbahan ng container mismo bago baguhin ang anuman. Ang pangalang nalulutas sa labas ay maaaring mabigo sa loob, dahil ang DNS configuration ng container ay hindi iyon ng host, at ang isinaling endpoint ay maaaring magharap ng source na hindi inaasahan ng mga patakaran ng file server.

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"

Kung nabigo ang paglutas, ayusin ang DNS sa network configuration sa halip na palitan ang isang address. Ang pagpapalit ng pangalan ng IP ay maaaring magbago ng pag-uugali ng authentication at server identity, na ginagawang dalawa ang isang problema. Ang sariling patakaran ng VPN client ang susunod na dapat suriin, dahil maaaring iba ang pagtrato nito sa mga process ng host at sa trapikong nagmumula sa container.

Ang identity ay hiwalay na desisyon

Ang drive letter na naka-map ng isang interactive na user ay hindi application interface. Umiiral ito sa isang logon session, at ang process ng container ay hindi bahagi nito. Gamitin ang UNC path at bigyan ang workload ng identity na sinusuportahan ng deployment model. Kung saan sinusuportahan ito ng domain, ang group Managed Service Account (gMSA) ay nagbibigay ng managed identity sa pamamagitan ng credential specification.

Inilalarawan ng gMSA guide para sa container ng Microsoft ang credential-spec arrangement na iyon at ang mga paunang kailangan nito, kabilang ang domain membership at host na makakakuha ng credential. Ang account, ang pagkuha, ang process identity sa loob ng container at ang mga pahintulot sa share ay dapat magtugma lahat. Ang VPN login ay hindi iyon identity, at ang pagluluto ng password sa isang image para muling gawin ang session ng host user ay lumilikha ng permanenteng pagkakalantad.

Panatilihing nakikita ang bumabagsak na yugto

Ang nabigong paglutas, pagtanggi sa koneksyon at pagtanggi sa access ay nangangailangan ng magkakaibang ebidensya. Ang mga ito ay ayon sa pagkakasunod-sunod isang tanong sa DNS, isang tanong sa routing o filtering, at isang tanong sa authentication o pahintulot. Basahin ang tugon na natanggap ng container sa halip na ang pangkalahatang error ng application.

Subukan gamit ang sariling identity ng workload at subukan din ang pagtanggi.

Magplano para sa muling pagkonekta

Bumabagsak ang mga VPN path. Kapag bumalik ang tunnel, maaaring bumalik ang isang endpoint na may ibang isinaling address, at ang umiiral na SMB session ay maaaring patay nang hindi napapansin ng application. Pangasiwaan iyon sa application: muling itatag ang path at identity, subukan muli ang operasyon, at itugma ang isang file operation na may hindi alam na resulta sa halip na ipagpalagay na walang nangyari.

Itala ang network mode, ang DNS source at ang identity arrangement sa deployment notes. Ang susunod na pagbigo ay tungkol sa eksaktong tatlong katotohanang ito.