MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
Distribuovaný IPv6 tunnel broker Bakalářská práce Jan Bortl Brno, podzim 2010
Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval(a) samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal(a) nebo z nich čerpal(a), v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Jan Bortl
i
Poděkování Děkuji vedoucímu své bakalářské práce, RNDr. Davidu Antošovi, Ph.D., za jeho péči, trpělivost a cenné rady.
ii
Zadání Seznamte se s mechanismy pro tunelování protokolu IPv6 sítěmi, které podporují pouze IPv4. Jednou z hlavních nevýhod používaných tunelů je jejich závislost na jediném zakončení tunelu na straně serveru, která přináší jedno místo kritické pro činnost systému. Navrhněte a implementujte distribuovaný tunnel broker pro přístup do IPv6 sítě jako systém propojených distribuovaných PoP (Point of Presence), umožňující klientům přístup do IPv6 sítě přes IPv4 síť. Tunnel broker bude podporovat správu a evidenci uživatelů. Dále bude podporovat přidělování fixních IPv6 adres (resp. adresních bloků) klientům nezávisle na jejich IPv4 adresách a případné mobilitě. Systém bude podporovat jak přístup z koncových stanic, tak i z hraničních směrovačů. Systém má být robustní v tom smyslu, že umožňuje klientům detekovat nedostupnost aktuálního PoP a přesměruje klienta na jiný funkční PoP. Přitom musí zachovat přidělené IPv6 adresy. Specifikujte třídu výpadků, které vytvořený systém dokáže úspěšně zvládnout. Alespoň na jedné platformě klienta implementujte tuto funkcionalitu tak, aby nevyžadovala zásah uživatele (tj. detekce výpadku PoP a přesměrování provozu proběhlo automaticky). Výstupem práce je open source implementace distribuovaného tunnel brokeru pro přístup do IPv6 sítě s webovým rozhraním pro konfiguraci klientem. Implementace bude vhodným způsobem uživatelsky dokumentována. Součástí práce bude textová část popisující architektu a implementaci systému v souladu s výše uvedenými požadavky.
Základní literatura: S. Hagen, „Ipv6 Essentials“, O'Reilly Media, Inc., ISBN 978-0596100582, 2006.
iii
Shrnutí Protokol IPv6 je nástupcem v současnosti používaného protokolu pro přenos informací IPv4. Tato práce navrhuje systém pro snadné tunelovaní IPv6 provozu přes stávající IPv4 síť. V teoretické části se zaměřuje na možnosti využití různých tunelovacích technik a navrhuje webový systém pro jejich správu. Zároveň je zde řešen problém zachování uživatelské IPv6 adresy napříč systémem. V praktické části je vysvětlena implementace takového systému, včetně ukázky praktického využití. Systém je implementován formou databáze s webovým portálem, prostředky pro provoz tunelovacích serverů a systémem pro automatické sestavení tunelu na straně uživatele.
Klíčová slova IPv6, Tunnel broker, SIT tunel, OpenVPN, Teredo, 6to4, 6in4, OSPF, BGP
iv
Obsah 1 2 3
4
5
6 7 8
Úvod............................................................................................................................1 Současné možnosti připojení k IPv6...........................................................................3 2.1 Teredo....................................................................................................................4 2.2 SIT (Simple Internet Transition) 6in4 a 6to4........................................................6 Návrh architektury.......................................................................................................8 3.1 Základní požadavky na Tunnel Broker.................................................................8 3.2 Komponenty..........................................................................................................9 3.2.1 Ovládací rozhraní.........................................................................................9 3.2.2 PoP – Point of Presence..............................................................................10 3.2.3 Klient..........................................................................................................10 3.3 Automatická konfigurace tunelu.........................................................................10 3.4 Ruční konfigurace...............................................................................................11 3.5 Návrh způsobu uložení dat..................................................................................11 3.5.1 DFD diagram (Data Flow Diagram)..........................................................12 Popis implementace...................................................................................................14 4.1 Ovládací rozhraní................................................................................................14 4.2 Frontend..............................................................................................................14 4.3 Backend...............................................................................................................15 4.4 Databáze..............................................................................................................16 4.5 PoP......................................................................................................................16 4.6 Klient...................................................................................................................18 4.6.1 Automatická konfigurace tunelu................................................................18 4.6.2 Ruční režim................................................................................................19 4.7 OpenVPN............................................................................................................20 Popis interního chodu aplikace..................................................................................21 5.1 Reakce na výpadek.............................................................................................21 5.1.1 Výpadek PoP .............................................................................................21 5.1.2 Výpadek ovládacího rozhraní.....................................................................21 5.1.3 Výpadek propojení mezi PoP.....................................................................21 5.1.4 Výpadek propojení do jiných sítí (Internet)...............................................22 5.1.5 Chybná implementace Tunnel Brokeru a tím způsobené poruchy.............22 5.1.6 Změna IPv4 adresy klienta.........................................................................22 5.2 Způsob změny směrování...................................................................................22 Závěr..........................................................................................................................24 Použitá literatura........................................................................................................25 Příloha: Uživatelská dokumentace............................................................................26 8.1 Registrace............................................................................................................26 8.2 Automatická konfigurace tunelu.........................................................................27 8.3 Ruční konfigurace...............................................................................................28
v
1 Úvod V současné době je Internet využíván stále častěji a v některých odvětvích je již nenahraditelný. Majoritním komunikačním protokolem je protokol IPv4 (Internet Protokol verze 4), který byl ovšem navržen v sedmdesátých letech minulého století. Jeho adresní rozsah se nezadržitelně plní a brzy je předpovídáno jeho vyčerpání. Proto je od začátku 90. let vyvíjen protokol IPv6 (Internet Protokol verze 6), který se většinu neduhů IPv4 snaží řešit. Nejdůležitější změnou je právě značné prodloužení adresy z 32bitů na 128bitů. Oba protokoly jsou ovšem navzájem nekompatibilní, byť jsou si v některých ohledech velmi podobné. V dnešní době brání rozšířenosti IPv6 špatná dostupnost tohoto protokolu pro koncové uživatele v domácnostech a kancelářích. Účelem tunnel brokerů je překonávat tento nedostatek a poskytnout plnohodnotnou IPv6 konektivitu pro běžného domácího uživatele, kancelář, případně malou podnikovou síť. Tunnel broker zajišťuje IPv6 konektivitu pro uživatele, který má k dispozici pouze IPv4 síť. Tuto činnost provádí tím, že sestaví IPv6 tunel k takovémuto uživateli a zprostředkuje takto téměř plnohodnotnou IPv6 konektivitu. Každý takový tunel broker má k dispozici pevný globální IPv6 rozsah, který poskytuje svým uživatelům. Běžný tunnel broker se skládá pouze z jednoho přístupového bodu PoP (Point of Presence). PoP je většinou nějaký server umístěný na rychlé páteřní lince s přístupem jak do IPv6, tak do IPv4 sítě. Což znamená, že umí plnohodnotně komunikovat jak na IPv4 tak na IPv6 síti (mluvíme zde o dualstack principu). U takovéto konfigurace tunnel brokeru však může dojít k tomu, že při výpadku tohoto prvku uživatel ztrácí přístup do sítě IPv6. Tedy běžný tunnel broker nijak neřeší dostupnost služby. Neřeší zejména přenositelnost svého přiděleného IPv6 rozsahu na jiný PoP. Jedná se tedy o problém kritického místa (Single Point of Failure). To znamená, že uživatel nemá možnost při
1
výpadku tohoto prvku se připojit jiným způsobem se zachováním jeho původní IPv6 adresy – je odříznut od IPv6 světa. Účelem této práce je odstranění tohoto nedostatku a to přidáním více přístupových bodů, které budou schopny obsloužit uživatele se zachováním jejich IPv6 adresy, a tím přinést o řád kvalitnější přístup do sítě IPv6, než je tomu pomocí běžného tunnel brokeru. Distribuovaný tunnel broker je síť vzájemné propojených PoP. Účelem takovéhoto PoP je umožnit na IPv4 infrastruktuře poskytovat IPv6 konektivitu pro uživatele, kteří nemají k dispozici nativní IPv6, nemají ji k dispozici stále nebo jsou mobilní ve smyslu časté změny IPv4 adresy, případně i změny fyzické lokace. IPv6 sice obsahuje podporu pro mobilní uživatele, ale vyžaduje k tomu právě nativní IPv6 infrastrukturu a netriviální nastavení směrovačů.
2
2 Současné možnosti připojení k IPv6 V dnešní době je situace s připojením na IPv6 v následujícím technickém stavu. K připojení do globální sítě IPv6 můžeme použít tyto možnosti: •
nativní metoda,
•
transparentní přechodový systém,
•
tunelovaná metoda. Nativní metoda je pro chod IPv6 nejsnadnější a nejrozumnější,
uživatelsky většinou není potřeba nic konfigurovat díky Autokonfiguraci 1 a DHCP2. Nativní metoda koexistuje vedle stávajícího protokolu IPv4 plně nezávisle, v podstatě jsou si IPv6 a IPv4 v tomto ohledu rovné. Pro tuto metodu je ovšem, jak již vyplývá z principu, nutná přímá účast správce sítě, případně nadřazeného (upstream) poskytovatele. Správce musí poskytnout a nakonfigurovat příslušné aktivní prvky po celé trase od uživatele až k již nakonfigurované páteřní IPv6 infrastruktuře (globální Internet). Toto se ovšem neobejde bez aktivních prvků, které IPv6 podporují. Zejména se jedná o směrovače. Většina v současnosti dostupných směrovačů již IPv6 bez větších problémů podporuje. Avšak starší zařízení nepodporují IPv6 vůbec, anebo je nutná výměna řídícího software uvnitř těchto prvků. IPv6 se proto nasazuje až po morální výměně těchto prvků, dříve to mnohdy není z ekonomických důvodů proveditelné. Například k dnešnímu dni (prosinec 2010), se v ČR neprodává domácí ethernetový směrovač, který by podporoval protokol IPv6. Nějaké náznaky zde sice existují, ale nemůžeme zde hovořit o plné podpoře IPv6. Transparentní
přechodové
systémy
jsou
jen
jakousi
dočasnou
náhražkou. Ty provádí transparentní překlad celých protokolů z IPv4 do IPv6, 1 Autokonfigurace je automatický proces přidělení IPv6 adresy podobný DHCP, neřeší však doplňkové informace (DNS servery). 2 DHCP (Dynamic Host Configuration Protocol) – automatické přidělení IP adresy včetně doplňkových informací.
3
respektive naopak. Tento způsob osobně považuji pouze za jakousi formu dočasného řešení přechodu na IPv6. Předpokladem úspěšného přechodu na IPv6 je koexistence obou protokolů na koncových stanicích globálního Internetu do doby, než IPv4 de facto zanikne. Tunelovací metoda oproti tomu většinou nevyžaduje zásah správce sítě (poskytovatele) jako u nativní metody. Vznikají zde ovšem problémy s komunikací blízkých uzlů. Většinou jsou v konečném důsledku nuceny použít mnohdy velmi vzdáleného tunel serveru, protože žádný bližší není k dispozici. Mezi další nevýhody patří velké vložené zpoždění k nejbližšímu tunelovacímu serveru. Následně popíši několik tunelovacích metod, které jsou pro účel této práce zajímavé nebo v současnosti ve velké míře používané.
4
2.1 Teredo
Ilustrace 1: Příklad sítě Teredo. Tunelovací
mechanismus
vyvinutý
firmou
Microsoft.
Je
navržen
za účelem připojení zařízení ukrytých za IPv4 NAT 3 k síti IPv6. Ke komunikaci, respektive k tunelování, používá IPv4 UDP pakety. Teredo síť se skládá z těchto hlavních prvků: •
Teredo klient – Zařízení, užívající Teredo protokol ke komunikaci po IPv6 (= začátek Teredo tunelu). Zařízení může být ukryté za IPv4 NAT.
3 NAT – Network Address Translator – překlad sítových adres, užívá se většinou ke skrytí privátní sítě za jednu nebo více IP adres veřejné sítě
5
•
Teredo
server
–
Zařízení
vně
NAT.
Používá
se
pouze
k
rozpoznávání typu NAT, nesměruje žádná uživatelská data. Předává klientovi informaci o nejbližší Teredo relay. •
Teredo relay – Slouží jako konec Teredo tunelu. Směruje data mezi IPv6 sítí pro Teredo klienty.
Teredo klient má pevně definovanou IPv6 adresu, v níž je zakódována IP adresa Teredo relay, IP adresa NAT a další informace – viz tabulka popisující strukturu IPv6 adresy: •
Bity 0 až 31 jsou Teredo prefix (užívá se 2001::/32).
•
Bity 32 až 63 jsou IPv4 adresa používaného Teredo serveru.
•
Bity 64 až 79 jsou různé značky.
•
Bity 80 až 95 obsahují zakódované číslo portu UDP.
•
Bity 96 až 127 obsahují zakódovanou IPv4 adresu vnější strany NAT.
Díky analýze komunikace NAT, která se provádí při získávání IPv6 adresy, dokáže dokáže Teredo klient rozpoznat chování tohoto překladu a následně jej překonávat s co nejvyšší efektivitou. Tato analýza probíhá ve spolupráci s Teredo serverem. V počáteční fázi Teredo klient zjišťuje, zdali je NAT průchozí pouze v rámci již sestavených UDP spojení, anebo se lze dostat zvnějšku dovnitř obousměrně i z jiné IP adresy - což se může stát, pokud se jedná o Cone NAT, tedy vnější IPv4 adresa (UDP porty) je mapována na vnitřní IPv4 adresu. Když zde hovořím o UDP spojení, nemyslím tím nějaký konkrétní stav datového rámce, protokol UDP je bez spojový. Neobsahuje žádnou informaci, jestli se jedná o nové čí stávající spojení. NAT vetšinou obsahuje zároveň i Stateful firewall, což je analyzátor průchozích rámců. Na základě analýzy rámců lze rozhodnout, jestli je příchozí UDP rámec součást existující komunikace, anebo nikoliv a na základě této informace jej vpustit přes NAT.
6
IPv6 adresa Teredo klienta obsahuje značku, pomocí které ostatní Teredo klienti rozpoznají, jakým způsobem mohou spolu komunikovat. Rozpoznají, zdali to mohou zkusit přímým IPv4 UDP spojením na číslo portu obsažené v IPv6 adrese, anebo musí použít příslušnou Teredo relay rovněž v adrese obsaženou. Jak je již patrno ze struktury Teredo IPv6 adresy, Teredo neumožňuje vždy zachovávat stejnou IPv6 adresu, ale vždy je odvislá od IPv4 adresy, případně konfiguraci NAT. To uživateli nemusí vadit, ale pro server je již tento stav nemyslitelný, protože se může snadno stát, že dojde ke změně celé adresy, a tím vznikne nutnost tyto změny včas zanášet do třetích systémů – například do systému DNS. Ke změně adresy nutně dojde ve chvíli, kdy se změní IPv4 adresa, anebo Teredo relay přestane fungovat, a klient bude muset najít jinou relay. Za jedním NAT se může nacházet více Teredo klientů, aniž by je to ovlivňovalo. Avšak díky NAT jejich vzájemná komunikace musí procházet přes Teredo relay, protože přímé adresování není možné.
2.2 SIT (Simple Internet Transition) 6in4 a 6to4 SIT je na rozdíl od Teredo pouze velmi jednoduchý mechanismus, spíše kontejner pro IPv6 rámce putující IPv4 sítí. Ve své podstatě pouze přidává IPv4 hlavičku (protokol 41) ke stávajícímu IPv6 datagramu. Tím ale vzniká omezení na MTU, protože běžná maximální velikost u IPv4 rámce je 1500 bajtů a tímto způsobem můžeme přepravit nefragmentovaný IPv6 paket o velikosti 1480 bajtů (zbylých 20 bajtů zabírá IPv4 hlavička). Sám o sobě ovšem neřeší adresaci ani NAT. Jedná se pouze o nástroj, jak přenést IPv6 paket přes plochou 4 IPv4 síť. Přes mnohé NAT vůbec neprochází, anebo je záměrně filtrován. Přes NAT může být zakončen pouze jediný takto sestavený tunel vedoucí na stejnou venkovní IPv4 adresu, protože NAT nemůže odlišovat více různých tunelů,
4 Tedy bez účasti překladů adres (NAT).
7
není zde totiž žádný rozlišující faktor. Toto zabraňuje použití tunelu více zařízením za stejným NAT.
Ilustrace 2: 6in4 propojení. Technicky velmi podobný princip používá i mechanismus zvaný 6to4. Na rozdíl od 6in4 má však předepsaný tvar IPv6 adresy, ze kterého je použitá část IPv6 adresy jako IPv4 adresa. Toto umožňuje efektivnější komunikaci, ale následkem je opět nestálost adresy podobná mechanismu Teredo. Navíc zde přicházíme o možnost komunikace za NAT.
8
3 Návrh architektury
3.1 Základní požadavky na Tunnel Broker Systém má být schopen připojit pomocí jednoho nebo více tunelů IPv6 podsíť nebo koncovou stanici přes IPv4 infrastrukturu s možností provozní změny zakončení tunelu na obou stranách takovéto sítě – tedy jak změny PoP, tak změny zakončení u uživatele. Každému uživateli je přidělen pevný IPv6 prefix, se kterým bude moci manipulovat. Tedy jej dělit na menší celky a směrovat přes své tunely. Prefix je přidělen na celou dobu existence uživatele v tomto systému. Tunelů s jedním uživatelským zařízením může být sestaveno více. Aplikace, síť nebo uživatel si vyberou nejvhodnější tunel na základě měření IPv4 infrastruktury nebo vlastního uvážení. Těmito tunely je nasměrována část přiděleného IPv6 rozsahu nebo celý přidělený rozsah. Důvodem, proč chceme mít možnost přidělený rozsah rozdělit, je umožnit jednomu uživateli vytvořit více vlastních sítí (domácnost, kancelář) a ty vzájemně je propojit.
9
3.2 Komponenty
Ilustrace 3: Struktůra sítě. Na obrázku 3 vidíme jednotlivé zamýšlené komponenty: •
klient – koncová stanice případně směrovač uživatele
•
ovládací rozhraní – uživatelské rozhraní k sestavování tunelu, backend tunelů
•
PoP - směrovač IPv6 datových spojení mezi ostatní PoP, klienty, případně vně sítě (okolní Internet)
3.2.1
Ovládací rozhraní
Eviduje a spravuje uživatele. Obhospodařuje požadavky uživatelů na správu a evidenci tunelů. Zajišťuje konfiguraci tunelů z jednotlivých PoP. Ovládací rozhraní rovněž zajišťuje službu, se kterou komunikuje klientská aplikace. Jeho pomocí může uživatel nebo systém automatické konfigurace tunelu měnit nastavení svých tunelů, prefixů apod.
10
3.2.2
PoP – Point of Presence
PoP je spojen s ostatními PoP pomocí IPv4 tunelu nebo jsou spojeny IPv6 sítí. PoP je dual-stack systém, má tedy IPv4 i IPv6 adresu. Pro běžný provoz (směrování paketů) nepotřebuje ovládací rozhraní. Veškerá data pro tento účel jsou uložena zvlášť. V případě výpadku ovládacího rozhraní dále směruje data ke klientům bez omezení. IPv4 stack slouží ke komunikaci s klienty sítě pomocí tunelů. IPv6 stack provádí směrování uživatelských datagramů mezi uživatele, PoP, případně vně této sítě.
3.2.3
Klient
•
Obsluhuje ovládací rozhraní.
•
Požaduje sestavování tunelu.
3.3 Automatická konfigurace tunelu Pro účely snadného a rychlého nastavení IPv6 u klienta slouží mechanismus Automatická konfigurace tunelu. Nejedná se o jednorázový proces, ale klientská aplikace si neustále v pravidelných intervalech ověřuje stav sítě a reaguje na patřičné anomálie přenastavením tunelu na výhodnější PoP. Tento mechanismus má sloužit k nastavení klientského zařízení nebo směrovače. Důvody, proč je výhodná automatická konfigurace tunelu, jsou tyto: •
Reakce na výpadky přístupové IPv4 sítě nebo výpadek PoP.
•
Reakce na zatížení sítě.
•
Snížení uživatelské zátěže obhospodařovat své tunely.
11
3.4 Ruční konfigurace Ruční konfigurace je vhodná ke kontrolovanému sestavení tunelu, a to zejména v případech, kdy správce systému chce mít plnou kontrolu nad sestavováním tunelu - například z důvodu nastavení firewallu nebo tam, kde není technicky možné provozovat automatickou konfiguraci tunelu. Veškeré nastavení klienta je nutno provádět ručně správcem systému. Správce systému si vybere, které tunely chce a jakým způsobem je bude používat. Součástí uživatelského rozhraní bude podrobný postup pro nejběžnější systémy. Uživatelské rozhraní nebude rozlišovat mezi ruční a automatickou konfigurací. Fyzické nastavení tunelu na PoP provede Ovládací rozhraní na základě informací vložených uživatelem.
3.5 Návrh způsobu uložení dat Data v databázi jsou zároveň téměř přesným vyobrazením stavu sítě, což se využívá k tomu, že konfiguraci tunelů lze provádět i ve chvíli, kdy je daný PoP je mimo provoz. Veškeré změny se projeví bezprostředně po zprovoznění PoP. V databázi jsou uchovány i tunely které ještě nejsou vytvořené. Právě na základě informací v databází se vytvoří, případně zruší.
12
Ilustrace 4: Zjedoušený ER diagram.
V ER diagramu jsou znázorněny čtyři nejdůležitější entity (user, pop, tunel, route). Entita user zahrnuje uživatele a jeho přidělený prefix, uživatel je identifikován svým unikátním číslem. Entita pop zahrnuje identifikaci popu a jeho veřejnou IPv4 adresu. Entitou tunel poté dochází ke spojení popu a uživatele a rovněž jsou zde evidovány adresy počátečních a koncových uzlů. Počáteční uzly jsou zde definovány z důvodů, že PoP může mít těchto adres více, a proto je nutno mezi nimi rozlišovat. Status vyjadřuje informaci, zdali je tunel již sestaven, čeká na sestavení, čeká na zrušení, případně je již zrušen a čeká pouze na výmaz. Entita route zahrnuje pak směrovací informaci, jaký prefix má být kterým tunelem směrován.
13
3.5.1
DFD diagram (Data Flow Diagram)
Z přiloženého DFD diagramu (ilustrace 5) je patrno, se kterou částí komunikuje uživatel a kterým směrem se přesouvají informace. Tento model byl zvolen pro svou přímočarost. Uživatel i systém automatické konfigurace komunikuje výhradně s frontend-em, přímý přístup do databáze nemají. Do stejné databáze přistupuje rovněž i backend (procesy tunneler a pinger), které realizují vzniklé žádosti na příslušných PoP a informace, o jejich zpracování zanáší zpět do databáze. PoP rovněž nemá přímý přístup do databáze. Veškerá komunikace s PoP je iniciována z backendu.
Ilustrace 5: DFD Diagram.
14
4 Popis implementace
4.1 Ovládací rozhraní Ovládací rozhraní se skládá ze tří základních částí: •
frontend – webová aplikace, zajištující zprostředkování informací z databáze, manipulaci s databází
•
backend – sada procesů, zajišťují sestavení tunelů na PoP
•
databáze
–
jsou
zde
uchovány
primární
data,
tedy
zejména
uživatelské účty, informace o PoP a informace o tunelech
4.2 Frontend Frontend je webová aplikace obsahující sadu CGI skriptů (pro běh v prostředí mod_perl25 nebo CGI6). Tyto skripty realizují předávání informace z databáze pro uživatelův přehled a zároveň úpravu dat v databázi pro další části systému. S tímto rozhraním rovněž komunikuje systém automatické konfigurace tunelu pomocí jednoduchých HTTP požadavků. Automatická část rozhraní je uživateli skryta (API je popsáno v přiložené dokumentaci), jako datový kontejner pro výměnu těchto dat byl užit datový formát JSON7. Frontend uvnitř celého systému komunikuje pouze s databází, přímé napojení na backend není žádoucí. Důvodem je možnost oddělení běhu backendu na jiný server. Frontendů může být více z důvodu lepšího rozložení výkonu. Uživatel se nejprve musí zaregistrovat, tím okamžikem je mu přidělen globální prefix například délky 48bitů, který se už v čase nemění. Dále uživatel požádá o zřízení tunelu, tyto informace se přenesou do 5 Akcelerator perl scriptu pod HTTP serverem Apache. http://perl.apache.org/ 6 Common Gateway Interface – rozhraní mezi protokolem HTTP a programem využívající standardní vstup a výstup. http://www.w3.org/CGI/ 7 JavaScript Object Notation – jedná se o datovou strukturu syntakticky kompatibilní s jazykem JavaScript, je určená pro výměnu informací.
15
databáze. Během sestavování tunelu
může uživatel rovněž požádat
o přesměrování části přiděleného rozsahu. Například se rozhodne, že jeho přídělený prefix o délce 48 bitů rozdělí na více 50bitových a každý z nich přesměruje na jiný tunel. Tato informace se rovněž uloží do databáze ke zpracování.
Ilustrace 6: Ukázka uživatelského rozhraní.
16
4.3 Backend Backend systému se skládá ze dvou základních procesů, a to tunneler a pinger. Proces zajištující tvorbu a správu tunelů se jmenuje tunneler. Jeho úkolem je v pravidelných intervalech kontrolovat informace o požadavcích v databázi a na základě těchto požadavků provádět patřičné změny na PoP a tyto změny zpětně reflektovat do databáze. Backend rovněž zajišťuje časově korektní řešení pořadí požadavků, aby například nemohlo dojít k směrování paketů ještě nesestaveným tunelem. Proto v každém běhu řeší požadavky v tomto pořadí: 1. Vytvoří nové tunely na PoP, případně zruší tunely, na kterých je již zrušena informace o směrování (v případě, že takové tunely jsou). 2. Nastaví (vytvoří nebo zruší) směrování v rámci sestavených tunelů. Další součást backendu je proces jménem pinger. Jeho úkolem je zprostředkovávat měření IPv4 ICMP echo (PING) směrem z PoP k uživateli. Důvodem oddělení od procesu tunneler je nutnost rychlejšího běhu a nezávislost na tomto procesu proto, aby webové rozhraní mohlo rychleji vracet informace o latenci, a uživatel nemusel čekat než proces tunneler zpracuje ostatní požadavky.
4.4 Databáze V databázi je uložen aktuální stav tunelů celé sítě a uživatelských účtů. Databázový server MySQL byl zvolen pro svou jednoduchost. Plně dostačuje kladeným požadavkům na rychlost a snadnost provozování. Kompletní struktura databáze je uložena na přiloženém CD ve formátu MySQL Dump.
17
Vzhledem k absenci funkce Database Change Notification 8 jsem zvolil metodu poolingu dat. Jednotlivé procesy si pravidelným dotazováním v řádu vteřin ověřují, zdali existuje nějaký požadavek na vyřízení. Tato metoda není
sice programově optimální, protože
zatěžuje
databázový systém zbytečnými dotazy, avšak vzhledem k databázovým indexům by s tímto neměl být problém.
4.5 PoP Jako primární platforma pro PoP byl zvolen OS Linux, konkretně Debian Linux. Běh nástroje potřebných pro plnohodnotný chod PoPu je ovšem možný i na jiných architekturách, ale tam nebyl řádně odzkoušen (FreeBSD, OpenBSD, Solaris). Platforma Microsoft Windows byla záměrně vynechána z důvodů velké programové nekompatibility s tímto systémem. Jednotlivé PoP jsou mezi sebou propojeny pomocí tunelů, anebo přímo (L2 okruhy apod.), přičemž výměnu prefixů si obhospodařují klasickým protokolem BGP9, případně OSPF10 nebo jeho libovolnou náhradou. Na každém PoP je proto nainstalován směrovací balík Quagga11, který tento požadavek splňuje. Quagga má rovněž snadno programátorsky uchopitelné rozhraní pro změnu konfigurace za chodu (CLI), která je pro tento systém rovněž důležitá (změny směrování uživatelských tunelů). Na PoP v rámci procesu inetd12 program jménem netstat, který zajišťuje fyzické zřizování, zánik a testovaní dle požadavků z backendu. Rovněž komunikuje se směrovacím balíkem quagga, kterému sděluje informace o směrovacích informacích k uživatelům. Informace jsou předávány pomocí textového rozhraní aplikace zebra běžící na portu tcp/2601. Jsou použity příkazy 'ipv6 route [prefix] [interface]' pro vytvoření směrování, a 'no ipv6 8 Database Change Notification - upozornění klienta databáze, že došlo ke změně v datové tabulce. 9 Border Gateway Protocol – směrovací protokol užívaný jako vnější protokol výmeny informací – většinou se používá jako mezi různými autonomními systémy (AS). 10 Open Shortest Path First – směrovací protokol využívající algoritmu Dijsktra - používá se uvnitř autonomního systému (AS). 11 Quagga je balík směrovacích programů pro UNIXové platformy (umí obsluhovat protokoly BGP, OSPF a RIP). 12 Běžná součást UNIXových systému, tzv. superserver, obsluhuje TCP a UDP porty v režimu server.
18
[prefix] [interface]' pro zrušení směrování. Jiný způsob komunikace s balíkem quagga není implementován. Proces zebra si všechny tyto směrovací informace ukládá do vlastního konfiguračního souboru, takže po rebootu není nutné tyto informace znovu vkládat. Dále je zde umístěn jednoduchý program, který zajistí načtení konfigurace tunelů z konfiguračního souboru pro případ restartu PoP. Veškeré informace obdržené od backendu systému jsou totiž uloženy na PoP, takže v případě restartu PoP není zapotřebí tyto informace znovu získávat z databáze. Backend pouze provede doplnění případných změn. Jak již bylo řečeno v předchozím odstavci, směrovací informace není zapotřebí znovu inicializovat, jsou již uchovány v rámci aplikace zebra13. Z těchto funkcí vyplývá, že samotný PoP je schopen plnit svou funkci i bez ovládacího rozhraní s výjimkou, že nelze provádět žádné změny konfigurace.
4.6 Klient Uživatel si může vybrat jakým, způsobem bude postupovat k získaní přístupu do světa IPv6, a to buď pomocí automatické konfigurace tunelu, používá-li OS Linux, anebo ruční konfiguraci, která by měla fungovat na libovolném operačním systému, jenž podporuje IPv6.
4.6.1
Automatická konfigurace tunelu
Uživatel má na svém počítači nainstalován program jménem akt.pl, který je napsán v jazyce Perl, čímž se významně rozšiřuje kompatibilita s různými platformami. V
konfiguračním
souboru
jsou
uchovány
přístupové
informace
k ovládacímu rozhraní a požadovaná část rozsahu nebo koncová adresa. Tato adresa samozřejmě musí být součást uživatelova přiděleného prefixu (prostoru).
13 Součást balíku Quagga, zajišťuje vzájemné předávání směrovacích informací v rámci tohoto balíku
19
Po spuštění program Automatická konfigurace tunelu (AKT) provede následující úkony: 1. Spojí se s frontendem systému a jednoduchými HTTP zprávami, kde se autentizuje, zjistí stav tunelů směrující požadovaný prefix. 2. Ze získaných informací provede porovnání, zdali jsou všechny PoP nastaveny pro úspěšné připojení, případně provede korekce na základě aktuálních informací (viz dále). 3. Vytvoří
tunel
na
uživatelské
straně
a
vyčkává
potvrzení
funkčností úspěšným spojením se tunelem s PoP (ověření pomocí IPv6). 4. Dále program kontroluje síťové parametry a přizpůsobuje se jejich změnám. V rámci testů síťových parametrů si systém automatické konfigurace tunelu ověřuje jednou z těchto metod stav sítě: •
ICMP RTT – je měřen čas odezvy PoPu na klasický IPv4 ICMP Echo request (PING).
•
HTTP download speed – je měřena rychlost stáhnutí souboru o velikosti 1 MB z IPv4 adresy PoP.
•
Packet loss – měří se procentní ztráta vzorku paketů změřených metodou IPv4 ICMP Echo request/reply. Jak je již patrno z podstaty věci, všechny tyto parametry je nutno řešit
ještě před sestavením samotného tunelu na úrovni protokolu IPv4. Měření těchto parametrů na protokolu IPv6 by způsobovalo zbytečné a nadměrné zatěžování PoP tvorbou tunelů. Rovněž by způsoboval dlouhé doby k sestavení legitimních tunelů. Výsledek těchto měření se použije k výběru nejvýhodnějšího PoP, na který se poté automaticky sestaví tunel.
20
4.6.2
Ruční režim
Ruční režim je možné kdykoliv použít, lze libovolně přepínat mezi ním a automatickým režimem. Interně systém nerozlišuje, jestli je tunel sestaven automatickým režimem nebo ručním. Rozdíl spočívá pouze v tom, že všechny parametry tunelu musí uživatel nastavit pomocí webového rozhraní. Parametry jsou tyto: •
vybraný PoP, ze kterého má být sestaven tunel
•
typ tunelu – OpenVPN nebo SIT
•
IP adresa zakončení tunelu (pak-li že byl vybrán typ SIT)
Webové rozhraní zároveň změří latenci ze všech PoP, které jsou k dispozici vůči zadané (uživatelské) IP adrese, což umožní uživateli se lépe rozhodnout, kam zakončit tunel. Následně se do vzniklého tunelu zavede celý uživatelův rozsah (prefix), anebo jeho část – podle toho, jaké si uživatel zvolí nastavení. K nastavení takto vzniklých tunelů na uživatelské straně není zapotřebí žádných specializovaných nástrojů. Všechny potřebné nástroje již operační systémy s podporou IPv6 obsahují (například nástroj ip z balíku iproute2 (Linux)).
4.7 OpenVPN OpenVPN je primárně určen k zabezpečenému propojení privátních sítí (VPN) na protokolu IPv4. Velmi dobře prochází IPv4 NAT, protože užívá běžné bezstavové UDP spojení s protistranou (podobně jako Teredo). Používá šifrování dat na principu Public Key Infrastructure (PKI) nebo Pre-Shared Key (PSK). Pro naše účely je tato funkce sice vítaná, ale nikoliv nezbytně nutná. Můžeme využít jeho vlastností a takto sestaveným spojením vytvořit SIT tunel. Výhodou je, že tunel může být zakončen na privátních adresách, z čehož vyplývá následující:
21
•
Změna vnější IPv4 adresy uživatele nemá vliv na tunel, OpenVPN se okamžitě přizpůsobí.
•
Projde běžně nastaveným firewallem a NAT (díky použití UDP rámců).
Tunnel broker by nepotřeboval znát IPv4 adresu uživatele, ta je dynamická, a tedy přirozeně mobilní. Proto jsem se rozhodl zakomponovat tento tunelovací mechanismus do podpory mého Tunnel brokeru.
22
5 Popis interního chodu aplikace
5.1 Reakce na výpadek Tento Tunnel Broker se snaží maximálně řešit všechny druhý výpadků svou koncepcí. Uvádím zde výčet různých problémů a nástin jejich řešení, které můžou tento systém postihnout. Důležité je připomenout, že v případě jakéhokoliv druhu výpadku zůstanou IPv6 adresy uživatelů zachovány.
5.1.1
Výpadek PoP
Přesměrování tunelů na jiný PoP iniciuje uživatel nebo automatická konfigurace
tunelů.
Interní
směrovací
protokol
provede
automatické
přesměrování uživatelských prefixů na zbývající tunely k daným uživatelům (pokud existují). V případě návratu PoP k činnosti je ale možné, že dojde k drobnému výpadku (řádově minuty), než se synchronizuje s ovládacím rozhraním (databází).
5.1.2
Výpadek ovládacího rozhraní
V případě výpadku ovládacího rozhraní nelze měnit žádné nastavení. Datový provoz mezi uživateli, jakožto vně systému, je však plně zachován. Pokud dojde k znepřístupnění databáze a existuje-li replikovaná databáze na jiném místě, lze provést převedení frontendu i backendu na novou lokalitu bez povšimnutí uživatelem. Samozřejmě je nutné počítat s patřičnou
propagací
systémem
DNS,
anebo
využít
jiných
metod
(přesměrovaní).
23
5.1.3
Výpadek propojení mezi PoP
Tuto
problematiku
doporučení
provozovat
reší
interní
všechny
směrovací
PoP
protokol.
propojené
Vzhledem
systémem
k
„každý
s každým„ (full-mesh topology) to nemusí znamenat žádný větší problém.
5.1.4
Výpadek propojení do jiných sítí (Internet)
Pokud by došlo k úplnému výpadku propojení do globální sítě Internet, tuto situaci nelze řešit. Interní propojení mezi uživateli zůstane zachováno. Nicméně tato situace je shodná se stejnou situací jako v případě IPv4.
5.1.5 Chybná implementace Tunnel Brokeru a tím způsobené poruchy Na tento problém neexistuje předem dané rozumné řešení. V případe, že se vyskytne skrytá chyba v software Tunnel brokeru, je nutná analýza této situace. Díky tomu může však, v nejhorším případě, dojít až k úplné odstávce systému.
5.1.6
Změna IPv4 adresy klienta
V případě, že se uživateli změní IPv4 adresa, je nutné rozlišovat, jestli uživatel používá OpenVPN tunelu nebo nikoliv. Pokud jej uživatel užívá, dojde automaticky k přesměrování, což Tunnel Broker ani neumí detekovat. V případě, že jej nepoužívá, je nutno provést ruční přesměrování tunelu na novou adresu. V případě, že se užívá Automatická konfigurace tunelu, toto není nutné, neboť se o tento proces postará tento mechanismus.
24
5.2 Způsob změny směrování V případě, že automatická konfigurace tunelu změří, že se rapidně zhoršila kvalita spojení v rámci sestaveného tunelu, nebo došlo k výpadku, provede Automatická konfigurace tunelu nové měření dostupnosti k jiným PoP. Nalezne-li
výrazně
lepší
parametry,
sestaví
nový
tunel
pomocí
ovládacího rozhraní a vyčká na úspěšné potvrzení o sestavení tunelu z požadovaného PoP. Poté přesměruje provoz přes takto vzniklý PoP přesměrováním výchozí směrovací informace (default route). Následně zahájí proces zrušení tunelu z předešlého PoP, přičemž svou stranu spojení zruší opět až po potvrzeném zrušení od ovládacího rozhraní, takže všechny mezitím došlé pakety se ještě zpracují. V případě výpadku ovládacího rozhraní není možné tyto změny provést, klient může pouze měnit výchozí tunel pro odchozí komunikaci (výchozí směrovací informace). Směr příchozí komunikace však ovlivnit nemůže. Tento postup má zajistit hladký přechod mezi jednotlivými PoP, a tím minimalizovat trvání výpadku služby. IPv6 adresy zůstanou v každém okamžiku stejné.
25
6 Závěr Cílem bakalářské práce bylo navrhnout a implementovat distribuovaný IPv6 tunnel broker, jenž bude umožňovat uživateli přístup do IPv6 sítě odkudkoliv, stále se svou předem přidělenou adresou. V první kapitole jsem zmínil několik způsobů, jak získat IPv6 konektivitu pro běžného uživatele. Ve druhé kapitole jsem nastínil architekturu, která bude využívat výše uvedených vlastností. Ve třetí kapitole jsem podrobněji rozebral důležité implementační detaily a osvětlil základní a důležité principy návrhu. Zdrojové kódy, instalační návod a uživatelská dokumentace jsou uchovány na přiloženém nosiči CD. Z hlediska zadání se mi podařilo splnit všechny náležitosti. Jediné kritické místo vyplynulo v rámci implementace v tom, že síť obsahuje pouze jedinou databázi, bez které nelze provádět změny. Zkušenosti s provozem tohoto systému jsem načerpal v rámci projektu XS26 (www.xs26.net), se kterým již několik let spolupracuji na správě systému.
26
7 Použitá literatura
S. Hagen, „Ipv6 Essentials“, O'Reilly Media, Inc., ISBN 9780596100582, 2006. P.
Satrapa,
„Internetový
protokol
IPv6“,
CZ.NIC,
z.s.p.o.,
ISBN 978-80-904248-0-7, 2008. Microsoft Corporation, About Teredo, dokument dostupný na URL http://msdn.microsoft.com/en-us/library/aa965905 (prosinec 2010)
François Donzé, The Internet Protocol Journal - Volume 7, Number 2, HP, dokument dostupný na URL http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_72/ipv6_autoconfig.html (prosinec 2010)
27
8 Příloha: Uživatelská dokumentace
8.1 Registrace Každý
uživatel,
který
chce
používat
tento
systém,
musí
být
zaregistrován. Tedy musí projít registrací, kde se ověří, že se nejedná o automatizovaného robota (testem „CAPTCHA“), zároveň se ověří existence emailového účtu a uživatel si vybere své jméno a heslo.
Ilustrace 7: Registrace uživatele Po registraci je nutné aby administrátor schválil uživatele. Tento krok je nezbytně nutný k tomu, aby bylo administrátorovi známo, kdo používá tento systém (předpokládá se plně veřejné nasazení). Zároveň administrátor přidělí uživateli jeho adresní rozsah.
28
Ilustrace 8: Kontaktní údaje uživatele
8.2 Automatická konfigurace tunelu Uživatel rozbalí obsah přiloženého souboru xs26-akt-0.1.tar.gz, ve kterém se nachází program, jenž obhospodařuje automatickou konfiguraci. Uvnitř tohoto souboru je nutné nastavit tyto údaje (nachází se na samotném začátku): Uživatelské jméno a heslo pro přístup do ovládacího rozhraní: $user = 'uzivatel'; $pass = 'heslo'; Požadovaný adresní rozsah: $prefix = '2a01:5e0:d:5000::/64'; Tento rozsah musí být celá část, anebo podčást přiděleného adresního rozsahu. Účelem tohoto, je, aby tentýž uživatel mohl používat IPv6 na více místech v jeden okamžik. Následně stačí program spustit a sledovat jeho činnost, po nějaké chvíli by již mělo být IPv6 plně k dispozici.
29
8.3 Ruční konfigurace V případě, že uživatel nechce nebo nemůže použít automatickou konfiguraci, postupuje podle následujícího postupu: V ovládacím rozhraní, si uživatel vytvoří nový tunel (pro jednoduchost uvedu pouze variantu bez OpenVPN tunelu): Uživatel si zde vybere, které PoP chce využít a na jakou IP adresu se má tento tunel vytvořit.
Ilustrace 9: Nový tunel. Poté je ještě nutné nasměrovat příslušný rozsah do tohoto tunelu.
Ilustrace 10: Zadaní informace o směrování.
30
Na svém zařízení je nutno vytvořit patřičné protistrany tunelu (příkazy jsou uvedeny pro OS Linux s nástrojem ip z balíku iproute2, jiné systémy je nutné konzultovat s uživatelským manuálem a najít ekvivalentní postup): Vytvoříme tunel: ip tunnel add sit1 local 10.136.0.2 remote 10.1.2.3 mode sit ttl 64 Zapneme jej: ip link set sit1 up Nastavíme výchozí směr komunikace: ip 6 route add ::/0 dev sit1 Nastavíme svou IPv6 adresu: ip 6 addr add 2a01:5e0:d:5000::1/64 dev sit1 Poté uživatel vyčká sestavení těchto tunelů a tím je připojen k síti IPv6.
31
