Unitate mapată printr-un VPN între locații: DNS, SMB și calea UNC

Pagina Rețea din Explorer afișează dispozitivele care s-au anunțat în segmentul local, iar un tunel rutat nu transportă niciunul dintre aceste anunțuri. De aceea un server poate fi perfect accesibil în timp ce fereastra din fața utilizatorului rămâne goală. O cale UNC cu nume nu depinde deloc de descoperire, iar soluția este să facem numele să se rezolve și portul să răspundă. Fereastra goală este un simptom al stratului greșit, nu al unei partajări defecte.

Descoperirea nu este același lucru cu accesibilitatea

Windows descoperă mașinile din apropiere prin protocoale concepute pentru un domeniu de difuzare, apoi prezintă ce a găsit ca listă de confort. Nimic din acea listă nu este necesar pentru accesul la fișiere prin SMB. Un client care cunoaște numele serverului și atinge TCP 445 va deschide partajarea, indiferent dacă mașina apare vreodată în Rețea.

Cele două straturi eșuează independent, de aceea "nu-l văd" și "nu-l pot deschide" merită teste diferite. Privirea listei spune ceva despre descoperire; deschiderea căii spune ceva despre serviciu.

Numiți serverul înainte de a mapa partajarea

Publicați serverul de fișiere în DNS cu adresa pe care o are dincolo și îndreptați locația clientului spre un resolver care poate răspunde pentru acea zonă. Un nume complet calificat evită dependența de o listă locală de sufixe de căutare, care este motivul obișnuit pentru care un nume scurt funcționează într-o locație și eșuează în alta.

Dacă mediul folosește Active Directory, rezolvarea numelor face parte și din autentificare: clientul trebuie să atingă un controler de domeniu pentru Kerberos, iar un ceas prea desincronizat va face schimbul de bilete să eșueze. Aceasta este o problemă diferită de accesibilitatea SMB și arată ca o eroare de acreditări. Testați controlerul de domeniu înainte de a retasta parola.

Rutați și filtrați în ambele sensuri

Un tunel între locații are nevoie de prefixul îndepărtat în tabela de rutare locală și de prefixul local în cea îndepărtată, iar paravanul de pe fiecare parte trebuie să permită traficul care sosește. O configurație unilaterală produce o conexiune care se deschide și nu răspunde niciodată, ceea ce utilizatorii descriu ca fiind o partajare lentă. Verificați mai întâi contoarele tunelului însuși. Dacă pachetele pleacă și nu se întoarce nimic, căutați ruta de retur sau filtrul îndepărtat.

Cu WireGuard, IP-urile permise ale partenerului și rutele sistemului de operare trebuie să fie în acord cu acea proiectare. Tunelul transportă pachete; nu furnizează înregistrări DNS sau permisiuni de partajare pe niciuna dintre părți.

Bazați regula de paravan pe rețeaua sursă reală care se va conecta și notați excepția. Dacă proiectarea traduce adrese undeva pe traseu, regula trebuie să folosească sursa tradusă, iar adresa originală a clientului nu mai este vizibilă în jurnale.

Autentificați-vă, apoi mapați unitatea

Parcurgeți straturile cu comenzi, nu cu fereastra Explorer:

Resolve-DnsName -Name files.corp.example -Type A
Test-NetConnection -ComputerName files.corp.example -Port 445
net use Z: \\files.corp.example\Projects /persistent:no

A doua comandă dovedește calea TCP, nu dreptul de a citi ceva. A treia este locul unde se exercită autentificarea și autorizarea, iar un eșec acolo ar trebui să vă trimită la permisiunile partajării și ale sistemului de fișiere, nu înapoi la router.

Păstrați intacte semnarea SMB și politica de autentificare existentă. Reactivarea SMB1 sau retransmiterea difuzărilor de descoperire prin tunel nu este necesară pentru o cale explicită, iar TCP 445 ar trebui să rămână pe calea privată, nu pe un redirecționare expusă internetului. Dați utilizatorilor o comandă rapidă administrată sau o unitate mapată către numele aprobat, iar pagina Rețea goală nu mai contează.