Návrh integrace protokolu IPv6 ve firmě Z-Ware

Mendelova univerzita v Brně Provozně ekonomická fakulta

Návrh integrace protokolu IPv6 ve firmě Z-Ware Bakalářská práce

Vedoucí práce: Ing. Petr Zach

Jan Hakl

Brno 2013

Na tomto místě bych rád poděkoval vedoucímu mé bakalářské práce, panu ing. Petru Zachovi, za jeho čas, odborné rady, podporu a trpělivost. Také bych rád poděkoval své rodině a přátelům za jejich podporu po celou dobu mého studia.

Prohlašuji, že jsem práci: Návrh integrace protokolu IPv6 ve firmě Z-Ware vypracoval samostatně a veškeré použité prameny a informace uvádím v seznamu použité literatury. Souhlasím, aby moje práce byla zveřejněna v souladu s § 47b zákona č. 111/1998 Sb., o vysokých školách ve znění pozdějších předpisů a v souladu s platnou Směrnicí o zveřejňování vysokoškolských závěrečných prací. Jsem si vědom, že se na moji práci vztahuje zákon č. 121/2000 Sb., autorský zákon, a že Mendelova univerzita v Brně má právo na uzavření licenční smlouvy a užití této práce jako školního díla podle § 60 odst. 1 autorského zákona. Dále se zavazuji, že před sepsáním licenční smlouvy o využití díla jinou osobou (subjektem) si vyžádám písemné stanovisko univerzity, že předmětná licenční smlouva není v rozporu s oprávněnými zájmy univerzity, a zavazuji se uhradit případný příspěvek na úhradu nákladů spojených se vznikem díla, a to až do jejich skutečné výše.

Brno, 27. 12. 2013

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

4

Abstract Hakl, J. Proposal of integration IPv6 protocol in Z-Ware company. Bachelor thesis. Brno, 2013. This bachelor thesis suggests and discuss methods and procedures of implementing IPv6 to computer network Z-ware company. It deals with practical settings of routers, servers and clients computers. Key words: IPv6, Linux, Cisco, Windows, IPv6 tunnel, Computer network

Abstrakt Hakl, J. Návrh integrace protokolu IPv6 ve firmě Z-Ware. Bakalářská práce. Brno, 2013. Tato bakalářská práce navrhuje a diskutuje metody a postupy implementace IPv6 do počítačové sítě firmy Z-ware. Zabývá se praktickým nastavením routerů, serverů a klientských počítačů. Klíčová slova: IPv6, linux, cisco, windows, IPv6 tunel, počítačová síť

5

OBSAH

Obsah 1 Úvod a cíl práce 1.1 Úvod práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Metodika . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Základní vlastnosti protokolu IPv6 2.1 Historie IPv6 . . . . . . . . . . . . . . 2.2 Formát datagramu . . . . . . . . . . . 2.3 Rozšiřující hlavičky . . . . . . . . . . . 2.4 Adresy v IPv6 . . . . . . . . . . . . . . 2.5 Individuální adresy . . . . . . . . . . . 2.6 Skupinové adresy . . . . . . . . . . . . 2.7 Identifikátor rozhraní . . . . . . . . . . 2.8 ICMPv6 . . . . . . . . . . . . . . . . . 2.9 Objevování sousedů . . . . . . . . . . . 2.10 Automatická konfigurace . . . . . . . . 2.11 Přechodové mechanismy . . . . . . . . 2.12 Routing . . . . . . . . . . . . . . . . . 2.13 Domain Name System . . . . . . . . . 2.14 IP6tables . . . . . . . . . . . . . . . . 2.15 Podpora IPv6 v operačních systémech 2.16 Bezpěčnostní problémy IPv6 . . . . . .

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

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

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

3 Praktická část 3.1 Představení firmy . . . . . . . . . . . . . . . 3.2 Topologie firemní sítě . . . . . . . . . . . . . 3.3 Výběr vhodného tunelu . . . . . . . . . . . . 3.4 Vytvoření účtu a tunelu u tunnel brokera . . 3.5 Konfigurace jihlavské pobočky . . . . . . . . 3.6 Konfigurace brněnské pobočky . . . . . . . . 3.7 Konfigurace serveru se službou iCanteen . . 3.8 Konfigurace webového a emailového serveru

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

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

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

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

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

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

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

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

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

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

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

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

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

6 6 6 6

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

7 7 7 9 10 12 12 13 14 14 15 17 21 21 23 23 24

. . . . . . . .

27 27 27 28 31 32 34 37 38

4 Finanční zhodnocení

40

5 Diskuse

41

6 Závěr

42

7 Reference

43

Přílohy

46

1

ÚVOD A CÍL PRÁCE

1 1.1

6

Úvod a cíl práce Úvod práce

Počátky protokolu IPv4, který má být nahrazen jeho novější verzí IPv6, sahají do roku 1980, kdy byl popsán v RFC 760. Verze, pomocí které je používána dodnes byla popsána v RFC 791 v roce 1981. První nedostatky adres se začaly objevovat začátkem 90. let. Podle tehdejších studií měly být adresy vyčerpány v horizontu 10 let. Tento scénář se nevyplnil, mimo jiné proto, že se začalo používat beztřídní adresování CIDR (Classless Inter-Domain Routing), zpřísnila se kritéria pro přidělování síťových adres a byly zavedeny mechanismy pro překlad adres (NAT-Network Address Translation). Problém s nedostatkem adres se tímto pouze odsunul a opět se projevil okolo roku 2005. Aktuálně se nacházíme v situaci, kdy je vyčerpána centrální zásoba IANA (Internet Assigned Numbers Authority - organizace celosvětově dohlížející na přidělování IP adres) a jednotlivé regionální registry (RIR-Regional Internet Registr) postupně spotřebovávají své zásoby. Výhody IPv6 oproti jeho předchůdci jsou zřejmé. IPv6 má mnohem větší adresní prostor (128 bitů u IPv6 oproti 32 bitům u IPv4). S tím souvisí i podpora mobilních zařízení, kterých za posledních pár let přibylo ohromné množství. Na podporu IPv6 se kazdoročně pořádají nejrůznější akce. Mezi nejvýznamnější patří IPv6 Day, který se koná vždy 6. června. V roce 2012 u příležitosti IPv6 Day implementovali nejvýznamnější poskytovatelé internetových služeb, jako je Google, Facebook, atd., podporu IPv6, takže jsou v současnosti jejich služby dostupné jak ze starého, tak i nového internetového protokolu. Většímu zavedení IPv6 do běžné praxe ovšem brání poskytovatelé internetu, kteří chtějí logicky produkovat co největší zisky a nechtějí mít starosti s implementací a podporou nového protokolu, když o to sami zákazníci zatím nemají moc zájem.

1.2

Cíl práce

Tato bakalářská práce si klade za cíl navrhnout, diskutovat a vybrat nejvhodnější řešení přechodu firmy Z-Ware k IPv6 a její propojení s celosvětovou sítí internet.

1.3

Metodika

V práci bude shrnuta základní problematika IPv6, základy přiřazování adres, bezpečnost a experimentální ověření navrhnutého řešení. V práci bude dále řešen výběr vhodného tunelovacího mechanismu, a to měřením RTT a ztrátovostí paketů, dále implementace IPv6 na servery, klientské počítače a routery a finanční zhodnocení.

2

ZÁKLADNÍ VLASTNOSTI PROTOKOLU IPV6

2

7

Základní vlastnosti protokolu IPv6

Následující kapitola se věnuje bližšímu popisu protokolu IPv6, jeho historii, výhodám a odlišnostem oproti jeho předchůdci, IPv4. Jsou zde podrobně vysvětleny detaily zápisu IPv6 adresy.

2.1

Historie IPv6

Historie IPv6 sahá do začátku 90. let, kdy začínalo být zřejmé, že adresní prostor v rámci IPv4 bude brzy vyčerpán.Pro IPv6 byly stanoveny tyto požadavky (Satrapa. 2011): • rozsáhlý adresní prostor, který vystačí pokud možno navždy • tři druhy adres: individuální (unicast), skupinové (multicast) a výběrové (anycast) • jednotné adresní schéma pro Internet i vnitřní sítě • hierarchické směrování v souladu s hierarchickou adresací • zvýšení bezpečnosti (zahrnout do IPv6 mechanismy pro šifrování, autentizaci a sledování cesty k odesílateli) • podpora pro služby se zajištěnou kvalitou • optimalizace pro vysokorychlostní směrování • automatická konfigurace (pokud možno plug and play) • podpora mobility (přenosné počítače apod.) • hladký a plynulý přechod z IPv4 na IPv6

2.2

Formát datagramu

Jak je vidět na obr. 1, tak datagram v IPv6 začíná hlavičkami, za kterými následují nesená data, oproti IPv4 však došlo v hlavičkách ke změně – dřív byla jejich délka proměnlivá a každý účastník komunikace mohl připojovat další nepovinné volby, každý router proto musel vypočítat kontrolní součet, protože se vždy minimálně změnila hodnota TTL. U IPv6 se naopak standardní hlavička minimalizovala a její prvky se omezily jen na ty nejnutnější. Základní hlavička má konstantní velikost (40 B oproti 20 B u hlavičky IPv4), veškeré doplňující údaje byly přesunuty do rozšířujících hlaviček (Satrapa. 2011). • verze – identifikuje verzi protokolu, u IPv6 obsahuje hodnotu 6

