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 за замовчуванням слухає 3478 для UDP і TCP та 5349 для TLS, і мережа, яка дозволяє 443, але відкидає ці порти, провалить виклики через ретранслятор, тоді як перегляд триватиме нормально. Зміна порту VPN нічого з цього не налаштовує, бо важливі порти належать службі ретрансляції, а не тунелю.
Прочитайте діагностику, потім перевірте виклик
Браузери показують потрібні відомості без перехоплення пакетів. Відкрийте сторінку діагностики WebRTC для свого браузера, здійсніть виклик і читайте обрану пару кандидатів, а не зібраний список: які типи локальних і віддалених кандидатів обрано, через який транспорт і родину адрес, і чи шлях прямий, чи через ретранслятор.
Два прочитання варто знати заздалегідь. Якщо обрана пара — хост-до-хост на приватних адресах, медіа залишається на шляху, про який можна міркувати; якщо це ретранслятор-до-ретранслятора, виклик витрачає ємність ретранслятора й залежить від доступності цієї служби. Несправність, яка зупиняється на «перевірці» без обраної пари, означає, що кандидатів зібрано, але жоден не пройшов перевірки зв'язності.
Потім порівняйте ті самі дві кінцеві точки в тому самому виклику, змінивши лише одну схвалену умову, і приймайте результат за двосторонніми медіа або даними, а не за індикатором «підключено». Збирання кандидатів вдається в багатьох випадках, які не несуть жодного кадру звуку. Повторіть виклик з іншого боку зміни й збережіть обидва діагностичні записи, бо порівняння двох запусків інформативніше за читання будь-якого з них окремо. Ті самі кінцеві точки, той самий кодек, одна змінена змінна.
Застосунок, який навмисно ставить свою політику транспорту ICE на relay, запитує лише кандидатів ретранслятора. Це налаштування не створює ретранслятор і не виправляє відсутні облікові дані; воно робить вимогу явною, що корисно, коли хтось звинувачує VPN у політиці, яку обрала сторінка.
Тримайте твердження про конфіденційність настільки вузьким, наскільки дозволяють докази
Розкриття кандидатів залежить від політики браузера й застосунку, а не лише від стану тунелю, і специфікація W3C для з'єднання між партнерами розглядає роботу з IP як окреме питання. Тому підключений VPN — слабка основа для обіцянки, що виклик розкриває лише одну обрану адресу. Двоє партнерів за одним тунелем можуть навіть обрати шлях, який ніколи не залишає хост, а це одночасно поліпшення конфіденційності й обмеження зв'язності.
Те, що ви можете сказати точно, вужче й корисніше: яку пару кандидатів обрано, який транспорт її ніс і чи залишився цей шлях усередині тунелю. Запишіть ці три факти для робочого й невдалого виклику, і різниця зазвичай називає компонент, який треба виправити.
Коли зв'язність працює, відокремте продуктивність від досяжності. Втрати, затримка, черги й MTU розташовані нижче правильної пари кандидатів, а ставлення до уривчастого виклику як до несправності зв'язності повертає вас до списку кандидатів без причини.