Nasazení IPv6 v síti poskytovatele obsahu

Transkript

1 ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE FAKULTA ELEKTROTECHNICKÁ KATEDRA POČÍTAČŮ Bakalářská práce Nasazení IPv6 v síti poskytovatele obsahu Radek Zajíc Vedoucí práce: Ing. Jan Kubr 22. května 2013

2

3 Poděkování Na tomto místě bych rád poděkoval vedoucímu práce Ing. Janu Kubrovi za jeho vstřícnost a cenné rady během studia i přípravy této bakalářské práce. Dále bych rád poděkoval své rodině, přátelům a kolegům, kteří mě behem studia i realizace projektu podporovali, a také společnosti Seznam.cz, a. s., která dala mé myšlence prostor, umožnila zavedení IPv6 v organizaci prosadit a dovést do plně funkčního stavu.

4

5 Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů, zejména skutečnost, že České vysoké učení technické v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle 60 odst. 1 autorského zákona. V Praze dne 22. května

6 České vysoké učení technické Fakulta elektrotechnická Radek Zajíc. Všechna práva vyhrazena. Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě elektrotechnické. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezplatných zákonných licencí, je nezbytný souhlas autora. Odkaz na tuto práci Zajíc, Radek. Nasazení IPv6 v síti poskytovatele obsahu. Bakalářská práce. Praha: České vysoké učení technické v Praze, Fakulta elektrotechnická, 2013.

7 Abstract This thesis focuses on the steps necessary for successful implementation of the IPv6 network protocol in existing datacenter. The datacenter services, available via IPv4 only before this work was completed, will be available via both protocols using the dual-stack approach. In the first part I discuss the needs of a datacenter and analysis of existing environment, the second proposes configuration-specific modifications and testing methods. The last part of this work mentions possible future evolution of a datacenter and the near future of IPv6-only datacenters. Keywords: Internet protocol, IPv4, IPv6, datacenter, dual-stack, DNS, Cisco, load-balancing. ix

8 Abstrakt Tato práce se zaměřuje na kroky, které je nutné provést pro úspěšnou implementaci síťového protokolu IPv6 do prostředí existujícího datacentra. Služby v datacentru, které před zpracováním práce byly dostupné pouze pomocí protokolu IPv4, budou nově využívat princip dual-stack, tedy dostupnost pomocí obou protokolů. V první části se zabývám potřebami v datacentru a analýzou stávajícího prostředí, ve druhé pak implementací konkrétních úprav v konfiguraci a testování. Závěrem zmiňuji možnost dalšího rozvoje, zejména příchod datacenter využívajících pouze IPv6 protokolu. Klíčová slova: Internetový protokol, IPv4, IPv6, datacentrum, dual-stack, DNS, Cisco, rozklad zátěže. x

9 Obsah Úvod... 1 O protokolu IPv Představení práce Pozadí práce Analýza prostředí Podpora nových technologií Alokované IPv6 adresy Adresní plán Volba implementace IPv6 v organizaci Podpora IPv6 v síťových prvcích a na síti Podpora IPv6 v serverových operačních systémech Podpora IPv6 v aplikacích Návrh řešení Alokace IPv6 u RIPE Adresní plán Volba implementace xi

10 3.4 Aktualizace řídícího software v síťových prvcích Konfigurace IPv6 sítě Aktualizace software v OS Linux Změny v aplikacích Změny nastavení load balancerů Úpravy na straně DNS serverů Monitoring Praktická implementace Konfigurace směrovačů v datacentrech Konfigurace serveru s OS Linux Konfigurace serveru s OS Solaris Webové servery Load balancery DNS servery Správný postup konfigurace IPv6 služby Testování Použité nástroje Testovací scénáře Výsledky testování Závěr Zhodnocení práce Možnosti rozvoje Použitá literatura Příloha A Seznam použitých zkratek Příloha B Obsah přiloženého CD xii

11 Seznam obrázků Obrázek 0.1: Tempo docházení IPv4 adres... 2 Obrázek 1.1: Logické schéma datacenter organizace... 6 Obrázek 4.1: Přehled Self IPs Obrázek 4.2: Založení Self IP Obrázek 4.3: Přehled Nodes Obrázek 4.4: Vytvoření nového Node Obrázek 4.5: Přehled poolů Obrázek 4.6: Založení poolu Obrázek 4.7: Přehled virtuálních serverů Obrázek 4.8: Založení virtuálního serveru xiii

12 Seznam tabulek Tabulka 3.1: Seznam lokalit a přidělených prefixů Tabulka 3.2: Generování IPv6 adres pro speciální sítě Tabulka 4.1: Loopback adresy směrovačů Tabulka 4.2: Postup konfigurace IPv6 služby Tabulka 5.1: Výsledky testování xiv

13 xv

14

15 Úvod Síť Internet zažívá od devadesátých let dvacátého století prudký rozvoj. To vede k rychlé konzumaci zdrojů potřebných pro jeho správné fungování. Jedním z takových zdrojů jsou i IP adresy, tedy identifikátory, které musí mít každý počítač připojený do celosvětové Sítě sítí a využívající ke komunikaci protokol TCP/IP 1. Aby IP adresy (dále je budeme označovat IPv4 podle interního čísla verze protokolu IP tj. verze 4) nedocházely tak rychle, objevily se během devadesátých let mechanismy umožňující lepší využití adres. Mezi ty nejdůležitější můžeme bezesporu zařadit mechanismus CIDR 2, který umožnil přidělovat adresy i v blocích jiné velikosti, než 2 8, 2 16 a Neméně důležité, byť více kontroverzní, bylo zavedení překladu IP adres 3. I přes přijatá opatření se po roce 2000 problém docházejících IP adres stal ještě palčivějším. Jeho důležitost rostla, zařízení připojených k Internetu bylo čím dál více. Zároveň došlo k rozvoji připojení i mimo severní Ameriku a Evropu zejména Asie se v konzumaci adres rychle dostala na druhé místo. Hrozbu docházejících IPv4 adres však i přes důrazná varování na odborných konferencích nebrali vážně poskytovatelé obsahu ani konektivity. Docházení IPv4 adres se totiž v průběhu posledních dvaceti let podařilo omezit a odsunout dále do budoucnosti. Až kolem roku 2008 začalo být jasné, že se skutečně blíží den, kdy IPv4 adresy dojdou. A to se o tři roky později skutečně stalo. Nejprve došly v únoru 2011 bloky adres organizaci IANA (centrální autorita přidělující internetové zdroje regionálním autoritám), následně v dubnu 2011 vyčerpala své IPv4 zdroje autorita APNIC (obsluhuje region Asie, Austrálie a Tichého oceánu). O necelý 1 RFC 791, Internet Protocol specification, 2 RFC 1517 RFC 1520, Classless Inter-Domain Routing 3 RFC 1631, The IP Network Address Translator, 1

16 rok a půl později došly IPv4 adresy organizaci RIPE, spravující region Evropy a Blízkého východu. Další regiony, kterým pravděpodobně dojdou IPv4 adresy v roce 2014, jsou severoamerický ARIN a jihoamerický LACNIC. Jako poslední se s problémem docházejících IPv4 adres zřejmě bude muset vypořádat Afrika, resp. organizace AFRINIC, spravující pro ni internetové zdroje. Jak je vidět, docházející IPv4 adresy jsou problémem, který postupně propadává od nejvyšších autorit níž a níž, až ke koncovým uživatelům Internetu. Ať už se jedná o poskytovatele obsahu nebo domácího uživatele, všichni potřebují funkční IPv4 konektivitu. Tu ale bez IPv4 adres nezískají. Obrázek 0.1: Tempo docházení IPv4 adres 4 4 Geoff Huston, IPv4 address report, 2

17 O protokolu IPv6 Rychlé konzumace IP adres původního Internetu si všimli i jeho zakladatelé a již v devadesátých letech připravili ve spolupráci s akademickým a komerčním sektorem návrh nového protokolu, který měl postupně nahradit původní protokol IP. Tím protokolem byl IPng, později přejmenovaný na IPv6 (opět podle interního čísla verze protokolu). Ke standardizaci samotného protokolu IPv6 došlo již v roce 1995 v dokumentu RFC , načež již po třech letech, v roce 1998, se tehdy stále nový protokol dočkal první aktualizace 6. V průběhu dalšího desetiletí pak průběžně probíhala standardizace a aktualizace protokolů vyšších vrstev ISO/OSI modelu tak, aby zahrnovaly i podporu pro protokol IPv6. Jmenovat můžeme například úpravu DNS pro podporu překladu doménových jmen na IPv6 adresy, DHCPv6 pro přidělování IPv6 adres koncovým počítačům, atp. Představení práce Ve zmiňovaném roce 2008 jsem první praktičtější zkušenosti s provozem IPv6 získal i já. Nejprve v síti lokálního poskytovatele připojení k Internetu, kde jsme začali protokol IPv6 aktivněji používat. Při té příležitosti jsme ale zjistili, že hlavní příčinou neúspěchu IPv6 je problém slepice nebo vejce. Zjednodušeně jde o situaci, kdy poskytovatelé připojení nejsou motivováni k zavádění IPv6 do svých sítí, protože pro nový protokol neexistuje kvalitní obsah. Stejně tak poskytovatelé obsahu nejsou motivování k zavádění IPv6, protože neexistuje uživatelská základna, která by nový protokol dokázala využít. Následně jsem shodou okolností nastoupil na pozici správce serverové infrastruktury do společnosti Seznam.cz, a. s. (dále jen organizace), a začal 5 RFC 1883, Internet Protocol, Version 6, 6 RFC 2460, Internet Protocol, Version 6, 3

