Klienci VPN docierają do serwera, ale nie do sieci LAN: które rozwiązanie?

Klient pinguje adres tunelu serwera OpenVPN i dostaje odpowiedź, potem próbuje hosta w sieci LAN serwera i nie dostaje nic. Ten podział mocno zawęża usterkę: tunel jest podniesiony, przekazywanie prawdopodobnie działa, a odpowiedź wychodzi drzwiami, które nie prowadzą z powrotem. Istnieją trzy rozwiązania, a właściwe zależy od tego, co kontrolujesz i z czego jesteś gotów zrezygnować. Odpowiedz na trzy pytania poniżej po kolei, a wybór przestanie być kwestią gustu.

Najpierw ustal, który kierunek jest zepsuty

Żądanie przychodzi na interfejs tunelu z adresem źródłowym z puli VPN. Serwer przekazuje je do hosta w sieci LAN, a ten host odpowiada bramie wskazanej przez własną tablicę, zwykle routerowi sieci LAN. Jeśli router nie ma trasy do puli, odpowiedź ginie tam albo błąka się w stronę internetu.

Przetestuj obie maszyny, zanim zmienisz którąkolwiek. Zapytaj na serwerze tablicę routingu, jak dotarłaby do klienta; zapytaj hosta w sieci LAN, jak dotarłby do tego samego adresu. Pierwsze wyszukanie zwykle wskazuje tunel, a drugie router sieci LAN, i ta różnica to usterka w jednym wierszu. Dwa wyszukania są tańsze niż audyt zapory i rozstrzygają kierunek problemu.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Jeśli host w sieci LAN już wskazuje serwer VPN, problemem jest reguła zapory lub limit MTU, a nie brakująca droga powrotna. Nie dodawaj trasy, żeby naprawić filtr.

Pytanie pierwsze: czy możesz edytować router zdalnej sieci LAN?

Gdy router sieci LAN jest twój, czystą odpowiedzią jest trasa statyczna do puli VPN z adresem LAN serwera VPN jako następnym skokiem. Zachowuje nienaruszone adresy źródłowe klientów, co ma znaczenie, gdy hosty w sieci LAN logują, filtrują lub ograniczają ruch według adresu. Nie wymaga też translacji na serwerze, więc tunel pozostaje czystą ścieżką routingu. Obowiązek, jaki tworzy, jest dokumentacyjny, bo pula, trasa i konfiguracja serwera muszą się zgadzać.

Zawodzi po cichu w dniu, gdy ktoś zmieni pulę. Zapisz wartość raz i traktuj zmianę w którymkolwiek z trzech miejsc jako zmianę we wszystkich trzech.

NAS lub przełącznik warstwy 3, który hostuje usługę, potrzebuje tej samej trasy, chyba że wysyła wszystko przez router, który ją ma. Sprawdź urządzenie kończące podsieć, nie tylko to zwrócone w stronę internetu. Małe sieci często mają trzy urządzenia z opinią o routingu.

Pytanie drugie: czy sieć LAN może przestać widzieć adresy klientów?

Gdy router należy do kogoś innego, translacja na serwerze VPN nie wymaga współpracy. Host w sieci LAN widzi adres LAN serwera, odpowiada mu, a serwer tłumaczy z powrotem. Dlatego urządzenia i role dostępu zdalnego oparte na NAT zachowują się właśnie tak.

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

Kosztem jest przypisanie: adresy na klienta znikają z logów sieci LAN. Każda lista dozwolonych na hoście w sieci LAN musi wtedy wskazywać serwer zamiast puli.

Wybierz translację, gdy współpraca jest niedostępna, a nie wtedy, gdy jest tylko niewygodna. Ukrywa klienta przed każdym przyszłym dochodzeniem, także przed tymi, w których musisz wiedzieć, który laptop otworzył połączenie. Może też psuć protokoły osadzające adresy w ładunku, bo translacja żyje w nagłówku. Żadna z opcji nie jest nowocześniejsza; odpowiadają na różne pytania o własność.

Pytanie trzecie: czy serwer sam jest klientem innego tunelu?

Wyobraź sobie drugą topologię: serwer VPN łączy się też z komercyjnym dostawcą, więc ma dwa tunele i dwa zestawy adresów. Ruch, który przekazuje dla własnych klientów, wychodzi przez dostawcę, a ten nie trasi odpowiedzi z powrotem do adresów puli. Dlatego odpowiedzi znikają, choć oba tunele są zdrowe.

Rozwiązaniem jest maskowanie także tunelu wychodzącego, żeby dostawca widział tylko adres tunelu serwera. Kierunek odwrotny potrzebuje własnej reguły, bo serwer nawiązujący połączenie do własnego klienta to inny przepływ. Bez tej reguły klient odpowiada na adres, którego nie potrafi trasować. Umieść wąską regułę przed każdym szerokim maskowaniem, żeby wygrała konkretna translacja.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Hosty z wieloma interfejsami dodają pokrewną usterkę, która z punktu widzenia klienta wygląda identycznie. Odpowiedź wychodzi interfejsem o niższej metryce, bo adres źródłowy wybrano z innej tablicy. Sprawdź drogę powrotną wyszukaniem, zamiast zakładać, że droga w przód ją implikuje.

Potem sprawdź oba kierunki i oba rozmiary

Po zmianie pinguj od klienta do hosta w sieci LAN, a następnie od hosta w sieci LAN do klienta. Drugi kierunek to ten, który ludzie pomijają, i to on ujawnia niekompletną regułę translacji. Zapisz oba wyniki z sygnaturą czasu, żeby późniejsza regresja była porównywalna.

Potem przenieś prawdziwe dane, bo mały ping, który się udaje, gdy duży transfer stoi, jest objawem MTU. Ta usterka pojawia się zaraz po tym, jak pogratulujesz sobie naprawienia trasy.

Na koniec przetestuj ponownie po restarcie. Polecenia trasy i zapory w czasie działania nie przetrwają go, a poprawka, która znika przy następnym starcie, zostanie zdiagnozowana ponownie przez kogoś z mniejszym kontekstem. Utrwal zmianę tak, jak twój system już to robi, a potem zrestartuj raz celowo.