Коли тестова сторінка WebRTC друкує 172.20.4.15, вона дізналася, що в цій мережі існує локальний інтерфейс. Це справжнє розкриття, і це не той самий висновок, що «медіа вийшли через вихід VPN». Виявлення кандидатів і маршрутизація пакетів — різні механізми, і більшість звітів про витоки зливають їх у один вердикт. Який із двох перед вами, вирішує виправлення.

Збирання відбувається до того, як щось надіслано

Браузер перелічує локальні інтерфейси, надсилає запит прив'язування на сервер STUN і просить у сервера TURN виділення, а потім записує результати в опис сесії як рядки кандидатів. Усе це завершується без виклику, без медіа і без співрозмовника. Тому список кандидатів — це запис виявлення, а не передавання.

Сучасні браузери можуть замінювати буквальну адресу кандидата хоста на mDNS-ім'я .local, тож сторінка не може прочитати приватний IP. Локальна мережа досі бачить multicast-запити, що розв'язують це ім'я, отже адреса ховається від застосунку, а не вилучається з мережі.

Порядок теж важливий: нове завантаження сторінки збирає новий набір, з іншим виділенням TURN і можливо іншим відбивним відображенням. Два різні запуски не обов'язково означають дві різні конфігурації.

Три типи кандидатів, три види доказів

Кожен рядок походить з окремого спостереження. Кожен тип відповідає на інше питання, а таблиця розділяє їх за тим, що вони можуть і чого не можуть встановити.

CandidateDerived fromWhat it establishesWhat it cannot establish
HostAn interface on the deviceA local address exists in that networkThat the peer can reach it
Server-reflexiveA STUN binding responseHow a NAT mapped this sourceWhich exit the media will use
Peer-reflexiveA connectivity check that arrivedAn address seen by the far sideThat it was ever advertised
RelayA TURN allocationThe relay server accepted the sessionThat the relay carries the call

Кандидата ретрансляції часто плутають з інтернет-адресою користувача. Він належить серверу TURN, і його наявність показує, що ретранслятор був доступний, а не що браузер вибрав його. Та сама плутанина йде у зворотний бік із кандидатами хоста, де mDNS-ім'я ховає адресу від сторінки, поки мережа все ще несе запити. Читайте тип раніше, ніж значення.

Вибрана пара відповідає на питання маршрутизації

ICE з'єднує кожного локального кандидата з кожним віддаленим, виконує перевірки зв'язності на кожній парі й номінує переможця. Саме ця номінована пара, видима у власній діагностиці браузера, несе медіа. Усе інше в списку — можливість, що програла.

Переможець повідомляє форму шляху. Ретранслятор до ретранслятора йде через сервер TURN, пара хостів лишається в локальній мережі, а серверно-відбивна пара йде напряму через NAT. Це той факт, який потрібен перевірці VPN, і він відрізняється від списку адрес. Два виклики з однаковими списками кандидатів можуть вибрати різні пари.

Невибрані кандидати все одно збиралися, а збирання — це мережевий трафік, що залишає машину. Виклик, який зрештою використав ретранслятор, не означає, що під час побудови списку нічого не розкрилося.

Засоби контролю відповідають цілям, а не оцінці витоку

Специфікація WebRTC щодо обробки IP описує кілька політик: використовувати лише інтерфейс, що несе маршрут за замовчуванням; використовувати всі інтерфейси; і вимкнути UDP без проксі, щоб трафік мусив іти через ретранслятор або проксі. Кожна обмінює зв'язність і затримку на інший вид експозиції. Яку політику і під якою назвою реалізує браузер, залежить від платформи й версії.

Виберіть політику за метою. Сховати локальні адреси від сторінки — одна мета; запобігти прямому трафіку між рівноправними вузлами — друга; утримати кожен пакет усередині тунелю — третя. Перша переважно про те, що дізнається застосунок, друга — про те, який шлях дозволено, а третю треба забезпечувати й на межі платформи або VPN.

Який би засіб ви не вибрали, перевірте обидві половини: запустіть тест збирання й запишіть типи кандидатів, а потім дослідіть вибрану пару під час реальної сесії. Чистий список адрес із прямим шляхом медіа — це все ще шлях, якого ви не планували.

Схожі статті