18 vyvíjet první kroky k zavedení IPv6 v organizaci tak, aby bylo možné využívat IPv6 pro poskytování IPv6 konektivity do sítě Internet pro vlastní zaměstnance pro poskytování vlastního obsahu (tj. firemních portálů) pomocí IPv6 plnohodnotně ve vlastních aplikacích tak, aby aplikace dokázala pracovat s IPv6 i IPv4 adresami Tato práce shrnuje zejména postupy, které bylo nutné provést pro zajištění spolehlivého poskytování vlastního obsahu pomocí IPv6. Okrajově se však také dotkne poskytování IPv6 konektivity vlastním zaměstnancům a zmíní některé potřebné úpravy v aplikacích, které mohou čtenářům s implementací IPv6 ve vlastní organizaci pomoci. Hlavními cíli práce jsou: získání IPv6 adresního rozsahu a navržení adresního plánu organizace zajištění funkční a spolehlivé IPv6 konektivity v organizaci navržení a otestování IPv6 konfigurace síťových prvků navržení a otestování IPv6 konfigurace operačních systémů na serverech příprava změn nastavení aplikací a systémů, které jsou vystaveny směrem do Internetu, aby podporovaly IPv6 Ačkoli při přípravě práce bylo věnováno veliké úsilí tomu, aby byla pokud možno zajištěna parita 1:1 mezi protokoly IPv4 a IPv6, vlivem některých technických omezení nebylo možné této parity dosáhnout u všech komponent. Cílem tedy není zajištění parity 1:1 pro naprosto všechny systémy v organizaci již od úplného začátku. Důraz je kladen na systémy, se kterými přijde do styku uživatel tedy primárně IPv6 konektivita jako taková, překlad jmen pomocí protokolu DNS a vydávání obsahu pomocí protokolu HTTP(S). 4

19 Interně organizace může a bude i nadále využívat i systémy, které podporují pouze protokol IPv4, dokud nedojde ke generační obměně uvedených systémů. Jedním z takových systémů je například široce rozšířená a v organizaci využívaná databáze MySQL. Ta, sama o sobě, nemá ve stabilních verzích řady MySQL 5 téměř žádnou podporu IPv6. 5

20 1. Pozadí práce Každé dnešní datacentrum prochází postupným vývojem. Dochází k obměně technologií za novější, rozšiřování počtu zařízení v síti, zavádění nových technologií. Nasazení protokolu IPv6 spadá do poslední zmíněné kategorie, tedy mezi zavádění nových technologií. Původní infrastruktura datacenter organizace plně využívá protokolu IPv4 a s ním spojené protokoly vyšších vrstev. Jak vypadá logické schéma zapojení datacenter organizace, včetně zapojení do sítě Internet, NIX.cz a připojení poboček, ukazuje následující obrázek. Obrázek 1.1: Logické schéma datacenter organizace Na obrázku je znázorněno propojení mezi datacentry, do sítě Internet, k pobočkám a dále pak v každém datovém centru sada aplikačních serverů (AS), DNS servery (DNS) a load balancery (vyznačeno jako jeden systém, pro zajištění vysoké dostupnosti jsou však load balancery v datacentru vždy v páru z pohledu serverů se však jedná o jeden systém). Pod LAN datacentra se pak schovává fyzická i logická síťová infrastruktura, postavená s využitím 6

21 redundantní hvězdicové topologie a virtuálních sítěmí s technologií VLAN 802.1q. Stávající konfiguraci infrastruktury je nutné modifikovat tak, aby podporovala IPv6. V dalších kapitolách proto postupně probereme změny v nastavení jednotlivých částí sítě tak, aby byla zajištěna funkčnost IPv6 ve všech znázorněných uzlech. Z pohledu sítě využívající protokol IPv4 nebude docházet k žádným změnám, proto bude IPv4 zmiňována pouze v místech, kde je potřeba znázornit či vysvětlit fungování některé oblasti, případně tam, kde bude odvozována IPv6 konfigurace od stávající IPv4 sítě. Snahou je pokud možno zajistit paritu 1:1 ve službách poskytovaných sítí i servery. 7

22 2. Analýza prostředí Tato část obsahuje kroky, které byly provedeny během analýzy stávajícího prostředí v organizaci. 2.1 Podpora nových technologií Pro implementaci každé nové technologie, jakou IPv6 beze sporu je, se bez podpory nových technologií ze strany řídících i provozních pracovníků v organizaci neobejdeme. Naštěstí v případě organizace byla v tento projekt již od začátku vkládána velká důvěra. Technologie IPv6 byla totiž vyhodnocena jako jeden z klíčových prvků pro zajištění tzv. business continuity, tedy zajištění fungování podniku a zachování konkurenceschopnosti pro další roky působení na trhu. 2.2 Alokované IPv6 adresy Před začátkem projektu nebyly v organizaci alokovány žádné IPv6 adresy. Díky členství organizace v RIPE 7 stačí pro získání potřebných adres vznést požadavek prostřednictvím tzv. RIPE LIR portálu. 2.3 Adresní plán V organizaci neexistoval adresní plán pro IPv6, bude ho tedy nutné navrhnout. 7 Réseaux IP Européens, organizace spravující internetové zdroje, jako např. IP adresy, nebo čísla autonomních systémů. 8

23 2.4 Volba implementace IPv6 v organizaci Z pohledu síťové konfigurace je možné volit mezi třemi hlavními směry implementace IPv6: Dual-stack, pouze IPv6 a tunelování IPv6 přes IPv4. Dále je nutné zvolit začátek implementace, zde přicházejí v úvahu volby top-to-bottom (shora dolů) a bottom-to-top (odspoda vzhůru) IPv6 datacentrum s NAT64 branou Tento inovátorský přístup uvažuje, že by byl stávající IPv4 protokol v datacentru téměř kompletně nahrazen nativním protokolem IPv6. IPv4 by zůstal jen na směrovačích připojujících datacentrum k Internetu a byl by ukončen na NAT64 8 bráně. Tato brána by zajistila namapování IPv4 adresního prostoru do IPv6 prostoru. Z pohledu serverů by pak veškerá komunikace probíhala jen a pouze po protokolu IPv6. Přístup bohužel není realizovatelný, protože mnoho aplikací nedokáže fungovat v režimu pouze IPv6. Zůstává ovšem otevřený pro další případnou studii a přechod v momentě, kdy IPv4 bude pouze okrajová technologie Tunelování IPv6 skrze IPv4 Nabízí se i možnost provádět tzv. tunelování protokolu IPv6 skrze nativní IPv4 protokol. Tato varianta vyžaduje konfiguraci tunelovací brány a koncových zařízení zároveň. Je také závislá na stabilitě IPv4 (protože tento protokol využívá) a citlivá na změny v IPv4 konfiguraci. Problémem jsou i nedostupné redundantní tunelovací brány, které by zvládaly provoz v řádu jednotek až desítek Gbit/s. Vzhledem k uvedeným nevýhodám nebyl ani tento přístup shledán jako vyhovující. 8 Stateful NAT64: Network Address and Protocol Translation, RFC 6146, 9

