Nasazení IPv6 v síti poskytovatele obsahu

Č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

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.

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 2013

...........................................

České vysoké učení technické Fakulta elektrotechnická © 2008 – 2013 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.

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

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

Obsah Úvod .............................................................................................................. 1 O protokolu IPv6 ....................................................................................... 3 Představení práce ....................................................................................... 3 1. Pozadí práce ............................................................................................. 6 2. Analýza prostředí .................................................................................... 8 2.1 Podpora nových technologií ................................................................ 8 2.2 Alokované IPv6 adresy........................................................................ 8 2.3 Adresní plán......................................................................................... 8 2.4 Volba implementace IPv6 v organizaci ............................................... 9 2.5 Podpora IPv6 v síťových prvcích a na síti ......................................... 10 2.6 Podpora IPv6 v serverových operačních systémech ......................... 12 2.7 Podpora IPv6 v aplikacích ................................................................. 13 3. Návrh řešení ........................................................................................... 15 3.1 Alokace IPv6 u RIPE......................................................................... 15 3.2 Adresní plán....................................................................................... 15 3.3 Volba implementace .......................................................................... 18

xi

3.4 Aktualizace řídícího software v síťových prvcích ............................. 19 3.5 Konfigurace IPv6 sítě ........................................................................ 19 3.6 Aktualizace software v OS Linux ...................................................... 20 3.7 Změny v aplikacích ............................................................................ 21 3.8 Změny nastavení load balancerů........................................................ 22 3.9 Úpravy na straně DNS serverů .......................................................... 23 3.10 Monitoring ....................................................................................... 23 4. Praktická implementace ....................................................................... 25 4.1 Konfigurace směrovačů v datacentrech ............................................. 25 4.2 Konfigurace serveru s OS Linux ....................................................... 33 4.3 Konfigurace serveru s OS Solaris ...................................................... 35 4.4 Webové servery ................................................................................. 37 4.5 Load balancery................................................................................... 38 4.6 DNS servery....................................................................................... 45 4.7 Správný postup konfigurace IPv6 služby .......................................... 46 5. Testování ................................................................................................ 47 5.1 Použité nástroje .................................................................................. 47 5.2 Testovací scénáře ............................................................................... 48 5.3 Výsledky testování ............................................................................. 51 Závěr ........................................................................................................... 52 Zhodnocení práce ..................................................................................... 52 Možnosti rozvoje ..................................................................................... 52 Použitá literatura ....................................................................................... 54 Příloha A Seznam použitých zkratek ...................................................... 55 Příloha B Obsah přiloženého CD ............................................................. 56

xii

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 ..................................................................... 38 Obrázek 4.2: Založení Self IP ..................................................................... 39 Obrázek 4.3: Přehled Nodes ........................................................................ 41 Obrázek 4.4: Vytvoření nového Node ........................................................ 41 Obrázek 4.5: Přehled poolů ......................................................................... 42 Obrázek 4.6: Založení poolu ....................................................................... 44 Obrázek 4.7: Přehled virtuálních serverů .................................................... 44 Obrázek 4.8: Založení virtuálního serveru .................................................. 45

xiii

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

xiv

xv

Ú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/IP1. 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ž 28, 216 a 224. Neméně důležité, byť více kontroverzní, bylo zavedení překladu IP adres3. 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, http://tools.ietf.org/html/rfc791 RFC 1517 – RFC 1520, Classless Inter-Domain Routing 3 RFC 1631, The IP Network Address Translator, http://tools.ietf.org/html/rfc1631 2

1

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 adres4

4

Geoff Huston, IPv4 address report, http://www.potaroo.net/tools/ipv4/index.html

2

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 18835, načež již po třech letech, v roce 1998, se – tehdy stále nový protokol – dočkal první aktualizace6. 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 6

RFC 1883, Internet Protocol, Version 6, http://tools.ietf.org/html/rfc1883 RFC 2460, Internet Protocol, Version 6, http://tools.ietf.org/html/rfc2460

