Az SMB megosztás csak VPN-en keresztül hibázik: aláírás vagy alhálózati ütközés?

Egy leképezett meghajtó, amely az irodában működik, otthon pedig időtúllépést ad, önmagában szinte semmi hasznosat nem árul el. Az alagút nyilvánvalóan továbbítja a csomagokat, különben semmi sem érne el a kiszolgálót. Ami meghibásodott, az három réteg egyikében van: a név rossz címre oldódott fel, a kliens megtagadta a munkamenet aláírását, vagy egy régi munkamenet túlélte az őt szállító kapcsolatot. Mindegyiknek más a javítása, és a három közül kettő kliensoldali.

Három hiba ugyanazt az üzenetet viseli

A meghajtóbetűjel nem mondja meg, melyik réteg tört el, és a hibaüzenet általában elég általános ahhoz, hogy mindháromra illjen. Két gyors kérdéssel válassza szét őket: válaszol-e a kiszolgáló az IP-címén, és fogad-e kapcsolatot a 445-es port?

Ezek a válaszok döntési táblázatot adnak találgatás helyett. Ha az IP működik, a név nem, az a névfeloldásra mutat. Ha mindkettő működik, de a bejelentkezés elutasított, az az aláírásra mutat. Ha mindkettő működik, de egy fájlolvasás egy alagútkimaradás után lefagy, az elavult munkamenetre mutat.

Ebben a sorrendben haladjon végig rajtuk, mert a rossz gazdagépre feloldódó név minden későbbi tesztet értelmetlenné tesz.

Oldja fel a nevet, mielőtt a megosztáshoz nyúl

Ha a kiszolgáló a címén válaszol, a megosztás neve pedig időtúllépést ad, az alagút teszi a dolgát, és a kliens rossz helyen keres. Távoli hozzáférésnél két ok magyarázza ennek nagy részét.

Az első a címátfedés. Ha az iroda 192.168.70.0/24 hálózatot használ, és az otthoni router ugyanezt a tartományt osztja ki, egy 192.168.70.20-ra feloldódó gazdagépnév helyi eszközre mutathat az alagút mögötti kiszolgáló helyett. A Windows ekkor helyben küldheti a kérést, elutasíthatja az útvonalat, vagy olyan nyomtatóra oldhatja fel, amelynek véletlenül ez a címe. A javítás az egyik oldal újraszámozása, nem egy újabb útvonal hozzáadása.

A második a DNS-hatókör. A belső DNS-kiszolgáló nélküli, vagy az alagúton keresztül elérhetetlen DNS-t használó VPN-adapter a rövid neveket nyilvános feloldóhoz engedi. Olvassa ki az adapter DNS-bejegyzéseit, és kérdezze le közvetlenül a belső nevet, mielőtt a megosztáshoz nyúl:

> ipconfig /all | findstr /i "DNS Servers"
> nslookup files.corp.internal
Server: 10.90.0.2
Address: 10.90.0.2
Name: files.corp.internal
Address: 10.90.0.15

Ha ez a lekérdezés a várt címet adja vissza, a névfeloldás tisztázott, és a probléma feljebb van a veremben.

Olvassa ki az aláírási követelményt mindkét oldalon

Egy elérhető kiszolgáló, amely minden bejelentkezést elutasít, házirend-eltérés jele, nem hálózati hiba. A Windows megkövetelheti az SMB-aláírást a kliensen, és egy nem aláíró kiszolgáló vagy NAS nem tudja befejezni a munkamenetet, akármilyen egészséges az alagút.

A kliensbeállítást anélkül is kiolvashatja, hogy a házirend-szerkesztőben kutatna:

> Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
RequireSecuritySignature
-------------------------
True
> Get-SmbConnection

A megfelelő kiszolgálóoldali érték a kiszolgáló SMB-konfigurációjában van, és a kettőnek egyeznie kell. Egy jelentett esetben a kliensen helyi házirend kapcsolta be a követelményt, miközben a kiszolgáló egyáltalán nem írt alá; a kikapcsolás és a gpupdate /force futtatása azonnal helyreállította a megosztást. Ez diagnosztikai lépés az ok megerősítésére, nem végleges javítás.

Lehetőleg mindkét oldalon kapcsolja be az aláírást, ahol a kiszolgáló támogatja. Egy biztonsági beállítás megváltoztatását, hogy egy megosztás működjön, az előző értékkel és az indokkal együtt kell rögzíteni, hogy senkinek ne kelljen újra felfedeznie a következő audit során.

Törölje az elavult munkamenetet, mielőtt az időzítőket hangolja

Az a megosztás, amely csak a VPN megszakadása és újracsatlakozása után fagy le, általában olyan munkamenetet tart, amelyet a kiszolgáló már eldobott. A kiszolgáló az inaktív SMB-munkameneteket a Autodisconnect időzítővel zárja a LanmanServer\Parameters alatt, amely alapértelmezésben 15 perc, míg a kliensnek saját SessTimeout-je van a LanmanWorkstation\Parameters alatt. Az ezeknél hosszabb kimaradás mindkét oldalt más elképzeléssel hagyja a munkamenetről.

Rögzített sorrendben reprodukálja, hogy az eredmény jelentsen valamit: csatlakoztassa az alagutat, nyissa meg a megosztást, szakítsa meg az alagutat két percre, állítsa helyre, majd próbáljon meg olvasni egy fájlt. Ha a csatolás magától helyreáll, hagyja békén az időzítőket. Ha addig lóg, amíg újra nem csatolja, csatlakoztassa újra a megosztást, miután az alagút áll, ahelyett hogy a létezése előtt csatolná, és ellenőrizze, hogy a csatolási segéd újrapróbálkozik-e.

Az időtúllépések emelése ésszerű utolsó lépés egy instabil kapcsolatnál, de a tünetet kezeli. Az a kliens, amely tovább vár egy munkamenetre, amelyet a kiszolgáló elfelejtett, továbbra is vár.

Fejezze be azzal, hogy egy fájlt olvas a csatoláson keresztül, majd még egyszer megszakítja és helyreállítja az alagutat. Ez az átvételi teszt egyszerre fedi le mindhárom réteget, és ez az egyetlen teszt, amely megfelel annak, amit a felhasználó valóban tesz.