2.2

Formát datagramu

8

Obrázek 1: Formát IPv6 datagramu (Satrapa. 2011) • třída provozu – osmibitová hodnota vyjadřující prioritu datagramu či jeho zařazení do určité přepravní třídy, cílem je, aby tato položka umožnila poskytovat IP služby se zaručenou kvalitou. V praxi se ale tohoto stavu v dohledné době nedočkáme, ani IPv6 však neumí zaručit přenosovou rychlost či zpoždení. Implicitní hodnota je rovna nule. • značka toku – 20 bitová hodnota, zatím není přesně definováno. Jako tok by měl být proud datagramů se společnými vlastnostmi (odesílatel, adresát, požadavky na vlastnosti spojení). Podle značky router pozná, že datagram patří k určitému toku dat, podle toho se router rozhoduje, co s daným paketem udělá. • délka dat – nese údaj o délce datagramu, k této hodnotě se počítají rozšířující hlavičky, nikoliv hlavička standardni. Maximální délka je 64 KB. • další hlavička – identifikace hlavičky, která následuje za standardaní hlavičkou. • dosah – maximální počet skoků, náhrada dřívějšího TTL (Time To Live), průchod jedním směrovačem je považován za jeden skok. Každý směrovač po cestě pak sníží hodnotu o jedničku. Dojde-li tím k vynulování položky, datagram bude zlikvidován a odesílateli se pošle ICMP (Internet Control Message Protocol) zpráva o vypršení maximálního počtu skoků. • adresy – dvojice IPv6 adres – zdrojová adresa (Source Address) a cílová adresa (Destination Address) Jak lze vidět na obr. 2, tak při porovnání hlaviček IPv4 a IPv6 je nápadná absence rozšiřujících voleb, kontrolního součtu a fragmentace u IPv6. Rozšířené volby byly nahrazeny obecnějším principem zřetězení doplňkových hlaviček, údaje o fragmentaci byly přesunuty rovněž do rozšiřujících hlaviček, navíc se dá očekvávat, že fragmentace bude v IPv6 ještě vzácnější než doposud. Kontrolní součet zmizel bez náhrady, je totiž vykonáván na nižších vrstvách síťové architektury (např. Ethernet).

2.3

Rozšiřující hlavičky

9

ti Obrázek 2: Porovnání hlaviček IPv6 a IPv4 datagramu (Cisco. 2011)

2.3

Rozšiřující hlavičky

Právě zde dochází k největší změně ve formátu hlaviček. Položka Další hlavička, která je umístěna na začátku každé rozšiřující hlavičky, obsahuje kód, který identifikuje další hlavičku. Poslední z nich obsahuje informace o typu dat, které datagram nese. Princip tohoto zřetězení hlaviček ukazuje obr. 3. Hlavní výhodou této koncepce je pružnost a úspornost. Přenášejí se pouze potřebné informace. Na druhou stranu zde existuje možná nevýhoda, že zpracování může představovat průchod dlouhým řetězcem. Pokud by se mělo odehrávat v každém směrovači na cestě mezi odesílatelem a příjemcem, mohlo by to vést k nezanedbatelné degradaci výkonu. Tento problém se řeší pomocí předepsaného pořadí rozšiřujících hlaviček v RFC 2460. Zde je jejich pořadí a krátká charakteristika. (Lupa.cz. 2011)

Obrázek 3: Princip zřetězení rozšiřujících hlaviček, (Zytrax.com. 2013)

2.4

Adresy v IPv6

10

1. Základní hlavička IPv6 (IPv6 header) 2. Volby pro všechny (Hop-by-hop Options) – informace pro všechny routery na cestě, že paket nese data, která by ho mohla zajímat 3. Volby pro cíl (Destination Options) – volby určené pro příjemce datagramu 4. Směrování (Routing) – možnost přídání jednoho či více uzlů, kterými musí datagram projít 5. Fragmentace (Fragment) – umožňuje pouze odesílajícímu zařízení odesílat větší data, než dovoluje maximální přenosová velikost paketu (MTU). Obsahuje identifikaci původního neděleného paketu, pořadí fragmentu a označení, zda jde o koncový paket. Umožňuje složit paket do původní podoby 6. Autentizace (Authentication) – obsahuje kontrolní informace, zda nebyla porušena integrita 7. Šifrování obsahu (Encapsulating Security Payload) – obsahuje parametry týkající se šifrování a dešifrování dat 8. Volby pro cíl (Destination Options) – volby pouze pro konečného příjemce 9. Mobilita (Mobility) Každá z hlaviček by měla být v paketu pouze jednou s výjimkou hlavičky Volby pro cíl, která se může vyskytnout dvakrát. Mezilehlé směrovače čtou pouze Volby pro všechny. Výjimku tvoří ty pakety, které mají rozšiřující hlavičku Směrování. Tam pak průběžný cílový uzel zajímá ještě hlavičky Volby pro cíl a Směrování. Ostatní hlavičky jsou určeny pouze pro koncový cílový uzel.

2.4

Adresy v IPv6

Adresa protokolu IPv6 je narozdíl od svého předchůdce 128 bitová (u IPv4 má adresa délku 32 bitů), což znamená, že u IPv6 máme k dispozici 2128 = 1038 adres. Pro lepší představivost, při ploše země 510 065 284,702 km2 vychází na každý metr čtverečný (včetně vodních ploch) těžko představitelných 667 134 927 900 000 000 000 000 adres. V současnosti je těžko uvěřitelné, že by nově vznikající adresní prostor někdy v dohledné době došel. Podoba a zápis adresy Adresa se zapisuje jako osm skupin hexadecimálních číslic oddělených dvojtečkou. Příkladem IPv6 adresy je např.: fedc:ba98:7654:3210:fedc:ba98:7654:3210

2.4

Adresy v IPv6

11

Očekává se, že uživatelé se vyhnou zápisu adresy v tomto tvaru a budou využívat pokud možno pořád DNS.(Satrapa. 2011) Zkracování adres Jelikož je poměrně častou hodnotou nula, nabízí se dvě možnosti pro zkrácení zápisu. Jednak v každé čtveřici můžete vynechat počáteční nuly. Místo „0000“ tedy lze psát jen „0“. Někdy se dokonce vyskytuje několik nulových skupin za sebou. Ty můžete nahradit zápisem „::“ (dvě dvojtečky). Koncovou nulu (v poslední čtveřici) pochopitelně vynechat nelze. Konstrukci „::“ je možné v každé adrese použít jen jednou. Jinak by nebylo jednoznačné, jak se má adresa rozvinout do původní podoby. Například adresu 0123:0000:0000:0000:4567:0000:0000:0000 lze postupně zkrátit takto: 123:0:0:0:4567:0:0:0 123::4567:0:0:0 nebo 123:0:0:0:4567:: nikoliv však 123::4567:: (Satrapa. 2011) Rozdělení adres U IPv6 rozlišujeme 3 druhy adres • Individuální (unicast) – identifikují jednotlivá síťová rozhraní. • Skupinové (multicast) – adresování skupin počítačů. Data odeslaná na tuto adresu jsou doručena všem členům skupiny. Skupinou se rozumí např. všechny IPv6 uzly nebo routery v lokální síti, výběr nejdůležitějších multicast adres ukazuje tabulka 1. • Výběrové (anycast) – označují skupinu, data jsou doručena pouze členovi, který je nejblíže. Rozdeleni adres ukazuje obr. 4.

2.5

12

Individuální adresy

Obrázek 4: Rozdělení IPv6 adres (Graziani. 2013)

2.5

Individuální adresy

Global unicast adresy Tyto adresy jsou obdobou veřejných IPv4 adres, adresa každého uzlu je tedy v IPv6 Internetu unikátní. V současnosti se rozděluje pouze malá část těchto adres, a to prefix 2000::/3. Schéma Global unicast adresy je znázorněno na obr. 5, (IPv6.cz. 2012).

Obrázek 5: Schéma global unicast adresy (Cisco Systems. 2012)

Lokální linkové adresy linky. Mají tvar

Link local adresy jsou jednoznačné pouze v rámci jedné

fe80::identifikátor_rozhraní Jejich výhodou je fakt, že si tuto adresu může každý uzel přidělit automaticky sám. (Graziani. 2013)

2.6

Skupinové adresy

Dalším adresním typem jsou skupinové (multicast) adresy. Multicast je technika, kterou používá zařízení pro poslání jednoho pakeu více strojům v jeden čas. (Emanuel. 2013)

2.7

13

Identifikátor rozhraní

Tabulka 1: Některé multicast adresy

adresa ff02::1 ff02::2 ff02::1:2

2.7

význam všechny uzly v lokální siti všechny routery v lokální síti všechny DHCP routery na lokální síti

Identifikátor rozhraní

