SMB-jagamine ebaõnnestub ainult VPN-i kaudu: allkiri või alavõrgu konflikt?

Kontoris töötav ja kodus aeguma minev kaardistatud ketas ei anna iseenesest peaaegu mingit kasulikku teavet. Tunnel edastab selgelt pakette, muidu ei jõuaks serverini midagi. See, mis ebaõnnestus, on ühes kolmest kihist: nimi lahendati valele aadressile, klient keeldus seanssi allkirjastamast või vana seanss elas kauem kui seda kandnud ühendus. Igal on erinev parandus ja kaks kolmest on kliendi poolel.

Kolm riket kannavad sama viga

Kettatäht ei ütle, milline kiht purunes, ja veatekst on tavaliselt piisavalt üldine, et sobida kõigile kolmele. Eristage neid kahe kiire küsimusega: kas server vastab oma IP-aadressil ja kas port 445 võtab ühenduse vastu?

Need vastused annavad otsustustabeli, mitte oletuse. Kui IP töötab ja nimi mitte, osutab see nimelahendusele. Kui mõlemad töötavad ja sisselogimine lükatakse tagasi, osutab see allkirjale. Kui mõlemad töötavad ja faililugemine jääb pärast tunnelikatkestust rippuma, osutab see aegunud seansile.

Töötage need läbi selles järjekorras, sest vale hosti lahendatud nimi muudab iga hilisema testi mõttetuks.

Lahendage nimi enne, kui jagamist puudutate

Kui server vastab oma aadressil ja jagamise nimi aegub, teeb tunnel oma tööd ja klient otsib valest kohast. Kaugjuurdepääsul selgitavad kaks põhjust suuremat osa sellest.

Esimene on aadresside kattumine. Kui kontor kasutab 192.168.70.0/24 ja kodune ruuter jagab sama vahemikku, võib hostinimi, mis lahendatakse aadressile 192.168.70.20, osutada kohalikule seadmele, mitte tunnelitagusele serverile. Windows võib seejärel saata päringu kohapeal, marsruudi tagasi lükata või lahendada selle printerile, millel juhtub see aadress olema. Parandus on ühe poole ümbernummerdamine, mitte teise marsruudi lisamine.

Teine on DNS-i ulatus. VPN-adapter ilma sisemise DNS-serverita või sellisega, mis pole tunneli kaudu kättesaadav, jätab lühikesed nimed avalikule resolverile. Lugege adapteri DNS-kirjed ja küsige sisemist nime otse enne, kui jagamist puudutate:

> 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

Kui see päring tagastab oodatud aadressi, on nimelahendus selge ja probleem on virnas kõrgemal.

Lugege allkirjanõuet mõlemas otsas

Kättesaadav server, mis keeldub igast sisselogimisest, on märk poliitikate erinevusest, mitte võrguveast. Windows võib nõuda kliendil SMB-allkirja ja server või NAS, mis ei allkirjasta, ei saa seanssi lõpule viia, ükskõik kui terve tunnel on.

Kliendi seadet saate lugeda ilma poliitikaredaktoris tuhnimata:

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

Vastav väärtus serveri poolel on serveri SMB-konfiguratsioonis ja need kaks peavad kokku langema. Ühel teatatud juhul oli kliendil nõue kohaliku poliitika kaudu sees, samal ajal kui server ei allkirjastanud üldse; selle väljalülitamine ja gpupdate /force käivitamine taastas jagamise kohe. See on diagnostiine samm põhjuse kinnitamiseks, mitte püsiv parandus.

Eelistage allkirjastamise sisselülitamist mõlemas otsas, kus server seda toetab. Jagamise toimimiseks turvaseade muutmine tuleks kirja panna varasema väärtuse ja põhjusega, et keegi ei peaks seda järgmisel auditil uuesti avastama.

Koristage aegunud seanss enne taimerite häälestamist

Jagamine, mis ripub alles pärast VPN-i langust ja taasühendamist, hoiab tavaliselt seanssi, mille server on juba kõrvaldanud. Server sulgeb jõudeolevad SMB-seansid LanmanServer\Parameters all oleva Autodisconnect taimeriga, mis on vaikimisi 15 minutit, samal ajal kui kliendil on oma SessTimeout LanmanWorkstation\Parameters all. Neist väärtustest pikem katkestus jätab kummagi poole seansist erineva ettekujutusega.

Korrake seda kindlas järjekorras, et tulemus midagi tähendaks: ühendage tunnel, avage jagamine, katkestage tunnel kaheks minutiks, taastage see ja proovige siis faili lugeda. Kui mount taastub ise, jätke taimerid rahule. Kui see ripub kuni uuesti mountimiseni, ühendage jagamine uuesti pärast tunnelitõusu, selle asemel et mountida enne selle olemasolu, ja kontrollige, kas mount-abiline proovib uuesti.

Aegade suurendamine on mõistlik viimane samm ebastabiilse lingi puhul, kuid see ravib sümptomit. Klient, mis ootab kauem seanssi, mille server on unustanud, ootab ikkagi.

Lõpetage ühe faili lugemisega läbi mounti ja seejärel tunnel veel kord katkestades ja taastades. See vastuvõtutest katab kõik kolm kihti korraga ja on ainus test, mis vastab sellele, mida kasutaja tegelikult teeb.