Vlákno názorů k článku Severní Amerika bez IPv4 adres: ARIN hlásí „zero“ od muf - Není náhodou pro "strýčka příhodu" rezervováno cca 250...
-
Ondřej CaletkaZlatý podporovatelJak určíte, kdo adresy potřebuje a kdo ne? I kdybyste všechny IPv4 adresy světa sesbíral a přerozdělil, stejně vám nevystačí na všechna současná internetová zařízení a to ještě vůbec neuvažujeme přepokládaný růst, jako třeba IoT.
-
Petr M (neregistrovaný)
Právě kvůli těm hračkám je public IP nezbytnost, bez ohledu na protokol. Budu dělat třeba elektronickýho vrátnýho s kamerou.
Pokud bude za NATem a zákazník chce zvonění do 1s a navázání komunkace s kamerou do 1s, tak i mobil i vrátný musí pinkat min. 1x za sekundu na server, jestli je tam požadavek druhé strany, autorizovat se,... A při požadavku na bezpečnost navíc s šifrováním a autentizací. Prodej v 10 státech, všude v průměru 20 000ks. To je 400 000 pingů/s (pokud budou spárovaný k baráku dva mobily, tak 600 000pingů/s) a musím mít odpovídající infrastrukturu (v každým z těch 10 států nějaký rack v datacentru s připojením na páteřní lajny,...).
Bez NATu zazvodí návštěva, pošle se na public IP aplikace v mobilu zpráva,... Chci se podívat ke dveřím, pustím appku, ta si z veřejné IP vyžádá video stream... A bez pinkání, bez sříně v datacentru.
Takže pokud chchi decentralizovaný řešení bez serverů, můžu použít IPv4, ale tam je na dnešní dobu moc málo volných adres na takový kšeft a navíc nepodporuje mobilitu klienta, takže bych se musel s mobilním klientem přihlašovat po každé změně sítě (přepnutí z LTE na WiFi,...)
Nebo můžu použít IPv6, kde je nejenom dostatek IP adres, ale dokonce je i podpora pro mobilitu, kde má zařízení několik IP adres a na jeho "domácí" IP adresu se protuneluju kamkoliv v rámci standardního řešení.
Nebo snad existuje kromě Public 4, Public 6 a Server nějaký čtvrtý, kouzelný řešení?
-
Petr M (neregistrovaný)
Nejde o zavření spojení. Problém NATu je v tom, že zvenku se na zařízení nedá dostat. Přijme paket zevnitř, zapamatuje si, od koho byl a pošle ho se svou hlavičkou. Pak si zase najde, od koho byl požadavek a předá mu odpověď a smaže záznam. Pokud pošlu z mobilu nebo z PC v práci povel "vypusť na tchýni pitbula", tak mám smůlu, NATem ten paket neprojde. NAT jednoduše neví, komu ho předat. Jedině zámku od kotce nechat zprávu na domluveným místě a doufat, že se zámek na tu zprávu mrkne dřív, než za sebou tchýně zavře dveře od baráku.
V praxi pak
- 99% komunikace probíhá jenom proto, aby zařízení bylo v obraze
- místo poslouchání ve stand-by a občasné synchronizace s WiFi se komunikuje trvale, u IoT na baterky a s WiFi je to zatím neřešitelný problém (ostatně, pinkání na server z aplikace na mobilu taky výdrži na jedno nabití nepřidá)
- překlenout NAT použitím dedikovanýho portu nejde bez spoluúčasti ISP (konfigurace NAT+Firewall), provozovatele služby (nastavení portu a IP) a klienta (konfigurace routeru).
- U mobilu má podstatný vliv nejenom na baterku, ale i na FUP
- Nutná podpora infrastruktury - servery poskytovatele služby, možnst sledování, SPoF pro celou oblast
- Zatěžuje zbytečně páteřní lajny - pokud si odběhnu do hospody v síti stejnýho ISP, tak stejně jdou požadavky x stovek km do jeho serverovny a zpátky - a nejenom moje požadavky... IPv6 by se odbavilo v rámci ISP. -
Obávám se pane, že o sítích toho moc nevíte a plkáním takových nesmyslů děláte IPv6 medvědí službu.
V praxi to funguje tak, že mobil (za NATem) naváže spojení se serverem (s veřejnou IP adresou) a toto spojení udržuje. Totéž udělá zámek od kotce. Pokud chce mobil komunikovat se zámkem, pošle zprávu na server a ten jí přepošle tím otevřeným spojením zámku - a naopak. Žádné "pinkání" není potřeba. Jediná nevýhoda je, že data nechodí přímo, ale delší cestou přes server.
Jinak, na přímé připojení zvenčí stačí jedna veřejná IP adresa pro celou domácí síť. A ta se u slušných ISP většinou dá zařídit. Svůj domácí router máte v moci, na jeho konfiguraci součinnost ISP nepotřebujete.
-
Petr M (neregistrovaný)
"V praxi to funguje tak, že mobil (za NATem) naváže spojení se serverem (s veřejnou IP adresou) a toto spojení udržuje. Totéž udělá zámek od kotce. Pokud chce mobil komunikovat se zámkem, pošle zprávu na server a ten jí přepošle tím otevřeným spojením zámku - a naopak"
Takhle to funguje na aplikační vrstvě, naprosto transparentně. Pod tím to chodí tak, že zámek kotce má IP 192.168.1.100, NAT to přeloží na svou adresu, řekněme 50.100.150.200 a pošle požadavek na otevření soketu na server 100.110.120.130.
Server 100.110.120.130 eviduje u spojení adresu 50.100.150.200, se kterým komunikuje. Namá šanci vidět, že je to ve skutečnosti spojení se zámkem. Kdyby server rovnou poslal v rámci spojení data na NAT, nedojde to nikam.
"Jinak, na přímé připojení zvenčí stačí jedna veřejná IP adresa pro celou domácí síť. A ta se u slušných ISP většinou dá zařídit. Svůj domácí router máte v moci, na jeho konfiguraci součinnost ISP nepotřebujete."
Jo, ale IoT má být pro lamy. Pokud bude něco potřeba rozvrtat v routeru, tak to bude v pr... Zkuste vysvětlit, že na ZyXelu se nedá použít návod pro OvisLink, nutit lamu k tomu, aby se hádal s ISPíkem, protože "ta krabička chce nějaký heslo"... A WiFi sítě za CGNATem jsou kapitola sama pro sebe...Už vidím to maškarádování na CGNATu.
-
SB (neregistrovaný)
„...naváže spojení se serverem (s veřejnou IP adresou) a toto spojení udržuje.“ Zapomněl jste upřesnit, jak klient se serverem udržuje spojení.
„...na přímé připojení zvenčí stačí jedna veřejná IP adresa pro celou domácí síť.“ Zde jste pozapomněl na administraci síťových prvků po cestě, často netriviální.
-
j (neregistrovaný)
Obavam se, ze kulovy vis leda ty. To spojeni je treba udrzovat orevreny => ta krabka musi byt neustale aktivni na siti. Pokud neni, neni ani zadny spojeni. Keepalive je pro tebe zjevne sprosty slovo ...
Kdyz krabka jen posloucha, tak staci kdyz je v nejakym sleep rezimu, a probudi se az v reakci na prichozi komunikaci.
A ad jedna IP ... jasne, on si kazdej jeden BFU bude konfigurovat porty, kdyz ani nevi co to je. Nemluve o tom, ze IPcek neni dost ani pro ty domacnosti.
-
SB (neregistrovaný)
Obávám se, že z vaší pozice můžete těžko určovat, čemu ještě stačí neveřejná adresa a čemu už ne.
Dovoluju si připomenout starší zajímavý článek o využití IPv6.
