Доступ к 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. Обрыв дольше этих значений оставляет каждую сторону с разным представлением о сеансе.

Воспроизведите это в фиксированном порядке, чтобы результат что-то значил: подключите туннель, откройте ресурс, разорвите туннель на две минуты, восстановите его, затем попробуйте прочитать файл. Если монтирование восстанавливается само, не трогайте таймеры. Если оно висит до повторного монтирования, переподключите ресурс после поднятия туннеля вместо того, чтобы монтировать его до появления туннеля, и проверьте, повторяет ли попытки помощник монтирования.

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

Завершите чтением одного файла через монтирование, а затем ещё одним обрывом и восстановлением туннеля. Этот приёмочный тест охватывает все три слоя сразу, и это единственный тест, который соответствует тому, что пользователь делает на самом деле.

Похожие статьи