Grafické rozhraní pro OpenVPN. Pavel Hasenöhrl

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů

Bakalářská práce

Grafické rozhraní pro OpenVPN Pavel Hasenöhrl

Vedoucí práce: Ing. Jan Kubr

Studijní program: Softwarové technologie a management, Bakalářský Obor: Softwarové inženýrství 26. května 2010

iv

v

Poděkování Zde bych rád poděkoval vedoucímu této práce Ing. Janu Kubrovi za čas strávený na konzultacích, hodnotné připomínky a taky za to, že mi dal možnost realizovat se v rámci této bakalářské práce.

vi

vii

Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).

V Praze dne 27. 5. 2010

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

viii

Abstract This bachelor project deals with design, implementation and testing of a multiplatform (Windows and Linux) graphical user interface for the OpenVPN program. In contrast to similar GUI this one supports management of either VPN client and server, supports routed and ethernet bridging modes and includes a system for automatic distribution of certificates and network settings. This solution described here encapsulates usage of the OpenSSL program. In combination with OpenVPN it has an ambition to become a good alternative to using other VPN solutions.

Abstrakt Tato bakalářská práce se zabývá návrhem, implementací a následným testování multiplatformního (Windows a Linux) grafického uživatelského rozhraní pro program OpenVPN. Narozdíl od jiných takových GUI podporuje správu VPN klienta i serveru, podporuje směrovaný i ethernet bridging mód a obsahuje systém pro automatickou výměnu certifikátů a nastavení sítě. Zde popsané řešení zapouzdřuje použití programu OpenSSL. V kombinaci s OpenVPN má ambice stát se dobrou alternativou k použití jiných řešení pro zprovoznění a správu VPN sítě.

ix

x

Obsah 1 Úvod

1

2 Popis problému, specifikace cíle 2.1 Cíl . . . . . . . . . . . . . . . . . . . . 2.2 Přehled VPN produktů . . . . . . . . . 2.2.1 Hamachi . . . . . . . . . . . . . 2.2.2 Remobo . . . . . . . . . . . . . 2.2.3 Wippien . . . . . . . . . . . . . 2.2.4 Microsoft VPN — PPTP . . . 2.2.5 Microsoft VPN — L2TP/IPSec 2.2.6 OpenVPN . . . . . . . . . . . . 2.3 GUI pro OpenVPN . . . . . . . . . . . 2.3.1 OpenVPN GUI . . . . . . . . . 2.3.2 OpenVPN-Admin . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

3 3 3 3 4 5 5 6 6 7 7 8

3 Analýza a návrh řešení 3.1 Požadavky . . . . . . . . . . . . . . 3.1.1 Systémové požadavky . . . 3.1.2 Funkční požadavky . . . . . 3.2 Případy užití . . . . . . . . . . . . 3.3 Struktura aplikace . . . . . . . . . 3.3.1 Obecná struktura . . . . . . 3.3.2 Konkrétní řešení . . . . . . 3.4 Automatická distribuce certifikátů 3.4.1 PKI . . . . . . . . . . . . . 3.4.2 IKE . . . . . . . . . . . . . 3.4.3 Kerberos . . . . . . . . . . . 3.4.4 SSL/TLS . . . . . . . . . . 3.4.5 Vlastní řešení — Exchanger 3.4.6 Vyhodnocení . . . . . . . . 3.5 Ethernet bridging . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9 9 9 9 10 11 11 12 12 13 14 15 15 16 16 17

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

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

4 Realizace 19 4.1 Použité technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.2 Protokol Exchanger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

xi

xii

OBSAH

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

20 21 22 22 23 24

5 Testování 5.1 Zaměření testování . . . . . . 5.1.1 Konzistence programu 5.1.2 Komunikační protokol 5.1.3 Multiplatformnost . . 5.2 Testovací prostředí . . . . . . 5.3 Testovací případy . . . . . . . 5.4 Akceptační test . . . . . . . . 5.5 Traceability matrices . . . . . 5.6 Výsledky testování . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

29 29 29 30 31 31 32 34 34 34

4.3

4.4

4.2.1 Formát zprávy . . 4.2.2 Popis komunikace . Problémy . . . . . . . . . 4.3.1 Multiplatformnost 4.3.2 Kódování řetězců . Licence . . . . . . . . . .

. . . . . .

6 Závěr 37 6.1 Další vývoj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 A Seznam použitých zkratek

41

B Obsah přiloženého CD

43

Seznam obrázků 3.1

struktura aplikace — její hlavní části . . . . . . . . . . . . . . . . . . . . . . . 13

4.1 4.2 4.3 4.4

formát zprávy protokolu . . . . . . . . . . . . . . . . . . . fungování protokolu pro distribuci certifikátů a parametrů stavový diagram protokolu na straně klienta . . . . . . . . stavový diagram protokolu na straně serveru . . . . . . . .

xiii

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

21 25 26 27

xiv

SEZNAM OBRÁZKŮ

Seznam tabulek 5.1 5.2

traceability matrix testovacích případů a funkčních požadavků . . . . . . . . . 35 traceability matrix testovacích případů a systémových požadavků . . . . . . . 36

xv

xvi

SEZNAM TABULEK

Kapitola 1

Úvod Poslední dobou, kdy se vysokorychlostní připojení k Internetu stalo dostupné i domácím uživatelům, dbá se i více na bezpečnost přenášených dat, stala se technologie VPN (Virtual Private Network) vyhledávanou a používanou. Na trhu existují mnohá řešení pro různě zručné uživatele, některá jsou komerční, jiná volně dostupná pro nekomerční použití. Běžný uživatel většinou potřebuje rychle vytvořit VPN síť či se připojit do existující VPN sítě pomocí co možná nejméně udájů, ale zároveň očekává bezpečnost a spolehlivost. Já jsem se zaměřil na open source VPN řešení — program OpenVPN, který splňuje poslední dva požadavky, ale nevýhodou je jeho zprovoznění a složité nastavení, které není většině uživatelů okenních systémů vlastní. Proto jsem se rozhodl napsat program, který toto nastavení usnadní uživatelům operačního systému Windows, respektive Windows XP. A zároveň udělám verzi pro Linux, aby užívání programu nebylo vázáno pouze na jeden operační systém.

1

2

KAPITOLA 1. ÚVOD

Kapitola 2

Popis problému, specifikace cíle 2.1

Cíl

Cílem je grafická aplikace, která bude fungovat jako rozhraní nad OpenVPN. Bude umět nastavit server a klienty ve směrovaném i ethernet bridging režimu. Podporovanou topologií sítě bude hvězda s centrálním prvkem serverem, nebude podporováno např. propojení dvou sítí tunelem, nebo zpřístupnění vnitřní sítě vzdáleným klientům. Hlavním důvodem je, že běžní uživatelé jinou topologii obyčejně nepotřebují, přidání dalších možností by zesložitilo program a znepřehlednilo nastavení. Důležitou součástí bude také automatická distribuce nastavení VPN sítě a certifikátů, pomocí kterých se budou klienti na VPN serveru autentizovat. Systém automatické distribuce certifikátů musí být bezpečný, ověření klientů bude probíhat pomocí předem domluveného jména a hesla. Ve výsledku by se mělo jednat o kompletní grafické rozhraní usnadňující práci s OpenVPN, ale zároveň nebude pokročilé uživatele nijak omezovat ve volnosti nastavení (libovolné očíslování sítě, vlastní bezpečnostní nastavení, nastavitelné číslo portu, ...)

2.2

Přehled VPN produktů

Již existují produkty, které používají technologii VPN. Těchto hotových produktů je celá řada a vyvíjejí se určitě další. Proto jsem hledal a prověřoval některé tyto produkty a porovnával je. Snažil jsem se vybrat produkty, které jsou relativně známé a používané.

2.2.1

Hamachi

Program Hamachi umožňuje vytvořit mezi klienty virtuální LAN (Local Area Network). Vytváří VPN tunely mezi všemi klienty, kteří se přihlásili do dané sítě. Výsledná topologie je mesh, kde je propojen každý s každým, což otevírá více spojení, než jak tomu je u architektury klient–server. Klientům se přiděluje adresa z veřejného rozsahu 5.0.0.0/8, což je jednak omezující a není to ani správné. Výhodou je, že není potřeba vlastnit veřejnou adresu, ale na druhou stranu je spojení závislé na serverech třetí strany, které nejsou vždy spolehlivé. Navíc to může představovat bezpečnostní riziko. Program je komerční, ale existuje i verze, která je zdarma k dispozici pro

3

4

KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE

nekomerční použití (tu také popisuji) ovšem s omezeným počtem současně připojených uživatelů. Více informací je na webových stránkách https://secure.logmein.com/products/ hamachi2/. Tento produkt je brán, jako určitý vzor pro mé řešení z pohledu jednoduchosti nastavení a uživatelské přívětivosti. Zároveň je mým osobním cílem tento produkt kombinací mého GUI (Graphical User Interface) a programu OpenVPN překonat. výhody: • umí broadcast • téměř bez potřeby nastavení nevýhody: • proprietární komerční řešení • závislé na třetí straně • adresní rozsah 5.0.0.0/8 • topologie mesh

2.2.2

Remobo

Remobo se nejvíce podobá programu Hamachi, ale vůbec nic se v něm nenastavuje, proto je velmi nenáročný na uživatele. Funguje to tak, že se vytváří mezi všemi přidanými klienty VPN tunely. Přiděluje také adresy z veřejného rozsahu (tentokrát 7.0.0.0/8), po každém spuštění ale přiděluje adresu znovu. Program je dostupný pouze v beta verzi, která je zatím zdarma. Více informací je na webových stránkách http://www.remobo.com. výhody: • žádné nastavování • multiplatformní nevýhody: • proprietární řešení • beta verze • neumí broadcast • závislé na třetí straně • žádné možnosti nastavení

2.2. PŘEHLED VPN PRODUKTŮ

5

• adresní rozsah 7.0.0.0/8 • nutnost registrace • dynamické přidělení adresy • topologie mesh

2.2.3

Wippien

Jedná se o IM (Instant Messaging) klient, který zároveň umožňuje VPN spojení mezi „přátely“. Klient samotný je zdarma a zdrojové soubory jsou k dispozici pod MIT (Massachusetts Institute of Technology) licencí, ale používá komponenty třetí strany. Navazování spojení a číslování sítí je poněkud „zvláštní“. Nepodařilo se mi navázat stabilní kanál mezi dvěma klienty. Více informací na http://www.wippien.com. výhody: • MIT licence nevýhody: • ranné stádium vývoje • potřeba účtu na jabber • komponety třetí strany • topologie mesh • „zvláštní“ konfigurace

