Význam a druhy tunelů

Typické situace, kdy se vyplatí postavit tunel je, když fyzická síť mezi dvěma body, které spolu chtějí komunikovat, sice existuje, ale má omezení, které znemožňuje provoz požadované aplikace. Dalším případem je poskytování tunelů ve velkém měřítku přímo providerem podkladové sítě, který tak může oddělit zákazníky, kontrolovat lépe provoz. Dokonce existují i technologie na velmi inteligentní manipulaci s tunelovaným provozem, rezervace pásma pro tunely, přesměrování tunelů v případě výpadků nebo k řízenému snížení kvality služeb podle stanovených politik a priorit. Z hlediska uživatele se tunelem může překlenout L3 síť (například síť s IP routingem) mezi dvěma či obecně více L2 sítěmi. Tunel lze také efektivně použít k překlenutí L3 sítě, která podporuje pouze protokol IPv4 a cílem je přenášet IPv6 nebo i nějaký exotičtější protokol typu IPX/SPX nebo AppleTalk. Další důvod pro tunelování je zabezpečení provozu šifrováním.

Výhodou tunelů je, že jsou z velké části softwarovou záležitostí a že je zpravidla celkem jednoduché a levné tunel sestavit, zvlášť v relaci s možností stavby fyzické síťové trasy nebo poskytnutím okruhu či síťového pásma nějakou jinou síťovou technologií, jako je DWDM. Nevýhodou tunelů je, že na obou stranách tunelu je nutné zpracovat (zabalit nebo rozbalit) tunelované datagramy, což stojí CPU čas a sběrnicové pásmo na koncových bodech. V případě šifrování provozu posílaného tunelem je využití CPU kritický parametr a často se používají i hardwarové kryptografické akcelerátory, zejména v enterprise aplikacích, kde je třeba dosahovat rychlostí řádově stovky Mbps a více. Dále tunely zvětšují latenci a snižují MTU (maximum transfer unit), to proto, že datagram je po zabalení do další vrstvy hlaviček větší. Přitom na velikost datagramů je horní limit daný nejmenším linkovým MTU v cestě mezi zdrojem a cílem (resp. mezi koncovými body tunelu, kde se od linkového MTU ještě odečítá velikost tunelovacích hlaviček). Z toho jsou dvě cesty ven. Buď nastavit na interfacy tunelu menší MTU, což může někdy dělat trochu problémy, protože se najdou i systémy, co uvažují s defaultním MTU 1500 bytů a nepodporují mechanismy path MTU discovery. Druhou možností je fragmentace datagramů, které po zabalení do tunelovacích hlaviček přesáhnou linkové MTU. To sebou samozřejmě přináší všechna negativa fragmentace z TCP, tedy zpomalování, zátěž CPU na sestavení fragmentů, větší náchylnost k zahazování datagramů, a navíc to je agnostické k protokolům vyšších vrstev.

Tunelování se považuje v řadě aplikací za standardní řešení, které má z technického i cenového hlediska optimální vlastnosti. Například zabezpečené šifrované spojení dvou poboček firmy mezi dvěma městy, nebo i dvěma kontinenty lze vybudovat pomocí enterprise-grade zařízení s použitím silných šifer a s redundancí za pouhý zlomek ceny, jakou by stálo vybudovat nebo pronajmout privátní síťový propoj například optickým kabelem. Stejně tak zabezpečené a šifrované připojení do vzdálené firemní sítě pro pracovníky, jejichž fyzická poloha připojení do přístupové sítě se v čase mění, jde zařídit nejsnáze a nejlevněji tunelem. Tunely jsou také považovány za univerzální přechodový mechanismus pro připojení k IPv6 internetu pro uživatele, jejichž ISP IPv6 ještě nepodporuje. V této aplikaci hraje roli především cena tunelu, která musí být pro koncové uživatele blízká nule.

Topologie sítí s tunely

