Tasker dhe WireGuard: dërgimi i Intent-it të duhur për një tunel

Nisja e aktivitetit të WireGuard sjell një aplikacion përpara, nuk ngre një tunel të caktuar. Një automatizim që hap aplikacionin dhe pret do të kalojë në test dhe do të dështojë herën e parë kur telefoni tashmë ndodhet në ekranin bazë. WireGuard ofron një rrugë të mbështetur të kontrollit në distancë për tunelet me emër, dhe ajo është më e ngushtë sesa sugjerojnë shumica e recetave. Lista e kontrollit më poshtë ndjek atë rrugë nga leja deri te rezultati i vëzhguar.

Kontrolloni nëse kontrolli në distancë është i aktivizuar

Marrësi i kontrollit në distancë nuk dëgjon gjithmonë. Cilësimet e WireGuard përfshijnë një opsion që aktivizon kontrollin në distancë të tuneleve, dhe derisa ai opsion të jetë i ndezur marrësi i shpërfill kërkesat në vend që të dështojë me zë. Vlera e parazgjedhur është e qëllimshme, sepse një marrës i eksportuar që mund të ngrinte tunele do të ishte vrimë sigurie në çdo pajisje ku është instaluar aplikacioni. Aktivizojeni përmes ndërfaqes dhe shkruani që e keni bërë, sepse është një cilësim që një përdorues i ardhshëm mund ta fikë pa e ditur se çfarë varej prej tij.

Marrësi më sipër trajton vetëm kërkesa UP dhe DOWN me emër, prandaj këtu nuk ka rrugë për të krijuar një tunel ose për të redaktuar konfigurimin e tij. Përpara se të mbështeteni tek ai, konfirmoni që komponenti ekziston në ndërtimin e instaluar: adb shell dumpsys package com.wireguard.android | grep -i receiver liston marrësit e deklaruar, dhe një ndërtim pa marrësin e kontrollit në distancë nuk do të përgjigjet kurrë. Nëse rrjedha e punës ka nevojë për një pikë tjetër fundore ose një partner tjetër, ai është një tunel tjetër dhe një konfigurim manual i veçantë brenda aplikacionit.

Kontrolloni çfarë leje ka kontrolluesi

WireGuard e mbron marrësin me një leje të rrezikshme, com.wireguard.android.permission.CONTROL_TUNNELS, të cilën aplikacioni kontrollues duhet ta ketë. Një transmetim i vetë-krijuar nuk mund të prodhojë një leje që dërguesi nuk e ka deklaruar kurrë ose që nuk i është dhënë kurrë. Ky është hapi ku recetat e automatizimit supozojnë në heshtje një aftësi që automatizimi nuk e ka.

Kontrolloni të dyja anët përpara se të shkruani detyrën. Komanda e parë liston lejen e deklaruar, dhe e dyta tregon nëse paketa e kontrolluesit e ka vërtet. Një kontrollues që e deklaron lejen në manifest por nuk e ka marrë kurrë në kohë ekzekutimi dështon gjithsesi, dhe dështimi vjen si heshtje dhe jo si dialog.

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

Nëse kontrolluesi nuk e ka lejen, përdorni integrimin që aplikacioni mbështet vërtet në vend që të ndërtoni një transmetim me dorë. Dërgimi i një Intent-i dhe shikimi që thirrja pati sukses provon vetëm se Android e pranoi, jo se WireGuard veproi sipas tij. Trajtoni një dërgim të paverifikuar si të panjohur, jo si sukses.

Krahasoni fushat e Intent-it me aplikacionin e instaluar

Katër fusha mbajnë të gjithë kërkesën, dhe secila ka një mënyrë dështimi që duket saktësisht si të tjerat. Merreni veprimin, shtesën e tunelit, paketën dhe objektivin saktë si një grup.

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

Veprimi emërton UP ose DOWN dhe asgjë tjetër, shtesa mbart emrin e saktë të konfiguruar të tunelit, paketa e kufizon dorëzimin te WireGuard, dhe objektivi duhet të jetë marrësi dhe jo një aktivitet. Një emër tuneli me gabim shtypi prodhon të njëjtën heshtje si një marrës i fikur, prandaj lexoni emrin në aplikacion përpara se të arrini në përfundimin se automatizimi është prishur. Veprimi DOWN është com.wireguard.android.action.SET_TUNNEL_DOWN me të njëjtën shtesë dhe paketë. Gjatë testimit dërgoni një kërkesë në një herë, sepse dy transmetime që garojnë me njëri-tjetrin krijojnë një gjendje që askush nuk mund t’ia atribuojë.

Testoni të njëjtën kërkesë nga një shell në pajisje për të ndarë Intent-in nga automatizimi. Nëse ajo komandë dështon ndërsa detyra e Tasker-it ka sukses, ndryshimi është leja e dërguesit dhe jo vlerat e fushave.

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

Kontrolloni çfarë nuk mbulon shkaktari

Një ngjarje e nisjes ose e daljes në plan të parë mund të kërkojë një lidhje, por aplikacioni mund të ketë provuar tashmë një kërkim emri ose një kërkesë fillestare përpara se ajo ngjarje të trajtohet. Shkaktari aktivizohet kur sistemi vëren ndryshimin e gjendjes, domethënë pasi aplikacioni ka filluar të punojë. Nëse aplikacioni nuk duhet të komunikojë kurrë jashtë tunelit, një shkaktar nisjeje nuk është rregull bllokimi dhe nuk mund të bëhet i tillë duke shtuar një vonesë. Konfiguroni një politikë të mbështetur gjithmonë aktive ose për çdo aplikacion për sjelljen e bllokimit, dhe mbajeni shkaktarin vetëm për lehtësi.

Sjellja e bllokimit jeton diku krejt tjetër. adb shell settings get global always_on_vpn_app emërton paketën e fiksuar si gjithmonë aktive, dhe adb shell dumpsys connectivity | grep -i vpn tregon rrjetet VPN që sistemi po ndjek tani. Asnjëra prej tyre nuk është diçka që një shkaktar nisjeje mund ta zëvendësojë.

I njëjti arsyetim vlen në skajin tjetër të sesionit. Ulja e tunelit sepse një dritare humbi fokusin prish punën në sfond, ndihmësit e vërtetimit dhe çdo aplikacion tjetër që llogariste te lidhja. Përcaktoni një fund sesioni të qëllimshëm në vend të një ndryshimi fokusi, dhe shmangni sekuencat e shpejta UP dhe DOWN kur automatizimi ndryshon kontekste.

Kontrolloni rezultatin, jo dërgimin

Një transmetim që kthehet pa gabim është pranuar nga Android dhe asgjë më tepër. Lexoni gjendjen e tunelit nga aplikacioni, dhe gatishmërinë e rrjedhës së punës nga ajo që i duhet vërtet hapit tjetër. Këto janë dy kontrolle të ndryshme, dhe kalimi i të parit nuk nënkupton të dytin.

Lexoni edhe gjendjen e ndërfaqes drejtpërdrejt: adb shell ip -brief addr show tun0 printon ndërfaqen e tunelit dhe adresën e saj, dhe një ndërfaqe që ekziston pa adresë është lart pa qenë e përdorshme. Më pas verifikoni vetë shërbimin privat, sepse një tunel i ngritur pa shtrëngim duarsh ose pa rrugë dështon gjithsesi në detyrën që kishte rëndësi. Një automatizim që kontrollon një lidhje me emër brenda kufijve realë të lejes së tij nuk ka nevojë të prekë ndërfaqen, të ekzekutojë një komandë root ose të dobësojë mbrojtjet e rrjetit të Android.