Partajările de rețea nu apar într-un VPN? Descoperirea se oprește

Partajarea se deschide când tastați calea, iar browserul de rețea nu arată nimic. Această combinație este obișnuită printr-un tunel și de obicei nu este o defecțiune. Descoperirea întreabă segmentul local; accesibilitatea întreabă o singură gazdă. Un tunel rutat transportă a doua și nu prima.

Descoperirea și accesibilitatea sunt separate

O listă de navigare este produsă de protocoale care anunță servicii unui segment local și ascultă acele anunțuri. Deschiderea unei partajări după nume este o conexiune directă la o singură gazdă. Prima are nevoie de un domeniu de difuzare sau multicast; a doua are nevoie de o rută și un port.

Printr-un tunel, a doua poate funcționa perfect în timp ce prima returnează o fereastră goală. Dacă tratați fereastra goală drept defecțiune, veți căuta un tunel stricat care își face treaba.

De ce lista de navigare rămâne goală

Windows a retras serviciul Computer Browser și a dezactivat SMB versiunea 1 implicit, ceea ce a eliminat mecanismul din spatele vechiului Network Neighborhood. Înlocuitori precum WS-Discovery, SSDP și DNS multicast vizează grupuri de difuzare sau multicast care există doar pe o legătură locală. Un tunel punct-la-punct nu are o astfel de legătură, iar routerele nu transmit acele grupuri implicit. Fiecare gazdă poate fi accesibilă, iar lista poate rămâne goală.

Unele programe adaugă propriul asistent de descoperire. Când acel asistent funcționează, este o caracteristică a programului, nu o proprietate a tunelului.

Folosiți nume explicite, apoi confirmați accesul

O cale UNC, o unitate mapată sau o conexiune Finder la o adresă SMB funcționează prin tunel odată ce numele se rezolvă și portul este deschis. Rezolvarea poate veni de la DNS, de la un sufix de căutare furnizat de VPN sau de la o intrare hosts gestionată central. Într-un domeniu, o interogare de director poate lista obiecte de calculator, iar acea listă este de obicei cel mai apropiat substitut pentru o vizualizare de navigare într-o rețea rutată. O scanare de porturi a prefixelor cunoscute este acceptabilă doar în rețele pe care le administrați sau pentru care sunteți autorizat explicit să testați.

O gazdă care răspunde nu promite că partajarea se va deschide. Un NAS poate avea o listă de permisiuni limitată la propria subrețea, care respinge adresele din pool-ul VPN. Regula de firewall a unui server de fișiere poate numi doar subrețeaua locală. Contul pe care îl furnizați pentru partajare poate fi un cont local care nu a fost niciodată creat pe acel server, iar conectarea prin VPN nu îl creează.

Unele programe corporative blochează deliberat traficul local și traficul mașinilor virtuale cât timp tunelul este activ. Acel acces lipsă este politică, iar corectarea aparține administratorului, nu tabelului de rutare al programului.

O ordine de diagnosticare care merită repetată

Parcurgeți straturile în ordine: ajungeți la adresă, rezolvați numele, deschideți portul 445, autentificați-vă, apoi citiți permisiunile partajării. Fiecare răspuns este separat, iar sărirea înainte produce o concluzie greșită și încrezătoare. Abia după ce toate trec merită investigată descoperirea.

nslookup fileserver.example.com
nc -vz fileserver.example.com 445
smbclient -L //fileserver.example.com -U EXAMPLE/jdoe

Lăsați o notă cu numele serverului, calea partajării, adresa la care s-a rezolvat și contul care a funcționat. Dacă lista de navigare se completează mai târziu după o repornire a serviciului, tratați asta ca o ciudățenie a descoperirii și nu ca dovadă că ruta anterioară era greșită. Nota este ce îi permite următoarei persoane să sară peste fereastra goală.