OSZOŁOMIĆ

STUN ( Session Traversal Utilities for NAT ; oryginalnie Simple Traversal of User Datagram Protocol (UDP) through Network Address Translators ) to ustandaryzowany zestaw metod, w tym protokół sieciowy, służący do przechodzenia przez bramki translatora adresów sieciowych (NAT) w aplikacjach real- czas głos, wideo, wiadomości i inne interaktywne komunikaty.

STUN jest narzędziem używanym przez inne protokoły, takie jak Interactive Connectivity Establishment (ICE), Session Initiation Protocol (SIP) i WebRTC . Zapewnia hostom narzędzie do wykrywania obecności translatora adresów sieciowych oraz do wykrywania zmapowanego, zwykle publicznego, protokołu internetowego (IP) i numeru portu, które NAT przydzielił dla protokołu datagramów użytkownika aplikacji (UDP) przepływa do zdalnych hostów. Protokół wymaga pomocy zewnętrznego serwera sieciowego (serwer STUN) znajdującego się po przeciwnej (publicznej) stronie NAT, zazwyczaj w publicznym Internecie .

STUN został po raz pierwszy ogłoszony w dokumencie RFC 3489; tytuł został zmieniony w specyfikacji zaktualizowanego zestawu metod opublikowanych jako RFC 5389, zachowując ten sam akronim.

Historia

Oryginalny algorytm charakteryzacji NAT z RFC 3489

STUN został po raz pierwszy ogłoszony w dokumencie RFC 3489. Oryginalna specyfikacja określała algorytm charakteryzujący zachowanie NAT zgodnie z zachowaniem adresów i mapowania portów. Ten algorytm nie jest niezawodny i ma zastosowanie tylko do podzbioru wdrożonych urządzeń NAT. Algorytm składa się z serii testów do wykonania przez aplikację. Gdy ścieżka na schemacie kończy się czerwonym prostokątem, komunikacja UDP nie jest możliwa, a gdy ścieżka kończy się żółtym lub zielonym prostokątem, komunikacja jest możliwa. Metody opisane w RFC 3489 okazały się zbyt zawodne, aby poradzić sobie z mnóstwem różnych implementacji NAT i scenariuszy aplikacji spotykanych w sieciach produkcyjnych. Protokół i metoda STUN zostały zaktualizowane w RFC 5389, zachowując wiele oryginalnych specyfikacji jako podzbiór metod, ale usuwając inne.

Tytuł został zmieniony w specyfikacji zaktualizowanego zestawu metod opublikowanych jako RFC 5389, zachowując ten sam akronim.

Projekt

STUN to narzędzie dla protokołów komunikacyjnych do wykrywania i przechodzenia przez translatory adresów sieciowych, które znajdują się na ścieżce między dwoma punktami końcowymi komunikacji. Jest zaimplementowany jako lekki klient-serwer , wymagający jedynie prostych komponentów zapytań i odpowiedzi z serwerem innej firmy zlokalizowanym we wspólnej, łatwo dostępnej sieci, zazwyczaj w Internecie . Strona klienta jest zaimplementowana w aplikacji komunikacyjnej użytkownika, takiej jak Voice over Internet Protocol (VoIP) lub klient komunikatora.

Podstawowy protokół działa zasadniczo w następujący sposób: klient, zwykle działający w sieci prywatnej , wysyła żądanie powiązania do serwera STUN w publicznym Internecie. Serwer STUN odpowiada odpowiedzią pomyślną , która zawiera adres IP i numer portu klienta, obserwowane z perspektywy serwera. Wynik jest zaciemniany przez wyłączne lub (XOR), aby uniknąć translacji zawartości pakietu przez bramy warstwy aplikacji (ALG), które przeprowadzają głęboką kontrolę pakietów w celu wykonania alternatywnych metod przechodzenia przez NAT.

