Je zajímavé, že první zmínka o nedostatku IPv4 adres se objevila už v RFC 1338 z roku 1992, takže to není žádná novinka a vědělo se o tom už ve chvíli, kdy se Československo připojilo k internetu. Je to koncepční problém, který jsme o desítky let oddálili pomocí překladu adres a privátního adresování, ale opravit ho na IPv4 nelze.
České ministerstvo školství má používat pouze české TLD (maximálně pro zahraniční spolupráci něco jiného), doufám, že to tak i je.
600 domén je dost, ale bez reálného seznamu se nedá posoudit, jestli jsou některé domény zbytečné. Přibližně 30 domén ročně mi ale připadá dost, ale bez seznamu se to nedá hodnotit.
Pro komerční projekt firma kupuje JEDNU doménu, která je snadno zapamatovatelná. K tomu případně pár překlepových, určitě ne desítky, natož stovky.
Az bude 1 IPv4 adresa stat $1000 mesicne tak to trh samozrejme vyresi. Pokud je ale konfigurace ipv6 drazsi nez platit za ipv4 tak to nikdo nebude resit. A ne, opravdu se nejedna o jeden checkbox nekde na jednom zarizeni, obvykle korporaty maji x zavislosti a zmeny stoji klidne statisice nebo i miliony.
Nasadené ako nasadené. Keď ohliadneme od ISP ktorí nevedia iný subnet ako /64, tak ďalší veľký problém je používanie DS-Lite a nie plnohodnotného dual stack.
Prečo je to problém: napríklad mám 5 pripojení, všetky vedia IPv4. Mám medzi nimi site-to-site VPN. Niektorí s ISP nám s veľkou slávou oznámia podporu IPv6 (a DS-lite). Môžem postupne migrovať jednotlivé pripojenia na IPv6, podľa toho ako príslušný provider zavedie podporu IPv6? No jasné že nemôžem. Pokiaľ by tam bol plnohodnotný dual stack, tak by som mohol. Výsledkom je, že ostávam na čistom IPv4 a všetky múdra, ako ISP dávno podporujú IPv6, idú jedným uchom dnu a druhým von.
DS-lite je ekvivalent CGNAT; za neho môžete dať len tých zákazníkov, ktorí v IPv4 svete nemali problém s CGNAT, ale nie tých, ktorí mali verejné adresy.
Voči existencii DS-lite nemám žiadne námietky. Problémom je, že ISP nemajú riešenie, pokiaľ DS-lite je nedostačujúce. Nech sa potom nikto nečuduje, že koncový zákazník to nerieši, keď mu čisté IPv4 funguje a DS-lite by mu nefungovalo.
VPN spojení je niekoľko, nie jedno. Nie je to hub-and-spoke, ale point-to-point. DS-lite s uvedeným obmedzením by bolo použiteľné presne pre jediného z nich. Už keby boli dvaja, tak títo dvaja sa nikdy nespoja.
A tak z pohledu providera je pochopitelne, ze tam kde muze verejne IPv4 proste vykosti. Stavet to zpusobem "necham jim public IPv4 a k tomu prilepim IPv6" - no, moznost to je, ale narazi prave v tom bode, kdy adresy i v ramci lokalnich poolu dojdou, pak se stejne bude dumat co s tim. A pokud si explicitne klient za IPv4 verejku neplati, je jednodussi to rovnou mit ve stavu ala DS-lite, zvlaste s novou sluzbou (core uz resite IPv6-only). Navic DS-lite se typicky cpe do sluzeb pro retail. Aneb pokud se nekdo snazi pouzivat pripojku urcenou primarne pro domacnosti pro korporatni potreby, tak spis bude problem v tom ze zvolil spatny typ sluzby (aby "usetril"). A tak kdyz chci setrit, pak se smirim i s IPSECem pres UDP, ne? A tam fakt neni limit jen jedne VPN.
>>> Jenže tohle ve skutečnosti vůbec problém není, protože ti největší internetoví hráči mají dávno šestku nasazenou
No ne tak uplne.
O2 na slovensku mobilni pripojeni pres IPv6 nema!
Mel jsem jeden projekt pouze na IPv6 AAAA.
Pak sem se nestacil divit, kdyz jednemu zakaznikovi to nejelo. A ostatnim vpohode.
Po dlohem patrani sem prisel na to ze O2 na sloevnsku nema jeste implementovanu IPv6 pro mob. pripojeni.
Pak jsem chte-nechte musel pridat take DNS A zaznam s IPv4 a pak mu to uz jelo.
Praveze je to naopak. Ked som naposledy ziadal od Orange verejnu IPv6 adresu, dostal som odpoved, ze mi verejnu IPv6 adresu daju len vtedy, ak si zaplatim za fixnu IPv4 adresu. Darmo som im vysvetloval, ze nepotrebujem IPv4 a ani nemusi byt fixna. Bernak nepusti.
Naco by som teda prechadzal na IPv6, ked mi neumozni to hlavne: pristup domov z netu?
Ak vie niekto ako je to u Orangu v SR teraz, potesi kazde info. Vdaka
Tak si na routeru zapni IPv6 a vygeneruj ULA prefix. V tu ránu máš na hraní prefix /48 a ani k tomu nemusíš mít přístup do IPv6 sítě...
Btw, každý zařízení v IPv6 síti má několik IP adres a používání lokálního ULA prefixu se s normální adresou nijak nebije, může se používat obojí. Jenom přes ULA se pak nedostaneš ven.
Tem malym poskytovatelum je to jedno, protoze maji na vyber, budto implementuji IPv6, stravi x desitek hodin konfiguraci a dalsich x stovek hodin troubleshootingem nebo za par korun poridi lepsi zarizeni ktere zvladne vyssi rychlost. Co myslite, Petre, co takovy zakaznik maleho poskytovatele pripojeni oceni vice - vyssi rychlost nebo IPv6? Realita.
Jenže spoustu těch problémů s IPv6 si ty korporáty způsobili sami. Např. já jsem řešil, proč korporátní notebook nedostává IPv6 adresu a celé IT mi nebylo schopné říct, proč to tak je. Takže jsem je navedl jak to ve Windows registrech zapnout. Ale nikdo už netuší proč to někdo v minulosti takhle nastavil.
Navíc na to měli spoustu času a mohli to řešit postupně už minimálně 10-20 let měli mít u všeho požadavek na podporu IPv6 až HW tak SW.
jenze na ipv6 v korporatnim prostredi se nemuzete divat jako na isp problem. Ipv6 ma ve windows default prioritu, takze pokud vsechny prvky s ipv6 nepocitaji (acl na switch/router/fw, routing, proxy, ips/ids, detekce nechtene ipv6, detekce solicitated router, ...), je opravdu bezpecnejsi ipv6 zakazat.
Neni problem se po ipv4 overit pres 802.1x a soucasne nahodit i ipv6, vystupovat jako solicitated router a pres transparent ipv6 proxy a fake dns ohnout ipv6 provoz cele lokalni vlan pres vlastni zarizeni.
Udrzovat celou sit s acl, fw, ids/ips, qos etc. jako dual stack nedava zadny smysl, vede to nutne k problemum a chybam.
Takze uvnitr privatni ipv4, ven http/https proxy s podporou ipv6 na ext, do dmz reverz proxy s ipv6+ipv4 na ext a jen ipv4 dovnitr je sakra lepsi reseni - ale zadne ipv4 adresy to neuvolni.
U home useru bez verejne IP je prechod snazsi, pokud nemaj vlastni router nebo jsou ochotni kupovat a ucit se konfigurovat novy.
Ipv6 ma ve windows default prioritu, takze pokud vsechny prvky s ipv6 nepocitaji (acl na switch/router/fw, routing, proxy, ips/ids, detekce nechtene ipv6, detekce solicitated router, ...), je opravdu bezpecnejsi ipv6 zakazat.
Ta priorita se dá nastavit. Určitě je tam něco jako Happy Eyeballs. Takže opravdu není bezpečnější IPv6 zakazovat. To udělá jenom totální ignorant, který nechce nic řešit a jenom si usnadnit práci. Navíc prohlášení Microsoftu:
Internet Protocol version 6 (IPv6) is a mandatory part of Windows Vista and Windows Server 2008 and newer versions. We do not recommend that you disable IPv6 or its components. If you do, some Windows components may not function. We recommend using Prefer IPv4 over IPv6 in prefix policies instead of disabling IPV6.
Udrzovat celou sit s acl, fw, ids/ips, qos etc. jako dual stack nedava zadny smysl, vede to nutne k problemum a chybam.
Smysl to má minimálně v tom, že pak ta síť a lidi jsou na IPv6 připraveni. Když si to takhle řekne každý, tak jsme v pytli. Přesně to samé se říkalo i o HTTPS ve firmách.
Ještě jsem nenapsal, že se jednalo o německý (kde IPv6 dává smysl, protože je tam již kolem 65%) technologický korporát a řešil jsem to právě kvůli požadavku na IPv6.
Tak ono se to jeden cas doporucovalo jako "reseni" a jak to jednou nekdo treba do GPO nastavil, uz se na to nesahlo. U Windows tomu navic moc nepomahaly automaticky navazany tunely, co zajistovaly IPv6 konektivitu v IPv4-only siti a mohla to byt defacto i nechtena dira, nastesti tahle hloupost uz vysla v mezicase zaplatpanbu z mody.
Vodafone taky IPv6 v mobilní síti neumí. Alespoň u nás v krajském městě.
Sice na webu https://www.vodafone.cz/pece/internet-data/internet-v-pocitaci/internet-ipv6/ se píše cit.: „Váš telefon nebo tablet si stahuje síťové nastavení automaticky a zatím pro něj není nastavení pro IPv6 připravené - tento typ nastavení využívají zařízení od Applu, ale také Android zařízení. V tomto případě je potřeba počkat, k aktualizacím operátorských nastavení dochází několikrát ročně. Jakmile se vám stáhne nové nastavení, IPv6 budete mít dostupné.“
…takže čekám, zkouším to od 2021, 2x ročně stále s negativním výsledkem tj. IPV4 only.
Vodafone to bohužel nedotáhl do konce a neposlal do Androidu aktualizované profily pro svou síť. Telefony tedy drží v nastavení pouze IPv4 a nenaváží automaticky dualstackové spojení.
Je třeba zajít do nastavení týkající se mobilní sítě a tam přepnout APN na IPv4/IPv6 (dual-stack). Telefon naváže nové spojení se sítí a dostane obě adresy. Funguje to, vyzkoušeno mnohokrát.
Nikoliv, ze ho implicitne nezapinaji prece neznamena, ze ho neumi.
A u iPhone to je spis problem na strane samotneho Apple, ze to tak dlouho trva.
Jako člověk, co publikuje do AppStore tomu rozumím, vím, že něco Apple schvaluje na několik pokusů (já mám rekord 3), ale tohle pokud dobře počítám může být cca 6. pokus, takže někdo buď neumí/nechce číst, vedení to nechce (možně nechce/nemůže udělat nějaké změny u sebe), nebo se na odpovědné pozici v korporátu střídají lidé takovým způsobem, že si nepředávají informace.
V každém případě nevidím nikde chybu Apple. Pokud chcete do ekosystému Apple, musíte splnit jejich podmínky, můžete si o tom myslet co chcete, ale to je tak všechno, co s tím můžete udělat.
Spoustu věcí, co po programátorech Apple chce (a myslím to obecně, jak pro desktop tak pro mobilní vývoj) je sice pro ně vopruz, (někdy dost velký), ale ve výsledku je to plus pro běžného uživatele.
No kdyz mas novej tel tak se ti to vetisnou pri prvnim spusteni nacte s novym profilem kde je IPV4/6.
Pokud mas ten telefon dyl, tak tam je profil jen s IPV4 a musis mu rucne ric ze ma brat oba.
Zajamve u vodafonu je ze na strnakach kde ti riak jak si rucne profil natavit ( protoze uz nepoosila nastavovaci sms/mms) tak maj jen ipv4
Neni to tunel, ale normalni routing provozu. Jinak je to spravne, DNS jsou TM, IP adresy taktez, ze site CETINu je to routovane na endpointy TM.
Do optiky CETINu to taky jde (technicky je to stejne jako to DSL).
Optika TM (na vlastni infra) je ukoncena na jinych prvcich, ktere by IPv6 taky umely, ale muselo by se chtit...
Přesně. To se furt tlačilo 5G s tím, že může mít uživatel tisíce zařízení a ty si můžou povídat - a dají mu čtyřkový adresy. Dávaly se nový modemy, předělával firmware v zařízeních a - s IPv6 by to nefungovalo, takže nový HW se rozjel na 20 let zastaralým protokolu.
Hlavně že nabrečeli slaný jezero, jak to nikdo nechce... K proč, když nedokážou technicky splnit, co slibují?
trh to nevyřeší
Na tohle jsem už alergický. Proč většina techniků má sklony k socialistickému narativu? Trh vyřeší všechno... ne ideálně, ale vyřeší, rozhodně lépe než centrální plánování.
Já se ptám:
1. Opravdu to je potřeba už řešit nebo ještě ne? (Opravdu trh rozhodl, že to je třeba řešit?)
2. Vyplatí se přechod na IPv6? (Vyplatí ve smyslu, že někde je technologický dluh, který je samozřejmě špatně. Ten znemožňuje přechod.) => je cena a přínos pro zákazníka vyšší než nechat to "nějak" na IPv4?
Ti co tvrdí, že to je ready, tak vám doporučuji se probrat ze sna. Třeba Čínské telefony, které má nemálo lidí. Ty volbu na IPv6 ignorují a často si sáhnou na IPv4, i když jim to v nastavení APN přikážete.
Už vidím, jak zákazníci ochotně mění své zařízení a neviní z toho poskytovatele, protože do teď to šlo přece. Ba hůř, budou brečet u státu, že to má za ně zařídit a zregulovat.
No a pak to zaplatíme my všichni, zaplatí to i lidi, kterých se to vůbec netýká a třeba by to zařízení i změnili nebo IPv6 dávno umí.
A jak trh vyresi problem Obecni pastviny?
Jenoduše: Trh chrání zdroje před vyčerpáním cenotvorbou. Pokud je X nedostatek, pak roste cena Y. Čím je X méně, tak bude cena Y vyšší.
Takže zdroj není možné koupit a dále čerpat, protože to je moc drahé a vyplatí se to stále menšímu počtu účasntíků trhu. V jistý moment na daný zdroj nebude mít dost velké množství trhu, takže se vyplatí hledat jiný zdroj.
Doporučuji základy ekonomie.
Centrální varianta, která je zde jak koukám obecně podporována. "Vlasntíkovi budeme říkat, co se svými zdroji má dělat, případně mu je ukradneme a rozházíme je všem okolo, tak nějak bez roznyslu, ladu a skladu. Vyčerpáme je mnohem dřív než trh. Případně u toho spácháme monopol na daný zdroj a narušíme soutež na trhu, aby to pro všechny bylo mnohem mnohem dražší a nikdo neměl nic a mohla si to koupit jen 0,1% elita, kterou vlastně ještě víc posíláme a udělám oligarchy, co se sedí na gigantickém majetku"
A čemu to vadí, že si každý janko bude tahat do tomu drátek do každého domu? Pokud na to má, tak co? Ať to dělá. Mně to je jedno, nevidím důvod mu do toho kecat.
Mně taky nikdo nekecá do toho, jak si připojím internet do domu. Koupil jsem si modem na SIMku a hotovo. Nechci mít povině drátek, či nějaký limit SIMek.
Pokud to začne někde drhnout, začne růst cena a už si to každý janko nebude moci do každého domu natáhnout drátek. Proč? No, protože na to nebude mít prachy.
Já nechápu tady to myšlení, zakazovat, regulovat někomu něco dělat... ve svém domě s něčím, co si sám platí.
Jenze jsi zapomnel na pokrok, ktery snizuje naklady na cerpani zdroje.
Napriklad:
Zatimco v predminulem stoleti byl lov velryb rizikova zalezitost, s novymi prostredky se z toho stala rutina, ktera malem zpusobila vyhynuti nekterych druhu velryb, a to bylo zastaveno jen zasahem vetsiny vlad a ustanovenim moratoria. Takze reseni neprislo diky volneho trhu, ale zasahem shora. A to porad nevime, jestli to u nekterych druhu pomohlo, protoze napr. populace velryby cerne se nelepsi ani po cca 50 letech od moratoria.
Ne, opravdu nechci aby trh resil problem obecni pastviny. Doporucuji ucebnici ekonomie pro pokrocile.
Je mozne, ze pro IPv4 by to trh vyresil, ale proc volit suboptimalni reseni, kdyz se nabizi prechod urychlit. Proc by stat mel zbytecne dlouho pouzivat zastaraly protokol, kdyz se nabizi novy, na ktery by stejne i v tvem zpusobu reseni musel prejit?
Budu se opakovat... a nebaví mě to... fakt ne...
Jo k těm IPv4, mohli jsme zůstat pod SSSR... neměli bychom ten internet přece. Moskva by nám určila, co je pro nás dobré.
Všechny technologie, i to, proč tu fungujeme přišlo z USA. Takže já se omlouvám, že i v tomto preferuji tržní přístup k věci, protože ten z opačné konci barikády dopadl revolucí a totálním nasráním lidí.
Jo a vylovit skoro velryby mi připadne menší problém než tady zlikvidovat celý kontinent a ohrožovat všechny okolo bizarním konfliktem vojenským skrz třídní boj a nějaký rudý nesmysly.
Takže mě nechte prosím žít a neserte mě tu s těma regulacemi. Mám pocit, že někteří si bez státní pomoci snad nekoupí ani mlíko v obchodě. Potřebují mít zakázané "Ty nevhodné produkty".
Není můj problém, že si nepřečteš první můj příspěvek, kde stojí, mimochodem že pod ním komentuješ, že?:
"Já se ptám:
1. Opravdu to je potřeba už řešit nebo ještě ne? (Opravdu trh rozhodl, že to je třeba řešit?)
2. Vyplatí se přechod na IPv6? (Vyplatí ve smyslu, že někde je technologický dluh, který je samozřejmě špatně. Ten znemožňuje přechod.) => je cena a přínos pro zákazníka vyšší než nechat to "nějak" na IPv4?
Ti co tvrdí, že to je ready, tak vám doporučuji se probrat ze sna. Třeba Čínské telefony, které má nemálo lidí. Ty volbu na IPv6 ignorují a často si sáhnou na IPv4, i když jim to v nastavení APN přikážete.
Už vidím, jak zákazníci ochotně mění své zařízení a neviní z toho poskytovatele, protože do teď to šlo přece. Ba hůř, budou brečet u státu, že to má za ně zařídit a zregulovat.
No a pak to zaplatíme my všichni, zaplatí to i lidi, kterých se to vůbec netýká a třeba by to zařízení i změnili nebo IPv6 dávno umí."
Tvrdis ze se ptas, ale doopravdy prezentujes svuj jasny nazor, pricemz tvrdis ze vsechno vyresi trh. No a pritom jsi nedokazal ani vysvetlit, jak trh vyresi problem obecni pastviny...
Pokud nedokazes obhajit sve tvrzeni, ze trh vyresi vsechno, pak nema smysl resit tvou 'otazku' "Opravdu trh rozhodl, že to je třeba řešit?". Na otazku 2 najdes odpoved v clanku.
Nefunguje, ja bych se do takove debaty ani moc nechtel zapojovat, ale chtel bych rict jednu vec a to, ze trh na zacatku internet nevymyslel a nefinancoval. Samozrejme jakmile se proslapne cesta, tak uz to pak jde samo a trh (nebo spise par jedincu, co si uvedomi, ze je to docela fajn vec) si s tim uz poradi. Faktem je, ze trh si neporadil se zacatkem IPv4 a cast lidi si predstavuje, ze si poradi s prechodem na IPv6 :D
Otazkou samozrejme je, zda by se neprosadilo neco jineho, ale to uz je fakt na velmi slozitou diskusi.
Takze kdyz nekdo odkoupil byt za 40 tisic, tak to neni dotace? :-) A bavime se typove o bytu, co se ve stejnem miste i typu stavby v dnesni dobe prodava treba za tri miliony.
Ono spousta lidi takhle ten byt velmi levne koupilo a obratem prodalo. A s nemalym ziskem. Ze tomu vy formalne dotace nerikate fakticky neznamena, ze o dotaci fakticky neslo. A za tohle samozrejme nikdo sedet nesel ;-)
No korupce by to byla, kdyby lidi strkali neco bokem (tehdejsim) konselum. Coz se taky nedelo. Aneb proste z radhausu ta nabidka prisla - a casto v rezimu, ze bud se prodaji vsecky byty v dome - a kdyz ne, tak privatizace se nekona. Vedel bych i o pripadech, kdy presne takto nekdo z domu koupil i byt s nekym, kdo na ten kauf navzdory supervyhodne cene proste nemel... aneb stacilo mit v prodavanem dome souseda, co mel par kacek na knizce. Doba byla takova, ze se toho obce zbavovaly.... no a dnes se resi, zak nasobne vetsi peniz ten obecni bytovy fond obnovit :-)
Jeden tradiční problém zcela volného neregulovaného trhu "bez přívlastků" je ten, že se jen velmi obtížně vyrovnává s monopoly a v segmentech, kde existují přirozené vstupní bariéry (nebo je snadné vytvářet nepřirozené) naopak vzniku a stabilitě monopolů výrazně napomáhá.
Neefektivita a mnohdy až patologické chování v oblastech závisejících na omezených "volně dostupných" zdrojích už byly zmíněny.
Jo a proto patenty, regulacemi vytvoříme monopoly a nadnárodní korporace, co mají jev "Too big too fall".
Uděláme prostředí tak šílené, že pro novou a malou firmu je nemožné vstoupit na trh, protože nemá na to zaplatit byrokracii, regulace.
Mezitím pro velký korpo to je pár drobných. Takže naopak regulace umožňují korporacím nerušený a neřízený růst. Však je často levnější zaplatit pokutu než přijít o zákazníky.
Coz jsi nadherne popsal pripad operatoru, kmitoctu, ci problem prechodu z IPv4 na IPv6 :)
On je to i se lehkou regulaci (cenovou) docela problem prosadit. Vem si, ze kdybys zvysil rocni poplatek, tak zakonite klesne cena IP adresy - jeji vlastnictvi prinasi naklady a kdo ji opravdu nepotrebuje, ten se ji rad zbavi. Ale to zase oddali prechod na IPv4, protoze se adresy vrati.
Takhle to bude samozrejme fungovat do doby, nez to zacne byt tak drahe a vyplati se prejit na IPv6. V ten moment pujde cena IPv4 uplne do haje, ale myslim si, ze tohle je jeste docela daleko.
Pokud chces priklad, ve kterem nema prsty stat skrz dane atd., tak vlastne zadas priklad z doby prvotne pospolnych spolecnosti. Dane jsou stare jak civilizace sama...
Ale konkretne - proc sis neprecetl muj prispevek z 11:05, kde udavam priklad velryb temer vyhubenych volnym rybolovem, to me vrta hlavou.
Ježišmarja... ukažte mi, kde byl v 90. letech trh bez zásahu státního aparátu a byrokarcie.
Prosím vás... však v 90 letech půlka Evropy, včetně nás sotva tušila, že existuje kapitalismus, trh vůbec nechápala (Nechápe ani do teď, děkujeme SSSR a místní socialisti)
Do roku 2000 bych vůbec, ale vůbec o nějakém trhu nemluvil, ten tu neexistoval.
IPv4 je nightmare. Vyvijim firmware, ktery kdybych mohl udelat a provozovat na ipv6, nemusel bych resit vicemene nic. Maximalne tak updatnout DNS., abych vedel, kde ho najdu. Takhle musim resit NAT, lokalni adresy, VPN, platit server, ktery dela cloud. Proste bolehlav. Kdyz k tomu pripocitam HTTPS, je to tak na skok do propasti. Protoze i ten zatraceny HTTPS potrebuje klice, ktere se vygeneruji tak, ze musim vystavit protikod, ale nemuzu, protoze jsem za natem. Takze slozita konstrukce a reseni pres cloud. Pokud spadne cloud, prestane fungovat vsechno. S IPv6 bych se dostal primo na zarizeni, nebylo by tam kriticke misto.
Tohle je představa všech IPv6 fans ...
Pak jsou překvapeni, že každá IPv6 adres nemá plný přístup do Internet a Internet nemám plný přístup ke každé IPv6 adrese ... I na IPv6 se používají firewally.
Dodavatelé "technologií" jsou překvapeni, že jejich stroj nemá a nebude mít plný přístup do Internetu. A to je problém, protože jejich firmware s tím počítá, je to přeci IPv6 .
Nejvíc překvapeni jsou výrobci výrobních linek za Xx10milionů Kč .
Oni to vyžadují a nejlépe s plným přístupem z Internetu. A pak ten firmware 10 let neupdatují, nebo ještě lépe za 5 let firma skončí.
Buďte soudní, dělejte firmware tak, aby se dal provozovat za firewallem.
Fakt mne nebaví (ser***), povolovat pro "technologii splachování záchodu" celý MS Cloud, protože moula nenastaví CNAME v DNS, ale udělá na "cludu" HTTP redirekt na dynamickou adresu v Azure.
Nebo se snaží z cloud kontaktovat svoji jedinečnou "technologii", ale má za málo nastavit CNAME aby se dal povolit ten jeden momentálně aktuální cloud host.
Jo a umět jen LetsEncrypt HTTP challenge a ne DNS je taky super, LE nezveřejňuje odkud se na HTTP koukne, takže taky musíte povolit celý Internet na portu 80, což je přesně to co u super bezpečného, auditovaného, léty prověřeného, firmware na jedno použití fakt chcete.
11. 6. 2024, 12:43 editováno autorem komentáře
Já pozoruji přechody na straně menších firem, a je to dost bída. Skoro v polovině, kde se o to pokusili, se pokorně vrátili zpět a v další čtvrtině pořád řeší problémy. Asi hlavní příčinou je, že ipv6 je zabijákem výkonu protože hromada prvků, třeba hodně populární mikrotik, neumí s ipv6 offload a tak zjišťují, že mají místo 1Gbit najednou 250Mbit linku. Dalším důvodem je složitost. IPv4 zprovozní poučný amatér metodou plug&play. Kdežto na IPv6 je třeba PhD. nejen z toho důvodu, že často chybí nebo je špatné webové GUI počínaje routery a konfigurátory VM konče, a je třeba něco mastit v konzoli z pochybných webů vygooglenými postupy ale i proto, že to prostě celé je objektivně mnohem komplikovanější.
Naprosto přesně napsáno! Vůbec se nepoukazuje na skutečné problémy který IPv6 přináší a prezentují se jen pozitiva.
To je jak nekonečné téma O2, Mikrotik, IPv6 v naší zemičce.
O2 dává /64 a nic jiného neumí, Mikrotik filozoficky odmítá ND-proxy a výsledek je neřešitelný problém, respektive lze zakoupit jiné zařízení ale to každý běžný uživatel odmítne. Když si vezmu takovou firmu která do toho narvala statisíce, absolutně zavrhne novou investici do něčeho co funguje i když musí platit ranec.
Největší problém IPv6 je nulová zpětná nativní kompatibilita s IPv4 a Chybějící Plug & Play pro běžné uživatele.
(NAT64/DNS64 vůbec nezmiňujte, je to nefunkční pro Discord a Steam a tím nepoužitelné pro konzumenty)
Tohle vyřešte a IPv6 se bude nasazovat kde to jen půjde.
1) Když požádám 10 lidí, aby každý zatloukl hřebík, jeden ten hřebík ohne, druhý si místo zatlučení hřebíku rozklepe palec a zbytek to v pohodě zvládne, tak jsou špatný hřebíky?
2) Na přechod je dual stack, IPv4 pojede dál. Zapnout IPv6 neznamená zahodit IPv4.
3) Rozcházet? Nechápu. Pichnul jsem modem do routeru, ten dostal adresu gatewaye, DNS a svůj /56 prefix skrz DHCP PD. Vzal první prefix /64 (přidal dvě nuly) a přiřadil to LAN.Začal oznamovat svou adresu, DNS server a prefix zákazníkům pomocí RA a zbytek zařídil autokonfigurační mechanismus. A když zařízení chtělo, vyžádalo si adresu přes DHCPv6 z toho rozsahu. Z pohledu uživatele nevíš, že existuje nějaká IP adresa a prostě to jede. Jestli má někdo potřebu s ev tom vrtat a rozbít to, je to jenom jeho problém. A le jde to i bez toho.
Ze specifickeho problemu Mikrotiku nemuzete delat genericky problem. Hardwarovy offload v IPv6 zadny problem neni a spousta zarizeni to vyresene ma. Aneb ted argumentujete stylem "koupil jsem levnou krabici a divim se, ze funguje suboptimalne". Holt kdyz pouzivate hardware s chipsetem, kde se s IPv6 offloadem jaksi moc nepocitalo, tak to nemuzete hazet na vrub IPv6.
A s tim UI pravdu nemate. Dnes i reseni pro chude (ala OpenWrt) to vyresene maji a nemusite nad tim ani nijak slozite premyslet. Tp nastaveni zas tak tezke neni. Na IPv6 zadne PhD fakt potreba neni.
Jenže oni ty mikrotiky mají, fungují a 15 let fungovat budou a z plezíru je měnit nebudou. Ten problém se mimochodem s postupem času paradoxně zhoršuje protože 1GBit+ se stává normou.
V jednoduchých případech možná není PhD třeba. Stačí ale nějaká drobná komplikace nebo odchylka od běžné praxe a je problém. Třeba se zprovozněním IPv6 v Proxmoxových VM/LXC v SoYouStart/OVH hostingu selhávají i PhD. Vyzkoušeno. Návod proxmoxu https://pve.proxmox.com/wiki/OVH#IPv6 v OVH prostředí nefunguje a návod OVH zase nepočítá s proxmoxem https://help.ovhcloud.com/csm/en-dedicated-servers-network-ipv6?id=kb_article_view&sysparm_article=KB0043765
Srovnej s IPv4, které je na 3 kliknutí.
11. 6. 2024, 11:57 editováno autorem komentáře
OVH má nevhodnou implementaci IPv6 už možná 15 let, od doby, co jsem je zkoušel poprvé. Jejich prefixy jsou "on-link", což je pro virtualizaci (pro kterou se váš hostitelský server stává routerem) naprosto nevhodné. Aby virtualizace fungovala dobře, potřebujete "routovaný" prefix, což umí třeba Hetzner.
V "Cloudu" zase OVH přiřazuje jednu IPv6 adresu (!), takže třeba nativní IPv6 v dockeru nerozjedete (s výjimkou připojení kontejneru do "host" namespace).
OVH je ukázkou toho, jak se to dělat nemá.
Když ono přechod na IPv6 je podle toho co jsem vypozoroval hlavně problém na straně malých poskytovatelů a jejich koncových zákazníků. Na IPv4 prostě zapojíte "router" a vše funguje. Technicky se jedná o situaci, kdy "router" ve výchozím stavu si na WAN straně vezme IPv4 adresu z DHCP, má nastavený NAT a na vnitřním portu má DHCP server + DNS server pro přeposílání dotazů. Náklady na instalaci skoro nic. Jenže bohužel takhle daleko nejsme u IPv6, minimálně u zařízení které jsem takhle viděl. Ve všech případech byla nutná manuální konfigurace routingu, manuální konfigurace DHCPv6, Neighbor Discovery a tak dále. Takže hlavně malí operátoři mají právě s tímhle nemalé náklady. Problém proto podle mého názoru není u velkých zákazníků, kteří mají své techniky, nebo mobilních, kde prakticky každý Android a iOS umí IPv6 autokonfiguraci, ale právě koncové domácnosti, kde výše popsané "plug and play IPv6" je prostě nezbytnost a hodně chybí.
Hlavně vemte také v úvahu "vesnice", kde většinou velcí operátoři nejsou nebo mají "nesmyslné" ceny a malí "wifináři" pro změnu nemají jak pokrýt náklady na migraci koncových uživatelů na IPv6, a to jak náklady finanční tak i lidské, Fanda Vomáčka je prostě sám na 15 okolních vesniček.
mám /48 od HE přes tunel. Není to ideální řešení, ale funkční
Jenže to je peklo, protože veškerá blbě naprogramovaná geolokace vás pak identifikuje v lepším případě v USA (Seznam...) nebo v Německu (Disney+...), případně čert-ví-kde. Kdejaká služba se obává, že buď nejste v ČR, nebo používáte VPN kvůli obcházení geolokace, takže vás vykopne...
(Podobně hloupě se IPv6 chová i v případě, pokud například máte nadnárodního providera, který vám přidělí adresu ze svého IPv6 rozsahu pro Evropu, registrovaného v Nizozemsku...)
Pokud neumí splnit požadavky legislativy, tak ať jdou podnikat v něčem jiným.
https://eur-lex.europa.eu/legal-content/CS/ALL/?uri=celex:32015R2120
Článek 4: Služba přístupu k internetu poskytuje přístup k internetu a v zásadě ke všem jeho koncovým bodům, bez ohledu na technologii sítě a koncové zařízení, které koncoví uživatelé používají. Avšak z důvodů, které poskytovatelé služeb přístupu k internetu nemohou ovlivnit, mohou být některé koncové body internetu někdy nepřístupné. Mělo by se proto vycházet z toho, že poskytovatelé svou povinnost související s poskytováním služby přístupu k internetu ve smyslu tohoto nařízení splnili, pokud tato služba poskytuje spojení prakticky se všemi koncovými body internetu. Poskytovatelé služeb přístupu k internetu by tedy neměli omezovat možnost spojení s žádným přístupným koncovým bodem internetu.
Nevím jak vy, ale já jsem to pochopil tak, že pokud používám na svým koncovým bodu (třeba Malině v garáži) Ethernet + IPv6, což jsou standardní technologie, má ISP zajistit, abych se k tomu dostal.
Avšak z důvodů, které poskytovatelé služeb přístupu k internetu nemohou ovlivnit, mohou být některé koncové body internetu někdy nepřístupné. - tohle je typicky nedostatek IPv4 adres a koncový bod za NATem, výpadek nebo firewall. Ale to neznamená, že když nezávisle na IPv4 koncový bod používá IPv6, není blokovaný a je online, má zůstat nedostupný.
Že se koncák rozhodne nepoužívat IPv6 a vypne si to, je jeho problém. Ale ISPík mu nesmí bránit v tom, aby si zapnul funkční IPv6.
Článek 8: Při poskytování služeb přístupu k internetu by měli poskytovatelé těchto služeb nakládat s veškerým provozem stejně, bez diskriminace, omezení či narušování, nezávisle na odesílateli, příjemci, obsahu, aplikaci, službě nebo koncovém zařízení. V souladu s obecnými zásadami práva Unie a ustálenou judikaturou by s provozem ve srovnatelných situacích nemělo být nakládáno rozdílně a s provozem v rozdílných situacích by nemělo být nakládáno stejně, s výjimkou případů, kdy je takové nakládání objektivně odůvodněno.
Jak chcete objektivně odůvodnit, že mám VPSku s nějakým serverem, kde zapnu IPv4 i IPv6 a se stejným provozem nakládá ISPík jinak (jedno z nich neprojde) jenom proto, že je tam jiný transportní protokol, který je navíc už víc jak 20 let starý?
Článek 11: Jakékoli postupy řízení provozu jdoucí nad rámec takovýchto opatření přiměřeného řízení provozu tím, že blokují, zpomalují, mění, omezují, ruší, zhoršují či diskriminují konkrétní obsah, aplikace nebo služby či konkrétní kategorie obsahu, aplikací nebo služeb, by měly být zakázány s výhradou odůvodněných a přesně vymezených výjimek stanovených v tomto nařízení. Tyto výjimky by měly být vykládány restriktivně a měly by se na ně vztahovat požadavky proporcionality. Konkrétní obsah, aplikace a služby, jakož i jejich konkrétní kategorie, by měly být chráněny, protože jejich blokování či jiná omezující opatření, která nespadají pod odůvodněné výjimky, by měla nepříznivý dopad na možnost volby pro koncové uživatele a možné inovace. Pravidla zakazující měnit obsah, aplikace nebo služby se vztahují na změnu obsahu sdělení, nezakazují však nediskriminační techniky datové komprese, které zmenšují velikost datového souboru bez jakékoli změny obsahu. Tato komprese umožňuje účinnější využívání nedostatkových zdrojů a slouží zájmu koncových uživatelů snižováním objemu dat, zvyšováním rychlosti a zlepšováním zkušeností s využíváním dotčeného obsahu, aplikací nebo služeb.
Takže má povinnost se postarat,, aby se zákazník dostal k online službám. Když se objeví nová služba s IPv6, zákazník se k ní nedostane...
Mám pokračovat?
12. 6. 2024, 19:44 editováno autorem komentáře
V kazdom tom clanku tam mas podmienovaci sposob. Checkol by som, ci neexistuju nejake vykonavacie predpisy pre to alebo ine pravne upravy, ktore to spresnuju.
Ti nasi/vasi ISP predpokaldam, ze maj pravne oddelenie a nieco take by neostalo bez povsimnutia ak by to bolo tak ako si to ty vykladas.
Zacni podnikat a ukaz vsetkym ISP ako sa to ma robit. Rad sa na to pozriem :)
Přesně jak tu shrnuli jiní.. . Velcí hráči mají problémy to nasadit správně (TM CZ vůbec, VDFN něco a 02 blbě - malý rozsah a omezený počet spojení atd...).
Pro malé je to moc komplikované a drahé.
BGP protokol ale umí oznamovat stejné IP v různých sítí a tudy by mohla vésti cesta. Číslo portu u IP protokolu také ztratilo svůj význam, když dneska skoro vše běží na https. Dřív bylo pěkné poznat jestli se tahá soubor přes FTP nebo volá přes VoIP nebo sleduje video nebo web. Asi daleko lepší by byla nějaká hlavička v https která by určovala prioritu, protože dost často se stává že musíte mít linku značně předimenzovannou kvůli neefektivnímu určení priorit.
Problem IPv6 je, ze neprinasi zadny prakticky uzitek.
Svet se naucil fungovat na kombinaci verejnych a neverejnych adres.
A ze kazde zarizeni potrebuje verejnou adresu? Asi ne cece.. protoze prvni vec co by jste meli udelat, je filtrovat veskerou komunikaci a povolit jenom to, co explicitne potrebujete. To se udela tak nejak automaticky, kdyz jedete v rezimu neverejne site za NATem.
Plus zpusob fungovani tech domacich udelatek - se to beztak pripojuje do cloudu vyrobce, a nemusi to mit ani z principu verejnou adresu.
Takze za me - trh to uz davno vyresil. Trh si jednoduse vystaci s IPv4.
To je ale jen pohled koncové sítě. Tam to tak skutečně je, uživatelé toho obvykle moc nepotřebují.
Problém chybějících adres je ale na druhé straně, u poskytovatelů služeb a infrastruktury. Když dnes budete chtít rozjet novou obsahovou službu, datacentrum, virtualizační platformu, poskytovatele připojení a cokoliv podobného, budou vám chybět adresy. Nestačí napsat na „úřad“ a dostat příděl. Ty adresy prostě nejsou.
Tyhle služby to mají dnes z velké části vyřešené a šestku bez problémů umí a používají. Ale pořád potřebují provozovat na veřejné části infrastruktury i IPv4, protože podpora pro IPv6 chybí u poloviny koncových sítí. Ty jsou teď na řadě, aby mohl internet přejít na delší adresy.
Tak měli tlačit na řešení, které problém řeší při minimální režii pro ty, kdo to celé platí (zákazníky). Kolik lidí si domů kupovalo Itania a výrobci software museli řešit, že běžný koncový uživatel má k dispozici max. 3-4 GB RAM. A kdyby nepřišlo AMD, tak by to možná řešili doteď.
12. 6. 2024, 14:13 editováno autorem komentáře
Spíše jste si nevšimnul omezeních, které máte pokud používáte pouze IPv4.
NAT byl vymyšlen pro zcela jiné účely než je dnes používaný. NAT není firewall a nejedná se tedy o filtrování provozu.
V neposlední řadě, důvod proč všechny udělátka se připojují někam do cloudu výrobce je právě obezlička, která souvisí s obrovským používáním NATu.
Trh si nevystačí s IPv4. Naopak trh je značně brzděn právě širší implementací IPv6. Nedostatek adres platíte ve značně vyšší ceně služeb, které na intenetu používáte. Cena IP adresy jen za posledních 10 let stoupla ze 6usd na 60usd a s nedostatkem bude stoupat.
Az budou vyrobci produkovat zarizeni, ktere nebudou mit bezpecnostni diry, tak muzeme uvazovat o jejich umisteni na verejnou adresu.
Zatim ale vsechno funguje lepe a bezpecneji, kdyz je schovano za NATem.
Se podivejte na par prukaku za posledni dobu.. botnety na kamerach, routrech, vysavacich.. no mame to zapotrebi? A vy by jste jeste chtel uzakonit ze vse ma byt na verejne adrese.. no potes. To opravdu neprinese zadny uzitek.
Ad cloudy: primarni ucel je evidence/parovani. Uz vidim jak si nejaky lojza z horni-dolni spravuje svoje soukromy DNS, aby tam zanesl veskere IoT ktere vlastni a mohl je z dovolene na druhem konci sveta ovladat. A pokud ne DNS, tak opisuje IPV6 adresy? A ktere prosim? Protoze zas z pohledu bezpecnosti, veci nemaji pevne pridelene adresy.
Cela ta situace je velice trapna, a nasazovani/vynucovani novych technologii jde proti zdravemu rozumu a realnym potrebam provozu / trhu.
To jste takovej Cimrman..
Autor tak vlastně zastává názor, který zároveň vyvrací.
Na jednu stranu tvrdite, jak NAT je zlo a ze vas omezuje, a na druhou stranu pak tvrdite, ze vlastne NAT neni zadnej problem a vse je skrze nej mozne.
Tak si uz sakra vyberte :)
ad Slipstreaming - vyzaduje spolupraci uzivatele (ne, vysavac vam sam od sebe neklikne na phishing stranku), a vyzaduje router ktery dela co nema (snooping nad wtf protokoly jako irc/sip - nic takoveho bezny user uz neprovozuje). Pokud mate ruzne podsite pro IoT a domaci pocitace, tak se utocnik dostane pouze do te domaci site - ale ne na ty iot hracky. Za me to neni zadna slabina, protoze vyzaduje spolupraci uzivatele, ktery si vlastne spousti plevel ve sve siti. To si rovnou muze pustit jakehokoliv vira/malware a bude kompromitovan, NAT, ne NAT.
Spolupracovat nemusi nutne jen uzivatel. Tim "wtf" protokolem je jen tak mimochodem treba i FTP, ktery bez conntrack helperu taky nefunguje jak ma. A treba i PPTP stale pouzivane u nekterych socka-VPN-reseni. A zrovna i ten SIP je vec, co bezny uzivatel casto provozuje. Nebo chcete popirat existenci IP telefonie? ;-)
Ach jo, zase jeden, co neví o počítačové síti nic víc, než že propojuje zařízení...
- NAT není bezpečnostní funkce. Nikdy nebyl a nikdy nebude.
- NAT je komplikace jak z pohledu techniky, tak z pohledu legislativy.
- Pokud se útočník v lokální síti, tak na IPv4 prosknuje těch 255 adres za zlomek sekundy, 2^64 nezvládne tak rychle. mDNS a podobný mechanismy vyjdou v obojím nastejno.
- Pokud oddělím sítě a útočník se do jedné z nich dostane, vidí i do těch, co to mají povoleno na firewallu. Bez ohledu na to, jestli po IPv4 nebo IPv6
- IPv4 nemá privacy extension.
Nevhodne prirovnani.
Kdyz uz mate analogii ke vchodum:
NAT je jako koule na dverich z jedne strany - zevnitr ven cokoliv, z vnejska dovnitr nic. Leda ze velice okate chytnete okamzik pootevrenych dveri v momente co majitel opousti byt.
A prece je takova jednostranna koule rozsirena jako NAT.. "v kazde rodine". A dokonce to spada mezi bezpecnostni prvky, ne mezi pridane benefity a luxus.
Nevhodne prirovnani.
V čem?
NAT je jako koule na dverich z jedne strany - zevnitr ven cokoliv, z vnejska dovnitr nic.
Jenže takhle právě NAT nefunguje.
A dokonce to spada mezi bezpecnostni prvky, ne mezi pridane benefity a luxus.
NAT nespadá mezi bezpečnostní prvky. Není to benefit nebo luxus, je to naopak zhoršení služby.
mate to tam napsane, staci cist a porozumet textu
Ne, tam není napsáno, v čem je to přirovnání nevhodné. Je tam napsáno jiné přirovnání.
ale ano, takhle klasicky NAT funguje (hovorove NAT, zde tedy SNAT, ne jinou variantu)
Ne, NAT ani SNAT nezabraňuje komunikaci z venku. Komplikuje ji oprávněnému uživateli, ale nezabraňuje jí.
kdyby jste opet neignoroval kontext, tak zjistite ze dana pasaz se tyka koule, ne NATu
Kdybyste si to po sobě přečetl, zjistil byste, že se to dá interpretovat obojím způsobem. A interpretovat to tak, že se to týká koule na dveřích a ne NATu nedává smysl, protože řeč je o NATu, koule sloužila jen jako (nevhodné) přirovnání. Nedává smysl tu básnit o vlastnostech koule, které nejsou podstatné pro to přirovnání.
Takže je to vhodné přirovnání, protože přesně ilustruje ten problém NATu, který vy nechápete. Nicméně nepochopil jste ho ani z toho přirovnání.
Ovšem pokud je nad vaše možnosti chápání to, že nějaká věc může komplikovat řádné užívání, ale zároveň nebrání nekalému užití, pak je to na pováženou. Ale můžu zkusit ještě pár příkladů, třeba se chytnete.
Třeba časový zámek s potvrzením zadání správného kódu na přenosné pokladně. Zadáte PIN a budete muset čekat – to je pro vás komplikace. Lupič vás donutí zadat PIN a s pokladnou uteče – to, že po útěku bude muset ještě chvíli počkat, než se do pokladny dostane, mu asi moc vadit nebude.
Nebo kompletní vyprázdnění nádrže auta při parkování. Pro vás bude komplikace, když při každém zaparkování auta vyprázdníte jeho nádrž, aby s ní m nikdo nemohl odjet. Bude pro vás komplikace i to, že když budete chtít někam jet, budete muset nádrž zase naplnit. Ovšem když zloděj přijede s přepravníkem, na který auto jednoduše naloží, prázdná nádrž mu vůbec vadit nebude – až auto odveze, klidně tu nádrž naplní.
Tak co, už chápete, že pokud něco komplikuje život právoplatnému uživateli, nemusí to nutně být nepřekonatelnou překážkou pro padoucha?
Melete hromadu nesouvisejicich nesmyslu, ale doposud jste zde vy a ani nikdo jiny neukazal:
1/ jak se SNAT da univerzalne prekonat z venku a adresovat sluzby na strojich ve vnitrni siti
2/ jak to omezuje bezneho uzivatele, ktery ma potrebu se pripojovat na uzly ve vnejsi siti
3/ vetsi nebo stejnou miru napadeni stroju za NATem vuci strojum ktere jsou dostupne primo, utocnikem na verejne siti (tj. zda NAT prispiva nebo neprispiva k bezpecnosti, resp. jeho souhrny efekt v otazce zabezpeceni)
jak se SNAT da univerzalne prekonat z venku a adresovat sluzby na strojich ve vnitrni siti
Úplně jednoduše pošlete na vnější rozhraní routeru paket s cílovou adresou ve vnitřní síti. Router ho normálně na základě routovací tabulky pošle do vnitřní sítě. NAT mu v tom nijak nezabrání. C.B.D.
jak to omezuje bezneho uzivatele, ktery ma potrebu se pripojovat na uzly ve vnejsi siti
Běžný uživatel má i potřebu připojovat se z venku do vnitřní sítě. Akorát to obvykle řeší různými cloudy. Při připojování na uzly ve vnější síti ho to omezuje například tak, že ty uzly často dělají různé kontroly na zdrojové IP adresy. Pokud třeba někdo škodí cílovému uzlu, zablokuje cílový uzel komunikaci s touto IP adresou, a tím i všechny, kteří jsou za ní schovaní na NATu. Nebo třeba různé hry omezují počet přístupů z jedné IP adresy.
vetsi nebo stejnou miru napadeni stroju za NATem vuci strojum ktere jsou dostupne primo, utocnikem na verejne siti (tj. zda NAT prispiva nebo neprispiva k bezpecnosti, resp. jeho souhrny efekt v otazce zabezpeceni)
Tohle je ovšem chybné vyvozování. NAT nemusí být příčina, může to být důsledek nějaké jiné společné příčiny.
Jako s tím turniketem na vstupu do bytu. Počet vyloupení bytu může být nižší, než když jste předtím bydlel v rodinném domě, kdy byly normální dveře. Ale nezpůsobí to ten turniket, nýbrž vchodové dveře do celého bytového domu, které zabrání tomu, aby se zloděj dostal do domu. Takže se nedostane ani před váš turniket. Akorát v takovém případě při zabezpečení svého bytu spoléháte na to, že máte poctivé sousedy, že do baráku nepouští cizí lidi, že neztrácejí klíče, že správce domu nedává klíč od domu každému, koho potká.
Proto je ten příměr s turniketem místo dveří do bytu vhodný. Protože ukazuje, že vám to život zkomplikuje, útočníka to nezastaví, a pokud se k vám zloděj nedostal, není to zásluha toho turniketu, ale toho, že se o vaši bezpečnost starají všichni okolo vás.
@RDa: S NATem jako bezpečnostní funkcí to nemyslíš vážně, že?
Definujeme si to takhle:
- Bezpečnostní funkce je taková, která:
1) zastaví útočníka (jinak nemá co do činění s bezpečností), a
2) nezabrání legitimnímu využití služby uživatelem (protože to by vypnutí byla ideální bezpečnostní funkce).
- Uživatel je osoba, která chce zařízení využít k jeho účelu a je k tomu oprávněna.
- Útočník je osoba, která má přístup k vnější síti, může odchytávat a posílat pakety a má zájem jakkoliv škodit.
- Protože NAT ovlivňuje průchod paketů v síti, berme oba případy, zdařené užití i zdařený útok doručení paketu s žádostí o navázání TCP spojení na zařízení ve vnitřní síti. Nebudeme uvažovat firewall atd.
Use case 1
Pepa je majitel domku. Udělal si domácí automatizaci, která mj. ovládá topení. Jede na dva týdny lyžovat, tak stáhne na ty dva týdny topení na 10°C. Druhý den si zlomí ruku a jede domů dřív. Protože je automatizace napojená na Ethernet, chce se připojit cestou domů z mobilu a zvednout teplotu dřív, aby nedojel do vymrzlýho baráku.
Nemůže, NAT mu nedovolí navázat spojení s PLC. Pakety končí na NATu, ale ten neví, kam je poslat dál.
V tomto případě jde o legtimní užití - nastavení topení v bytě jeho vlastníkem a obyvatelem. Nebylo umožněno, tj. v tomto bodě NAT nesplnil definici bezpečnostní funkce v bodě 2.
Tohle je Jirsákovo stěhování ledničky skrz turniket.
Use case 2
S Pepou má Lojza nevyřízený účty a ví, že po loňským úraze na lyžích si platí VPSku a jeho domácí automatizace na ni udržuje TCP spojení, kdyby něco. A že znovu odjel na lyže. Chce mu odstavit topení úplně, ať mu zamrznou a popraskají trubky.
Má přístup k lince. Odposlechne IP adresu a port VPSky.
Alternativa 1: V tu chvíli je NAT otevřený pro IP adresu a por VPSky kvůli doručování odpovědí. Pošle SYN paket s IP adresou a portem jeho VPSky, ten projde otevřeným oknem na NATu rovnou na zařízení.
Alternativa 2: Pošle jménem VPSky FIN paket. Spojení se přeruší, automatizace se ho pokusí navázat znovu. Vydává se za VPS a na jeho SYN odpoví ACK. ACK paket projde NATem na zařízení.
Bad boy won. Útočník nebyl zastaven, nebyla splněna ani první podmínka pro bezpečnostní funkci, a to rovnou dvěma různými způsoby.
Tohle je Jirsákův zloděj, co přelezl turniket.
Porovnání s IPv6 bez NATu
Pepa zná IP adresu a přihlašovací údaje k PLC, to je vidět zvenčí, nastaví, co potřebuje.
Lojza nemá spojení, který by shodil, protože PLC je jenom na přjmu a nekomunikuje. Nemá co shodit s tím, že se to k němu připojí. Proskenovat 2^72 adres (prefix /56) během Pepovy dovolené nestihl.
Bez NATu se kupodivu povedlo legitimní užití, ale útočník pohořel. Takže definici bezpečnostní funkce splňuje IPv6, ne NAT. Jak že to říkal ten beránek v bajce? To máš, vlku, bl-béééééé
15. 6. 2024, 23:20 editováno autorem komentáře
Use case 1:
Pepa vi ze ma doma NAT a provede DNAT konfiguraci na ovladaci port PLC. Pokud je trocha chytrejsi, provede to v dynamicke variante s povolenim na port knocking. Pokud ho zajima bezpecnost, sve PLC ovlada skrze VPN, treba na bazi WG. Problem vyresen bezpecne.
Use case 2:
Pokud ma Lojza pristup k lince, tak jste kompromitovan nezavisle na nasazene halde technologii, proste jste MITM = boss. Neni to relevantni k NAT ani IPv4 - vidi prece pakety na jeho lince. Problem neni resitelny zadnym zpusobem.
Takze jste stejny neschopa a demagog jako Filipek. Gratuluji.
Bohuzel ani jeden priklad neni prikladem, jak se nekdo cizi z internetu dostane do vasi LAN za NATem. Proste to nejde, uz to pochopte. Reseni je to dostatecne bezpecne (opakuji znova statisticky dukaz: vzdalene nabourane stroje nejsou nikdy ty, ktere jsou v privatnim adresnim prostoru za NAT, ale kompromituji se verejne dostupne stroje).
Vsichni si pouze vymyslite dalsi, casto tezko splnitelne, podminky - jako ze potrebujete mit pristup na linku.. nebo posilat falesne pakety na rozhrani - coz znova vyzaduje byt v segmentu nadrazene site, jinak vam takovy paket zahodi prvni router.
Takze ne - zatim nikdo nedokazal onu magickou schopnost demonstrovat, ze takova SNAT mu nedela potize. A proto jste neschopove, oba dva. A to neni zesmesnovani - pouze konstatovani faktu, ze nedokazete prezentovat aplikovatelny vektor utoku.
RDa: No tak si to probereme postupně. Co se stane, když na vnější rozhraní vašeho routeru s NATem (kde nebude žádný firewall), dorazí paket s adresou z vaší vnitřní sítě? BUde směrován do vaší vnitřní sítě na zařízení, které má IP adresu uvedenou v tom paketu. Pokud to nevíte, dostudujte si to.
Vy určitě budete namítat, jak by se tam ten paket dostal. No jednoduše, ze sítě, ve které je to vnější rozhraní routeru. V té budou zařízení vašeho ISP, možná také zařízení dalších klientů vašeho ISP. Že vám tam ISP určitě nebude posílat žádný škodlivý provoz? Že ISP odděluje vaše zařízení od zařízení ostatních klientů? Jak to víte? Jste si tím jistý? Dokážete si to zkontrolovat? Zjistíte, pokud dojde ke změně? V každém případě to, co by vás chránilo, by byl firewall ISP, ne váš NAT.
Proto jsem NAT přirovnával k turniketu místo dveří do bytu v bytovém domě. Tam by vás také chránil nikoli ten turniket, ale zámek na vstupních dveřích do domu – a to, že byste měl slušné sousedy.
Další podmínky si tu vymýšlíte vy. Třeba to, že útočník musí být někdo cizí z internetu, pod čímž si představujete někoho hodně daleko. Jenže takhle se bezpečnost neřeší. Ochrana sítě musí fungovat i tehdy, když je útočník hned vedle, v síti ISP, v zařízení nějakého klienta, se kterým sdílíte segment sítě ISP apod.
Jediný, kdo je v této diskusi demagog, jste vy. Tváříte se, že útočník musí být někde daleko. Polemizujete s tvrzením, že SNAT nedělá útočníkovi potíže – jenže nic takového nikdo netvrdil. Bylo řečeno, že SNAT není dostatečná ochrana. Jako s tím turniketem – i ten by zloději dělal potíže, ale zloděje by nejspíš nezastavil.
Takže, speciálně pro superneschopu a demagoga, aplikovatelný vektor útoku: útočník ovládá zařízení vašeho souseda, který je klientem stejného ISP, jeho router je na stejném segmentu sítě ISP, jako váš router, a ISP nefiltruje komunikaci v rámci daného segmentu sítě.
Pokud byste se zase chtěl vymlouvat, že je to speciální případ – za prvé, bezpečnost se řeší i kvůli speciálním případům. Zámek do bytu si také nedáváte kvůli lidem, kteří vás nechtějí vykrást, ale kvůli těm, kteří vás chtějí vykrást a dostali se do baráku. Za druhé, pokud byste chtěl argumentovat tím, že ISP ale filtruje provoz mezi zařízeními v jednom segmentu sítě – pak by ale tu ochranu zajišťoval ten firewall ISP a ne váš NAT. Což poznáte například podle toho, že když tam firewall ISP bude, útok bude neúspěšný; když tam nebude, útok bude úspěšný. Za to přítomnost či nepřítomnost NATu na vašem routeru nebude mít na úspěšnost útoku žádný vliv.
Samozřejmě existují i možnosti, jak se dostat skrze NAT na dálku. Tam záleží na konkrétním způsobu fungování NATu, často může pomoci, pokud se kanál v NATu otevře zevnitř. Pokud byste měl pocit, že k tomu musí útočník už ovládat nějaké zařízení v interní síti, pak máte špatný pocit – může stačit třeba vmanipulovat uživatele, aby navštívil nějakou webovou stránku, a ten kanál v NATu otevře uživatelův webový prohlížeč.
opakuji znova statisticky dukaz: vzdalene nabourane stroje nejsou nikdy ty, ktere jsou v privatnim adresnim prostoru za NAT, ale kompromituji se verejne dostupne stroje
To není žádný důkaz. Za prvé to není pravda, samozřejmě je nabouraná spousta zařízení, která jsou za NATem. Za druhé už jsem vám vysvětloval, že i kdyby to byla statisticky prokázaná věc, nepoznáte z toho, zda jde o kauzalitu nebo korelaci.
Takže se přestaňte ztrapňovat pokusy o zesměšňování oponentů a začněte vnímat fakta. Je potřeba začít od toho, co je bezpečnost, a jak fungují sítě.
Proč NAT přirovnávat k turniketu? Není to spíše jako telefonní ústředna, která jednu veřejnou telefonní linku rozděluje mezi spoustu interních linek v závodě? Nebo vrátnice, která umožňuje jeden vchod - jednu adresu či dokonce jedno PSČ užívat mnoha lidem s jejich byty či kancelářemi?
I tou vrátnicí nebo ústřednou lze projít zvenku dovnitř, podle toho, jaký bude vrátný či spojovatel a jakou bezpečnostní politiku budou uplatňovat. Zároveň lze v případě potřeby zavést striktní pravidla, třeba že každý příchozí balíček vrátný zrentgenuje a zkontroluje detektorem na výbušniny...
Proč NAT přirovnávat k turniketu?
Protože to byl příklad něčeho, co oprávněnému uživateli komplikuje život (přes turniket budete do bytu nebo z bytu těžko stěhovat lednici nebo gauč), ale útočníkovi to nebrání v útoku (zloděj přes turniket z bytu vynese spoustu věcí, případně se nebude rozpakovat turniket zničit nebo demontovat, pokud mu bude překážet.
I tou vrátnicí nebo ústřednou lze projít zvenku dovnitř, podle toho, jaký bude vrátný či spojovatel a jakou bezpečnostní politiku budou uplatňovat. Zároveň lze v případě potřeby zavést striktní pravidla, třeba že každý příchozí balíček vrátný zrentgenuje a zkontroluje detektorem na výbušniny...
Jenže NAT právě žádnou bezpečnostní politiku neuplatňuje. To se tu celou dobu snažíme vysvětlit. Bezpečnostní politiku případně uplatňuje firewall.
"Jenže NAT právě žádnou bezpečnostní politiku neuplatňuje."
Vrátnice nebo ústředna také ne. Základní funkcí je sdílení vstupního místa pro několik uživatelů. Některými vrátnicemi může projít každý a pošta s bombou může být doručena až k danému uživateli. Některé ústředny hovor zvenku nepřepojí, jiné ho přepojí po doplnění upřesňující informace, možná i na základě předchozí informace, že linka 123 předtím volala do servisu. Sama vrátnice nebo ústředna není zárukou bezpečí, nanejvýš komplikuje život průchozím ale třeba i spammerům, kteří nevědí ke komu jdou nebo koho chtějí spojit, tak jejich žádost zůstane na vrátnici nebo v ústředně.
Turniket je ale něco jiného, ten nějakým způsobem kontroluje (třeba jen počítá) průchod z jednoho místa do druhého místa, není to křižovatka nebo rozcestník. Turniket může být klidně masivní odolná klec, která nepustí nikoho, kdo nesplní kritérium. Turniket je dimenzovaný na nějakou velikost, pokud se jím mají stěhovat ledničky, musí na to být uzpůsoben.
- Ústředna má nějakou klapku, kterou můžeš použít ve veřejné síti a spojí tě s konkrétním člověkem. NAT sám o sobě takovou možnost nemá - má jenom jedno veřejný číslo, nedovoluje přidat další číslice a s volajícím se nebaví.
- Vrátnice, no budiž. Ale taková, která nemá povědomí o tom, kdo za ní pracuje a nedovoluje ty zaměstnance kontaktovat. Takže ten musí co pět minut proběhnout ven na smluvený místo a podívat se, jestli za ním někdo nedošel.
- NATem tě může protáhnout jenom ten, kdo je uvnitř. To není o nastavení pravidel, to je fakt. Obcházení (maškaráda) je vyhnutí se té vrátnici skrz díru v plotě, kterou si ten zaměstnanec udělá na vlastní pěst a řekne o ní návštěvě. Když ji někdo nepovolaný objeví, proklouzne dovnitř a ta slavná vrátnice o tom vůbec neví.
- Rentgenování balíčků není NAT, rentgenování balíčků je firewall. To je úplně jiná funkcionalita. Nezávislá na NATu.
Tož proto...
to, ze si niekto otvori port a je pristupny zvonku je pochopitelne pripad, ze to za NATom nie je
Ehm. Útok v tom případě šel na venkovní adresu NATu, NAT to propustil do vnitřní sítě a změnil těm paketům útočníka IP adresu ze svojí na jeho vnitřní. Takže nějak nechápu, proč tvrdíš, že to za NATem nebylo, když mezi útočníkem a tou napadenou věcí byl NAT a v tom trafficu se vrtal. Že v něm je otevřený okno je jeho normální funkcionalita, ne jeho nepřítomnost!!!
A tím pádem sis na to odpověděl sám - prakticky všechny*) útoky na IoT po IPv4, co se netýkaly routerů s veřejnou IPv4 adresou. Nějak je v tomhle stavu nevidím reálný, že profesionální firma vyrobí tisíce krabiček a bude individuálně řešit na desítkách routerů u desítek ISPíků obcházení NATu, aby je pak zarazil CGNAT, nebo je při tomhle vyčerpání adres všechny věšet na veřejný IPv4 adresy.
*) Jediná možnost je, že někdo z firem s prefixem class A z 50 let starýho přídělu si takovou krabičku zapne ve vnitřní síti bez NATu
pre pripad, ze viete o com hovorite, len neviete citat, este raz:
pisali ste o bootnetoch na IoT ktore boli zalozene z vekej casti na zariadeniach za NATom.
Mozte uviest konkretny priklad takeho bootnetu?
--
To, ze na presnujuci komentar k uvedenej otazke ste odpovedali nezmyselny sloh nepovazujem za hodne reakcie. Diskusia kde si dokazujete kto ma vacsieho ma naozaj nezaujima.
Tak bude delat to, co tam je napsano.. a pokud jste lini to studovat, zde mate popis pro laiky:
Devices infected by Mirai continuously scan the internet for the IP address of Internet of things (IoT) devices. Mirai includes a table of IP address ranges that it will not infect, including private networks and addresses allocated to the United States Postal Service and Department of Defense.
Victim IoT devices are identified by “first entering a rapid scanning phase where it asynchronously and “statelessly” sent TCP SYN probes to pseudo-random IPv4 addresses, excluding those in a hard-coded IP blacklist, on telnet TCP ports 23 and 2323”. If an IoT device responds to the probe, the attack then enters into a brute-force login phase. During this phase, the attacker tries to establish a telnet connection using predetermined username and password pairs from a list of credentials. Most of these logins are default usernames and passwords from the IoT vendor. If the IoT device allows the Telnet access, the victim's IP, along with the successfully used credential is sent to a collection server.
https://en.wikipedia.org/wiki/Mirai_(malware)
https://www.imperva.com/blog/malware-analysis-mirai-ddos-botnet/?redirect=Incapsula
Mirai tedy zamerne necilil na uzly za NAT, ale jen ty, co maji verejnou adresu. Ono totiz kdyz tam je C&C cast implementovana jako listener (ma to v sobe telnet-like shell), tak byt schovanej za NAT-em je jak to rict... totalne k nicemu.
Takze mit derave IoT za NAT-em, byla konkretne v pripade Mirai zaruka ochrany.
Nejak vam ta vase demagogie nevychazi :D
RDa: Jak jsem psal, to byste nejdříve musel vědět, co ten zdroják dělá a jak funguje internet.
Když se chcete připojit z druhého konce internetu na zařízení, k němuž znáte jen privátní IP adresu, opravdu nemůžete jen tak poslat paket s cílovou privátní IP adresou.
Konkrétní příklad – kdyby bylo ve vaší domácí síti za NATem nějaké zařízení napadené Mirai a kód si vygeneroval náhodnou IP adresu 172.16.173.127, s jakým zařízením se naváže komunikace?
Dokud nebudete znát odpověď na tuhle otázku, nemá smysl, abyste pokračoval v diskusi – protože nechápete podstatu diskuse. No a až zjistíte odpověď na tu otázku, budete se stydět, co tady celou dobu píšete za nesmysly, a v diskusi také pokračovat nebudete.
Vy jste totalne vedle.
Konkrétní příklad – kdyby bylo ve vaší domácí síti za NATem nějaké zařízení napadené Mirai a kód si vygeneroval náhodnou IP adresu 172.16.173.127, s jakým zařízením se naváže komunikace?
Ne.
1) Zarizeni v lokalni siti nebude napadeno Mirai.
2) Mirai nikdy nevygeneruje takovou IP, viz zdrojak.
Znova odbocujete do nesmyslu ktery nenastane.
A jsme u toho co tvrdim od pocatku:
Když se chcete připojit z druhého konce internetu na zařízení, k němuž znáte jen privátní IP adresu, opravdu nemůžete jen tak poslat paket s cílovou privátní IP adresou.
Z tohoto pohledu NAT poskytuje bezpecnostni zaruku stejnou jako specificke filtrovaci pravidlo ve firewallu - ze zarizeni za NATem NEBUDE kontaktovatelne z celeho verejneho internetu.
Dekuji tedy, ze jste konecne priznal, ze zarizeni za NATem je v bezpeci.
RDa: Tak ještě jednou a pro absolutně neznalé.
Představte si situaci, kdy zařízení v lokální síti bude napadeno Mirai. Chápu, že o sítích nic nevíte, ale vězte, že zařízení může mít více IP adres, takže může být v privátní síti a zároveň mít veřejnou IP adresu. Nebo může být jen v privátní síti, ale veřejná IP adresa může být na jeho IP adresu NATována. Nebo ta lokální síť prostě může mít veřejné IP adresy – psal jsem o lokální síti, ne o privátní síti. Takže máme situaci, kdy máte zařízení napadené Mirai.
Teď si představte, že by v tom zdrojáku Mirai nebyla ta podmínka při generování náhodných IPv4 adres. Takže by to zařízení vygenerovalo IP adresu 172.16.173.127 a s ní by začalo navazovat spojení. Co by se podle vás stalo?
Až to budete vědět, pochopíte (možná), proč je ve zdrojáku ta podmínka. Pak by vám mělo dojít, že ta podmínka neznamená, že Mirai nenapadá zařízení v privátních sítích.
Mimochodem, ono totiž není jak na dálku zjistit, že je nějaké zařízení v privátní síti. Ono totiž může mít více adres, může být provoz na tu privátní IP adresu NATován z veřejné adresy…
Z tohoto pohledu NAT poskytuje bezpecnostni zaruku stejnou jako specificke filtrovaci pravidlo ve firewallu - ze zarizeni za NATem NEBUDE kontaktovatelne z celeho verejneho internetu.
Má to jednu drobnou vadu – není to pravda.
Už jsem vám to psal, jenže vy to ignorujete. Tak ještě jednou. Máte router se SNAT, který směrem do lokální sítě má IP rozsah 192.168.1.0/24. Na vnější rozhraní toho routeru přijde IP adresa s cílovou IP adresou 192.168.1.3. Co udělá SNAT? Co udělá router?
Až budete umět odpovědět na tyhle otázky, pochopíte, v čem se celou dobu mýlíte.
Vy jste asi blbej nebo nevim, ale znova:
Pokud IoT zarizeni ma pristup na vice podsiti a bylo napadnuto z verejne site skrze DNAT, tak ta podminka zajisti ze NEBUDE napadat dalsi zarizeni za timto NATem v one konkretni privatni siti.
Coz je presny opak vaseho soucasneho vnimani, AKA:
Až to budete vědět, pochopíte (možná), proč je ve zdrojáku ta podmínka. Pak by vám mělo dojít, že ta podmínka neznamená, že Mirai nenapadá zařízení v privátních sítích.
Ta podminka zarucuje ze se Mirai o zarizeni za NATem nebude zajimat. Napadne jen to verejne dostupne zarizeni. A pokud je zarizeni verejne dostupne, protoze na nej nekdo skrze DNAT nastavil pristup, tak ho nelze povazovat za schovane za NAT.
Vy jste asi blbej nebo nevim, ale znova:
Od vás to beru jako pochvalu.
Pokud IoT zarizeni ma pristup na vice podsiti a bylo napadnuto z verejne site skrze DNAT, tak ta podminka zajisti ze NEBUDE napadat dalsi zarizeni za timto NATem v one konkretni privatni siti.
Ve skutečnosti je tam ta podmínka pro to, aby se zbytečně nestřílelo do IP adres, u nichž je nízká pravděpodobnost úspěchu.
Ta podminka zarucuje ze se Mirai o zarizeni za NATem nebude zajimat.
Nezaručuje. Zařízení za NATem může být dostupné přes veřejnou IP adresu.
A pokud je zarizeni verejne dostupne, protoze na nej nekdo skrze DNAT nastavil pristup, tak ho nelze povazovat za schovane za NAT.
Vida, už se blížíte k cíli. To, jestli je tam nastaven DNAT, ovšem nevíte – třeba i proto, že se to může kdykoli změnit. (Může to nastavit váš ISP, pokud byste chtěl tvrdit, že přece víte, co máte nastavené.) Takže žádné zařízení nemůžete považovat za schované za NATem. A to je to, co se vám tu snaží několik lidí vysvětlit už několik dní.
NAT totiž nic neschovává, NAT naopak zpřístupňuje.
17. 6. 2024, 09:00 editováno autorem komentáře
Ve skutečnosti je tam ta podmínka pro to, aby se zbytečně nestřílelo do IP adres, u nichž je nízká pravděpodobnost úspěchu.
To je vase dezinterpretace jasneho faktu. Zdrojak rika "neutocit na zarizeni v privatnich sitich" (aka za NAT-em). Nic vice, nic mene.
Jak jste prisel na to, ze to ma korelaci s nizkou mirou uspechu, ale zaroven tvrdite v predeslych komentarich, ze IoT zarizeni za NATem jsou castejsi nebo stejne snadne obeti, fakt nevim.
To je vase dezinterpretace jasneho faktu. Zdrojak rika "neutocit na zarizeni v privatnich sitich" (aka za NAT-em). Nic vice, nic mene.
To je vaše dezinterpretace jasného faktu. 127.0.0.0/8 nejsou privátní sítě, 15.0.0.0/7 nejsou privátní sítě atd. Navíc privátní síť nemusí být za NATem.
Jak jste prisel na to, ze to ma korelaci s nizkou mirou uspechu, ale zaroven tvrdite v predeslych komentarich, ze IoT zarizeni za NATem jsou castejsi nebo stejne snadne obeti, fakt nevim.
Přišel jsem na to jednoduše tak, že rozumím fungování IP sítí podstatně lépe, než vy. Takže například na rozdíl od vás chápu, že na zařízení za NATem na druhé straně internetu se fakt nedostanete tak, že do paketu uvedete jako cílovou adresu jeho IP adresu z privátního rozsahu. Co je na tom tak těžké pochopit?
To, že jsou IoT zařízení za NATem častější oběti plyne jednoduše z toho, že je takových zařízení podstatně víc.
Tohle je uz mega trapny ze nedokazete udrzet kontext o kterem se bavime.
Bavime se pouze a jenom o teto casti podminek:
(o1 == 10) || // 10.0.0.0/8 - Internal network (o1 == 192 && o2 == 168) || // 192.168.0.0/16 - Internal network (o1 == 172 && o2 >= 16 && o2 < 32) || // 172.16.0.0/14 - Internal network
To jsou site za NATem.
Ze ten bot nema potrebu utocit na US DoD, USPS a jine specificke vyjimky ma zcela jine duvody (napr. souvisejici s mirou odhalitelnosti, tudiz zivotnosti botnetu)
Takže například na rozdíl od vás chápu, že na zařízení za NATem na druhé straně internetu se fakt nedostanete tak, že do paketu uvedete jako cílovou adresu jeho IP adresu z privátního rozsahu. Co je na tom tak těžké pochopit?
Ja tomu rozumim a presne tohle i ocekavam ze bude platit - a proto tvrdim ze NAT je zabezpeceni, protoze zamezi moznosti komunikace temer vsech utocniku na chranene zarizeni.
Tedy zcela stejne, jako kdyz si nastavite firewall s vyjimkou na chatu/do prace nebo odkud se bezne pripojujete - a utocnik bude mit stesti se nachazet na stejne zdrojove adrese.
Bavime se pouze a jenom o teto casti podminek:
Jen o části těch podmínek se bavíte vy. Přičemž jste to nikde nenapsal a vůbec jste nezdůvodnil, proč se bavíte zrovna o této části.
To jsou site za NATem.
Nejsou. Jsou to privátní rozsahy, které nejsou routovatelné ve veřejném internetu. To neznamená, že jsou to sítě za NATem.
Ze ten bot nema potrebu utocit na US DoD, USPS a jine specificke vyjimky ma zcela jine duvody (napr. souvisejici s mirou odhalitelnosti, tudiz zivotnosti botnetu)
To je vaše ničím nepodložená spekulace.
Ja tomu rozumim
V tom případě to velmi dobře maskujete.
a proto tvrdim ze NAT je zabezpeceni, protoze zamezi moznosti komunikace temer vsech utocniku na chranene zarizeni.
NAT ale ničemu nezamezí. A pokud je to „téměř všech“, není to „zabezpečení“.
Tedy zcela stejne, jako kdyz si nastavite firewall s vyjimkou na chatu/do prace nebo odkud se bezne pripojujete - a utocnik bude mit stesti se nachazet na stejne zdrojove adrese.
Není to stejné. Firewall nastavuju já, takže mám kontrolu nad tím, koho dovnitř pustím a koho ne. Ta „ochrana“, o které píšete, není způsobená NATem, ale konfigurací sítě a případně firewallu někde před tím NATem. A nemáte to ve své moci vy.
Rozdíl mezi firewallem a NATem je ten, že firewall vybrané pakety zahazuje, nepustí je dál. NAT jenom překládá adresy v paketech, nikdy žádný paket nezahodí. Nevím, jak si představujete, že by fungovalo síťové zabezpečení na úrovni paketů, které nikdy žádný paket nezahodí. To je jak kdybyste měl u vstupu do budovy ochranku, která by ovšem nikdy nemohla nikoho zastavit. To je podle vás zabezpečení?
Proto jsem NAT přirovnával k turniketu místo dveří do bytu v bytovém domě. Vy se pořád oháníte tím, jak vás chrání turniket, ale ve skutečnosti jediná ochrana je zámek na vchodových dveřích do bytového domu. Který ale nemáte pod kontrolou, nevíte, kdo všechno od něj má klíč. Nevíte ani zda zrovna není rozbitý a dveře nejdou otevřít i bez klíče. Takže vaše vlastní ochrana je nulová, a spoléháte na ochranu od někoho jiného, o které nevíte nic, ani jestli vůbec existuje. A tomu říkáte „zabezpečení“.
"Proto jsem NAT přirovnával k turniketu místo dveří do bytu v bytovém domě."
Proč to nepřirovnat spíše k té vrátnici nikoliv "místo" ale "navíc" ke dveřím v bytovém domě? Přímá komunikace jsou dveře z bytu přímo na ulici. Kdokoliv jde kolem, může si vyzkoušet jejich pevnost, klíč pod rohožkou nebo jestli někdo nezapomněl zamknout. V případě NATu máte před těmi dveřmi z bytu navíc vrátnici, která uplatňuje různý způsob řízení přístupu. Může to být vrátnice někde v knihovně, kde pustí každého nebo se vrátný aspoň zeptá, za kým jde. Když někdo projde vrátnicí, může zkoušet dveře bytů, jako by je jinak mohl zkoušet přímo z ulice. Zloděje může přes vrátnici neúmyslně provést i někdo z obyvatelů.
U toho IPv6 jsou těch dveří z ulice biliony, takže zloděj nebude zkoušet jedny po druhých a musí jít najisto. Ovšem také nelze vyloučit, že zloděj získá přesné číslo dveří. Takže je třeba ty dveře zabezpečit.
Kdybych psal botnet pro IPv4 adresy pro jinou síť, tak tam budu mít přesně tuhle podmínku.
Lokální síť znám (masku i vlastní adresu) a pročuchám to normálně v cyklu jako první. Co najdu, to infikuju. Udělám si tak zálohu v lokální síti, kdyby tenhle stroj někdo odstavil.
Ve druhým kole se pokusím hledat další cíle. Vygeneruju adresu a zkusím na ni zaútočit. Ale je určitá množina adres, na který se z lokální sítě nepodívám, protože je chytne první správně nastavený firewall a spadnou do logu. Nechci se nechat odhalit a nechci čekat na odpovědi, který nepřijdou. Takže když se vygeneruje něco z té množiny, rovnou to zahodím a zkusím jinou adresu.
To, že do téhle množiny zapadne i LANka, ve které sedím, je úplně jedno. Když se generují cizí adresy, svoji síť už mám proskenovanou a infikovanou, takže nevadí, že vypadne.
A navíc to má i další výhodu. Když se k tomu dostane nějaký tydýt, co nerozumí sítím, tak si bude myslet, že za NATem napadnu maximálně jeden stroj a bude řešit ten. A že má napadenou celou síť ho nenapadne, protože přece ostatní stroje kolem nesplňují tuhle podmínku...
Vyhledejte si Googlem „botnet IoT“. Kterýkoli botnet, který takhle najdete, se pravděpodobně skládá z velké části ze zařízení za NATem. On totiž dnes neexistuje způsob, jak by mohlo velké množství IoT zařízení mít veřejné IPv4 adresy. POkud by dnes někdo vyrobil IoT zařízení, které bude vyžadovat veřejnou IPv4 adresu, bude to zařízení prakticky neprodejné. Naopak pokud by měl někdo spoustu volných IPv4 adres, určitě je nepoužije tak, že na ně pověsí IoT zařízení. A botnet, který by se specializoval jenom na zařízení s veřejnou IPv4 adresou, by byl maličký a nepřinášel by žádnou výhodu oproti botnetům ze zařízení, která jsou za NATem.
ale ked teda ste vygooglili "bottnet z IoT obsahujuci relevantne percento zariadeni za NATom", mozte sa s nami podelit o tuto znalost.
(ocividne Mirai, co nasiel vas sparingpartner, take nie je)
--
inak len tak na okraj: pocet IPv4 x pocet dostupnych portov mi pride celkom dost na to aby z toho bolo mozne vyskladat aj niekolko bootnetov. Takze si musite najst lepsi argument, ked to skusate pouzit ako existencny dokaz existencie vami definovaneho objektu.
hmm... zaujimave... ste dvojicky alebo len duchovne spriazneni?
obaja miesto jednoduchej odpovede si vyberiete uplne zbytocnu cast prispevku s pocitom, ze k tomu musite povedat nejaku zbytocnost.
Ale som rad, ze zjavne s tym IoT bootnetom to bol nezmysel. Uz som sa zlakol, ze mi nieco v zivote uslo.
Tak ještě jednou prosím, NAT není firewall.
Zde na root.cz stále je velmi vydařený článek přesně na námi diskutované téma https://www.root.cz/clanky/proc-neni-nat-totez-co-firewall/
Typickým příkladem proč NAT není firewall je použití NATu na Cisco routeru (určitě i jiný výrobce, ale já znám hlavně Cisco). Ty zařízení nemají firewall, přesto umí překlad adres, ale před útoky z venku vás prostě neochrání. Paket určený pro vnitřní síť bez rozpaků doručí dovnitř. A pak postačí aby váš ISP měl bezpečnostní incident a máte v té chvíli problém i vy.
K tomu Use Case 1:
Včera ve 14:14 Filip Jirsák psal: Ne, NAT ani SNAT nezabraňuje komunikaci z venku. Komplikuje ji oprávněnému uživateli, ale nezabraňuje jí.
Ty teď popisuješ, jak to jde udělat, ale po tom, co uživatel vrtá do nastavení routeru. Rád bych jenom podotknul, že je to jaksi činnost navíc, kterou musí člověk umět. Pokud to neumí BFU, je to komplikace, protože ji musíš udělat za něj, nebo ho na to proškolit. Navíc je tam podmínka nebýt za CGNATem.
Stejně tak zřídit server někde na veřejné IP adrese znamená vybrat poskytovatele, zaplatit službu, nakonfigurovat to, otestovat to,... Zase další komplikace.
Docela se divím, že se o tom s Jirsákem hádáš, když to vidíš stejně.
K tomu Use Case 2:
Píšeš: Pokud ma Lojza pristup k lince, tak jste kompromitovan nezavisle na nasazene halde technologii, proste jste MITM = boss. Neni to relevantni k NAT ani IPv4 - vidi prece pakety na jeho lince. Problem neni resitelny zadnym zpusobem.
V tom případě ale nechápu, proč ty a tvoje sekta prezentujete svatý NAT jako univerzální ochranu před tím, aby zařízení zvenčí jakkoliv kontaktoval kdokoliv nepovolaný. Můžeš nějak, místo útoků ad hominem, vysvětlit, jaký útok a jakým způsobem by asi tak měl samotný NAT, bez asistence dalších bezpečnostních mechanismů, zastavit?
A ne, MITM neznamená, že útočník je king. Na to jsou zase jiný metody zabezpečení. Tady šlo jenom o tvoje tvrzení o filtraci provozu NATem. Zabezpečení má několik vrstev, každá řeší něco jinýho a NAT mezi ně nepatří. Proto jsem v podmínkách definoval jako podmínku prolomení to, že je doručen paket zvenku na zařízení.
Ale je fér přiznat, že jsem večer už byl unavený v tom use case 2 jsem udělal chybu. První doručený paket byl FIN, a dokonce spustil akci na koncovým zařízení.
Navíc si ještě dovolím podotknout, že v cybersec kurzu nás učili, že nemáme útočníkovi věci zjednodušovat, třeba tím, že prozradíme v chybovým hlášení druh a verzi produktu, protože pak může přesně cílit útok na konkrétní zranitelnost. Tady jede 24/7 spojení na nějakou IP adresu a port, to je na 99% tunel z nějaké běžící IoT věci ve vnitřní síti, co má překonat NAT. A s minimálně 60% pravděpodobností MQTT. Svítí to jak maják. A jediný důvod, proč to vidí je, že tam je NAT. Bez něho proletí v případě potřeby 10 paketů mezi neznámou IP adresou a nějakou adresou s prefixem v Pepově síti a útočník, aby to odhalil, musí zrovna v té chvíli logovat data. A když to náhodou chytne, tak než projde logy a zjistí, která páčka, tak session skončí a nestihne do ní zasáhnout.
Tak ty krabičky kromě NATu obsahujou i FW, který ve výchozím stavu zpravidla dropne všechno z wan a většina současných služeb je schopná s tím vesele fungovat. Pochybuju že odstranění NAT a přímá komunikace tu bezpečnost nějak vylepší, až bude Mařena na svym FW povolovat příchozí spojení, aby nasdílela kolegyni v kanclu fotky z dovolená co má na disku, když bez NAT už nepotřebuje žádné ty cloudy a může sdílet hezky napřímo.
Ale tohle je o možnosti volby. Máňa může mít klidně fotky v čmoudu, ale to není důvod nutit Lojzu, aby je tam měl taky.
Pokud jde o IoT, tak to je jednoznačně lepší bez čmoudu. Prodej 50k zařízení a budeš udržovat až 100k spojení v reálným čase skrz server (zařízení + mobil majitele, například). A tím, že ten server je SPOF a jak klekne, máš velký problém...
A IPv6 nativně podporuje IPSEC. Zapneš a je to zabezpečený... (původně to mělo být povinně, ale malý krabičky by to nedaly).
Pokud jde o ztrátu dat, tak platí zálohovat, zálohovat, zálohovat. O fotky přijdeš nejenom, když ti klekne NAS, ale i když provozovatele čmoudu chytne rapl a změní podmínky... V tom si nevybereš a záloha se vždycky hodí
Mas ku vsetkemu moznost volby? Ani nahodou. Moznost volby nieje zakaldne ludske pravo.
To je trh/podnikanie.
Chod, podnikaj a predavaj to be cmoudu. lojzu nikto nenuti ich tam tiez. Lojza ma moznost volby, len tie volby s amu nemusia pacit ale to je uz druha vec.
Hadam si to tie firmy spocitali a porovnali plusy/minusy, ze sa vidali cestou cmoudu. Myslis si, ze im ten cmoud bezi na jednom serveri? Ze im to len tak klakne? Aj keby, tak velky problem neubdem mat. Plus nevsimol som si zeby internet a diskusie boliz aplavene nefunkcnostou cmoudu.
Ako som psial niekde inde IPv6 povazujem viac za akadamicky protokol. IPSEC ako nativnu vec povazujem za jednu z tych akademicky veci, ktora sa minula realite.
Nésu síťař, takže - byl by praktický popis problému, který to tak moc komplikuje?
Poslední WiFinář nemoh bejt takový kopyto, aby to nezvládl nakonfigurovat, když mou veřejnou IP adresu protáhl NATem ne soukromý rozsah a potom s toho zpátky dělal "veřejku" se třema portama. Pustit cokoliv přímo rozhodně složitější nebude a i přesto to nechtěl zvládnout.
Jasně. Takže tvrdíš, že:
- Kupovat, provozovat a udržovat CGNAT je levnější, než to pustit rovnou.
- Logovat z CGNATu, kdo kdy kam lezl kvůli policajtům, archivovat to a hledat v tom je levnější a jednodušší, než se prostě podívat do tabulky a říct "Tenhle prefix má přidělenej Lojza Průša, Úchylná 550/12"
- Kupovat další IP adresy za stovky dolarů, pokud chceš růst, je efektivnější, než si na to vyčlenit nějaký blok z miliard adres, který už máš k dispozici.
- Je levnější udržovat na uplinku při MS v hokeji tisíce streamů toho samýho, než využít multicast a klonovat si to až na routeru ve vnitřní síti
A teď tu O poslanci, co nikdy nezalhal
V bývalé práci jsme na jednom produktu vyslyšeli volání po ovládání z mobilu odkudkoliv. Věř, že jako výrobce jsme si počítali každý cent, ale díky těm <píííp píííp píííp píííp> ISP nejlevnější řešení - TCP po IPv6 - padlo hned a dopadlo to tak, že:
- vývoj sežral o 2800 člověkohodin víc, protože aplikace do čmoudu, testování,...
- 30% z výrobní ceny bylo určeno jako žrádlo pro provozovatele čmoudu, bez kterýho by to nekomunikovalo
Takže výrobek, který by mohl jít z fabriky za 100€, prodáš do velkoobchodu za 150€ jenom kvůli debilnímu NATu. Když započítáš přepravu, marži pro velkoobchod a maloobchod, DPH... Kolik tak ten rovnák na vohybák může ve finále stát zákazníka? 70-120€?
A ty jako výrobce musíš řešit, z čeho ten čmoud platit po celou dobu životnosti výrobku... Nevíš, jestli ti to za rok nezdraží kvůli cenám energie atd.
Pro výrobce IoT věcí fakt to poslední, po čem by toužili, používání čmoudu. Buďto se musí uskromnit, abych nebyl cenově výrazně nad konkurencí, nebo plánovat kratší životnost výrobku kvůli vypnutí čmoudu a vnucení novýho kusu, kde je další předplatný, nebo výrobek jenom pronajímat. A je tam závislost na třetí straně, která je obecně blbě...
Tak pokud se to konkrétně Vás netýká, tak máte můj respekt, nicméně on ten čmoud (který nenávidím a odmítám) má jednu drobnou výhodu - představit si IoT které komunikuje směrem ven na nějaký čmoud a tam si vyměňuje data si dokážu celkem v pohodě (mnohem radší self-hosted, ale to je fuk).
Z představy průměrného dodavatele IoT, jehož zařízení je otevřené světu, a které je chráněné jen 2^64 obskuritou (kterou nejspíš naruší nějaký DynDNS nebo něco takového) mě běhá mráz po zádech.
Ty IoT krámy by se stejně slušelo schovat za VPN nebo alespoň nějakou proxy s omezením provozu, stejně jako v IPv4 (protože díry, protože potenciálně nebezpečné dopady při průniku, protože se výrobce po čase vykašle na aktualizace, ale nikdo soudný to zařízení jen kvůli tomu nevyhodí). Na druhou stranu mít možnost si po zralé úvaze na jakémkoliv zařízení spustit službu přístupnou potenciálně* z celého internetu by bylo velmi žádoucí.
* Pořád si můžeme přístupnost doladit firewallem.
14. 6. 2024, 09:22 editováno autorem komentáře
Co přesně znamená "Ty IoT krámy"? Pět let starý, neupdatovaný klon BSD se samo domo tuningem a zapnutým telnetem? Linuxový stroj, kde je update 1x za dva měsíce a SSH se povoluje po sériové konzoli? Nebo jednočip, který nemá možnost spouštět, co není v ROMce, nemá skriptování a nemá ethernetový bootloader?
Cokoliv z toho, moc bych mezi tím v principu nerozlišoval. Jde o to, že zranitelnost může být kdekoliv - u jednočipu možná s menší pravděpodobností výskytu, ale i opravy; u nějakého složitějšího systému pravděpodobnost výskytu téměř jistá, hlavně když to někdo dobastlí, aby to tak akorát fungovalo a víc se tím nezaobírá.
Pak samozřejmě záleží na dopadech - pokud si bude někdo číst data z wifi teploměru nebo mi zhasne žárovku, tak se nic moc neděje. Pokud mi ale hackne čínskou rychlovarnou konvici, může to být kardinální průšvih.
V obecné rovině mi přijde nejbezpečnější to všechno naházet do jednoho pytle a považovat apriori za děravé a potenciálně šmírující, a podle toho s tím taky zacházet.
Já se děsím spíš těch, co tvrdí, že za NATem jsou v bezpečí. Ono je to spíš naopak.
Už jenom to, že se udržuje spojení s čmoudem, prozradí, že za touhle adresou je tolik a tolik takových a makových zařízení. Podle délky paketů, frekvence, cílové adresy,... se to dá docela dobře uhodnout. Podstrčit paket s podvrženou zdrojovou adresou taky není problém a proletí NATem jak pendolino dodávkou. DoSnout IoT krabičku v IPv4 taky není problém, zasáhnout do několik hodin / dní existujícího spojení je jednodušší, než když se náhodou někde objeví nečekaný spojení odnikud, proletí 20 paketů a zase zmizí.
Teorie a zbytecne obavy.
Pokud by NAT byla technologie zneuzitelna v takovem meritku jak si myslite, tak ho dnes nikdo neprovozuje... a je tomu tak? no neni. NAT se tesi oblibe, protoze kazdy domaci router ho ma zaplej by default. Tudiz NAT je v kazde rodine.
Za kolik a jakych incidentu muze samotny NAT ? Rekl bych ze temer za nula - vzdy jsou jine, uspesnejsi, jednodussi vektory utoku. A samotny nat nestaci - jak uz tady nekdo psal, potrebuje mit na routru cinklej FW a nejakeho iniciatora zevnitr.
Jestli nejaky ISP dovoluje podvrhnout zdrojovou IP (aka nema na svem hranicnim routru nastaveni typu rp_filter=1) a jede open relay.. je problem sam o sobe, ale nikterak vam nepomuze. A jak caste jsou tyhle utoky? Znova nic nic nic, co by bylo na dennim poradku.
DoS/DDoS neni bezpecnostni kompromitace, jen provozni opruz.
NAT je v každé rodině ne kvůli bezpečnosti, ale proto, že každý rodina chce na internet a to nejde bez IP adresy pro každý zařízení. A pokud ta rodina dostane maximálně jednu IP adresu na přípojku, tak jinou možnost nemá.
Zeptat se, za kolik incidentů může NAT, je stejný, jako zeptat se, za koik vražd může sekera. Odpověď je, že za žádný, za všechny může ten, kdo tu sekeru držel v ruce, když k té vraždě došlo nebo nevědomky ten, kdo sekeru neschoval před agresivním opilcem...
Podvrhnout zdrojovou adresu nemusí ISP, ale může to udělat kdokoliv. A není to omezeno na lokální adresy. Když ze zařízení ve svojí síti pošlu UDP paket na obecnou veřejnou adresu, NAT ji pošle ven a zapamatuje si mou adresu. A když dojde odpověď z té veřejné adresy, podívá se o záznamů a prohodí odpověď zpátky na zařízení, co si ten paket vyžádalo. Prostě chvíli na NATu zůstane otevřeno okno na odpovědi... A aby tam to okno nebylo, tak je nesmím otvírat / udržovat otevřený, ale to s NATem neudělám, protože bych se nedozvěděl, že se mnou chce komunikovat někdo z vnějšího světa.
Samozřejmě, že pokud je médium přípojky 5GHz WiFi, může být celkem triviální se do toho nabořit nezávisle na ISPíkovi a pak už se i ta vnitřní adresa dá zneužít... Fantazii se meze nekladou.
Btw, zajímavější je si dojet autem před dům oběti a nabořit se po WiFi přímo do LANky, pokud nechává zabezpečení jenom na routeru a považuej vnitřní síť za bezpečnou... A pak je úplně jedno, na jakým protokolu to jede.
Ale kdo chce, může to vypnout (nebo o to požádat známýho). To ale neplatí, pokud ISPík nedovolí používat IPv6 vůbec.
I s firewallem má ale Ipv6 několik výhod. Třeba kamarád nemohl pařit nějakou gamesu, protože mu to psalo, že z jeho IP adresy už hraje 10 lidí - byl za CGNATem. Privacy Extension, multicast, přístup k IPv6 only službám,...
Problem je, ze on to trh vyresil uz tak pred 15 lety. Masivni prechod z beznych protokolu na cokoliv-over-http, brutalni narust vykonu sitovych prvku, implementace sitovych protokolu primo na FPGA a serverless reseni schopne za 1 IP schovat tisic projektu. HTTP nema problem fungovat za hradbou NATu. Z trzniho hlediska proste IPv6 nepotrebujeme, protoze pro uzivatele neni problem byt NATovan, pro poskytovatele sluzeb neni potreba mit vyhrazene reseni, SPF, DKIM a DMARC vyresil i potrebu IP adres pro MX.
IPv6 je jiste technicky potreba, je to zpusob jak udrzet Internet v puvodnim konceptu "vsichni jsou primo pripojeni, kazdy muze komunikovat naprimo s kazdym", ale tenhle devadesatkovy model Internetu proste neodpovida tomu, jak Internet ve 20. letech 21. stoleti vypada.
Ale ono ty implementace IPv4 v FPGA (TCAM) take zazily sve "vybuchy". Ten jeden nastal s 256k prefixy v globalnich v4 tabulkach, podobne to bylo s 512k a dalsi i v IPv4-only sitich brzy nastane, protoze se pomalu blizime k 1M zaznamu, kde ale soucasne konci limit cele rady tech skatuli.
Jinak samozrejme IPv6 v TCAM je implementovane take uz dlouho. Dokonce efektivneji, bavime-li se o tom, kolik prostoru to tam zabere.
Takhle fakt nevypadá popis od odborníka
... ale tenhle devadesatkovy model Internetu proste neodpovida tomu, jak Internet ve 20. letech 21. stoleti vypada.
Takže podle něj budeme používat protokol ze 70. let, stavěný na to, že počítač stojí řádově 100k$ a váží minimálně 20 kilo, nikdo jich nebude mít víc než desítky? Nepočítá s mobilitou (multihoming,...), nepočítá se streamováním (multicast, QoS), nepočítá s bezpečností atd.?
Ale zase budou mít čipy vyrobené tou největší litografií na světě. ;oD
11. 6. 2024, 15:05 editováno autorem komentáře
Tak mi poradte: Modelova situacia ... zmenim providera od ktoreho dostanem pekny rozsah ipv6, nastavim si home network a pohoda jazda ... Ale teraz pridem niekam kde je len ipv4 (90% tak kam chodim) a chcem sa teraz cez IPSEC VPNku spojit na svoj GW a cez VPN cojaviem namapovat smb disky ovladat domacnost, pozriet na kamery , streamovat hudbu atd ... Otazka je, ze ako? poznamka: nemam rad akekolvek cloudove riesenie
Niektori provideri (Orange| poskytujú možnosť otvoriť port na ich CGNAT, ktorý je potom forwardovaný k tebe. Nemáš na výber aký port, ale je to dosť, aby si napr. dostal k sebe wireguard (alebo inú vpn, ktorej je jedno, na akom porte beží).
Ak to ISP nepodporuje, tak len vo vlastnej réžií nejaký proxy v cloude.
11. 6. 2024, 16:24 editováno autorem komentáře
Stačí, když se rozhlédnu po okolí. Problém s IPv6 je jeden zásadní - špatně se s tím pracuje, respektive pamatuje. Nejsem přímo síťař, ale když mi někdo zavolá ohledně nefunkčního čehosi, jsem schopen mu z paměti nadiktovat hromadu IPv4 adres, subnety a řešit s ním routování a případné problémy co odkud nejde, vše po telefonu. IPv6 si nepamatuju ani jednu. A nejsem v tom sám :) Tak prosté to je.
Jenže to je principiální problém protokolu, který má více adres, jsou prostě vždycky delší. Když vynaleznete hypotetické IPv5, které „jenom prodlouží adresy“, taky si je budete těžko pamatovat. Představte si ekvivalentní zápis 128bitové adresy jako v IPv4:
88.54.86.114.215.84.54.220.11.168.36.18.214.55.88.140
Naštěstí tu už čtyřicet let máme DNS. Já nemám v hlavě žádnou adresu, ani IPv4 ani IPv6. Tedy kromě několika veřejných DNS resolverů. Zbytek je pak uložen v DNS.
Ja teda sitar jsem a nepamatuju si poradne ani IPv4 adresy. A nejsem v tom sam, vsak proto uz v roce 1983 bylo vymysleno DNS, ze? :-) Kdyz mi nekdo zavola, tak se to domenove jmeno take diktuje jednoduseji, nez zmet cislic. Tak proste to je.
No hlavně argument "IPv6 je strašně dlouhá" vůbec neobstojí. Můj IPv6 prefix je: 2a07:3450:2::. Což je na znaky kratší, než moje ipv4. Spodních 64b mě buď vůbec nezajímá (slaac) nebo je to manuální a je to něco jako ::1.
A jasně, máme DNS.
Ale zábavná diskuse. Doma jsem v roce 2010 zapnul router advertisment v mikrotiku a od té doby mám doma ipv6. A dnes jsem se dozvědět, že to mikrotik vlastně vůbec neumí :-D
Případně, že firmy používají tak slabé routery, že to nezvládne ani gigabit. (Někdy od roku 2014 máme ve firmě CCR.) A tak dále. Pohádky na dobrou noc. Tak příští rok zase. :-D
Nevím, jak vy, ale já si pamatuju prostě čtyři čísla. Já si tu IP adresu nepamatuju po jednotlivých číslicích... Vy ano? Jako chápu, že je to asi možné ale nenapadlo by mě, že někdo takový existuje.
A co se týká těch firem: v malých firmách jste občas rád za 100/20. To jen k tomu gigabitu. Co se tam používá za hardware raději nechtějte vědět. Stejně víte.
Já si svou IPv4 (a ani IPv6) adresu nepamatuju. Vůbec nevím, k čemu by mi v hlavě byla. Naposledy jsem to nastavil před mnoha lety, kdy místní ISP měnil adresy a přidělil mi jiný rozsah. Od té doby to mám v mikrotiku a v dokumentaci. Při upgrade HW routeru jsem udělal textový export, nalil to do nového routeru, zkontroloval nastavení a je to.
A co se týká těch firem: v malých firmách jste občas rád za 100/20. To jen k tomu gigabitu. Co se tam používá za hardware raději nechtějte vědět. Stejně víte.
Vím, co se tam používá za HW. Ale HW z doby před 15 lety gigabit zvládal levou zadní. Dokonce to zvládal i v roce 2006, kdy jsem pracoval u místního ISP a kdy hlavní router na gigabitu byl nějaký pentium 4.
Vytahovat v roce 2024, že někdo má ve firmě(!!!!!) hw, který neumí gigabit je úplně absurdní. Tahle diskuse je 20 let zastaralá.
Tak jasne, ze kdyz ty zarizeni spocitate na prstech jedne ruky, tak ty cisla z rukavu asi vysypete. Kdyz tech spravovanych veci budete mit stovky/tisice a rozhazene po svete, tak v ty hlave udrzite mozna par klicovych prvku, ale rozhodne ne celou infrastrukturu.
A pokud si clovek zvykne na to, ze ma udrzovane DNS (coz jde i dynamicky), pak vlastne ani ten prechod z IPv4 na IPv6 tolik neboli. Protoze to hostname pisete porad stejny a muze vam byt i fuk, jakou verzi protokolu to pouziva.
Nejde ani tak o situaci, kdy všechno krásně funguje. Ale ve chvíli, kdy nastane nějaký průser a nefunguje komunikace ani třeba k internímu DNS, tak zatímco v případě IPv4 si člověk lépe vybaví adresy kritických bodů z hlavy, u IPv6 potřebuje evidenci/"papír". A už je to o krok navíc při řešení problému. A i tato banalita je jeden z důvodů, proč v různých situacích pohodlnější zůstat u IPv4, je to pohodlnější.
Ja si treba z hlavy nevybavim ani IPv4 default gateway, co mam v praci ;-) Ono uz jen CIDR a setreni adresama holt zpusobi treba i to, ze ta gateway nemusi byt nutne .1 - i kdyz jde porad o adresu na zacatku subnetu, ze?
Ne, argument s evidenci neni ve slozitejsim prostredi ani omylem validni, ve slozitejsich infrastrukturach se bez toho papiru (evidence) neobejdete ani v ciste IPv4 siti. A jak u IPv4, tak u IPv6 plati, ze si dost muzete usnadnit zivot automatickou konfiguraci - ktera je mnohdy i lepsi nez nejaky papir :-)
Doporučuju napřed kouknout na https://www.youtube.com/watch?v=NDu5sWf8iyI a pak teprve vykládat něco o pamatování IP adres v lokální síti
Škoda. On totiž existuje způsob, jak se odkázat na stroj v lokální síti, stačí si je pojmenovat. Líp se pamatuje kodi-loznice
nebo kamera-garaz
, než jakákoliv sekvence čísel.
Funguje to i bez nastavování, zapnuto by default. Bez ohledu na to, jestli z widlí nebo tučňáka. Bez ohledu na to, jestli stroje komunikují po IPv4 nebo IPv6. Bez ohledu na to, jestli má stroj adresu zadrátovanou natvrdo, nebo ji dostal pseudonáhodně z DHCP poolu...
Když máme něco takovýho, tak bych memorování IP adres nazval masochismem. A málo co je tak směšný, jako když masochista řekne: "Bejby, nandej mi to rákoskou na holou. Ale opatrně, ať to nebolí."
Proč? Chci se vrtat doma v routeru, napíšu ssh root@router.local
. Jednou vyskočí v logu jako poslední přihlášení adresa s ULA prefixem, jindy IPv4, jindy IPv6 z lokální sitě... Ale dostanu se tam a nastavím, co je potřeba. Po čem, to není podstatný.
Stejně tak používám tiskarna.local
, switch.local
,...
mDNS je prostě super
Ne víc, jak s IPv4
Když to převedu analogicky do IPv4, tak
- Horní půlka supluje to, co je teď veřejná IP, CGNAT a NAT.
- Dolní půlka je ekvivalent adresy za posledním NATem, routování na ni nesahá, ale je tam jenom jako "payload", až se to dostane do konečné sítě.
Horní půlka má 64b, tj. povýšilo se to z 32b - z 4 000 000 000 na 16 000 000 000 000 000 000 sítí. Nevyčítal bych firmě, že dostane /48, horních 8b z těch 16b využije pro identifikaci budovy nebo pobočky a dalších 8b pro identifikaci sítě (dílna, pokladny,...) To je stejně legitimní, jako použít 10.0.0.0/8 a nevyužít ho celý pro 16M strojů.
U domácnosti je těch 256 sítí (prefix 256) taky OK. Pokud přijde nějaká norma na rodělení sítí a začne se implementovat, uživatel zapne síť pro hosty, nebo chce síť pro IoT, na pokusy,... tak se k těm /64, co je jedna LANka, hodí pár bitů navíc. Je to stejná funkce, jako u toho 192.168.x.y použít x pro identifikaci VLANy na úrovni IP.
Dolní půlka je věc konečné sítě. Je to tak rozděleno symetricky. Jasně, šlo by hodit jenom 32b, ale utrpí zarovnání dat a nebyla by rezerva do budoucna. Pokud vím, tak se zatím načaly jenom dva bloky /16 a u dalších se to, v případě potřeby, může dělit jinak (jako byly třídy u IPv4), pokud se ukáže, že to děláme blbě.
Zákazník si platí v rámci přípojky /48 nebo /56. Zbytek do /128 je prostě v jeho režii a nepřísluší ISPíkovi hodnotit, jak moc (ne)účelně je využívá.
To je ovšem správně. IPv6 byl navržen tak, aby se IP adresami mohlo plýtvat opravdu hodně a dalo se to využít k optimalizaci sítě. Je pro všechny lepší, když koncové síti přidělíte obří rozsah adres, se kterým si může dělat, co se správcům zlíbí, než jim to přidávat po malých kouskách, komplikovat jim tím uspořádání sítě a navíc pro jednu cílovou síť obsadit několik řádků routovací tabulky.
Já bych navrhoval opatření "ostudy". Pokud by nějaký poskytovatel internetu nenabízel automaticky plnohodnotný ipv6, musel by veškerá omezení zmiňovat na všech propagačních materiálech, že dostupný není celý internet, ale jen jeho část. To by poskytovatelům dělalo ostudu a mohlo by to věci trochu pohnout.
Stejně tak by to musel zmínit ve všech reklamách na daný produkt. Včetně toho, že např. přidělují menší než doporučené rozsahy.
Malým poskytovatelům by to asi tolik nevadilo, velcí mediální oplzlíci by z toho měli ostudu.
Ale všichni by se více snažili, ale nebylo by to natvrdo přikázáno, aby mohla dožít starší hardware.
11. 6. 2024, 21:08 editováno autorem komentáře
Azure má i po pěti letech (!) od doby, kdy jsem to testoval poprvé, nepoužitelnou podporu IPv6 pro compute:
1. Neumí v Address space přidělit IP prefix z rozsahu Microsoftu, musíte si "vymyslet" nějaký subnet (někdejší příklady v dokumentaci uváděly prefix tuším abc:abc:abc:abc::/64)
2. Nutí vás přidělit si "veřejnou IPv6 adresu" (max. prefix /124)
3. Následně vás nutí dělat 1:1 NAT66; compute má pak "falešné" IPv6 adresy
Na load balancerech, CDN, apod., to může být lepší, ale u compute je to po těch letech fakt s podivem.
Tak ono Azure, co jsem zatím viděl, jede hlavně pro IoT jako tunel přes NATy. Tam IPv6 moc nedává smysl. Ostatní věci všichni v mojí bublině dělají v AWS.
Mega ostuda je, že GitHub, jako služba pro vývojáře, kteří by měli mít přístup k nejnovějším věcem, je IPv4 only. To je jedna z věcí, za který by se fakt měli stydět. Hlavně že tam mají AI a podobný pitomosti. Já mít takovou službu v takovým stavu, tak chotím kanálama s papírovou kabelou na hlavě.
Představ si, že si koupíš hybridní auto a až doma zjistíš, že má nefunkční rekuperaci do baterky a prodejce řekne, že doteď jsi přece hybrida neměl, tak to nebudeš postrádat. Budeš vnímat jeho jednání jako podraz, nebo svoje výtky na hlavu prodejce jako demagogii?
Kupující má právo vědět, co kupuje a fertyk.
Souhlas. Právo používat "připojení k internetu" by měl jenom ten, kdo
- dá min. download ve špičce 40Mbps
- poměr download"upload 1:2 nebo lepší
- veřejnou IPv4 nebo prefix min. /56 v IPv6
- možnost DNS záznamu ve svojí doméně (formát nickzakaznika.superduperisp.cz
), kde si zákazník řekne svůj nick
Pokud cokoliv z toho nesplní, nejednalo by se o připojení k internetu a musel by uvádět ve formě pochopitelné pro BFU, v čem je oproti připojení k internetu rozdíl a jak to uživatele omezí.
Jak se dá počet NATů zjistit? Obvykle je zákazník za NATem a svým routerm si přidá druhý NAT. Proč by měl poskytovatel internetu dělat další NATy moc nechápu, ale myslím že by to už nemělo ničemu vadit, pokud je to uděláno dobře. Někdo blokuje nějaké porty u odchozího spojení? To jsem ještě neviděl.
Ale ano, mažete. Přinejmenším zmizel jeden z mých příspěvků, ve kterém jsem vyjádřil domněnku o tom, že by bylo daleko jednodušší rozšířit adresní prostor a na nic jinak nesahat a že by to zásadně zjednodušilo nasazení "nového" protokolu v kontrastu k tomu, jak vypadá IPv6, co všechno změnilo a zavedlo navíc.
A to je právě ta škoda, já si rád přečtu kde se kdo mýlí, případně kde jsem udělal chybu v úsudku já. Škoda no.
Nechápu čemu to vadí, těch pár bajtů v db snad nikoho nezruinuje. Místo aby se člověk poučil ze svých nebo cizích chyb a k věci, musí prolízat bláboly denyho o infalci, korupci a cenách nemovitostí. :-/
Tohle by mi normálně bylo jedno, ale v kontextu kdy se maže diskuze k věci a bláboly nechávají, mi to nepříjde hodné serveru kde se akcentuje svobodný SW.
Jako proč bych se měl ptát???? Tady se posílají názory a reakce, odpovědi na ně. Na otázky je fórum.
A protože reakce na můj názor byla smazána, můj názor se nemění. Ipv6 je podle mě pro bfu paskvil.
Kdyby jednoduše místo 8 bitů změnili 10/12/16 bitů tak mohlo všechno pokračovat s velmi decentním updatem firmwérů.
Sám vidíš, že si moji adresu skoro pamatuješ.
A co se týče trolingu, tady to má být zábava, pokud to cenzor nechápe (Ty?), měl by se chytnout za nos. Nejvíc kliků a reakcí se vždycky sejde u kontroverzní diskuze. Plácání se po ramenou, jo všecko OK, blabla kec o ničom, aktivistický blábol, nikoho ke čtení ani k reakci nevyprudí. Místo abyste byli rádi, že to tady žije a někdo se snaží přispívat, tak to tady zařezáváte.
To je mmchdm hlavní důvod proč nikdy nepřispěju ani korunou, zařízli jste mi už několik zpráviček a názorů, pokaždé mě to dost sebere a dávám si otázku, jestli mi tahle pokrytecká společnost stojí za to - na jedný straně plná huba podpory opensource, svobodného softwéru, formátů a na druhý straně zářezy za nepohodlný názor nebo formu. Evidentně si zakládáte elitářský klub správných názorů. Njn, dneska je to moderní, kdo neblábolí s námi je dezolát a patří zaříznout, zakázat, nejlíp odstavit od netu, aby se o tom někdo náhodou nedozvěděl.
> Jako proč bych se měl ptát????
Třeba aby ses dověděl cituji : "kde jsem udělal chybu v úsudku já" ;)
> Kdyby jednoduše místo 8 bitů změnili 10/12/16 bitů tak mohlo všechno pokračovat s velmi decentním updatem firmwérů.
Ne, nemohlo. Musí vedle sebe koexistovat obě verze. Takže je třeba vedle implementovat i verzi s větší šířkou + potřebné přechodové mechanismy.
Navíc ten kód vůbec nemusí být psaný stylem, aby se nějaká část hlavičky dala jednoduše přifouknout.
> Sám vidíš, že si moji adresu skoro pamatuješ.
A k čemu to je? Žádné zařízení by tuhle "adresu" určitě nemělo, už jen proto že 255.255.255.255 taky není normální adresa.
I v ipv4 světě je pamatování adres dobré akorát pro garážníky co mají pod palcem 5 a půl stroje.
12. 6. 2024, 14:58 editováno autorem komentáře
Nezlob se na mě, ale za tím si stojím a za blábol to rozhodně nepovažuji. Souhlasím s tím, že IPv6 se snažil řešit některé neduhy IPv4, zároveň se tím ale zesložitil. A vsadil bych boty na to, že kdyby se jen vzal IPv4 a rozšířil se adresní prostor, tak jsme tady už nový protokol dnes měli, protože by to prostě fungovalo a nebyl by tam takový prostor pro to, co všechno se může rozbít a celkově by to bylo jednodušší na implementaci, testování a nasazení.
EDIT: Takže by to možná nebylo zdaleka ideální, ale ten nejpalčivější problém by byl vyřešen.
12. 6. 2024, 13:02 editováno autorem komentáře
A vsadil bych boty na to, že kdyby se jen vzal IPv4 a rozšířil se adresní prostor, tak jsme tady už nový protokol dnes měli, protože by to prostě fungovalo a nebyl by tam takový prostor pro to, co všechno se může rozbít a celkově by to bylo jednodušší na implementaci, testování a nasazení.
Tak to buďte rád, že jste to neudělal. Winter is coming. :-)
Stačí se rozhlédnout, co, kdo, jak a proč přechod na IPv6 brzdí a u kolika z těch důvodů je rozumný důvod předpokládat, že by odpadly, kdyby se to udělalo tak, jak navrhujete vy.
Ale ono jde právě o to, že nestačí jen vzít ipv4 a rozšířit adresní prostor.
Chybí tam třeba přechodové mechanismy z ipv4 na ten rozšířený. Takže celá tahle komplexní mašinerie se musí tak jako tak navrhnout na zelené louce.
I ten rozšířený protokol by fungoval vedle starého ipv4. Konfigurovat a provozovat jakýkoliv dual stack je náročné a management se na tom bude snažit ušetřit. Obzvlášť když náklady na ipv4 s jeho rovnáky na vohejbáky je třeba platit tak jako tak, dokud dostatečně nezdechne.
No neviem.
Mne IPv6 prisiel ako akademicky protokol.
Par chytrych hlav si povedalo, ze vymysli dokonaly protokol. No a nevyslo im to a este to,co vymysleli je neprakticke. Pripomina mi to Slovensky jazyk. Technicky je na vysokej urovni ale neprakticky na bezne pouzivanie so zbytocnymi finesami, ktore len zbytcne trapia deti na hodinach Slovenskeho jazyka. O to viacej sa mi zacala pacit anglictina, kde mi pride, ze prakticka stranka bola pre nich dolezitejsia ako dokonalost jazyka.
Za mna sa mali zobrat doterajsie skusenosti a postavit nieco nove. Predsalen aj IPv6 je stary protokol, ktory vznikol uz v roku1998 a internet bol vtedy este v plienkach.
Pride mi, ze sa spekulovalo, sepkulovalo a spekulovalo az bolo neskoro a zobral sa IPv6, lebo tam bolo dostatok adries.
Pred niekolkymi rokmi tu(alebo na konkurencnom webe) vysiel serial o zranitelnostiach IPv6 a bolo to zaujimave citanie.
No na jednu stranu to tak opravdu vypadá, na druhou stranu to navrhovali lidi z praxe a akademiků byla menšina.
A na lidi z praxe to místy pěkně zprasili že člověk přemýšlí, jak moc kdo hulil, třeba to, že všechny EH paketu nejsou formátu t-l-v by asi v akademii dopadlo nějak jako "tak pane kolego si to předělejte a na podzim se tu potkáme".
To akademicky som myslel obrazne. Seslo se par chytrych hlav a tie sa neudrzali na uzde.
Aj ta prax je problem. Skusenosti/internet v dobe vzniku IPv6 bol niekde inde. Aka bola prax/skusenosti do roku 1998?
Chcelo to novu verziu na zaklade aktualnych skusenosti a stave itnernetu. Aj za cenu, ze sa veci/HW, co sa doteraz urobili na Ipv6, zahodia.
IPv4 je několikanásobně složitější, než IPv6!
Odpadne celý slavný NAT.
Není potřeba řešit problémy, když mám doma síť 192.168.1.0, v práci 192.168.1.0 a musím řešit home office po VPN.
Kde stačí v IPv6 normálně poslat UDP paket, tam se ve světě IPv4 tunelovat minimálně tři firewally s pomocí serveru.
Kde se v IPv4 u ISP eviduje, kdo, kdy, z které IP adresy lezl na který server lezl kvůli policjtům, tam v IPv6 stačí mít uloženou tabulku prefix-zákazník.
Není potřeba se drbat s maškarádováním a šibovat s portama na routeru, prostě použiju adresu toho serveru.
A další "drobnosti"
Je rozdíl, jestli o tom člověk neví, nebo jestli o tom ví a ignoruje to.
Rozhodně lidem není jedno, že si připlácí za čmoud tam, kde by nemuseli (v ceně výrobků s konektivitou). Co jsem se ptal 10 lidí v okolí, jestli by si koupili zvonek ke dveřím s kamerou, který komunikuje s mobilem napřímo, nebo stejný produkt s komunikací přes čmoud a s příplatkem, tak všichni preferovali to první.
A zkus si představit situaci, kdy má účetní a samoživitelka se dvěma dětma v jedné osobě během tří dnů dodat nějaký papíry na finančák pod hrozbou flastru, ale musí zůstat doma s nemocným děckem. Pokusí se nahodit VPN z domova, ale kolidují privátní sítě. Nechal bys ji vrtat se u ní doma v routeru, když tomu nerozumí, nebo změníš adresování ve firmě? Podotýkám, že v takové situaci zmínka před ní o tom, že je to všechno funguje jak má, automaticky znamená, že ti udělá z hlavy leknín.
"Co jsem se ptal 10 lidí v okolí, jestli by si koupili zvonek ke dveřím s kamerou, který komunikuje s mobilem napřímo, nebo stejný produkt s komunikací přes čmoud a s příplatkem, tak všichni preferovali to první."
Jak by to fungovalo bez čmoudu? Domácnost by si platila doménu a zvonek s kamerou by měl vlastní subdoménu, takže by stačilo do mobilu zadat třeba "zvonek.prastena45-brno.cz" a už by se komunikovalo se zvonkem? Nebo by se zvonek s mobilem spároval třeba přes QR kód na displeji zvonku? Či přes nějakou funkci routeru, který by mobilu prozradil adresu zvonku? Jak by tohle probíhalo s minimální asistencí uživatele?
Jak by to fungovalo v ideálním světě? Pokud by uživatel neměl svou doménu, dostal by nějakou doménu n-tého řádu od ISP (stejně, jako dříve ISP poskytovali e-mailové schránky nebo webhosting). Doména by byla zaregistrovaná na domácím routeru. V okamžiku, kdy se do sítě připojí nové zařízení, by router v administraci zobrazil informace o tomto zařízení (typ, zařízení apod.), zeptal by se, zda má zařízení zapojit do domácí sítě, a dovolil by změnit DNS název. Ten by pak zaregistroval v DNS a buď by umožnil do DNS přidat výzvu pro vystavení certifikátu, nebo by sám vystavení certifikátu pro to zařízení zprostředkoval.
Protokoly pro všechny nutné operace už existují, i když něco by se třeba dalo zefektivnit. ISP vám doménu k přípojce zatím neposkytne, ale v tuhle chvíli by tohle používali stejně jen early adopters, kteří doménu stejně mají. Chybí software v routerech, který by se postaral o tu administraci domácích zařízení. Bylo by hezké, kdyby se tímhle směrem vydal třeba Turris Omnia. A pak by samozřejmě byla potřeba podpora v těch zařízeních, aby se primárně nesnažila komunikovat s nějakým cloudem, ale aby počítala s tím, že se mají primárně zaregistrovat do domácí sítě.
Připojím zvonek do LAN a instaluju do mobilu aplikaci. Kliknu v ní na "vyhledat" a očuchá síť pomocí mDNS, zobrazí zvonky a vybereš si, se kterým ji spáruješ. Naváže se spojení a vymění si klíče, proběhne konfigurace a uloží si IP adresy protistrany. To funguje v lokální síti úplně stejně na IPv4 i IPv6.
Pokud se s mobilem dostaneš mimo vlastní síť a máš spuštěnou aplikaci, může použít třeba RFC6275 (netuším, jestli už je novější náhrada), nebo se připojit a říct napřímo "hele, zvonku, teď poslouchám na adrese X".
Když zazvoní návštěva, naváže zvonek normální TCP spojení s naposledy známou adresou. Pokud vypadne spojení nebo nedokáže najít protistranu, tak je to stejný, jako když u klasickýho zvonku není nikdo doma. Návštěva se nedozvoní a buďto volá na mobil, nebo odchází. Takže robustnější mechanismus v tomhle případně není potřeba.
Tahle vaše domněnka byla vyvrácena ve všech předchozích diskusích o IPv6.
Zjednodušeně řečeno – když rozšíříte adresní prostor, musíte upravit i další věci. Např. přidělování adres v síti, protože do ARP paketu prostě větší adresu nenarvete, do DNS A záznamu také ne. Takže pro přidělování adres bylo potřeba vytvořit nový protokol. No a přidělování IP adres je v IPv6 řešené lépe, než v IPv4.
Nic jiného se nezměnilo nebo nezavedlo navíc, jako povinné.
Navíc když se mění protokol a stejně se to musí implementovat znovu, je to unikátní příležitost opravit věci, které se moc nepovedly. Nikdy jindy už k tomu příležitost nebude.
Např. přidělování adres v síti, protože do ARP paketu prostě větší adresu nenarvete
Zrovna v ARP by problém nebyl, protože byl navržen natolik prozíravě, aby si poradil s obecnou délkou adresy. V praxi tedy "jen" do 255B, ale to by pro tento účel bohatě stačilo. To, že bylo pro IPv6 zvoleno odlišné řešení, mělo jiné důvody.
Po letech zkušeností s IPv6* musím říct, že největší problém ohledně IPv6 adres pro BFU je ten, že o nich nic neví. Router se nastaví pomocí DHCP PD, koncový zařízení se nakonfiguruje pomocí SLAAC, data dostane pomocí RA. Stačí spojit kabely a jede to samo.
Problém je, jenom když to ISP zmrší a musí se to dělat jinak, než podle standardů (přidělení /64 nebo míň, různý firewally, NAT66 a podobný kosočtvercoviny).
*) Mám doma VDSL od T-Mobile, nativně, s prefixem /56 - tak jak to tehdy navrhl Radek Zajíc. A jediný, co jsem nastavoval, tak hinty pro VLANy
To neví kolikrát ani "ajťáci", když se domnívají, že na L3 ISO/OSI modelu můžou rozhodnou, jestli jde z pohledu aplikace o legitimní provoz a že NAT to nějak zázračně vyvěští. Přitom tohle je až v kompetenci L5 a výš. Přitom NAT ani nevyvěští, kam poslat příchozí paket, pokud nemá v poznámkách, kdo se s tím serverem bavil...
L3 (IP) má jediný úkol. Doručit data z jednoho bodu na jiný a NAT jaksi jde proti tomu. L4 má řešit výpadky dat, fragmentaci do paketů atd. (TCP, UDP,...).
Maximum filtrace, co jde na L3/L4 rozumně udělat, je říct, že ze sítě A se nesmí navazovat spojení do stě B, nebo že síť C vůbec nebude akceptovat porty pro třeba SSH, NFS, SMB a DRP z vnější sítě. To ale řeší firewall a jeho pravidla, ne NAT.
Co s adresami děláš, že potřebuješ kalkulačku? Já občas používám ipcalc pro IPv4 adresy (typu "jaký je rozsah pro 10.1.2.57/28) a tam mi přijde že šestnáctkový zápis naopak bude lépe řešitelný z hlavy.
Asi jediný případ, kdy jsem potřeboval převádět z/do desítkové, byla síť na matfyzu, kde admini přidělovali IPv6 = poslední číslo je nejnižší bajt IPv4 adresy. Ale ne "zápisem" ale fakt "binárně" - tj. např. 195.113.20.16 má IPv6 adresu 2001:718:1e03:801::10.
Tak, muze si to IPko volat jako "2001:718:1e03:801::0.0.0.16".
Coz mne privadi k tomu, ze tam mohl dat rovnou cely IPko, t.j.
"2001:718:1e03:801::c371:1410") a volat si to pak jako:
"2001:718:1e03:801::195.113.20.16".
Zapis v hexa je jen forma zapisu. Na bajtech to nic nemeni.
(nekolik EDITu ve snaze zbavit se ty vlozeny pomlcky uprostred adresy, kterou mi tam vklada formular)
13. 6. 2024, 11:35 editováno autorem komentáře
Coz mne privadi k tomu, ze tam mohl dat rovnou cely IPko, t.j. "2001:718:1e03:801::c371:1410") a volat si to pak jako: "2001:718:1e03:801::195.113.20.16".
To je koneckonců i důvod, proč tahle méně známá varianta textové formy IPv6 adresy existuje: pro praktický zápis adres, kde dolních 32 bitů reprezentuje IPv4 adresu.
No o tom mluví už dost let, ale žádný velký posun tady https://stats.labs.apnic.net/ipv6/CN není vidět. Je možný, že to jenom není vidět za tím jejich firewallem.
Ekvivalent platí minimálně celé EU (nařízení o síťové neutralitě) a pokud regulátor funguje na principu "stěžuj si, já rozhodnu"...
Btw, nebylo by špatný, kdyby se redaktoři z Rootu nebo z Lupy pokusili vyzpovídat ČTÚ, jak to je se síťovou neutralitou a blokováním legitimního provozu po IPv6. Bylo by to zajímavý počteníčko...
Problem s temy SRV je beztak o tom, ze to tam moc nevyskalujete. Ano, na serverove strane teoreticky vytriskate potencial jedne IP az na dren, ale klienty za (CG)NATy to nezachrani a moc jim to nepomuze. Hadejte, proc ISP klientum za temi preklady krom jineho omezuji i pocet soubeznych spojeni.. ? No protoze tech portu je proste malo ;-)
Neřekl bych. IPv6 je velmi jednoduchý protokol, který funguje vlastně stejně jako IPv4 a naopak některé složitosti úplně ruší. Třeba zjednodušuje hlavičku a vyhazuje položky, které se ukázaly být zbytečnými.
Samozřejmě je třeba řešit některé věci, které se v IPv4 neřešily nikdy, třeba přidělování veřejných adres v privátní síti nebo přiřazování celých bloků adres pro jednotlivé sítě. Tohle IPv4 neřešila, protože nikdy nebylo tolik adres, aby se automatizovaně přidělovaly po celých blocích.
Postupně během těch třiceti let pak vznikla spousta dalších mechanismů, zejména kvůli přechodu z IPv4. Kdyby se to mohlo přepnout střihem, tak by většina dalších navazujících protokolů a RFC nebylo vůbec potřeba.
Hlavní problém nedostatku IPv4 adres a potřeby nasadit IPv6 je na straně provozovatelů služeb a infrastruktury. Tedy datacenter, různých portálů, poskytovatelů VPS, cloudu a podobně. Tihle mají s nedostatkem adres problém, nemají kde brát a musejí nakupovat. Vidět je to třeba i v cloudech, kde se začaly za adresy platit měsíční poplatky. Tohle pocítí každý, kdo má někde třeba jen VPS.
Aby se tohle mohlo odbourat, musejí mít k IPv6 přístup koncoví uživatelé. Pak se může stará a problémová IPv4 zahodit a pojedeme v klidu na IPv6, kde je adres dost. Jenže celá tahle věc pálí segment služeb, ale ne segment uživatelský. Ten napíše „my máme adres dost“ a neřeší to.
Připomíná to problém občiny, kdy část společnosti pokrčí rameny „nám to nevadí“ a neřeší to. V případě IPv6 potřebujeme, aby přešli všichni. Pálí to ve skutečnosti jen část světa a ta druhá část nemá přímou motivaci to řešit.
Naštěstí se to sune správným směrem, letos bychom globálně měli přesáhnout 50% penetraci. Třeba Německo a Francie jsou ale už kus přes 70 %. Česko se pohybuje okolo 27 % a až to spustí T-Mobile a dotáhne Vodafone, půjdeme taky prudce nahoru. Ono se to poddá, jen to bohužel trvá velmi dlouho.
Dobrá věc se prodává sama.
===
Děkuji za obsáhlou reakci.
Ze zkušenosti vím, že dobré věci lidé rychle přijímají a špatné odmítají. Platí to zcela obecně a myslím, že to může být příčina i u IPv6.
Netvrdím, že jsem IT specialista, ale u IPv6 mě třeba jako technika zarazila délka adres. U IPv6 je 128 bitů dlouhá adresa oproti 32 bitům dlouhé adrese u IPv4. To znamená, že tvůrci standardu nezvětšili adresní prostor 128/32 = 4-krát, ale zvětšili jej 2^(128-32) = 2^96 = 8*10^28-krát. To už se pak spíše pohybujeme okolo těžko představitelného nekonečna, než kolem běžně představitelných a zapamatovatelných čísel. Systém s těžko zapamatovatelnými adresami se špatně spravuje a stává se obtížně řiditelným. Třeba právě tato skutečnost mi implikuje, že standard IPv6 nevytvářeli prvotřídní technici, ale jen jakási druhá liga. A ta se pak diví, že jejich "skvělý počin" ti "hloupí uživatelé a správci" nechápou a nechtějí.
Kdokoliv měl možnost přijít s lepším řešením. Místo toho se desítky let rozvíjí tohle, takže bych řekl, že nikdo jiný nic lepšího nevymyslel. Kdyby to bylo tak jednoduché, tak je to přece dávno vyřešené, IPv6 se zahodilo a během půl roku jsme si všichni nasadili ten hypotetický lepší standard. Nestalo se.
S tou délkou adresy je to celkem logické. Nemá smysl dělat tak složitou věc a přidat tam jeden bajt, protože by to nestačilo. Cílem bylo zbavit se překladu adres a podobných komplikací a zůstat u jednoduché směrované sítě. Pro tu ale potřebujete dostatek adres.
Kolik je ale dostatek? Když o tom budete přemýšlet v roce 1995, asi něco vymyslíte. Ale počítal jste už tehdy s mobilními telefony, chytrými domácnostmi, cloudem, virtuálními servery a dalšími věcmi, které přišly za dvacet let?
Proto bylo lepší a rozumné navrhnout nový adresní prostor obrovský, protože jsme dávno přišli na to, že ten předchozí obrovský prostor nestačil. V 70. letech se zdály být čtyři miliardy adres jako obrovské nekonečné číslo a byla to chyba. Byl by nesmysl tu chybu opakovat znovu. Ten protokol není navrhován na příštích pět let, ale na desetiletí a možná na staletí.
Špatně zapamatovatelné adresy jsou jen výmluva. Kvůli špatně zapamatovatelným adresám tu máme DNS – už nějakých 40 let. Pokud tím někdo argumentuje u místní sítě, tam může naopak díky velikosti prostoru IPv6 použít takovou strukturu, že pro něj bude jednodušší si adresy zapamatovat – když to teda k něčemu bude potřebovat.
To, že byl zvolen tak obrovský prostor adres, je správně. Poučení z přechodu z IPv4 na IPv6 je, že už to nikdy nechceme dělat. Adresní prostor nestačilo zvětšit tak, aby nám podle našich představ vydržel sto let a ve skutečnosti bylo potřeba řešit další změnu protokolu za 50 let, protože se stane něco, s čím nepočítáme. Ten adresní prostor bylo potřeba zvětšit tak, aby i když těch nečekaných událostí, které potřebu adresního prostoru najednou nafouknou, bylo deset, pořád ještě tam bude spousta místa. Pracujeme nejenom se známými neznámými, ale byla snaha to připravit i na neznámé neznámé. Takže je naprosto v pořádku, že se zvolil absurdně velký adresní prostor.
Díky to obrovské velikosti adresního prostoru IPv6 je možné také to, že se dnes přiděluje jen z malinké části dostupného prostoru. Pokud se v budoucnosti ukáže, že způsob přidělování je špatně, prostě se vezme další část adresního prostoru a z ní se začne přidělovat jinak. Což je přesně to, co pořád opakují odpůrci IPv6 – „mělo se to udělat nějak jednodušeji, bez velkých změn“. Ano, přesně to IPv6 do budoucna umožňuje – přejít na novou verzi protokolu, aniž by se musel měnit ten základ, tedy především velikost adresy.
Takže současné problémy s přechodem z IPv4 na IPv6, to, jak to trvá dlouho a jak se to odkládá, ukazují, že navrhnout IPv6 tak, aby se takový přechod už nikdy dělat nemusel, bylo správné rozhodnutí.
Ze zkušenosti vím, že dobré věci lidé rychle přijímají a špatné odmítají.
Tak takovou zkušenost vám závidím. Abychom nechodili daleko a nezabředávali do politiky, tak např. moje zkušenost z linuxových diskusních fór je, že navrhnete-li uživateli více možností, jak řešit problém, většina si spolehlivě vybere tu nejhorší.
No a pokud jde o operační systémy, většina si vybere prapravnuka CP/M s naroubovaným GUI, telemetrií, vestavěnou reklamou a miliardou obechávek třeba na to, aby tam šlo mít několik uživatelských profilů. A to i když třeba v kanclu se může střídat několik uživatelů u jednoho stroje a spíš, než diskety, je středobodem dnešního IT vesmíru čmoud jak za doby mainframů na UNIXu a terminálů.
Nebo procesory - dodneška se používá 8051, i když hardwarově podporuje max. 128B plnohonotné RAMky a má sedm různých, nezáměnných adresních prostorů, kde se některý překrývají. Oproti třeba krásně jednoduché H8...
Krásná je i 8086 v 16b režimu se segmentováním adres. A následnýma kulišárnama jako EMS pro větší paměti, než 1MB. Být tam MC68k, to by bylo ušetřených psychofarmak pro progamátory, co mají ve stroji 4MB RAM, potřebují pro aplikaci 2MB, ale vidí jenom 640 kB.
A nakonec svět 8086 dopadl tak, že se překládají instrukce ze strojáku CISCovýho procesoru na RISCový rutinky... Protože Intelí architektury vždycky stály za hnědý mazlavý a tunilo se to jak o život. Nakonec se používá všechnokromě toho, s čím se furt drží zpětná kompatibilita, protože ten základ stejně dávno vyhnil a v prach se rozpadnul.
K těm 128 bitům, má to svoje opodstatnění.
16 bitů jsou jednotlivý bloky, ze kterých se bere. V případě, že se to dělá blbě, je to rezerva pro začátek se stejnou délkou, ale líp.
Každý blok má 13 bitů (jsme na /29), co se přiděluje poskytovatelům připojení. V těch 13 bitech je kontinent a rozlišení poskytovatele.
Poskytovatel má dát zákazníkovi /48 nebo /56 (firma nebo koncák). Má pro sebe 19 (nebo 27) bitů na rozlišení zákazníka a na organizaci sítě - třeba 5b pro město, 7b pro městskou část/vesnici,... To je na něm, jak to využije. 0.5m firemních zákazníků mu asi vydrží hodně dlouhou dobu, a to jedna firma sežere tolik, co 256 koncáků. Bylo to plánováno tak, aby mohl udělat strom z routerů a přidávat další bity pro další úrovně.
Pro firmu je výsledek 128-48 = 80b. Síť je 64b, takže IT oddělení dostane 16b pro svou režii. Třeba hierarchicky - budova, oddělení,... A něco jako rezerva, kdyby firma rostla. Odpovídá to kapacitně přesně na X a Y v 10.X.Y.Z v IPv4
Koncák dostane pro svou potřebu 72b. Z toho si může udělat 256 sítí. Asi to hned všechno nevyužije, ale hodí se to. Třeba strýc měl velkou zahradu a postavil na ní barák dceři. S takovým prefixem nemusí řešit další přípojku, jenom zapojí routery do kaskády a tomu dalšímu deleguje /57. Navíc to dává i prostor pro oddělení sítí. Může třeba za pár let vyjít nějaký předpis, že IoT věci musí být v oddělené síti a naajednou se ty bity hodí.
No a jedna síť je 64b. Pro to je zase dobrý důvod - adresy nejsou na syslení u ISPíka, ale na to, aby je měl k dispozici koncový zákazník, který na ně věší zařízení a nemusel řešit jejich nedostatek. 64b krásně vyjde do registrů procesoru, takže se s nima dobře pracuje. ROuter bere jako konstantu dolních 64b (ty se uplatní v koncové síti), zařízení v síti má konstantní prefix a řeší si dolních 64b. Jednoduchý, rychlý, elegantní, s velkou rezervou pro zákazníka. Co víc si přát...
Vedla se spousta diskusí o tom, že je IPv6 špatné – ale ve všech případech se dospělo k tomu, že ostatní varianty jsou buď horší nebo srovnatelné.
Problém je v tom, že je to klasická externalita – tedy náklady s provozem IPv4 platí někdo jiný, než kdo může zvětšovat zastoupení IPv6. Největší náklady na IPv4 mají poskytovatelé služeb, rozšíření ale brání hlavně zastoupení mezi koncovými klienty, případně jejich ISP.
Problém taky je, že většina diskutujících nemá tušení, jak fungují IP sítě. Je to jako s jinými problémy: pokud o nich nevíte dost, zdají se vám snadná řešení jako dostatečná a odborníky máte za podivíny hledající složitá řešení.
Pokud o tom víte dost a začnete na základě skutečných znalostí vymýšlet novou verzi protokolu IP, dojdete nakonec stejně k něčemu, co bude hodně připomínat IPv6. Jednoduchá řešení totiž neexistují. Kdyby existovala, dávno bychom je používali, protože by se snadno prosadila.
Já jsem si jako zhruba desetileté dítě kreslil ponorky na základě silného zážitku z knihy 20 000 mil pod mořem. Stačil papír a tužka a za chvíli byly kompletní plány ponorky hotové. Je to naprosto jednoduchá věc, navrhnout ponorku umím i dnes. Trvá to tak patnáct minut komplet i s namalovanými postelemi a rozvrženými skříněmi. Vůbec nechápu, proč s tím inženýři tráví tolik času.
Pravda. Nás zkoušeli z ISO/OSI modelu ve druháku na elektro průmce (jestli dobře počítám, tak to vychází na 1996). A nikdy bych nečekal, že někdo z oboru bude chtít na síťové vrstvě, která má zajistit popojení všeho nezávisle na lince, médiu a datech, rozhodovat o tom, jestli se připojuje oprávněný nebo neoprávněný klient. Já bych tam ty data prostě doručil a jestli je využít nebo zahodit, to ať si rozhodne prezentační nebo aplikační vrstva...
To samý, když se na síťové vrstvě, zodpovědné za propojení všeho se vším, někdo snaží obhajovat mechanismus, který to sabotuje.
Ne, není.
Problém je jenom v tom, že pokud roky člověk něco používá, vytvoří se mu fyzicky dráhy v mozku a bere to jako intuitivní a samozřejmou věc. Tohle bylo třeba s přechodem na OOP, znám plno lidí, co se z C nikdy nedostali na C++ a objekty nenávidí. Když si na YT pustím namátkově nějaký video o Rustu, vždycky je na začátku upozornění, že je potřeba myslet jinak,...
No a tady máme nějaký jedince, kteří mají něco zažitýho a změna by je stála mrtě energie a brání se tomu. Proti nim jde jenom zákazník (který tomu nerozumí, nebo ani neví, že to existuje), nebo manažer, kterýmu "vysvětlí, že je to špatně" a jedou si furt dál postaru.
Tam je fakt potřeba externí kopanec, který bude mít tolik energie, aby je donutil začít něco dělat. Bylo by naivní čekat, že se do toho pustí sami.
Mimochodem, našel jsem zajímavou věc:
Zákon 128/2005Sb, § 62
(1) Osoba vykonávající komunikační činnost je povinna používat pro poskytování služeb, určování technických rozhraní a síťových funkcí v míře nezbytně nutné pro zabezpečení interoperability a bezpečnosti služeb, spojení mezi koncovými body, usnadnění změny poskytovatele a přenositelnosti čísel a k rozšíření možností výběru pro uživatele normy a specifikace, jejichž seznam je uveřejňován v Úředním věstníku Evropské unie jako základ pro podporu harmonizovaného zajišťování sítí elektronických komunikací, poskytování služeb elektronických komunikací, přiřazených prostředků a přiřazených služeb, spojení mezi koncovými body, usnadnění změny poskytovatele a přenositelnosti čísel.
(2) Pokud normy nebo specifikace podle odstavce 1 nebyly uveřejněny, použijí se normy nebo specifikace přijaté evropskými organizacemi pro normalizaci. Pokud takové normy a specifikace neexistují, použijí se přiměřeně mezinárodní normy nebo doporučení přijatá Mezinárodní telekomunikační unií (ITU), Evropskou konferencí správ pošt a telekomunikací (CEPT), Mezinárodní organizací pro normalizaci (ISO) nebo Mezinárodní elektrotechnickou komisí (IEC).
I zkusil jsem vyhledávat věstníky a vypadly krásný věci, jako odst. 23 v https://eur-lex.europa.eu/legal-content/CS/TXT/HTML/?uri=OJ:L:2019:151:FULL&from=CS :
Veřejné jádro otevřeného internetu, tedy hlavní protokoly a infrastruktura, jež jsou globálním veřejným statkem, zajišťuje základní funkci internetu jako celku a je základem pro jeho běžný provoz. Agentura ENISA by měla podpořit bezpečnost veřejného jádra otevřeného internetu a stabilitu jeho fungování, včetně klíčových protokolů (zejména DNS, BGP, a IPv6), provozu systému doménových jmen (včetně provozu všech domén na vrcholné úrovni) a provozu root zone.
Nevím, ja vy, ale já z toho mám pocit, že ISPík má povinnost používat protokoly, který řekne EU a definují standardizační organizace. A věstník se zmiňuje o IPv6 dokonce jako o strategickým protokolu, klíčovým pro fungování internetu. A to už před pěti lety. A tenhle věstník vyšel už před pěti lety... Je ostuda ISPíků, že IPv6 ještě nemají k dispozici všichni. A ostuda úřadů, že nepokutují porušování zákona.
18. 6. 2024, 18:11 editováno autorem komentáře
Je to ostuda konkretnich ISPku, ale neplati to vseobecne. Muj domaci ISP mi IPv6 pridelil, u rodicu mam kabelovku a DS-lite me tam nikterak neurazi a u tchyne jsem na pritomnost IPv6 prisel s vymenou muzejniho routeru za jednickoveho Turrise, co chtel nekdo uz vyhodit :D A i v mobilu jsem se dockal...
Realne mi doma dela provoz po IPv6 uz vic, nez na IPv4 - a to jen diky par IPv4-only sluzbam treba tem od statni spravy. A tam tech "narizeni vlady" mame hned nekolik... presto se na ne houfne kasle.
Jasně, stálo by je to prý mrtě peněz. Kdybyten čas, co hledají rovnáky na ohybáky v IPv4 použili na zavedení IPv6, mají to už dávno.
Já mám doma nativní IPv6 přes T-Mobile VDSL s jejich ZyXELem do bridge a jedničkovým Turrisem za tím a šlape to jak víno. Když se dva roky zpátky kouslo DHCP a stroje neměly 4-kový adresy, zjistil jsem to až když večer manželka nadávala, že jí nejede IPTV ve chvíli, když jsem chtěl něco stahovat z Githubu. Všechno ostatní jelo úplně normálně.
A teď máme TV na Androidu a díval jsem se, že si ten krám sosnul i šestkovou adresu. Takže jediná věc, která už ve vnitřní síti nechodí na IPv6, je starý managovaný stovkový switch v pracovně. Resp. jeho management, protože pracuje na L2 a IP protokol je na L3, takže šestka projde v pohodě. Ale s tím management rozhraním se dá žít...
Ale mobil mám u TM, takže tam šestka nehrozí :( Vánoční dotaz, jestli si od nich vezmu nový mobil nebo sluchátka jsem zahrál do autu s tím, že nejhezčí dárek by byla šestka v mobilu, abych se konečně dostal do vnitřní sítě. Nechápali, která páčka :(