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

do góry

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

do góry

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/h
ow-does-team-viewer-establish-a-remote-desktop-conne
ction

--
pozdrawiam
Roman Tyczka

do góry

On 2018-11-08, Roman Tyczka <n...@b...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/h
ow-does-team-viewer-establish-a-remote-desktop-conne
ction

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

do góry

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

do góry

On 2018-11-09, Mateusz Viste <m...@n...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

do góry

Marcin Debowski pisze:
> On 2018-11-09, Mateusz Viste <m...@n...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.

do góry

On 2018-11-09, PawelS pawel(at)wbcd(dot)pl <f...@e...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

do góry

"Marcin Debowski" lnXBD.281801$Y...@f...ams1

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

Przy dobrym wietrze ;) mam 4 ms Pingowania na drodze:

Smartfon Asus
WiFi w mieszkaniu
Apek Tenda
Ethernet 100 Mb/s
ApCek TpLink
WiFi 350 metrów ulicy
Apek TpLink
Ethernet 100 Mb/s
Apek TpLink
Ethernet 100 Mb/s nie wiem dokąd i nie wiem, co dalej...

Jest to najkrótszy ping, jaki pamiętam z tych, które
zmierzyłem. Programem mierzącym był Ookla -- SpedTest.

https://play.google.com/store/apps/developer?id=Ookl
a&hl=pl

Zwykle jednak te pingi są dłuższe. Inna sprawa, że zwykle
wtedy mierzę, gdy wg mnie łączność szwankuje. :)

--
_._ _,-'""`-._ .`'.-. ._. http://eneuel.w.duna.pl .-.
)\._.,--....,'``.
(,-.`._,'( coma |\`-/| .'O`-' ., ; o.' danutac.oferty-kredytowe.pl '.O_' /,
_.. \ _\ (`._ ,.
`-.-' \ )-`( , o o) `-:`-'.'. '`\.'`.' '~'~'~'~'~'~'~'~'~'~'~'~'~' o.`.,
`._.-(,_..'--(,_..'`-.;.' Felix Lee
-bf- `- \`_`"'-.o'\:/.d`|'.;. p \ ;'. . . ;,,. ; . ,.. ; ;. .
..;\|/.......................................

do góry