VPN과 TURN 릴레이: WebRTC 통화를 실제로 운반하는 것은 어느 쪽인가
터널은 ICE가 보는 경로를 바꿀 뿐, 릴레이를 할당하거나 시그널링을 제공하지 않습니다. VPN 출구와 TURN 서버가 각각 무엇을 제공하는지 비교합니다.
페이지는 VPN을 통해 로드되지만 통화는 결코 연결되지 않는다: 같은 주소 표시줄에 숨은 두 가지 다른 고장이다. 터널이 바꾼 것은 브라우저가 쓰는 경로뿐이며, 시그널링 서비스도 STUN 서버도 릴레이도 되지 않았고 ICE가 어느 후보 쌍을 고를지도 정하지 않는다. 각 구성 요소가 맡은 일을 분리하는 것이야말로 모호한 “WebRTC가 차단되었다”를 구체적인 고장으로 바꾼다.
네 가지 일, 터널이 건드리는 것은 하나뿐
애플리케이션은 어떤 시그널링 방식으로 세션 정보를 교환하며, 이것이 첫 번째 일이다. ICE는 후보 주소를 모으고 하나가 작동할 때까지 쌍을 시험하며, 이것이 두 번째다. STUN은 상대가 자신의 트래픽이 밖에서 어떻게 보이는지 알게 하고, TURN은 직접 경로가 없을 때 쓰일 릴레이를 할당한다. 이 네 역할은 서로 다르며, VPN은 그들이 만나는 주소와 필터링에 영향을 줄 뿐 어느 하나를 제공하지는 않는다.
그래서 로그인 성공은 미디어 경로에 대해 아무것도 말해 주지 않는다. 시그널링은 보통 페이지가 이미 쓰는 HTTPS를 443 포트에서 타고, 미디어는 UDP로 전혀 다른 목적지로 갈 수 있다.
사설 주소 지정은 혼란을 키운다. 터널 주소는 상대에게 그쪽으로 돌아올 의도된 경로가 있을 때만 쓸모가 있으며, 사설이라는 사실은 상호 도달성의 증거가 아니고 검사할 수 없는 후보를 버릴 때 브라우저도 그렇게 취급하지 않는다. 당신에게 로컬로 보이는 후보가 반대편에서는 검사 불가능할 수 있다. 터널이 미디어를 떨어뜨린다고 결론짓기 전에 그 틈을 배제할 가치가 있다.
VPN 출구와 TURN 릴레이를 비교하라
둘 다 패킷을 전달하기에 혼동되지만, 위의 비교 표는 기능 목록이 아니라 열 단위로 읽어야 한다. 릴레이 할당은 인증된 요청으로 만들어지는 세션별 객체이고, 터널은 경로다. 하나에는 만료되는 자격 증명이 있고, 다른 하나에는 도달 가능하거나 그렇지 않은 상대 주소가 있다.
| Component | What it contributes | What it needs to work | What it cannot do |
|---|---|---|---|
| VPN exit | Changes the observed mapping and the route packets take | A working tunnel and a policy that permits the media transport | Allocate a relay or supply signaling |
| STUN server | Reports the mapped address a peer appears to use | Reachability from the client, on its configured transport | Carry media when a direct path fails |
| TURN server | Relays media through an authenticated allocation | Valid credentials, an allowed transport and sufficient capacity | Fix a missing ICE policy or an unauthorized client |
| Signaling channel | Carries offers, answers and candidate lists | Both peers reaching the same application endpoint | Establish connectivity by itself |
포트 번호가 차이를 구체화한다. TURN은 기본적으로 UDP와 TCP에는 3478, TLS에는 5349에서 수신하며, 443을 허용하면서 그 포트들을 버리는 네트워크에서는 브라우징은 정상적으로 계속되어도 릴레이 통화는 실패한다. VPN의 포트를 바꾸어도, 중요한 포트가 터널이 아니라 릴레이 서비스에 속하므로 그것들 중 어느 것도 구성되지 않는다.
진단을 읽고 나서 통화를 시험하라
브라우저는 패킷 캡처 없이 필요한 정보를 보여 준다. 브라우저의 WebRTC 진단 페이지를 열고 통화를 한 뒤, 수집된 목록이 아니라 선택된 후보 쌍을 읽어라: 어떤 로컬·원격 후보 유형이 선택되었고, 어느 전송과 주소 체계를 거쳤으며, 경로가 직접인지 릴레이인지.
두 가지 읽는 법을 미리 알아 두면 좋다. 선택된 쌍이 사설 주소의 호스트 대 호스트라면 미디어는 추론할 수 있는 경로에 머물고, 릴레이 대 릴레이라면 통화는 릴레이 용량을 소비하고 그 서비스의 가용성에 의존한다. 선택된 쌍 없이 “확인 중”에서 멈추는 고장은 후보는 모였지만 연결성 검사를 통과한 것이 하나도 없다는 뜻이다.
그다음 같은 통화에서 같은 두 끝점을 승인된 조건 하나만 바꾸어 비교하고, 결과는 “연결됨” 표시가 아니라 양방향 미디어나 데이터로 판정하라. 후보 수집은 오디오 프레임을 하나도 나르지 않는 많은 경우에 성공한다. 변경의 반대편에서 통화를 반복하고 두 진단 캡처를 모두 보관하되, 두 번의 실행을 비교하는 편이 어느 하나만 읽는 것보다 정보가 많다. 같은 끝점, 같은 코덱, 바뀐 변수는 하나.
ICE 전송 정책을 의도적으로 relay로 둔 애플리케이션은 릴레이 후보만 요청한다. 그 설정은 릴레이를 만들지도, 빠진 자격 증명을 고치지도 않으며 요구 사항을 명시할 뿐이고, 사이트가 고른 정책 때문에 VPN이 의심받을 때 유용하다.
프라이버시 주장은 증거만큼만 좁게 유지하라
후보 노출은 터널 상태만이 아니라 브라우저와 애플리케이션 정책에 달려 있고, W3C의 피어 연결 명세는 IP 처리를 별개의 사안으로 다룬다. 따라서 연결된 VPN은 통화가 선택된 주소 하나만 드러낸다고 약속할 근거로 약하다. 같은 터널 뒤의 두 피어는 호스트를 전혀 떠나지 않는 경로를 고를 수도 있으며, 그것은 동시에 프라이버시 개선이고 연결성 제약이다.
정확히 말할 수 있는 것은 더 좁고 더 유용하다: 어떤 후보 쌍이 선택되었고, 어떤 전송이 그것을 날랐으며, 그 경로가 터널 안에 머물렀는지. 작동하는 통화와 실패하는 통화에 대해 이 세 가지 사실을 기록하면, 차이는 대개 고쳐야 할 구성 요소를 지목한다.
연결성이 작동하면 성능과 도달성을 분리하라. 손실, 지연, 대기열, MTU는 모두 올바른 후보 쌍의 하류에 있고, 끊기는 통화를 연결성 고장으로 다루면 이유 없이 후보 목록으로 돌아가게 된다.