3

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

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

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

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

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 RIPE7 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ů. http://www.ripe.net/

8

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).

2.4.1 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 NAT648 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.

2.4.2 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, http://tools.ietf.org/html/rfc6146

9

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ě.

2.4.4 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.

2.4.5 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

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ř. SEND9). Nadále tedy nebudou v návrhu ani v implementaci řešeny.

2.5.2 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ě).

2.5.3 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, http://tools.ietf.org/html/rfc3971 - protokol pro ochranu před nevyžádaným rozesíláním oznámení o routerech dostupných v síti.

11

Později byl na verzi 10 aktualizován i software ve starších zařízeních BigIP 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í IPv6.

2.6 Podpora IPv6 v serverových operačních systémech 2.6.1 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 199610, opravdu plnohodnotná implementace této technologie se v Debian Linuxu objevila až ve verzi Debian Linux „Squeeze“ (6.0), který se objevil v únoru 201111. Tato verze tedy bude dále uvažována pro implementaci.

2.6.2 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 IPv6.

2.6.3 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, http://www.redhat.com/mirrors/LDP/HOWTO/Linux+IPv6HOWTO/basic-history-ipv6-linux.html 11 Informace o verzi Debian „squeeze“, http://www.debian.org/releases/squeeze/

12

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.

2.7.1 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í.

2.7.2 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 IPv6.

2.7.3 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

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

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::/32.

3.2 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-6412. 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, http://tools.ietf.org/html/rfc4291

15

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ě

3.2.2 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ž 4095. 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 192.168.40.1 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

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ě.

3.2.3 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 hextetu13 IPv6 adresy, a to opět v přepisu „tak, jak je“. Tedy například pro IPv4 adresu 192.168.40.128/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 192.168.89.111/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 192.168.89.10/21

13

2a02:598:1:89::10/64

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

192.168.88.11/21

2a02:598:1:89::111/64

192.168.90.12/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.

3.2.4 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

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

3.5.1 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

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.

3.5.3 IPv6 firewall Pro zajištění ochrany sítě před útoky bude navržena základní sada pravidel pro IPv6 firewall.

3.5.4 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 DHCPv6.

3.6 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 2.6.18 s OpenVZ patchi, nejméně ve verzi el5.028stab081.1.1. Pro spolehlivou funkcionalitu IPv6 MTU discovery je doporučováno jádro el5.028stab092 a novější, případně jádro 2.6.32 s OpenVZ patchi. Standardní jádro 2.6.18 není vhodné zejména z důvodu, že nepodporuje stavový IPv6 firewall.

20

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).

3.6.1 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/96.

3.7 Změny v aplikacích Změny v aplikacích lze rozdělit na několik kategorií.

3.7.1 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.

3.7.2 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

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.

3.7.3 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í.

3.7.4 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

-

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 2.9.22, 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 Unbound14. 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. 3.10 Monitoring V organizaci se používají dva monitorovací systémy, Nagios 15 a Mon16 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, http://unbound.net/ Nagios, http://www.nagios.org/ 16 mon – Service Monitoring Daemon, https://mon.wiki.kernel.org/index.php/Main_Page 15

23

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

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.

4.1.1 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

4.1.2 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

2a02:598:6262::1/128

Směrovač A2

2a02:598:6262::2/128

25

Směrovač B1

2a02:598:6262::3/128

Směrovač B2

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 !

4.1.3 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

2a02:598:6262:X::Y/64, Y,

serverovny

je

vyhrazen

IPv6

rozsah

kde X odpovídá číslu serverovny. Poslední hextet,

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

2a02:598:6263:Y::X/64,

serverovnami

je

vyhrazen

IPv6

rozsah

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

Ve všech případech jsou rozhraní zahrnuta do IPv6 OSPFv3 oblasti 0.

4.1.4 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).

4.1.4.1 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.

4.1.4.2 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

