W dniu 2018-11-03 o 09:13, Roman Tyczka pisze:

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

W torrentach jest tracker i on podaje namiary na seedy i peery.
Jak uda ci się losowo wstrzelić odpowiedni adres i port, to też powinno
zadziałać. Nie rozgryzałem tego jakoś i nie używałem, ale chyba
magnetlink jakoś tak działa.

do góry

On Sat, 3 Nov 2018 09:43:16 +0100, nadir wrote:

>> 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?
>
> W torrentach jest tracker i on podaje namiary na seedy i peery.
> Jak uda ci się losowo wstrzelić odpowiedni adres i port, to też powinno
> zadziałać. Nie rozgryzałem tego jakoś i nie używałem, ale chyba
> magnetlink jakoś tak działa.

A klient torrenta zna adres tego trackera/trackerów? Bo jeśli zna to co
wtedy, gdy klienta potrzymam 3 lata w offline, trackery jakie znał zdechną
i nie będzie znał nowych... połączy się z siecią?
No chyba, że magnetlink ma w sobie zakodowany adres, ale wtedy też taki
link po latach staje się martwy, tak jest?

--
pozdrawiam
Roman Tyczka

do góry

On Sat, 03 Nov 2018 10:36:27 +0100, Roman Tyczka wrote:
> A klient torrenta zna adres tego trackera/trackerów? Bo jeśli zna to co
> wtedy, gdy klienta potrzymam 3 lata w offline, trackery jakie znał
> zdechną i nie będzie znał nowych... połączy się z siecią?
> No chyba, że magnetlink ma w sobie zakodowany adres, ale wtedy też taki
> link po latach staje się martwy, tak jest?

O tyle co się orientuję (ale żadnym ekspertem torrentowym nie jestem), to
adres(y) trackerów znajduję się w pliku *.torrent (lub w magnet-linku).
Jeśli żaden z tych trackerów nie działa to dupa. Ew. możesz dodać ręcznie
jakieś dodatkowe trackery, licząc na to że inni też tak zrobili. No chyba
że korzystasz z DHT, i łączysz się z innymi trackerami dla innych
potrzeb, to wtedy jest szansa że akurat znajdą się inni użytkownicy
posiadający dane które cię interesują.

Mateusz

do góry

W dniu 2018-11-03 o 10:36, Roman Tyczka pisze:

> A klient torrenta zna adres tego trackera/trackerów? Bo jeśli zna to co
> wtedy, gdy klienta potrzymam 3 lata w offline, trackery jakie znał zdechną
> i nie będzie znał nowych... połączy się z siecią?

Adres trackera jest "zaszyty" w pliku torrent. Jak tracker zdechnie, to
nici z wymiany informacji o peer-ach. Choć można w miarę upływu czasu
dodawać i modyfikować adresy trackerów, właśnie na wypadek jak zdechną.

> No chyba, że magnetlink ma w sobie zakodowany adres, ale wtedy też taki
> link po latach staje się martwy, tak jest?

Jak to dokładnie działa w magnet link, to nie wiem.

do góry

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

> W dniu 2018-11-03 o 10:36, Roman Tyczka pisze:
>
>> No chyba, że magnetlink ma w sobie zakodowany adres, ale wtedy też taki
>> link po latach staje się martwy, tak jest?
> Jak to dokładnie działa w magnet link, to nie wiem.

Magnet link w podstawowej wersji zawiera skrót (hash) pliku *.torrent. Może
też do linku dodawać parametry wywołania jak dla typowy linku, np.:
dn=<download name>
tr=<adres trackera>
Przykładowo dla pliku "nazwa torrenta.torrent" magnet link może wyglądać
tak:

magnet:?xt=urn:btih:tu_hash_torrenta_hex&dn=nazwa+to
rrenta&tr=http%3A%2F%2Ftracker1.org%2Fann%3Fmagnet&t
r=udp%3A%2F%2Ftracker2.org%3A80%2Fannounce

