VPN 출구 IP는 터널의 증거가 아니다: 서버가 보는 것

누군가 VPN 사용자만 접근할 수 있는 서비스를 요청하고, 뻔한 구현은 출구 주소 목록을 허용하는 것이다. 목록은 실제로 무언가를 한다. 누가 연결할 수 있는지를 제한한다. 터널이 사용되었다는 것을 증명하지는 않는다. 주소는 출구를 운영하는 사람의 것이고 그 운영자는 누구의 트래픽이든 전달할 수 있기 때문이다. 이 두 진술 사이의 간극이 설계 문제의 전부다.

서버는 연결마다 하나의 주소를 본다

연결은 출발지 주소와 목적지 포트를 가지고 도착하며, 네트워크 계층이 보고하는 것은 그 정도다. 클라이언트가 터널을 사용하면 당신의 리스너에 도달하는 패킷은 출구나 그 앞의 변환에서 온다. 클라이언트 자신의 주소는 보통 사설이며 결코 나타나지 않는다. 따라서 클라이언트의 LAN 범위에 맞춰 작성한 방화벽 규칙은 아무 효과도 없다.

그 출발지 주소 뒤의 모든 것은 애플리케이션 데이터이며, 애플리케이션은 그것을 인증하는 만큼만 신뢰할 수 있다.

당신의 출구가 어떻게 보이는지 시험하라

규칙을 작성하기 전에 양쪽 끝에서 경로를 보라. 클라이언트가 자기 출구에 대해 갖는 시각과 서버가 연결에 대해 갖는 시각이 중요한 두 가지 사실이다.

curl -sS https://api.ipify.org; echo
ss -tn state established '( sport = :443 )' | head

첫 번째 명령은 클라이언트가 드러나는 공인 주소를 보고하며, 어떤 허용 목록에도 반드시 이 값이 들어가야 한다. 두 번째는 서버의 설정된 연결을 상대 주소와 함께 보여 주며, 규칙이 실제로 일치하는 대상이 바로 이것이다. 둘이 당신의 정신 모델과 어긋난다면 정책을 고치기 전에 모델을 고쳐라. 클라우드 데이터베이스 방화벽, 애플리케이션 허용 목록, 로드 밸런서는 각각 다른 변환 계층을 볼 수 있다.

두 출구 집합 가운데 하나만 목록화할 수 있다

한 경우는 요청 시점에 확인할 수 있고 다른 경우는 그렇지 않으며, 이는 매우 다른 보장을 낳는다.

curl -sS https://check.torproject.org/torbulkexitlist | wc -l

공개된 Tor 출구 목록은 가져와 비교할 수 있지만 목록의 나이와 각 출구의 자체 정책에 달려 있으므로, 알려진 출구에 대한 거부 규칙은 시행 가능하고 검토 가능하다. 상용 VPN에는 이에 상응하는 등록부가 없다. 주소는 돌아가고, 많은 제공자는 아무것도 공개하지 않으며, 터널은 한 번도 VPN에 속한 적 없는 임대 클라우드 주소에서 돌아갈 수 있다. 당신이 작성하는 목록은 관찰된 주소의 스냅숏이며, 이를 호스팅 범위로 넓히면 증거를 더하지 않으면서 무관한 작업 부하를 더한다.

주소를 정책 입력으로 사용하고 증거로 사용하지 마라

규칙이 무엇을 위한 것인지 정하라. 네트워크 제한은 좁게 유지하고, 관찰된 주소를 날짜와 이유와 함께 기록하며, 정당한 사용자에게 출구가 바뀔 때 복구 경로를 주어야 한다. 접근 제어에는 인증된 계정이나 서명된 토큰이 필요하다. 오직 그것들만 요청을 신원에 묶기 때문이다. 위험 점수는 주소를 하나의 신뢰할 수 없는 신호로 사용하고 그 오탐과 사각지대를 받아들일 수 있다. 규칙을 제품 결정으로 쓰는 것은 정직하다. 터널의 존재에 대한 검증으로 쓰는 것은 그렇지 않다.

거울 요청, 즉 VPN 뒤에 있는 사용자의 실제 주소를 되찾는 것은 같은 이유로 실패한다. 하나의 연결은 하나의 주소를 나르고, 세션 사이의 변화는 여러 설명과 양립한다. 이전 값을 역사로 다루고 진실로 다루지 마라.