2.2.4

Microsoft VPN — PPTP

VPN řešení zabudované přímo v operačních systémech Windows. Nastavuje se pomocí wizarda. PPTP (Point-to-Point Tunneling Protocol) není ale považován za bezpečný protokol [5]. Více informací na Microsoft TechNet [14]. výhody: • součást OS (Operating System) Microsoft Windows • klient-server nevýhody: • není bezpečný protokol • neumí broadcast

6


2.2.5

Microsoft VPN — L2TP/IPSec

Další VPN řešení podporované v operačních systémech Windows. Na rozdíl od PPTP používá L2TP (Layer Two Tunneling Protocol) IPSec (IP Security), takže je bezpečné. Bohužel pro VPN server je nutné mít serverový operační systém např. Windows 2003 Server. Klient je zabudovaný i ve workstation např. Windows XP. Běžní uživatelé si proto vlastní VPN tohoto typu nevytvoří. Více informací na Microsoft TechNet [13]. výhody: • součást OS Microsoft Windows • bezpečný • klient-server nevýhody: • potřeba více portů • nutný serverový OS

2.2.6

OpenVPN

OpenVPN je velmi bezpečné řešení pro VPN — bezpečnost zajišťuje knihovna OpenSSL. Pracuje ve dvou režimech — směrovaném a ethernet bridging, který umožňuje posílání broadcastů, ale server se nastavuje složitěji. Server může provozovat kdokoliv, kdo je dostupný z internetu alespoň přes jeden TCP (Transmission Control Protocol) nebo UDP (User Datagram Protocol) port, odpadá tak závislost na serverech třetích stran. Program má podrobnou, ale složitější konfiguraci. Další nevýhodou je podepisování a distribuce certifikátů, kterou je potřeba dělat ručně. Jedná se open source projekt distribuovaný pod GPL (General Public License) licencí. Více informací na stránkách projektu http://openvpn.net. Tento VPN produkt mnoho dobrých vlastností, nevýhodou je složitá konfigurace, kterou je možné odstranit právě pomocí GUI. výhody: • open source • bezpečné • broadcast • UDP nebo TCP • multiplatformní • podrobná konfigurace • klient-server • nezávislost na třetí straně

2.3. GUI PRO OPENVPN

7

nevýhody: • složitější konfigurace • distribuce certifikátů

2.3

GUI pro OpenVPN

V době, kdy jsem začal pracovat s programem OpenVPN žádné oficiální GUI pro něj neexistovalo. Až když jsem začal pracovat na vlastním řešení, objevily se na stránkách projektu OpenVPN další GUI pro tento program. Většinou se jedná o programy vázané na jednu platformu (Tunnelblick, KVpnc, ...). Pouze charakteristika OpenVPN-Admin je nejpodobnější. Můj program ale řeší i distribuci certifikátů a nastavení sítě mezi serverem a klienty, usnadňuje použití režimu ethernet bridging, což ostatní GUI nenabízí. Na Internetu, zejména pak na http://sourceforge.net je mnoho dalších GUI pro program OpenVPN. Některá jsou nová, jiná starší v porovnání s GUI vyvýjeném mnou. Některá vyžadují webový server (OpenVPN Web GUI, MyVPN OpenVPN Web Config, ...), další mají jen část funkcionality a nemá smysl je všechny vypisovat, jen příklad několika z nich: OpenVPN Client Windows, FASTOpenVPN-Gui, gopenvpn, ...

2.3.1

OpenVPN GUI

Jedná se o jednoduché GUI k programu OpenVPN napsané nad WIN32. Neusnadňuje nastavení jednotlivých parametrů pomocí GUI a nepřidává žadnou další funkcionalitu. Ostatní vlastnosti programu OpenVPN neovlivňuje. Uvedl jsem ho, protože je součástí distribuce OpenVPN pro Windows, díky čemuž je více „oficiální“ než ostatní GUI pro OpenVPN. Více informací na stránkách projektu http://openvpn.se. výhody: • open source • distribuováno spolu s OpenVPN nevýhody: • pouze Windows • jen základní vlastnosti • neobsahuje nic nového

8


2.3.2

OpenVPN-Admin

OpenVPN-Admin je GUI napsané ve frameworku Mono. Je tedy k dispozici jak pro platformu Windows, tak Linux. Umožňuje nastavení klienta i serveru, ale neřeší distribuci certifikátů a nastavení sítě. Více informací na stránkách projektu http://sourceforge.net/ projects/openvpn-admin/. výhody: • open source • multiplatformní nevýhody: • neřeší distribuci certifikátů

Kapitola 3

Analýza a návrh řešení 3.1 3.1.1

Požadavky Systémové požadavky

SR1: OS Windows XP Program je primárně určen pro operační systém Windows XP, všechny jeho vlasnosti musí fungovat pod tímto systémem. SR1: OS Linux Program bude portován i pod operační systém Linux. GUI by mělo být stejné jako ve verzi pro Windows, ostatní funkce mohou být řešeny jinak. SR2: OpenSSL Program bude umět spolupracovat s programem/knihovnou OpenSSL (kvůli bezpečnostním funkcím).

3.1.2

Funkční požadavky

FEAT1: Jednoduché nastavení Nejdůležitější parametry pro funkční nastavení sítě by měly být uživateli nabídnuty nejdříve. Uživatel ale musí mít možnost zobrazit si a nastavit i další parametry skrze grafické rozhraní. Jednotlivá pole pro zadání hodnot budou obsahovat výchozí hodnotu, výstižný popisek a nápovědu, kterou si případně uživatel bude moci zobrazit, když si nebude jistý významem pole (např. najetím kurzorem myši na popisek pole). FEAT2: Správa nastavení sítí Systém umožňuje spravovat různé sítě. Nastavení bude ukládáno do adresáře se jménem sítě. V daném adresáři budou i konfigurační soubory pro OpenVPN, privátní klíč a certifikáty. Adresáře s nastavením bude možno ukládat kamkoliv a pro vybrání správné lokace bude sloužit klasický dialog pro uložení souboru. FEAT3: Podpora broadcastů Program bude podporovat nastavení režimu ethernet bridging, kvůli podpoře broadcastů v síti VPN. Nastavení tohoto režimu má jistá specifika, se kterými bude program umět pomoci.

9

10

KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ

FEAT4: Automatická distribuce certifikátů Část programu zajišťuje distribuci certifikátů mezi klienty a serverem. Tato vlastnost je klíčová pro jednoduchou použitelnost tohoto řešení. Zároveň nesmí tato funkce narušit bezpečnost a důvěryhodnost sítě. Server i klienti si vygenerují vlastní privátní klíč, předávat se budou pouze certifikáty a žádosti o podepsání certifikátu. Tato komunikace mezi serverem a konkrétním klientem bude zabezpečena silnou symetrickou šifrou s předem dohodnutým heslem. FEAT5: Logování Aplikace musí umět zaznamenávat události, které nastaly při konfiguraci sítě, distribuci certifikátů, spravování klientů, ... Log se bude zobrazovat v okně aplikace a zároveň ukládat do souboru. FEAT6: Stavové informace Aplikace by také měla zobrazovat v jakém stavu se daná síť či připojení k ní nachází. Stavy serveru budou, jestli je inicializovaný, spuštěný, vypnutý, dále, kteří uživatelé se mohou připojit, kteří jsou revokování. U klienta se budou zobrazovat pouze stavy, zda je u serveru autentizován a jestli je připojen. FEAT7: Správa klientů Server bude mít možnost jednotlivé klienty odstranit či zneplatnit jejich certifikáty (revokace). FEAT8: Lokalizace Texty v GUI programu by měly být lokalizovatelné do jiných jazyků. Při prvním spuštění se program zeptá na jazyk, který má používat, a toto nastavení si uloží. FEAT9: Generování konfigurace Z nastavení VPN serveru i klienta bude možné vygenerovat konfigurační soubor ve formátu, jaký používá OpenVPN. Server ještě bude umět vygenerovat konfiguraci pro své klienty (jen ty direktivy, které jsou určeny aktuálním nastavení serveru a klient je nemůže ovlivnit) a bude ji umět poslat klientům na vyžádání, bude se posílat podobně jako certifikáty.

3.2

Případy užití

UC1: Vytvoření nové sítě Uživateli je dovoleno vytvořit novou síť (server nebo klienta) v kterémkoliv stavu aplikace. Uživatel vyvolá dialog pro tvorbu serveru/klienta, vybere adresář, kde se vytvoří adresář sítě a zadá její jméno. Vytvořená síť se stane aktivní. V případě chyby se aplikace vrátí do výchozího stavu (stav jako po spuštění). UC2: Otevření sítě Uživatel vyvolá dialog umožňující načíst dříve vytvořenou síť, vybere adresář sítě, kterou chce načíst. Po potvrzení dialogu se síť načte jako aktivní, nebo vyskytneli se nějaký problém, obnoví se výchozí stav aplikace. UC3: Úprava nastavení aplikace Uživatel v dialogu pro nastavení aplikace, který je přístupný vždy, může měnit nastavení aplikace. Obsahuje formulář s parametry aplikace. Každá řádka formuláře obsahuje popisek s nápovědou a vedle popisku je nějaké vstupní pole s hodnotou, kterou lze změnit. Dialog je nutné potvrdit pro uložení provedených změn, celé nastavení se okamžitě uloží do příslušného souboru.

3.3. STRUKTURA APLIKACE

11

