VPN 앱을 끄면 인터넷이 멈출 때 확인할 네 계층

무료 VPN 클라이언트나 브라우저 확장을 일주일 써 보고 끄면 인터넷이 멈춘다. Wi-Fi 아이콘은 여전히 연결을 보여 주고, 같은 공유기에 붙은 다른 기기는 멀쩡하며, 브라우징을 되살리는 것은 앱을 다시 켜거나 삭제하는 것뿐이다. 이 패턴은 암호화가 의존성을 만든 것이 아니다. 앱이 터널이 소유하지 않은 어딘가에 써 둔 설정이다.

클라이언트는 터널이 소유하지 않은 설정을 고친다

Windows나 macOS의 프라이버시 클라이언트는 보통 세 곳을 동시에 건드린다. 인터넷 옵션이 노출하는 것과 같은 항목인 시스템 HTTP 프록시를 설정한다. 패킷을 잡기 위해 흔히 TAP 드라이버인 가상 어댑터를 설치한다. 그리고 확인자 목록을 다시 쓴다. 그런데 연결 끊기를 누를 때 사라지는 것은 터널뿐이다.

브라우저 확장은 범위가 더 좁다. 보통 자기 프로필이나 그 브라우저 하나가 따르는 프록시를 바꾼다. 그래서 한 브라우저만 실패하고 명령줄 도구는 계속 동작할 수 있고, 그 반대도 가능하다. 확장은 다른 계층을 건드릴 권한이 애초에 없었던 것이다. 어느 계층을 편집했는지가 어느 도구가 깨지는지를 결정한다.

어느 쪽이든, 그 낡은 결정은 되돌릴 이유가 없는 소프트웨어가 내린 것이다. 터널은 눈에 보이는 부분이었고, 깔끔하게 종료되는 유일한 부분이기도 했다. 나머지는 프로세스보다 오래 사는 저장소의 설정이므로, 앱을 제거하는 것이 세 가지를 한 번에 되돌리는 유일한 단계다. 무엇이든 다시 설치하기 전에 그 저장소를 읽는 것이 증상을 진단으로 바꾼다.

세 가지 잔재, 세 가지 다른 고장

첫 번째 잔재는 아무것도 가리키지 않는 프록시다. LAN 프록시 확인란이 그대로 켜져 있거나, 이제 아무 프로세스도 듣지 않는 localhost 포트를 가리키는 구성 스크립트 URL이 남아 있다. 브라우저는 모든 요청을 그 죽은 포트로 보내고, 시간 초과가 마치 네트워크가 죽은 것처럼 보일 때까지 멈춰 있다. 두 번째는 기본 경로를 여전히 쥐고 있는 어댑터다. TAP-Windows 장치나 벤더 라우팅 드라이버는 제거 후에도 실제 인터페이스로 남는다. 부여받은 경로를 계속 유지하며 트래픽은 존재하지 않는 터널로 사라진다. 어느 잔재도 스스로 알리지 않고, 둘 다 정전처럼 보인다.

세 번째는 DNS이며, 다른 둘보다 더 일찍 실패한다. 확인자 목록에 터널을 통해서만 닿는 서버만 있으면, 페이지를 하나 요청하기도 전에 모든 조회가 시간 초과된다. 그래서 브라우저는 죽은 프록시가 아니라 닿을 수 없는 사이트로 보고한다. 어느 경우든 네트워크 의미의 장애가 아니다. 각각은 아무도 취소하지 않은 잔재이고, 각각 다른 곳에서 고친다.

네 계층을 차례로 내려가며 확인한다

애플리케이션에 가장 가까운 계층에서 시작해 아래로 내려간다. 계층은 그 가시성 순서대로 실패하기 때문이다. 시험마다 한 계층만 바꾸고 매번 다시 시험한다. 모든 것을 한 번에 초기화하면 브라우징은 대개 돌아오지만, 어떤 잔재가 원인이었는지 말할 수 없게 되어 다음 설치에서 같은 수수께끼가 재현된다. 순서는 프록시, 어댑터, 경로, 확인자다.

