Automatische VPN-tunneling tussen OSGi-gateways

Transcriptie

1 Faculteit Ingenieurswetenschappen Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. P. LAGASSE Automatische VPN-tunneling tussen OSGi-gateways door Bas BOONE Jelle NELIS Promotor: prof. dr. ir. F. GIELEN Co-promotor: prof. dr. ir. F. DE TURCK Scriptiebegeleiders: R. HENS en J. HOLLEZ Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen Academiejaar

2

3 Faculteit Ingenieurswetenschappen Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. P. LAGASSE Automatische VPN-tunneling tussen OSGi-gateways door Bas BOONE Jelle NELIS Promotor: prof. dr. ir. F. GIELEN Co-promotor: prof. dr. ir. F. DE TURCK Scriptiebegeleiders: R. HENS en J. HOLLEZ Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen Academiejaar

4 Dankwoord Graag zouden wij iedereen willen bedanken die heeft bijgedragen tot de verwezenlijking van dit eindwerk. Op de eerste plaats bedanken wij prof. dr. ir. F. Gielen en prof. dr. ir. F. De Turck. Speciale dank gaat uit naar onze thesisbegeleiders Raf Hens en Jan Hollez voor de geboden ondersteuning, inzichtvol commentaar en snelle reactie op al onze vragen. Verder willen we Nico Goeminne danken voor de gedane suggesties en Gudrun Evertsz-Montenegro voor het nalezen van de Engelstalige extended abstract. Bas Boone en Jelle Nelis, juni 2006

5 Toelating tot bruikleen De auteurs geven de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie. Bas Boone en Jelle Nelis, juni 2006

6 Automatische VPN-tunneling tussen OSGi-gateways door Bas BOONE Jelle NELIS Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen Academiejaar Promotor: prof. dr. ir. F. GIELEN Co-Promotor: prof. dr. ir. F. DE TURCK Scriptiebegeleiders: R. HENS en J. HOLLEZ Faculteit Ingenieurswetenschappen Universiteit Gent Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. P. LAGASSE Samenvatting In deze thesis wordt een systeem besproken dat toelaat een site-to-site VPN op te zetten tussen twee netwerken die met het internet verbonden zijn via een OSGi-gateway. Dit gebeurt op een voor de gebruiker transparante en gebruiksvriendelijke manier. Allereerst wordt er een specificatie opgesteld over wat er verwacht wordt van het systeem en wordt de architectuur voorgesteld. Vervolgens worden een aantal VPN-technologieën worden besproken en vergeleken, alsook een aantal adresseringsstrategieën, die het mogelijk maken netwerken te verbinden die overlappende subnetwerken gebruiken. Wanneer beslist is van welke technologieën gebruik zal gemaakt worden, worden een aantal ontwerpbeslissingen toegelicht. Uit de testresultaten blijkt dat het systeem bij hoge bandbreedtes (100 Mbps) een significante negatieve impact heeft op de throughput, maar bij lagere bandbreedtes een zeer kleine impact heeft op throughput, vertraging en pakketverlies. Thuisgebruikers en zelfs kleine bedrijven maken gebruik van breedbandverbindingen waar de bandbreedtes (vooral qua upload) beperkt zijn. De negatieve effecten van het systeem op de eigenschappen van de verbinding zijn in deze gevallen miniem. Tot slot worden een aantal mogelijke uitbreidingen en mogelijkheden voor verder onderzoek besproken.

7 Trefwoorden OSGi, VPN, veiligheid

8 Automatic VPN tunneling between OSGi gateways Bas Boone, Jelle Nelis Supervisor(s): Frank Gielen, Filip De Turck Abstract This article describes an architecture and implementation for automatic VPN tunneling between OSGi gateways, aiming for a userfriendly, transparent solution to set up a secure tunnel between home networks. Keywords VPN, OSGi I. INTRODUCTION MANY home users have a small home network, which can be used to share files and printers, play games, etc. Since these networks are usually connected to the Internet, they would also like to be able to connect to devices on other networks. Of course, security is important: access to a network should be limited to trusted networks, and all network traffic should be safe from eavesdroppers. A similar situation exists for companies: they would like their employees on the road to have access to the company network, but only if this can be done in a secure way. Solutions addressing this problem are called Virtual Private Networks (VPN s). These solutions exist in hardware or in software. For client-to-site connections (where clients need to be connected to a network), these solutions usually suffice, although they require some technical competence on the networkside. For site-to-site connections (where two or more networks need to be connected), additional problems can arise: the gateways could be performing Network Address Translation (NAT), the gateways could have dynamically assigned IP-addresses, and the networks could be using overlapping private subnets. This article describes a solution which solves these problems, so that an authenticated, confidential and integer site-tosite VPN can be set up by non-technical users. The system is completely transparent for the client, meaning that no additional software must be installed on the client (only on the gateways) and existing connections are not hindered. The target users for this system are home users, and small companies looking for an easy-to-set-up VPN solution which does not require a lot of technical knowhow. Fig. 1. An example of a case where two networks use overlapping subnetworks: both use /24, and both gateways perform NAT. II. DESIGN To address these problems, several technologies, which are described further in the following subsections, are used. A. OpenVPN OpenVPN is used to set up a secure tunnel between gateways. OpenVPN is an SSL-based VPN solution which works by installing a virtual network interface. All traffic sent to this virtual network interface will then be authenticated, encrypted, encapsulated in UDP-packets, and sent to the remote gateway. Since it is SSL-based, X.509 certifcates are used for authentication. B. Address translation If two networks use overlapping subnetworks, address translation is used to prevent conflicts. Traffic destined for the remote network has its source address changed to a non-conflicting address, and incoming traffic from the remote network has its destination address changed back to the correct address. This way, an overlay network is created for both participating networks. C. Negotiation between gateways To be able to detect situations where subnets of the participating networks overlap, a negotiation is performed before the actual VPN setup. During this negotiation, the gateways decide which overlay networks to use. The design uses a listener pattern, so that new items that need to be negotiated (i.e. encryption algorithm to be used) can easily be added. D. OSGi The system is implemented as a set of OSGi applications (called OSGi bundles ). The OSGi Service Platform is a component-oriented computing environment for networked devices. It is used in residential gateways, but also in digital mobile phones and embedded appliances. The main benefit of using OSGi is the ability of doing remote management of the applications. This allows for easy deployment and life cycle management. E. Naming system To address the problem of gateways with dynamically assigned IP-addresses, each gateway is given a unique name. This name corresponds with the name in the X.509 certificate mentioned in section II-A. Gateways register their IP-address with a Gateway Naming System Server (GNS-server). Users can set up a VPN-connection by specifying the name of the gateway they want to connect to. Gateway names are also used by the user to specify a list of trusted gateways that can set up a VPN connection with them.

9 This naming system is also used to name individual hosts, so they can be looked up by other hosts, even though address translation is in effect (therefore using the original IP-addresses would not work). Every host can specify its desired name; it will be suffixed with the gateway name. III. TEST RESULTS Throughput and delay were measured for two setups: one using high bandwidth links (100 Mbps), and one using lower bandwidth links (effectively employing a home broadband Internet connection). If the system was employed, throughput suffered in the high bandwidth situation, because encryption on the gateways was executed slower than the rate of arriving packets. In the lower bandwidth situation, throughput was only 3% lower, which corresponds with the OpenVPN header overhead. The increase in delay was in both cases negligable. IV. CONCLUSION The described system offers a userfriendly, transparent system to set up a VPN between two (or more) networks. Security, address conflicts, and naming issues are handled by the system, and shielded from the end user. REFERENCES [1] OpenVPN website, [2] OSGi Alliance, About the OSGi Service Platform, 2004

10 INHOUDSOPGAVE i Inhoudsopgave 1 Probleemsituering Probleemschets Doel van de thesis Outline Specificatie Vereisten Use cases Architectuur Module view Negotiator ConfigurationManager AddressTranslation Policing VPNInterface AutoVPNInterface WebInterface GNS GNSserver Deployment view Client Gateways Serverpark Service Provider

11 INHOUDSOPGAVE ii 4 Technologiestudie OSGi Motivatie Overzicht Architectuur VPN-technologieën Vereisten IPSec OpenVPN PPTP, L2TP Vergelijking Adresseringsstrategie Netwerken samenvoegen Adresvertaling Ontwerp Inleiding Negotiator Generiek onderhandelingsprotocol Implementatie onderhandelingsprotocol ConfigurationManager AddressTranslation AddressTranslationConfig NegotiatorListener methodes VPNInterface Bundle startup VPNImpl AutoVPNInterface WebInterface GNS Protocol GNS Bundle startup GNSServer

12 INHOUDSOPGAVE iii BIND GNSServer Tests en resultaten Testopstelling Throughput Delay Pakketverlies Jitter Conclusie Verder onderzoek DNS op de gateway Broadcasts over de tunnel Hostnamen op het virtuele netwerk Uitbreiding naar IPv

13 INHOUDSOPGAVE iv Lijst van gebruikte afkortingen 3DES Triple DES 3DESE Triple DESE 3IDEA Triple IDEA AES Advanced Encyption Standard AH Authentication Header API Application Programming Interface ARP Address Resolution Protocol BIND Berkeley Internet Name Daemon bps bits per second CA Certificate Authority CBC Cipher Block Chaining CCP Compression Control Protocol CHAP Challenge Handshake Authentication Protocol CIDR Classless Inter-Domain Routing CIFS Common Internet File System DES Data Encryption Standard DESE PPP DES Encryption DHCP Dynamic Host Configuration Protocol

14 INHOUDSOPGAVE v DNS Domain Name System DNS-SD DNS Service Discovery ECP Encryption Control Protocol ESP Encapsulating Security Payload FCS Frame Check Sequence FTP File Transfer Protocol GNS Gateway Naming System GRE Generic Routing Encapsulation HDLC High-Level Data Link Control HMAC Hash Message Authentication Code HTTP HyperText Transfer Protocol HTTPS HTTP Secure IBM International Business Machines ICMP Internet Control Message Protocol IDEA International Data Encryption Algorithm IEEE Institute of Electrical & Electronics Engineers IETF Internet Engineering Task Force IKE Internet Key Exchange IP Internet Protocol IPCP Internet Protocol Control Protocol IPSec Internet Protocol Security IPX Internetworking Packet Exchange IPXCP Internetworking Packet Exchange Control Protocol

15 INHOUDSOPGAVE vi ISAKMP Internet Security Association Key Management Protocol ISO International Organization for Standardization ISP Internet Service Provider IV Initialisation Vector J2EE Java 2 Enterprise Edition JVM Java Virtual Machine kbps kilobits per second L2TP Layer 2 Tunneling Protocol LAC L2TP Access Concentrator LAN Local Area Network LCP Link Control Protocol LEAP Lightweight Extensible Authentication Protocol LLC Logical Link Control LNS L2TP Network Server MAC Media Access Control Mbps Megabits per second MD5 Message Digest 5 Algorithm mdns Multicast DNS MPPE Microsoft Point-to-Point Encryption MS-CHAP Microsoft Challenge Handshake Authentication Protocol MSS Maximum Segment Size MTU Maximum Transmission Unit NAS Network Access Server

16 INHOUDSOPGAVE vii NAT Network Address Translation NCP Network Control Protocols NetBIOS Network Basic Input/Output System NIC Network Interface Card OSGi Open Services Gateway initiative PAC PPTP Access Concentrator PAP Password Authentication Protocol PNS PPTP Network Server PPP Point-to-Point Protocol PPTP Point-to-Point Tunneling Protocol PRF Pseudo Random Function PSK Pre-Shared Key RC5 Rivest Cipher 5 RFC Request For Comments RSA Rivest, Shamir & Adleman (public key encryption technology) RTP Real-time Transport Protocol RTT Round Trip Time SA Security Association SHA Secure Hash Algorithm SLP Service Location Protocol SP Service Provider SPI Security Parameter Index SSL Secure Socket Layer

17 INHOUDSOPGAVE viii SuSE Software- und System-Entwicklung TCP Transmission Control Protocol TLS Transport Layer Security UDP User Datagram Protocol VPN Virtual Private Network WAN Wide Area Network

18 PROBLEEMSITUERING 1 Hoofdstuk 1 Probleemsituering 1.1 Probleemschets Vele thuisgebruikers beschikken reeds over een thuisnetwerk. Ze kunnen dit gebruiken om onder andere bestanden en printers te delen en spelletjes te spelen. Indien dit netwerk aangesloten is op het internet, zou het interessant zijn indien ook toestellen op netwerken van andere gebruikers kunnen bereikt worden. Hierbij treden echter een paar problemen op. Een eerste probleem is veiligheid: niet iedereen mag toegang hebben tot hun netwerk en de communicatie mag niet afgeluisterd kunnen worden door derden. Verdere moeilijkheden kunnen optreden indien beide gateways gebruik maken van NAT, zodat het niet mogelijk is toestellen op het andere netwerk te bereiken zonder speciale voorzorgen. Ook het feit dat gateways dynamische IP-adressen kunnen hebben, kan voor bijkomende uitdagingen zorgen. Ten slotte is er nog de mogelijkheid dat twee netwerken overlappende subnetwerken gebruiken. De meeste thuisgebruikers hebben echter niet de technische kennis om deze problemen op te lossen. Een gelijkaardig probleem zien we bij bedrijven. Bedrijven kijken almaar meer over de geografische grenzen heen en eisen steeds meer flexibiliteit van hun werknemers. Verschillende filialen van eenzelfde bedrijf (nationaal of internationaal) moeten op een eenvoudige en betrouwbare manier bedrijfsinformatie kunnen delen. Verder kan het handig zijn dat een leverancier bepaalde, geselecteerde informatie kan opvragen die zich binnen het bedrijfsnetwerk bevindt. Vroeger werd dit meestal opgelost door gebruik te maken van zogenaamde leased lines, wat een hoge kost met zich meebracht. Werknemers zouden het bedrijfsnetwerk ook vanop een andere locatie moeten kunnen gebruiken. Dit kan onder andere gebruikt worden om aan thuiswerk te doen, maar ook kunnen

19 1.2 Doel van de thesis 2 rondreizende werknemers van zodra ze over een internetverbinding beschikken dezelfde bedrijfsinformatie raadplegen op de meest verscheidene locaties. Klanten kunnen hierdoor bijvoorbeeld sneller op de hoogte gebracht worden van de specificaties van de producten en/of diensten die men aanbiedt, wat een voorsprong ten opzichte van de concurrentie betekent. Eén van de vereisten die opgelegd worden door vele bedrijven voor een dergelijk systeem is de vertrouwelijkheid van de doorgestuurde informatie. Men wil niet dat belangrijke, innovatieve informatie in handen komt van de concurrentie. De oplossing voor dit probleem is een Virtual Private Network (VPN). Deze technologie stelt een gebruiker in staat een veilige verbinding te creëren over een onveilig netwerk. Er is een onderscheid tussen site-to-site VPN s, waarbij twee (of meer) netwerken op een veilige manier kunnen communiceren, en client-to-site VPN s, waarbij een enkele client logisch gezien deel wordt van een ander netwerk. Grote bedrijven zullen echter meestal gebruik maken van een hardware VPN-oplossing, omwille van de schaalbaarheid. Voor kleinere bedrijven is dit meestal een te dure optie maar ontbreekt tevens de technische kennis om een dergelijke oplossing op poten te zetten. Ook voor thuisgebruikers is dit geen optie. Naast de dure hardware-oplossingen zijn er ook veel software-oplossingen, maar deze vereisen (vooral voor site-to-site) te veel kennis. 1.2 Doel van de thesis Het doel van deze thesis is een VPN-oplossing te creëren, waarbij een absoluut minimum aan configuratie nodig is en waarbij geen technische kennis vereist is bij de gebruikers. Deze VPNoplossing moet in staat zijn twee netwerken te verbinden (site-to-site), zodat de communicatie tussen deze twee netwerken geauthenticeerd, confidentieel en integer is. Verder moet de VPNoplossing transparant zijn voor de gebruikers op beide netwerken: dit betekent dat er geen extra software moet geïnstalleerd worden op de machines van de gebruikers en dat bestaande verbindingen geen hinder ondervinden wanneer een verbinding opgezet wordt. De VPN-oplossing moet ook in staat zijn client-to-site verbindingen op te zetten; dit kan dan uiteraard niet zonder extra software te installeren op de client. Er zijn in grote lijnen twee soorten gebruikers: thuisgebruikers, die hun thuisnetwerken willen verbinden en kleine bedrijven die op zoek zijn naar een softwarematige, eenvoudig in te stellen VPN-oplossing. Voor thuisgebruikers is de makkelijke configureerbaarheid de belangrijkste vereiste, terwijl

