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의 네트워크 보호를 약화할 필요가 없습니다.