Hlavní navigace

IPv6 se dá u poskytovatele nasadit za jediný den, postavte si vlastní laboratoř

 Autor: Pixabay
Ve čtvrtek 4. června proběhl tradiční seminář o IPv6, který každoročně pořádá sdružení CESNET. Tentokrát byl zaměřen na přechod od starého protokolu IPv4 k modernímu IPv6, protože právě o to celou dobu jde.
Petr Krčmář 9. 6. 2020
Doba čtení: 14 minut

Sdílet

Od roku 2016 pořádá sdružení CESNET seminář o IPv6. Konal se zatím vždy 6. června, na den IPv6. Letos ovšem toto datum vyšlo na sobotu, proto bylo už před rokem rozhodnuto, že se akce bude konat už 4. června. Tím se nabízí, že to může být akce zaměřená na přechod z IPv4 na IPv6, řekl v úvodu semináře Ondřej Caletka. Zavedení nového protokolu samo o sobě nic nevyřeší. Vyřešíme to až tím, že budeme moci ten původní vypnout.

Blažej Krajňák: IPv6 rychle a snadno, u lokálního ISP za jeden den

Vybudování infrastruktury pro IPv6 nemusí být náročné ani drahé. Blažej Krajňák během své přednášky ukázal, že je to možné zvládnout během jediného dne a nejsou k tomu potřeba žádné investice. Je to jednoduché, není potřeba se toho bát, říká Krajňák.

Konkrétně šlo o poskytovatele s názvem Levonet (AS50242), který nabízí své služby na východním Slovensku. Hlavní síť je postavená na optických vláknech, připojení poskytuje buď pomocí FTTH či FTTB, na odlehlejších místech pak pomocí 5GHz Wi-Fi. Pro účely této přednášky je podstatné, že jsme členy RIPE, máme přidělené ASN a máme vlastní adresy.

Celá akce proběhla během jednoho pátku, kdy byl státní svátek. Cílem bylo připravit adresní plán, zpřístupnit veřejné služby po IPv6, poskytnout konektivitu po IPv6 pro nové zákazníky a připravit adresní prostory pro firemní zákazníky. Pokud o to budou mít zájem nebo je v budoucnu požádáme my, budou moci snadno na IPv6 přejít.

Adresní prostor je rozdělen na veřejné služby, správu jednotlivých prvků, propojovací rozsahy, propoje ke koncovým zákazníkům a nakonec delegaci pro koncové sítě. Běžná domácnost dostává rozsah /56 a pro firmu je vyhrazeno /48. Poskytovatel dostal od RIPE přidělen rozsah /29, ale současný plán používá zatím jen /32. Zbytek si necháváme pro případ další potřeby.

Oba nadřazení poskytovatelé připojení (Swan a Energotel) mají plnou podporu dual-stacku, takže jim stačilo pomocí BGP oznámit nové sítě a propojení proběhlo bez problémů. Nezapomeňte filtrovat rozsahy, které oznamujete. Podepsat rozsahy pomocí RPKI je už pak u RIPE velmi jednoduché. Máme tu kupu incidentů, kdy dochází k únosu prefixů. Ochrana je zapnutá na jedno kliknutí.

Vnitřní routing je postaven čistě na OSPF, mezi jednotlivými routery se používá rozsah /64 a router ID se používá stejný jako v případě IPv4. Zákazníci připojení pomocí IPv6 mají vytočené PPPoE a připojují se na koncentrátor MikroTik, který nabízí RADIUS a na něm má staticky vytvořené prefixy pro zákazníky. Máme to tak proto, aby se při odpojení a připojení prefix neměnil.

Interní služby běží ve dvou lokalitách, ve kterých jsou provozovány poštovní servery, DNS, webové servery a další. Při IPv4 měla každá služba primární i sekundární adresu a pomocí OSPF cost bylo možné si jednoduše sekundární adresu znevýhodnit. Když pak dojde k výpadku, sekundární server automaticky převezme provoz na sebe.

V případě IPv6 se ale nic podobného udělat nedá, protože se spouští dummy rozhraní, na kterém visí veškeré prefixy. Pokud zvýším cost jednoho prefixu, zvýším ho pro celé dummy rozhraní. Pro šestku bylo tedy potřeba vytvořit dvě dummy rozhraní, na jedno z nich se pak nasadí primární adresy, na druhé sekundární.

Nasazení IPv6 na DNS serveru Bind bylo velmi jednoduché, stačilo vypnout parametr -4 a naopak zapnout listen-on-v6 s uvedením příslušných adres. Nezapomínejte také na reverzní záznamy, minimálně pro mailové servery je potřeba je doplnit. V delegaci reverzních zón v RIPE je možné snadno zapnout podepisování pomocí DNSSEC, takže je pak podepsaný celý reverzní záznam.