24 2.4.3 Dual-stack přístup Přichází s myšlenkou, že vedle stávajícího protokolu IPv4 bude na všech důležitých zařízeních nakonfigurován nativně i protokol IPv6, budou tedy existovat dvě sítě vedle sebe jedna využívající protokol IPv4, druhá IPv6, obě přitom poběží po shodné fyzické vrstvě a budou sdílet i část vrstvy spojové. Jde o nejčastější implementaci v dnešních datacentrech i koncových sítích, proto bude zvolen i v našem případě Bottom-to-top implementace Při volbě tohoto způsobu implementace se začínají konfigurovat prvky sítě od konce sítě. Tedy například nejprve jsou nastaveny servery, pak směrovače, pak je zajištěna konektivita do Internetu, atp. Nevýhodou je nutnost častých změn konfigurací a využívání přechodových (tunelovacích) mechanismů. Z uvedených důvodů byla tedy tato varianta zavržena a nebude použita Top-to-bottom implementace S konfigurací se v tomto případě začíná odshora (od jádra sítě). Jde o preferovaný způsob v mnoha organizacích. Nejprve jsou nakonfigurovány směrovače v jádru sítě, je zajištěna internetová konektivita a následně se přechází k dalším prvkům sítě, jako např. load-balancery a koncové servery. Je-li implementace dobře navržena, není v tomto případě nutné dělat po prvotní konfiguraci žádné výrazné změny v nastavení. Protože tato implementace odpovídá nejlépe prostředí datacentra s velkým množstvím konfigurovaných zařízení, byla vybrána jako vyhovující a bude podle ní postupováno. 2.5 Podpora IPv6 v síťových prvcích a na síti Síťové prvky lze rozdělit do tří kategorií, každá pak má jiný vliv na implementaci IPv6. 10

25 2.5.1 Přepínač Tyto síťové prvky v organizaci nevyužívají žádnou z funkcionalit, která by vyžadovala specifickou konfiguraci pro podporu IPv6 (např. SEND 9 ). Nadále tedy nebudou v návrhu ani v implementaci řešeny Směrovače V datacentru organizace se používají směrovače Cisco C6500. V nich bude nutné aktualizovat software, aby získal patřičnou podporu nové technologie. Z pohledu výkonu poskytuje Cisco C6500 hardwarovou akceleraci routování IPv6 paketů, tedy ani zde nenastane problém. V dalším textu budou zmíněny ověřené verze software, které jsou nutné pro dosažení maximální možné parity služeb 1:1 (tedy zajištění takových IPv6 služeb, které poskytnou stejnou funkcionalitu, jako služby IPv4 sítě) Load balancery (rozklad zátěže) V průběhu času došlo v organizaci k několika změnám v zařízeních určených k rozkladu zátěže mezi více koncových serverů. Původní používaná technologie, LVS, IPv6 nepodporovala. Tato technologie byla z důvodů nedostačujících výkonových možností nahrazena novým systémem, zařízením Big-IP 8800 od společnosti F5 Networks. Big-IP 8800 se softwarem ve verzi 9 již podporu IPv6 měla, ale vyžadovala dokoupení placeného modulu pro IPv6. V době pořízení však stále nebylo produkční nasazení IPv6 aktuální, a proto modul nebyl zakoupen. Následně došlo k pořízení nové technologie, zařízení Viprion, opět od společnosti F5 Networks. Toto zařízení nabídlo zároveň novější software ve verzi 10, ve kterém je již podpora IPv6 zahrnuta i bez dokupování dalších modulů. 9 Secure Neighbor Discovery, RFC 3971, - protokol pro ochranu před nevyžádaným rozesíláním oznámení o routerech dostupných v síti. 11

26 Později byl na verzi 10 aktualizován i software ve starších zařízeních Big- IP 8800, čímž se plnohodnotná podpora IPv6 dostala i na ně. Z tohoto pohledu byly load balancery (zařízení pro rozklad zátěže) plnohodnotně připraveny na produkční nasazení IPv Podpora IPv6 v serverových operačních systémech OS Linux V organizaci se používá tzv. distribuce (sada programů) operačního systému Linux, která nese název Debian Linux. Ačkoli se podpora IPv6 v operačním systému Linux začala objevovat již v roce , opravdu plnohodnotná implementace této technologie se v Debian Linuxu objevila až ve verzi Debian Linux Squeeze (6.0), který se objevil v únoru Tato verze tedy bude dále uvažována pro implementaci Virtualizace pomocí OpenVZ V organizaci se pro virtualizaci jednotlivých serverů používá technologie aplikační virtualizace OpenVZ od společnosti RedHat. Dochází k přípravě vlastních verzí tzv. jádra operačního systému (Linux Kernel) s podporou OpenVZ úprav (patches). Bude nutné zajistit, že na všech serverech s OpenVZ poběží jádro s plnou podporou IPv OS Solaris V prostředí organizace vyvstala potřeba konfigurovat IPv6 v systému Sun (Oracle) Solaris ve verzích 10 a 11. Tyto verze umožňují nakonfigurovat IPv6 10 History of IPv6 in Linux, HOWTO/basic-history-ipv6-linux.html 11 Informace o verzi Debian squeeze, 12

27 do stavu, který splňuje základní požadavky (síťová konektivita je v aplikacích dostupná). Starší verze nejsou uvažovány. 2.7 Podpora IPv6 v aplikacích Podporu je potřeba rozdělit podle toho, zda jde o aplikaci, která je součástí distribuce operačního systému, nebo zda jde o aplikaci vyvíjenou/modifikovanou uvnitř organizace Podpora v aplikacích v distribuci Při uvažování již zmiňované distribuce Debian Linux 6.0 je IPv6 standardně podporováno téměř ve všech aplikacích. Pro použití u poskytovatele obsahu je podpora plně dostačující Podpora ve vnitrofiremně vyvíjených/modifikovaných aplikacích Firemní aplikace, které jsou otevřené ve směru do veřejného internetu, běží uvnitř webového serveru Apache nebo Nginx, případně ve zřetězení Nginx Apache. Oba tyto servery podporují IPv6 nativně, pouze server Nginx je nutné při vnitrofiremních úpravách překládat ze zdrojových kódů se zapnutou podporou IPv Podpora v DNS V případě DNS je potřeba zkombinovat oba výše zmíněné přístupy: - dojde k úpravě konfigurace DNS serverů tak, aby byly dostupné pomocí IPv6 protokolu. - poté, co bude infrastruktura konkrétní služby plnohodnotně připravena na provoz přes IPv6, bude nutné přidat do DNS zóny této služby tzv. AAAA záznam s IPv6 adresou jejího webového serveru 13

28 Kromě toho bude nutné přidat do DNS zóny organizace informaci o tom, že DNS servery jsou dostupné pomocí IPv6 protokolu. Toho docílíme opět přidáním AAAA záznamu, tentokrát k názvům jednotlivých DNS serverů. 14

29 3. Návrh řešení 3.1 Alokace IPv6 u RIPE Před dalšími kroky bylo nutné provést alokaci IPv6 adresního bloku u organizace RIPE. Výsledkem alokace bylo přidělení IPv6 bloku 2a02:598::/ Adresní plán Dalším krokem, po provedené IPv6 alokaci, je rozdělení adresního rozsahu IPv6 bloku tak, aby splňoval kritérium hierarchického dělení a agregovatelnosti (zpětného slučování příbuzných menších adresních bloků do bloku většího). Dochází tedy k rozdělení alokovaného /32 bloku postupně na bloky pro konkrétní datacentrum, posléze pro konkrétní privátní VLAN nebo veřejně dostupnou VLAN. Struktura IPv6 adres v organizaci tedy má následující podobu a masku 2a02:598:XXXX:YYYY:CCCC:CCCC:CCCC:DDDD/64 Kde - XXXX určuje tzv. lokalitu (datacentrum fyzickou jednotku, která zastřešuje používání uvedeného prefixu). - YYYY určuje číslo VLAN, případně obsahuje speciální hodnotu 0 (viz dále) - CCCC:CCCC:CCCC:DDDD je spodních 64 bitů IPv6 adresy. V případě autokonfigurace klientských stanic (v síti centrály a poboček organizace) je pro generování adresy používán mechanismus EUI V případě manuálně přiřazovaných adres (zejm. pro serverové a síťové prvky) platí, že CCCC je rovno nule, zatímco DDDD je alokováno manuálně. 12 Appendix A, RFC 4291, IPv6 Addressing Architecture, 15

30 3.2.1 Seznam lokalit (část adresy označená XXXX) Pro zajištění řádu při alokacích došlo k rezervaci následujících prefixů lokalit. Prefixy v tabulce neuvedené zůstávají nepřiděleny. Tabulka 3.1: Seznam lokalit a přidělených prefixů 2a02:598:0000::/36 Prefixy pro datacentra 2a02:598:0000::/48 Rezervováno nevyužito 2a02:598:0001::/48 Prefix pro datacentrum č. 1 2a02:598:0002::/48 Prefix pro datacentrum č. 2 2a02:598:0003::/48 2a02:598:0FFF::/48 Rezervováno pro další datacentra 2a02:598:6262::/48 Prefix pro spojovací sítě datacenter 2a02:598:6263::/48 Prefix pro spojovací sítě k pobočkám 2a02:598:7000::/40 Prefixy pro pobočky 2a02:598:7000::/48 Prefix pro centrálu 2a02:598:7001::/48 Prefix pro pobočku v Brně Zápis čísel VLAN (část adresy označená YYYY) Číslo VLAN podle IEEE standardu 802.1q je dvanáctibitové číslo, které může nabývat hodnoty 0 až Dvě z těchto hodnot, 0 (0x000) a 4095 (0xFFF) jsou ale rezervovány. Zápis čísel VLAN v IPv6 adrese umožňuje rychlou identifikaci umístění IPv6 adresy (serveru, směrovače) v síti, a zároveň kopíruje IPv4 adresní plán organizace, kdy je každá VLAN zapsána i ve třetím oktetu IPv4 adresy. Tedy například z IPv4 adresy lze poznat, že se nachází ve VLAN 40. Z pohledu návrhu adresního plánu byly diskutovány dvě varianty, a to - zápis VLAN v IPv6 adrese tak, jak je (tj. 40 pro VLAN 40) - zápis VLAN v IPv6 adrese po konverzi do hexadecimálního zápisu (tj. 28 pro VLAN 40) 16

