W dniu 30.10.2018 o 12:36, Marcin Debowski pisze:

Jakiego rzędu są opóźnienia na gigabitowych swiłczach? Powiedzmy, że
mam wpięte szeregowo 3-4 słicze. Będzie to miało jakikolwiek zauważalny
wpływ na prędkość? Coś innego?

Zależy od switcha. Są wolniejsze i szybsze, mają różną przepustowość, zarządzalne mogą priorytetować konkretny ruch lub konkretne porty.

On 2018-10-30, BQB <adres.anty@spamowy.com.invalid> wrote:

W dniu 30.10.2018 o 12:36, Marcin Debowski pisze:

Jakiego rzędu są opóźnienia na gigabitowych swiłczach? Powiedzmy, że
mam wpięte szeregowo 3-4 słicze. Będzie to miało jakikolwiek zauważalny
wpływ na prędkość? Coś innego?

Zależy od switcha. Są wolniejsze i szybsze, mają różną przepustowość, zarządzalne mogą priorytetować konkretny ruch lub konkretne porty.

Ale jakie to są rzędy wielkosci np. dla jakiś tanich bez zarządzania, powiedzmy TL-SG105?

--
Marcin

On Tue, 30 Oct 2018 12:33:34 +0000, Marcin Debowski wrote:

Ale jakie to są rzędy wielkosci np. dla jakiś tanich bez zarządzania,
powiedzmy TL-SG105?

Wpływ na szybkość jest zerowy.

Wpływ na latencję natomiast - poniżej milisekundy.

Mateusz

On 2018-10-30, Mateusz Viste <mateusz@nie.pamietam> wrote:

On Tue, 30 Oct 2018 12:33:34 +0000, Marcin Debowski wrote:

Ale jakie to są rzędy wielkosci np. dla jakiś tanich bez zarządzania,
powiedzmy TL-SG105?

Wpływ na szybkość jest zerowy.

Wpływ na latencję natomiast - poniżej milisekundy.

Dzięki. Tak mi się na zrowy chłopski rozum wydawało (w końcu jak inaczej zbudowac większą sieć), ale mam wpiete juz 3 sztuki, a być może będę musiał dołożyc jeszcze jeden pomiedzy, to wolałem się upewnić.

--
Marcin

W dniu 31.10.2018 o 01:23, Marcin Debowski pisze:

On 2018-10-30, Mateusz Viste <mateusz@nie.pamietam> wrote:

On Tue, 30 Oct 2018 12:33:34 +0000, Marcin Debowski wrote:

Ale jakie to są rzędy wielkosci np. dla jakiś tanich bez zarządzania,
powiedzmy TL-SG105?

Wpływ na szybkość jest zerowy.

Wpływ na latencję natomiast - poniżej milisekundy.

Dzięki. Tak mi się na zrowy chłopski rozum wydawało (w końcu jak inaczej
zbudowac większą sieć), ale mam wpiete juz 3 sztuki, a być może będę
musiał dołożyc jeszcze jeden pomiedzy, to wolałem się upewnić.

ZTCP, to kiedyś czytałem, że 7 swichy w szeregu to jest maks. ale nigdy tego nie zweryfikowałem. Nie wiem również, czemu niby tylko tyle.

On 2018-10-31, BQB <adres.anty@spamowy.com.invalid> wrote:

W dniu 31.10.2018 o 01:23, Marcin Debowski pisze:

On 2018-10-30, Mateusz Viste <mateusz@nie.pamietam> wrote:

On Tue, 30 Oct 2018 12:33:34 +0000, Marcin Debowski wrote:

Ale jakie to są rzędy wielkosci np. dla jakiś tanich bez zarządzania,
powiedzmy TL-SG105?

Wpływ na szybkość jest zerowy.

Wpływ na latencję natomiast - poniżej milisekundy.

Dzięki. Tak mi się na zrowy chłopski rozum wydawało (w końcu jak inaczej
zbudowac większą sieć), ale mam wpiete juz 3 sztuki, a być może będę
musiał dołożyc jeszcze jeden pomiedzy, to wolałem się upewnić.

ZTCP, to kiedyś czytałem, że 7 swichy w szeregu to jest maks. ale nigdy tego nie zweryfikowałem. Nie wiem również, czemu niby tylko tyle.

Nie ma to coś wspólnego z TTL (hop limit)?

--
Marcin

