Jak skonfigurować zewnętrzny serwer TURN dla Jitsi za NAT

Najważniejsza kwestia: zewnętrzny serwer TURN powinien być skonfigurowany jako rezerwowy dla klientów, którzy nie mogą nawiązać użytecznej ścieżki WebRTC z powodu NAT lub restrykcyjnych zapór sieciowych. Nie zastępuje on Jitsi Videobridge (JVB) w standardowych spotkaniach wielostronnych. Jeśli sam serwer Jitsi jest zabezpieczony NAT, nadal należy zapewnić dostęp do JVB z Internetu, zazwyczaj przez UDP 10000, lub poprawnie skonfigurować rozgłaszany adres publiczny mostu.

W przypadku obecnych wdrożeń Jitsi, najczystszym rozwiązaniem jest zazwyczaj publicznie dostępny host coturn z nazwą DNS, taką jak turn.example.com, ograniczonymi czasowo danymi uwierzytelniającymi dostarczanymi przez Prosody za pośrednictwem XEP-0215 ​​oraz TURN przez UDP/TCP i TURN przez TLS dla sieci o ograniczonych możliwościach. Aktualna dokumentacja TURN Jitsi wyraźnie zaleca dynamiczne dane uwierzytelniające zamiast osadzania stałej nazwy użytkownika i hasła w konfiguracji przeglądarki. Zobacz oficjalną dokumentację konfiguracji Jitsi TURN .

Kiedy zewnętrzny serwer TURN jest właściwym rozwiązaniem

Użyj TURN, gdy niektórzy uczestnicy mogą otworzyć stronę internetową Jitsi, ale nie mogą nawiązać niezawodnego połączenia, zwłaszcza z sieci korporacyjnych, hotelowych sieci Wi-Fi, kampusów, operatorów komórkowych, sieci VPN lub innych środowisk, które blokują lub silnie filtrują protokół UDP. TURN jest również przydatny w przypadku indywidualnych połączeń Jitsi, gdy nie można nawiązać połączenia peer-to-peer.

Nie traktuj TURN jako pierwszej poprawki dla źle skonfigurowanego Jitsi Videobridge. Oficjalny podręcznik Jitsi dla systemów Debian/Ubuntu mówi, że gdy serwer znajduje się za NAT-em, router musi przekierować wymagane porty, a most może wymagać jawnego mapowania adresów lokalnych na publiczne. Domyślnie ważne porty obsługiwane przez Jitsi to TCP 443 i UDP 10000. Przed dodaniem TURN zapoznaj się z aktualnym podręcznikiem samodzielnego hostingu Jitsi dla systemów Debian/Ubuntu .

Krok 1: Przygotuj publiczny host TURN i DNS

Najprostsza topologia to osobna maszyna wirtualna lub serwer z publicznym adresem IP. Utwórz rekord A lub AAAA, który turn.example.combędzie odpowiadał danemu hostowi. Dedykowana nazwa hosta jest szczególnie przydatna, jeśli później zaoferujesz TURN przez TLS, ponieważ certyfikat musi być zgodny z nazwą hosta używaną przez klientów.

Jeśli host TURN sam znajduje się za NAT-em, Coturn musi znać adres publiczny, który powinien reklamować. Coturn obsługuje external-ipmapowanie, w tym pary publiczny/prywatny, takie jak external-ip=203.0.113.10/192.168.1.10. W dokumentacji zaznaczono również, że porty przekaźnikowe muszą być spójnie mapowane przez NAT. Zapoznaj się z oficjalną przykładową konfiguracją Coturn-a .

Krok 2: Zainstaluj coturn

W obsługiwanym systemie Debian lub Ubuntu zainstaluj coturn z repozytorium dystrybucji:

sudo apt update
sudo apt install coturn

Wersje pakietów różnią się w zależności od wersji systemu operacyjnego, dlatego nie kopiuj numeru wersji ze zrzutu ekranu ani z innego serwera. Po instalacji sprawdź, czy jednostka usługi istnieje i czy pakiet został zainstalowany turnserver.

Krok 3: Skonfiguruj coturn dla uwierzytelniania za pomocą współdzielonego klucza tajnego

W przypadku Jitsi, praktyczna konfiguracja produkcyjna wykorzystuje mechanizm współdzielonego klucza tajnego Coturn, aby Prosody mogło generować tymczasowe dane uwierzytelniające TURN. Użyj tego samego klucza tajnego po obu stronach. Minimalny punkt wyjścia wygląda następująco:

listening-port=3478
tls-listening-port=5349
realm=turn.example.com

fingerprint
use-auth-secret
static-auth-secret=REPLACE_WITH_A_LONG_RANDOM_SECRET