Identifikátor rozhraní se používá pro identifikaci koncových stanic v síti, respektive jejich síťových rozhraní a v IPv6 adrese zaujímá posledních 64bitů. K vytvoření identifikátoru rozhraní existuje více metod (IPv6.cz. 2009): • automaticky z MAC adresy v modifikovaném EUI-64 formátu (výchozí pro OS Linux, Cisco, Juniper,Windows XP či Windows Server 2003), • manuálně nastavený, • dočasně či trvale náhodně vygenerovaný (výchozí pro Windows Vista, Windows Server 2008, Windows 7), • identifikátory kryptograficky generované. EUI-64 Základní podoba identifikátoru rozhraní EUI-64 vyczází z MAC adresy síťové karty, kde se vloží mezi třetí a čtvrtý bajt konstanta FFFE. Předposlední bit v prvním bajtu slouží jako příznak globality. Ve standardním EUI-64 zde hodnota 0 signalizuje celosvětově jednoznačnou adresu, zatímco 1 označuje adresu lokální. IPv6 používá modifikované EUI-64 a hodnotu tohoto bitu invertuje. Čili 0 představuje lokální identifikátor a hodnota 1 identifikátor globální. Tato změna usnadňuje vytváření identifikátorů rozhraní „na koleně“ – například pro sériové linky. Takže z MAC adresy 00:8c:a0:c2:71:35 se v IPv6 adrese stane identifikátor rozhraní 028c:a0ff:fec2:7135. Princip vzniku EUI-64 je také vidět na obr. 6.

Obrázek 6: Princip tvorby EUI-64 adresy (IPv6.cz. 2009)

2.8

14

ICMPv6

Tabulka 2: Typy adres, (IPv6.cz. 2009)

prefix ::/128 ::1/128 fc00::/7 fe80::/10 ff00::/8 ostatní

2.8

význam nedefinovaná adresa lokální smyčka (loopback) unikátní individuální lokální individuální lokální linkové adresy skupinové individuální globální

ICMPv6

Internet Control Message Protocol version 6 je pozměněný ICMPv4 pro IPv6, kompletní definice je obsažena v RFC 4443. Hlavním úkolem ICMPv6 je ohlašování chybových stavů, diagnostika funkčnosti (pomocí utility ping) a představuje rámec pro rozšíření k provádění budoucích změn. (Wikipedia. 2013)

2.9

Objevování sousedů

Objejování sousedů (neighbor discovery), je princip, který nahrazuje ARP používaný u IPv4. Hlavním úkolem objevování sousedů je tedy zjištění linkové adresy jiného počítacče ve stejné síti. Kromě toho slouží i k řešení dalších problémů, (Satrapa. 2011) uvádí tyto: • zjišťování linkových adres uzlů ve stejné lokální síti, • rychlé aktualizace neplatných položek a zjišťování změn v linkových adresách, • hledání směrovačů, • přesměrování, • zjišťování prefixů, parametrů sítě a dalších údajů pro automatickou konfiguraci adresy, • ověřování dosažitelnosti sousedů, • detekce duplicitních adres. Ke splnění těchto problémů slouží hlavně 2 zprávy, přenášené pomocí ICMPv6 (Wikipedia. 2013): • Výzva sousedovi (neighbor solicitation) – pomocí této zprávy žádá uzel souseda o linkovou adresu, případně uzel zjišťuje, zda je soused pořád dostupný na dříve zjištěné linkové adrese • Ohlášení souseda (neighbor advertisement) – odpověď na výzvu sousedovi, obsahuje MAC adresu

2.10

Automatická konfigurace

15

Zjištění linkové adresy souseda Pokud chce uzel zjistit MAC adresu jiného uzlu ze stejné podsítě, tak pošle svůj dotaz na adresu ff02:0:0:0:0:1:ff00::/104, tato adresa se jmenuje solicited-node multicast address. Posledních 24 bitů z této adresy patří pro posledních 24 bitů z hledané IPv6 adresy. Pokud tedy uzel hledá MAC adresu pro 2001:db8:1:1:022a:fff:fe32:5ed1, ptát se bude na adrese ff02::1:ff 32:5ed1. Každý IPv6 uzel musí přijímat skupinově adresované datagramy směřující na adresu vyzývaného uzlu pro všechny adresy, které mu byly na příslušném rozhraní přiděleny. Pokud mu dorazí výzva, reaguje na ni ohlášením souseda, z nějž se tazatel dozví jeho linkovou adresu a následně mu může odeslat datagram. (IPv6.cz. 2009)

2.10


Internetový protokol verze 6 byl už od základu navržen pro minimální počáteční konfiguraci. Cílem bylo, aby po připojení zařízení do sítě nebyla od uživatele vyžadována žádná dodatečná konfigurace. Pro tento účel byly navrženy dvě možnosti: bezstavová a stavová konfigurace. Bezstavová konfigurace Díky velkému adresnímu prostoru, kterým IPv6 disponuje, se upustilo od nutnosti určování IPv6 adresy centrální autoritou (serverem), naopak každý klientský počítač si IPv6 adresu určí sám podle údajů, které má k dispozici – např. EUI-64. Uzel poté rozešle výzvu svému sousedovi s právě vygenerovanou adresou, pokud je odpověď negativní, je adresa unikátní. Pro určení zbylé části adresy (globálního prefixu sítě) je potřeba mít informace o svém okolí. Jediný kdo tyto informace má je směrovač, přes který vedou pakety do sítě ale i ven do internetu. Tento směrovač je proto vybaven mechanismem automatického hlášení (Router advertisement pakety). Uzel je případně schopen si o zaslání RA paketu zažádat, a to pomocí Router solicitation. Princip komunikace je zobrazen na obr. 7. Router advertisement paket obsahuje síťový prefix a výchozí bránu. Daný uzel je nyní už schopen vytvořit si platnou IPv6 adresu, stále ale ještě nezná DNS adresu serveru. Tu je schopen poznat pomocí bezstavového DHCPv6. Pro tento mechanismus se vžilo označení SLAAC, nebo-li Stateless Adress Autoconfiguration, popsáno v RFC 2462. Uvedeno na (Lupa.cz. 2011) Stavová konfigurace Stavová konfigurace pracuje na principu fungujícím již pěknou řádku let. Základem je autorita (server), která spravuje konfigurační parametry. Tyto parametry poté klientům po vyžádání sděluje.

2.10


16

Obrázek 7: Získání adresy při bezstavové konfiguraci(NETWORKWORLD. 2007) DHCPv6 Typickým představitelem stavové konfigurace je DHCPv6. DHCP (Dynamic Host Configuration Protocol) umožňuje strojům automatickou konfiguraci všeho, co je potřeba pro plnohodnotné připojení uzlu do sítě. Součástí DHCPv6 jsou tři typy strojů: • Klient - Koncové zařízení, které se chce připojit do sítě. • Server - Spravuje a přiděluje požadovaná pravidla. • Zprostředkovatel - předává DHCP zprávy mezi klientem a serverem, pokud se nenacházejí na stejné podsíti. Na (IPv6.cz. 2009) je uveden postup DHCPv6 konfigurace následovně: 1. Objevování (discover) - klient pošle na skupinovou adresu všech DHCP agentů na lince (ff02::1:2) výzvu (router solicit), do níž zařadí své identifikační údaje. 2. Nabídka (offer) - servery, které jsou mu ochotny přidělit nějaké parametry (zpravidla bývá jediný, ale může jich být více) pošlou klientovi své nabídky zprávou, která se nazývá router advertisement. 3. Požadavek (request) - klient si vybere nabídku, jež se mu jeví jako nejvhodnější, na adresu všech DHCPv6 serverů pošle zprávu s DUID serveru, pro který je tato zpráva určena. 4. Potvrzení (acknowledge) - celý proces končí odesláním potvrzení, kterým server klientovi oznámí, že mu parametry skutečně přidělil. Celý postup získávání a přidělení adresy je znázorněn na obr. 8. Identifikace zařízení je u DHCPv6 velmi důležitá. U DHCPv4 se použivá ethernetová adresa, u DHCPv6 se zavádí pojem DUID (DHCP Unique Identifier). Je to jednoznačný identifikátor každého zařízení, které se účastní DHCP procesu. DUID by měl zůstat stejný i např. při výměně síťové karty počítače. DUID nemá definovanou standartní délku. Může mít 12-20 bytů. Server porovná DUID se údaji v databázi a doručí konfigurační data.

2.11

Přechodové mechanismy

17

Obrázek 8: Získání adresy při DHCPv6 (H3C Technologies. 2013)

2.11


Přechodové mechanismy slouží ke zpřístupnění IPv6 i IPv4 internetu zároveň. Pokud ISP nabízí IPv6 nativně, lze nakonfigurovat zařízení do režimu dvojího zásobníku. Pokud ale ISP IPv6 nenabízí vůbec, je nutné řešit tunelování. A to buď pomocí statického nebo automatického tunelu. Dvojí zásobník (dual stack) Zařízení, která pracují v režimu dvojího zásobníku, musí podporovat jak IPv4 tak i IPv6, zároveň musí mít i obě adresy, které získají běžným způsobem (ruční konfigurací nebo pomoci DHCP, respektive DHCPv6). Podporovat oba protokoly musí i DNS, vzájemná kooperace mezi oběma protokoly probíhá v aplikační vrstvě, daná aplikace si zde data, která přišla jedním protokolem vyzvedne, na základě svého nastavení upraví a upravená data odešle druhým protokolem příjemci. Princip fungování dvojího zásobníku je znázorněn na obr. 9. (NetworkComputing. 2012)

Obrázek 9: Princip fungování dvojího zásobníku, zdroj:autor