On Wed, 31 Oct 2018 09:24:25 +0000, Marcin Debowski wrote:

On 2018-10-31, BQB <adres.anty@spamowy.com.invalid> wrote:

W dniu 31.10.2018 o 01:23, Marcin Debowski pisze:

On 2018-10-30, Mateusz Viste <mateusz@nie.pamietam> wrote:

On Tue, 30 Oct 2018 12:33:34 +0000, Marcin Debowski wrote:

Ale jakie to są rzędy wielkosci np. dla jakiś tanich bez
zarządzania,
powiedzmy TL-SG105?

Wpływ na szybkość jest zerowy.

Wpływ na latencję natomiast - poniżej milisekundy.

Dzięki. Tak mi się na zrowy chłopski rozum wydawało (w końcu jak
inaczej zbudowac większą sieć), ale mam wpiete juz 3 sztuki, a być
może będę musiał dołożyc jeszcze jeden pomiedzy, to wolałem się
upewnić.

ZTCP, to kiedyś czytałem, że 7 swichy w szeregu to jest maks. ale nigdy
tego nie zweryfikowałem. Nie wiem również, czemu niby tylko tyle.

Nie ma to coś wspólnego z TTL (hop limit)?

TTL to właściwość pakietu IP. Ramka Ethernetowa nie posiada żadnego analogicznego licznika. Nie ma żadnego limitu dot. ilości switchy przez które ramka może zostać przełączona. Milion lat temu, kiedy światem rządziły repeatery i huby a samo pojęcie domeny kolizyjnej powodowało przerażenie w oczach każdego admina, sprawy miały się inaczej. Ale to wszystko szczęśliwie jest już dawno za nami.

Mateusz

On 2018-10-31, Mateusz Viste <mateusz@nie.pamietam> wrote:

On Wed, 31 Oct 2018 09:24:25 +0000, Marcin Debowski wrote:

On 2018-10-31, BQB <adres.anty@spamowy.com.invalid> wrote:

ZTCP, to kiedyś czytałem, że 7 swichy w szeregu to jest maks. ale nigdy
tego nie zweryfikowałem. Nie wiem również, czemu niby tylko tyle.

Nie ma to coś wspólnego z TTL (hop limit)?

TTL to właściwość pakietu IP. Ramka Ethernetowa nie posiada żadnego analogicznego licznika. Nie ma żadnego limitu dot. ilości switchy przez które ramka może zostać przełączona. Milion lat temu, kiedy światem rządziły repeatery i huby a samo pojęcie domeny kolizyjnej powodowało przerażenie w oczach każdego admina, sprawy miały się inaczej. Ale to wszystko szczęśliwie jest już dawno za nami.

Aha, czyli switche to tylko poziomie ramki i nic tam w pakietach nie grzebie. A routery? Nie modyfikują licznika?

--
Marcin

On Wed, 31 Oct 2018 21:02:57 +0000, Marcin Debowski wrote:

On 2018-10-31, Mateusz Viste <mateusz@nie.pamietam> wrote:

On Wed, 31 Oct 2018 09:24:25 +0000, Marcin Debowski wrote:

On 2018-10-31, BQB <adres.anty@spamowy.com.invalid> wrote:

ZTCP, to kiedyś czytałem, że 7 swichy w szeregu to jest maks. ale
nigdy tego nie zweryfikowałem. Nie wiem również, czemu niby tylko
tyle.

Nie ma to coś wspólnego z TTL (hop limit)?

TTL to właściwość pakietu IP. Ramka Ethernetowa nie posiada żadnego
analogicznego licznika. Nie ma żadnego limitu dot. ilości switchy przez
które ramka może zostać przełączona. Milion lat temu, kiedy światem
rządziły repeatery i huby a samo pojęcie domeny kolizyjnej powodowało
przerażenie w oczach każdego admina, sprawy miały się inaczej. Ale to
wszystko szczęśliwie jest już dawno za nami.

Aha, czyli switche to tylko poziomie ramki i nic tam w pakietach nie
grzebie.

Zgadza się, przełącznik Ethernetowy to urządzenie ograniczające się - jak sama nazwa wskazuje - do warstwy drugiej, tj. obecnie z reguły sieci Ethernet. Pojęcie "pakietu" w ogóle nie istnieje w switchowej głowie. Abstrahuję tu od tzw. "switchy L3" które od kilkunastu lat można ujrzeć w kolorowych katalogach producentów, bo to nic innego jak małe routerki z dużą ilością portów, przebrane za switch.

