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 با همان فیلد اضافی و بسته است. هنگام آزمایش هر بار یک درخواست بفرستید، چون دو پخش که از هم پیشی می‌گیرند وضعیتی می‌سازند که هیچ‌کس نمی‌تواند به چیزی نسبت دهد.

همان درخواست را از یک پوسته روی دستگاه آزمایش کنید تا 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 را سست کند.