On 02 Nov 2018 11:03:49 GMT, Mateusz Viste wrote:

> 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.
>
> W takiej sytuacji Grześ może tylko próbować wysyłać tysiące pakietów do
> Krzysia, z losowymi portami src licząc, że RouterG w którymś momencie
> podmieni port src na akurat ten wybrany przez RouterK. Słowem całkowita
> loteria. Dla zwiększenia szans powodzenia, Krzyś może rozpocząć
> kilkanaście sesji UDP z różnymi portami src, coby Krzysiowi było łatwiej
> trafić.
>
> Aby zrozumieć tandetność tej sytuacji, należy zrozumieć co tak naprawdę
> robią RouterK i RouterG.
>
> Kiedy router dostaje jakiś pakiet z wewnątrz:
> 1. zmienia port src
> 2. zmienia IP src
> 3. oblicza nowy checksum TCP (lub UDP)
> 4. zapisuje sobie w pamięci (w tzw. tablicy sesji) informację co
> przetłumaczył, od kogo i na co.
>
> Kiedy router dostaje jakiś pakiet z zewnątrz:
> 1. sprawdza w tablicy sesji czy posiada wpis odpowiadający tuplowi IPsrc
> +IPdst+portSrc+portDst.
> 2. Jeśli któryś z wpisów tablicy sesji się zgadza, to podmienia adres
> DST i port DST zgodnie z wpisem.
>
> Wynika z tego, że aby ustalić połączenie z kimś za NATem, trzeba
> wystarczająco szczęścia by wstrzelić się w parametry wpisu tablicy sesji.
> A parametry te zna tylko sam router. Porty to wartości szesnastobitowe
> (przy czym zakres 0-1024 można pominąć), więc kombinacji jest tylko nieco
> ponad 4 miliony. Ale to dalej loteria.
>
> Odpowiadając na pierwotne pytanie: nie ma takiej magii, która pozwoliłaby
> ustawić na sockecie flagę "P2P" aby dostać się do dowolnego hosta za
> NATem.

Ok, w takim razie JAK aplikacja typu torrent łączy się z setkami innych
punktów w sieci P2P, z tymi za NATem także (mimo, że sama też jest za
NATem)?
Czytałem kiedyś opis tej technologii, padały tam nazwy pewnych technik i
odbywało się to niskopoziomowo, niestety wtedy mnie to mniej interesowało i
nie pamiętam, a teraz chętnie bym się tym pobawił. I to działa na IPv4, na
100%.

--
pozdrawiam
Roman Tyczka

do góry

On Fri, 02 Nov 2018 12:41:02 +0100, Roman Tyczka wrote:
> Ok, w takim razie JAK aplikacja typu torrent łączy się z setkami innych
> punktów w sieci P2P, z tymi za NATem także (mimo, że sama też jest za
> NATem)?

Czyżby tak się działo? Tzn. czy aplikacja BitTorrent jest w stanie
połączyć się ze zdalnym hostem za całkowitym NATem, sama będąc za
całkowitym NATem i bez pomocy zewnętrznego serwera? Jeśli taka magia
istnieje to sam chętnie się o niej dowiem.

Z tego co się orientuję, to większość torrentowców ustawia przekierowania
na swoich routerach. Właśnie po to, by móc być osiągalnym. W ten sposób
są też w stanie nawiązać połączenie z kimkolwiek kto jest za całkowitym
(tzn. bez przekierowań) NATem, posiłkując się serwerem wspólnym dla obu
hostów, przez który to serwer host A może poprosić hosta B "połącz się ze
mną bo coś bym chciał od ciebie a jesteś za NATem, mój adres to 1.2.3.4,
pukaj do portu 6999".

Istnieją też brzydkie tricki takie jak UPnP czy też NAT-PMP, ale to
wymaga wsparcia ze strony domowego routera i polega z grubsza na
automatycznym ustawianiu reguł z przekierowaniami.

Mateusz

do góry

W dniu 02.11.2018 o 12:03, 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.

Nieprawdą jest jakobyż.

https://en.wikipedia.org/wiki/Hole_punching_(network
ing)

p. m.

do góry

On 2018-11-02, Roman Tyczka <n...@b...no> 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.

One robią zdaje się z wykorzystanie "strony trzeciej", czyli tu
operatora, np. Skype. Jedyne co mi przychodzi do głowy na pośrednie
ominięcie NATu to np. tunel po ssh. Pośrednie, bo samo połączenie ssh
musi iść z udziałem NAT tak czy inaczej.

--
Marcin

do góry

On 2018-11-02, m <m...@g...com> wrote:
> W dniu 02.11.2018 o 12:03, 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.
>
> Nieprawdą jest jakobyż.
>
> https://en.wikipedia.org/wiki/Hole_punching_(network
ing)

No ale to jest z użyciem "third party".

--
Marcin

do góry

