Hindi Lumilitaw ang Mga Network Share sa VPN? Humihinto ang Pagtuklas

Bubukas ang share kapag tinype mo ang path nito, at walang ipinapakita ang browser ng network. Karaniwan ang kombinasyong iyon sa tunnel at karaniwang hindi ito sira. Nagtatanong ang pagtuklas sa lokal na segment; nagtatanong ang maaabot sa isang host. Dinadala ng rutadong tunnel ang pangalawa at hindi ang una.

Hiwalay ang pagtuklas at ang maaabot

Ang listahan ng pag-browse ay ginagawa ng mga protocol na nag-aanunsyo ng mga serbisyo sa lokal na segment at nakikinig sa mga anunsyong iyon. Ang pagbukas ng share sa pamamagitan ng pangalan ay direktang koneksyon sa isang host. Ang una ay nangangailangan ng broadcast o multicast na domain; ang pangalawa ay nangangailangan ng ruta at port.

Sa tunnel, maaaring gumana nang perpekto ang pangalawa habang nagbabalik ng walang laman na window ang una. Kung ituturing mong sira ang walang laman na window, hahanapin mo ang sirang tunnel na gumagawa ng trabaho nito.

Bakit nananatiling walang laman ang listahan ng pag-browse

Inalis ng Windows ang serbisyong Computer Browser at hindi pinagana ang SMB bersyon 1 bilang default, na nagtanggal ng makinarya sa likod ng lumang Network Neighborhood. Ang mga kapalit tulad ng WS-Discovery, SSDP at multicast DNS ay tumutugon sa broadcast o multicast na grupo na umiiral lamang sa lokal na link. Ang point-to-point na tunnel ay walang ganoong link, at hindi ipinapasa ng mga router ang mga grupong iyon bilang default. Maaaring maabot ang bawat host at maaaring manatiling walang laman ang listahan.

May mga programang nagdaragdag ng sarili nilang katulong sa pagtuklas. Kapag gumagana ang katulong na iyon, ito ay tampok ng programa, hindi katangian ng tunnel.

Gumamit ng malinaw na pangalan, pagkatapos ay kumpirmahin ang access

Isang UNC path, isang naka-map na drive o isang koneksyon ng Finder sa isang SMB address ay gumagana sa tunnel kapag naresolba ang pangalan at bukas ang port. Maaaring magmula ang resolusyon sa DNS, sa search suffix na ibinibigay ng VPN, o sa hosts entry na pinamamahalaan nang sentral. Sa isang domain, maaaring maglista ng mga computer object ang directory query, at ang listahang iyon ay karaniwang pinakamalapit na kapalit ng browse view sa rutadong network. Ang port scan ng mga kilalang prefix ay katanggap-tanggap lamang sa mga network na pinapatakbo mo o malinaw na awtorisado kang subukan.

Ang host na sumasagot ay hindi nangangako na bubukas ang share. Maaaring may allowlist ang NAS na limitado sa sarili nitong subnet, na tumatanggihan sa mga address ng VPN pool. Maaaring lokal na subnet lamang ang binabanggit ng firewall rule ng file server. Ang account na ibinibigay mo para sa share ay maaaring lokal na account na hindi kailanman ginawa sa server na iyon, at ang pagkonekta sa VPN ay hindi ito ginagawa.

May mga corporate program na sadyang hinaharangan ang lokal na trapiko at trapiko ng virtual machine habang nakaupo ang tunnel. Ang nawawalang access na iyon ay patakaran, at ang pagwawasto ay para sa administrator, hindi sa routing table ng programa.

Isang pagkakasunod-sunod ng diagnostic na sulit ulitin

Daanan ang mga layer sa pagkakasunod-sunod: maabot ang address, i-resolve ang pangalan, buksan ang port 445, mag-authenticate, pagkatapos ay basahin ang mga pahintulot ng share. Hiwalay ang bawat sagot, at ang paglukso nang pasulong ay nagbubunga ng kumpiyansang maling konklusyon. Pagkatapos lamang na lahat ay pumasa, sulit imbestigahan ang pagtuklas.

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

Mag-iwan ng tala na may pangalan ng server, path ng share, address na naresolba nito at account na gumana. Kung mamaya mapupuno ang listahan ng pag-browse pagkatapos i-restart ang isang serbisyo, ituring itong kakaibang pagtuklas at hindi patunay na mali ang dating ruta. Ang tala ang nagbibigay-daan sa susunod na tao na laktawan ang walang laman na window.