min-port=49160
max-port=49200

no-multicast-peers
no-cli

Jeśli host TURN znajduje się za NAT, dodaj odpowiednie external-ipmapowanie. Jeśli włączasz TURN przez TLS, skonfiguruj certi pkeyz zaufanym certyfikatem dla turn.example.com. Oficjalna dokumentacja kontenera Coturn wyjaśnia, że ​​TURN używa zakresu portów przekaźnikowych dla mediów i że zakres ten można zawęzić za pomocą min-porti max-port. Zapoznaj się z oficjalną dokumentacją Dockera Coturn, aby uzyskać informacje o tym samym zachowaniu portu przekaźnikowego.

Krok 4: Otwórz porty nasłuchujące i przekaźnikowe

Częstym błędem jest otwieranie tylko portów 3478 lub 5349, zapominając o zakresie przekaźników. Program nasłuchujący Coturn akceptuje początkowe połączenie TURN, ale media przekazywane korzystają z przydzielonych portów przekaźnikowych. Jeśli wybierzesz 49160-49200, zezwól na ten sam zakres przez zaporę hosta, grupę zabezpieczeń w chmurze i dowolny NAT nadrzędny.

sudo ufw allow 3478/udp
sudo ufw allow 3478/tcp
sudo ufw allow 5349/tcp
sudo ufw allow 49160:49200/udp

Jeśli potrzebujesz najszerszej kompatybilności z zablokowanymi sieciami korporacyjnymi, przewodnik Jitsi TURN opisuje obsługę TURN przez TLS na porcie TCP 443. Może to wymagać dedykowanej nazwy hosta TURN, a gdy protokół HTTPS współdzieli ten sam adres publiczny, multipleksowania TLS SNI. Nie przenoś TURN bezmyślnie na port 443, chyba że rozumiesz, kto jest właścicielem tego portu.

Krok 5: Skonfiguruj Jitsi w celu reklamowania zewnętrznej usługi TURN

W obecnym wdrożeniu pakietu Jitsi w systemie Debian/Ubuntu, Prosody używa mod_external_servicesdo publikowania informacji STUN/TURN dla klientów. Przykład Prosody w Jitsi używa external_service_secrettabeli external_servicesz secret = true. Współdzielony sekret musi być zgodny z static-auth-secret.

external_service_secret = "REPLACE_WITH_THE_SAME_LONG_RANDOM_SECRET";

external_services = {
    { type = "stun", host = "turn.example.com", port = 3478 },
    { type = "turn", host = "turn.example.com", port = 3478,
       transport = "udp", secret = true, ttl = 86400, algorithm = "turn" },
    { type = "turns", host = "turn.example.com", port = 5349,
       transport = "tcp", secret = true, ttl = 86400, algorithm = "turn" }
};

Zachowaj istniejące moduły i ustawienia specyficzne dla witryny w pliku Prosody wygenerowanym przez Jitsi; nie zastępuj całego pliku powyższym fragmentem. Dokładna nazwa pliku zazwyczaj znajduje się po domenie wdrożenia w /etc/prosody/conf.d/. Przykład konfiguracji Jitsi można sprawdzić w oficjalnym repozytorium Jitsi .

Jeśli korzystasz z oficjalnego wdrożenia Dockera, preferuj udokumentowane zmienne środowiskowe zamiast ręcznie edytować wygenerowane pliki Prosody. Aktualna dokumentacja Dockera udostępnia zmienne TURN_CREDENTIALS, TURN_HOST, TURN_PORT, TURN_TRANSPORT, TURNS_HOSTi TURNS_PORT. Zapoznaj się z aktualnym przewodnikiem po samodzielnym hostingu Jitsi Docker, ponieważ domyślne wartości zmiennych mogą się zmieniać między wersjami.

Krok 6: Uruchom ponownie i zweryfikuj usługi

Po zmianie coturn, zrestartuj go i sprawdź jego status:

sudo systemctl restart coturn
sudo systemctl status coturn
sudo ss -lntup | grep -E '3478|5349'

Po zmianie konfiguracji Prosody sprawdź jej składnię, jeśli pakiet Prosody zawiera narzędzie sprawdzające, a następnie uruchom ponownie Prosody. W zależności od zmian wprowadzonych w Jitsi, ponowne uruchomienie odpowiednich usług Jitsi może być również wskazane:

sudo prosodyctl check config
sudo systemctl restart prosody

Czysty status usługi coturn jedynie dowodzi, że demon działa. Nie dowodzi on, że dane uwierzytelniające są zgodne, zakres przekaźników jest osiągalny ani że przeglądarka może uzyskać kandydata na przekaźnik.

