Router LAN i klient VPN: dwa urządzenia, dwie tablice routingu

Dwa urządzenia przekazują pakiet dalej i każde prowadzi własną tablicę. Router LAN wie, że zdalny prefiks należy do klienta VPN, a klient VPN wie, jak dotrzeć do tego prefiksu przez swój tunel. Skonfiguruj tylko pierwszą tablicę, a pakiet dotrze do maszyny bez pasującej trasy, więc wyjdzie ponownie przez trasę domyślną. To cała usterka, a z perspektywy LAN wygląda jak pętla routingu, bo prawie nią jest.

Narysuj oba skoki, zanim dotkniesz trasy

Weź ilustracyjny układ: hosty LAN na 192.168.50.0/24, zwykły router na 192.168.50.1, dedykowany klient na 192.168.50.15 i zdalny LAN na 10.60.0.0/24 osiągalny tylko przez tunel, który trzyma ten klient. Żaden z dwóch zakresów prywatnych nie nakłada się na drugi, a tunel ma własny plan adresacji.

Oba zakresy prywatne mają znaczenie, bo decydują, które urządzenie może odpowiedzieć. Strona zdalna zobaczy pakiet przychodzący z adresu tunelu klienta, a jej odpowiedź musi znaleźć drogę z powrotem do 192.168.50.0/24. Jeśli skonfigurowano tylko kierunek wychodzący, żądanie może działać, podczas gdy odpowiedź znika.

Krok 1: skieruj router na klienta, a nie na tunel

Na routerze LAN dodaj trasę docelową, której następnym skokiem jest adres LAN klienta:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Ten wpis mówi „dostarcz to do maszyny, która potrafi tunelować”. Nie mówi nic o tym, jak zbudowany jest tunel, i nie zastępuje własnej trasy klienta. Na routerze zarządzanym odpowiednik żyje na stronie tras statycznych urządzenia; na routerze Linux należy do konfiguracji interfejsu, który posiada LAN, a nie do powłoki, którą zamkniesz.

Sprawdź odpowiedź drugiego polecenia. Jeśli zgłasza klienta jako gateway, a interfejs LAN jako device, pierwszy skok jest poprawny, a reszta pracy jest na drugiej maszynie.

Krok 2: daj klientowi własną trasę po stronie tunelu

Klient otrzymuje teraz pakiet dla 10.60.0.0/24 i zagląda do własnej tablicy. Jeśli jego konfiguracja tunelu zainstalowała trasę dla tego prefiksu, pakiet jedzie dalej zaszyfrowany. Jeśli nie, pakiet pasuje do zwykłej trasy domyślnej i wraca do 192.168.50.1, który wysyła go ponownie do klienta.

Spójrz, zanim coś dodasz:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

Brak trasy prefiksu we wszystkich tablicach to znalezisko, którego szukasz. Dodaj ją przez własną konfigurację tunelu, aby następne ponowne połączenie zainstalowało ją ponownie; ręczna ip route add znika wraz z sesją i sprawia, że usterka wraca w najmniej dogodnym momencie. Następnym skokiem jest interfejs tunelu albo adres, który VPN przydziela jako swojego peera, w zależności od klienta, a adres peera powinien pochodzić z bieżącego profilu, a nie ze starej notatki.

Pętla, gdy wystąpi, w praktyce nie jest nieskończona: TTL spada przy każdym przejściu, a pakiet ginie z komunikatem o przekroczeniu czasu. Dlatego powtarzany traceroute może sugerować cykl, podczas gdy klient, który po prostu nie przekazuje, po cichu porzuca ten sam pakiet.

Krok 3: zezwól na przekazywanie i wybierz drogę powrotną

Odbieranie i przekazywanie to różne uprawnienia. net.ipv4.ip_forward=1 na kliencie zezwala na tranzyt na poziomie jądra, a reguła firewalla nadal musi go zezwolić między interfejsem LAN a tunelem. Reguła, która zezwala na dostęp do własnej strony administracyjnej klienta, nie zezwoli na tranzyt do zdalnego LAN, a tę różnicę łatwo przeoczyć, gdy ten sam host odpowiada na pingi lokalnie.

Strona zdalna ma problem lustrzany. Musi wiedzieć, że 192.168.50.0/24 jest osiągalny przez tego uwierzytelnionego klienta. Z OpenVPN to zwykle oznacza trasę na klienta wypychaną przez konfigurację serwera albo plik specyficzny dla klienta na serwerze, który deklaruje LAN za klientem. Bez tego zdalny LAN albo porzuca odpowiedź, albo wysyła ją do własnej bramy domyślnej, czyli do internetu.

Tłumaczenie źródła jest alternatywą, gdy prefiksu LAN nie można ogłosić. Ograniczona reguła masquerade na kliencie przepisuje źródło na adres tunelu, a odpowiedzi wracają wtedy naturalnie. Ukrywa też, który host LAN złożył żądanie, i sama z siebie nie pozwala stronie zdalnej inicjować połączeń do wewnątrz. Wybierz ten kompromis świadomie, zamiast dodawać ogólne masquerade i odkrywać skutek uboczny później.

Krok 4: utrwal obie decyzje, a następnie przetestuj rzeczywistą drogę

Każda trasa ma właściciela, a właścicielem jest konfiguracja, która odtwarza się przy starcie lub przy ponownym połączeniu. Na routerze może to być wpis trasy statycznej; na kliencie może to być profil VPN, NetworkManager lub systemd-networkd. Zweryfikuj, ponownie łącząc tunel i restartując klienta, a potem przeczytaj tablicę jeszcze raz, zamiast ufać zmianie.

Zachowaj nienaruszoną trasę domyślną, która niesie zewnętrzne połączenie tunelu. Zastąpienie jej, aby „uprościć” konfigurację, psuje zaszyfrowaną drogę, zanim jakikolwiek ruch wewnętrzny zdąży jej użyć, a objawem jest tunel, który po zmianie nigdy się nie odtwarza.

Testuj ze zwykłego hosta LAN, nie z klienta, ponieważ żądanie powstałe na kliencie nigdy nie ćwiczy pierwszego skoku routera. Pobierz usługę, która istnieje tylko w zdalnym LAN, i potwierdź treść odpowiedzi, a następnie sprawdź liczniki lub logi klienta, aby zobaczyć tranzyt. Wewnętrzny traceroute pokazujący prywatne skoki dowodzi przekazywania, nie szyfrowania: droga zewnętrzna to osobna obserwacja, a tylko liczniki interfejsu tunelu pokazują, co przez niego wyszło.