Tunelování v sítích (nejen) IPv6

Tunelovaní v sítích
(nejen) IPv6
Tomáš Hlaváček
Tunelování je metoda přenosu dat, která umožňuje překlenout omezení
existující fyzické sítě a zajistit vyšší úroveň bezpečnosti, přenášet proto­
koly, které nejsou na fyzické síti podporovány, nebo spojit fyzicky oddělené
sítě do logického celku. Článek projednává o různých tunelovacích techno­
logiích, zejména ve vztahu k IPv6.
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 hle­
diska 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 tech­
nologií, 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ě šif­
rová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 hla­
vič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 zpoma­
lová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. Na­
pří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 pra­
covní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ě nepod­
poruje. 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-topoint tunelů jsou GRE (Generic Routing En­
capsulation) 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ýko­
nu 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í spo­
jení. 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 tune­
lů 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ře­
krytí 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 po­
už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-l)/2 tu­
nelů, kde N je počet koncových bodů.
Naproti tomu návrhový vzor hub-and-spo­
ke vychází z myšlenky, že se určí omezené
množství hubu, centrálních směrovačů, na
které si všechny endpointy navážou tunel
Společnost Ignum se rozhodla podpořit aktivity tunnel brokera SixXS poskytnutím vlastního
který zatím jako jediný zajišťuje v ČR tyto služby
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 ad­
resu 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ýpa­
dek 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 paradig­
matu 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 poz­
dě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 postave­
né 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 in­
ternetu 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í tunelo­
vání, překlad adres a protokolů, případně
i manipulace s DNS.
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í. Ne­
vý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í mechanis­
mus č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íťo­
vý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živa­
tele, 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 zpra­
vidla organizace, která umožňuje registraci
a získání uživatelského přístupu do provisio­
ning systému, který uživateli založí a nastaví
tunel, přidělí adresy pro koncovou síť, nasta­
ví 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ů. Mimo­
chodem, 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ý provi­
der, 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čas­
nosti 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 (Au­
tomatic 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 do­
sá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á, ne­
př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 ome­
zení 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šťo­
vání bezpečnosti a robustnosti spojení mezi
cloudem a konzumentem jeho služeb.
Zdroje
[1] RFC2784, http://tools.ietf.org/html/
±2784
[21 RFC2637, http://tools.ietf.org/html/
±2637
[3] RFC2661, http://tools.ietf.org/html/
±2661
[4] RFC4213, http://tools.ietf.org/htmt/
±4213
[5] RFC 1918, http://tools.ietf.org/html/
±1918
[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] RFC4380, http://tools.ietf.org/html/
±4380
Autor pracuje jako
síťový specialista
ve společnosti
Ignum.