V případě mailového serveru to bylo také velmi jednoduché, u Postfixu stačilo doplnit konfigurační položku smtp_bind_address6, přidat šestkovou adresu do inet_interfaces a přepnout inet_protocols na all. Nezapomeňte doplnit SPF záznam v DNS, aby příjemci akceptovali vaši novou IPv6 adresu.

Jako webový server byl použit Apache, u kterého stačí doplnit novou adresu za volbu listen jak pro HTTP, tak pro HTTPS. Pak stačí restartovat a všechno běží. Jen je potřeba pohlídat, že redakční systém umí například logovat IPv6 adresy. V tomto případě jde o WordPress, který s tím nemá nejmenší problém.

Zákazníci používají jako koncové zařízení obvykle MikroTik hAP, kde stačí povolit balíček IPv6 a poté zapnout delegaci prefixu pomocí DHCPv6, poté se adresa přidělí na vnitřní rozhraní a poté už stačí jen spustit RA v síti, aby koncová zařízení získala svou adresu. Zjistil jsem, že při exportu nastavení MikroTik prohazuje pořadí těchto příkazů, takže je potřeba pohlídat správné pořadí, jinak zavedení konfigurace selže. Někteří zákazníci používají routery od TP-Linku, u kterých také stačí vše zapnout ve webovém rozhraní.

S tímto nastavením vše fungovalo, klienti dostali IPv6 a také služby jsou dnes provozovány v dual-stacku. To vše je možné stihnout za jediný den. Přesto zůstala ještě nějaká další práce: zajistit monitoring IPv6 služeb a konektivity, aktualizace softwarové sondy RIPE Atlas a migrace stávajících zákazníků. V případě MikroTiků není problém připravit automatický migrační plán. Horší to bude u TP-Linků, kterých už máme také dost.

Největší problém bude ve vesnicích, kde je zákaznické zařízení až za 5GHz anténou, která je v režimu router. Buď je musíme přepnout do režimu bridge a vytáčet PPPoE až z koncového zařízení nebo budeme síť přes anténu normálně routovat. To ale budeme potřebovat ještě rozmyslet. Síť tedy nabízí IPv4 i IPv6 a výkonnostně jsou na tom úplně stejně.

Ondřej Budín: Cesta k IPv6-only síti SŠ-COPT Kroměříž

Původní konfigurace sítě střední školy vypadala tak, že vše pokrývaly přepínače řešící pouze linkovou vrstvu. Síť byla rozdělena pouze na dva segmenty: hlavní a VLAN pro hosty. Vůbec nebyla řešena first-hop security, takže se kdokoliv mohl připojit do ethernetové zásuvky a byl v hlavním segmentu sítě. MikroTik CCR byl zároveň bránou do internetu, firewallem, překladačem adres a VPN koncentrátorem. Bezdrátové přístupové body značky Zyxel tu byly od roku 2012.

Poskytovatel zařadil školu mezi firemní zákazníky, takže před dvěma lety požádala o přidělení IPv6 prefixu. Zavolal nám technik, k čemu vlastně tu IPv6 potřebujeme. Poté už dorazil e-mail s potřebnými informacemi včetně delegovaného prefixu, adresami rozhraní WAN a brány. Jednalo se o statickou konfiguraci a staticky vyroutovaný prefix. Škola dostala prefix /48, ale podsítě adresu jen z malé části /56, kdyby mělo v budoucnu dojít ke změně poskytovatele, který by nabízel také jen /56.

Na začátku bylo potřeba implementovat nějaký přechodový mechanismus. V praxi příliš mnoho možností není, buď je možné nasadit klasický dual-stack nebo kombinaci NAT64+DNS64. Bohužel RouterOS podporuje pouze dual-stack, takže volba byla jasná. Musíme ovšem mít všechno v síti dvakrát.

Stejně tak byla situace jasná v případě autokonfigurace adres. DHCPv6 v RouterOS nepodporuje přidělování koncových adres ani bezestavové doplnění konfiguračních voleb. Další možností bylo spustit vlastní DHCPv6, ale toto řešení zase narazilo na stejné DUID všech počítačů v síti způsobené klonováním operačních systémů. Nakonec jsem se rozhodl jít nejjednodušší cestou a použít SLAAC.