A routery? Nie modyfikują licznika?

Routery to i owszem, oczywiście. Od tego ten licznik właśnie jest, by pakiety IP nie zapętlały się zbyt długo w meandrach internetu. Tutaj maksymalna ilość skoków jest zależna od tego ile sobie zażyczy nadawca (w granicach do 255 skoków, bo TTL IP to ośmiobitowa wartość). No ale dyskusja była, zdaje się, o przełącznikach.

Wracając do tematu TTL, to istnieją urządzenia routujące które nie zmieniają licznika. Urządzenia te czynią tak dlatego, że chcą być niewidzialne ("stealth"), bo często poza wymuszaniem swojego trasowania wykonują także szereg innych operacji filtrująco-analizujących (DPI, IDS, IPS...). Zdarzyło mi się widzieć jak wielo-gigabitowa sieć z takimi urządzeniami została zabita przez 1 (jeden) błędny pakiet - właśnie przez brak mechanizmu wykrywania pętli w postaci TTL.

Mateusz

On 2018-11-01, Mateusz Viste <mateusz@nie.pamietam> wrote:

On Wed, 31 Oct 2018 21:02:57 +0000, Marcin Debowski wrote:

A routery? Nie modyfikują licznika?

Routery to i owszem, oczywiście. Od tego ten licznik właśnie jest, by pakiety IP nie zapętlały się zbyt długo w meandrach internetu. Tutaj maksymalna ilość skoków jest zależna od tego ile sobie zażyczy nadawca (w granicach do 255 skoków, bo TTL IP to ośmiobitowa wartość). No ale dyskusja była, zdaje się, o przełącznikach.

Tak tak, ale korzystam z okazji i z Twojej wiedzy co by poukładac sobie to w głowie w sposób nieco bardziej systematyczny.

Wracając do tematu TTL, to istnieją urządzenia routujące które nie zmieniają licznika. Urządzenia te czynią tak dlatego, że chcą być niewidzialne ("stealth"), bo często poza wymuszaniem swojego trasowania wykonują także szereg innych operacji filtrująco-analizujących (DPI, IDS, IPS...). Zdarzyło mi się widzieć jak wielo-gigabitowa sieć z takimi urządzeniami została zabita przez 1 (jeden) błędny pakiet - właśnie przez brak mechanizmu wykrywania pętli w postaci TTL.

Nb. czytałem jakiś czas temu o bardzo ciekawym ataku opierającym się (OIDP) własnie na odczycie stanu licznika - sprawdzane było w ten sposób z jakim hostem łączył się atakowany serwer czy tez jakie zaszło zdarzenie (modyfikujące lub nie licznik).

--
Marcin

On Fri, 02 Nov 2018 04:02:17 +0000, Marcin Debowski wrote:

Nb. czytałem jakiś czas temu o bardzo ciekawym ataku opierającym się
(OIDP) własnie na odczycie stanu licznika - sprawdzane było w ten sposób
z jakim hostem łączył się atakowany serwer czy tez jakie zaszło
zdarzenie (modyfikujące lub nie licznik).

Licznik TTL to średnio interesujące źródło informacji, a sam jego odczyt ciężko uznać za "atak". Swoją drogą, jego wartość faktycznie pozwala odgadnąć (z dużą dozą tolerancji) typ systemu operacyjnego który chowa się za danym adresem. Ale to informacja tak czy inaczej bardzo luźna, dużo lepsze wyniki w tym kontekście daje analiza flag, które host ustawia podczas hand-shake'u TCP (tzw. "TCP fingerprinting").

Mateusz

On 2018-11-02, Mateusz Viste <mateusz@nie.pamietam> wrote:

On Fri, 02 Nov 2018 04:02:17 +0000, Marcin Debowski wrote:

Nb. czytałem jakiś czas temu o bardzo ciekawym ataku opierającym się
(OIDP) własnie na odczycie stanu licznika - sprawdzane było w ten sposób
z jakim hostem łączył się atakowany serwer czy tez jakie zaszło
zdarzenie (modyfikujące lub nie licznik).

