Tilkoblet stasjon over et steds-VPN: DNS, SMB og UNC-banen

Siden Nettverk i Utforsker viser enheter som har annonsert seg selv på det lokale segmentet, og en rutet tunnel frakter ingen av disse annonseringene. Derfor kan en server være helt nåbar mens vinduet foran brukeren blir stående tomt. En navngitt UNC-bane er ikke avhengig av oppdagelse i det hele tatt, og løsningen er å få navnet til å slå opp og porten til å svare. Det tomme vinduet er et symptom på feil lag, ikke på en ødelagt deling.

Oppdagelse er ikke det samme som nåbarhet

Windows finner maskiner i nærheten via protokoller som er laget for et kringkastingsdomene, og viser det den fant som en bekvemmelighetsliste. Ingenting i den listen trengs for SMB-filtilgang. En klient som kjenner servernavnet og kan nå TCP 445, åpner delingen uansett om maskinen noen gang dukker opp under Nettverk.

De to lagene svikter uavhengig av hverandre, og derfor fortjener "jeg ser det ikke" og "jeg får det ikke åpnet" forskjellige tester. Å se på listen sier noe om oppdagelse; å åpne banen sier noe om tjenesten.

Navngi serveren før du kobler til delingen

Publiser filserveren i DNS med adressen den har på den andre siden, og pek klientstedet mot en resolver som kan svare for den sonen. Et fullt kvalifisert navn unngår avhengighet av en lokal suffikssøkeliste, som er den vanlige grunnen til at et kort navn virker på ett sted og svikter på et annet.

Hvis miljøet bruker Active Directory, er navneoppslag også en del av autentiseringen: klienten må nå en domenekontroller for Kerberos, og en klokke som går for langt ut av takt får billettutvekslingen til å svikte. Det er et annet problem enn SMB-nåbarhet og ser ut som en innloggingsfeil. Test domenekontrolleren før du skriver passordet på nytt.

Rut og filtrer i begge retninger

En tunnel mellom to steder trenger det eksterne prefikset i den lokale rutetabellen og det lokale prefikset i den eksterne, og brannmuren på hver side må tillate trafikken som kommer inn. En ensidig konfigurasjon gir en forbindelse som åpnes og aldri svarer, noe brukerne beskriver som at delingen er treg. Sjekk tunnelens egne tellere først. Hvis pakker går ut og ingenting kommer tilbake, er returruten eller det eksterne filteret stedet å se.

Med WireGuard må peerens tillatte IP-adresser og operativsystemets ruter stemme med den utformingen. Tunnelen frakter pakker; den skaffer ikke DNS-poster eller delingstillatelser på noen av sidene.

Bygg brannmurregelen på det faktiske kildenettverket som skal koble seg til, og skriv ned unntaket. Hvis utformingen oversetter adresser et sted i banen, må regelen bruke den oversatte kilden, og den opprinnelige klientadressen er ikke lenger synlig i loggen.

Autentiser, og koble deretter til stasjonen

Arbeid deg nedover lagene med kommandoer i stedet for med Utforsker-vinduet:

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 beviser TCP-banen, ikke retten til å lese noe. Den tredje er der autentisering og autorisasjon utøves, og en feil der bør sende deg til delings- og filsystemtillatelsene i stedet for tilbake til ruteren.

Behold SMB-signering og den eksisterende autentiseringspolicyen intakt. Det er ikke nødvendig å aktivere SMB1 igjen eller videresende oppdagelseskringkasting gjennom tunnelen for en eksplisitt bane, og TCP 445 bør bli på den private veien i stedet for på en internettvendt videresending. Gi brukerne en administrert snarvei eller en tilkoblet stasjon til det godkjente navnet, og den tomme Nettverk-siden slutter å bety noe.