Krok 7: Sprawdź, czy TURN rzeczywiście może przekazywać media

Testowanie z tej samej sieci LAN nie wystarczy. Użyj co najmniej jednego klienta w innej sieci, najlepiej połączenia mobilnego lub sieci, o której wiadomo, że ogranicza UDP. W diagnostyce WebRTC przeglądarki poszukaj kandydata ICE typu relay. Kandydat przekaźnikowy oznacza, że ​​przeglądarka pomyślnie uzyskała dane uwierzytelniające TURN i utworzyła alokację TURN.

Obserwuj również logi coturn podczas dołączania użytkownika testowego. Po wybraniu TURN powinieneś zobaczyć uwierzytelnione alokacje i ruch przekaźnikowy. Jeśli zauważysz błędy uwierzytelniania, porównaj coturn static-auth-secretz tajnym kluczem uwierzytelniającym Prosody lub Docker TURN. Jeśli alokacje się powiodą, ale media nadal nie działają, sprawdź zaporę portu przekaźnikowego i mapowanie NAT.

Nie wymuszaj TURN tylko po to, by udowodnić istnienie serwera, chyba że masz ku temu uzasadniony powód. W normalnych warunkach ICE wybiera najlepszą ścieżkę roboczą. Pomyślne wdrożenie może zatem obejmować wiele spotkań, które nigdy nie będą wymagały TURN.

Krok 8: Oddziel konfigurację NAT JVB od rozwiązywania problemów TURN

To właśnie ten punkt pozwala uniknąć marnowania czasu na rozwiązywanie problemów. Serwer Jitsi za NAT nadal wymaga poprawnej konfiguracji publicznej dostępności mostu. W aktualnym przewodniku szybkiego startu Jitsi napisano, że most zazwyczaj konfiguruje się automatycznie, ale jeśli większe wywołania nie powiodą się, można dodać mapowanie statyczne ice4j.harvest.mappingw /etc/jitsi/videobridge/jvb.conf:

ice4j {
  harvest {
    mapping {
      static-mappings = [
        {
          local-address = "192.168.1.20"
          public-address = "203.0.113.20"
        }
      ]
    }
  }
}

Przekieruj UDP 10000 z publicznego punktu granicznego do hosta JVB i upewnij się, że adres publiczny jest tym, do którego faktycznie mogą dotrzeć klienci zdalni. TURN może pomóc klientom w sieciach o ograniczonych możliwościach, ale nie należy go używać do ukrywania uszkodzonego mapowania NAT JVB.

Szybka lista kontrolna rozwiązywania problemów

• Nazwa hosta TURN nie jest rozwiązywana: napraw DNS przed testowaniem Jitsi.
• 3478/5349 nasłuchują lokalnie, ale nie zdalnie: sprawdzają zaporę hosta, zaporę w chmurze, NAT routera i filtrowanie dostawcy.
• Niepowodzenie uwierzytelniania: sprawdź, czy współdzielony klucz tajny jest identyczny w konfiguracji coturn i Jitsi/Prosody.
• Pojawia się kandydat na przekaźnik, ale medium nie działa: sprawdź, czy skonfigurowany zakres portów przekaźnikowych jest otwarty od końca do końca.
• Nie udają się tylko połączenia wielostronne: sprawdź JVB UDP 10000 i reklamę adresu publicznego JVB.
• Tylko sieci korporacyjne zawodzą: dodaj lub zweryfikuj TURN przez TLS, często na TCP 443, jeśli jest to stosowne.
• Zmiany w Dockerze znikają po ponownym uruchomieniu: skonfiguruj obsługiwane .envzmienne zamiast edytować wygenerowane pliki w kontenerach.

Jak wygląda poprawny wynik

Prawidłowa konfiguracja ma trzy obserwowalne zachowania. Po pierwsze, zwykli użytkownicy mogą uzyskać dostęp do Jitsi Videobridge bezpośrednio bez TURN, jeśli ich sieci na to pozwalają. Po drugie, użytkownicy w sieciach z ograniczeniami mogą otrzymać tymczasowe dane uwierzytelniające TURN i uzyskać relaykandydata ICE. Po trzecie, coturn wyświetla uwierzytelnione alokacje tylko wtedy, gdy jest to potrzebne, zamiast domyślnie wyświetlać każde spotkanie.

Ta kombinacja zapewnia użyteczne rozwiązanie awaryjne, nie powodując, że serwer TURN stanie się niepotrzebnym wąskim gardłem przepustowości. Utrzymuje również przejrzystość rozwiązywania problemów: problemy z JVB NAT pozostają problemami JVB, podczas gdy TURN rozwiązuje węższy problem łączności WebRTC, gdy trasy bezpośrednie są zablokowane.