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. Абрыў даўжэйшы за гэтыя значэнні пакідае кожны бок з розным уяўленнем пра сесію.

Аднавіце гэта ў фіксаваным парадку, каб вынік нешта значыў: падключыце тунель, адкрыйце рэсурс, разарвіце тунель на дзве хвіліны, аднавіце яго, потым паспрабуйце прачытаць файл. Калі мантаванне аднаўляецца само, не чапайце таймеры. Калі яно вісіць да паўторнага мантавання, перападключыце рэсурс пасля ўзняцця тунеля замест таго, каб мантаваць яго да з’яўлення тунеля, і праверце, ці паўтарае спробы памочнік мантавання.

Павелічэнне тайм-аўтаў — разумны апошні крок для нестабільнага канала, але яно лечыць сімптом. Кліент, які даўжэй чакае сесію, пра якую сервер забыў, усё адно чакае.

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

Падобныя артыкулы