31 Z důvodu zachování přehlednosti konfigurací byl po dlouhé diskusi s ostatními administrátory nakonec zvolen a potvrzen zápis čísla VLAN tak, jak je. Tedy do IPv6 adresy (která je sama zapisována šestnáctkově) je zapisováno číslo VLAN v desítkové soustavě Zápis adres serverů (část adresy označená CCCC a DDDD) V případě serverů dochází vždy k ruční konfiguraci, tedy části adresy, označené výše jako CCCC, jsou vždy rovny nule. Část adresy, označená DDDD, kopíruje v případě IPv4 sítě /24 bajt z posledního oktetu IPv4 adresy do posledního hextetu 13 IPv6 adresy, a to opět v přepisu tak, jak je. Tedy například pro IPv4 adresu /24 je vygenerována IPv6 adresa 2a02:598:1:40::128/64. V datacentrech organizace se dále vyskytují specifické IPv4 sítě, které se vyznačují jinou maskou, než /24 (zejména jde o masku /21). I tyto IPv4 sítě měly původně masku /24, posléze ale vznikla nutnost jejich rozšíření, bez podstupování readresace všech serverů. Proto došlo ke změně masky na /21. V případě takové sítě pak platí pravidlo, že IPv4 adresy, které zároveň obsahují i číslo VLAN, se adresují stejně, jako v případě masky /24: Např. pro IPv4 adresu /21 (VLAN 89) vznikne IPv6 adresa 2a02:598:1:89::111/64. Pro IPv4 adresy, které taktéž patří do uvedeného bloku, ale nezahrnují číslo VLAN, pak platí, že pro každých 256 adres je k jejich IPv4 adrese přičtena hodnota +0x100. Výsledkem jsou takovéto adresy: Tabulka 3.2: Generování IPv6 adres pro speciální sítě IPv6 adresa téhož serveru IPv4 adresa /21 2a02:598:1:89::10/64 13 hextet, přesněji snad hexadekatet, přenáší termín oktet (jeden byte 8 bitů IPv4 adresy) ze světa IPv4 do světa IPv6 (jedno slovo 16 bitů IPv6 adresy). Tento termín není standardizován, pro absenci lepšího termínu jej ale budu dále v textu používat. 17

32 /21 2a02:598:1:89::111/ /21 2a02:598:1:89::212/64 Maska IPv6 sítě zde vždy zůstává /64! Tento způsob adresace je kompromisem, vzniklým na základě dohody se správci serverů v uváděných IPv4 sítích. Není optimální, ale umožňuje systémově očíslovat servery i tam, kde by jinak vznikla nekonzistence mezi IPv4 a IPv6 světem Veřejně dostupné IPv6 adresy Zatímco ve světě IPv4 se v důsledku docházejících adres hojně používá technologie překladu adres (dále jen NAT) a část používaných adres z principu nemůže být z internetu dostupná, dochází v případě IPv6 ke změně paradigmatu a veřejně (z internetu) jsou automaticky dostupné všechny adresy. Tento princip lze v případě interních serverů organizace klasifikovat jako výrazné bezpečnostní riziko, proto je na vstupu do sítě aplikován filtr, který zabrání na adresy serverů přistupovat. Z jiného pohledu ale nezbytně musí existovat část IPv6 adres, na které je z internetu povolen přístup (aby bylo možné využívat služby poskytovatele obsahu i mimo jeho síť). Zároveň je nutné zachovat princip agregovatelnosti, tedy tyto adresy musí být ze stejného rozsahu datacentra, jako adresy serverů, které veřejně dostupné nejsou. Pro takovéto případy je vyhrazen blok s hodnotou YYYY=0 a maskou /112, tedy takový, který odpovídá rezervované hodnotě VLAN 0. Veřejně dostupné IPv6 adresy mají proto vyhrazen blok adres 2a02:598:XXXX:0::/112 XXXX opět značí číslo lokality. 3.3 Volba implementace Pro implementaci IPv6 v organizaci je možné zvolit několik různých přístupů, přičemž každý z nich má své klady i zápory. V praxi se často přístupy kombinují podle potřeby. Po vyhodnocení různých typů implementace byl zvolen dual-stack přístup s implementací top-to-bottom. Datacentrum bude 18

33 tedy nakonfigurované tak, že zařízení budou využívat zároveň IPv4 i IPv6. Při konfiguraci proběhne nejprve konfigurace jádra sítě, následně zařízení zajišťující rozklad zátěže (load-balancery), pak přijdou na řadu operační systémy na serverech a úplně nakonec dojde k úpravě aplikační konfigurace. 3.4 Aktualizace řídícího software v síťových prvcích V rámci nasazení IPv6 bude provedena aktualizace software na směrovačích Cisco C6500. Novým softwarem je verze 12.2(33)SXI4 ve variantě s72033_rp-advipservicesk9_wan-m. 3.5 Konfigurace IPv6 sítě Konfigurace IPv6 sítě se zaměří na následující oblasti: - konfigurace směrovacího protokolu BGP pro propojení s vnějším Internetem a předávání směrovacích informací o vnějších autonomních systémech mezi vlastními směrovači - nastavení směrovacího protokolu OSPFv3 pro předávání směrovacích informací o jednotlivých segmentech sítě organizace mezi vlastními směrovači - nastavení IPv6 adresace a podpory vysoké dostupnosti pro jednotlivé VLAN používané v datacentrech Směrovací protokol BGP Nastavení směrovacího protokolu BGP bude kopírovat stávající model BGP spojení, tedy bude navázán IPv6 peering (propojení) ve sdružení NIX.cz a IPv6 tranzitní spojení s tranzitními poskytovateli, kteří IPv6 tranzit nabízejí. Interní BGP spojení budou kopírovat stávající model BGP pro IPv4, tedy propojení směrovačů do čtverce. 19

34 3.5.2 Směrovací protokol OSPFv3 Nastavení protokolu OSPFv3 (IPv6) bude kopírovat stávající model OSPFv2 (IPv4) sítě, tedy propojení směrovačů do čtverce IPv6 firewall Pro zajištění ochrany sítě před útoky bude navržena základní sada pravidel pro IPv6 firewall Konfigurace IPv6 na jednotlivých VLAN Na směrovači v každé VLAN bude nakonfigurována IPv6 adresa směrovače, vygenerovaná z IPv4 adresy podle pravidel číslovacího plánu. Dále bude vytvořena konfigurace sdílené IPv6 adresy pro zajištění vysoké dostupnosti služeb. K tomu bude využit protokol Cisco HSRP pro IPv6. Na VLAN se nevyužívá žádná z forem automatické konfigurace, v prostředí datového centra jsou adresy jednotlivým zařízením přidělovány ručně. Bude tedy deaktivováno ohlašování směrovače (router-advertisement) a nebude konfigurována žádná podpora pro DHCPv Aktualizace software v OS Linux Pro nasazení IPv6 bude nasazována verze Debian Linux 6.0. V ojedinělých případech neexistující kompatibility aplikace s verzí 6.0 bude použit Debian Linux 5.0. V případě OpenVZ virtualizace je nutné použít jádro ve verzi s OpenVZ patchi, nejméně ve verzi el5.028stab Pro spolehlivou funkcionalitu IPv6 MTU discovery je doporučováno jádro el5.028stab092 a novější, případně jádro s OpenVZ patchi. Standardní jádro není vhodné zejména z důvodu, že nepodporuje stavový IPv6 firewall. 20

