Klient OpenVPN dociera do serwera, ale nie do hostów LAN: lista kontrolna

Klient zgłasza połączenie, adres tunelu odpowiada na ping, a nic w biurowej sieci LAN nie odpowiada. Widzę to po niemal każdej aktualizacji klienta, a pierwszym odruchem jest otwarcie firewalla, co zwykle jest błędnym krokiem: tunel jest w porządku, a przerwa jest na jednym z trzech przeskoków, które pakiet musi pokonać. Przejdź drogę w kolejności, w jakiej pokonuje ją pakiet, najpierw trasa klienta, potem przekazywanie na serwerze, potem podróż powrotna, a właściciela usterki znajdziesz w kilka minut.

Krok pierwszy: obserwuj decyzję routingu klienta

Zanim dotkniesz serwera, udowodnij, że klient wysyła pakiet do tunelu. Zapytaj jądro, którego interfejsu użyłoby dla jednego konkretnego hosta LAN, zamiast czytać całą tablicę:

ip route get 192.168.50.10

Jeśli odpowiedź wskazuje twój fizyczny adapter i bramę biurową, żadna zmiana po stronie serwera nie pomoże. OpenVPN rozdaje trasy tylko wtedy, gdy serwer je wypycha, więc poszukaj push "route 192.168.50.0 255.255.255.0" w konfiguracji serwera, a potem połącz klienta ponownie. Większość klientów stosuje wypchnięte trasy przy połączeniu, nie przy ponownym wczytaniu profilu.

W Windows to samo pytanie ma inne polecenie. Find-NetRoute -RemoteIPAddress 192.168.50.10 wypisuje interfejs i następny przeskok, który wybrałby stos, a route print -4 pokazuje, czy wypchnięty prefiks w ogóle istnieje.

Krok drugi: potwierdź, że serwer przekazuje pakiet dalej

Jeśli trasa klienta jest prawidłowa, pakiet dociera do serwera, a serwer musi zgodzić się go przekazać. Przełącznik jądra jest pierwszą bramą i sysctl net.ipv4.ip_forward musi zwrócić 1. Ustawienie go przez echo 1 > /proc/sys/net/ipv4/ip_forward działa do następnego restartu, i właśnie dlatego ta sama skarga wraca kilka tygodni później.

Zapisz to gdzieś, co przetrwa restart:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

Drugą bramą jest tablica filtrów. Host z zainstalowanym Dockerem często ma politykę FORWARD ustawioną na DROP, a tunel dziedziczy tę decyzję. iptables -L FORWARD -v -n pokazuje zarówno politykę, jak i liczniki pakietów; jeśli polityka to DROP, przekazywanie wymaga wyraźnego zezwolenia dla kierunku z tunelu do LAN i jeszcze jednego dla odpowiedzi.

Krok trzeci: śledź pakiet do LAN i szukaj odpowiedzi

Obserwuj obie strony serwera jednocześnie. Przechwytuj na tunelu i na interfejsie LAN, filtrując do jednego klienta i jednego hosta, aby wyjście pozostało czytelne:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

Żądania, które pojawiają się na tun0 i ponownie na eth0 ze źródłem 10.8.0.x, po których następuje cisza, oznaczają, że pakiet dotarł, a odpowiedź poszła gdzie indziej. Host LAN odpowiada swojej bramie domyślnej, ta brama nie ma trasy do puli VPN, a odpowiedź ginie na routerze LAN. Pingowanie hosta LAN z serwera niczego nie dowodzi o tej drodze, bo ten ruch nigdy nie przechodzi przez tunel.

Krok czwarty: wybierz między translacją a trasą powrotną

Dwie naprawy zamykają dziurę, a wybór ma konsekwencje wykraczające poza to, czy ping działa. Translacja źródła czyni serwer pozornym nadawcą:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Ogranicz regułę do puli i interfejsu LAN, a następnie utrwal ją, inaczej następne przeładowanie firewalla po cichu usunie twoją poprawkę. Kosztem jest tożsamość: każdy klient wygląda jak serwer VPN w logach LAN i regułach dostępu, a per-client policy becomes guesswork.

Trasa statyczna dla 10.8.0.0/24 na routerze LAN, wskazująca serwer VPN, utrzymuje adresy klientów widoczne i jest lepszą odpowiedzią długoterminową, gdy ten router jest twój. Wiele miejsc przez jakiś czas prowadzi oba rozwiązania, NAT do natychmiastowej naprawy i trasę po zapisaniu polityki firewalla. Jeśli serwer jest peerem site-to-site, a nie pulą, strona serwera potrzebuje także iroute dla zdalnej podsieci, inaczej trasa peera istnieje, ale ruch klientów nigdy nie jest z nią kojarzony.

Krok piąty: zweryfikuj z klienta i zapisz, co się zmieniło

Zamknij pętlę z klienta, nie z serwera. Połącz się z prawdziwą usługą na hoście LAN, a potem potwierdź, że liczniki translacji się przesunęły za pomocą iptables -t nat -L POSTROUTING -v -n, bo reguła bez pakietów to reguła, która nigdy nie pasowała. conntrack -L -s 10.8.0.5 pokazuje przepływ i jego stan, gdy potrzebujesz dowodu, że kierunek powrotny jest śledzony.

Zostaw notatkę w konfiguracji serwera: która podsieć, który interfejs, która reguła i czy router LAN ma trasę powrotną. Następnym razem, gdy aktualizacja klienta usunie wypchniętą trasę, ta notatka zamieni gaszenie pożaru w poprawkę jednej linii.