Tunely lze používat ojediněle jako spojnice mezi disjunktními sítěmi pro jejich vzájemné propojení, ale pomocí tunelů lze postavit i rozsáhlou virtuální síť, kde tunelování tvoří základ architektury. V obou případech se užívají návrhové vzory, které respektují nutná omezení daná fyzickou sítí, nad kterou se tunely budují, ale umožňují překlenout jiná omezení. Hlavní dva návrhové vzory jsou point-to-point, respektive mesh, versus hub-and-spoke. První termín point-to-point vyjadřuje fakt, že oba koncové body tunelu mají stejné postavení, oba mohou spojení navázat, nebo je spojení nestavové a tím pádem se navazovat po prvotní konfiguraci už nemusí. Hlavními reprezentanty point-to-point tunelů jsou GRE (Generic Routing Encapsulation) popsaný v RFC 2784 [1] a PPTP (Point-to-Point Tunneling Protocol) popsaný v RFC 2637 [2], který používá GRE jako svůj stavební prvek. GRE je protokol nestavový, má velmi malou režii z hlediska velikosti vlastní hlavičky i spotřebovaného CPU výkonu na tunelování a je velmi robustní. Jeho nevýhodou je, že v okamžiku nastavení GRE tunelu je třeba znát adresy obou koncových bodů tunelu a oba koncové body musí být navzájem dostupné přes IP, což explicitně vylučuje, aby byl mezi koncovými body NAT, s výjimkou 1:1 NATu. Naproti tomu PPTP je už stavový protokol, kde jedna nebo obě strany podle vlastních pravidel sestavují spojení. PPTP spojení se skládá z kontrolního TCP kanálu a z datového kanálu, který je ve skutečnosti dynamicky sestavený GRE tunel. Mezi další reprezentanty point-to-point tunelů patří protokol L2TP [3] a 6in4 [4].

Návrhový vzor mesh vychází z toho, že koncové body tunelů, i pokud jich je víc, jsou rovnocenné. Tunely se používají k překrytí fyzické sítě virtuální topologií, aby se eliminovaly například bezpečnostní nebo směrovací omezení fyzické sítě. Předpokládá se, že ve směru předpokládaných toků se mezi koncovými body nastaví tunel a použije se směrování podle příslušné vrstvy, na jakou se tunely napojují. Pro L3 tunely (například statické GRE tunely) určené pro přenos IPv4 mezi pobočkami firmy, které používají v rámci kanceláře vyhrazené sítě podle RFC 1918 [5], lze použít statické směrování nebo některý standardní dynamický směrovací protokol, jako OSPFv2 nebo RIPv2. Mesh je možné postavit jen částečný, tak aby logická topologie vhodně skryla fyzickou topologii a její omezení, zajistila dosažitelnost a přiměřenou redundanci, ale nepřinesla velkou administrační zátěž. Extrémní návrh full-mesh, tedy propojení všech tunnel-endpointů se všemi, má smysl při malém počtu koncových bodů (do pěti) a při nepředvídatelných tocích, nicméně znamená dohromady navázat N*(N-1)/2 tunelů, kde N je počet koncových bodů.

Naproti tomu návrhový vzor hub-and-spoke vychází z myšlenky, že se určí omezené množství hubů, centrálních směrovačů, na které si všechny endpointy navážou tunel a budou mezi sebou komunikovat skrze hub. Výhody jsou ve snadnější administraci a v tom, že při použití stavového protokolu není třeba předem znát adresy koncových uzlů, stačí, aby koncový bod tunelu znal adresu hubu a aby sám vyvolal spojení. Nevýhodou pak je, že jde o komplexnější situaci, huby jsou zatěžovány veškerým provozem a jsou kritickou infrastrukturou, jejíž výpadek znamená rozpojení všech tunelů. Použití hub-and-spoke je celkově méně robustní, má větší režii a přináší prostoje při navazování a obnovování spojení.

