Co pořád máte s tou IPv6? Jenom sebevrah připojí každé své lokální zařízení přímo na WAN. Bez NAT, hw firewallu či alternativy to nikdo svéprávný neudělá.
Pamatuji, že jsem někdy před mileniem pročítal nějaké texty(už si nepamatuji kde, které) a v nich se počítalo, že IPv6 bude hlavně pro nové oblasti (Asie, Afrika) a že starý svět pojede na IPv4.
Hlavně když IPv6 nic nového kromě množství IP adres nic nepřináší. V těch rozvíjejíchc světových světadílech se počítalo s velkým množstvím IP.
PS. připomínám fakt, že pokud vám doma skončí IPv4 všechna starší zařízení smartTV, VoiP telefony, sítové tiskárny, tablety, web kamery, set-top-boxy, satelity DVT-S, apod.. které nepodporují IPv6 můžete vyhodit. Tedy za předpokladu, že nebudete mít nějaký router který bude podporovat paralelně oba protokoly najednou v rámci vaší LAN ale kdoví jak to bude pak s překladem požadavku z IPv4 na IPv6 do WAN.
A to ani nemluvím o tom, že 60% populace ČR vůbec netuší že něco jako IP existuje.
Nedostatek adres trápí především provozovatele služeb. Adresy jsou příplatková služba a bude se to zhoršovat – za poslední dva roky vyletěla cena na burzách na dvojnásobek. Přitom velká většina infrastruktury je na IPv6 dávno připravena a stojí to na uživatelích. Jakmile uživatelé budou schopni přistupovat ke službám po IPv6, může se čtyřka zahodit a všichni si oddechnou, protože ke své službě dostanou libovolný počet adres. Tak už je to dnes, ale bez čtyřky se ještě pro uživatele fungovat nedá.
Třeba Facebook se rád chlubí tím, že ve svých datacentrech už vůbec IPv4 nemá a překládá do ní jen na okraji sítě pro uživatele, kteří přijdou právě po čtyřce. Podobně to můžete zařídit třeba s CloudFlare – vaše služba běží kompletně na šestce a pro čtyřkové uživatele máte CDN, která umí oba protokoly.
Trapi to nove potencionalni poskytovatele sluzeb, ti soucasni uz IP adresy maji a radi se s nimi za priplatek podeli. Jedinou nasilnou moznost, jak prejit na IPv6 je zdrazit registraci IPv4 natolik, ze se to nevyplati a i tak si myslim, ze dokud to pujde, tak se bude prechazet na (CG)NAT.
Druha vec je, ze treba prejitim na IPv6 u nekterych poskytovatelu ztratite moznost mit verejnou IPv4, takze proc by to nekdo delal ?
8. 6. 2021, 12:00 editováno autorem komentáře
Myslím, že je to taková domněnka, že IPv4 adresy velcí poskytovatelé mají a mají jich dostatek. Ano, mají jich dostatek, protože překotně adresy skupují, ale tempem, jakým se adresy konzumují ani to skupování není udržitelná strategie.
Třeba AWS má přes 100 milionů IPv4 adres a tu a tam přikoupí několik dalších milionů. To se rozebíralo např. zde: https://news.ycombinator.com/item?id=24839887
Faktem je, že právě Amazon IPv6 postupně zavádí na více a více službách. Kdyby o to nebyl zájem/ kdyby to nepotřebovali, tak by to nedělali - zrovna Amazon je silně zaměřený na to, co zákazníci vyžadují a jsou za to ochotní platit/ kvůli tomu službu používat.
Amazon zavádí IPv6 inkrementálně a ano, spousta jeho služeb IPv6 nepodporuje vůbec. Zatím.
I varianta "dual-stack" je ale krok vpřed, protože umožňuje např. z EC2 instance s IPv6 přistupovat k cílům, které jsou v IPv4 světě "za NATem" nebo "nedostupné". Podobně umožňuje přistupovat ke službám nasazeným na AWS z IPv6-only prostředí. I takhle přispívá k řešení "nedostatku IPv4 adres". Amazon tenhle nedostatek netrápí, druhou stranu spojení ale třeba ano.
Snaha Amazonu je nahamounit maximum IPv4 adres a použít je v čmoudu pro IoT a podobně. Pokud totiž člověk chce fungovat v IPv4 světě s dvojicí zařízení mimo vlastní síť, potřebuje mít stroj s veřejnou IPv4, nebo někoho, kdo tím disponuje...
Dual stack zavádí jenom proto, že třeba US mobilní operátoři dávají 6ku nativně a zjistili, že můžou jejich služby zákazníci používat i jako bridge mazi strojem za 4kovým NATem a 6kovým mobilem. A některý jejich služby ve světě IPv6 moc nedávají smysl...
No a to je jedna z nejčastějších chybných domněnek pramenících v 20 let zastaralých představách o počítačových sítích. Je totiž jaksi potřeba ustoupit z původní představy, že má vnitřní síť je bezpečné hradní nádvoří a všichni ti škaredí a zlí útočníci jsou někde na druhé straně hradního příkopu.
Útoky mohou totiž snadno přicházet zevnitř sítě. A nemusí to být nutně přímo útočník, který se napojil přes WiFi, bohatě stačí přinést si domů zavirovaný mobil.
Zabezpečit je potřeba každé připojené zařízení a nespoléhat se jen na jeden hraniční firewall.
Jenomže on má do jisté míry pravdu. Drtivé většině koncových uživatelů to skutečně je naprosto jedno. A NAT si stejně vyrobím už prostě proto, abych měl za firewallem (tedy za jednou zafirewallovanou gateway) celou síť, kde běží spoustu dalších služeb, nad jejich zabezpečením nemám vůbec žádnou kontrolu. O ten NAT jako takový přílši nejde.
V čem bude přesně jednodušší? Samozřejmě, že firewall může fungovat pro IPv6 stejně jako pro IPv4. To ale na věci nic nemění. V okamžiku, kdy jsem za NAT, co vyblokuju firewallem před NAT je vyblokované pro celou síť. A to drtivé většině lidí prostě stačí. To je celé. A je to naprosto primitivní.
Že to bez překladu bude jednodušší a přehlednější atokonto opravdu není pravda. To platí pouze pokud potřebujete nějakou speciální konfiguraci. Jenomže to většinu lidí fakt nezajímá. Hřebík, kladivo, hotovo. Stačí.
To, co vy považujete za "škody" někdo jiný může celkem efektivně považovat za jistý způsob primitivního dostatečně efektivního řešení. Proto taky ten přechod probíhá pomalu. Protože na úrovní SOHO řešení poptávka prostě není. To, co je, stačí. Chápete to už konečně?
Nikdo netvrdí, že je to ideální. Je to prostě jen pro velkou část případů užití dostatečné. (A kdy jsem se narodil pochopitelně psát nebudu, to se nezlobte.)
"Protože na úrovní SOHO řešení poptávka prostě není."
Je poptávka po tom, aby věci fungovali. Ale není povědomí o tom, jak to udělat jednoduše a správně, tak se NATuje, tuneluje a udržuej otevřený socket ze dvou stran na prostředníka někde v Tramtárii místo toho, aby dva stroje prostě nahodily IPSEC tunel mezi sebou ve chvíli, kdy je to potřeba. A živíš na to další tři zbytečný stroje - CGNAT, prostředníka a druhý CGNAT.
V čem bude přesně jednodušší? Samozřejmě, že firewall může fungovat pro IPv6 stejně jako pro IPv4. To ale na věci nic nemění. V okamžiku, kdy jsem za NAT, co vyblokuju firewallem před NAT je vyblokované pro celou síť. A to drtivé většině lidí prostě stačí. To je celé. A je to naprosto primitivní.
Ne, opravdu není. V obou případech musí být firewall. NAT je něco navíc, co tam být nemusí. Vyblokovat síť zvenčí dovnitř je na firewallu naprosto stejná práce na IPv4 i na IPv6 - konkrétně:
Policy: DROP
Allow: zevnitř ven
To se neliší ani jedním záhybem v hlavě.
Jednodušší a méně náchylné na chyby je to z toho důvodu, že nemusíte přemýšlet nad tím, v které fázi má packet už IP adresu přeloženou (NATEM) a v které ještě ne. Za NATEM děláte to samé pravidlo pro externí provoz a podruhé pro interní provoz. To je náchylné k chybě už při vytváření, ale hlavně je to náchylné ve chvíli, kdy přidáváte další interní segment nebo DMZ.
To tvrdíte vy, Miroslave. Technicky máte pravdu, ale nejste se schopen mentálně přenést na úroveň běžných uživatelů, které to víceméně nezajímá. To, co je triviální a stejné pro vás nebo pro mě není triviální pro ně.
Je to ostatně obecně něco, co mě tady na Rootu nikdy nepřestane překvapovat: ta neschopnost pochopit běžné uživatele velké části diskutujících. A pak se všichni diví, jak je možné, že přechod na to skvělé XYZ trvá tak dlouho. Jednoduše je to možné. Z hlediska pohledu běžných uživatelů to prostě není třeba. Protože těm stačí řešení možná méně ideální a složitější v abstraktním smyslu, ale jednodušší na pochopení. Jenomže zdejší geekové tohle nejsou schopni vidět.
@martinpoljak
Když si přečtete moje příspěvky na téma, tak si myslím, že tu mentalitu chápu, a dokonce razím i "kacířskou" tezi, že nová technologie si musí vydobýt své místo tím, že bude dávat smysl všem: poskytovatelům připojení, poskytovatelům služeb a obsahu, i uživatelům.
Stav, kdy je IPv6 něco nového, jiného, nepřinese žádnou závratnou výhodu, ale spíš okamžité (počáteční) problémy, považuji za krajně neuspokojivý a naprosto chápu, že IPv4 všem stačí. Strašáci v podobě "IPv4 je dražší", se jaksi opravdu neprojevují v praxi.
Až se tu objeví významná část ISP, kteří IPv4 budou poskytovat za výrazný příplatek, tak to bude jiná. Zatím si to nikdo proti konkurenci nedovolí - pro ISP je zatím levnější podporovat IPv4 - a tedy je to levnější i pro zákazníka. Dohoda mezi ISP o násilném přechodu na IPv6 není možná, byl by to učebnicový příklad kartelové dohody a ve výsledku by to poškodilo trh. Jakkoliv jsou někteří technici přesvědčeni o opaku.
Mám obavu, že nevíte, že běžní uživatelé ani neví nic o jakémsi NATu, IP, ethernetu apod. V 99% případů budou používat to, co jim dá poskytovatel. Když otevřou Google, Seznam a Facebook a bude jim chodit internetová televize, tak jsou v podstatě vysmátí. To je prostě realita.
Root.cz čtou spíše lidi, co to zajímá a co tomu buď rozumí, chtějí aspoň nějak rozumět nebo ti, co předstírají, že se chtějí poučit, ale vlastně hledají spíš potvrzení vlastní "pravdy", stejně jako v každé jiné diskuzi na internetu.
Tak jestli vám není jasné, že bez překladu to bude snažší, tak to asi vůbec nechápete. Chci povolit port pro jedno zařízení. Bez NATu mi to stačí nastavit ve firewallu přímo jenom pro to jedno konkrétní zařízení. S NATem musíte nastavit ten port i tam. A teď si představte, že máte těch zařízení např. s portem 80 v síti více a s NATem musíte udělat port forwarding a pouze jedno zařízení může z venku používat ten port 80.
Chápete, že je jedno jestli ten firewall blokuje kompletní IP adresu nebo jenom prefix více adres?
Ale mně to je jasné. Jenomže to pořád neznamená, že to znamená, že je smysluplné i pro toho běžnějšího uživatele. Pro toho je mentálně podstatně jednodušší prostě port zakázat nebo povolit v celé síti i když je to vlastně složitější technicky. Koncepčně je to primitivní a nic víc obvykle nepotřebuje.
Víte co, nechápejte to (já vlastně chápu proč to nechápete, ono to technicky nemá logiku ale to na věci nic nemění), ale pak se nedivte, že zářný svět IPv6 a čehokoliv dalšího prostě běžné uživatele vůbec nezajímá. Mají doma šroubovák a kladivo a to jim k zařízení toho, co potřebují stačí.
Nestačí to možná tak vám. Ale to na věci nic nemění.
Právě naopak pro uživatele je mnohem jednoduší pochopit, že na routeru mají firewall, který všechny příchozí spojení blokuje a že když chtějí něco mít dostupné z internetu, tak to stačí povolit ve firewallu. Chcete povolit nějaký port na všech zařízeních žádný problém stačí nastavit firewall. A teď jim to samé zkuste vysvětlit s NATem. Už slyším ty dotazy proč se ty adresy musí měnit a proč když mám adres 192.168.0.1, tak mi to ukazuje 82.82.0.54.
A ještě jednou NAT je jenom stupidní překlad jedné adresy na druhou nic víc nic míň nemá to s bezpečností nic společného.
Jenže tady nejde o uživatele (těm je to opravdu šumák, protože netuší, že tam něco jako IP adresa vůbec je), ale hlavně o poskytovatele, kteří nyní platí velké peníze za veřejné IPv4 i když by mohli mít veřejné IPv6 zadarmo. IPv6 only bude nakonec výhra pro všechny.
Pro toho je mentálně podstatně jednodušší prostě port zakázat nebo povolit v celé síti i když je to vlastně složitější technicky. Koncepčně je to primitivní a nic víc obvykle nepotřebuje.
Nic přeci nebrání výrobcům zařízení (krabiček, routerů), aby takto zjednodušenou správu udělali i na IPv6. Na IPv4+NAT je to technická nutnost, ale na IPv6 to není nijak vyloučené.
Dokonce by bylo docela prospěšné, kdyby se to stalo nepsaným standardem na přechodnou dobu, než lidé objeví nové možnosti.
Neodpustím si poznámku o tom, že stejná nevole byla, když přišli výrobci modemů a SOHO routerů s touto zjednodušenou správou pro NAT. Mnoho polo-lajko-šťouralo-profesionálů tehdy brblalo, jak je šílené nastavit router, když každý výrobce k tomu přistupuje jinak. Jeden jen podle portů, druhý pokročilejší konfigurací s nějakou vnitřní magií. Jeden to nazývá NAT, druhý PAT, třetí NAPT. Další zavádí označení DMZ. Někteří umožňují zapínat a vypínat aplikační helpery, jiní je mají nevypnutelné (a jiní nezapnutelné).
Nic přeci nebrání výrobcům zařízení (krabiček, routerů), aby takto zjednodušenou správu udělali i na IPv6
Výrobcům v tom "brání" cena. Místo 4kbit flashky tam budou muset dát 32kbit a místo SoC za 10 centů tam bude muset být soc za dolar aby se tam vůbec ty IPv6 adresy vešly a aby to to zařízení vůbec zvládlo s rozumnou propustností obsloužit. Pak bude muset najmout druhého vývojáře, protože znalosti toho současného píšícího to celé v JavaScriptu edice rok 1995 už na IPv6 nestačí. Takže ve výsledku router s designem klingonské bitevní lodě podporující Wifi7 nebude stát 500,- ale verze s podporou IPv6 bude za 2000,- a to si přece koncový uživatel nekoupí, protože ani neví, co to IPv6 je. (Tento text berte prosím s nadsázkou).
Tak jo, jenže on si uživatel koupí router za 4 stovky a ten má mizernou wifi, a tak si pořídí nějaký extender, a ten moc nepomůže... až si nakonec stejně koupí ten router za ~2 tisíce, kde už zase IPv6 obvykle je.
Kromě toho si významná část nic nekoupí, protože to dostanou od providera (O2, ... a u UPC ani není jiná možnost - no dostanou, mají pronajato). Ale tyhle routery/modemy už dost dlouho IPv6 mají a out-of-the-box fungující. Sice tam jsou mouchy (O2: máte prefix /64; UPC: sice máte /56, ale není jak to delegovat na další router, takže efektivně stejně máte /64).
Nicméně vám zařízení fungují a v lokální síti máte dual stack.
Já nechápu, proč tohle výrobci vyvíjejí (a asi všichni víme, že ten výsledek v SOHO routerech je velmi často strašný zprasek). Já kdybych dělal router, tak tam dám OpenWRT a nastavím to jejich „Luci pro BFU“ a ještě ušetřím, protože nebudu muset psát webové konfigurační rozhraní. No a OpenWRT samozřejmě IPv6 podporuje, a to i na historických routerech s 4 MB flash a 32 MB RAM, takže žádné dražší komponenty se nekonají.
Opravdu rád bych viděl router pro IPv4 s firmwarem, který se vejde do 512B FLASH. A ještě psaný v JavaScriptu.
Hlavně ty úvahy typu "na IPv6 by byl potřeba silnější (dražší) hardware zcela ignorují skutečnost, že za tu dobu, co se tenhle argument pořád dokola opakuje, se velikosti pamětí všeho druhu i výkony procesorů, které lze koupit za stejné peníze, narostly o několik řádů. Když jsem poprvé slyšel o tom, že se pracuje na nové verzi IP protokolu, měl jsem v počítači 4MB RAM a 80MB disk - a to tehdy patřilo k nadprůměru. Dneska mám přímo v procesoru 6MB L2 cache a 64MB L3 cache, RAM narostla o více než čtyři řády a diskový prostor o více než pět. Takže i kdyby bylo skutečně potřeba čtyřikrát víc paměti a čtyřikrát vyšší výkon procesoru (což ani jedno samozřejmě není pravda), bohatě by se v tom ztratilo.
Nemluvě o tom, že cena pamětí (a hardware vůbec) u konzumního routeru stejně tvoří poměrně malou část koncové ceny.
Jednodušší na straně provozovatele služby to bude v tom, že IPv4 nejsou a nemusí je shánět.
Jednodušší pro ISPíka to bude, že se nemusí starat o CGNAT a podobný pitomosti. Nemusí logovat, kdo kam lezl, prostě přidělí prefixy a když dojdou benga, sdělí, na koho je prefix psaný a hotovo. Taky může díky multicastu během olympiády ušetřit kapacitu uplinku a páteře.
Jednodušší pro výrobce IoT je to v tom, že nepotřebuje server, přes který se jeho výrobky domlouvají. Nemusí ho kupovat, živit, vyvíjet appku ani platit hotový řešení v čmoudu.
Jednodušší pro koncáka je to v případě, že chce něco rozchodit. Chceš se dostat na domácí NAS? Nepotřebuješ tunelovat porty a složitě konfigurovat NAT, jenom si blikneš QR kód s IP adresou a klíčem do mobilu a hotovo. Připojíš se odkudkoliv
Horší to mají zlí hoši. Není tam SPOF, který by vyřadil polovinu kamer ve městě tím, že se kamery přes NAT nepřipojí k DVR. Není tam jeden provozovatel služby, na kterýho by zaklekli chlápci v uniformách. A 128+16b se skenuje hůř, než 32+16b, že...
> Jak se bez serveru ty IoT výrobky najdou a nakonfigurují, aby to zvládl běžný uživatel?
Dnes na to zvyčajne používajú mDNS-SD. Používateľ si stiahne appku a tá má workflow, aby sa pripojila na SSID zariadenia, používateľ nastavil svoju wifi, zariadenie sa prehodí a appka nájde zariadenie v používateľovej sieti. Následne ho pridá do zoznamu používateľových aplikácií, ktoré môže ovládať. To všetko samozrejme mobilom; pre desktopové systémy sa SSID prehadzuje ručne, pripája na well-known ip adresu z browseru a cez browser nastaví SSID a prípadná statická ip adresa.
Tak to funguje pre IoT čo podporujú wifi. Tie, čo majú iné rádio, napríklad zigbee, tam je to väčšia sranda. Skenujú sa QR kódy na zariadeniach, stláčajú párovacie tlačidlá, atď.
Spárovat to jde i jinak - připojím to do sítě, připíchnu se s USB klíčenkou, zmáčknu tlačítko a zapíše se soubor s IP adresou a vygenerovaným tokenem pro přihlášení. Ten pak dá přechroupat prográmku v PC nebo v mobilu a je to. Pokud se to udělá dobře, tak se do zařízení nikdo bez fyzickýho přístupu k němu nebo bez platnýho tokenu nedostane.
Nachápu, jak se na základě dat od uživatele zlepšuje služba pro něj, když se výrobce neobtěžuje ani s bezpečnostním updatem a pokud vyjde nový FW, je většinou horší než ten starý. Ale pokud někdo věří, že svět bude hezčí, nikdo mu nebrání posílat jednou týdně výrobci report jako opt-in.
blbosť a NAT vždy bude potrebný,... už z princípu ako sieť funguje nemôže byť každé zariadenie pripojené na WAN. Neviem si predstaviť tlačiareň pripojenú do WAN a hocikto na nete by mi tlačil doma papiere, a firewall? To není úplne to isté a ani by v tomto nepomohlo... potrebuješ mať izolovanú (vnútornú) sieť v ktorej budú mať zariadenie prístup k iným zariadeniam v rámci tejto siete, ale nikto z WAN nebude mať prístup k zariadenia v tejto vnútornej siete, a to je čo NAT robí a veľmi dobre. Firewall je dobrá vec, ale toto nevyrieši, lebo v rámci vnútornej siete môžu pribúdať aj ubúdať zariadenia v čase sa rôznak pripájať, a teraz si predstav prekonfigurovávať firewall pre každé zariadenie zvlášť... to by sme dopadli. NAT toto perfektne rieši. Ono NAT a firewall riešia sieť z opačných koncov a dosť odlišne.
8. 6. 2021, 15:57 editováno autorem komentáře
„už z princípu ako sieť funguje nemôže byť každé zariadenie pripojené na WAN. Neviem si predstaviť tlačiareň pripojenú do WAN.“
Přestaň si myslet, že budeš mít tiskárnu zapojenou do WAN. Pořád to bude LAN, akorát s globálními veřejnými adresami. A to kdo se odkud kam dostane je jen a pouze záležitost firewallu.
To máte marné. Je to jako vysvětlovat proč jezdím do práce na koloběžce na serveru pro automobilisty. Lidé zde sítím rozumí a tak nerozumí, že pro někoho, kdo sítím nerozumí je NAT jako nástroj podstatně pochopitelnější takže když se pak ve výsledku zkombinuje s firewallem, je to pro něho jednoduché a bezpečné řešení, které je schopen triviálně a intuitivně chápat bez toho, aby se musel zabývat dalšími detaily.
martinpoljak: Co je na NATu pro běžné uživatele pochopitelné? Jak to může být lepé pochopitelné, než nic? Podle vás běžný uživatel snáze nastaví firewall+NAT než firewall? Nemyslím si, že tady nikdo kromě vás nerozumí tomu, jak běžní uživatelé přistupují k sítím. Zatím to spíš vypadá, že píšete nesmysly.
Zkusil bych to uvést na konkrétním příkladu. Uživatel má NAS s adresou 2001:db8::10. Chce na něj povolit HTTPS provoz z internetu. Povolí tedy na routeru komunikaci na 2001:db8::10 na port 443. Jak jednodušeji to nastaví, když na tom routeru bude mít i NAT?
Použije forwardované porty. To, že to nefunguje, není problém vyčerpání adres; neexistuje důvod, aby ISP nemohl každému říct „venkovní adresa je 1.2.3.4 a forwarduju vám porty 14520 až 14540“. Ten problém bude někde hlouběji a úplně vidím, jak po zavedení IPv6 budou běžné podobné zprasky: ISP bude blokovat příchozí provoz „protože bezpečnost“; ISP přidělí /120 (zdravíme do Wedosu); ISP přidělí _jednu_ adresu (třeba na mobilech přes PPP, protože datový tarif pro notebooky je dražší než datový tarif pro mobily). Atd.
To je jak s komunismem - když tu byl NAT (myšleno především masquerade) 20 let, tak bude dalších 20 let trvat, než se podaří jej z myšlení vymýtit. Soudobá představa, že NAT je něčím zcela přirozeným, co tu bylo vždy a nedá se bez toho obejít, mezitímco přímé adresování je zbytečností, výstřelkem, hipsterstvím či kratochvílí znuděných akademiků, přetrvává.
Lidé zde sítím rozumí a tak nerozumí, že pro někoho, kdo sítím nerozumí je NAT jako nástroj podstatně pochopitelnější takže když se pak ve výsledku zkombinuje s firewallem, je to pro něho jednoduché a bezpečné řešení, které je schopen triviálně a intuitivně chápat bez toho, aby se musel zabývat dalšími detaily.
Nechápu, co tím chcete říct. Abyste povolil provoz, musíte znát IP adresu, protokol a u některých protokolů port. Např.:
IPv4:
Veřejná IP adresa 195.88.64.12. Port tcp/80 povolit na vnitřní 172.16.0.1.
IPv6:
Veřejná IP adresa 2001:470:5a28:16::1 povolit port tcp/80.
Uživatel nemusí vůbec vědět, že existuje něco, co se nazývá "NAT" - ani v jednom případě. Prostě vidí informaci o tom, jaký provoz je povolený a jakou IP adresu má nahlásit protějškům. Pokud o pojem "NAT" zavadil, tak v tom může žít dál, i když přejde na IPv6 a NAT tam technicky nebude.
@mlocik97 Fakt, jo? Doma mám rozdělený zařízení do několika skupin:
- IPTV - tam jsou jenom set-top-boxy. Nemám kontrolu nad FW a nevyužívá to nic ve vnitřní síti, tak jsem to odsekl a nevidí to nic bokem.
- LOCAL - jsou zařízení jako tiskárna, který nechci, aby někdo používal zvenčí, něco stahovaly nebo odesílaly a aby se dostaly na jinou skupinu zařízení.
- DIRTY - věci, kde není update a nejsou pod kontrolou ( telka s HBB,...). Můžou na net a nikam jinam.
- LAN - normální počítače, co můžou do DMZ a LOCAL
- DMZ - zatím 1ks HC2 s NextCloudem, dostupný zvenku i z LAN a DIRTY
Jede to všechno na dual stack. NAT je jenom na IPv4 a jenom proto, že mám jenom jednu veřejnou IP adresu a několik sítí. Na IPv6 to jede krásně bez NATu (mám od ISP prefix /56). Hádej, jak jsem to udělal?
-> Petr M:
Mám to podobně, ale dual stack jen v nutnosti, jinak pouze IPv6, kde to jde, s možností NAT64 (hodně provozu přes to jde, také 4->6 zvenku).
IPTV: pozor, settopboxy (obzvlášť androidí, ale i Enigma) těžká šmíra, je třeba masivně blokovat (masivní biče).
LOCAL: Můžou mít ULA, případné aktualizace pak lze řešit ven přes proxy, nebo vlastní cache uvnitř sítě.
DIRTY: TV Hbbtv - stejný drek jako settopboxy, patří do podsítě IPTV.
LAN: Mám jako 2 podsítě - bezpečnou (linuxové počítače s aktualizacemi) a nebezpečnou (widle ap.), liši se pochopitelně filtrováním.
Mimoto další, např. několik VLAN pro wifi dle rozsahu přístupu a použití.
Ono NAT a firewall riešia sieť z opačných koncov a dosť odlišne.
Zde je to pěkně vysvětlené:
https://www.root.cz/clanky/proc-neni-nat-totez-co-firewall/
"Drtivé většině koncových uživatelů to skutečně je naprosto jedno."
Jo, stejně jako jestli pošťačka přiveze dopis autem nebo na kole. Ale musí ten dopis dojít.
Když kamarád brečel do telefonu, že nemůže pařit onlajnovku a zjistilo se, že herní server zvládne max. čtyři připojení z jedné IP adresy a on je za CGNATem... Nebo když kvůli jednomu zavirovanýmu komplu za pěti NATy nejdede nějaká služba půlce okresu. Nebo když vypadl server Amazonu a kamarád si nemohl rozsvítit na WC, protože bez čmoudu se nepřipojil vypínač ke světlu. Tak to jsou přesně situace, kdy užitečnosti NATu velmi silně pochybuju.
Nebo když vypadl server Amazonu a kamarád si nemohl rozsvítit na WC, protože bez čmoudu se nepřipojil vypínač ke světlu.
Něco mi říká, že by pravděpodobně to samé nastalo, i kdyby ten krám komunikoval přes IPv6. On totiž zmíněný přístup umožňuje parádní vendor lock-in a šmírování spousty dat a nezdá se mi, že by si to někdo jako Amazon nechal ujít.
Ono je aj otázka, čo je to za vypínač, že potrebuje mať prístup ku cloudu, aby zapol svetlo.
"Normálny smart" vypínač je relé, ktoré monitoru stav fyzického vypínača, skombinuje ho so svojim interným stavom (ktorý je možné meniť mobilom/nejakým gatewayom/z cloudu/atď) a následne kontroluje stav pripojeného spotrebiča tak, že mu do kábla pustí/nepustí 220V - ako klasický vypínač. V prípade, že sa nevie pripojiť do cloudu/wifi/zigbee/atď, funguje úplne klasicky, ako keby smart nič nebolo.
Potom sú tu však rozličné tlačidlá/vypínače/apod, ktoré nie sú zapojené do elektroinštalácie (tá je napevno zapnutá) a fungujú len cez cloud/lokálnu gateway/atď. Toto sa zvyčajne používa, pokiaľ sa dorába smart funkčnosť v existujúcich priestoroch a majiteľ sa nechce dotýkať elektroinštalácie. Je to lacnejšie, ale s kompromismi a práve toto ide do tých úchylární.
@bez přezdívky
Ještě jste zapomněl na chytré vypínače, které fungují peer to peer, spíš jako stavový automat. Nemají potřebu žádné gateway, mohou ji mít a nemusí. Ty jsou v profesionálních instalacích nejčastější, protože neobsahují SPOF.
A zapomněl jste na světlo, které má trvalý přívod elektřiny a vypínač přímo na svítidle. Stropní svítidla na řetízek.
To je ale vedlejší, jaké různé systémy existují. Nemá smysl se pozastavovat nad tím, že každé řešení má své nevýhody. Má i své výhody. Zadavatel má možnost si to zvážit a rozhodnout se. Je hloupé kritizovat druhého, proč si pořídil něco, co se zrovna Vám nelíbí.
To, co jste popsal jako „normální smart vypínač“ moc smart není. Aby to bylo smart, nemůže mít fyzický vypínač svůj stav, nýbrž jen posílá informaci „změň stav“.
Přístup do cloudu se používá proto, že to celé chcete ovládat z mobilu, který je připojený do sítě operátora – a musí komunikovat s domácí branou. A pak už je to jen otázka implementace. Pokud se aktuální stav světel drží někde v cloudu a vypínač posílá do cloudu událost „změň stav“, na základě které cloud změní stav a pošle zpět zprávu „sepni relé“, výpadek cloudu bude znamenat, že si nerozsvítíte. (Naříkám že je to rozumná implementace, ale je možná.)
> Aby to bylo smart, nemůže mít fyzický vypínač svůj stav, nýbrž jen posílá informaci „změň stav“.
Ešte raz: ...relé, ktoré monitoruje stav (pripojeného) fyzického vypínač, skombinuje ho so svojim interným stavom (ktorý je možné meniť mobilom/nejakým gatewayom/z cloudu/atď) a následne kontroluje stav pripojeného spotrebiča tak, že mu do kábla pustí/nepustí 220V...
T.j. stav relé/chytrého vypínača/výstupu na spotrebič nie je rovnaký, ako stav pripojeného fyzického vypínača. Fyzický vypínač vie ovplyvniť stav relé, relé sa rozhodne, ako zmenu stavu bude interpretovať (napr. momentary/toggle/edge/ignore).
> Přístup do cloudu se používá proto,
Ja viem, prečo sa to používa. Aktuálny stav sa v cloude nedrží, je to zbytočné (ok, možné to je, ale nezmyselné), cloud je proxy medzi aplikáciou+asistentami (Google Assistant/Alexa/Homekit) a zariadením. Pokiaľ vypínač zvláda wifi (ako shelly alebo sonoff) a nepotrebuje zigbee/z-wave, tak sa to dá predať zákazníkovi aj bez hubu.
Fyzický vypínač má dva stavy – zapnuto a vypnuto (podle toho má své jméno). Ty stavy jsou fyzicky vyjádřené překlopením kolébky vypínače. Samozřejmě můžete udělat „smart“ instalaci, že vypínač v poloze „zapnuto“ bude někdy znamenat, že světlo svítí a někdy, že nesvítí, stejně tak i opačný stav. Ale taková instalace by byla na pěst.
Ve smart instalaci dává fyzický vypínač smysl jako bypass. Jinak je podstatně lepší fyzický přepínač, který pošle signál, že se má změnit stav, a případná indikace stavu indikuje skutečný stav vyhodnocený nějakým řadičem.
> Samozřejmě můžete udělat „smart“ instalaci, že vypínač v poloze „zapnuto“ bude někdy znamenat, že světlo svítí a někdy, že nesvítí, stejně tak i opačný stav. Ale taková instalace by byla na pěst.
Problém je v tom, že vypínač je možné preklopiť len fyzicky, nedá sa mu povedať, aby sa preklopil. Preto napr. shelly má pre vypínač dva režimy: toggle a edge. Edge je presne to, čo popisujete, toggle treba vrátiť najprv do polohy ktorá zodpovedá aktuálnemu stavu až potom ďalšia akcia zapne/vypne zariadenie.
Väčšina používateľov preferuje Edge, to že vypínač fyzicky nezodpovedá stavu im nevadí, sú na to zvyknutí zo schodišťákov.
Alternatívou je vymeniť vypínače za spínače, aj dvojpolohové (jedným zapnúť, druhým vypnúť). Pre väčšinu inštalácií to nie je problém, ale niekedy nájsť relé ktoré vie obslúžiť viac ako 2 spínače na jednom okruhu už problém môže byť (pri prepínačoch 2 x č. 5B+N x č. 7 to nevadí, celá séria sa tvári ako jeden).
Jenom upřesním, že schodišťák je také spínač. Indikace u spínače může být řešena například LEDkou (u schodišťáku dříve doutnavkou).
Tady jste se spletl v elektrikářských pojmech. Schodišťový vypínač ("schodišťák") je technicky přepínač nebo dvojpřepínač, pokud slouží jako vložený.
Spínač na schodišťový automat elektrikáři označují jako "tlačítko" (případně s tou doutnavkou).
NAT není totéž co firewall.
NAT byl určen původně na něco zcela jiného, než je jeho dnešní implementace na SOHO zařízeních.
IPv6 se naopak snaží vyřešit mraky problémů, které přinesl právě NAT a jeho současné nasazení. Jenže nastal druhý problém, operátoři prostě poředpokládají, že máte v SOHO přesně asi jedno zařízení, což je bohužel také hodně špatně.
Pto koncového uživatele je NAT stejně nepochopitelný jako firewall. Ani jedno nepoužívají a ani nevědí, že něco takového existuje. Koncoví uživatelé chtějí přístup na internet (myšleno web) a to je vše, nedělají žádnou "černou magii" s přesměrováváním portů, nastavování pravidel provozu, a podobně. Jednak nevědí, co to je, a druhak je to uráží.
Jistě, je to pochopitelnější, ale jen proto, že to znají, používají a ví, že to funguje, tedy nebojí se toho. V tom je celé jádro pudla. Jsem si vcelku jistý, že kdyby IPv6 znamenalo "jen víc adres a jiný formát adresy", tak by s jeho zavedením nebyl jediný problém.
Jenže celý problém s nasazením IPv6 u koncových uživatelů podle mě selhává ani ne tak na technice, jako spíš na faktu že neexistuje jednoduchý způsob, jak ten přechod z IPv4 udělat. Opakování faktu, že "je to moderní, do budoucna nutné" tomu nepomůže, dokud budou návody mnohem delší a s dovětkem, že se to stejně bude způsobovat problémy. Vážně.
Dohledávat informace k tomu, jak IPv6 vlastně funguje je nervy drásající proces: oproti IPv4, kde je cesta vcelku přímočará (mnohokráte a na mnoha místech popsaná) a pro spoustu lidí snadno uchopitelná (protože ji znají a používají), tak se tady dozvíte především co kde nefunguje, že je to všechno jinak atd. ale že by existoval nějaký návod, podle kterého by si mohli během deseti minut nastavit ten či onen domácí router? Nejsou.
Jsem zvědav, kdy se najde odborník, který si lajzne vytvořit pro většinu uživatelů srozumitelný návod, který nebude prošpikovaný technikáliemi, které koncové uživatele nezajímají. A i když třeba nebude tak obecný a do detailu přesný, bude použitelný. Můj tip je spíš nikdy, protože by byl okamžitě v diskuzi roztrhán na cucky za nedostatečnou technickou úroveň návodu. A tak se zase holt nehneme z místa.
Měl by to udělat výrobce zařízení. Ostatně, má povinnost dodat k zařízení návod k použití ze zákona. Nic mu nebrání napsat dva odstavečky o tom, co je modul zač, na co se používá,... A může to být i marketingový trik, že možnost se něco naučit bude motivovat lidi i ke koupi výrobku, se kterým se dostanou k vědomostem a zvládnou to sami.
A pokud jde o princip srozumitelně a do hloubky, co knížka o IPv6 od Pavla Satrapy? https://www.root.cz/knihy/internetovy-protokol-ipv6/
V čem je pochopitelnější?
IPv6: Na večírek pro býložravce přijde krokodýl. Nechci tem krokodýla, nepustím tam krokodýla.
IPv4: Na večírek přijde krokodýl, ale převleče se v šatně za zebru. Nechci tam krokodýla, ale mám vyhodit krokodýla, nebo zebru? Zastavuju je před, nebo za šatnou? A proč se vlastně převlíká?
IPv4: Na večírek přijde krokodýl, ale převleče se v šatně za zebru. Nechci tam krokodýla, ale mám vyhodit krokodýla, nebo zebru? Zastavuju je před, nebo za šatnou? A proč se vlastně převlíká?
Nerozumím, jak je myšleno to převlečení krokodýla za zebru. Jako že na server se službou NAT přijde z WAN podstrčená odpověď na žádost některého stroje z LAN a ta je předána tomu stroji? Nebo že na NAT z WAN přijde žádost, která je podle pravidla přeložena a poslána některému stroji do LAN?
Není lepší NAT přirovnávat k podatelně či telefonní ústředně v podniku?
IPv4: Na večírek přijde krokodýl, ale převleče se v šatně za zebru. Nechci tam krokodýla, ale mám vyhodit krokodýla, nebo zebru? Zastavuju je před, nebo za šatnou? A proč se vlastně převlíká?
Keby sme aspom tusili ako NAT funguje, vsak. ;)
Ked uz to mame nejako napasovat na zvieratka, tak skor takto:
Zebra ani krokodyl a ine zvieratka nejazdia na vylet kazdy vlastnou karou ale spolocne nasadnu do kary spz ZOO. Takto jazdia hore dole, nikto s tym nema problem. Iba ak filzi po ceste, pretoze vidia len spz ZOO, ale netusia kto konkretne sa vezie. Tak je to dobre a tak to ma byt ;)
9. 6. 2021, 21:20 editováno autorem komentáře
Tak znovu. Konfiguruješ firewall. Víš o tom jenom to, že od někud přijde balíček dat, má nějakou adresu odesílatele, adresu příjemce a pár dalších atributů.
Adresa příjemce je pro tebe stejně viditelná, jako v přírodě druh zvířete. A najednou se ti tahle vlastnost změni pod rukama a při tom je to ten samý balíček dat,...
No... destination nat...
1. klient za natom posle paket na sever
2. Pravidlo v prerouting tabulke paket odchyti a kedze je to dnat pravidlo tak zmeni src adresu na svoju ip a tuto skutocnost si poznaci vo svojej nat tabulke.
3. Paket poputuje podla routovacej tabulky k cielovemu servru
4. Server vytvori na poziadavku odpoved, src adresu nastavi svoju a dst adresu nastavi NAT.
5. Pravidlo vo firewalli odchyti prichadzajuci paket, porovna ho so svojou tabulkou a ak najde zhodu tak nastavi dst adresu klienta ktory poziadavku poslal.
6. Paket poputuje podla routovaciej tabulky cez urceny interface na interface zariadenia ktore ma bindnutu dst adresu
Kde je v tom problem, server ani len netusi ze komunikuje s NATom, clovek ktory vie co robi si nastavi routovanie a pravidla vo firewalli natu tak aby sa kazda odpoved dostala tam kam ma.
Preberieme aj source nat? ;)
Mam DNS recursory ve vnitrni siti na "interni" ipv4+ipv6. Mam DMZ sit, ktera ma pouze public ipv4+ipv6. Mam DMZ2 sit, ktera ma pouze public ipv4+ipv6.
Ted mi vysvetlete, jak server v DMZ a v DMZ2 pripojim po ipv4 na ty rekurzory (port 53).
Ak izolujete DMZ a DMZ2 uplne izolujete od intranetu tak preco by nejakym sposobom mali vidiet do intranetu? Ak maju servre v DMZ a v DMZ2 vidiet rekurzor tak ho nemozete strkat tam kde by k nemu nemali mat pristup. Alebo si trochu nastudovat sietovanie a na serveroch v DMZ a v DMZ2 pridat interface ktore su v "internej" sieti.
10. 6. 2021, 18:00 editováno autorem komentáře
Ja nemluvim o uplne izolaci DMZ. Ja potrebuji, aby sluzby v DMZ komunikovaly s intranetem s tim, co maji povolene na firewallu.
Aha, takze kvuli tomu, aby videli na 4ce do interni site, tak musim pridat interface s prechodovou ipv4 sit. Pro kazdou takovou DMZ vlastni prechodovou sit. A pro kazdou takovouhle prechodovou sit extra pravidla na firewallu. Komplexita administrace a bezpecnosti nasobne roste.
Je videt, ze jste rozsahlou sit nikdy nespravoval.
Pokud píšete, že vnitřní síť máte na na neveřejných IPv4+v6 (ULA?) a v DMZ a DMZ2 máte vše na veřejných IPv4+global IPv6, tak není snad problém to zaroutovat dovnitř i bez nějakých přechodových mechanizmů, když si to povolím ve firewallu. Nic nebrání přeci tomu, aby mezi sebou komunikovaly neveřejné/veřejné IPv4 globální/ULA IPv6 adresy, pokud si nastavím patřičně směrování a firewall.
Pokud pominu, že bych viděl jako chybu, aby z DMZ sítí se sahalo na DNS do vnitřní sítě (řešil bych drouhou sadou v DMZ, kam se tlačí DNS data z vnitřku a všechny DMZ sítě vyyužívají tuto sadu serverů v DMZ).
Pro mne je mnohem bezpecnejsi, kdyz nedovolim verejnym IP komunikovat s rfc1918 sitemi by default. Eliminuje to chybu, kdy se z verejne IP da dostat do interni site nejakym budoucim nastavenim firewallu.
Ano, extra rekurzory jsem jiz zvazoval. Ale to byl jen priklad. Mam ruzne sluzby, ktere potrebuji komunikovat z DMZ do intranetu a ne kazdou sluzbu lze pushovat do DMZ. Treba reverzni proxy, centralni logy, monitoringy, backupy...
Tak pak mám možnost v té DMZ, která ,má jít ven nebo i dovnitř, aby hosti měli vedle sebe veřejnou a neveřejnou IPv4 adresu, podobně globální a ULA IPv6 adresu a nastavním preferencí pak komunikace ven půjde z veřejné/globální adresy a komunikace proti vnitřní síti bude používát neveřejnou/ULA a hranice mezi DMZ a vnitřkem nemusí překračovat mišmaš adres.
Ve Vasem vysledku tam pak budou nejmene 4 adresy, tedy 2 nebo 4 interface(vlan):
1] GUA ipv6
2] public ipv4
== prvni fqdn
3] ULA ipv6
4] rfc1918 ipv4
== druhe fqdn
Na firewallu = mismas. Routovani mismas. Preference vyberu zdrojove adresy kvuli ULA mismas. Nutnost nasadit ULA do vnitrni site. RFC1918 a ULA jdouci na tu 1]2] se NAT na ip interface firewallu. Ta ip je pro kazdou dmz jina. Ble.
Mam to udelane takto na 1 ci 2 interface(vlan):
1] GUA ipv6
2] public ip4
== jedno fqdn
Na firewallu = mene pravidel nez v prvnim pripade. Jistota, ze mi z public IP neprojde nic do rfc1918 (+1 pravidlo na fw). NAT z vnitrni site do 1]2] dokud nebude mit interni klient GUA ipv6.
Tak ta komplikace s dvěma IPčky na serverech DMZ je proto, ať nemusím NATovat na přechodu DMZ a intranetem v obou směrech. Pokud mermomocí chcete NATovat, tak pak je zbytečné do DMZ cpát neveřejky/ULA adresy. A pokud nechcete propouštět pakety přes hranici kde zdroj/cíl není oboje veřejka nebo neveřejka, tak si to musíte NATnout.
Pořád vidím nejčistější nechaz v DMZ veřejky/global a pouštět to dovnitř a ven do DMZ bez NATu (pokud v DMZ mají servery jen jednu síť, skrz kteoru jdou do internetu i do intranetu). Řešení s NATem bych u tohot odmítl, NATovt na veřejku až jen odchozí provoz, co jde mimo firmu a její DMZ. A pokud je to větší síť tak očekávám, že je jiný router/firewall pro cestu internet/DMZ a přes jiný jde provoz DMZ/intranet.
„Pro mne je mnohem bezpecnejsi, kdyz nedovolim verejnym IP komunikovat s rfc1918 sitemi by default. Eliminuje to chybu, kdy se z verejne IP da dostat do interni site nejakym budoucim nastavenim firewallu.“
Na to stačí 1 (v úplném provedení 4) pravidlo na firewallu, ale když si chcete přidělávat práci a vymýšlet ony rovnáky...
Já to chápu tak, že czechsys neřeší pimárně to, aby mu neutíkaly ULA a neveřejné IP adresy do Internetu. On řeší to, že chce, aby uvnitř DMZ zón se vyskytovaly jen pakety, kde zdroj i cíl je veřejná IPv4/globální IPv6 adresa? Takže při přístupu z intranetu do DMZ zón provádí srcnat na veřejnou adresu routeru a všechny přístupy z intranetu tak vůči serverům v DMZ vystupují s veřejnou IP routeru. Jen netuším, jak řeší přístup z těch serverů z DMZ do intranetu, což požaduje také? To pak leda musí se spojovat na IP adresu routeru do intranetu a něm dělat dstnat na interní IP adresu? To se mi jeví jako dost neštastné řešení už jen z důvodu, že pokud hovoří o větším systému, tak budu určitě chtít sledovat i toky v jednotlivých semgentech a takto si komplikuji párování spojení, musím k tomu přikládat i vyčítáno stavů NAT stroje přes flow, taktéž logy v DMZ budou ochuzeny o info IP adresy klienta atd.
Ale pokud to tak má vyřešeno pro IPv4, tak pokud na tom mermomocí trvá pro IPv6, tak to jde řešit překladem prefixů na hraniční bráně mezi DMZ a intranetem (NPTv6), ale rozhodně je to něco, co se silně nedoporučuje dělat.
Pro mne je mnohem bezpecnejsi, kdyz nedovolim verejnym IP komunikovat s rfc1918 sitemi by default. Eliminuje to chybu, kdy se z verejne IP da dostat do interni site nejakym budoucim nastavenim firewallu.
Podle mě je to přesně naopak. Odfiltrovat síť (i veřejnou) je otázka jednoho pravidla, nebo celkové policy.
Díky NATU naopak máte mišmaš pravidel - např. z vnitřní sítě - via vlastní veřejnou adresu - zpět do vnitřní sítě. Nebo odlišná pravidla z vnitřní sítě 1 do vnitřní sítě 2 vs. z internetu do vnitřní sítě 2 (obvykle to, co je přístupné zvenčí, chcete mít přístupné i z ostatních vnitřních sítí)... Na firewallu pak musíte zběsile nakombinovat pravidla...
Častým výsledkem je, že je tam díra, kterou nikdo nevidí, nebo naopak je něco z různých směrů dost nelogicky nedostupné (nejčastější je obrácení NATU z vnitřní do vnitřní).
Je videt, ze jste rozsahlou sit nikdy nespravoval.
No, co taky server hosting. Spravovali ju hlavne kolegovia. Ja som sa k tomu dostal ak bola treba nejaka specialitka, inak som bol ako admin nerentebilny, pretoze som ako admin nebol plateny. Ansible je dobry kamarat ak ho zvladate na pokrocilejsej urovni ;)
Firewall vám nic neřiká? Přece žádné zařízení by němělo být jentak připojené do internetu bez FW a IDS.
A na druhou stranu u jednoúčelových triviálních gadgetů typu IoT je to fuk, ty mají stejně třeba jen jeden port a pokud mají korektně nastavené šifrování, není šance to nějak narušit (kromě DDOS). A pokud nemusí komunikovat navenek, tak vždy postačí je nechat fungovat na privátní síti v rámci svého serveru, čímž se to řeší.
Navíc z článku docela jasně vyplývá, že funguje už i NAT64, takže se ta privátní síť pak může připojit přes nějaké zařízení nebo ten server ven a s pořádným firewallem.
Rovnou říkám, že na toto nejsem odborník, ale výrazy typu sebevrah opravdu nechápu... v domácnosti mám poměrně dost připojených zařízení, a jsem si skoro jist, že všechna už dávno umí Ipv6 (od mobilů přes pc až po STB)... a pokud neumí, bude to 15 let stará plečka, které se rád zbavím (myslím třeba síťová tiskárna nebo nějaký wifi repeater). U té tiskárny jde stejně tisknout i lokálně přes USB (případně to elegantně řešit přes wifi router s USB portem).