Mateusz Viste pisze:
> On Fri, 02 Nov 2018 10:59:01 +0100, Roman Tyczka wrote:
>> Rzeczywiście za mało precyzyjnie napisałem. Używając określenia P2P
>> miałem na myśli nie tylko bezpośrednie połączenie host-host, co jest
>> oczywiste,
>> ale dalsze problemy jakie za tym idą, czyli nawiązanie połączenia
>> omijającego NAT. Czytałem gdzieś kiedyś o tym, że sprawa opiera się o
>> niskopoziomowe manipulowanie nagłówkami TCP/IP w czasie zestawiania
>> połączenia, potem to już z górki (w sensie, że sama komunikacja jest
>> innym etapiem, a problemem jest nawiązanie połączenia). Takie rzeczy
>> robi skype, torrenty czy kiedyś emule.
>
> Nie ma cudów - aby Grześ z Krzysiem mogli pogadać po TCP, to jeden z nich
> co najmniej musi być poza NATem. Jeśli obaj są za NATem, to pomóc może
> jedynie oparcie się na osobie trzeciej.
>
> Z UDP można próbować kombinować, ale to niezwykle upierdliwa sprawa:
>
> Krzyś wysyła datagramy UDP do Grzesia, z portu src 5000 do portu dst 6000.
>
> Krzyś -> RouterK -> INTERNET -> RouterG -> Grześ
>
> Po drodze RouterK zmienia port źródłowy datagramów na, dajmy na to, 20000.
Nie zawsze jest to prawdą. To zależy od rodzaju użytego Routera.
Być może tak jak to napisałeś poniżej FreeBSD zmieni port źródłowy połączenia.

> W praktyce pojedynczy wpis tablicy sesji wygląda tak (przykład na
> FreeBSD, zależnie od implementacji routera może być wyświetlony nieco
> inaczej):
>
> em0 tcp 85.86.45.1:54887 (192.168.0.8:56309) -> 80.88.105.69:80
Sprawdź jak to wygląda w przypadku kiedy Routerem jest Linux.
W kliencie HTTP przed nawiązaniem połączenia ustawiłem bind
do lokalnego portu, następie pobrałem stronę, która wyświetla informacje
o połączeniu (m.in. adres IP, port), adres IP oczywiście był adresem NAT,
ale port źródłowy się nie zmienił. Gdyby były dwa równoległe połączenia
z tego samego portu źródłowego, to dla drugiego połączenia
port źródłowy faktycznie ulega już modyfikacji.