Android OpenVPN: dodanie prywatnej trasy bez rootowania telefonu

Potrzebujesz jeszcze jednej prywatnej podsieci — powiedzmy 10.60.0.0/24 — której profil obecnie nie zawiera. Na laptopie dodałbyś trasę i poszedł dalej. W Androidzie VPN jest aplikacją, urządzenie tun należy do tej aplikacji, a bez roota nie ma tabeli routingu do edycji. Trasa nadal musi istnieć, ale trafia do profilu, który wczytuje klient, i działa tylko wtedy, gdy druga strona się zgadza. Oto zmiana, ponowne połączenie, strona serwera i wycofanie.

Przed zmianą: co trasa może, a czego nie może

Trasa odpowiada na jedno pytanie: który interfejs ma nieść ruch do tego celu. Nic nie autoryzuje. Jeśli właściciel sieci nie zgodził się, że ten telefon może dotrzeć do tej podsieci, poprawna trasa daje konfigurację, która wygląda poprawnie, i ciche odrzucenie na bramie, a kolejną godzinę spędzisz, edytując niewłaściwy plik.

Najpierw zdobądź tę zgodę, pisemnie, jeśli sieć ma właściciela. Potem zanotuj, czego nie robisz: nie przypisujesz telefonowi adresu w tym LAN-ie, nie zmieniasz listenera serwera i nie wybierasz witryny po nazwie hosta. To cztery różne zmiany i tylko pierwsza jest twoja.

Edytuj profil, który klient naprawdę wczytuje

Dla zgodnego klienta, który importuje zwykły tekst opcji OpenVPN, dodatek to jedna linia:

route 10.60.0.0 255.255.255.0

Dodaj ją do treści profilu, obok pozostałych dyrektyw routingu, a endpoint, certyfikaty, obsługę kluczy i linie weryfikacji operatora zostaw dokładnie takie, jakie były. Nie wklejaj całego starego przykładu, żeby pożyczyć jedną linię: kompresja, bezwzględne ścieżki plików i przestarzałe ustawienia cipher podróżują razem i będą kosztować osobną sesję debugowania.

Krok, który ludzie pomijają, to własność pliku. Jeśli aplikacja zaimportowała profil, kopia, której używa, należy do aplikacji, a edycja pobranego oryginału niczego nie zmienia. Użyj edytora obsługiwanego przez klienta albo ponownie zaimportuj edytowany plik przez ścieżkę aktualizacji, i potwierdź nazwę aktywnego profilu, gdy istnieje kilka podobnych nazw. Zapisz, który zmieniłeś.

Jeśli profil już zawiera route-nopull, żadna trasa z serwera nie jest instalowana i każdy prefiks potrzebny telefonowi musi być wymieniony jawnie. To uzasadniony projekt, ale oznacza, że pominięta linia wygląda dokładnie jak odmowa serwera.

Połącz się ponownie i zweryfikuj na urządzeniu

Najpierw rozłącz, potem połącz ponownie właśnie ten profil, który edytowałeś, zamiast pozwalać aplikacji przywrócić ostatnią sesję. Otwórz dziennik połączenia i potwierdź, że klient przetworzył nową linię; dyrektywa routingu ignorowana przez interfejs to częsty skutek edycji niewłaściwej kopii.

Testuj cel po adresie, nie po nazwie. Sprawdzenie TCP na jeden znany port usługi mówi więcej niż ping, bo wiele hostów odpowiada na ICMP, podczas gdy port usługi jest filtrowany. Jeśli adres odpowiada, a nazwa nie, masz pytanie o resolver, a nie o routing, i następna sekcja nie jest dla ciebie.

Należą tu też dwie kontrole zasięgu. VPN na aplikację oznacza, że trasa adresowa może istnieć, podczas gdy aplikacja, którą testujesz, jest poza uwzględnionym zbiorem, więc testuj aplikacją, która naprawdę jest w środku. A prefiks IPv4 nic nie mówi o ścieżce IPv6; jeśli usługa jest dual-stack, dodaj odpowiednią trasę IPv6 albo spodziewaj się, że klient wybierze ścieżkę, której nie zamierzałeś.

Jeden wynik negatywny warto rozpoznać wcześnie: jeśli trasa full-tunnel już obejmuje 0.0.0.0/0, prefiksu nie brakuje, a dodanie go ponownie niczego nie zmienia. Podwójne pokrycie nie naprawia odmowy po stronie serwera ani brakującej odpowiedzi.

Dokończ ścieżkę na serwerze

Trzy rzeczy muszą być prawdziwe poza telefonem. Brama potrzebuje trasy do celu i zgody na przekazywanie źródła telefonu w jej stronę. Cel musi akceptować to źródło i zwracać odpowiedzi przez bramę, inaczej projekt wymaga świadomego tłumaczenia na wyjściu. Opcja route z podręcznika OpenVPN obejmuje dyrektywę po stronie klienta; przekazywanie i routing powrotny to osobne ustawienia na osobnych maszynach.

Jeśli cel znajduje się za innym klientem VPN, a nie bezpośrednio za bramą, serwer potrzebuje iroute dla podsieci tego peera. Ta dyrektywa należy do serwera i opisuje, który klient posiada prefiks; telefon nie może jej dostarczyć z własnego profilu i żadna ilość edycji po stronie klienta jej nie zastąpi.

Sprawdź jawnie ścieżkę powrotną. Odpowiedź wychodząca trasą domyślną zamiast tunelem daje klasyczny objaw na wpół otwartego połączenia: połączenie nawiązuje się w jedną stronę i nic nie wraca. Tłumaczenie źródła na bramie jest uzasadnioną poprawką, gdy cel nie może routować z powrotem, ale to decyzja polityki z własnymi konsekwencjami.

Wycofanie i akceptacja

Zachowaj poprzedni profil przed edycją. Jeśli zmiana pogorszy sytuację, przywróć tę kopię tą samą ścieżką ponownego importu, połącz się ponownie i potwierdź, że stare zachowanie wraca — to potwierdza, że zmieniłeś to, co myślałeś, że zmieniasz. Wycofanie, które nie przywraca starego stanu, oznacza, że aplikacja trzyma trzecią kopię, której nie znalazłeś.

Zaakceptuj zmianę, gdy spełnione są cztery warunki, sprawdzone w tej kolejności po świeżym połączeniu: cel odpowiada na swoim porcie usługi, prywatna nazwa rozwiązuje się, jeśli jest oczekiwana, HTTPS nadal waliduje zamierzoną nazwę hosta i całość nadal działa po restarcie lub przejściu z Wi-Fi na sieć komórkową. Ostatnia kontrola wyłapuje trasę, która istnieje tylko do chwili, gdy Android odtworzy tunel.

• Przed jakąkolwiek edycją potwierdź, że właściciel sieci dopuszcza cel.
• Umieść trasę w profilu, który wczytuje klient, a potem zaimportuj ponownie i połącz się.
• Zweryfikuj przez port usługi, w zasięgu na aplikację, dla właściwej rodziny adresów.
• Napraw przekazywanie, routing powrotny i iroute na serwerze, nie na telefonie.
• Zachowaj kopię do wycofania i przetestuj ponownie po restarcie.