UC4: Úprava nastavení sítě Aby si uživatel mohl zobrazit nastavení sítě, musí být aktivní nějaká síť (viz UC1 a UC2). Potom si může uživatel vyvolat dialog s nastavením sítě, ten obsahuje formulář s parametry sítě. Každá řádka formuláře obsahuje popisek s nápovědou a vedle popisku je nějaké vstupní pole s hodnotou. Dialog je nutné potvrdit pro uložení provedených změn. Jestliže je zapnutá funkce automatického ukládání, uloží se změny i do příslušného souboru. UC5: Ovládání Uživatel je schopen ovládat a volat funkce aplikace pomocí dialogu s příkazy. Příkazy ve vyvolaném dialogu se liší podle aktivní sítě. U sítě typu klient je uživateli umožněno vygenerovat privátní klíč a žádost o certifikát, spustit výměnu informací se serverem a připojit se k VPN serveru. U sítě typu server je uživateli umožněno vygenerovat privátní klíče a certifikáty, spustit server pro výměnu potřebných informací s klienty, vypnout zmíněný server a spustit VPN server, u serveru v režimu TAP navíc umožňuje nastavit NAT (Network Address Translation) a zrušit NAT. UC6: Správa klientů Klienty sítě lze spravovat pouze při aktivní síti typu server. Uživatel vyvolá dialog pro správu, který umožňuje přidávat a mazat záznamy. Záznam je dvojice jméno–heslo. Po každé změně se záznamy ukládají do příslušného souboru. UC7: Logování Logování se provádí automaticky. Uživatel si logované informace může zobrazit vyvoláním příslušného dialogu.

3.3 3.3.1

Struktura aplikace Obecná struktura

Jedná se o desktopovou multiplatformní (Windows a Linux) aplikaci s grafickým uživatelským rozhraním. V požadavcích je dále uvedeno, že bezpečnostní funkce budou poskytovány programem/knihovnou OpenSSL, která je dostupná pro obě platformy. Projekt OpenSSL je otevřený, tudíž, zda je implementace skutečně bezpečná, mohou posoudit i další odborníci na toto téma, navíc je známý a uznávaný. Aplikace musí umět spravovat VPN server, stejně tak klienty, proto bude pracovat v několika režimech podle nastavení sítě, která je v daný okamžik aplikací otevřená. Konkrétně se bude jednat o čtyři stavy server/klient v režimu TUN/TAP a ještě stav, kdy není otevřena žádná síť. Každý stav se mezi sebou více či méně liší. Největší odchylky v potřebné konfiguraci aplikace jsou mezi stavy serveru a klienta. Konfigurace režimu server obsahuje serverovou část systému pro automatickou distribuci certifikátů, aplikace v režimu klient zase musí obsahovat klientskou část systému. Server na rozdíl od klienta spravuje své klienty např. jejich přihlašovací informace k systému pro automatickou výměnu certifikátů. Aplikace je navržena tak, že k jedné konkrétní síti se může připojit více klientů a každá síť má vždy jeden server. Skládá se z několika hlavních částí: GUI, systém pro automatickou distribuci certifikátů, programu/knihovny OpenSSL, programu OpenVPN, případně

12


WMI (Windows Management Instrumentation) (pouze Windows) a souborů pro persistentní uložení potřebných dat. Tato aplikace tvoří jakousi nadstavbu nad programem OpenVPN, který používá klíče a certifikáty vytvářené programem OpenSSL. Zapouzdřuje tak používání těchto programů, tudíž uživatel pak nemusí používat tyto programy přímo, ale používá jednotné grafické rozhraní. Tento přístup má i nevýhody, GUI, jak je navržené, počítá jen s některými funkcemi, tudíž může omezovat použití programu OpenVPN. S tím se však počítá. Částečně struktura aplikace vychází z mé dřívější práce, která řešila specifické nastavení operačního systému a programu OpenVPN pro mód ethernet bridging. Tuto práci jsem dělal v rámci předmětu Y36SPS (Správa počítačových sítí). Výsledek práce je k dispozici na wiki předmětu [4].

3.3.2

Konkrétní řešení

Program, který obsahuje GUI a propojuje všechny části se nazývá „vpnTrustee“. Systém automatické distribuce certifikátů je vlastním řešením určeným přímo pro danou aplikaci a jmenuje se „Exchanger“. Je rozdělen do dvou částí — serverovou a klientskou, které mezi sebou komunikují zde navrženým protokolem, viz obrázek 3.1. Exchanger je součástí programu vpnTrustee. Ve verzi pro Windows se používá služba WMI, která se v programu připojuje pomocí COM (Component Object Model) a dotazování probíhá jazykem WQL (WMI Query Language). Služba WMI je zde použita kvůli získávání jmen síťových rozhraní. OpenVPN, OpenSSL a další programy, které program využívá, se volají ve skriptech spouštěných v interpretu příkazové řádky (cmd — Windows, bash — Linux). Skripty se vykonávají v rámci hlavního programu či Exchangeru, jak je naznačeno na obrázku 3.1. Skripty spouštějící OpenVPN se ale spouští jako samostatný proces, lze tak např. přejít ke správě jiné sítě, zatímco jedna VPN síť už běží. VpnTrustee si ukládá některé informace na disk. Je zde soubor globální konfigurace, který je určený pro danou instalaci programu a nachází se v adresáři dané instalace. Ostatní soubory má každá síť vlastní, jedná se o soubor obsahující nastavení sítě, logovací soubor a v případě serveru ještě soubor s přihlašovacími informacemi klientů. Všechny tyto soubory jsou textové v kódování UTF–8 (Unicode Transformation Format).

3.4

Automatická distribuce certifikátů

Program OpenVPN primárně používá pro zabezpečení důveryhodnosti a autentičnosti komunikačního kanálu mezi serverem a klienty asymetrické šifrování RSA. To je založené na privátním klíči a veřejném klíči. Privátní klíč by měl správně znát jenom jeho majitel (ten kdo ho vygeneroval). Veřejný klíč zase musí znát všichni, to lze obyčejně jen těžko zajistit, útočník může např. podsouvat podvržené veřejné klíče. Jedním ze způsobů je certifikace veřejných klíčů. Veřejný klíč je součástí certifikátu, který také obsahuje identifikační údaje uživatele a další informace. Certifikát je podepsán certifikační autoritou, tento podpis zaručuje, že se nejedná o falzifikát. OpenVPN používá konkrétně PKI (Public Key Infrastructure), která je založená na certifikátech dle ITU-T X.509 [8].

3.4. AUTOMATICKÁ DISTRIBUCE CERTIFIKÁTŮ

13

Workstation

Workstation vpnTrustee – Client Mode

vpnTrustee – Server Mode

vpnTrustee

vpnTrustee

Global Configuration File

WQL Network Configuration File

Exchanger Server

Exchanger Protocol

Global Configuration File

Exchanger Client WQL

Script Script

WMI (Windows)

Network Configuration File

Script Script

WMI (Windows)

Log File

Script

Script

OpenSSL

Log File

OpenSSL

Logins File

OpenVPN

VPN tunnel

OpenVPN

Obrázek 3.1: struktura aplikace — její hlavní části

Pro úplnost OpenVPN umožňuje zabezpečit komunikaci i předsdíleným statickým klíčem, který musí být přítomen na obou komunikujících stanicích. Ovšem tento způsob neumožňuje rozeznat klienty mezi sebou, tudíž je vhodný pouze pro point-to-point VPN. To je také důvod, proč předsdílený klíč zde nebude použit. Vytvoření a bezpečná vyměna certifikátů je kromě nastavení nejvetší problém pro většinu začínajících uživatelů programu OpenVPN. Bezpečnost je zde důležitá, protože na distribuci certifikátů pak záleží bezpečnost VPN sítě. Automatizace tohoto procesu pak skryje tento krok náročný na provedení před uživatelem a usnadní mu tak práci. Je nutné vybrat správný protokol, případně nástroj, který to je schopný zajistit. Zároveň by bylo dobré, kdyby bylo možné přenášet i nastavení VPN sítě ze serveru na klienta.

3.4.1

PKI

PKI je infrastruktura veřejných klíčů, která by se zde mohla využít. Certifikáty by se mezi serverem a klientem mohly posílat v otevřené podobě pomocí znamých protokolů jako FTP (File Transfer Protocol), SCP (Secure Copy Protocol), RCP (Remote Copy Protocol), ... Jestli je certifikát pravý se zjistí ověřením podpisu certifikátem důvěryhodné certifikační autority a autentizace se provede porovnáním identifikačních polí v certifikátu.

14


Nevýhoda je, že všichni klienti i server musí mít své certifikáty podepsané důvěryhodnou certifikační autoritou, což je problém. Nelze předpokládat, že si každý zařídí takovýto certifikát. Proto v této aplikaci bude certifikační autoritou server a autentizace bude zaručena pomocí nějakého bezpečného protokolu.

výhody: • ideální řešení

nevýhody: • nelze zde použít

3.4.2

IKE

IKE (Internet Key Exchange) je protokol sloužící pro ustanovení bezpečnostní asociace používané IPSec. Používá framework pro autentizaci a výměnu klíčů ISAKMP (Internet Security Association and Key Management Protocol), části Oakley a SKEME (Secure Key Exchange Mechanism) [2]. Jedná se o komplexní protokol. Protokol IKE používá UDP port 500. Vzhledem k tomu, že během vytváření bezpečnostní asociace se přenáší veřejné klíče a mohou se přenášet certifikáty [3], by teoreticky šel protokol IKE z tohoto hlediska použít. Bohužel IKE je příliš svázáno s IPSec, nelze nebo je obtížné použít IKE samostatně, a byl by proto velký problém ho použít v této aplikaci. Neexistuje nebo alespoň mi není známa multiplatformní otevřená implementace IKE. Protokol je potřeba správně nakonfigurovat. Navíc klient nemá certifikát, dokud mu server nepodepíše žádost o certifikát, bylo by otázkou, jestli by šlo IKE pro toto použití nějakým způsobem „ohnout“ a zda by to bylo ještě bezpečné. Existuje ještě IKEv2, které má různá vylepšení, existují i jeho implementace, ale z pohledu použití v dané aplikaci je na tom stejně jako původní IKE.

výhody: • komplexní protokol

nevýhody: • svázané s IPSec • chybí multiplatformní implementace • nastavování

3.4. AUTOMATICKÁ DISTRIBUCE CERTIFIKÁTŮ

3.4.3

15

Kerberos

Kerberos je protokol, který řeší autentizaci klienta a serveru přes nezabezpečený komunikační kanál. Klient žádá autentizační server o tiket, který v poslední fázi obsahuje kromě jiných informací časové razítko, čas expirace tiketu a klíč [15], který může být použit pro šifrování další komunikace. Existuje implementace Kerberos V5 pro volné použití vyvinutá na MIT. Verzi 4 tohoto protokolu už není vhodné používat, protože používá dnes již slabou šifru DES (Data Encryption Standard) [9]. Kerberos V5 běží standardně na portu 88. V UNIXových systémech existují standardní nástroje, které umí použít Kerberos a šifrovat komunikaci pomocí dohodnutého klíče např. program rcp, který by se mohl použít pro danou aplikaci. Bohužel verzi pro Windows, která by uměla totéž, jsem nenašel. Pro přenos certifikátů by pak bylo zapotřebí šifrovat data „ručně“ a posílat je přes existující nebo vlastní protokol pro přenos souborů, otázkou je, zda by pak byla zaručena integrita dat. výhody: • autentizace • free multiplatformní implementace z MIT nevýhody: • instalace a nastavování • následný přenos dat