Widać tu nazwę i dwa trackery, przy czym drugi wołany po UDP i z podanym
portem. Jeśli trackery nie działają, można je usunąć i dodać nowy,
oczywiście poprawnie zapisany jako urlencoded.

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

do góry

W dniu 03.11.2018 o 03:57, Marcin Debowski pisze:
> 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.

Wydawało mi się że nie trzeba. Tj sądziłem zawsze że jeżeli to third
party odbiera połączenie, to wie z którego portu to połaczenie jest
wykonywane. Pakiety które idą potem na ten sam port, trafiają na port
wyjściowy kompa za NATem.

p. m.

do góry

W dniu 03.11.2018 o 09:19, Mateusz Viste pisze:
> 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

Może znadinterpretowałem. Zrozumiałem osobę trzecią jako proxy/relay.
Coś co przez siebie przepuszcza cały ruch. W takim przypadku
rzeczywiście, bez udziału osoby trzeciej się nie da.


> i b) z
> całkowitym NATem po obu stronach :)

Jestem przekonany, że jeżeli osoba trzecia tylko wskaże peerom na jakie
adresy/porty mają ze sobą gadać, da się to zrobić z całkowitym NATem po
obu stronach bez skanowania wszystkich portów NATa.

p. m.

do góry

On Sat, 03 Nov 2018 13:32:14 +0100, m wrote:
> Wydawało mi się że nie trzeba. Tj sądziłem zawsze że jeżeli to third
> party odbiera połączenie, to wie z którego portu to połaczenie jest
> wykonywane.

To się oczywiście zgadza.

> Pakiety które idą potem na ten sam port, trafiają na port
> wyjściowy kompa za NATem.

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.

Zatem to co piszesz jest prawdą, ale tylko i wyłącznie w kontekście
połączenia/sesji między "kompem za NATem" a serwerem "third-party". Nikt
inny z zewnątrz nie "wstrzeli się" w tą samą sesję.

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

Powyższe, w luźnym tłumaczeniu brzmi "host 192.168.0.8 użył swojego portu
56309 by nawiązać połączenie z 80.88.105.69 na porcie 80, po NAT
podmieniłem adres prywatny na mój własny 85.86.45.1 i zmieniłem port na
54887, następnie wypuściłem pakiet interfejsem em0".

W drodze powrotnej, tylko i wyłącznie pakiety odpowiadające temu wzorcowi
trafią do 192.168.0.8 (czyli pakiety pochodzące od 80.88.105.69 z portu
80, zaadresowane do 85.86.45.1 na port 54887 i pojawiające się na
interfejsie em0 routera).

Mateusz

do góry

On Sat, 03 Nov 2018 13:39:45 +0100, m wrote:
> Jestem przekonany, że jeżeli osoba trzecia tylko wskaże peerom na jakie
> adresy/porty mają ze sobą gadać, da się to zrobić z całkowitym NATem po
> obu stronach bez skanowania wszystkich portów NATa.

W świecie IT przekonania to za mało. Patrz odpowiedź którą wysłałem
kilkanaście sekund temu w innej odnodze wątku. Jeśli nie wierzysz,
zalecam wykonanie testu samemu, empiryzm najlepszą drogą do wiedzy.

Mateusz

do góry

W dniu 2018-11-03 o 13:01, Andrzej P. Wozniak pisze:

> Magnet link w podstawowej wersji zawiera skrót (hash) pliku *.torrent. Może
> też do linku dodawać parametry wywołania jak dla typowy linku, np.:
> dn=<download name>
> tr=<adres trackera>
> Przykładowo dla pliku "nazwa torrenta.torrent" magnet link może wyglądać
> tak:
>
> magnet:?xt=urn:btih:tu_hash_torrenta_hex&dn=nazwa+to
rrenta&tr=http%3A%2F%2Ftracker1.org%2Fann%3Fmagnet&t
r=udp%3A%2F%2Ftracker2.org%3A80%2Fannounce
>
>
> Widać tu nazwę i dwa trackery, przy czym drugi wołany po UDP i z podanym
> portem. 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

Jest tylko hash pliku i nic po za tym.

do góry