Masarykova univerzita Fakulta informatiky
Srovnání VPN realizací Diplomová práce
Bc. Přemysl Šteidl Brno 2007
Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.
2
Poděkování Rád bych poděkoval vedoucímu mé diplomové práce RNDr. Radku Ošlejškovi, Ph.D. za pomoc a rady, které mi při tvorbě této práce poskytnul.
3
Shrnutí Tato diplomová práce se zabývá virtuálními privátními sítěmi (VPN). Vysvětluje jejich princip, popisuje technologie využívané při tvorbě VPN. Představuje vybraná softwarová VPN řešení a srovnává je dle zvolených parametrů.
4
Klíčová slova VPN, Virtuální privátní sítě, srovnání, bezpečnost, PPTP, L2TP, IPSec, Openswan, OpenVPN, Poptop, Stunnel, tinc
5
Obsah 1 Úvod .........................................................................................................................................8 2 Teoretický úvod do VPN ........................................................................................................9 2.1 Co je to VPN?...................................................................................................................9 2.2 Motivace ...........................................................................................................................9 3 Požadavky na VPN ...............................................................................................................12 3.1 Bezpečnost......................................................................................................................12 3.2 Další požadavky..............................................................................................................13 4 Technologie VPN...................................................................................................................14 4.1 Technologie používané při tvorbě VPN .........................................................................14 4.2 Síťový model TCP/IP .....................................................................................................14 4.2.1 Spojová vrstva (Linková vrstva – Link Layer)....................................................15 4.2.2 Síťová vrstva (Network Layer) ...........................................................................15 4.2.3 Transportní vrstva (Transport Layer) ..................................................................15 4.2.4 Aplikační vrstva (Application Layer)..................................................................15 4.3 VPN na spojové vrstvě ...................................................................................................16 4.3.1 Virtuální sítě pomocí LAN emulace....................................................................16 4.3.2 MPOA (Multiprotocol over ATM)......................................................................17 4.3.3 MPLS (Multiprotocol Label Switching) .............................................................17 4.4 VPN na síťové vrstvě......................................................................................................18 4.4.1 Filtrování směrovacích informací........................................................................18 4.4.2 VPN s využitím tunelů ........................................................................................19 4.4.3 VPN s využitím šifrování na síťové vrstvě .........................................................26 4.5 VPN na aplikační a transportní vrstvě ............................................................................30 4.5.1 Protokol SSL (Secure Socket Layer)...................................................................30 5 VPN řešení .............................................................................................................................32 5.1 Testovací sestava ............................................................................................................32 5.2 VPN řešení......................................................................................................................33 5.2.1 OpenVPN ............................................................................................................33 5.2.2 Openswan ............................................................................................................36 5.2.3 Poptop (PPTP server) + PPTP Klient..................................................................38 5.2.4 Stunnel.................................................................................................................40 5.2.5 tinc.......................................................................................................................42 6 Porovnání VPN .....................................................................................................................45 6.1 Srovnání..........................................................................................................................45 6.2 Srovnávací parametry .....................................................................................................45 6.2.1 Bezpečnost...........................................................................................................45 6.2.2 Škálovatelnost .....................................................................................................46 6.2.3 Výkon ..................................................................................................................47 6.2.4 Spolehlivost .........................................................................................................47 6.2.5 Přizpůsobivost .....................................................................................................47
6
6.3 Hodnocení.......................................................................................................................48 7 Závěr ......................................................................................................................................50 Literatura....................................................................................................................................51
7
Kapitola 1
Úvod Rozvoj informačních technologií a zejména zvyšování dostupnosti Internetu v posledních letech umožňuje přistupovat ke spoustě informací téměř každému jednotlivci i veliké organizaci. S přístupem k informacím ale souvisí také problematika zajištění dostupnosti jen určitých informací určeným cílovým skupinám. V současné době jsou technologie VPN (Virtual Private Networks) jedním z hlavních způsobů, jak využít dostupné internetové připojení ke komunikaci mezi subjekty (firmami, jednotlivci) s možností komunikaci zabezpečit a ochránit. Existujících VPN řešení je celá řada a vybrat si to pravé konkrétní řešení není jednoduché. Vybudovat fungující VPN lze několika způsoby, já proto ve své práci proto nabízím čtenáři základní přehled VPN technologií a popisuji jejich principy, aby se čtenář mohl v oblasti VPN zorientovat. Konkrétní možnosti realizace VPN uvádím pomocí vybraných softwarových řešení dostupných pro operační systémy Linux (některé jsou dostupné i pro jiné OS). Na těchto řešeních porovnávám vybrané parametry a pomocí srovnání mohu pomoci čtenáři rozhodnout, zda některé uvedené řešení využije. V kapitole následující po úvodu se zabývám virtuálními privátními sítěmi obecně a uvádím důvody, proč a k čemu lze VPN využít. Třetí kapitola nastiňuje základní, zejména bezpečnostní, požadavky na VPN sítě. V další kapitole jsou popsány jednotlivé technologie VPN, rozdělené podle příslušnosti do různých vrstev TCP/IP modelu, a také základní používané protokoly. Následující kapitoly jsou již zaměřeny na představení vybraných VPN implementací dostupných pod operační systém Linux. Jednotlivá softwarová řešení jsou ohodnocena a porovnávána podle zvolených kritérií.
8
Kapitola 2
Teoretický úvod do VPN 2.1
Co je to VPN?
Pro Virtual Private Networks (dále jen VPN), neboli česky „virtuální privátní (soukromé) sítě“ lze nalézt několik definicí. Jak již samotný název napovídá, jedná se o sítě, jejichž soukromí je umožněno či zajištěno pomocí určité formy virtualizace. Definice VPN dle konsorcia VPNC [2]: „Virtual Private Network (VPN) je privátní datová síť, která využívá veřejné telekomunikační infrastruktury a zajišťuje soukromí pomocí tunelovacích protokolů a bezpečnostních procedur.“ Další možná definice je například tato [3]: „VPN je způsob simulace soukromé sítě ve veřejné síti, jakou je například Internet. Nazývá se „virtuální“ protože závisí na použití virtuálního propojení – to je dočasné spojení, nepropojené fyzicky přímo, ale skládající se z paketů směrovaných různými stroji na Internetu, propojených ad-hoc. Virtuální spojení jsou vytvářena mezi dvěma stroji, strojem a síti nebo dvěma sítěmi.“ VPN sítě tedy umožňují vytvořit soukromé, zabezpečené spojení na veřejných linkách. Sítě VPN mohou být vytvořeny za použití příslušného softwaru, hardwaru, nebo kombinací obojího. Více o způsobu a technologiích vytváření VPN bude obsahem dalších kapitol.
2.2
Motivace
Hlavní motivací pro vytváření VPN sítí je požadavek na zajištění soukromé komunikace při využití externí již existující síťové infrastruktury. Představme si soukromou síť, například uvnitř nějaké organizace, která umožňuje bezpečnou komunikaci mezi zaměstnanci. Po nějaké době se firma rozroste a rozhodne se vybudovat další pobočku v jiné části republiky. Zároveň ale chce, aby mezi sebou mohli všichni zaměstnanci nadále bezpečně komunikovat a předávat si informace. Je v celku zřejmé, že rozšíření stávající sítě a přímé propojení obou poboček by mohlo být velice nákladné. Nastává tedy otázka, jak využít jinou, již existující infrastrukturu a pobočky tak spojit se zachováním bezpečnosti. K zajištění takové zabezpečené služby pak slouží některé technologie uvedené v dalších kapitolách mé práce, spadající pod jednotný pojem Virtual Private Network.
9
V době, kdy se zlepšily možnosti připojení k Internetu, jak technologické tak i cenové, zlepšila se také možnost vytvářet VPN pomocí Internetu. Můžeme tedy říct, že rozvoj VPN jde ruku v ruce s rozvojem Internetu. Nutno uvést, že vedle pravděpodobně nejrozšířenějšího způsobu propojení VPN pomocí Internetu, existují ještě plně privátní sítě. Využití Internetu pro VPN může mít pro určité organizace nevhodné parametry (např. nedostatečná dostupnost, spolehlivost, kvalita) a v tomto případě existuje možnost využití plně privátních sítí. Na rozdíl od VPN využívajících internetové připojení je privátní síť uzavřenou síťovou strukturou s vlastním adresovacím schématem a směrovací hierarchií dostupnou jen určité skupině uživatelů. Pokud je nutné propojit vzdálenější oblasti, využije se připojení přes pronajaté dedikované komunikační linky poskytovatelů spojových služeb (nejčastěji ATM a Frame Relay). Přes zjevné výhody v oblasti bezpečnosti jsou však plně privátní sítě oproti VPN přes Internet zejména ekonomicky náročnější. VPN sítě mohou mít 3 základní podoby a těmi jsou[1]: 1)
spojení typu uzel – uzel (nebo také bod – bod). To je dnes asi nejrozšířenější případ využití VPN. Jako příklad můžeme uvést i „obyčejné“ připojení klienta banky přes Internet k zabezpečené webové bankovní aplikaci, umožňující vzdáleně ovládat jeho účet.
Obrázek 2.1: spojení typu uzel - uzel
2)
spojení typu uzel – síť (bod – síť). Příkladem může být vzdálené připojení zaměstnanců do podnikové sítě, například na služební cestě. VPN jim umožní přístup ke všem dokumentům, ke kterým mají běžný přístup, jakoby seděli ve své kanceláři u svých podnikových počítačů. Tomuto typu připojení se také často říká „Road Warrior“ (česky „cestující válečník“) podle spojitosti, kdy je klient (zaměstnanec) nucen přistupovat do vzdálené (podnikové) sítě z neznámého („nebezpečného–válečného“) prostředí.
10
Obrázek 2.2: spojení typu uzel - síť
3)
spojení typu síť - síť. Příkladem může být výše již zmíněné propojení lokálních sítí jednotlivých poboček firmy přes Internet nebo nějakého veřejného poskytovatele spojení. Všechny počítače se pak tváří, že jsou v jedné lokální síti.
Obrázek 2.3: spojení typu síť – síť
11
Kapitola 3
Požadavky na VPN 3.1
Bezpečnost
Virtuální privátní sítě jsou vytvářeny zejména z důvodu zajištění zabezpečené a snadné komunikace všech účastníků spojení. Na prvním místě v požadavcích na VPN je tedy bezpečnost. Bezpečnost je ale poměrně široký pojem a nemá jedinou a jednoznačnou definici. Mezinárodní norma ISO [4] definuje bezpečnost takto: „Bezpečnost je zajištěnost proti nebezpečí a souhrn administrativních, logických, fyzických a technických opatření k detekci a opravě nesprávného použití daného systému“ V našem případě je daným systémem celá virtuální privátní síť. Tato uvedená definice není na první pohled příliš konkrétní a proto je lepší detailněji uvést, jaké konkrétní bezpečnostní požadavky budeme na VPN klást. Základní bezpečností požadavky jsou tyto: •
Autentizace – proces ověření, zda daná entita (uživatel) je skutečně ta, za kterou se vydává. Pro ověření totožnosti (identity) se využívá řada autentizačních metod. Mezi nejběžnější metody patří prokázání znalosti nějakého hesla, vlastnictví tajného klíče či bezpečnostního certifikátu.
•
Autorizace – proces zjištění, zda daná entita (uživatel) má oprávnění k provedení požadované operace (např. k přístupu do soukromé sítě). Autorizace nastupuje po úspěšně uskutečněné autentizaci. Pro zajištění autentizace a autorizace lze využít například bezpečnostní protokoly RADIUS (Remote Authentication Dial In User Service) nebo TACACS (Terminal Access Controller Access Control System) [5].
•
Důvěrnost – cílem zajištění důvěrnosti je zabránit nepovolaným účastníkům komunikace přečíst soukromá data. K zajištění důvěrnosti dat se využívá šifrování. Šifrování je proces, kdy se data za pomoci šifrovacího algoritmu a šifrovacího klíče zpracují do „těžko čitelné“ podoby. Možnost dešifrovat zašifrovaná data bez znalosti dešifrovacího klíče je pak dána kvalitou šifrovacího algoritmu a také délkou použitého klíče. Čím větší úsilí musíme na prolomení šifry vynaložit, tím mluvíme o silnější šifře. Mezi šifrovací algoritmy patří např. DES, 3DES, IDEA, Blowfish a další.
•
Integrita – přenesená data musí být možné získat přesně v takové podobě, v jaké byla
12
odeslána. Je důležité udržet data neporušená a mít možnost zjistit chybu a nesprávnost získaných dat. Porušení integrity dat může být následkem chybného spojení, ale také například snahou útočníka podvrhnout přenášená data. Integrita dat se zajišťuje nejčastěji pomocí šifrovacích algoritmů, hashovacích funkcí a různých opravných kódů.
3.2
Další požadavky
Další požadavky na vlastnosti VPN sítí pak mohou být některé z následujících. Vždy záleží na konkrétních požadavcích uživatelů nebo organizace, jejich seznam tedy není úplný. •
Spolehlivost a robustnost – požadavek, aby byla komunikace spolehlivá a odolná proti výpadkům.
•
Výkon – požadavek, aby síť měla dostatečnou přenosovou rychlost, malé zpoždění apod. Výkon u VPN sítí bývá často nižší než klasická komunikace, například z důvodu náročnějšího zpracování a šifrování dat.
•
Škálovatelnost – pro řadu subjektů je důležité, aby bylo možné VPN snadno a levně rozšířit.
•
další
13
Kapitola 4
Technologie VPN 4.1
Technologie používané při tvorbě VPN
Pro vytvoření VPN existuje řada technologií a využívá se řada protokolů. V této části jednotlivé technologie představím, uvedu možnosti jejich využití, případně sdělím výhody a nevýhody, které dané technologie mají.. Rozdělit jednotlivé technologie VPN lze několika způsoby, například: ●
●
dle způsobu zajištění bezpečnosti 1.
VPN se šifrováním informací (např. využití IPSec, SSL)
2.
VPN na důvěryhodných linkách (např. ATM1, Frame Relay2)
dle způsobu směrování ve VPN 1.
„peer“ model (např. BGP/MPLS) – směrovací výpočet se provádí na každém uzlu na dráze do cíle
2.
„overlay“ model (např. ATM, Frame Relay, GRE tunely) – vytvoření přímého spojení mezi dvěma (koncovými) prvky sítě.
Já podrobněji představím jednotlivé technologie z pohledu rozdělení dle funkčnosti sítě ve spojitosti s vrstvami modelu TCP/IP, které je myslím poměrně přehledné[1].
4.2
Síťový model TCP/IP
Síťový model TCP/IP (podobně jako rozšířenější model OSI) popisuje způsoby jak bude vypadat síťová propojení a komunikace. Oba síťové modely jsou rozděleny na vrstvy, kde každá vrstva má definované služby a může komunikovat s vrstvami sousedními. Model ISO/OSI je sedmivrstvý, model TCP/IP je čtyřvrstvý [6]. 1
ATM – Asynchronous Transfer Mode je standard pro vysokorychlostní síťovou architekturu používající přepínání buněk pevné délky. 2 Frame Relay - Přenosová síťová technologie, pracující s přepínáním rámců proměnné délky. Používá sestavení virtuálních obvodů mezi propojenými zařízeními [16].
14
Obrázek 3.1: vrstvy TCP/IP modelu
4.2.1
Spojová vrstva (Linková vrstva – Link Layer)
Spojová vrstva má na starosti ovládání konkrétní přenosové cesty, respektive sítě. Stará se také o přímé vysílání a příjem datových paketů. V rámci modelu TCP/IP ale není blíže specifikována, protože je závislá na použité přenosové technologii.
4.2.2
Síťová vrstva (Network Layer)
Úkolem této vrstvy je postarat se o to, aby se jednotlivé pakety dostaly od odesilatele až ke svému skutečnému příjemci. Součástí této vrstvy jsou prvky zajišťující adresaci a směrování. Hlavním protokolem této vrstvy je IP (Internet Protocol).
4.2.3
Transportní vrstva (Transport Layer)
Tato vrstva má za úkol zejména logické spojení koncových účastníků a zajištění přenosu dat mezi nimi. Přenos dat v transportní vrstvě zajišťují protokoly TCP (Trasmission Control Protocol) a UDP (User Datagram Protocol). Protokol TCP zajišťuje garantovaný přenos paketů dle správného pořadí. Protokol UDP zajišťuje negarantovaný přenos paketů.
4.2.4
Aplikační vrstva (Application Layer)
Jejími entitami jsou jednotlivé aplikace (programy), které ke komunikaci využívají vlastní protokoly. Součástí této vrstvy jsou například protokoly FTP (File Transfer Protocol), HTTP (Hyper Text Transfer Protocol) nebo SSH (Secure Shell) [6].
15
VPN dle TCP/IP modelu tak můžeme rozlišit na: ●
VPN na spojové vrstvě
●
VPN na síťové vrstvě
●
VPN na transportní vrstvě
●
VPN na aplikační vrstvě
4.3
VPN na spojové vrstvě
Technologie vytváření VPN na spojové vrstvě pracují na principu podobném vytváření plně privátních sítí na vlastních nebo pronajatých oddělených přenosových linkách. Vytvořené VPN na spojové vrstvě jsou pak nezávislé na vyšší přenosový vrstvě. Infrastrukturu těchto sítí s virtuálními obvody ve spojové vrstvě tvoří sítě ATM a Frame Relay. Za zvláštní typ VPN tvořených na spojové vrstvě můžeme považovat virtuální sítě (VLAN). Technologie virtuálních sítí vznikla původně pro prostředí ethernetových přepínačů, ale používá se i v sítích ATM a Frame Relay.
4.3.1
Virtuální sítě pomocí LAN emulace
Virtuální sítě VLAN lze vytvářet technologií emulace LAN a to dvěma způsoby, v závislosti na způsobu připojení sdílených serverů k ATM [1]: 1)
Sdílené servery jsou připojeny k páteřní síti přímým ATM připojením. K vytvoření virtuální sítě VLAN mezi uzly, musíme použít technologii emulovaných lokálních sítích LANE (LAN Emulation). Základní funkcí LANE je emulace LAN nad ATM sítí. LANE protokol definuje rozhraní pro protokoly vyšší (síťové) vrstvy. Pakety těchto síťových protokolů jsou pak posílány přes ATM síť a zapouzdřeny v LANE MAC rámcích. LANE protokol tedy umožňuje, aby ATM síť vypadala jako síť typu Ethernet nebo Token Ring. Základ LANE tvoří prvky LES (LAN emulation server), mapující MAC adresy na ATM adresy, a LEC (LAN emulation client) rozhraní, které musí obsahovat každý člen emulované LAN (ELAN). Podle požadavků jednotlivých LEC, překládá LES MAC a ATM adresy . Poté spolu mohou jednotliví klienti LEC komunikovat. Protože klient LEC může být členem více sítí ELAN, standard LANE umožňuje vytvoření více překrývajících se virtuálních sítí. Tak mohou uzly z různých ELAN přistupovat ke společným síťovým zdrojům bez nutnosti průchodu přes směrovač. Členy ELAN mohou být jen uzly ATM, zatímco členy VLAN mohou být jak uzly ATM, tak i uzly na standardních segmentech. Na členy ELAN tak můžeme pohlížet jako na podmnožinu VLAN. Protože v jedné ATM síti se může vyskytovat více ELAN, je nutné zajistit jejich
16
propojení. To je zajištěno pomocí směrovačů. Směrování datových paketů pak probíhá stejným způsobem jako u standardních sítí. Jednotlivým ELAN jsou přiřazena různá čísla a podle adresy cíle LEC pak pozná, že paket není lokální (cíl není na stejné ELAN) pošle jej na hlavní směrovač dané ELAN sítě, který paket nasměruje do cíle. 2)
4.3.2
Technologie ATM je použita pouze na páteřních přepínačích ale ve vlastní síti nejsou žádné koncové uzly ATM. V tomto případě je prostředí páteře ATM pro virtuální sítě zcela transparentní. Připojené LAN přepínače komunikují mezi sebou bez toho, že by si „uvědomovaly“ existenci ATM sítě mezi sebou
MPOA (Multiprotocol over ATM)
Protokol MPOA (Multiprotocol over ATM) byl vyvinut z cílem integrovat směrování sítí ATM a umožnit jejich spolupráci se sítěmi jiného typu. MPOA je nadstavbou technologie LANE. V MPOA (Multiprotocol over ATM) sítích se ke směrování paketů používají tzv. „virtuální směrovače“. Virtuální směrovače emulují funkci tradičních směrovačů a používají směrovací techniku „cut-through“. Touto technikou se datový tok mapuje přímo do přímého virtuálního spojení přes ATM síť a pakety se nemusí zpracovávat při průchodu v každém směrovači, jako je to u techniky „hop-by-hop“. Může tak dojít k nárůstu výkonu díky menšímu počtu zpracování paketů na každém směrovači. Princip MPOA Princip MPOA standardu vychází z rozdělení funkcí tradičního víceprotokolového směrovače, tedy oddělení výpočetního zpracování směrování od vlastního fyzického směrování (přenosu) paketů mezi jednotlivými podsítěmi. Výpočetní zpracování (správa adres apod.) je prováděno MPOA serverem (MPS) a vlastní fyzické směrování paketů provádí koncová zařízení MPOA Clients (MPC) podle pokynů MPS. Funkce MPS je integrována přímo do ATM přepínačů nebo funguje jako samostatný směrovací server s ATM připojením. Funkce MPC je zabudována do okrajových ATM přepínačů a do připojených ATM stanic. Zařízení provádějící směrovací výpočty jsou tím fyzicky oddělena od zařízeních provádějící vlastní fyzické přenosy. Výhoda MPOA technologie je v dynamicky vytvářených virtuálních obvodech mezi koncovými uzly, které vyžadují méně nákladnou konfiguraci. Nedostatkem MPOA sítě z pohledu VPN je omezení, dané nutností použit jednotného ATM prostředí jako přenosové technologie na spojové vrstvě.
4.3.3
MPLS (Multiprotocol Label Switching)
MPLS (Multiprotocol Label Switching) je hybridní technologie, která integruje dva základní přístupy k tvorbě VPN: •
směrování na síťové vrstvě a přepínání paket po paketu
•
vytvoření virtuálních obvodů na spojové vrstvě a přepínání podle datových toků.
17
Integruje se tak směrování na síťové vrstvě s tzv. přepínáním podle značek (label switching).Vlastní přepínání podle značek funguje na tomto principu: Přenášená data jsou nejprve označena pomocí speciálních značek. Značky jsou přiděleny na základě různých kritérii (např. cílová adresa nebo příslušnost k určité VPN). V rámci přenosu v MPLS síti se pak data směrují podle těchto značek (ne podle adresy). Podle těchto značek a směrovací tabulky se směrovače rozhodují, kam data přenášet. Po přenosu na koncový prvek MPLS jsou již data dále směrována klasicky podle cílové adresy MPLS není svázána s žádnou specifickou technologií spojové vrstvy a může pracovat s libovolným médiem, po kterém se dají přenášet síťové pakety. VPN vytvořená pomocí MPLS mají tři základní složky: 1)
řízenou distribuci směrovacích informací jako způsob vytvoření VPN a řízení vzájemného propojení mezi nimi
2)
použití identifikátorů (VPN ID) pro jednotlivé virtuální sítě a jejich provázanost s IP adresami k jejich (potenciální) změně na unikátní adresy;
3)
využití přepínání podle značek (MPLS) na směrování paketů cestami, vytvořenými pomocí bodů (1) a (2).
Shrnutí Architektura MPLS je založena na aplikaci značek na paket, vstupující do sítě MPLS. Tím se pro daný paket určí sekvence přepínačů, kterými musí projít na své cestě mezi koncovými uzly a výstupními směrovači. Rozšířením této architektury z hlediska VPN je zavedení globálního identifikátoru CUG (Closed User Group identifier). Tento identifikátor může být přiřazen paketu při vstupu do MPLS sítě a pak použit jako index ve směrovací tabulce pro VPN k určení počáteční značky. Na výstupu ze sítě MPLS je pak CUG znovu použit jako index v globální tabulce VPN k určení výstupního směrovače.
4.4
VPN na síťové vrstvě
4.4.1
Filtrování směrovacích informací
VPN s filtrováním směrovacích informací je založené na principu omezení zveřejnění směrovacích informací o dosažitelnosti jiných sítí. V tomto případě směrovač, zastupující skupinu uzlů VPN, navazuje spojení s předáním směrovacích informací pouze se vstupním směrovačem sítě poskytovatele spojení a ne se všemi okolními sítěmi. Informace o dostupnosti, či přímo existence, sítě VPN tak nejsou vůbec zveřejňovány ostatním sítím, které do VPN nespadají. Představu o způsobu použití filtrování směrovacích informací přiblíží následující obrázek.
18
Obrázek 3.2: VPN s využitím filtrování směrovacích informací
Hlavním problémem při vytváření VPN s využitím filtrování směrovacích informací je zajistit bezpečnost filtrujícího zařízení, které umožňuje směrování do externích oblastí mimo VPN. Toto zařízení připojující VPN k externím sítím (např. k Internetu) je pak jakási „strážená brána do externího světa“ a většinou se jedná o nějaký typ firewallu umožňující potřebné bezpečností funkce a pravidla (např. překlad adres NAT, protože celá VPN musí využívat přidělený jedinečný adresový prostor). Je také nutné zabezpečit, aby všechny stroje uvnitř sítě VPN neměly jinou možnost propojit se s externími sítěmi jinak, než přes takto zabezpečená zařízení. V případě napadnutí jednoho stroje připojeného přes nezabezpečené zařízení by byla ohrožena celá síť.
4.4.2
VPN s využitím tunelů
Další metody budování VPN jsou založeny na takzvaných tunelech. Jak název napovídá, při vytváření spojení mezi stroji ve VPN se (v nezabezpečené) části sítě vytvoří tunel, ve kterém pak komunikace probíhá a je od externí komunikace oddělena. 4.4.2.1
GRE tunely
Nejčastějším používaným způsobem klasického tunelování pro spojení mezi zdrojovým a cílovým směrovačem je využití protokolu GRE (Generic Routing Encapsulation) vyvinutého firmou Cisco.
19
Tunely GRE jsou budovány směrovači, které slouží jako vstupní a výstupní body do páteřní sítě pro jednotlivé části VPN. Speciálně zabalené pakety přenášené tunelem obsahují přídavnou GRE hlavičku (GRE Header) a cílovou adresu, odpovídající směrovači na konci tunelu. V koncovém bodě tunelu dojde k rozbalení paketu a následné směrování paketu do cíle již pokračuje podle informací ve své původní IP hlavičce.
Cílová hlavička Původní paket
GRE hlavička Původní paket
Obrázek 3.3: vytvoření GRE paketu
GRE tunely jsou obecně typu bod - bod, tzn., že pro tunel existuje jen jedna zdrojová a jedna cílová adresa. Některé firemní implementace však umožňují konfiguraci bod – více bodů, tedy existenci více cílových adres.
Obrázek 3.4: tunelování GRE [1]
Výhodou této implementace je jednoduchá možnost oddělení adresace. Všechny přístupové body do páteřní sítě a zároveň koncové body vytvořených tunelů, používají adresaci a směrování společné páteřní sítě. Technika tunelování používá adresaci koncových bodů tunelů z adresového prostoru páteřní sítě a pakety přenášené tunelem, používají adresy z adresového prostoru VPN.
20
Tím dojde k odstínění obou adresových prostorů a směrování v obou sítích jsou od sebe izolována. Díky tomu můžeme použít v rámci VPN (vícenásobně) privátní adresový prostor pro více VPN na společné sdílené síti. Díky využití tunelů můžeme také přenášet v podstatě libovolný síťový protokol beze změny, dochází tak k simulaci privátní dedikované sítě. Nevýhodou využití tunelů k vytváření VPN je administrativní náročnost a škálovatelnost, především při vytváření většího počtu tunelů, zejména typu uzel – síť. Všechny GRE tunely musí být předem (manuálně) zkonfigurovány. V závislosti na velikosti sítě a počtu vytvářených tunelů tak vzrůstá náročnost na konfiguraci a údržbu tunelovaných spojení. Problémem může být také nedostatečný výkon koncových bodů tunelů zajišťujících zpracování velkého počtu paketů. A další nevýhoda také spočívá v absenci přímé implementace bezpečnostních mechanismů (šifrování). 4.4.2.2
VPN s komutovaným přístupem
Další typ VPN s využitím tunelů, jsou sítě s komutovaným přístupem VPDN (Virtual Private Dial Networks). Tyto sítě se využívají u spojení VPN typu klient – server . U sítí s komutovaným přístupem se využívají převážně dva standardy [1], [5]. 1)
PPTP (Point-to-Point Tunneling Protocol) Protokol PPTP byl vytvořen společnostmi US Robotics, Microsoft, 3COM, Ascend Communications a ECI Telematics. Specifikován je v RFC3 2637, ale standardizován dle IETF (Internet Engineering Task Force [10]) není. PPTP pro svou činnost využívá protokol PPP (Point-to-Point protocol), který zajišťuje vzdálený přístup mezi dvěma body. PPTP nad tímto protokolem vytváří klientem inicializované tunely. Původní paket je nejprve obalen do PPP, dále pak do upravené verze GRE protokolu a nakonec předán protokolu IP, který okolo něho vytvoří ještě jednu hlavičku, aby mohl být správně přenesen.
3
RFC (Request For Comments) – soubor dokumentů definujících internetové standardy, spravovaný sdružením IETF [17]
21
Původní IP
IP hlavička
GRE hlavička
PPP hlavička
Původní IP zašifrovaný
PPP hlavička
Původní IP zašifrovaný
Obrázek 3.5: vytvoření paketu v PPTP
Vytvoření PPTP tunelu probíhá ve dvou krocích: 1.
Uživatel se s pomocí PPP spojení připojí k přístupovému serveru, zde je ale dané PPP spojení ukončeno.
2.
Následně se spustí PPTP klient a nad TCP portem 1723 se vytvoří PPTP řídící spojení s požadovaným PPTP serverem dosažitelným v rámci standardních směrovacích informací a ke kterému má klient přístupová práva. PPTP tunel je tedy vytvořen PPTP serverem bez následné účasti přístupového serveru.
Pro autentizaci se využívají funkce protokolu PPP, který podporuje protokoly PAP (Password Authentication Protocol), CHAP (Challenge Handshake Authentication Protocol), nebo MS-CHAP (Microsoft Challenge Handshake Authentication Protocol), případně novější verze MS-CHAPv2. Pro šifrování se využívá protokol MPPE (Microsoft Point-to-Point Encryption) pracující s algoritmem RSA RC4 a s klíči o délce 40-128bit. Pro kompresi lze využít protokol MPPC (Microsoft Point-to-Point Compression).
Obrázek 3.6: VPN pomocí PPTP [1]
22
Omezení protokolu PPTP Protokol PPTP je velice rozšířen a to zejména díky společnosti Microsoft, která ho plně propaguje ve svých produktech. PPTP klient je již součástí jejich operačních systémů. Proto jsou VPN sítě realizované na protokolu PPTP často k vidění u firem s požadavkem na snadný přístup řadových zaměstnanců do podnikové sítě „odkudkoliv“ a bez složité instalace přístupových klientů. Tato vlastnost (snadná rozšiřitelnost a jednoduchá implementace na straně klienta) je často největším důvodem pro využití PPTP, bohužel ale tento protokol má jednu velkou nevýhodu. Vlastní standard protokolu PPTP totiž přesně nedefinuje, jakým způsobem má probíhat autentizace a šifrování dat. Může se tedy stát, že dvě zařízení různých výrobců s podporou PPTP spolu nebudou moci komunikovat, protože zajišťují autentizaci či šifrování jiným způsobem. Zranitelnost PPTP Firma Counterpane Internet Security, založená Brucem Schneierem (mj. spoluautorem šifrovacích technologií Blowfish a Twofish), zveřejnila informace o zranitelnosti protokolu PPTP. Dle Schneiera a Mudge, kteří se podrobně zabývali implementací PPTP od společnosti Microsoft, je autentizační protokol slabý a je napadnutelný slovníkovým útokem. Většinu hesel lze bezproblémově odhalit během několika hodin a problém se týká obou typů šifrování (40-bitového i 128-bitového). Mimo to lze v návrhu nalézt i řadu dalších chyb, díky kterým lze proti možnému šifrování vést další útoky. Není problém zneužít mechanismus dohody spojení v PPTP a otevřít si tak jeho spojení. Proti uživatelům PPTP od Microsoftu se tak snadno dá vést několik vážných útoků s odepřením služeb [5]. Na závěr nutno připomenout, že uvedená zranitelnost se netýká protokolu PPTP jako takového, ale jeho konkrétní implementace (autentizačního protokolu Microsoft CHAP, MS-CHAPv2) v operačních systémech Windows, která je špatně navržená. Vzhledem k možnostem použít i jiné šifrovací a autentizační mechanizmy, nelze protokolem PPTP zcela opovrhovat. Bližší informace k uvedené analýze lze nalézt na stránkách B. Schneiera [7], [8] 2.
L2TP (Layer 2 Tuneling Protocol) Novější model L2TP vychází ze staršího standardu L2F (Layer 2 Forwarding) od společnosti Cisco Systems a ze specifikace PPTP od Microsoftu. Protokol L2TP je popsán v RFC 2661. Varianta využívající navíc protokolu IPSEC pro zajištění důvěrnosti se nazývá L2TP/IPSEC a je popsána v RFC 3193 [1], [5].
23
Původní IP
IPSec ESP hlavička
PPP hlavička
Původní IP
UDP hlavička
L2TP hlavička
PPP hlavička
Původní IP
UDP hlavička
L2TP hlavička
PPP hlavička
Původní IP zašifrovaný
IPSec ESP trailer
Obrázek 3.7: vytvoření L2TP/IPSEC paketu
Základními dvěma prvky protokolu L2TP jsou přístupový koncentrátor L2TP Access Concentrator (LAC), ve kterém je fyzicky zakončen vytáčený hovor, a síťový server L2TP Network Server (LNS), který zakončuje a případně autentizuje datový proud. Vytvoření tunelu pro připojení uživatele to podnikové sítě probíhá takto. 1.
Uživatel zahájí PPP spojení k poskytovateli spojení (ISP).
2.
Přístupová koncentrátor (LAC) toto spojení přijme.
3.
Uživatel si se síťovým serverem (LNS) dohodne parametry protokolu LCP (Line Control Protocol) a opět přístupový koncentrátor LAC provede částečnou autentizaci uživatele. K autentizaci může LAC využívat zvlášť připojeného autentizačního serveru (např. RADIUS).
4.
Pokud uživatel není právoplatným klientem sítě VPN, klient není připuštěn ke koncovému bodu (LNS). Pokud je autentizace úspěšná, klient je nasměrován na koncový bod (LNS).
5.
Nyní dojde k vytvoření obou konců tunelu mezi LAC a LNS.
6.
Po vytvoření daného VPN tunelu se vytvoří komunikační relace L2TP, přes kterou koncový uživatel vstoupí do podnikové sítě.
24
Obrázek 3.8: VPN pomocí L2TP [1]
Výhody protokolu L2TP: •
L2TP je postaven na standardech, a je tak zajištěna lepší spolupráci různých zařízení L2TP od různých výrobců.
•
podpora víceprotokolových prostředí. (L2TP umožňuje přenášet různé směrovací protokoly jako IP, IPX či AppleTalk). Dále L2TP podporuje veškeré přenosové technologie v sítích WAN sítích jako je Frame Relay, ATM, X.25 a SONET
•
za šifrování je odpovědný standardizovaný protokol IPSec. Je tedy zajištěna autentizace, integrita dat, důvěrnost dat, případně ochrana proti opakování relace (ochranu proti opětovnému zasílání proudu zachycených, tzv. Replay Attacs ).
Srovnání PPTP a L2TP Protože protokol L2TP vychází z protokolu PPTP, mají řadu společných vlastností, zejména to, že oba jsou postaveny na protokolu PPP. Dále oba protokoly zajišťují funkce tunelování a zapouzdření, takže po síti IP je s nimi možné zasílat zátěž PPP nad libovolným protokolem. Proces spojení PPP využívají také k autentizaci uživatelů a vlastní konfiguraci. V tomto se naopak liší: •
Protokol PPTP umožňuje autentizaci, kompresi a šifrování, ale samotný protokol L2TP šifrování dat neobsahuje, to umožňuje až zkombinovaný protokol L2TP/IPSec.
•
Protokolu PPTP zahajuje šifrování až po dokončení procesu spojení PPP (po autentizaci PPP). Protokol L2TP/IPSec využívá šifrování dat již před procesem spojení PPP.
•
Protokol PPTP vyžaduje pouze autentizaci na úrovni uživatele, zatímco L2TP kromě ní požaduje navíc také autentizaci počítače, definovanou certifikátem.
•
Protokol PPTP nemá problémy se sítěmi s NAT (překlad síťových adres). V případě protokolu L2TP je k použití sítí s NAT nutné, aby strany podporovali
25
NAT-T (IPSec NAT Traversal)
PPTP
L2TP/IPSec klady
• • •
• • •
Jednoduchost Podpora NAT Zabudovaná podpora v OS Microsoft a tudíž velká rozšířenost
•
zápory Není možné zjistit skutečného původce • paketu Ne zcela standardizovaná specifikace • Problémy se zabezpečením u OS Microsoft
Bezpečnost (dvojí autentizace)
Složitost Problémy s NAT
Tabulka 3.1: srovnání PPTP a L2TP/IPSec
4.4.3
VPN s využitím šifrování na síťové vrstvě
Vytvářet VPN lze také s pomocí šifrování na síťové vrstvě. 4.4.3.1
Protokol IPSec
Architektura IPSec (IP Security) představuje v současnosti jedno z nejlepších řešení pro budování VPN [5], [9]. IPSec využívá různé kryptografické technologie a zajišťuje: ●
důvěrnost (např. pomocí šifrování DES, 3DES, AES)
●
integritu (např. pomocí hashovacích funkcí MD5, SHA)
●
autentizaci
Architektura IPSec tak, jak existuje v současné době, je vlastně souhrnem několika protokolů definovaných sdružením IETF (Internet Engineering Task Force [10]). IPSec je implementován jak v IPv4, tak povinně i v IPv6. IPSec je definován v řadě RFC již od roku 1995 a mezi základní dokumenty patří RFC 2401 a 2411. Základ tvoří protokoly AH (Autentification Header) a ESP (Encapsulating Security Payload). Tyto protokoly pozměňují původní IP hlavičky paketů a celkově paket zabezpečují. •
Protokol AH zajišťuje integritu dat a autenticitu odesílatele, nezajišťuje však šifrování dat. Pomocí jednosměrného hashe vytváří z paketu pouze otisk dat. Ke generování otisku se používají algoritmy SHA1 nebo MD5. AH také umožňuje ochranu před opakováním relace (tzv. Replay Attack), tedy zachytávání paketů útočníky s cílem zmatení příjemce či vyřazení příjemce z provozu. AH v sobě nese pořadové číslo paketu (tzv. Sequence number field).
26
Původní IP paket IP hlavička
IP data
AH v transportním módu IP hlavička
AH hlavička
IP data
Autentizováno
AH v tunelovacím módu Nová IP hlavička
AH hlavička
IP hlavička
IP data
Autentizováno Obrázek 3.9: IPSec AH
•
Protokol ESP zajišťuje autenticitu odesílatele, integritu dat a také šifrování. Standardně se data šifrují pomocí DES, ale protože se tento algoritmus již nepovažuje za zcela bezpečný, využívá se častěji jeho vylepšená varianta 3DES. Není ale vyloučeno použít i jiné algoritmy (např. Blowfish). Původní IP paket IP hlavička
IP data
ESP v transportním módu IP hlavička
ESP hlavička
IP data
ESP trailer
ESP auth
IP data
ESP trailer
Šifrováno Autentizováno ESP v tunelovacím módu Nová IP hlavička
ESP hlavička
IP hlavička
ESP auth
Šifrováno Autentizováno Obrázek 3.10: IPSec ESP
27
Požadované zabezpečené spojení je uskutečněno vytvořením šifrovaného tunelu mezi dvěma koncovými zařízeními (router, firewall apod.). V IPSec existují dva režimy šifrování. Oba se liší svým uplatněním a také objemem režie, doplněným k přenášenému paketu. •
Transportní mód – původní IP hlavička je zachována a upravuje se (šifruje) pouze datová část paketu. Výhodou transportního módu jsou nižší nároky na přenosové pásmo. Tím, že jsou k dispozici informace o cílovém zařízení, lze rovněž během přenosu paketu sítí aplikovat některé nadstandardní mechanismy (např. kvalita služeb – QoS). Transportní mód se nejčastěji používá při autentizaci vzdálených klientů VPN.
•
Tunelovací mód – původní data spolu s IP hlavičkou jsou zabalena a chráněna v nově vytvořeném IP paketu. Nový paket obsahuje IP adresu odesílatele a příjemce z transportní IP sítě. Tunelovací mód může spolupracovat s oběma protokoly (ESP i AH). V současnosti se tento mód používá častěji.
Bezpečnostní asociace (Security Association, dále jen SA) Aby bylo možné zapouzdření a vybalení paketu s AH nebo ESP je potřeba tajný klíč, algoritmus a další údaje. Tyto informace jsou uloženy právě v Security Association. SA zavádějí vztah důvěry mezi dvěma partnerskými zařízeními a koncové body sítě VPN se pomocí nich dohodnou na přenosových pravidlech. SA si vzájemně potvrzují zásady (tzv. politics) s potenciálním partnerem, jaké parametry bude navazované spojení mít. SA obsahují: •
zdrojovou a cílovou IP adresu nebo rozsah adres
•
IPSEC protokol (AH nebo ESP), případně IPComp pro komprimaci
•
algoritmus a tajný klíč
•
security parameter index (SPI) – jednoznačná identifikace SA zapsaná jako 32-bitové číslo v hlavičce paketu
dle implementace mohou některá SA navíc obsahovat: •
IPSEC mód (tunel nebo transport)
•
životnost SA, klíče
•
velikost posuvného okna (u obrany proti Replay Attacs)
Jednotlivé množiny SA jsou pak uloženy v centrální databázi Security Assocciation Database (SAD). SA pouze specifikuje jak IPsec chrání datový provoz. Další informace je potřebná pro definování toho, který datový provoz chránit. Tato informace je uložena v Security Policy (SP), které je uloženo v databázi Security Policy Database (SPD). Security Policy obvykle určuje tyto parametry:
28
•
Zdrojová a cílová adresa paketů, které se mají chránit. V transportním módu jsou to stejné adresy jako v SA. V tunelovém módu se mohou lišit.
•
Protokol a port, jež se mají chránit. V některých případech, kdy nelze tyto údaje definovat se chrání veškerý datový provoz mezi uvedenými adresami.
•
SA, které se má použít pro ochranu paketů.
Rozlišujeme dva typy bezpečnostních asociací: •
Pro prvotní dohodu klíčů, autentizaci partnerů a vytvoření bezpečného komunikačního kanálu, tzv. Internet Key Exchange SA.
•
Pro vlastní komunikaci v IPSec (IPSec SA). Asociace IPSec SA jsou jednosměrné a je proto nutné zavést samostatné SA pro každý směr.
Ve virtuální soukromé síti musí být tajné klíče a šifrovací algoritmy sdílené mezi všemi účastníky komunikace. Bezpečně nastavit SA a vyměnit tajné symetrické klíče můžeme opět dvěma způsoby: •
ruční konfigurací. Toto řešení ale není příliš pohodlné a je poměrně náchylné na chyby. Dohodnutí a nastavení SA tak musí VPN partneři provést před spuštěním síťového provozu. Předem dohodnuté klíče se také špatně mění a často zůstávají původní po dlouhou dobu, což snižuje bezpečnost.
•
s využitím protokolu IKE (Internet Key Exchange). Pomocí protokolu IKE popsaného dále lze autentizovat (ověřit) partnery komunikace a zároveň spravovat bezpečnostní klíče a jejích výměnu.
Protokol IKE zajišťuje dohodu klíčů, autentizaci partnerů, správu klíčů a jejich výměnu. Je to obousměrný protokol a vytváří bezpečný komunikační kanál mezi oběma zařízeními, která se dohodnou na šifrovacím algoritmu, hashovacím algoritmu, autentizační metodě a případných informacích o skupině. Výměna klíčů vychází z algoritmu Diffie-Hellman, případně vylepšená verze STS (Station-To-Station) s obranou proti útokům typu „Man in the middle“ (útočník odposlouchává pakety v síti a upravené je vkládá zpět do komunikačního proudu). IKE protokol funguje ve dvou fázích. V první fázi se vytváří tzv. ISKAMP SA, jejímž cílem je dohodnutí parametrů přenosu pro vzájemnou komunikaci. Po dohodnutí a zavedení bezpečnostního kanálu se přejde na fázi druhou, ve které se za pomoci dohodnuté ISKAMP SA ustanoví další bezpečnostní parametry a zavedou jednotlivé IPSec SAs nutné pro vlastní přenos uživatelských dat. Internet Security Association and Key Management Protocol (ISAKMP) je systém, který definuje mechanismus implementace protokolu výměny klíčů a dohody o zásadách zabezpečení. ISAKMP slouží pro bezpečnou výměnu parametrů SA a tvorbu a správu bezpečnostních klíčů v IPSec. V současné době podporuje ISAKMP jediný protokol a to IKE [5].
29
Shrnutí VPN založená na protokolu IPsec jsou díky implementaci na síťové vrstvě lehce škálovatelná. Protože k šifrování dochází právě na síťové vrstvě, není tak zabezpečení vázáno na konkrétní aplikace (např. na rozdíl od SSL) a budovaná VPN může být platformě nezávislá. Navíc lze IPSec použít i v kombinaci s jinými VPN řešeními (GRE, L2TP [1]).
4.5
VPN na aplikační a transportní vrstvě
Pro vytváření VPN na vyšších vrstvách TCP/IP modelu, tedy aplikační a transportní vrstvě se nejčastěji využívá bezpečnostní protokol SSL původně vyvinutých společností Netscape Communications.
4.5.1
Protokol SSL (Secure Socket Layer)
Bezpečnostní protokol SSL definuje způsob šifrování a autentizaci komunikujících stran. Protokol TLS (Transport Layer Security) je následovníkem protokolu SSL a ve své verzi 1.0 je, až na malé rozdíly, s SSL ve verzi 3.0 totožný. Často se proto uvádí složený zápis SSL/TLS. Pro zajištění bezpečnosti využívá protokol SSL asymetrickou a symetrickou kryptografii. Před vlastním přenosem si obě strany (aplikace) ověří totožnost pomocí asymetrické kryptografie (za pomoci veřejných a soukromých klíčů). Po úspěšné autentizaci dále pokračují v komunikují pomocí symetricky šifrovaných zpráv (např. s využitím algoritmů 3DES, RC4). Integrita přenášených dat pak bývá zajištěna pomocí hashovacích funkcí (např. SHA, MD5). Řešení VPN pomocí SSL má řadu výhod. Jednou z nich jsou nízké náklady na provoz. Šifrovaná data přenáší samotná aplikace, která SSL implementuje a bývá jí často webový prohlížeč. V podstatě všechny dnešní webové prohlížeče SSL podporují a v případě využití prohlížeče jako VPN klienta, odpadá problém s instalacemi samostatných softwarových klientů. To ulehčuje práci správcům takovýchto VPN. Klienti mohou přistupovat do VPN sítí z různých počítačů, které mají v danou chvíli k dispozici bez starostí se sháněním a instalací VPN klientů. V takových případech je ale nutné uživatele poučit o nebezpečí využití neznámých a zejména nedůvěryhodných počítačů. Neznámé počítače mohou obsahovat špiónské programy, či jiný nebezpečný software, který by mohl odhalit přístupové heslo do sítě VPN a mohla by být bezpečnost sítě ohrožena. Existují však také SSL VPN řešení umožňující vzdálenou kontrolu parametrů přistupujících počítačů (např. kontrolu verze operačního systému, běžícího firewallu a antiviru) a podle získaných informací umí nastavit přístupová práva a služby pro vzdálené uživatele. Přesto je lepší používat pouze důvěryhodné a zabezpečené počítače a v určitých případech omezit přístup jen na méně citlivá data a služby. Nevýhoda využití SSL VPN pomocí webových prohlížečů může být také skutečnost, že tato řešení můžou podporovat pouze omezené komunikační služby (přenos souborů, e-mail apod.). Pro zajištění více služeb je nutné využít speciálních instalovaných VPN klientů. Takové sítě jsou srovnatelné s „tradičními“ VPN řešeními, ale za cenu ztráty snadné rozšiřitelnosti VPN.
30
Shrnutí SSL VPN naleznou využití převážně pro spojení typu bod – bod, pro propojení menších sítí a zejména pro připojení cestujících uživatelů k firemním sítím (bod – uzel). Pro spojení rozsáhlých sítí vzdálených poboček se příliš nepoužívají.
31
Kapitola 5
VPN řešení Pro tuto práci jsem vybral pět softwarových VPN řešení, které jsem otestoval a v této kapitole je představím.
5.1
Testovací sestava
Vybraná řešení byla instalována a testována na jednoduché, isolované 100Mbit lokální síti tvořené dvěma počítači spojené UTP kabelem přes switch. Na obou strojích byl instalován operační systém UBUBTU Linux v nejnovější verzi 7.04 Feisty Fawn, se kterým mám dobré zkušenosti. Tato linuxová distribuce vychází ze známe distribuce Debian a přesto, že je poměrně mladá (od roku 2004), stala se oblíbenou pro svoji uživatelskou přívětivost a dobrou komunitní podporu, která je schopná a ochotná pomoci. Počítač č. 1 (server): Stolní PC • procesor: AMD Athlon 2500+, jádro Barton • operační paměť: 512 MB RAM • síťový adaptér: Intel 211143-Based PCI Fast Ethernet Adapter 100Mbit • používaná IP adresa: 192.168.0.1 • používaná IP adresa ve virtuální síti: 10.0.0.1 • operační systém: UBUBTU Linux 7.04 Feisty Fawn, verze jádra 2.6.20-15 Počítač č. 2 (klient): Notebook • procesor: Intel Celeron 2,4 GHz • operační paměť: 494 MB RAM • síťový adaptér: Realtek TRL8139/810x 100Mbit • používaná IP adresa: 192.168.0.5 • používaná IP adresa ve virtuální síti: 10.0.0.2 • operační systém: UBUBTU Linux 7.04 Feisty Fawn, verze jádra 2.6.20-15 Další použité prvky: • switch: Ovislink Live-FSH5R
32
5.2
VPN řešení
VPN řešení jsem vybíral s hlavním požadavkem na funkčnost v operačním systému Linux. Některé testované aplikace jsou dostupné i pro jiné operační systémy, v nich se může instalace a konfigurace lišit. Případným zájemcům o zmíněné aplikace proto doporučuji navštívit domovské webové stránky, kde se dozví více informací a naleznou podrobnější návody, rady nebo řešení možných problému, které se mohou při provozování VPN vyskytnout. Nutno poznamenat, že uváděné informace jsou dostupné většinou pouze v anglickém jazyce.
5.2.1
OpenVPN
Domovská stránka: http://openvpn.net/ OpenVPN je široce konfigurovatelné VPN řešení, umožňující propojení dvou a více sítí. OpenVPN je open source řešením a je licencován dle GPL (General Public Licence), je tedy dostupné zdarma. hlavní charakteristika[11]: • pro zabezpečení se využívá technologie protokolů SSL/TLS. • pro komunikaci se využívá virtuální zařízení TUN/TAP • dostupnost pro řadu OS (Linux, Windows 2000/XP, OpenBSD, FreeBSD, NetBSD, Mac OS X a Solaris) • podpora režimů 1:1 (tunel) nebo N:1 (režim klient/server) • autentizace za použití sdíleného klíče případně X.509 certifikátů • odolnost při použití na nekvalitních linkách • volitelná komprese • snadná konfigurace • standardně používá pro přenos UDP protokol, ale lze použít i TCP • komunikace probíhá na jediném portu (snadno se nastavuje firewall) OpenVPN je řešení pracující na technologii zabezpečení komunikace pomocí protokolů SSL/TTL. K šifrování lze použít jakýkoliv algoritmus dostupný v použité SSL knihovně. Zabezpečení je tak na vysoké úrovni. Je dokonce možné nastavit velikost replay-window jako obranu proti útokům Replay Attacs. OpenVPN démon běží v uživatelském režimu a komunikuje prostřednictvím rozhraní TAP (univerzální síťový ovladač poskytující ethernetové rozhraní) nebo TUN (univerzální síťový ovladač poskytující dvoubodové rozhraní), která jsou nyní standardní součástí linuxových distribucí. Vytvořená TUN či TAP rozhraní všechna přijatá data předávají uživatelskému procesu, který vystupuje v roli síťové karty. Pro komunikaci se implicitně používá protokol UDP (je možné využít i TCP) a vše probíhá na jediném portu, snadno se tedy konfiguruje firewall.
33
Instalace Instalace je poměrně jednoduchá. Nejjednodušší je instalace pomocí stáhnutého balíčků pro danou distribuci. Já jsem program stáhnul z domovských stránek ve formě zdrojového kódu a nainstaloval pomocí trojice standardních příkazů: ./configure make make install
Před instalací je nutné mít nainstalovanou knihovnu Openssl a pokud chceme používat kompresi, tak také knihovnu LZO. 1.
Model propojení bod – bod s využitím sdíleného klíče.
Vytvoření tunelu mezi dvěma stranami s použitím sdíleného klíče je jednoduché.[11] Níže uvedený příklad je pro nejjednodušší přímé propojení pouze dvou počítačů. Mezi těmito stroji nyní popíši vytvoření šifrovaného a komprimovaného tunelu se sdíleným klíčem. Nejprve vygenerujeme tajný klíč, na počítači č. 1, pomocí: openvpn --genkey --secret /etc/openvpn/secret.key
Po bezpečné cestě ho dopravíme na druhý počítač. Na počítači č. 2 vytvoříme konfigurační soubor s příponou .conf, např. /etc/openvpn/vpn.conf, který bude mít tento obsah (řádky s # jsou komentáře, nemusí být součástí souboru): #adresa vzdálené strana remote 192.168.0.1 #nastavení IP adresy ve VPN a síťové masky ifconfig 10.0.0.2 255.255.255.0 #číslo portu port 5001 #protokol proto udp #typ a číslo virtuálního zařízení tun/tap dev tun #soubor se sdíleným klíčem secret /etc/openvpn/secret.klic ping 10 #použití lzo comp-lzo #upovídanost OpenVPN verb 6 mute 10 user openvpn
34
group openvpn
Stejný konfigurační soubor vytvoříme (zkopírujeme) na počítač č. 1, ale níže uvedené řádky změníme: remote 192.168.0.5 ifconfig 10.0.0.1 255.255.255.0
A nakonec VPN spustíme příkazem: openvpn --config /etc/openvpn/vpn.conf
V systémech se nám objeví zařízení tap0 se zvolenými IP adresami. Od této chvíle je komunikace mezi stroji šifrována a v tomto případě také komprimována 2
Model propojení klient – server s využitím certifikátů.
OpenVPN od verze 2.0 umožňuje pracovat také v režimu klient/server. Lze tedy tento software využít například pro vytvoření podnikového VPN serveru, který umožní přistupovat více zaměstnancům do lokální sítě. V režimu klient/server je vhodné použít autentizaci pomocí certifikátů. V tomto případě by použití jenom sdílených klíčů bylo omezující. Je tedy nutné mít k dispozici nějakou certifikační autoritu nebo nějaké platné certifikáty [14]. Sdílené klíče lze použít jako další bezpečnostní prostředek, který se použije např. pro podepisování řídících dat. Nastavení 1)
Na serveru (počítač č. 1) vytvoříme konfigurační soubor /etc/openvpn/vpn_server.conf #režim klient/server mode server #označení serveru tls-server dev tun proto udp port 5000 #adresa serveru ifconfig 10.0.0.1 255.255.255.0 #rozsah adres klientů ifconfig-pool 10.0.0.2 10.0.0.100 255.255.255.0 #nastavení SSL #certifikát certifikační autority ca /etc/openvpn/cacert.pem #certifikát serveru cert /etc/openvpn/server.crt #klíč serveru key /etc/openvpn/server.key
35
#soubor s parametry protokolu Diffie-Hellman dh /etc/openvpn/dh1024.pem #parametry logování log-append /var/log/openvpn #jméno logovacího souboru status /var/run/openvpn/vpn.status 10 comp-lzo verb 5
VPN spustíme příkazem: openvpn --config /etc/openvpn/vpn_server.conf.
2)
Na klientovi (počítač č. 2) vytvoříme soubor /etc/openvpn/ vpn_klient.conf #vzdálená strana serveru remote 192.168.0.1 5000 tls-client dev tun proto udp # stažení konfigurace ze serveru pro vzdálenou správu pull #certifikát CA ca cacert.pem #certifikát klienta cert klient.cert #klíč klienta key klient.key comp-lzo verb 3
OpenVPN spustíme příkazem: openvpn --config /etc/openvpn/vpn_klient.conf
5.2.2
Openswan
Domovská stránka: http://www.openswan.org Openswan (Open Secure Wide Area Network) je sada nástrojů pro implementaci protokolu IPsec v operačním systému Linux a umožňuje vytvořit tunel mezi dvěma sítěmi. Je pokračovatelem aplikace FreeS/WAN., známé starší implementace protokolu IPSec v Linuxu. Je dostupná zdarma pod licencí GNU/GPL. Openswan má dvě hlavní komponenty: • •
KLIPS – zajišťující funkce IPSec (šifrování,autentizaci,kompresi) PLUTO – nástroj pro správu klíčů a výměnu klíčů (IKE)
36
Instalace Openswan, spolu s podpůrnými moduly, lze stáhnout ve formě balíčku. Pro Linuxy se staršími jádry (nižší než 2.6) je nutné kompilovat jádro a přidat do něj podporu pro protokol IPSec. Konfigurace Konfigurace Openswanu má jednu příjemnou vlastnost. Konfigurační soubory pro oba počítače na koncích tunelů mohou být stejné. Stačí vytvořit jeden konfigurační soubor a přenést ho na druhý počítač. Je to dáno tím, že při konfiguraci si „označíme“ počítač na jedné straně tunelu jako left a druhý jako right. Openswan automaticky pozná na které straně tunelu se počítač nachází. Nejprve se u obou počítačů přesvědčíme, že mají soubor etc/ipsec.secrets ve kterém se nachází šifrovací klíč. Uděláme to příkazem: ipsec showhostkey --left (případně right, v závislosti na kterém PC příkaz
spustíme) Pokud se klíč nevytvořil při instalaci, nebo ho chceme změnit, vytvoříme klíč nový příkazem: ipsec newhostkey --output etc/ipsec.secrets
Hlavní konfigurace Openswanu se nachází v souboru /etc/ipsec.conf: config setup #nastavení síťového zařízení interfaces ipsec0=eth0 #vypnutí debugovacích nástrojů klipsdebug=none plutodebug=none plutoload=%search plutostart=%search uniqueids=yes #nastavení tunelu se jmenem testovacivpn conn testovacivpn #nastavení levého konce tunelu (počítač č. 2) left=192.168.0.5 #vygenerovaný klíč v PC2 leftrsasigkey=0sAE9jdDFJ390FJjf3m... nastavení pravého konce tunelu (počítač č.1) right=192.168.0.1 rightrsasigkey=0sAof6dfj2/fwedf... #automatická změnu klíčů, vložené budou jen pro navázaní spojení authby=rsasig #automatické spuštění tunelu po startu auto=start
Po tomto nastavení přeneseme konfigurační soubor i na druhý počítač.
37
Na obou počítačích nahrajeme tunel do paměti pomocí: ipsec auto --add testovacivpn
Poté stačí tunel spustit jen na jednom stroji pomocí: ipsec auto --up testovacivpn
Funkčnost a stav tunelů lze získat příkazem: ipsec auto --status
5.2.3
Poptop (PPTP server) + PPTP Klient
Domovská stránka: http://www.poptop.org/ Poptop je implementace PPTP serveru pro Linux, existují ale také ve verzi pro Solaris 2.6, OpenBSD, FreeBSD. Díky Poptopu je možné vytvořit VPN server, na který se lze snadno přihlásit pomocí vestavěných PPTP klientů na strojích Microsoft Windows 95/98/Me/NT/2000/XP. Pro Linux je nutné klienta doinstalovat. hlavní rysy: • • • •
Poptop je šířen zdarma pod licencí GNU/GPL. autentizace a šifrování kompatibilní s Microsoftem (MSCHAPv2, MPPE 40-128bit RC4 šifrováním) podpora připojení více klientů najednou snadná integrace do Microsoft sítí
Protože je protokol PPTP postaven na protokolu PPP, je pro Poptop server nutné, aby byla nainstalovaná podpora PPP. V nových distribucích Linuxu však není s podporou problém, je již jejich součástí. Vlastní Poptop server lze nainstalovat pomocí balíčku pptpd, nebo přeložit ručně. Pro chod je také nutné nainstalovat podporu šifrovacích Microsoft protokolů MPPE (Microsoft Point to Point Encryption). Pravděpodobně už bude ale také instalovaná. Můžeme to ověřit pomocí: modprobe ppp-compress-18 && echo success
Konfigurace 1)
Konfigurace serveru (počítač č. 1)
do souboru /etc/pptpd.conf uložíme: #virtuální adresa localip 10.0.0.1 #adresy virtuálních vzdálených strojů rozsahu) remoteip 10.0.0.2-10 #cesta k souboru s nastavením ppp démona option /etc/ppp/options.pptpd
(mohou
být
ve
formě
38
nastavíme parametry ppp démona v souboru: /etc/ppp/options.pptpd #jméno serveru pro autentizaci (stejné jako v /etc/ppp/chapsecrets) name pptpd #odmítneme autentizaci pomoci pap, chap a mschap refuse-pap refuse-chap refuse-mschap # budeme požadovat autentizaci pomoci MS-CHAPv2 require-mschap-v2 #budeme požadovat šifrování pomocí 128bit MPPE require-mppe-128 nobsdcomp nodeflate
nastavíme jména a hesla uživatelů v: /etc/ppp/chap-secrets # klient klient1
server pptpd
klíč heslo
IP adresy *
a nakonec server spustíme příkazem /usr/bin/pptpd 2)
Konfigurace klienta
V operačních systémech Windows je klient pro PPTP již předinstalován, pro Linux musíme klienta nainstalovat. PPTP klient pro Linux lze nalézt zde [12]: Pokud chceme klienta stáhnout ve formě balíčku, musíme ho hledat pod názvem pptp-linux. Klienta lze nastavovat ručně, ale lze také využít některé grafické rozhraní, které doinstalujeme, a přes které se klient nastavuje snáze. Nastavení PPTP klienta ukáži za pomocí grafické utility pptpconfig, kterou lze nalézt zde [13].
39
Obrázek. 5.1 grafická utilita pptpconfig
na záložce Server nastavíme: Server: 192.168.0.1 Name: pptpd Username: klient1 Password: heslo
na záložce Routing, nasměrujeme veškerý provoz do tunelu, nastavíme ALL to Tunnel
na záložce Encryption, zapneme: Require Microsoft Point-to-Point Encryption (MPPE)
klikneme na tlačítko Add a tím uložíme nastavení tunelu do seznamu. kliknutím na Start se připojíme.
5.2.4
Stunnel
Domovská stránka: http://www.stunnel.mirt.net/ Stunnel je program umožňující vytvářet šifrované tunely za pomocí protokolu SSL. Je dostupný pro velkou řadu operačních systémů (Linux, Microsoft Windows, BSD, Solária). Dá se nazvat „univerzálním obalovačem“ a najde využití nejenom pro tvorbu VPN. Umožňuje vytvořit zabezpečené spojení nad nezabezpečenými protokoly (např. POP, IMAP). Možnosti zabezpečení pomocí Stunnelu jsou dány použitou SSL knihovou (nejčastěji OpenSSL)
40
Instalace Pro vytvoření VPN pomocí Stunnelu je zapotřebí knihovna SSL (nejčastěji OpenSSL) a také podpora PPP, proto se musíme ujistit, že jsou v systému nainstalovány, případně je doinstalovat. Stunnel existuje i ve formě balíčků, instalace je tedy snadná. Konfigurace Nastavení Stunnelu je snadné, konfigurace se nachází v jediném souboru. Pro vytvoření bezpečného tunelu lze v Stunnelu využít certifikáty X509. Nnávod jak vytvořit certifikáty lze nalézt zde [14]. Tato ukázková konfigurace předpokládá vlastnictví těchto klíčů: • •
server: veřejný klíč (server.cert), privátní klíč(server.pem), certifikát CA(cacert.cer) klient: veřejný klíč (klient.cert), privátní klíč(klient.pem), certifikát CA(cacert.cer)
1)
Nastavení serveru:
Vytvoříme konfigurační soubor stunnel.conf: #veřejný klíč podepsaný CA cert = /home/stunnel/certificates/server.cert #privátní klíč key = /home/stunnel/certificates/server.pem #stupeň ověřování certifikátu verify = 2 #složka s certifikáty CApath = /home/stunnel/certificates #certifikát CA. CAfile = /home/stunnel/certificates/cacert.cer #mód server Client = no [vpn] #číslo portu accept = 2020 exec = /usr/sbin/pppd execargs = pppd local pty = yes
Stunnel spustíme příkazem stunnel stunnel.conf
2)
Nastavení klienta:
Vytvoříme konfigurační soubor stunnel.conf: cert = /home/stunnel/certificates/klient.cert
41
key = /home/stunnel/certificates/klient.pem verify = 3 CApath = /home/stunnel/certificates CAfile = /home/stunnel/certificates/cacert.cer debug = 7 #output = /home/stunnel/stunnel.log client = yes foreground = yes connect = 192.168.0.1:2020
Stunnel spustíme příkazem stunnel stunnel.conf
5.2.5
tinc
Domovská stránka: http://www.tinc-vpn.org/ Tinc je VPN démon, který využívá metodu tunelování a šifrování k vytvoření zabezpečené privátní sítě. hlavní rysy: • • • • • • •
tinc je zdarma šířen pod licencí GNU/GPL podpora mnoha OS (Linux, FreeBSD, OpenBSD, NetBSD, MacOS/X, Solaris, Windows 2000/XP) podpora šifrování, autentizace (pomocí OpenSSL) volitelná komprese pomocí zlib nebo LZO podpora směrování full-mesh (spojení každý s každým, tinc démon se snaží zasílat data mezi účastníky přímo, pokud možno bez prostředníků) snadná rozšiřitelnost (Pro přidání hostitele do sítě stačí přidat nový konfigurační soubor, bez nutnosti startu nového démona či vytvoření nového síťového zařízení) podpora IPv6
Tinc využívá pro vytváření tunelů univerzální síťové ovladače TUN/TAP, v nových distribucích Linuxu jsou již součástí jádra. Protože se pro bezpečnostní funkce používá knohova OpenSSL je nutné tento balík nainstalovat ještě před vlastní instalací tincu. Pro využití komprese jsou také nutné knihovny zlib či LZO. Pro instalaci tincu lze využít dostupné balíky (v závislosti na distribuci).. Konfigurace Nejdříve se přesvědčíme, že je v systémů vytvořené univerzální síťové zařízení /dev/net/tun c 10 200 pokud není, vytvoříme ho mknod -m 600 /dev/net/tun c 10 200
42
Pro vytvoření nové VPN sítě, je vhodné přiřadit ji nějaké jméno. Toho dosáhneme, pokud budeme spouštět tinc s parametrem –n [jméno], např.: tincd -n vpnka
V tomto případě bude kořenový adresář souborů VPN sítě /etc/tinc/vpkna, pokud jméno neuvedeme, je standardní cesta /etc/tinc/. Hlavní konfigurační soubor se nachází v souboru /etc/tinc/vpnka/tinc.conf Konfigurační soubory klientů jsou ve složce /etc/tinc/vpnka/hosts/ 1)
Nastavení serveru
V souboru /etc/tinc/vpnka/tinc-up nastavíme, #virtuální adresa, eth0 je jméno síťového rozhraní ifconfig eth0 10.0.0.1 netmask 255.255.255.0
v souboru /etc/tinc/vpnka/tinc.conf: #jméno Name = PC1 #používané virtuální zařízení Device = /dev/net/tun
a soubor /etc/tinc/vpnka/hosts/PC1 bude obsahovat: #lokální adresa Address = 192.168.0.1 -----BEGIN RSA PUBLIC KEY----[zde bude veřejný klíč] -----END RSA PUBLIC KEY-----
Nakonec vytvoříme soukromé/veřejné klíče, pomocí příkazu tincd -n vpnka -K
Soukromý klíč se uloží do /etc/tinc/vpnka/rsa_key.priv, veřejný klíč je umístěn do konfiguračního souboru ve složce /etc/tinc/vpnka/hosts/ 2)
Nastavení klienta, počítač č. 2
Soubor /etc/tinc/vpnka/tinc-up bude obsahovat: ifconfig eth0 10.0.0.5 255.255.255.0
Do souboru /etc/tinc/company/tinc.conf umístíme, Name = PC2 ConnectTo = PC1 Device = dev/net/tun
do souboru /etc/tinc/vpnka/hosts/PC2: Address = 192.168.0.5
43
-----BEGIN RSA PUBLIC KEY----[veřejný klíč] -----END RSA PUBLIC KEY-----
vytvoříme soukromé/veřejné klíče, pomocí příkazu tincd -n vpnka -K
Nakonec musíme ještě zajistíme distribuci všech host souborů i s klíči do /etc/tinc/vpnka/hosts/ složek u jednotlivých počítačů. V tomto případě, obsahují složky hosts u obou počítačů dva konfigurační soubory a to PC1 a PC2. Tunelovacího démona spustíme příkazem: tincd –n vpnka
44
Kapitola 6
Porovnání VPN 6.1
Srovnání
V této kapitole uvedu hlavní parametry uvedených VPN řešení a dojde na jejich srovnání. Srovnání bude prezentováno slovně a pomocí tabulek. Uvedené parametry jsou získány z oficiálních materiálů jednotlivých řešení a z provedených nebo převzatých testů/analýz. Některé vlastnosti nelze snadno přímo otestovat, uvádím proto pouze jejich slovní rozbor.
6.2
Srovnávací parametry
6.2.1
Bezpečnost
Za hlavní kritéria pro hodnocení bezpečnosti lze považovat způsob, jak VPN zajišťují autentizaci uživatelů, vlastní šifrování přenášených dat a zda nabízejí prostředky pro ověření integrity přenášených dat. Kvalita zabezpečení je dána zejména použitými šifrovacími algoritmy s dostatečně dlouhými klíči, ale závisí samozřejmě také na konkrétním způsobu implementace a odstranění zranitelných míst v aplikaci. Hodnocení kvality jednotlivých algoritmů není úkolem této práce, to přenechávám specializovaným studiím. Kvalitu tak hodnotím spíše podle toho, zda jsou využívány standardizované a prověřené algoritmy, nebo zda jsou použita vlastní řešení (MS_CHAP). Tabulka 6.1 nabízí přehled používaných bezpečnostní prvků. Z něj lze vidět, že nejširší možnosti zabezpečení nabízí Openswan a OpenVPN.
Openswan
OpenVPN
Poptop Stunnel tinc
Metody autentizace sdílený klíč, RSA, certifikáty X.509 sdílený klíč, certifikáty X.509 PAP, CHAP, MS-CHAP, MS-CHAPv2 RSA, certifikáty X.509 RSA
Metody šifrování Integrita dat 3DES, AES
MD5, SHA
Blowfish, 3DES, AES
SHA, MD5
MPPE
–
3DES, AES Blowfish
SHA SHA
Tabulka 6.1: bezpečnostní prvky
45
Openswan nabízí několik metod autentizace a přenos je chráněn různým stupněm zabezpečení (v závislosti na nastaveném režimu, více viz.protokol Ipsec v kapitole 4). Navíc protokol protokol IPSec umožňuje chránit veškerý provoz, který běží na síťové vrstvě. OpenVPN nabízí kvalitní a bezpečné řešení také. Za bezpečný lze považovat také Stunnel. Tato dvě řešení zajišťují bezpečnostní funkce za pomoci externí knihovny (OpenSSL). Jejich bezpečnost je tedy z velké části závislá na kvalitách a funkcích této knihovny, která je v současnosti na dobré úrovni. Tinc využívá knihovnu SSL také, ale vlastní implementace tincu není nejlepší. Jeho zabezpečení má trhliny a není na takové úrovni jako IPSec, což na oficiálních webových stránkách přiznávají sami autoři aplikace. O problémech v zabezpečení s protokolem PPTP jsem se zmínil v kapitole 4. Přestože je řada problémů odstraněna, Poptop stále obsahuje nebezpečná místa z důvodů kompatibility s klienty v OS Microsoft Windows.
6.2.2
Škálovatelnost
Hodnocení škálovatelnosti může být pro řadu VPN velmi významným faktorem. Pokud se dá očekávat budoucí rozšiřování privátní sítě, je nutné, aby bylo co možná nejsnadnější přidávat nové účastníky sítě. Pro srovnání parametru škálovatelnosti jsem použil informace z projektu Volans [15], který hodnotil škálovatelnost podle třech parametrů. Výsledné hodnocení je tak dáno jako součet počtu nutných: 1.
úprav konfiguračních souborů (a)
2.
aktualizací směrovacích informací (b)
3.
distribucí tajných klíčů (c)
ve full-mesh síti (spojení každého uzlu s každým) na N uzlech sítě. Výsledky jsou shrnuté v následující tabulce.
OpenVPN
Úprava Aktualizace Celková Distribuce Konfiguračních Směrovacích náročnost klíčů (c) souborů (a) informací (b) (a+b+c) 2(N-1) 1 N(2N-1) N
Openswan
N
N(2N)
PopTop
N
2(N-1)
2(N-1)
N(5N-2)
Stunnel
2(N-1)
2(N-1)
1
N(4N-3)
1
1
2
N(4)
tinc
Tabulka 6.2: škálovatelnost
Z uvedené tabulky je vidět, že nejlépe škálovatelné řešení je tinc, který obsahuje směrovacího démona, který usnadňuje rozšíření sítě (v případě full-mesh sítě se konfiguruje pouze nově přidaný uzel sítě).
46
6.2.3
Výkon
Výkon je dalším z důležitých parametrů VPN. Hlavními dvěma atributy výkonu jsou přenosová kapacita a odezva. Tyto výkonnostní parametry jsem otestoval na uvedené lokální síti. Přenosovou rychlost jsem měřil programem iperf [18]. Komunikace probíhala přes protokol TCP, velikostí TCP okénka jsem ponechal na programem implicitně nastavenou na 85,3 Kb. Měření bylo prováděno 10-krát v obou směrech a výsledek byl zprůměrován. Z důvodů objektivity byla veškerá komprese vypnuta. Odezva byla měřena standardním programem ping a je uvedena jako hodnota RTT (Round Trip Time, tedy čas přenosu informace od zdroje do cíle a zpět). Měření jsem provedl opět 10-krát v obou směrech a výsledek udává průměr těchto měření. Síťbez VPN Openswan OpenVPN Poptop Stunnel Tinc Přenosová kapacita (Mbit/s) RTT (ms)
47,6
27,5
25,6
27,1
28,2
16,1
0,23
0,51
0,93
0,53
1,11
0,89
Tabulka 6.3: výkonnostní parametry
Dle tabulky je vidět, že přenos přes VPN je pomalejší než přímé propojení. Až na řešení tinc byly výsledky přenosové kapacity poměrně vyrovnané. V odezvě je nejlepší Openswan a Poptop. Ve výkonnostních parametrech VPN je tak jistě co zlepšovat.
6.2.4
Spolehlivost
Jako další srovnávací parametr se nabízí spolehlivost jednotlivých řešení. Otestování spolehlivosti není jednoduché a většinou je nutné provést dlouhodobější a náročnější testování. V mých (jednoduchých a izolovaných) testovacích podmínkách byl VPN přenos stabilní. Při testování VPN jsem nezjistil žádné očividné přenosové problémy a všechna řešení se jevila spolehlivě. Spolehlivost byla pravděpodobně dána přímým spojením obou strojů a nemohla být ovlivněna výpadky či přetížením sítě. Mohu se domnívat, že daná VPN řešení se v rozsáhlejších sítích s kolísavým zatížením a větším počtem uživatelů nebudou chovat takto spolehlivě. Předpokládám, že dojde k poklesu výkonnosti, případně k výpadkům. Pro získání údajů o spolehlivosti v „plném nasazení“ bude nutné provést rozsáhlejší a komplexnější testy. Otázku spolehlivosti tak ponechávám otevřenou dalším testům. Přesto v oblasti spolehlivosti nesmím opomenout zmínit dobrou vlastnost OpenVPN a Stunnelu, kteří se dokáží automaticky pokoušet o navázání přerušeného spojení.
6.2.5
Přizpůsobivost
Přizpůsobivost VPN řešení, ve smyslu možnosti upravit a rozšířit funkce, je další parametr, dle kterého lze porovnávat. Možnost snadné úpravy funkcí jednotlivých VPN je jistě dobrá vlastnost.
47
Bohužel žádné z testovaných řešení nenabízí možnost přímé úpravy aplikace pomocí zásuvných modulů (pluginů). Vylepšit tak jednotlivé aplikace není úplně snadné. Přesto jsou mezi zvolenými řešeními rozdíly. OpenVPN, Stunnel a tinc používají k zajištění bezpečnosti externí knihovny. Pokud budou tyto knihovny vylepšeny o nové funkce a algoritmy, je velice snadné je do těchto aplikací přidat, bez nutnosti aplikaci upravovat. U Poptopu takováto možnost není, stejně jako u Openswanu je změna funkcionality problematická.
6.3
Hodnocení
Každé z uvedených řešení má co nabídnout. Pokud bych měl vybrat nejkomplexnější řešení, vybral bych si Openswan. Protokol IPSec je v současné době asi nejlepší z hlediska bezpečnosti, navíc je definován jako standard a nabízí mnoho funkcí. Bohužel je poměrně složitý a nekonfiguruje se snadno. Jako dobré řešení se mi jeví stále populárnější OpenVPN, nabízí dobrou bezpečnost, v celku snadnou konfiguraci a podporu řady operačních systémů. Tinc hodnotím kladně vzhledem k jeho dobré škálovatelnosti, avšak výkonnostně a bezpečnostně zaostává. Poptop nabízí slušný výkon, ale má bezpečnostní problémy. Jeho výhodou je snadné připojení klientů z MS Windows.
48
VPN
Openswan
OpenVPN
Tabulka 6.4: souhrnný přehled
Poptop
Stunnel
tinc
Verze
2.4.6
2.0.9
1.3.0
4.18
1.0.7
Domovská stránka
Podporované OS
Metody autentizace
Metody šifrování
Integrita dat
Komprese
Škálovatelnost
www.openswan.org
Linux, FreeBSD, NetBSD, OpenBSD,Mac OS X
Sdílený klíč, RSA, certifikáty X.509
3DES, AES, (Twofish, Blowfish)
SHA, MD5
IPComp
N(2N)
www.openvpn.net
Linux, MS Windows 2000/XP, xBSD, Mac OS X, Solaris
Sdílený klíč, certifikáty X.509
Blowfish, 3DES, AES
SHA, MD5
LZO
N(2N-1)
www.poptop.org
Linux (podpora klientů i z MS Windows)
PAP, CHAP, MSCHAP, MSCHAPv2
MPPE
–
–
N(5N-2)
www.stunnel.mirt.net
Linux, MS Windows, xBSD, Mac OS X, Solaris, OS/2 a další
RSA, certifikáty X.509
3DES, AES
SHA
zlib, rle
N(4N-3)
www.tinc-vpn.org
Linux, MS Windows 2000/XP, xBSD, Mac OS X, Solaris
RSA
Blowfish
SHA
zlib, LZO
N(4)
49
Kapitola 7
Závěr Tato práce měla za cíl představit základní principy virtuální privátních sítí a porovnat vybraná VPN řešení dle různých parametrů. Řešení jsem vybíral z ohledem na možnosti fungování pod operačním systémem Linux a dostupnosti zdarma. Těchto řešení je celá řada a přesto, že tato práce obsahuje jen reprezentativní vzorek, udává hlavní možnosti, které v současné době otevřená řešení pro Linux nabízí. Řada z testovaných řešení je ale dostupná i pro jiné operační systémy, možnosti využití jsou tak širší. VPN jsou jistě stále žádanější a podle této práce si zájemci mohou udělat přehled, jakým způsobem virtuální privátní sítě fungují. Mají k dispozici základní přehled parametrů vybraných řešení, mohou je porovnat a naleznou zde také ukázkové případy konfigurací VPN. Tato práce nemůže a neposkytuje detailní přehledy či návody na všechna dostupná VPN řešení (manuálové stránky některých VPN řešení mají i desítky stran), ale může být startovacím textem pro zájemce o zdarma dostupné, nenáročné a přesto kvalitní VPN řešení. Pro detailnější informace musí vážní zájemci o konkrétní VPN řešení nahlédnout do jednotlivých oficiálních materiálů. Myslím, že lze bez větších obav využít některé z uvedených řešení, výběr závisí na konkrétních požadavcích. Mým doporučením je řešení Openswan a OpenVPN.
50
Literatura [1]
Luhový Karel, seriál o VPN, 2003, soubor internetových článků dostupných (březen 2007) na http://www.svetsiti.cz/view.asp?rubrika=Tutorialy&temaID=219&clanekID=220
[2]
Virtual Private Network Consorcium, http://www.vpnc.org
[3]
Scott C., Wolfe P., Erwin M: Virtual Private Networks, druhé vydání, O'Reilly, 1999, ISBN 1-56592-529-7
[4]
International Organization for Standardization, http://www.iso.org
[5]
Thomas M. T.: Zabezpečení počítačových sítí bez předchozích znalostí, CP Books, 2005, ISBN 80-251-0417-6
[6]
Peterka Jiří, Principy počítačových sítí, http://www.spsest.sk/spse/jpeterka_siet/f_pri.htm
[7]
Schneier B. a Mudge, Cryptanalysis of Microsoft's Point-to-Point Tunneling Protocol (PPTP), 1998, dostupné (duben 2004) na http://www.schneier.com/paper-pptp.html
[8]
Schneier B. a Mudge, Cryptanalysis of Microsoft's PPTP Authentication Extensions (MSCHAPv2), 1999, dostupné (duben 2007) na http://www.schneier.com/paper-pptpv2.html
[9]
Daler Ivan, IPSec Howto, 2006, dostupné (duben 2007) na http://www.ipsechowto.org/ipsec-howto_cz.html
dostupné
(duben
2007)
na
[10] The Internet Engineering Task Force, http://www.ietf.org [11] Hladík Radek, OpenVPN jednoduše, 2004, http://www.root.cz/clanky/openvpn-vpn-jednoduse/
dostupné
(duben
2007)
na
(květen
2007)
na
[12] Linux PPTP klient, http://pptpclient.sourceforge.net/ [13] pptpconfig, http://quozl.netrek.org/pptp/pptpconfig/pptpconfig.phtml [14] Kára Michal, Jak na OpenSSL, http://www.root.cz/clanky/jak-na-openssl/
2003,
dostupné
[15] Khanvilkar Shashank, Project VOLANS - Virtual Private Network research 2004, dostupné (duben 2007) na http://mia.ece.uic.edu/~papers/volans [16] Svět sítí, Slovníček pojmů http://www.svetsiti.cz/slovnik.asp
a
zkratek,
dostupné
(květen
2007)
na
[17] Request For Comments, http://www.ietf.org/rfc.html [18] Iperf, http://dast.nlanr.net/Projects/Iperf/ [19] Lewis Mark: Comparing, Designing, and Deploying VPNs, Cisco Press, 2006
51
