, řada přišla na DNSSEC a další. Ondřej Surý z CZ.NICu zdůvodnil potřebu DNSSECu, především vysvětlil, jak se dá na DNS servery zaútočit a proč vám různé kličky nezajistí bezpečí.
Portál AbcLinuxu, 19. dubna 2024 19:27
Kdy se dočkáme IPv6 u Telefónicy? A kdy u UPC? To jsou otázky na které naleznete odpovědi v tomto článku. Dále se pak dozvíte, jaká témata byla obsahem přednášek na této zajímavé konferenci.
Minulý týden se v Praze konala dvoudenní konference Internet a Technologie 2011 pořádaná sdružením CZ.NIC a peeringovým centrem NIX.CZ. Konference se první den téměř výhradně týkala IPv6 a tento den se ostatně kryl se Světovým dnem IPv6. Konference zastávala především edukační význam – člověk IPv6 prakticky neznalý byl postupně seznámen s „proč“ i „jak“ na IPv6.
Druhý den se pozornost přesunula k jiným „internetovým“ tématům. Tento článek nepopisuje všechny přednášky – spíše jen představuje ty zajímavé. V příštích týdnech by měl být k dispozici videozáznam akce (která byla také streamována přes Internet) a použité slidy.
Středeční dopoledne bylo lehkým úvodem. Zástupce NIX.CZ nejprve informoval o tom, že v NIXu se také potýkali s nedostatkem IPv4 adres, a tak v březnu tohoto roku přešli z /24 bloku na blok velikosti /22. NIX.CZ samozřejmě členům přiděluje i adresy IPv6, avšak provoz přes IPv6 je o několik řádů menší než provoz přes IPv4.
Ondřej Filip z CZ.NICu dále představil novodobou historii IPv4 od velkorysého přidělování bloků typu A, B, C, D až po CIDR. Rovněž poukázal na zavedení NATu jako krátkodobého řešení před přechodem na IPv6 na začátku devadesátých let. Důsledně popsal způsob, jakým se předělují bloky postupně od IANA až k vašemu ISP. Upozornil na současný nedostatek adres v regionálních registrech. Nejhůře je na tom APNIC (Asie, Pacifik) následovaný RIPE (Evropa a okolí).
Následovala prezentace od Ministerstva průmyslu a obchodu, která na mě působila poněkud trapně. Byla plná čísel direktiv a nařízení a vzdálených letopočtů, což mi trochu připomnělo termíny na přijetí Eura. Ve výsledku jsme se dozvěděli, že s IPv6 je to na úřadech bída a chvátat se jim až tak moc nechce. A i když přijde nařízení shora, ne vždy pak dojde k realizaci.
Pavel Satrapa poskytl důležitý úvod do problematiky IPv6. Mimo jiné hovořil o možnostech tunelování (včetně 6rd), ale také NAT64+DNS64, což je asi poslední krok v nasazování IPv6. V tomto prostředí už nejsou přidělovány adresy IPv4 pro komunikaci s venkovním světem: DNS64 automaticky mapuje A záznamy na speciální AAAA záznamy a NAT64 se pak stará o zprostředkování komunikace se starým světem IPv4.
Pak už přišlo asi to, na co asi většina IPv6 chtivých a znalých návštěvníků čekala. Panelová diskuze se zástupci Telefónica ČR a UPC a také zástupci Seznam.cz, Mafry (iDNES.cz a Lidovky.cz) a Centrum.cz. Účastníci mohli klást své otázky přímo na místě a spolu s diváky online streamu pak mohli diskutovat (nebo se ptát) přes Jabber MUC místnost.
Zástupce tohoto poskytovatele se vyjadřoval hlavně k xDSL; u mobilního připojení je situace úplně jiná, tam se NATuje už dávno. Telefónica je v kritické situaci, protože součástí jejich nabídky je veřejná IPv4 adresa. Neočekávají, že by dostali přiděleny nové adresní bloky, a tak jim po všech optimalizacích dojdou IPv4 adresy někdy v první polovině roku 2012. K tomuto termínu směřují své aktivity týkající se IPv6.
Telefónica se problematice IPv6 věnuje už bezmála dva roky, především tráví čas přípravou strategie a konáním kroků k podpoře tohoto protokolu. Od loňské konference Internet a Technologie učinili značný pokrok, ačkoliv nefiremním (rezidentním) zákazníkům zatím IPv6 nenabízejí. Jejich páteř IPv6 podporuje a stejně jsou na tom i jejich DNS servery a hlavní webové stránky. Prozatím tedy v pilotním provozu dokážou nabídnout IPv6 pouze korporátním zákazníkům.
Omezením a brzdou celého přechodu není ani tak nasazení IPv6 jako takového, ale spíše příprava jejich vnitřních systémů, vyškolení pracovníků atd. Už mají ukázkové verze softwaru pro provisioning, ale ještě neumí vše, co je potřeba. Očekávají, že v rámci pilotního provozu budou mít první rezidenty na IPv6 už v listopadu, nejpozději na začátku roku 2012. Technicky je koncept jasný: dual stack přes PPP.
Celkový přístup Telefónicy není „hurá, nasadíme IPv6“, nýbrž „dochází nám adresy, tak nám nic nezbývá“. Noví zákazníci po kritickém bodu, kdy dojdou IPv4 adresy, budou dostávat jen neveřejné IPv4 adresy (dojde tedy na Carrier Grade NAT) a k tomu rozsah IPv6. Navzdory doporučením v RFC půjde jen o blok /64, nikoliv o /48, ale větší půjde přiobjednat, stejně jako si můžete extra IPv4 adresy objednat teď. Stávající zákazníci budou moci na tento model přejít také.
V tento moment mě zajímalo, jestli to opravdu znamená, že pokud budu chtít doma nativní IPv6, tak se budu muset vzdát veřejné IPv4 adresy. Nedostalo se mi zrovna konkrétní odpovědi (i to kolem mě kvůli tomu zašumělo), ale bylo mi řečeno, že veřejné IPv4 adresy bude možné i v budoucnu koupit podle ceníku.
Telefónica se bojí problémů u existujících zákazníků – IPv6 tedy nedostanete domů automaticky, bude to na požádání (chybějící podpora v modemech, ke kterým ani nemají přístup na dálku, problémová podpora v operačním systému atp.).
U UPC je situace o něco veselejší. Přípravu na přechod na IPv6 zahájili před několika měsíci (95 % sítě je prý připraveno) a po optimalizacích jim současný adresní prostor vystačí do konce roku 2012. V současnosti dokončují práce (upgrade síťových prvků) na kabelové síti, ale je před nimi ještě (podobně jako u Telefónicy) práce na provisioningu.
Co se zařízení u koncových uživatelů týče, zařízení fungující jako bridge budou bez problémů, ale odhadem v září budou muset nějak vyřešit problém zařízení fungujících jako router. Existující zákazníci budou mít k dispozici veřejnou IPv4 adresu a rozsah IPv6 (také jen /64). Noví zákazníci si budou muset vystačit s neveřejnou IPv4 adresou a navrch dostanou rozsah IPv6. Při přechodu jednoduše na dálku restartují modem u zákazníka.
Ve vzdálené budoucnosti pak dojde na NAT64+DNS64.
Ti se docela hezky shodli na tom, že IPv4 adres mají dost a celkově moc nechvátají. Zatímco ISP problém aktivně řeší a mají, řekl bych, s přechodem více práce, tady je ticho po pěšině. Na konci tohoto roku nebo někdy příští rok by se mohl IPv6 záznam objevit u některých méně významných, systémově odloučených služeb.
Zbytek dne byl věnován IPv6 do větší hloubky: Jaromír Talíř konkrétně popsal problematiku tunelování přes 6to4 a Teredo. 6to4 přináší problémy s MTU (je nutné jej snížit, proto weby testující funkčnost IPv6 zkoušejí i průchodnost velkých paketů) a taktéž různé snaživé firewally na cestě tento protokol mnohdy blokují.
Igor Šmerda z Nokie se pochlubil podporou dual stacku v telefonech Nokia počínaje už Nokií 5140 a 9500. Větší část problému ale samozřejmě leží na bedrech mobilních operátorů.
Ve čtvrtek jsme si už mohli od IPv6 odpočinout , řada přišla na DNSSEC a další. Ondřej Surý z CZ.NICu zdůvodnil potřebu DNSSECu, především vysvětlil, jak se dá na DNS servery zaútočit a proč vám různé kličky nezajistí bezpečí.
Za pozornost rozhodně stála přednáška Petra Eckersleyho z Electronic Frontier Foundation. Ten vysvětlil, proč se současný model SSL certifikátů musí zničit: běžný webový prohlížeč důvěřuje neuvěřitelnému množství certifikačních autorit (kromě těch hlavních i „podřízeným“ certifikačním autoritám). Mezi nimi mohou být autority různých vlád a i kdyby nebyly, tak jsou důkazy, že některé vlády tlačí na CA, aby vystavily certifikáty dle jejich představ. Jediná kompromitovaná CA ohrožuje bezpečnost všech prohlížečů, které dané CA věří. Celek je tedy natolik silný jako jeho nejslabší část.
Tento přístup je tedy celkově nefunkční: bezmezně věříme obrovskému množství subjektů a ještě jim za certifikáty platíme. EFF chce napomoci decentralizaci celého systému a obecnému rozšíření používání HTTPS.
Ačkoliv pro mě osobně byla zajímavá jen panelová diskuze, protože většinu ostatní problematiky jsem už znal, akce mě velice potěšila a musím organizátory pochválit. Má jediná výtka by tak směřovala jen k ozvučení. Světový den IPv6 se v ČR taktéž vydařil: podle informací od CZ.NIC byl v tento den každý desátý web v TLD .CZ dostupný přes IPv6. Provoz přes tento protokol v NIXu dokonce překonal mezník 1 Gbit/s, což je více než sedminásobek oproti běžnému stavu.
14.6.2011 07:53
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
15.6.2011 09:53
GeoRW | skóre: 13
| blog: GeoRW
| Bratislava
14.6.2011 09:47
houska | skóre: 41
| blog: HW
Mel bych jen pripominky k ozvuceni, usazeni prekladatelu (ackoliv jsem nesedel uplne vzadu, tak jsem ji slysel velmi zretelne) a posazeni diskutujicich u panelove diskuse - nebylo na ne videt, nechapu proc nesedeli na podiu)
14.6.2011 11:56
pavlix | skóre: 54
| blog: pavlix
proč bude kyslík i UPC dávat /64 prefix a ne /48?Krátká odpověď: Protože to stačí. Dlouhá odpověď: 1) Chtějí mít větší část pro své vlastní členění. 2) Nechtějí zbytečně plýtvat na lidech (domácnost či kancelář víc než /64 nepotřebuje). 3) Alespoň hrubé napasování do stávající obchodní politiky (další /64 dostaneš, ale za příplatek).
nebo nepochopili základní podstatu ipv6?Obávám se, že chyba není na jejich straně. Základní podstata IPv6 není v tom, že se budou k domácímu zákazníkovi za pár stovek měsíčně chovat jako k velké organizaci. Telefonica prostě dodá domácí router s /64 prefixem. Tak jako předtím dodala domácí router s /32 IPv4 a NATem.
domácnost či kancelář víc než /64 nepotřebuje
Bude-li chtít vlastní firewall, potřebuje aspoň /64 + 1.
14.6.2011 19:13
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
14.6.2011 19:46
pavlix | skóre: 54
| blog: pavlix
To jo, jedině používat ebtables. To si přechodem na nativní IPv6 docela pohorším.To je špatná interpretace... na bridgích můžeš normálně používat iptables, pokud vím. Ebtables potřebuješ jen když chceš chytat informace, které v iptables nejdou.
14.6.2011 19:44
pavlix | skóre: 54
| blog: pavlix
Bude-li chtít vlastní firewall, potřebuje aspoň /64 + 1.Což o to, domácnost s /64 bude obvykle mít vlastní router, který tu /64 bude rozdávat a zároveň bude realizovat funkci síťového firewallu. Ten se připojí přímo na linku od poskytovatele a tím pádem má vnější transportní IP (tedy v podstatě tu +1 dostanem vždy). Ale jinak, pokud půjde na routeru od poskytovatele vypnout /64 rozsah a zapnout statickou routu na link-local adresu firewallu, pak není ani žádná další IP potřeba. Pokud bychom nemohli zasahovat do routeru, který nám rozdává /64, tak máme problém tak jako tak. Filtrovat lze v pohodě pomocí bridge, ale různé IPsec a další VPN se budou muset trochu obcházet, tam ta jedna vnější IP bude trochu chybět.
Pokud vím, tak Telecom ohlásil konfiguraci přes PPP. Takže předpokládám, že zákaznický konec PPP bude mít adresu z jiného rozsahu (třeb jen link-scope), než delegovaný prefix.
Nicméně mě to taky štve, protože mám jak Ethernet, tak WiFi a chci je mít oddělené. A na obou bezstavovou autokonfiguraci. Tudíž potřebují víc, jak /64.
Což o to, domácnost s /64 bude obvykle mít vlastní router, který tu /64 bude rozdávat a zároveň bude realizovat funkci síťového firewallu. Ten se připojí přímo na linku od poskytovatele a tím pádem má vnější transportní IP (tedy v podstatě tu +1 dostanem vždy).Nejsem si jist, ze to takhle bude fungovat. Nedavno jsem se snazil zjistit neco o tom, jak je to s IPv6 a PPP, a pochopil jsem z toho, ze narozdil od IPv4, kde se spojovaci adresa prideluje v ramci PPP (a PPP tunel typicky nema normalni prefix), tak v IPv6 se v ramci PPP domlouva jen interface ID, ktere se pouzije na konstrukci link-local adresy a pripadne globalni adresy pridelene standardnimi prostredky (RA ci DHCPv6). Takze tech pridelenych /64 se pouzije spis na ten PPP tunel. Takze bych spis tipoval, ze to bude nejaky pseudobridge a lokalni pocitace budou skrz nej prijimat RA od poskytovatele. Ale je to spis castecna spekulace, nevite nekdo o nejakem RFC, ktery by specifikoval standardni zpusob nasazovani treba ADSL?
14.6.2011 13:41
pavlix | skóre: 54
| blog: pavlix
15.6.2011 10:10
pavlix | skóre: 54
| blog: pavlix
Nemůže (třeba časem) dojít k tomu, že přenosy přes carrier-grade NAT budou znevýhodněny, např. budou pomalejší?Může dojít k ledasčemu... nejlepší scénář je, že se s přechodem na IPv6 bude zdržovat tak dlouho, až se sesypou routovací tabulky :D (pokud k tomu dojde).
To by možná vytvořilo celkem rozumný "kompromisní" tlak na content providery. Jinak je k IPv6 zatím nic nenutí. IPv6 only zákazníci, to je daleká budoucnost.Já si myslím, že ve chvíli, kdy bude mít IPv6 nějakých 30%-40% zákazníků, kteří budou mít místo domácíhí IPv4 NATu carrier-grade NAT nebo NAT64, tak už budou všichni content provideři koukat po IPv6 kvůli rozlišení jednotlivých domácností (většina bude mít jen /64).
Vím, že se mnou netriviální počet místních nesouhlasí...
14.6.2011 13:51
pavlix | skóre: 54
| blog: pavlix
Co mně na té panelové diskuzi nesmírně potěšilo a naplnilo optimizmem bylo, že se vůbec nikdo nezmínil o nějakých "pokročilých" vlastnostech IPv6 jako mobilita, IPSec, atd... Dlouhodobě zastávam názor, že jediná alespoň trochu dobrá věc na IPv6 je právě to, že ten základ je obyčejné IP s většími adresami, a že ty s prominutím ptákoviny navrch si můžu strčit za klobouk.Není se čemu divit, když tam byli poskytovatelé internetu a ne správci firemních sítí a VPN. IPsec funguje velmi dobře už i na IPv4 (i když to stálo hodně úsilí, které na IPv6 nebylo potřeba), a na IPv6 těží právě z absence NATu.
Resp. je považuju za největší brzdu rozovje IPv6, které není schopné se prosadit za 10 let své existence.IPv6 se není schopné vedle IPv4 (samo) prosadit ve větší míře ani teď. Prosazuje ho nedostatek IPv4, jediný pádný argument (vše ostatní jsou jen bonusy). Bylo pouze potřeba počkat, až ty IPv4 opravdu dojdou. Považovat víceméně nezávisle vyvíjený IPsec a mobilitu, které jsou mimochodem už dávno pro IPv6 hotové, za brzdu, mi přijde jaksi... úplně mimo. Tvůrci síťového hardware a software mají IPsec už dlouho a mobilita není nic tak těžkého.
Teď to vypadá, že nám nic jiného nezbyde, tak alespoň udělejme jen to nutné a nepouštějme se do nějakých větších akcíZvětšení adresního prostoru je ta největší akce vůbec :). Vyžaduje upgrade software i hardware na všech úrovních a nedá se dobře dělat pozvolna.
14.6.2011 14:25
pavlix | skóre: 54
| blog: pavlix
14.6.2011 14:36
pavlix | skóre: 54
| blog: pavlix
14.6.2011 18:00
pavlix | skóre: 54
| blog: pavlix
16.6.2011 19:32
pavlix | skóre: 54
| blog: pavlix
Cítím se poctěn [tvým/jakýmkoli] uznáním mé inteligenceOn se přece necítí poctěn svým vlastním uznáním své inteligence, ne?
Znám několik dalších správců firemních sítí, kteří, když jsem jim ukázal OpenVPN, tak říkali věci typu: "To nemůže fungovat, to není tak komplikovaný jako IPSec", "Proč je IPSec tak složitej?". Někde to dokonce nasadili a jsou značně spokojení. Ale to jen bokem, k tomu IPSecuCo mně na té panelové diskuzi nesmírně potěšilo a naplnilo optimizmem bylo, že se vůbec nikdo nezmínil o nějakých "pokročilých" vlastnostech IPv6 jako mobilita, IPSec, atd... Dlouhodobě zastávam názor, že jediná alespoň trochu dobrá věc na IPv6 je právě to, že ten základ je obyčejné IP s většími adresami, a že ty s prominutím ptákoviny navrch si můžu strčit za klobouk.Není se čemu divit, když tam byli poskytovatelé internetu a ne správci firemních sítí a VPN. IPsec funguje velmi dobře už i na IPv4 (i když to stálo hodně úsilí, které na IPv6 nebylo potřeba), a na IPv6 těží právě z absence NATu.
Ono to jde ruku v ruce. Ano Cisco a spol už mají IPSec a mobilitu a další fičurky hotové a občas se mezi sebou i domluví. Zato jsem neviděl jediný SOHO router, který by to nějak uměl.Resp. je považuju za největší brzdu rozovje IPv6, které není schopné se prosadit za 10 let své existence.IPv6 se není schopné vedle IPv4 (samo) prosadit ve větší míře ani teď. Prosazuje ho nedostatek IPv4, jediný pádný argument (vše ostatní jsou jen bonusy). Bylo pouze potřeba počkat, až ty IPv4 opravdu dojdou. Považovat víceméně nezávisle vyvíjený IPsec a mobilitu, které jsou mimochodem už dávno pro IPv6 hotové, za brzdu, mi přijde jaksi... úplně mimo. Tvůrci síťového hardware a software mají IPsec už dlouho a mobilita není nic tak těžkého.
Ale no takTeď to vypadá, že nám nic jiného nezbyde, tak alespoň udělejme jen to nutné a nepouštějme se do nějakých větších akcíZvětšení adresního prostoru je ta největší akce vůbec :). Vyžaduje upgrade software i hardware na všech úrovních a nedá se dobře dělat pozvolna.
Upgrady se dělají pořád, ať už HW nebo SW, prostě nějaká verze už bude podporvat IPv6, pak se "dočasně" bude používat dualstack a pak se časem ta mrtvá IPv4 vypne... Nikde jsem neviděl, že by někdo na všech úrovních vypnul všechno IPv4 a přinesl všecko IPv6 a vyměnil to
14.6.2011 14:32
pavlix | skóre: 54
| blog: pavlix
Znám několik dalších správců firemních sítí, kteří, když jsem jim ukázal OpenVPN, tak říkali věci typu: "To nemůže fungovat, to není tak komplikovaný jako IPSec", "Proč je IPSec tak složitej?". Někde to dokonce nasadili a jsou značně spokojení. Ale to jen bokem, k tomu IPSecuVidíš, já jsem teď měl o IPsecu školení... a reakce byly spíše ve smyslu: „No, my používáme OpenVPN, ale tohle vypadá jednodušší, asi to začneme nasazovat taky, aspoň to bude narozdíl od OpenVPN fungovat všude bez nějakých kliček.“ Takže tu máme dva protichůdné pohledy, a co dál?
Ono to jde ruku v ruce. Ano Cisco a spol už mají IPSec a mobilitu a další fičurky hotové a občas se mezi sebou i domluví. Zato jsem neviděl jediný SOHO router, který by to nějak uměl.Pokud SOHO router definuješ tak, že nic neumí, pak je vše v pořádku. Pokud ho definuješ cenou a neznáš Mikrotik, tak je na čase rozšířit svůj přehled o síťových prvcích. Nicméně, ruku v ruce to nejde. IPv6 lze používat i bez IPsec, a IPsec lze používat i bez IPv6.
Ale no takTakže mi dáváš za pravdu? :)
„No, my používáme OpenVPN, ale tohle vypadá jednodušší, asi to začneme nasazovat taky, aspoň to bude narozdíl od OpenVPN fungovat všude bez nějakých kliček.“ Takže tu máme dva protichůdné pohledy, a co dál?A dál nic. Nikomu neberu jeho názor, ale je potřeba uvést názory oba, ty jsi uvedl jeden, já druhý, tak je to vyvážené... Ikdyž nechápu, jak někomu IPSec připadá jednodušší a jaké kličky jsou u OpenVPn potřeba, tak to neřeším a až někoho takového potkám, tak ho požádám, ať mi to předvede
Pokud SOHO router definuješ tak, že nic neumí, pak je vše v pořádku.Tady jsem se asi vyjádřil ne úplně přesně... Ne SOHO, ale takové to "SOHO", co si každý v krámě koupí za pár stovek a čeho jsou plné domácnosti a malé firmy...
Pokud ho definuješ cenou a neznáš Mikrotik, tak je na čase rozšířit svůj přehled o síťových prvcích.Zajímavé tvrzení, ale částečně s ním souhlasím. Dokud neznám všecho, je čas si znalosti rozšiřovat. Ovšem, co se týče Mikrotiku, resp. routerboardů, tak nějaké povědomí bych měl. Jenže z mně nepochopitelného důvodu nexistuje nic jako 750 s jednou wifi, takže pokud chci nahradit onen výsě uvedený "SOHO" za něco lepšího, tak se dostávam na tisíce korun. Nebo snad existuje něco, co má 5x ETH a 1x wifi a licenci, která umí AP a krabičku a adaptér? A btw: podpora IPv6 v Mirkotiku je sice uspokojivá, ale rozhodně tomu (alespoň ve 4.x) spousta věcí chyběla - třeba DHCPServer,EoIP. A zrovna z té přednášky jsem se snažil připojit přes Winbox na IPv6 a hle, prý co je to za divný port :2. Nakonec jsem ale našel na jejich stránkách verzi, která už to pobrala.
Tak daleko bych nešelAle no takTakže mi dáváš za pravdu? :)
Souhlasím, že je potřeba výměna HW a SW, o tom snad není potřeba diskutovat. Pokud mám něco, co IPv6 neumí a já IPv6 chci/potřebuju, tak to musím vyměnit... Já ale říkám, že se ty výměny dělají průběžne a z různých důvodů a často se tam to IPv6 prostě vetře tím, že to prostě umí verze, kterou nasazují kvůli něčemu jinému. A zároveň říkám, že pak se to dá dělat postupně a nikoliv najednou...
14.6.2011 18:08
pavlix | skóre: 54
| blog: pavlix
Ikdyž nechápu, jak někomu IPSec připadá jednodušší a jaké kličky jsou u OpenVPn potřebaChceš mi snad říct, že přijdu třeba k Windows Vista, stáhnu OpenVPN, a jedu? Možná jsem blbej já, ale zabralo mi to docela dost času to vůbec rozjet.
Nebo snad existuje něco, co má 5x ETH a 1x wifi a licenci, která umí AP a krabičku a adaptér?Pokud vím, tak mezi tisícovkou a dvěma (budiž to vcelku přiměřená cena) se dá SOHO řešení od Mikrotiku vybrat.
A btw: podpora IPv6 v Mirkotiku je sice uspokojivá, ale rozhodně tomu (alespoň ve 4.x) spousta věcí chybělaUž nějakou dobu se používá řada 5.x, právě kvůli IPv6.
Tak daleko bych nešelTedy nejsme ve sporu... alespoň pokud ignoruješ pár drobných problémků, které při přechodu z IPv4 na IPv6 vyplouvají. Já o nich bohužel vím, takže vím, že je tam pár starostí navíc, a nelze prostě ignorovat vše, co na IPv6 ještě nechceš. Tzn, ano, jde to postupně, ale ne tak hladce, jako ten IPsec, se kterým jsi to pokud vím srovnával, už jen proto, že IPsec nevyžaduje změny na všech zařízeních v síti.
Chceš mi snad říct, že přijdu třeba k Windows Vista, stáhnu OpenVPN, a jedu? Možná jsem blbej já, ale zabralo mi to docela dost času to vůbec rozjet.To je samozřejmě otázka, co myslíš tím přijdu, stáhnu, rozjedu. Já, když jsem poprvé OpenVPN zkoušel, tak jsem stáhl, napsal jednoduchej config a během (nekecám) 5ti minut jsem měl funkční tunel mezi dvěma WinXP. Můžu doporučit pěkný článek http://www.root.cz/clanky/openvpn-vpn-jednoduse/
Pak přidejme OpenVPN-GUI, které přidává perfektní GUI. Dokonce mají na stránkách howto, jak ten instlační balíček upravit, aby se dal personifikovat pro každého zaměstnance napříjkad. Dál jsem někde viděl aplikaci, která sama vygeneruje žádost o cert a pošle jí, něco jako Certificate enrollment wizard. Ale to se dostáváme někam dál, než standardní IPSec. A sice do situace, kdy každý klient má svůj certifikát (IPSec na to kdysi potřeboval speciální rozšíření, navzájem pochybně kompatibilní). Pokud se bavíme o group authentikaci, kterou jsem zatím mětšinou viděl, tzn. použije se na šifrování nějaký sdílený klíč a pak username/password, tak to OpenVPn umí taky, je to značně jednoduché a také funkční...
Nevýhodou OpenVPN (musím otevřeně přiznat) je, že TUN/TAP adaptér nemá podporu pro UAC. Zatím jsem po detailech nepátral, na Vistách jsem to zatím nikde rozcházet neuměl, na Win7 budu muset...
Pokud vím, tak mezi tisícovkou a dvěma (budiž to vcelku přiměřená cena) se dá SOHO řešení od Mikrotiku vybrat.Nezbývá, než odpovědět, že si budeš muset trochu rozšířit obzory
Bohužel nedá. Jediná možnost je http://www.i4wifi.cz/rb750gl-64-mb-ram-400-mhz-5x-gigabit-lan-vc-l4_d2415.html , případně verze G, případně předchůdce 450. Toto řešení, ač ho rád a hodně nasazuju, nemá WiFi. A v kategorii do 2K se dostaneme pouze na řešení typu http://www.i4wifi.cz/rb411u-300-mhz-1x-minipci-1x-minipci-e-1x-lan-1x-usb-1x-sim-vc-l4_d1497.html nebo http://www.i4wifi.cz/rb711u-400-mhz-cpu-32-mb-ram-1x-lan-1x-5-ghz-l3-u-fl_d1976.html . Ty jsou sice za slušné peníze, ale mají maximálně 2-3 eth porty, potřebují krabičku a adaptér a ještě k tomu, když jsme to tu smontovali a zkusili, tak jsme zjistili, že je potřeba dalších asi 500 za upgrade licence, aby to umělo AP.
Už nějakou dobu se používá řada 5.x, právě kvůli IPv6.Pokud mně paměť neklame, tak zařízení s dodanou licencí na 3.x nejde upgradovat na 5.x. Navíc 5.x je poměrně nová a někteří lidé na síťové infrastruktuře jsou spíše konzervativní
Ale ani tady nejsme ve sporu, i tak jsem to psal, že až od 5.x je ta podpora IPv6 slušná.
14.6.2011 19:56
pavlix | skóre: 54
| blog: pavlix
To je samozřejmě otázka, co myslíš tím přijdu, stáhnu, rozjedu. Já, když jsem poprvé OpenVPN zkoušel, tak jsem stáhl, napsal jednoduchej config a během (nekecám) 5ti minut jsem měl funkční tunel mezi dvěma WinXP. Můžu doporučit pěkný článek http://www.root.cz/clanky/openvpn-vpn-jednoduse/Rozjet OpenVPN mezi XPčkama umí s prominutím každej blbec.
Nezbývá, než odpovědět, že si budeš muset trochu rozšířit obzoryKdyž už, tak bych si je musel zůžit :), ale myslím, že to nebude potřeba. I kdybysme jen znásilnili tu klientskou jednotku, tak kolik může stát krabice a zdroj? ETH porty se dají rozšířit switchem za dvě stovky. K tomu 500 za upgrade. A máš SOHO řešení i s IPsec. Jestli to přesáhne 2000, tak jen o málo. Při troše snahy člověk jistě najde něco lepšího. Já tyhle věci nehledám na i4, ale zeptám se u poskytovatele a ten vždycky něco vytáhne ze skříně :). Já osobně jsem trochu větší hračička, takže asi brzo budu kupovat nějakého TP-Linka, ale za účelem instalace OpenWRT. Takže se mi nechce věnovat víc času dokazování, že lze sehnat dostačující Mikrotik, když jsem výše ukázal, že cca za dva tisíce jde to řešení poskládat alespoň nějak. IPsec jsem potřeboval nasazovat zatím akorát ve firemním prostředí, kde na mé doporučení koupili RB-1100 nebo něco podobného, tam zase nebyl tak ostrý požadavek na cenu.
i tak jsem to psal, že až od 5.x je ta podpora IPv6 slušná.Tak tak.
I kdybysme jen znásilnili tu klientskou jednotku, tak kolik může stát krabice a zdroj? ETH porty se dají rozšířit switchem za dvě stovky. K tomu 500 za upgrade. A máš SOHO řešení i s IPsec. Jestli to přesáhne 2000, tak jen o málo.Co se člověk nedozví
Jen pro dokreslení, krabička je za cca 200-300, zdroj v podobných cenách. Trochu nám to šplhá, ale což, okolo 2K pořád jsme. Pak ten switch, ano, pohodka, jen tam bude další zařízení, za dvěstě nějaký noname... A asi bude tak pěkně manageovatelný, jako ty porty na mikrotiku. Nu a VLANy určitě zvládne taky...
Ale až buděš někdy mluvit s tím poskytovatelem, zeptej se ho na řešení v jednom zařízení, a pokud něco vytáhne ze skříně, opravdu jsem zvědavý, klidně pošlu dotaz do i4wifi, jestli to mají.
Jakmile není požadavek na cenu, tak můžeme mluvit o Ciscu PIX, RB1000 a klidně i o routeru na bázi PC.
OpenWRT jsem zkoušel cca 2 roky nazad. Ale s mikrotikem se to v mnoha ohledech srovnat nedalo.
Když už, tak bych si je musel zůžit :),Á, pán je suterén
Nu nechme to u toho, že ta zplácanina okolo 2K je to, co jsi předtím zmiňoval.
Chceš mi snad říct, že přijdu třeba k Windows Vista, stáhnu OpenVPN, a jedu? Možná jsem blbej já, ale zabralo mi to docela dost času to vůbec rozjet.
Rozjet OpenVPN mezi XPčkama umí s prominutím každej blbec.Můžu se zeptat, co je na těch Vistách tak zvláštního, čím se odlišují od těch XP, že tvrdíš tak odlišné věci? Já vím jen o tom UAC... Jinak tomu opravdu nerozumím
Jinak OpenVPN mi běhá na Linuxu, WinXP, FreeBSD, Mikrotiku i na Maemu a nikde, opakuji nikde, to nebyl větší problém než nainstalovat, zadat konfigurák a klíče.
Zato jsem neviděl jediný SOHO router, který by to nějak uměl.Levné krabičky pro koncové zákazníky, kam výrobce nedá nic, co opravdu nemusí, aby ušetřil, opravdu nejsou tím správným měřítkem...
14.6.2011 18:11
pavlix | skóre: 54
| blog: pavlix
14.6.2011 20:02
pavlix | skóre: 54
| blog: pavlix
14.6.2011 14:44
Petr Tomášek | skóre: 39
| blog: Vejšplechty
Zvětšení adresního prostoru je ta největší akce vůbec :). Vyžaduje upgrade software i hardware na všech úrovních a nedá se dobře dělat pozvolna.Nesouhlasím. Pokud by se IPv6 bylo vyvíjelo rozumně, tak se nejdřív udělalo jen to naprosto nejnutnější a namapoval by se adresní prostor IPv6 - IPv6 na přechodné období 1:1 (tj. vydalo by se RFC, že např. prvních 10 let by se mohlo používat jen 2^32 IPv6 adres namapovatelných na IPv4). Takže nemusel být vůbec žádný problém s routováním, jen by se podle jednoduchého schématu namapoval adresní prostor IPv6 - IPv4. No a po přechodné době by se povolily i další IPv6 rozsahy, což by velmi rychle přechod na IPv4 vpodstatě vynutilo. Jenže problém je ve tvůrcích IPv6, kteří museli za každou cenu nacpat do nové verze protokolu tolik nekompatibilních novinek, že už to pak takto nebylo možné. A je to škoda, protože kdyby se na to šlo chytřeji a nebyla snaha naráz všechno změnit, tak už tu IPv6 mohlo být dávno...
14.6.2011 18:12
pavlix | skóre: 54
| blog: pavlix
14.6.2011 18:31
pavlix | skóre: 54
| blog: pavlix
Takže nemusel být vůbec žádný problém s routováním, jen by se podle jednoduchého schématu namapoval adresní prostor IPv6 - IPv4.Je to asi zbytečné, protože prostě nechceš chápat a radši ze sebe děláš pitomce, ale jeden pokus tomu dám: problém s routováním by samozřejmě byl i podle tohohle schématu, protože s IPv6 se mění struktura paketu, přinejmenším musíš použít víc místa na adresu, takže to stejně znamená nutnost vyměnit HW/SW.
14.6.2011 18:40
pavlix | skóre: 54
| blog: pavlix
Ad a) není pravda, že se struktura musí změnit. Máme různé options a tak, kam by se dala uložit, pokud by to za to stálo.Fíha, tak od tud vítr vane... ty bys chtěl totálně vše sprasit, jenom abysme mohli předstírat, že se nic nezměnilo. Ale fuj.
Ad b) já jsem to pochopil tak, že by to bylo "normální" IPv6, ale pouze s rozsahy z IPv4.Já tě chápu, ale tohle „normální IPv6“ by způsobilo dvojí přechod místo jednoho, takže by vyšlo zbytečně draho.
Pak bych si dovedl představit, že se na nějaké gateway udělá mapování 1:1, něco jako teď ten NAT64. Ve vnitřní sítí mám IPv6 stroje a routery dělají ten "NAT" na IPv4. A postupně by se sítě s IPv6 zvětšovaly až by byly dost velké a to by byl ten moment, kdy by se to rozjelo řetězovou reakcí...Tedy vlastně bys chtěl, aby vymysleli něco jako NAT64, aby se mohlo postupně přecházet. Fajn, potěším tě, oni vymysleli dokonce přímo NAT64. Tudíž můžeš realizovat přesně to, po čem toužíš.
Ad c) Zmíněné řešení je sice kostrbaté, ale aspoň nějaké. Přiznám se, že první imho rozumné "oficiální" přechodové řešení, které jsem viděl je právě ten NAT64. Viz ta přednáška na IT11, kde byla většina těch řešení shrnuta...NAT64 má historii sice o něco kratší než IPv6, ale i tak je to schéma, které je známé už deset let. Nejmenovalo se to celou dobu NAT64 (to je relativně nový název), ale ten princip už je vymyšlený dlouho. Potíž je v tom, že firmy se začaly zajímat o IPv6 až na začátku roku 2011. Překvapuje mě, že se stále snažíš hledat problém někde jinde.
Fíha, tak od tud vítr vane... ty bys chtěl totálně vše sprasit, jenom abysme mohli předstírat, že se nic nezměnilo. Ale fuj.Nenapsal jsem, že to je možnost, ale že se mi to také moc nezdá? Jen jsem psal, že je možné to udělat, aniž by se ten formát změnil.
NAT64 má historii sice o něco kratší než IPv6, ale i tak je to schéma, které je známé už deset let. Nejmenovalo se to celou dobu NAT64 (to je relativně nový název), ale ten princip už je vymyšlený dlouho. Potíž je v tom, že firmy se začaly zajímat o IPv6 až na začátku roku 2011. Překvapuje mě, že se stále snažíš hledat problém někde jinde.No, kdyby se s tím řešením přislo před pár lety, tak by se mi to právě líbílo víc. Sice se mi to řešení moc nelíbí, protože je to prasárna, ale z nabízených možností je dle mně nejlepší. A proč to považuju za prasárnu? a) moc to připomíná to řešení s IP options b) nekombí se to zrovna nejlíp s DNSSECem... A můžu poprosit o nějaký odkaz, jak se to jmenovalo před tím, a třeba i na nějaké rok, dva tři staré howto, jak to na Linuxu/Mikrotiku nastavit? Opravdu v této problematice nemám kompletní znalosti, ale zatím jsem zaregistroval všechny tunely nebo tak, tak měly různé problémy. Ostatně i na té přednášce to bylo zmíněno. A nesnažím se problémy někde jinde. Jen zmiňuju ty věci, které se mi nelíbí. Věci, které se mi líbí nezmiňuju a používám (ano i já používám IPv6
), ale nad nimi nemám potřebu filozofovat/diskutovat ve fórech...
Jen jsem psal, že je možné to udělat, aniž by se ten formát změnil.Jenže nakonec bys stejně buď musel udělat skutečný přechod, ve kterém by ta adresa byla normálně, tedy v jednom kuse na daném místě v paketu, nebo obětovat rychlost kvůli nutnosti každý paket analyzovat v podstatě softwarově. V konečném důsledku by ses přechodu nevyhnul a ještě by to stálo víc. A nebo vyhnul, ale pak by to furt stálo víc a ještě bychom s sebou na věky táhly tu prasáckou variantu...
14.6.2011 20:54
pavlix | skóre: 54
| blog: pavlix
Nenapsal jsem, že to je možnost, ale že se mi to také moc nezdá?Ne. Ale je dobře, že jsi to tak myslel.
No, kdyby se s tím řešením přislo před pár lety, tak by se mi to právě líbílo víc. Sice se mi to řešení moc nelíbí, protože je to prasárna, ale z nabízených možností je dle mně nejlepší.Ono se s tím řešením přišlo právě cca před deseti lety. Dokonce z roku 2002 podle mě najdeš i nějaké prvotní implementace pro Linux a BSD (nepamatuju si názvy). Kdo chtěl, mohl v té době daný software doladit a uvést do praxe. V tu dobu o to ale z pochopitelných důvodů nebyl zájem.
A proč to považuju za prasárnu? a) moc to připomíná to řešení s IP options b) nekombí se to zrovna nejlíp s DNSSECem...Tak ona to samozřejmě prasárna je. Ale je to vyváženo tím, že: 1) Je to jediná metoda (ten způsob, ne konkrétní standard či implementace) zpřístupnění starého protokolu, která se dá udělat na jednom místě v síti (oproti metodám, co vyžadují podporu na každém stroji). 2) Ta prasárna bude po letech s časem mizet, ne přibývat. 3) Není to o moc větší prasárna než praktické nasazení stávajícího protokolu (jenom o quirky při překladu mezi protokoly, kterým se stejně nedá vyhnout).
nekombí se to zrovna nejlíp s DNSSECem...Já myslím, že se to kombí s DNSSECem velmi dobře. Ne bez úpravy, ale rozhodně dobře. DNS64 překladač lze spojit s validátorem (ať už na cílovém stroji nebo na síti). Přirozenější možnost bude obohatit validátory na koncových strojích o zpětný překlad a validaci A záznamu.
A můžu poprosit o nějaký odkaz, jak se to jmenovalo před tím, a třeba i na nějaké rok, dva tři staré howto, jak to na Linuxu/Mikrotiku nastavit? Opravdu v této problematice nemám kompletní znalosti, ale zatím jsem zaregistroval všechny tunely nebo tak, tak měly různé problémy. Ostatně i na té přednášce to bylo zmíněno.Zkusím si vzpomenout / vygooglit / zeptat se. Mikrotik to určitě neuměl, šlo o experimentální záležitost, o kterou se nikdo z dodavatelů krabiček pro lidi nezajímal (není se čemu divit, když se nezajímali o celé IPv6).
A nesnažím se problémy někde jinde. Jen zmiňuju ty věci, které se mi nelíbí. Věci, které se mi líbí nezmiňuju a používám (ano i já používám IPv6Já si osobně myslím, že hledat v tomto konkrétním případě chybu u tvůrců IPv6 je chyba. Samozřejmě, během vývoje udělali spoustu různých chyb, proto jsou taky ty RFC v několikáté generaci. Ale pozdní nasazení IPv6 podle mě padá na hlavu těm, co se pozdě rozhodli se jím vůbec zabývat. Všichni ISP, poskytovatelé hostingů a obsahu, výrobci hardware a software, správci sítí, a další zainteresovaní, měli možnost se zabývat IPv6 už cca 15 let a mohli včas připomínkovat všechny problémové části IPv6. Kdo se tím začal zabývat až 2010/2011, ať se laskavě smíří s dosavadním vývojem. Je pár věcí, kterým se v IPv6 mohlo zamezit včas, ale v době hotových implementací nezbývá než si vyžrat, co jsme si nechali uvařit.
14.6.2011 18:20
pavlix | skóre: 54
| blog: pavlix
Pokud by se IPv6 bylo vyvíjelo rozumně, tak se nejdřív udělalo jen to naprosto nejnutnější a namapoval by se adresní prostor IPv6 - IPv6 na přechodné období 1:1 (tj. vydalo by se RFC, že např. prvních 10 let by se mohlo používat jen 2^32 IPv6 adres namapovatelných na IPv4). Takže nemusel být vůbec žádný problém s routováním, jen by se podle jednoduchého schématu namapoval adresní prostor IPv6 - IPv4.To ale vůbec nepíšeš o vývoji IPv6, ale o nasazování IPv6, a to by vyžadovalo, aby všichni dobrovolně migrovali na IPv6 (byť s kratšími adresami) v době, kdy to ještě není potřeba. A kdo se trošku v globální síti pohybuje, musí vědět, že to je naprostá utopie.
Jenže problém je ve tvůrcích IPv6, kteří museli za každou cenu nacpat do nové verze protokolu tolik nekompatibilních novinek, že už to pak takto nebylo možné.V tvůrcích žádný problém není, tvůrce nikdo poslouchat nemusí. Tvůj přístup by fungoval, kdyby Internet byl centrálně řízený komunismus nebo alespoň firma. Nicméně, tvůj názor je přinejmenším docela zajímavý a opravdu by to takhle v malém měřítku (například ve firmě) udělat šlo. Ale je štěstí, že IPv6 vzniklo na míru globálnímu Internetu, kde funguje nejlíp ta metoda, s jakou se teď IPv6 v reálu nasazuje. A vzhledem k tomu, že je IPv6 z pricipu nekompatibilní délkou adresy (vynechme prosím utopii s mapovanými adresami), je nejlepší ty nekompatibilní změny udělat všechny najednou. Později už to vzhledem k decentralizaci (mimojiné i výroby) moc nepůjde.
A je to škoda, protože kdyby se na to šlo chytřeji a nebyla snaha naráz všechno změnit, tak už tu IPv6 mohlo být dávno...Ano, to je pravda, ale s tím nemají tvůrci nic společného. To bylo rozhodnutí manažerů, že se IPv6 nebude nasazovat, dokud to nebude vyloženě nutné. A nemůžeš chtít po manažerech a technicích z celého světa, aby se dohodli na nějakém postupu. Oni jsou rádi, když se vůbec dohodou v rámci jediné firmy.
V tvůrcích žádný problém není, tvůrce nikdo poslouchat nemusí. Tvůj přístup by fungoval, kdyby Internet byl centrálně řízený komunismus nebo alespoň firma.A tohle je to jádro pudla, na kterém se neshodnem
Ne, že by měli někoho poslouchat, ale měli by se trochu krotit a mít trochu pokoru a ponaučení z minulosti. Ale no tom už jsme se jednou neshodli, takže se neshodnem asi zase
14.6.2011 20:58
pavlix | skóre: 54
| blog: pavlix
A tohle je to jádro pudla, na kterém se neshodnemSpolutvůrcem IPv6 může být kdokoli, kdo napíše kus dokumentace nebo třeba jen důležitou připomínku Já, ty, kdokoli. Kdyby se o protokol při jeho tvorbě zajímali ti, kteří loni tvrdili, že není potřeba, a teď ho „narychlo“ uvádějí do provozu, leccos by se tím vyřešilo.
Celkový přístup Telefónicy není „hurá, nasadíme IPv6“, nýbrž „dochází nám adresy, tak nám nic nezbývá“.No, až tak bych to neviděl. Jejich přístup je rozhodně pozitivní. Lepší než u hromady jiných "ISP", kteří si před mnoha lety řekli "dochází na adresy, dáme klienty za NAT, a veřejnou IP na žádost / za příplatek, tak na co IPv6". A mnohým tento postoj ještě pár let vydrží. A stejně to mohli udělat u O2. Nic by se nestalo. Stejně jako se nic nestalo na jejich mobilní síti, kde to tak už je.
15.6.2011 10:35
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
První věc se týká NATu.Vždycky když slyším nějakého zastánce IPv6 mluvit o NATu, tak mám pocit, že mu NAT minimálně vyvraždil půl rodiny, jak nenávistně o něm mluví Asi se shodnem na tom, že NAT není bezpečnostní prvek, ten se dá na IPv6 udělat prostě firewallem (ikdyž to musí být stavový firewall a pak je CPU a jiná náročnost na firewall téměř identická). I toho maskování vnitřní sítě bych se klidně vzdal, to je spíš jen Security Thru Obscurity (ikdyž silně zaobskurněný).
Ale co jsem u IPv6 nenašel je ta nezávislost na poskytovateli(-ích), kterou mi NAT nabízí. Dokud nemám stovky počítačů, pak je přeci ideální mít svoje vlastní adresy, které při opouštění mé sítě najěkým způsobem namapuju na přidělené vnější. Pokud změním poskytovatele, tak se téměř nic neděje. Nebo v případě, že mám dvě připojení k Internetu - doma teď máme celkem 4 s různou kvalitou, rychlostí, atd.... Jaký je správný způsob, jak s IPv6 řešit takovouto situaci: Mám firmičku s 5ti počítači. Mají ADSL a k dispozici je nějaká free wifi. S IPv4 jim nastavím nějaké pěkné adresy typu 10.0.0.x, router bude mít dvě vnější rozhraní, jedno do ADSL modemu, druhé WiFi. Na každém z nich se nastaví NAT a stačí volit defaultní gateway (mikrotik umí sám podle pingu např). Jedinou cestu, jak by se to dalo udělat bez NATu, vidím v získání bloku nezávislém na poskytovateli a účastnění se routingu. Nebo při každé změně připojení přeadresovat všechny počítače.
A to mně přivádí k druhému dotazu. Existuje nějaký protokol/software (DHCP6?), který přiděluje adresy nějak sekvenčně bez EUI64? EUI64 se mi moc nelíbí a všiml jsem si, že i hodně serverů ho nepoužívá (2002:d91f:cd32::1 www.nic.cz, 2001:67c:68::18 wwww.root.cz). Všimněte si, že tyhle adresy už jsou vcelku zapamatovatelné, ovšem s EUI64 na konci to bude o poznání horší. Líbílo by se mi něco typu: Hele, tady máš prefix a rozdávej čísla ::100 až ::200.
15.6.2011 13:23
pavlix | skóre: 54
| blog: pavlix
První věc se týká NATu.Vždycky když slyším nějakého zastánce IPv6 mluvit o NATu, tak mám pocit, že mu NAT minimálně vyvraždil půl rodiny, jak nenávistně o něm mluvíNe, pouze nás stál hromadu peněz, protože nebýt jeho, tak bysme už před mnoha lety telefonovali po internetu. Tím pádem by pravděpodobně i veškeré ceny volání byly nižší, a to nejen pro nás, co tomu rozumíme. Taky bysme v mnohých případech ušetřili pěkný kus cesty, protože bysme někomu po telefonu prostě řekli, co má na firewallu jak povolit a mohli bysme daný stroj opravit na dálku. Takhle tam musíme buď dojet, nebo musíme mít nakonfigurovaný nějaký tunel, což většina z těch krabiček navíc ani neumí.
Ale co jsem u IPv6 nenašel je ta nezávislost na poskytovateli(-ích), kterou mi NAT nabízí. Dokud nemám stovky počítačů, pak je přeci ideální mít svoje vlastní adresy, které při opouštění mé sítě najěkým způsobem namapuju na přidělené vnější.Nezávislost na poskytovateli řeší AS a BGP. Pokud na to nemáš, tak lze na IPv6 používat 1:1 NAT, který je stále ještě mnohem lepším řešením než NAT 1:N.
A to mně přivádí k druhému dotazu. Existuje nějaký protokol/software (DHCP6?), který přiděluje adresy nějak sekvenčně bez EUI64? EUI64 se mi moc nelíbí a všiml jsem si, že i hodně serverů ho nepoužívá (2002:d91f:cd32::1 www.nic.cz,Příští díl článku o IPv6 bude obsahovat odpověď na tvoji otázku :). Krátká odpověď: Jde to a jmenuje se to DHCPv6.
Nezávislost na poskytovateli řeší AS a BGP. Pokud na to nemáš, tak lze na IPv6 používat 1:1 NAT, který je stále ještě mnohem lepším řešením než NAT 1:N.Osobně si myslím, že to není jen o tom, jestli na to mám, ale i o tom, jestli je to efektivní. Mít AS a BGP na každých pár počítačů je nejenom složité na správu, ale asi by to slušně zabordelilo i globální routovací tabulky. To mapování 1:1 je přesně to, co by mi stačilo.
Jde to a jmenuje se to DHCPv6.Já jsem si to myslel a počkám si na ten slibovaný díl
Leč bohužel ani jednu z těchto dvou věcí jsem na Mikrotiku 5.4 nenašel. Na linuxu (Fedora14) bych asi bez problemu rozjel ten DHCP, ale nevidim v man ip6tables možnost jakéhokoliv netmapu nebo něčeho podobného. Tzn. asi moc běžná záležitost to nebude? A přitom právě v tomto přechodovém období s triliardou možných tunelů by to bylo vhodné. CZ.NIC má veřejný 6to4 relay, super, jenže pokaždé, když se mi změní veřejná IPv4 adresa, změní se mi adresy v celé síti (auvajs). Můžu si pořídit nějaký tunel, kde se předem zaregistruju atd... ale ty jsou zase zbytečně daleko. Takže ideální varianta, tunel od NICu a když nepojede (třeba kvůli té změně IPv4), tak se to samo přehodí na horší tunel, který ale není závislý na zdrojové adrese.
15.6.2011 21:07
pavlix | skóre: 54
| blog: pavlix
Osobně si myslím, že to není jen o tom, jestli na to mám, ale i o tom, jestli je to efektivní. Mít AS a BGP na každých pár počítačů je nejenom složité na správu, ale asi by to slušně zabordelilo i globální routovací tabulky.Ne na každých pár počítačů, samozřejmě :). Pár počítačů je velmi často za jedním routerem, který sám tvoří single point of failure. Pak už je potřeba myslet na to, co se vlastně má pokazit.
To mapování 1:1 je přesně to, co by mi stačilo.Ještě aby ne :). Samo o sobě to slouží jako důkaz, že nějaká forma překladu adres se v IPv6 hodí.
ale nevidim v man ip6tables možnost jakéhokoliv netmapu nebo něčeho podobného. Tzn. asi moc běžná záležitost to nebude?Však taky dost lidí prohlašuje, že NAT není v IPv6 potřeba. Musíš počkat, až se přijde na to, že potřeba je :).
CZ.NIC má veřejný 6to4 relay, super, jenže pokaždé, když se mi změní veřejná IPv4 adresa,Můžeš používat veřejnou IPv4 adresu, která netrpí změnami, nebo používat tunel, který se nemění podle IPv4 adresy. Možností je spousta, například SixXS tunel přes Ignum.
změní se mi adresy v celé síti (auvajs).V IPv6 se přečíslování sítě nepovažuje za až takový průšvih, pokud nemáš stroje v DNS. Pokud ano, viz výše.
Můžu si pořídit nějaký tunel, kde se předem zaregistruju atd... ale ty jsou zase zbytečně daleko.Ignum/SixXS je daleko? Ideální varianta je samozřejmě nativní konektivita.
Ne na každých pár počítačů, samozřejmě :). Pár počítačů je velmi často za jedním routerem, který sám tvoří single point of failure. Pak už je potřeba myslet na to, co se vlastně má pokazit.Jo, jenže tenhle spof je tak nějak v dosahu. Jinak řečeno, jak jsem psal, typický příklad: Zákazník má dvě pidi kanceláře a 5 počítačů. Má ADSL a cca 99% času mu funguje. Jenže je na internetu hodně závislý, takže má ještě anténu namířenou na nějaký CZ.FREE AP. Tam má domluvenou poměrně malou konektivitu, ale přeci. Přehodí se mu to automaticky a on jen pozná, že mu to jede pomalejc, tak přestane stahovat hambatinky, ať mu ty emaily projdou. A čistě statisticky, ten router mu ještě neodešel, ADSL vypadává cca jednou do měsíce. A pokud nepomůže restart modemu, tak se dovolá dřív na lampárnu než na O2
V IPv6 se přečíslování sítě nepovažuje za až takový průšvihI když se nepoužijí ty link specific adresy? Výše zmíněný zákazník má v síti lokální SMB server. Pokud by se síť přečíslovávala, tak lokální spojení spadnou také, ne? A zase mít na každém stroji dvě IP (lokální a globální), to se mi moc nechce...
Ideální varianta je samozřejmě nativní konektivita.Chápu-li to správně, tak ta výše zmíněný problém nevyřeší. A přiznám se, že rád vyzkouším i různé ty tunely a spol, ať s tím mám co nejvíc zkušeností...
16.6.2011 00:22
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
I když se nepoužijí ty link specific adresy? Výše zmíněný zákazník má v síti lokální SMB server. Pokud by se síť přečíslovávala, tak lokální spojení spadnou také, ne? A zase mít na každém stroji dvě IP (lokální a globální), to se mi moc nechce...Proč? Vždyť to je správné a logické řešení! A kdyby IPv4 adres byl dostatek a k ADSLku by jich byl třeba blok /24, tak byste nakonec jistě také používal ještě lokální adresy právě z tohoto důvodu...
Dvě adresy ve mně evokují více problémů se správou, řešením problémů,....
16.6.2011 02:29
pavlix | skóre: 54
| blog: pavlix
16.6.2011 02:28
pavlix | skóre: 54
| blog: pavlix
A čistě statisticky, ten router mu ještě neodešel, ADSL vypadává cca jednou do měsíce. A pokud nepomůže restart modemu, tak se dovolá dřív na lampárnu než na O2Chápu. A výpadky jsou i u lepších poskytovatelů. Takže pokud to nutně musí být, tak IPv6 NAT rozsah na rozsah :).
I když se nepoužijí ty link specific adresy? Výše zmíněný zákazník má v síti lokální SMB server. Pokud by se síť přečíslovávala, tak lokální spojení spadnou také, ne?Proč by měla spadnout? Přečíslování na IPv6 je plynulé, prostě se začne preferovat jiný prefix a ten starý se nechá pro stávající (lokální) spojení.
A zase mít na každém stroji dvě IP (lokální a globální), to se mi moc nechce...Mít na IPv6 několik IP adres se považuje za normální stav. Preference zdrojových adres odchozí komunikace je specifikována včetně možnosti ji doladit.
Chápu-li to správně, tak ta výše zmíněný problém nevyřeší.To byla jenom poznámka na okraj :).
Chápu. A výpadky jsou i u lepších poskytovatelů. Takže pokud to nutně musí být, tak IPv6 NAT rozsah na rozsah :).Ok, zeptám se tedy takto. Jakým způsob je nyní možné řešit s IPv6 nastíněnou situaci? Tedy mám síť s cca 5-50 počítači a mám 2-5 připojení k internetu, které chci přepínat (dejme tomu, že nepotřebuju sdílet). Ať to nekomplikuju, tak mám jen jeden router, který má připojené ty jednotlivé konektivity k sobě. V lokální síti mám server, který chtějí lidé využívat bez ohledu na internet. Přepnutí musí ovšem fungovat v řádu desítek sekund. Nevadí mi, že popadají vnější spojení při přehazování, ale chtěl bych, aby nepopadaly lokální spojení.
16.6.2011 12:29
pavlix | skóre: 54
| blog: pavlix
16.6.2011 14:07
pavlix | skóre: 54
| blog: pavlix
Jinak řečeno, v současné době není poměrně běžný problém (alespoň u mně) snadno a elegatně řešitelný, zatímco na IPv4 je (ač s použitím proklínaného NATu).To se samozřejmě u nového protokolu může stát. Ale v tomto případě s tebou nesouhlasím, protože se mi současné řešení v IPv6 zdá z mnoha důvodů elegantnější než současné řešení v IPv4. Takže za mě, pouze není k dispozici stejné řešení.
Spousta lidí nás přesvědčuje, že už je tu s námi 10 let...
Zapomněl jste dodat, že vaše hypotetická síť, kde 50 stanic má připojení zálohováno 5 různými způsoby neprovozuje vůbec žádný veřejný server, protože ten byste za NAT schovával těžko.
Bez dynamického směrování (či podvodů ve stylu křížených domácích agentů mobilního IP u poskytovatelů) se tento problém řeší velmi obtížně, protože vždy musíte obětovat jednu funkcionalitu za jinou.
Možná by vás zajímala sisifosská snaha pojmenovaná shim6, která se snaží o nemožné.
Asi se shodnem na tom, že NAT není bezpečnostní prvek, ten se dá na IPv6 udělat prostě firewallemJenom pro upřesnění: na IPv4 to zabezpečení musíš udělat firewallem taky, ten NAT je tam (mluvím o náročnostni na CPU) navíc.
Jasně, ale pokud NAT i stavový firewall sdílejí Connection Tracking mechanismy (což oba potřebují), pak se jedna práce dělá jen jednou. A firewall pak obsahuje něco jako "--state new -i wan -j DROP" a to udělá většinu práce.Asi se shodnem na tom, že NAT není bezpečnostní prvek, ten se dá na IPv6 udělat prostě firewallemJenom pro upřesnění: na IPv4 to zabezpečení musíš udělat firewallem taky, ten NAT je tam (mluvím o náročnostni na CPU) navíc.
15.6.2011 21:08
pavlix | skóre: 54
| blog: pavlix
Jasně, ale pokud NAT i stavový firewall sdílejí Connection Tracking mechanismy (což oba potřebují), pak se jedna práce dělá jen jednou. A firewall pak obsahuje něco jako "--state new -i wan -j DROP" a to udělá většinu práce.Pokud se použije pouze firewall, tak se jedna práce dělá taky jen jednou. Navíc tabulka musí mít kvůli NATu další sloupce.
16.6.2011 02:36
pavlix | skóre: 54
| blog: pavlix
Však ano, já píšu, že firewall a firewall+NAT dělají téměř stejně složitou práci.O tom se nechci hádat, ale myslím si, že NAT (se stavovým firewallem) je složitější implementačně, paměťově i výpočetně, než jednoduchý stavový firewall, a zároveň je náchylnější na chyby a různé problémy. Zvlášť, pokud se jedná o NAT 1:N. Ale nejsem to schopný nijak kvantifikovat, v podstatě je to spíš můj pocit než cokoli jiného.
15.6.2011 13:29
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
S IPv4 jim nastavím nějaké pěkné adresy typu 10.0.0.x, router bude mít dvě vnější rozhraní, jedno do ADSL modemu, druhé WiFi. Na každém z nich se nastaví NAT a stačí volit defaultní gateway (mikrotik umí sám podle pingu např). Jedinou cestu, jak by se to dalo udělat bez NATu, vidím v získání bloku nezávislém na poskytovateli a účastnění se routingu. Nebo při každé změně připojení přeadresovat všechny počítače.Já jen dodám, že nikdo vám nebrání těm počítačům napevno nastavit lokální adresy, jako je to u IPv4. Já mám třeba server na fd00:1::1. Pro komunikaci v rámci místní sítě nemusíte používat veřejné adresy.
To sice jde, ale musím si dát setsakra pozor, aby žádný stroj tu adresu nepoužil při komunikaci ven. Přičemž u IPv4 tam funguje NAT jako někdo, kdo to v takovém případě alespoň částečně zachrání.... A samozřejmě, já chci komunikovat dovnitř i ven a v současné době je NAT to, co mi nabízí zdání, že to můžuS IPv4 jim nastavím nějaké pěkné adresy typu 10.0.0.x, router bude mít dvě vnější rozhraní, jedno do ADSL modemu, druhé WiFi. Na každém z nich se nastaví NAT a stačí volit defaultní gateway (mikrotik umí sám podle pingu např). Jedinou cestu, jak by se to dalo udělat bez NATu, vidím v získání bloku nezávislém na poskytovateli a účastnění se routingu. Nebo při každé změně připojení přeadresovat všechny počítače.Já jen dodám, že nikdo vám nebrání těm počítačům napevno nastavit lokální adresy, jako je to u IPv4. Já mám třeba server na fd00:1::1. Pro komunikaci v rámci místní sítě nemusíte používat veřejné adresy.
15.6.2011 13:48
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
15.6.2011 21:10
pavlix | skóre: 54
| blog: pavlix
To sice jde, ale musím si dát setsakra pozor, aby žádný stroj tu adresu nepoužil při komunikaci ven.IPv6 má vytvořený docela dobrý mechanismus pro výběr zdrojové adresy. Je na to samostatné RFC, jinak na linuxu
man gai.conf.
všiml jsem si, že i hodně serverů ho nepoužíváNo, servery budou obvykle konfigurovane staticky, takze autokonfigurace je vcelku zbytecna. Me se pristup s RA/SLAAC pro koncove pocitace vcelku libi (nebot zajisti relativne staticke adresy aniz by clovek musel cokoliv kdekoliv nastavoval. Akorat dost netusim, jak se pocita s napojenim na DNS. Bud se clovek vykasle na reverzy, nebo stejne bude muset nekde shromazdovat informace o pouzivanych adresach (a pak uz si moc prace neusetri). Nebo treba pri delegaci /64 na domaciho uzivatele. To se na nej deleguje i prislusny poddomena reverzniho DNS a ceka se, ze si to uzivatel nastavi?
15.6.2011 14:36
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Samozřejmě, že to řeší DNS, ale občas člověk pracuje přímo s IP adresama, občas je to pro něj pohodlnější, atd... Například při konfiguraci firewallu teď z hlavy napíšu IP adresy všech strojů, ze kterých je potřeba admin access na SSH.
U serverů to je jasné. Ale mně se to právě líbí i u "klientských" počítačů.Tak pokud budeš mít pevný prefix, můžeš si AFAIK klientské počítače nakonfigurovat podle libosti. Akorát budeš muset všechno dělat ručně nebo na síti rozběhat DHCP (a to konfigurovat ručně, aby se párovaly MAC a IP)
Přesně, buď si to nakonfiguruju ručně anebo se ptám, zda to DHCPv6 umí nebo zda existuje něco jiného, co dělá přesně to, co dělá DHCP pro IPv4. T.j. přijde dotaz a on se podívá do tabulky, zjistí, že téhle MAC ještě nic nedal, tak jí dá prefix::100, pak přijde další dotaz, dá mu prefix::101 a když se první znovu zeptá, tak dostane prefix::100. A samozřejmě to něco musí být podporováno ve Win klientech, jinak to ztrácí efekt...U serverů to je jasné. Ale mně se to právě líbí i u "klientských" počítačů.Tak pokud budeš mít pevný prefix, můžeš si AFAIK klientské počítače nakonfigurovat podle libosti. Akorát budeš muset všechno dělat ručně nebo na síti rozběhat DHCP (a to konfigurovat ručně, aby se párovaly MAC a IP)
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.