OpenVPN nadal wypycha stare trasy? Sprawdź, co wczytał

Dodajesz trasę, restartujesz usługę, łączysz się ponownie, a tabela klienta wygląda dokładnie tak jak wcześniej. Mogą być prawdziwe dwie różne rzeczy: serwer nie wczytał Twojej zmiany albo klient nie zainstalował tego, co otrzymał. Nie mają ze sobą nic wspólnego poza objawem, więc pierwszym krokiem jest ustalenie, który z dwóch przypadków masz.

Poniższe porównanie idzie od procesu na zewnątrz, ponieważ proces jest jedynym autorytetem co do tego, który plik obowiązuje.

Plik, który edytowałeś, i plik, który czyta proces

Zacznij od unit i wiersza poleceń, który wygenerował. Na hoście systemd systemctl cat openvpn@server wypisuje wiersz ExecStart, a unit instancji zwykle wywodzi ścieżkę konfiguracji z nazwy instancji, więc demon uruchomiony jako openvpn@office czyta inny plik niż uruchomiony jako openvpn@server. Porównaj to z argv działającego procesu. Narzędzie do zarządzania konfiguracją dodaje jeszcze jeden sposób utraty zmiany: może zapisać poprawny plik w miejscu, którego unit nigdy nie wymienia, i wtedy udane wdrożenie wygląda jak nic.

Znaczniki czasu rozstrzygają to szybko: jeśli plik jest nowszy niż czas uruchomienia procesu, proces nie mógł go przeczytać. Firmware routera dodaje trzeci przypadek, bo wiele modeli trzyma ustawienia w pamięci flash i odbudowuje konfigurację podczas rozruchu, co czyni edycję pliku na dysku całkowicie niewłaściwą warstwą.

Co wypycha serwer i co instaluje klient

Wypchnięta trasa musi przejść przez dwa filtry. Na serwerze musi znajdować się w wczytanej konfiguracji, a nie w zakomentowanym bloku ani w pliku specyficznym dla klienta, którego nazwa się nie zgadza. Na kliencie pull musi być włączone, a żaden pull-filter nie może odrzucać tej opcji. Połącz się z verbosity 4 i odczytaj wypchnięte opcje, które zgłasza klient: jeśli trasa jest na tej liście, serwer zrobił swoje, a klient wybiera, żeby jej nie instalować.

Pliki specyficzne dla klienta są częstym źródłem zamieszania. Plik nazwany według common name certyfikatu wypycha opcje tylko do tego klienta, a różnica jednego znaku po cichu zatrzymuje wypychanie, bez błędu po żadnej stronie. Serwer zapisuje w logu common name, który zobaczył przy połączeniu, więc porównaj tę wartość z nazwą pliku, a nie z tym, jak sądzisz, nazywa się klient.

Wypchnięty prefiks i trasa powrotna to różne problemy

Klient, który celowo ignoruje redirect-gateway, aby zachować własną lokalną drogę do internetu, tworzy drugą, niezwiązaną lukę. Sondy serwera docierają do adresu tunelu, ale odpowiedzi nigdy nie nadchodzą, ponieważ odpowiedź zaadresowana do IP tunelu serwera jest routowana przez zwykłą bramę domyślną klienta. Wypchnięta trasa podsieci nie jest tu winna; brakuje trasy, która odsyła ruch do sieci tunelu serwera z powrotem przez urządzenie tunelowe.

Dodanie tej trasy na kliencie naprawia odpowiedzi na sondy inicjowane przez serwer. Nie zastępuje wypchniętej trasy podsieci i odwrotnie też tak jest, ponieważ obie opisują przeciwne kierunki ruchu.

Porównaj tabele na obu końcach

Po każdej zmianie połącz się ponownie i odczytaj tabelę klienta dla wypchniętego prefiksu i dla urządzenia tunelowego. Następnie przetestuj w obu kierunkach: od klienta do hosta w wypchniętej podsieci i od tego hosta z powrotem do klienta. Trasa, która istnieje, ale nie przenosi ruchu, oznacza jedno z trzech: druga strona nie przekazuje, firewall odrzuca przepływ albo odpowiedź nie ma drogi powrotnej.

Trzymaj razem trzy identyfikatory: ścieżkę konfiguracji, nazwę unit lub instancji i tożsamość klienta, z którym testowałeś.

Te trzy zamieniają następne zdarzenie w pięciominutowe sprawdzenie zamiast kolejnego dochodzenia, i właśnie ich potrzebuje kolega, gdy tunel staje się czyimś innym problemem.

Problem z trasą, który przeżywa restart, często wcale nie jest problemem routingu; usterka leży wyżej niż tabela, którą wciąż czytasz.