Názory k článku IPv6 po deseti letech: svět je v třetině cesty, Česko se zaseklo

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.

Že nechá vybudovat zákazníka i na 6 a čtyřky se zbaví, jakmile to bude možné. Když bude dělat všechno výhradně na 4, tak se jí nezbaví nikdy.

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...

Není. Odporuje principu KISS a způsobuje plno problémů

Technicky ano. Jenomže to běžného uživatele opravdu nezajímá.

martinpoljak: Ono to jde ale strašně snadno hacknout. Vytvoříte ten NAT, pak nastavíte firewall – to je podle vás snadné. Pak ten NAT dáte tajně pryč, firewall se o tom nijak nemůže dozvědět – voila, máte firewall nastavený stejně snadno, jako firewall+NAT. To vás nenapadlo, že?

Neodporuje (resp. nemusí). Mám krabičku, která dělá firewall i NAT a vše pod jedním UI. Nastavím vnější IPv4 a IPv6 adresy, vnitřní subnety pro oba protokoly a automaticky to nastaví firewall i NAT.

Tím „automaticky to nastaví firewall i NAT“ máte asi na mysli jedno masquerade pro vnitřní síť a zákaz spojení zvenku dovnitř. To je výchozí nastavení pro lid, to není nic nového.

Zavirovaný mobil? Nestačil by „moderní web“?

Absolutní off-topic otázka, a neber ji prosím jako útok na tvoji osobu.
Ve kterém roce jsi se narodil? Zažil jsi dobu před NATem?

Já si totiž myslím, že NAT napáchal nejen škody v sítích, ale i v myslích mnohých lidí.

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.

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í.

Trošku problém je v tom, že to zbylé 1 % tvoří ten ten obsah, ten internet tím, čím je.

Ano, a ti ví nebo si zjistí, co potřebují, aby to chodilo. :-)

Jenže asi tak 1 % z toho 1 % jsou takový kanóni, aby měli vlastní server doma. K tvoření obsahu na YouTube/Insta­gramu/whatever vám to sedmkrát natované připojení stačí.

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?

Ano. Vždyť právě o tom mluvím.

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.

Nebude. Není potřeba. Na jeho adopci je to vidět. Tyhle teorie jsou přesně ty teorie lidí, co tomu sice rozumí, ale běžné uživatele vůbec nejsou s to pochopit.

Je potřeba, a potřebuje to i běžný uživatel. Jenom neví, že se to jmenuje IPv6, protože tomu nerozumí (stejně tak, jako neví, že potřebuje TCP, ale kdyby se mu vypnulo, tak si hned půjde stěžovat).

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.

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...

u toho IoT je trochu potíž v tom, že Tasmota IPv6 by default neumí a i když si to člověk zkompiluje s podporou, tak management je dostupný po http a musí řešit, jak se k tomu vlastně zabezpečeně připojit. Ale řeší se to, jen to bude na dlouho.

No protože je 99% jistota, že ISPík propustí IPv4 a 20% jistota, že si to čuchne k IPv6. Protože ISPíci jsou lemry a SOHO krabičky jsou na tom s podporou bídně... Dokud se tohle nezlepší, tak tak se podporou jenom IPV6 ořízneš od většiny zákazníků a dual stack zbytečně žere paměť a výkon CPU.

Jednodušší pro výrobce IoT je to v tom, že nepotřebuje server, přes který se jeho výrobky domlouvají.
Jak se bez serveru ty IoT výrobky najdou a nakonfigurují, aby to zvládl běžný uživatel? Jak bude výrobce bez serveru šmírovat... pardon, sbírat data pro účely zlepšování služeb?

> 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.

To právě NAT vůbec nedělá. NAT jen tupě přepisuje adresy v hlavičce tam a zpět. Žádné oddělení a filtraci nezajišťuje. To dělá právě ten firewall.

„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?

Možná vás to překvapí, ale ano. Nesmysly, pane Jirsáku, píšete vy a nejen tady a teď. A to si klidně berte osobně.

