Tasker და WireGuard: სწორი Intent ერთი გვირაბისთვის

WireGuard-ის აქტივობის გაშვება აპს წინა პლანზე გამოაქვს და არ ასწევს კონკრეტულ გვირაბს. ავტომატიზაცია, რომელიც აპს ხსნის და ელოდება, ტესტში გაივლის და პირველივე ჯერზე ჩავარდება, როცა ტელეფონი უკვე მთავარ ეკრანზე ზის. WireGuard წარმოგიდგენთ მხარდაჭერილ დისტანციური მართვის გზას დასახელებული გვირაბებისთვის და ის უფრო ვიწროა, ვიდრე რეცეპტების უმეტესობა გვთავაზობს. ქვემოთ მოცემული სია ამ გზას გადის ნებართვიდან დაკვირვებულ შედეგამდე.

შეამოწმეთ, ჩართულია თუ არა დისტანციური მართვა

დისტანციური მართვის მიმღები ყოველთვის არ უსმენს. WireGuard-ის პარამეტრებში არის ოპცია, რომელიც რთავს გვირაბების დისტანციურ მართვას და სანამ ის ჩართული არ არის, მიმღები მოთხოვნებს უგულებელყოფს და არა ხმამაღლა ვარდება. ნაგულისხმევი მნიშვნელობა განზრახ ასეა, რადგან ექსპორტირებული მიმღები, რომელსაც გვირაბების აწევა შეეძლო, უსაფრთხოების ხვრელი იქნებოდა ყველა მოწყობილობაზე, სადაც აპი დაყენებულია. ჩართეთ ის ინტერფეისიდან და ჩაიწერეთ, რომ ეს გააკეთეთ, რადგან ეს ის პარამეტრია, რომელსაც მომავალი მომხმარებელი გამორთავს ისე, რომ არ იცის რაზე იყო დამოკიდებული.

ზემოთ მოცემული მიმღები მხოლოდ დასახელებულ UP და DOWN მოთხოვნებს ამუშავებს, ამიტომ აქ გვირაბის შექმნის ან მისი კონფიგურაციის რედაქტირების გზა არ არსებობს. სანამ დაეყრდნობით, დაადასტურეთ, რომ კომპონენტი დაყენებულ ბილდში არსებობს: adb shell dumpsys package com.wireguard.android | grep -i receiver ჩამოთვლის გამოცხადებულ მიმღებებს და ბილდი დისტანციური მართვის მიმღების გარეშე არასოდეს უპასუხებს. თუ სამუშაო ნაკადს სჭირდება სხვა ბოლო წერტილი ან სხვა პარტნიორი, ეს სხვა გვირაბია და აპის შიგნით ცალკე ხელით გამართვა.

შეამოწმეთ, რა ნებართვა აქვს კონტროლერს

WireGuard მიმღებს იცავს საშიში ნებართვით, com.wireguard.android.permission.CONTROL_TUNNELS, რომელიც მმართველ აპს უნდა ჰქონდეს. საკუთარი მაუწყებლობა ვერ შექმნის ნებართვას, რომელიც გამომგზავნს არასოდეს გამოუცხადებია ან არასოდეს მიუღია. ეს არის ის ნაბიჯი, სადაც ავტომატიზაციის რეცეპტები ჩუმად ვარაუდობენ შესაძლებლობას, რომელიც ავტომატიზაციას არ აქვს.

დავალების დაწერამდე შეამოწმეთ ორივე მხარე. პირველი ბრძანება ჩამოთვლის გამოცხადებულ ნებართვას, ხოლო მეორე აჩვენებს, ნამდვილად აქვს თუ არა ის კონტროლერის პაკეტს. კონტროლერი, რომელიც ნებართვას მანიფესტში აცხადებს, მაგრამ გაშვების დროს არასოდეს მიუღია, მაინც ვარდება და წარუმატებლობა სიჩუმედ მოდის და არა დიალოგად.

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

თუ კონტროლერს ნებართვა არ აქვს, გამოიყენეთ ის ინტეგრაცია, რომელსაც აპი ნამდვილად მხარს უჭერს, ხელით მაუწყებლობის აწყობის ნაცვლად. Intent-ის გაგზავნა და იმის დანახვა, რომ გამოძახება წარმატებული იყო, მხოლოდ იმას ამტკიცებს, რომ Android-მა მიიღო ის და არა იმას, რომ WireGuard-მა იმოქმედა მის მიხედვით. დაუმოწმებელ გაგზავნას მოეპყარით როგორც უცნობს და არა როგორც წარმატებას.

შეადარეთ Intent-ის ველები დაყენებულ აპს

ოთხი ველი ატარებს მთელ მოთხოვნას და თითოეულს აქვს წარუმატებლობის ისეთივე გზა, როგორც დანარჩენებს. მიიღეთ მოქმედება, გვირაბის დამატებითი ველი, პაკეტი და სამიზნე ერთი ნაკრების სახით სწორად.

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

