Tasker i WireGuard: slanje ispravnog Intent-a za jedan tunel

Pokretanje WireGuard aktivnosti dovodi aplikaciju u prvi plan, a ne podiže određeni tunel. Automatizacija koja otvori aplikaciju i čeka proći će na testu i pasti prvi put kada telefon već stoji na početnom ekranu. WireGuard nudi podržan put daljinskog upravljanja za imenovane tunele, i on je uži nego što većina recepata sugerira. Kontrolna lista ispod prolazi tim putem od dozvole do uočenog rezultata.

Provjerite je li daljinsko upravljanje omogućeno

Prijemnik za daljinsko upravljanje ne sluša uvijek. Postavke WireGuard-a sadrže opciju koja omogućava daljinsko upravljanje tunelima, i dok ta opcija nije uključena, prijemnik ignorira zahtjeve umjesto da glasno zakaže. Zadana vrijednost je namjerna, jer bi izvezeni prijemnik koji može podizati tunele bio sigurnosna rupa na svakom uređaju na koji je aplikacija instalirana. Omogućite je kroz sučelje i zapišite da ste to učinili, jer je to postavka koju budući korisnik može isključiti ne znajući šta je o njoj ovisilo.

Uzvodni prijemnik obrađuje samo imenovane zahtjeve UP i DOWN, pa ovdje nema puta za stvaranje tunela ili uređivanje njegove konfiguracije. Potvrdite da komponenta postoji u instaliranoj verziji prije nego se na nju oslonite: adb shell dumpsys package com.wireguard.android | grep -i receiver navodi deklarirane prijemnike, a verzija bez prijemnika za daljinsko upravljanje nikada neće odgovoriti. Ako radni tok treba drugu krajnju točku ili drugog partnera, to je drugi tunel i zasebno ručno postavljanje unutar aplikacije.

Provjerite koju dozvolu ima kontroler

WireGuard štiti prijemnik opasnom dozvolom, com.wireguard.android.permission.CONTROL_TUNNELS, koju kontrolna aplikacija mora imati. Vlastiti broadcast ne može stvoriti dozvolu koju pošiljatelj nikada nije deklarirao ili mu nikada nije bila dodijeljena. Ovo je korak u kojem recepti za automatizaciju tiho pretpostavljaju sposobnost koju automatizacija nema.

Provjerite obje strane prije pisanja zadatka. Prva naredba navodi deklariranu dozvolu, a druga pokazuje drži li je paket kontrolera stvarno. Kontroler koji deklarira dozvolu u svom manifestu, ali mu nikada nije dodijeljena tijekom izvršavanja, ipak zakaže, a neuspjeh dolazi kao tišina, a ne kao dijalog.

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

Ako kontroler nema dozvolu, koristite integraciju koju aplikacija stvarno podržava umjesto ručnog sastavljanja broadcasta. Slanje Intent-a i uočavanje da je poziv uspio dokazuje samo da ga je Android prihvatio, a ne da je WireGuard postupio po njemu. Tretirajte neprovjereno slanje kao nepoznanicu, a ne kao uspjeh.

Provjerite polja Intent-a prema instaliranoj aplikaciji

Četiri polja nose cijeli zahtjev, i svako ima način neuspjeha koji izgleda isto kao ostali. Postavite radnju, dodatak za tunel, paket i cilj ispravno kao skup.

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

Radnja imenuje UP ili DOWN i ništa drugo, dodatak nosi točan konfigurirani naziv tunela, paket ograničava dostavu na WireGuard, a cilj mora biti prijemnik, a ne aktivnost. Naziv tunela s tipfelerom proizvodi istu tišinu kao isključen prijemnik, pa pročitajte naziv u aplikaciji prije nego zaključite da je automatizacija pokvarena. Radnja DOWN je com.wireguard.android.action.SET_TUNNEL_DOWN s istim dodatkom i paketom. Tijekom testiranja šaljite jedan zahtjev odjednom, jer dva broadcasta koja se utrkuju stvaraju stanje koje nitko ne može pripisati.

Testirajte isti zahtjev iz ljuske na uređaju kako biste odvojili Intent od automatizacije. Ako ta naredba zakaže dok Tasker zadatak uspijeva, razlika je dozvola pošiljatelja, a ne vrijednosti polja.

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

Provjerite šta okidač ne pokriva

Događaj pokretanja ili prelaska u prvi plan može zatražiti vezu, ali aplikacija je možda već pokušala traženje naziva ili početni zahtjev prije nego što je taj događaj obrađen. Okidač se aktivira kada sistem primijeti promjenu stanja, a to je nakon što je aplikacija počela raditi. Ako aplikacija nikada ne smije komunicirati izvan tunela, okidač pokretanja nije pravilo blokiranja i ne može se u takvo pretvoriti dodavanjem odgode. Konfigurirajte podržanu politiku stalnog uključivanja ili po aplikaciji za ponašanje blokiranja, a okidač zadržite samo radi praktičnosti.

Ponašanje blokiranja živi negdje sasvim drugdje. adb shell settings get global always_on_vpn_app imenuje paket prikvačen kao stalno uključen, a adb shell dumpsys connectivity | grep -i vpn prikazuje VPN mreže koje sistem trenutno prati. Ništa od toga nije nešto što okidač pokretanja može zamijeniti.

Isto razmišljanje vrijedi na drugom kraju sesije. Spuštanje tunela zato što je jedan prozor izgubio fokus kvari pozadinski rad, pomoćnike za autentifikaciju i svaku drugu aplikaciju koja se oslanjala na vezu. Definirajte namjeran kraj sesije umjesto promjene fokusa i izbjegavajte brze sljedove UP i DOWN kada automatizacija mijenja kontekste.

Provjerite rezultat, a ne slanje

Broadcast koji se vrati bez greške Android je prihvatio i ništa više. Čitajte stanje tunela iz aplikacije, a spremnost radnog toka iz onoga što sljedeći korak stvarno treba. To su dvije različite provjere, i prolazak prve ne podrazumijeva drugu.

Čitajte i stanje sučelja izravno: adb shell ip -brief addr show tun0 ispisuje sučelje tunela i njegovu adresu, a sučelje koje postoji bez adrese je podignuto, ali nije upotrebljivo. Zatim provjerite samu privatnu uslugu, jer tunel koji je podignut bez rukovanja ili bez rute ipak pada na zadatku koji je bio važan. Automatizacija koja upravlja jednom imenovanom vezom unutar svojih stvarnih granica dozvole ne mora dirati sučelje, pokretati root naredbu ni slabiti Androidove mrežne zaštite.