Brak dostępu do LAN przez OpenVPN? Sprawdź strefy, trasy i drogę powrotną

Tunel zgłasza udane połączenie, strona samego routera się ładuje, a mapowanie dysku do maszyny za nim wciąż kończy się przekroczeniem czasu. W tym zestawieniu nie ma sprzeczności: router odpowiada jako on sam, a dotarcie do czegokolwiek za nim to inna decyzja podjęta w innym miejscu. Wykonaj poniższe kontrole po kolei i zatrzymaj się na pierwszym błędzie, bo każda opiera się na poprzedniej. Gdy wszystkie cztery przejdą, usterka jest nad tunelem, a nie w nim.

Który filtr widzi pakiet kierowany do LAN

Pakiet adresowany do routera jest zużywany lokalnie; pakiet adresowany do hosta za nim musi zostać przekazany, a zapory ogniowe oceniają te dwa przypadki osobno. Zgoda na dotarcie do routera nie mówi więc nic o zgodzie na jego przekroczenie. Firmware, który ukrywa swoje zestawy reguł, nadal implementuje oba, zwykle jako selektor oferujący LAN, internet lub oba. Jeśli selektor pomija LAN, żadna późniejsza kontrola nie będzie miała znaczenia.

OpenWrt czyni ten podział sprawdzalnym, a różnica warta jest jednego czytania. Strefa kończąca tunel potrzebuje reguły przekazywania do strefy LAN, podczas gdy reguła wejściowa rządzi tylko usługami na samym routerze. Działająca strona administracyjna obok martwego LAN to zwykły skutek tej brakującej reguły przekazywania.

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

Spójrz na cel przekazywania strefy, która niesie tunel: accept to to, czego potrzebuje drabina, a reject wyjaśnia każde przekroczenie czasu poniżej. Dwa sąsiednie ustawienia dają ten sam objaw, więc wyklucz je, póki tu jesteś. Izolacja bezprzewodowa ukrywa hosty przewodowe przed klientami bezprzewodowymi, a router, który uznaje bezczynne hosty LAN za offline, może odrzucać odpowiedzi nawet po tym, jak przekazywanie zacznie działać.

Dlaczego tunel dzielony potrzebuje wypchniętego prefiksu

Klient, który wysyła cały ruch przez tunel, ma już prefiks LAN dzięki swojej trasie domyślnej, więc nie ma czego dodawać. Tunel dzielony to przypadek wymagający jawnego wskazania prefiksu, bo nic innego w konfiguracji o nim nie wspomina. Dodaj dyrektywę do konfiguracji serwera i przeładuj usługę.

push "route 192.168.50.0 255.255.255.0"

Profile zawierające route-nopull ignorują wypchnięte trasy, więc ten sam prefiks należy do pliku klienta. W każdym razie potwierdź, że wpis dotarł, zamiast tego zakładać, bo ciche nadpisanie wygląda identycznie jak problem z zaporą.

ip route show | grep 192.168.50

Partner lokacja-lokacja prosi o więcej niż wypchnięcie. Serwer musi nauczyć się, jakie prefiksy stoją za tym partnerem, co robi wiersz iroute w jego pliku client-config-dir, a jego własna tabela potrzebuje pasującej trasy do tunelu.

Odpowiedź potrzebuje adresu, do którego może dotrzeć

Przekazanie żądania to tylko połowa wymiany, bo host LAN musi odpowiedzieć na adres z puli tunelu. Małe routery zwykle załatwiają to przez tłumaczenie źródła w strefie tunelu, więc odpowiedź jest adresowana do routera i nie wymaga konfiguracji gdzie indziej. Usuń to tłumaczenie, a host potrzebuje własnej trasy do puli, którą dostaje za darmo, gdy router jest jego bramą domyślną. Host z ręcznie ustawionym adresem i inną bramą odpowiada przez tę bramę, a klient widzi sesję, która się otwiera i potem zastyga.

tcpdump -ni tun0 host 192.168.50.20

Uruchom to na routerze, gdy klient powtarza żądanie, i czytaj miejsce docelowe odpowiedzi, a nie samo żądanie. Odpowiedź adresowana do puli oznacza, że droga powrotna działa, a usterka jest głębiej. Całkowity brak odpowiedzi oznacza, że host nigdy nie przyjął pakietu, co odsyła cię do zestawu reguł.

Drabina, która kończy się we właściwym miejscu

Cztery kontrole lokalizują warstwę i każda jest jednym poleceniem, a nie oceną. Wykonaj je po kolei i zatrzymaj się na pierwszym błędzie. Kolejność jest ważniejsza niż polecenia, bo późniejszy udany krok ukrywa powód niepowodzenia wcześniejszego.

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

Nazwy należą do końca drabiny, nigdy do początku. Udostępnienie, które odpowiada jako 192.168.50.20, ale nie jako nas.local, wskazuje na rozwiązywanie nazw lub sufiks wyszukiwania, a zmiany w zaporze nie mogą zmienić żadnego z nich.

Zanotuj pierwszy nieudany krok, potem daj portom usług osobną rundę, bo nasłuchiwacz i zezwolenie hosta to osobne wymagania. Udostępnianie plików, pulpit zdalny i strumienie z kamer potrzebują obu, a zapora hosta, która ufa podsieci LAN, ale nie puli tunelu, odrzuca klienta, podczas gdy ping nadal przechodzi. Gdy wszystkie kontrole przejdą, a aplikacja nadal zawodzi, usterka jest nad tunelem: usługa przypisana do jednego interfejsu albo proxy skonfigurowane na kliencie.