4.1.4.3 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 43037 neighbor 2A02:598:6262::1 remote-as 43037 neighbor 2A02:598:6262::1 update-source Loopback0 neighbor 2A02:598:6262::2 remote-as 43037 neighbor 2A02:598:6262::2 update-source Loopback0 neighbor 2A02:598:6262::3 remote-as 43037 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 43037 neighbor 2A02:598:6262::1 remote-as 43037 neighbor 2A02:598:6262::1 update-source Loopback0 neighbor 2A02:598:6262::3 remote-as 43037 neighbor 2A02:598:6262::3 update-source Loopback0 neighbor 2A02:598:6262::4 remote-as 43037 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

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 43037 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 47200 neighbor 2001:7F8:14::11 description NIX.CZ routeserver neighbor 2001:7F8:14::12 remote-as 47200 neighbor 2001:7F8:14::12 description NIX.CZ routeserver neighbor 2001:0DB8:BABA:DEDA::1 remote-as 29208 neighbor 2001:0DB8:BABA:DEDA::1 description Tranzit neighbor 2A02:598:6262::1 remote-as 43037 neighbor 2A02:598:6262::1 update-source Loopback0 neighbor 2A02:598:6262::2 remote-as 43037 neighbor 2A02:598:6262::2 update-source Loopback0 neighbor 2A02:598:6262::4 remote-as 43037 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

neighbor 2A02:598:6262::4 soft-reconfiguration inbound network 2A02:598::/32 exit-address-family !

4.1.5 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).

4.1.6 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

standby standby standby standby

version 2 Y ipv6 2A02:598:X:Y::1/64 Y priority CCC 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 110.

4.1.7 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

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

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).

4.2.1 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

(router-

advertisements). 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

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.

4.2.2 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

-

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 4.3.1 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 127.0.0.1 localhost 10.2.71.121 server.ng.seznam.cz 2a02:598:X:Y::Z server.ng.seznam.cz

loghost

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

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.

4.3.2 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 net0/v6static

create-addr

-T

static

2a02:598:X:Y::Z/64

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

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ší

4.4.1 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.

4.4.2 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) ::ffff:192.168.1.2.

předávat

IPv4

adresu

v IPv6

tvaru,

tj.

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

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í.

4.5.1 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

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

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 192.168.84.230/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.

4.5.2 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::/32.

4.5.3 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

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

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.

4.5.4 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

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ěží.

43

-

Ostatní volby neměníme

-

Vyplněný dialog potvrdíme kliknutím na tlačítko Finished.

Obrázek 4.6: Založení poolu

4.5.5 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 4.5.2.

-

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

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

Úprava DNS zón přidáním AAAA záznamů je jednoduchá, např. do souboru /etc/bind/master/novinky.cz přidáme veřejně dostupnou IPv6 adresu služby: @ www

IN AAAA 2a02:598:1::7 IN AAAA 2a02:598:1::7

4.7 Správný postup konfigurace IPv6 služby Protože je v postupu poměrně dost kroků, považuji za vhodné přidat i doporučený postup konfigurace služby tak, aby byla skutečně zajištěna její funkčnost a nedošlo k omezení uživatelů. Před započetím konfigurace podle této tabulky se předpokládá funkční IPv6 konektivita a hotové nastavení síťových směrovačů a load balancerů. V každém kroku zároveň zmiňuji osobu, která je za uvedený krok zodpovědná. Právo veta (tj. odmítnutí spuštění služby po IPv6) má vždy administrátor služby. Pokud bude konfigurace provedena v uvedeném pořadí, a není-li chyba na straně aplikace, bude služba funkční i po IPv6. Tabulka 4.2: Postup konfigurace IPv6 služby #

Úkon

Zodpovědnost

1. Úprava aplikace pro podporu IPv6

Vývojář služby

2. Úprava konfigurace serveru

Administrátor

3. Úprava konfigurace load balanceru

Administrátor

4. Otestování funkčnosti služby přes IPv6 protokol 5.

Umístění IPv6 adresy služby do DNS a zpřístupnění koncovým uživatelům

Administrátor, Vývojář služby Administrátor

46