3.4.4

SSL/TLS

SSL (Secure Sockets Layer), respektive TLS (Transport Layer Security) používá OpenVPN pro zabezpečení svého kanálu. SSL/TLS umí ověřit identitu serveru a klienta na základě certifikátu, zde je ovšem stejný problém, který by měl řešit právě tento systém (podepsané certifikáty nejsou k dispozici). Protokol SSL/TLS by při výměně certifikátů zajišťoval šifrování komunikace symetrickou šifrou na základě hesla. Jsou zde dvě možné varianty. Použít program pro výměnu souborů založený např. na SFTP (Secure File Transfer Protocol), HTTPS (Hypertext Transfer Protocol Secure), ... To by vyžadovalo najít a použít nějaké jednoduché implementace pro Windows a Linux. Bylo by ovšem nutné jimi podmínit použití celé aplikace. Druhá možnost je použít SSL/TLS přímo v kódu a jednoduché, takto šifrované, přenášení souborů si napsat sám. Např. knihovna Qt ve svém síťovém modulu nabízí třídu QSslSocket, která použití SSL/TLS usnadňuje. To je varianta, která mi příjde ze zatím uvedených nejvíce optimální. výhody: • běžný způsob zabezpečení komunikace

16


3.4.5

Vlastní řešení — Exchanger

Vlastní řešení zahrnuje šifrování a integritu přenášených zpráv, definování informací, které se budou přenášet, způsob autentizace. Šifrování a integrita zpráv bude zajištěna knihovnou s kryptografickými funkcemi projektu OpenSSL. Bude použito silné šifrování — AES (Advanced Encryption Standard) s délkou klíče 256 bitů v módu CBC (Cipher Block Chaining). Integrita bude zaručena integritním nepadělatelným kódem HMAC (Keyed-Hash Message Authentication Code), konkrétně HMAC–SHA–1 [7]. Klient bude autentizován na základě jména a hesla. Z hesla bude odvozen klíč pro AES a HMAC. Jelikož pouze klient a server budou znát heslo, neměly by zprávy jít rozluštit ani pozměnit jiným subjektem. V rámci tohoto protokolu bude možné bezpečně přenášet certifikáty, žádosti o certifikát i nastavení VPN sítě. výhody: • jednoduché řešení přímo pro konkrétní aplikaci • nejsou potřeba další programy nevýhody: • možnost chyby návrhu či implementace

3.4.6

Vyhodnocení

Bohužel využití PKI se společnou důvěryhodnou certifikační autoritou zrovna pro tento účel není možné. Ten, kdo by chtěl mít svoji VPN síť takto seriózní, pravděpodobně nebude ani potřebovat takovýto program pro pomoc s vytvořením VPN sítě. Nepočítá se s použitím programu v enterprise prostředí. Pro systém automatické distribuce certifikátů vyšlo IKE jako naprosto nevhodné. Ani by nebylo možné provést všechny potřebné kroky v rámci tohoto protokolu, natož použít nějakou implementaci IKE pro tento účel. Zpočátku se jevil jako dobrý nápad použití protokolu Kerberos. Kerberos jako takový by vyřešil autentizaci, ale zde by mohl být problém ve výměně potřebných informací. Dalším proti je potřeba nainstalovat a zkonfigurovat příslušný program, to by byla další zátěž pro uživatele. Vlastní protokol, který řeší šifrování a integritu po svém se může zdát jako bezpečnostní risk. Jedná se však o relativně jednoduchý protokol a bezpečnostní funkce, které zde budou použité, pakliže budou správně použité, zaručí bezpečnost porovnatelnou s mnohem komplexnějšími protokoly. Samozřejmě stejného a pravděpodobně i jistějšího výsledku by mohlo být dosaženo pomocí SSL/TLS vrstvy. SSL/TLS ale řeší mnoho dalších věcí, které se zde nevyužijí. Proto především pro názornost navrhnu kompletně vlastní protokol. SSL/TLS vrstva může být použita v dalších verzích aplikace.

3.5. ETHERNET BRIDGING

3.5

17

Ethernet bridging

Režim ethernet bridging se obtížněji zprovozňuje narozdíl od směrovaného režimu. Aby funkce aplikace byly konzistentní, je nezbytné, aby z uživatelova pohledu bylo jedno, jestli VPN síť pracuje na 2. nebo 3. vrstvě OSI (Open Systems Interconnection) modelu. Rozdíl ovšem je, že v režimu ethernet bridging funguje broadcastový provoz i protokoly jako IPX (Internetwork Packet Exchange). Tento režim používá na straně serveru síťový most, kterým přemostí TAP rozhraní a další virtuální či fyzická síťová rozhraní. Ovšem je zde problém, když se použije fyzické rozhraní používané pro přístup do sítě, zvláště sítě Internet, může to být bezpečnostní riziko a zároveň se pro očíslování sítě musí použít určitý adresní rozsah. Na Windows jsem vymyslel následující řešení tohoto problému, které nijak neomezuje uživatele v nastavení sítě VPN. TAP adaptér se přemostí spolu s virtuálním loopback adaptérem. Na síťovém mostu se nastaví libovolná adresa z nějakého privátního rozsahu a pomocí NAT (Network Address Translation) s přesměrováním portu VPN z rozhraní připojeného do Internetu na tento síťový most je možné tuto privátní síť zpřístupnit. V tomto bodě předpokládám, že nebude problém aplikovat stejné řešení na platformě Linux. Výcházím z toho, že NAT, loopback adaptér i síťový most zde existují.

18


Kapitola 4

Realizace 4.1

Použité technologie

Program je napsán v jazyce C++, zejména kvůli autorově zkušenostem s tímto jazykem. Jako další aspekt tohoto výběru může sloužit velký počet šifrovacích knihoven (pro účely komunikačního protokolu), jednoduché volání API (Application Programming Interface) funkcí OS (nakonec nebylo tak úplně potřeba, ale je lepší mít tyto možnosti), dobrá přenositelnost kódu mezi platformami. Abych dodržel podmínku multiplatformnosti programu, použil jsem framework Qt. Vývoj probíhal na OS Microsoft Windows XP SP3 32-bit verze v prostředí Microsoft Visual Studio 2005 Standard Edition, které bylo zvoleno nejen kvůli dobré autorově zkušenosti s ním, ale kvůli formátu knihoven. Linker MSVC (Microsoft Visual C++) používá knihovny ve formátu .lib, ve kterém je dostupná většina zkompilovaných knihoven v aktuálních verzích, kdežto balík MinGW (konkrétně linker ld) používá knihovny ve formátu .a, formáty sice lze mezi sebou převést, ale zbytečně by se to tím mohlo zesložitit. Překlad a ladění na linuxové platformě probíhal v prostředí Qt Creator 1.0.0. Návrh software, konkrétně UML (Unified Modeling Language) diagramy, jsem vytvářel v Microsoft Office Visio 2007, není to sice uznávaný CASE (Computer-Aided Software Engineering) nástroj, ale pro vizualizaci diagramů naprosto postačuje. Veškeré vytvořené diagramy jsou součástí elektronické přílohy této práce. Framework Qt ve verzi 4.6.0 jsem překompiloval, protože není k dispozici zkompilovaná verze knihoven pro MSVC 2005. Existuje sice verze pro MSCV 2008, ale zde je hlavně problém v debug verzi knihoven, které jsou slinkovány s vyšší debug verzí MSVCRT (Microsoft Visual C++ Run-Time knihovny), která se distribuuje pouze s instalací MSVC 2008. Program z celého frameworku využívá pouze knihovny QtCore4 a QtGui4, respektive QtCored4 a QtGuid4. Jako knihovnu s bezpečnostními funkcemi jsem vybral „prověřenou“ knihovnu crypto, která je mimojiné součástí programu OpenSSL, konkrétně libeay32 (Windows) a libcrypto (Linux). Dále ve verzi pro Windows používám technologii WMI, která je v kódu přístupná přes COM rozhraní.

19

20

KAPITOLA 4. REALIZACE

4.2

Protokol Exchanger

Protokol, který bude zajišťovat automatickou distribuci certifikátů a parametrů sítě, je mojí vlastní záležitostí. Z hlediska logiky a toku dat jde o half-duplex — v jednom okamžiku vždy jedna strana poslouchá a ta druhá vysílá. Lze jej tedy jednoduše popsat jako stavový automat. Je založen na protokolu TCP, který je spojově orientovaný a spolehlivý. Předpokládá se tedy, že data budou chodit ve formě datového proudu v pořadí a neduplikovaná. Na této vrstvě musí protokol detekovat ukončení spojení, chyby soketu způsobí okamžité ukončení spojení. Jelikož celá komunikace je jeden dlouhý datový proud, je potřeba nějakým způsobem oddělovat jednotlivé zprávy. Zároveň je nutné rozeznávat jednotlivé typy zpráv. K těmto účelům slouží hlavička, která se skládá z pole obsahujícího délku zprávy a pole pro její typ. Za hlavičkou je vlastní obsah zprávy a na konci zprávy je pole s kódem HMAC, viz obrázek 4.1. Stanice se ověřují jménem a heslem. Na serveru je úložiště, kde jsou dvojice jméno–heslo pro všechny povolené klienty. Jméno se používá pro rozlišení klientů a vyběr správného hesla na straně serveru. Klíč pro zde použitou symetrickou blokovou šifru AES i nepadělatelný integritní kód HMAC se odvozuje z hesla a je pro obě funkce stejný. Konkrétně se pro odvození klíče použije hashovací funkce SHA–1 (Secure Hash Algorithm 1). Tady by možná mohl být bezpečnostní problém v takovémto odvození klíče, ale narozdíl od DES, AES nemá slabé klíče [6].

4.2.1

Formát zprávy

Protokol pracuje se zprávami, které mají předepsaný formát. Všechny části: hlavička, data a HMAC jsou přítomny ve všech zprávách. Formát zprávy je znázorněn na obrázku 4.1.

