Trasy wypychane przez OpenVPN nie są instalowane: czas, uprawnienia lub polityka

Serwer twierdzi, że wypchnął trasę, klient twierdzi, że jest połączony, a cel nadal jest nieosiągalny. Dokładnie taki obraz dają trzy przyczyny. Dodawanie trasy uruchomiło się, zanim urządzenie istniało, klientowi brakowało uprawnień do zmiany tabeli albo polityka kazała klientowi ignorować wypchnięte opcje.

Z zewnątrz wyglądają identycznie i wymagają różnych poprawek. Przeczytaj dziennik klienta w miejscu, w którym zapada decyzja o trasie.

Udowodnij, że trasy nie ma, a nie tylko że jest zepsuta

Zacznij od udowodnienia, że trasy nie ma, a nie że jest zepsuta. W systemie Linux ip route show dev tun0 wylicza, co klient zainstalował na urządzeniu tunelowym. W systemie Windows route print lub Get-NetRoute pokazuje to samo w formie tabeli.

Trasa, która istnieje, ale nie przekazuje ruchu, to inny problem. To przenosi dochodzenie do reguł przekazywania i zapory sieciowej, a nie do instalacji trasy.

Czas: dodawanie uruchomiło się, zanim urządzenie istniało

Klient analizuje PUSH_REPLY serwera po tym, jak kanał kontrolny jest podniesiony i jak skonfigurował interfejs. Dopiero wtedy dotyka tabeli routingu, używając mechanizmu, który zapewnia platforma. Linux przechodzi przez netlink; Windows używa API, które wymaga podniesionego tokenu. Skrypt lub klient, który dodaje trasy zaraz po odczytaniu konfiguracji, może uruchomić się, zanim urządzenie TUN/TAP istnieje, a jądro odrzuca dodanie.

Ten sam wyścig wyjaśnia, dlaczego trasa wpisana ręcznie działa, a automatyczna nie: zanim ją wpiszesz, interfejs jest już podniesiony.

route-delay istnieje właśnie dla tego przypadku, a route-up wskazuje skrypt uruchamiany po skonfigurowaniu interfejsu i tras. Trasy zależne od adresu tunelu umieść w tym haczyku, a nie na wczesnym etapie.

Uprawnienia: kto może zmienić tabelę

Zmiana tabeli routingu systemu Windows wymaga podniesionego tokenu. GUI uruchomione przez zwykłego użytkownika może ustawić adres adaptera przez usługę i nadal nie móc dodać trasy. Dziennik pokazuje wtedy błąd w stylu odmowa dostępu, a nie brakujące wypchnięcie.

Uruchomienie GUI jako administrator albo użycie klienta opartego na usłudze zmienia ten wynik. Zaplanowane zadanie, które uruchamia klienta bez wymaganego tokenu, nie zmienia.

Przed zmianą czegokolwiek sprawdź, na jakim koncie klient naprawdę działa. Wersja i tryb usługi decydują, jakie przyczyny są w ogóle możliwe, więc zapisz oba obok wyniku trasy.

Polityka: wypchnięte trasy można celowo odrzucić

route-nopull sprawia, że klient ignoruje trasy wypychane przez serwer, w tym wypchniętą trasę domyślną, podczas gdy adres tunelu jest nadal akceptowany. Wypchnięte opcje DNS i DHCP są odrzucane przez tę samą dyrektywę. Taki klient nie jest wadliwy; oczekuje jawnych wierszy tras we własnej konfiguracji.

route-noexec to inna kontrola: całkowicie powstrzymuje klienta przed wykonywaniem zmian tras. Topologia, której klient nie potrafi zmapować, może dać podobny wynik, a trasa jest rejestrowana jako odrzucona, a nie dodana. Przeczytaj wiersz dziennika, który zgłasza decyzję, zamiast zgadywać, która z trzech przyczyn zachodzi. Następnie sprawdź efektywny profil, ponieważ importer lub narzędzie zarządzające może dodać opcje, których użytkownik nigdy nie edytował.

Profil, który w edytorze tekstu wygląda czysto, nadal może zawierać dodaną dyrektywę w czasie działania.

Porównaj listę wypychania z tabelą

Po połączeniu połóż listę wypychania serwera obok tabeli klienta. W systemie Linux to ip route show dev tun0; w systemie Windows route print lub Get-NetRoute. Jeśli trasy nie ma, najpierw napraw instalację. Jeśli istnieje, a ruch zawodzi, przejdź do polityki przekazywania i zapory sieciowej.

Zapisz wersję klienta, konto, na którym działa, i to, czy jest oparty na usłudze. Te trzy fakty powiedzą następnej osobie, które przyczyny zostały wykluczone.