20 1.3 Outline 3 veiligheid van de opgestelde verbinding van secundair belang is. Bedrijven echter zullen bereid zijn iets meer te moeten configureren als dit de nodige veiligheid met zich meebrengt. De oplossing moet werken op een intelligente gateway. Zulke gateways zijn vergelijkbaar met set-top boxes voor bijvoorbeeld interactieve digitale televisie, met het verschil dat de gateways generiek zijn en hun functionaliteit softwarematig aan te passen is. Ze kunnen ook van op afstand beheerd kan worden, bijvoorbeeld door de Internet Service Provider (ISP). Deze kan het systeem dan als een service aanbieden aan zijn klanten. 1.3 Outline Gebaseerd op de specificatie van het systeem aan de hand van use cases en scenariodiagrammen in hoofdstuk 2 wordt er in hoofdstuk 3 een architectuur voorgesteld. Vooraleer deze architectuur kan worden geïmplementeerd, moeten de benodigde technologieën onderzocht worden. In hoofdstuk 4 worden de belangrijkste VPN-technologieën besproken en vergeleken. Verder wordt ook het probleem van de adresseringsstrategie onderzocht en wordt OSGi besproken. Na het besluit over de te gebruiken technologieën wordt in hoofdstuk 5 de concrete implementatie van het systeem beschreven. Hoofdstuk 6 beschrijft de testopstelling die we gebruikt hebben om het uiteindelijk systeem te testen en geeft de gedane tests en hun resultaten weer. Tot slot volgt hoofdstuk 7 waar een algemeen besluit wordt geformuleerd. Tevens worden hierin mogelijke verdere uitbreidingen en onderzoeksdomeinen voorgesteld.

21 SPECIFICATIE 4 Hoofdstuk 2 Specificatie In sectie 2.1 wordt in grote lijnen uitgelegd wat het systeem waar deze thesis over handelt, als functionaliteit moet bevatten en aan welke kwaliteitsvereisten het moet voldoen. In sectie 2.2 wordt aan de hand van use cases duidelijk gemaakt wat er verwacht wordt. 2.1 Vereisten Verbinding De hoofdfunctionaliteit bestaat uit het opzetten, onderhouden en afsluiten van een verbinding tussen twee intelligente gateways. Gebruiksvriendelijkheid Dit dient op een dusdanige manier te gebeuren dat er zo weinig mogelijk technische kennis vereist is. Een computerleek moet in staat zijn een verbinding op te zetten en af te breken. Eventuele configuratie wordt afgewenteld op een netwerkbeheerder die verantwoordelijk is voor het thuisnetwerk of in het geval van bedrijven voor het netwerk van de vestiging. Veiligheid Bijkomende vereisten worden opgelegd voor het soort verbinding dat gemaakt wordt. Verkeer dat van het ene naar het andere netwerk wordt verstuurd mag niet kunnen gelezen of veranderd worden door derden. Ook moet ervoor gezorgd worden dat de andere gateway wordt geauthenticeerd vooraleer een verbinding wordt opgezet. Transparantie Het opzetten en sluiten van een verbinding moet transparant zijn voor de eindgebruiker (elke gebruiker in elk van de netwerken). Alle diensten die werkten voordat

22 2.2 Use cases 5 de verbinding werd opgezet, moeten blijven werken nadat deze is opgezet. verbindingen mogen niet onderbroken worden. Reeds gemaakte Makkelijke installatie Het systeem moet makkelijk installeerbaar zijn. Aanpasbaarheid en uitbreidbaarheid Het systeem moet erop voorzien zijn dat er zich veranderingen kunnen voordoen in de gebruikte technologie (het moet bijvoorbeeld mogelijk zijn met minimale inspanning te veranderen van gebruikte VPN-technologie). Verder moet het eenvoudig zijn om nieuwe features toe te voegen. 2.2 Use cases Figuur 2.1 toont welke soorten gebruikers er bestaan en welke acties zij mogen ondernemen. We kunnen een onderscheid maken tussen drie soorten actoren. De Service Administrator is diegene die de dienst aanbiedt. Deze is verantwoordelijk voor het aanbieden van de dienst aan de verschillende eindgebruikers. Hiervoor moet hij informatie over de verschillende gateways die gebruik maken van deze dienst bijhouden. Verder zijn er de eindgebruikers waarbij er onderscheid gemaakt wordt tussen een gewone eindgebruiker en de netwerkbeheerder. De netwerkbeheerder staat in voor de configuratie van de gateway terwijl de gewone gebruiker een verbinding moet kunnen opzetten, afsluiten en natuurlijk gebruiken. Figuur 2.2 toont hoe de netwerkbeheerder de lokale gateway kan instellen. De gateway kan eventueel informatie vragen aan de Service Provider. Figuur 2.3 laat zien hoe een gewone eindgebruiker de verbinding kan starten en stoppen. Bij het starten van een verbinding wordt, na authenticatie van de remote gateway, onderhandeld over de parameters die gaan worden gebruikt. Hierbij kan het nodig zijn om de Service Provider te gebruiken, bijvoorbeeld om bijkomende informatie nodig voor de verbinding op te vragen.

23 2.2 Use cases 6 Figuur 2.1: Use Case Diagram Figuur 2.2: Use Case: Configureren gateway door netwerkbeheerder

24 2.2 Use cases 7 Figuur 2.3: Use Case: Starten en stoppen verbinding tussen gateways

25 ARCHITECTUUR 8 Hoofdstuk 3 Architectuur Figuur 3.1: Module view 3.1 Module view Figuur 3.1 toont alle modules van het systeem en hoe ze zich onderling verhouden. De module ConfigurationManager wordt door elke module die configuratie wil opslaan, gebruikt. De modules worden elk apart besproken in de volgende secties.

26 3.1 Module view Negotiator Bij het opstellen van een verbinding tussen twee gateways zijn er verschillende zaken die veranderlijk zijn. Denk maar aan de mogelijkheden die beide gateways aanbieden, de gebruikte fysieke en te gebruiken virtuele IP-ranges. Natuurlijk is het onbegonnen werk om voor elke verbinding handmatig te moeten aangeven welke waarden de te gebruiken parameters aannemen. Hier vloeit de Negotiator uit voort. Alle modules in het systeem hebben de mogelijkheid om parameters die ze in de onderhandeling tussen de twee gateways willen betrekken, te registreren. Bij de onderhandeling van een verbinding worden de modules die zich geregistreerd hebben, geraadpleegd voor het nemen van een beslissing over hun respectievelijke parameters. Deze manier van werken heeft een aantal voordelen. Zo wordt de logica van de feitelijke onderhandeling en de specifieke problemen die men kan tegenkomen bij de onderhandeling van bepaalde parameters gescheiden. Het toevoegen van een extra parameter wordt dan slechts een kwestie van het registreren ervan bij de Negotiator, aan de Negotiator zelf dient niets veranderd te worden. In feite weerhoudt niets iemand ervan om deze Negotiator te gebruiken voor een totaal ander systeem waar een dergelijke onderhandeling bij te pas komt ConfigurationManager De ConfigurationManager houdt twee verschillende soorten informatie bij, enerzijds wordt informatie bijgehouden die gelijk is voor het gehele systeem, zoals de lijst van vertrouwde gateways. Anderszijds wordt per verbinding de informatie die onderhandeld werd door de Negotiator opgeslagen. Dit heeft als voordeel dat een module die bepaalde informatie nodig heeft om in zijn functionaliteit te voorzien niet op de hoogte moet zijn welke module hiervoor verantwoordelijk is. Informatie specifiek aan een module die niet gebruikt wordt door andere modules op het systeem hoort niet thuis in de ConfigurationManager, maar dient door die specifieke module bijgehouden worden AddressTranslation De module AddressTranslation bevat alle functionaliteit om te beslissen of adresvertaling nodig is voor een bepaalde verbinding en om deze adresvertaling in te stellen op de gateway. De module wordt geregistreerd bij de Negotiator, die de feitelijke onderhandeling afhandelt, terwijl de module AddressTranslation de beslissingen neemt over het al dan niet gebruiken van adresvertaling en de eventuele parameters van de adresvertaling.

27 3.1 Module view Policing De module Policing staat in voor de authorisatie van gebruikers binnen het virtuele netwerk VPNInterface De module VPNInterface staat in voor het opstarten en controleren van een VPN-verbinding. Een andere verantwoordelijkheid is het instellen van de routering naar het netwerk waarnaar de VPN-verbinding is ingesteld. Deze functionaliteit is ondergebracht in een aparte module, zodat het eenvoudig is om van onderliggende VPN-technologie te veranderen: enkel deze module moet in dat geval aangepast worden AutoVPNInterface Het opzetten en afbreken van een verbinding heeft verschillende gevolgen: er moeten een aantal interne objecten aangemaakt of verwijderd worden, de adresvertaling moet opgezet of afgebroken worden en de onderliggende VPN-oplossing moet logischerwijze aangesproken worden. Om ervoor te zorgen dat de gateway zich niet in een inconsistente staat bevindt (bijvoorbeeld: de VPN-verbinding is afgesloten maar de bijbehorende adresvertaling is niet ongedaan gemaakt), worden alle acties die nodig zijn om een verbinding op te zetten of af te breken in deze module gebundeld WebInterface De enige module waarmee de eindgebruiker rechtstreeks in contact komt is de webinterface die aangeboden wordt door het systeem. Er wordt een onderscheid gemaakt tussen verschillende soorten gebruikers. Enerzijds zijn er de eindgebruikers die enkel gemachtigd zijn verbindingen aan te maken, af te sluiten en te gebruiken. Anderszijds zijn er de netwerkbeheerders die bovenop de acties die een eindgebruiker mag ondernemen, meer geavanceerde acties mag uitvoeren. Meer specifiek: de netwerkbeheerder kan de lokale configuratie van het systeem wijzigen. Dit kan bijvoorbeeld het aanpassen van een lijst van vertrouwde gateways of een lijst van gebruikers die toegang tot het netwerk krijgen, zijn GNS De module GNS staat in voor het registreren van afbeeldingen van namen op IP-adressen bij de GNS-server. Elke communicatie met de GNS-server is beveiligd (geauthenticeerd en

28 3.2 Deployment view 11 geëncrypteerd) GNSserver De module GNSserver bevindt zich op een server die beheerd wordt door de Service Provider. Hij houdt de afbeeldingen van namen op IP-adressen bij, die hij ontvangt van de GNS en verschaft een lookup-service voor deze namen. Zoals vermeld in sectie is de communicatie tussen gateway en GNS-server beveiligd. Twee soorten relaties worden bijgehouden: enerzijds zijn er de relaties (gatewaynaam, IPadres gateway), anderzijds zijn er de relaties (clientnaam, virtueel IP-adres client). 3.2 Deployment view Figuur 3.2 toont waar elke module zich fysiek bevindt. Enkel de modules die instaan voor de communicatie tussen verschillende nodes zijn in de figuur opgenomen, zo zullen op beide gateways behalve de modules op de figuur ook volgende modules aanwezig zijn: Configuration- Manager, AddressTranslation, Policing en AutoVPNInterface. Figuur 3.2: Deployment view

29 3.2 Deployment view Client De eindgebruiker heeft enkel een standaardbrowser nodig om gebruik te kunnen maken van het systeem Gateways De eindgebruiker surft naar de webinterface van zijn lokale gateway om het systeem te besturen. Op aanvraag van de gebruiker zal het systeem in actie treden. Hierbij komt de module GNS in werking en communiceert hierbij met de module GNSServer die zich bevindt in het serverpark van de Service Provider (SP). Communicatie tussen de lokale gateway en de gateway waarmee verbinding wordt gemaakt gebeurt tussen de modules Negotiator en VPNInterface op beide gateways Serverpark Service Provider De Service Provider biedt de module GNSServer aan.

30 TECHNOLOGIESTUDIE 13 Hoofdstuk 4 Technologiestudie 4.1 OSGi Motivatie Als platform voor de intelligente gateway waarop het systeem moet werken, werd gekozen voor het OSGi-platform. Dit platform is uitstekend geschikt voor residential Internet gateways en is reeds aanwezig op een aantal commerciële gateways. Hierna wordt het OSGi-platform in meer detail besproken, waarbij de punten die het geschikt maken, worden aangestipt Overzicht Het OSGi Service Platform is een specificatie voor een Java-gebaseerd applicatieframework voor genetwerkte devices. Het was oorspronkelijk ontworpen voor gebruik in residential Internet gateways met het oog op huisautomatie. Het wordt nu echter ook voor veel andere doeleinden gebruikt, waaronder telematica, smart phones en embedded toestellen. In deze thesis ligt de focus uiteraard op het originele aspect van residential Internet gateways. OSGi specifieert een framework voor softwarecomponenten, die men bundles noemt. Het formaat van deze componenten is vastgelegd en er is een API voor de deployment van de componenten, zodat de lifecycle ervan gecontroleerd kan worden. Dit maakt OSGi uitermate geschikt om aan remote deployment en remote management te doen. Componenten kunnen eenvoudig geïnstalleerd, verwijderd en geüpdatet worden. Het systeem is service-georiënteerd: componenten kunnen dynamisch elkaars services ontdekken en gebruiken.

31 4.1 OSGi Architectuur Figuur 4.1: OSGi architectuur De OSGi-specificaties beschrijven een aantal lagen, zoals voorgesteld in figuur 4.1. De lagen in het geel vormen samen het OSGi-framework. JVM Het OSGi-framework draait op een Java Virtuele Machine (JVM). Er werd gekozen voor JVM omdat het een open standaard is die beschikt over de nodige features zoals portabiliteit, veiligheid en betrouwbaarheid. Class loading Het uitvoerbare deel van bundles zijn Java klassen, georganiseerd in packages. In tegenstelling tot andere frameworks zoals J2EE, kunnen deze klassen gedeeld worden tussen bundles. Dit maakt de implementatie complexer, maar heeft als voordeel dat bundles libraries kunnen bevatten voor andere bundles, zodat de memory footprint kleiner kan gehouden worden. De afhankelijkheid die op deze manier tussen bundles ontstaat, wordt op de volgende manier opgelost: elke bundle specifieert welke packages hij exporteert en welke hij importeert (zie figuur 4.2). Exporteren van een package betekent dat alle andere bundles gebruik kunnen maken van deze package. Bundles kunnen slechts gestart worden indien alle packages die ze importeren aanwezig zijn in het framework. Life cycle management Een bundle is een Java Archive (JAR). OSGi specifieert een aantal headers die aanwezig moeten zijn in het Manifest-bestand van de JAR, waaronder de geïmporteerde en geëxporteerde