35 V případě jader o starší verzi je bezpodmínečně nutné nastavit hodnotu MTU na síťovém adaptéru na hodnotu 1280 (nejnižší MTU hodnota, kterou musí podporovat každý systém komunikující protokolem IPv6) Konfigurace IPv6 v OS Linux V OS Linux budou konfigurovány IPv6 adresy na stejném rozhraní, jako IPv4 adresy. Tvořeny budou podle schématu uvedeného v číslovacím plánu. Dále bude zakázán příjem oznámení směrovače (router-advertisement) a povolen IPv6 forwarding. Jako poslední zásah do konfigurace bude nastavena volba bindv6only, která umožní aplikacím pomocí IPv6 socketů a speciálního přístupu linuxového jádra přijímat i IPv4 spojení, se zdrojovými adresami namapovanými do IPv6 prostoru ::ffff:0:0/ Změny v aplikacích Změny v aplikacích lze rozdělit na několik kategorií Podpora ve webovém serveru a reverzní proxy Jde o konfigurační změnu u software Nginx a Apache. V případě, že je IPv6 podporováno webovým serverem a reverzním proxy serverem, jedná se o malou úpravu konfiguračního souboru aplikace. Změnu provádí na straně produkčních serverů jejich správce po předchozí konfiguraci IPv6 v operačním systému Podpora práce s IPv6 adresami v aplikaci Jde o nezbytně nutnou podporu na všech místech, kde se v aplikaci s IP adresami pracuje. Aplikace zejména nesmí zpracovávat či ukládat adresy jako textovou podobu IPv4 adresy nebo čtyřbajtové celé číslo bez znaménka (unsigned 32bit integer). Všechna aplikační programová volání musí podporovat předávání adresy tak, aby jak volající, tak volaný dokázal předat/přijmout i IPv6 adresu. 21

36 Zejména z tohoto důvodu musí být provedena podrobná analýza a revize zdrojových kódů. V případě identifikace problémových míst musí dojít k úpravám, aby kód podporoval obě rodiny adres (IPv4 i IPv6). Tato část změn je prováděna aplikačními vývojáři v organizaci Naslouchání na IPv6 socketech V případě webových aplikací tuto podmínku, nutnou pro spuštění služby na IPv6, zajistí podpora ve webovém serveru a reverzní proxy. V případě, že aplikace sama naslouchá na socketovém rozhraní, musí naslouchat zároveň na IPv4 i IPv6 socketech, a to tak, aby úspěšně přijala nově přichozí spojení Ukládání IPv6 adres v databázích Převážně z důvodu dalšího zpracování adres (např. při blokování nevyžádaných obchodních sdělení v diskusních fórech, nebo identifikaci problémových uživatelů) je občas nutné IP adresy ukládat do databáze. Pro tyto případy bude nutné, podobně jako v případě revize API, provést revizi ukládání adres. V případě ukládání adres do databáze (v případě MySQL) bude nutné provést přechod na strukturu varbinary(16) a sadu podpůrných MySQL funkcí, které dokáží převádět IPv4 i IPv6 adresy z textové podoby do binární a naopak. IPv4 adresa v binární podobě pak zabírá v databázi čtyři bajty, IPv6 adresa celých 16 bajtů. 3.8 Změny nastavení load balancerů Konfigurace bude kopírovat svět IPv4, zejména: - Každá VLAN bude mít vlastní Self IP IPv6 adresy - Jednotlivé servery budou přidávány se svými IPv6 adresami mezi ostatní Nodes 22

37 - Každá IPv4 sada serverů (pool) bude mít protějšek v podobě IPv6 sady serverů (poolu) - Každý IPv4 virtuální server bude mít protějšek v podobě IPv6 virtuálního serveru - Pro správné fungování přístupu z interních firemních IPv6 adres bude vytvořeno speciální překladové pravidlo nat6_private_address, kopírující funkcionalitu stávajícího pravidla nat_private_address. 3.9 Úpravy na straně DNS serverů Využívané autoritativní DNS servery, PowerDNS ve verzi , podporují IPv6 záznamy v zónových souborech (tj. na úrovni dat v aplikaci), tak i z pohledu naslouchání na IPv6 socketu. Není potřeba provádět žádnou změnu v nastavení, aby byly IPv6 záznamy v zónách podporovány, toto je funkční automaticky. Aby PowerDNS naslouchal na IPv6 socketu, bude potřeba provést změny v konfiguračních souborech povolit IPv6. V organizaci jsou dále v provozu i rekurzivní servery Unbound 14. Ty IPv6 podporují přirozeně, stačí na serveru, kde jsou umístěny, nakonfigurovat IPv6 konektivitu podle návodu pro servery s operačním systémem Linux Monitoring V organizaci se používají dva monitorovací systémy, Nagios 15 a Mon 16 na operačním systému Linux. Součástí obou monitorovacích nástrojů jsou skripty pro kontrolu dostupnosti služeb, které již podporují jak protokol IPv4, tak i IPv6. 14 Unbound validating, recursive and caching DNS resolver, 15 Nagios, 16 mon Service Monitoring Daemon, 23

38 Pro správné fungování monitoringu tedy stačí na monitorovacích serverech nakonfigurovat IPv6 konektivitu podle návodu pro servery s operačním systémem Linux. 24

39 4. Praktická implementace 4.1 Konfigurace směrovačů v datacentrech Všechny směrovače Cisco je potřeba konfigurovat v tzv. Cisco enable režimu, tedy v privilegovaném režimu. Do konfigurace lze vstoupit pomocí sekvence příkazů Router> enable Router#! uživatel je nyní v enable režimu Router# configure terminal Router (config)#! uživatel je nyní v konfiguračním režimu Z konfiguračního režimu se správce dostane zadáním příkazu exit. Pokud je zanořen v některém z konfiguračních podstromů, může o úroveň výše přejít zadáním příkazu end Základní konfigurace IPv6 na Cisco routeru Jako první z příkazů musíme na Cisco routeru provést povolení IPv6 routování. K tomu slouží příkaz ipv6 unicast-routing Konfigurace Loopback rozhraní Každý směrovač má Loopback rozhraní, které má svoji IPv6 adresu s maskou /128. Pro tyto adresy je vyhrazen rozsah 2a02:598:6262::/64, ze kterého jsou alokovány. Směrovače jsou celkem čtyři, jsou jim tedy přiděleny následující IPv6 adresy. Ty jsou pak nastaveny na loopback rozhraních. Tabulka 4.1: Loopback adresy směrovačů Směrovač A1 Směrovač A2 2a02:598:6262::1/128 2a02:598:6262::2/128 25

40 Směrovač B1 Směrovač B2 2a02:598:6262::3/128 2a02:598:6262::4/128 Konfigurace Loopback rozhraní probíhá následující sekvencí příkazů: interface Loopback0 ipv6 address 2A02:598:6262::X/128! Konfigurace spojovacích sítí mezi směrovači Směrovače jsou v tuto chvíli zapojeny do čtverce a to tak, že v serverovně jsou vždy dva směrovače vzájemně propojené, a z každého směrovače pak vede spoj do protilehlého směrovače ve druhé serverovně. Směrovače ve druhé serverovně jsou pak opět propojené mezi sebou. Pro propojení v rámci serverovny je vyhrazen IPv6 rozsah 2a02:598:6262:X::Y/64, kde X odpovídá číslu serverovny. Poslední hextet, Y, je alokován podle priority směrovače v serverovně: - primární směrovač používá číslo 1 - sekundární směrovač pak číslo 2 Konfigurace spojů v rámci serverovny probíhá tedy následovně: interface Port-channelB ipv6 address 2A02:598:6262:X::Y/64 ipv6 ospf 1 area 0! Místo parametru Port-channelB je nutné dosadit konkrétní název spojovacího rozhraní. Pro propojení mezi serverovnami je vyhrazen IPv6 rozsah 2a02:598:6263:Y::X/64, kde Y odpovídá prioritám směrovačů v propojení (primární směrovače mezi sebou zde mají 1, sekundární pak 2). Poslední hextet adresy, X, pak obsahuje číslo serverovny. Konfigurace vypadá následovně: interface Port-channelA ipv6 address 2A02:598:6263:Y::X/64 ipv6 ospf 1 area 0! 26

41 Ve všech případech jsou rozhraní zahrnuta do IPv6 OSPFv3 oblasti Směrovací protokol BGP Pro správné fungování BGP je nutné nejprve nakonfigurovat Loopback rozhraní a propojovací sítě (viz dvě sekce výše). Dále je nutné nakonfigurovat IPv6 na rozhraních ve směru k národnímu peeringovému uzlu (NIX.cz) a tranzitním poskytovatelům (aktuálně tranzit podporuje pouze jeden IPv4 tranzitní poskytovatel) Konfigurace pro peeringové centrum NIX.cz interface Port-channelA description <---- NIX ipv6 address 2001:7F8:14::Z:Z/64 ipv6 nd ra suppress ipv6 traffic-filter ISP_IPV6_IN_1 in ipv6 traffic-filter ISP_IPV6_OUT_1 out! Parametr Z:Z nabývá hodnot dle aktuálně přidělených adres od sdružení NIX.cz. Konfigurace zahrnuje mimo jiné aplikaci filtrů provozu, které budou vytvořeny později Konfigurace pro tranzitního poskytovatele interface TenGigabitEthernetC/D description <---- smer Tranzit ipv6 address 2001:0DB8:BABA:DEDA::2/64 ipv6 traffic-filter ISP_IPV6_IN_1 in ipv6 traffic-filter ISP_IPV6_OUT_1 out! Konfigurace zahrnuje mimo jiné aplikaci filtrů provozu, které budou vytvořeny později. 27

