Lista pecet@man.lodz.pl
[Lista archiwów] [Inne Listy]

Re: [PECET] opoznienia na switchu

To: pecet@man.lodz.pl
Subject: Re: [PECET] opoznienia na switchu
From: "PawelS pawel(at)wbcd(dot)pl" <fake@email.org>
Date: Tue, 06 Nov 2018 18:10:53 +0100
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ć ? ;)

<Pop. w Wątku] Aktualny Wątek [Nast. w Wątku>