SMB-kunhavigo malsukcesas nur per VPN: subskribo aŭ subreta konflikto?
Kunhavigo, kiu funkcias en la loka reto, povas malsukcesi nur tra la tunelo. Apartigu subskriban malakcepton, interkovrantan subreton kaj malnovan SMB-sesion.
Mapita disko, kiu funkcias en la oficejo kaj finiĝas per tempolimo hejme, preskaŭ tute ne donas utilan informon per si mem. La tunelo evidente transportas pakaĵojn, alie nenio atingus la servilon. Kio malsukcesis, estas en unu el tri tavoloj: la nomo solviĝis al la malĝusta adreso, la kliento rifuzis subskribi la sesion, aŭ malnova sesio postvivis la konekton, kiu portis ĝin. Ĉiu havas alian riparon, kaj du el la tri estas ĉe la klienta flanko.
Tri paneoj portas la saman eraron
La diska litero ne diras, kiu tavolo rompiĝis, kaj la erarteksto kutime estas sufiĉe ĝenerala por konveni al ĉiuj tri. Apartigu ilin per du rapidaj demandoj: ĉu la servilo respondas ĉe sia IP-adreso, kaj ĉu la pordo 445 akceptas konekton?
Tiuj respondoj produktas decidtabelon anstataŭ konjekton. Se IP funkcias kaj la nomo ne, tio indikas nomsolvadon. Se ambaŭ funkcias kaj la ensaluto estas rifuzata, tio indikas subskribon. Se ambaŭ funkcias kaj legado de dosiero haltas post interrompo de la tunelo, tio indikas malnovan sesion.
| Symptom | Layer to inspect |
|---|---|
| IP works, hostname times out | DNS or subnet overlap |
| TCP 445 opens, logon refused | SMB signing policy |
| Hangs after reconnect | Session state and timers |
Prilaboru ilin en tiu ordo, ĉar nomo solvita al la malĝusta gastiganto igas ĉiun postan teston senintenca.
Solvu la nomon antaŭ ol tuŝi la kunhavigon
Se la servilo respondas ĉe sia adreso kaj la kunhaviga nomo finiĝas per tempolimo, la tunelo faras sian taskon kaj la kliento serĉas en la malĝusta loko. Ĉe fora aliro, du kaŭzoj klarigas la plejparton de tio.
La unua estas adresinterkovro. Kiam la oficejo uzas 192.168.70.0/24 kaj la hejma kurserpilo disdonas la saman gamon, gastigantnomo solvita al 192.168.70.20 povas montri al loka aparato anstataŭ al la servilo malantaŭ la tunelo. Windows tiam povas sendi la peton loke, rifuzi la itineron, aŭ solvi ĝin al printilo, kiu hazarde havas tiun adreson. La riparo estas renumeri unu flankon, ne aldoni alian itineron.
La dua estas la DNS-amplitudo. VPN-adaptilo sen interna DNS-servilo, aŭ kun tiu, kiu ne atingeblas tra la tunelo, lasas mallongajn nomojn iri al publika solvilo. Legu la DNS-riktalojn de la adaptilo kaj demandu la internan nomon rekte antaŭ ol tuŝi la kunhavigon:
> 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.15Se tiu demando redonas la atendatan adreson, la nomsolvado estas klarigita kaj la problemo estas pli supre en la stako.
Legu la subskriban postulon ĉe ambaŭ finoj
Atingebla servilo, kiu rifuzas ĉiun ensaluton, estas signo de malakordo de politikoj, ne de retpaneo. Windows povas postuli SMB-subskribon ĉe la kliento, kaj servilo aŭ NAS, kiu ne subskribas, ne povas fini la sesion, kiom ajn sana estas la tunelo.
Vi povas legi la klientan agordon sen traserĉi la politikan redaktilon:
> Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
RequireSecuritySignature
-------------------------
True
> Get-SmbConnectionLa responda valoro ĉe la servila flanko troviĝas en la SMB-agordo de la servilo, kaj ambaŭ devas kongrui. En unu raportita kazo la kliento havis la postulon ŝaltita per loka politiko, dum la servilo tute ne subskribis; malŝalti ĝin kaj ruli gpupdate /force tuj restarigis la kunhavigon. Tio estas diagnoza paŝo por konfirmi la kaŭzon, ne daŭra riparo.
Preferu ŝalti subskribon ĉe ambaŭ finoj, kie la servilo subtenas ĝin. Ŝanĝo de sekureca agordo por igi kunhavigon funkcii devus esti registrita kun sia antaŭa valoro kaj la kialo, por ke neniu devu remalkovri ĝin ĉe la sekva revizio.
Forigu la malnovan sesion antaŭ ol agordi la tempomezurilojn
Kunhavigo, kiu haltas nur post kiam la VPN falas kaj rekonektiĝas, kutime tenas sesion, kiun la servilo jam forĵetis. La servilo fermas neaktivajn SMB-sesiojn laŭ la tempomezurilo Autodisconnect sub LanmanServer\Parameters, kiu defaŭlte estas 15 minutoj, dum la kliento havas sian propran SessTimeout sub LanmanWorkstation\Parameters. Interrompo pli longa ol tiuj valoroj lasas ĉiun finon kun malsama imago pri la sesio.
Ripetu ĝin en fiksa ordo, por ke la rezulto signifu ion: konektu la tunelon, malfermu la kunhavigon, interrompu la tunelon dum du minutoj, restarigu ĝin, kaj poste provu legi dosieron. Se la muntado mem resaniĝas, lasu la tempomezurilojn trankvile. Se ĝi haltas ĝis vi remuntas, rekonektu la kunhavigon post kiam la tunelo staras anstataŭ munti ĝin antaŭ ol ĝi ekzistas, kaj kontrolu, ĉu la muntada helpanto reprovas.
Altigi tempolimojn estas racia lasta paŝo por malstabila ligo, sed ĝi traktas la simptomon. Kliento, kiu atendas pli longe sesion, kiun la servilo forgesis, ankoraŭ atendas.
Finu per legado de unu dosiero tra la muntado, poste interrompu kaj restarigu la tunelon ankoraŭ unufoje. Tiu akcepta testo kovras ĉiujn tri tavolojn samtempe, kaj ĝi estas la sola testo, kiu kongruas kun tio, kion la uzanto efektive faras.