Połączono z OpenVPN, ale brak ping i udziału SMB? Sprawdź trzy bramy

Tunel wstaje, klient dostaje adres, a nic w zdalnej sieci LAN nie odpowiada. Ping zawodzi, udział się nie otwiera, a dziennik VPN wygląda czysto, bo z jego punktu widzenia sesja jest zdrowa. Między tą sesją a plikiem na serwerze stoją trzy niezależne bramy: polityka przekazywania, porty potrzebne usłudze i nazwa, którą wpisałeś zamiast adresu.

Każda brama zawodzi z innym objawem, a tylko pierwsza jest na serwerze VPN.

Przekazywanie to polityka na łańcuchu FORWARD

Akceptacja nasłuchu OpenVPN odbywa się na INPUT, dlatego tunel może się połączyć, gdy każdy pakiet kierowany do LAN jest odrzucany. Ruch przychodzący na tun0 i wychodzący przez interfejs LAN przechodzi przez FORWARD, a host z domyślną polityką DROP odrzuca go tam po cichu. Zanim dotkniesz czegokolwiek innego, sprawdź zarówno sysctl, jak i łańcuch: sysctl net.ipv4.ip_forward i iptables -L FORWARD -v -n.

Zezwól na zamierzony kierunek i należące do niego odpowiedzi, na przykład regułę accept z interfejsu tunelu do interfejsu LAN oraz regułę stateful dla ruchu established i related. Jeśli LAN stoi za innym routerem, ten router potrzebuje trasy powrotnej do puli klientów albo source NAT na serwerze VPN. Potwierdź tę ścieżkę jednym pingiem, zanim dodasz kolejne reguły, bo reguła, do której nie można dotrzeć, nigdy nie pojawia się w liczniku.

SMB potrzebuje więcej niż jednego portu

Udostępnianie plików to nie jedna rozmowa TCP 445. Wykrywanie używa UDP 137 i 138, starsze sesje NetBIOS używają TCP 139, a nowoczesne sesje SMB używają TCP 445. Reguła otwierająca tylko 445 tworzy irytujący przypadek, w którym mapowany dysk działa, a przeglądanie sieci nie, albo odwrotnie.

Duże transfery przez tunel trafiają też na problemy z MSS, które wyglądają jak zepsuty udział. SYN ogłaszający pełny rozmiar segmentu LAN jest odrzucany przez mniejsze MTU tunelu, a połączenie wisi po uścisku dłoni. Ograniczanie MSS na ścieżce przekazywania, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, usuwa ten rodzaj zatoru. Sprawdź kopią kilku megabajtów, a nie listą katalogu, bo małe odpowiedzi przechodzą, nawet gdy duże transfery nie.

Adapter tunelu przychodzi jako nowy profil sieci

Windows klasyfikuje każdy adapter do profilu sieciowego, a nowy adapter tunelu zwykle trafia do Public, gdzie reguły udostępniania plików i drukarek są zablokowane. To decyzja zapory hosta na serwerze plików, a nie problem routingu na serwerze VPN. Zmień kategorię celowo za pomocą Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private po potwierdzeniu, że polityka na to pozwala, bo kategoria zmienia też to, które reguły przychodzące obowiązują.

Ten sam profil wyjaśnia ping, który zawodzi, podczas gdy TCP 445 działa: żądania echa są w Public domyślnie odrzucane.

Nazwy same nie przekraczają rutowanego tunelu

Rozwiązywanie nazw NetBIOS i lokalne wykrywanie opierają się na rozgłoszeniach, których rutowany tunel nie przenosi. Dlatego wpisanie krótkiej nazwy serwera zawodzi, gdy jego adres działa, a udział wygląda na zepsuty, choć zepsute jest tylko wyszukiwanie. Dodaj rekord DNS dla serwera w resolverze, który rozdaje tunel, albo użyj adresu w skrócie.

Jeśli wdrożenie nadal zależy od WINS, skonfiguruj go na kliencie, zamiast liczyć na pojawienie się ruchu rozgłoszeniowego. Testuj najpierw adresem, żeby awaria nazwy nie została pomylona z awarią zapory.

Testuj jedną warstwę naraz i czytaj pierwszą awarię

Idź w górę: pinguj bramę tunelu, pinguj hosta LAN po adresie, potem otwórz port usługi za pomocą Test-NetConnection -ComputerName 10.8.0.5 -Port 445, i dopiero wtedy uwierzytelnij się w udziale. Pierwszy zawodzący krok to warstwa do naprawy, a każdy kolejny krok to szum, dopóki tamten nie przejdzie. Ping, który odpowiada, gdy port pozostaje zamknięty, wskazuje na własną zaporę serwera plików, a port, który otwiera się mimo cichych pingów, wskazuje na filtrowanie ICMP. Zapisz pierwszy zawodzący krok, zanim cokolwiek zmienisz, bo druga zmiana ukrywa wynik pierwszej.

Jeśli serwer VPN nie jest routerem LAN, potwierdź trasę powrotną na tym routerze przed dodaniem kolejnych reguł na serwerze. Bez niej żądania docierają do hosta, a odpowiedzi wychodzą domyślną trasą w stronę internetu, co z perspektywy klienta wygląda dokładnie jak odrzucenie przez zaporę.

Trzymaj konto udziału osobno od logowania VPN w notatkach, bo udany tunel nic nie mówi o uprawnieniach do plików. Wystawianie SMB do internetu, by obejść brakującą regułę, nie jest rozwiązaniem.