W dniu 26.06.2025 o 10:14, J.F pisze:
> On Wed, 25 Jun 2025 23:00:20 +0200, Mirek wrote:

>> banał:
>> ssh -L 31761:<adres-kamery>:80 <user>@<adres-do-czego-mam-dostęp>
>
> Moment moment ... gdzies tu musi być "publiczny" adres IP.
>

A czy ja napisałem, że nie musi? Ważniejsze jest, że to do czego się
chcesz przetunelować nie musi mieć dostępu do internetu, wpisanej bramy
czy dns, może mieć nawet źle wpisany adres ip (w innej sieci) i też się
da.

--
Mirek

do góry

W dniu 26.06.2025 o 10:12, J.F pisze:
> On Wed, 25 Jun 2025 23:08:47 +0200, Mirek wrote:
>> W dniu 24.06.2025 o 15:57, ??x??(R)???????????? pisze:
>>> Kurwa. NIE. Milion klientów może być podłączonych do jednego serwera na
>>> jednym IP i mogą tworzyć milion VPN z tego serwera. Pojąłeś w końcu?
>>
>> NIE. Milion jednocześnie nie może.
>
> Chyba może.

AAA pewnie że może.
Pochrzaniło mi się, że milion za jednym natem (już problematyczne) do
jednego IP serwera VPN - to już na pewno się nie uda.

--
Mirek

do góry

On Thu, 26 Jun 2025 20:36:43 +0200, Mirek wrote:
> W dniu 26.06.2025 o 10:12, J.F pisze:
>> On Wed, 25 Jun 2025 23:08:47 +0200, Mirek wrote:
>>> W dniu 24.06.2025 o 15:57, ??x??(R)???????????? pisze:
>>>> Kurwa. NIE. Milion klientów może być podłączonych do jednego serwera na
>>>> jednym IP i mogą tworzyć milion VPN z tego serwera. Pojąłeś w końcu?
>>>
>>> NIE. Milion jednocześnie nie może.
>>
>> Chyba może.
>
> AAA pewnie że może.
> Pochrzaniło mi się, że milion za jednym natem (już problematyczne) do
> jednego IP serwera VPN - to już na pewno się nie uda.

Za zwykłym, prostym NAT - nie może, bo choćby nr portów zabraknie
(16 bit - ciekawe skąd w chinskim patencie nr portu 80000).

Ale przecież NAT może miec więcej wychodzących adresów IP,
albo liczyc, że nie wszyscy będą naraz jakieś sesje mieli.


Ale do jednego serwera VPN to chyba mogą, bo port przychodzący jeden.


J.

do góry

W dniu 26.06.2025 o 21:41, J.F pisze:

> Za zwykłym, prostym NAT - nie może, bo choćby nr portów zabraknie
> (16 bit - ciekawe skąd w chinskim patencie nr portu 80000).

Też to zauważyłem i w tym momencie odechciało mi się czytać.

>
> Ale przecież NAT może miec więcej wychodzących adresów IP,
> albo liczyc, że nie wszyscy będą naraz jakieś sesje mieli.
>
Teoretycznie może, praktycznie rutery mają dużo mniejsze limity.

>
> Ale do jednego serwera VPN to chyba mogą, bo port przychodzący jeden.
>
Ale nie VPN za natem tylko klienci. Pakiety będą wracały z tym samym
adresem źródłowym, porcie źródowym, adresem docelowym i zostaje 2^16
portów docelowych.


--
Mirek

do góry

On Thu, 26 Jun 2025 22:20:47 Mirek <m...@n...dev> wrote:
> Ale nie VPN za natem tylko klienci. Pakiety będą wracały z tym samym
> adresem źródłowym, porcie źródowym, adresem docelowym i zostaje 2^16
> portów docelowych.

Minus jeden, bo port zerowy taki trochę mało użyteczny.

A w praktyce mniej, bo wysyłanie klienckich pakietów w świat z portem
źródłowym < 1024 może być niemile widziane.

No i ten VPN musi latać po UDP albo TCP. Z takim np. GRE albo
niekapsułkowanym ESP już tylko jeden klient może być w stanie się
połączyć w danej chwili.

Mateusz

do góry

W dniu 26.06.2025 o 00:32, cezar pisze:

> Peery wysyłają do siebie pakiety po UDP w tym samym czasie (a raczej w
> małych odstępach czasowych), mając nadzieje że firewalle zakwalifikują
> ję jako odpowiedzi na wysłane pakiety i otworzą kanał do transmisji po UDP.
>

A nie da się przejść po tym samym na TCP?
W ogóle taki NAT odróżnia TCP od UDP?
Ja w sumie to jestem zdziwiony, że do UDP tworzy się kanał zwrotny...

--
Mirek

do góry

