V předchozím blog postu jsem popsal v jaké situaci jsme byli před implementací IPv6. V tom dnešním Vám prozradím, jak nám IPv6 pomohla z naší situace ven.
Ještě než se pustíme do toho pozitivního, tak začnu našim začátkem v IPv6. Celý náš upgrade začal zákaznický požadavek, abychom zpřístupnili některé naše služby po IPv6. Jednalo se o službu, která běžela za redundantním párem load balancerů, takže řešením bylo přidělit jim IPv6 adresy a v DNS vytvořit AAAA záznamy. Celkem jednoduché řešení, které nám vyřešilo požadavek.
Ve výsledku pak tyto load balancery měly 4 adresy - naší interní adresu, interní adresu k serverům zákazníka, veřejnou IPv4 adresu a veřejnou IPv6 adresu.
Také Vám to příjde děsivé? Teď, když se na to díváme zpětně, tak nám ano.
Pro každou skupinu serverů nebo zákazníka máme rezervovaný /48 IPv6 rozsah. V rámci VLAN nebo uplinku je přidělený /64 rozsah tak, aby fungoval hned od začátku SLAAC. V případě, že je potřeba víc rozsahů (např. kvůli VPN, segmentaci sítě, atd.), tak další rozsahy routujeme dle potřeby.
Interní IPv4 jsme nahradili veřejnými IPv6 adresami a na všech serverech zapnuli firewall. Tato změna také přispěla k refaktorování kódu starající se o firewall v puppetu a k výraznému zjednodušení konfigurace (o tom zas příště). Mohli jsme také zrušit naše interní DNS servery. Všechny servery jsou nyní registrované ve veřejné DNS zóně. To přineslo i větší svobodu uživatelům připojených skrz VPN, kteří nyní nejsou omezeni na naše DNS servery. V rámci DNS má každý server jeden AAAA a nekteré jeden A záznam, nikdy ne víc.
Servery, které potřebují ke svému fungování IPv4 adresu, využívají dual-stack. Všechny ostatní servery ve výchozím stavu instalujeme jako IPv6-only. Pokud některý ze serverů z nějakého důvodu potřebuje přistoupit do IPv4 sítě, tak mu nastavíme náše DNS64 servery, které přesměrují provoz skrz NAT64 servery. Provozu skrz NAT64 servery je naprosté minimum. Pro naše případy většinou opravdu stačí IPv6 only konektivita. V případě potřeby se dá NAT64 škálovat velmi dobře - např. pomocí DNS balancingu.
Pokud má mít server přidělenou konkrétní IP adresu, tak se buď manuálně nebo automaticky při instalaci nastaví staticky. Ostatní servery využívají adresu získanou pomocí autokonfigurace, kterou si zaregistrují do inventory systému. To nám pomohlo výrazně zjednodušit DHCP servery v síti.
Management karty u serverů získávají pomocí auto konfigurace. Naštěstí zde všechny servery používají k výpočtu adresy MAC adresu, tudíž generování DNS záznamů pro servery z MAC adres je jednoduché.
Zjednodušilo se debugování problémů v komunikaci mezi servery, protože všechna komunikace je přímá a vždy vidíme reálnou zdrojovou a cílovou adresu.
Přechod na veřejné IP adresy nám také pomohl přejít čistě na L3 switche, které jsou schopné odroutovat provoz v maximální možné rychlosti portu. Softwarové routery necháváme jen v situacích, kde potřebujeme buď segmentovat malou síť nebo dělat statefull filtraci provozu.
Zjednodušily se nám VPN propoje mezi datacentry - už nikdy nevznikne kolize mezi sítěmi.
Uživatelé připojení v IPv4 only síti mohou dobrovolně využít IPv6 tunnel, takže dostanou na své zařízení plnohodnotnou IPv6 konektivitu.
Většina software a hardware je již na IPv6 připravena. Ze síťových prvků - Arista, Cisco i Mikrotik splňují vše, co zatím potřebujeme.
Abych zde IPv6 jen nevychaloval, tak je potřeba podívat se i na současné nevýhody IPv6.
Pouze většina software a hardware je na IPv6 připravena. Dlouhodobě se setkáváme s aplikacemi, které na IPv6 připraveny nejsou. Jedná se hlavně o zákaznické aplikace, které pracují s IP adresami ve špatném formátu - například je ukládají do databáze jako VARCHAR(15).
Z těch systémovějších věcí nám největší problém dělala instalace ruby gemů, kde jsme museli na DNS serverech začít zahazovat odpovědi na A DNS dotazy. I přestože gem manažer navázal IPv6 spojení skrz NAT64, tak stejně instalaci ukončil chybou, protože se nemohl napřímo spojit pomocí preferované IPv4. V momentě, kdy nedostal A záznam, tak vše provedl přes IPv6 a instalace gemu se zdařila.
Velmi často se setkáváme se situací, kdy je IPv6 potřeba aktivovat nějakým přepínačem nebo seprátní konfigurací. Většinou pak ale daná aplikace funguje v IPv6 síti dobře.
Nejnáročnější byla příprava PXE bootu pro instalaci serverů ze sítě a inventory systém - Foreman ani MAAS bohužel nepodporují IPv6 only deployment. Na toto téma napíšeme separátní blog post.
Celý přechod na IPv6 od prvních pokusů, prvního serveru až po finální IPv6 only infrastrukturu nás stál řádově vyšší stovky pracovních hodin a ještě nějaký čas stát bude.
Občas narazíme na starší zařízení, které IPv6 nepodporuje nebo ve velmi omezené míře. Konkrétně bych zde zmínil některé APC PDU nebo starší L2 D-link switche. Za nás nejpodstatnější je ale chybějící podpora IPMI protokolu přes IPv6 u Supermicro serverů.
Bohužel se musím přiznat, že interní IPv4 adresy ještě stále používáme a to ve 2 případech. OpenVPN aktuálně vyžaduje ke svému běhu IPv4 adresy k peer-to-peer komunikaci mezi klientem a VPN serverem, IPv6 ale u OpenVPN funguje dobře a nejedná se o rozsah, který bychom museli routovat. O IPv6 v OpenVPN se určitě rozepíšeme jindy.
Zásadnější jsou pro nás aktuálně management karty serverů, kde máme v každém datacentru jednu vyhrazenou síť s IPv4 DHCP serverem. Supermicro servery nepodporují a do budoucna nejspíš ani nebudou podporovat IPMI over LAN protokol přes IPv6. Tento problém se ale doufám vyřeší přechodem na Redfish. U HP serverů mohu potvrdit, že IPMI přes IPv6 zvládají dobře.
Přesun na IPv6 only síť nám ale pomohl výrazně zjednodušit síťovou infrastrukturu a do staré konfigurace s IPv4 bychom se už nikdy nevraceli.
Naší vizí do blízké budoucnosti je vytvořit IPv4 as a service infrastrukturu, která bude bude poskytovat NAT46/NAT64. Všechny servery by pak byly čistě IPv6 only a nám by se zjednodušila správa i monitoring. Z dlouhodobého hlediska využítí IPv6 roste a těšíme se na dobu, kdy překročíme metu 50% provozu.