Netwerkshares verschijnen niet op een VPN? Detectie stopt

De share opent wanneer u het pad typt, en de netwerkbrowser toont helemaal niets. Die combinatie komt veel voor via een tunnel en is meestal geen storing. Detectie stelt een vraag aan het lokale segment; bereikbaarheid stelt een vraag aan één host. Een gerouteerde tunnel vervoert het tweede en niet het eerste.

Detectie en bereikbaarheid zijn gescheiden

Een bladerlijst wordt geproduceerd door protocollen die diensten aankondigen aan een lokaal segment en naar die aankondigingen luisteren. Een share op naam openen is een directe verbinding met één host. Het eerste vereist een broadcast- of multicast-domein; het tweede vereist een route en een poort.

Via een tunnel kan het tweede perfect werken terwijl het eerste een leeg venster teruggeeft. Wie het lege venster als de storing ziet, gaat op zoek naar een kapotte tunnel die zijn werk doet.

Waarom de bladerlijst leeg blijft

Windows heeft de service Computer Browser uitgefaseerd en SMB versie 1 standaard uitgeschakeld, waardoor de machinerie achter de oude Netwerkomgeving verdween. Vervangers zoals WS-Discovery, SSDP en multicast-DNS richten zich op broadcast- of multicast-groepen die alleen op een lokale verbinding bestaan. Een punt-tot-punt-tunnel heeft zo’n verbinding niet, en routers sturen die groepen standaard niet door. Elke host kan bereikbaar zijn en de lijst kan toch leeg blijven.

Sommige programma’s voegen hun eigen detectiehulp toe. Als die hulp werkt, is dat een functie van het programma, geen eigenschap van de tunnel.

Gebruik expliciete namen en bevestig daarna de toegang

Een UNC-pad, een toegewezen station of een Finder-verbinding naar een SMB-adres werkt via de tunnel zodra de naam wordt opgelost en de poort open is. Oplossing kan komen van DNS, van een zoekachtervoegsel dat de VPN levert, of van een centraal beheerde hosts-regel. In een domein kan een directoryquery computerobjecten opsommen, en die lijst is meestal de dichtstbijzijnde vervanging voor een bladerview op een gerouteerd netwerk. Een poortscan van bekende prefixen is alleen aanvaardbaar op netwerken die u beheert of waarvoor u uitdrukkelijk toestemming hebt om te testen.

Een host die antwoordt, belooft niet dat de share opengaat. Een NAS kan een allowlist hebben die beperkt is tot zijn eigen subnet en VPN-pooladressen weigert. De firewallregel van een bestandsserver noemt misschien alleen het lokale subnet. Het account dat u voor de share opgeeft, kan een lokaal account zijn dat nooit op die server is aangemaakt, en verbinden via de VPN maakt het niet aan.

Sommige bedrijfsprogramma’s blokkeren bewust lokaal verkeer en verkeer van virtuele machines zolang de tunnel actief is. Die ontbrekende toegang is beleid, en de oplossing hoort bij de beheerder, niet bij de routetabel van het programma.

Een diagnostische volgorde die het herhalen waard is

Loop de lagen in volgorde af: bereik het adres, los de naam op, open poort 445, authenticeer en lees dan de sharemachtigingen. Elk antwoord staat op zichzelf, en vooruit springen levert een zelfverzekerde verkeerde conclusie op. Pas als ze allemaal slagen, is detectie het onderzoeken waard.

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

Laat een notitie achter met de servernaam, het sharepad, het adres waarnaar het is opgelost en het account dat werkte. Als de bladerlijst later na een herstart van een service volloopt, behandel dat als een eigenaardigheid van detectie en niet als bewijs dat de eerdere route fout was. De notitie is wat de volgende persoon het lege venster laat overslaan.