32 4.1 OSGi 15 Figuur 4.2: Gedeelde klassen packages. Nadat bundles geïnstalleerd zijn, kunnen ze gestart en gestopt worden. Het installeren van bundles kan gebeuren vanuit een andere bundle. De initiële bundles kunnen dan geïnstalleerd worden dankzij een Initial Provisioning specificatie, of via commandolijn parameters wanneer het framework opgestart wordt. Vooraleer een geïnstalleerde bundle gestart kan worden, moet hij eerst geresolved worden. Hierbij wordt gekeken of alle afhankelijkheden van de bundle (bijvoorbeeld geïmporteerde packages) voldaan zijn. Om een bundle te starten, wordt gekeken naar de Bundle-Activator header in de Manifest van de bundle. Deze bevat de naam van een klasse die de BundleActivator-interface moet implementeren. Deze klasse implementeert start- en stop-methodes. Een bundle hoeft niet noodzakelijk een Bundle-Activator te bevatten: in dat geval kan de bundle niet gestart of gestopt worden en dient hij enkel om geïmporteerd te worden door andere bundles. Bundles kunnen op elk moment verwijderd worden. De packages die de bundle exporteert, blijven dan wel beschikbaar voor bundles die ervan gebruik maken. Over het algemeen is het zo dat de packages waarvan een bundle afhankelijk is nooit gewijzigd worden als een bundle actief is. Als het nodig is, zal de bundle eerst gestopt worden en daarna opnieuw opgestart. Service Registry Het OSGi-platform is van nature zeer dynamisch: bundles kunnen op elk moment gestopt en gestart worden. De Service Registry is er om bundles te kunnen laten samenwerken in deze dynamische omgeving. Hiermee kunnen bundles:

33 4.2 VPN-technologieën 16 objecten registreren bij de Service Registry; deze objecten worden services genoemd. Services worden geregistreerd met een interfacenaam en een aantal properties. de Service Registry doorzoeken naar services op basis van bepaalde criteria. notificaties ontvangen wanneer een bepaalde service verschijnt of verdwijnt. Veiligheid Veiligheid is een belangrijk probleem voor een platform dat in staat moet zijn applicaties uit te voeren van vele verschillende bronnen. Er zijn dan ook verschillende veiligheidsmechanismen ingebouwd in OSGi. Eerst is er de Java 2 Code Security. Deze is ingebouwd in de JVM en laat toe bepaalde resources te beschermen door middel van Permissions. Bestanden kunnen bijvoorbeeld beschermd worden met FilePermissions. Verder kunnen in Java ook access modifiers gebruikt worden in de code om toegang tot klassen of methodes af te schermen. OSGi voegt hier nog bescherming van packages aan toe: packages van een bundle die niet geëxporteerd worden, kunnen niet bereikt worden door andere bundles. Er kunnen ook Package Permissions ingesteld worden: hiermee kan de import en export van bepaalde packages beperkt worden tot een set van vertrouwde bundles. Tot slot is er de Service Permission, waarmee er kan voor gezorgd worden dat enkel de gewenste bundles bepaalde services kunnen aanbieden of gebruiken. 4.2 VPN-technologieën Vereisten De vereisten voor de VPN-technologie voor deze thesis zijn de volgende. Vertrouwelijkheid, authenticatie en integriteit moeten ondersteund worden. Er moet een implementatie zijn die aanspreekbaar is vanuit Java, aangezien de oplossing moet draaien op een OSGi-gateway. Er moet een implementatie zijn die installeerbaar is op een OSGi-gateway. Dit houdt in

34 4.2 VPN-technologieën 17 dat deze implementatie in userspace 1 uitgevoerd zou moeten worden. Er moet een implementatie beschikbaar zijn voor zoveel mogelijk platformen. De oplossing moet werken samen met NAT, aangezien veel thuisnetwerken achter een gateway zitten die NAT uitvoert. Het moet mogelijk zijn policies in te stellen om aan toegangscontrole te doen (dit is vooral interessant voor bedrijven) IPSec Overzicht IPSec is een uitbreiding van het IP-protocol om veiligheid aan te bieden voor IP-verkeer. Het was oorspronkelijk ontworpen voor de nieuwe IPv6 standaard en later aangepast om ook met IPv4 te werken. De IPSec-architectuur is gestandaardiseerd in RFC 4301 [3]. IPSec gebruikt twee protocollen (AH en ESP) om authenticatie, integriteit en vertrouwelijkheid van communicatie te verzekeren. Verder zijn er ook nog twee mogelijke modi: tunnelmode of transportmode. Bij tunnelmode wordt elk IP-pakket volledig geëncrypteerd en/of geauthenticeerd en geëncapsuleerd in een nieuw IP pakket. Bij transportmode wordt enkel de IP-data geëncrypteerd en/of geauthenticeerd en worden nieuwe headers toegevoegd aan het IP pakket; de oorspronkelijke headers van het IP-pakket blijven ongewijzigd. Dit wordt grafisch voorgesteld in figuur 4.3. Figuur 4.3: Het verschil tussen tunnel- en transportmode Integriteit van de communicatie wordt verzekerd door het gebruik van Hash Message Authentication Codes (HMAC). De HMAC van een pakket wordt berekend door de hash te berekenen 1 Userspace slaat op code die uitgevoerd wordt als een gewoon proces; kernelspace slaat op code die uitgevoerd wordt in de kernel, bijvoorbeeld als driver of module.