U firewallu bylo nasazeno dvojí řešení. Segmenty se školními stanicemi a síťovými prvky mají restriktivnější konfiguraci neumožňující navázání připojení z internetu. Naopak části sítě s osobními zařízeními uživatelů umožňují navázání spojení zvenčí. Zabezpečení je tedy na koncových uživatelích, ale my nikoho neomezujeme.

Na RouterOS bylo potřeba povolit balíček IPv6, přidělit adresu na rozhraní a přidat jednu statickou routu k poskytovateli. Hned poté jsem se pustil do konfigurace firewallu, která je inspirovaná IPv4 firewallem. Kompletně ovšem chybí NAT a je potřeba pamatovat na správné filtrování ICMPv6.

Další fáze zahrnovala konfiguraci serverů, která byla ovšem bez problémů, jak Windows Server, tak Debian podporují IPv6 a vše správně funguje. Servery mají statickou konfiguraci adres v IPv4 i IPv6. Narazil jsem jen na problém s Eset ESMC Virtual Appliance, která vůbec nepodporuje IPv6.

U serverových aplikací není také v principu problém, až na Docker. Docker je jeden velký problém, docker-compose od verze 3 nepodporuje správu IPv6 sítí. Aplikace tedy běží pouze po IPv4, ale je před nimi reverzní proxy Nginx, takže navenek vše po IPv6 funguje.

Když byly spuštěny všechny služby na statických IPv6 adresách, nastal čas zapnout oznamování prefixu do sítě. V tu chvíli všechny stanice s Windows získaly globální IPv6 adresy a vše začalo fungovat.

Jako problém se ukázaly síťové tiskárny, které mají ve webovém rozhraní podporu IPv6 vypnutou. Novou tiskárnu nám přijeli instalovat technici, kteří ale neměli s IPv6 zkušenosti. Je to podobný problém jako s 802.1X, který je také implementován, ale používá jej velmi málo zákazníků.

Ve Zlínském kraji mezi tím vznikl projekt kybernetického zabezpečení příspěvkových organizací (KBPO), což v praxi znamená také výměnu stávajících zařízení za modernější. My jsme už měli funkční IPv6, ale projekt KBPO byl IPv4-only a se šestkou vůbec nepočítal. V praxi vše funguje tak, že do organizace přijedou technici, odpojí přepínače i firewall a nahradí je novými. Takže vlastně kompletní předělání celé sítě. Bohužel se nemyslelo ani na first-hop security, kterou je ale potřeba řešit, i když IPv6 nepoužíváte.

KBPO přinesl nový adresní plán, který řešil segmentaci, ale opět nepočítal s IPv6. Byla tu možnost úpravy, takže jsem plán upravil tak, aby zahrnoval i IPv6. V síti je 16 samostatných VLAN, které rozdělují zařízení do podsítí podle účelu.

Dodány byly dva kusy firewallů Fortinet FortiGate 81E, přepínače HPE 5130 a jeden Aruba 2930F. Wi-Fi pokrytí zajišťují body Aruba iAP-305. V datacentru ve Zlíně pak běží společně pro všechny organizace Aruba AirWave, syslog server a monitoring. FortiGate má ve výchozím stavu IPv6 vypnutou, captive portál nepodporuje dual-stack, stejně jako SSL-VPN, chybí bezpečnostní profilx pro NAT64 a NAT46 a GUI úplně chybí pro OSPFv6 a DHCPv6. Podpora šestky je řekněme chvalitebná, ale rozhodně ne výborná.

FortiOS ale na rozdíl od RouterOS podporuje NAT64, bohužel jen v podobě NAT64 Policy, které nepodporují bezpečnostní profily pro filtrování obsahu. Je tedy nutné bezpečnostní profily nastavit na IPv6/IPv4 policy, ta se ale zase s použitím NAT64 neaplikuje. Jediným řešením je přesunout bránu pro NAT64 na další router, který jsem ale neměl. Nakonec musela být vytvořena nová VDOM (namespace) s názvem NAT64, která je s kořenovou VDOM propojená pomocí VDOM Link se spojovací dual-stack sítí.

Škola má dvě lokality, které jsou propojení tunelem IPsec. Pro každý protokol je vytvořen vlastní tunel, do budoucna je v plánu sjednotit oba protokoly do jednoho dual-stackového tunelu na IPv6. Routing mezi firewally na obou lokalitách zajišťuje OSPFv2 a OSPFv3.

Síť pro hosty byla nejprve řešená pomocí 802.1X, ale to se ukázalo jako nefunkční, protože uživatelé nebyli schopni nakonfigurovat suplikanta. Nakonec se jako jediné východisko ukázal captive portál, který je ve FortiOS podporován. Podporuje sice IPv6, ale dual-stack je problematický. Nakonec jsme vypnuli podporu IPv4 a provozujeme jej jen na IPv6.

