Tasker dan WireGuard: mengirim Intent yang tepat untuk satu tunnel

Menjalankan aktivitas WireGuard membawa aplikasi ke depan, bukan menyalakan tunnel tertentu. Otomasi yang membuka aplikasi lalu menunggu akan lolos saat diuji dan gagal pertama kali ponsel sudah berada di layar utama. WireGuard menyediakan jalur kendali jarak jauh yang didukung untuk tunnel bernama, dan jalur itu lebih sempit daripada yang disarankan kebanyakan resep. Daftar periksa di bawah menelusuri jalur itu dari izin sampai hasil yang teramati.

Periksa apakah kendali jarak jauh aktif

Penerima kendali jarak jauh tidak selalu mendengarkan. Setelan WireGuard menyertakan opsi yang mengaktifkan kendali jarak jauh atas tunnel, dan sampai opsi itu aktif penerima mengabaikan permintaan alih-alih gagal dengan berisik. Nilai bawaannya disengaja, karena penerima yang diekspor dan bisa menyalakan tunnel akan menjadi celah keamanan di setiap perangkat yang memasang aplikasi ini. Aktifkan lewat antarmuka dan catat bahwa Anda melakukannya, karena ini setelan yang bisa dimatikan pengguna mendatang tanpa tahu apa yang bergantung padanya.

Penerima di atas hanya menangani permintaan UP dan DOWN bernama, jadi tidak ada jalur di sini untuk membuat tunnel atau menyunting konfigurasinya. Pastikan komponen itu ada di build yang terpasang sebelum mengandalkannya: adb shell dumpsys package com.wireguard.android | grep -i receiver mendaftar penerima yang dideklarasikan, dan build tanpa penerima kendali jarak jauh tidak akan pernah menjawab. Jika alur kerja membutuhkan titik akhir atau peer lain, itu tunnel lain dan penyiapan manual terpisah di dalam aplikasi.

Periksa izin yang dimiliki pengendali

WireGuard melindungi penerima dengan izin berbahaya, com.wireguard.android.permission.CONTROL_TUNNELS, yang harus dimiliki aplikasi pengendali. Siaran kustom tidak dapat menciptakan izin yang tidak pernah dideklarasikan pengirim atau tidak pernah diberikan kepadanya. Inilah langkah ketika resep otomasi diam-diam mengandaikan kemampuan yang tidak dimiliki otomasi itu.

Periksa kedua sisi sebelum menulis tugas. Perintah pertama mendaftar izin yang dideklarasikan, dan yang kedua menunjukkan apakah paket pengendali benar-benar memilikinya. Pengendali yang mendeklarasikan izin di manifesnya tetapi tidak pernah diberi izin itu saat runtime tetap gagal, dan kegagalannya datang sebagai kesenyapan, bukan sebagai dialog.

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

Jika pengendali tidak memiliki izin itu, gunakan integrasi yang benar-benar didukung aplikasi alih-alih membangun siaran secara manual. Mengirim Intent dan melihat panggilannya berhasil hanya membuktikan Android menerimanya, bukan bahwa WireGuard bertindak atasnya. Perlakukan pengiriman yang tidak terverifikasi sebagai hal yang tidak diketahui, bukan sebagai keberhasilan.

Cocokkan bidang Intent dengan aplikasi yang terpasang

Empat bidang membawa seluruh permintaan, dan masing-masing punya cara gagal yang tampak persis sama dengan yang lain. Dapatkan aksi, extra tunnel, paket, dan target dengan benar sebagai satu kesatuan.

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

Aksi menyebut UP atau DOWN dan tidak yang lain, extra membawa nama tunnel yang dikonfigurasi persis, paket membatasi pengiriman ke WireGuard, dan target harus penerima, bukan aktivitas. Nama tunnel yang salah ketik menghasilkan kesenyapan yang sama seperti penerima yang dimatikan, jadi bacalah nama itu di aplikasi sebelum menyimpulkan otomasinya rusak. Aksi DOWN adalah com.wireguard.android.action.SET_TUNNEL_DOWN dengan extra dan paket yang sama. Kirim satu permintaan setiap kali saat menguji, karena dua siaran yang saling mendahului menghasilkan keadaan yang tidak bisa diatribusikan siapa pun.

Uji permintaan yang sama dari shell di perangkat untuk memisahkan Intent dari otomasi. Jika perintah itu gagal sementara tugas Tasker berhasil, selisihnya adalah izin pengirim, bukan nilai bidangnya.

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

Periksa apa yang tidak dicakup pemicu

Peristiwa peluncuran atau latar depan aplikasi dapat meminta koneksi, tetapi aplikasi mungkin sudah mencoba pencarian nama atau permintaan awal sebelum peristiwa itu ditangani. Pemicu menyala ketika sistem menyadari perubahan status, yaitu setelah aplikasi mulai bekerja. Jika aplikasi tidak boleh pernah berkomunikasi di luar tunnel, pemicu peluncuran bukan aturan pemblokiran dan tidak bisa dijadikan begitu dengan menambahkan penundaan. Konfigurasikan kebijakan selalu aktif atau per aplikasi yang didukung untuk perilaku pemblokiran, dan simpan pemicu hanya untuk kemudahan.

Perilaku pemblokiran tinggal di tempat yang sama sekali lain. adb shell settings get global always_on_vpn_app menyebut paket yang disematkan sebagai selalu aktif, dan adb shell dumpsys connectivity | grep -i vpn menunjukkan jaringan VPN yang sedang dilacak sistem saat ini. Tidak satu pun dari keduanya dapat digantikan oleh pemicu peluncuran.

Penalaran yang sama berlaku di ujung lain sesi. Menurunkan tunnel karena satu jendela kehilangan fokus merusak pekerjaan latar belakang, pembantu autentikasi, dan aplikasi lain yang mengandalkan koneksi. Tentukan akhir sesi yang disengaja alih-alih perubahan fokus, dan hindari rangkaian UP dan DOWN yang cepat ketika otomasi berganti konteks.

Periksa hasilnya, bukan pengirimannya

Siaran yang kembali tanpa galat telah diterima Android dan tidak lebih. Baca status tunnel dari aplikasi, dan baca kesiapan alur kerja dari apa yang benar-benar dibutuhkan langkah berikutnya. Itu dua pemeriksaan berbeda, dan lulus yang pertama tidak berarti yang kedua.

Baca juga status antarmuka secara langsung: adb shell ip -brief addr show tun0 mencetak antarmuka tunnel dan alamatnya, dan antarmuka yang ada tanpa alamat berarti naik tanpa bisa dipakai. Lalu verifikasi layanan privatnya sendiri, karena tunnel yang naik tanpa handshake atau tanpa rute tetap gagal pada tugas yang penting. Otomasi yang mengendalikan satu koneksi bernama dalam batas izin sebenarnya tidak perlu mengetuk antarmuka, menjalankan perintah root, atau melemahkan perlindungan jaringan Android.