5. Testování Každá služba musí před spuštěním IPv6 pro veřejnost projít sadou testovacích scénářů, aby bylo zajištěno, že zavedení nového protokolu nepřináší žádné negativní dopady na uživatele. Teprve po průchodu standardními testovacími scénáři je možné přidat AAAA záznam do DNS konfigurace tak, jak je popsáno v kapitole 4.6. Proto jsem nejprve vybral sadu nástrojů, kterou lze otestovat služby po jejich nakonfigurování, a připravil sadu testovacích scénářů. Nakonec jsem provedl test pro sadu služeb, které byly spuštěny v první vlně implementace IPv6.

5.1 Použité nástroje Úspěch testování závisí mimo jiné i na použitých nástrojích. Pro testování sítě v datacentru jsem zvolil čtyři základní nástroje: ping6, traceroute, dig a wget.

5.1.1 Ping, resp. ping6 Nástroj Ping, resp. ping6 testuje funkčnost IPv6 konektivity (konkrétně ICMP protokolu) mezi testujícím a testovaným systémem. Umožňuje například: -

odhalit rozdílné chování sítě v případě IPv4 a IPv6 (testujeme zvlášť IPv4 síť nástrojem ping a IPv6 síť nástrojem ping6)

-

zjistit, zda v síti existuje úzké hrdlo z pohledu MTU

-

ověřit ztrátovost paketů na síti

Pomocí nástroje ping ale není jednoduché diagnostikovat problém „na cestě“ mezi testujícím a testovaným systémem, k tomu slouží nástroj traceroute.

47

5.1.2 Traceroute Podobně jako Ping, resp. ping6, testuje funkčnost IPv6 konektivity – dokáže využít UDP a ICMP protokolu a zobrazí všechny systémy na cestě od testujícího k testovanému systému, které odpoví na UDP resp. ICMP paket.

5.1.3 Dig Nástroj dig slouží k diagnostice systému DNS. Pomůže nám zjistit, zda jsou změny, které provedeme v DNS, skutečně vidět (tzn. obsah DNS zóny odpovídá očekávání) a dále také zda DNS servery správně reagují na dotaz pomocí protokolu IPv6 (tzn. je funkční IPv6 konektivita na server).

5.1.4 Wget Tento nástroj umožňuje simulovat chování klientského prohlížeče. Jeho spuštěním dokážeme načíst obsah z webového serveru pomocí námi preferovaného protokolu (IPv4 nebo IPv6) a porovnat chování obou protokolů, případně rozdílné výstupy z testu.

5.2 Testovací scénáře Navrhl jsem základní testovací scénáře, které pomohou odhalit případné problémy v konfiguraci.

5.2.1 Konektivita v datacentru Ověření proběhne nástrojem Ping resp. Ping6. Test se provádí ze serveru uvnitř sítě s funkční IPv6 konektivitou a porovnává se výsledek pro IPv4 a IPv6 protokol. Test musí vrátit maximálně 1% ztrátovost paketů (packet loss) a rozdíl mezi středním časem odpovědi (avg) IPv4 a IPv6 nesmí překročit ±10 % hodnoty IPv4 času. # ping6 -c 50 2a02:598:2:63::11 --- 2a02:598:2:63::11 ping statistics --50 packets transmitted, 50 received, 0% packet loss, time 50015ms

48

rtt min/avg/max/mdev = 1.022/1.935/2.775/0.754 ms # ping -c 50 10.2.63.11 --- 10.2.63.11 ping statistics --50 packets transmitted, 50 received, 0% packet loss, time 50035ms rtt min/avg/max/mdev = 0.931/2.054/3.264/0.727 ms

5.2.2 Konektivita z datacentra do internetu Opět využívá nástroje ping6, případně traceroute pro diagnostiku. Ze serveru uvnitř sítě musí být dostupný stroj v IPv6 Internetu (musí odpovídat na ping6). Pro test jsme si vybrali cílový server www.nix.cz. Test musí vrátit maximálně 1% ztrátovost paketů (packet loss). # ping6 -c 50 www.nix.cz --- www.nix.cz ping statistics --50 packets transmitted, 50 received, 0% packet loss, time 49929ms rtt min/avg/max/mdev = 7.817/9.341/11.271/0.975 ms