Hlavička

LENGTH Neznaménkové čtyřbajtové číslo v síťovém pořadí bajtů určující počet zbývajících bajtů zprávy za hlavičkou (součet počtu bajtů polí DATA a HMAC).

TYPE Jeden bajt určující typ zprávy, respektive její obsah.

DATA Vlastní obsah zprávy. Je to posloupnost bajtů proměnné délky. Obsah může být v otevřeném tvaru, nebo je šifrovaný.

HMAC Za daty je přilepen nepadělatelný integritní kód HMAC–SHA–1, má fixní velikost 20 bajtů. Kód vznikne z hlavičky a dat, tudíž hlavička a data jsou chráněny proti podvržení.

4.2. PROTOKOL EXCHANGER

LENGTH (4B)

TYPE (1B)

21

DATA

HMAC (20B)

Obrázek 4.1: formát zprávy protokolu

4.2.2

Popis komunikace

Komunikace tímto protokolem probíhá mezi klientem a serverem. Celý proces je rozdělen do několika kroků, v každém kroku se komunikuje vždy jen jedním směrem — jedna stanice vysílá, druhá přijímá. Které zprávy a jakým směrem jsou posílány, je popsáno na obrázku 4.2. Během procesu mohou nastat různé chyby (ukončené spojení, chyba soketu, chyba při čtení souboru, neplatná zpráva, ...) Když nějaká chyba nastane, spojení je ukončeno stranou, která chybu detekovala. Jednotlivé kroky jsou rozepsány dále z pohledu klienta a serveru. Jednotlivé stavy na straně klienta ilustruje obrázek 4.3 a na straně serveru to je obrázek 4.4. Krok 1 Klient iniciuje TCP spojení se serverem. Poté klient pošle zprávu, kde data obsahují nezašifrované jméno klienta. Klient čeká, dokud není celá zpráva odeslána (to zjistí od nižší vrstvy — soketu), než přejde do dalšího kroku. To je z důvodu, aby se komunikace nezasekla, kdy druhá strana čeká na konec zprávy, zatímco ta první čeká na zprávu v dalším kroku. Na druhé straně server očekává zprávu se správně nastaveným typem, přečte jméno klienta a zjistí, zda je jméno definované na serveru. V případě, že je jméno definováno, použije přidružené heslo pro další komunikaci a přejde do další fáze. Jinak server ukončí spojení. Krok 2 Server pošle zprávu s určitými parametry sítě VPN, které jsou potřeba pro úspěšné připojení k VPN serveru. Tyto parametry se serializují a tato data jsou již před odesláním

22


šifrována, protože obě stanice již znají klíč, který mají použít. Než přejde do další fáze, ujistí se, že celá zpráva byla odeslána. Klient přijímá zprávu s parametry. Když ji celou přečte, spočítá HMAC hlavičky a dat a porovná ho s HMAC, který přišel se zprávou. Jestliže se liší, druhá strana nepoužila stejný klíč, nebo byla zpráva změněna — komunikace bude ukončena. Následuje rozšifrování dat a načtení parametrů do nastavení klienta. Klient přejde k dalšímu kroku, zde je klient jistý, že komunikuje se správným serverem. Krok 3 Klient pošle žádost o certifikát CSR (Certificate Signing Request), předtím ho případně ještě vygeneruje společně s privátním klíčem. Zase se ujistí, že zpráva byla poslána než přejde k dalšímu kroku. Zde může nastat chyba, kdy nelze přečíst nebo vygenerovat soubor se žádostí o certifikát — ukončení komunikace. Server přijímá zprávu se žádostí o certifikát. Jestliže HMAC u zprávy souhlasí, ví i server, že komunikuje se správným klientem. Server musí žádost podepsat certifikační autoritou CA (Certificate Authority). Zde může nastat chyba, kdy se žádost nepodaří podepsat, to má za následek ukončení komunikace, jinak vznikne certifikát CRT (Certificate) a server přejde do následujicí fáze. Krok 4 Server pošle certifikát certifikační autority CA CRT, aby klient mohl ověřit pravost certifikátu serveru. Jako pokaždé se ujistí, že zpráva byla poslána než přejde k dalšímu kroku. Zde by neměl nastat problém, ale v případě, že se nepodaří načíst soubor CA CRT, spojení se ukončí. Klient přijímá zprávu obsahující CA CRT, u které nejdříve zkontroluje HMAC, poté rozšifruje, uloží soubor na disk a přejde k dalšímu kroku. Krok 5 V posledním kroku server pošle certifikát klienta CRT, platí totéž co v předchozím kroku. Poté, co je celá zpráva odeslána, začne server ukončovat spojení. Klient očekává zprávu s CRT, stále se kontroluje HMAC, data se rozšifrují a jako v předchozím kroku se CRT uloží na disk. Klient začne také ukončovat spojení. Spojení na obou stranách bude uzavřeno a celý proces končí.

4.3

Problémy

Při implementaci aplikace se vyskytly nějaké potíže, s některými nebylo těžké se vypořádat, jiné přetrvaly. Zde bych rozebral ty nejzásadnější.

4.3.1

Multiplatformnost

Z toho, jestli bude kód aplikace přenositelný a bude fungovat stejně na obou platformách, jsem měl největší obavy. S použitým frameworkem Qt jsem neměl žádné zkušenosti. Místo síťového modulu Qt jsem použil sokety, které se chovají na obou platformách stejně, což jsem měl už vyzkoušené. Nakonec s překladem programu na obou platformách nebyl žádný problém.

4.3. PROBLÉMY

23

Dalším aspektem přenositelnosti celého řešení je propojení s dalšími programy. To je zde realizováno pomocí skriptů, jednotlivé interprety příkazové řádky nejsou stejně mocné (cmd neumí tolik funkcí jako bash), v tom ale problém nebyl, ve Windows nebylo pokročilé funkce potřeba. Program OpenSSL je na obou platformách shodný (nebo alespoň použité funkce se chovají stejně). Znatelná odchylka nastala až ve zprovoznění režimu ethernet bridging programu OpenVPN. Způsob, který funguje na Windows (síťový most, loopback adaptér a NAT), na Linuxu nefunguje, což jsem nepředpokládal. Nelze přidat loopback rozhraní do síťového mostu, to je problém, protože aby toto řešení fungovalo, musí být kromě TAP rozhraní přemostěno další rozhraní. Další takové rozhraní není obyčejně dostupné. Naštěstí zde funguje přímé použití bez síťového mostu. Je stále nutné použít NAT.

4.3.2

Kódování řetězců

Největší problém, na který jsem narazil je kódování řetězců. Qt nabízí třídu pro řetězce QString, která umí pracovat v UNICODE, převádět mezi různým typem kódování např. ASCII (American Standard Code for Information Interchange), UTF–8, UTF–16, UCS–4 (Universal Character Set), ... Takže v rámci stejného programu není s řetězci žádný problém. Obyčejně bych UNICODE nepoužíval v takovéto aplikaci. Aplikace ale musí spolupracovat s dalšími programy, předávat jim parametry. Některé z těchto parametrů musí být v UNICODE, zejména pak na platformě Windows, kde se používá pro názvy souborů a adresářů, ale i síťových rozhraní. Parametry je potřeba ukládat do souborů, to ovšem není přiliš velký problém s použitím UTF–8, stejným způsobem se přenáší řetezce přes síť Exchanger protokolem. Programy jsou zde volány pomocí skriptů, které se spouští v interpretu příkazové řádky (ve Windows to je cmd, na Linuxu to je bash). Všechny potřebné parametry se předávají jako argumenty skriptu. Interpret je spuštěn v novém procesu vytvořeném pomocí třídy QProcess. QProcess vezme argumenty předané v programu, kde jsou reprezentovány pomocí QString, a předá je API funkcím v kódování podle dané platformy. Zde nastává ten největší problém. Skriptům spouštěným na platformě Windows se argumenty předají v UTF–16, zatímco na platformě Linux podle nastavených lokále. Programy, které slouží pouze dané platformě (mkdir, netsh, ...), očekávají vstup v daném kódovaní. Problém nastává hlavně s programem OpenSSL, který očekává jako vstup ASCII řetězec, nebo při použití přepínače „-utf8“ řetězec kódovaný v UTF–8 — nelze tedy přímo použít UTF–16 řetězce. Ve Windows se tedy pro argumenty skriptů místo UNICODE použije mechanismus kódových stránek [11]. Protože certifikáty vytvořené OpenSSL se posílají mezi stanicemi, kde mohou být rozdílné platformy, lokále či kódové stránky (CP852 CP1250, CP1252, ...), může docházet v souvislosti s tímto k potížím. Nejjednodušším řešením problému je používat pouze znaky ASCII pro parametry, které s tímto souvisí. Jedná se zejména o tyto parametry: název sítě, jméno klienta, kód země, jméno města. Zatím se jedná pouze o doporučení, není to v aplikaci nijak zakázáno. Je možné, že v dalších verzích se podaří problém odstanit převedením určitých argumentů skriptu na UTF–8.

24

4.4


Licence

Důležitou otázkou při vyvýjení software je, pod jakou licencí uvolnit své dílo. Bohužel tento aspekt je leckdy opomíjen. Podle mého názoru to je tím, že studenti se ve škole učí díla vytvářet, ale už ne, jak s nimi dále nakládat, chránit je, využívat díla jiných autorů, ... Každopádně tento software vyvýjím, aby sloužil co nejvíce uživatelům. Nemám v úmyslu poskytovat tento software exklusivně žádnému dalšímu subjektu. Neočekávám žádné finanční příjmy z této aktivity, proto chci, aby byl software dostupný všem zcela zdarma. Ještě bych dodal, že chci zveřejnit zdrojový kód hlavně z důvodu, aby si každý mohl ověřit, že se software nesnaží úmyslně poškodit jeho uživatele, dále aby případně mohl zdrojový kód posloužit ke vzdělávacím účelům. Software tedy bude tzv. open source. Protože software používá knihovny jiných autorů — jedná se o framework Qt, který je distribuován pod LGPL (Lesser General Public License), dále knihovnu OpenSSL, která je distribuovaná pod duální Apache–style licencí. Tyto skutečnosti omezují možnosti, jakou použít pro svoje dílo licenci. LGPL říká, že odvozené dílo musí použít stejnou licenci (tedy LGPL), je zde však možnost použití jiné i nesvobodné licence v případě, že se nejedná o odvozené dílo, ale pouze o práci, která používá knihovnu. Ovšem zde se názory, co je to či ono, liší. Abych se vyhnul podobným nejednoznačnostem ve svém software, použiji licenci GPL, se kterou je LGPL kompatibilní [1]. Pro knihovnu OpenSSL, která se přilinkovává, musím uvést výjimku, protože není pod licencí kompatibilní s GPL (GPL toto umožňuje). Další omezení přidává vývojové prostředí (Microsoft Visual Studio 2005 Standard Edition), které jsem použil a které mi bylo poskytnuto s akademickou licencí. Zde je omezení, že se nesmí použít ke komerčním účelům [12]. Samotná GPL licence toto nezaručuje, je možné takto šířené programy komerčně prodávat, ale jelikož budu software poskytovat zdarma pomocí Internetu, věřím, že i tato podmínka bude splněna.

