Dlaczego podsieć za klientem OpenVPN jest nieosiągalna?

Pingi do adresu tunelu serwera przechodzą, własna tablica tras klienta wygląda poprawnie, a LAN za tym klientem nadal jest nieosiągalny. Tablica tras klienta wygląda poprawnie, serwer ma trasę prowadzącą do tunelu, a pakiety nadal znikają. To klasyczny objaw tunelu layer-3, który nie wie, że jeden z jego klientów jest także bramą.

Interfejs tun nie ma następnego skoku dla każdego klienta. Jądro widzi jeden interfejs z wieloma partnerami, więc decyzja, który klient ma otrzymać pakiet dla zdalnego LAN, musi być podjęta wewnątrz procesu OpenVPN. Ta decyzja jest konfigurowana przez iroute, a bez niej pakiet nie ma dokąd pójść.

Serwer trasuje według klienta, nie według interfejsu

Gdy serwer musi wysłać pakiet na adres tunelu klienta, odpowiedź jest jednoznaczna: adres należy do sesji tego klienta. Gdy celem jest cała podsieć za tym klientem, adres nie należy do nikogo, kogo serwer zna, a trasa jądra do tunelu mówi tylko "przez ten interfejs", nie wskazując którego partnera.

OpenVPN rozwiązuje to wewnętrzną tablicą tras, która przypisuje prefiks celu do konkretnego klienta. Ta tablica jest budowana z wpisów iroute, dlatego zwykła trasa na hoście serwera nie wystarcza. Trasa jądra doprowadza pakiet do interfejsu tunelu; wewnętrzne przypisanie decyduje, która sesja go otrzyma. Dlatego naprawa nigdy nie pojawia się w wyjściu tras jądra.

Jeśli przypisania brakuje, pakiet dociera do serwera, pasuje do trasy tunelu i zostaje odrzucony, bo żaden klient nie rości sobie prawa do celu. Nic nie zapisuje czystego błędu, dlatego awaria wygląda jak cicha czarna dziura, a nie pętla trasowania.

Zapisanie wpisu iroute, który nazywa klienta

iroute mieszka w pliku konfiguracji właściwym dla klienta, a nie w głównej konfiguracji serwera. Wskaż serwerowi katalog opcją client-config-dir, następnie utwórz plik, którego nazwa jest nazwą wspólną certyfikatu klienta, i wpisz do niego prefiks.

Dla oddziału, którego LAN to 10.20.0.0/24, a nazwa wspólna certyfikatu to branch-router, plik pod tą ścieżką zawiera wiersz taki jak iroute 10.20.0.0 255.255.255.0. Główna konfiguracja potrzebuje tylko opcji katalogu; prefiks mieszka u klienta.

Nazwa wspólna to kruchy element. Certyfikat wystawiony z innym subject albo wdrożenie, które uwierzytelnia użytkowników po nazwie użytkownika, podczas gdy plik jest nazwany od certyfikatu, daje plik, który nigdy nie jest czytany. Sprawdź nazwę, którą serwer faktycznie raportuje dla sesji, i rozważ opcję, która sprawia, że niedopasowany klient zawodzi, zamiast po cichu łączyć się bez swoich tras. Zmiana nazwy pliku tak, by pasowała do certyfikatu, to pięciominutowa poprawka, która zapobiega bardzo długiemu wieczorowi.

Jeden klient może posiadać kilka prefiksów. Dodaj jeden wiersz iroute na sieć i trzymaj listę obok pozostałych ustawień tego klienta, aby przypisanie pozostało audytowalne.

Budowanie trasy powrotnej w obu kierunkach

Dostarczanie pakietów do zdalnego LAN to połowa pracy. Klient musi także wysyłać ruch tego LAN do tunelu, co zwykle robi się, wypychając trasę do klienta: wiersz taki jak push "route 10.8.0.0 255.255.255.0" mówi każdemu klientowi, jak dotrzeć do sieci po stronie serwera. Dla oddziału równoważna trasa wskazuje tunel dla wszystkiego, co ma osiągnąć po stronie serwera.

Kierunek powrotny potrzebuje właściciela po drugiej stronie. Tam ktoś musi znać drogę powrotną: statyczna trasa na routerze LAN wskazująca pulę VPN na serwer albo tłumaczenie adresów na serwerze, zanim ruch wejdzie do LAN. Trasa statyczna zachowuje oryginalne adresy widoczne w logach i regułach dostępu, ale wymaga współpracy właściciela LAN; tłumaczenie jest samodzielne, lecz ukrywa, kto naprawdę się połączył.

Przekazywanie musi być włączone na hoście serwera. Bez niego jądro przyjmuje pakiet z tunelu i odmawia przekazania go do interfejsu LAN, co z punktu widzenia klienta wygląda identycznie jak brakujący iroute.

Sprawdzanie osiągalności właściwymi sondami

Testuj warstwami, zamiast pingować drugi koniec i zgadywać. Z serwera sprawdź, że wewnętrzne przypisanie dla prefiksu istnieje i że trasa jądra wskazuje tunel. Z klienta potwierdź, że wypchnięta trasa jest zainstalowana, a jej domyślna droga do adresu LAN to tunel.

Potem obserwuj pakiety. Przechwycenie na interfejsie tunelu pokazuje, czy serwer nadaje w stronę klienta, a przechwycenie na interfejsie LAN pokazuje, czy przekazuje dalej. Jeśli pierwsze pokazuje pakiety, a drugie nic, problemem jest przekazywanie lub filtr; jeśli żadne nic nie pokazuje, wyszukanie nie powiodło się wcześniej.

Dwa serwery połączone tunelem powtarzają tę samą regułę po obu stronach: każdy potrzebuje iroute dla puli drugiego i każdy potrzebuje trasy oraz przekazywania, które czynią drogę symetryczną. Trasowanie i polityka to tutaj odrębne kwestie. Trasowanie decyduje, dokąd pakiet może iść, a reguła FORWARD decyduje, czy wolno, więc klient z dwoma wierszami iroute osiąga oba prefiksy, chyba że filtr mówi inaczej.