WebRTC 후보 목록이 VPN에 대해 알려주는 것

WebRTC 테스트 페이지가 172.20.4.15를 출력하면, 그 페이지는 해당 네트워크에 로컬 인터페이스가 있음을 알아낸 것입니다. 이것은 실제 노출이지만 «미디어가 VPN 출구로 나갔다»는 것과 같은 발견은 아닙니다. 후보 탐색과 패킷 라우팅은 별개의 메커니즘이며, 대부분의 누출 보고서는 둘을 하나의 판정으로 합칩니다. 어느 쪽을 보고 있는지가 해결책을 결정합니다.

수집은 무엇이든 전송되기 전에 일어납니다

브라우저는 로컬 인터페이스를 열거하고, STUN 서버에 바인딩 요청을 보내고, TURN 서버에 할당을 요청한 뒤, 그 결과를 세션 기술에 후보 줄로 기록합니다. 이 모든 것은 통화도, 미디어도, 상대방도 없이 끝납니다. 따라서 후보 목록은 전송이 아니라 발견의 기록입니다.

최신 브라우저는 호스트 후보의 실제 주소를 mDNS 이름 .local로 바꿀 수 있어, 페이지가 사설 IP를 읽을 수 없습니다. 로컬 네트워크는 그 이름을 해석하는 멀티캐스트 질의를 여전히 보므로, 주소는 회선에서 사라진 것이 아니라 애플리케이션에서 숨겨진 것입니다.

순서도 중요합니다. 페이지를 새로 고치면 새 집합이 수집되고 TURN 할당과 반사 매핑이 달라질 수 있어, 서로 어긋나는 두 번의 실행이 반드시 두 가지 다른 구성은 아닙니다.

세 가지 후보 유형, 세 가지 증거

각 줄은 서로 다른 관찰에서 나옵니다. 유형마다 다른 질문에 답하며, 표는 무엇을 입증할 수 있고 무엇을 입증할 수 없는지에 따라 후보들을 구분합니다.

릴레이 후보는 흔히 사용자의 인터넷 주소로 오해됩니다. 그것은 TURN 서버에 속하며, 존재 자체는 릴레이가 사용 가능했다는 뜻이지 브라우저가 그것을 선택했다는 뜻이 아닙니다. 같은 혼동이 호스트 후보에서는 반대 방향으로 일어나, mDNS 이름이 페이지에서 주소를 숨기지만 네트워크는 여전히 질의를 나릅니다. 값을 읽기 전에 유형을 읽으십시오.

선택된 쌍이 라우팅 질문에 답합니다

ICE는 모든 로컬 후보를 모든 원격 후보와 짝짓고, 각 쌍에 연결성 검사를 실행하고, 승자를 지명합니다. 브라우저 자체 진단에 보이는 그 지명된 쌍이 미디어를 나릅니다. 목록의 나머지는 모두 패배한 가능성입니다.

승자는 경로의 모양을 알려 줍니다. 릴레이 대 릴레이는 TURN 서버를 거치고, 호스트 쌍은 로컬 네트워크에 머물며, 서버 반사형 쌍은 NAT를 통해 직접 갑니다. 이것이 VPN 점검에 필요한 사실이며, 주소 목록과는 다른 사실입니다. 동일한 후보 목록을 가진 두 통화가 서로 다른 쌍을 택할 수 있습니다.

선택되지 않은 후보도 여전히 수집되었고, 수집은 기기에서 나가는 네트워크 트래픽입니다. 결국 릴레이를 사용한 통화라고 해서 목록을 만드는 동안 아무것도 노출되지 않았다는 뜻은 아닙니다.

제어는 누출 점수가 아니라 목표에 대응합니다

WebRTC의 IP 처리 명세는 기본 경로를 나르는 인터페이스만 사용하는 것, 모든 인터페이스를 사용하는 것, 그리고 프록시되지 않은 UDP를 꺼서 트래픽이 릴레이나 프록시를 거치게 하는 것 등 몇 가지 정책을 설명합니다. 각각은 연결성과 지연을 다른 종류의 노출과 맞바꿉니다. 브라우저가 어느 것을 어떤 이름으로 구현하는지는 플랫폼과 버전에 따라 다릅니다.

목표에서 정책을 고르십시오. 페이지에서 로컬 주소를 숨기는 것이 하나의 목표이고, 직접적인 피어 간 트래픽을 막는 것이 또 하나이며, 모든 패킷을 터널 안에 두는 것이 세 번째입니다. 첫째는 주로 애플리케이션이 무엇을 아는지, 둘째는 어떤 경로가 허용되는지, 셋째는 플랫폼이나 VPN 경계에서도 강제해야 합니다.

어떤 제어를 고르든, 수집 테스트를 실행해 후보 유형을 기록하고 그다음 실제 세션에서 선택된 쌍을 살펴보는 방식으로 두 절반을 모두 확인하십시오. 직접 미디어 경로를 가진 깨끗한 주소 목록도 의도하지 않은 경로입니다.