To je škoda, protože pořád jsou ISP bez IPv6. Třeba UPC. Doma mě to nevadí, VDSL od T-Mobile to má funkční.
Na Slovensku se i v tomto ohledu začíná něco dít. Doufejme že ostatní členové koncernu budou následovat.
I když samozřejmě, změna z veřejné IPv4 na veřejný IPv6 prefix + DS-lite rozhodně není změnou k lepšímu; veřejná IPv4 adresa je o mnoho hodnotnější.
Doufejme že nikoliv. Nemám problém mít ipv6 v UPC síti. Ale chci veřejnou IPv4 adresu. IPv6 mi nic nepřinese, tu mám na turrisu skrze 6in4 a funguje to dokonce lépe, než tunel od he.net. I když ten tunel 6in4 využívá nějaký server
Ne všude je dostupná ipv6 či veřejná ip adresa, pokud se chci připojit na turris, musím mít veřejnou ipv4 a tu ipv6 je možnost si zařídit.
na turrisu mám nastaveno:
config interface 'wan6'
option _orig_ifname '@wan'
option _orig_bridge 'false'
option proto '6to4'
option mtu '1472'
A prostě to funguje. Ping je srovnatelný s IPv4 (oprtoti tunelu od HE, kde je desetkrát pomalejší).
Tak fakticky jsem pořád u 802.cz. Smlouva na bázi předplatného, internet funguje, jen ipv6 musím tunelovat přes HE.
Když jsem se s RIOmedia posledně bavil, tak mi nabízeli přechod na jejich tarif s "výhodnou cenou", když se upíši na dva roky a ipv6 bych stejně neměl.
Ještě máme v baráku optiku od c2net.cz, ale tam o ipv6 taky asi ještě neslyšeli (na webu o něm není ani zmínka).
Používám SixXS doma i v práci - místní velcí i malí ISP svorně IPv6 nenabízejí.
Bude zajímavé, projeví-li se vypnutí SixXS na takovém tom IPv6 penetration grafu, který o desetinky procent pomalu roste. Možná, že letos naopak skočí dolů...
Mě se tu jejich slavnou službu nepovedlo ani nikdy vyzkoušet. Po založení účtu mi odečetli nějaké nesmyslné body, protože xDSL modem neodpovídal na ping, čímž se celý účet stal prakticky nepoužitelným, ten tunel nešlo ani založit. Tak nějak jsem filosofii té služby nikdy nepobral. Zlaté HE.
Samozřejmě není, pokud to provider neblokuje. Nicméně problém jsem si uvědomil až tehdy, když už bylo pozdě, a nešlo ho žádným způsobem vyřešit. Prostě to odečetlo body a od té chvíle ten účet byl naprosto k nepotřebě. Jestli si ten ping následně povolil nebo ne už bylo úplně jedno.
Fakt přístup na palici.
No ono to mělo něco do sebe, žádosti o tunel/subnet někdo u SixXS schvaloval a byly registrovány na uživatele, co předpokládám +/- kopíruje postup když žádám o příděl u nativní konektivity.
U HE je možno si naklikávat tunely prakticky anonymně v řádech minut, což samozřejmě vedlo k zneužívání např k těžení dat z webů státní správy, což vedlo k postupné blokaci celého rozsahu HE tunelů, je tady o tom vlákno ve fóru.
Nicméně souhlas s tím, že Massarovy rekce na fóru jsou minimálně v době od zastavení registrací dost arogantní.
"Jako asi nejlepší alternativa se jeví tunnel broker od Hurricane Electric, který je rovněž zdarma a má body rozmístěné po celém světě. Na rozdíl od SixXS ale nedosáhne přes NAT, takže uživatel potřebuje veřejnou IPv4."
Tunnel broker od Hurricane Electric jsem kdysi používal, ale je to už skoro deset let, takže si nepamatuji detaily. Ovšem pamatuji si, že jsem za NATem právě byl a IPv6 jsem používal k protunelování se na svůj počítač.
Předpokládám, že nemáš veřejnou IP pro všechna zařízení. Uživatelské výhody IPv6 jsou pak zcela zřejmé, můžeš mít veřejnou adresu pro všechna zařízení. A veřejnou adresu pro všechna zařízení budou mít i méně šťastní, kteří třeba jsou za CGNATem.
Konečně pak začne normálně fungovat SIP, sdílení souborů bez prostředníků, doma si budeš moci provozovat web server... Na trh se dostanou noví provideři... Zkvalitní se v současné době poskytované služby (i když třeba u takového Wedosu to tak nevypadá kvůli jejich přístupu 1 IPv6 per VPS)...
S bezpečností to bude stejné/podobné jako u IPv4, v některých ohledech alespoň teoreticky lepší.
Samotný NAT nezajišťuje bezpečnost a typicky se ani sám nepoužívá, jelikož ho lze "prostřelit". Většinou se používá kombinace NAT+firewall, kde se blokoují spojení z venku.
U IPv6 si jednoduše nastavíš firewall tak, aby třeba spojení s TV nebo s nějakým IoT bazmegem nemohlo být navázané z venku, ale že na web server to naopak možné bude, ale jen na portech 80 a 443...
VPN určitě smysl má a to třeba kvůli tomu, aby ses z venku dostal na konfiguraci třeba té IoT krabky bez toho, abys musel povolovat inicializaci komunikace z venku pro všechny ostatní.
A nebo to uděláš tak, že zařízením povolíš pouze komunikaci se šifrováním a autentizací (v IPv6 je dobře "zabudovaný" IPSec).
Odpovím si sám: http://ipv6-test.com - tam je vše otestované a popsané.
Pozor, upřednostňování je dost problém - pokud to říkám dobře: Když využívá aplikace systém, řídí upřednostňování (v Linuxu) gai.conf, ale když na to aplikace prdí, řeší si to sama. Takhle jsem týdny hledal, proč mi Opera nejede přes 6, a ona (sviňa), když měla i 4, jela jen přes 4. Jiné aplikace zkoušejí přes oba protokoly, co přijde dřív, atd.
1. rád bych vysvětlení jak se "teoreticky zlepší" bezpečnost když do internetu vystavím zařízení třetích stran a budu doufat, že výrobce vyřešil bezpečnost za mě.
2. Co prosím znamená "prostřelit" NAT????
A pak, že "Většinou se používá kombinace NAT+firewall, kde se blokoují spojení z venku." je chujovina. Jednoduchý NAT dovnitř nepustí nic, co si neotevřelo port ze vnitř a základní firewall brání použít jiné porty než určené, ale na NATu nemá význam z důvodu v první větě.
1. Nikdo tě nenutí vystavovat do internetu zařízení která nechceš. Buď vůbec nepotřebuješ přístup z venku a necháš pouze link-local nebo link-local a unique-local (nikdo se na ně nedostane) a nebo potřebuješ přístup z venku, ale povolíš přístup pouze určitým zařízením (autentizovaných pomocí IPsec) a nebo povolíš přístup jen z určitých adres/subnetů.
2. Uvažujme NAT s externí adresou 1.2.3.4 (která je např. v subnetu 1.2.3.0/24) a interními adresami ze sítě 192.168.0.0/24. Ty jako útočník máš adresu 1.2.3.5 a chceš se dostat na zařízení za NATem s adresou 192.168.0.1. Pošleš packet s cílovou IP 192.168.0.1 na "WAN port" routeru.
Pokud není nastaven firewall, packet se dostane až na cílové zařízení.
K bodu jedna se nemá cenu vyjadřovat jako k celému IoT. Výrobci nejsou schopni zabezpečit současná zařízení a zákazník neni schopný takové problémy odhalit. Pro běžného zákazníka je IoT utopie.
A pak citace tvého vejšplechtu: "Pošleš packet s cílovou IP 192.168.0.1 na "WAN port" routeru. Pokud není nastaven firewall, packet se dostane až na cílové zařízení." ... no to je pochopitelně chujovina.
Víš co se opravdu stane když tam nebude firewall? ... vůbec nic, router paket zahodí a udělá to proto že ho nenajde v NAT tabulce. Aby se paket dostal z WAN do LAN na konkrétní adresu na běžném routeru s NAT tak by ten port musel být forwardovaný a nebo by tam musela být DMZ.
Obyčejný paketový firewall nemá na routeru téměř žádný význam protože NAT tabulka sama o sobě vylučuje jiné pakety než očekávané. Jiná situace je pochopitelně na zařízeních bez NAT (třeba přímo malém web serveru) ... tam bych asi firewall nasadil, ale z jiných důvodů.
2pavelv: Ano dalsi trotl co nevi, ze router odroutuje KAZDEJ paket o kterym vi kam ho poslat, a to domaci router vi zcela VZDY. Bud to totiz ty posle dovnitr, pokud je to adresa z vnitrniho rozsahu, nebo to vrati na svoji default GW.
Neboli dalsi dement, kterej si mysli, ze za NATem je v bezpeci ... a ze tech dmentu tu je ...
Vis ty kretene jak fuguej ROUTER? Vis leda velky hovno.
@pavelv
"A pak citace tvého vejšplechtu: "Pošleš packet s cílovou IP 192.168.0.1 na "WAN port" routeru. Pokud není nastaven firewall, packet se dostane až na cílové zařízení." ... no to je pochopitelně chujovina."
Si to můžeš sám vyzkoušet. Nastav si NAT bez firewallu a uvidíš, že ta chujovina bude fungovat.
"Víš co se opravdu stane když tam nebude firewall? ... vůbec nic, router paket zahodí a udělá to proto že ho nenajde v NAT tabulce."
A proč by ho měl zahodit? To by bylo pro router bez firewallu nestandardníc chování.
Vem si, že na tom hypotetickém routeru (veřejka 1.2.3.4 na jednom portu, před druhý port NATovaný subnet 192.168.0.0/24) může mít třeba přes třetí port další privátní subnet, dejme tomu 192.168.1.0/24, ale neNATovaný. Legitimní chování je, že packet pro cílovou adresu ze sítě 192.168.0.0/24 projde, protože mohl být poslán třeba z 192.168.1.0/24. Router bez firewallu se vůbec nedívá na zdrojovou IP a už vůbec ho nezajímá na který port mu packet dorazil. Prostě se podívá do směrovací tabulky, zjistí, že 192.168.0.0/24 je přímo připojená síť a packet pošle.
NAT je jen iluze bezpečí, i když tam je firewall, který zabraňuje "prostřelení".
Když budu v Praze na připojen k internetu a napadne mě, že napadnu lan kamaráda v Ostravě který může a nemusí mít veřejnou adresu???
To je sice zajímavá otázka, ale je to přesný opak otázky, kterou si musíte klást, když chcete něco zabezpečit. Vy se ptáte: „Jak se ke mně dostane ne příliš schopný útočník, který má smůlu, špatné nástroje a je na špatném místě?“ Když chcete něco zabezpečit, musíte se ptát: „Dokáže tohle překonat schopný útočník, který je na správném místě, má správné nástroje a bude mu přát štěstí?“ Když budete zabezpečovat barák, taky nebudete řešit magora, který by se pokusil prorazit železobetonovou zeď, ale zaměříte se na slabá místa baráku, takže na okna, dveře, různé šachty.
Takže počítejte s tím, že tím útočníkem může být soused, který je s vámi za stejným NATem, může to být váš ISP. A kdyby na vás chtěl někdo útočit vzdáleně? Nemusí útočit přímo na vás, ale může nejprve zaútočit třeba na toho souseda nebo ISP.
No a pak existují techniky, které otevřou „díru“ v NATu s malou pomocí zevnitř sítě – přičemž ta pomoc nemusí přicházet od napadeného počítače, může to být i něco, co vlastně udělá normální program při běžném používání. Používá se to i u legitimní komunikace – když spolu mají navázat dva počítače za NATem přímé spojení, třeba kvůli VPN, IP telefonii, přenosu velkých souborů nebo jen chatu, mohou si s pomocí třetí strany takové „tunely“ v NATu, že pak mohou komunikovat přímo, bez potřeby prostředníka – ten slouží čistě jenom k tomu, aby se ty dvě strany domluvily, kde a jak ten tunel v NATu udělají.
1) jednoduse ... firewall na ipv4 s NATem ... 384 pravidel. Exaktne totez na Ipv6 ... 168 pravidel. Tzn, pravdepodobnost chyby je zcela jiste polovicni, ne-li lepsi. Na sestce nemusim resit v jaky fazi routovani ma paket jakou IP a kde to jeste je OK a kde uz ne, kdyz ma Ip z privatniho rozsahu.
2) dalsi trotl co nema paru co udela router kdyz na nej prijde dst 192.168.1.1? To je zazrak, co? On to odroutuje. Jedinej chuj tu ses prave ty a prave magori jako ty zpusobujou to, ze se da do domacich siti dostat lusknutim prstu, protoze sou prece v bezpeci za NATem.
Citace: "dalsi trotl co nema paru co udela router kdyz na nej prijde dst 192.168.1.1"
... můžeš nám tedy objasnit co ten router udělá? Jak jako že to "odroutuje" když má jen NAT s nat tabulkou? Na základě čeho konkrétně? Těšíme se na pohádku protože takhle to vypadá že jen trollíš.
Linux (na kterem je postaveno mnoho SOHO routeru) apriori nerozlisuje nejaky WAN ci LAN port. Pokud mu prijde nejaky packet (bez ohledu na port), ktery namatchuje v conntrack tabulce stavajicich spojeni, tak ho podle zaznamu z tabulky upravi, jinak ho proste routuje tak, jak je + aplikace firewall (iptables) pravidel.
Nejjednodusi NAT-router tedy obsahuje jen jedno iptables pravidlo, ktery rika, ze pri odchodu paketu pres WAN rozhrani se ma aplikovat NAT. V takovem pripade se prichozi pakety na WAN, ktere nematchuji v conntract tabulce, zpracuji uplne stejne, jako by prisly z LAN rozhrani. Pravda, dneska uz je docela obvykle, ze domaci routery defaultne obsahuji i iptables pravidla, ktera blokuji prichozi pakety z WAN, ktere nebyly namatchovane v conntrack tabulce (tedy stavovy firewall), nicmene to neni nutna podminka pro NAT.
Nikdy neříkej že něco nejde, protože se najde pitomec, co neví, že to nejde a udělá to.
Tak důkaz sporem, jak v matematice. Pokud se najde jedna možnost, jak NAT překonat, tak je tam bezpečnostní díra.
Třeba chlápek přes ulici, kterýho v noci probudil tvůj pes, nemůže znovu usnout a náhodou ví, že máš stejnýho ISP a stejný segment sítě jako on.
- Je na stejné síti za CGNATem jako ty (vidí tvůj router přímo, ale komunikaci vás dvou nevidi firewall ani router u ISP)
- Má kontrolu nad zařízením v té síti (jeho router, který dokáže přímo komunikovat s tvým)
- Umí upravit pravidla vlastního routeru tak, aby měl jiný rozsah IP naž ty
- Umí upravit pravidla vlastního firewallu tak, aby tvůj rozsah IP adres prošel ven.
- Má možnost oskenovat IP a MAC adresy v síti
- Má možnost poslat přímo na libovolný domácí router v síti cokoliv.
Vážně NAT bez firewallu nemůže ohrozit naštvaný soused?
Z internetu ale nepřijde nic co by mělo jako destinaci ip adresu v lokální síti. Pro internet je totiž lokální ip adresa neplatná.
Nemáte pravdu. Internet je hodně velký a zahrnuje také zařízení, která jsou na stejném segmentu sítě, jako vnější rozhraní vašeho routeru. Představte si, že jste v paneláku, ISP tam má jeden switch, do kterého jsou připojeny routery jednotlivých bytů. Každý bytový router NATuje, takže máte pocit, že můžete být v klidu. Ale představte si, co se asi stane, když soused pošle z vnějšího rozhraní svého routeru paket s MAC adresou vašeho routeru a cílovou IP adresou z lokálního rozsahu, kterou má nějaký váš počítač.
ad2)
Nejsem teda znalec, ale z meho laickeho pohledu nevim jak by se mohl na napr. muj domaci router zvenku dostat paket urceny na LAN rozsah, rekneme klasicky 192.168.1.0 .
Prece zadny ISP neodroutuje paket s dest 192.168.1.0, nebo se pletu?
Jak by utocnik, rekneme z vedlejsi vesnice poslal paket, ktery se dostane az na muj LAN?
Diky za vysvetleni
patamat5: Pletete se. Ten paket se tam může dostat třeba tak, že ho pošle kdokoli, kdo je na stejné síti, jako vnější rozhraní vašeho routeru. Takže pokud bude někdo ve vedlejší vesnici připojený na stejné WiFi AP nebo kabelem na stejný switch, prostě jen pošle paket s IP adresou cíle 192.168.1.0 a MAC adresou vnějšího rozhraní vašeho routeru. K žádnému routování v síti ISP v takovém případě nedojde.
No, snizuje, ale neeliminuje. To je prave ten nejvetsi problem.
Predstav si, ze na stejne siti je pripojenych radove 200 dalsich lidi. Kdokoliv z nich se muze dostat na tvoje computery za NATEM. Ovsem co hur, libovolny hacker, ktery hackne souseduv spatne zabezpeceny windows 95, se pres nej muze dostat na tvuj super zabezpeceny system.
Nesnižuje, pokud se totiž někdo dostane k heslu k WiFi, vidí komplet traffic včetně MAC adresy. Když předpokládá síť za NATem s rozsahem 192.168.x.y (99% šance), má jenom 65k možností, kam ten ping poslat, a pravděpodobně se při vypnutým firewallu něco ozve.
https://www.root.cz/clanky/odposlouchavani-a-prolamovani-wi-fi-siti-zabezpecenych-pomoci-wpa2/
Cokoliv jde ven z baráku, je třeba považovat za veřejnou síť, kde není garantováno, kdy co přiletí. Cokoliv za NATem je co do bezpečnosti stejný, jako IPv6 s veřejnýma adresama (s tím, že firewall má v obou případech stejný vliv).
2Filip Jirsák: Vpohode to projde na 90% i pres router providera. Mozna i vic. Otestovano mockrat, bez potizi se da projit prevazne pres 5-8 hopu. A sourcerouting taky prevazne funguje vpohode. Naprosto bez zavani mi prave ted chodi icmp reply pres 1/2 republiky kde v src ty odpovedi je 10.x ... pricemz to protece jak NIXem tak tim cendrovo bordelem a protoze se spolu nekamaradej, tak to jeste profrci oklikou pres londyn.
Pardon, korektně fungující NAT by neměl routovat ale jen NATovat. Pakliže někdo nastaví NAT jako router, je to hloupost a potřebuje firewall.
Jenomže řeč je o routerech, na kterých je také nastaven NAT. A routery routují.
„Jenom NATovat“ je nesmysl. NAT překládá adresy proto, aby paket se změněnou adresou někam dál poslal. Takže musí buď routovat nebo se musí chovat jako bridge. A NAT na bridge by byl z hlediska „zabezpečení“ ještě daleko horší, protože by do vnitřní sítě posílal úplně všechno, co by dostal na vnějším rozhraní.
Tohle ale není pravda:
Samotný NAT nezajišťuje bezpečnost a typicky se ani sám nepoužívá, jelikož ho lze "prostřelit". Většinou se používá kombinace NAT+firewall, kde se blokoují spojení z venku.
Nejpoužívanější typ NATu zásadním a přitom inteligentním způsobem řeší bezpečnost. Komunikovat z internetu mohou jen ti, kteří byli sami kontaktování aplikací z lokální sítě. Tedy v podstatě všichni kdo náhodně skenují internet jsou odříznutí, což podstatným způsobem zvyšuje bezpečnost.
Naproti tomu, pokud si zavedete IPv6 opravdu se musíte začít starat o firewall. Potřeboval bych nějakou funkci co by na IPv6 simulovala běžný NAT, abych se nemusel starat o firewall a nesnížil si tím bezpečnost.
Ostatně je to jedna z věcí, která brání IPv6 k většímu rozšíření. Mít totiž lokální podsíť a NAT opravdu bezpečnost zvyšuje a to i když se člověk nestará o firewall.
Tvle muzete mi ric proc sem tyhle debilove lezou ve velkym? A pak reste nejaky zabezpeceni domacich siti kdyz takovyhle debilove to klidne i konfigurujou a tvarej se jak tomu rozumej ...
Ta krabice je predevsim ROUTER a ten nedela NIC jinyho, nez ze veme paket, podiva se na DST a posle ho na port, na kterej mu miri routa, a v pripade domaci routeru existujou moznosti prevazne jen dve. Bud to posle dovnitr, protoze adresa odpovida vnitrnimu rozsahu, nebo to posle na default GW, protoze nevi kam jinam by to poslal. Zadnej NAT mu v tom nezbrani protoze NAT ty trotle dela JEDININOU vec, veme pakety ktery smerujou zevnitr ven, a zmeni jejich SRC na zadanou(prevazne verenou) IP, pricemz si ulozi do tabulky src port. A kdyz prijde zvenku paket kterej ma za dst ten port, tak mu prozmenu zmeni DST IP a ...!!!! ODROUTUJE !!!!! ho.
Tudiz pokud ten paket dorazi rovnou s vnitrni IP ... tak !!!prekvapeni!!! ho odrroutuje taky.
Přečtěte si něco o tom, jaké existují typy NATů. Jeden typ nepřidá nic na bezpečnosti.
https://cs.wikipedia.org/wiki/STUN
Neřeší.
Router bez NATu dostane paket, vezme z hlavičky IP adresu a vidí, že ta adresa odpovídá síti na portu X, tak to předá na port X.
Router s NATem má jenom navíc jedno pravidlo
if(packet.source_addr in lan_range) apply_nat(packet)
Když přijde na WAN požadavek na adresu za routerem, projde durch. Od toho je firewall, aby řek, že má zahodit paket, pokud přijde zvenčí do adresního rozsahu LAN.
NAT naopak bezpečnost zhoršuje, protože vytváří falešnou iluzi bezpečí a idioti neřeší firewall, protože z jedné "veřejné" adresy sítě za LAN přece paket dovnitř neprojde... Ostatní adresy, na který může útočník mířit, nějak neřeší.
To není pravda. NAT hlavně vytváří vlastní mapování, které si pamatuje, aby dovedl směrovat i pakety z internetu do vnitřní sítě.
Je více způsobu jak to lze dělat. Nebezpečný je jen způsob "full cone NAT".
https://cs.wikipedia.org/wiki/STUN
Všechny ostatní typy NATu funkčně nahrazují firewall.
IPv4 má cca 2^32 adres. Na jednu z nich posadíš něco, co jde prostřelit jenom na pozvánku z druhé strany. Zbytku si nevšímáš (nemáš firewall).
Je to jako když máš pozemek s obvodem 4 000 000km, na oficiální cestu postavíš metr širokou branku, kterou otevře vrátný těm, kdo se prokážou pozváním a jsou na seznamu. Ploty a tak neřešíš. Pak prohlásíš, že se tam nikdo bez pozvání nedostane.
Kdo chce, prostě tu branku obejde. A vrátnýmu je to jedno, protože on je placený za hlídání a obsluhu branky, ne za to, aby někoho honil kolem pozemku.
@xsouku04
"Nejpoužívanější typ NATu zásadním a přitom inteligentním způsobem řeší bezpečnost."
To čemu říkáš nejpoužívanější typ NATu je ve skutečnosti NAT + firewall. Nic ti nebrání si podobným způsobem nastavit firewall na IPv6, tedy že budeš mít blokované vytváření spojení z venku.
127.0.0.1 - bez té to prostě nefunguje
::1 - bez té to taky nefunguje
fe80::xxxx:xxxx:xxxx:xxxx - automaticky vygenerovaná
fe80::1 - kdo si má pamatovat xxxx:xxxx:xxxx:xxxx
2001:470:...xxxx:xxxx:xxxx:xxxx - automaticky vygenerovaná
2001:470:...:1 - kdo si má pamatovat xxxx:xxxx:xxxx:xxxx
2001:470:...:1:1 až ...5:1 - různé služby, nemusí mít různé porty, když mají jinou IP, obvykle webové aplikace
172.x.x.2, 172.x.x.3, 172.x.x.4, 172.x.x.255 - služby pro zařízení, která je obtížné nastavit do jiné sítě (vývoj)
192.168.1.1 - přístup na zařízení, které se nedá nastavit do jiné sítě (debil výrobce)
10.1.1.10 - "normální" IPv4 adresa
" Uživatelské výhody IPv6 jsou pak zcela zřejmé, můžeš mít veřejnou adresu pro všechna zařízení."
Na něco takového neni technika připravená. kdo zajistí bezpečnost těch věcí a jak můžeme věřit výrobcům? Co až se třeba ukáže, že všechny pračky a ledničky maji root/root a přístupné ssh? A kdo vlastně potřebuje něco takového? Já tu žádnou výhodu nevidim.
"Na něco takového neni technika připravená. kdo zajistí bezpečnost těch věcí a jak můžeme věřit výrobcům? Co až se třeba ukáže, že všechny pračky a ledničky maji root/root a přístupné ssh?"
Chápeš rozdíl mezi "můžeš mít veřejnou adresu" a "musíš mít veřejnou adresu"? Když nechi mít pračku a ledničku přistupnou z internetu, tak jim nechám jen link-loacal a nebo link-local a unique-local adresy. Nebo jim dám veřejné, ale na firewallu nastavím patřičná pravidla (s kým můžou komunikovat a jestli vůbec můžou komunikavat).
NAT není kvůli bezpečnosti a nikdy tak nebyl plánován. Dává spíš pocit falešného bezpečí. Jakmile útočník ovládne alespoň jedno zařízení z vnitření sítě (což nemusí být nijak složité), může si dělat co chce.
"A kdo vlastně potřebuje něco takového? Já tu žádnou výhodu nevidim."
Někteří lidé by třeba rádi doma měli z internetu přístupný web server a nebo rozumně provozavali VoIP a nebo by rádi sdíleli soubory bez nutnosti nahrávat je do čmoudu.
Tobě NAT možná nevadí, protože nejspíš jenom brouzdáš po webu, ale ostatní třeba chtějí víc.
Běžně používaný typ NATu bezpečnost zvyšuje, protože dovnitř může jen ten, kdo byl nejdříve sám kontaktován zevnitř.
Pokud se někdo dostane na zařízení uvnitř sítě, je to špatné Nicméně útočník tam má tu komplikaci, že si musí si otevřít zadní vrátka přes nějakou veřejnou ip adresu.
Ale to je špatné i pokud se tam dostane přes IPv6, zadní vrátka často netřeba, může kontaktovat přímo.
Běžně používaný typ NATu bezpečnost zvyšuje, protože dovnitř může jen ten, kdo byl nejdříve sám kontaktován zevnitř.
To není pravda. Bohužel běžně používaný typ NATu bezpečnost snižuje, protože se bohužel najde spousta lidí jako vy, kteří si myslí, že je NAT před něčím ochrání. NAT nedělá nic jiného, než že jenom překládá adresy v paketu, a k tomu potřebuje umět uhodnout, co asi tak patří k sobě. Když na router s NATem dorazí paket s IP adresou z vnitřní sítě, tak ho prostě pošle na cílový počítač. Když na ten router dorazí paket, ze kterého NAT usoudí, že by měl přeložit jeho IP adresu, přeloží ji a paket normálně pošle do vnitřní sítě na cílový počítač. To, že NAT komplikuje přístup z internetu do vnitřní sítě vám, neznamená, že je to problém pro útočníka.
Pokud se někdo dostane na zařízení uvnitř sítě, je to špatné
Ne, špatné je SOHO síť považovat za bezpečnou síť. To už dávno neplatí a jediné bezpečné řešení je považovat SOHO síť za veřejnou síť.
Přečtěte si prosím něco o tom, jaké existují typy mapování NATů.
https://cs.wikipedia.org/wiki/STUN
Nebezpečný typ NATů je jen Full Cone NAT, který se naštěstí téměř nepoužívá.
Na wan by neměly být akceptovány pakety kde je destinace lokální síť.
Neměly. A víte, která síťová komponenta se může postarat o to, aby akceptovány nebyly? Firewall.
NAT funkci routeru přeci nepotřebuje, tak proč ji tam vůbec dávat? NAT má NATovat a ne routovat, pak si ušetřím fidlání s firewalem.
Když tady tak tapetujete diskusi tím, že si mají ostatní zjistit, co je to NAT – měl byste jít příkladem. Zkuste si představit, jak by fungoval takový NAT, který by jenom NAToval, nedělal by nic jiného – ani by neroutoval, ani by nefungoval jako bridge. Takový NAT by byl na hranici vaší sítě, dostal by paket z vnitřního počítače a změnil by jeho zdrojovou IP adresu. A co dál s tím paketem? Routovat nesmí, přeposlat na druhé rozhraní (jako bridge) také ne. Takže vlastně jen zbývá rozhodnout, zda je paket určený pro tento počítač (tedy to NATující zařízení) – není, takže se paket zahodí.
Nektery lidi (BFUcka) by si radi treba doma pustili tu gamesu, kterou si za litr koupili, a zahrali si ji s kamosem vedle v baraku, kterej je stejnej BFU jako oni. Ale nefunguje jim to. Jiny by si treba chteli pustit videokonferenci ... ale taky jim to nefunguje (vyzkousel sem desitky ruznejch, pokud nejsou na vsech zucastnencyh verejny IPcka, vzdycky je nejakej problem, jednomu jde obraz bez zvuku, druhymu zvuk bez obrazu, treti nevidi nic, ctvrtej se ani neprihlasi ...). Dalsi by treba chtel z domova stahnout ty fotky aby je moh ukazat, ale nema jak se tam dostat ...
Já bych se rád jednou dožil toho, že Retroshare pojede přes 6 a nebude třeba složitě nastavovat vnitřní a vnější port, předávat s klíčem 2 adresy, nastavovat na NATu přesměrování pro každého klienta uvnitř sítě a někomu, kdo nemá veřejnou, ještě dělat prostředníka (s tím, že to funguje všelijak).
Tak jinak:
Vy pravděpodobně zvenku dostupné adresy nevyužijete (asi je to tak lepší), ale výrobce krabičky (pokud není úplným kokotem) vám místo pravidla pro NAT přednastaví pravidlo pro zablokování provozu zvenku. Bezpečnost je tak stejná (ne-li vyšší) a vy získáte výhodu, že nebudete s nikým v síti (aťto vlastní či CGN) sdílet adresu, takže např. vás kvůli sousedovi nezabanují na serveru. Žádné nevýhody z toho pro vás neplynou, spíš možnosti navíc.
Tahle zařízení je potřeba strčit do speciální VLANy a pokud možno jim odříznout přístup na Internet – např. tiskárna má tisknout a ne se někam připojovat (mohla by někam např. odesílat vytištěné dokumenty).
Pokud to zařízení není otevřený hardware nebo aspoň standardní systém, kam sis nainstaloval otevřený OS, tak není radno tomu moc věřit.
IPv6 je naprosta nezbytnost. Kdo tady placa nesmysly o tom, ze NAT spravi vsechno tak nevi, jak (ne)funguje internet.
Kdyby byl NAT resenim, tak by cely svet potreboval jedinou IP adresu a cely by byl za jednim velkym NATem :-)
Konkretni priklad toho, jak soucasny internet nefunguje:
Mame po svete stovky klientu, kazdy z nich ma jedno nebo vic nasich zarizeni. Kdyz na nich potrebuju udelat jakykoliv servis, musi se napred spojit na nas server, nahodit vpn, ja si ze servera musim zjistit jakou ma pres vpn adresu a pak jit pres dalsi vpn a pres servera na tohle zarizeni. Pritom by stacilo naprosto jednoduse udelat ssh na 2001:1234:5678:abcd::1234. Kdyby meli IPv6 adresu. Jenomze tu nemaji.
Zkouseli jsme teredo, jakz takz to fungovalo, ale v konecnem vysledku nic moc. Nakonec to skoncilo tim nasim serverem se stovkami vpn.
Jinak, v kancelari mame ipv6 pres 6to4, nas provider totiz o ipv6 jeste neslysel. Nebudu se o nem vyjadrovat...
A kdybych mel poscitat vsechny hodiny, co jsem stravil konfigurovanim routovani portu na NAT, abych se dostal na vnitrni sit e jake jsou problemy s https, protoze treba Lets'encrypt v podstate neumoznuje vydat certifikat na zarizeni, ktere neni dosazitelne na portu 80 a dalsi problemy, tak bych nascital nejmin rok.
No to je ještě dobrý. Dělali jsme zařízení pro jeden obchodní řetězec a jejich požadavek byl "reakce na povel z webu / mobilu do 5s". A protože se nedalo počítat s IPv6, nakonec to dopadlo tak, že co 2,5s se zařízení ptalo serveru "Máš pro mě něco?" Každý dotaz a odpověď dohromady 2kB, objednávka byla na 20k ks první rok. Jenom na tohle dotazování skrz NAT padlo na jedno zařízení v průměru 48kB/minutu, tj.skoro 68MB/den.
A když se to napočítalo i s produkcí na dalších pět let, tak v DC skončil rack s trojicí load balancerů, dva servery se SQL na požadavky, front end servery se 16 fyzickýma jádrama, dedikovaná optická lajna,...
U IPv6 by si zařízení pamatovalo svůj stav. Appka v mobilu by znala IPv6 adresu, domluvili by se napřímo, bylo by to rychlejší a levnější. Na server by vlastně chodilo jenom sosat update softwaru a realizovat seznámení při instalaci, aby user nemusel přepisovat IP6 adresu... Stačilo by na to normální VPSko.
Petre, to jste delali zbytecne slozite.
Ja bych si predstavoval podstatne jednodussi reseni tohoto problemu:
Server, bude poslouchat na tcp portu treba 1234. Na clientske masine za NATem se nahodi spojeni na server, port 1234 a posle se mu ID clienta, aby server vedel, kdo se spojil (podle IP to nepozna). Pak bude client cekat, az mu server neco posle, spojeni zustane otevrene. Jednou za par minut by se poslat kratky packet, aby nespadlo spojeni, ale typicky by client zustaval nemy. Az by server mel nejaka data pro clienta, podiva se do tabulky na kterem spojeni visi tento client a posle se mu to. Client to dostane v realnem case.
Pokud spojeni spadne, client ho okamzite obnovi a znovu se prihlasi.
Server by musel pouze ustat radove 100k aktivnich spojeni, ale traffic by byl pomerne maly.
Samozrejme v praxi by kanal musel byt kryptovany, a podobne vychytavky, ale v principu by to mohlo fungovat takto.
Já bych si představoval ještě jednodušší metodu, přímo se bavit mezi sebou. Odpadl by SPOF, traffic by šel dolů, klesla by energetická náročnost a cena výrobku o docela podstatnou položku. Ony totiž servery ($$$), vyvinout a odladit serverovou část ($$$), hosting ($$$), konektivita ($$$), energie ($$$) a údržba ($$$) se musí zaplatit v ceně výrobku, takže to nakonec dalo pěkných cca 40% VO ceny. Jenom proto, že je potřeba probourat debilní NAT.
A to pinkání na servery, to je přesně ten princip, jakým se udržuje otevřený spojení. Jenom nelítají pakety jenom tak, ale v daným čas a s nějakým nákladem. Když už to tam je a jde o čas...
Takovou službu už leta provozuje Go6lab: https://go6lab.si/current-ipv6-tests/nat64dns64-public-test/
O tom vím, psali jste to tu, ale:
1. Je to jen vzdálené testovadlo, ne výkonové, koncepční řešení v propojovacích uzlech po světě.
2. Tunel žádný neznám.
To je dobrý nápad! Ale obávám se, že aby taková služba byla uživatelsky atraktivní, musela by nabízet veřejné IPv4 adresy. A ty se dnes vyvažují zlatem.
Nabízet IPv4-in-IPv6 tunel s NATovanou adresou by asi moc atraktivní nebylo. Navíc by to na operátora kladlo nároky na ukládání překladů pro řešení případného zneužití.