CGNAT i ewentualne problemy

to jest typowe "hole punching"

Peery wysyłają do siebie pakiety po UDP w tym samym czasie (a raczej w małych odstępach czasowych), mając nadzieje że firewalle zakwalifikują ję jako odpowiedzi na wysłane pakiety i otworzą kanał do transmisji po UDP.

Problem jest oczywiście z tym że nie wiadomo jaki src port da firewall pakietowi wychodzącemu, dlatego zestawia się N połączeń żeby zwiększyć szanse na trafienie.

Oczywiście do tego potrzebny jest jakiś koordynator - NP połączenie po TCP do jakiegoś serwera, które wymienia informację pomiędzy peerami. To połączenie nie jest używane później do przekazywania właściwych danych.

Tutaj na prędce napisałem klienta

U mnie nawiązuje otwiera firewalle po kilku sekundach ale są raczej głupawe, bo przydzielają porty źródłowe sekwencyjnie

c.

A czy ja napisałem, że nie musi? Ważniejsze jest, że to do czego się chcesz przetunelować nie musi mieć dostępu do internetu, wpisanej bramy czy dns, może mieć nawet źle wpisany adres ip (w innej sieci) i też się da.

W dniu 26.06.2025 o 21:41, J.F pisze:

Też to zauważyłem i w tym momencie odechciało mi się czytać.

Teoretycznie może, praktycznie rutery mają dużo mniejsze limity.

Ale nie VPN za natem tylko klienci. Pakiety będą wracały z tym samym adresem źródłowym, porcie źródowym, adresem docelowym i zostaje 2^16 portów docelowych.

Minus jeden, bo port zerowy taki trochę mało użyteczny.

A w praktyce mniej, bo wysyłanie klienckich pakietów w świat z portem źródłowym < 1024 może być niemile widziane.

No i ten VPN musi latać po UDP albo TCP. Z takim np. GRE albo niekapsułkowanym ESP już tylko jeden klient może być w stanie się połączyć w danej chwili.

Mateusz

W dniu 26.06.2025 o 00:32, cezar pisze:

A nie da się przejść po tym samym na TCP? W ogóle taki NAT odróżnia TCP od UDP? Ja w sumie to jestem zdziwiony, że do UDP tworzy się kanał zwrotny...

Nie ma szans. Można oczywiście "encapsułować" TCP w UDP (nie wiem czy jest jakiś polski odpowiednik encapsulate - słownik podaje kapsułkować ale dziwnie brzmi) Ale UWAGA-UWAGA ... nadchodzi QUIC to takie TCP over UDP :-) HTTP/3 na tym stoi.

Jak najbardziej

popatrz sobie w /proc/sys/net/netfilter/nf_conntrack_* (lub ip_conntrack_*)

bez 3-way handshake to najlepsza metoda na uzyskanie 2-kierunkowej komunikacji.

No musi - bo chocby porty te same, a jednak to kanał inny.

Chyba zazwyczaj komunikacja jest jednak dwustronna, to musi być i kanał zwrotny.

Tylko tak mi chodzi po głowie - jeden program, może chyba słać pakiety UDP do wielu odbiorców, z jednego socketu/portu, więc może jest sens, żeby NAT to tłumaczył na jeden port wychodzący.

Zas sesja TCP to zawsze tylko między dwoma stronami ...

J.

W dniu 30.06.2025 o 10:10, J.F pisze:

Może to jest to co nazywają "simultaneous transmission", czyli wysyłasz jednocześnie do koordynatora i do peera, koordynator przekazuje port peerowi, potem już tylko do peera i sprawa załatwiona. Ale to by zbyt proste było - pewnie nie na wszystkich ruterach to działa albo nie każdy system pozwala na taką transmisję.

W dniu 30.06.2025 o 20:10, Mirek pisze:

Sądzę że jet to trywialnie proste, bo VPN może działać w obrębie aplikacji klienckich i nawet "milion" różnych/separowanych VPN w tej samej sieci lokalnej (no dobra 254 :)...ale za CGNAT z jednym IP to jest możliwe w sensie klientów podłączonych do niego. Podobnie działa każda apka, która łączy się na dane konto do serwera i obojętnie czy to VPN czy poczta, czy jakiekolwiek konto z ID :) Zwyczajnie, jeśli transmisja leci klient-serwer-klient to teoretycznie nie ma większych ograniczeń, jedynie ograniczenia prędkości i łączy operatora, który udostępnia usługę VPN "przez siebie.

W dniu 25.06.2025 o 14:56, J.F pisze:

Przecież napisałem to wcześniej. Dlaczego jesteś takim debilem, który powiela to co napisałem a na dodatek próbujesz przypisać to sobie?

Musisz się dowartościować czy jak?