VPN, 프록시, 확장 프로그램과 WebRTC
작성 · 수정
주소를 숨기려고 VPN이나 개인정보 확장 프로그램을 쓰는 사람들은 화상통화 품질이 나빠지거나 테스트 페이지에 진짜 주소가 그대로 보이는 일을 겪곤 합니다. 두 관찰 모두 맞고, 둘 다 WebRTC가 동작하는 방식에서 나옵니다. 이 글은 VPN이나 프록시 뒤에서 통화가 달라지는 이유, WebRTC가 드러낼 수 있는 것, 표준이 말하는 절충, 내 설정을 점검하는 방법을 설명합니다.
WebRTC는 왜 웹사이트보다 더 많은 것을 볼까
브라우저가 일반 웹 페이지를 불러올 때 서버가 내 네트워크에 대해 보는 것은 하나, 요청이 온 공인 주소뿐입니다. WebRTC 통화는 더 많이 필요합니다. 상대에게 가는 경로를 찾으려고 브라우저는 자신에게 닿을 수 있는 모든 주소를 모아 그 목록을 통화 페이지에 넘깁니다. WebRTC가 IP 주소를 어떻게 다뤄야 하는지 정한 RFC 8828은 이 효과를 설명합니다. 연결 정보를 수집하면 사설 주소와 공인 주소가 여럿 웹 애플리케이션에 전달될 수 있고, 일반 요청보다 사용자의 네트워크에 대해 더 많은 것이 드러날 수 있다는 것입니다.
직접 경로에는 실제 주소가 필요하므로 통화에는 유용하지만, VPN이 모든 것을 숨겨 주리라 기대하는 사람에게는 개인정보 문제입니다. 표준은 세 가지 상황을 꼽습니다. 모든 트래픽을 보내지 않는 VPN에서는 브라우저가 VPN의 주소와 함께 인터넷 업체가 배정한 주소도 찾을 수 있어 VPN을 쓰는 목적이 무너집니다. NAT 뒤에서는 사설 주소를 알아낼 수 있고 이는 식별 정보로 쓰일 수 있습니다. 프록시에서는 STUN 요청이 프록시를 우회해 클라이언트의 공인 주소를 보여줄 수 있습니다. 문서는 VPN 사례를 가장 중요하게 봅니다.
표준이 브라우저에 허용하는 것
RFC 8828은 브라우저가 주소를 얼마나 드러낼지에 따라 네 가지 모드를 정의하며, 무엇을 얻고 무엇을 포기하는지가 분명하게 적혀 있습니다.
- 모드 1은 모든 네트워크 인터페이스를 씁니다. 미디어 경로는 가장 좋지만 가장 많이 드러내며, 표준은 사용자 동의 없이 써서는 안 된다고 말합니다.
- 모드 2는 기본 경로와 그 인터페이스의 사설 주소를 씁니다. 미디어는 대체로 웹 트래픽과 같은 길을 가고 직접 연결도 가능합니다. 동의가 없을 때의 기본값입니다.
- 모드 3은 기본 경로만 쓰고 사설 주소를 공유하지 않습니다. 덜 드러내지만 트래픽이 릴레이를 거치거나 NAT를 돌아가거나 실패할 수 있습니다.
- 모드 4는 웹 트래픽에 쓰는 프록시로 미디어를 강제로 보냅니다. 주소는 숨겨지지만 프록시에는 대개 UDP 지원이 없어서 미디어가 품질이 낮은 TCP로 넘어갑니다.
패턴은 분명합니다. 개인정보를 더 지킬수록 통화 품질이나 안정성이 희생되고, 어느 쪽에 무게를 둘지는 필요에 달려 있습니다. 상대에게 위치를 숨겨야 하는 사람과 그저 매끄러운 회의를 원하는 사람은 서로 다른 설정이 필요합니다.
VPN이 통화에 하는 일
- VPN은 모든 것을 다른 도시나 다른 나라의 서버로 돌릴 수 있습니다. 원래 가장 짧은 경로로 갈 미디어에 거리와 지연이 더해집니다.
- 일부 VPN은 UDP를 막거나 웹 트래픽만 터널로 보냅니다. 그러면 구성에 따라 브라우저가 좋은 경로를 못 찾거나 VPN과 함께 실제 네트워크도 찾습니다.
- 상대 브라우저가 보는 내 공인 주소는 VPN의 주소일 수도, 내 주소일 수도, 둘 다일 수도 있습니다.
- 무료 VPN은 과부하인 경우가 많고, 화면이 얼어붙고 소리가 로봇처럼 들리는 증상으로 나타납니다.
- 일부 회사 VPN은 통화가 잘 돌아가도록 미디어가 터널을 우회하게(스플릿 터널링) 일부러 설정합니다. RFC 8828도 일부 기업 사용자가 정확히 그렇게 하기를 원한다고 언급합니다.
집 네트워크에서 잘 되던 통화가 VPN을 켜면 나빠진다면 그 통화에서는 VPN을 끄거나 더 가까운 서버를 고르세요. 개인정보를 위해 VPN이 꼭 필요하다면 음성만 쓰거나 화질을 낮춰 부하를 줄이세요.
프록시가 하는 일
프록시는 내 대신 웹 트래픽을 전달합니다. 보통 브라우저 요청은 실어 나르지만 UDP 미디어는 싣지 못합니다. 그래서 프록시 뒤의 통화는 TCP를 쓰기 쉽고, 지연이 늘고 회복력이 떨어지며, 릴레이로 가는 TCP 경로가 없으면 연결에 실패합니다. 표준이 지적하듯 STUN 트래픽이 프록시를 건너뛸 수도 있으므로, 프록시만으로 상대가 내 주소를 절대 보지 못한다고 보장되지 않습니다.
브라우저 확장 프로그램이 할 수 있는 일
- 개인정보·차단 확장 프로그램은 WebRTC가 모을 수 있는 후보를 제한할 수 있습니다. 주소는 숨겨지지만 통화 연결도 막힐 수 있습니다.
- 일부 확장 프로그램은 카메라나 마이크에 간섭합니다. 예를 들어 예상치 못한 사이트의 장치 접근을 막습니다.
- 광고 차단기는 통화 서비스의 스크립트나 도메인을 막을 수 있고, 통화 페이지가 열리기는 하는데 아무 일도 하지 않는 것처럼 보입니다.
- 헤더나 트래픽을 다시 쓰는 확장 프로그램은 통화를 설정하는 시그널링을 깨뜨릴 수 있습니다.
빠른 점검은 확장 프로그램을 끈 시크릿 창이나 확장 프로그램이 없는 두 번째 브라우저 프로필입니다. 거기서 통화가 되면 확장 프로그램을 하나씩 다시 켜면서 어디서 깨지는지 찾으세요.
내 설정 테스트하기
- VPN을 끈 상태로 이 사이트의 WebRTC 연결 테스트를 실행하고 판정과 후보 종류를 기록합니다.
- VPN을 켜고 다시 실행합니다. 표의 공인 주소가 VPN의 주소로 바뀌면 WebRTC가 터널을 쓰고 있는 것입니다. 인터넷 업체의 주소가 여전히 보이면 일부 트래픽이 터널 밖으로 나가고 있습니다.
- 스크린샷을 찍어야 한다면 주소 일부 가리기 옵션을 쓰세요. 표는 나만 볼 수 있으며 페이지가 주소를 어디에도 보내지 않는다는 점을 기억하세요.
- 내 공인 주소를 보여주는 웹사이트와 비교해 보세요. VPN 업체가 자체 누출 테스트를 제공한다면 그것과도 비교해 보세요.
- VPN이 있을 때와 없을 때 친구와 실제 통화를 해 보고 품질을 비교하세요.
WebRTC가 드러내는 것을 제한하고 싶다면 브라우저, VPN 앱, 신뢰할 만한 확장 프로그램에서 설정을 찾고 제공자의 문서를 읽으세요. 이름과 효과가 서로 다르기 때문입니다. 무엇을 바꾸든 테스트를 반복하고 실제 통화를 해 보세요. 모든 것을 숨기지만 통화를 깨뜨리는 설정은 대개 원하던 것이 아닙니다.
짧은 점검표
- 무엇이 필요한지 정하세요. 매끄러운 통화, 최대한의 개인정보, 또는 그 사이의 균형입니다.
- 매끄러운 통화를 원하면 VPN을 끄거나 UDP가 허용되는 가까운 서버를 고르세요.
- 개인정보가 우선이면 품질이 떨어질 수 있음을 받아들이고, 의존하기 전에 테스트하세요.
- VPN이 WebRTC로부터 모든 것을 숨겨 준다고 가정하지 말고 확인하세요.
- WebRTC의 개인정보 동작은 해마다 바뀌어 왔으니 브라우저를 최신으로 유지하세요.
ChatLite에 대해
이 사이트의 연결 테스트는 브라우저가 내놓는 주소를 내 화면에만 보여주므로, 중요한 ChatLite 통화 전에 VPN을 켠 경우와 끈 경우를 비교해 볼 수 있습니다.
참고 자료
이 글을 확인하는 데 쓴 공식 문서입니다. 문서는 각 운영 주체가 관리하며 바뀔 수 있습니다. 한국어 메뉴 이름은 버전과 언어 설정에 따라 다를 수 있으니, 화면의 이름과 다르면 비슷한 항목을 찾거나 공식 문서의 영어 이름을 참고하세요.
ChatLite의 현재 동작을 기준으로 검토한 날짜: .