NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - CGNAT a dostęp do usług bankowych, Netflixa i gier online moje doświadczenia
Goto page Previous 1, 2, 3, 4, 5, 6, 7 Next
Mirek
Guest
Guest
Wed Jun 25, 2025 11:08 pm
W dniu 24.06.2025 o 15:57, x pisze:
Quote:
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?
jednym IP i mogą tworzyć milion VPN z tego serwera. Pojąłeś w końcu?
NIE. Milion jednocześnie nie może.
--
Mirek
cezar
Guest
Guest
Thu Jun 26, 2025 12:32 am
On 6/25/25 21:31, Mirek wrote:
Quote:
W dniu 25.06.2025 o 09:52, J.F pisze:
Pewnie można zaryzykować. albo sprawdzic kilka kolejnych, na wypadek,
gdyby ktos się wciął.
Ale trafi na "dobry" router, co wylosuje, i d* :-)
No to się inicjuje więcej połączeń z jednej strony i wielokrotnie trafić
z drugiej strony. Na tej publikacji co podał kolega Cezar jest przykład:
256 zainicjowane połączenia i 1024 próby daje paradoksalnie 98% szans na
powodzenie.
Ciekawa sprawa jest z "simultaneous transmission trick" - nie wiem o co
chodzi, ale chyba nie o adresy multicastowe, bo to raczej też nie realne.
Teoretycznie gdyby wysłać pakiet do serwera uzgadniającego p2p i
następnie zmusić jakoś system, żeby użył tego samego socketu - czyli de
facto zmusić do przydzielenia takiego samego portu wyjściowego i
następnie wysłać do docelowego peera to bylibyśmy w domu.
Ale nie wiem czy tędy droga - może kolega Cezar nam wyjaśni skoro
twierdzi że w tym siedzi.
Pewnie można zaryzykować. albo sprawdzic kilka kolejnych, na wypadek,
gdyby ktos się wciął.
Ale trafi na "dobry" router, co wylosuje, i d* :-)
No to się inicjuje więcej połączeń z jednej strony i wielokrotnie trafić
z drugiej strony. Na tej publikacji co podał kolega Cezar jest przykład:
256 zainicjowane połączenia i 1024 próby daje paradoksalnie 98% szans na
powodzenie.
Ciekawa sprawa jest z "simultaneous transmission trick" - nie wiem o co
chodzi, ale chyba nie o adresy multicastowe, bo to raczej też nie realne.
Teoretycznie gdyby wysłać pakiet do serwera uzgadniającego p2p i
następnie zmusić jakoś system, żeby użył tego samego socketu - czyli de
facto zmusić do przydzielenia takiego samego portu wyjściowego i
następnie wysłać do docelowego peera to bylibyśmy w domu.
Ale nie wiem czy tędy droga - może kolega Cezar nam wyjaśni skoro
twierdzi że w tym siedzi.
to jest typowe "hole punching"
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.
Problem jest oczywiście z tym że nie wiadomo jaki src port da firewall
pakietowi wychodzącemu, dlatego zestawia się N połączeń żeby zwiększyć
szanse na trafienie.
Oczywiście do tego potrzebny jest jakiś koordynator - NP połączenie po
TCP do jakiegoś serwera, które wymienia informację pomiędzy peerami. To
połączenie nie jest używane później do przekazywania właściwych danych.
Tutaj na prędce napisałem klienta
https://smalldev.tools/share-bin/v1ZAJVmQ
i serwer do wymiany IP
https://smalldev.tools/share-bin/hTCznAFu
U mnie nawiązuje otwiera firewalle po kilku sekundach ale są raczej
głupawe, bo przydzielają porty źródłowe sekwencyjnie
c.
J.F
Guest
Guest
Thu Jun 26, 2025 10:12 am
On Wed, 25 Jun 2025 23:08:47 +0200, Mirek wrote:
Quote:
W dniu 24.06.2025 o 15:57,
Çxá´Âí íí í pisze:
Kurwa. NIE. Milion klientw moe byÄ podÄ czonych do jednego serwera na
jednym IP i mogÄ tworzyÄ milion VPN z tego serwera. PojÄ e w kocu?
NIE. Milion jednoczenie nie moe.
Kurwa. NIE. Milion klientw moe byÄ podÄ czonych do jednego serwera na
jednym IP i mogÄ tworzyÄ milion VPN z tego serwera. PojÄ e w kocu?
NIE. Milion jednoczenie nie moe.
Chyba moe.
J.
J.F
Guest
Guest
Thu Jun 26, 2025 10:14 am
On Wed, 25 Jun 2025 23:00:20 +0200, Mirek wrote:
Quote:
W dniu 25.06.2025 o 17:55, cezar pisze:
On 6/25/25 01:12, Çxá´Âí íí í wrote:
W dniu 25.06.2025 o 01:53, Çxá´Âí íí í pisze:
https://imgur.com/GFxLWsXÂ Spjrz na adres w przeglÄ darce :)
No cudownie... postawie sobie po rodku SERWER, ktry jest de facto
VPNem i on to zestawi "p2p"
bana:
ssh -L 31761:<adres-kamery>:80 <user>@<adres-do-czego-mam-dostÄp
On 6/25/25 01:12, Çxá´Âí íí í wrote:
W dniu 25.06.2025 o 01:53, Çxá´Âí íí í pisze:
https://imgur.com/GFxLWsXÂ Spjrz na adres w przeglÄ darce :)
No cudownie... postawie sobie po rodku SERWER, ktry jest de facto
VPNem i on to zestawi "p2p"
bana:
ssh -L 31761:<adres-kamery>:80 <user>@<adres-do-czego-mam-dostÄp
Moment moment ... gdzies tu musi byÄ "publiczny" adres IP.
J.
J.F
Guest
Guest
Thu Jun 26, 2025 10:17 am
On Wed, 25 Jun 2025 16:55:22 +0100, cezar wrote:
Quote:
On 6/25/25 01:12,
Çxá´Âí íí í wrote:
W dniu 25.06.2025 o 01:53, Çxá´Âí íí í pisze:
Z przeglÄ darkÄ tak nie pjdzie.
Nie, nie pjdzie ale jeli pomiÄdzy przeglÄ darkÄ postawisz SERWER
(aplikacja), ktry zestawi to poÄ czenie, to przeglÄ darka bez problemu
to obsuy z adresu localhost
...wystawionego na odpowiednim porcie
dla przeglÄ darki na danym kompie. Tak to dziaa. Wiem doskonale, e
tego nie robie, to skÄ d masz mieÄ wiedzÄ?
Masz prtscr
https://imgur.com/GFxLWsXÂ Spjrz na adres w przeglÄ darce :)
No cudownie... postawie sobie po rodku SERWER, ktry jest de facto
VPNem i on to zestawi "p2p"
Hole punching jest mi doskonale znany ale to nie wystarcza. Po to
powstay 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 kady router SOHO robi)
szansa wytworzenia dziury w dwch NATach jest maa (ale jest)
Dokadnie w tym temacie siedzÄ zawodowo od 25 lat wiec mi nie pierdol e
wynalaze jaki chiski cudowny patent, ktry rozwiÄ zuje wszystkie
problemy NATw.
W dniu 25.06.2025 o 01:53, Çxá´Âí íí í pisze:
Z przeglÄ darkÄ tak nie pjdzie.
Nie, nie pjdzie ale jeli pomiÄdzy przeglÄ darkÄ postawisz SERWER
(aplikacja), ktry zestawi to poÄ czenie, to przeglÄ darka bez problemu
to obsuy z adresu localhost
...wystawionego na odpowiednim porcie
dla przeglÄ darki
na danym kompie. Tak to dziaa. Wiem doskonale, e
tego nie robie, to skÄ d masz mieÄ wiedzÄ?
Masz prtscr
https://imgur.com/GFxLWsXÂ Spjrz na adres w przeglÄ darce :)
No cudownie... postawie sobie po rodku SERWER, ktry jest de facto
VPNem i on to zestawi "p2p"
Hole punching jest mi doskonale znany ale to nie wystarcza. Po to
powstay 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 kady router SOHO robi)
szansa wytworzenia dziury w dwch NATach jest maa (ale jest)
Dokadnie w tym temacie siedzÄ zawodowo od 25 lat wiec mi nie pierdol e
wynalaze jaki chiski cudowny patent, ktry rozwiÄ zuje wszystkie
problemy NATw.
Hi hi - chinski patent moe wietnie dziaaÄ z routerkami TP-Link i
innymi chinskimi
A kto se kupi lepszy ... to niech teraz molestuje support, e mu
kamery nie dziaajÄ .
Moe siÄ skoczyÄ tak, e chinczycy sprzedadzÄ tym "lepszym" swj
patent :-)
J.
Mirek
Guest
Guest
Thu Jun 26, 2025 7:59 pm
W dniu 26.06.2025 o 10:14, J.F pisze:
Quote:
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.
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
Mirek
Guest
Guest
Thu Jun 26, 2025 8:36 pm
W dniu 26.06.2025 o 10:12, J.F pisze:
Quote:
On Wed, 25 Jun 2025 23:08:47 +0200, Mirek wrote:
W dniu 24.06.2025 o 15:57, x 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.
W dniu 24.06.2025 o 15:57, x 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
J.F
Guest
Guest
Thu Jun 26, 2025 9:41 pm
On Thu, 26 Jun 2025 20:36:43 +0200, Mirek wrote:
Quote:
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 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.
On Wed, 25 Jun 2025 23:08:47 +0200, Mirek wrote:
W dniu 24.06.2025 o 15:57, x 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.
Mirek
Guest
Guest
Thu Jun 26, 2025 10:20 pm
W dniu 26.06.2025 o 21:41, J.F pisze:
Quote:
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).
(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ć.
Quote:
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.
Quote:
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
Mateusz Viste
Guest
Guest
Fri Jun 27, 2025 8:56 am
On Thu, 26 Jun 2025 22:20:47 Mirek <mirek@null.dev> wrote:
Quote:
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.
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
Mirek
Guest
Guest
Fri Jun 27, 2025 6:04 pm
W dniu 26.06.2025 o 00:32, cezar pisze:
Quote:
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.
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
cezar
Guest
Guest
Fri Jun 27, 2025 11:37 pm
On 6/27/25 17:04, Mirek wrote:
Quote:
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
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.
Quote:
W ogóle taki NAT odróżnia TCP od UDP?
Jak najbardziej
Jak najbardziej
popatrz sobie w /proc/sys/net/netfilter/nf_conntrack_* (lub
ip_conntrack_*)
Quote:
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.
x
Guest
Guest
Sat Jun 28, 2025 7:59 pm
W dniu 25.06.2025 o 17:55, cezar pisze:
Quote:
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"
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?
Quote:
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
Albo PiS albo Polska
J.F
Guest
Guest
Mon Jun 30, 2025 10:10 am
On Fri, 27 Jun 2025 18:04:19 +0200, Mirek wrote:
Quote:
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?
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.
Quote:
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.
Mirek
Guest
Guest
Mon Jun 30, 2025 8:10 pm
W dniu 30.06.2025 o 10:10, J.F pisze:
Quote:
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.
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
elektroda NewsGroups Forum Index - Elektronika Polska - CGNAT a dostęp do usług bankowych, Netflixa i gier online moje doświadczenia