VPN czy przekaźnik TURN: co naprawdę przenosi połączenie WebRTC?
Tunel zmienia ścieżkę, którą widzi ICE; nigdy nie przydziela przekaźnika ani nie zapewnia sygnalizacji. Porównaj, co oferuje wyjście VPN i serwer TURN.
Strona ładuje się przez VPN, a połączenie nigdy nie wstaje: dwa różne błędy w tym samym pasku adresu. Tunel zmienił ścieżkę, której używa przeglądarka; nie stał się usługą sygnalizacji, serwerem STUN ani przekaźnikiem i nie decyduje, którą parę kandydatów wybierze ICE. Właśnie rozdzielenie zadania każdego komponentu zamienia mgliste „WebRTC jest zablokowane” w konkretną usterkę.
Cztery zadania, z których tunel dotyka tylko jednego
Aplikacja wymienia informacje o sesji przez jakieś rozwiązanie sygnalizacyjne i to jest pierwsze zadanie. ICE zbiera adresy kandydatów i testuje pary, aż jedna zadziała, co jest drugim. STUN pozwala drugiej stronie poznać, jak wygląda jej ruch z zewnątrz, a TURN przydziela przekaźnik w przypadkach, gdy nie ma bezpośredniej ścieżki. Te cztery role są różne, a VPN wpływa na adresy i filtrowanie, na które trafiają, zamiast dostarczać którąkolwiek z nich.
Dlatego udane logowanie nic nie mówi o ścieżce mediów. Sygnalizacja zwykle jedzie tym samym HTTPS, którego strona już używa, na porcie 443, podczas gdy media mogą podróżować przez UDP do zupełnie innego celu.
Prywatne adresowanie pogarsza zamieszanie. Adres tunelu jest użyteczny dla drugiej strony tylko wtedy, gdy ma ona zamierzoną ścieżkę powrotną do niego; bycie prywatnym nie jest dowodem wzajemnej osiągalności, a przeglądarki nie traktują tego w ten sposób, gdy odrzucają kandydatów, których nie można sprawdzić. Kandydat, który wygląda u ciebie lokalnie, może być niesprawdzalny z drugiej strony. Warto wykluczyć tę lukę, zanim uznasz, że tunel gubi media.
Porównaj wyjście VPN z przekaźnikiem TURN
Oba przekazują pakiety, dlatego bywają mylone, a tabelę porównawczą powyżej warto czytać kolumna po kolumnie, a nie jako listę funkcji. Przydział przekaźnika to obiekt na sesję tworzony przez uwierzytelnione żądanie; tunel to trasa. Jedno ma poświadczenia, które wygasają, drugie ma adres drugiej strony, który albo jest osiągalny, albo nie.
| 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 |
Numery portów czynią różnicę konkretną. TURN domyślnie nasłuchuje na 3478 dla UDP i TCP oraz na 5349 dla TLS, a sieć, która zezwala na 443, ale odrzuca te porty, będzie miała nieudane połączenia przez przekaźnik, podczas gdy przeglądanie działa normalnie. Zmiana portu VPN niczego z tego nie konfiguruje, bo ważne porty należą do usługi przekaźnika, nie do tunelu.
Przeczytaj diagnostykę, potem przetestuj połączenie
Przeglądarki udostępniają potrzebne informacje bez przechwytywania pakietów. Otwórz stronę diagnostyki WebRTC swojej przeglądarki, wykonaj połączenie i czytaj wybraną parę kandydatów, a nie zebraną listę: jakie typy kandydatów lokalnych i zdalnych wybrano, przez jaki transport i rodzinę adresów oraz czy ścieżka jest bezpośrednia, czy przez przekaźnik.
Dwa odczyty warto znać z góry. Jeśli wybrana para to host-host na adresach prywatnych, media pozostają na ścieżce, o której można rozumować; jeśli to przekaźnik-przekaźnik, połączenie zużywa pojemność przekaźnika i zależy od dostępności tej usługi. Usterka, która zatrzymuje się na „sprawdzaniu” bez wybranej pary, oznacza, że kandydaci zostali zebrani, ale żaden nie przeszedł testów łączności.
Następnie porównaj te same dwa punkty końcowe w tym samym połączeniu, zmieniając tylko jeden zatwierdzony warunek, i przyjmij wynik na podstawie dwukierunkowych mediów lub danych, a nie wskaźnika „połączono”. Zbieranie kandydatów udaje się w wielu przypadkach, które nigdy nie przenoszą ani jednej ramki audio. Powtórz połączenie po drugiej stronie zmiany i zachowaj oba zapisy diagnostyczne, bo porównanie dwóch przebiegów mówi więcej niż czytanie któregokolwiek z osobna. Te same punkty końcowe, ten sam kodek, jedna zmieniona zmienna.
Aplikacja, która celowo ustawia swoją politykę transportu ICE na relay, prosi tylko o kandydatów przekaźnika. To ustawienie nie tworzy przekaźnika i nie naprawia brakujących poświadczeń; czyni wymóg jawnym, co jest przydatne, gdy ktoś obwinia VPN o politykę wybraną przez witrynę.
Trzymaj twierdzenie o prywatności tak wąskie jak dowody
Ekspozycja kandydatów zależy od polityki przeglądarki i aplikacji, a nie tylko od stanu tunelu, a specyfikacja W3C dla połączenia między równorzędnymi traktuje obsługę IP jako własną sprawę. Połączony VPN jest więc słabą podstawą do obietnicy, że połączenie ujawnia tylko jeden wybrany adres. Dwie strony za tym samym tunelem mogą nawet wybrać ścieżkę, która nigdy nie opuszcza hosta, co jest jednocześnie poprawą prywatności i ograniczeniem łączności.
To, co możesz powiedzieć precyzyjnie, jest węższe i bardziej użyteczne: która para kandydatów została wybrana, który transport ją niósł i czy ta ścieżka pozostała wewnątrz tunelu. Zapisz te trzy fakty dla połączenia działającego i zawodnego, a różnica zwykle wskazuje komponent do naprawy.
Gdy łączność działa, oddziel wydajność od osiągalności. Utrata, opóźnienie, kolejki i MTU leżą wszystkie poniżej poprawnej pary kandydatów, a traktowanie rwącego połączenia jako usterki łączności odsyła cię do listy kandydatów bez powodu.