SMB-jako epäonnistuu vain VPN:n yli: allekirjoitus vai aliverkon törmäys?

Kartoitettu asema, joka toimii toimistossa ja aikakatkeaa kotona, ei kerro itsessään juuri mitään hyödyllistä. Tunneli kuljettaa selvästi paketteja, muuten mikään ei saavuttaisi palvelinta. Vika on yhdessä kolmesta kerroksesta: nimi ratkesi väärään osoitteeseen, asiakas kieltäytyi allekirjoittamasta istuntoa, tai vanha istunto selvisi sitä kuljettaneesta yhteydestä. Kullakin on oma korjauksensa, ja kaksi kolmesta on asiakaspäässä.

Kolme vikaa kantaa samaa virhettä

Asemakirjain ei kerro, mikä kerros hajosi, ja virheteksti on yleensä riittävän yleinen sopiakseen kaikkiin kolmeen. Erottele ne kahdella nopealla kysymyksellä: vastaako palvelin IP-osoitteellaan, ja ottaa portti 445 yhteyden vastaan?

Vastaukset tuottavat päätöstaulukon arvauksen sijaan. Jos IP toimii mutta nimi ei, kyse on nimien ratkaisusta. Jos molemmat toimivat mutta kirjautuminen hylätään, kyse on allekirjoituksesta. Jos molemmat toimivat mutta tiedoston luku jumittuu tunnelikatkon jälkeen, kyse on vanhentuneesta istunnosta.

Käy ne läpi siinä järjestyksessä, sillä väärään isäntään ratkeava nimi tekee jokaisesta myöhemmästä testistä merkityksettömän.

Ratkaise nimi ennen kuin kosket jakoon

Jos palvelin vastaa osoitteessaan ja jakonimi aikakatkeaa, tunneli tekee tehtävänsä ja asiakas etsii väärästä paikasta. Etäkäytössä kaksi syytä selittää suurimman osan tästä.

Ensimmäinen on osoitteiden päällekkäisyys. Kun toimisto käyttää 192.168.70.0/24-verkkoa ja kotireititin jakaa saman alueen, isäntänimi, joka ratkeaa osoitteeseen 192.168.70.20, voi osoittaa paikalliseen laitteeseen tunnelin takana olevan palvelimen sijaan. Windows voi silloin lähettää pyynnön paikallisesti, hylätä reitin tai ratkaista sen tulostimeen, jolla sattuu olemaan tuo osoite. Korjaus on numeroida toinen puoli uudelleen, ei lisätä uutta reittiä.

Toinen on DNS-laajuus. VPN-sovitin ilman sisäistä DNS-palvelinta tai sellaisella, joka ei ole tunnelin kautta tavoitettavissa, jättää lyhyet nimet julkiselle ratkaisijalle. Lue sovittimen DNS-merkinnät ja kysy sisäinen nimi suoraan ennen kuin kosket jakoon:

> 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

Jos kysely palauttaa odotetun osoitteen, nimien ratkaisu on selvitetty ja ongelma on pinossa ylempänä.

Lue allekirjoitusvaatimus molemmista päistä

Tavoitettavissa oleva palvelin, joka hylkää jokaisen kirjautumisen, on merkki käytäntöjen erosta eikä verkkoviasta. Windows voi vaatia SMB-allekirjoituksen asiakkaalta, eikä palvelin tai NAS, joka ei allekirjoita, voi saada istuntoa valmiiksi, oli tunneli kuinka terve tahansa.

Voit lukea asiakasasetuksen ilman käytäntöeditorin selailua:

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

Vastaava arvo palvelinpuolella on palvelimen SMB-kokoonpanossa, ja kahden on oltava yhtä mieltä. Eräässä raportoidussa tapauksessa asiakkaalla oli vaatimus päällä paikallisen käytännön kautta, kun taas palvelin ei allekirjoittanut lainkaan, ja sen pois kytkeminen sekä gpupdate /force palautti jaon välittömästi. Se on diagnostinen vaihe syyn vahvistamiseen, ei pysyvä korjaus.

Suosi allekirjoituksen kytkemistä päälle molemmissa päissä, jos palvelin tukee sitä. Turva-asetuksen muuttaminen jaon toimivuuden vuoksi tulee kirjata aiemman arvon ja syyn kanssa, jotta kenenkään ei tarvitse löytää sitä uudelleen seuraavassa auditoinnissa.

Tyhjennä vanhentunut istunto ennen aikakatkaisujen säätämistä

Jako, joka jumittuu vasta VPN:n katkettua ja yhdistettyä uudelleen, pitää yleensä istuntoa, jonka palvelin on jo hylännyt. Palvelin sulkee käyttämättömät SMB-istunnot Autodisconnect-ajastimella kohdassa LanmanServer\Parameters, joka on oletuksena 15 minuuttia, kun taas asiakkaalla on oma SessTimeout kohdassa LanmanWorkstation\Parameters. Noita arvoja pidempi katko jättää kummankin pään eri käsitykseen istunnosta.

Toista se kiinteässä järjestyksessä, jotta tuloksella on merkitystä: yhdistä tunneli, avaa jako, katkaise tunneli kahdeksi minuutiksi, palauta se ja yritä sitten lukea tiedosto. Jos liitos palautuu itsestään, jätä ajastimet rauhaan. Jos se jumittuu, kunnes liität uudelleen, yhdistä jako uudelleen tunnelin ollessa pystyssä sen sijaan että liittäisit sen ennen kuin se on olemassa, ja tarkista yrittääkö liitoksen apuri uudelleen.

Aikakatkaisujen nostaminen on kohtuullinen viimeinen vaihe epävakaalle yhteydelle, mutta se hoitaa oiretta. Asiakas, joka odottaa pidempään istuntoa, jonka palvelin on unohtanut, odottaa silti.

Lopuksi lue tiedosto liitoksen kautta ja katkaise ja palauta tunneli vielä kerran. Se hyväksymistesti kattaa kaikki kolme kerrosta kerralla, ja se on ainoa testi, joka vastaa sitä, mitä käyttäjä todella tekee.