42 Konfigurace BGP instance Konfigurace předpokládá, že organizace již provozuje IPv4 BGP relace. Nenastavuje se zde tedy např. parametr bgp router ID. Rozlišujeme konfiguraci na směrovačích, které nemají přímé propojení k tranzitnímu partnerovi, nebo do uzlu NIX.cz, a konfiguraci na směrovačích, které přímé propojení k tranzitnímu partnerovi, nebo do uzlu NIX.cz, mají. Konfigurace vždy obsahuje i seznam všech IPv6 adres všech ibgp směrovačů v autonomním systému. V lokalitě 1 vypadá konfigurace směrovače nepřipojeného do NIX.cz takto: router bgp neighbor 2A02:598:6262::1 remote-as neighbor 2A02:598:6262::1 update-source Loopback0 neighbor 2A02:598:6262::2 remote-as neighbor 2A02:598:6262::2 update-source Loopback0 neighbor 2A02:598:6262::3 remote-as neighbor 2A02:598:6262::3 update-source Loopback0! address-family ipv6 neighbor 2A02:598:6262::1 activate neighbor 2A02:598:6262::1 soft-reconfiguration inbound neighbor 2A02:598:6262::2 activate neighbor 2A02:598:6262::2 soft-reconfiguration inbound neighbor 2A02:598:6262::3 activate neighbor 2A02:598:6262::3 soft-reconfiguration inbound network 2A02:598::/32 exit-address-family! V lokalitě 2 vypadá konfigurace směrovače nepřipojeného do NIX.cz podobně, pouze se změní sada BGP sousedů: router bgp neighbor 2A02:598:6262::1 remote-as neighbor 2A02:598:6262::1 update-source Loopback0 neighbor 2A02:598:6262::3 remote-as neighbor 2A02:598:6262::3 update-source Loopback0 neighbor 2A02:598:6262::4 remote-as neighbor 2A02:598:6262::4 update-source Loopback0! address-family ipv6 neighbor 2A02:598:6262::1 activate neighbor 2A02:598:6262::1 soft-reconfiguration inbound neighbor 2A02:598:6262::3 activate neighbor 2A02:598:6262::3 soft-reconfiguration inbound neighbor 2A02:598:6262::4 activate 28

43 neighbor 2A02:598:6262::4 soft-reconfiguration inbound network 2A02:598::/32 exit-address-family! Konfiguraci BGP pro směrovač připojený do NIX.cz uvádím z důvodu rozsáhlosti pouze jednou, ve druhé lokalitě dojde pouze k doplnění ostatních adres BGP sousedů. Konfigurace obsahuje mimo spojení s tranzitním poskytovatelem i základní ukázku konfigurace IPv6 BGP pro sdružení NIX.cz (autonomní systém 6881) a pro routeserver NIX.cz (autonomní systém 47200). K route serveru je připojena velká část poskytovatelů konektivity a obsahu, proto není obvykle nutné konfigurovat IPv6 peeringy s každou organizací zapojenou do NIX.cz. router bgp neighbor 2001:7F8:14::2 remote-as 6881 neighbor 2001:7F8:14::2 description NIX.CZ neighbor 2001:7F8:14::4 remote-as 6881 neighbor 2001:7F8:14::4 description NIX.CZ neighbor 2001:7F8:14::11 remote-as neighbor 2001:7F8:14::11 description NIX.CZ routeserver neighbor 2001:7F8:14::12 remote-as neighbor 2001:7F8:14::12 description NIX.CZ routeserver neighbor 2001:0DB8:BABA:DEDA::1 remote-as neighbor 2001:0DB8:BABA:DEDA::1 description Tranzit neighbor 2A02:598:6262::1 remote-as neighbor 2A02:598:6262::1 update-source Loopback0 neighbor 2A02:598:6262::2 remote-as neighbor 2A02:598:6262::2 update-source Loopback0 neighbor 2A02:598:6262::4 remote-as neighbor 2A02:598:6262::4 update-source Loopback0! address-family ipv6 neighbor 2001:7F8:14::2 activate neighbor 2001:7F8:14::2 soft-reconfiguration inbound neighbor 2001:7F8:14::4 activate neighbor 2001:7F8:14::4 soft-reconfiguration inbound neighbor 2001:7F8:14::11 activate neighbor 2001:7F8:14::11 soft-reconfiguration inbound neighbor 2001:7F8:14::12 activate neighbor 2001:7F8:14::12 soft-reconfiguration inbound neighbor 2001:0DB8:BABA:DEDA::1 activate neighbor 2001:0DB8:BABA:DEDA::1 soft-reconfiguration inbound neighbor 2A02:598:6262::1 activate neighbor 2A02:598:6262::1 soft-reconfiguration inbound neighbor 2A02:598:6262::2 activate neighbor 2A02:598:6262::2 soft-reconfiguration inbound neighbor 2A02:598:6262::4 activate 29

44 neighbor 2A02:598:6262::4 soft-reconfiguration inbound network 2A02:598::/32 exit-address-family! Směrovací protokol OSPFv3 Konfiguraci OSPFv3 na Cisco IOS zajistíme následující sekvencí příkazů. ipv6 router ospf 1 log-adjacency-changes area 0 range 2A02:598:X::/48 area 0 range 2A02:598:6262:X::/64 area 0 range 2A02:598:6263:C::/64 passive-interface default no passive-interface Port-channelA no passive-interface Port-channelB redistribute connected redistribute static! ipv6 router ospf 1 area 0 range 2A02:598:6262::Y/128! Tato konfigurace zajistí, že dojde k vytvoření instance OSPFv3. Instance je aktivní pouze na rozhraních Port-channelA a Port-channelB, pro ostatní rozhraní v směrovači je neaktivní. Parametr C zde vyjadřuje číslo priority spojů mezi směrovači (viz adresování /64 spojovacích sítí). Směrovač oznamuje pouze svou /48 podsíť, tedy podsíť, která platí pro jeho serverovnu. Proto je zapotřebí na všech místech místo X nakonfigurovat číslo serverovny dle adresního plánu. Zároveň je ve výše uvedené konfiguraci uvedený řádek s maskou IPv6 sítě /128. Tento řádek nastavuje oznamování o IPv6 adrese, která je na dotčeném směrovače nastavena na Loopback rozhraní. Proto je potřeba za Y nahradit poslední hextet z takové adresy (viz tabulku Loopback adres výše) Konfigurace HSRP a VLAN Pro každou VLAN je provedena konfigurace IPv6 následujícím způsobem: interface VlanY ipv6 address 2A02:598:X:Y::Z/64 ipv6 nd ra suppress 30

45 standby version 2 standby Y ipv6 2A02:598:X:Y::1/64 standby Y priority CCC standby Y preempt! Zde opět X odpovídá číslu serverovny, Y číslu VLAN (je použito i v direktivě interface VlanY) a Z je poslední oktet IPv4 adresy. Sdílená highavailability adresa vždy končí (má hodnotu parametru Z nastavenou) na ::1. Tímto postupem je zároveň nakonfigurována jak adresa konkrétního směrovače v rámci VLAN, tak zároveň i protokol HSRP pro high-availability, přičemž dochází k nastavování priority routeru primární router v lokalitě má v parametru CCC hodnotu 120, sekundární pak Konfigurace IPv6 firewallu Konfigurace IPv6 firewallu se v průběhu zavádění nových služeb zajisté bude přizpůsobovat. Pro začátek však byla připravena sada IPv6 pravidel, která zajišťují odstínění vnitřní sítě organizace před balastem z Internetu. Pravidla jsou aplikována na všech místech, kde vstupuje/vystupuje provoz z/do IPv6 Internetu. Na vstupu dochází k - zahození adres, které nemají na vstupu co dělat - povolení BGP, ICMP, sestavených spojení a protokolů DNS a WWW (pouze na veřejně dostupné IPv6 adresy) Na výstupu pak probíhá kontrola a propuštění paketů z veřejně dostupných adres, ICMP všeho druhu, DNS provozu a přístupu z vnitřku sítě na HTTP/HTTPS zdroje mimo organizaci. Výpis základního firewallu s pravidly ve směrech OUT (výstup) a IN (vstup) následuje.! ipv6 access-list ISP_IPV6_OUT_1 permit ipv6 FE80::/9 any permit ipv6 2A02:598:1::/64 any permit ipv6 2A02:598:2::/64 any permit tcp 2A02:598:1::/48 any eq www 31

