Gekoppelde schijf via een site-VPN: DNS, SMB en het UNC-pad

De pagina Netwerk in Verkenner toont apparaten die zich op het lokale segment hebben aangekondigd, en een gerouteerde tunnel vervoert niets van die aankondigingen. Daarom kan een server prima bereikbaar zijn terwijl het venster voor de gebruiker leeg blijft. Een benoemd UNC-pad is helemaal niet afhankelijk van detectie, en de oplossing is de naam laten resolven en de poort laten antwoorden. Het lege venster is een symptoom van de verkeerde laag, niet van een kapotte share.

Detectie is niet hetzelfde als bereikbaarheid

Windows vindt nabije machines via protocollen die voor een broadcastdomein zijn ontworpen, en toont wat het vond als een gemakslijst. Niets in die lijst is nodig voor SMB-bestandstoegang. Een client die de servernaam kent en TCP 445 kan bereiken, opent de share, of de machine ooit onder Netwerk verschijnt of niet.

De twee lagen falen onafhankelijk, en daarom verdienen "ik zie het niet" en "ik kan het niet openen" verschillende tests. Naar de lijst kijken zegt iets over detectie; het pad openen zegt iets over de dienst.

Noem de server voordat je de share koppelt

Publiceer de fileserver in DNS met het adres dat hij aan de overkant heeft, en wijs de clientlocatie naar een resolver die voor die zone kan antwoorden. Een volledig gekwalificeerde naam voorkomt afhankelijkheid van een lokale suffixzoeklijst, wat de gebruikelijke reden is dat een korte naam op de ene locatie werkt en op de andere niet.

Gebruikt de omgeving Active Directory, dan is naamresolutie ook deel van de authenticatie: de client moet een domeincontroller voor Kerberos bereiken, en een klok die te ver uit de pas loopt laat de ticketuitwisseling mislukken. Dat is een ander probleem dan SMB-bereikbaarheid en ziet eruit als een inlogfout. Test de domeincontroller voordat je het wachtwoord opnieuw intypt.

Routeer en filter in beide richtingen

Een site-naar-site-tunnel heeft het externe prefix in de lokale routetabel nodig en het lokale prefix in de externe, en de firewall aan elke kant moet het aankomende verkeer toestaan. Eenzijdige configuratie levert een verbinding op die opengaat en nooit antwoordt, wat gebruikers beschrijven als een trage share. Controleer eerst de eigen tellers van de tunnel. Als pakketten vertrekken en er komt niets terug, dan is de retourroute of het externe filter de plek om te kijken.

Bij WireGuard moeten de toegestane IP's van de peer en de routes van het besturingssysteem met dat ontwerp overeenkomen. De tunnel vervoert pakketten; hij voorziet niet in DNS-records of sharemachtigingen aan een van beide kanten.

Baseer de firewallregel op het werkelijke bronnetwerk dat gaat verbinden, en schrijf de uitzondering op. Als het ontwerp ergens in het pad adressen vertaalt, moet de regel de vertaalde bron gebruiken, en het oorspronkelijke clientadres is niet langer zichtbaar voor logging.

Authenticeer, koppel dan de schijf

Werk de lagen af met opdrachten in plaats van met het 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

De tweede opdracht bewijst het TCP-pad, niet het recht om iets te lezen. De derde is waar authenticatie en autorisatie worden uitgeoefend, en een fout daar moet je naar de share- en bestandssysteemmachtigingen sturen in plaats van terug naar de router.

Laat SMB-ondertekening en het bestaande authenticatiebeleid intact. SMB1 weer inschakelen of detectiebroadcasts door de tunnel doorsturen is niet nodig voor een expliciet pad, en TCP 445 hoort op het private pad te blijven in plaats van op een naar internet gerichte doorsturing. Geef gebruikers een beheerde snelkoppeling of gekoppelde schijf naar de goedgekeurde naam, en de lege Netwerk-pagina maakt niets meer uit.