Zaloguj się

Serwery TURN w prostych słowach: jak wideo przechodzi przez restrykcyjne sieci

Serwery TURN wyjaśnione prostym językiem: jak przekazują zaszyfrowane wideo i sterowanie przez zapory, które Cię blokują.

Cliqer Team

14 września 2026 · czas czytania: 6 min

An abstract diagram of two devices connecting through a relay server node, representing a TURN relay path

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.

Najważniejsze wnioski
  • 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.

Jeśli połączenie działa w domowym Wi-Fi, ale zawodzi w obiekcie lub w biurze, to wyraźny sygnał, że trafiasz na zaporę, której sam STUN nie pokona, i potrzebujesz przekaźnika TURN.

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:

TerminCo robiKiedy jest używany
STUNPomaga urządzeniu poznać własny publiczny adres IP i portPierwsza próba, lekka, bez udziału przekaźnika
TURNPrzekazuje ruch między urządzeniami przez UDP lub TCP, gdy ścieżka bezpośrednia zawodziRozwiązanie zapasowe, gdy sam STUN nie zestawi połączenia
TURNSTURN przekazywany przez TLS, zwykle na porcie 443Zablokowane 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ć

  1. 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.
  2. 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.
  3. 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.
  4. 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ą.

Czy WebRTC jest bezpieczne?

Pełny obraz tego, jak połączenie WebRTC jest zabezpieczone end-to-end.

Dokumentacja Security & Networking

Wymagania dotyczące połączeń wychodzących, na których opierają się TURN i TURNS.

Jak przyspieszyliśmy udostępnianie ekranu czterokrotnie

Jakie miejsce zajmuje opóźnienie przekaźnika w szerszym obrazie szybkości udostępniania ekranu.

FAQ

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.

TURNnetworkingWebRTCfirewalls

Autor: Cliqer Team

Tworzymy Cliqer, pilot internetowy używany na scenach, w salach wykładowych i salach konferencyjnych na całym świecie.

Poprowadź swoje następne show z Cliqer

Dowolne slajdy, dowolny telefon, w dowolnym miejscu. Aplikacja desktopowa hostuje pokój, prezenterzy po prostu otwierają link.

Czytaj dalej

Więcej: bezpieczeństwo i it na Twoje następne show

An IT manager and an event producer reviewing a procurement form together at a desk
Bezpieczeństwo i IT

Jak uzyskać akceptację działu IT dla oprogramowania AV: praktyczny przewodnik

Co naprawdę sprawdza przegląd bezpieczeństwa oprogramowania AV w dziale IT i jak się przygotować, by Twoje narzędzie zostało zatwierdzone za pierwszym razem.
A boardroom table with a laptop showing an abstract blurred chart, empty chairs waiting for a meeting to begin
Bezpieczeństwo i IT

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

Zachowaj poufność prezentacji dla zarządu: co nigdy nie powinno opuszczać Twojego urządzenia i jak sprawdzić, dokąd narzędzie wysyła dane.
A person unlocking a laptop with a fingerprint sensor instead of typing a password
Bezpieczeństwo i IT

Klucze dostępu w pigułce: logowanie bez hasła dla zapracowanych zespołów

Klucze dostępu wyjaśnione prosto: jak działa logowanie bez hasła, dlaczego jest odporne na phishing i jak włączyć je w Twoim zespole.
Newsletter

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.