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.
|