USB를 통한 Android 역방향 테더링: 명령, 점검, 롤백

역방향 테더링은 휴대폰의 트래픽을 컴퓨터로 옮기고 그 컴퓨터의 연결을 통해 내보냅니다. USB 케이블만으로는 되지 않습니다: 휴대폰에는 라우팅을 넘겨받는 캡처 서비스가, 컴퓨터에는 그 패킷을 이어서 나르는 릴레이가 필요합니다. 경로에는 애플리케이션, 휴대폰의 캡처, USB 릴레이, 호스트의 출구라는 네 개의 홉이 있고 각기 담당이 다릅니다. 이 실행 안내서는 그 경로를 만들고, 호스트 VPN을 제자리에 두고, 결과를 신뢰하기 전에 각 홉을 점검합니다.

무엇이든 실행하기 전에 홉을 지도로 그리세요

각 홉은 자기 정책을 적용하므로 한쪽 끝에서 동작하는 결과가 다른 쪽에 대해 알려주는 것은 없습니다. 애플리케이션은 목적지와 리졸버를 고르고, 캡처 서비스는 어떤 트래픽이 릴레이로 들어갈지 정하며, 릴레이는 호스트 소켓으로 전달하고, 호스트의 라우팅과 VPN이 목적지가 마침내 보는 주소를 정합니다.

한 번에 VPN 서비스 클라이언트 하나만 휴대폰의 캡처 역할을 가질 수 있으므로 두 번째 일반 VPN 앱은 릴레이 위에 겹치지 않습니다. VPN이 컴퓨터에 속한다면 캡처 서비스는 그 컴퓨터로 가는 접근 고리이며, 원격 터널이 이미 결과를 보호한다는 증거는 아닙니다.

휴대폰을 만지기 전에 릴레이를 준비하세요

Gnirehtet 는 이 구조의 문서화된 예로, 루트가 필요 없는 VPN 서비스 클라이언트를 휴대폰에 두고 호스트에서는 ADB로 전달되는 릴레이를 쓰며, IPv4 위에서 TCP와 UDP를 지원합니다. 저장소는 이 프로젝트가 더 이상 활발히 유지되지 않는다고도 밝히므로, 참조 설계이자 실험실용 작업 도구로 다루고 관리되는 기기군에 표준으로 삼을 지원 제품으로 보지는 마세요.

adb devices
adb shell getprop ro.build.version.release
gnirehtet run

먼저 adb devices를 실행합니다. 호스트의 디버깅 키를 받아들이지 않은 휴대폰은 승인되지 않은 것으로 보고되며, 기기의 확인 요청이 승인되기 전에는 릴레이가 붙지 않습니다. gnirehtet run는 클라이언트를 설치하고 릴레이를 시작하며 캡처를 활성화하는데, 단계를 분리한 버전에서는 대신 문서화된 install, relay, start 하위 명령을 사용하세요.

ADB 접근은 기기 제어 관계이지 네트워크 설정이 아닙니다. 자신이 통제하는 컴퓨터만 승인하고, 작업이 끝나면 그 승인을 취소할 계획을 세우세요.

호스트 VPN을 다시 경로에 두세요

릴레이는 호스트의 평범한 프로세스이므로 이후 연결은 호스트의 라우팅 표를 따릅니다. 전체 터널 프로필은 그것을 실어 나르지만 분할 터널은 그렇지 않을 수 있습니다. 호스트 VPN이 앱별 제어를 쓴다면 릴레이 바이너리를 허용 집합에 넣어야 하며, 그렇지 않으면 브라우저가 보호되는 것처럼 보이는 동안 릴레이는 계속 물리 인터페이스를 씁니다.

ip route get 1.1.1.1
curl -4 https://ifconfig.me
sudo ss -tnp | grep -i relay

호스트 VPN에 연결하기 전과 후에 처음 두 명령을 실행합니다. 주소가 바뀌지 않으면 클라이언트 창이 무엇이라 하든 릴레이는 터널 위에 있지 않습니다. 사설 전용 터널은 공용 목적지를 호스트의 평소 출구에 남기는데, 이는 유출처럼 보이지만 설정한 정책대로입니다.

릴레이를 지나는 트래픽의 DNS는 호스트에서 해석되므로 어떤 서버가 이름을 보는지는 호스트의 리졸버가 정합니다. 휴대폰의 사설 DNS 설정은 릴레이를 넘어가지 않고, 휴대폰 쪽 리졸버 시험으로는 호스트의 조회를 설명할 수 없습니다.

각 홉을 따로 확인하세요

세 가지 점검을 이 순서로 합니다: 휴대폰이 릴레이에 닿는지, 릴레이가 호스트 정책 아래 목적지에 닿는지, 애플리케이션이 목적지를 올바로 해석해 쓰는지입니다. 페이지를 새로 고치며 추측하지 말고 첫 실패에서 멈추세요.

adb shell dumpsys connectivity | grep -i -A3 vpn
adb logcat -s GnirehtetRelay:V Gnirehtet:V

연결성 덤프의 VPN 네트워크 항목 은 캡처 서비스가 활성임을 보여 주고, 릴레이 자체 로그는 흐름이 도착하는지를 보여 줍니다. 둘 중 하나에 없으면 문제가 깔끔하게 갈립니다: 캡처가 없으면 휴대폰 쪽, 흐름이 없으면 호스트 쪽입니다.

호스트에서 동작하는 브라우저는 호스트 브라우저의 경로를 증명할 뿐 릴레이 프로세스의 경로를 증명하지 않습니다. 각자가 보고하는 주소를 비교하고, 사설 자원과 공용 페이지를 모두 시험하세요, 사설 전용 터널은 한쪽만 라우팅할 수 있기 때문입니다.

철거하고 실패 시 동작을 고르세요

롤백은 안내서의 일부입니다. 릴레이를 멈추고 제거하고, 캡처 클라이언트를 제거하고, 작업이 끝나면 휴대폰의 개발자 옵션에서 호스트 디버깅 승인을 취소하세요.

gnirehtet stop
gnirehtet uninstall
adb kill-server

릴레이가 사라졌을 때 휴대폰이 어떻게 해야 하는지 정하세요. 명시적으로 고르지 않으면 모바일 데이터로 되돌아가 라우팅하려던 트래픽이 새어 나갈 수 있으므로, 연결 차단 동작이나 VPN 정책을 의도적으로 설정하고 의존하기 전에 철거를 시험하세요.

승인한 호스트, 릴레이 버전, 호스트 터널 정책, 철거 단계를 기록하세요. 그 기록이 다음 역방향 테더링 설정을 또 한 번의 재발견 오후가 아니라 반복 가능한 작업으로 만듭니다.