
Co jakiś czas udostępnianie ekranu, połączenie wideo albo połączenie sterujące prezentera po prostu nie chce się nawiązać w jednej konkretnej sieci, choć wszędzie indziej działa bez zarzutu. W dziewięciu przypadkach na dziesięć winowajcą jest zablokowane połączenie bezpośrednie, a rozwiązaniem jest serwer TURN. Serwery TURN w prostych słowach: to przekaźnik, który utrzymuje połączenie peer-to-peer, gdy sieć nie pozwala dwóm urządzeniom komunikować się ze sobą bezpośrednio.
Jeśli zastanawia Cię, po co Twojemu narzędziu do prezentacji w ogóle ustawienie „relay” lub „TURN”, oto odpowiedź. Warto to zrozumieć niezależnie od tego, czy dziś wieczorem diagnozujesz zerwane połączenie, czy przed zakupem weryfikujesz deklaracje narzędzia dotyczące obsługi sieci.
- TURN to zapasowy przekaźnik na wypadek, gdy nie da się nawiązać bezpośredniego połączenia WebRTC, zdefiniowany w IETF RFC 8656.
- Ruch przechodzący przez TURN pozostaje szyfrowany end-to-end: przekaźnik przesyła bajty, nigdy nie mając kluczy do ich odszyfrowania.
- Cliqer automatycznie przełącza się na przekaźnik, w tym na ścieżkę TURNS przez port 443 w najbardziej zablokowanych sieciach.
Dlaczego połączenia bezpośrednie czasem zawodzą
WebRTC, technologia stojąca za większością narzędzi do wideo i sterowania peer-to-peer, preferuje bezpośrednie łączenie dwóch urządzeń. To wydajne i szybkie rozwiązanie: między telefonem prezentera a komputerem hosta, na którym wyświetlane są slajdy, nie ma żadnego pośrednika. Problem w tym, że prawdziwie bezpośrednie połączenie wymaga, by oba urządzenia były osiągalne w otwartym internecie, a większość urządzeń nie jest.
Routery domowe używają NAT (Network Address Translation), by współdzielić jeden publiczny adres IP między wieloma urządzeniami, co już samo w sobie komplikuje połączenia bezpośrednie. Sieci firmowe i sieci w obiektach eventowych idą dalej: często całkowicie blokują ruch UDP albo ograniczają połączenia wychodzące do krótkiej listy dozwolonych portów. STUN, lżejszy protokół, radzi sobie z prostymi przypadkami NAT, pomagając dwóm urządzeniom poznać ich publiczne adresy. Nie rozwiąże jednak wszystkiego.
Co właściwie robi TURN
TURN (Traversal Using Relays around NAT) to rozwiązanie zapasowe właśnie na taką sytuację. Zdefiniowany w IETF RFC 8656, działa tak, że oba urządzenia otrzymują adres przekaźnika, na który wysyłają ruch zamiast do siebie nawzajem. Przekaźnik po prostu przesyła pakiety między obiema stronami.
W tym, jak to robi, liczą się trzy rzeczy:
Ruch nadal jest szyfrowany end-to-end
Przekaźniki TURN przesyłają te same pakiety szyfrowane DTLS i SRTP, których używałoby bezpośrednie połączenie WebRTC. Przekaźnik nie ma kluczy do ich odszyfrowania, więc przenosi bajty, nigdy nie widząc treści.
To rozwiązanie zapasowe, a nie domyślne
Dobrze zbudowana aplikacja najpierw próbuje połączenia bezpośredniego i przełącza się na TURN dopiero wtedy, gdy ono zawiedzie, bo ścieżka bezpośrednia jest szybsza.
Dane uwierzytelniające są tymczasowe
Dostęp do TURN przyznawany jest zwykle za pomocą krótkotrwałych danych uwierzytelniających generowanych dla każdej sesji, a nie stałego wspólnego hasła, więc dane, które wyciekną, szybko wygasają, zamiast dawać trwały dostęp.

STUN, TURN i TURNS: czym się różnią
Te trzy skróty bywają używane zamiennie, choć nie powinny:
| Termin | Co robi | Kiedy jest używany |
|---|---|---|
| STUN | Pomaga urządzeniu poznać własny publiczny adres IP i port | Pierwsza próba, lekka, bez udziału przekaźnika |
| TURN | Przekazuje ruch między urządzeniami przez UDP lub TCP, gdy ścieżka bezpośrednia zawodzi | Rozwiązanie zapasowe, gdy sam STUN nie zestawi połączenia |
| TURNS | TURN przekazywany przez TLS, zwykle na porcie 443 | Zablokowane sieci, które przepuszczają na zewnątrz tylko standardowy ruch webowy |
Ten ostatni wiersz ma większe znaczenie, niż się wydaje. Sieć, która blokuje wszystko poza standardowym ruchem HTTPS na porcie 443, i tak przepuści połączenie TURNS, bo z jej perspektywy wygląda ono identycznie jak zwykłe przeglądanie stron. Właśnie ten mechanizm stoi za tym, dlaczego firmowe zapory blokują narzędzia do prezentacji, i za tym, dlaczego dobre narzędzia i tak się przez nie przedostają.
Jak Cliqer korzysta z TURN
Aplikacje desktopowe i webowe Cliqer najpierw próbują nawiązać bezpośrednie połączenie WebRTC, zabezpieczone DTLS i SRTP. Jeśli sieć je blokuje, połączenie automatycznie przełącza się na szyfrowany przekaźnik TURN, w tym na ścieżkę TURNS przez port 443 dla sieci, które przepuszczają na zewnątrz tylko standardowy ruch webowy. Dane uwierzytelniające TURN są generowane dla każdego żądania z 24-godzinnym czasem ważności i rotują automatycznie, zamiast być wpisanymi na sztywno wartościami, których klient używa bez końca.
Nic z tego nie wymaga od Ciebie żadnej konfiguracji. Przełączenie następuje automatycznie i niezauważalnie, niezależnie od tego, czy prezentujesz z domowego biura, czy z zablokowanego centrum konferencyjnego. Jeśli chcesz poznać pełny obraz tego, jak zabezpieczona jest reszta połączenia, przeczytaj czy WebRTC jest bezpieczne oraz dokumentację Security & Networking.
Co tracisz na przekaźniku, a czego nie
Przekazywanie ruchu przez TURN nie jest darmowe pod względem inżynieryjnym. Kierowanie ruchu przez trzeci punkt dodaje niewielkie opóźnienie w porównaniu z połączeniem bezpośrednim i zużywa więcej przepustowości po stronie operatora przekaźnika. Nie tracisz natomiast bezpieczeństwa: przekaźnik nigdy nie odszyfrowuje przesyłanych danych, więc zablokowana sieć nie zmusza Cię do wyboru między „działa” a „jest prywatne”.
W przypadku udostępniania ekranu, gdzie każde dodatkowe sto milisekund jest bardziej odczuwalne niż przy prostym sygnale przełączenia slajdu, szerszy obraz opóźnień opisujemy w artykułach jak przyspieszyliśmy udostępnianie ekranu czterokrotnie oraz jak naprawić opóźnienia udostępniania ekranu w spotkaniach hybrydowych.

