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.