유출 탐지 · 기술 설명

WebRTC 유출이란

WebRTC는 브라우저에 내장된 실시간 통신 기능으로, 화상 회의, 음성 통화, P2P 파일 전송 등에 사용됩니다. 피어 간 연결을 맺기 위해 브라우저는 STUN 서버를 통해 공용 인터넷 쪽에서 보이는 자신의 주소를 알아냅니다. 이 탐지에는 보통 UDP가 사용되며, 일반적인 HTTP / SOCKS 프록시가 UDP까지 반드시 처리하는 것은 아닙니다.

STUN 요청이 프록시를 우회해 로컬 네트워크에서 직접 나가면 웹 페이지 스크립트가 실제 공인 IP를 알아낼 수 있습니다. 이 과정에는 보통 카메라나 마이크 권한이 필요 없고 추가 확인 창도 뜨지 않기 때문에, 프록시가 실시간 통신 트래픽까지 제대로 처리하는지 확인하는 데 흔히 사용됩니다.

결과 해석 방법

유출 발견 후 대처 방법

• 프록시 클라이언트를 TUN 모드로 전환해 WebRTC의 UDP도 프록시 출구를 거치게 하세요.
• Chrome / Edge: 기업 정책 <code>WebRtcIPHandling</code> = <code>disable_non_proxied_udp</code>로 설정하세요. Firefox: <code>about:config</code>에서 <code>media.peerconnection.ice.proxy_only_if_behind_proxy</code>를 활성화하세요. WebRTC를 아예 제거하지는 마세요. WebRTC가 없는 브라우저는 그 자체로 식별될 수 있습니다.
• Brave: WebRTC IP 처리 정책을 “프록시되지 않은 UDP 사용 중지”로 설정하세요.
• 회의나 음성 통화가 필요하다면 먼저 프록시 클라이언트의 UDP / STUN 라우팅 규칙을 수정하세요.

출구 IP가 여러 개라고 해서 반드시 유출은 아닙니다

분할 라우팅을 설정했다면 STUN 서버마다 다른 노드를 거칠 수 있습니다. 예를 들어 Google의 STUN은 미국 출구로, Cloudflare의 STUN은 홍콩 출구로 나갈 수 있습니다. 이런 결과가 꼭 위험한 것은 아니며, 중요한 것은 규칙 설계와 일치하는지입니다. 정말 주의해야 할 경우는 모든 WebRTC 주소가 실제 물리적 위치나 로컬 ISP를 가리킬 때입니다.

DNS 유출도 그만큼 중요합니다

WebRTC 유출은 “실제 IP”를 노출하고, DNS 유출은 “어떤 도메인을 조회했는지”를 노출합니다. DNS 요청이 프록시를 거치지 않으면 로컬 통신사나 업스트림 리졸버가 여전히 방문한 사이트를 볼 수 있습니다.

이 페이지의 DNS 유출 탐지는 실제 프로브를 사용합니다: CleanIP.io는 미국 유타(ns1)와 미국 로스앤젤레스(ns2)에서 권한 있는 NS를 각각 한 대씩 운영하며 dp.cleanip.io 영역을 서비스합니다. 탐지할 때마다 독립된 <uuid>.dp.cleanip.io 하위 도메인 8개를 조회하며, 이 쿼리는 시스템의 스텁 리졸버 -> ISP / VPN / 공용 재귀 리졸버를 거쳐 최종적으로 저희의 권한 있는 NS에 도달합니다. NS는 쿼리를 보낸 리졸버의 IP와 (있는 경우) EDNS 클라이언트 서브넷을 기록한 뒤 비교할 수 있도록 돌려줍니다.

두 가지 신호에 주목하세요. ① ECS 서브넷 — 재귀 리졸버가 클라이언트 서브넷을 전달했다면(Google 8.8.8.8에서 흔함), 그 서브넷은 클라이언트 신원을 확실히 보여 주는 증거입니다. ② 리졸버 국가 — 공용 재귀 리졸버(1.1.1.1 / 8.8.8.8)가 국경을 넘는 애니캐스트로 응답하는 것은 정상입니다. 중요한 것은 VPN을 켰다고 생각할 때 리졸버의 위치가 HTTP 출구와 같은 국가인지입니다.

프록시 모드와 TUN 모드의 결과가 다른 이유

HTTP / SOCKS 프록시는 보통 TCP만 처리하므로 STUN에 필요한 UDP가 전송되지 못할 수 있고, 페이지에 “유출 없음”이 표시될 수 있습니다. 이는 UDP가 안전하게 프록시되었다는 뜻이 아니라 UDP가 STUN 서버에 도달하지 못했다는 뜻일 뿐입니다. TUN 모드는 가상 네트워크 어댑터에서 TCP와 UDP를 모두 가로채므로 실제 UDP 출구 경로를 더 잘 반영합니다.