OpenVPN na Androidzie nie dodaje trasy bez adresu tunelu

Twój profil OpenVPN na Androidzie nie dodaje trasy, bo telefon nie ma adresu na interfejsie wirtualnym, więc nie ma na co trasa mogłaby wskazywać. Trasy odpowiadają tylko na to, dokąd mają trafić pakiety. Adres tunelu odpowiada na to, kim jest telefon wewnątrz tunelu, i klient musi go dostarczyć, zanim interfejs może powstać. Przejdź cztery sprawdzenia poniżej po kolei i zatrzymaj się na pierwszym błędzie, bo edycja tras przed powstaniem adresu ukrywa prawdziwy problem.

Czytaj błąd w kolejności, w jakiej wykonuje go klient

Androidowy VpnService.Builder trzyma te dwa pojęcia osobno: addAddress() umieszcza adres na interfejsie, który buduje aplikacja, addRoute() dodaje prefiks docelowy, a establish() odmawia utworzenia interfejsu, dopóki nie zostanie dodany co najmniej jeden adres. Klient OpenVPN odwzorowuje profil i opcje wypychane przez serwer dokładnie na te wywołania, więc połączenie, które nigdy nie parsuje adresu, w ogóle nie może zbudować interfejsu.

Dlatego linia logu, którą czytasz, może wymieniać trasę, podczas gdy przyczyna jest o krok wcześniej. Klient dociera do etapu trasy dopiero po powstaniu interfejsu; bez adresu wywołanie trasy od razu zawodzi albo nigdy się nie wykonuje. Gdy log mówi, że nie można dodać trasy, zacznij od adresu, a nie od składni trasy.

Sprawdzenie 1: czy serwer umieszcza adres w odpowiedzi?

W usłudze OpenVPN z routingiem adres pochodzi z puli serwera albo z przydziału dla klienta, a topologia decyduje o jego kształcie. Na serwerze OpenVPN 2.4 lub nowszym usługa z topologią podsieci wygląda tak:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

Przy takim kształcie serwer wypycha coś w rodzaju ifconfig 10.8.0.6 255.255.255.0. Starsze wdrożenie z topology net30 wypycha zamiast tego adres peera, na przykład ifconfig 10.8.0.6 10.8.0.5, więc profil przeniesiony między dwoma modelami może wyglądać poprawnie, nosząc niewłaściwą maskę sieci.

Poszukaj w logu połączenia klienta zestawu wypchniętych opcji. Jeśli nie ma w nim ani jednej linii ifconfig, serwer nigdy nie wysłał adresu albo klient odrzucił opcję. Na serwerze używającym client-config-dir plik nazwany według common name certyfikatu musi istnieć i zawierać przydział:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Sprawdzenie 2: czy klient zachowuje otrzymany adres?

Zbyt szeroki filtr to druga częsta przyczyna. pull-filter istnieje w OpenVPN 2.4 i nowszym, a gdy kilka filtrów pasuje do tej samej opcji, wygrywa ostatni pasujący, więc catch-all na końcu usuwa adres bez błędu:

# removes every pushed option, including the address
pull-filter ignore "ifconfig"
pull-filter ignore "route"

Zawęź filtr do opcji, której naprawdę chcesz się pozbyć, i zostaw adres w spokoju:

# keeps the pushed address, drops one unwanted LAN route
pull-filter ignore "route 10.60.0.0"

Rada, by wyłączyć wszystkie pull, zwykle pochodzi od kogoś, kto chce pozbyć się jednej trasy. route-nopull to węższy przełącznik: zachowuje ifconfig i pozostałe wypchnięte opcje, a odrzuca wypchnięte trasy i opcje w stylu DHCP. Użyj go, gdy naprawdę tego chcesz, a kwestię adresu rozstrzygnij osobno.

Sprawdzenie 3: czy adres jest twój do wpisania?

Ręczne adresowanie jest uzasadnione tylko wtedy, gdy operator przekazuje ci wartość. Jeśli wpiszesz adres sam, musi on pochodzić z podsieci klienta VPN, być unikalny wśród aktywnych sesji i pasować do topologii, którą uruchamia serwer. Kopiowanie adresu mostu stacjonarnego lub hosta w zdalnej sieci LAN zawodzi z obu powodów: telefon zażądałby adresu, który już istnieje gdzie indziej, a brama nie miałaby drogi powrotnej do niego.

Prefiks zdalnej sieci LAN w trasie jest celem, nigdy tożsamością telefonu. Trasa dla 10.60.0.0/24 mówi, żeby dotrzeć do tej sieci przez tunel; nie mówi nic o tym, który adres 10.60.0.x telefon powinien mieć, a telefon nie powinien mieć żadnego z nich. Przydziały statyczne należą do strony serwera, gdzie nie mogą kolidować z pulą dynamiczną.

Dwie sesje na jednej tożsamości ujawniają tę samą kolizję. Jeśli ten sam certyfikat łączy się dwa razy, a serwer wypycha jeden stały adres do obu, druga sesja duplikuje pierwszą, a rozwiązaniem są osobne tożsamości lub osobne przydziały, a nie zmiana po stronie klienta.

Sprawdzenie 4: czy coś innego zajmuje miejsce tunelu?

Android pozwala na jedną aktywną usługę VPN naraz. Inna aplikacja VPN albo wpis zawsze włączonego VPN pozostawiony dla profilu, który już nie działa, może zająć to miejsce, zanim twój klient OpenVPN wywoła establish(). Wtedy interfejs nigdy się nie pojawia, choć profil jest poprawny, więc rozłącz drugi VPN, wyłącz ustawienie zawsze włączonego i połącz się ponownie, zanim dotkniesz profilu.

Usługa wymagająca mostkowania Ethernet to druga ślepa uliczka. Aplikacja Android bez roota może utworzyć tunel IP, a nie mostkowany segment Ethernet, więc żaden wpisany adres nie uruchomi serwera dev tap; operator musi zaproponować usługę z routingiem. Zgłaszając problem, podaj nazwę i wersję klienta, zestaw wypchniętych opcji, topologię oraz dokładny krok, w którym adres powinien się pojawić.

Jeśli wszystkie cztery sprawdzenia przejdą, a adres istnieje, jest unikalny i poprawnie zamaskowany, pytanie o trasę staje się zwyczajne: które prefiksy serwer autoryzuje i jak klient powinien je ograniczyć. Zapisz adres tunelu, jego maskę sieci i topologię, zanim zmienisz cokolwiek innego, bo to właśnie te trzy wartości operator musi porównać z widokiem serwera.