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 อ่อนแอลง