Licznik TTL to średnio interesujące źródło informacji, a sam jego odczyt ciężko uznać za "atak". Swoją drogą, jego wartość faktycznie pozwala odgadnąć (z dużą dozą tolerancji) typ systemu operacyjnego który chowa się za danym adresem. Ale to informacja tak czy inaczej bardzo luźna, dużo lepsze wyniki w tym kontekście daje analiza flag, które host ustawia podczas hand-shake'u TCP (tzw. "TCP fingerprinting").

To nie było takie proste, ale nie moge obie przypomnieć teraz szczegółów. Jak odgrzebię to zapodam. --
Marcin

On Fri, 02 Nov 2018 07:39:35 +0000, Marcin Debowski wrote:

On 2018-11-02, Mateusz Viste <mateusz@nie.pamietam> wrote:

On Fri, 02 Nov 2018 04:02:17 +0000, Marcin Debowski wrote:

Nb. czytałem jakiś czas temu o bardzo ciekawym ataku opierającym się
(OIDP) własnie na odczycie stanu licznika - sprawdzane było w ten
sposób z jakim hostem łączył się atakowany serwer czy tez jakie zaszło
zdarzenie (modyfikujące lub nie licznik).

Licznik TTL to średnio interesujące źródło informacji, a sam jego
odczyt ciężko uznać za "atak". Swoją drogą, jego wartość faktycznie
pozwala odgadnąć (z dużą dozą tolerancji) typ systemu operacyjnego
który chowa się za danym adresem. Ale to informacja tak czy inaczej
bardzo luźna, dużo lepsze wyniki w tym kontekście daje analiza flag,
które host ustawia podczas hand-shake'u TCP (tzw. "TCP
fingerprinting").

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_fingerprinting

Mateusz

On 2018-11-02, Mateusz Viste <mateusz@nie.pamietam> wrote:

On Fri, 02 Nov 2018 07:39:35 +0000, Marcin Debowski wrote:

On 2018-11-02, Mateusz Viste <mateusz@nie.pamietam> wrote:

On Fri, 02 Nov 2018 04:02:17 +0000, Marcin Debowski wrote:

Nb. czytałem jakiś czas temu o bardzo ciekawym ataku opierającym się
(OIDP) własnie na odczycie stanu licznika - sprawdzane było w ten
sposób z jakim hostem łączył się atakowany serwer czy tez jakie zaszło
zdarzenie (modyfikujące lub nie licznik).

Licznik TTL to średnio interesujące źródło informacji, a sam jego
odczyt ciężko uznać za "atak". Swoją drogą, jego wartość faktycznie
pozwala odgadnąć (z dużą dozą tolerancji) typ systemu operacyjnego
który chowa się za danym adresem. Ale to informacja tak czy inaczej
bardzo luźna, dużo lepsze wyniki w tym kontekście daje analiza flag,
które host ustawia podczas hand-shake'u TCP (tzw. "TCP
fingerprinting").

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_fingerprinting

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

--
Marcin

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_fingerprinting

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 :)

Ataki to swoją drogą jak najbardziej, istnieją przeróżne i zaiste bywają często mocno pokręcone.

Mateusz

On 2018-11-02, Mateusz Viste <mateusz@nie.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_fingerprinting

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

On 02 Nov 2018 07:29:34 GMT, Mateusz Viste wrote:

Nb. czytałem jakiś czas temu o bardzo ciekawym ataku opierającym się
(OIDP) własnie na odczycie stanu licznika - sprawdzane było w ten sposób
z jakim hostem łączył się atakowany serwer czy tez jakie zaszło
zdarzenie (modyfikujące lub nie licznik).

Licznik TTL to średnio interesujące źródło informacji, a sam jego odczyt ciężko uznać za "atak". Swoją drogą, jego wartość faktycznie pozwala odgadnąć (z dużą dozą tolerancji) typ systemu operacyjnego który chowa się za danym adresem. Ale to informacja tak czy inaczej bardzo luźna, dużo lepsze wyniki w tym kontekście daje analiza flag, które host ustawia podczas hand-shake'u TCP (tzw. "TCP fingerprinting").

Widzę, że kolega obcykany w TCP, więc skorzystam z okazji i spytam.
Na czym od strony TCP polega połączenie P2P, jak je uzyskać? Chodzi mi o
niskopoziomowy dostęp do socketa, od strony programowej. Załóżmy, że
chciałbym się pobawić w połączenia P2P i je zakodować na poziomie
windowsowych socketów. Od czego zacząć, jak ugryźć?

