무선 디버깅 트래픽이 VPN 누출의 증거가 아닌 이유
Wi-Fi로 페어링된 ADB 세션은 디버깅 관계를 증명할 뿐, 인터넷 출구 경로를 증명하지 않습니다. 그 관찰이 실제로 무엇을 다루는지 설명합니다.
무선 디버깅을 켜고 노트북을 연결했는데 VPN이 켜져 있는 동안에도 세션이 계속 작동했습니다. 그것은 무언가가 터널을 빠져나간 것처럼 보입니다. 거의 확실히 아닙니다. 디버깅 세션과 앱의 웹사이트 요청은 서로 다른 네트워크 관계이며, 둘 중 하나만 터널을 넘어야 합니다.
저는 이 오독을 두 번 겪었습니다. 한 번은 휴대폰과 노트북이 같은 Wi-Fi에 있을 때, 한 번은 재부팅 후에도 페어링이 유지되었을 때입니다. 두 경우 모두 VPN은 설정된 대로 정확히 작동하고 있었습니다.
버그에 이름을 붙이기 전에 관찰에 이름을 붙여라
누출 주장 앞에는 세 가지 사건이 있을 수 있으며, 그것들은 서로 대체될 수 없습니다. 도구가 서비스를 발견할 수 있고, 기기가 워크스테이션을 승인할 수 있으며, 권한이 부여된 세션이 실제로 명령과 바이트를 실어 나를 수 있습니다. 어느 것을 보았는지 적어 두십시오. 각각은 사람들이 가정하는 것보다 적게 증명합니다.
발견은 보통 mDNS나 포트 스캔입니다. 페어링은 휴대폰에서 내리는 등록 결정이며, 사용자가 입력하는 코드로 확인됩니다. 살아 있는 세션은 페어링된 두 엔드포인트 사이로 트래픽이 이동했다는 뜻입니다. 그중 어느 것도 앱의 HTTPS 요청이 어디로 가는지 설명하지 않습니다.
목적지, 인터페이스, 주소 체계, 타임스탬프, 사용자 프로필을 그 사건에 붙여 두십시오. 그 세부 정보가 없으면 관찰을 의도한 로컬 네트워크 정책이나 당시 실행 중이던 VPN 빌드와 비교할 수 없습니다.
두 경로가 결코 만나지 않는 이유
무선 디버깅은 기기로 들어오는 연결입니다. adbd는 Wi-Fi 인터페이스에 바인딩된 포트에서 수신하고, 워크스테이션은 페어링 후 그 포트로 접속합니다. 방향이 중요합니다. 노트북이 휴대폰 안으로 들어가는 것이지 그 반대가 아닙니다. 이것은 출구 누출과 정반대입니다.
앱의 인터넷 트래픽은 VpnService가 설치하는 터널 인터페이스로 나가며, UID와 라우팅 규칙으로 매칭됩니다. adbd는 shell 사용자로 실행되는 시스템 데몬이며, 그 라우팅 집합 안의 앱이 아닙니다. 모든 앱이 터널에 고정되어 있어도 adbd는 기저 Wi-Fi 링크에 남습니다.
잠금 모드는 대상 앱에 터널을 강제합니다. 수신 소켓을 출구 경로로 바꾸지는 않습니다.
그래서 작동하는 ADB 세션과 작동하는 킬 스위치가 모순 없이 공존합니다. 누출을 증명하려면 차단되어야 하는 방향을 관찰해야 합니다.
출구 테스트의 실제 모습
디버깅 채널이 아니라 대상 앱을 테스트하십시오. 실패 조건을 의도적으로 만든 다음, 새 요청을 한 번 보내고 무슨 일이 있었는지 기록하십시오.
- VPN이 유일한 경로인지 확인하십시오. VPN 없이 연결 차단을 켠 상태로 상시 연결 VPN을 켭니다.
- 지원되는 방식으로 VPN을 중지하고 앱이 연결 없음을 보고하는지 확인하십시오.
- 그 앱에서 무해한 요청을 하나 보내고 실패하는지 성공하는지 기록하십시오.
- 무선 디버깅을 켠 상태와 끈 상태로 반복해 변수를 분리하십시오.
그 조건에서 차단된 요청은 증거입니다. 성공한 ADB 세션은 증거가 아니며, 터미널 앱에서 보낸 ping 한 번도 아닙니다.
잠금이 켜진 상태에서 요청이 실제로 성공한다면, 앱의 UID와 VPN 허용, 활성 네트워크, 클라이언트 버전을 기록하십시오. 그 조합이 진짜 발견입니다.
페어링은 세션보다 오래 산다
페어링은 영구 상태이며, 케이블 테스트 후 잊어도 되는 핸드셰이크가 아닙니다. Android의 디버깅 문서는 무선 워크플로를 설명하고, 관계가 명시적으로 잊히거나 권한이 취소될 때까지 지속된다고 언급합니다.
터널을 탓하기 전에 무엇이 아직 승인되어 있는지 확인하십시오. 무선 디버깅을 열고 페어링된 기기를 보고, 더 이상 알아보지 못하는 것은 잊으십시오. 워크스테이션에서 adb devices를 실행해 어떤 항목이 아직 응답하는지 확인하고, 오래된 항목을 제거하려면 adb disconnect를 실행하십시오. 무선 디버깅을 끄면 수신 포트가 완전히 닫힙니다.
공유되거나 신뢰할 수 없는 네트워크에서는 꺼 두십시오. 통제하지 않는 네트워크에서의 영구 승인은 가상의 TUN 우회보다 더 큰 문제입니다.
그 버그를 보고하기 전에
유용한 보고서는 실패한 정확한 경계를 지목합니다. 기기 모델과 Android 릴리스, VPN 클라이언트와 버전, 잠금이 활성화되었는지, 앱 패키지와 UID, 휴대폰이 있던 네트워크를 포함하십시오. 관찰을 만든 명령이나 요청과 발생 시각도 추가하십시오. 그것이 없으면 당신이 깨졌다고 주장하는 경계를 아무도 재현할 수 없습니다.
테스트를 더 극적으로 보이게 하려고 집행을 끄거나 신뢰할 수 없는 네트워크에서 디버깅을 노출하지 마십시오. 그것은 측정 대상을 바꾸고 아무도 반복할 수 없는 증거를 남깁니다.
VPN이 켜져 있을 때 ADB가 연결되었다는 것이 유일한 증거라면, 잘못된 경로를 측정한 것입니다. 먼저 앱 수준 테스트를 다시 실행하십시오. 답은 보통 거기서 나옵니다.