Gekoppelde skyf oor ’n werf-VPN: DNS, SMB en die UNC-pad

Die Netwerk-bladsy in Verkenner wys toestelle wat hulself op die plaaslike segment aangekondig het, en ’n gerouteerde tonnel dra niks van daardie aankondigings nie. Dis hoekom ’n bediener heeltemal bereikbaar kan wees terwyl die venster voor die gebruiker leeg bly. ’n Benoemde UNC-pad hang glad nie van ontdekking af nie, en die oplossing is om die naam te laat oplos en die poort te laat antwoord. Die leë venster is ’n simptoom van die verkeerde laag, nie van ’n gebreekte deel nie.

Ontdekking is nie dieselfde as bereikbaarheid nie

Windows ontdek nabygeleë masjiene deur protokolle wat vir ’n uitsaaidomein ontwerp is, en wys dan wat hy gevind het as ’n gerieflys. Niks in daardie lys is nodig vir SMB-lêertoegang nie. ’n Kliënt wat die bedienernaam ken en TCP 445 kan bereik, sal die deel oopmaak, of die masjien ooit onder Netwerk verskyn of nie.

Die twee lae faal onafhanklik, en daarom verdien "Ek kan dit nie sien nie" en "Ek kan dit nie oopmaak nie" verskillende toetse. Om die lys te kyk, sê iets oor ontdekking; om die pad oop te maak, sê iets oor die diens.

Noem die bediener voordat jy die deel koppel

Publiseer die lêerbediener in DNS met die adres wat hy aan die oorkant het, en wys die kliëntwerf na ’n oplosser wat vir daardie sone kan antwoord. ’n Volledig gekwalifiseerde naam vermy die afhanklikheid van ’n plaaslike agtervoegselsoeklys, wat die gewone rede is waarom ’n kort naam by een werf werk en by ’n ander faal.

As die omgewing Active Directory gebruik, is naamoplossing ook deel van verifikasie: die kliënt moet ’n domeinbeheerder vir Kerberos bereik, en ’n horlosie wat te ver uit stap, laat die kaartjie-uitruiling misluk. Dit is ’n ander probleem as SMB-bereikbaarheid en lyk soos ’n geloofsbriewefout. Toets die domeinbeheerder voordat jy die wagwoord weer intik.

Roeteer en filter in beide rigtings

’n Werf-tot-werf-tonnel het die afgeleë voorvoegsel in die plaaslike roeteblad nodig en die plaaslike voorvoegsel in die afgeleë een, en die brandmuur aan elke kant moet die verkeer wat aankom toelaat. Eensydige konfigurasie lewer ’n verbinding wat oopmaak en nooit antwoord nie, wat gebruikers beskryf as die deel wat stadig is. Kyk eers na die tonnel se eie tellers. As pakkette vertrek en niks terugkom nie, is die terugroete of die afgeleë filter die plek om te kyk.

Met WireGuard moet die eweknie se toegelate IP's en die bedryfstelsel se roetes by daardie ontwerp pas. Die tonnel dra pakkette; dit voorsien nie DNS-rekords of deeltoestemmings nie aan enige kant nie.

Baseer die brandmuurreël op die werklike bronnetwerk wat gaan koppel, en skryf die uitsondering neer. As die ontwerp êrens in die pad adresse vertaal, moet die reël die vertaalde bron gebruik, en die oorspronklike kliëntadres is nie meer sigbaar vir logboeke nie.

Verifieer, koppel dan die skyf

Werk laag vir laag af met opdragte eerder as met die Verkenner-venster:

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

Die tweede opdrag bewys die TCP-pad, nie die reg om iets te lees nie. Die derde is waar verifikasie en magtiging uitgeoefen word, en ’n mislukking daar moet jou na die deel- en lêerstelseltoestemmings stuur eerder as terug na die roeteerder.

Hou SMB-ondertekening en die bestaande verifikasiebeleid ongeskonde. Om SMB1 weer te aktiveer of ontdekkingsuitsendings deur die tonnel te stuur, is nie nodig vir ’n uitdruklike pad nie, en TCP 445 moet op die private pad bly eerder as op ’n internetgerigte deurvoer. Gee gebruikers ’n bestuurde kortpad of gekoppelde skyf na die goedgekeurde naam, en die leë Netwerk-bladsy hou op om saak te maak.