2.11


18

Tunelování O tunelování by se měl zajímat každý, kdo potřebuje IPv6 adresu nebo připojení, ale jeho ISP (poskytovatel internetu) nativně IPv6 nenabízí. Rozlišujeme dva typy tunelů, automatický a statický. Automatické tunely Princip tunelování je vcelku jednoduchý, IPv6 datagram se zapouzdří do IPv4 paketu, který je poté poslán ke směrovači zprostředkovatele tunelu, který má přístup do IPv6 sítě, a proto může IPv4 paket odstranit a dále, už po IPv6 síti, odeslat pouze IPv6 paket přímo k původnímu cili. Princip tunelování znázorňuje obr. 10.

Obrázek 10: Princip tunelování (Satrapa. 2011)

6over4 Mechanismus tunelování 6over4 (kompletní specifikace obsahuje RFC 2529), oficiálním názvem „Transmission of IPv6 over IPv4 Domains without Explicit Tunnels”, předpokládá, že zařízení sice podporuje IPv6, ale nachazí se pouze v IPv4 síti. Dané stroje musí podporovat jak IPv4 tak IPv6, protože balí své IPv6 datagramy do IPv4. Tyto datagramy poté posílají routeru, který podporuje 6over4, který potom tyto datagramy odesílá dál do IPv6 sítě. Princip fungování 6over4 tunelování zobrazuje obr. 2.11.

Obrázek 11: Princip 6over4 tunelování, zdroj:autor

6to4 Tunelování 6to4, oficiálním názvem „Connection of IPv6 Domains via IPv4 Clouds“, je automatický tunelovací mechanismus, který vychází z předpokladu, že existují dvě IPv6 sítě, které chceme vzájemně propojit, ale které jsou připojeny pouze do IPv4. Princip fungování zobrazuje obr. 14. Zapouzdření IPv6 paketu do IPv4 je vidět na obr. 12.

2.11


19

Obrázek 12: Zapouzdření 6to4 paketu, zdroj:autor Základním požadavkem je, aby síť měla veřejnou IPv4 adresu, která bude přidělena 6to4 routeru, který je připojen jak k IPv4 internetu tak ke koncové IPv6 síti. Z této veřejné IPv4 adresy se vytvoří 6to4 prefix, který má standartní délku 48 bitů a jehož prvních 16 bitů obsahuje 2002 a pro zbývajících 32 bitů se převede IPv4 adresa koncového směrovače do šestnáctkové soustavy, tak jak lze vidět na obr. 13.

Obrázek 13: Princip tvorby IPv6 adresy u 6to4 (MikroTik. 2011) Velkou výhodou 6to4 je jeho jednoduchost při nasazování. Naproti tomu velkou nevýhodou je spolehlivost, respektive nespolehlivost. 6to4 využívá zprostředkovatele provozované různými subjekty. Tento výběr nelze nijak ovlivnit, a proto nelze ani garantovat funkčnost. Dalším problémem je použití protokolu 41 (obecné tunelování), který bývá velmi často zakázán ve firewallech, proto není výjmkou dvojciferná nespolehlivost datových přenosů. Kompletní specifikace je uvedena v RFC 3056 Teredo Dalším z automatických tunelovacích mechanismů je Teredo, které zprostředkovává IPv6 komunikaci uzlům uprostřed IPv4 sítě. Jeho velkými výhodami je jednak jednoduchost při jeho nasazení a také fakt, že dokáže procházet NATem. Jeho nevýhodou je bohužel efektivita, kdy dochází k několikanásobnému nárůstu doby odezvy.

2.11


20

Obrázek 14: Schématické znázornění 6to4 tunelování se zapouzdřením 6to4 paketu Při první inicializaci posílá klient na server (jehož adresa je zpravidla nastavená automaticky) klasickou výzvu směrovači (router solicitation) zabalenou do UDP datagramu. Server klientovi posíla zpět ohlášení směrovače (router advertisement). Prvních 32 bitů prefixu sítě, který je obsažený v ohlášení směrovače, má vždy hodnotu 2001:0000, poté následuje IPv4 adresa serveru. Statické tunely Statické tunely, kam patří např. služby Hurricane Electric, Sixxs nebo Freenet6 fungují na podobném principu. Nejprve je potřeba se zaregistrovat na uvedených stránkách, kde uvedete základní údaje o svém připojení a daná služba vám vygeneruje tunel pro připojení k IPv6. Výhodou statických tunelů je fakt, že propojují dvě pevně dané adresy a mají tedy předvídatelné chování. Jejich nevýhodou je, že uživatel tunelu je plně závislý na jeho provozovateli. Freenet6 Jako jediný ze třech vyjmenovaných statických tunelů neposkytuje Freenet6 tunel server na území České republiky. Tudíž zde dochází, díky neoptimální topologii, ke zpoždění doby odezvy. Nejbližší tunel server se nachází v nizozemském Amsterdamu. Pro provoz tunelu je také nutné si stáhnout program gogoCLIENT, díky kterému se k tomuto tunelu připojíte. Sixxs Nabízí pro české zájemce o IPv6 tunel server v Praze, provozovaný společností Ignum. Velkou nevýhodou Sixxs je registrace a celková komunikace s uživatelem. Žádosti o vytvoření účtu, a následně i o registraci nového tunelu, podléhají ručnímu schvalování, proto je dobré vyplnit pečlivě všechny údaje. Vyždavováno je nejen jméno a email, ale také název organizace, adresa, telefon a důvod žádosti o vytvoření nového účtu, který musí mít minimálně 20 slov. Mně osobně se registrace tunelu podařila až na 3. pokus. Posuzování a schvalování naštěstí probíhá do několika hodin (i o víkendech), takže to není až taková překážka. V systému Sixxs se vše platí ve virtuální měně (ISK). Pro začátek dostane uživatel 25 ISK, např. za žádost o nový tunel uživatel zaplatí 10 ISK, za změnu adresy konce tunelu 15 ISK. ISK se dají i vydělávat, např. za radu ve fóru (www.sixxs.net/forum) dostanete 5 ISK, za každý týden co je tunel v provozu, dostanete dalších 5 ISK. Hurricane Electric Stejně jako Sixxs, i Hurricane Electric provozuje jeden ze svých tunel serverů na území České republiky. Hurricane Electrice poskytuje IPv6

2.12

Routing

21

tunel srovnatelné kvality se Sixxs, ale narozdíl od Sixxs zde není proces ručního schvalování účtu nebo samotného tunelu, celý proces registrace a zprovoznění tunelu je tedy mnohem plynulejší a uživatelsky přívětivější. V rámci jednoho účtu je možné si vytvořit až 5 tunelů, pro každý tunel Hurricane Electric nabízí ukázkovou konfiguraci pro většinu OS a síťových prvků (Windows 7. Windows 8, Windows XP, Cisco IOS, JunOS, Debian, Ubuntu,...).

2.12

Routing

Statický routing Statický routing na IPv6 funguje na podobném principu jako u IPv4, do routovací tabulky směrovače se staticky vloží IPv6 adresa s prefixem a next hop, případně exit interface. Použití statického routingu je vhodné zejména u jednoduchých neměnných sítí, případně na přístupových routerech každé síťě. Dynamický routing RIPng Router Information Protocol next generation, je další verzí směrovacího protokolu RIPv2, od které se liší hlavně v podpoře IPv6. RIPng se hodí spíše pro menší a jednoduché sítě. (Wikipedia. 2013) OSPFv3 Protokol Open Shortest Path First, ve 3. verzi, je link-state dynamický směrovací protokol, který funguje na principu, že všechny routery si uchovávají kompletní a vždy aktuální mapu sítě. Každá změna v topologii je okamžitě nahlášena všem směrovačům v celé síti. Pro určení nejkratší cesty používa Dijkstrův algoritmus. Hlavími výhodami je rychlá konvergence a jeho škálovatelnost k mnohem větším sítím.(McFarland. 2011) EIGRPv6 Enhanced Interior Gateway Routing Protocol, je distance vektorový, classless routovací protokol. Jedná se o proprietární protokol Cisca, funguje tedy pouze na Cisco směrovačích. Používá Diffusing update algoritmus (DUAL).(McFarland. 2011)

2.13

Domain Name System

BIND Podporu IPv6 v DNS řeší RFC 3596, z DNS serverů podporuje IPv6 například BIND (Berkeley Internet Name Domain), a to od verze 9. Pro dopředné dotazy (tedy zjištění adresy k danému jménu) již existujícícho zónového souboru stačí přidat řádek, který se od IPv4 liší pouze v použitém typu zdrojového záznamu. Misto jednoho ‚A‘ se zapisují hned čtyři ‚AAAA‘. Čtyři ‚A‘ byly zvoleny z důvodu, že IPv6

2.13

Domain Name System

22