On 6/27/25 17:04, Mirek wrote:
> W dniu 26.06.2025 o 00:32, cezar pisze:
>
>> Peery wysyłają do siebie pakiety po UDP w tym samym czasie (a raczej w
>> małych odstępach czasowych), mając nadzieje że firewalle zakwalifikują
>> ję jako odpowiedzi na wysłane pakiety i otworzą kanał do transmisji po
>> UDP.
>>
>
> A nie da się przejść po tym samym na TCP?
Nie ma szans. Można oczywiście "encapsułować" TCP w UDP (nie wiem czy
jest jakiś polski odpowiednik encapsulate - słownik podaje kapsułkować
ale dziwnie brzmi)
Ale UWAGA-UWAGA ... nadchodzi QUIC to takie TCP over UDP :-)
HTTP/3 na tym stoi.




> W ogóle taki NAT odróżnia TCP od UDP?
Jak najbardziej

popatrz sobie w /proc/sys/net/netfilter/nf_conntrack_* (lub
ip_conntrack_*)


> Ja w sumie to jestem zdziwiony, że do UDP tworzy się kanał zwrotny...

bez 3-way handshake to najlepsza metoda na uzyskanie 2-kierunkowej
komunikacji.

do góry

W dniu 25.06.2025 o 17:55, cezar pisze:

>>>> Z przeglądarką tak nie pójdzie.
>>>
>>> Nie, nie pójdzie ale jeśli pomiędzy przeglądarką postawisz SERWER
>>> (aplikacja), który zestawi to połączenie, to przeglądarka bez
>>> problemu to obsłuży z adresu localhost :)...wystawionego na
>>> odpowiednim porcie dla przeglądarki :) na danym kompie. Tak to
>>> działa. Wiem doskonale, że tego nie robiłeś, to skąd masz mieć wiedzę?
>>
>> Masz prtscr :)
>> https://imgur.com/GFxLWsX  Spójrz na adres w przeglądarce :)
>>
>>
>>
>
> No cudownie... postawiłeś sobie po środku SERWER, który jest de facto
> VPNem i on to zestawił "p2p"

Ale to źle że tak można?
>
> Hole punching jest mi doskonale znany ale to nie wystarcza.  Po to
> powstały też takie technologie jak ICE(+STUN) no i TURN bo nie zawsze
> się da się przedostać przez fierewalle.
> W przypadku symmetric NAT (czyli taki jak prawie każdy router SOHO robi)
> szansa wytworzenia dziury w dwóch NATach jest mała (ale jest)
> Dokładnie w tym temacie siedzę zawodowo od 25 lat wiec mi nie pierdol że
> wynalazłeś jakiś chiński cudowny patent, który rozwiązuje wszystkie
> problemy NATów.

Doskonale wiem, że nie wszystkie. Jeśli chodzi o operatorów, to w Polsce
działa z każdym a nawet z Starlink Muska z tym chodzi. Jeśli jednak ktoś
sobie w domu stawia superrouter (za NAT operatora) to w sumie nie wiem
po co. Jeśli jednak ma publiczny adres IP to P2P mu niepotrzebne i wtedy
taki superrouter ma sens. Sensem całości jest obejście NAT operatora,
który coraz częściej nie udostępnia klientom publicznego IP i takie
rejestratory, kamery, IoT nie mogłyby działać zdalnie. Działają i oto
głównie chodzi.


--
Pixel(R)??
Albo PiS albo Polska

do góry

On Fri, 27 Jun 2025 18:04:19 +0200, Mirek wrote:
> W dniu 26.06.2025 o 00:32, cezar pisze:
>> Peery wysyłają do siebie pakiety po UDP w tym samym czasie (a raczej w
>> małych odstępach czasowych), mając nadzieje że firewalle zakwalifikują
>> ję jako odpowiedzi na wysłane pakiety i otworzą kanał do transmisji po UDP.
>>
>
> A nie da się przejść po tym samym na TCP?
> W ogóle taki NAT odróżnia TCP od UDP?

No musi - bo chocby porty te same, a jednak to kanał inny.

> Ja w sumie to jestem zdziwiony, że do UDP tworzy się kanał zwrotny...

Chyba zazwyczaj komunikacja jest jednak dwustronna, to musi być i
kanał zwrotny.

Tylko tak mi chodzi po głowie - jeden program, może chyba słać pakiety
UDP do wielu odbiorców, z jednego socketu/portu, więc może jest sens,
żeby NAT to tłumaczył na jeden port wychodzący.

Zas sesja TCP to zawsze tylko między dwoma stronami ...

J.

do góry

W dniu 30.06.2025 o 10:10, J.F pisze:

> Tylko tak mi chodzi po głowie - jeden program, może chyba słać pakiety
> UDP do wielu odbiorców, z jednego socketu/portu, więc może jest sens,
> żeby NAT to tłumaczył na jeden port wychodzący.
>

Może to jest to co nazywają "simultaneous transmission", czyli wysyłasz
jednocześnie do koordynatora i do peera, koordynator przekazuje port
peerowi, potem już tylko do peera i sprawa załatwiona.
Ale to by zbyt proste było - pewnie nie na wszystkich ruterach to działa
albo nie każdy system pozwala na taką transmisję.

--
Mirek

do góry