Tasker và WireGuard: gửi đúng Intent cho một đường hầm

Khởi chạy hoạt động của WireGuard đưa ứng dụng ra trước, chứ không dựng một đường hầm cụ thể. Một tự động hóa mở ứng dụng và chờ sẽ qua được bài kiểm tra và thất bại ngay lần đầu khi điện thoại đã ở màn hình chính. WireGuard cung cấp một đường điều khiển từ xa được hỗ trợ cho các đường hầm có tên, và nó hẹp hơn những gì hầu hết công thức gợi ý. Danh sách kiểm tra bên dưới đi theo con đường đó từ quyền đến kết quả quan sát được.

Kiểm tra xem điều khiển từ xa đã bật chưa

Bộ nhận điều khiển từ xa không phải lúc nào cũng lắng nghe. Cài đặt của WireGuard có một tùy chọn bật điều khiển từ xa các đường hầm, và cho đến khi tùy chọn đó bật, bộ nhận sẽ bỏ qua yêu cầu thay vì thất bại ồn ào. Giá trị mặc định là có chủ đích, vì một bộ nhận được xuất ra có thể dựng đường hầm sẽ là lỗ hổng bảo mật trên mọi thiết bị đã cài ứng dụng. Bật nó qua giao diện và ghi lại rằng bạn đã làm, vì đây là cài đặt mà người dùng sau có thể tắt mà không biết điều gì phụ thuộc vào nó.

Bộ nhận ở trên chỉ xử lý các yêu cầu UP và DOWN có tên, nên ở đây không có đường để tạo đường hầm hay sửa cấu hình của nó. Xác nhận thành phần có trong bản dựng đã cài trước khi dựa vào nó: adb shell dumpsys package com.wireguard.android | grep -i receiver liệt kê các bộ nhận được khai báo, và một bản dựng không có bộ nhận điều khiển từ xa sẽ không bao giờ trả lời. Nếu quy trình làm việc cần điểm cuối khác hoặc đối tác khác, đó là đường hầm khác và một thiết lập thủ công riêng bên trong ứng dụng.

Kiểm tra quyền mà bộ điều khiển có

WireGuard bảo vệ bộ nhận bằng một quyền nguy hiểm, com.wireguard.android.permission.CONTROL_TUNNELS, mà ứng dụng điều khiển phải có. Một broadcast tự tạo không thể tạo ra quyền mà người gửi chưa bao giờ khai báo hoặc chưa bao giờ được cấp. Đây là bước mà các công thức tự động hóa lặng lẽ giả định một khả năng mà tự động hóa không có.

Kiểm tra cả hai phía trước khi viết tác vụ. Lệnh đầu tiên liệt kê quyền được khai báo, và lệnh thứ hai cho biết gói của bộ điều khiển có thực sự giữ quyền đó không. Một bộ điều khiển khai báo quyền trong manifest nhưng chưa bao giờ được cấp lúc chạy vẫn thất bại, và thất bại đến như sự im lặng chứ không phải hộp thoại.

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

Nếu bộ điều khiển không có quyền, hãy dùng tích hợp mà ứng dụng thực sự hỗ trợ thay vì tự dựng broadcast. Gửi một Intent và thấy lệnh gọi thành công chỉ chứng minh Android đã chấp nhận nó, không phải WireGuard đã hành động theo nó. Coi một lần gửi chưa xác minh là chưa biết, không phải thành công.

Đối chiếu các trường Intent với ứng dụng đã cài

Bốn trường mang toàn bộ yêu cầu, và mỗi trường có một kiểu thất bại trông giống hệt các trường khác. Đặt đúng hành động, trường phụ của đường hầm, gói và mục tiêu như một bộ.

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

Hành động nêu tên UP hoặc DOWN và không gì khác, trường phụ mang đúng tên đường hầm đã cấu hình, gói giới hạn việc giao cho WireGuard, và mục tiêu phải là bộ nhận chứ không phải một hoạt động. Một tên đường hầm có lỗi chính tả tạo ra sự im lặng giống như bộ nhận bị tắt, nên hãy đọc tên trong ứng dụng trước khi kết luận rằng tự động hóa hỏng. Hành động DOWN là com.wireguard.android.action.SET_TUNNEL_DOWN với cùng trường phụ và gói. Khi kiểm tra, hãy gửi từng yêu cầu một, vì hai broadcast chạy đua nhau tạo ra trạng thái không ai có thể quy cho.

Kiểm tra cùng yêu cầu đó từ shell trên thiết bị để tách Intent khỏi tự động hóa. Nếu lệnh đó thất bại trong khi tác vụ Tasker thành công, khác biệt là quyền của người gửi chứ không phải giá trị các trường.

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

Kiểm tra những gì trình kích hoạt không bao phủ

Một sự kiện khởi chạy hoặc lên trước của ứng dụng có thể yêu cầu kết nối, nhưng ứng dụng có thể đã thử tra tên hoặc yêu cầu ban đầu trước khi sự kiện đó được xử lý. Trình kích hoạt bắn khi hệ thống nhận ra thay đổi trạng thái, tức là sau khi ứng dụng đã bắt đầu làm việc. Nếu ứng dụng không bao giờ được liên lạc bên ngoài đường hầm, trình kích hoạt khởi chạy không phải quy tắc chặn và không thể biến thành như vậy bằng cách thêm độ trễ. Cấu hình chính sách luôn bật hoặc theo từng ứng dụng được hỗ trợ cho hành vi chặn, và chỉ giữ trình kích hoạt để tiện dụng.

Hành vi chặn sống ở nơi hoàn toàn khác. adb shell settings get global always_on_vpn_app nêu tên gói được ghim là luôn bật, và adb shell dumpsys connectivity | grep -i vpn hiển thị các mạng VPN mà hệ thống đang theo dõi lúc này. Không cái nào trong hai thứ đó là thứ mà trình kích hoạt khởi chạy có thể thay thế.

Cùng lý lẽ đó áp dụng ở đầu bên kia của phiên. Hạ đường hầm vì một cửa sổ mất tiêu điểm làm hỏng công việc nền, các trợ giúp xác thực và mọi ứng dụng khác đang dựa vào kết nối. Định nghĩa một kết thúc phiên có chủ đích thay vì thay đổi tiêu điểm, và tránh chuỗi UP và DOWN nhanh khi tự động hóa chuyển ngữ cảnh.

Kiểm tra kết quả, không phải việc gửi

Một broadcast quay về không lỗi đã được Android chấp nhận và không hơn. Đọc trạng thái đường hầm từ ứng dụng, và đọc mức sẵn sàng của quy trình từ điều bước tiếp theo thực sự cần. Đó là hai kiểm tra khác nhau, và qua cái đầu không có nghĩa là qua cái thứ hai.

Cũng đọc trực tiếp trạng thái giao diện: adb shell ip -brief addr show tun0 in giao diện đường hầm và địa chỉ của nó, và một giao diện tồn tại mà không có địa chỉ là đang lên nhưng không dùng được. Sau đó xác minh chính dịch vụ riêng, vì một đường hầm đang lên mà không có bắt tay hoặc không có tuyến vẫn thất bại ở tác vụ quan trọng. Một tự động hóa điều khiển một kết nối có tên trong giới hạn quyền thực của nó không cần chạm vào giao diện, chạy lệnh root hay làm yếu các biện pháp bảo vệ mạng của Android.