მოქმედება ასახელებს UP-ს ან DOWN-ს და სხვა არაფერს, დამატებითი ველი ატარებს ზუსტად კონფიგურირებულ გვირაბის სახელს, პაკეტი მიწოდებას WireGuard-ით ზღუდავს და სამიზნე უნდა იყოს მიმღები და არა აქტივობა. ბეჭდვითი შეცდომის მქონე გვირაბის სახელი იმავე სიჩუმეს იძლევა, რასაც გამორთული მიმღები, ამიტომ სახელი აპში წაიკითხეთ, სანამ დაასკვნით, რომ ავტომატიზაცია გატეხილია. DOWN მოქმედება არის com.wireguard.android.action.SET_TUNNEL_DOWN იმავე დამატებითი ველითა და პაკეტით. ტესტირებისას გაგზავნეთ ერთი მოთხოვნა ერთდროულად, რადგან ერთმანეთს რომ ასწრებენ, ორი მაუწყებლობა ქმნის მდგომარეობას, რომელსაც ვერავინ მიაკუთვნებს.

იგივე მოთხოვნა შეამოწმეთ მოწყობილობის shell-იდან, რათა Intent ავტომატიზაციისგან გამოყოთ. თუ ეს ბრძანება ვარდება, სანამ Tasker-ის დავალება წარმატებით სრულდება, განსხვავება გამომგზავნის ნებართვაა და არა ველების მნიშვნელობები.

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

შეამოწმეთ, რას არ ფარავს ტრიგერი

აპის გაშვების ან წინა პლანზე გამოსვლის მოვლენას შეუძლია კავშირი მოითხოვოს, მაგრამ აპმა შესაძლოა უკვე სცადა სახელის ძიება ან საწყისი მოთხოვნა, სანამ ეს მოვლენა დამუშავდება. ტრიგერი ირთვება, როცა სისტემა ამჩნევს მდგომარეობის ცვლილებას, რაც მას შემდეგ ხდება, რაც აპმა მუშაობა დაიწყო. თუ აპს გვირაბის გარეთ კომუნიკაცია არასოდეს არ უნდა ჰქონდეს, გაშვების ტრიგერი დაბლოკვის წესი არ არის და მას ვერ გადააქცევთ ასეთად დაყოვნების დამატებით. დაბლოკვის ქცევისთვის დააკონფიგურირეთ მხარდაჭერილი მუდამ ჩართული ან აპის მიხედვით პოლიტიკა და ტრიგერი მხოლოდ მოხერხებულობისთვის დატოვეთ.

დაბლოკვის ქცევა სულ სხვაგან ცხოვრობს. adb shell settings get global always_on_vpn_app ასახელებს მუდამ ჩართულად მიმაგრებულ პაკეტს, ხოლო adb shell dumpsys connectivity | grep -i vpn აჩვენებს VPN ქსელებს, რომლებსაც სისტემა ახლა თვალს ადევნებს. არც ერთი მათგანი არ არის ის, რაც გაშვების ტრიგერს შეუძლია შეცვალოს.

იგივე მსჯელობა ეხება სესიის მეორე ბოლოს. გვირაბის დაწევა იმიტომ, რომ ერთმა ფანჯარამ ფოკუსი დაკარგა, ამტვრევს ფონურ სამუშაოს, აუთენტიფიკაციის დამხმარეებს და ნებისმიერ სხვა აპს, რომელიც კავშირზე იყო დამოკიდებული. განსაზღვრეთ განზრახ სესიის დასასრული და არა ფოკუსის ცვლილება, და მოერიდეთ სწრაფ UP და DOWN მიმდევრობებს, როცა ავტომატიზაცია კონტექსტებს ცვლის.

შეამოწმეთ შედეგი და არა გაგზავნა

უშეცდომოდ დაბრუნებული მაუწყებლობა Android-მა მიიღო და მეტი არაფერი. გვირაბის მდგომარეობა აპიდან წაიკითხეთ, ხოლო სამუშაო ნაკადის მზადყოფნა იმიდან, რაც შემდეგ ნაბიჯს ნამდვილად სჭირდება. ეს ორი სხვადასხვა შემოწმებაა და პირველის გავლა მეორეს არ ნიშნავს.

ინტერფეისის მდგომარეობაც პირდაპირ წაიკითხეთ: adb shell ip -brief addr show tun0 ბეჭდავს გვირაბის ინტერფეისს და მის მისამართს, ხოლო მისამართის გარეშე არსებული ინტერფეისი აწეულია გამოუსადეგრად. შემდეგ შეამოწმეთ თვითონ კერძო სერვისი, რადგან ხელის ჩამორთმევის ან მარშრუტის გარეშე აწეული გვირაბი მაინც ვარდება იმ დავალებაში, რომელსაც მნიშვნელობა ჰქონდა. ავტომატიზაციას, რომელიც ერთ დასახელებულ კავშირს საკუთარი ნებართვის რეალურ საზღვრებში მართავს, არ სჭირდება ინტერფეისზე შეხება, root ბრძანების გაშვება ან Android-ის ქსელური დაცვის შესუსტება.