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