Mappet drev over en site-VPN: DNS, SMB og UNC-stien

Siden Netværk i Stifinder viser enheder, der har annonceret sig selv på det lokale segment, og en routet tunnel bærer ingen af disse annonceringer. Derfor kan en server være fuldt ud tilgængelig, mens vinduet foran brugeren forbliver tomt. En navngivet UNC-sti afhænger slet ikke af opdagelse, og løsningen er at få navnet til at slå op og porten til at svare. Det tomme vindue er et symptom på det forkerte lag, ikke på en ødelagt deling.

Opdagelse er ikke det samme som tilgængelighed

Windows finder nærliggende maskiner via protokoller, der er designet til et broadcast-domæne, og viser derefter det fundne som en bekvemmelighedsliste. Intet på den liste er nødvendigt for SMB-filadgang. En klient, der kender servernavnet og kan nå TCP 445, åbner delingen, uanset om maskinen nogensinde dukker op under Netværk.

De to lag fejler uafhængigt, og derfor fortjener "jeg kan ikke se det" og "jeg kan ikke åbne det" forskellige tests. At kigge på listen fortæller om opdagelse; at åbne stien fortæller om tjenesten.

Navngiv serveren, før du mapper delingen

Publicér filserveren i DNS med den adresse, den har på den anden side, og peg klientstedet mod en resolver, der kan svare for den zone. Et fuldt kvalificeret navn undgår afhængighed af en lokal suffikssøgeliste, som er den sædvanlige grund til, at et kort navn virker på ét sted og fejler på et andet.

Hvis miljøet bruger Active Directory, er navneopløsning også en del af autentificeringen: klienten skal nå en domænecontroller til Kerberos, og et ur, der går for langt ud af trit, får billetudvekslingen til at fejle. Det er et andet problem end SMB-tilgængelighed og ser ud som en legitimationsfejl. Test domænecontrolleren, før du skriver adgangskoden igen.

Rout og filtrér i begge retninger

En site-til-site-tunnel kræver det fjerne præfiks i den lokale routingtabel og det lokale præfiks i den fjernes, og firewallingen på hver side skal tillade den trafik, der ankommer. En ensidig konfiguration giver en forbindelse, der åbner og aldrig svarer, hvilket brugerne beskriver som en langsom deling. Kontrollér først tunnelens egne tællere. Hvis pakker forlader og intet vender tilbage, er returruten eller det fjerne filter stedet at kigge.

Med WireGuard skal peerens tilladte IP-adresser og styresystemets ruter stemme overens med det design. Tunnelen bærer pakker; den leverer ikke DNS-poster eller delingstilladelser på nogen af siderne.

Byg firewallreglen på det faktiske kildenettværk, der skal forbinde, og skriv undtagelsen ned. Hvis designet oversætter adresser et sted på vejen, skal reglen bruge den oversatte kilde, og den oprindelige klientadresse er ikke længere synlig i loggen.

Autentificér, og map derefter drevet

Arbejd lag for lag ned med kommandoer i stedet for med Stifinder-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 anden kommando beviser TCP-stien, ikke retten til at læse noget. Den tredje er, hvor autentificering og autorisation udøves, og en fejl der bør sende dig til delings- og filsystemtilladelserne i stedet for tilbage til routeren.

Behold SMB-signering og den eksisterende autentificeringspolitik intakt. Det er ikke nødvendigt at genaktivere SMB1 eller videresende opdagelsesbroadcasts gennem tunnelen for en eksplicit sti, og TCP 445 bør blive på den private vej i stedet for på en internetvendt videresendelse. Giv brugerne en administreret genvej eller et mappet drev til det godkendte navn, og den tomme Netværk-side holder op med at betyde noget.