Serwery STUN i Address Restricted NAT - komunikacja P2P

Question

Witam, od jakiegoś czasu interesuje się sieciami P2P. Istotne pojęcia jakie rozumiem (być może źle):

Serwer STUN - Wysyła w odpowiedzi publiczny adres źródłowy klienta.

Full cone NAT - Pakiety z zewnętrznego IP:PORT zawsze są mapowane do wewnętrznego (prywatnego) IP:PORT.

Address Restricted NAT - Pakiety z zewnętrznego IP:PORT są mapowane do wewnętrznego IP:PORT gdy komunikowaliśmy się z źródłowym hostem już wcześniej.

Wiem, że STUN nie działa dla Symmetric NAT. Nie wiem jednak jakim cudem działa to dla Address Restricted NAT. Przecież ta druga konfiguracja również mapuje IP:PORT tylko wtedy gdy już wcześniej się z nim komunikowaliśmy, a serwer STUN pozwala jedynie poznać publiczny adres.

No bo mamy sobie hosty A i B. Dzięki serwerowi STUN oba znają swój publiczny adres. Ale co z tego? Przecież gdy A spróbuje skomunikować się z B, to zostanie odrzucony bo B nie zna A.

Z tego jak ja to rozumiem to komunikacja P2P była by możliwa tylko dla Full cone NAT. Oczywiście wiem, że źle to rozumiem . Będę więc wdzięczny za wytłumaczenie mi gdzie popełniam błąd myślowy.

Z góry dziękuje i pozdrawiam serdecznie.

Comments

To, zdaje się, polega na tym że A próbuje wysyłać pakiety UDP na adres publiczny B i jednocześnie B wysyła na adres publiczny A. Za którymś pakietem oba NATy mają już zapamiętane przekierowanie.

---

@Oscar

To w takim razie czemu to nie zadziała dla Symmetric NAT w ten sposób? Tam też w tablicach NAT powinny pojawić się odpowiednie wpisy przekierowujące...

Answer 1

Wydaje mi się, że zrozumiałem po przeanalizowaniu m.in. poniższego artykułu:

https://ipdemystify.com/2021/03/13/stun-turn-and-ice-for-nat-traversal-demystified/

Otóż proces nawiązania połączenia p2p między węzłami widzę tak:

1. Dla full-cone NAT nie ma żadnego problemu.

2. Dla Adres restricted NAT proces wygląda tak:

A wysyła ruch do B, Brama B odrzuca pakiety od A bo go nie zna.

B wysyła ruch do A, Brama A odrzuca pakiety od B bo go nie zna.

A ponownie wysyła ruch do B, tym razem w "Tabeli NAT" dla jest już zapisane, że B próbowało się skontaktować z A. Więc pakiety zostają przyjęte.

Analogicznie dzieje się w przypadku ruchu B do A.

Połączenie jest nawiązane.

3. W przypadku Symmetric NAT jest wymagane by każde żądanie dokładnie odpowiadało odpowiedzi. Tu nie ma znaczenia, że kiedyś próbowaliśmy się z jakimś hostem skontaktować, pakiety zostaną przyjęte tylko gdy są odpowiedzią na konkretne jedno żądanie. Z tego powodu użycie protokołu STUN nie powiedzie się tu. By połączenie p2p było możliwe, choć jeden z węzłów nie może być za NATem symetrycznym.

Tak ja staram się to zrozumieć, jeżeli wygaduje bzdury to będę niezmiernie wdzięczny za poprawienie mnie .

EDIT: Miałem rację, przedstawiony przeze mnie algorytm nazywamy UDP hole punching.