Tasker i WireGuard: wysyłanie właściwego Intentu dla jednego tunelu

Uruchomienie aktywności WireGuard przenosi aplikację na pierwszy plan, a nie podnosi konkretnego tunelu. Automatyzacja, która otwiera aplikację i czeka, przejdzie test i zawiedzie za pierwszym razem, gdy telefon już jest na ekranie głównym. WireGuard udostępnia obsługiwaną ścieżkę zdalnego sterowania nazwanymi tunelami i jest ona węższa, niż sugeruje większość przepisów. Poniższa lista kontrolna przechodzi tę ścieżkę od uprawnienia do zaobserwowanego wyniku.

Sprawdź, czy zdalne sterowanie jest włączone

Odbiornik zdalnego sterowania nie zawsze nasłuchuje. Ustawienia WireGuard zawierają opcję włączającą zdalne sterowanie tunelami, a dopóki nie jest włączona, odbiornik ignoruje żądania zamiast głośno zawodzić. Wartość domyślna jest celowa, ponieważ wyeksportowany odbiornik, który mógłby podnosić tunele, byłby dziurą w zabezpieczeniach na każdym urządzeniu z zainstalowaną aplikacją. Włącz ją przez interfejs i zapisz, że to zrobiłeś, bo to ustawienie, które przyszły użytkownik może wyłączyć, nie wiedząc, co od niego zależało.

Powyższy odbiornik obsługuje tylko nazwane żądania UP i DOWN, więc nie ma tu ścieżki do tworzenia tunelu ani edycji jego konfiguracji. Zanim na nim polegniesz, potwierdź, że komponent istnieje w zainstalowanej kompilacji: adb shell dumpsys package com.wireguard.android | grep -i receiver wymienia zadeklarowane odbiorniki, a kompilacja bez odbiornika zdalnego sterowania nigdy nie odpowie. Jeśli przepływ pracy wymaga innego punktu końcowego lub innego peera, to inny tunel i osobna ręczna konfiguracja wewnątrz aplikacji.

Sprawdź, jakie uprawnienie ma kontroler

WireGuard chroni odbiornik niebezpiecznym uprawnieniem, com.wireguard.android.permission.CONTROL_TUNNELS, które musi mieć aplikacja sterująca. Własny broadcast nie może wytworzyć uprawnienia, którego nadawca nigdy nie zadeklarował ani nigdy nie otrzymał. To jest krok, w którym przepisy automatyzacji po cichu zakładają możliwość, której automatyzacja nie ma.

Sprawdź obie strony przed napisaniem zadania. Pierwsze polecenie wymienia zadeklarowane uprawnienie, a drugie pokazuje, czy pakiet kontrolera naprawdę je ma. Kontroler, który deklaruje uprawnienie w manifeście, ale nigdy go nie otrzymał w czasie działania, nadal zawodzi, a niepowodzenie przychodzi jako cisza, a nie jako okno dialogowe.

adb shell pm list permissions -g -d | grep -i control_tunnels
adb shell dumpsys package net.dinglisch.android.taskerm | grep -i control_tunnels

Jeśli kontroler nie ma uprawnienia, użyj integracji, którą aplikacja naprawdę obsługuje, zamiast budować broadcast ręcznie. Wysłanie Intentu i zobaczenie, że wywołanie się udało, dowodzi tylko, że Android je przyjął, a nie że WireGuard na nie zareagował. Niezweryfikowaną wysyłkę traktuj jako niewiadomą, a nie jako sukces.

Porównaj pola Intentu z zainstalowaną aplikacją

Cztery pola niosą całe żądanie, a każde ma sposób zawodu, który wygląda dokładnie tak samo jak pozostałe. Dobrze ustaw akcję, dodatkowe pole tunelu, pakiet i cel jako jeden zestaw.