adresa, je co se týče počtu použitých bitů, čtyřikrát větší než IPv4 adresa (IPv4 má 32 bitů a IPv6 128 bitů) (Satrapa. 2011). Ukázka IPv4 a IPv6 záznamu k doméně dobradomena.cz a poddoméně www.dobradomena.cz je popsána na (Lupa.cz. 2010): $ORIGIN dobradomena.cz. ; ... @ IN A 198.51.100.1 @ IN AAAA 2001:DB8:AB::1 www IN A 198.51.100.1 www IN AAAA 2001:DB8:AB::1 Přidáním těchto dvou řádků s AAAA záznamy a restartováním BINDu začnete oznamovat do světa, že váš webový server poskytuje služby i přes IPv6. Dobrým pravidlem je však ještě vytvoření reverzní zóny k IPv6 adresám, v určitých případech jako je poštovní server to je dokonce nezbytností pro jeho správnou funkcionalitu. Reverzní záznam k IPv4 adrese se dal poměrně bez problému zapsat z hlavy, u IPv6 to ale tak snadné nebude. Jednoduchý způsob, jak zjistit reverzní zápis pro IPv6, je použití příkazu ‚dig -x‘ nebo ‚sipcalc -r‘. $ dig -x 2001:DB8:AB::1 ... ;; QUESTION SECTION: ;1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.a.0.0.8.b.d.0.1.0.0.2.ip6.\\arpa. IN PTR $ sipcalc -r 2001:DB8:AB::1 ... Reverse DNS (ip6.arpa) 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.a.0.0.8.b.d.0.1.0.0.2.ip6.\\arpa. Předpokladem pro obsluhu této IPv6 adresy je to, že vám váš poskytovatel hostingu či ISP přidělil IPv6 blok a delegoval správu reverzních adres na vaše servery. Například pro síť 2001:DB8:AB::/48 byste obsluhovali reverzní zónu b.a.0.0.8.b.d.0.1.0.0.2.ip6.arpa. Ukázka definice reverzní zóny v ‚named.conf‘ pro přidělený prefix ‚2001:DB8:AB::/48‘: zone "b.a.0.0.8.b.d.0.1.0.0.2.ip6.arpa" in { type master; file "/etc/bind/master/b.a.0.0.8.b.d.0.1.0.0.2.ip6.arpa"; }; Odpovídající záznam v reverzní zóně pro IPv6 adresu 2001:DB8:AB::1

2.14

23

IP6tables

# cat /etc/bind/master/b.a.0.0.8.b.d.0.1.0.0.2.ip6.arpa $ORIGIN b.a.0.0.8.b.d.0.1.0.0.2.ip6.arpa. ; ... 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.a.0.0.8.b.d.0.1.0.0.2.ip6.\\arpa. IN PTR www.dobradomena.cz

2.14

IP6tables

Paketový filtr ip6tables je obdobou filtru iptables pracujícího na IPv4. Tabulka 3 zobrazuje volby pro použití iptables, které jsou ovšem platné i pro ip6tables. Tabulka 3: Volby použití ip6tables, (Wikipedia. 2013)

volba -A (append) -D (delete) -R (replace) -I (insert) -L (list) -F (flush) -N (new-chain) -X (delete-chain) -P (policy) -E (rename-chain)

2.15

význam Přidá na konec řetězce nové pravidlo Smaže pravidlo Nahradí pravidlo Vloží na začátek řetězce nové pravidlo Vypíše všechna pravidla v řetězci. Vyprázdní v řetězci všechna pravidla Vytvoření nového řetězce. Smaže vlastní řetězec Politika (policy) řetězce Přejmenování vlastního řetězce

Podpora IPv6 v operačních systémech

V dnešní době už všechny nejčastěji používané OS mají ve svém jádře implementovanou podporu IPv6, problém by mohl nastat u některých starších linuxových distribucí, ale i zde není získání IPv6 podpory žádným větším problémem. Podpora IPv6 v linoxových systémech Pro kontrolu, zda konkrétní počítač s linuxem podporuje IPv6 postačí tento jednoduchý test test -f /proc/net/if_inet6 && echo "Kernel podporuje IPv6" Pokud tento test selže, podporu IPv6 v jádře zapneme modprobe ipv6

2.16

24

Bezpěčnostní problémy IPv6

Dočasná konfigurace rozhraní linuxu provede

Dočasná konfigurace jednotlivých rozhraní se na

ip -6 addr add 2001:718:720::a dev eth0 Ověření konfigurace vypsaním rozhraní: ip -6 addr show Přidání výchozí brány: ip -6 route add default via 2001:718:720::1 Zobrazení směrovací tabulky: ip -6 route show Statická konfigurace rozhraní Statická (trvalá) konfigurace na linuxu se provádí v /etc/network/interfaces pro Debianovské systémy a nebo v /etc/sysconfig/network/scripts/ifcfg-eth0. Do tohoto souboru se přidá: auto eth0 iface eth0 inet6 static address 2001:718:720::a netmask 64 gateway 2001:718:720::1 Na linuxu se pouze změnily příkazy pro diagnostické nástroje, místo ping se používá ping6, traceroute je nahrazen traceroute6. Podpora IPv6 v OS Microsoft Windows Podpora IPv6 u OS Windows je mnohem lepší než u linoxvých systémů, Microsoft totiž přidal podporu IPv6 už do Service Packu 1 pro Windows XP, který byl vydán v roce 2002, ve svých serverových systémech poporuje IPv6 od verze Windows Server 2003. Nastavení statické konfigurace je k nalezení v Ovládací panely -> Síť a Internet> Síťová připojení. Zde vybereme připojení, které chceme konfigurovat, klikneme na Vlastnosti a zde vybereme položku Protokol IP verze 6.

2.16


Přestože má IPv6 řadu výhod a její nasazení je prakticky nevyhnutelné, jsou zde i určité neýhody a závažná bezpečnostní rizika.

2.16


25

Router Advertisement Flood Útok, který znežívá vlastnost automatické konfigurace DHCPv6, konkrétně konfigurace pomocí router advertisement paketů. Po stažení a nainstalování thc-toolkitu z www.thc.org/thc-ipv6/ stačí na libovolné linuxové distribuci zadat do terminálu flood_router6 eth0 a na multicastovou adresu ff02::1 (všechny IPv6 uzly v síti) se začne odesílat velké množství router advertisement paketů, v podstatě se tedy jedná o Denial of Services (DoS) útok, jehož důsledkem je zamrznutí či pád systémů Windows Vista/7/8, ale i Android nebo iOS. Linux jako jediný OS tento útok ustojí, z toho důvodu, že přijme pouze prvních 30 RA paketů. Tato zranitelnost je známá už asi 3 roky, ale všechny systémy (kromě linuxových) si s ní stále nedokáží poradit. Řešením je vypnout Router Discovery v příkazovém řádku Windows: netsh int ipv6 show int netsh int ipv6 set int "Local Area Connection" routerdiscovery=disabled netsh int ipv6 show int "Local Area Connection" Případně koupit switch od firmy Cisco s RA Guard (filtr blokující router advertisement pakety) nebo blokovat zbloudilé pakety pomocí firewallu a přijímat pouze ty, od potvrzených routerů (ppq.ch. 2012). Duplicate Address Detection V sítích, kde nově příchozí uzly získávájí svou konfiguraci pomocí bezstavové konfigurace může útočící uzel spustit DOS útok, který bude na každou DAD (Duplicate Address Detection) žádost odpovídat že požadovaná adresa je už používaná. Spustit tento DOS útok opět není problém, z výše uvedeného thc-toolkitu stačí na rootovské konzoli spustit dos-new-ipv6 eth0 V konečném důsledku tedy dochází k znemožnění komunikace na IPv6 (uzel má nakonfigurovanou výchozí bránu na IPv6, ale samotnou IPv6 adresu vůbec nepoužívá). Linux kolizi v používání duplicitní adresy úplně ignoruje a adresu používá dál. (Grégr. 2013) MitM (Man-in-the-middle) Tímto útokem je útočník schopen vnutit uzlům pomocí DHCPv6 falešnou adresu DNS serveru, který má útočník pod svou správou a kde jsou podvrženy A/AAAA záznamy pro webové stránky. Útočník na daném serveru může spustit transparentní proxy pro odposlech případně modifikaci stránek.

2.16


26

Obranou proti tomuto útoku je používat IPv6 Router Advertisement Guard, který zahazuje falešné RA zprávy. (Grégr. 2013) Bezpečnost tunelovacích mechanismů Určité bezpečnostní riziko může nastat i při použití tunelovacích mechanismů. Většina firewallů případně ACL (Acces Control List) není schopna monitorovat provoz uvnitř tunelu, takže firewall vidí např. IPv4 provoz směřující na UDP port 55000, který nemá důvod blokovat. Tento paket, který má v sobě zabalený IPv6 paket směřující např. na SMTP port, tedy pošle dál. Může zde tedy velmi snadno docházet k rozesílání spamu. (Grégr. 2013)

3

PRAKTICKÁ ČÁST

3 3.1

27

Praktická část Představení firmy

Bakalářská práce se zabývá přechodem síťové infrastruktury firmy Z-Ware na protokol IPv6. Firma Z-Ware se zabývá vývojem a instalací identifikačních, stravovacích a přístupových systémů. Firma vznikla v květnu 1989, zpočátku se její činnost věnovala vývoji programového vybavení (simulátory technologických procesů, trenažéry pro jaderné i konvenční elektrárny, univerzální grafický a databázový editor a jiné podobné projekty). Od roku 1996 se firma intenzivně zabývá identifikačními systémy. Nejprve se jednalo o systém pro strážní službu, později docházkové systémy, dále systémy pro automatizaci stravování (objednávky, výdej, bezobjednávkový systém), přístupové systémy a systémy k ovládání kopírek, výrobě čipů, atd. Tyto systémy jsou hlavní náplní firmy Z-Ware i v současnosti. Hlavní střediska firmy se nacházejí v Jihlavě a Brně. Další servisní místa jsou v Praze, Břeclavi, Lanškrouně a Ostravě. Nejdůležitější elektronické komponenty systému firma nejen vyvíjí, ale i vyrábí. (Z-Ware. 2006)

