On Sat, 03 Nov 2018 16:08:35 +0100, nadir wrote:
> To to jest pikuś.
>
> Ja mam na myśli takiego magnet linka:
>
> magnet:?xt=urn:btih:HI7NPHMTIXD6RTS4JSGWTCCTEHSGKIIA
>
> Jest tylko hash pliku i nic po za tym.

W takiej sytuacji, klient torrentowy może próbować posiłkować się jakąś
swoją sztywną listą trackerów lub skorzystać z DHT. W każdej z tych
sytuacji niezbędna jest pomoc zewnętrznego serwera.

Mateusz

do góry

Osoba podpisana jako nadir <n...@h...org>
w artykule <news:5bddb9f4$0$484$65785112@news.neostrada.pl> pisze:

> W dniu 2018-11-03 o 13:01, Andrzej P. Wozniak pisze:
>
>> Magnet link w podstawowej wersji zawiera skrót (hash) pliku *.torrent.
>> Jeśli trackery nie działają, można je usunąć i dodać nowy,
>> oczywiście poprawnie zapisany jako urlencoded.
>
> To to jest pikuś.
>
> Ja mam na myśli takiego magnet linka:
>
> magnet:?xt=urn:btih:HI7NPHMTIXD6RTS4JSGWTCCTEHSGKIIA

To oczywiście lipny przykład, bo poprawny skrót jest zapisywany
szesnastkowo.

> Jest tylko hash pliku i nic poza tym.

Jak napisałem, że możesz dodać nowy tracker, to dodaj jakikolwiek
działający, jeśli nie masz żadnego aktywnego torrenta. Nazwę też możesz
dodać sam - tymczasową, aby tylko na liście pobierania wyświetlało się
coś sensownego i niepowtarzalnego.

--
Andrzej P. Woźniak u...@p...onet.pl (zamień miejscami z<->h w adresie)

do góry

W dniu 2018-11-03 o 20:17, Andrzej P. Wozniak pisze:

>> magnet:?xt=urn:btih:HI7NPHMTIXD6RTS4JSGWTCCTEHSGKIIA
>
> To oczywiście lipny przykład, bo poprawny skrót jest zapisywany
> szesnastkowo.

A co w nim lipnego?
Mam na przykład taki, świeży wygenerowany na przykładzie hash-a z
działającego torrenta:

magnet:?xt=urn:btih:ALGVGJL3ND5MSBEJQUF6CBUR356EFZC2

> Jak napisałem, że możesz dodać nowy tracker, to dodaj jakikolwiek
> działający, jeśli nie masz żadnego aktywnego torrenta. Nazwę też możesz
> dodać sam - tymczasową, aby tylko na liście pobierania wyświetlało się
> coś sensownego i niepowtarzalnego.

Ależ ja wiem, że mogę sobie pododawać to i tamo.
Mnie bardziej dziwi jak to działa bez dodawania żadnych trackerów. Skąd
mój klient wie do czego łączyć i skąd cokolwiek pobierać? Gdzieś te
hash-e są rozgłaszane?

do góry

Osoba podpisana jako nadir <n...@h...org>
w artykule <news:5bddfa80$0$526$65785112@news.neostrada.pl> pisze:

> W dniu 2018-11-03 o 20:17, Andrzej P. Wozniak pisze:
>
>>> magnet:?xt=urn:btih:HI7NPHMTIXD6RTS4JSGWTCCTEHSGKIIA
>>
>> To oczywiście lipny przykład, bo poprawny skrót jest zapisywany
>> szesnastkowo.
> A co w nim lipnego?
> Mam na przykład taki, świeży wygenerowany na przykładzie hash-a z
> działającego torrenta:
> magnet:?xt=urn:btih:ALGVGJL3ND5MSBEJQUF6CBUR356EFZC2

No dobra, przyjrzałem się jeszcze raz. Skróty wyglądają na zapisane
w kodowaniu Base32 (znaki A-Z, 2-7) zamiast hex (znaki 0-9, A-F).

