Tasker și WireGuard: trimiterea Intentului corect pentru un tunel

Lansarea activității WireGuard aduce o aplicație în prim-plan, nu ridică un tunel anume. O automatizare care deschide aplicația și așteaptă va trece la test și va eșua prima dată când telefonul este deja pe ecranul principal. WireGuard expune o cale de control de la distanță acceptată pentru tuneluri numite, iar aceasta este mai îngustă decât sugerează majoritatea rețetelor. Lista de verificare de mai jos parcurge acea cale de la permisiune la rezultatul observat.

Verificați dacă controlul de la distanță este activat

Receptorul de control de la distanță nu ascultă mereu. Setările WireGuard includ o opțiune care activează controlul de la distanță al tunelurilor, iar cât timp opțiunea este oprită receptorul ignoră cererile în loc să eșueze zgomotos. Valoarea implicită este intenționată, pentru că un receptor exportat care ar putea ridica tuneluri ar fi o breșă de securitate pe fiecare dispozitiv care a instalat aplicația. Activați-o din interfață și notați că ați făcut-o, pentru că este o setare pe care un utilizator viitor o poate opri fără să știe de ce depindea.

Receptorul de mai sus tratează doar cereri UP și DOWN numite, deci aici nu există o cale de a crea un tunel sau de a-i edita configurația. Confirmați că componenta există în compilarea instalată înainte de a vă baza pe ea: adb shell dumpsys package com.wireguard.android | grep -i receiver listează receptoarele declarate, iar o compilare fără receptorul de control de la distanță nu va răspunde niciodată. Dacă fluxul de lucru are nevoie de alt punct final sau de alt partener, acesta este alt tunel și o configurare manuală separată în interiorul aplicației.

Verificați ce permisiune are controlerul

WireGuard protejează receptorul cu o permisiune periculoasă, com.wireguard.android.permission.CONTROL_TUNNELS, pe care aplicația care controlează trebuie să o dețină. Un broadcast propriu nu poate fabrica o permisiune pe care expeditorul nu a declarat-o niciodată sau care nu i-a fost acordată niciodată. Acesta este pasul în care rețetele de automatizare presupun în tăcere o capacitate pe care automatizarea nu o are.

Verificați ambele părți înainte de a scrie sarcina. Prima comandă listează permisiunea declarată, iar a doua arată dacă pachetul controlerului o are într-adevăr. Un controler care declară permisiunea în manifest dar nu a primit-o niciodată la execuție eșuează în continuare, iar eșecul vine ca tăcere și nu ca dialog.

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

Dacă controlerul nu deține permisiunea, folosiți integrarea pe care aplicația o acceptă cu adevărat în loc să construiți un broadcast manual. Trimiterea unui Intent și constatarea că apelul a reușit dovedește doar că Android l-a acceptat, nu că WireGuard a acționat în consecință. Tratați o trimitere neverificată ca necunoscută, nu ca succes.

Comparați câmpurile Intentului cu aplicația instalată

Patru câmpuri poartă întreaga cerere, iar fiecare are un mod de eșec care arată exact ca celelalte. Nimeriți acțiunea, extra-ul tunelului, pachetul și ținta ca un singur set.

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

Acțiunea numește UP sau DOWN și nimic altceva, extra-ul poartă numele exact configurat al tunelului, pachetul restricționează livrarea la WireGuard, iar ținta trebuie să fie receptorul și nu o activitate. Un nume de tunel cu greșeală de tastare produce aceeași tăcere ca un receptor dezactivat, așa că citiți numele în aplicație înainte de a concluziona că automatizarea este stricată. Acțiunea DOWN este com.wireguard.android.action.SET_TUNNEL_DOWN cu același extra și același pachet. Trimiteți o singură cerere o dată în timpul testării, pentru că două broadcasturi care se întrec produc o stare pe care nimeni nu o poate atribui.

Testați aceeași cerere dintr-un shell pe dispozitiv pentru a separa Intentul de automatizare. Dacă acea comandă eșuează în timp ce sarcina din Tasker reușește, diferența este permisiunea expeditorului și nu valorile câmpurilor.

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

Verificați ce nu acoperă declanșatorul

Un eveniment de lansare sau de trecere în prim-plan poate solicita o conexiune, dar aplicația poate fi încercat deja o căutare de nume sau o cerere inițială înainte ca evenimentul să fie tratat. Declanșatorul se activează când sistemul observă schimbarea de stare, adică după ce aplicația a început să lucreze. Dacă aplicația nu trebuie să comunice niciodată în afara tunelului, un declanșator de lansare nu este o regulă de blocare și nu poate deveni una adăugând o întârziere. Configurați o politică acceptată de mereu activ sau pe aplicație pentru comportamentul de blocare, și păstrați declanșatorul doar pentru confort.

Comportamentul de blocare locuiește cu totul în altă parte. adb shell settings get global always_on_vpn_app numește pachetul fixat ca mereu activ, iar adb shell dumpsys connectivity | grep -i vpn arată rețelele VPN pe care sistemul le urmărește acum. Niciunul dintre ele nu este ceva ce un declanșator de lansare poate înlocui.

Același raționament se aplică la celălalt capăt al sesiunii. Coborârea tunelului pentru că o fereastră a pierdut focalizarea strică munca din fundal, ajutoarele de autentificare și orice altă aplicație care conta pe conexiune. Definiți un sfârșit de sesiune deliberat în loc de o schimbare de focalizare, și evitați secvențele rapide de UP și DOWN când automatizarea schimbă contexte.

Verificați rezultatul, nu trimiterea

Un broadcast care se întoarce fără eroare a fost acceptat de Android și nimic mai mult. Citiți starea tunelului din aplicație, iar pregătirea fluxului de lucru din ce are nevoie cu adevărat pasul următor. Sunt două verificări diferite, iar trecerea primeia nu o implică pe a doua.

Citiți și starea interfeței direct: adb shell ip -brief addr show tun0 tipărește interfața tunelului și adresa ei, iar o interfață care există fără adresă este ridicată fără a fi utilizabilă. Apoi verificați serviciul privat în sine, pentru că un tunel ridicat fără handshake sau fără rută eșuează în continuare în sarcina care conta. O automatizare care controlează o singură conexiune numită în limitele reale ale permisiunii sale nu trebuie să atingă interfața, să ruleze o comandă root sau să slăbească protecțiile de rețea ale Android.