--
pozdrawiam
Roman Tyczka

On Fri, 02 Nov 2018 09:40:09 +0100, Roman Tyczka wrote:

Widzę, że kolega obcykany w TCP, więc skorzystam z okazji i spytam.
Na czym od strony TCP polega połączenie P2P, jak je uzyskać? Chodzi mi o
niskopoziomowy dostęp do socketa, od strony programowej. Załóżmy, że
chciałbym się pobawić w połączenia P2P i je zakodować na poziomie
windowsowych socketów. Od czego zacząć, jak ugryźć?

Na tak zadane pytanie naprawdę nie wiem co odpowiedzieć, bo nie rozumiem co kolega kombinuje. Odpowiem jak umiem.

Połączenie P2P to nic innego jak połączenie między jednym hostem a drugim, bez udziału dedykowanego serwera. W praktyce jeśli chcemy móc nawiązać połączenie w sposób niezależny od tego która ze stron jest inicjatorem, to obie strony muszą posiadać socket otwarty w trybie LISTEN. Czyli de facto oba hosty są "serwerami". Przykładem takiej implementacji jest popularne NTP. NTP działa co prawda z UDP, ale przy TCP zasada jest podobna. W naturze TCP leży pojęcie "serwera" i "klienta", więc dodatkowa trudność przy TCP polega na ustaleniu kto będzie robił za serwer a kto za klienta. Tutaj rozwiązania do głowy przychodzą mi (tak na zaraz) trzy:

1. jeśli adresy IP obu hostów są z góry znane, to ew. przyjąć że ten niższy jest zawsze serwerem, więc niech wyższy się łączy.

2. oba hosty nasłuchują na porcie x, jednocześnie starając się nawiązać równoległe połączenie z rozmówcą z innego socketu. Jak tylko komuś uda się nawiązać połączenie, likwiduje swój socket nasłuchujący (a druga strona zaprzestaje prób połączenia w drugą stronę).

3. oba hosty przechodzą losowo w tryb serwer/klient. Np. pierwsze 5s host czeka na połączenie z zewnątrz. Jeśli się nie uda, to przechodzi w tryb klienta i sam próbuje nawiązać połączenie z drugą stroną przez kilka sekund. Długość okresów klient/serwer wypadałoby losować, coby uniknąć nieszczęśliwej synchronizacji w której oba hosty zawsze są w tym samym trybie.

Każda z powyższych metod ma swoje wady i zalety. Wybór zależy głównie od założeń projektowych.

Od strony programowej nie ma tu nic szczególnego. Logika będzie różna zależna od wersji 1/2/3, ale "klient" zawsze będzie musiał wykonać kroki socket() + connect()
....a "serwer" zawsze będzie musiał wykonać kroki socket() + bind() + listen() + accept()

Jeśli celem jest stworzenie jakiegoś własnego protokołu do wymiany danych, to wybór UDP wydaje się (hobbystycznie patrząc) ciekawszy. Pozwoliłby w dużo bardziej elegancki sposób rozwiązać etap nawiązywania sesji, i pozwoliłby na dużo większą dowolność w implementacji metod transferu danych.

Całkiem możliwe również że kompletnie nie zrozumiałem pytania, w takim razie zalecam uściślenie.

Mateusz

On 02 Nov 2018 09:37:23 GMT, Mateusz Viste wrote:

Widzę, że kolega obcykany w TCP, więc skorzystam z okazji i spytam.
Na czym od strony TCP polega połączenie P2P, jak je uzyskać? Chodzi mi o
niskopoziomowy dostęp do socketa, od strony programowej. Załóżmy, że
chciałbym się pobawić w połączenia P2P i je zakodować na poziomie
windowsowych socketów. Od czego zacząć, jak ugryźć?

Na tak zadane pytanie naprawdę nie wiem co odpowiedzieć, bo nie rozumiem co kolega kombinuje. Odpowiem jak umiem.

[...]

Jeśli celem jest stworzenie jakiegoś własnego protokołu do wymiany danych, to wybór UDP wydaje się (hobbystycznie patrząc) ciekawszy. Pozwoliłby w dużo bardziej elegancki sposób rozwiązać etap nawiązywania sesji, i pozwoliłby na dużo większą dowolność w implementacji metod transferu danych.

Całkiem możliwe również że kompletnie nie zrozumiałem pytania, w takim razie zalecam uściślenie.

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.