>> Jak napisałem, że możesz dodać nowy tracker, to dodaj jakikolwiek
>> działający, jeśli nie masz żadnego aktywnego torrenta. Nazwę też możesz
>> dodać sam - tymczasową, aby tylko na liście pobierania wyświetlało się
>> coś sensownego i niepowtarzalnego.
> Ależ ja wiem, że mogę sobie pododawać to i tamo.
> Mnie bardziej dziwi jak to działa bez dodawania żadnych trackerów.

A jak działa podłączanie po raz pierwszy komputera do internetu? Przecież
wtedy nie ma jeszcze adresu IP.

> Skąd
> mój klient wie do czego łączyć i skąd cokolwiek pobierać?

Raczej serwer. W trybie bez trackerów każdy z klientów sam działa jak
tracker i rozgłasza swoje usługi po UDP. Z drugiej strony zaś nasłuchuje,
czy inne klienty nie rozgłaszają się jako trackery.

Jeśli nie ma innego klienta w sieci lokalnej czy w tej samej klasie adresów
IP (należących do jednego dostawcy), to oczekiwanie na trafienie może trwać
miesiącami. Stąd sugestia, by zawsze mieć aktywnego jakiegoś torrenta z
działającymi trackerami lub trackery dopisywać samodzielnie.

> Gdzieś te hash-e są rozgłaszane?

Skróty to są raczej wymieniane bezpośrednio między klientami, kiedy już
jakieś się ze sobą skontaktują. Oprócz tego klienty pracujące jako trackery
udostepniają listę innych klientów, z którymi miały kontakt.

Przy włączonym DHT (i innych rozszerzeniach) i aktywnych torrentach klient
nie tylko stale się rozgłasza, ale też ma wciąż niepustą listę innych
klientów (w tym pracujących jako trackery) i jeśli dodasz nowy magnet link,
ponawia wymianę skrótów (i w miarę potrzeby list klientów).

Oczywiście to jest uproszczenie, więc coś tam mogłem pominąć lub przekręcić.

--
Andrzej P. Woźniak u...@p...onet.pl (zamień miejscami z<->h w adresie)

do góry

On 2018-11-03, Roman Tyczka <n...@b...no> wrote:
> 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?

O torrentach nie mam pojęcia, ale widzę, że się dyskusja w innym
podwątku już rozwinęła.

Niestety, chyba nie ma innego sposobu. Po prostu trzeba jakoś tę
informację o portach przekazać. Nawet jak te peery zadzwonią do siebie
telefonem to cały czas będzie to wymieniony przypadek użycia
alretnatywnej usługi :)

--
Marcin

do góry

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.

do góry

On Sun, 04 Nov 2018 23:23:29 +0100, PawelS pawel(at)wbcd(dot)pl wrote:
> 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ł.

Niektóre implementacje mogą próbować portu nie zmieniać, zgadza się. To
pomaga m.in. przy RDP w ramach SIP. Ale to bardzo ograniczona zdolność, i
tak czy inaczej nie pozwalająca wbić się zewnętrznej osobie trzeciej na
ten sam port by trafić do hosta w LANie (któryś z kolegów to wcześniej
sugerował).

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

Otóż to.

Mateusz

do góry

Mateusz Viste pisze:
> On Sun, 04 Nov 2018 23:23:29 +0100, PawelS pawel(at)wbcd(dot)pl wrote:
>> 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ł.
>
> Niektóre implementacje mogą próbować portu nie zmieniać, zgadza się. To
> pomaga m.in. przy RDP w ramach SIP. Ale to bardzo ograniczona zdolność, i
> tak czy inaczej nie pozwalająca wbić się zewnętrznej osobie trzeciej na
> ten sam port by trafić do hosta w LANie (któryś z kolegów to wcześniej
> sugerował)
Oczywiście mowa tutaj NAT (SNAT/MASQUERADE).
Tak czy inaczej w przypadku gdy dwa hosty znajdują się za NAT,
to nawet jeśli obydwa hosty nawiążą połączenie TCP z serwerem
osiągalnych dla obydwu hostów znajdujących się za NAT
nawet jak poznają swoje adresy IP+PORT za NAT w dalszym ciągu
nie będą w stanie ze sobą wymieniać bezpośrednio pakietów.
Żaden firewall/router/NAT nie wyśle do hosta dla którego robi NAT
pakietu pochodzącego z "zewnątrz" nie będącego pakietem
związanym z połączeniem wychodzących z sieci lokalnej
(oczywiście przy braku translacji w drugą stronę DNAT).

