VPN을 켰을 때만 사이트가 차단하나요? 사이트가 보는 것은 이겁니다

상점은 집에서는 잘 열리지만 터널이 올라오는 순간 «비정상 트래픽»의 벽이 나타납니다. 포럼은 로그인을 거부하고, 스트리밍 페이지는 당신이 한 번도 가본 적 없는 나라에 있다고 주장합니다. 그중 어느 것도 스파이웨어를 필요로 하지 않습니다. 사이트는 패킷이 도착하는 주소를 보며, VPN을 쓰면 그 주소는 가정용 회선이 아니라 데이터센터의 것이 됩니다. VPN 탐지라고 불리는 것의 대부분은 이 한 가지 사실에서 시작하고 끝나며, 나머지는 예측 가능한 오류율을 가진 추론입니다.

차단은 패킷이 어디서 오는 것처럼 보이는지에서 시작됩니다

모든 요청은 출발지 주소를 지니며, 받는 서버는 이를 공개 데이터에서 조회할 수 있습니다. 어느 네트워크가 이를 알리는지, 그 네트워크가 호스팅 제공자인지, 남용 목록에 오른 적이 있는지, 등록기관이 어느 나라를 배정하는지 말입니다. 그중 어느 것도 당신을 식별하지 않지만, 모두 합치면 분류하기에 충분합니다.

자신의 트래픽을 낯선 사람의 눈으로 보세요. 두 명령이 표면의 대부분을 덮으며, 두 번째가 사람들이 잊는 것입니다.

curl -sS https://ipinfo.io/json
dig +short TXT o-o.myaddr.l.google.com @ns1.google.com

첫 번째는 출구 주소, 그 조직과 국가를 돌려줍니다. 두 번째는 Google 네임서버에 도달한 리졸버의 주소를 돌려줍니다. 이는 흔히 출구와 다른 네트워크에 속하며, 사이트가 리졸버 측 데이터를 기록하면 보게 되는 주소입니다. 이 둘이 서로 다른 나라에 속하면, 설정에 아무 문제가 없어도 일부 사이트는 그 불일치를 의심스럽게 봅니다.

거부가 터널이 올라온 뒤에야 시작된다면 무엇보다 출구 주소를 의심하세요. 브라우저를 건드리기 전에 서버를 바꾸고 다시 시도하세요. 같은 제공자의 세 출구에서 따라다니는 차단은 제공자의 대역에 관한 것이고, 다른 서버에서 사라지는 차단은 그 하나의 주소에 관한 것입니다.

시간대, 언어, 시계가 주소와 일치하지 않습니다

페이지 코드는 권한 요청 없이 당신의 시간대, 언어 기본 설정, 화면 설정을 읽을 수 있습니다. 연결이 싱가포르 데이터센터에서 오는데 브라우저가 중부 유럽 시간을 보고하는 것은 주소만보다 강한 신호이며, 사기 점수가 바로 그런 불일치를 알아채도록 만들어졌습니다.

Intl.DateTimeFormat().resolvedOptions().timeZone
navigator.language
Intl.DateTimeFormat().resolvedOptions().locale

개발자 콘솔의 그 세 줄은 브라우저가 자발적으로 무엇을 주는지 알려줍니다. VPN 클라이언트는 경로만 바꿀 뿐이므로, 들고 다니는 프로필은 국내로 남지만 출구는 그렇지 않습니다. 여기서 중요한 것은 일관성입니다. 출구와 같은 지역으로 설정된 노트북은 평범해 보이지만, 스스로 모순되는 노트북은 그렇지 않습니다.

실패가 간헐적인 것도 그 때문입니다. 많은 사이트는 신경 쓰지 않고, 몇몇은 점수를 매기며, 한 회원제 사이트는 당신을 사기꾼이라고 판단합니다. 클라이언트는 세 경우 모두 올바르게 작동하며, 그래서 «분명 브라우저 문제일 겁니다»라는 흔한 지원 답변은 짜증나면서도 부분적으로 맞습니다.

페이지 코드가 실제로 아는 것