Pro osobní zařízení žáka či zaměstnance je dostupná autentizace pomocí 802.1X na Wi-Fi i ethernetových zásuvkách. Síť nemá vůbec IPv4, je tedy IPv6-only a používáme NAT64. Všichni používají relativně nové modely telefonů, takže ani tam není žádný problém se šestkou.

Připravuje se také záložní konektivita, protože primární poskytovatel měl několikrát problém s peeringem na IPv6. Některé sítě pak nebyly dostupné, bohužel nezafungoval ani mechanismus happy eyeballs, protože servery pro ověření funkčnosti IPv6 zrovna dostupné byly. Pracuje se na zřízení záložní VDSL linky od T-Mobile a poté bude probíhat překlad z primárního na záložní prefix pomocí NAT66.

Rok zkušeností s provozem přístupové sítě na IPv6 ukazuje, že to jde, ale neobejdete se bez trpělivosti. Buď budete vypadat jako blázen nebo jako hračička. Všichni se vás budou ptát, k čemu to je. Narazíte na spoustu bugů a chyb ve firmware, které vám znepříjemní život. Často budete také marně hledat pořádnou dokumentaci k funkcionalitě IPv6. Stejně to ale stojí za to a šel bych do toho znovu!

Radek Zajíc: Stavíme IPv6-only virtualizační laboratoř

Domácí sítě mají obvykle k dispozici dual-stack, což je způsob, jak rozjet IPv4 a IPv6 vedle sebe. To nás ale nezbavuje závislosti na IPv4. Období přechodu ze starého na nový protokol nabízí ideální možnost naučit se pracovat v prostředí, kde vůbec není IPv4. V běžných sítích za pět či za deset let už často najdeme jen IPv6. V sítích mobilních operátorů v Americe už často IPv4 nenajdeme. Přístup ke starému protokolu je zprostředkován pomocí NAT64/DNS64.

Kde začít, když chci stavět prostředí bez IPv4? V první řadě je potřeba zajistit IPv6 konektivitu, která mi dá alespoň několik prefixů o velikosti /64. Nejmenší použitelná síť má /60 adres, tedy dalších 16 podsítí. S tím už se dá začít hrát, dá se stavět vnitřní routing a podobně. V Česku jsou minimálně čtyři operátoři, kteří vám na VDSL dalí IPv6 s prefixem /56. Jsou to ÚVT Internet, Metronet, T-Mobile a Avonet. Prefixy dostanete pomocí DHCP delegace, stejně tak u kabelovky od UPC. Rozhodně je dobré oslovit svého operátora, často umí nabídnout IPv6 jen na vyžádání. Situace se v posledních letech zlepšila, opravdu velká část regionálních poskytovatelů IPv6 nabízí. Zkuste to.

Radek Zajíc si postavil vlastní testovací laboratoř. Jejím základem je DSL modem připojený k routeru Turris, který vytáčí PPPoE spojení do internetu. Pomocí DHCP klienta pak od poskytovatele získává IPv6 prefix o velikosti /56. Dále vytváří jednu síť, která je IPv6-only a poté klasická dual-stacková. Do ní jsou připojeny další dva routery: jeden s RouterOS a druhý s OpenWRT. Za každým z těch routerů je další síť oddělená pomocí VLAN, obě jsou pak připojené do tří serverů. Na jednom běží VMWare ESXi, na druhém serverové Windows 10 a na posledním je Ubuntu 20.04 LTS. Poslední jmenovaný stroj je klíčový, běží na něm NAT64, DNS64 a virtualizace s bridgem propojujícím jednotlivé VLAN.

Při návrhu sítě bylo potřeba začít adresním plánem. Síť byla rozdělena na následující podsítě: domácí síť s dual-stackem, zvláštní síť pro Docker a síť pro IPv6-only s NAT64/DNS64. Kromě toho jsou tu ještě dvě podsítě routované na zmíněný RouterOS a OpenWRT, které obsluhují sítě za nimi.

Protože nejde o jednu velkou plochou síť, je potřeba poměrně dost routovat. Turris má nastavené čtyři statické routy, pro každou síť jednu. Statické routy předcházejí problému v situaci, kdy je restartován primární router, ale ty sekundární to nevidí jako výpadek konektivity. Pak si stále myslí, že svou routu mají, ale ta se mezi tím z DHCP delegace ztratila z primárního routeru a ten přestane směrovat provoz.

