Udział SMB zawodzi tylko przez VPN: podpisywanie czy konflikt podsieci?

Zmapowany dysk, który działa w biurze, a w domu kończy się przekroczeniem limitu czasu, sam w sobie nie mówi prawie nic przydatnego. Tunel najwyraźniej przenosi pakiety, inaczej nic nie dotarłoby do serwera. To, co zawiodło, leży w jednej z trzech warstw: nazwa została rozwiązana na zły adres, klient odmówił podpisania sesji albo stara sesja przetrwała połączenie, które ją niosło. Każda ma inną naprawę, a dwie z trzech są po stronie klienta.

Trzy awarie noszą ten sam błąd

Litera dysku nie mówi, która warstwa padła, a treść błędu jest zwykle dość ogólna, by pasować do wszystkich trzech. Rozdziel je dwoma szybkimi pytaniami: czy serwer odpowiada pod swoim adresem IP i czy port 445 przyjmuje połączenie?

Te odpowiedzi dają tabelę decyzyjną zamiast domysłu. Jeśli IP działa, a nazwa nie, wskazuje to na rozwiązywanie nazw. Jeśli oba działają, a logowanie jest odrzucane, wskazuje to na podpisywanie. Jeśli oba działają, a odczyt pliku zawiesza się po awarii tunelu, wskazuje to na nieaktualną sesję.

Przechodź je w tej kolejności, bo nazwa wskazująca niewłaściwy host czyni każdy późniejszy test bez znaczenia.

Rozwiąż nazwę, zanim dotkniesz udziału

Jeśli serwer odpowiada pod swoim adresem, a nazwa udziału kończy się przekroczeniem limitu czasu, tunel robi swoje, a klient szuka w złym miejscu. W dostępie zdalnym dwie przyczyny wyjaśniają większość takich przypadków.

Pierwsza to nakładanie się adresów. Gdy biuro używa 192.168.70.0/24, a domowy router przydziela ten sam zakres, nazwa hosta rozwiązująca się na 192.168.70.20 może wskazywać urządzenie lokalne zamiast serwera za tunelem. Windows może wtedy wysłać żądanie lokalnie, odrzucić trasę albo rozwiązać je na drukarkę, która przypadkiem ma ten adres. Naprawą jest przenumerowanie jednej strony, nie dodanie kolejnej trasy.

Druga to zakres DNS. Karta VPN bez wewnętrznego serwera DNS lub z serwerem nieosiągalnym przez tunel pozostawia krótkie nazwy publicznemu resolverowi. Odczytaj wpisy DNS karty i zapytaj bezpośrednio o nazwę wewnętrzną, zanim dotkniesz udziału:

> 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

Jeśli to zapytanie zwróci oczekiwany adres, rozwiązywanie nazw jest ustalone, a problem leży wyżej w stosie.

Odczytaj wymóg podpisywania po obu stronach

Osiągalny serwer, który odrzuca każde logowanie, to oznaka niezgodności zasad, a nie usterki sieci. Windows może wymagać podpisywania SMB po stronie klienta, a serwer lub NAS, który nie podpisuje, nie może ukończyć sesji, niezależnie od kondycji tunelu.

Ustawienie klienta możesz odczytać bez przeszukiwania edytora zasad:

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

Odpowiednia wartość po stronie serwera znajduje się w konfiguracji SMB serwera i obie muszą się zgadzać. W jednym zgłoszonym przypadku klient miał wymóg włączony przez zasady lokalne, podczas gdy serwer wcale nie podpisywał; wyłączenie go i uruchomienie gpupdate /force natychmiast przywróciło udział. To krok diagnostyczny potwierdzający przyczynę, a nie trwała naprawa.

Preferuj włączanie podpisywania po obu stronach, tam gdzie serwer to obsługuje. Zmianę ustawienia bezpieczeństwa, aby udział działał, należy zapisać wraz z poprzednią wartością i przyczyną, żeby nikt nie musiał odkrywać jej ponownie podczas następnego audytu.

Wyczyść nieaktualną sesję, zanim dostroisz liczniki

Udział, który zawiesza się dopiero po zerwaniu i ponownym połączeniu VPN, zwykle trzyma sesję, którą serwer już odrzucił. Serwer zamyka bezczynne sesje SMB według licznika Autodisconnect w LanmanServer\Parameters, domyślnie 15 minut, podczas gdy klient ma własny SessTimeout w LanmanWorkstation\Parameters. Awaria dłuższa niż te wartości zostawia każdą stronę z innym wyobrażeniem o sesji.

Odtwórz to w ustalonej kolejności, żeby wynik coś znaczył: połącz tunel, otwórz udział, zerwij tunel na dwie minuty, przywróć go, a potem spróbuj odczytać plik. Jeśli montowanie wraca samo, zostaw liczniki w spokoju. Jeśli wisi do ponownego zamontowania, połącz udział ponownie po podniesieniu tunelu zamiast montować go, zanim istnieje, i sprawdź, czy pomocnik montowania ponawia próbę.

Podnoszenie limitów czasu to rozsądny ostatni krok przy niestabilnym łączu, ale leczy objaw. Klient, który dłużej czeka na sesję, o której serwer zapomniał, nadal czeka.

Zakończ odczytem jednego pliku przez montowanie, a potem jeszcze raz zerwij i przywróć tunel. Ten test akceptacyjny obejmuje wszystkie trzy warstwy naraz i jest jedynym, który odpowiada temu, co użytkownik naprawdę robi.