Tilkopla stasjon over eit stad-VPN: DNS, SMB og UNC-stigen

Sida Nettverk i Utforskaren viser einingar som har annonsert seg sjølve på det lokale segmentet, og ein ruta tunnel fraktar ingen av desse annonseringane. Difor kan ein server vere heilt nåbar medan vindauget framfor brukaren blir ståande tomt. Ein namngitt UNC-stig er ikkje avhengig av oppdaging i det heile, og løysinga er å få namnet til å slå opp og porten til å svare. Det tomme vindauget er eit symptom på feil lag, ikkje på ei øydelagd deling.

Oppdaging er ikkje det same som nåbarheit

Windows finn maskiner i nærleiken via protokollar som er laga for eit kringkastingsdomene, og viser det han fann som ei bekvemmelegheitsliste. Ingenting i den lista trengst for SMB-filtilgang. Ein klient som kjenner servernamnet og kan nå TCP 445, opnar delinga same kva maskinen nokon gong dukkar opp under Nettverk.

Dei to laga sviktar uavhengig av kvarandre, og difor fortener "eg ser det ikkje" og "eg får det ikkje opna" ulike testar. Å sjå på lista seier noko om oppdaging; å opne stigen seier noko om tenesta.

Namngi serveren før du koplar til delinga

Publiser filserveren i DNS med adressa han har på den andre sida, og peik klientstaden mot ein resolver som kan svare for den sona. Eit fullt kvalifisert namn unngår avhengigheit av ei lokal suffikssøkeliste, som er den vanlege grunnen til at eit kort namn verkar på ein stad og sviktar på ein annan.

Viss miljøet brukar Active Directory, er namneoppslag òg ein del av autentiseringa: klienten må nå ein domenekontrollar for Kerberos, og ei klokke som går for langt ut av takt får billettutvekslinga til å svikte. Det er eit anna problem enn SMB-nåbarheit og ser ut som ein innloggingsfeil. Test domenekontrollaren før du skriv passordet på nytt.

Rut og filtrer i begge retningar

Ein tunnel mellom to stader treng det eksterne prefikset i den lokale rutetabellen og det lokale prefikset i den eksterne, og brannmuren på kvar side må tillate trafikken som kjem inn. Ein einsidig konfigurasjon gir ei tilkopling som opnar og aldri svarar, noko brukarane skildrar som at delinga er treg. Sjekk teljarane til tunnelen sjølv først. Viss pakkar går ut og ingenting kjem tilbake, er returruta eller det eksterne filteret staden å sjå.

Med WireGuard må tillatne IP-adresser til peeren og rutene til operativsystemet stemme med den utforminga. Tunnelen fraktar pakkar; han skaffar ikkje DNS-postar eller delingstillatingar på nokon av sidene.

Bygg brannmurregelen på det faktiske kjeldenettverket som skal kople seg til, og skriv ned unntaket. Viss utforminga set om adresser ein stad i stigen, må regelen bruke den omsette kjelda, og den opphavlege klientadressa er ikkje lenger synleg i loggen.

Autentiser, og kople deretter til stasjonen

Arbeid deg nedover laga med kommandoar i staden for med Utforskaren-vindauget:

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

Den andre kommandoen provar TCP-stigen, ikkje retten til å lese noko. Den tredje er der autentisering og autorisasjon blir utøvde, og ein feil der bør sende deg til delings- og filsystemtillatingane i staden for tilbake til rutaren.

Hald SMB-signering og den eksisterande autentiseringspolicyen intakt. Det er ikkje nødvendig å slå på SMB1 igjen eller videresende oppdagingskringkasting gjennom tunnelen for ein eksplisitt stig, og TCP 445 bør bli på den private vegen i staden for på ei internettvend videresending. Gi brukarane ein administrert snarveg eller ein tilkopla stasjon til det godkjende namnet, og den tomme Nettverk-sida sluttar å bety noko.