5.2.3 Lokální test reakce aplikace Pro tento test použijeme nástroj wget a pokusíme se načíst obsah z interního serveru pomocí protokolu IPv6. Hostname (HTTP hlavičku Host) určujeme ručně, stejně tak jako IPv6 adresu testovaného stroje. V případě IPv6 adresy nesmíme zapomenout tuto uvádět v hranatých závorkách, jinak dochází ke kolizím se syntaxí pro uvedení čísla portu. Test musí vrátit obsah stránky v rozumně krátkém čase (nižším, než půl sekundy). # wget -O /dev/null --header="Host: www.novinky.cz" http://[2a02:598:2:63::11]:9611/ --2013-04-20 23:40:45-- http://[2a02:598:2:63::11]:9611/ Connecting to [2a02:598:2:63::11]:9611... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: ‘/dev/null’ [

<=>

] 59,129

--.-K/s

in 0.04s

2013-04-20 23:40:45 (1.29 MB/s) - ‘/dev/null’ saved [59129]

49

5.2.4 Test načítání obsahu aplikace z internetu Jde o test, který probíhá v okamžiku nakonfigurování virtual serveru na load-balanceru, tedy v okamžiku, kdy je již služba připravena k ostrému spuštění pro uživatele, ale ještě není AAAA záznam v DNS zóně. Proto dotaz nástrojem wget využívá přímo IPv6 adresy služby. # wget -O /dev/null --header="Host: www.novinky.cz" http://[2a02:598:2::7]/ --2013-04-20 23:52:46-- http://[2a02:598:2::7]/ Connecting to [2a02:598:2::7]:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: ‘/dev/null’ [ <=>

] 59,129

--.-K/s

in 0.04s

2013-04-20 23:52:46 (1.27 MB/s) - ‘/dev/null’ saved [59129]

5.2.5 Překlad jmenného názvu na IPv6 adresu Po vložení AAAA záznamu do DNS musíme otestovat, zda je záznam korektně viditelný pro vnější internet. Testujeme vždy oba DNS servery organizace, tj. ns.seznam.cz a ms.seznam.cz. Jde-li o službu s více názvy, např. www.novinky.cz a novinky.cz, testujeme vždy oba názvy. Pokud nástroj dig vrátí prázdný řádek, není záznam v DNS vidět. # dig +short -tAAAA 2a02:598:1::7 # dig +short -tAAAA 2a02:598:1::7 # dig +short -tAAAA 2a02:598:1::7 # dig +short -tAAAA 2a02:598:1::7

www.novinky.cz @ns.seznam.cz www.novinky.cz @ms.seznam.cz novinky.cz @ns.seznam.cz novinky.cz @ms.seznam.cz

5.2.6 End-to-End test aplikace z internetu Tento test může proběhnout až v okamžiku, kdy je do DNS umístěn AAAA záznam. Je téměř shodný s testem 5.2.4, jen se místo dotazů na IPv6 adresu ptáme už přímo na název serveru. # wget -6 -O /dev/null http://www.novinky.cz/ --2013-04-20 23:53:27-- http://www.novinky.cz/ Resolving www.novinky.cz (www.novinky.cz)... 2a02:598:1::7 Connecting to www.novinky.cz (www.novinky.cz)|2a02:598:1::7|:80... HTTP request sent, awaiting response... 200 OK

50

Length: unspecified [text/html] Saving to: ‘/dev/null’ [ <=>

] 59,129

--.-K/s

in 0.05s

2013-04-20 23:53:27 (1.22 MB/s) - ‘/dev/null’ saved [59129]

5.3 Výsledky testování Uvádím pouze výsledky testování pro tři základní služby, které byly nakonfigurovány jako první. Ostatní služby musí projít podobným testem, jinak nejsou vyhodnoceny jako funkční a dostupné po IPv6. Tabulka 5.1: Výsledky testování

