Który komponent naprawdę posiada limit tras OpenVPN?

Profil z dwustu trasami działa na jednej maszynie, a na innej instaluje czterdzieści. Silnik, integracja, która go uruchamia, i serwer, który go karmi, mają coś do powiedzenia, i każdy z nich może zatrzymać listę w innym punkcie. Czytanie awarii jako jednego limitu prowadzi do niewłaściwego pliku. Mechanizm ma trzy etapy, a etap, który się zatrzymał, zostawia widoczne ślady, gdy wiesz, czego szukać.

Trzy etapy, trzy różne limity

Najpierw silnik analizuje opcję i decyduje, czy ta wersja ją rozumie. Potem integracja instaluje to, co zgłasza silnik, a jej własny kod może ograniczyć lub przekształcić listę. Na koniec serwer decyduje, ile tras wyśle do danej tożsamości, zanim jakikolwiek etap klienta cokolwiek zobaczy. Trzy etapy, trzy pułapy, i tylko jeden z nich jest liczbą w profilu.

Podniesienie jednego pułapu nic nie robi dla pozostałych. Odrzucona wysłana trasa może być decyzją polityki na serwerze, nakładką, którą rozwiązał klient, albo limitem instalatora, który wyrzucił nadmiar. Każdy z tych przypadków ma inne rozwiązanie.

Rozdziel te trzy, zanim cokolwiek zmierzysz. Błąd parsera nazywa token, limit instalatora zostawia krótką tabelę tras, a decyzja polityki nie zostawia niczego. Ślady mówią, który etap sprawdzić najpierw.

Parser mówi pierwszy

Nieznana opcja zawodzi głośno i wcześnie, a tekst błędu nazywa token. To najłatwiejszy do rozpoznania etap: porównaj dokładny komunikat z zainstalowaną wersją silnika, bo opcja dodana w jednym wydaniu jest nieznana w poprzednim. Profil skopiowany z nowszego wdrożenia jest zwykłym źródłem tej niezgodności. Parser nigdy po cichu nie ignoruje dyrektywy, której nie rozpoznaje.

Zaakceptowana opcja nic nie mówi o wyniku. Analiza się udaje, a lista nadal może zostać przycięta przez instalatora albo nigdy nie zaproponowana przez serwer. Traktuj czystą analizę jako pozwolenie na dalsze kroki, nie jako dowód.

Zapisz ciąg wersji z binarki, która faktycznie działała, a nie z wyobrażenia menedżera pakietów o tym, co jest zainstalowane. Te dwa nie zgadzają się częściej, niż się oczekuje.

Instalator ma własny pułap

Komponent, który odpowiada za aktywację, może być wtyczką NetworkManager, a nie binarką silnika, i może narzucić własny limit, zanim powstanie jakikolwiek tunel. Jego edytor może pokazywać pole, którego działający silnik nigdy nie czyta, albo czytać pole, którego edytor nie pokazuje. Obie sytuacje z zewnątrz wyglądają jak błąd klienta. Żadnej nie naprawia edycja profilu.

Licz to, co dotarło, a nie to, co skonfigurowano. Polecenie ip route show dev tun0 wyświetla zainstalowane trasy, a porównanie tej liczby z wysłaną listą oddziela trasę odrzuconą od tej, której nigdy nie wysłano. Liczba zgodna z wysyłką kieruje podejrzenie z powrotem na serwer.

Otoczka powłoki wokół binarki silnika, wymuszająca większą liczbę, zaciemnia aktualizacje i zamienia wycofanie w zgadywanie. Ukrywa też prawdziwy limit przed każdym, kto przeczyta konfigurację następnym razem.

Serwer decyduje, co ci zaproponowano

Polityka dla każdego klienta może zmniejszyć listę przed przesłaniem. Plik właściwy dla klienta może dodać trasy dla jednej tożsamości albo polityka grupowa może je pominąć, a klient nie potrafi odróżnić trasy odfiltrowanej od takiej, której nigdy nie zdefiniowano. Właśnie ta niejednoznaczność sprawia, że zapis serwera jest ważny. Proś o faktyczną listę wysyłki dla tej tożsamości, nie o szablon.

Porównaj zapis serwera z otrzymaną listą. Luka między nimi to warstwa polityki, i zwykle jest mniejsza, niż sugeruje profil.

Gdy projekt na to pozwala, uogólnij sąsiednie sieci i usuń przestarzałe wpisy. Mniej i większych tras rozwiązuje więcej przypadków niż wyższy pułap.

Zmień liczbę we właściwym miejscu

Użyj udokumentowanego ustawienia komponentu, który naprawdę posiada limit. Jeśli w wtyczce brakuje pola, sprawdź, czy wtyczka jest starsza od funkcji albo czy trasy posiada inny backend. Następnie udokumentuj wersje silnika, wtyczki i serwera obok wybranej wartości. Kolejna aktualizacja otwiera pytanie ponownie, i właśnie notatka czyni je odpowiadalnym.

Testuj ponownie po każdej aktualizacji któregokolwiek z trzech. Limit podniesiony we właściwym miejscu i tak się przesuwa, gdy zmienia się komponent, który go egzekwuje. Zapis wersji to jedyna rzecz, która czyni ten ruch przewidywalnym.