Diagnozowanie połączenia, które nie chce się zestawić
- Spróbuj na chwilę połączyć się przez hotspot w telefonie. Jeśli tam połączenie działa, a w sieci obiektu nie, problemem jest sieć, a nie aplikacja.
- Sprawdź, czy aplikacja ma widoczny wskaźnik „relay” lub „typ połączenia”, i upewnij się, że próbuje użyć TURN, zamiast od razu zgłaszać błąd.
- Upewnij się, że wychodzący ruch HTTPS na porcie 443 jest dozwolony, bo zapasowa ścieżka TURNS przez 443 to ostatnia linia obrony w najbardziej restrykcyjnych sieciach.
- Jeśli nic z tego nie pomoże, zgłoś sprawę zespołowi IT obiektu lub biura, podając konkretne porty i protokoły z dokumentacji dostawcy, a nie ogólne „nie działa”.
Jeśli oceniasz zachowanie sieciowe w ramach szerszej weryfikacji dostawcy, uwzględnij to w pełnej liście kontrolnej bezpieczeństwa oprogramowania do prezentacji, bo to, jak narzędzie radzi sobie z restrykcyjnymi sieciami, łatwo przeoczyć aż do dnia, w którym ma to znaczenie.
Dlaczego firmowe zapory blokują narzędzia do prezentacji
Dlaczego biura tak szczelnie blokują sieci i jak dobrze zbudowane narzędzia się przez nie przedostają.
FAQ
Nie, w dobrze zbudowanej aplikacji TURN to przezroczyste rozwiązanie zapasowe. Cliqer automatycznie pobiera nowe dane uwierzytelniające TURN i przełącza się na przekaźnik tylko wtedy, gdy połączenie bezpośrednie nie jest możliwe.
Nie. Przekaźnik przesyła ten sam szyfrowany end-to-end ruch DTLS i SRTP, którego używałoby połączenie bezpośrednie, nie mając kluczy do jego odszyfrowania. Zmienia się trasa, a nie szyfrowanie.
Najpewniej Twój ruch jest przekazywany przez TURN zamiast iść bezpośrednio, co dodaje niewielkie opóźnienie. To cena za to, że połączenie w ogóle działa w sieci blokującej bezpośrednie połączenia peer-to-peer.
VPN kieruje i szyfruje cały ruch urządzenia przez zewnętrzny podmiot przez całą sesję. TURN to węższy przekaźnik, specyficzny dla aplikacji, używany tylko wtedy, gdy nie da się nawiązać bezpośredniego połączenia WebRTC, i tylko dla tego połączenia.
Zacznij teraz
Jeśli prezentujesz w obiektach eventowych, biurach klientów lub w dowolnym miejscu z siecią, nad którą nie masz kontroli, wypróbuj Cliqer za darmo i zobacz automatyczne przełączanie w akcji albo przeczytaj pełny przegląd bezpieczeństwa, by dowiedzieć się, jak chroniona jest każda warstwa połączenia.
Co zrobić, gdy slajdy zawieszą się w trakcie prezentacji
Spokojny plan na wypadek, gdy slajdy zawieszą się na scenie: co sprawdzić najpierw, jak mówić dalej i jak szybko wrócić do rytmu.
Dlaczego firmy rentalowe i realizacyjne przenoszą sterowanie show do oprogramowania
Dlaczego firmy rentalowe i realizacyjne zamieniają zestawy pilotów do prezentacji na programowe sterowanie show, które lekko podróżuje na każdy obiekt.
Poprowadź swoje następne show z Cliqer
Czytaj dalej
Więcej: bezpieczeństwo i it na Twoje następne show


Prezentowanie poufnych treści: ochrona danych na posiedzeniach zarządu

Klucze dostępu w pigułce: logowanie bez hasła dla zapracowanych zespołów
Otrzymaj kolejny poradnik przed swoim następnym show
Praktyczne poradniki dla prezenterów, ekip AV i zespołów eventowych oraz wydania Cliqer, które mają znaczenie. Bez spamu, rezygnacja jednym kliknięciem.