DNS64/NAT64 je komponenta, bez které se dnes neobejdete v lokální síti bez IPv4 konektivity. Stále existuje spousta internetových zdrojů, které nepoužívají IPv6. My jim ovšem můžeme k doménovému jménu přidat vygenerovanou IPv6 adresu a poté jí na hranici sítě překládat zpět do IPv4.

V sítí je dostupný také DHCPv6 serve, který dokáže poskytnout adresu DNS serveru starším klientům. Ty novější si ji dokáží získat přímo z oznámení směrovače (RA). Radek Zajíc používá implementaci Kea, která mu také umožňuje bootovat ze sítě pomocí PXE v režimu UEFI i legacy BIOS. Bohužel je to něco, co nedokážu implementovat pomocí OpenWRT.

Při bootu v režimu legacy bootu není možné startovat z IPv6, protože původní standardy s tím nepočítají. Což ale neznamená, že neexistuje cesta, jak toho s malou pomocí dosáhnout. Je možné použít iPXE, což je software, který dokáže nastartovat ze sítě. Je možné ho zavést pomocí běžného PXE nebo ji zapsat do bootovací ROM síťové karty. Je možné to udělat i ve VMWare, pak je možné také startovat ze sítě.

Pro Docker je vyhrazená samostatná podsíť /64, stačilo zapnout podporu IPv6, nastavit síť v souboru daemon.json a restartovat službu. Pokud chcete další síť, je možné si vytvořit bridge a přidat do něj další sítě. Docker má bohužel stále otevřený na GitHubu požadavek, ve kterém spousta uživatelů žádá, aby docker network create mohl fungovat i bez IPv4 konektivity. Autoři na to ale neslyší, ale Docker stále nelze takto provozovat a kontejner běžně nemá práva na to, aby si ze svého rozhraní IPv4 adresu a bránu odstranil. Jste tedy odsouzeni k tomu, abyste žili v dual-stackovém prostředí nebo používali kontejnery s vyššími oprávněními.

Pro virtualizaci se v laboratoři používá KVM, QEMU a libvirt. QEMU obsahuje iPXE boot ROM s podporou IPv6. Ovšem UEFI image v Ubuntu je bez podpory IPv6. Můžete si ale sehnat vlastní, který bude IPv6 podporovat. Pozor ovšem musíme dát na to, že QEMU ignoruje upravené pořadí bootu. Bohužel mi to z nějakého důvodu přestalo fungovat, asi z toho bude nový bugreport.

Intel AMT je určen pro dálkovou správu serverů, na kterých není k dispozici například IPMI. Podporu bylo dříve možné zapnout pomocí MeshCommanderu, ale od určité doby se dozvíte jen chybu 400. Naštěstí je možné podporu zapnout také ve webovém rozhraní, které je ale nejprve nutné navštívit po IPv4. MeshCommander se ale není ochoten připojit přímo na IPv6 adresu, musíte použít doménové jméno. Pak to funguje. Bohužel Intel AMT používá jiný typ DUID záznamu, než jaký se používá standardně. Je delší a není možné ho použít v OpenWRT pro přidělení statického záznamu.

VMWare funguje na IPv6-only sítí dobře, ale pokud v něm zapneme použití DHCPv6, vypne se autokonfigurace. V takové situaci ale stroj nenabere adresu výchozí brány a je nedostupný mimo lokální síť. Asi by to bylo na bugreport, ale já používám verzi ESXi, která je zdarma a nemá podporu. Můžu to zkusit nahlásit a uvidíme, jestli to VMWare opraví. VMWare podporuje připojování NFS, což funguje po IPv6 naprosto bez problémů.

MIF obecny

Klíčovou částí veškeré infrastruktury je DNS, ale bohužel se asi nikdo nezamýšlel nad tím, jak používat stroje nezadané ručně do DNS. Pokud byste chtěli dělat například DHCPv6 rezervace, tak by to pro některé operační systémy fungovalo. Bohužel třeba v macOS je to velmi omezené. Já jsem skončil u toho, že používám multicast DNS. Aby to fungovalo mezi různými VLAN, je nutné zapnout takzvaný multicast DNS reflector, což zajistí Avahi-daemon.

Pokud si chcete hrát s IPv6 a nechcete si stavět vlastní laboratoř, můžete využít služeb některého s poskytovatelů VPS, kteří vám na virtuální server naroutují použitelný prefix. Například známý Hetzner na každý virtuální stroj naroutuje /64, britský poskytovatel Mythic Beasts nabízí služby IPv6-only a švýcarský IPv6onlyhosting nabízí ve výchozí konfiguraci prefix /64, ale na požádání umí dát i /48.