DNS 유출
웹사이트에 접속하기 전에 기기는 도메인을 IP로 해석합니다. 이 단계가 프록시를 거치지 않으면, 이후 연결이 암호화되고 제대로 프록시되더라도 ISP의 리졸버가 사용자가 방문하는 모든 도메인을 보게 됩니다.
흔한 원인은 시스템 수준의 DNS 설정이 프록시 규칙보다 우선하거나, 프록시 클라이언트가 처음부터 DNS를 처리하지 않는 경우입니다.
TLS 연결 핑거프린트
JA4 / JA3 — 클라이언트의 TLS 핸드셰이크 특성
TLS 핸드셰이크 핑거프린트를 수집하는 중…
작동 방식
IP 유출이란 무엇이며, 프록시를 켜도 유출되는 이유
유출이란 프록시나 VPN을 거친다고 생각한 트래픽 중 일부가 이를 우회해 로컬 네트워크로 바로 나가면서 실제 IP를 상대방에게 넘겨주는 것을 말합니다. 프록시 클라이언트에 ‘연결됨’이 표시된다고 해서 모든 요청을 제어하고 있다는 뜻은 아닙니다.
WebRTC 유출
WebRTC는 브라우저에 내장된 피어 간 통신 기능으로, 화상 통화와 화면 공유가 이를 기반으로 작동합니다. 직접 연결을 맺기 위해 STUN 서버에 ‘내 공인 주소가 무엇인가’를 묻는데, 이 요청이 프록시를 우회할 수 있습니다.
그 결과 페이지에는 프록시의 IP가 보이지만 WebRTC는 실제 IP를 넘겨줍니다. 가장 전형적이면서도 가장 간과하기 쉬운 유출입니다.
IPv6 유출
많은 프록시는 IPv4만 처리합니다. 네트워크에 IPv6도 있고 대상 사이트가 이를 지원하면 브라우저가 IPv6 직접 경로를 우선 사용할 수 있어, 프록시가 아예 무용지물이 됩니다.
판단 방법은 간단합니다. 이 페이지에 IPv4와 IPv6가 함께 표시되고 둘이 서로 다른 네트워크에 속한다면, 트래픽이 두 스택으로 나뉘어 나가고 있는 것입니다.
시간대와 일관성
엄밀히 말해 이것은 유출이 아니라 모순입니다. 시스템 시간대, 브라우저 언어, IP 위치는 서로 일치해야 합니다. 미국 IP에 UTC+8 시계라면 그 자체로 강한 신호입니다. 위험 관리 시스템은 사용자의 실제 IP를 알 필요 없이, 위장하고 있다는 증거만 있으면 됩니다.
자주 묻는 질문
유출이 발견되지 않았다면 안전합니까?
이번 검사가 다루는 경로에 현재 유출이 없다는 뜻입니다. 확장 프로그램, 다른 애플리케이션, 시스템 업데이트 모두 새로운 유출 경로를 만들 수 있으므로 설정을 바꾼 뒤에는 다시 테스트하세요.
DNS 유출은 어떻게 해결합니까?
먼저 프록시 클라이언트에서 ‘프록시를 통해 DNS 해석’ 또는 이에 해당하는 옵션을 켜세요. 그래도 안 되면 시스템 DNS를 프록시가 제공하는 주소로 지정하세요. 브라우저의 보안 DNS 설정을 바꾸면 해당 브라우저 프로세스에만 적용됩니다.
WebRTC를 꺼야 합니까?
끄는 것은 권장하지 않습니다. WebRTC가 없는 Chromium 브라우저는 그 자체로 식별될 수 있습니다. 대신 WebRTC가 사용할 수 있는 경로를 제한하세요. Chrome / Edge에서는 기업 정책 WebRtcIPHandling을 disable_non_proxied_udp로 설정하고, Brave에서는 ‘Disable non-proxied UDP’를 선택하고, Firefox에서는 about:config에서 media.peerconnection.ice.proxy_only_if_behind_proxy를 활성화하세요. 가장 확실한 해결책은 프록시 클라이언트의 TUN 모드입니다.
IPv6 유출이 있으면 어떻게 해야 합니까?
프록시가 IPv6도 처리하게 하거나, 시스템 네트워크 설정에서 IPv6를 비활성화하세요. 후자가 더 확실하지만 IPv6 전용 서비스를 사용할 수 없게 됩니다.