46 permit tcp 2A02:598:1::/48 any eq 443 permit tcp 2A02:598:2::/48 any eq www permit tcp 2A02:598:2::/48 any eq 443 permit icmp 2A02:598:1::/48 any permit icmp 2A02:598:2::/48 any permit ipv6 2A02:598:6262::/48 any permit ipv6 2A02:598:6263::/48 any permit ipv6 2A02:598:7000::/48 any permit ipv6 2A02:598:7001::/48 any permit ipv6 host 2001:0DB8:BABA:DEDA::2 any permit ipv6 host 2001:7F8:14::36:1 any permit ipv6 host 2001:7F8:14::36:2 any permit tcp 2A02:598:1:84::/64 any eq domain permit udp 2A02:598:1:84::/64 any eq domain permit tcp 2A02:598:2:84::/64 any eq domain permit udp 2A02:598:2:84::/64 any eq domain deny ipv6 any any! ipv6 access-list ISP_IPV6_IN_1 remark ODFILTRUJEME BALAST deny icmp any any router-advertisement permit icmp FE80::/9 any permit icmp any any nd-na permit icmp any any nd-ns deny ipv6 3FFE::/16 any deny ipv6 2001:DB8::/32 any deny ipv6 ::/8 any deny ipv6 FE00::/9 any deny ipv6 FF00::/8 any remark POVOLIME BGP permit tcp host 2001:0DB8:BABA:DEDA::1 gt 1023 host 2001:0DB8:BABA:DEDA::2 eq bgp permit tcp host 2001:0DB8:BABA:DEDA::1 eq bgp host 2001:0DB8:BABA:DEDA::2 gt 1023 permit tcp 2001:7F8:14::/64 gt 1023 host 2001:7F8:14::36:1 eq bgp permit tcp 2001:7F8:14::/64 eq bgp host 2001:7F8:14::36:1 gt 1023 permit tcp 2001:7F8:14::/64 gt 1023 host 2001:7F8:14::36:2 eq bgp permit tcp 2001:7F8:14::/64 eq bgp host 2001:7F8:14::36:2 gt 1023 remark POVOLIME ICMP NA ROUTERY permit icmp any host 2001:0DB8:BABA:DEDA::2 permit icmp any host 2001:7F8:14::36:1 permit icmp any host 2001:7F8:14::36:2 remark POVOLIME ICMP permit icmp any 2A02:598:1::/64 permit icmp any 2A02:598:2::/64 permit icmp any 2A02:598:1::/48 echo-reply permit icmp any 2A02:598:2::/48 echo-reply permit icmp any 2A02:598:6262::/48 permit icmp any 2A02:598:6263::/48 remark POVOLIME WWW 32

47 permit tcp any 2A02:598:1::/64 eq www permit tcp any 2A02:598:2::/64 eq www permit tcp any host 2A02:598:1::1077 eq domain permit udp any host 2A02:598:1::1077 eq domain permit tcp any host 2A02:598:2::1077 eq domain permit udp any host 2A02:598:2::1077 eq domain permit ipv6 any host 2A02:598:6263:7000::2 permit ipv6 any 2A02:598:7000::/48 permit ipv6 any 2A02:598:7001::/48 remark POVOLIME SESTAVENA SPOJENI permit tcp any 2A02:598:1::/48 established permit tcp any 2A02:598:2::/48 established permit udp any eq domain 2A02:598:1:84::/64 permit udp any eq domain 2A02:598:2:84::/64 deny ipv6 any any! 4.2 Konfigurace serveru s OS Linux Je potřeba zajistit jak konfigurací IPv6 sítě v systému, tak zároveň i zajistit unifikované nastavení systému pomocí předdefinovaných hodnot v systémové konfigurační databázi (/proc) Konfigurace systémových parametrů V adresáři /etc/sysctl.d vytvoříme soubor szn-ipv6.conf, do kterého umístíme následující řádky: # ipv6 optimalizace - vypnuti prijmu RA net.ipv6.conf.all.accept_ra=0 net.ipv6.conf.default.accept_ra=0 # zapnuti zpetne kompatibility (ipv6 socket akceptuje i ipv4 # spojeni) net.ipv6.bindv6only=0 # zapne ipv6 forwarding net.ipv6.conf.all.forwarding=1 net.ipv6.conf.default.forwarding=1 Volba accept_ra zamezí příjem oznámení směrovače (routeradvertisements). Volba bindv6only zajistí, že IPv6 sockety budou díky interním mechanismům v linuxovém jádře přijímat i IPv4 spojení a mapovat IPv4 adresy do prostoru ::ffff:0:0/96. 33

48 Volba forwarding zajistí, že systém bude (v případě existence více síťových zařízení) provádět směrování IPv6 paketů mezi jednotlivými rozhraními. Dále do souboru /etc/modules přidáme následující řádky (pokud tam ještě nejsou): ipv6 ip6_tables ip6table_filter ip6table_mangle ip6t_reject Tyto řádky zajistí načtení základních IPv6 modulů při startu systému Konfigurace IPv6 adresy v Debian Linuxu Protože se jedná o servery, je IPv6 adresa nastavena staticky v souboru /etc/network/interfaces: iface ethb inet6 static address 2a02:598:X:Y::Z netmask 64 up ip -6 route add 2a02:598:X::/64 via 2a02:598:X:Y::A up ip -6 route add 2a02:598::/32 via 2a02:598:X:Y::1 up ip -6 route add default via 2a02:598:X:Y::A Zde je potřeba zmínit některé hodnoty, které se liší v závislosti na různém nastavení serveru. 2a02:598:X:Y::Z je IPv6 adresa serveru vygenerovaná z IPv4 adresy serveru. 2a02:598:X:Y::A je IPv6 adresa výchozí brány vygenerovaná z IPv4 adresy výchozí brány. ethb je název síťového rozhraní, pro které je IPv6 nastavováno, například eth0. Z důvodu problémů na straně síťových skriptů v Debian Linuxu dochází k nastavení směrování pomocí příkazu ip -6 route spouštěném po nakonfigurování rozhraní (stav up ). Konfigurují se tři různé záznamy do routovací tabulky: - výchozí brána, která je spočtena z IPv4 výchozí brány 34

49 - směrování celého rozsahu organizace (2a02:598::/32) na Cisco router (2a02:598:X:Y::1) - směrování celého veřejného rozsahu konkrétního datacentra (2a02:598:X::/64) na load balancer nebo Cisco (směrování je shodné s IPv4 směrováním). Toto je nutné z důvodu úprav hlaviček IPv6 paketů, ke kterým dochází na load balancerech. Pokud je v systému staré jádro s nefunkčním IPv6 MTU discovery algoritmem, je nutné přidat za up řádky ještě řádek up ip link set mtu 1280 dev eth0 Místo eth0 je přirozeně nutné zadat název správného síťového rozhraní. 4.3 Konfigurace serveru s OS Solaris Solaris 10 Do souboru /etc/hostname6.nge0 (obecně: k /etc/hostname6 je připojen název zařízení síťové karty) přidáme adresu a prefix sítě: # cat /etc/hostname6.nge0 addif 2a02:598:X:Y::Z/64 up Do souboru /etc/inet/ipnodes přidáme mimo IPv4 i IPv6 adresu a název serveru: # cat /etc/inet/ipnodes ::1 localhost localhost server.ng.seznam.cz loghost 2a02:598:X:Y::Z server.ng.seznam.cz Soubor /etc/inet/ndpd.conf obsahuje zákaz příjmu automaticky generované adresy. V systému Solaris 10 démon volbu bohužel ignoruje, přesto ji nastavíme. # cat /etc/inet/ndpd.conf ifdefault StatelessAddrConf false ifdefault StatefulAddrConf false 35

50 Nakonec zbývá nastavit směrovací tabulku, tj. směrovací záznamy podle datacentra, VLAN a standardu zmíněného v sekci konfigurace linuxového serveru výše. route -p add -inet6 2a02:598:X::/64 2a02:598:X:Y::A route -p add -inet6 2a02:598::/32 2a02:598:X:Y::1 route -p add -inet6 default 2a02:598:X:Y::A Parametr -p zajistí, že se směrovací záznamy uloží v systému a neztratí se během restartu Solaris 11 Nejprve přidáme IPv6 rozhraní: # ipadm create-addr -T addrconf net0/v6 Následně vytvoříme rozhraní se statickou konfigurací a přidáme IPv6 adresu/masku sítě: # ipadm create-addr -T static 2a02:598:X:Y::Z/64 net0/v6static Do souboru /etc/inet/ndpd.conf přidáme zákaz příjmu automaticky generované adresy. # cat /etc/inet/ndpd.conf ifdefault StatelessAddrConf false ifdefault StatefulAddrConf false Nakonec zbývá nastavit směrovací tabulku, tj. směrovací záznamy podle datacentra, VLAN a standardu zmíněného v sekci konfigurace linuxového serveru výše. Nastavení směrování je shodné s postupem pro Solaris 10. route -p add -inet6 2a02:598:X::/64 2a02:598:X:Y::A route -p add -inet6 2a02:598::/32 2a02:598:X:Y::1 route -p add -inet6 default 2a02:598:X:Y::A Parametr -p zajistí, že se směrovací záznamy uloží v systému a neztratí se během restartu. 36

