Automatyzacja L2TP na Androidzie: skrypt może poprosić, nie zbudować

Mit głosi, że L2TP na Androidzie to kolejna rzecz, którą skrypt shell może uruchomić: dodaj trasę, wywołaj starą usługę, gotowe. Tak nie może być, bo cztery różne warstwy muszą się zgodzić, zanim tunel przeniesie pakiet. Warstwa IPsec chroni ścieżkę, L2TP przenosi sesję, PPP negocjuje łącze, a Android musi zarejestrować wynik jako VPN, wokół którego może routować. Widziałem dwie próby z kopiowanymi poleceniami i za każdym razem trasa istniała, gdy nic nie było zaszyfrowane.

Co naprawdę osiąga zmiana trasy

Dodanie trasy decyduje, dokąd pakiet pójdzie dalej. Nie negocjuje asocjacji bezpieczeństwa, nie otwiera sesji L2TP i nie wykonuje wymiany PPP, która daje adres, partnera i ustawienia DNS. Na telefonie widocznym rezultatem jest ruch wychodzący złą ścieżką albo wychodzący i ginący, bez stanu tunelu gdziekolwiek.

To samo dotyczy wywołania usługi skopiowanego ze starszego wydania. Wewnętrzna instalacja VPN Androida nie jest opublikowanym API automatyzacji, a numerowana transakcja z innej wersji może trafić w inną operację albo wymagać uprawnień, których skrypt nie ma. Automatyzacja niosąca hasło nigdy nie powinna polegać na zgadywanych wewnętrznych argumentach, bo trybem awarii jest albo cichy no-op, albo na wpół utworzony profil, którego nikt nie sprząta.

Czterech właścicieli, a skrypt nie jest żadnym z nich

Weź je po kolei. IPsec ustanawia i utrzymuje chronioną ścieżkę oraz uwierzytelnia partnerów. L2TP przenosi po niej sesję, a to warstwowanie jest powodem, dla którego standard traktuje je jako osobne mechanizmy, a nie jeden protokół. W tym PPP negocjuje parametry łącza, których użyje klient. Potem Android odpowiada za stronę platformy: zarejestrowany interfejs VPN, zakres na aplikację, stan always-on i cykl życia, który decyduje, co się dzieje po zabiciu aplikacji.

Skrypt widzi tylko ostatnią z tych warstw i zwykle pośrednio. Może poprosić klienta o połączenie, jeśli ten klient udostępnia udokumentowaną kontrolę, a potem obserwować stan interfejsu. Nie zastąpi trzech warstw poniżej i nie sprawi, że platforma potraktuje niezarejestrowany interfejs jako VPN.

Dlaczego demon też nie jest skrótem

Uruchomienie uprzywilejowanego demona Linuksa na urządzeniu wygląda jak brakujący element i często rzeczywiście podnosi tunel. Tego jednak nie robi: nie rejestruje tunelu w Androidzie. Interfejs istnieje w jądrze, ale wybór VPN platformy, routowanie na aplikację, polityka always-on i cykl życia o nim nie wiedzą, a własne zmiany trasy i DNS demona konkurują z menedżerem sieci o te same tabele.

Rezultatem jest połączenie działające dla ruchu demona i tajemniczo niedziałające dla aplikacji, na której ci zależało, albo takie, które przetrwa do ponownej oceny sieci przez system. Żaden z tych wyników nie jest błędem platformy; to granica między posiadaniem gniazda a posiadaniem udogodnienia VPN.

Jak wyglądają obsługiwane ścieżki

Jeśli organizacja może przejść na profil, który Android sam dostarcza, ścieżka platformy jest uczciwa. Od API 30 VpnManager obsługuje udostępnianie i kontrolę profili VPN platformy przez aplikacje, z procesem autoryzacji powiązanym z aplikacją wywołującą. To nie jest konwerter L2TP: model profilu udostępniany dla IKEv2 nie tłumaczy istniejącej konfiguracji L2TP, a zmiana protokołu jest migracją, nie zmianą nazwy. Tożsamości, trasy, prywatny DNS i uprawnienia dostępu trzeba przenieść świadomie.

Jeśli usługa musi pozostać na L2TP/IPsec, obsługiwanym zestawem jest klient i wydanie systemu, które operator naprawdę dokumentuje, oraz jego kontrakt automatyzacji, jeśli istnieje. Gdy nie ma udokumentowanej kontroli bez nadzoru, poprawną odpowiedzią jest obsługiwane połączenie ręczne, a nie kruchy uprzywilejowany skrypt, który przypadkiem działa na jednym buildzie.

Co robi poprawna automatyzacja

Mając udokumentowaną kontrolę, automatyzacja ma małe i obronne zadanie: poprosić o nazwane połączenie, poczekać na gotowość, zatrzymać się przy błędzie uwierzytelniania lub konfiguracji, wykonać zaplanowaną pracę i zostawić sprzątanie komponentowi, który posiada połączenie. Poświadczenia zostają u klienta, który umie je przechowywać i rotować.

Zapisz, który komponent posiada którą warstwę, zanim napiszesz pierwszą linię, i sprawdź wynik według tego:

• IPsec i PPP obsługuje klient, a nie trasy skryptu.
• Połączenie pojawia się w stanie VPN platformy, więc zakres na aplikację i always-on go dotyczą.
• Żadne wewnętrzne wywołanie usługi, numer transakcji ani zgadywany argument nie niesie poświadczenia.
• Awaria na dowolnym etapie nie zostawia na wpół zarejestrowanego profilu.