4.4. LICENCE

25

Network

PARAMETERS encrypted

CLIENT CSR encrypted

CA CRT encrypted

EXCHANGER – SERVER

EXCHANGER – CLIENT

CLIENT NAME open form

CLIENT CRT encrypted

Obrázek 4.2: fungování protokolu pro distribuci certifikátů a parametrů

26


Sending name sended

Receiving parameters received

Generating key pair succeeded

socket error

Sending CSR

error

error

error

error

error

sended

socket error

Receiving CA CRT received

socket error Receiving CRT received

socket disconnected Disconnecting

Disconnected

Obrázek 4.3: stavový diagram protokolu na straně klienta

4.4. LICENCE

27

Receiving name received

Sending parameters sended

Receiving CSR

socket error

received

error

Signing CSR

socket error

succeeded

error

error

error

error

Sending CA CRT sended

Sending CRT sended

socket disconnected Disconnecting

Disconnected

Obrázek 4.4: stavový diagram protokolu na straně serveru

28


Kapitola 5

Testování Testování je velice důležitá část vývoje každého software i jiných činností. Jedná se o proces, kdy se testovaný program spouští s úmyslem najít chyby a ověřit jeho kvalitu. Kvalitou se rozumí míra splnění požadavků kladených na daný software. Jsou to požadavky sepsané podle prání a potřeb zákazníka, stejně tak požadavky, které nemusí být nikde uvedeny, ale jsou předpokládány např. stabilita programu, žádné nežádoucí postranní efekty (trojské koně, malware),...

5.1

Zaměření testování

Testování je samo o sobě časově nákladnou činností. Svědčí o tom i poměr testerů k vývojářům. Ten je nejčastěji 1:3 podle průzkumu QAI’s 20th Annual Software Testing Conference ze září roku 2000 [16]. Podle uvedeného poměru bych měl mít k dispozici třetinu testera, proto nemůžu věnovat testování tolik času, kolik by bylo potřeba, stejně nikdy nelze otestovat všechno. Navíc podle Pareto principu 20% příčin způsobí 80% defektů [10]. Je absolutně nezbytné vybrat jen malou množinu testů, která pokryje co nejlépe, co možná nejvíce těch nejdůležitějsích částí software. Vybral jsem následující části, jsou v seřazeny podle jejich závažnosti (severity): • konzistence programu • komunikační protokol • multiplatformnost

5.1.1

Konzistence programu

Testování konzistence programu bude spočívat v testování GUI, čili jeho tzv. „oklikáním“, podle určitých scénářů. Kromě pozorování změn v GUI (řetězce v polích, stavy tlačítek, chování při změně velikosti okna, ...) se budou také sledovat případné změny v souborech, které program vytváří (změny v konfiguračních souborech, chybějící/přebývající soubory, ...).

29

30

KAPITOLA 5. TESTOVÁNÍ

Důležitou otázkou je, zda se tyto testy budou provádět manuálně či by se neměly automatizovat. Využití automatizace testů bych viděl při regresních testech, ale vzhledem k tomu, že pro automatické testování GUI je nutný speciální nástroj např. IBM Rational Robot a tvorba skriptů + jejich údržba jsou časově náročné, bude se testování GUI provádět manuálně. Avšak pro kontrolu stavu souborů lze případně vytvořit relativně jednoduché skripty, které kontrolu usnadní. Tímto způsobem testovaný program bude sledován nástrojem pro testování správy paměti např. program IBM Rational PurifyPlus nebo Valgrind. Toto je důležité u tzv. „unmanaged“ kódu, což je tento případ. Lze tak odhalit případné memory leaks, které mohou kromě paměťové efektivity negativně ovlivnit stabilitu programu. V souvislosti s těmito testy by mohla být otestována efektivita kódu a provedena kontrola pokrytí kódu aplikace. Pro oba tyto testy je potřeba potřeba aplikaci spustit ve speciálním programu. První zmíněný test by mohl být proveden např. v programu IBM Rational Quantify jehož výstupem je graf volání funkcí s vyznačením těch funkcí, ve kterých se strávilo nejvíce času. Na jeho základě by se tak odhalit potenciální bottleneck, kdy program zbytečně dlouho čeká, i když by nemusel, či deadlock, kdy některé vlákno uvízne v některé funkci až do konce programu. Takto program otestovat je rozhodně dobré pro ověření stability (odhalení deadlock), případně následnou optimalizaci kódu (hledání bottleneck). Ke kontrole pokrytí kódu aplikace slouží např. program IBM Rational PureCoverage. Výstup z takovéhoto typu programu je schopen vyjádřit, kolikrát byla jaká funkce za celou dobu běhu testovaného programu volána, přesně kolik řádků funkce bylo vykonáno a na základě toho lze najít kód, který není nikdy vykonán. Tento test se používá nejčastěji v kombinaci s jednotkovými testy a kontroluje se tak jejich pokrytí. Avšak pro tento případ by připadalo v úvahu použití, kdy by se kód na základě tohoto testu optimalizoval. Zejména z časových důvodů toto ale provádět nehodlám.

5.1.2

Komunikační protokol

K otestování funkčnosti komunikačního protokolu bude za potřebí alespoň dvou instancí testovaného programu, jedna bude nastavená jako server, druhá jako klient. Jelikož komunikační protokol používá TCP sockety, je potřeba ověřit správné navázání a ukončení každého spojení. Dále je třeba kontrolovat data, která chodí navázaným komunikačním kanálem. K tomuto účelu se nejlépe hodí síťový analyzátor Wireshark, který umožňuje sledovat TCP stream. Komunikační protokol musí fungovat za normálních provozních podmínek, musí být ovšem také odolný vůči chybám i záměrným útokům. Jelikož všechna data kromě paketu se jménem jsou šifrována a celý paket je chráněný proti přepsání nepadělatelným integritním kódem HMAC, budou útoky spočívat ve změně hlavičky, konkrétně prvních čtyř bajtů, které obsahují délku paketu za hlavičkou. Lze tak zapříčinit, že nebude možno sestavit paket z datového proudu správně.

5.2. TESTOVACÍ PROSTŘEDÍ

5.1.3

31

Multiplatformnost

Protože důležitým požadavkem je multiplatformnost, konkrétně jsou podporovány operační systémy Windows XP a Linux 2.6, Je nutné ověřit funkčnost programu na stejné platformě i mezi oběma platformami. Tudíž stejné testy by měly proběhnout na obou platformách stejně.

5.2

Testovací prostředí

Testovací prostředí beží na jednom počítači ve virtuálních prostředí. Jako hostující systém je zde Windows XP SP3 32-bit. Oba virtualizované systémy jsou propojeny s hostujícím systémem přes síťová rozhraní, aby mohly oba systémy komunikovat přímo mezi sebou, jsou tato rozhraní propojena síťovým mostem (192.168.30.1/24). Windows Jako testovací prostředí založené na platformě Windows slouží operační systém Windows XP SP2 build 2600 nainstalovaný ve virtualizačním nástroji VirtualPC 2007 32-bit verze. Na tomto systému je nainstalovaný balík OpenVPN 2.0.9, knihovna vcredist_x86_2005 a kvůli debug verzi programu, je zde zkopírována debug verze knihoven uvedených v manifestu programu ze systému, na kterém byl program zkompilován. Jsou zde nainstalovány testovací nástroje IBM Rational PurifyPlus a IBM Rational Quantify. Systém je nakonfigurován následujícím způsobem. Služba „Brána Firewall / Sdílení připojení k Internetu (ICS)“ je zastavena a zakázána, „Telefonní subsystém“, „Správce vzdáleného přístupu“ a „Směrování a vzdálený přístup“ jsou povoleny a spuštěny. Jsou zde přítomna následující síťová připojení: • „Připojení k místní síti“ — spojení s hostitelským systémem (192.168.30.12/24) • „TAP“ — TAP adaptér nainstalovaný s OpenVPN • „Loopback“ — Microsoft Loopback Adapter • „Síťový most“ — Ethernet Bridge na propojení „Loopback“ a „TAP“ Linux Testovací prostředí Linux, konkrétně distribuce Ubuntu 9.04 desktop i386 je nainstalovaná ve virtualizačním nástroji innotek VirtualBox 1.5.6. Systém je plně aktualizovaný. Je zde nainstalovaný balík openvpn 2.1˜rc11-1ubuntu3, knihovny libssl0.9.8, libqt4 4.5.0. Nainstalovaný je zde i nástroj potřebný pro testování Valgrind 1.3.4.1. Jsou zde přítomna následující síťová připojení: • „eth1“ — spojení s hostitelským systémem (192.168.30.11/24) • „tap0“ — TAP adaptér přidaný pomocí OpenVPN

32


5.3

Testovací případy