Komunikaty STUN są wysyłane w pakietach User Datagram Protocol (UDP). Ponieważ UDP nie zapewnia niezawodnego transportu, niezawodność jest osiągana przez kontrolowaną przez aplikację retransmisję żądań STUN. Serwery STUN nie implementują żadnego mechanizmu niezawodności dla swoich odpowiedzi. Gdy niezawodność jest obowiązkowa, można zastosować protokół kontroli transmisji (TCP), ale wiąże się to z dodatkowym obciążeniem sieci. W aplikacjach wrażliwych na bezpieczeństwo STUN może być transportowany i szyfrowany przez Transport Layer Security (TLS).

Aplikacja może automatycznie określić odpowiedni serwer STUN do komunikacji z określonym peerem, wysyłając zapytanie do systemu nazw domen (DNS) o serwer stun (dla UDP) lub stuns (dla TCP/TLS) ( SRV ) rekord zasobu, np. _stun._udp.example.com. Standardowy numer portu nasłuchiwania dla serwera STUN to 3478 dla UDP i TCP oraz 5349 dla TLS. Alternatywnie protokół TLS można również uruchomić na porcie TCP, jeśli implementacja serwera umożliwia demultipleksowanie pakietów TLS i STUN. W przypadku, gdy żaden serwer STUN nie zostanie znaleziony za pomocą wyszukiwania DNS, standard zaleca, aby docelowa nazwa domeny została przeszukana pod kątem rekordów adresu (A lub AAAA), które byłyby używane z domyślnymi numerami portów.

Oprócz korzystania z szyfrowania protokołu z TLS, STUN ma również wbudowane mechanizmy uwierzytelniania i integralności wiadomości za pośrednictwem wyspecjalizowanych typów pakietów STUN.

Kiedy klient oceni swój adres zewnętrzny, może go użyć jako kandydata do komunikacji z równorzędnymi użytkownikami, udostępniając zewnętrzny adres NAT zamiast adresu prywatnego, który nie jest osiągalny dla równorzędnych sieci publicznej.

Jeśli oba komunikujące się elementy równorzędne znajdują się w różnych sieciach prywatnych, z których każda znajduje się za NAT, elementy równorzędne muszą skoordynować działania, aby określić najlepszą ścieżkę komunikacji między nimi. Niektóre zachowania NAT mogą ograniczać łączność równorzędną, nawet jeśli znane jest powiązanie publiczne. Interactive Connectivity Establishment (ICE) zapewnia ustrukturyzowany mechanizm określania optymalnej ścieżki komunikacji między dwoma urządzeniami równorzędnymi. Rozszerzenia protokołu inicjowania sesji (SIP) są zdefiniowane w celu umożliwienia korzystania z ICE podczas konfigurowania połączenia między dwoma hostami.

Ograniczenia

Translacja adresów sieciowych jest realizowana za pomocą wielu różnych schematów mapowania adresów i portów, z których żaden nie jest znormalizowany.

STUN nie jest samodzielnym rozwiązaniem translacji NAT, które można zastosować we wszystkich scenariuszach wdrażania NAT i nie działa poprawnie ze wszystkimi z nich. Jest to narzędzie wśród innych metod i jest narzędziem dla innych protokołów zajmujących się translacją NAT, w szczególności Traversal using Relay NAT (TURN) i Interactive Connectivity Establishment (ICE).

STUN współpracuje z trzema rodzajami NAT: NAT z pełnym stożkiem , NAT z ograniczonym stożkiem i NAT ze stożkiem z ograniczonym portem . W przypadku NAT z ograniczonym stożkiem lub stożek z ograniczonym portem klient musi wysłać pakiet do punktu końcowego, zanim NAT zezwoli na pakiety z punktu końcowego do klienta. STUN nie działa z symetrycznym NAT (znanym również jako dwukierunkowy NAT), który jest często spotykany w sieciach dużych firm. Od adresu IP serwera STUN różni się od punktu końcowego, w przypadku symetrycznego NAT mapowanie NAT będzie inne dla serwera STUN niż dla punktu końcowego. TURN oferuje lepsze wyniki z symetrycznym NAT.

Zobacz też

Linki zewnętrzne