martinpoljak: Nějak jste zapomněl uvést ten příklad, jak si uživatel zpřístupní z internetu svůj NAS, když ho má za firewallem a za NATem.

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á.

Nikdo neříká, že se bez toho nedá obejít. Ale málokdo potřebuje cokoliv lepšího. To je rozdíl.

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.

Zatim teda vidim nekolikrat za sebou ze lidi nechapou predevsim ten NAT (a dost si ho pletou s firewallem).

@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šina zažívá to samý, akorát to neumí pojmenovat a nezná příčinu, takže nemůže ISPíka nakopat do koulí

Jak ten vendor lock-in Amazon monetizuje? Provoz cloudových serverů něco stojí, takže Amazon potřebuje minimálně pokrýt tyto náklady.

1. To záleží na tech. provedení.
2. To má především ukázat, až do jakých uchýláren se může zvrhnout zbytečná, umělá závislost.

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/zig­bee/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í.

Ja som nikoho nekritizoval; chápem, že lepšie sa predávajú krabice, ktoré zákazník doma vybalí a nejako to funguje, ako keď pri kúpe krabice musí naplánovať a vykonať rekonštrukciu domu.

No ale potom sa môže stať, že si nerozsvieti na záchode, keď vypadol hub.

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/tog­gle/edge/igno­re).

> 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+asis­tentami (Google Assistant/Ale­xa/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). A ano, ovládání bez indikace stavu je pro lidi pořád daleko přijatelnější, než indikace, která ukazuje naprosto náhodně.

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).

Řeč byla o tom, na co jsou lidé zvyklí. Ne jak to nazývají elektrikáři.

Řeč byla o tom, na co jsou lidé zvyklí. Ne jak to nazývají elektrikáři.

Ano, na toto jsou lidi zvyklí. Schodišťák byl a je přepínač.
Vložený je křížový vypínač ("křížák").

Ovladač schodišťového automatu je "tlačítko".

Viz zde (sekce řazení 6 a 7 + oddíl "tlačítko"):

https://cs.wikipedia.org/wiki/Vyp%C3%ADna%C4%8D#Z%C3%A1kladn%C3%AD_proveden%C3%AD_sp%C3%ADna%C4%8D%C5%AF

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? ;)

dw: A pak zjistíte, že se na ten server nedostanete z vnitřní sítě. Navíc jste to napsal špatně, DNAT je Destination NAT, tedy se mění adresa cíle, ne zdroje.

njn, moja chyba, malo tam samozrejme byt dynamic nat. Zrejme ta pozdna hodina.

s destination nat sa pouzije conntrack aby to fungovalo.

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).

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...

Ano, mam na to 1 pravidlo. Je skoro na vrcholu seznamu pravidel ve fw.

Nebo snad z toho meho komentare vyplyva neco jineho?

Ale stjený počet pravidel mi vyjde pokud začnu dropni pakety nemající zdrojovou adresu z DMZ přídělu a mířící dovnitř. A za tím mohu dál pokračovat povolováním vyjímek...

Na to, aby mi ULA nelezly přes rozhraní do inetu, stačí 1 pravidlo!!!!! Na to není potřeba zakazovat komunikaci mezi veřejnými adresami a ULA.

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 ;)

Když ta VPN bude mít úplně jiný výstupní server v jiné zemi (podle potřeby) a jinak řešenou routu, tak proč by ne ? Jinak řečeno, jste si jist, že Ipv6 u Netflixu nefunguje ostatním ? Neblokuje to třeba váš výstupní server resp. fw českého poskytovatele ? Já bych začal tím, že bych si nejdřív prošel příslušná fóra...
Ale samozřejmě to píšu s vědomím, že Ipv6 zatím neprovozuju a ani Netflix předplacený nemám... Dal jsem si teď vpn do vyhledávání a mělo by to fungovat viz třeba restoreprivacy­.com/vpn/best/ip­v6/. Technicky vzato openVPN to podporuje a wireguard taktéž, nevidím problém...

Že? A přitom by to mělo fungovat z fleku, hned a napřímo. Kde se asi stala chyba...