TC1: Konzistence stavů Aplikace se může nacházet v několika stavech, které souvisí s tím, jaký režim VPN právě spravuje. Jednotlivé stavy se vyznačují dostupnými dialogy a jejich konfigurací. Po spuštění je aplikace ve výchozím stavu — k dispozici jsou dialogy pro správu sítí file a globální nastavení global, u dialogu file jsou umožněny pouze volby new server, new client a open, ostatní jsou zakázány. Připravíme si prázdný testovací adresář. Vytvoříme nový server, v dialogu otevřeme testovací adresář a jako název souboru do dialogu zadáme „server1“, aplikace se přepne do správy VPN serveru v režimu TUN, tuto skutečnost ověříme procházením všech dostupných dialogů, které by měly odpovídat danému profilu a měly by být ve výchozím stavu až na dialog file, u něj budou všechny volby povoleny. V testovacím adresáři pak musí být adresář „server1“ obsahující soubor „openssl.cnf“ zkopírovaný z adresáře se skripty a konfigurační soubor „config.txt“ s vyplněnými řádky „session=server1“ a „profile=0“ V dialogu nastavení sítě network, přepneme režim VPN na TAP. Tentokrát se aplikace přepne do správy VPN serveru v režimu TAP, všechny dialogy by měly být ve stejném stavu, akorát dialog s ovládacími příkazy command a dialog network se budou lišit. Dialog potvrdíme tlačítkem OK a uložíme konfiguraci volbou save z dialogu file. V konfiguračním souboru se změní řádka „profile=1“. Zavřeme spravovanou síť, aplikace by se měla přepnout do výchozího stavu. Nyní vyzkoušíme otevřít stejnou síť, v dialogu otevřeme testovací adresář a vybereme adresář s názvem dané sítě — „server1“. Všechny dialogy by měly být ve stejném stavu, jako když jsme správu dané sítě uzavírali. Tudíž i vstupní pole v dialogu network musí obsahovat poslední potvrzené nastavení uložené v konfiguračním souboru. V tomto bodě zkusíme danou síť smazat, aplikace se zase vrátí do výchozího stavu, ale adresář „server1“ v testovacím adresáři by neměl existovat. Analogicky provedeme test správy klientů, akorát adresář se bude jmenovat „client1“ a při přepnutí režimu z TUN na TAP se nezmění žádný dialog. Parameter „profile“ bude 2 a 3. Po celou dobu testu bude program sledován pomocí nástroje pro testování správy paměti. TC2: Komunikační protokol Aplikaci upravíme globální nastavení, na platformě Windows vyplníme cestu k instalačnímu adresáři programu OpenVPN, zaškrtneme funkce autosave a autogenerate. V testovacím adresáři podobně jako v TC1 vytvoříme klienta a server. U klienta v nastavení sítě vyplníme adresu, na kterou se pokusí připojit (na testovacím prostředí Windows „192.168.30.11“, Linux „192.168.30.12“), port exchange serveru bude „5000“, jméno klienta „Karel“ a heslo „1234“. Toto nastavení uložíme, v konfiguračním souboru by mělo být toto nastavení zapsáno. Na serveru nastavíme jméno sítě „vpn1“, VPN port „1194“, VPN protokol „udp“, id země „CZ“, jméno města „Liberec“, délku klíče „1024“ a port exchange serveru „5000“. Na serveru dále přidáme login „Karel“ s heslem „1234“ a vygenerujeme klíče s certifikáty. Kromě konfiguračního souboru s odpovídajícím nastavením by adresář měl obsahovat soubory „index.txt“ a „serial“ zkopírované z adresáře se skripty, dále naprázdné soubory „dh.pem“, „ca.key“,

5.3. TESTOVACÍ PŘÍPADY

33

„ca.crt“, „server.key“ a „server.csr“. Tato bude výchozí nastavení pro tyto testy. Testovací adresář si proto zazálohujeme a před každým testem obnovíme. Síťový provoz můžeme odchytávat na všech systémech, ale bylo by to zbytečné, protože systémy jsou propojeny přímo přes hostitelský systém, lze předpokládat, že provoz bude fungovat spávně oběma směry. Síťový provoz se bude proto odchytávat na hostitelském systému na síťovém mostu, který obě testovací prostředí propojuje. TC2.1: Správnost Na jedné instanci aplikace se načte adresář se serverem a spustí se server (exchanger), na druhé instanci se načte klient. Klient se připojí k serveru (exchange). Po celou dobu je na testovacích prostředí program sledován nástroji pro testování správy paměti a pro zefektivnění kódu (postupně, ne najednou). Vyhodnocení testu pomůže také analýza logovacího souboru, který je na serveru i klientovi. Cílem testu je zjistit, zda celá sekvence proběhla úspěšně, případně zjistit, kde nastala chyba. Na klienta by se měly přenést některé hodnoty nastavené na serveru (session, VPN port, VPN protokol, id země, jméno města, délka klíče a režim VPN), také by se u klienta měly objevit neprázdné soubory „client.key“, „client.csr“, „client.crt“ a „ca.crt“. Na serveru se zase vytvoří soubory „Karel.csr“ a „Karel.crt“. TC2.2: Bezpečnost TC2.1 probíhá za ideálních podmínek, tento test bude prováděn skoro stejně s rozdílem, že přihlašovací jméno v jednom případě nebude souhlasit s tím na serveru, ve druhém případě bude jméno odpovídat, ale heslo bude jiné a ve třetím nebude jméno ani heslo vyplněné. Ve všech případech nesmí sekvence skončit úspěšně, ale chyba musí být zaznamenána co nejdříve a spojení musí být ukončeno. TC2.3: Odolnost Testovat se bude pouze odolnost serveru. Telnetem se připojíme na server a pošleme několik znaků, to by mělo zapříčinit, že server přečte hlavičku, kde uvidí velké číslo v délce paketu a bude čekat na zbytek dat (v nejlepším případě). Indikace tohoto jevu je otevřené TCP spojení. Server je sledován stejnými nástroji jako v TC2.1 a TC2.2. TC3: Multiplatformnost Zda je software skutečně multiplatformní se ověří provedením testů podle TC1 a TC2 na obou platformách zvlášť. Následně TC2, kde klient a server budou každý na jiné platformě (nejdříve klient — Linux a server — Windows, potom server — Linux a klient — Windows). Cílem je dokázat funkčnost serveru a klienta na obou platformách. TC4: VPN v režimu TUN Načteme předpřipravené konfigurace klienta a serveru vytvořené při TC2. Na serveru spustíme exchanger a klientem se na něj připojíme, celý tento proces musí dopadnout podle TC2.1, tím jsou server a klient připraveni navázat VPN spojení. Na serveru ještě nastavíme v dialogu network číslo VPN sítě „172.16.0.0“, její masku „255.255.255.0“, jako TAP adaptér vybereme „TAP“ (pouze Windows, na Linuxu se použije dynamické zařízení) a spustíme VPN server volbou start z command dialogu. Otevře se samostatné okno konzole, počkáme, dokud se neobjeví hláška „Initialization Sequence Completed“. U klienta nastavíme TAP adaptér jako u serveru a připojíme se k VPN serveru pomocí volby connect v command dialogu. Otevře se zase samostatné okno, kde se v případě úspěchu

34


objeví hláška „Initialization Sequence Completed“, zde je nutné prostudovat hlášení typu warning či error, je možné, že se např. nepovede přidat záznam do směrovací tabulky apod. V případě, že všechny předchozí kroky proběhly úspěšně, ověříme funkčnost sítě VPN. To provedeme příkazem ping z klienta na server a opačně. Klient se bude snažit pingovat adresu 172.16.0.1, server pak adresu přidělenou klientovi, zde to bude s největší pravděpodobností adresa 172.16.0.6. TC5: VPN v režimu TAP Server a klient připravíme jako v první fázi TC4, ale před tím přepneme v dialogu network režim VPN na TAP, tato změna se bude propagovat do klienta v rámci výměny parametrů. V nastavení klienta pak ještě nastavíme TAP adaptér jako v TC4. Na serveru nastavíme adresu VPN serveru „172.16.0.1“, masku „255.255.255.0“, rozsah přidělovaných adres „172.16.0.10“ až „172.16.0.100“, TAP adaptér „TAP“ (Windows) nebo „tap0“ (Linux), loopback adaptér „Loopback“ (pouze Windows), bridge adaptér „Síťový most“ (pouze Windows), nic adaptér „Připojení k místní síti“ (Windows) nebo „eth1“ (Linux). Server je pak ještě nutné inicializovat volbou init NAT v command dialogu. Pak už je možné jako v TC4 spustit VPN server a připojit se k němu. V případě, že všechny předchozí kroky proběhly úspěšně, ověříme funkčnost sítě VPN. To provedeme příkazem ping z klienta na server a opačně. Klient se bude snažit pingovat adresu 172.16.0.1, server pak adresu přidělenou klientovi, zde to bude pravděpodobně adresa 172.16.0.10.

5.4

Akceptační test

Jako akceptační test budou sloužit testovací případy TC4 a TC5. Půjde o demostraci, že lze pomocí testovaného software sestavit síť VPN v obou podporovaných režimech mezi dvěma počítači — serverem a klientem.

5.5

Traceability matrices

Z následujících matic mapujících testovací případy a funkční (matice 5.1) či systémové požadavky (matice 5.2) vyplývá, že testy jsou zaměřeny hlavně na systém automatické distribuce certifikátů a parametrů sítě a dále na správnou funkčnost řešení pod oběma platformami. To je naprosto záměrné, protože se jedná o nejdůležitější vlastnosti testované aplikace.

5.6

Výsledky testování

Během testování se podařilo odhalit několik chyb, které byly následně opraveny. Bohužel vybrané testovací nástroje na testovacím prostředí Windows zapříčinily nefunkčnost protokolu Exchanger. Na stejném testovacím prostředí bez použití testovacího nástroje proběhla komunikace úspěšně. Pod testovacím nástrojem na Linuxu protokol fungoval. Testování protokolu nemohlo celé proběhnout podle představ, při testech týkajících se protokolu byl program sledován testovacím nástrojem pouze na platformě Linux.

X X

FEAT9: Generování konfigurace

FEAT8: Lokalizace

FEAT7: Správa klientů

FEAT6: Stavové informace X

X X

X X

FEAT5: Logování

X

FEAT4: Automatická distribuce certifikátů

X

FEAT3: Podpora broadcastů

FEAT2: Správa nastavení sítě

TC1: Konzistence stavů TC2: Komunikační protokol TC2.1: Správnost TC2.2: Bezpečnost TC2.3: Odolnost TC3: Multiplatfomnost TC4: VPN v režimu TUN TC5: VPN v režimu TAP

35

FEAT1: Jednoduché nastavení

5.6. VÝSLEDKY TESTOVÁNÍ

X

X X X X X X

X X X

X X

X

X

X X

X X

X X

