OpenVPN iroute a trasa jądra: której brakuje?
Serwer ma trasę, a ruch nadal staje. Jedna decyzja o ścieżce należy do jądra, druga do peera; dowiedz się, której brakuje i co sprawdzić.
Pakiet do 10.77.20.0/24 podejmuje na serwerze OpenVPN dwie odrębne decyzje: system operacyjny musi przekazać go interfejsowi VPN, a OpenVPN musi wiedzieć, który podłączony klient posiada ten prefiks. Brak trasy w jądrze odrzuca go przed tunelem, brak trasy peera odrzuca go potem. Oba błędy wyglądają z odległej sieci LAN identycznie, a rozstrzygnięcie, który masz, wymaga po jednym poleceniu po każdej stronie.
W klasycznej ścieżce danych w przestrzeni użytkownika trasa jądra wprowadza pakiet do procesu tunelu, a iroute mówi temu procesowi, który peer ma go odebrać. Żadna nie zastępuje drugiej, a konfiguracja z tylko jedną z nich będzie wyglądać rozsądnie aż do pierwszego ping.
Dwie decyzje, nie jedna trasa
Wyobraź sobie łącze między lokalizacjami, w którym 10.77.20.0/24 leży za jednym klientem. Trasa jądra serwera, na przykład ip route add 10.77.20.0/24 dev tun0, wysyła pasujące pakiety do urządzenia tunelu. Następnie OpenVPN zagląda do własnej wewnętrznej tabeli, zbudowanej z wpisów iroute w katalogu konfiguracji klienta, aby zdecydować, które połączenie peera je odbierze. Bez trasy jądra pakiet nigdy nie dociera do procesu, a bez trasy peera dociera do procesu i nigdzie nie idzie.
Ten podział łatwo zapomnieć, bo jedna linia trasy w profilu klienta może wyglądać, jakby wykonywała obie prace. Nie wykonuje: wypchnięcie trasy mówi klientom, co wysyłać przez tunel, podczas gdy iroute mówi serwerowi, kto posiada zakres adresów za klientem. Żyją w różnych plikach, są czytane przez różne strony i zawodzą w przeciwnych kierunkach.
Gdzie należy iroute i co mówi
Wpis trafia do pliku dla pojedynczego klienta nazwanego według common_name klienta, w katalogu client-config-dir, jako iroute 10.77.20.0/24. Zgodność nazwy pliku nie jest kosmetyczna: OpenVPN wyszukuje uwierzytelnioną tożsamość i czyta plik dokładnie o tej nazwie, więc plik o nazwie site-a działa tylko dla klienta, którego nazwa wspólna to site-a. Dodaj ccd-exclusive, jeśli klienci bez takiego pliku mają być całkowicie odrzucani, co jest właściwym ustawieniem, gdy każdy klient jest bramą lokalizacji. Trzymaj jeden plik na bramę i nazywaj go według podmiotu certyfikatu, który rzeczywiście wystawiasz.
Przetestuj wpis z serwera, zanim obwinisz odległą sieć LAN. Plik statusu wymienia podłączonych klientów wraz z ich nazwami wspólnymi, a serwer uruchomiony z --verb 4 zapisuje w dzienniku instalację iroute w chwili łączenia się peera. Jeśli przy połączeniu nic się nie pojawia, plik jest w złym katalogu albo podaje złą tożsamość.
Pułapka: plik jest, tożsamość błędna
Poprawnie wyglądający iroute przypięty do złego peera marnuje więcej czasu niż brakujący plik, bo wszystko na dysku wygląda dobrze. Zmiana nazw certyfikatów, zduplikowane nazwy wspólne i username-as-common-name zmieniający efektywną tożsamość wszystko to powodują. Sprawdź, jaką tożsamość uwierzytelnił serwer, a nie jakiej oczekiwałeś: wynik statusu jest rozstrzygający, a nazwa pliku to tylko klucz wyszukiwania.
Trasa może przeżyć swojego właściciela. Trasy statyczne i wpisy iroute opisują prefiks, a nie gwarancję dostępności, więc ruch może nadal być kierowany do peera, który jest obecnie odłączony.
Dokończ ścieżkę za peerem
Własność peera to środek ścieżki, nie koniec. Klient musi przekazywać pakiety z tunelu do swojej sieci LAN, co oznacza włączone przekazywanie IP na tym hoście i regułę zapory, która pozwala na przejście. Hosty w odległej sieci LAN potrzebują drogi powrotnej dla adresu tunelu: albo trasy wskazującej z powrotem na bramę, albo świadomie zaprojektowanego NAT po stronie klienta. Potwierdź ustawienie przekazywania na kliencie za pomocą sysctl net.ipv4.ip_forward, zamiast zakładać domyślną wartość dystrybucji.
Jeśli inni klienci VPN mają docierać do tej podsieci, układ znów rośnie: serwer potrzebuje client-to-client, a ci klienci muszą trasować prefiks przez tunel. Nic z tego nie wynika z własnej tabeli tras serwera.
Zweryfikuj jeden cel z rzeczywistego źródła, a nie z samego serwera. Ping z niepowiązanego hosta LAN do hosta za klientem ćwiczy drogę powrotną, regułę przekazywania i własność peera w jednym ruchu, podczas gdy udany handshake dowodzi tylko tożsamości. Następnie odłącz peera-właściciela i zanotuj, co robi trasa, bo ta odpowiedź jest twoim trybem awarii.