Ještě existuje kategorie exotických protokolů a technologií, které nelze zařadit ani do jednoho z návrhových vzorů a které zpravidla umožňují postavit síť oběma způsoby, a navíc přináší vlastnosti, které ani nemusí nutně zapadat do obecného paradigmatu tunelování.

Protokoly pro podporu přechodu na IPv6

Přechod internetu v globálním měřítku z protokolu IPv4 na IPv6 bude dříve či později nevyhnutelný. To se samozřejmě ví už dávno, oficiálně podle [6] už několik let. Aby byl přechod co nejméně problematický a uživatele významně neovlivňoval, pro podporu přechodu na IPv6 vznikly různé mechanismy, které jsou zpravidla postavené na myšlenku tunelování. Cílem je buď připojit k IPv6 internetu host nebo síť, která má pouze IPv4 upstram či obecně uplinky, nebo opačně zpřístupnit obsah na IPv4 internetu IPv6-only hostům v IPv6-only sítích. V prvním případě se tunelováním překlenuje neschopnost podkladné fyzické sítě přenášet IPv4, ale není problém dát koncovým uzlům IPv6 adresy. Ve druhém případě je situace složitější, počítá se totiž s tím, že koncový uzel prostě nebude mít vůbec IPv4 adresu, ale přesto bude chtít komunikovat s IPv4 světem. Za tím účelem je navrženo několik protokolů, které různě kombinují tunelování, překlad adres a protokolů, případně i manipulace s DNS.

Společnost Ignum se rozhodla podpořit aktivity tunnel brokera SixXS poskytnutím vlastního serveru, který zatím jako jediný zajišťuje v ČR tyto služby

Tunelovací protokol 6in4

Protokol 6in4 definovaný v RFC 4213 [4] definuje velmi jednoduchý protokol na enkapsulaci IPv6 datagramů přímo v IPv4. Tím zajišťuje svoji úlohu s minimální režií. Nevýhodou 6in4 je, že jako nestavový protokol neprochází v obecném případě NATem a že je nutné ho staticky konfigurovat podobně jako GRE. Protože oba koncové body musí znát adresu svého partnera, je nutné mít buď statické veřejné a neNATované IPv4 adresy na koncových bodech, nebo použít nějaký automatický konfigurační mechanismus či protokol. Kvůli omezením protokolu 6in4 není tento protokol příliš rozšířený pro tunelování IPv6 ke koncovým uživatelům, ale používá se k tunelování mezi servery a celými sítěmi a jeho podpora je na běžných síťových operačních systémech bezproblémová. Z hlediska zařazení k návrhovému vzoru je tento protokol nestavový a point-to-point.

Tunelování IPv6 pro koncové uživatele

Zajistit IPv6 konektivitu pro koncové uživatele, jejichž ISP IPv6 nepodporují, lze také pomocí tunelů. Díky několika celosvětovým iniciativám, které vytvořily takzvané Tunnel Brokery toho lze dosáhnout dokonce zdarma a relativně snadno. Tunnel Broker je zpravidla organizace, která umožňuje registraci a získání uživatelského přístupu do provisioning systému, který uživateli založí a nastaví tunel, přidělí adresy pro koncovou síť, nastaví reverzní DNS a pomůže při nastavení jeho koncové stanice či sítě. Z hlediska topologie se jedná o hub-and-spoke a současní TB disponují (často vlastními proprietárními) protokoly a softwarem pro automatické navazování tunelů pro klienty s dynamickou IPv4 adresou, nebo dokonce i přes NAT.
Hlavní TB jsou v současnosti SixXS a Hurricane Electric. SixXS je nekomerční organizace, která má centrální provisioning systém, ale IPv6 adresy, koncové body pro tunely a síťové pásmo získává od sponzorů – provozovatelů koncových bodů. Mimochodem, koncový bod SixXS je i v Praze, což umožňuje českým uživatelům připojení k IPv6 internetu se zanedbatelnou latencí a dostatečným síťovým pásmem. Hurricane Electric je velký mezinárodní síťový provider, a tak pásmo a tunelové body poskytuje převážně sám.

