VPN (Virtual Private Network) jest prywatną siecią, która używa publicznej sieci, najczęściej Internetu, do łączenia zdalnych punktów i użytkowników. Oprócz wykorzystywania dedykowanych połączeń, VPN stosują połączenia internetowe przebiegające od sieci prywatnej lub korporacyjnej do punktu zdalnego albo zdalnego użytkownika.
Istnieją dwa typy sieci VPN:
Remote-Access, czyli zdalny dostęp, nazywana także VPDN (Virtual Private Dial-up Network). Łączy ona użytkownika z siecią lokalną. Ten typ sieci jest szczególnie użyteczny dla przedsiębiorstw, które mają zdalnych, często przemieszczających się pracowników, np. duża firma rozsyłająca po kraju wielu przedstawicieli handlowych. Przedsiębiorstwo, które chce zaimplementować VPN typu Remote-Access na większą skalę, zwraca się z prośbą do ESP (Enterprise Service Provider). ESP zarządza NAS (Network Access Server) i zaopatruje zdalnych użytkowników w oprogramowanie klient. W ten sposób tworzy się bezpieczne, szyfrowane połączenie między prywatną siecią firmową a zdalnymi użytkownikami za pośrednictwem niezależnego operatora.
Dzięki zastosowaniu zaawansowanych technik szyfrowania oraz specjalnego, dedykowanego sprzętu firma może połączyć wiele swoich rozproszonych punktów, a właściwie sieci lokalnych, za pośrednictwem sieci publicznej. Ten typ VPN dzieli się na dwa podtypy, oparte na: intranecie i ekstranecie. O sieci typu pierwszego mówi się zazwyczaj wtedy, gdy przedsiębiorstwo ma centralę i jeden lub kilka punktów zdalnych, które chce połączyć. Intranetowa VPN łączy sieć lokalną centrali z siecią lokalną punktu zdalnego. Natomiast sieci wirtualne z wykorzystaniem ekstranetu stosuje się z powodzeniem wtedy, kiedy przedsiębiorstwo zachowuje silne związki ze swoim podwykonawcą, klientem lub łączą je innego typu mocne więzi z jakimś innym przedsiębiorstwem. Dzięki połączeniu sieci lokalnych obydwu firm przedsiębiorstwa mogą pracować we współużytkowanym środowisku.
W zależności od typu VPN – Remote-Access lub Site-to-Site – użytkownik będzie potrzebował pewnych urządzeń oraz oprogramowania, niezbędnych do zbudowania sieci VPN. Oto one:
W VPN przewidziano kilka metod zabezpieczenia danych:
IDEA jest zbliżony do algorytmu DES, lecz jego programowe implementacje są szybsze. Do szyfrowania jawnych bloków danych o długości 64 bitów IDEA używa klucza 128-bitowego. Algorytm dzieli te bloki na cztery 16-bitowe podbloki, a iteracje, których jest 8, tworzą z nich kolejno również cztery 16-bitowe podbloki, które po ostatniej iteracji są łączone w 64-bitowy blok zaszyfrowany. Iteracja w IDEA jest jak gdyby podwójną iteracją DES. IDEA jest algorytmem, który z założenia jest łatwy w realizacji sprzętowej i programowej, ale został opatentowany i na użytkowanie komercyjne potrzebna jest licencja. Dwa powielane moduły, które składają się na jego strukturę, ułatwiają scalanie w technologii VLSI.
Wiele sieci VPN opiera się na tunelowaniu w Internecie. Tunelowanie jest procesem umieszczania całego pakietu w innym pakiecie i wysyłania go przez sieć. W procesie tunelowania biorą udział trzy rodzaje protokołów:
Tunelowanie ma ważne następstwa dla VPN. Przykładowo: użytkownik może umieścić pakiet używający protokołu nie wspierającego Internetu, np. NetBEUI, wewnątrz pakietu IP i przesyłać go bezpiecznie przez Internet.
W konfiguracji dwupunktowej stosuje się protokół kapsułkowania GRE (Generic Routing Encapsulation).
Określono w nim sposób przygotowania do transportu protokołu oryginalnego za pośrednictwem protokołu transportowego, którym jest typowo protokół na bazie IP. Zawiera on informację o typie kapsułkowanego pakietu oraz informacja o połączeniu między klientem a serwerem. Oprócz GRE w trybie tunelowym czasem używa się IPSec do kapsułkowania pakietów. IPSec sprawdza się dobrze w obydwu typach sieci VPN – Remote-Access i Site-to-Site.
Do protokołów używanych przez VPN zdalnego dostępu i opartych na strukturze PPP należą:
IPSec Working Group IETF zdefiniowała protokół IPSec (IP Security), który ma dwa tryby szyfrowania: tunelowy i transportowy. W pierwszym z nich szyfruje się nagłówek i ładunek każdego z pakietów, natomiast w drugim tylko ładunek. Wszystkie urządzenia muszą używać wspólnego klucza, a zapory ogniowe muszą mieć ustanowione podobne polityki bezpieczeństwa. IPSec może szyfrować dane między różnymi urządzeniami, takimi jak np. dwa rutery, ruter i zapora ogniowa czy komputer osobisty i ruter.
IPSec opiera się na trzech protokołach:
AH zapewnia uwierzytelnienie integralności i pochodzenia danych. Integralność danych jest zapewniona poprzez sumę kontrolną generowaną przez kod identyfikacyjny wiadomości. Natomiast sprawdzenie oryginalności danych dokonuje się poprzez zamieszczenie tajnego, współdzielonego klucza w danych przeznaczonych do identyfikowania.
AH może być aplikowany zarówno w trybie tunelowym, jak i w trybie transportowym. AH może być stosowany samodzielnie lub w połączeniu z ESP. W takiej kombinacji identyfikacja może być zapewniona między parą komputerów, zapór ogniowych lub między komputerem a zaporą.
ESP zapewnia poufność danych dzięki szyfrowaniu. Może także opcjonalnie zapewnić uwierzytelnienie pochodzenia danych, sprawdzanie integralności i replay protection. Porównując ESP do AH, widać, że tylko ten pierwszy dostarcza szyfrowania, natomiast obydwa zapewniają identyfikację, sprawdzenie integralności i replay protection. Szyfrowanie ESP stosuje symetryczny współdzielony klucz, tzn. jest on współużytkowany przy szyfrowaniu i deszyfrowaniu danych. Kiedy używa się funkcji identyfikujących ESP, wtedy stosuje się takie same algorytmy HMAC, czyli HMAC-MD5 lub HMAC-SHA, jak w AH.
Tryb transportowy jest zazwyczaj używany między punktami końcowymi połączenia. Przykładowo, jeżeli na ścieżce komunikacyjnej wzdłuż wszystkich elementów pomiędzy serwerem a klientem wymaga się bezpiecznej komunikacji, klient i serwer użyją trybu transportowego IPSec.
Natomiast tryb tunelowy stosuje się między dwoma urządzeniami w sytuacji, kiedy przynajmniej jedno z nich nie jest punktem końcowym połączenia – na przykład kiedy wymaga się bezpiecznego połączenia między dwiema zaporami ogniowymi ulokowanymi między klientem a serwerem, to obydwie zapory ogniowe w komunikacji między sobą użyją trybu tunelowego IPSec.
ISAKMP definiuje standardową strukturę negocjowania SA, inicjującego generowanie wszystkich kluczy kryptograficznych i póeniejszego odświeżania tych kluczy. Oakley jest obowiązkowym protokołem zarządzania kluczem używanym w strukturze ISAKMP. Protokół ISAKMP wspiera zautomatyzowane negocjowanie SA oraz automatyczne generowanie i odświeżanie kluczy kryptograficznych.
Serwery AAA (Authentication, Authorization i Accounting) są stosowane wtedy, kiedy wymaga się wyższego poziomu zabezpieczenia dostępu w środowisku typu Remote-Access. Kiedy przychodzi żądanie dotyczące sesji z dial-up klienta, żądanie to jest przekazywane do serwera AAA. Serwer ten sprawdza, kim jest użytkownik (Authentication), co mu wolno robić (Authorization) i co obecnie robi (Accounting).
Innym sposobem tworzenia sieci wirtualnych jest jednoczesne wykorzystanie protokołów BGP i MPLS. VPN oparte na BGP/MPLS zostały opisane w RFC 2547. Jest już zdefiniowany mechanizm umożliwiający dostawcom usług wykorzystanie własnych szkieletowych sieci IP jako fundamentu pod budowę VPN dla klientów. Metodę opisaną w RFC 2547 nazywa się często BGP/MPLS VPN, ponieważ BGP jest używany do dystrybucji informacji o wyborze trasy VPN w sieci szkieletowej dostawcy, a MPLS jest odpowiedzialny za przesyłanie ruchu między punktami VPN.
Zręby koncepcji tworzenia prywatnych sieci wirtualnych opartych na BGP i MPLS można ująć zwięźle, w kilku zdaniach. Ich nadrzędnym celem jest zaoferowanie klientom bardzo prostych usług nawet wtedy, kiedy nie mają doświadczenia w trasowaniu IP. Drugim istotnym celem jest sprawienie, żeby te usługi odznaczały się skalowalnością i ułatwiały szeroką implementację. Ponadto reguły, które są używane do tworzenia VPN, mogą być implementowane samodzielnie przez usługodawcę lub przy współpracy z klientem. Wreszcie na koniec – dobrana metodyka powinna zapewnić dostarczenie usług z wartością dodaną, wzmacniających więzy z klientem.
W rozumieniu RFC 2547 VPN jest zbiorem reguł. To właśnie polityki są odpowiedzialne za spójność wielu punktów. Punkt klienta jest dołączany do sieci dostawcy usług za pomocą jednego lub wielu portów. Dostawca usług kojarzy każdy port z tablicą trasowania VPN. W terminologii RFC 2547 (i RFC 2547bis) tablica trasowania VPN jest nazwana VRF (VPN Routing and Forwarding).
Urządzenia tego typu zapewniają klientowi dostęp do sieci dostawcy usług sieciowych za pośrednictwem łączy do jednego lub kilku ruterów znajdujących się na brzegu sieci operatora. W słownictwie anglosaskim sprzęt ten jest czasem oznaczany jako CE (Customer Edge). Typowo na brzegu sieci klienta powinien być zainstalowany ruter IP, który komunikuje się bezpośrednio z ruterami operatora, chociaż czasem może to być przełącznik warstwy drugiej. Po ustaleniu komunikacji ruter brzegowy klienta ogłasza (reklamuje) trakty VPN punktu lokalnego ruterowi brzegowemu dostawcy, a następnie uczy się zdalnych traktów VPN pochodzących od zdalnego rutera brzegowego operatora.
Rutery brzegowe operatora, nazywane też PE (Provider Edge), wymieniają informacje z ruterami klienta, używając statycznego trasowania, protokołu RIP 2, OSPF lub EBGP (External BGP peering). Ruter znajdujący się na brzegu sieci operatora wspiera informacje o wyborze trasy dotyczące ścieżek VPN dla tych sieci wirtualnych, do których jest on bezpośrednio dołączony. Taka konstrukcja poprawia skalowalność modelu RFC 2547, ponieważ eliminuje konieczność wsparcia przez rutery brzegowe dostawcy usług wszystkich traktów VPN tego dostawcy.
Każdy ruter na brzegu sieci operatora wspiera VRF dla każdego z połączonych punktów. Każdy typ połączenia klienta, jak na przykład PVC Frame Relay, PVC ATM i VLAN, jest odwzorowywany w specyficznym VRF. W ten sposób to ruter operatora, a nie punkt jest skojarzony z tablicą VRF. Jak wiadomo, z jedną VRF może być skojarzonych wiele portów rutera brzegowego dostawcy. To jest cecha ruterów, która pozwala na tworzenie wielu tablic trasowania wspierających segregowanie informacji o wyborze trasy w VPN.
Ruter brzegowy operatora, po nauczeniu się lokalnych ścieżek VPN od ruterów brzegowych klienta, wymienia informacje o wyborze trasy VPN z innym takim ruterem, używając IBGP (Internal BGP, RFC 1966 i 2796). Kiedy stosuje się MPLS do wysyłania strumienia danych VPN przez sieć szkieletową dostawcy, wejście rutera brzegowego operatora funkcjonuje jak wejście etykietującego przełącznika trasującego LSR (Label Switch Router) i analogicznie, wyjście takiego rutera zachowuje się jak wyjście etykietującego przełącznika trasującego.
Urządzeniem takim może być dowolny ruter w sieci dostawcy, który nie jest połączony z ruterem brzegowym klienta. Taki ruter funkcjonuje jak tranzytowy etykietujący przełącznik trasujący MPLS, kiedy przesyła strumień danych między brzegowymi ruterami. Ponieważ ruch jest przesyłany w szkielecie MPLS z użyciem dwuwarstwowego stosu etykiet, ruter szkieletowy jest zobligowany do wsparcia jedynie dróg do operatorskich ruterów brzegowych. Natomiast nie musi on wspierać informacji o wyborze drogi specyficznych dla każdego punktu klienta.
W sieciach wirtualnych opartych na BGP/MPLS wykorzystuje się dwa podstawowe rodzaje ruchu:
Taka topologia widnieje na rysunku obok. Jeden operator dostarcza tu usługi VPN oparte na BGP/MPLS różnym klientom instytucjonalnym. W sieci znajdują się dwa rutery brzegowe dostawcy usług, które są połączone z czterema różnymi punktami należącymi do klientów. Ustanowione w tym przykładzie polityki można scharakteryzować krótko: dowolny komputer z pierwszego punktu może się komunikować z dowolnym komputerem z drugiego punktu. I odwrotnie. Podobne relacje zachodzą między dwoma pozostałymi punktami.
W VPN BGP/MPLS przepływ sterowania składa się z dwu podstrumieni. Pierwszy odpowiada za wymianę informacji o wyborze drogi między ruterami brzegowymi klienta i operatora, a także pomiędzy ruterami brzegowymi operatora. Natomiast drugi jest odpowiedzialny za ustanawianie LSP w szkielecie sieci operatora między jego ruterami brzegowymi.
Ruter brzegowy, oznaczony na rysunku numerem 1, został skonfigurowany w taki sposób, aby skojarzyć VRF, oznaczony kolorem czerwonym, z interfejsem lub podinterfejsem, przez który uczy się tras od rutera brzegowego klienta. Kiedy ruter klienta poszukuje drogi dla prefiksu 10.1/16 do rutera brzegowego operatora, urządzenie dostawcy zapisuje lokalną drogę do 10.1/16 w czerwonym VRF.
Ruter 1 z brzegu sieci dostawcy szuka drogi dla 10.1/16 do rutera 2, używając IBGP (Internal BGB). Przed rozpoczęciem poszukiwania ruter brzegowy 1 wybiera etykietę MPLS, w tym przypadku 222, po to, aby wyszukać drogę i przypisać swój adres zwrotny jako następny przeskok BGP dla danej drogi. Prywatne adresowanie zostało zdefiniowano w RFC 1918. W RFC 2547bis uwzględniono: nachodzące na siebie przestrzenie adresowe przez użycie swego rodzaju wyróżników dróg RD (Route Distinguisher) i rodzinę adresów VPN-IPv4.
RFC 2547bis ogranicza dystrybucję informacji o wyborze tras między ruterami brzegowymi operatora, używając filtrowania tras opartego na rozszerzonych atrybutach środowiska BGP.
Kiedy ruter brzegowy 2 operatora wysyła odpowiede do urządzenia pierwszego, to określa, czy powinno się zapisać drogę do prefiksu 10.1/16 w czerwonym VRF przez wykonanie filtrowania opartego na wspomnianych już atrybutach BGP. Gdyby ruter 2 zdecydował się zapisać drogę w czerwonym VRF, wtedy pokaże drogę z prefiksem 10.1/16 ruterowi brzegowemu nr 2 klienta.
Aby zastosować MPLS do przesłania ruchu VPN w sieci szkieletowej dostawcy między ruterami brzegowymi operatora, które uczą się dróg, a ruterem, który ogłasza drogę, musi zostać ustalona ścieżka LSP. Proces ten został zilustrowany na rysunku 329.
LSP – etykietowana przełączana ścieżka – może zostać ustanowiona, a następnie utrzymywana w sieci dostawcy usług przy użyciu protokołów LDP (Label Distribution Protocol) lub RSVP (Resource ReSerVation Protocol). Etykietowana przełączana ścieżka będzie dla prostoty nazywana dalej ścieżką etykietowaną. Operator używa LDP wtedy, kiedy chce ustanowić transmisję typu best-effort LSP między swoimi dwoma ruterami brzegowymi. W tym przypadku ścieżka etykietowana przebiega tą samą drogą co ruch best-effort. Natomiast RSVP używa się w sytuacji, kiedy dostawca chce przypisać pasmo ścieżce lub używa traffic enineering do wybrania ścieżki dla LSP. Ścieżki etykietowane tworzone na podstawie protokołu RSVP wspierają gwarancje jakości usług QoS.
Niezbędne minimum dla zapewnienia kompatybilność między różnymi dostawcami usług można określić krótko: zarówno rutery brzegowe, jak i szkieletowe muszą przynajmniej wspierać LDP. Gdyby dostawca zdecydował się na użycie LDP, wtedy w sieci szkieletowej zostanie stworzona pełna siatka best-effort etykietowanych ścieżek. Dzięki temu wspiera się spójność połączeń między ruterami brzegowymi.
Etykietowane ścieżki tworzone na fundamencie RSVP maja wyższy priorytet niż utworzone za pośrednictwem LDP. Ścieżki obydwu rodzajów funkcjonują między parą ruterów brzegowych, jednak wejście etykietującego rutera przełączającego LSR (Label Switching Router) wybiera etykietowaną ścieżkę opartą na RSVP zamiast na LDP. Może być jedna ścieżka etykietowana bąde kilka równoległych. Route Reflektor działa jak serwer, który „odbija” trasy z wejścia rutera brzegowego do wyjść ruterów brzegowych. Jeśli dostawca usług używa tego „reflektora”, wtedy musi stale ustanawiać ścieżki etykietowane między brzegowymi ruterami, gdyż reflektory nie są niezbędną częścią ścieżki tranzytowej między ruterami brzegowymi. W każdym przypadku chodzi oczywiście o rutery dostawcy usług.
Komputer o adresie 10.2.3.4 (rysunek 329) wysyła wszystkie pakiety zawierające dane dla serwera 10.1.2.8 do swoje domyślnej bramy. Kiedy pakiet dotrze do rutera brzegowego klienta, to wyśle on pakiet IPv4 do rutera brzegowego operatora.
Ruter nr 2 otrzymuje pakiet, przegląda czerwony VRF i uzyskuje następujące informacje:
Ruch użytkownika jest kierowany z pierwszego rutera brzegowego do drugiego przy użyciu pliku etykiet MPLS składającego się z dwu etykiet. Przed transmitowaniem pakietu drugi ruter brzegowy „wkłada” etykietę 222 do pliku etykiet, która staje się etykietą wewnętrzną. Ta etykieta jest początkowo zapisywana w czerwonym VRF, kiedy brzegowy ruter nr 2 otrzymuje ogłoszenie IBGP o trasie pierwszego rutera brzegowego do 10.1/16. Następnie ruter brzegowy nr 2 układa etykietę związaną z LDP na stos etykiet, czyniąc z niej etykietę zewnętrzną (szczytową).
Po utworzeniu pliku etykiet ruter brzegowy nr 2 wysyła pakiet MPLS do pierwszego rutera szkieletowego w sieci operatora zgodnie z LSP między dwoma wymienionymi ruterami brzegowymi. Rutery dostawcy przełączają pakiety poprzez rdzeń sieci szkieletowej dostawcy opartej na etykiecie zewnętrznej.
Kiedy ruter brzegowy nr 1 otrzymuje pakiet, zdejmuje ze stosu etykietę, tworząc pakiet IPv4. Ruter ten używa wewnętrznej etykiety (222) do zidentyfikowania bezpośrednio połączonego rutera brzegowego klienta, który będzie obiektem następnego skoku, do 10.1/16. W końcu ruter brzegowy nr 1 wysyła pakiet IPv4 do rutera brzegowego klienta, który wysyła pakiet do serwera 10.1.3.8 w punkcie 1.
Najważniejszym celem sieci VPN opartych na BGP/MPLS jest uproszczenia operacji sieciowych, dzięki czemu stają się atrakcyjne dla klienta. Dostawcy usług sieciowych mogą zaoferować skalowalne usługi z wartością dodaną.
Spośród wielu zalet tych sieci do najistotniejszych można zaliczyć:
Pod pojęciem telekomunikacyjnej sieci wirtualnej VPN rozumie się sieć opartą na publicznej infrastrukturze Frame Relay lub ATM. Jest to alternatywne (i lepsze) rozwiązanie w stosunku do sieci prywatnej z łączami dzierżawionymi. Odpowiada ono modelowi sieci VPN opartej na warstwie drugiej (L2VPN). Ostatnio popularność zyskuje koncepcja intranetu, gdzie tworzy się prywatne sieci rozległe z wykorzystaniem rozwiązań stosowanych w sieci Internet. Architektura typowej sieci intranetowej zawiera rutery i przełączniki odpowiadające głównie urządzeniom warstwy 3 lub 2 modelu komunikacyjnego ISO/OSI.
Zadaniem ruterów jest szeroko rozumiane zarządzanie ruchem pakietów w sieci (kierowanie przepływem, zarządzanie trafikiem i przepływnością, realizacja funkcji bezpieczeństwa), natomiast zadaniem urządzeń warstwy 2 jest transport pakietów między ruterami w sposób najbardziej efektywny (gwarantowanie odpowiedniej przepływności). W tradycyjnej sieci internetowej realizacja sieci VPN była utrudniona z powodu braku odpowiednich mechanizmów gwarantujących wymaganą przez użytkownika jakość obsługi QoS (Quality of Service).
Opracowane w ostatnich latach nowe mechanizmy trasowania w sieciach IP – gwarantujące właściwą jakość obsługi, zarządzanie pojemnością i zasobami sieci, sterowanie dostępem do sieci oraz właściwe zabezpieczenie przed niepowołanym dostępem do zasobów internetowych – stały się podstawą rozwoju sieci wirtualnych IP VPN, czyli sieci rozległych (bez ograniczeń odległościowych) opartych na protokole IP.
Ich rozwój wynika z korzyści, jakie zaczęły oferować współczesne sieci IP VPN:
Sieć IP VPN winna dobrze zabezpieczać przed niepowołanym dostępem do zasobów, zapewniać wymaganą jakość obsługi oraz umożliwiać zintegrowane zarządzanie. Wyróżnia się sześć podstawowych obszarów związanych z tworzeniem sieci IP VPN:
Zasadniczym celem współczesnych sieci IP VPN jest zapewnienie prywatności i bezpieczeństwa przekazów transportowanych przez sieci publiczne. Wysokie wymagania bezpieczeństwa transportu spełnia mechanizm tunelowania pakietów przez sieć, połączony z szyfrowaniem danych. Tunelowanie pozwala na odwzorowanie połączeń punkt–punkt (odpowiedników kanałów wirtualnych) w środowisku sieci bezpołączeniowej, umożliwiając realizację zaawansowanych funkcji szyfrowania danych. Stosowanie tuneli zapewnia szyfrowanie całych pakietów IP łącznie z ich nagłówkami, co jest niezmiernie ważne, gdyż uniemożliwia identyfikację nadawcy i odbiorcy informacji niepowołanym użytkownikom sieci.
Telekomunikacyjne sieci wirtualne IP VPN używają wielu mechanizmów bezpieczeństwa transportu danych, takich jak: bezpieczny protokół IPsec (IP Security), protokół tunelowania L2TP i protokół L2F dla warstwy drugiej modelu, protokół GRE (Generic Routing Encapsulation) obsługujący tunele IP, a także zaawansowane techniki szyfrowania danych oparte na standardach symetrycznego DES (Data Encryption Standard), rozszerzonego DESX i potrójnego szyfrowania 3DES (Triple DES).
Ze względu na sposób użytkowania wyróżnia się trzy rodzaje telekomunikacyjnych sieci IP VPN: dostępowe, intranetowe i ekstranetowe.
Sieci dostępowe IP VPN umożliwiają rozszerzenie zakresu sieci prywatnej za pomocą sieci publicznej – zapewniając dostęp użytkownikom oddalonym, ruchomym, jak też odległym oddziałom firmy. Dzięki wykorzystaniu współdzielonej infrastruktury sieci operatora publicznego znacznie obniża się koszt budowy sieci dostępowej. Stosowana w tych rozwiązaniach funkcja roamingu umożliwia łączenie sieci dostępowych o zróżnicowanych rodowodach. Dla bezpieczeństwa informacji tworzy się tunele kanału danych.
Wirtualne sieci intranetowe IP VPN są alternatywą tworzenia prywatnych sieci rozległych WAN. Ich funkcjonowanie, oparte na architekturze intranetów, zakłada korzystanie ze współdzielonej infrastruktury sieciowej, udostępnianej przez operatorów publicznych z wykorzystaniem technologii IP, Frame Relay lub ATM. Do tworzenia bezpiecznych tuneli przenoszących trafik korporacyjny w sieci intranetu są używane mechanizmy IPSec oraz GRE. Najtańszym sposobem budowy intranetowej sieci VPN jest wykorzystanie do tego celu tradycyjnej sieci Internet, doposażonej w mechanizm etykietowanego przełączania wieloprotokołowego MPLS (Multiprotocol Label Switching).
Sieci ekstranetowe IP VPN – opierające się na protokołach z rodziny TCP/IP – tworzy się do łączenia korporacji z ważniejszymi klientami firmy, firmami współpracującymi czy najważniejszymi dostawcami korporacji. Sieci ekstranetowe IP VPN działają na takich samych zasadach jak sieci intranet VPN, a więc korzystają z opracowanych na przestrzeni ostatnich dwóch lat strategii skalowania rozwiązań sieciowych (przełączanie wielowarstwowe, przełączanie wieloprotokołowe, protokoły MPLS czy najnowszego MPlS opracowanego dla sieci optycznych).
Idea SSL VPN opiera się na prostej zasadzie: wykorzystaniu mechanizmów szyfrowania i uwierzytelniania, wbudowanych w przeglądarkę internetową. W odróżnieniu od IPSec VPN użytkownik otrzymuje dostęp nie do całej sieci, a tylko do wybranych jej zasobów.
Jedną z zasadniczych różnic pomiędzy sieciami zdalnego dostępu VPN, opartymi na IP Security, a SSL jest to, że te pierwsze wymagają instalacji i konfiguracji oprogramowania klienckiego w systemie zdalnego użytkownika, podczas gdy SSL VPN korzysta jedynie z przeglądarki webowej. Chociaż SSL może być wykorzystywany zarówno w połączeniach HTTP, FTP, SMTP, jak i telnet, to standardowo jest on wbudowany tylko w przeglądarkach HTTP. Wywoływane jest połączenie HTTPS (Hypertext Transfer Protocol over Secure Socket Layer - RFC 2818). Dodatkowo, do połączeń SSL VPN klient standardowo potrzebuje otwartego portu TCP 443.
Sieci SSL VPN spełniają wymagania współczesnej firmy, oferując: elastyczność (dostęp z dowolnego miejsca i różnych urządzeń: laptopów, PDA, telefonów komórkowych), niskie koszty, bezpieczeństwo sieci przedsiębiorstwa, prostotę wdrożenia. W sieciach SSL VPN jest wykorzystywany protokół SSLv3 lub nowszy TLSv1 (Transport Layer Security). W przypadku urządzeń bezprzewodowych stosuje się protokół WTLS (Wireless Transport Layer Security).
Wszechobecność protokołu SSL wynika z jego elastyczności i stabilności. Protokół SSL zapewnia trzy podstawowe komponenty zabezpieczania: uwierzytelnienie, poufność i integralność. W modelu OSI jest on umiejscowiony na warstwie transportowej.
Podczas zestawiania połączenia VPN SSL ma miejsce:
Niektóre produkty zapewniają translację plików, a nawet zawartości desktopu do formatu HTML. Umożliwia to przeglądanie i edycję dokumentów bez konieczności ich pobierania i zapisywania na zdalnym komputerze. Dodatkowo bezpieczeństwo zwiększa fakt, że użytkownicy, mając łatwy dostęp do sieci firmowej, zaprzestają przenoszenia dokumentów na wymiennych dyskach, laptopach, przesyłania jako załączniki do poczty itp.
Często firmowy intranet wykorzystuje wewnętrzny DNS, niedostępny z zewnątrz. Zdalni użytkownicy mogą mieć dostęp do niego poprzez serwer reverse-proxy. Funkcjonuje on pomiędzy zdalnym użytkownikiem a stronami firmowymi. Sieć firmowa pozostaje bezpieczna za zaporą sieciową.
Brama SSL VPN zapewnia dodatkową ochronę, pośrednicząc pomiędzy żądaniami zdalnego klienta a serwerem aplikacji. Zdalne połączenie dociera tylko do bramy, gdzie jest kończone, a zadanie jest przetwarzane, autoryzowane i tłumaczone na właściwe protokoły, tj. ICA (Independent Computing Architecture), RDP (Remote Desktop Protocol) dla serwera terminali Windows, X-11 - aplikacji pod kontrolą Linuksa lub Uniksa, HTTP lub HTTPS - serwerów WWW, 3270 lub 5250 dla aplikacji mainframe i AS/400. Następnie żądanie jest przesyłane poprzez nowo zestawione połączenie do serwera aplikacji back-end.
Możliwe jest wdrożenie 3-stopniowej polityki dostępu do dokumentów:
Podstawową funkcją realizowaną przez każdą bramę SSL VPN jest rola proxy stron WWW. Polega ona na połączeniu się bramy z serwerem http, pobraniu strony i odesłaniu jej w postaci zaszyfrowanej SSL/TLS do przeglądarki klienta.
Urządzenia SSL VPN obsługują protokoły FTP i CIFS wykorzystywane przez serwery plików. Wewnętrzny protokół aplikacji jest tłumaczony przez bramę, na zewnątrz jako HTTP i HTML, tzw. Webifying aplikacji. Dla użytkownika końcowego serwer plików jest widziany jako serwer HTTP. Translacja aplikacji funkcjonuje nie w każdym przypadku. Niektóre programy, jak MS Outlook lub inne typu instant messaging, posiadają indywidualny, charakterystyczny wygląd, który jest zmieniany po przetłumaczeniu na HTML. Powoduje to pewien dyskomfort użytkowników. Rozwiązaniem jest zastosowanie przekierowania portów (port forwarding). Wymaga to pobrania niewielkiego programu działającego po stronie klienta, zwykle w Javie lub Active, który nasłuchuje na porcie zdefiniowanym dla konkretnej aplikacji. Pakiet przychodzący na ten port jest przesyłany w tunelu SSL przez sieć zewnętrzną do bramy SSL VPN, która go rozszyfrowuje i przekazuje do rzeczywistego serwera aplikacji.
Niektóre produkty udostępniają funkcję rozszerzenia sieci (network extension). Zdalny użytkownik uzyskuje bezpośrednie połączenie z siecią korporacyjną, a kontrola dostępu opiera się jedynie na informacjach z warstwy sieci - adresy IP oraz numery portów.
Zadania, jakie powinna realizować brama SSL VPN, nie ograniczają się jedynie do pełnienia roli proxy dla statycznych stron umieszczonych na firmowym serwerze HTTP. Powinna ona zapewniać też kompleksową translację wiadomości z serwera poczty elektronicznej na format WWW, umożliwiać obsługę aplikacji e-commerce, programów zarządzających informacją osobistą PIM (Personal Information Management) oraz systemu zdalnego zarządzania. Pracownicy zdalni często bowiem mają potrzebę dostępu do firmowych katalogów i plików znajdujących się na wewnętrznych serwerach plików.
Brama SSL VPN powinna wspierać protokoły transportowe FTP, NFS (Network File System), serwerów plików Microsoft - protokół CIFS/SMB (Common Internet File System/Server Message Block).
Nawet jeżeli dany produkt SSL VPN nie posiada wbudowanego narzędzia obsługi poczty przez WWW, to umożliwia połączenie się z firmowymi aplikacjami pocztowymi, takimi jak Microsoft Outlook Web Access, iNotes firmy IBM czy SquirrelMail (open source). Należy dokonać wyboru, czy wdrożyć powyższe, mniej popularne wśród użytkowników końcowych aplikacje pocztowe, czy też uboższą w możliwości translację poczty na format WWW.
Dla aplikacji, które nie mogą być tłumaczone na WWW, istnieją dwie metody bezpośredniego dostępu do nich: przekierowanie portów (port forwarding) lub rozszerzenie sieci. Translacja portów jest stosowana w przypadku popularnych aplikacji, korzystających ze znanych portów. Natomiast rozszerzenie sieci umożliwia dostęp do całej sieci poprzez stworzenie tunelu. W tym celu brama musi dostarczyć maszynie klienckiej odpowiednie oprogramowanie. Zazwyczaj jest to aplet Javy (<100 kb) lub ActiveX. Może on jednak powodować problemy zgodności z przeglądarką, systemem operacyjnym i naruszać bezpieczeństwo. Przykładowo, użytkownik MS Internet Explorer z poziomem bezpieczeństwa ustawionym na wysoki nie będzie mógł korzystać z tych technik. Obniżenie poziomu bezpieczeństwa nie zawsze jest dopuszczalne. Po wdrożeniu dwóch omawianych technik, kontrola dostępu nie może być już prowadzona. Reguły bezpieczeństwa są wówczas ograniczone jedynie do kontroli adresu URL.
SSL VPN może pełnić rolę proxy dla standardowych protokołów pocztowych: SMTP, POP, IMAP. Mechanizm ten polega na przesyłaniu danych pomiędzy klientem a bramą w postaci zaszyfrowanej - POP-over-SSL, IMAP-over-SSL lub SMTP-over-SSL. Technika ta pozwala stosować szyfrowanie SSL nawet w przypadku starszych serwerów pocztowych oraz tych, które znajdują się w prywatnej przestrzeni adresowej, nie wymagając przy tym mechanizmów translacji portów i rozszerzenia sieci.
Jako urządzenia pełniące również rolę ochronną, produkty SSL VPN powinny zapewniać szczegółową kontrolę dostępu do usług z sieci korporacyjnej. Należy określić, które zasoby są dostępne oraz jakie operacje na nich są możliwe. W przypadku prostej kontroli wybiera się grupę, która ma dostęp do danych zasobów. Możliwa jest także bardziej zaawansowana kontrola - poszczególne pliki są udostępniane, pod warunkiem że użytkownik uwierzytelni się na serwerze LDAP (Lightweight Directory Access Protocol) i ma uaktualniony skaner antywirusowy.
Identyfikacja użytkownika i przypisanie go konkretnej grupie jest dla systemu zdalnego dostępu SSL VPN zadaniem krytycznym. Najczęściej wykorzystuje się mechanizmy uwierzytelniania: LDAP i RADIUS. RADIUS (Remote Authentication Dial-In User Service) jest często wykorzystywany w procesie uwierzytelniania pod systemami Windows, Unix oraz w metodach opartych na żetonach, np. RSA SecurID.
SSL VPN powinien współpracować z infrastrukturą klucza publicznego PKI (Public-Key Infrastructure) i obsługiwać listę odwołanych certyfikatów (Certificate Revocation Lists).
Podczas definiowania reguł kontroli dostępu można różnicować użytkowników, w zależności od posiadania certyfikatu. Pracownik łączący się z domowego PC, posiadającego swój certyfikat, jest traktowany jako zaufany użytkownik i może uzyskać większe uprawnienia w dostępie do sieci korporacyjnej niż użytkownik logujący się z komputerów publicznych (w kawiarence czy kiosku internetowym), niemających odpowiednich certyfikatów.
SSL jest wszędzie tam, gdzie jest przeglądarka internetowa. Tak więc na świecie są miliony już preinstalowanych klientów mogących łączyć się z bramami SSL VPN. To o wiele szersze grono potencjalnych odbiorców niż w przypadku IPSec VPN. Przewiduje się, że przeciętny podział technik zdalnego dostępu będzie kształtował się następująco: ok. 10-20% uprzywilejowanych pracowników będzie korzystać z połączeń IPSec VPN, pozostałą grupę będą stanowić użytkownicy SSL VPN. Sieci SSL VPN pozwalają korzystać z dostępu do poczty, zarządzania informacją osobistą PIM (Personal Information Management), intranetu, aplikacji biurowych oraz plików zlokalizowanych na korporacyjnym serwerze, co dla większości pracowników jest zadowalające. SSL nie jest nową technologią - jest tylko jej nowym zastosowaniem.