--
pozdrawiam
Roman Tyczka

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.

Ale cierpliwości - IPv6 już u progu :) (od 20 lat)

Mateusz

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

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

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_(networking)

p. m.

On 2018-11-02, m <mvoicem@gmail.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_(networking)

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

--
Marcin

W dniu 03.11.2018 o 01:15, Marcin Debowski pisze:

On 2018-11-02, m <mvoicem@gmail.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_(networking)

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.

On 2018-11-03, m <mvoicem@gmail.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_(networking)

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

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_(networking)

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

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.

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

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

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.

Osoba podpisana jako nadir <none@hell.org>
w artykule <news:5bdd75ae$0$494$65785112news.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+torrenta&tr=http%3A%2F%2Ftracker1.org%2Fann%3Fmagnet&tr=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  uszer@pochta.onet.pl  (zamień miejscami z<->h w adresie)

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+torrenta&tr=http%3A%2F%2Ftracker1.org%2Fann%3Fmagnet&tr=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.

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

Osoba podpisana jako nadir <none@hell.org>
w artykule <news:5bddb9f4$0$484$65785112news.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 uszer@pochta.onet.pl (zamień miejscami z<->h w adresie)

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?

Osoba podpisana jako nadir <none@hell.org>
w artykule <news:5bddfa80$0$526$65785112news.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  uszer@pochta.onet.pl  (zamień miejscami z<->h w adresie)

On 2018-11-03, Roman Tyczka <noemail@because.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_(networking)

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

W dniu 03.11.2018 o 03:57, Marcin Debowski pisze:

On 2018-11-03, m <mvoicem@gmail.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_(networking)

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.

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

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

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.

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

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.

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

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 <mateusz@nie.pamietam>

Może pomóc przypomnieć ? ;)

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

Mateusz Viste pisze:

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.

Wręcz przeciwnie napisałeś wszystko jasno:

[ User:LAN:IP:PORT   ] NAT:IP:PORT    ===> Remote:Port
[ Joe:10.0.1.1:1234  ] 30.0.3.3:3456  ===> 20.0.2.2:2345
[ Bob:10.0.4.4:1234  ] 40.0.4.4:4567  ===> 20.0.2.2

Ten wątek wydaje mi się ciekawszy, więc zacytuję artykuł od Romana:

Introducing the Introducer
[...]
* Joe tries to send packets to Bob on address 40.0.4.4:4567. Because it's
sent from the same internal address, the firewall re-uses the From address
of 30.0.3.3:3456, and write that as the "from" address on a packet headed
"to" 40.0.4.4:4567. A paranoid NAT will also add 40.0.4.4 as an allowed
destination for this port.
Bob's firewall sees an incoming packet on 40.0.4.4:4567,
looks that up in its masquerading table, and forward
the packet to 10.0.4.4:1234.

Hey! Joe just sent a packet straight to Bob! Bob does the same thing going the other way. Suddenly, with a little help
from the introducer server out on the network, these friends can talk
to each other. The cool thing is that whatever traffic goes on
between these peers does NOT go through the central server.
Other than letting the clients find each other ("matchmaking")
the server gets out of the way.

Stąd wniosek, że NAT zapamiętuje tylko parę LAN:IP:PORT + NAT:IP:PORT
czy teoretycznie jak pojawi się trzeci użytkownik Ola
[ Ola:10.0.5.5 ] 50.0.5.5:7788 ===> Anywhere,
to Ola może również nawiązać połączenie z Joe lub Bob.

Trochę mi to psuje moje zrozumienie jak działa NAT
i jego tablica stanów połączeń, według to której
powyższy przypadek nie powinien zadziałać.

On Thu, 08 Nov 2018 18:52:44 +0100, PawelS pawel(at)wbcd(dot)pl wrote:

Stąd wniosek, że NAT zapamiętuje tylko parę LAN:IP:PORT + NAT:IP:PORT
czy teoretycznie jak pojawi się trzeci użytkownik Ola [ Ola:10.0.5.5 ]
50.0.5.5:7788 ===> Anywhere,
to Ola może również nawiązać połączenie z Joe lub Bob.

Trochę mi to psuje moje zrozumienie jak działa NAT i jego tablica stanów
połączeń, według to której powyższy przypadek nie powinien zadziałać.

Implementacji NATu (jak i innych rzeczy) jest mnóstwo. Niewykluczone, że któraś tak się zachowuje. Świat IT to dżungla.