Protokol AYIYA

K překlenutí NATu a jistých omezení firewally vznikl také pokročilý protokol AYIYA (Anything In Anything) [7]. Smyslem tohoto protokolu je umožnit relativně nenákladné tunelování libovolného protokolu, v současnosti zejména IPv6, přes L4 protokoly, jako je UDP, TCP nebo SCTP. Tím se sice zvyšuje režie a komplexita protokolu, ale výhodou je, že L4 protokoly prochází NATem. AYIYA navíc poskytuje základní zabezpečení proti útokům na tunely, zejména vydávání se za jednu stranu tunelu a opětovné vyslání zachycených dat. Implementace AYIYA na straně klienta existuje v podobě multiplatformího open-source softwaru AICCU (Automatic IPv6 Connectivity Client Utility), který je šířen pod BSD licencí a vznikl přímo v rámci SixXS.

Jiné tunelovací technologie

Mimo rozebraných protokolů ještě stojí za pozornost celá rodina protokolů IPsec, která má provozní mód tunel a jím umožňuje dosáhnout tunelování různorodých protokolů po heterogenní nebezpečné síti. Zaměření IPsecu je sice především na bezpečnost, kryptografii a autenticitu dat, což ale nevylučuje možnost postavit pomocí IPsec tunelů zajímavé a komplexní virtuální sítě.

Další důležitá technologie je Teredo [8], za níž v současnosti stojí Microsoft. Jedná se o cloud koncových bodů pro dynamické nestavové tunely a používá vlastní protokol pro sestavování tunelů, vyhledávání nejkratší cesty a řízení. Výhodou je, že Teredo funguje prakticky samo a nevyžaduje konfiguraci, dokonce je dodávané v některých verzích Windows a je ve výchozím stavu zapnuté, takže umožňuje komunikovat uživatelům s IPv6 světem, aniž by to vůbec věděli. Na druhou stranu Teredo neposkytuje pevné IPv6 adresy a jeho architektura je složitá, nepřehledná a v mnoha ohledech znemožňuje řešení problémů, pokud nějaké nastanou. Teredo je také považováno za bezpečnostní riziko, a proto ho administrátoři Windows často hned deaktivují.

Tunelování v budoucnosti

Nedostatek IPv4 adres je velkou výzvou pro celý internet a návrháři protokolů projevili velkou invenci při vymýšlení přechodových mechanismů, které umožňují obejít omezení IPv4 internetu, zejména NAT, který je vlastně také důsledkem nedostatku adres. V budoucnu, až se prosadí IPv6, zmizí NATy a v internetu bude opět běžná end-to-end konektivita, zmenší se význam tunelovacích technologií jako prostředku pro přechod na IPv6. Naopak s příchodem cloud computingu a privátních cloudů bude třeba zajistit ve velké míře bezpečné, vyhrazené a spolehlivé komunikační kanály, a tak se možná přesune hlavní význam tunelování právě do zajišťování bezpečnosti a robustnosti spojení mezi cloudem a konzumentem jeho služeb.

Zdroje

[1] RFC 2784, http://tools.ietf.org/html/rfc2784
[2] RFC 2637, http://tools.ietf.org/html/rfc2637
[3] RFC 2661, http://tools.ietf.org/html/rfc2661
[4] RFC 4213, http://tools.ietf.org/html/rfc4213
[5] RFC 1918, http://tools.ietf.org/html/rfc1918
[6] RIPE 55 meeting report, www.ripe.net/ripe/meetings/ripe-meetings/ripe-55/meeting-report
[7] Internet Draft AYIYA: Anything In Anything, http://unfix.org/~jeroen/archive/drafts/draft-massar-v6ops-ayiya-01.txt
[8] RFC 4380, http://tools.ietf.org/html/rfc4380

Tomáš Hlaváček
Autor pracuje jako síťový specialista ve společnosti Ignum.