www.super.cz

www.sport.cz

www.novinky.cz

Služba

51

Test

Očekávání

Skutečnost

Výsledek

5.2.1

<10 ms, <±10% diff, <1% p.l.

1,5 ms, -6% diff, 0% p.l.

V pořádku

5.2.2

<20 ms odezva, <1% p.l.

9,3 ms odezva, 0% p.l.

V pořádku

5.2.3

Úspěšně načte obsah

Úspěšně načte obsah

V pořádku

5.2.4

Úspěšně načte obsah

Úspěšně načte obsah

V pořádku

5.2.5

Vrátí IPv6 adresu

Vrátí IPv6 adresu

V pořádku

5.2.6

Úspěšně načte obsah

Úspěšně načte obsah

V pořádku

5.2.1

<10 ms, <±10% diff, <1% p.l.

1,3 ms, 0% diff, 0% p.l.

V pořádku

5.2.2

<20 ms odezva, <1% p.l.

9,8 ms odezva, 0% p.l.

V pořádku

5.2.3

Úspěšně načte obsah

Úspěšně načte obsah

V pořádku

5.2.4

Úspěšně načte obsah

Úspěšně načte obsah

V pořádku

5.2.5

Vrátí IPv6 adresu

Vrátí IPv6 adresu

V pořádku

5.2.6

Úspěšně načte obsah

Úspěšně načte obsah

V pořádku

5.2.1

<10 ms, <±10% diff, <1% p.l.

1,7 ms, 7% diff, 0% p.l.

V pořádku

5.2.2

<20 ms odezva, <1% p.l.

10,1 ms odezva, 0% p.l.

V pořádku

5.2.3

Úspěšně načte obsah

Úspěšně načte obsah

V pořádku

5.2.4

Úspěšně načte obsah

Úspěšně načte obsah

V pořádku

5.2.5

Vrátí IPv6 adresu

Vrátí IPv6 adresu

V pořádku

5.2.6

Úspěšně načte obsah

Úspěšně načte obsah

V pořádku

Závěr Cílem mé bakalářské práce bylo zanalyzovat, navrhnout a implementovat způsob, jakým lze v datacentru začít poskytovat internetové služby pomocí internetového protokolu IPv6. Nejdůležitější částí práce byla bezpochyby analýza stávajícího prostředí a navržení potřebných změn v infrastruktuře datacentra. Neméně důležitá pak byla i samotná realizace navržených změn, která vedla ke zdárnému konci – tedy k tomu, že dnes organizace úspěšně provozuje služby dostupné pomocí IPv6 právě díky mnou navrženým postupům.

Zhodnocení práce Na základě zkušeností získaných z provozu mnou navrženého řešení zastávám názor, že práce splnila požadavky na ni kladené. Při návrhu jsem se setkal s mnoha omezeními, která stávající platformy přinášejí. Klíčová omezení se podařilo vyřešit a řešení zadokumentovat. Věřím, že případné další rozšiřování IPv6 v organizaci bude díky navrženým technologickým změnám úspěšné a efektivní. Během přípravy jsem získal mnoho poznatků z oblasti nových síťových technologií a protokolů, které již nyní využívám při práci na dalších projektech.

Možnosti rozvoje Některé stávající vnitřní aplikace v organizaci stále nedisponují plnou podporou IPv6 a proto pro komunikaci využívají i nadále protokol IPv4. V okamžiku, kdy bude IPv6 spolehlivě fungovat i v těchto aplikacích, bude díky navržené konfiguraci snadno realizovatelný jejich přechod na nový protokol. Dále, ačkoli jde o budoucnost vzdálenou několik let, je bezpochyby možné zvažovat přechod na datacentra využívající jen pouze protokol IPv6. Způsob takového fungování jsem zmínil již v kapitole 2.4.1. Věřím, že se datacentra

52

obecně touto cestou vydají a protokol IPv4 v nich, i kvůli mnoha jeho omezením, jednoho dne budeme moci úplně deaktivovat.

