UNC-hozzáférés Windows-tárolókban: előbb a név, aztán az identitás

Egy Windows-tároló, amelynek a bújtatás túloldalán lévő megosztásra van szüksége, két egymástól független módon hibázik, és a gazdagép Intézője egyiket sem bizonyítja. A tárolónak saját hálózati végpontja és saját folyamatidentitása van. Az asztalon feloldódó név és a fájlszerver által ott elfogadott munkamenet az asztalt írja le, nem a terhelést.

A gazdagép Intézője nem bizonyíték

A megosztás gazdagépen való megnyitása a gazdagép DNS-ügyfelét, a gazdagép forgalomirányító táblázatát és a gazdagépen bejelentkezett fiókot használja. Egy tárolófolyamat ezekből semmit sem örököl hallgatólagosan, akkor sem, ha a tároló ugyanazon a gépen fut, és a VPN-ügyfél is ott fut. Az első határ a hálózati útvonal: fel tudja-e oldani a tároló a nevet, és tud-e TCP-munkamenetet nyitni az SMB-portra. A második az identitás: elfogadja-e a fájlszerver azt, amit a tároló bemutat, azzal a jogosultsággal, amelyre a terhelésnek szüksége van.

Ha egyetlen problémaként kezeljük őket, megjelenik az ismert kör: tágítjuk a tűzfalszabályokat, hogy kijavítsuk azt, ami valójában a megosztás által adott hozzáférés-megtagadó válasz.

Kövesse a tároló saját kérését

A Windows-tárolók hálózatát a Host Networking Service kezeli, amely saját hálózati névtérrel rendelkező végpontokat hoz létre. A választott mód dönti el, hogy a végpont lefordított, áthidalt vagy a gazdagéppel megosztott hálózathoz csatolt. Ez a döntés egyszerre két dolgot változtat meg: mit tud feloldani a tároló, és milyen forrás címet lát a fájlszerver.

Mielőtt bármit módosítana, erősítse meg, mit figyel meg maga a tároló. Egy kívül feloldódó név belül meghiúsulhat, mert a tároló DNS-konfigurációja nem a gazdagépé, és egy lefordított végpont olyan forrást mutathat, amelyre a fájlszerver szabályai nem számítanak.

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"

Ha a feloldás meghiúsul, a hálózati konfigurációban javítsa a DNS-t, ne az címet cserélje le. A név IP-re cserélése megváltoztathatja a hitelesítés és a kiszolgálóidentitás viselkedését, ami egy problémát kettővé tesz. A VPN-ügyfél saját szabályzata a következő ellenőrizendő dolog, mert eltérően kezelheti a gazdagép folyamatait és a tárolóból eredő forgalmat.

Az identitás külön döntés

Az interaktív felhasználó által csatolt meghajtóbetűjel nem alkalmazásfelület. Egyetlen bejelentkezési munkamenetben létezik, és a tárolófolyamat nem része annak. Használja az UNC-útvonalat, és adjon a terhelésnek olyan identitást, amelyet az üzembe helyezési modell támogat. Ahol a tartomány támogatja, a csoportosan felügyelt szolgáltatásfiók (gMSA) felügyelt identitást biztosít hitelesítőadat-specifikáción keresztül.

A Microsoft tároló-gMSA útmutatója leírja ezt a hitelesítőadat-specifikációs elrendezést és előfeltételeit, köztük a tartománytagságot és a hitelesítő adatot lekérni képes gazdagépet. A fióknak, a lekérésnek, a tárolón belüli folyamatidentitásnak és a megosztási jogosultságoknak mind össze kell illeszkedniük. A VPN-bejelentkezés nem ez az identitás, és a jelszó képre sütése a gazdagép felhasználói munkamenetének utánzásához állandó kitettséget teremt.

Tartsa láthatóan a meghiúsuló szakaszt

A feloldási hiba, a kapcsolat elutasítása és a hozzáférés megtagadása különböző bizonyítékokat igényel. Ezek sorrendben DNS-kérdés, forgalomirányítási vagy szűrési kérdés, valamint hitelesítési vagy jogosultsági kérdés. A tároló által kapott választ olvassa, ne az alkalmazás általános hibáját.

Teszteljen a terhelés saját identitásával, és teszteljen elutasítást is.

Tervezze meg az újracsatlakozást

A VPN-útvonalak kiesnek. Amikor az alagút visszatér, a végpont más lefordított címmel térhet vissza, és egy meglévő SMB-munkamenet halott lehet anélkül, hogy az alkalmazás észrevenné. Kezelje ezt az alkalmazásban: állítsa helyre az útvonalat és az identitást, próbálja újra a műveletet, és egyeztesse az ismeretlen eredményű fájlműveletet ahelyett, hogy feltételezné, semmi sem történt.

Jegyezze fel a hálózati módot, a DNS-forrást és az identitáselrendezést az üzembe helyezési jegyzetekben. Pontosan ez a három tény lesz a következő hiba tárgya.