3.2

Topologie firemní sítě

Současný stav firemní síťe je vidět na obr. 15. Skládá se ze 2 poboček a dvou hostovaných serverů. Navrhovaný stav firemní sítě po nasazení IPv6 je vidět na obr. 16. Detaily a změny oproti původní topologii jsou diskutovány níže. Na jednom z výše zmíněných serverů, který je provozován firmou Master Internet, s.r.o., běží služba pro elektronické objednávání obědů iCanteen. Druhý server má ve své správě firma PIPNI s.r.o. a běží na něm webový server a server pro elektronickou poštu. Firemní pobočky se nacházejí v Brně a v Jihlavě. Brněnská pobočka Pobočka v Brně, která sídlí na adrese Řípská 20a, má celkem 15 stanic: • 2x Notebook HP Pavilion dv6000t - Intel Core 2 Duo, Windows XP, 1 GB DDR2, 100 GB HDD • 5x PC - Intel Core i3, Windows 7, 4 GB DDR2, 500 GB HDD • 5x PC - AMD Athlon 64 X2, Windows XP SP3, 2 GB DDR2, 160 GB HDD • 3x PC - Intel Core i5, Windows 8, 4 GB DDR3, 750 GB HDD Mezi síťové prvky v Brně patří: • Switch Zyxel ES-108A

3.3

Výběr vhodného tunelu

28

Obrázek 15: Současný stav firemní sítě • WiFi AP AirLive WL-8000AP • Linuxový router s OS Fedora 4 • FTP a databázový server s OS Fedora 7 Jihlavská pobočka Jihlavská pobočka se nachází na adrese Havlíčkova 44, dále v ní je: • Router Cisco 1841 • Switch Netgear GS108E Prosafe Plus • 2x PC - AMD Core 2 duo, Windows XP SP3, 2 GB DDR2, 160 GB HDD • 5x PC - Intel Core i3, Windows 7, 4 GB DDR2, 500 GB HDD

3.3


Způsob testování Jelikož pouze 3 ze 4 ISP konocových uzlů firmy poskytují IPv6 nativně, je nutné řešit tunelování. Pro testování byly použity 3 tunely, a to 6to4, Hurricane Electric a Sixxs. Tunelovací mechanismus 6to4 byl vybrán z důvodu jeho jednoduchého nasazení, i když

3.3


29

Obrázek 16: Navrhovaný stav topologie firemní sítě po nasazení IPv6 s možnou teoretickou nestabilitou tunelu. Hurricane Electric a Sixxs mají sice obtížnější nasazení a implementaci, ale jejich kvalita spojení by měla být na mnohem vyšší úrovni. Tyto teoretické předpoklady byly během testování potvrzeny. Pro výběr vhodného tunelu byl použit test pomocí pingu na IPv6 adresu Googlu – 2a00:1450:4008:c01::63, který byl spouštěn na routeru Mikrotik RB951-2n. Testovací topologie je vidět na obr. 17. Příkaz pro spuštění pingu měl tvar: /ping 2a00:1450:4008:c01::63 count=100 size=100 interval=0.1s interface= sit1

Obrázek 17: Topologie pro testování spolehlivosti jednotlivých tunelů Byl spouštěn tedy s intervalem 0.1s, velikost datagramu byla 100 bajtů, počet pingů v jednom testu byl 1000. Tento příkaz byl spouštěn ze skriptu pravidelně každých 25 minut po dobu 24 hodin. Začátek testování byl 3. 12. 2013 v 18:00, konec byl o 24 hodin později – 4. 12. 2013 v 18:00 hodin. Ze získaných dat byly pro lepší porovnání vytvořeny grafy ztrátovosti paketů a průměrné doby odezvy.

3.3


30

Skript pro test propustnosti jednotlivých tunelů: #!/bin/bash ssh [email protected] '/interface enable sit1' ssh [email protected] ':put "$[/system clock get time], $[/system clock get date]";/ping 2a00:1450:4008:c01::63 count=1000 size=100 interval=0.1s interface=sit1' >> 6to4.txt ssh [email protected] '/interface disable sit1' ssh [email protected] '/interface enable sit2' ssh [email protected] ':put "$[/system clock get time], $[/system clock get date]";/ping 2a00:1450:4008:c01::63 count=1000 size=100 interval=0.1s interface=sit2' >> sixxs.txt ssh [email protected] '/interface disable sit2' ssh [email protected] '/interface enable sit3' ssh [email protected] ':put "$[/system clock get time], $[/system clock get date]";/ping 2a00:1450:4008:c01::63 count=1000 size=100 interval=0.1s interface=sit3' >> he.txt ssh [email protected] '/interface disable sit3'

Tento skript byl spuštěn pomocí watch -n 1500 skript.sh 6to4 tunel Na obr. 18 lze vidět, že ztrátovost paketů se po většinu pracovní doby dne pohybuje vysoko nad 10%, klesá pouze po dobu nočních hodin. Doba odezvy se po celý den pohybuje okolo hodnoty 37 ms, opět pouze v nočních hodinách klesá na zhruba 32 ms. Pokud graf z obr. 18 porovnáme s grafem na obr. 19, zjistíme, že čas po který docházelo k nulové ztrátovosti paketů u 6to4 tunelu odpovídá menší datové vytíženosti peeringového centra nix.cz ze stejného dne. Hurricane electric tunel U tohoto tunelu je situace se spolehlivostí úplně jiná. Na obr. 20 lze vidět, že ztrátovost paketů je celý den 0 % a průměrná doba odezvy se pohybuje okolo 32 ms, což jsou relativně dobré hodnoty. Sixxs tunel Sixxs tunel je ve srovnání s tunelem Hurricane electric mírně kvalitnější – také 0 % ztrátovost paketů, průměrná doba odezvy byla 29 ms (oproti 32 ms u Hurricane

3.4

Vytvoření účtu a tunelu u tunnel brokera

31

Obrázek 18: Graf ztrátovosti paketů a průměrné doby odezvy u 6to4 tunelu

Obrázek 19: Graf datového toku peeringového centra nix.cz electric tunelu). Na obr. 21 lze vidět, že ztrátovost i průměrná doba odezvy je po celých 24 hodin prakticky stejná. Jaký tunel tedy vybrat? Pokud porovnáme všechny 3 testované tunely, zjistíme že 6to4 tunel je vzhledem ke své ztrátovosti paketů nepoužitelný, průměrná ztrátovost paketů po dobu testovaných 24 hodin byla 11 %. Uvažovat o nasazení by se proto dalo pouze u dvou Hurricane electric a Sixxs tunel. Oba tunely mají 0 % ztrátovost paketů a jejich průměrná doba odezvy se pohybuje okolo 30 ms (32 ms u Hurricane electric, oproti 29 ms u Sixxs). Mírně nižší doba odezvy je u Sixxs tunelu vykoupena relativně zdlouhavým a obtěžujícím postupem registrace. Pro přechod firmy k IPv6 jsem proto vybral Hurricane electric. Celkové porovnání všech testovaných tunelů je vidět v tabulce 4.

3.4

Vytvoření účtu a tunelu u tunnel brokera

Na adrese http://www.tunnelbroker.net/register.php si zaregistrujeme účet, který nám umožní vytvořit si až 5 tunelů. Po registraci a prvním příhlašení si vytvoříme

3.5

32

Konfigurace jihlavské pobočky

Obrázek 20: Graf ztrátovosti paketů a průměrné doby odezvy Hurricane electric tunelu Průměrná Průměrná Průměrná Průměrná

doba odezvy za 24 hodin [ms] doba odezvy (8-17 hodin) [ms] ztrátovost paketů za 24 hodin [%] ztrátovost paketů (8-17 hodin) [%]

6to4 35,46 36,5 11,05 13,95

Hurricane Electric Sixxs 31,79 29,07 31,80 29,04 0 0 0 0

Tabulka 4: Průměrné naměřené hodnoty u testovaných tunelů nový tunel kliknutím na odkaz Create Regular Tunnel v levém menu a dostaneme se do nabidky, kde zadáme svou současnou IPv4 adresu a vybereme si vhodný tunel server, pro české uživatele je nejvhodnější jediný tunel server umístěný v ČR, konkrétně v Praze, s adresou 216.66.86.122.

3.5


Konfigurace routeru Na přístupovém cisco routeru jihlavské pobočky nakonfigurujeme tunel následovně: configure terminal ipv6 unicast-routing interface Tunnel0 description Hurricane Electric IPv6 Tunnel Broker no ip address ipv6 enable ipv6 address 2001:470:6e:4a8::2/64 tunnel source 213.226.227.225 tunnel destination 216.66.86.122

3.5


33

Obrázek 21: Graf ztrátovosti paketů a průměrné doby odezvy u Sixxs tunelu tunnel mode ipv6ip ipv6 route ::/0 Tunnel0 end write