On 2018-11-02, Mateusz Viste <m...@n...pamietam> wrote:
> On Fri, 02 Nov 2018 10:11:30 +0000, Marcin Debowski wrote:
>>>> To nie było takie proste, ale nie moge obie przypomnieć teraz
>>>> szczegółów. Jak odgrzebię to zapodam.
>>>
>>> To jest bardzo proste. Jak kto ciekawy to sięgnie po gugla i znajdzie
>>> m.in. to:
>>> https://en.wikipedia.org/wiki/TCP/IP_stack_fingerpri
nting
>>
>> Ta forma ataku nie byłą prosta, nie fingerprintinig. Zresztą, mam coraz
>> więcej wątpliwości czy czegoś nie pomieszałem. Natrafiłem na opis chyba
>> na Niebezpieczniku, po którym dotarłem do oryginału, ale cholera nie
>> mogę się tego teraz doszukać.
>
> Ach bo ty o tym ataku o którym niewiele wiemy, że był skomplikowany.
> Myślałem że odnosisz się do mechanizmu fingerprintingu TCP :)

No wiem, że pieprzę trzy-po-trzy, ale było to na tyle fajne, że
musiałem się podzielic, a teraz za cholerę nie mogę dość co to było i
wygóglać.

--
Marcin

do góry

W dniu 03.11.2018 o 01:15, Marcin Debowski pisze:
> On 2018-11-02, m <m...@g...com> wrote:
>> W dniu 02.11.2018 o 12:03, 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.
>>
>> Nieprawdą jest jakobyż.
>>
>> https://en.wikipedia.org/wiki/Hole_punching_(network
ing)
>
> No ale to jest z użyciem "third party".
>

Tylko w zakresie poznania portu na który peery mają do siebie gadać.
Potem już gadają bezpośrednio ze sobą. (w dużym uproszczeniu).

p. m.

do góry

On 2018-11-03, m <m...@g...com> wrote:
> W dniu 03.11.2018 o 01:15, Marcin Debowski pisze:
>>>>> miałem na myśli nie tylko bezpośrednie połączenie host-host, co jest
>>>> co najmniej musi być poza NATem. Jeśli obaj są za NATem, to pomóc może
>>>> jedynie oparcie się na osobie trzeciej.
>>>
>>> Nieprawdą jest jakobyż.
>>>
>>> https://en.wikipedia.org/wiki/Hole_punching_(network
ing)
>>
>> No ale to jest z użyciem "third party".
>>
>
> Tylko w zakresie poznania portu na który peery mają do siebie gadać.
> Potem już gadają bezpośrednio ze sobą. (w dużym uproszczeniu).

Ale to nie jest takie "tylko". Cała trudność polega na tym, że trzeba być
albo poza NATem albo użyć jakiejś znanej usługi. Można jeszcze na ślepo
walić po portach, o czym Mateusz napisał, co też może zostać wykryte
(bo musiałoby być intensywne) i po ptokach.

--
Marcin

do góry

On Sat, 03 Nov 2018 02:57:52 GMT, Marcin Debowski wrote:

>>>>>> miałem na myśli nie tylko bezpośrednie połączenie host-host, co jest
>>>>> co najmniej musi być poza NATem. Jeśli obaj są za NATem, to pomóc może
>>>>> jedynie oparcie się na osobie trzeciej.
>>>>
>>>> Nieprawdą jest jakobyż.
>>>>
>>>> https://en.wikipedia.org/wiki/Hole_punching_(network
ing)
>>>
>>> No ale to jest z użyciem "third party".
>>>
>>
>> Tylko w zakresie poznania portu na który peery mają do siebie gadać.
>> Potem już gadają bezpośrednio ze sobą. (w dużym uproszczeniu).
>
> Ale to nie jest takie "tylko". Cała trudność polega na tym, że trzeba być
> albo poza NATem albo użyć jakiejś znanej usługi. Można jeszcze na ślepo
> walić po portach, o czym Mateusz napisał, co też może zostać wykryte
> (bo musiałoby być intensywne) i po ptokach.

Tak, to jest chyba to o co pytałem. Trzecia strona w przypadku skypa czy
team viewera jest zupełnie naturalna. Ciekawi mnie jednak jak to jest w
sieciach torrent, gdzie niby nie ma serwerów. Czy jest możliwe wykrycie
peera losowymi adresami i portami? Nie sądzę. Może jest jeszcze jakiś
trick?

--
pozdrawiam
Roman Tyczka

do góry

On Sat, 03 Nov 2018 03:05:22 +0100, m wrote:
> Tylko w zakresie poznania portu na który peery mają do siebie gadać.
> Potem już gadają bezpośrednio ze sobą. (w dużym uproszczeniu).

W dużym uproszczeniu to aby peery mogły do siebie rozmawiać, to muszą
mieć wyprowadzony choć jeden port na zewnątrz. Znaczy jesteś podwójnie
poza tematem, bo miało być a) bez udziału osoby trzeciej i b) z
całkowitym NATem po obu stronach :)

Mateusz

do góry