Action:  com.wireguard.android.action.SET_TUNNEL_UP
Extra:   tunnel:lab-wg
Package: com.wireguard.android
Target:  Broadcast Receiver

Akcja nazywa UP albo DOWN i nic więcej, dodatkowe pole niesie dokładną skonfigurowaną nazwę tunelu, pakiet ogranicza dostarczanie do WireGuard, a celem musi być odbiornik, a nie aktywność. Nazwa tunelu z literówką daje tę samą ciszę co wyłączony odbiornik, więc przeczytaj nazwę w aplikacji, zanim uznasz, że automatyzacja jest zepsuta. Akcja DOWN to com.wireguard.android.action.SET_TUNNEL_DOWN z tym samym dodatkowym polem i pakietem. Podczas testów wysyłaj jedno żądanie naraz, bo dwa broadcasty, które się ścigają, dają stan, którego nikt nie może przypisać.

Przetestuj to samo żądanie z powłoki na urządzeniu, aby oddzielić Intent od automatyzacji. Jeśli to polecenie zawodzi, a zadanie Taskera się udaje, różnicą jest uprawnienie nadawcy, a nie wartości pól.

adb shell am broadcast -a com.wireguard.android.action.SET_TUNNEL_UP -e tunnel lab-wg --receiver-permission com.wireguard.android.permission.CONTROL_TUNNELS

Sprawdź, czego nie obejmuje wyzwalacz

Zdarzenie uruchomienia lub przejścia aplikacji na pierwszy plan może zażądać połączenia, ale aplikacja mogła już próbować wyszukania nazwy lub początkowego żądania, zanim to zdarzenie zostanie obsłużone. Wyzwalacz zadziała, gdy system zauważy zmianę stanu, czyli po tym, jak aplikacja zaczęła pracować. Jeśli aplikacja nigdy nie może komunikować się poza tunelem, wyzwalacz uruchomienia nie jest regułą blokowania i nie da się go takim zrobić przez dodanie opóźnienia. Skonfiguruj obsługiwaną politykę zawsze włączonego lub dla poszczególnych aplikacji dla zachowania blokowania, a wyzwalacz zachowaj tylko dla wygody.

Zachowanie blokowania mieszka zupełnie gdzie indziej. adb shell settings get global always_on_vpn_app nazywa pakiet przypięty jako zawsze włączony, a adb shell dumpsys connectivity | grep -i vpn pokazuje sieci VPN, które system śledzi w tej chwili. Żadne z nich nie jest czymś, co wyzwalacz uruchomienia może zastąpić.

To samo rozumowanie dotyczy drugiego końca sesji. Opuszczenie tunelu dlatego, że jedno okno straciło fokus, psuje pracę w tle, pomocniki uwierzytelniania i każdą inną aplikację, która polegała na połączeniu. Zdefiniuj zamierzony koniec sesji zamiast zmiany fokusu i unikaj szybkich sekwencji UP i DOWN, gdy automatyzacja zmienia konteksty.

Sprawdź wynik, nie wysyłkę

Broadcast, który wraca bez błędu, został przyjęty przez Androida i nic więcej. Czytaj stan tunelu z aplikacji, a gotowość przepływu pracy z tego, czego naprawdę potrzebuje następny krok. To dwie różne kontrole i przejście pierwszej nie oznacza drugiej.

Czytaj też stan interfejsu bezpośrednio: adb shell ip -brief addr show tun0 wypisuje interfejs tunelu i jego adres, a interfejs, który istnieje bez adresu, jest podniesiony, ale bezużyteczny. Potem zweryfikuj samą usługę prywatną, bo tunel podniesiony bez uścisku dłoni lub bez trasy nadal zawodzi w zadaniu, na którym zależało. Automatyzacja, która steruje jednym nazwanym połączeniem w granicach swoich rzeczywistych uprawnień, nie musi dotykać interfejsu, uruchamiać polecenia root ani osłabiać zabezpieczeń sieciowych Androida.