SMB koplietošana neizdodas tikai caur VPN: paraksta vai apakštīkla konflikts?

Koplietošana, kas strādā LAN, var neizdoties tikai caur tuneli. Atdaliet paraksta noraidījumu, pārklājošos apakštīklu un novecojušu SMB sesiju.

Kartētais disks, kas strādā birojā un mājās beidzas ar taimautu, pats par sevi gandrīz nesniedz noderīgu informāciju. Tunelis acīmredzami pārsūta paketes, pretējā gadījumā nekas nesasniegtu serveri. Tas, kas neizdevās, ir vienā no trim slāņiem: vārds tika atrisināts uz nepareizu adresi, klients atteicās parakstīt sesiju, vai veca sesija pārdzīvoja savienojumu, kas to nesa. Katram ir cits labojums, un divi no trim ir klienta pusē.

Trīs kļūmes valkā vienu un to pašu kļūdu

Diska burts nenorāda, kurš slānis salūza, un kļūdas teksts parasti ir pietiekami vispārīgs, lai derētu visiem trim. Atdaliet tos ar diviem ātriem jautājumiem: vai serveris atbild uz sava IP adresi, un vai ports 445 pieņem savienojumu?

Šīs atbildes dod lēmumu tabulu, nevis minējumu. Ja IP strādā un vārds ne, tas norāda uz vārdu atrisināšanu. Ja abi strādā un pieteikšanās tiek noraidīta, tas norāda uz parakstu. Ja abi strādā un faila lasīšana uzkaras pēc tuneļa pārtraukuma, tas norāda uz novecojušu sesiju.

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

Izstrādājiet tos šajā secībā, jo vārds, kas atrisināts uz nepareizo resursdatoru, padara katru vēlāko testu bezjēdzīgu.

Atrisiniet vārdu, pirms pieskaraties koplietošanai

Ja serveris atbild uz savas adreses un koplietošanas vārds taimautē, tunelis dara savu darbu un klients meklē nepareizajā vietā. Tālvadības piekļuvē divi iemesli izskaidro lielāko daļu šī.

Pirmais ir adrešu pārklāšanās. Kad birojs izmanto 192.168.70.0/24 un mājas maršrutētājs piešķir to pašu diapazonu, resursdatora nosaukums, kas atrisināts uz 192.168.70.20, var norādīt uz vietējo ierīci, nevis uz serveri aiz tuneļa. Windows tad var nosūtīt pieprasījumu lokāli, noraidīt maršrutu vai atrisināt to uz printeri, kuram nejauši ir šī adrese. Labojums ir pārnumurēt vienu pusi, nevis pievienot vēl vienu maršrutu.

Otrais ir DNS tvērums. VPN adapteris bez iekšējā DNS servera vai ar tādu, kas nav sasniedzams caur tuneli, atstāj īsos vārdus publiskam resolverim. Izlasiet adaptera DNS ierakstus un pajautājiet iekšējo vārdu tieši, pirms pieskaraties koplietošanai:

> 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

Ja šis vaicājums atgriež gaidīto adresi, vārdu atrisināšana ir skaidra un problēma ir augstāk stekā.

Izlasiet paraksta prasību abos galos

Sasniedzams serveris, kas noraida katru pieteikšanos, ir politikas nesaskaņas pazīme, nevis tīkla kļūda. Windows var pieprasīt SMB parakstu klientā, un serveris vai NAS, kas neparaksta, nevar pabeigt sesiju, lai cik vesels būtu tunelis.

Klienta iestatījumu varat izlasīt, nemeklējot politikas redaktorā:

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

Atbilstošā vērtība servera pusē ir servera SMB konfigurācijā, un abām jāsakrīt. Vienā ziņotā gadījumā klientam prasība bija ieslēgta ar vietējo politiku, kamēr serveris nemaz neparakstīja; tās izslēgšana un gpupdate /force palaišana nekavējoties atjaunoja koplietošanu. Tas ir diagnostikas solis cēloņa apstiprināšanai, nevis pastāvīgs labojums.

Dodiet priekšroku paraksta ieslēgšanai abos galos, kur serveris to atbalsta. Drošības iestatījuma maiņa, lai koplietošana darbotos, jāreģistrē kopā ar iepriekšējo vērtību un iemeslu, lai nevienam tas nav jāatklāj no jauna nākamajā auditā.

Notīriet novecojušo sesiju pirms taimeru regulēšanas

Koplietošana, kas uzkaras tikai pēc tam, kad VPN nokrīt un atkal pieslēdzas, parasti tur sesiju, ko serveris jau ir izmetis. Serveris aizver neaktīvās SMB sesijas pēc Autodisconnect taimera sadaļā LanmanServer\Parameters, kas pēc noklusējuma ir 15 minūtes, kamēr klientam ir savs SessTimeout sadaļā LanmanWorkstation\Parameters. Pārtraukums, kas garāks par šīm vērtībām, atstāj katru galu ar atšķirīgu priekšstatu par sesiju.

Atkārtojiet to noteiktā secībā, lai rezultātam būtu jēga: pievienojiet tuneli, atveriet koplietošanu, pārtrauciet tuneli uz divām minūtēm, atjaunojiet to un pēc tam mēģiniet lasīt failu. Ja montāža atjaunojas pati, atstājiet taimerus mierā. Ja tā uzkaras, līdz veicat atkārtotu montāžu, pievienojiet koplietošanu atkārtoti pēc tam, kad tunelis ir pacēlies, tā vietā lai to montētu pirms tā pastāv, un pārbaudiet, vai montāžas palīgs mēģina vēlreiz.

Taimautu palielināšana ir saprātīgs pēdējais solis nestabilam savienojumam, taču tas ārstē simptomu. Klients, kas ilgāk gaida sesiju, ko serveris ir aizmirsis, joprojām gaida.

Pabeidziet, izlasot vienu failu caur montāžu, un pēc tam vēlreiz pārtraucot un atjaunojot tuneli. Šis pieņemšanas tests vienlaikus aptver visus trīs slāņus, un tas ir vienīgais tests, kas atbilst tam, ko lietotājs patiešām dara.

Saistītie raksti