Gdzie należy trasa w OpenVPN: po stronie klienta czy serwera?
Naga trasa w konfiguracji serwera zmienia serwer, a nie klienta. Wybierz plik klienta, globalny push albo push dla jednego klienta i sprawdź, co dotarło.
Dodajesz route 10.60.0.0 255.255.255.0 do konfiguracji serwera, restartujesz, ponownie łączysz laptop, a podsieć nadal jest nieosiągalna z tego laptopa. Linia została przyjęta, usługa wystartowała czysto i nic w logu nie wygląda źle. Stało się tak, że trasa została zainstalowana na maszynie, którą edytowałeś: brama uważa teraz, że może osiągnąć ten prefiks, podczas gdy klientowi nic nie powiedziano. Umiejscowienie to całe pytanie, a są cztery miejsca, w których ta sama linia może mieszkać.
Cztery miejsca i kto otrzymuje każde z nich
Trasę można dodać przez własną konfigurację klienta, zaproponować każdemu klientowi przez globalny push, zaproponować jednemu klientowi przez plik specyficzny dla klienta albo zapisać w kontekście routingu samego serwera.
Te cztery przypadki używają niemal identycznej składni i dają zupełnie różne rezultaty. Pierwsze trzy wpływają na to, co klient wysyła do tunelu; czwarty wpływa na to, jak serwer dociera do sieci, co jest przydatne, gdy sam serwer potrzebuje ścieżki, a szkodliwe, gdy zostanie pomylone z dystrybucją.
Zdecyduj, który z czterech chcesz, przed napisaniem linii, a następnie potwierdź odbiorcę.
| Placement | Effect | Receiver |
|---|---|---|
| Client profile route | Installed by the client at connect | That client only |
Global push "route ..." | Sent to every client that accepts pushed options | All pulling clients |
| Client-specific push | Sent to the matching client context | One identity |
| Server config route, no push | Added to the server's own table | The gateway itself |
Dlaczego naga trasa serwera zaskakuje ludzi
Konfiguracja serwera to pierwsze miejsce, w które zaglądają administratorzy, a dyrektywa trasy wygląda tam jak stwierdzenie o sieci VPN. To nie jest to. OpenVPN traktuje ją jako lokalną instalację trasy na maszynie, na której działa demon, czyli dokładnie ten sam rodzaj zmiany, jaką zrobiłbyś za pomocą ip route, a potem zapomniał.
Dystrybucja wymaga, aby trasa została wypchnięta przez push, a push wymaga, aby klient ją pobrał. Klient uruchomiony z wyłączonymi pobranymi opcjami całkowicie ignoruje ofertę. Sprawdź oba końce tego uścisku dłoni przed przepisaniem pliku serwera, bo log serwera nie będzie się skarżyć: z jego strony oferta została wysłana. Zaakceptowana trasa wchodzi też w życie dopiero przy następnym połączeniu, nigdy w sesji, w której już jesteś.
Gdy zobaczysz obie operacje jako odrębne, awaria przestaje być tajemnicza: serwer osiąga prefiks, klient nie, i oba stwierdzenia są prawdziwe jednocześnie.
Pliki dla poszczególnych klientów i tożsamość, z którą się zgadzają
Plik specyficzny dla klienta jest nazwany od tożsamości uwierzytelnionej przez serwer, którą domyślnie jest nazwa powszechna certyfikatu. Przyjazna nazwa połączenia w kliencie desktopowym nie jest tą wartością, a niezgodność tworzy plik, który nigdy nie jest czytany.
Sprawdź katalog, którego serwer faktycznie używa, a następnie potwierdź, że nazwa pliku dokładnie odpowiada uwierzytelnionej tożsamości, wraz z wielkością liter.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/W tym pliku trasa nadal musi być wypchnięta przez push, ponieważ kontekst dla pojedynczego klienta to zestaw opcji stosowanych do sesji tego klienta, a nie lokalna tablica routingu. Naga trasa ma tam ten sam problem co naga trasa w pliku globalnym.
Własny plik klienta i narzędzie, które nim zarządza
Trasa umieszczona w konfiguracji klienta jest instalowana przy połączeniu tego klienta i usuwana przy rozłączeniu, co jest właściwym cyklem życia dla statycznego celu.
Jeśli profil należy do menedżera sieci, może on raz zaimportować te opcje, a potem trzymać własną kopię. Edytowanie pobranego pliku później nic nie zmienia, co jest częstą przyczyną "trasa jest, ale nie działa".
Sprawdź aktywny profil, a nie pobrany plik, i sprawdź zaimportowane ustawienia, które pokazuje menedżer. Następnie połącz się i zapytaj system, której ścieżki używa konkretny adres, zamiast zakładać, że tunel wygrał, bo trasa istniała w pliku tekstowym.
Sprawdź na kliencie, a potem sprawdź ścieżkę powrotną
Zapytaj własną tablicę routingu klienta o cel, a nie tablicę serwera. Wyszukanie jednego hosta wewnątrz prefiksu wystarczy, aby pokazać interfejs i następny skok, które zostaną użyte.
ip route get 10.60.0.10Jeśli wyszukiwanie wskazuje tunel, dystrybucja zadziałała, a pozostały problem jest gdzie indziej. Jeśli wskazuje bramę domyślną, trasa nie została zainstalowana, została odfiltrowana przez opcję po stronie klienta lub należy do profilu, którego klient nie używa.
Załóż, że dystrybucja zadziałała, a mimo to nic nie odpowiada: sprawdź wtedy przekazywanie na bramie, trasę powrotną drugiej strony i dowolny firewall między nimi. Trasa wybiera ścieżkę, nie daje dostępu.