SMB споделяне се проваля само през VPN: подпис или конфликт на подмрежи?

Споделяне, което работи в LAN, може да се провали само през тунела. Отделете отказ на подпис, припокриваща се подмрежа и остаряла 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 сървър или с такъв, който е недостъпен през тунела, оставя кратките имена да отиват към публичен resolver. Прочетете 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. Прекъсване, по-дълго от тези стойности, оставя всяка страна с различна представа за сесията.

Възпроизведете го в фиксиран ред, за да значи нещо резултатът: свържете тунела, отворете споделянето, прекъснете тунела за две минути, възстановете го и след това опитайте да прочетете файл. Ако монтирането се възстанови само, оставете таймерите на мира. Ако виси, докато не монтирате отново, свържете споделянето отново, след като тунелът е вдигнат, вместо да го монтирате преди да съществува, и проверете дали помощникът за монтиране опитва отново.

Увеличаването на таймаутите е разумна последна стъпка при нестабилна връзка, но лекува симптома. Клиент, който чака по-дълго сесия, която сървърът е забравил, все още чака.

Завършете, като прочетете един файл през монтирането и след това прекъснете и възстановите тунела още веднъж. Този приемен тест покрива и трите слоя наведнъж и е единственият, който отговаря на това, което потребителят всъщност прави.

Подобни статии