SMB-ресурс не працює лише через VPN: підпис чи конфлікт підмереж?

Ресурс, що працює в локальній мережі, може відмовляти лише через тунель. Відокремте відмову підпису, перекривану підмережу й застарілий сеанс SMB.

Під’єднаний диск, який працює в офісі й завершується тайм-аутом удома, сам по собі майже нічого не повідомляє. Тунель явно передає пакети, інакше до сервера нічого б не доходило. Відмовив один із трьох шарів: ім’я розв’язалося в неправильну адресу, клієнт відмовився підписувати сеанс або старий сеанс пережив з’єднання, яке його несло. Кожен має власне виправлення, і два з трьох — на боці клієнта.

Три відмови носять ту саму помилку

Літера диска не каже, який шар зламався, а текст помилки зазвичай досить загальний, щоб пасувати всім трьом. Розділіть їх двома швидкими запитаннями: чи відповідає сервер за своєю IP-адресою і чи приймає порт 445 з’єднання?

Ці відповіді дають таблицю рішень замість здогаду. Якщо IP працює, а ім’я ні, це вказує на розв’язання імен. Якщо працює і те, і те, але вхід відхилено, це вказує на підпис. Якщо працює і те, і те, але читання файлу зависає після обриву тунелю, це вказує на застарілий сеанс.

SymptomLayer to inspect
IP works, hostname times outDNS or subnet overlap
TCP 445 opens, logon refusedSMB signing policy
Hangs after reconnectSession state and timers

Проходьте їх у цьому порядку, бо ім’я, що розв’язується в неправильний хост, робить будь-яку наступну перевірку безглуздою.

Розв’яжіть ім’я, перш ніж торкатися ресурсу

Якщо сервер відповідає за своєю адресою, а ім’я ресурсу завершується тайм-аутом, тунель робить свою справу, а клієнт шукає не там. Під час віддаленого доступу дві причини пояснюють більшість цього.

Перша — перекриття адрес. Коли офіс використовує 192.168.70.0/24, а домашній маршрутизатор роздає той самий діапазон, ім’я хоста, що розв’язується в 192.168.70.20, може вказувати на локальний пристрій замість сервера за тунелем. Windows тоді може надіслати запит локально, відхилити маршрут або розв’язати його в принтер, який випадково має цю адресу. Виправлення — перенумерувати один бік, а не додати ще один маршрут.

Друга — область DNS. VPN-адаптер без внутрішнього DNS-сервера або з недоступним через тунель сервером залишає короткі імена публічному резолверу. Прочитайте записи DNS адаптера й запитайте внутрішнє ім’я напряму, перш ніж торкатися ресурсу:

> 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

Якщо цей запит повертає очікувану адресу, розв’язання імен з’ясовано, а проблема вище в стеку.

Прочитайте вимогу підпису на обох боках

Доступний сервер, що відхиляє кожен вхід, — ознака неузгодженості політик, а не мережевої несправності. Windows може вимагати підпис SMB на клієнті, а сервер або NAS, що не підписує, не може завершити сеанс, хоч би яким здоровим був тунель.

Прочитати налаштування клієнта можна, не шукаючи в редакторі політик:

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

Відповідне значення на боці сервера міститься в конфігурації SMB сервера, і вони мають збігатися. В одному описаному випадку на клієнті вимогу ввімкнула локальна політика, тоді як сервер узагалі не підписував; вимкнення й запуск gpupdate /force одразу відновили ресурс. Це діагностичний крок для підтвердження причини, а не постійне рішення.

Волійте вмикати підпис на обох боках там, де сервер це підтримує. Зміну параметра безпеки заради роботи ресурсу слід записувати з попереднім значенням і причиною, щоб нікому не довелося відкривати її заново під час наступного аудиту.

Очистіть застарілий сеанс, перш ніж налаштовувати таймери

Ресурс, що зависає лише після обриву й повторного підключення VPN, зазвичай тримає сеанс, який сервер уже відкинув. Сервер закриває простоюючі сеанси SMB за таймером Autodisconnect у розділі LanmanServer\Parameters, за замовчуванням 15 хвилин, тоді як у клієнта свій SessTimeout у розділі LanmanWorkstation\Parameters. Обрив довший за ці значення залишає кожен бік з різним уявленням про сеанс.

Відтворіть це у фіксованому порядку, щоб результат щось означав: під’єднайте тунель, відкрийте ресурс, розірвіть тунель на дві хвилини, відновіть його, потім спробуйте прочитати файл. Якщо монтування відновлюється саме, не чіпайте таймери. Якщо воно висить до повторного монтування, перепід’єднайте ресурс після підняття тунелю замість того, щоб монтувати його до появи тунелю, і перевірте, чи повторює спроби помічник монтування.

Збільшення тайм-аутів — розумний останній крок для нестабільного каналу, але воно лікує симптом. Клієнт, який довше чекає на сеанс, про який сервер забув, усе одно чекає.

Завершіть читанням одного файлу через монтування, а потім ще одним обривом і відновленням тунелю. Цей приймальний тест охоплює всі три шари одразу, і це єдиний тест, що відповідає тому, що користувач робить насправді.

Схожі статті