Těmito příkazy vytvoříme nové rozhraní Tunnel0, přiřadíme mu IPv6 adresu 2001:470:6e:4a8::2/64, zdrojovou a cílovou adresu. Nakonec nastavíme statické routování a celou konfiguraci uložíme. Konfiguraci vnitřního rozhraní provedeme následovně: configure terminal ipv6 unicast-routing interface GigabitEthernet0/0 ipv6 address 2001:470:6e:4a8::3/64 no shutdown

Konfigurace DHCPv6 configure terminal ipv6 dhcp pool dhcpv6 ipv6 address prefix 2001:470:6e:4a8::3/64 dns-server 2001:718:720::a domain-name z-ware.cz

Vytvořili jsme si nový dhcpv6 pool a pojmenovali jsme ho dhcpv6. interface Gi0/0 ipv6 nd managed-config-flag ipv6 dhcp server dhcpv6

3.6

Konfigurace brněnské pobočky

34

Zde jsme vytvořený pool dhcpv6 přiřadili k rozhraní GigabitEthernet 0/0. Nastavení klientů Klienty nastavíme podle obr. 22.

Obrázek 22: Nastavení automatického adresování na OS Windows A pro získání adresy z dhcpv6 serveru napíšeme do příkazové řádky: ipconfig /release 6 ipconfig /renew 6

3.6


Z důvodu plánovaného růstu a s tím spojených vyšším nárokům na výkon plánuje firma nákup nového routeru, nejspíše od firmy Cisco. Doporučil bych Proto bude následná konfigurace uvedena už pro plánovaný nový router. Poskytovatel internetového připojení pro brněnskou pobočku, firma Netbox, nabizí pro své zákazníky IPv6 nativně, takže odpadá nutnost řešit připojení pomocí tunelu. Hlavní Router Konfigurace vnějšího rozhraní: configure terminal ipv6 unicast-routing

3.6


35

interface GigabitEthernet 0/1 ipv6 address 2001:718:721::2e52/128 no shutdown

Konfigurace vntiřního rozhraní: configure terminal ipv6 unicast-routing interface GigabitEthernet 0/0 ipv6 address 2001:718:720::1/64 no shutdown

Těmito příkazy nastavíme na routeru DHCPv6: configure terminal ipv6 dhcp pool dhcpv6 ipv6 address prefix 2001:470:6e:4a8::3/64

Konfigurace serveru Na serveru brněnské pobočky běží ftp, mysql a také ssh daemon pro vzdálenou konfiguraci. Na tomto serveru je nainstalován OS Fedora, ve verzi 7. Konfigurace síťového rozhraní Protože se jedná o server, je vhodné nakonfigurovat ho staticky, tak aby se jeho adresace neměnila. Nejprve se přesvědčíme, zda je na tomto serveru ipv6 zapnuta. Pod uživatelem root otevřeme soubor /etc/sysconfig/network a přesvědčíme se, zda je zde uveden řádek NETWORKING_IPV6=yes

Pokud ne, do tohoto souboru ho připíšeme. Jako další otevřeme opět pod uživatelem root soubor /etc/sysconfig/network-scripts/ifcfg-eth0 a připíšeme do něj tyto řádky: IPV6INIT=yes IPV6ADDR=2001:718:720::a IPV6_DEFAULTGW=2001:718:720::1 ONBOOT=YES

Rozhraní zrestartujeme service network restart

a vyzkoušíme jeho funkčnost pomocí pingu: ping6 www.google.com

3.6


36

Ip6tables na serveru Konfiguraci ip6tables najdeme v souboru etc/sysconfig/ip6tables Povolení FTP, ICMPv6,SSH a MySQL: ip6tables -A INPUT -p icmpv6 -j ACCEPT ip6tables -A OUTPUT -p icmpv6 -j ACCEPT ip6tables -A FORWARD -p icmpv6 -j ACCEPT ip6tables -A INPUT -i eth0 -p tcp --dport 21 -j ACCEPT ip6tables -A OUTPUT -i eth0 -p tcp --dport 21 -j ACCEPT ip6tables -A FORWARD -i eth0 -p tcp --dport 21 -j ACCEPT ip6tables -A INPUT -i eth0 -p tcp --dport 20 -j ACCEPT ip6tables -A OUTPUT -i eth0 -p tcp --dport 20 -j ACCEPT ip6tables -A FORWARD -i eth0 -p tcp --dport 20 -j ACCEPT ip6tables -A INPUT -i eth0 -p tcp --dport 3306 -j ACCEPT ip6tables -A OUTPUT -i eth0 -p tcp --dport 3306 -j ACCEPT ip6tables -A FORWARD -i eth0 -p tcp --dport 3306 -j ACCEPT ip6tables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT ip6tables -A OUTPUT -i eth0 -p tcp --dport 22 -j ACCEPT ip6tables -A FORWARD -i eth0 -p tcp --dport 22 -j ACCEPT

Povolení paketů patřících do již existujícícho spojení (ESTABLISHED) a pakety navazující nové spojení v rámci již běžící komunikace (RELATED): ip6tables -A INPUT -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT ip6tables -A INPUT -p udp -m state --state ESTABLISHED,RELATED -j ACCEPT

Nastavení default politiky zahodit všechny pakety, kromě odchozích. ip6tables -P INPUT DROP ip6tables -P OUTPUT ACCEPT ip6tables -P FORWARD DROP

Konfigurace DNS Na serveru v brněnské pobočce je zprovozněn DNS server BIND9, jeho konfigurační soubor se nachází v /etc/named.conf. $TTL 86400 ; 1 day z-ware.cz IN SOA dns.z-ware.cz. ( 2009040700 ; serial 10800 ; refresh (3 hours) 900 ; retry (15 minutes) 604800 ; expire (1 week) 86400 ; minimum (1 day) ) NS dns.z-ware.cz. ; z-ware.cz AAAA 2001:718:720::a

3.7

Konfigurace serveru se službou iCanteen

37

Konfigurace reverzního zónového souboru Reverzní zónový soubor slouží ke zjištění IPv6 adresy ze zadaného doménového jména. $TTL 86400 $ORIGIN 0.2.7.0.8.1.7.0.1.0.0.2.ip6.arpa. @ IN SOA dns.z-ware.cz ( 2008121200 ;serial 3H ;refresh 15M ;retry 1W ;expire 1D ;negative cache TTL ) @ IN NS dns.z-ware.cz.

3.7

Konfigurace serveru se službou iCanteen

Konfigurace síťového rozhraní Tak jako v v sekci věnované konfiguraci serveru v brněnské pobočce, tak i zde bude server konfigurován staticky. Toto nastavení se nebude od výše zmíněné konfigurace moc lišit, jediný rozdíl bude v nastavení rozhraní a ip6tables. Opět tedy otevřeme pod uživatelem root soubor /etc/sysconfig/networkscripts/ifcfg-eth0 a připíšeme do něj tyto řádky: IPV6INIT=yes IPV6ADDR=2001:718:732:6e::3b5 IPV6_DEFAULTGW=2001:718:732:6e::1 ONBOOT=YES

Rozhraní opět zrestartujeme service network restart


Konfigurace ip6tables Na tomto serveru bude povolen pouze provoz icmpv6 paketů pro testování funkčnosti připojení a dále služba iCanteen běžící na portu tcp/3306. ip6tables -A INPUT -p icmpv6 -j ACCEPT ip6tables -A OUTPUT -p icmpv6 -j ACCEPT ip6tables -A FORWARD -p icmpv6 -j ACCEPT ip6tables -A INPUT -i eth0 -p tcp --dport 3306 -j ACCEPT ip6tables -A OUTPUT -i eth0 -p tcp --dport 3306 -j ACCEPT ip6tables -A FORWARD -i eth0 -p tcp --dport 3306 -j ACCEPT

3.8

Konfigurace webového a emailového serveru

38



3.8


Konfigurace síťového rozhraní Tak jako v předchozích případech, tak i zde bude server konfigurován staticky. Opět tedy otevřeme pod uživatelem root soubor /etc/sysconfig/network-scripts/ifcfg-eth0 a připíšeme do něj tyto řádky: IPV6INIT=yes IPV6ADDR=2001:718:732:6c::3a5 IPV6_DEFAULTGW=2001:718:732:6c::1 ONBOOT=YES

Rozhraní opět zrestartujeme service network restart


Konfigurace ip6tables Na tomto serveru běží daemon pro web a elektronickou poštu, budou proto povoleny porty 80/tcp (http), 443/tcp (https), dále 25/tcp (SMTP), 110/tcp (POP3) a 143/tcp (IMAP). ip6tables -A INPUT -p icmpv6 -j ACCEPT ip6tables -A OUTPUT -p icmpv6 -j ACCEPT ip6tables -A FORWARD -p icmpv6 -j ACCEPT ip6tables -A INPUT -i eth0 -p tcp --dport 80 -j ACCEPT ip6tables -A OUTPUT -i eth0 -p tcp --dport 80 -j ACCEPT ip6tables -A FORWARD -i eth0 -p tcp --dport 80 -j ACCEPT ip6tables -A INPUT -i eth0 -p tcp --dport 443 -j ACCEPT ip6tables -A OUTPUT -i eth0 -p tcp --dport 443 -j ACCEPT ip6tables -A FORWARD -i eth0 -p tcp --dport 443 -j ACCEPT ip6tables -A INPUT -i eth0 -p tcp --dport 25 -j ACCEPT ip6tables -A OUTPUT -i eth0 -p tcp --dport 25 -j ACCEPT