51 4.4 Webové servery Organizace používá dva webové servery, Apache a Nginx. Pro správné fungování je potřeba používat následující minimální verze webových serverů: - Apache řady 2.2 a novější - Nginx verze 1.0 a novější Apache server Tento server není potřeba speciálně pro podporu IPv6 konfigurovat. Apache naslouchá na IPv6 socketu při použití standardní Listen 80 direktivy v konfiguračním souboru aplikace Nginx server Konfigurace se provádí tak, že v konfiguračním souboru (jehož umístění závisí na aplikaci) dojde ke změně parametru listen 80; na IPv6-kompatibilní podobu listen [::]:80; Tato varianta způsobí, že Nginx začne do souborů se záznamem o přístupu (aplikační logy) a v případě použití jako reverzní proxy i aplikacím (v hlavičce X-Forwarded-For) předávat IPv4 adresu v IPv6 tvaru, tj. ::ffff: Pokud takové chování není žádoucí, lze zvolit alternativní zápis, kdy v konfiguračním souboru vzniknou dva následující řádky: listen 80; listen [::]80 ipv6only=on; V takovéto konfiguraci bude Nginx naslouchat na dvou socketech. První z nich bude pouze IPv4 socket, druhý pouze IPv6 socket. Jde vlastně o změnu 37

52 chování systému, kdy se pro konkrétní aplikaci nastaví chování jako při direktivě bindv6only=1 (viz výše). 4.5 Load balancery Konfigurace load balancerů F5 Viprion probíhá, na rozdíl od Cisco směrovačů či serverů s OS Linux nebo Solaris, pomocí webového prohlížeče. Následující řádky proto budou kromě textových popisků obsahovat i snímky obrazovky z administračního rozhraní Self IP adresy Konfigurují se pro každou VLAN zvlášť. Zadávají se dva typy adres: - Self IP vlastní tu má každý load balancer svou - Self IP plovoucí (floating) tuto sdílejí oba load balancery v lokalitě, odpovídá na ni však pouze ten balancer, který je v uvedenou chvíli aktivní. Konfigurace probíhá v sekci Network Self IPs: Obrázek 4.1: Přehled Self IPs Po kliknutí na tlačítko Create se objeví dialogové okno, do kterého postupně vyplníme požadované hodnoty: 38

53 Obrázek 4.2: Založení Self IP - IP Address: Zadáme IPv6 adresu podle adresního plánu (resp. viz níže) - Netmask: Zadáme síťovou masku pro IPv6 adresu. Používané varianty jsou: o ffff:ffff:ffff:ffff:0:0:0:0 pro masku /64 o ffff:ffff:ffff:ffff:ffff:ffff:ffff:0 pro masku /112 - VLAN: Vybereme správnou VLAN, do které zadaná Self IPv6 adresa patří - Floating IP: Je-li námi zadávaná adresa plovoucí, zaškrtneme. Plovoucí adresa jde zadat až po zadání standardních IPv6 adres. - Vyplněný dialog potvrdíme kliknutím na tlačítko Finished. Postupně je nutné přidat: - Self IP vlastní pro veřejně dostupné IPv6 adresy - Self IP plovoucí pro veřejně dostupné IPv6 adresy - Self IP vlastní pro každou VLAN v datacentru - Self IP plovoucí pro každou VLAN v datacentru 39

54 V případě Self IPs pro VLAN dochází ke generování IPv6 adres z IPv4 adres standardním způsobem podle číslovacího plánu (např. z IPv4 adresy /24 vznikne IPv6 adresa 2a02:598:1:84::230/64). V případě Self IPs pro veřejně dostupné adresy nejsou dostupné IPv4 adresy vhodné pro tvorbu IPv6 adres, proto jsou nakonfigurovány následující adresy (v tomto pořadí): - Primární load-balancer, Self IP vlastní: 2a02:598:X:0::231/112 - Záložní load-balancer, Self IP vlastní: 2a02:598:X:0::232/112 - Oba load-balancery, Self IP plovoucí: 2a02:598:X:0::230/112 X, jako obvykle, určuje ID datacentra Pravidlo nat6_private_address Toto pravidlo vytvoříme v sekci Local Traffic Virtual Servers irules. Klikneme na tlačítko Create new irule a postupně vyplníme dialogové okno podle následujících parametrů: Name: nat6_private_address Definition: when CLIENT_ACCEPTED { if {[class match [IP::remote_addr] equals private_net6]} { snat [IP::local_addr] } } Pravidlo využívá definici private_net6, což je proměnná, obsahující celou adresu sítě organizace, tj. 2a02:598::/ Přidávání IPv6 serverů do seznamu Nodes Každý server, resp. jeho IPv6 adresu, je potřeba přidat do seznamu serverů (v podání load-balanceru se serverům říká Nodes). Správa Nodes probíhá v sekci Local Traffic Virtual Servers Nodes: 40

55 Obrázek 4.3: Přehled Nodes Chceme-li přidat nový server (Node), klikneme na tlačítko Create, které nás přesměruje na dialogové okno pro zadávání nového serveru (Node): Obrázek 4.4: Vytvoření nového Node 41

56 Zde zadáváme hlavně IPv6 adresu serveru (bez masky sítě) a název serveru. Protože rozhraní pro správu Viprionu neakceptuje dva stejné názvy serverů, je potřeba k názvu každého serveru připojit text _v6. Dále je možné vybrat tzv. Health Monitor, tedy skript, který bude testovat funkčnost serveru. Výchozí hodnota (Node Default) je testování pomocí ICMPv6 tj. zda server odpovídá na dotaz ICMP echo request. Výchozí hodnota plně postačuje a mění se jen ve speciálních případech. Vyplněný dialog potvrdíme kliknutím na tlačítko Finished Tvorba IPv6 Poolů Konfigurace a tvorba IPv6 Poolů probíhá v sekci Local Traffic Virtual Servers Pools. Přehled poolů vypadá následovně: Obrázek 4.5: Přehled poolů Chceme-li přidat nový Pool, klikneme na tlačítko Create. Objeví se dialogové okno pro založení poolu. V tomto okně postupně vyplníme následující položky. - Name: Název shodný s IPv4 poolem, na konec přidáme text _v6 - Health Monitors: vybereme Health Monitor podle typu služby - New Members: o Zadáme TCP/UDP port služby do pole Service Port 42

57 o Z rozvinutého seznamu vedle textu Address vybereme a pomocí tlačítka Add postupně přidáme ty servery, na kterých služba běží. - Ostatní volby neměníme - Vyplněný dialog potvrdíme kliknutím na tlačítko Finished. 43

58 Obrázek 4.6: Založení poolu IPv6 virtuální servery Jako poslední krok při přidávání konfigurace služby na load balanceru je nutné založit tzv. virtuální server. To provádíme v sekci Local Traffic Virtual Servers kliknutím na tlačítko Create. Obrázek 4.7: Přehled virtuálních serverů Při zakládání virtual serveru je nutné vyplnit zejména následující vlastnosti: - Name: Název shodný s IPv4 poolem, na konec přidáme text _v6 - Destination Type: Host, Address: Veřejně dostupná adresa služby (např. 2a02:598:1::7) - Service Port: port podle typu služby, např. 80 pro HTTP, 443 pro HTTPS - Type: Performance (Layer 4) (vybraný způsob rozkladu zátěže na úrovni čtvrté vrstvy ISO/OSI modelu, shodné s IPv4 virtual servery) - Protocol: protokol podle typu služby, TCP nebo UDP - Protocol Profile: fastl4, shodné s IPv4 virtual servery - irules: vybereme irule nat6_private_address, založený v Default Pool: vybereme pool, který jsme pro službu založili v předcházejícím kroku - Ostatní volby neměníme - Vyplněný dialog potvrdíme kliknutím na tlačítko Finished. 44

59 Nyní může proběhnout otestování funkčnosti a následně založení AAAA záznamu v DNS. Poté už bude služba dostupná uživatelům. Obrázek 4.8: Založení virtuálního serveru 4.6 DNS servery Pro povolení naslouchání na IPv6 socketu je potřeba upravit konfigurační soubor pdns.conf tak, aby konfigurační volba local-ipv6 obsahovala IPv6 adresu, na které chceme naslouchat, např. takto: local-ipv6=2a02:598:x:y::z 45