Mappad enhet över ett plats-VPN: DNS, SMB och UNC-sökvägen

Sidan Nätverk i Utforskaren visar enheter som har annonserat sig på det lokala segmentet, och en routad tunnel bär inga av dessa annonseringar. Därför kan en server vara fullt nåbar medan fönstret framför användaren förblir tomt. En namngiven UNC-sökväg är inte beroende av identifiering alls, och lösningen är att få namnet att slå upp och porten att svara. Det tomma fönstret är ett symptom på fel lager, inte på en trasig delning.

Identifiering är inte samma sak som nåbarhet

Windows hittar närliggande maskiner via protokoll som är gjorda för en broadcastdomän och visar det den hittade som en bekvämlighetslista. Inget i listan krävs för SMB-filåtkomst. En klient som känner till servernamnet och kan nå TCP 445 öppnar delningen, oavsett om maskinen någonsin dyker upp under Nätverk.

De två lagren fallerar oberoende av varandra, och därför förtjänar "jag kan inte se det" och "jag kan inte öppna det" olika tester. Att titta på listan säger något om identifiering; att öppna sökvägen säger något om tjänsten.

Namnge servern innan du mappar delningen

Publicera filservern i DNS med den adress den har på andra sidan, och peka klientplatsen mot en resolver som kan svara för den zonen. Ett fullständigt kvalificerat namn undviker beroende av en lokal suffixesöklista, vilket är det vanliga skälet till att ett kort namn fungerar på en plats och misslyckas på en annan.

Om miljön använder Active Directory är namnuppslagning också en del av autentiseringen: klienten måste nå en domänkontrollant för Kerberos, och en klocka som går för långt ur takt får biljettutbytet att misslyckas. Det är ett annat problem än SMB-nåbarhet och ser ut som ett inloggningsfel. Testa domänkontrollanten innan du skriver lösenordet igen.

Routa och filtrera i båda riktningarna

En tunnel mellan två platser behöver det avlägsna prefixet i den lokala routingtabellen och det lokala prefixet i den avlägsna, och brandväggen på varje sida måste tillåta trafiken som anländer. En enkelriktad konfiguration ger en anslutning som öppnas och aldrig svarar, vilket användare beskriver som att delningen är långsam. Kontrollera tunnelns egna räknare först. Om paket lämnar och inget kommer tillbaka är returvägen eller det avlägsna filtret platsen att titta på.

Med WireGuard måste peerens tillåtna IP-adresser och operativsystemets rutter stämma med den designen. Tunneln bär paket; den tillhandahåller inte DNS-poster eller delningsbehörigheter på någon av sidorna.

Utgå från det faktiska källnätverket som ska ansluta när du skriver brandväggsregeln, och skriv ned undantaget. Om designen översätter adresser någonstans i vägen måste regeln använda den översatta källan, och den ursprungliga klientadressen syns inte längre i loggen.

Autentisera, mappa sedan enheten

Arbeta nedåt genom lagren med kommandon i stället för med Utforskarens fönster:

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

Det andra kommandot bevisar TCP-vägen, inte rätten att läsa något. Det tredje är där autentisering och auktorisering utövas, och ett fel där bör skicka dig till delnings- och filsystemsbehörigheterna i stället för tillbaka till routern.

Behåll SMB-signering och den befintliga autentiseringspolicyn intakta. Att återaktivera SMB1 eller vidarebefordra identifieringsbroadcast genom tunneln behövs inte för en explicit sökväg, och TCP 445 bör stanna på den privata vägen i stället för på en internetvänd vidarebefordran. Ge användarna en hanterad genväg eller mappad enhet till det godkända namnet, och den tomma Nätverk-sidan slutar spela roll.