JavaScript에는 네트워크 인터페이스를 나열하는 API가 없습니다. 페이지는 노트북이 어떤 주소를 가졌는지 물을 수 없으므로, 스크립트가 LAN 주소를 읽는다는 옛 주장은 대부분 플러그인 시대의 기억입니다. 그때는 ActiveX 컨트롤, Java 애플릿 및 다른 네이티브 코드가 정확히 그 일을 할 수 있었습니다.

WebRTC는 «로컬 주소 유출 없음» 원칙의 정직한 예외입니다. 한때 후보 수집은 요청하는 모든 페이지에 로컬 주소를 노출했고, 수정은 호스트 후보를 무작위 mDNS 이름으로 바꾸는 것이었습니다. 그 기본값은 현재 브라우저에서 유지되지만 프로토콜 보장이 아니라 브라우저의 결정이므로, 오래된 빌드나 로컬 후보를 다시 활성화하는 강화된 구성은 여전히 유출될 수 있습니다. 여기서는 어떤 확장보다 브라우저 업데이트가 더 도움이 됩니다.

제공자는 내용이 아니라 이름을 봅니다

HTTPS는 페이지 내용을 처음부터 끝까지 보호하며, 그 바이트를 전달하는 터널 운영자는 이를 읽을 수 없습니다. 운영자는 여전히 당신이 어느 주소에 접속했는지 볼 수 있습니다, 그리고 대부분의 배포에서는 핸드셰이크의 서버 이름도 볼 수 있습니다. 연결이 올바른 사이트로 라우팅되려면 이름을 읽을 수 있어야 하기 때문입니다. Encrypted Client Hello는 바로 그 필드를 숨기기 위해 존재하며, 클라이언트와 사이트가 모두 지원할 때만 도움이 됩니다.

이름 해석은 나머지 절반입니다. 제공자가 리졸버도 제공하면, 어떤 연결이 생기기 전에 당신이 찾는 모든 이름을 봅니다. 기기가 HTTPS로 공용 리졸버를 쓰면, 제공자는 그 리졸버로 가는 연결만 보고 목록은 리졸버 자신이 봅니다.

암호화되지 않은 HTTP 요청은 호텔 네트워크에서 읽히는 것과 같은 이유로 운영자에게도 읽힙니다. 내부에 암호화된 것이 없습니다. 터널은 결코 그 반대를 주장하지 않았고, 애플리케이션의 선택을 고쳐 주지도 않습니다.

«이것은 VPN»과 «이것은 나»를 분리하세요

탐지는 저렴하고 확률적이며 자주 틀립니다. 공유 출구 주소는 누군가가 남용했기 때문에 표시되고, 기업 대역은 호스팅으로 분류되며, 이동통신사는 모두를 놀라게 하는 지리적 결과를 냅니다. 식별은 다른 문제입니다. 로그인한 계정, 쿠키, 결제 정보, 또는 메모를 비교하는 두 관찰자 같은 지속적인 연결이 필요합니다.

실제로 무엇과 싸우고 있는지 결정하세요. 목표가 페이지를 읽는 것이라면 HTTPS가 이미 그 일을 하고 터널은 거의 바꾸지 않습니다. 목표가 사이트가 당신이 어느 도시에 있는지 모르게 하는 것이라면 출구와 리졸버가 중요합니다. 목표가 실제 신원과의 연결을 끊는 것이라면 계정이 약점이며, 서버를 바꾸는 것은 방금 사용한 로그인에 아무 효과도 없습니다.

새 출구는 어디서도 로그아웃시키지 않으며, 사이트가 사용한 계정에 대해 이미 저장한 것을 지울 수도 없습니다. 따라서 실용적인 순서는 화려하지 않습니다. 네트워크가 평범해 보이는 출구를 고르고, 브라우저 프로필을 그에 맞게 유지하고, 유출에 취약한 기능이 현대적 기본값을 쓰도록 브라우저를 업데이트하고, 소수의 사이트는 여전히 당신에 대해 잘못 추측할 것임을 받아들이세요.