53

Použitá literatura [1] SATRAPA, Pavel. IPv6: internetový protokol verze 6. 3., aktualiz. a dopl. vyd. Praha: CZ.NIC, c2011, 407 s. CZ.NIC. ISBN 978-80904248-4-5. [2] HAGEN, Silvia. IPv6 Essentials. 2nd ed. Beijing: O´Reilly, 2006, 418 s. ISBN 05-961-0058-2. [3] Debian IPv6 Project. Debian.org [online]. 2013 [cit. 2013-03-11]. Dostupné z: http://wiki.debian.org/DebianIPv6 [4] IPv6 Knowledge Base Portal. CISCO. Cisco.org [online]. 2012 [cit. 2013-03-19]. Dostupné z: http://www.cisco.com/web/solutions/netsys/ipv6/knowledgebase/index. html [5] COLTUN, Rob. OSPF for IPv6. IETF.org [online]. 2008 [cit. 2013-0326]. Dostupné z: http://tools.ietf.org/html/rfc5340 [6] HINDEN, Robert M. IP Version 6 Addressing Architecture. IETF.org [online]. 2006 [cit. 2013-04-02]. Dostupné z: http://tools.ietf.org/html/rfc4291 [7] DEERING,

Stephen

E.

Internet

Protocol,

Version

6

(IPv6)

Specification. IETF.org [online]. 1998 [cit. 2013-04-05]. Dostupné z: http://tools.ietf.org/html/rfc2460 [8] KENT, Stephen. Security Architecture for the Internet Protocol. IETF.org

[online].

1998

[cit.

2013-04-05].

Dostupné

z:

http://tools.ietf.org/html/rfc2401 [9] DAVIES, Elwyn B. Recommendations for Filtering ICMPv6 Messages in Firewalls. IETF.org [online]. 2007 [cit. 2013-04-10]. Dostupné z: http://www.ietf.org/rfc/rfc4890.txt

54

Příloha A Seznam použitých zkratek Zkratka

Význam

AAAA

Jeden ze záznamů ve službě DNS, který uchovává IPv6 adresy

ACL

Access Control List, seznam pravidel v bráně firewall, určující povolené a zakázané kombinace zdrojů, cílů a protokolů

BGP

Border Gateway Protocol, protokol pro výměnu směrovacích informací v síti Internet

DNS

Domain Name System, systém překladu jmenných identifikátorů na jiné identifikátory (např. čísla, IP adresy, a pod.)

HTTP

Hypertext Transport Protocol, protokol pro přenos (nejen) textových informací po síti Internet

ID

Obecná zkratka znamenající „identifikátor“

IPv4

Internetový protokol verze 4

IPv6

Internetový protokol verze 6

MTU

Maximum Transmission Unit, největší velikost datového paketu, jakou síť dokáže přenést

MySQL

Databázový stroj vyvíjený komunitou a dostupný jako open-source, byť je jeho vývoj zastřešován společností Oracle

NIX

Neutral Internet eXchange, neutrální uzel zajišťující propojení směrovačů různých organizací. V kontextu této práce jde o uzel NIX.cz.

OSPF

Open Shortest Path First, protokol pro nalezení nejkratší cesty mezi směrovači v rámci organizace

SQL

Structured

Query

Language,

strukturovaný

dotazovací

jazyk

používaný v databázích URL

Uniform Resource Locator, textový řetězec identifikující konkrétní zdroj na síti Internet

VLAN

Virtual LAN, v kontextu datacentra virtualizovaný Ethernet podle standardu IEEE 802.1q

WWW

World-wide-web, služba pro výměnu (primárně) textových a obrazových

informací, založená

využívající protokol HTTP

55

na

principu klient-server

a

Příloha B Obsah přiloženého CD | +| | +-

readme.txt ..................... stručný popis obsahu CD src | thesis.docx .. zdrojový text práce ve formátu MS Word +- data ...................... zdrojové obrázky, nákresy thesis +- thesis.pdf ................ text práce ve formátu PDF

56