Naka-map na drive sa pamamagitan ng site VPN: DNS, SMB at ang UNC path

Ipinapakita ng pahina ng Network sa Explorer ang mga device na nag-anunsyo ng sarili sa lokal na segment, at walang dalang anunsyo ang rutang tunnel. Kaya nga maaaring ganap na maabot ang server habang nananatiling walang laman ang bintana sa harap ng gumagamit. Ang pinangalanang UNC path ay hindi umaasa sa pagtuklas, at ang solusyon ay gawing naresolba ang pangalan at sumagot ang port. Ang walang laman na bintana ay sintomas ng maling layer, hindi ng sirang share.

Ang pagtuklas ay hindi pareho ng pag-abot

Naghahanap ang Windows ng mga kalapit na makina sa pamamagitan ng mga protocol na ginawa para sa broadcast domain, pagkatapos ay ipinapakita ang nahanap bilang listahan para sa kaginhawahan. Wala sa listahang iyon ang kailangan para sa SMB file access. Ang client na alam ang pangalan ng server at nakakaabot sa TCP 445 ay bubuksan ang share, lumitaw man ang makina sa Network o hindi.

Nabibigo ang dalawang layer nang hiwalay, kaya ang "hindi ko ito nakikita" at "hindi ko ito mabuksan" ay karapat-dapat sa magkaibang pagsubok. Ang pagtingin sa listahan ay nagsasabi tungkol sa pagtuklas; ang pagbukas ng path ay nagsasabi tungkol sa serbisyo.

Pangalanan ang server bago i-map ang share

I-publish ang file server sa DNS gamit ang address na mayroon ito sa kabilang panig, at ituro ang site ng client sa resolver na makakasagot para sa zone na iyon. Ang ganap na kwalipikadong pangalan ay umiiwas sa pagdepende sa lokal na listahan ng suffix sa paghahanap, na karaniwang dahilan kung bakit gumagana ang maikling pangalan sa isang site at nabibigo sa iba.

Kung gumagamit ng Active Directory ang kapaligiran, bahagi rin ng authentication ang pagresolba ng pangalan: kailangang maabot ng client ang domain controller para sa Kerberos, at ang orasan na masyadong lumihis ay magpapabigo sa palitan ng ticket. Iba itong problema sa SMB reachability at mukhang error sa credential. Subukan ang domain controller bago i-type muli ang password.

Ruta at filter sa dalawang direksyon

Kailangan ng site-to-site tunnel ang remote prefix sa lokal na routing table at ang local prefix sa remote, at dapat payagan ng firewall sa bawat panig ang papasok na trapiko. Ang one-way na configuration ay gumagawa ng koneksyon na bumubukas at hindi kailanman sumasagot, na inilalarawan ng mga gumagamit na mabagal na share. Suriin muna ang mga counter ng tunnel mismo. Kung lumalabas ang mga packet at walang bumabalik, hanapin ang return route o ang remote filter.

Sa WireGuard, dapat tumugma ang pinapayagang IP ng peer at ang mga ruta ng operating system sa disenyong iyon. Nagdadala ng packet ang tunnel; hindi ito nagbibigay ng DNS record o pahintulot sa share sa alinmang panig.

Ibase ang firewall rule sa aktwal na source network na kokonekta, at isulat ang exception. Kung nagsasalin ng address ang disenyo sa isang punto ng path, dapat gamitin ng rule ang isinaling source, at hindi na makikita ang orihinal na address ng client sa log.

Mag-authenticate, pagkatapos i-map ang drive

Daanan ang mga layer gamit ang mga command sa halip na ang window ng 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

Pinatutunayan ng ikalawang command ang TCP path, hindi ang karapatang magbasa ng kahit ano. Ang pangatlo ang lugar kung saan isinasagawa ang authentication at authorization, at ang kabiguan doon ay dapat magdala sa iyo sa pahintulot ng share at file system, hindi pabalik sa router.

Panatilihing buo ang SMB signing at ang umiiral na patakaran sa authentication. Hindi kailangan ang muling pagpapagana ng SMB1 o pagpapasa ng broadcast ng pagtuklas sa tunnel para sa malinaw na path, at dapat manatili ang TCP 445 sa pribadong path, hindi sa forward na nakaharap sa internet. Bigyan ang mga gumagamit ng pinamamahalaang shortcut o naka-map na drive sa aprubadong pangalan, at hindi na mahalaga ang walang laman na pahina ng Network.