Mapowany dysk przez VPN między lokalizacjami: DNS, SMB i ścieżka UNC

Strona Sieć w Eksploratorze pokazuje urządzenia, które zgłosiły się w lokalnym segmencie, a tunel routowany nie przenosi żadnego z tych zgłoszeń. Dlatego serwer może być doskonale osiągalny, podczas gdy okno przed użytkownikiem pozostaje puste. Nazwana ścieżka UNC wcale nie zależy od wykrywania, a rozwiązaniem jest doprowadzenie do tego, by nazwa się rozwiązywała, a port odpowiadał. Puste okno jest objawem niewłaściwej warstwy, nie zepsutego udziału.

Wykrywanie to nie to samo co osiągalność

Windows znajduje pobliskie maszyny przez protokoły zaprojektowane dla domeny rozgłoszeniowej, a potem przedstawia znalezione jako listę dla wygody. Nic z tej listy nie jest potrzebne do dostępu do plików przez SMB. Klient, który zna nazwę serwera i osiąga TCP 445, otworzy udział, niezależnie od tego, czy maszyna kiedykolwiek pojawi się w Sieci.

Obie warstwy zawodzą niezależnie, dlatego "nie widzę tego" i "nie mogę tego otworzyć" zasługują na różne testy. Spojrzenie na listę mówi o wykrywaniu; otwarcie ścieżki mówi o usłudze.

Nazwij serwer, zanim zamapujesz udział

Opublikuj serwer plików w DNS z adresem, który ma po drugiej stronie, i skieruj lokalizację klienta na resolver, który potrafi odpowiadać dla tej strefy. Pełna nazwa kwalifikowana pozwala uniknąć zależności od lokalnej listy sufiksów wyszukiwania, co jest zwykłą przyczyną tego, że krótka nazwa działa w jednej lokalizacji, a w innej zawodzi.

Jeśli środowisko używa Active Directory, rozwiązywanie nazw jest też częścią uwierzytelniania: klient musi dotrzeć do kontrolera domeny dla Kerberos, a zegar zbyt odbiegający od rzeczywistości spowoduje niepowodzenie wymiany biletów. To inny problem niż osiągalność SMB i wygląda jak błąd danych logowania. Przetestuj kontroler domeny, zanim ponownie wpiszesz hasło.

Routing i filtrowanie w obu kierunkach

Tunel między lokalizacjami potrzebuje zdalnego prefiksu w lokalnej tablicy routingu i lokalnego prefiksu w zdalnej, a zapora po każdej stronie musi przepuszczać ruch, który przychodzi. Jednostronna konfiguracja daje połączenie, które się otwiera i nigdy nie odpowiada, co użytkownicy opisują jako wolny udział. Najpierw sprawdź własne liczniki tunelu. Jeśli pakiety wychodzą i nic nie wraca, szukaj trasy powrotnej albo zdalnego filtra.

W WireGuardzie dozwolone adresy IP peera i trasy systemu operacyjnego muszą zgadzać się z tym projektem. Tunel przenosi pakiety; nie zapewnia rekordów DNS ani uprawnień do udziału po żadnej ze stron.

Oprzyj regułę zapory na rzeczywistej sieci źródłowej, która będzie się łączyć, i zapisz wyjątek. Jeśli projekt gdzieś na ścieżce tłumaczy adresy, reguła musi używać przetłumaczonego źródła, a pierwotny adres klienta nie jest już widoczny w logach.

Uwierzytelnij, a potem zamapuj dysk

Przechodź przez warstwy za pomocą poleceń, a nie okna Eksploratora:

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

Drugie polecenie dowodzi ścieżki TCP, nie prawa do czytania czegokolwiek. Trzecie jest miejscem, w którym sprawdzane są uwierzytelnianie i autoryzacja, a niepowodzenie tam powinno skierować cię do uprawnień udziału i systemu plików, a nie z powrotem do routera.

Zachowaj podpisywanie SMB i istniejące zasady uwierzytelniania bez zmian. Ponowne włączanie SMB1 ani przekazywanie rozgłoszeń wykrywania przez tunel nie jest potrzebne dla jawnej ścieżki, a TCP 445 powinien pozostać na ścieżce prywatnej, a nie na przekierowaniu do internetu. Daj użytkownikom zarządzany skrót lub mapowany dysk do zatwierdzonej nazwy, a pusta strona Sieci przestanie mieć znaczenie.