Mateusz

On 08 Nov 2018 18:24:53 GMT, Mateusz Viste wrote:

Stąd wniosek, że NAT zapamiętuje tylko parę LAN:IP:PORT + NAT:IP:PORT
czy teoretycznie jak pojawi się trzeci użytkownik Ola [ Ola:10.0.5.5 ]
50.0.5.5:7788 ===> Anywhere,
to Ola może również nawiązać połączenie z Joe lub Bob.

Trochę mi to psuje moje zrozumienie jak działa NAT i jego tablica stanów
połączeń, według to której powyższy przypadek nie powinien zadziałać.

Implementacji NATu (jak i innych rzeczy) jest mnóstwo. Niewykluczone, że któraś tak się zachowuje. Świat IT to dżungla.

Powiem tylko tyle, że za pomocą TeamViewera i będąc za NATem łączyłem się z
wieloma różnymi komputerami z odległych sieci, też będących za NATem. Czyli
to _chyba_ jednak działa. I jak sądzę, obraz nie jest transmitowany przez
serwery TV.

https://security.stackexchange.com/questions/14280/how-does-team-viewer-establish-a-remote-desktop-connection

--
pozdrawiam
Roman Tyczka

On 2018-11-08, Roman Tyczka <noemail@because.no> wrote:

On 08 Nov 2018 18:24:53 GMT, Mateusz Viste wrote:

Stąd wniosek, że NAT zapamiętuje tylko parę LAN:IP:PORT + NAT:IP:PORT
czy teoretycznie jak pojawi się trzeci użytkownik Ola [ Ola:10.0.5.5 ]
50.0.5.5:7788 ===> Anywhere,
to Ola może również nawiązać połączenie z Joe lub Bob.

Trochę mi to psuje moje zrozumienie jak działa NAT i jego tablica stanów
połączeń, według to której powyższy przypadek nie powinien zadziałać.

Implementacji NATu (jak i innych rzeczy) jest mnóstwo. Niewykluczone, że któraś tak się zachowuje. Świat IT to dżungla.

Powiem tylko tyle, że za pomocą TeamViewera i będąc za NATem łączyłem się z
wieloma różnymi komputerami z odległych sieci, też będących za NATem. Czyli
to _chyba_ jednak działa. I jak sądzę, obraz nie jest transmitowany przez
serwery TV.

https://security.stackexchange.com/questions/14280/how-does-team-viewer-establish-a-remote-desktop-connection

To będę się musiał doszkolić.

Tyle tylko, że to udp punching wyglada mi z lekka dziwnie, bo np. ten cały TeamViewer ma w swoich FAQ'ach długi elaborat o tym jakie porty otwierac, wykorzystywac, etc. a i zdaje się nie zawsze ten punching działa (zalezy jak NAT jest ustawiony, resttrictive etc.). W sumie tak ździebko to wszystko wygląda na coś wątpliwego co jest stosowane jak juz inaczej sie nie da.

--
Marcin

On Thu, 08 Nov 2018 21:00:38 +0100, Roman Tyczka wrote:

On 08 Nov 2018 18:24:53 GMT, Mateusz Viste wrote:

Stąd wniosek, że NAT zapamiętuje tylko parę LAN:IP:PORT + NAT:IP:PORT
czy teoretycznie jak pojawi się trzeci użytkownik Ola [ Ola:10.0.5.5 ]
50.0.5.5:7788 ===> Anywhere,
to Ola może również nawiązać połączenie z Joe lub Bob.

Trochę mi to psuje moje zrozumienie jak działa NAT i jego tablica
stanów połączeń, według to której powyższy przypadek nie powinien
zadziałać.

Implementacji NATu (jak i innych rzeczy) jest mnóstwo. Niewykluczone,
że któraś tak się zachowuje. Świat IT to dżungla.

Powiem tylko tyle, że za pomocą TeamViewera i będąc za NATem łączyłem
się z wieloma różnymi komputerami z odległych sieci, też będących za
NATem. Czyli to _chyba_ jednak działa. I jak sądzę, obraz nie jest
transmitowany przez serwery TV.