Windows에서는 각 점검이 운영체제에 포함된 명령 하나로 끝나므로 아무것도 설치할 필요가 없다. 순서대로 실행하고 출력을 함께 보관한다. 네 가지 답은 나란히 놓아야 의미가 있기 때문이다. 프록시, 어댑터, IPv4 경로, 확인자 목록을 그 순서로 보고한다:

netsh winhttp show proxy
Get-NetAdapter
route print -4
Get-DnsClientServerAddress

Linux와 macOS에는 각자의 명령이 필요하며 서로 호환되지 않는다. Linux에서는 경로는 ip route에서, 확인자는 systemd-resolved가 관리하는 경우 resolvectl status에서 얻고, 아니면 cat /etc/resolv.conf로 돌아간다. macOS에서는 경로는 netstat -rn에서, 확인자는 scutil --dns에서, 시스템 프록시는 scutil --proxy에서 얻는다. macOS 사용자가 ip route를 실행하면 command not found가 나오고, 그곳의 /etc/resolv.conf는 권위 있는 구성이 아니라 생성된 스텁이다. 계층을 확인하기 전에 플랫폼을 확인하지 않으면 첫 명령이 곧 발견이 된다.

각 계층마다 한 가지를 묻는다. 앱이 꺼져 있는 동안에도 이 값이 실재하는 무언가를 가리키는가. 죽은 포트의 프록시, 터널 없는 어댑터, 내려간 인터페이스를 지나는 기본 경로, 터널 안의 확인자는 모두 아니오다. 어느 하나의 아니오로도 증상을 설명할 수 있기에 시험마다 한 번의 변경이 중요하다.

프록시는 터널이 아니다

프록시는 요청을 받아 다른 곳에서 가져와 응답을 돌려준다. 즉 목적지를 알고 있으며 사이트가 스스로 암호화하지 않은 것은 무엇이든 본다. 다른 프로토콜을 운반하지 않는다. 목적지가 이미 TLS를 쓰지 않는 한 경로를 보호하지 않는다. 그리고 설치한 무엇이든 당신의 개입 없이 바꿀 수 있다.

이 구분은 물어야 할 질문을 바꾼다. 프록시가 남아 있다면 터널이 올라와 있는지가 아니라 어떤 프로그램이 아직 브라우저를 조종하는지를 찾아야 한다. 터널은 완전히 건강하면서 이 고장과 전혀 무관할 수 있다.

그런 클라이언트가 실제로 무엇을 했는지 알고 싶다면 대시보드를 읽지 말고 관찰하라. Process Monitor는 그것이 건드린 레지스트리 키와 파일을 기록하고, 패킷 캡처는 트래픽이 어디로 갔는지 드러낸다. 둘 다 평범한 도구이며, 어떤 상태등보다 잔재에 관한 질문에 잘 답한다. 둘 다 앱이 계속 실행 중일 필요가 없다.

증거가 아니라 구성 요소를 제거한다

지속되는 해결책은 설정을 쓴 것을 제거하는 것이다. 앱을 제거하고, 그것이 추가한 가상 어댑터를 지우고, 프록시와 확인자 목록을 비운 뒤 재부팅하고 앱을 설치하지 않은 상태로 시험한다. 그때 브라우징이 된다면 임시방편이 아니라 원인을 찾은 것이다. 어느 계층이 낡았는지 적어 두라. 같은 벤더는 같은 실수를 두 번 반복하는 경향이 있다.

다음 클라이언트를 설치한 뒤 증상이 돌아오면, 서비스가 무언가를 망가뜨렸다고 단정하기 전에 네 계층을 다시 걸어라. 증거는 대개 네 곳 중 하나에 아직 있다. 두 번째 앱이 다섯 번째 계층을 만드는 것이 아니라 네 층 중 하나를 편집한다.

재설치는 프록시를 되돌리지만 낡은 어댑터는 되돌리지 않으며 확인자 두 개를 목록에 남길 수 있다. 이 비대칭이 모든 것을 초기화하는 버튼보다 제거 후 시험이 나은 이유다. 다음에 연결이 끊길 때 비교할 기준선도 준다.