휴대폰에는 비행기 아이콘이 떠 있고, VPN 클라이언트는 두 분째 Connecting에 있으며, 프로필은 올바릅니다. 한 시간 전 같은 건물에서 잘 동작했습니다. 아무것도 고장 나지 않았습니다. VPN은 다른 네트워크가 실어 나르는 연결이고, 비행기 모드는 그 연결을 실어 나르던 네트워크를 방금 제거했습니다. 클라이언트는 업링크 없이 할 수 있는 일이 그것뿐이라 계속 재시도합니다.

혼란스러운 점은 비행기 기호가 Wi-Fi 사용 가능 여부를 알려 주지 않고, Connecting은 클라이언트가 인증 중인지 아니면 그저 기다리는지 알려 주지 않는다는 것입니다. 이 두 가지를 분리하면 진단은 일 분이면 끝납니다.

비행기 기호는 무선 보고서가 아니다

지원되는 Android 기기에서는 비행기 모드에서도 Wi-Fi와 Bluetooth를 켜 둘 수 있고, 기기는 지난번 선택을 기억합니다. Google의 Pixel 비행기 모드 안내 가 바로 그 동작을 설명합니다. 따라서 아이콘은 셀룰러가 꺼졌다는 것만 뜻할 수 있습니다.

글리프가 아니라 실제 상태를 확인하세요. adb shell settings get global airplane_mode_on 은 모드 자체에 대해 0 또는 1을 반환하고, adb shell dumpsys connectivity 은 기기가 현재 가진 네트워크를 검증 상태와 함께 나열합니다. 이 두 출력을 합치면 아이콘이 답할 수 없는 질문에 답이 됩니다.

Wi-Fi가 꺼져 있거나, 켜져 있어도 아무것에도 연결되어 있지 않다면 VPN 엔드포인트로 가는 경로가 없고, 아무리 다시 연결해도 경로가 생기지 않습니다. 가장 먼저 배제할 사례가 바로 이것입니다. 올바른 해결책이 VPN 앱 밖에 있는 유일한 경우이기 때문입니다.

Connecting이 실제로 뜻하는 것

클라이언트는 저장된 프로필을 들고 이름을 표시하며, 아무것과도 접촉하지 않은 채 스피너를 돌릴 수 있습니다. 구성은 로컬입니다. 터널을 세우려면 도달 가능한 서버, 완료된 핸드셰이크, 라우팅할 인터페이스가 필요합니다. 마지막 부분만 동작하는 네트워크가 필요하므로, 무선이 꺼져 있어도 앞의 두 가지는 성공처럼 보일 수 있습니다.

따라서 스피너는 최소 세 가지 상황과 일치합니다. 업링크가 전혀 없는 경우, 엔드포인트에 도달하지 못하는 업링크, 도달하지만 인증에 실패하는 업링크입니다. 화면에서는 똑같아 보이고 로그에서는 완전히 다릅니다. 그래서 이런 경우 첫 번째로 유용한 산출물은 로그이며, 또 한 번의 재시도가 아닙니다.

Android 자체의 VPN 문서도 연결 수립과 별도의 상시 연결·차단 정책 사이에 같은 선을 긋습니다. 이 분리가 바로 휴대폰이 오프라인인데도 보호되는 것처럼 보이면서 터널은 없는 이유입니다.

구별할 가치가 있는 네 가지 상태

아래 네 가지 상태는 화면이 모두 똑같이 그리므로 이름을 붙일 가치가 있습니다.

StateWhat you will seeWhat to do
Airplane mode, Wi-Fi offNo networks in dumpsys, VPN retries foreverTurn Wi-Fi on, or accept that the tunnel cannot exist
Wi-Fi on, not associatedInterface exists, no default networkJoin the access point
Associated, not validatedNetwork listed, captive-portal flag setComplete the portal sign-in, then reconnect
Validated, tunnel downInternet works, VPN fails or blocksDebug the tunnel, not the radio

세 번째 행이 호텔과 공항에서 대부분의 사람을 잡습니다. 연결은 입장 허가가 아닙니다. 휴대폰을 통과시키지 않은 포털은 Wi-Fi 비밀번호를 기꺼이 받아들이고, 그다음 VPN 엔드포인트로 트래픽을 보내지 않습니다. 터널을 끈 상태에서 먼저 브라우저로 로그인하는 것이 보통 유일한 통과 방법입니다.

차단이 상황을 더 나빠 보이게 하는 이유

상시 연결 VPN과 VPN 없이 연결 차단이 모두 켜져 있으면, 터널이 올라오지 않을 때마다 적용 대상 앱이 모두 차단됩니다. 이것은 기능이 동작하는 것이지 두 번째 고장이 아닙니다. 증상은 앱 하나의 실패에서 모든 것이 실패하는 것으로 바뀌어, 훨씬 큰 문제처럼 읽힙니다.

사람들이 잘못 읽는 순서도 이것으로 설명됩니다. 비행기 모드 켜짐, 업링크 없음, 앱 차단, VPN은 connecting이라고 표시. 차단은 정책이 제 역할을 한 것이었습니다. 업링크를 시험하려고 정책을 끄면 아마 원했던 보호가 사라지고 배우는 것도 없습니다.

대신 범위를 확인하세요. 어떤 앱이 적용되고 어떤 앱이 제외되며, 프로필이 사용자별인지 기기 전체인지. Wi-Fi가 나타나면 VPN 앱을 실행하는 작업은 트리거이지, 그 전에 패킷이 나가지 않았다는 보장이 아닙니다.

추측을 끝내는 진단 순서

아래에서 위로 진행하세요. 모드를 확인하고, 네트워크가 있는지 확인하고, 검증되었는지 확인하고, 로컬 서브넷 밖의 무언가에 도달할 수 있는지 확인한 다음에야 클라이언트를 보세요. adb shell ping -c 3 1.1.1.1 은 거친 테스트지만, 없는 경로와 터널이 불만인 채 존재하는 경로를 구분합니다.

네트워크가 목록에 있는데 ping이 실패하면 문제는 VPN보다 상류에 있고 어떤 클라이언트 설정도 고치지 못합니다. ping이 성공해도 터널이 서지 않는다면 그 순간 클라이언트 로그를 확보하세요. 오류가 시간 초과와 인증 거부를 구분해 주며, 이 둘은 공통점이 없습니다.

의도한 상태로 되돌리며 마무리하세요. 평소 설정이라면 비행기 모드에서 Wi-Fi를 허용하고 포털을 완료한 뒤 차단 정책을 다시 켜고, 그다음 한 번 다시 연결해 터널이 스스로 올라오는지 확인하세요. 수동 재시도 후에만 동작하는 구성은 다음 부팅에서 또 실패합니다.

관련 글