Představovat IPv6 na tomto blogu asi není úplně nutné, článek je přecijen určen pro technicky zaměřené čtenáře. Pokud by přecijen někdo nevěděl oč se jedná a článek si chtěl přečíst a porozumět mu, tak doporučím alespoň pročíst wiki o IPv6.
Než jsme začali implementovat IPv6, tak jsme používali celkem běžnou konfiguraci, kterou jsem viděl snad na všech předchozích pozicích, kde jsem pracoval.
Každý server měl interní IPv4 adresu z rozsahu 10.0.0.0/8 nebo jiného dostatečně velkého rozsahu z RFC 1918. Do veřejné sítě byly většinou připojeny jen zařízení označené jako router, které dělaly NAT - a to obousměrně. Obstarávaly komunikaci serverů z vnitřní sítě ven a i naopak přesměrovaly provoz od uživatelů na správný server uvnitř sítě.
V interní síti běžely také PXE a DHPC server. Na žádném ze serverů nebyla staticky nakonfigurovaná adresa a o vše se staralo DHCP.
Pro jednodušší přístup k serverům používala doménová jména. V době naší interní IPv4 sítě jsmě měli interní DNS resolvery, které byly zároveň autoritativní pro .srw top level doménu. V této doméně byla zaregistrovaná všechna zařízení a interní služby - např. monitoring.srw nebo backup.srw.
Pro přístup k serverům jsme měli samozřejmě VPN, která nám propojila interní síť s kanceláří, popř. s klienty, kteří byli na cestách.
Tato konfigurace sítě nám s rostoucími požadavky dlouhodobě dělala vrásky na čele.
Veškerý provoz nám obsluhovalo jedno zařízení jehož výpadek nebo lokální indispozice měla vliv na všechny služby za ním. Samozřejmě jsme také naráželi na Hairpinning, kdy komunikace mezi službami přes veřejné IP adresy nebyla přímočará a často se řešily nesmyslné výpadky. Ve výsledku byla konfigurace firewallu tak složitá, že jsme jí upravovali s respektem. Hairpin NAT se sice dal řešit přepisem veřejných doménových jmen na interní IP adresy na našich DNS resolverech, ale vyžadovalo by to udržovat seznam všech domén, které na našich serverech běžely.
Konfigurace mail serverů byla také složitější, protože se v postfixu musel jako mailname uvádět správné veřejné jméno, aby emaily nebyly odmítány už při pokusu o doručení.
A pak přišlo několik zásadních změn, které nás donutily zamyslet se.
S roustoucím množstvím zákazníků nám rostl i provoz v síti, ale i množství DDOS útoků. Velmi brzy se NATovací zařízení ukázalo být úzkým hrdlem a my jsme museli udělat zásadní úpravu v návrhu infrastruktury. Serverům, na kterých běží veřejné služby (např. weby zákazníků), jsme dali krom interní adresy také veřejnou IPv4 adresu. Tím jsme ulehčili práci NATovacímu zařízení a částečně decentralizovali infrastrukturu. Vzniklo nám však několik nových problémů.
Zásadním z nich byl firewall, který jsme do té doby řešili jen na NATovacím zařízení. Nyní jsme museli začít řešit firewall na jednotlivých serverech v síti. Firewall jsme sice mohli řešit na switchích, ale ten by byl jen bezstavový a je tam jen omezené množství pravidel na celý switch.
DHCP klient musel být schopný rozpoznat, jestli má přidělenou veřejnou IPv4 gateway a nepřepisovat jí interní - na toto sice stačil malý hook do isc-dhcp-clienta, ale i tak jsme se o to museli (resp. puppet) starat.
A pak také servery byly registrované v interní DNS zóně, nově však i ve veřejné DNS zóně. Museli jsme tedy spravovat 2 DNS záznamy pro každý server.
Naše služby si objednali 2 zákazníci, kteří měli požadavek na oddělenou infrastrukturu v jiných datacentrech, ale zase chtěli využívat výhod služeb, které nám běžely interně (např. sdílený monitoring).
Jako první problém se ukázalo interní IP adresace, kde nám kolidovaly interní IPv4 rozsahy a tak jsme museli část sítě přečíslovat, aby nám správně fungovala VPN a komunikace s našemi servery.
Zákazníkům jsme také přiradili top level domény .erd a .dis a to nám zkomplikovalo interní DNS resolvery, protože jsme museli nastavit forwardování zón. Představa, že tímto způsobem přidáváme dalšího zákazníka nás už v ten moment děsila.
A v poslední řadě nám celou naší ideu rozbil cloud, který jsme občas používali k pokrytí špiček, a jehož dynamičnost nám komplikovala správu celé infrastruktury.
Jak jsme se dostali do stavu, který nám vyhovuje popisuji v druhém pokračování zde.