VPN이 예전 IP를 유출한 게 아니라, 기억된 값이 그랬다

VPN이 켜진 뒤 서비스 보고서에서 예전 공인 주소를 보는 것 자체가 유출의 증거는 아니다. 실제 연결은 터널 출구를 쓰고 있는데 앱이 터널이 생기기 전에 배운 값을 보내는 것일 수 있다. 이는 서로 다른 두 증거이며, 현재 패킷을 설명하는 것은 하나뿐이다. 다른 하나는 네트워크 경로의 어떤 것도 소유하지 않기 때문에 재연결을 살아남은 값이다.

하나의 주소 뒤에 있는 두 가지 설명

사람들이 상상하는 순서는 VPN이 활성화된 줄 알 때 물리 인터페이스를 떠나는 패킷이다. 보고서를 흔히 설명하는 순서는 더 짧고 따분하다—앱이 이전에 주소를 배웠고 아직 들고 있다. 사건을 차례로 늘어놓으면 둘이 갈린다.

Address learned before the tunnel: P1
Tunnel up: the next request exits at P2
Application reuses its retained P1 in a message body
Receiver logs source P2 and submitted value P1

그 순서 어디에도 첫 주소로부터의 실제 연결은 필요 없다. 기억된 값은 메시지 안을 타고 흐르고, 헤더는 현재 경로가 고른 출구를 나른다. 두 필드를 모두 기록하는 서비스는 그것을 나란히 보여 주며 모순처럼 보일 것이다.

그것은 가능한 설명이지 특정 클라이언트에 대한 비난이 아니다. 평판은 증거가 아니다—읽을 수 있는 코드베이스, 신뢰하는 브랜드, 다른 출구는 한 프로그램이 무엇을 보관했고 보냈는지 아무것도 말해 주지 않는다.

앱의 기억은 재연결보다 오래 남는다

VPN에 연결하면 새 연결이 지나는 경로가 바뀐다. 앱 상태는 그대로 두고, 원격 서비스가 이미 저장한 정보를 되돌릴 수도 없다. 프로그램은 계정 식별자, 저장된 위치, 기기 이름 또는 이전에 얻은 다른 값을 보낼 수 있고, 암호화는 그 페이로드를 이동 중에 보호하지만 아무것도 빼내지 않는다. 재연결은 네트워크 사건이고, 보관된 값은 앱 사건이다.

이 구분이 중요한 이유는 둘이 다른 곳에 살기 때문이다. 앱 상태는 프로그램에 속하고 재시작을 견디며, 경로는 운영체제에 속해 연결할 때마다 다시 만들어진다. 하나를 지워도 다른 하나에는 영향이 없다.

서비스는 몇 달 전에 건넨 값을 보관할 수도 있고, 그 경우 어떤 로컬 변경도 그것을 지우지 못한다. 그것은 보관이며 터널 완전히 밖에 있다.

먼저 출발지 헤더를, 다음에 페이로드를 읽는다

주소가 어디에 나타났는지부터 정하자. 서버의 연결 로그는 실제 출발지를 설명하고, 메시지 필드, 계정 프로필, 로컬 진단 화면은 훨씬 전에 보내거나 저장한 값을 설명할 수 있다. 그 관찰들은 다른 질문에 답한다.

시각도 비교하자. 예전 주소가 VPN 연결보다 앞선 필드에 나타나면 페이로드 설명이 더 강하다. 터널이 켜져 있는 동안 서버가 예전 주소에서의 직접 연결을 기록하면 그것은 라우팅 문제이며 다른 조사가 필요하다. 관찰 유형을 먼저 정리하면 하나의 주소가 세 사건의 증거로 늘어나는 것을 막는다.

메모에서 따로 보관하자—연결 출처, 메시지 필드, 계정 화면, 로컬 진단. 네 곳에 적힌 하나의 주소는 여전히 하나의 주소다.

보관은 전송과 다른 단계다

RFC 6973의 프라이버시 지침은 수집, 이용, 공개, 보관을 별개의 단계로 다루고, 재사용된 식별자가 상관을 쉽게 만든다고 경고한다. 새 네트워크 경로는 전송 단계를 바꿀 뿐 그 밖의 것은 바꾸지 않는다. 수신자가 이미 가진 기록은 영향을 받지 않고, 입구에서 값을 저장한 프로필도 마찬가지다. 그래서 전송이 올바르게 동작해도 재연결은 실패한 것처럼 느껴질 수 있다.

어떤 패킷 필터도 수신자의 기록에서 값을 지울 수 없고, 다시 연결한다고 해서 모든 프로그램의 저장 기록이 지워지지도 않는다. 이것은 터널이 아니라 데이터 소유자의 문제이며 다른 종류의 해법이 필요하다. 네트워크에 숨겨 달라고 하기 전에 서비스가 무엇을 얼마나 보관하는지 물어보자.

터널을 탓하기 전에 확인할 것

앱의 문서화된 수집과 계정 제어를 검토하고, 어떤 필드를 보낼 수 있는지, 서비스가 얼마나 보관하는지, 계정에서 지우거나 고칠 수 있는지 정하자. 그다음 설명을 가르는 시험을 하자—새 계정이나 깨끗한 앱 프로필이다. 예전 값이 사라지면 보관이나 캐시 상태가 관련되었다. 깨끗한 프로필에서도 남으면 VPN이 실패했다고 결론짓기 전에 실제 요청 필드를 살펴보자.

직접 연결이 정말 있다면 네트워크 경로의 발견으로 다루자. 라우팅, 분할 터널, 클라이언트 정책을 각자의 조건으로 조사하고, 그 결과를 단지 재연결을 살아남은 페이로드 값과 섞지 말자. 두 고장은 스크린샷에서는 비슷해 보이고 캡처에서는 전혀 다르게 행동한다.