Tasker وWireGuard: إرسال النيّة الصحيحة لنفق واحد
يمكن لـ Tasker أن يطلب من WireGuard تشغيل نفق واحد باسم محدد عبر مستقبل التحكّم عن بُعد. ولا يزال على المتحكّم أن يملك إذن CONTROL_TUNNELS.
إن تشغيل نشاط 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
إذا لم يكن المتحكّم يملك الإذن، فاستخدم التكامل الذي يدعمه التطبيق فعلًا بدلًا من بناء بثّ يدويًا. إن إرسال نيّة ورؤية أن النداء نجح يثبت فقط أن Android قبله، لا أن WireGuard تصرّف بناءً عليه. تعامل مع الإرسال غير المتحقَّق منه على أنه مجهول، لا على أنه نجاح.
تحقّق من حقول النيّة مقابل التطبيق المثبَّت
أربعة حقول تحمل الطلب كله، ولكل واحد منها نمط فشل يبدو تمامًا كالآخر. اضبط الإجراء، والحقل الإضافي للنفق، والحزمة، والهدف معًا كمجموعة واحدة.
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 مع الحقل الإضافي والحزمة نفسيهما. أرسل طلبًا واحدًا في المرة أثناء الاختبار، لأن بثّين يتسابقان ينتجان حالة لا يستطيع أحد نسبتها.
اختبر الطلب نفسه من صدفة على الجهاز لفصل النيّة عن الأتمتة. إذا فشل ذلك الأمر بينما تنجح مهمة 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 يطبع واجهة النفق وعنوانها، والواجهة الموجودة بلا عنوان تكون مرفوعة دون أن تكون صالحة للاستعمال. ثم تحقّق من الخدمة الخاصة نفسها، لأن نفقًا مرفوعًا بلا مصافحة أو بلا مسار يظل يفشل في المهمة التي كانت تهم. الأتمتة التي تتحكّم في اتصال واحد مسمّى داخل حدود إذنها الحقيقية لا تحتاج إلى النقر على الواجهة أو تشغيل أمر جذر أو إضعاف حمايات شبكة Android.