Tabulka 5.1: traceability matrix testovacích případů a funkčních požadavků Při všech testech, kde se kontrolovala správa paměti byly odhaleny memory leaks a potenciální memory leaks, byly ale zpozorovány už v knihovnách, nikoli v hlavním programu. Potenciální memory leak nemusí nutně znamenat chybu. Z tohoto hlediska je na tom program dobře. Test protokolu Exchanger proběhl úspěšně, podařilo se dokázat odolnost vůči chybám, které by mohl běžně uživatel udělat při jeho používání (TC2.2). Také poslání velkého čísla na začátku zprávy (TC2.3) znehodnotí maximálně danou session, která zůstane viset, dokud klient neukončí spojení. Ani při těchto testech se nestalo, že by došlo k memory leak nebo by se program zasekl či spadl. Nicméně zde by bylo na místě aplikovat timeout pro každou session a omezit maximální délku zprávy, aby se minimalizovaly následky případných DoS (Denial of Service) útoků. Nejdůležitější je, že se podařilo úspěšně ověřit celková funkčnost aplikace demostrací sestavení VPN spojení klienta se serverem v obou režimech mezi oběma platformami. Při této fázi bylo potřeba ještě ladit skripy, protože původně vznikly skripty pro Windows a jejich verze pro Linux nebyla odzkoušena.

X

TC4: VPN v režimu TUN TC5: VPN v režimu TAP

TC2.3: Odolnost

TC2.2: Bezpečnost

TC2.1: Správnost

TC3: Multiplatfomnost

SR1: OS Windows XP SR2: OS Linux SR3: OpenSSL TC2: Komunikační protokol

TC1: Konzistence stavů

36 KAPITOLA 5. TESTOVÁNÍ

X X X X X X

X

Tabulka 5.2: traceability matrix testovacích případů a systémových požadavků

Kapitola 6

Závěr Na příkladu této práce je možné pozorovat, jak se mohou požadavky na software měnit během vývoje. Na začátku jsem přišel s nějakou vizí, jak by měl software vypadat a co by měl všechno umět. Ale postupně v různých fázích vývoje (návrhu, implementaci, testování) vycházelo najevo, že některé požadavky jsou založené na špatných předpokladech, a proto by nemohly být efektivně splněny. Některé tyto požadavky byly splněny jiným způsobem, než jak bylo naznačeno v jejich zápisu. Pro splnění jiných (méně závažných) požadavků zase nezbylo potřebné množství času a nebyly splněny vůbec. Je potřeba si dávat velký pozor při sbírání a sepisování požadavků na software a nečekat že se požadavky nebudou měnit. Chyba zde se projeví v dalších fázích vývoje a nezřídka to končí neúspěšným projektem. Dovolím si tvrdit, že tohle není ten případ. Na druhou stranu je pravda, že kdybych pro tento projekt měl formálně vytvořený plán, pravděpodobně bych ho nebyl schopen dodržet. Některé fáze byly delší a složitější než jsem očekával. Určitě se mi tato zkušenost bude hodit v dalších projektech. Výsledný program splnil mé očekávání. Myslím si, že by mohl být přínosem pro další uživatele. Největší přínos shledávám v automatické distribuci certifikátů a parametrů, která v jiných GUI pro OpenVPN chybí nebo je uzavřenou součástí jiných řešení VPN např. Hamachi. Dále zprovoznění ethernet bridging módu OpenVPN je zde velmi usnadněné, ačkoliv bylo nutné několik věcí obejít, aby možnosti nastavení byly stejné jako ve směrovaném módu. Další vlastností vycházející z implementace, která se dá využít, je použití skriptů. Zkušení uživatelé si jejich přepsáním mohou přizpůsobit některé funkce, nebo je ladit v případě nějakého problému. Projekt zveřejním na serveru http://sourceforge.net, který hostuje svobodný open source software. To je důležitý krok, aby se software dostal ke svým uživatelům a zároveň, abych mohl dostat zpětnou vazbu pro vývoj dalších verzí. Aby mohl být software správně používán dalšími uživateli a nedocházelo k nějakým nedorozuměním, připravil jsem názornou uživatelskou dokumentaci, která je součástí distribuce. Tato dokumentace je také elektronickou přílohou této práce.

37

38

KAPITOLA 6. ZÁVĚR

6.1

Další vývoj

Dnes již není možné přijít s novým software a myslet si, že ho budou všichni s vděčností používat. Uživatelé musí vidět přínos v používání daného software. Aplikace má GUI, to se musí jednak líbit a musí být také přehledné a výstižné. Abych mohl tyto aspekty vylepšit potřebuji mít dostatečně velkou zpětnou vazbu. Zveřejněním první verze programu dám příležitost ke zpětné vazbě. Zatím však budu schopen nezávisle na tom připravovat další verzi. Zde se mohu zaměřit na následující: • doprogramování zbylých funkcí (zobrazování stavových informací, revokace klientů, generování konfiguračních skriptů) • vylepšení stávacích funkcí (zlepšení logování, odladění skriptů) • přidání nových funkcí (kontrola validity parametrů VPN) • přidání dalších spravovaných parametrů VPN • podpora OS Windows Vista a Windows 7 • vyřešení problému s kódováním řetězců Po dostavení se případné reakce od uživatelů mohou být přepracovány a vylepšeny všechny části aplikace. Předpokládají se hlavně úpravy GUI (rozdělení parametrů VPN do skupin, výstižnější popisky a nápověda, úprava ovládacích prvků, ...)

Literatura [1] Free Software Foundation, Inc. Frequently Asked Questions about the GNU Licenses [online]. 2010. [cit. 2010-05-16]. Dostupné z: http://www.gnu.org/licenses/gpl-faq. html. [2] HADEN, R. IPsec VPN, isakmp security association, ike key exchange [online]. c2010. [cit. 2010-05-05]. Dostupné z: http://rhyshaden.com/ipsec.htm. [3] HARKINS, D. – CARREL, D. The Internet Key Exchange (IKE) [online]. c1998. [cit. 2010-05-05]. Dostupné z: http://www.ietf.org/rfc/rfc2409.txt. [4] HASENÖHRL, P. Simulace LAN přes internet [online]. 2009. [cit. 2010-05-26]. Dostupné z: https://dsn.felk.cvut.cz/wiki/vyuka/cviceni/y36sps/semestralky/ hasenp1. [5] KERST, U. VPN: vzdálený přístup bez kompromisů (1) [online]. 2009. [cit. 2010-05-26]. Dostupné z: http://securityworld.cz/securityworld/ VPN-vzdaleny-pristup-bez-kompromisu-1-1771. [6] LÓRENCZ, R. Proudové šifry, blokové šifry, DES, 3DES, AES, operační módy. In Bezpečnost přenosu a zpracování dat, Praha: ČVUT FEL, 2007. [7] LÓRENCZ, R. Hašovací funkce, MD5, SHA-x, HMAC. In Bezpečnost přenosu a zpracování dat, Praha: ČVUT FEL, 2007. [8] LÓRENCZ, R. DSA, PKI a infrastruktura. In Bezpečnost přenosu a zpracování dat, Praha: ČVUT FEL, 2007. [9] Massachusetts Institute of Technology. Kerberos: The Network Authentication Protocol [online]. 2010. [cit. 2010-05-05]. Dostupné z: http://web.mit.edu/kerberos/. [10] MAŘÍK, R. Nástroje kvality. In Testování a kvalita software, Praha: ČVUT FEL, 2007. [11] Microsoft Corporation. MSDN Library: Code Pages (Windows) [online]. c2010. [cit. 2010-05-05]. Dostupné z: http://msdn.microsoft.com/en-us/library/ dd317752%28v=VS.85%29.aspx. [12] Microsoft Corporation. Developer AA License Agreement (EULA) [online]. c2010. [cit. 2010-05-10]. Dostupné z: http://msdn.microsoft.com/en-us/academic/ bb250608.aspx.

39

40

LITERATURA

[13] Microsoft Corporation. Protokol L2TP (Layer Two Tunneling Protocol) [online]. c2010. [cit. 2010-05-26]. Dostupné z: http://technet.microsoft.com/cs-cz/library/ cc759432%28WS.10%29.aspx. [14] Microsoft Corporation. Understanding PPTP (Windows NT 4.0) [online]. c2010. [cit. 2010-05-26]. Dostupné z: http://technet.microsoft.com/en-us/library/ cc768084.aspx. [15] MLÍKA, J. Kerberos přihlašování snadno a rychle [online]. 2008. [cit. 201005-05]. Dostupné z: http://www.abclinuxu.cz/clanky/bezpecnost/ kerberos-prihlasovani-snadno-a-rychle. [16] RICE, R. The Elusive Tester to Developer Ratio [online]. 2009. [cit. 2010-0419]. Dostupné z: http://riceconsulting.com/home/index.php/Testing-Metrics/ the-elusive-tester-to-developer-ratio.html.

Příloha A

Seznam použitých zkratek VPN Virtual Private Network LAN Local Area Network GUI Graphical User Interface IM Instant Messaging MIT Massachusetts Institute of Technology PPTP Point-to-Point Tunneling Protocol OS Operating System L2TP Layer Two Tunneling Protocol IPSec IP Security TCP Transmission Control Protocol UDP User Datagram Protocol GPL General Public License NAT Network Address Translation WMI Windows Management Instrumentation COM Component Object Model WQL WMI Query Language UTF Unicode Transformation Format PKI Public Key Infrastructure FTP File Transfer Protocol SCP Secure Copy Protocol

41

42

PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK

RCP Remote Copy Protocol IKE Internet Key Exchange ISAKMP Internet Security Association and Key Management Protocol DES Data Encryption Standard SSL Secure Sockets Layer TLS Transport Layer Security SFTP Secure File Transfer Protocol HTTPS Hypertext Transfer Protocol Secure AES Advanced Encryption Standard CBC Cipher Block Chaining HMAC Keyed-Hash Message Authentication Code OSI Open Systems Interconnection IPX Internetwork Packet Exchange API Application Programming Interface MSVC Microsoft Visual C++ UML Unified Modeling Language CASE Computer-Aided Software Engineering MSVCRT Microsoft Visual C++ Run-Time SHA–1 Secure Hash Algorithm 1 CSR Certificate Signing Request CA Certificate Authority CRT Certificate ASCII American Standard Code for Information Interchange UCS Universal Character Set LGPL Lesser General Public License DoS Denial of Service .. .

Příloha B

Obsah přiloženého CD . design manual program bin src license.txt text

UML a jiné diagramy uživatelská dokumentace programu spustitelná verze (pro Windows) zdrojové kódy licence programu text této práce

43

Grafické rozhraní pro OpenVPN. Pavel Hasenöhrl

Recommend Documents