Działa na zasadzie Krzyś i Grześ zalewają się wzajemnie pakietami UDP, aż któryś trafi w oczko. Pisałem o tym wcześniej. Jednak z tego co się orientuję, to w 99% przypadków ruch TV odbija się jednak od ich serwerów (przynajmniej tak było kilka lat temu), a wtedy NAT nie ma znaczenia i żadnego cudowania nie potrzeba.

Mateusz

On 2018-11-09, Mateusz Viste <mateusz@nie.pamietam> wrote:

On Thu, 08 Nov 2018 21:00:38 +0100, Roman Tyczka wrote:

On 08 Nov 2018 18:24:53 GMT, Mateusz Viste wrote:

Stąd wniosek, że NAT zapamiętuje tylko parę LAN:IP:PORT + NAT:IP:PORT
czy teoretycznie jak pojawi się trzeci użytkownik Ola [ Ola:10.0.5.5 ]
50.0.5.5:7788 ===> Anywhere,
to Ola może również nawiązać połączenie z Joe lub Bob.

Trochę mi to psuje moje zrozumienie jak działa NAT i jego tablica
stanów połączeń, według to której powyższy przypadek nie powinien
zadziałać.

Implementacji NATu (jak i innych rzeczy) jest mnóstwo. Niewykluczone,
że któraś tak się zachowuje. Świat IT to dżungla.

Powiem tylko tyle, że za pomocą TeamViewera i będąc za NATem łączyłem
się z wieloma różnymi komputerami z odległych sieci, też będących za
NATem. Czyli to _chyba_ jednak działa. I jak sądzę, obraz nie jest
transmitowany przez serwery TV.

Działa na zasadzie Krzyś i Grześ zalewają się wzajemnie pakietami UDP, aż któryś trafi w oczko. Pisałem o tym wcześniej. Jednak z tego co się orientuję, to w 99% przypadków ruch TV odbija się jednak od ich serwerów (przynajmniej tak było kilka lat temu), a wtedy NAT nie ma znaczenia i żadnego cudowania nie potrzeba.

Dla mnie to rewelacja, że ktos coś takiego w ogóle stosuje i druga, że większość FW na to pozwala.

--
Marcin

Marcin Debowski pisze:

On 2018-11-09, Mateusz Viste <mateusz@nie.pamietam> wrote

[...]

Działa na zasadzie Krzyś i Grześ zalewają się wzajemnie pakietami UDP, aż któryś trafi w oczko. Pisałem o tym wcześniej. Jednak z tego co się orientuję, to w 99% przypadków ruch TV odbija się jednak od ich serwerów (przynajmniej tak było kilka lat temu), a wtedy NAT nie ma znaczenia i żadnego cudowania nie potrzeba.

OK, w przypadku UDP to każda aplikacja, która zrobić socket() i bind()
będzie w stanie odbierać pakiety z dowolnego źródła.
W przypadku TCP jak sam wcześniej napisałeś:

Nikt inny z zewnątrz nie "wstrzeli się" w tą samą sesję.

Czyli FW/NAT musiałby przepuścić pakiet SYN do hosta za NAT,
wtedy host znajdujący się za NAT mógłby zaakceptować połączenie.

Dla mnie to rewelacja, że ktos coś takiego w ogóle stosuje i druga, że większość FW na to pozwala.

Czy ta większość obejmuje również router z OS Linux ?
I czy ewentualnie regułami iptables można tutaj coś popsuć ?
W sensie poprawić bezpieczeństwo sieci za NAT.

On 2018-11-09, PawelS pawel(at)wbcd(dot)pl <fake@email.org> wrote:

Marcin Debowski pisze:

Dla mnie to rewelacja, że ktos coś takiego w ogóle stosuje i druga, że większość FW na to pozwala.

Czy ta większość obejmuje również router z OS Linux ?
I czy ewentualnie regułami iptables można tutaj coś popsuć ?
W sensie poprawić bezpieczeństwo sieci za NAT.

Nie wiem. Część tego co znalazłem sugeruje, że np. niektóre routery blokują, ale tak jak googlam dla Linuksa to nie widzę nic konkretnego. U mnie jest w ogóle taka struktura, że mam potrójny NAT z jakimś dziwadłem od DLinka od kablówki na WANie a dalej Mikrotik i Linux też z NATem. Przyjmując ze Skype i parę innych komunikatorów, tudzież SIPowy voip to stosuja, to najwyraźniej wszystkie 3 NATy są na to podatne.

--
Marcin

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

On 2018-11-02, Roman Tyczka <noemail@because.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