3.8


39

ip6tables -A FORWARD -i eth0 -p tcp --dport 25 -j ACCEPT ip6tables -A INPUT -i eth0 -p tcp --dport 110 -j ACCEPT ip6tables -A OUTPUT -i eth0 -p tcp --dport 110 -j ACCEPT ip6tables -A FORWARD -i eth0 -p tcp --dport 110 -j ACCEPT ip6tables -A INPUT -i eth0 -p tcp --dport 143 -j ACCEPT ip6tables -A OUTPUT -i eth0 -p tcp --dport 143 -j ACCEPT ip6tables -A FORWARD -i eth0 -p tcp --dport 143 -j ACCEPT



4

40

FINANČNÍ ZHODNOCENÍ

4

Finanční zhodnocení

Přechod k IPv6 není v ideálním případě (všechny síťové prvky a operační systémy IPv6 podporují) nijak nákladnou záležitostí, v podstatě se platí pouze práce technika, který přenastaví všechny prvky a uzly. V případě přechodu firmy Z-Ware je i vzhledem k plánovanému rozšiřování brněnské pobočky nutno dokoupit i nový router a bezdrátový access point, což je investice zhruba 19 000 Kč za router a 500 Kč za AP. Samotný přechod k IPv6 by síťovému technikovi zabral asi 10 hodin práce pro obě pobočky. Pokud si tento technik naúčtuje za každou hodinu 500 Kč, tak to je dohromady 5000 Kč. Přenastavení zbylých 2 serverů by měly na starosti firmy, u kterých jsou tyto servery v pronájmu. Cena za tento přechod by byla nulová, je už obsažena v ceně měsíčního paušálu za pronájem serveru. Samotné zavedení IPv6 do firemní sítě neni nijak nákladnou záležitostí, v našem případě by činilo asi 5000 Kč. Náklady začínají stoupat, pokud je nutnost dokoupit i nějaký síťový prvek, tak jako v našem případě. Celková cena za přechod k IPv6 by byla asi 25 000 Kč. Finanční zhodnocení zobrazuje i tabulka 4. Důvod platby Router Cisco 2811 TP-LINK TL-WR741ND Práce technika za 10 hodin, při sazbě 500Kč/hodina Celkové náklady Tabulka 5: Celkové finanční zhodnocení

Částka 18 789 Kč 494 Kč 5 000 Kč 24 283 Kč

5

5

DISKUSE

41

Diskuse

V současné době nemá firma Z-Ware moc důvodů přecházet k IPv6, současná infrastruktura funguje tak, jak má a přechod k IPv6 by v současnosti firmě způsobil pouze více problémů než užitku. Na druhou stranu firma Z-Ware plánuje rozšiřování brněnské pobočky a při této příležitosti i nákup nového routeru, tudíž by bylo vhodné konfiguraci nového routeru spojit s přechodem k IPv6. Tento přechod je do budoucna stejně nevyhnutelný a je proto lepší být připraven.

6

6

ZÁVĚR

42

Závěr

Nový internetový protokol verze 6 je do budoucna jediným způsobem, jak vyřešit problém s nedostatkem IPv4 adres. Přestože má IPv6 řadu výhod (především takřka nevyčerpatelný adresní prostor), existují zde i rizika (především bezpečnostní), která není dobré podceňovat. Jeho nasazení ale zatím brání zdrženlivost poskytovatelů připojení, kteří se nehrnou do něčeho, co jim nepřinese rychlé zisky. Jediným způsobem pro většinu uživatelů tak zatím stále zůstává řešit svoje připojení k IPv6 internetu pomocí tunelování. Tunelovací mechanismy mají relativně dobrou kvalitu připojení, proto není nutné čekat s nasazením IPv6 do své sítě na našeho poskytovatele připojení. Hlavním cílem práce bylo navrhnout připojení firmy Z-Ware k IPv6, a to včetně nastavení serverů, klientských počítačů, automatické konfigurace a DNS. Podle laboratorního testování se tento cíl podařilo splnit. Při tvorbě bakalářské práce mě překvapila bezpečnostní rizika, která jsou pomocí IPv6 snadno zneužitelná a vedou k zamezení komunikace na IPv6, případně k odchytu IPv6 komunikace.

7

7

REFERENCE

43

Reference Brown, S. Configuring IPv6 For Cisco IOS.. Rockland: Syngress Media, 2002. ISBN 19-289-9484-9. Satrapa, P. IPv6: internetový protokol verze 6. 3., aktualiz. a dopl. vyd.. Praha: CZ.NIC, 2011. 407 s. ISBN 978-80-904248-4-5. Cricket, L. DNS and Bind on IPv6. Sebastopol. Sebastopol: O’Reilly Media, Inc., 2011. 37 s. ISBN 14-493-0519-9. Graziani, R. IPv6 Fundamentals: A Straightforward Approach to Understanding IPv6. Cisco Press, 2013. 702 s. ISBN 978-1-58714-313-7. McFarland, S. IPv6 for Enterprise Networks. Sebastopol: Cisco Press, 2011. 398 s. ISBN 978-1-58714-227-7. Wikipedia. IPv6[online]. 2011 [cit. 2013-12-10]. Dostupné z: . Satrapa, P. Kde vzít IPv6 tunel[online]. 2011[cit. 2013-12-10]. Dostupné z: . Grégr, M. IPv6 Mýty a skutečnost, díl IV. - Podpora autokonfigurace[online]. 2011 [cit. 2013-12-10]. Dostupné z: . Nix Graft. Red Hat / CentOS IPv6 Network Configuration[online]. 2011 [cit. 2013-12-9]. Dostupné z: . NetFilter. IP6TABLES[online]. 2011 [cit. 2013-12-12]. Dostupné z: . Grégr, M. IPv6 Mýty a skutečnost, díl V. - Zjednodušené hlavičky[online]. 2011 Dostupné z: . Zytrax.com. Tech Stuff - Ipv6[online]. 2013 [cit. 2013-12-7]. Dostupné z: .

7

REFERENCE

44

Cisco Systems. Overview of IPv6. Cisco[online]. 2012 [cit. 2013-11-25]. Dostupné z: . IPv6.cz. IPv6 Mýty a skutečnost, díl IV. - Podpora autokonfigurace[online]. 2009 [cit. 2013-12-6]. Dostupné z: . MikroTik. Setting up an IPv6 tunnel via 6to4[online]. 2011 [cit. 2013-11-20]. Dostupné z: . Surý, O. Pohněme s IPv6: nakonfigurujte si Apache a BIND[online]. 2010 [cit. 2013-11-20]. Dostupné z: . IPv6.cz. DHCPv6[online]. 2009 [cit. 2013-11-24]. Dostupné z: . Wikipedia. ICMPv6[online]. 2013 [cit. 2013-11-28]. Dostupné z: . IPv6.cz. Objevování sousedů[online]. 2009 [cit. 2013-12-4]. Dostupné z: . PPQ.CH. IPV6 ROUTER ADVERTISEMENT FLOOD[online]. 2012 [cit. 2013-12-5] Dostupné z: . NetworkComputing. Deploying Dual-Stack IPv4 and IPv6 Networks[online]. 2012 [cit. 2013-12-5] Dostupné z: . Odom, W. Stateless Autoconfiguration and Router Advertisements[online]. 2007 [cit. 2013-12-7] Dostupné z: . Sixxs. IPv6 Deployment Tunnel Broker[online]. 2013 [cit. 2013-12-7]. Dostupné z: .

7

REFERENCE

45

Hurricane Electric. Hurricane Electric Free IPv6 Tunnel Broker[online]. 2013 [cit. 2013-12-7]. Dostupné z: . FREENET6. gogo6, IPv6 products, community and services[online]. 2013 [cit. 2013-12-10]. Dostupné z: <www.gogo6.com/freenet6>. Wikipedia. Neighbor Discovery Protocol[online]. 2013 [cit. 2013-12-10]. Dostupné z: . Wikipedia. Iptables[online]. 2013 [cit. 2013-13-10]. Dostupné z: . Grégr, Matěj. (Ne)bojíme se IPv6.2013 [cit. 2013-13-10]. . Z-Ware. Z-WARE – identifikační systémy docházkové, stravovací, přístupové[online]. 2006 [cit. 2013-12-13]. Dostupné z: . Wikipedia. Routing Information Protocol[online]. 2013 [cit. 2013-12-17]. Dostupné z: . H3C Technologies. DHCPv6 overview[online]. 2013 [cit. 2013-12-17]. Dostupné z: . Emanuel, P. Adresy v internetovém protokolu verze 6 (I)[online]. 2013 [cit. 2013-12-19]. Dostupné z: . IPv6.cz. Individuální adresy (unicast)[online]. 2012sr [cit. 2013-12-19]. Dostupné z: . IPv6.cz. Identifikátor rozhraní [online]. 2009 [cit. 2013-12-19]. Dostupné z: .

Přílohy

Návrh integrace protokolu IPv6 ve firmě Z-Ware

Recommend Documents