Tak jak sam napisałeś:
> Nikt inny z zewnątrz nie "wstrzeli się" w tą samą sesję.

Poza tym poniższy scenariusz też nie powinien zadziałać:
> 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ć.
gdyż jak sam napisałeś:
> Tablica sesji NAT to nie tylko relacja "port zewnętrzny = klient w
> środku". To zestaw kilku informacji: port po translacji + adres IP po
> translacji + zdalny host + zdalny port + interfejs wyjściowy routera.
czyli, aby wysłać odebrany pakiet z "zewnątrz" i przesłać do host za NAT,
dane połączenie musi zostać odnalezione w tablicy sesji NAT,
w przeciwnym razie translacja odwrotna nie będzie możliwa,
czyli powyższe próby "Grzesia" zakończą się odrzucaniem pakietów
oraz ewentualnym logowaniem pakietów, a takie wysyłanie pakietów
może zostać odebrane jak skan portów i również zablokowane.

> From: Mateusz Viste <m...@n...pamietam>
Może pomóc przypomnieć ? ;)

do góry

On Tue, 06 Nov 2018 18:10:53 +0100, PawelS pawel(at)wbcd(dot)pl wrote:
> czyli, aby wysłać odebrany pakiet z "zewnątrz" i przesłać do host za
> NAT,
> dane połączenie musi zostać odnalezione w tablicy sesji NAT,
> w przeciwnym razie translacja odwrotna nie będzie możliwa,
> czyli powyższe próby "Grzesia" zakończą się odrzucaniem pakietów oraz
> ewentualnym logowaniem pakietów, a takie wysyłanie pakietów może zostać
> odebrane jak skan portów i również zablokowane.

Ja być może niejasno napisałem, dlatego sprostuję: moja teoria wymaga
naturalnie by Krzyś wykonał kilka/kilkanaście (im więcej tym lepiej) prób
w kierunku Grzesia. W ten sposób Grześ ma jakąś tam szansę wpaść na
poprawną parę portów.
Jeśli tylko jedna ze stron będzie kombinować, to oczywiście szanse na
powodzenie są żadne.

Mateusz

do góry

On Tue, 06 Nov 2018 18:10:53 +0100, PawelS pawel(at)wbcd(dot)pl wrote:

>>> 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ł.
>>
>> Niektóre implementacje mogą próbować portu nie zmieniać, zgadza się. To
>> pomaga m.in. przy RDP w ramach SIP. Ale to bardzo ograniczona zdolność, i
>> tak czy inaczej nie pozwalająca wbić się zewnętrznej osobie trzeciej na
>> ten sam port by trafić do hosta w LANie (któryś z kolegów to wcześniej
>> sugerował)
> Oczywiście mowa tutaj NAT (SNAT/MASQUERADE).
> Tak czy inaczej w przypadku gdy dwa hosty znajdują się za NAT,
> to nawet jeśli obydwa hosty nawiążą połączenie TCP z serwerem
> osiągalnych dla obydwu hostów znajdujących się za NAT
> nawet jak poznają swoje adresy IP+PORT za NAT w dalszym ciągu
> nie będą w stanie ze sobą wymieniać bezpośrednio pakietów.
> Żaden firewall/router/NAT nie wyśle do hosta dla którego robi NAT
> pakietu pochodzącego z "zewnątrz" nie będącego pakietem
> związanym z połączeniem wychodzących z sieci lokalnej
> (oczywiście przy braku translacji w drugą stronę DNAT).

I chyba znalazłem ten dokument, który o tym kiedyś czytałem z masą linków
dodatkowych.

http://www.mindcontrol.org/~hplus/nat-punch.html

Trochę on przeczy stwierdzeniom, że się nie da ;-)

Oczywiście na start potrzebny jest serwer, żeby zestawić połączenie, ale
już sam transfer go nie wymaga.

Co Wy na to?

--
pozdrawiam
Roman Tyczka

do góry