35 4.2 VPN-technologieën 18 van een geheime sleutel geconcateneerd met de inhoud van het pakket. Voor de hash kan men gebruik maken van MD5 of SHA. Indien de ontvanger ook over de geheime sleutel beschikt, kan hij ook deze hash berekenen en controleren of het bericht gewijzigd is tijdens het transport. Vertrouwelijkheid wordt verzekerd door symmetrische encryptie. De IPSec standaard schrijft voor dat NULL en DES encryptie verplicht aanwezig moeten zijn, maar over het algemeen worden krachtigere algoritmes gebruikt. Een beveiligde verbinding wordt een Security Association (SA) genoemd. gedefinieerd door een set van parameters: Een SA wordt bron- en bestemming-ip-adres van de resulterende IPSec header. woorden de peers van de IPSec verbinding. Dit zijn met andere IPSec protocol: opgezet worden) AH of ESP (indien beide samen gebruikt worden, moeten twee SA s algoritme en geheime sleutel voor encryptie Security Parameter Index (SPI). Een 32-bit getal dat de SA identificeert. Een SA is geldig voor een unidirectionele verbinding. Voor een full duplex verbinding zijn dus twee SA s nodig. Deze SA s kunnen manueel worden ingesteld. De gebruikers moeten dan zelf op een of andere manier een (statische) geheime sleutel kiezen. Dit noemt men vaak een pre-shared key (PSK). Maar er kan ook gebruik gemaakt worden van het Internet Key Exchange-protocol (IKE), dat een sleutel voorziet voor de SA. Dit protocol wordt beschreven in sectie Werking AH Authentication Header Het AH protocol zorgt voor integriteit van IP-pakketten. De header (die een veelvoud van 32 bits lang is) wordt grafisch weergegeven in figuur 4.4. HMAC: een HMAC van de geheime sleutel, de data van het IP-pakket en de onveranderlijke delen van de IP-header (zoals bron- en bestemmingsadres). Moet een veelvoud van 32 bits lang zijn. Next Header: specifieert het protocol van de volgende header. In tunnelmode is dit 4, voor IP; in transportmode met TCP-verkeer is dit 6, voor TCP.

36 4.2 VPN-technologieën 19 Figuur 4.4: Een authenticated header SPI: de SPI van de security association, zodat de ontvanger weet welke sleutel en algoritme hij moet gebruiken. Sequence Number: dit 32-bit getal wordt mee opgenomen in de hash om replay attacks te voorkomen. ESP Encapsulating Security Payload Het ESP protocol zorgt voor vertrouwelijkheid en (optioneel voor) integriteit. De structuur van een met ESP geëncapsuleerd pakket wordt grafisch weergegeven in figuur 4.5. Figuur 4.5: Een ESP header

37 4.2 VPN-technologieën 20 SPI: zoals bij AH. Sequence Number: zoals bij AH. Data: geëncrypteerde data. In transportmode is dit de data in het IP-pakket; in tunnelmode is dit het volledige IP-pakket. Indien het encryptie-algoritme dit vereist, kan dit veld ook een initialisatievector (IV) bevatten. Padding Length: Aangezien IPSec block ciphers gebruikt, is het nodig om padding te voorzien indien de lengte van de data niet een veelvoud van de blokgrootte is. Next Header: zoals bij AH. HMAC (optioneel): een HMAC over de ESP header, data en trailer. IKE Internet Key Exchange Het IKE-protocol is ontworpen om het veilig opzetten van een IPSec verbinding mogelijk te maken, zonder met pre-shared keys te werken: het zorgt voor authenticatie van de peers, sleuteluitwisseling en opzetten van de SA s. Het IKE-protocol wordt over het algemeen geïmplementeerd door een userspace programma en gebruikt UDP poort 500 voor de communicatie. Het protocol werkt in twee fasen. In de eerste fase worden de peers geauthenticeerd en wordt een Internet Security Association Key Management Protocol (ISAKMP) SA vastgelegd. De authenticatie kan gebeuren aan de hand van PSK s, RSA sleutels en X.509-certificaten. In de tweede fase worden de parameters van de SA s voor IPSec onderhandeld. Deze communicatie wordt beschermd met de ISAKMP SA. Normaal onderhandelen de twee peers slechts één ISAKMP SA; deze kan dan gebruikt worden om twee (of meer) unidirectionele IPSec SA s te onderhandelen. NAT-Traversal Standaard IPSec kan in transportmode niet gebruikt worden in combinatie met Network Address Translation (NAT). Verschillende problemen duiken op: AH kan niet gebruikt worden aangezien het bronadres van de verzonden IP-pakketten (die worden herschreven door NAT) deel uitmaakt van de HMAC. De HMAC is na NAT dus niet meer geldig. ESP kan ook niet gebruikt worden, omdat NAT een poortnummer van het onderliggende protocol (TCP of UDP) gebruikt om onderscheid te maken tussen verschillende verbin-

38 4.2 VPN-technologieën 21 dingen. Aangezien ESP deze poortnummers encrypteert, kan een NAT-router onmogelijk onderscheid maken tussen verschillende verbindingen die ESP gebruiken. Ook in tunnelmode kunnen er problemen optreden, aangezien het geëncapsuleerde IP-adres niet vertaald wordt. Verdere problemen worden beschreven in [1]. Een mogelijke oplossing voor ESP is om de ESP-pakketten te encapsuleren in UDP-pakketten. Hierdoor beschikt de NAT-router toch weer over een poortnummer en zal hij nu wel onderscheid kunnen maken tussen verschillende verbindingen. NAT-traversal wordt beschreven in [2] OpenVPN Overzicht OpenVPN is een relatief nieuwe VPN-oplossing, gebaseerd op SSL/TLS. Het ontstond als reactie op de complexiteit en steile leercurve van typische IPSec-oplossingen. In tegenstelling tot IPSec, waarin IKE wordt gebruikt om sleutels uit te wisselen, gebruikt men in OpenVPN SSL/TLS. Dit protocol was in eerste instantie ontworpen voor de applicatielaag, maar kan ook gebruikt worden voor andere doeleinden. De voordelen tegenover IKE zijn dat het protocol eenvoudiger is (waardoor te verwachten is dat er minder fouten optreden bij implementatie) en dat het zijn deugdelijkheid al ruim bewezen heeft dankzij het gebruik in het HTTPS-protocol. Verder is het hierdoor mogelijk OpenVPN volledig in userspace te implementeren, zodat porteren veel vereenvoudigd wordt (er zijn geen aanpassingen of uitbreidingen van de IP-stack nodig). Voor alle duidelijkheid: OpenVPN is een echte VPN, waarbij willekeurig IP-verkeer kan beveiligd worden. Er bestaan namelijk ook vele zogenaamde SSL-VPN s, die in feite niets meer zijn dan een webinterface naar een bepaalde applicatie, over HTTPS. Aangezien er geen RFC of andere standaard bestaat voor het protocol dat gebruikt wordt door OpenVPN, beschrijven we hier de implementatie zelf. Werking SSL/TLS SSL is een protocol dat als doel heeft privacy en data-integriteit te verlenen tussen twee communicerende applicaties (oorspronkelijk client en server). Het protocol werd ontwikkeld door Netscape en SSL versie 3 is (met enige wijzigingen) hernoemd naar TLS en vastgelegd in RFC 2246 [5].

39 4.2 VPN-technologieën 22 Authenticatie in SSL/TLS gebeurt aan de hand van X.509-certificaten. In de meeste gevallen wordt enkel de server geauthenticeerd, maar de server kan ook een certificaat eisen van de client, zodat beide partijen geauthenticeerd kunnen worden. SSL/TLS moet gedragen worden door een betrouwbaar transport protocol. Dit is meestal TCP (bijvoorbeeld bij HTTPS). OpenVPN protocol OpenVPN heeft twee authenticatie-modi: Static Key: maakt gebruik van een pre-shared static key. TLS: maakt gebruik van SSL/TLS en certificaten voor authenticatie en key exchange. In static key mode wordt op voorhand een pre-shared sleutel gegenereerd en gebruikt door beide OpenVPN peers, voor de tunnel gestart wordt. Deze sleutel bevat 4 onafhankelijke sleutels: HMAC send, HMAC receive, encrypt en decrypt. Standaard worden deze sleutels door beide partijen gebruikt. In TLS mode wordt een TLS-sessie opgestart met bidirectionele authenticatie. Beide partijen moeten hierbij een certificaat hebben, ondertekend door een Certificate Authority (CA). Als de authenticatie slaagt, worden encryptie/decryptie en HMAC sleutels gegenereerd, waarbij beide partijen random materiaal leveren. In deze mode worden de sleutels niet bidirectioneel gebruikt; elke partij bezit dus een eigen HMAC send, HMAC receive, encrypt en decrypt -sleutel. Zodra elke partij zijn sleutels heeft, kan de tunnelwerking beginnen. Headerformaat De communicatie tussen client en server verloopt via UDP. De server ontvangt standaard verbindingen op poort 1194 (deze poort is toegewezen voor OpenVPN-communicatie door IANA, zie [12]). De pakketten zien eruit als volgt: packet message type payload key id Packet message type: (5 bit) specifieert of het gaat om een controle-, ack-, of databoodschap. Key-id: (3 bit) de key-id verwijst naar een reeds onderhandelde TLS-sessie.

40 4.2 VPN-technologieën 23 Payload: kan bestaan uit een controle-, ack- of data-boodschap. Data-boodschappen bevatten de IP-pakketten die over de tunnel gestuurd worden, nadat ze geëncrypteerd en geauthenticeerd zijn; controle- en ack-boodschappen bevatten TLS-data. Indien OpenVPN in static key mode opereert, worden enkel data-boodschappen verstuurd; de velden package message type en key-id worden in dat geval ook weggelaten. Indien OpenVPN in TLS-mode opereert, moet ook een TLS-verbinding opgezet worden. De payload hiervan wordt gedragen door controle-boodschappen. Bovendien vereist het TLSprotocol een betrouwbare verbinding; daarom wordt ook een betrouwbaarheidslaag toegevoegd (door gebruik te maken van ack-boodschappen). gemultiplext (zie figuur 4.6). Er worden in dit geval dus twee stromen Figuur 4.6: Multiplexen van IP-pakketten bestemd voor de tunnel, met TLS-data. Controle-boodschappen In deze boodschappen wordt de TLS-data geëncapsuleerd. Aangezien TLS een betrouwbaar protocol verwacht (en UDP niet betrouwbaar is), is het nodig een reliability layer toe te voegen. Dit is geïmplementeerd als een simpel ack-retransmit-protocol. De controle-boodschappen zien er als volgt uit: local session id (8 bytes): identificeert de TLS-sessie. De key-id die hierboven gespecifieerd werd, is een verkorte versie van deze session id, omwille van efficiëntieredenen. HMAC van encapsulatieheader voor integriteitscheck: (indien deze optie werd gespecifieerd door de gebruiker (16 of 20 bytes)) deze optie werd ingevoerd om DoS-aanvallen te weren. Enkel clients die over de (statische) HMAC encrypt-sleutel beschikken kunnen zodoende een TLS-sessie starten met de server. packet-id (4 bytes): zorgt voor bescherming tegen replay-aanvallen

41 4.2 VPN-technologieën 24 ACK packet id array length (1 byte); indien aankomst van andere pakketten wordt bevestigd. ACK packet-id array: (als length > 0) ACK remote session id: (als length > 0) message packet-id (4 bytes) TLS payload ciphertext (n bytes): de eigenlijke TLS-data. Eens de TLS-sessie is opgezet wordt hierover informatie uitgewisseld om sleutels te onderhandelen: key method type; bij type1 levert de server alle sleutels, bij type2 leveren beide partijen random materiaal om een sleutel te genereren, door gebruik te maken van de TLS PRF mixing functie. key source structure; informatie om sleutels te generen options string length options string: in deze string kunnen opties gespecifieerd worden (onder meer een gebruikersnaam en wachtwoord om aan authenticatie op basis van gebruikersnaam/wachtwoordparen te doen, bovenop het certificaat) ACK-boodschappen maar bevatten enkel acknowledgements. Deze boodschappen zijn gelijkaardig aan de controle-boodschappen, Data-boodschappen Deze boodschappen encapsuleren de eigenlijke verstuurde data die kan bestaan uit IP-pakketten of ethernetpakketten. De data-boodschappen bestaan uit: HMAC van de cijfertekst IV + cijfertekst (16 of 20 bytes, afhankelijk van het gekozen algoritme) cijfertekst IV (lengte afhankelijk van gekozen algoritme) cijfertekst

42 4.2 VPN-technologieën 25 De plaintext van de data-boodschappen bevat ten slotte een packet id (4 bytes) en de plaintext zelf (IP-pakket of ethernetpakket). De data-boodschappen bevatten geen reliability layer. Dit komt omdat de geëncapsuleerde protocollen (IP of ethernet) dit ook niet eisen. De betrouwbaarheid kan dan door een hoger niveau (bijvoorbeeld TCP) afgehandeld worden. Eigenschappen Userspace OpenVPN maakt gebruik van de tun- of de tapdriver. Dit is een virtuele netwerkinterface. De gebruiker kan deze gebruiken als een echte, fysische netwerkinterface, maar de pakketten die ernaar verstuurd worden, worden doorgestuurd naar de OpenVPN-applicatie. Hierdoor kan OpenVPN volledig in userspace werken en is het programma veel gemakkelijker te porteren dan oplossingen waarbij de IP-stack in kernelspace wordt uitgebreid. Er zijn dan ook versies beschikbaar voor de meeste courante besturingssystemen (Windows, Linux, Solaris, Mac OSX, *BSD). De tun- en tapdriver is standaard aanwezig in recente Linux-kernels, FreeBSDkernels, OpenBSD-kernels, en kan geïnstalleerd worden met een commandline-tool in windows (mits beheerdersrechten). Management interface OpenVPN beschikt over een management interface. Vanaf de lokale computer kan een TCP-connectie gemaakt worden met OpenVPN. Over deze connectie kunnen dan commando s gestuurd worden om de status op te vragen, wachtwoorden toe te voegen, PPTP, L2TP Zowel Point-to-Point Tunneling Protocol (PPTP) als Layer 2 Tunneling Protocol (L2TP) maken onderliggend gebruik van Point-to-Point Protocol (PPP). Voor een volledige bespreking moet dus eerst PPP bekeken worden. PPP Het Internet Protocol (IP) zorgt ervoor dat een pakket van variabele lengte zijn weg kan vinden van bron naar bestemming, maar om dit tot een goed einde te brengen, worden er enkele diensten verwacht van de onderliggende laag. De netwerklaag gebruikt de diensten van de onderliggende datalinklaag (zie figuur 4.7). De belangrijkste verantwoordelijkheden van de datalinklaag zijn het encapsuleren van data die het krijgt van de netwerklaag voor transmissie, het verbeteren van

43 4.2 VPN-technologieën 26 Figuur 4.7: Gelaagd OSI-model fouten en het effectief verzenden van de geëncapsuleerde data over de fysieke link. De eerste twee zorgen voor de interface tussen datalinklaag en netwerklaag, de laatste voor de interface tussen datalinklaag en fysieke laag. In IEEE802, een familie IEEE-standaarden over LANs, heten deze respectievelijk Logical Link Control (LLC) en Media Access Control (MAC). Mensen die ooit een thuisnetwerk opgezet of onderhouden hebben, zijn zeker bekend met de term Ethernet (IEEE802.3). Dit is dan ook één van de meest bekende protocollen die bovenstaand probleem aanpakt (zij het enkel het MAC-gedeelte, het LLC-gedeelte is voor LANs gestandaardiseerd onder de naam IEEE802.2). Wanneer er echter enkel een fysieke verbinding is zonder datalinklaag, kunnen er zonder verdere tussenkomst geen netwerkpakketten verstuurd worden. Twee voorbeelden hiervan en de bijhorende oplossingen worden hierna besproken. Serial Line Internet Protocol Een simpel voorbeeld van een situatie waar enkel een fysieke verbinding aanwezig is, komt men tegen wanneer twee computers rechtstreeks met elkaar worden verbonden door een seriële kabel. Het Serial Line Internet Protocol (SLIP) wordt hierbij gebruikt om de brug te vormen tussen de fysieke laag en de netwerklaag. SLIP zorgt er enkel voor dat IPpakketten worden verpakt voor transmissie en stuurt ze door naar de fysieke laag. Dit protocol is dan ook nooit formeel gestandaardiseerd, maar is een de facto-standaard voor het verzenden van IP-pakketten over een seriële verbinding. In [7] wordt de werking besproken, maar vooral

44 4.2 VPN-technologieën 27 de tekortkomingen komen ter sprake. Tekortkomingen SLIP De modem die een thuisgebruiker gebruikt om over internettoegang te beschikken, maakt in sommige gevallen enkel een fysieke verbinding met de ISP. Hoewel SLIP in principe in dit geval ook kan gebruikt worden, wordt dit doorgaans niet gedaan wegens de tekortkomingen besproken in [7]. Zo is het niet mogelijk om een ander protocol dan IP te versturen over SLIP en gebeurt er foutdetectie noch foutcorrectie. Er wordt geen compressie ondersteund, maar het belangrijkste nadeel is dat de twee machines in een SLIP-verbinding elkaars IP-adres vooraf moeten kennen omdat SLIP geen manier heeft om adresinformatie uit te wisselen. Point-to-Point Protocol Om aan deze tekortkomingen het hoofd te bieden, werd het Pointto-Point Protocol (PPP) ontwikkeld. PPP - niet zozeer een protocol, maar wel een verzameling van protocollen - biedt bovenop het encapsuleren van data van de netwerklaag verschillende diensten aan. PPP biedt niet alleen foutdetectie en compressie, maar ook authenticatie en encryptie aan, twee dingen die interessant zijn voor VPN-oplossingen. De werking van PPP kan onderverdeeld worden in drie secties die elk hun specifiek doel hebben. Net als SLIP moet PPP data komende van de netwerklaag verpakken voor transmissie, maar omdat meer geavanceerde diensten worden aangeboden zal dit complexer zijn dan de simpele encapsulatie van SLIP (de encapsulatie bestaat hier uit het simpelweg aanduiden van het einde van een pakket). 1. De interface naar de fysieke laag wordt verzorgd door het Link Control Protocol (LCP). 2. Een verzameling van protocollen, genaamd Network Control Protocol s, verzorgt de interface naar de netwerklaag. Voor elk netwerkprotocol dat PPP kan vervoeren, wordt een protocol gespecifieerd. 3. Bovenop de standaardcomponenten van PPP, die instaan voor het basisonderhoud van de fysieke verbinding en de netwerkverbindingen, worden er twee additionele groepen protocollen gedefinieerd. Deze staan in voor het ondersteunen van de basisprotocols (LCP Support Protocols) of het aanbieden van extra diensten over de opgezette verbinding (LCP Optional Feature Protocols).

45 4.2 VPN-technologieën 28 PPP: Encapsulatie De structuur van een PPP-frame is gebaseerd op het ISO High-Level Data Link Control (HDLC), oorspronkelijk ontwikkeld door IBM (zie [8]). Figuur 4.8: PPP-frame Flag: Een sequentie van één byte ( ) die het begin of het einde van een frame aanduidt. Address: De binaire sequentie , het standaardbroadcastadres. Een HDLC-frame kan een adres bevatten, maar PPP kent geen afzonderlijke adressen toe aan beide kanten van de verbinding. Control: De binaire sequentie HDLC biedt verschillende modes aan, PPP echter ondersteunt slechts één van deze modes, namelijk een best-effort service. Protocol: twee bytes die het geëncapsuleerde protocol aanduiden. Zie [9, 10, 11] voor de mogelijke waarden. Data: Geëncapsuleerde data. FCS: Frame Check Sequence, gebruikt voor foutdetectie. De velden Protocol en FCS zorgen al voor twee extra services ten opzichte van SLIP: respectievelijk de mogelijkheid van encapsulatie van meerdere protocollen en foutdetectie. PPP: Link Control Protocol Voor elke fysieke link kan maximum één LCP-link opgezet worden. Figuur 4.9 toont de mogelijke overgangen die een PPP-verbinding kan maken. Een PPP-verbinding begint en eindigt altijd in de Link Dead-fase, waar er geen fysieke verbinding is tussen beide eindpunten van de link. Van zodra er een fysieke verbinding wordt opgezet, start de onderhandeling over de LCP-configuratie. Indien dit niet lukt, blijft de verbinding in de Link Dead-fase. Na de succesvolle onderhandeling kan de authenticatie van start gaan, indien dit niet lukt wordt de LCP-verbinding afgebroken. Bij succesvolle authenticatie is er een volwaardige LCPverbinding.

46 4.2 VPN-technologieën 29 Figuur 4.9: Fase-overgangen bij het opzetten van een PPP-verbinding Een LCP-verbinding wordt pas gesloten als de fysieke verbinding het begeeft of als één van beide uiteinden van de verbinding vraagt om de verbinding te sluiten. Het is dus niet zo dat als alle verbindingen die geopend waren over de LCP-verbinding (zoals NCP-verbindingen en verbindingen die aanvullende protocollen maken) gesloten zijn, automatisch de LCP-verbinding wordt verbroken. PPP: Network Control Protocols Op dit moment is er wel een actieve LCP-verbinding, maar er kan nog geen verkeer over gestuurd worden omdat hiervoor een NCP-verbinding moet opgezet worden voor het bijbehorende protocol. Elk netwerkprotocol dat men over PPP kan versturen heeft een eigen NCP-protocol. Voor IP bijvoorbeeld is dit het Internet Protocol Control Protocol (IPCP), voor IPX bestaat het Internetworking Packet Exchange Control Protocol

47 4.2 VPN-technologieën 30 (IPXCP). Vooraleer een NCP-verbinding opgezet kan worden, moet men beschikken over een volledig geconfigureerde LCP-verbinding. Lukt de onderhandeling voor een bepaalde NCP-verbinding, dan bevindt de PPP-verbinding zich in de Link Open-fase en kan de verbinding gebruikt worden. Er kunnen over één LCP-verbinding meerdere NCP-verbindingen gestart worden om meerdere netwerkprotocollen door te sturen over dezelfde fysieke verbinding. PPP: LCP Support Protocols Tijdens de onderhandeling van de LCP-verbinding kunnen er bijkomende protocollen gebruikt worden. Voor het probleem dat we hier bespreken zijn vooral de protocollen die authenticatie bijvoegen interessant. Bekende voorbeelden zijn het Password Authentication Protocol (PAP: zie [13]) en het Challenge Handshake Authentication Protocol (CHAP: zie [14]). PPP: LCP Optional Feature Protocols Nadat er een PPP-verbinding is opgezet zorgen deze protocollen ervoor dat er extra diensten kunnen geleverd worden. Een voorbeeld hiervan is compressie, dit wordt aangeboden door het Compression Control Protocol (CCP). Belangrijker voor een VPN-oplossing is het aanbieden van encryptie, dit kan door het Encryption Control Protocol (ECP: zie [15]). Verschillende encryptie-algoritmen worden ondersteund, waaronder DES en 3DES. PPTP Geschiedenis Het Point-to-Point Tunneling Protocol is ontwikkeld door een consortium waarin onder andere Microsoft en 3Com zetelden. PPTP gebruikt PPP om verkeer te tunnelen over een IP-netwerk zoals het internet, zonder PPP te veranderen. Cisco was de eerste die een implementatie klaar had en verkocht een licentie aan Microsoft. In deze implementatie kan de authenticatie gebeuren met Cisco LEAP of met MS-CHAP en encryptie gebeurt aan de hand van het Microsoft Point-to-Point Encryption protocol (MPPE: zie [16]). PPTP-clients worden sinds Windows 95 meegeleverd en de Routing And Remote Access Service for Microsoft Windows bevat een PPTP server. Vanaf versie (28 oktober 2005) zit er officiële ondersteuning voor PPTP in de Linux-kernel. SuSE 10 was de allereerste Linuxdistributie met een volledig werkende PPTP-client. Ook voor MacOS zijn er PPTP-clients beschikbaar.

48 4.2 VPN-technologieën 31 Veiligheid Door de grote marktpenetratie en door het feit dat Microsoft eerst was met het aanbieden van een implementatie, is Microsoft PPTP veruit het meest gebruikt. Er zijn echter op het internet vele waarschuwingen te vinden in verband met het gebrek aan veiligheid bij deze implementatie. Bruce Schneier en Mudge hebben de eerste versie van de implementatie van Microsoft onderzocht en concluderen dat ze inherent onveilig is, als voorbeeld geven ze L0phtcrack, een programma dat het mogelijk maakt om op basis van de doorgestuurde hashes makkelijk het wachtwoord te verkrijgen (zie [17, 18, 19]). Dit is op verschillende nieuwssites gepubliceerd geweest (zie [20, 21, 22]). Nadat dit aan het licht kwam heeft Microsoft enkele aanpassingen aangebracht aan hun implementatie, maar nog steeds werden veiligheidsproblemen gesignaleerd. Asleap bijvoorbeeld (zie [23, 24]) kan zwakke LEAP- en PPTP-wachtwoorden onderscheppen enkel en alleen door het verkeer af te luisteren. Met dit wachtwoord kan dan de hele PPTP-stroom gedecodeerd en gelezen worden. Bruce Schneier en Mudge onderzochten de verbeterde versie en publiceerden de resultaten, het bleek nog altijd mogelijk dezelfde wachtwoorden te weten te komen (zie [25, 19]). Verder zijn er nog enkele Microsoft Security Bulletins waar veiligheidsproblemen besproken worden. In MS ([26]) wordt toegelicht hoe een Denial-of-Service-aanval kan worden ondernomen door een slechtgevormde PPTP-pakketstroom te versturen. Er hoeft hiervoor geen geldige PPTP-sessie opgezet te worden. MS ([27]) bespreekt een gelijkaardige aanval. Een samenvatting van alle bekende exploits met betrekking tot PPTP en resultaten van tests omtrent deze exploits zijn te vinden in [28]. Werking Terwijl bij PPP één extra machine instaat voor de implementatie van het protocol, genaamd de Network Access Server (NAS) verdeelt PPTP de verantwoordelijkheden onder twee verschillende machines zoals geïllustreerd in figuur De PPP-verbinding wordt door PPTP logisch uitgebreid door de PPP-frames te tunnelen tussen twee machines, namelijk de PPTP Access Concentrator (PAC) en de PPTP Network Server (PNS). In plaats van verbonden te worden met het publieke internet zoals dat het geval is bij PPP, wordt er over dit publieke internet een tunnel opgezet zodat de PPTP-client verbonden wordt met een privaat netwerk naar keuze. De PAC staat in voor de clientzijde van de tunnel. PSTN- of ISDN-lijnen zijn rechtstreeks verbonden met deze machine. De PAC moet in staat zijn een PPP-verbinding op te zetten en te onderhouden over de fysieke verbindingen waarvoor hij verantwoordelijk is én staat in voor

49 4.2 VPN-technologieën 32 Figuur 4.10: Werking van PPTP / L2TP het afhandelen van het PPTP-protocol. De PNS staat in voor de serverzijde van de tunnel. Er bestaat een many-to-many-relatie tussen PACs en PNSs. Zo is het mogelijk dat eenzelfde PNS diensten aanbiedt aan gebruikers verbonden met verschillende PACs (client-to-site VPN). Het is eveneens mogelijk om voor eenzelfde virtueel netwerk verschillende PNSs te gebruiken. PPTP is verbindingsgeoriënteerd. Zowel de PAC als de PNS houdt informatie bezig over alle gebruikers die verbonden zijn met een PAC. Wanneer een gebruiker verbonden met een welbepaalde PAC een verbinding met de PNS wil opzetten, wordt er een tunnel tussen PAC en PNS opgezet. Vooraleer PPP kan getunneld worden tussen PAC en PNS moet er een controleverbinding tussen hen opgezet worden. Deze verbinding is een standaard TCP-verbinding op poort 1723 waarover PPTP controle- en onderhoudsboodschappen stuurt. Deze verbinding wordt gebruikt voor het opzetten, onderhouden en afbreken van sessies over de tunnel. Naast de controleverbinding maakt PPTP gebruik van een IP-tunnel tussen dezelfde PAC en PNS. Er wordt gebruik gemaakt van een licht gewijzigde versie van Generic Routing Encapsulation (GRE: zie [29, 30]) om de PPP-pakketten te encapsuleren. Alle PPP-sessies tussen een bepaald PAC-PNS-paar worden over dezelfde tunnel vervoerd, op basis van een sleutel in de GRE-header kan een PPP-pakket toegewezen worden aan een welbepaalde PPP-sessie. Op deze manier worden verschillende PPP-sessies gemultiplext over één enkele tunnel. De pakketten die over deze tunnel lopen zijn PPP-pakketten geëncapsuleerd in GRE, verzonden over IP zoals te zien in figuur 4.11.

50 4.2 VPN-technologieën 33 PPTP is uiteraard niet beperkt tot inbelverbindingen. Bovenvernoemde PPTP-clients zorgen ervoor dat een niet-inbelclient zelf kan instaan voor een eindpunt van een PPTP-tunnel. De PPTP-client zorgt dan zowel voor het inpakken in en uitpakken van PPP-frames, als voor het tunnelen door PPTP. Figuur 4.11: Structuur van een PPTP-pakket L2TP Geschiedenis Layer 2 Tunneling Protocol komt voort uit twee andere protocollen die PPP tunnelen, namelijk Layer 2 Forwarding (L2F) van Cisco en PPTP. Voor authenticatie en encryptie steunt L2TP grotendeels op andere protocollen. Bij L2TP/PPP (hierbij worden PPP-sessies getunneld over L2TP) zorgt PPP voor authenticatie bij het opzetten van de controleverbinding en encryptie voor de dataverbinding. Een andere mogelijkheid is L2TP/IPSec, hierbij steunt L2TP op de mogelijkheden van IPSec qua authenticatie en encryptie. Cisco beweert een patent te hebben met betrekking tot L2F en L2TP, namelijk patent nummer in de Verenigde Staten van Amerika. Werking De werking van L2TP is volledig analoog aan de werking van PPTP (zie figuur 4.10). PPP laat toe om TCP/IP-pakketten te versturen over dial-upverbindingen door ze te encapsuleren in PPP-frames en ze te versturen naar een ISP die de TCP/IP-pakketten uit deze PPP-frames haalt en ze het publieke internet instuurt. L2TP, net als PPTP, trekt deze logische verbinding door naar een zelf gekozen machine ergens op het internet. Er wordt een tunnel opgezet tussen een machine bij de eigen ISP en een zelf te kiezen machine. De functionaliteiten van de Network Access Server (NAS) worden net als bij PPTP gesplitst tussen de L2TP Access Concentrator (LAC) en de L2TP Network Server (LNS). De LAC doet zich voor als een NAS ten opzichte van de gebruiker, maar is in werkelijkheid het ingangspunt voor de L2TP-tunnel. De LNS doet dienst als eindpunt van de L2TP-tunnel en ontdoet de L2TP-pakketten van zijn L2TP- en PPP-header zodat enkel het TCP/IP-pakket overblijft en doorgestuurd wordt naar het achterliggende netwerk. Net als bij PPTP kunnen over een tunnel tussen LAC en LNS meerdere sessies lopen.

51 4.2 VPN-technologieën 34 Figuur 4.12: Structuur van een L2TP/PPP-pakket L2TP tunnelt PPP-verkeer en erft dus authenticatie, encryptie en compressie over van PPP.Het biedt daarnaast een beperkte authenticatie van de eindpunten van de tunnel, maar biedt geen extra beveiliging van het verkeer over de tunnel. Figuur 4.12 toont de structuur van een L2TP/PPP-pakket. Een L2TP/PPP-pakket is niks anders dan een UDP-datagram met specifieke inhoud. Om verdere beveiliging aan te bieden gebruikt L2TP/IPSec de mogelijkheden van IPSec, zoals beschreven in L2TP/PPPpakketten worden geëncapsuleerd in IPSec-pakketten om de extra beveiligingsmogelijkheden in IPSec te gebruiken. Er wordt dus een L2TP-tunnel opgezet over een beveiligde IPSec-verbinding. Tabel 4.2: Vergelijking VPN-technologieën IPSec OpenVPN PPTP L2TP/PPP L2TP/IPSec Authenticatie PSK, RSA, PSK, MS- PPP IPSec, PPP X.509 X.509, user/pass CHAPv2, CISCO LEAP Key exchange IKE TLS/SSL Geen Geen IKE Standaard ondersteunde AES, DES, Alle in PPP 2 PPP IPSec, PPP encryptie- algoritmen 3DES, RC5, IDEA, 3IDEA, CAST, Blowfish OpenSSL (3DES, AES, Blowfish,...) Kernelspace of Kernelspace Userspace Kernelspace Kernelspace Kernelspace userspace Bridging Nee Ja Ja Ja Nee 2 3DESE (RFC2420), DESE (RFC1969), MPPE (RFC3078), maar men kan voor elk encryptie-algoritme een ECP schrijven.

52 4.2 VPN-technologieën 35 Tabel 4.2: Vergelijking VPN-technologieën IPSec OpenVPN PPTP L2TP/PPP L2TP/IPSec Platform Beschikbaar Windows, Windows, Windows, Windows, voor bijna Unix, Linux, Linux, Linux, alle *BSD, Mac *BSD, *BSD, *BSD, platformen OSX meeste Unices meeste Unices meeste Unices NAT-traversal Nee Ja Ja Ja Nee Aanspreekbaar in Nee Ja Nee Nee Nee Java op algemene manier Vergelijking Tabel 4.2 toont de eigenschappen van de verschillende VPN-technologieën waarop deze vergelijking is gebaseerd. Allereerst zullen we PPTP en L2TP/PPP bespreken aangezien beide technologieën gelijkaardig zijn. Beiden tunnelen PPP-verkeer zonder verdere encryptie en doen aan authenticatie bij het opzetten van de verbinding, maar voorzien niet in per-pakketauthenticatie. Het enige grote verschil is de manier waarop het PPP-verkeer geëncapsuleerd wordt. PPTP gebruikt een GRE-achtig protocol om daarna via IP verzonden te worden. L2TP/PPP neemt een PPP-frame, voegt hier eigen informatie aan toe en encapsuleert dit in UDP voor verzending. Beide protocollen moeten in het algemeen in kernelspace geïmplementeerd worden wat voor het systeem dat hier besproken wordt een groot probleem met zich meebrengt aangezien de VPN-oplossing met zo weinig mogelijk extra configuratie op de gateways moet kunnen geïnstalleerd worden. Verder is de veiligheid die PPTP biedt onvoldoende voor het systeem. Bij L2TP is er dan weer sprake van een patentprobleem. Deze problemen geven aan dat het niet de moeite is het probleem van de installatie en moeilijke aanspreekbaarheid in Java te proberen op te lossen. IPSec en L2TP/IPSec zijn eveneens gelijkaardige protocollen met dat verschil dat IPSec enkel IP-verkeer kan transporteren terwijl L2TP/IPSec doordat het PPP tunnelt ook andere protocollen kan vervoeren. Tevens heeft L2TP/IPSec meerdere lagen van encryptie en authenticatie ten opzichte van IPSec. IPSec en L2TP/IPSec zijn in dit geval niet makkelijk bruikbaar

53 4.3 Adresseringsstrategie 36 aangezien er standaard niet door NAT kan getunneld worden en de meeste implementaties zich in kernelspace bevinden waardoor ze minder makkelijk aanspreekbaar zijn in Java en moeilijk installeerbaar zijn. OpenVPN is de beste oplossing voor dit probleem aangezien verschillende problemen rechtstreeks opgelost worden door dit protocol. NAT is geen probleem. policies kunnen worden geïmplementeerd. het is aanspreekbaar in Java door gebruik te maken van een TCP-verbinding. de veiligheid wordt gegarandeerd door TLS voor sleuteluitwisseling en de effectieve datapakketten worden geauthenticeerd en geëncrypteerd met de meest recente cryptografische algoritmen uit de OpenSSL-bibliotheek. 4.3 Adresseringsstrategie Eén van de problemen die kunnen optreden wanneer men een VPN-verbinding aanlegt tussen twee willekeurige netwerken, is dat van overlappende subnetwerken: beide gateways gebruiken overlappende (of gelijke) subnetwerken, als gevolg hiervan is het onmogelijk voor hosts op het ene netwerk om hosts op het andere netwerk te adresseren. Immers, deze hosts lijken op hetzelfde netwerk te zitten, de contacterende host zal zijn IP-pakketten niet naar de gateway sturen, maar een ARP-request versturen op het netwerk (en dus geen antwoord krijgen, of een antwoord van een verkeerde host). Dit probleem komt uiteraard enkel voor indien de netwerken gebruik maken van een subnetwerk uit de private adresruimte. Deze bestaat uit de subnetwerken /8, /12 en /16. 3 Het probleem is zeker niet te verwaarlozen bij home gateways, omdat gateways van hetzelfde merk en type vaak hetzelfde subnetwerk gebruiken (typisch bijvoorbeeld /24 of /8). Een aantal mogelijke oplossingen worden beschreven in de volgende secties. 3 De CIDR-notatie wordt hier gebruikt om de netwerken aan te duiden.

54 4.3 Adresseringsstrategie Netwerken samenvoegen De meest voor de hand liggende oplossing is om de twee overlappende netwerken proberen samen te voegen tot één netwerk. Dit kan door de VPN-daemon te laten opereren in bridgemode. In deze mode gedraagt de VPN-tunnel zich als een ethernet-bridge: alle ethernet-pakketten die op het ene netwerk verstuurd worden (en de gateway bereiken), worden doorgestuurd over de tunnel naar het andere netwerk. Op deze manier vormen de twee netwerken samen één logisch netwerk. Om dit te doen werken moeten alle hosts op beide netwerken ingesteld zijn op hetzelfde subnetwerk (met hetzelfde netwerkmasker). Bovendien mogen geen 2 hosts uit de verschillende netwerken hetzelfde IP-adres hebben. Dit kan opgelost worden indien op beide netwerken alle hosts met DHCP geconfigureerd worden. Dan kan één van de gateways gekozen worden als DHCP-server, die dan niet-conflicterende IP-adressen kan uitdelen aan de hosts op beide netwerken. Eventueel kan een groter subnetwerk gekozen worden als nieuw netwerk, om er zeker van te zijn dat alle hosts een IP-adres kunnen krijgen. Deze oplossing vereist natuurlijk dat de gateways de oorspronkelijke DHCP-servers (dit kunnen eventueel de gateways zelf zijn) kunnen stopzetten. Het grote nadeel van deze oplossing is dat het zeer waarschijnlijk is dat een aantal hosts een nieuw IP-adres zullen moeten krijgen. Dit is echter niet wenselijk: alle bestaande verbindingen voor deze hosts zullen hierdoor afgebroken worden, ook al was het niet de gebruiker van deze host die de VPN-verbinding opgezet heeft! Een ander nadeel is dat deze oplossing enkel werkt voor netwerken waarbij alle IP-adressen door DHCP geconfigureerd worden. Als er een adresconflict is tussen twee hosts met hetzelfde statisch ingestelde IP-adres, zal dit manueel opgelost moeten worden Adresvertaling Een tweede oplossing is om gebruik te maken van adresvertaling. Door op de gateways de bron- en bestemmingsadressen van pakketten aan te passen, kan een client op het ene netwerk aangesproken worden door een client op het andere netwerk aan de hand van een nieuw, virtueel IP-adres. Er wordt dus als het ware een overlay-netwerk gecreëerd. Op deze manier kunnen de hosts hun huidige IP-adres behouden, zodat bestaande verbindingen niet worden verbroken. Verder werkt deze methode ook voor netwerken met statisch ingestelde IP-adressen. Er zijn verschillende manieren om deze adresvertaling in te stellen:

55 4.3 Adresseringsstrategie 38 Adresvertaling met virtuele IP-adressen in het remote netwerk Dit systeem kan toegepast worden indien op beide netwerken alle hosts met DHCP geconfigureerd worden en de gateways DHCP-server zijn. De gateways op beide netwerken sturen de IP-adressen van de met DHCP geconfigureerde hosts door naar elkaar. De gateways reserveren voor elk van deze IP-adressen een nieuw, virtueel IP-adres op hun lokale netwerk en houden een relatie bij tussen fysiek en virtueel IP-adres. Wanneer een IP-pakket op de gateway toekomt met als bestemmingsadres een van de gereserveerde virtuele IP-adressen, wordt het bestemmingsadres van het pakket vertaald naar het fysieke IP-adres en wordt het pakket verstuurd naar de remote gateway. Op de andere gateway zal dan het bronadres vertaald worden naar het virtuele IP-adres dat daar gereserveerd is. Een probleem is wel dat pakketten voor het remote netwerk mogelijkerwijs niet op de gateway toekomen. Het virtuele IP-adres voor een host op het remote netwerk ligt immers binnen het eigen netwerk. Dit IP-adres zal dus geresolved worden aan de hand van een ARP-request. Het is dus nodig dat de gateway ARP-reply s (met het MAC-adres van de gateway) zal genereren voor de hosts van het remote netwerk. Verder is het zo dat er voortdurende communicatie nodig is tussen de gateways, om elkaar in te lichten wanneer een nieuwe host verschijnt op hun netwerk. Adresvertaling met nieuwe subnetwerken Een betere oplossing is om aan beide netwerken een nieuw, onderling niet overlappend, virtueel subnetwerk toe te kennen. De gateway past dan adresvertaling toe op de volgende manier: bij IP-pakketten met als bestemming het virtuele subnetwerk van de remote gateway wordt het bronadres vertaald naar een IP-adres uit het lokale virtuele subnetwerk bij IP-pakketten met als bestemming het lokale virtuele subnetwerk wordt het bestemmingsadres vertaald naar het correcte IP-adres uit het lokale fysieke subnetwerk De gateway houdt dus een relatie bij voor alle clients op zijn netwerk. De routering moet zo ingesteld worden dat pakketten bestemd voor het remote virtuele subnetwerk, verstuurd worden over de tunnel. Het voordeel van deze methode is dat het onafhankelijk van de DHCP-server werkt. Verder is het zo dat elke gateway enkel verantwoordelijk is voor de adresvertaling van zijn eigen hosts. Dit

56 4.3 Adresseringsstrategie 39 maakt het eenvoudiger om te implementeren en eenvoudiger uitbreidbaar naar situaties waarin gateways verschillende VPN-verbindingen aanmaken. Een nadeel van deze methode is dat, aangezien men niet kan weten hoeveel hosts er op een gegeven subnetwerk zitten (doordat hosts een statisch ingesteld IP-adres kunnen hebben), men voor het virtuele subnetwerk altijd een even groot subnetwerk moet kiezen als het fysieke subnetwerk. Bovendien kan men voor de virtuele subnetwerken enkel kiezen uit de private adresruimte (indien men een publiek subnetwerk zou kiezen, is dit niet meer adresseerbaar door de hosts). Indien het fysieke subnetwerk /8 is, is het dus onmogelijk om een nieuw virtueel subnetwerk te kiezen dat groot genoeg is. Verder is het ook mogelijk, in het geval dat er meerdere VPN-verbindingen worden opgezet vanuit één gateway, dat de private subnetwerken waaruit een gateway kan kiezen voor virtuele subnetwerken, uitgeput raken. Elke VPN-verbinding zal er immers voor zorgen dat twee subnetwerken niet meer gebruikt kunnen worden (namelijk het lokale virtuele subnetwerk en het remote virtuele subnetwerk). Deze nadelen worden geminimaliseerd indien de subnetwerken van de deelnemende partijen niet te groot gekozen worden. Figuur 4.13 toont een voorbeeld van deze methode. Figuur 4.13: Een voorbeeld van adresvertaling met nieuwe subnetwerken. Het linkernetwerk heeft als virtueel subnetwerk /24; het rechternetwerk heeft /24.

57 ONTWERP 40 Hoofdstuk 5 Ontwerp 5.1 Inleiding In dit hoofdstuk wordt het ontwerp van het systeem besproken. De eerste ontwerpbeslissing betreft de inbedding in het OSGi Service Platform. Zoals vermeld in sectie 4.1 bestaan applicaties voor dit platform uit bundles die services kunnen aanbieden en gebruiken. Het is dan ook een logische stap om de verschillende modules uit de architectuur af te beelden op OSGi-bundles 1. Voor elke module wordt een Java interface aangemaakt (deze interfaces worden gegroepeerd in de package jason.interfaces) en een bundle die een klasse bevat die deze interface implementeert. Deze bundle wordt als service geregistreerd in het OSGi-framework. Deze aanpak heeft als voordeel dat de modules onafhankelijk van elkaar kunnen geïmplementeerd worden (er is enkel een afhankelijkheid van de interfaces). Een ander voordeel is dat de modules onafhankelijk van elkaar kunnen geïnstalleerd worden op de gateways en dat er eenvoudig een module kan vervangen worden. Indien men bijvoorbeeld een bug vaststelt in de VPNInterface, hoeft enkel deze bundle vervangen te worden, de andere bundles hoeven hiervoor niet eens gestopt te worden. Om dit te verwezenlijken werd gekozen voor een zwakke binding tussen de bundles: wanneer een bepaalde bundle een service wil gebruiken van een andere bundle, wordt de service op dat moment opgezocht. De bundles houden dus geen blijvende referenties bij naar andere bundles. Een andere ontwerpbeslissing betreft de keuze van OpenVPN als basis voor de VPNInterface. De keuze voor OpenVPN is gemotiveerd in Voor de adresvertaling, besproken in 4.3.2, wordt gebruik gemaakt van iptables, een pro- 1 Een uitzondering is de module GNSserver. Deze module bevindt zich niet op een gateway, maar op een server beheerd door de Service Provider. gewone Java-applicatie. Deze is dan ook niet geïmplementeerd als een OSGi-bundle, maar als een

58 5.2 Negotiator 41 gramma dat kan gebruikt worden om de firewall- en adresvertalingsopties in de linuxkernel in te stellen. Dit betekent dat adresvertaling momenteel enkel mogelijk is op een linuxgateway, maar het is zeker mogelijk om deze functionaliteit ook te implementeren voor andere platformen. Bij de onderhandeling die optreedt tussen gateways alvorens een VPN-verbinding op te zetten, wordt gekeken of beide partijen adresvertaling ondersteunen, indien dit nodig blijkt. Ten slotte werd ook nog een protocol ontworpen voor de onderhandeling tussen gateways (sectie 5.2.1) en één voor de communicatie tussen gateway en GNS-Server (sectie 5.8.1). De module Policing werd niet geïmplementeerd. De volgende secties beschrijven het ontwerp voor de verschillende modules/bundles. 5.2 Negotiator Figuur 5.1 toont alle klassen gebruikt voor de implementatie van de module Negotiator Generiek onderhandelingsprotocol Om de redenering in sectie tot een goed einde te brengen, moeten beide onderhandelingspartners natuurlijk eenzelfde taal spreken. Deze taal wordt hieronder besproken. Bij het starten van de onderhandeling gaat de Negotiator van de gateway die de onderhandeling heeft gestart, aan alle geregistreerde bundles een gesorteerde lijst van waarden vragen van alle parameters waarvoor deze bundle zich geregistreerd heeft. Deze lijsten dienen gesorteerd te zijn volgens dalende voorkeur. Op basis van de aangeleverde lijsten wordt een bericht opgesteld dat naar de andere kant wordt verstuurd. Het bericht volgt de specificatie in figuur 5.2. Hierbij is <EOL> het einde van een lijn en zijn <Name> en <Choice> tekstsequenties waar geen : of ; in voorkomen. De Negotiator van de gateway die het bericht ontvangt, verwerkt dit bericht en krijgt alzo de gesorteerde lijsten waarvan eerder sprake. Aan elk van de op deze gateway geregistreerde bundles wordt, voor elke parameter waarvoor deze geregistreerd is, een gesorteerde lijst met waarden gegeven. Op basis van deze informatie beslist de bundle over deze parameters en geeft een lijst met beslissingen terug voor alle parameters waar een beslissing voor nodig is. Een antwoord wordt opgesteld aan de hand van de beslissingen van de bundles. Dit bericht volgt de specificatie in figuur 5.3. De beslissing neemt één van de volgende waarden aan: één van de mogelijke waarden die werden aangeleverd door de beginnende gateway.

59 5.2 Negotiator 42 Figuur 5.1: Klassendiagram van relevante klassen voor de bundle Negotiator UNKNOWN geeft aan dat de beginnende gateway over een parameter wil onderhandelen die de ontvangende gateway niet kent (dus waarvoor geen bundle zich geregistreerd heeft). N/A geeft aan dat er geen beslissing nodig is voor deze parameter, dit kan bijvoorbeeld voorkomen wanneer een extra parameter nodig is om tot een beslissing van een andere parameter te komen. FAIL is een manier om de beginnende gateway duidelijk te maken dat er geen beslissing mogelijk is en dat een verbinding niet mogelijk is onder de op dat ogenblik geldende omstandigheden. Het is niet verplicht om een beslissing in te vullen, in dit geval wordt N/A als beslissing aangenomen.

60 5.2 Negotiator 43 Figuur 5.2: (a) Specificatie van vraag negotiatorprotocol (b) Voorbeeld van een vraag Figuur 5.3: (a) Specificatie van antwoord negotiatorprotocol (b) Voorbeeld van een antwoord De gateway die de onderhandeling heeft ingezet, bekijkt de beslissingen die de andere gateway genomen heeft, beslist of hij hier al dan niet mee akkoord gaat en stuurt een ACK of een NACK naar de andere gateway. Bij een ACK zal langs beide kanten de verbinding opgezet worden. Een NACK heeft als gevolg dat de onderhandeling en de bijbehorende verbinding wordt afgebroken Implementatie onderhandelingsprotocol Om het Negotiatorprotocol van te implementeren is er gebruik gemaakt van de listenerarchitectuur. Alle bundles die de onderhandeling van één of meerdere parameters wil uitbesteden aan de Negotiator moet een interface genaamd NegotiatorListener implementeren. In grote lijnen zijn er twee fasen: in de eerste registreert elke bundle zich bij de lokale Negotiator waarna er over verbindingen kan onderhandeld worden (tweede fase). Registratie Figuur 5.4 toont hoe een registratie bij de Negotiator in zijn werk gaat. Bij de lokale gateway registreert een bundle de parameters waarvoor hij verantwoordelijk wil zijn. Enige tijd later komt er een andere bundle online die zijn parameters wil registreren. Bij de registratie merkt de Negotiator dat één of meerdere van de parameters die de tweede bundle wil registreren reeds geregistreerd is door de eerste bundle. Nadat de bundle van de Negotiator te horen heeft gekregen welke parameters hij niet mag registreren, probeert hij nog een keer. Ditmaal lukt

61 5.2 Negotiator 44 Figuur 5.4: Registratiefase generiek onderhandelingsprotocol de registratie. Eenzelfde registratie voltrekt zich bij alle gateways die gebruik maken van dit systeem. Onderhandeling Wanneer een gebruiker een verbinding wil starten zal het systeem een onderhandeling starten tussen de lokale gateway en de gateway waarmee de gebruiker verbinding wil maken. Deze onderhandeling is op zich eveneens onderverdeeld in verschillende stappen. Maar vooraleer er met de effectieve onderhandeling begonnen wordt, wordt er door middel van de mogelijkheden die SSL/TLS biedt gecontroleerd of de gateway waarmee wordt gecommuniceerd wel degelijk is wie hij zegt te zijn. Ook wordt gekeken of de andere kant voorkomt in de lokale lijst van vertrouwde gateways. Deze controles gebeuren aan beide kanten van de verbinding en zodra één van de controles faalt, wordt de onderhandeling afgebroken. Voor elke aanvraag tot onderhandeling die een gateway verwerkt, wordt een aparte thread opgestart zodat er terzelfdertijd opnieuw op nieuwe aanvragen gewacht kan worden. 1. Request: in figuur 5.5 wordt grafisch weergegeven wat er gebeurt in deze eerste stap. De Negotiator vraagt aan alle geregistreerde NegotiatorListener s een geordende lijst van keuzes voor elke parameter waarvoor die specifieke bundle zich geregistreerd heeft. Wanneer hij al deze lijsten ontvangen heeft, wordt het bericht gegenereerd volgens de specificatie in figuur 5.2. Eens het bericht aangemaakt is, wordt het over een beveiligde verbinding naar de andere gateway gestuurd.

62 5.2 Negotiator 45 Figuur 5.5: Genereren vraag generiek onderhandelingsprotocol 2. Antwoord: wanneer de vraag binnenkomt aan de andere kant van de verbinding, wordt tijdens het ontleden van het bericht gekeken welke NegotiatorListener lokaal verantwoordelijk is voor de verschillende parameters. De geordende lijsten van de desbetreffende parameters worden aan de juiste bundles gegeven zodat deze een beslissing kunnen nemen over hun parameters. De Negotiator ontvangt deze beslissingen en genereert een antwoord om terug te sturen naar de gateway die de onderhandeling heeft gestart. In figuur 5.6 wordt dit grafisch weergegeven. Figuur 5.6: Beslissingsfase generiek onderhandelingsprotocol 3. Bevestiging: de beslissing die de gateway aan de andere kant van de verbinding genomen heeft over de te onderhandelen parameters, moet nog goedgekeurd worden door de gateway

63 5.2 Negotiator 46 die de onderhandeling heeft gestart. Dit gebeurt door het bericht met de beslissingen aan de verantwoordelijke bundles te geven. Van zodra één van de bundles niet akkoord gaat met de onderhandelde parameters (typisch zal dit gebeuren als de beslissing van een parameter FAIL is of in het geval de beslissing UNKNOWN is en de desbetreffende parameter verplicht is voor de huidige verbinding) zal een NACK verstuurd worden. Wanneer alle beslissingen echter in orde zijn, kunnen beide kanten alles in gereedheid brengen voor de effectieve VPN-verbinding. Figuur 5.7 geeft dit grafisch weer. Figuur 5.7: Controlefase generiek onderhandelingsprotocol NegotiatorListener Om gebruik te kunnen maken van de diensten van de Negotiator moet een bundle de interface NegotiatorListener implementeren, waar volgende functies worden gedefinieerd: getparameterlists: een functie die wordt gebruikt in de eerste fase van de eigenlijke onderhandeling (figuur 5.5) om geordende voorkeurslijsten voor alle parameters te verkrijgen. negotiateparameters: een functie die wordt gebruikt in de beslissingsfase (figuur 5.6) om de beslissing te laten gebeuren. negotiatedparameters: een functie die de bundle op de hoogte brengt van de beslissing van de parameters zoals in figuur 5.7. Een bundle moet zich bij de Negotiator registreren voor elke parameter waar hij voor verantwoordelijk wil zijn.

64 5.3 ConfigurationManager 47 DefaultNegotiatorListener Voor het simpele geval dat een parameter niet wordt beïnvloed door andere parameters werd er een abstracte standaardimplementatie van NegotiatorListener aangeboden. Hierbij wordt enkel de functie die een beslissing neemt voor elke parameter, geïmplementeerd. Het is niet de bedoeling van de onderhandeling om de wil van één van de gateways door te drukken, maar om een keuze te maken die voor beide gateways de best mogelijke optie is rekening houdend met de wensen van de andere gateway. De implementatie volgt de volgende redenering: allereerst worden uit beide gesorteerde lijsten die opties geschrapt die niet voorkomen in de andere lijst. Daarna worden voor alle resterende opties de indices opgeteld, de optie met de kleinste som wordt teruggegeven als beslissing. Figuur 5.8 laat een dergelijke onderhandeling zien. In stap 1 worden choice1, choice3 en choice5 geschrapt als mogelijke beslissing. De keuze tussen choice2 en choice4 gebeurt op basis van de graad van voorkeur die de gateways aan deze keuzes hebben gegeven. Alhoewel gateway 2 choice4 als absolute voorkeur heeft opgegeven, zal toch choice2 gekozen worden aangezien die keuze het best mogelijke compromis is. Figuur 5.8: Voorbeeld van een standaardonderhandeling 5.3 ConfigurationManager Figuur 5.9 toont alle klassen gebruikt voor de implementatie van de module ConfigurationManager. Nadat de onderhandeling heeft plaatsgevonden, moet de onderhandelde informatie ergens bijgehouden worden. Hiervoor zijn verschillende mogelijkheden. De Negotiator kan alle bundles afzonderlijk op de hoogte brengen of de informatie kan centraal opgeslagen worden. Dit laatste is precies waarvoor de ConfigurationManager in het leven geroepen is. Buiten verbindingsspecifieke informatie houdt de ConfigurationManager eveneens informatie bij die van toepassing is voor het lokale systeem, zoals een lijst van gateways waarmee een verbinding mag gemaakt worden en

65 5.4 AddressTranslation 48 Figuur 5.9: Klassendiagram van relevante klassen voor de bundle ConfigurationManager certificaten van de lokale gateway. De lijst van vertrouwde gateways wordt bij het afsluiten van de bundle persistent opgeslagen zodat het falen van de ConfigurationManager niet tot gevolg heeft dat de configuratie verloren gaat. Om de verbindingsspecifieke informatie consistent te houden, worden er twee functies voorzien om verbindingen in het systeem te onderhouden. Eén om een verbinding aan te maken in het systeem en één om een verbinding uit het systeem te verwijderen. 5.4 AddressTranslation Figuur 5.10 toont een overzicht van de belangrijkste klassen in de bundle AddressTranslation.

66 5.4 AddressTranslation 49 Figuur 5.10: Klassendiagram van relevante klassen voor de bundle AddressTranslation AddressTranslationConfig Om informatie over een bepaalde adresvertaling op te slaan, wordt gebruik gemaakt van klassen die de interface AddressTranslationConfig implementeren. In deze interface zijn methoden voorzien om de adresvertaling in te stellen en te herstellen. Verder omvat hij methoden om de gebruikte subnetwerken te verkrijgen voor de lokale virtuele IP-adressen, de remote virtuele IP-adressen en de IP-adressen voor de tunnel. Twee dergelijke klassen werden geïmplementeerd: NoneAddressTranslationConfig en Static- RemappingAddressTranslationConfig. NoneAddressTranslationConfig voert geen adresvertaling uit en houdt dus enkel de informatie bij over de gebruikte subnetwerken. StaticRemappingAddressTranslationConfig voert een statische remapping van IP-adressen uit. Hierbij wordt een subnetwerk volledig afgebeeld op een nieuw subnetwerk, op volgende wijze: de offset van het (oude) IP-adres (bv ) binnen het (oude) subnetwerk (bv /24) wordt opgeteld bij het nieuwe subnetwerk (bv /24). Op deze manier wordt een nieuw IP-adres bekomen (in het voorbeeld ), dat binnen het nieuwe subnet-

67 5.4 AddressTranslation 50 werk ligt. Deze functionaliteit wordt bekomen door gebruik te maken van de tool iptables en is dus enkel beschikbaar op linux-gateways. Er worden om de adresvertaling te starten twee regels toegevoegd aan de nat -tabel van iptables: iptables -t nat -A PREROUTING -d lokaal_virtueel_subnetwerk -j NETMAP --to lokaal_fysiek_subnetwerk iptables -t nat -A POSTROUTING -d remote_virtueel_subnetwerk -s lokaal_fysiek_subnetwerk -j NETMAP --to lokaal_virtueel_subnetwerk Deze commando s worden uitgevoerd vanuit Java in een nieuw extern proces. Het eerste commando zal ervoor zorgen dat het doeladres van IP-pakketten gericht aan het lokale virtuele netwerk, vertaald zal worden naar het correcte fysieke IP-adres uit het lokale virtuele netwerk. Aangezien deze regel aan de PREROUTING chain wordt toegevoegd, wil dit zeggen dat deze pakketten naar het lokale netwerk gerouteerd worden (zoals verwacht). Het tweede commando neemt pakketten die afkomstig zijn van het lokale netwerk en bestemd zijn voor het remote virtuele netwerk en vertaalt hun bronadres naar het correcte virtuele adres uit het virtuele lokale subnetwerk. In figuur 5.11 wordt een voorbeeld gegeven van statische remapping met als lokaal fysiek subnetwerk /24, lokaal virtueel subnetwerk /24, en remote virtueel subnetwerk /24. De iptables commando s zijn in dit geval: iptables -t nat -A PREROUTING -d /24 -j NETMAP --to /24 iptables -t nat -A POSTROUTING -d /24 -s /24 -j NETMAP --to / NegotiatorListener methodes AddressTranslationImpl implementeert ook de interface NegotiatorListener. Bij het opstarten van de bundle wordt een AddressTranslationImpl-object geregistreerd bij de Negotiator-service voor de parameters: addresstranslationmethods, localrange, remoterange, tunnelrange en physicalrange.

68 5.4 AddressTranslation 51 Figuur 5.11: Voorbeeld van adresvertaling met statische remapping De betekenis van de parameters is als volgt: addresstranslationmethods de adresvertalingsmethodes die ondersteund worden ( none en static-remapping zijn gedefinieerd) physicalrange het lokale, fysieke subnet van de gateway localrange de virtuele subnetten die gebruikt kunnen worden om het lokale netwerk te adresseren vanaf de andere gateway remoterange de virtuele subnetten die gebruikt kunnen worden om het remote netwerk te adresseren vanaf de lokale gateway tunnelrange de virtuele subnetten die gebruikt kunnen worden voor de eindpunten van de tunnel (met andere woorden de IP-adressen voor de virtuele tun-netwerkinterfaces op beide gateways) Bij het opstarten van de bundle zal nagegaan worden wat het fysieke subnet is van het lokale netwerk. Aangezien dit onmogelijk te bepalen is met de bestaande Java-API, wordt hiervoor gebruik gemaakt van jnetdev (zie [31]), een open source Java class library voor low level pakketmanipulatie, die ook deze functionaliteit aanbiedt.

69 5.4 AddressTranslation 52 Wanneer een nieuwe VPN-verbinding aangemaakt wordt op de lokale gateway, zal getparameters() opgeroepen worden. De bundle zal dan nagaan welke adresvertalingsmethodes mogelijk zijn op de gateway (in de huidige implementatie is dit none en static-remapping voor een linuxgateway, none voor een Windowsgateway). Voor de parameter physicalrange wordt het eerder bepaalde fysieke subnet meegegeven. De waarde voor de parameters localrange, remoterange en tunnelrange is dezelfde: de verzameling private subnetwerken die niet overlappen met het fysieke lokale subnet en niet overlappen met subnetten die reeds gebruikt worden als virtueel subnet bij andere verbindingen. Het algoritme om deze verzameling te bepalen kan in pseudocode beschreven worden: result := lege lijst taken := lijst van subnetwerken die reeds in gebruik zijn subnetwork := subnetwerk /16 method addbiggestfreeranges(subnetwork) { if (grootte subnetwork < 4) // onbruikbaar return if (overlap met een subnetwerk uit taken) splits subnetwork in 2 gelijke delen: s1 en s2 addbiggestfreeranges(s1) addbiggestfreeranges(s2) else voeg subnetwork toe aan result } Dit algoritme wordt toegepast voor de 3 subnetwerken die gereserveerd zijn voor privaat gebruik ( /16, /8, /12). Wanneer een nieuwe VPN-verbinding wordt opgezet door een andere gateway, zal negotiate- Parameters() opgeroepen worden. De bundle zal dan eerst nagaan welke adresvertalingsmethode gebruikt moet worden. Indien het fysieke subnetwerk van de remote gateway (in parameter physicalrange ) niet overlapt met het lokale fysieke subnetwerk of met een virtueel subnetwerk voor een andere verbinding en het lokale fysieke subnetwerk deel uitmaakt van de verzameling subnetwerken in remoterange, dan kan de verbinding opgezet worden zonder adresvertaling. Indien dit niet het geval is, wordt bekeken of beide gateways adresvertaling ondersteunen.

70 5.5 VPNInterface 53 Als dit niet zo is, zal de onderhandeling falen. Als dit wel zo is, wordt nagegaan of er compatibele virtuele subnetwerken gevonden kunnen worden. Drie subnetwerken moeten gevonden worden: een subnetwerk voor het virtuele subnetwerk van de lokale gateway dat compatibel is met de remoterange parameter van de andere gateway en bovendien nog niet gebruikt wordt op de eigen gateway een subnetwerk voor het virtuele subnetwerk van de remote gateway dat compatibel is met de localrange parameter van de andere gateway en nog niet gebruikt wordt op de eigen gateway een subnetwerk voor de tunnel, compatibel met de tunnelrange parameter en de eigen vrije subnetwerken. De methode negotiatedparameters() wordt opgeroepen indien het antwoord van de remote gateway ontvangen is. De bundle zal, op basis van de parameters die de remote gateway gekozen heeft, een AddressTranslationConfig aanmaken en zal dit opslaan in de ConfigurationManager. Figuur 5.12 toont een voorbeeld van een negotiatie, waarbij beide gateways hetzelfde lokaal fysiek netwerk hebben: /16. Figuur 5.12: Voorbeeld van een onderhandeling 5.5 VPNInterface Figuur 5.13 toont een overzicht van de belangrijkste klassen in de bundle VPNInterface.

71 5.5 VPNInterface 54 Figuur 5.13: Klassendiagram van relevante klassen voor de bundle VPNInterface Bundle startup Bij het opstarten van de bundle wordt de OpenVPN-binary geïnstalleerd op de gateway, meer bepaald in de bundle storage area. Dit is een directory op de gateway waar de bundle volgens de OSGi-specificaties bestanden kan opslaan die persistent moeten zijn. Er zal eerst gekeken worden of er reeds een OpenVPN-binary geïnstalleerd is in deze bundle storage area. Indien dit niet het geval is, wordt nagegaan wat het besturingssysteem en de processor van de gateway zijn. Op basis van deze informatie wordt de juiste binary vanuit de JAR gekopieerd naar de bundle storage area. Ook de private key en het certificaat, nodig voor het opzetten van VPNverbindingen, worden in dat geval gekopieerd naar de bundle storage area VPNImpl Wanneer startvpn() opgeroepen wordt, worden de volgende acties ondernomen:

72 5.6 AutoVPNInterface 55 Er wordt nagegaan of er nog een vrij tun-device is en indien dit zo is, wordt de naam hiervan (tun0, tun1,...) meegegeven als parameter aan de daemon De OpenVPN-daemon kan ingesteld worden om zelf routering in te stellen nadat een VPN-verbinding succesvol aangemaakt is. De bundle vraagt daarom bij de Configuration- Manager de AddressTranslationConfig voor deze verbinding op. Hieruit wordt de virtuele remote range gehaald (bij een NoneAddressTranslationConfig is dit gewoon de fysieke remote range) en deze wordt dan als parameter meegegeven voor de OpenVPN-daemon. Uit de AddressTranslationConfig wordt ook de tunnelrange gehaald. Uit deze range worden de IP-adressen gekozen voor de tun-devices. De initiërende gateway kiest het eerste IPadres uit het netwerk, de gecontacteerde gateway kiest het tweede IP-adres. Verder kiest de bundle ook nog een vrije poort om de management interface op te laten luisteren. Deze management interface zal gebruikt worden om statusinformatie te verkrijgen van de OpenVPN-daemon. Ten slotte wordt de OpenVPN-daemon opgestart met al deze parameters. Het resulterende Java-Process wordt bijgehouden om het bij het stopzetten van de verbinding, af te kunnen sluiten. Om het einde van een VPN-verbinding te detecteren, is gebruik gemaakt van een keep-alive systeem. In een actieve verbinding wordt door beide gateways elke 10 seconden een ping doorgestuurd naar de andere gateway. Als één van de gateways 60 seconden lang geen ping ontvangt, besluit deze dat de verbinding is afgebroken en sluit de daemon af. Dit wordt gedetecteerd door VPNImpl, die hierop de AutoVPNInterface oproept om de verbinding volledig stop te zetten. Wanneer stopvpn() opgeroepen wordt, wordt de OpenVPN-daemon afgesloten (het is niet nodig om nog een controleboodschap naar de andere gateway te sturen; deze zal het beëindigen van de VPN-verbinding detecteren via het keep-alive-mechanisme). Door het afsluiten van de daemon wordt ook de routering weer hersteld. 5.6 AutoVPNInterface Figuur 5.14 toont alle klassen die gebruikt werden om de AutoVPNInterface te implementeren. Dit is enkel de klasse AutoVPNInterfaceImpl die de drie functies gespecifieerd in de interface

73 5.7 WebInterface 56 Figuur 5.14: Klassendiagram van relevante klassen voor de bundle AutoVPNInterface jason.interfaces.autovpninterface implementeert. Het openen van een verbinding wordt geïllustreerd in figuur De naam van de gateway waarmee verbinding dient gemaakt te worden wordt voorgeschoteld aan de GNS, die het IPadres van de gateway teruggeeft. Op basis van deze informatie kan de onderhandeling tussen de twee gateways van start gaan (zie 5.2.2). Als deze onderhandeling faalt, wordt de verbinding afgebroken. Is de onderhandeling gelukt, dan zal de informatie nodig om de volgende stappen tot een goed einde te brengen, opgeslagen zijn in de ConfigurationManager. Vervolgens wordt de effectieve verbinding en adresvertaling opgezet. Aan de serverkant (gateway die een aanvraag voor een onderhandeling krijgt) gebeurt dit nadat een ACK is ontvangen van de gateway die de onderhandeling begonnen is. Het afsluiten van een verbinding gaat als volgt: eerst wordt de adresvertaling teruggedraaid, daarna wordt de VPN-verbinding gesloten en als laatste wordt alle verbindingsspecifieke informatie die is opgeslagen, verwijderd. Dit wordt weergegeven in figuur WebInterface Voor de implementatie van de webinterface is gekozen voor het gebruik van servlets aangezien hier een raamwerk voor beschikbaar werd gesteld. Er werden twee verschillende servlets gemaakt, één die de gewone eindgebruiker zal gebruiken en één voor de netwerkbeheerder. Dit wordt grafisch voorgesteld in figuur 5.17.

74 5.7 WebInterface 57 Figuur 5.15: Openen verbinding met behulp van AutoVPNInterface HelperServlet De superklasse van alle servlets in dit systeem is HelperServlet. Hierin worden alle acties ondernomen die nodig zijn om een werkend geheel te krijgen, maar de eigenlijke inhoud wordt overgelaten aan de klassen die overerven van deze superklasse. De eigenlijke business logic bevindt zich dus in respectievelijk VPNServlet en JasonAdminServlet. VPNServlet De functionaliteit die een gewone eindgebruiker mag gebruiken, is bij deze servlet ondergebracht. Er kan een onderscheid gemaakt worden tussen twee soorten acties. Enerzijds kan er een verbinding opgezet worden met een gateway die vooraf door een netwerkbeheerder als vertrouwd is bestempeld. Anderzijds kunnen er veranderingen gebracht worden aan een reeds opgezette verbinding. Op dit moment is bijvoorbeeld het sluiten van een verbinding en het registreren van een client voor die verbinding geïmplementeerd. Registratie door een eindgebruiker van zijn machine zorgt ervoor dat zijn machine kan worden bereikt via een door hem gekozen naam (zie 5.8).

75 5.8 GNS 58 Figuur 5.16: Sluiten verbinding met behulp van AutoVPNInterface JasonAdminServlet De netwerkbeheerder moet in staat zijn de lokale configuratie van het systeem te veranderen. Dit kan hij doen via deze servlet. Omdat enkel de netwerkbeheerder toegang mag hebben tot deze servlet, is er een basisauthenticatie geïmplementeerd. Via deze servlet kan de netwerkbeheerder op dit moment gateways toevoegen en verwijderen uit de lijst van vertrouwde gateways. 5.8 GNS De bundle GNS wordt voor twee doeleinden gebruikt in het systeem: bij het opstarten van het systeem registreert de GNS een relatie (naam van de gateway, publieke IP-adres van de gateway) bij de GNS-Server, zodat de gateway op naam kan opgezocht worden door andere gateways. Voor bestaande verbindingen wordt de GNS ook gebruikt om relaties tussen hosts op het lokale netwerk en hun virtuele IP-adressen voor die verbinding te registeren bij de GNS-Server, zodat deze op naam kunnen opgezocht worden door hosts uit het remote netwerk. Figuur 5.18 toont een overzicht van de belangrijkste klassen in de bundle GNS.

76 5.8 GNS 59 Figuur 5.17: Klassendiagram van relevante klassen voor de bundle WebInterface Figuur 5.18: Klassendiagram van relevante klassen voor de bundlee GNS Protocol GNS Het protocol dat gebruikt wordt om deze relaties te registreren is zeer eenvoudig. De gateway maakt een SSL-verbinding aan met de GNS-Server, op poort Zowel de gateway als de GNS-Server gaan na of de certificaten die uitgewisseld worden ondertekend zijn door de CA. De GNS stuurt dan over deze verbinding de volgend informatie: IP-adres<CRLF> naam De naam kan de gatewaynaam zelf zijn (voor het registreren van een gateway), of kan een string zijn van de vorm host.gatewaynaam (voor het registreren van het virtuele IP-adres van

77 5.9 GNSServer 60 een host uit het lokale netwerk). De GNS-Server zal nagaan of de gatewaynaam overeenkomt met de naam van het certificaat Bundle startup Bij het opstarten van de bundle wordt een GNSUpdateThread opgestart. Deze thread zal het publieke IP-adres van de gateway opvragen en dit IP-adres bij de GNS-Server registeren. Daarna zal hij om de 60 seconden nagaan of het publieke IP-adres van de gateway veranderd is en indien nodig het IP-adres opnieuw registreren GNSServer De module GNSServer is geïmplementeerd als een standaard Java-applicatie, bestaande uit één klasse, GNSServer. Verder wordt er gebruik gemaakt van het open source programma BIND BIND Voor het opvragen van IP-adressen wordt gebruik gemaakt van DNS. Dit systeem is welbekend en transparant te gebruiken vanuit Java. Voor het registreren van een relatie wordt gebruik gemaakt van het protocol dat beschreven wordt in sectie Voor het DNS-gedeelte wordt gebruik gemaakt van het open source programma BIND. Het programma is geconfigureerd zodat het verantwoordelijk is voor het domein jason.org. Het is dit programma dat de DNS-query s zal resolven. Het is ook ingesteld om dynamische updates toe te laten in dit domein GNSServer De klasse GNSServer bevat een main()-methode die wacht op SSL-connecties op poort Indien een connectie opgezet wordt, wordt nagekeken of het certificaat van de andere partij ondertekend is door de CA. Daarna wordt het IP-adres en de naam (vastgelegd in het protocol) opgeslagen. De naam wordt vergeleken met de naam van het certificaat. Indien alles in orde is, wordt met de tool nsupdate (deel van de BIND-suite) de relatie toegevoegd aan het domein jason.org. Voor een gatewaynaam betekent dit dat er een relatie 2 Een wijziging van het IP-adres van de gateway heeft geen invloed op bestaande VPN-connecties. OpenVPN kan ingesteld worden om ook pakketten te aanvaarden met een onverwacht bronadres, zolang ze geauthenticeerd zijn.

78 5.9 GNSServer 61 (gatewaynaam.jason.org, IP-adres) toegevoegd is; voor een hostnaam betekent dit een relatie (hostnaam.gatewaynaam.jason.org, IP-adres).

79 TESTS EN RESULTATEN 62 Hoofdstuk 6 Tests en resultaten 6.1 Testopstelling Om het systeem te testen zijn er twee testopstellingen opgezet. Eén testopstelling bevindt zich in de gecontroleerde omgeving van de universiteit en bestaat uit twee computers die dienstdoen als gateways, één computer die dienstdoet als GNS-server, één computer die wordt gebruikt als client en een switch. Als besturingssysteem staat er op de gateways en GNS-server Debian, op de client staat een dual boot van Debian en Windows. Wanneer nodig werden laptops gereserveerd om dienst te doen als extra clients. Alle gebruikte machines zijn voorzien van een 10/100Mbps-NIC. Deze testopstelling is schematisch weergegeven in figuur 6.1. Figuur 6.1: Testopstelling in gecontroleerde omgeving.

80 6.2 Throughput 63 De tweede testopstelling bevindt zich in een meer realistische omgeving. Twee computers die met een breedbandaansluiting verbonden zijn met het internet doen hier dienst als gateways/clients. Figuur 6.2 toont deze testopstelling schematisch. Figuur 6.2: Testopstelling in realistische omgeving. 6.2 Throughput Bij deze test werd een bestand via het HTTP-protocol verstuurd van de ene client naar de andere. Op de gateways werd het verkeer onderschept (aan de ongeëncrypteerde kant) met behulp van tcpdump. Dit verkeer werd dan later geanalyseerd met Ethereal. Deze aanpak werd gekozen omdat het een realistische use-case voorstelt en omdat het TCP-protocol (gebruikt door HTTP), in het geval van één verbinding, de maximale bandbreedte zal proberen te benutten. Verwacht wordt dat door de tunneling een lagere throughput kan bereikt worden: enerzijds door de overhead van het OpenVPN-protocol, anderzijds doordat OpenVPN de pakketten niet snel genoeg kan encrypteren of decrypteren, waardoor er pakketten gedropt zullen moeten worden op de gateways. Er treedt geen extra overhead op door IP-fragmentatie. Dit zou wel kunnen voorkomen indien de extra headers ervoor zorgen dat de IP-pakketten groter zouden worden dan de Maximum Transmission Unit (MTU) voor de netwerkinterface. OpenVPN voorkomt dit probleem echter door in de SYN- en SYN/ACK-pakketten die verstuurd worden bij het opzetten van de TCPverbinding, de optie Maximum Segment Size (MSS) te verlagen, zodat rekening wordt gehouden met de OpenVPN-headers. Uit de beschrijving van het OpenVPN-protocol in sectie kan berekend worden wat de overhead is die geïntroduceerd wordt door het gebruik van OpenVPN. In beide opstellingen werd gebruik gemaakt van Blowfish-encryptie in Cipher Block Chaining (CBC) modus. Aangezien Blowfish werkt in blokken van 8 bytes, kan berekend worden dat de totale overhead van OpenVPN-headers 69 tot 76 bytes is (er kunnen tot 7 bytes padding nodig zijn).

81 6.3 Delay 64 Tabel 6.1 geeft een overzicht van de gemiddelde throughput in het geval het systeem niet gebruikt wordt, in het geval enkel een VPN-verbinding is opgezet en in het geval zowel een VPN-verbinding als adresvertaling actief zijn. Tabel 6.1: Throughput zonder VPN VPN + adresvertaling lab 58,521 Mbps 19,305 Mbps 20,735 Mbps thuis 472,376 kbps 457,288 kbps 456,560 kbps In de testopstelling in het lab is duidelijk een serieuze vermindering in throughput merkbaar. De bottleneck is hier duidelijk de processorkracht van de gateways: deze zijn niet in staat de pakketten tijdig te encrypteren en decrypteren. In de thuistestopstelling is de vermindering in throughput veel kleiner: er is slechts een vermindering van ongeveer 3% bij de gevallen met VPN. Doordat de ISP s de uploadbandbreedte laag houden, is er minder processorkracht nodig en wordt de overhead enkel veroorzaakt door de OpenVPN-headers. Figuren 6.3 en 6.4 geven ten slotte de throughput weer als functie van de tijd. In de testopstelling in het lab zijn op een paar punten dipjes te zien: deze komen overeen met een sleutelonderhandeling door het OpenVPN-protocol (deze sleutelonderhandeling werd ingesteld om om de 60 seconden op te treden). 6.3 Delay Voor het berekenen van de delay werd gebruik gemaakt van de tool ping, die de roundtrip-time (RTT) meet tussen twee toestellen, gebruik makende van ICMP echo-requests. Tabel 6.2 toont de RTT s (in ms) gemeten in de testopstelling in het lab (uitgemiddeld over 20 ping s): Tabel 6.2: RTT (in ms) bij de testopstelling in het lab zonder VPN VPN + Adresvertaling 0,3 0,8 0,8

82 6.3 Delay 65 (a) Throughput zonder systeem (b) Throughput met VPN (c) Throughput met VPN en adresvertaling Figuur 6.3: Throughput bij de testopstelling in het lab (in bytes/s) Uit deze tabel blijkt dat de RTT met 0.5 ms verhoogd wordt indien de VPN gebruikt wordt. De RTT verhoogt echter niet indien ook adresvertaling gebruikt wordt. Dit ligt in de lijn van verwachtingen: de encryptie die de VPN uitvoert is processorintensief en zorgt dus voor vertraging. De adresvertaling is relatief eenvoudig en wordt in de kernel uitgevoerd; de extra vertraging die hierdoor optreedt is relatief klein. Tabel 6.3 geeft de resultaten met de thuistestopstelling weer. Uit deze tabel zou men kunnen afleiden dat de vertraging geïntroduceerd door de VPN veel groter is dan in het lab, alhoewel ze werd uitgevoerd door PC s met meer rekenkracht. Er bleken echter grote uitschieters te zitten in de metingen, waarna ook de standaardafwijking op de metingen is berekend. Aangezien de standaardafwijking zo groot is, is het moeilijk om uitspraken te doen over de vertraging in dit geval. Waarschijnlijk is het zo dat de tussenliggende

83 6.4 Pakketverlies 66 (a) Throughput zonder systeem (b) Throughput met VPN (c) Throughput met VPN en adresvertaling Figuur 6.4: Throughput bij de thuistestopstelling (in bytes/s) Tabel 6.3: RTT (in ms) bij de thuistestopstelling zonder VPN VPN + Adresvertaling meetwaarde 21,379 24,714 25,610 standaardafwijking 3,191 2,351 4,212 routers verschillende prioriteiten geven aan ICMP- en UDP-pakketten. 6.4 Pakketverlies Om het pakketverlies dat mogelijkerwijze optreedt te meten, werd gebruikt gemaakt van IPerf (zie [32]). Allereerst werden er tests gedaan met de testopstelling in het lab. Er werden twee clients gebruikt voor deze tests, één die dienstdeed als IPerf-server om verbindingen aan te nemen en een andere als IPerf-client. Beide clients bevinden zich logischerwijze in het netwerk van een verschillende gateway zoals weergegeven in figuur 6.5. Voor deze tests werd een UDP-stroom van een opgegeven bandbreedte verstuurd van client

84 6.4 Pakketverlies 67 Figuur 6.5: Testopstelling voor meten pakketverlies naar server. Elk van de UDP-pakketten bevatte 1470 bytes data. Zonder VPN-verbinding of adresvertaling is er nooit pakketverlies op de gateways, zelfs als we meer dan 100 Mbps proberen te versturen. Indien we de test uitvoeren met dezelfde machine zoals gebruikt bij de tests in 6.2 wordt een stroom van 75Mbps verstuurd. Testen we echter met een andere machine, wordt een snelheid van 93Mbps gehaald. Dit laat vermoeden dat een 100Mbps-NIC niet altijd exact 100Mbps aankan, alle pakketten die verstuurd worden komen ook effectief aan, maar de netwerkkaart kan niet snel genoeg pakketten versturen om de gewenste throughput te halen. Wanneer een VPN-verbinding tussen de gateways is opgezet, begint er reeds pakketverlies op te treden vanaf een pakketstroom van 33Mbps. Dit is waarschijnlijk het gevolg van het droppen van pakketten omdat de netwerkbuffer niet snel genoeg kan verwerkt worden door de vertraging die de berekeningen van OpenVPN met zich meebrengen. Wanneer naast de VPN-verbinding gebruik gemaakt wordt van adresvertaling treedt er eveneens pakketverlies op vanaf een stroom van 33 Mbps. Adresvertaling blijkt dus geen invloed te hebben op het percentage pakketverlies. De introductie van pakketverlies vanaf 33Mbps kan op zijn minst ongewenst worden genoemd, maar om te testen of dit invloed heeft op de werking van het systeem in een realistische omgeving (een symmetrische upload/downloadbeperking van 100 Mbps is allesbehalve realistisch te noemen voor thuisgebruik) werden de tests opnieuw gedaan op de testopstelling zoals getoond in figuur 6.2. De machine waarop de IPerf-client draait, is verbonden met het internet door een ADSL-verbinding met een uploadbeperking van 512 Kbps. Figuur 6.6 toont de resultaten met gebruik van UDP-pakketten met een payload van 1470 bytes. Zonder VPN-verbinding treedt er bij kleine bandbreedte geen pakketverlies op. Wanneer de uploadbeperking van 512 kbps naderbij komt, begint er pakketverlies op te treden, meer bepaald vanaf ongeveer 400 kbps.

85 6.4 Pakketverlies 68 Figuur 6.6: Pakketverlies bij gebruik van UDP-datagrammen van 1470 bytes Het percentage pakketverlies dat optreedt wanneer er een VPN-verbinding tussen beide machines is opgezet is merkbaar hoger. Het is zelfs zo dat zelfs bij kleine bandbreedtes pakketverlies optreedt. Vermoedelijk is dit het geval omdat door de overhead die OpenVPN introduceert, de UDP-pakketten gefragmenteerd raken, waardoor er meer kans is dat een pakket verloren raakt. Dit kan eevnwel niet de enige oorzaak zijn, vermoedelijk worden op het internet gefragmenteerde (UDP-)pakketten behandeld met een lagere prioriteit. Adresvertaling blijkt ook in de realistische omgeving nauwelijks effect te hebben. Figuur 6.7: Vergelijking pakketverlies tussen situatie met UDP-datagrammen van 1470 bytes ten opzichte van UDP-datagrammen van 1000 bytes

86 6.5 Jitter 69 Om te testen of de fragmentatie van de UDP-pakketten tot effect heeft dat er altijd pakketten verloren gaan, werden bijkomende tests uitgevoerd met UDP-pakketten met een payload van 1000 bytes. Hierdoor zullen de pakketten niet gefragmenteerd worden. Anderzijds is het wel zo dat om dezelfde bandbreedte te halen er meer pakketten zullen moeten verstuurd worden. In figuur 6.7 worden de resultaten van beide tests naast elkaar gezet. Het is duidelijk dat de fragmentatie een grote rol speelt in het al dan niet optreden van pakketverlies. Wanneer er geen fragmentatie optreedt, is er tot ongeveer 350 kbps geen pakketverlies en wordt het percentage pakketverlies bij hogere bandbreedtes zo goed als gehalveerd. Zolang applicaties die UDP gebruiken hun pakketten niet volledig vullen, zal die applicatie dus geen hinder ondervinden van pakketverlies. Wanneer een applicatie volle UDP-pakketten verstuurt, zal de verbinding niet geheel transparant zijn, er treedt namelijk sowieso pakketverlies op terwijl dit niet zo is zonder deze verbinding. 6.5 Jitter Voor sommige applicaties kan het verschil in doorzendtijden tussen opeenvolgende pakketten, genaamd jitter, een belangrijke invloed hebben. Denk hierbij bijvoorbeeld aan een videostroom. Om te testen of het systeem een invloed heeft op de jitter werden voor verschillende gevallen metingen gedaan met behulp van IPerf. Er werden enkel resultaten gemeten voor die bandbreedtes waarvoor in alle gevallen een aanvaardbaar percentage pakketverlies optreedt. Wanneer er te veel pakketverlies optreedt, zal die voor de besproken applicaties grotere gevolgen hebben dan jitter. Een andere reden waarom enkel voor zulke bandbreedtes jitter werd gemeten, zijn de onbetrouwbare resultaten die IPerf oplevert voor jitter wanneer er pakketverlies optreedt. Het verschil tussen de doorzendtijden van twee opeenvolgende pakketten kan niet exact berekend worden als één van deze pakketten verloren gaat. IPerf meet de jitter zoals gespecifieerd in de RFC voor het Real-time Transport Protocol (RTP: zie [33]). Voor elk pakket wordt de doorzendtijd berekend als het verschil tussen de RTP-timestamp van het pakket (ingevuld door de client) en de aankomsttijd op de server. De jitter wordt dan berekend als het gemiddelde van de verschillen in doorzendtijden van opeenvolgende pakketten. Er wordt echter niet gesproken over wat er gebeurt wanneer pakketten verloren gaan. De resultaten worden grafisch weergegeven in figuur 6.8. Er zit geen duidelijke lijn in de meetwaarden: jitter gemeten bij de rechtstreekse verbinding is niet consequent minder dan in het geval er enige vorm van VPN is opgezet. Het is zelfs zo dat voor een bandbreedte van 350

87 6.5 Jitter 70 Figuur 6.8: Jitter kbps bij de rechtstreekse verbinding een jitter gemeten wordt die tot vijfmaal zo hoog is als bij de gevallen met VPN. Binnen de gevallen waarbij een VPN-verbinding opgezet is, valt er evenmin een logica te vinden. Bij 100 kbps met adresvertaling is de jitter ongeveer dubbel zo groot als zonder adresvertaling, maar voor 200 kbps is dit dan weer minder dan een vierde. De enige conclusie die kan genomen worden is dat het tussenliggende netwerk meer invloed heeft op de aanwezige jitter dan de situatie op de gateways.