Vlákno názorů k článku SixXS vypne IPv6 tunely, služby ukončí 6. června od Josef Pavlik - IPv6 je naprosta nezbytnost. Kdo tady placa nesmysly...
-
IPv6 je naprosta nezbytnost. Kdo tady placa nesmysly o tom, ze NAT spravi vsechno tak nevi, jak (ne)funguje internet.
Kdyby byl NAT resenim, tak by cely svet potreboval jedinou IP adresu a cely by byl za jednim velkym NATem :-)Konkretni priklad toho, jak soucasny internet nefunguje:
Mame po svete stovky klientu, kazdy z nich ma jedno nebo vic nasich zarizeni. Kdyz na nich potrebuju udelat jakykoliv servis, musi se napred spojit na nas server, nahodit vpn, ja si ze servera musim zjistit jakou ma pres vpn adresu a pak jit pres dalsi vpn a pres servera na tohle zarizeni. Pritom by stacilo naprosto jednoduse udelat ssh na 2001:1234:5678:abcd::1234. Kdyby meli IPv6 adresu. Jenomze tu nemaji.
Zkouseli jsme teredo, jakz takz to fungovalo, ale v konecnem vysledku nic moc. Nakonec to skoncilo tim nasim serverem se stovkami vpn.Jinak, v kancelari mame ipv6 pres 6to4, nas provider totiz o ipv6 jeste neslysel. Nebudu se o nem vyjadrovat...
A kdybych mel poscitat vsechny hodiny, co jsem stravil konfigurovanim routovani portu na NAT, abych se dostal na vnitrni sit e jake jsou problemy s https, protoze treba Lets'encrypt v podstate neumoznuje vydat certifikat na zarizeni, ktere neni dosazitelne na portu 80 a dalsi problemy, tak bych nascital nejmin rok.
-
Petr M (neregistrovaný)
No to je ještě dobrý. Dělali jsme zařízení pro jeden obchodní řetězec a jejich požadavek byl "reakce na povel z webu / mobilu do 5s". A protože se nedalo počítat s IPv6, nakonec to dopadlo tak, že co 2,5s se zařízení ptalo serveru "Máš pro mě něco?" Každý dotaz a odpověď dohromady 2kB, objednávka byla na 20k ks první rok. Jenom na tohle dotazování skrz NAT padlo na jedno zařízení v průměru 48kB/minutu, tj.skoro 68MB/den.
A když se to napočítalo i s produkcí na dalších pět let, tak v DC skončil rack s trojicí load balancerů, dva servery se SQL na požadavky, front end servery se 16 fyzickýma jádrama, dedikovaná optická lajna,...U IPv6 by si zařízení pamatovalo svůj stav. Appka v mobilu by znala IPv6 adresu, domluvili by se napřímo, bylo by to rychlejší a levnější. Na server by vlastně chodilo jenom sosat update softwaru a realizovat seznámení při instalaci, aby user nemusel přepisovat IP6 adresu... Stačilo by na to normální VPSko.
-
Petre, to jste delali zbytecne slozite.
Ja bych si predstavoval podstatne jednodussi reseni tohoto problemu:
Server, bude poslouchat na tcp portu treba 1234. Na clientske masine za NATem se nahodi spojeni na server, port 1234 a posle se mu ID clienta, aby server vedel, kdo se spojil (podle IP to nepozna). Pak bude client cekat, az mu server neco posle, spojeni zustane otevrene. Jednou za par minut by se poslat kratky packet, aby nespadlo spojeni, ale typicky by client zustaval nemy. Az by server mel nejaka data pro clienta, podiva se do tabulky na kterem spojeni visi tento client a posle se mu to. Client to dostane v realnem case.
Pokud spojeni spadne, client ho okamzite obnovi a znovu se prihlasi.Server by musel pouze ustat radove 100k aktivnich spojeni, ale traffic by byl pomerne maly.
Samozrejme v praxi by kanal musel byt kryptovany, a podobne vychytavky, ale v principu by to mohlo fungovat takto.
-
Petr M (neregistrovaný)
Já bych si představoval ještě jednodušší metodu, přímo se bavit mezi sebou. Odpadl by SPOF, traffic by šel dolů, klesla by energetická náročnost a cena výrobku o docela podstatnou položku. Ony totiž servery ($$$), vyvinout a odladit serverovou část ($$$), hosting ($$$), konektivita ($$$), energie ($$$) a údržba ($$$) se musí zaplatit v ceně výrobku, takže to nakonec dalo pěkných cca 40% VO ceny. Jenom proto, že je potřeba probourat debilní NAT.
A to pinkání na servery, to je přesně ten princip, jakým se udržuje otevřený spojení. Jenom nelítají pakety jenom tak, ale v daným čas a s nějakým nákladem. Když už to tam je a jde o čas...
