Mapita disko trans reteja VPN: DNS, SMB kaj la UNC-vojo

La paĝo Reto en Esplorilo montras aparatojn, kiuj anoncis sin en la loka segmento, kaj voja tunelo portas neniun el tiuj anoncoj. Tial servilo povas esti tute atingebla dum la fenestro antaŭ la uzanto restas malplena. Nomata UNC-vojo tute ne dependas de esplorado, kaj la solvo estas igi la nomon solviĝi kaj la pordon respondi. La malplena fenestro estas simptomo de malĝusta tavolo, ne de difektita kunuzo.

Esplorado ne samas kiel atingeblo

Windows trovas proksimajn maŝinojn per protokoloj destinitaj por elsenda domajno, kaj poste prezentas la trovaĵon kiel komfortan liston. Nenio en tiu listo necesas por SMB-dosieraliro. Kliento, kiu konas la servilnomojn kaj povas atingi TCP 445, malfermos la kunuzon, ĉu la maŝino iam aperos sub Reto aŭ ne.

La du tavoloj malsukcesas sendepende, kaj tial "mi ne vidas ĝin" kaj "mi ne povas malfermi ĝin" meritas malsamajn testojn. Rigardi la liston raportas pri esplorado; malfermi la vojon raportas pri la servo.

Nomu la servilon antaŭ ol mapi la kunuzon

Publikigu la dosierservilon en DNS kun la adreso, kiun ĝi havas aliflanke, kaj direktu la klientan ejon al solvilo, kiu povas respondi por tiu zono. Plene kvalifikita nomo evitigas dependecon de loka sufiksa serĉolisto, kio estas la kutima kialo, ke mallonga nomo funkcias en unu ejo kaj malsukcesas en alia.

Se la medio uzas Active Directory, nomosolvado estas ankaŭ parto de aŭtentikigo: la kliento devas atingi domajnan regilon por Kerberos, kaj horloĝo tro malagordita igos la biletan interŝanĝon malsukcesi. Tio estas alia problemo ol SMB-atingeblo kaj aspektas kiel eraro pri akreditaĵoj. Testu la domajnan regilon antaŭ ol retajpi la pasvorton.

Voju kaj filtru en ambaŭ direktoj

Tunelo inter ejaj necesas la malproksiman prefikson en la loka voja tabelo kaj la lokan prefikson en la malproksima, kaj la fajroŝirmilo ambaŭflanke devas permesi la alvenantan trafikon. Unudirekta agordo produktas konekton, kiu malfermiĝas kaj neniam respondas, kion uzantoj priskribas kiel malrapidan kunuzon. Kontrolu unue la proprajn nombrilojn de la tunelo. Se pakaĵoj foriras kaj nenio revenas, serĉu la returnan vojon aŭ la malproksiman filtron.

Ĉe WireGuard, la permesitaj IP-adresoj de la kunulo kaj la vojoj de la operaciumsistemo devas kongrui kun tiu dezajno. La tunelo portas pakaĵojn; ĝi ne provizas DNS-rikordojn aŭ kunuzajn permesojn ĉe iu ajn el la du flankoj.

Bazu la fajroŝirmilan regulon sur la reala fonta reto, kiu konektiĝos, kaj notu la escepton. Se la dezajno tradukas adresojn ie en la vojo, la regulo devas uzi la tradukitan fonton, kaj la origina klienta adreso jam ne videblas en protokoloj.

Aŭtentikigu, poste mapu la diskon

Malsupreniru la tavolojn per komandoj anstataŭ per la fenestro de Esplorilo:

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

La dua komando pruvas la TCP-vojon, ne la rajton legi ion. La tria estas kie aŭtentikigo kaj rajtigo efektiviĝas, kaj malsukceso tie devus sendi vin al la kunuzaj kaj dosiersistemaj permesoj, ne reen al la enkursigilo.

Konservu SMB-subskribon kaj la ekzistantan aŭtentikigan politikon sendifekte. Reŝalti SMB1 aŭ plusendi esploradajn elsendojn tra la tunelo ne necesas por eksplicita vojo, kaj TCP 445 devus resti sur la privata vojo, ne sur en Interreton direktita plusendo. Donu al uzantoj administritan ligilon aŭ mapitan diskon al la aprobita nomo, kaj la malplena paĝo Reto ĉesas gravi.