VPN

ITpedia

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
  • Site-to-Site.

Spis treści

Remote-Access

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.

Site-to-Site

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.

  • Intranet – sieć lokalna lub rozległa przedsiębiorstwa, w której zastosowano technologie internetowe: głównie oprogramowanie oparte na TCP/IP i HTTP. Kontakt takiej sieci z siecią publiczną odbywa się najczęściej przez zaporę ogniową.
  • Ekstranet – sieć niezależnych przedsiębiorstw, oparta na technologiach internetowych. Są to często sieci korporacyjne połączone ze sobą za pośrednictwem bezpiecznych łączy internetowych i linii dzierżawionych.

Składniki VPN

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:

  • oprogramowanie klient rezydujące na komputerze osobistym każdego zdalnego użytkownika;
  • dedykowane urządzenia, jak np. zapora ogniowa;
  • dedykowany serwer VPN dla usług dial-up;
  • NAS (Network Access Server), używany przez dostawcę do zapewnienia dostępu do VPN przez zdalnego użytkownika.

Bezpieczeństwo VPN

W VPN przewidziano kilka metod zabezpieczenia danych:

  1. Zapora ogniowa. Stanowi ona rodzaj przegrody między siecią prywatną a Internetem. Zapora ogniowa jest oddzielnym urządzeniem lub oprogramowaniem, ale wszystkie jej funkcje mogą być wbudowane w niektóre rutery.
  2. Szyfrowanie. Większość systemów szyfrowania przynależy do jednej z dwu następujących kategorii:
    • Symmetric-key encryption,
    • PKE (Public-Key Encryption).
      W przypadku Symmetric-key encryption, czyli preferującej metodę z użyciem klucza symetrycznego, każdy komputer ma klucz sekretny, który może stosować do szyfrowania pakietów zawierających informacje przed ich wysłaniem przez sieć do innego komputera. Przy stosowaniu tej metody trzeba wiedzieć, które z komputerów będą się ze sobą komunikowały, gdyż klucz będzie zainstalowany na każdym z nich.
      Szyfrowanie z użyciem klucza publicznego wymaga kombinacji klucza prywatnego i publicznego. Klucz prywatny zna tylko komputer wysyłający, natomiast klucz publiczny jest znany wszystkim komputerom, z którymi będzie prowadzona komunikacja. Aby dekodować zaszyfrowaną wiadomość, komputer musi używać klucza publicznego i swojego klucza prywatnego. Popularną metodą szyfrowania jest PGP (Pretty Good Privacy).
  3. PGP – popularny system szyfrowania informacji, oparty na algorytmach IDEA, RSA i MD5, rozpowszechniany przez jego autora, P. Zimmermana, początkowo bezpłatnie. PGP może funkcjonować prawie w każdym systemie operacyjnym i uchodził za absolutnie bezpieczny. Program opiera się na dwu kluczach: publicznym i prywatnym. Wynik przetwarzania (tzw. haszowania) wiadomości jest tworzony przez MD5 i szyfrowany za pomocą RSA kluczem prywatnym nadawcy. Klucz publiczny wykorzystuje algorytm RSA, a prywatny algorytm IDEA. Chociaż między tymi kluczami zachodzi tak złożona zależność matematyczna, że wykrycie klucza tajnego staje się praktycznie niemożliwe, to jednak w 1994 r. doszło w USA – gdzie kryptografię zalicza się do broni – do złamania danych zaszyfrowanych algorytmem PGP. W rozłożeniu klucza ponad 450-bitowego (129-cyfrowy RSA) na czynniki pierwsze brało udział 1600 komputerów PC przez 8 miesięcy. Odtąd korzysta się z kluczy RSA przekraczających 2000 bitów. Na ogół uważa się, że rozłożenie klucza IDEA odpowiada złamaniu 3000-bitowego RSA.
  4. IDEA (International Data Encryption Algorithm) – algorytm blokowego szyfrowania danych, opracowany w Swiss Federal Institute of Technology.

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.

Tunelowanie

Funkcjonowanie protokołu PPTP
Funkcjonowanie protokołu PPTP

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:

  • Protokół transportowy (Carrier Protocol), używany przez sieć do transportu informacji;
  • Protokół kapsułkowania lub tunelowania (Tunneling Protocol). Protokół, w rodzaju GRE, IPSec, L2F, PPTP czy L2TP, który niejako „owija” oryginalne dane;
  • Protokół przenoszony (Passenger), czyli oryginalne, transportowane jednostki danych IPX, NetBEUI, IP oraz innych.

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żą:

  1. L2F (Layer 2 Forwarding) – opracowany przez Cisco System; L2F używa schematu identyfikacji wspieranego przez PPP;
  2. PPTP (Point-to-Point Tunneling Protocol) – firmowany przez PPTP Forum, w którego skład weszły US Robotics, Microsoft, 3Com, Ascend i ECI Telematics; PPTP wspiera 40- i 128-bitowe szyfrowanie i używa schematu identyfikacji wspieranego przez PPP;
  3. L2TP (Layer 2 Tunneling Protocol) – rezultat współpracy PPTP Forum, Cisco Systems oraz IETF (Internet Engineering Task Force). Łączy cechy PPTP i L2F. L2TP w pełni wspiera IPSec i może być używany jako protokół tunelowania w VPN typu dwupunktowego i zdalnego dostępu. Może też tworzyć tunel między: klientem a ruterem, NAS a ruterem i między dwoma ruterami. L2TP jest protokołem sieciowym, który kapsułkuje ramki PPP po to, aby móc je przetransportować siecią IP, FR lub ATM. Kiedy jest skonfigurowany do przenoszenia ramek siecią IP, to może zostać użyty do tunelowania w Internecie. Ale L2TP może być także bezpośrednio zaimplementowany jako wsparcie WAN, bez stosowania warstwy transportowej IP. Natomiast w przypadku sieci VPN – L2TP transportuje ramki PPP w pakietach IP.

Protokół IPSec

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 (Authentication Header), który zapewnia zarówno identyfikację oryginalności danych, jak i ich integralność,
  • ESP (Encapsulating Security Payload), dostarczający poufności danych, identyfikację oryginalności oraz integralności danych,
  • ISAKMP (Internet Security Association and Key Management Protocol), który jest odpowiedzialny za automatyczne ustawianie SA oraz zarządzanie kluczami kryptograficznymi tych SA.

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.

Zastosowanie trybów transportowego i tunelowego

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/Oakley

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

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).

Sieci VPN oparte na BGP/MPLS

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.

  • BGP (Border Gateway Protocol) – protokół trasowania międzydomenowego w sieciach TCP/IP, oparty na algorytmie distance-vector. BGP eliminuje EGP, wykrywa pętle na poziomie systemu autonomicznego i polepsza skalowalność Internetu. Miara trasowania jest tylko jedna – preferencja łącza, przypisywana przez administratora sieci. Rutery BGP przechowują kompletny graf całej sieci, ale wymieniają między sobą nie całe tablice, lecz jedynie zmiany. Cztery typy komunikatów protokołu BGP zostały zawarte w RFC 1771 (BGP4). RFC 2545 zawiera rozszerzenia dla IPv6, RFC 2547 charakteryzuje VPN BGP/MPLS, RFC 2858 wprowadza rozszerzenia wieloprotokołowe, a RFC 3107 – etykiety w BGP4.

Składniki sieciowe

Tworzenie wirtualnych sieci VPN BGP/MPLS wg. RFC 2547
Tworzenie wirtualnych sieci VPN BGP/MPLS wg. RFC 2547

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 z obrzeża sieci klienta

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 dostawcy usług

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.

  1. RIP (Routing Information Protocol, RFC 1058 i RFC 1723 dla RIP 2) – protokół trasowania w sieci XNS firmy Xerox, stosowany w prawie wszystkich innych systemach. Do wyznaczania tras pakietów wykorzystuje algorytm DVA (Distance-Vector Algorithm), a więc decyzję wyboru trasy uzależnia od najmniejszej liczby przejść przez rutery. Rutery RIP rozgłaszają co ok. 30 s swoją listę sieci, z którymi mają połączenie, umożliwiając innym ruterom aktualizację własnych tablic trasowania. W sieciach rozległych są one nieefektywne, zastępowane stopniowo m.in. protokołami NLSP i OSPF. Jedyną miarą stosowaną przez RIP jest wspomniana liczba przejść przez rutery (1–15);
  2. OSPF (Open Shortest Path First) – protokół trasowania typu LSA (Link State Algorithms), wykorzystujący algorytm Dijkstry (SPF). OSPF decyzję wyboru trasy uzależnia m.in. od: liczby przejść przez rutery, szybkości transmisji, opóenień wywołanych przeciążeniami sieci i od kosztów ścieżek przypisanych portom ruterów. Tablice trasowania aktualizuje tylko istotnymi informacjami, np. o stanach połączeń. Ponadto OSPF może oprzeć trasowanie na żądaniach warstwy wyższej – pole DS – i wspomagać te protokoły warstwy wyższej, które określają szczególne typy usług, np. pilność pewnych danych. Protokół jest dziełem grupy IGP powołanej przez IETF, przedstawionym początkowo w RFC 1247, a następnie rozszerzanym przez RFC 2178, 2328, 2370, 2676 (QoS), 2740 (IPv6) oraz inne.

Rutery w sieci szkieletowej dostawcy

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.

Model operacyjny

W sieciach wirtualnych opartych na BGP/MPLS wykorzystuje się dwa podstawowe rodzaje ruchu:

  1. Przepływ sterowania, który jest użyty do dystrybuowania tras VPN i ustalenia LSP (Label Switched Path);
  2. Przepływ danych, który jest stosowany przy wysyłaniu klientowi strumienia danych.

Przykładowa topologia sieciowa

Przykład topologii wirtualnej sieci prywatnej VPN BGP/MPLS
Przykład topologii wirtualnej sieci prywatnej VPN BGP/MPLS

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.

Przepływ sterowania

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.

Wymiana informacji o wyborze trasy

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.

Ustanawianie LSP

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.

Ustanowienie LSP w sieci wirtualnej VPN BGP/MPLS
Ustanowienie LSP w sieci wirtualnej VPN BGP/MPLS
  • BE (Best-Effort) – sposób obsługiwania ruchu w Internecie przy zawartości pola DSCP=000000: bez QoS i w miarę najlepszych możliwości;
  • TE (Traffic Engineering) – inżynieria ruchu, nowa koncepcja włączania różnych metod badawczych i analiz, dzięki którym transmisja będzie obsługiwana stosownie do jej specyfiki i priorytetu;
  • RSVP (resource ReSerVation Protocol) – nowoczesny protokół sygnalizacji, przeznaczony do rezerwowania zasobów. Udostępnia różne style rezerwacji i modele przystosowane do wymagań różnych aplikacji, sieci wirtualnych i usług NFS. RSVP nie jest protokołem trasowania, a więc nie narzuca metodyki trasowania i może współpracować z różnymi protokołami ruterów. Stale kontroluje zarówno stan łączy, jaki i węzłów, a w razie awarii ponownie inicjuje sesję. Ponadto adaptuje się on dynamicznie do rekonfiguracji grup, topologii ruterów i zmian trasy ruchu, wspiera SNMP i obydwie wersje IP oraz zapobiega powstawaniu pętli. Rezerwację zasobów RSVP przeprowadza począwszy zawsze od odbiorcy lub grupy odbiorców. Do ważnych własności tego protokołu należy również obligatoryjne odświeżanie rezerwacji, które zwalnia z obowiązku rozłączania zestawionego połączenia wirtualnego i podnosi odporność systemu na awarie oraz inne niespodziewane zmiany. Odnawianie rezerwacji jest cykliczne.

Strumień danych

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:

  • etykietę MPLS, która została pokazana przez brzegowy ruter nr 1 z marszrutą (etykieta 222);
  • następny przeskok BGP dla danej drogi;
  • inicjującą (początkową) etykietę MPLS dla LSP z rutera nr 2 do rutera nr 1.

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.

Korzyści wynikające z VPN BGP/MPLS

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ć:

  • Nie wprowadzają ograniczeń do planu adresowania używanego przez każdego klienta VPN;
  • Ruter brzegowy klienta i każdy punkt klienta nie wymieniają informacji o wyborze drogi z innymi ruterami brzegowymi klienta. Klienci nie muszą zajmować się kwestiami trasowania między punktami, ponieważ są one w gestii dostawcy usług;
  • Klienci VPN nie mają szkieletu lub wirtualnego szkieletu do administrowania. Dzięki temu nie muszą zarządzać dostępem do szkieletowych i brzegowych ruterów dostawcy usług. Natomiast dostawcy nie mają oddzielnego szkieletu lub wirtualnego szkieletu do administrowania dla każdego klienta VPN. Dostawcy nie wymagają zarządzania dostępem do ruterów brzegowych klienta;
  • Polityki, które determinują, czy specyficzny punkt należy do określonego VPN, są politykami klienta. Model administrowania naszkicowany w RFC 2547bis VPN umożliwia klientowi zaimplementować polityki tylko przez dostawcę lub też przez dostawcę współpracującego z klientem;
  • VPN może łączyć brzegi sieci wielu dostawców usług;
  • Bezpieczeństwo VPN BGP/MPLS nie wymaga stosowania metod kryptograficznych, mimo to jest równoważne bezpieczeństwu szkieletowych sieci warstwy 2, jak ATM czy Frame Relay;
  • Przy dostarczaniu usług – zarówno VPN, jak i internetowych – ich dostawcy mogą korzystać ze wspólnej infrastruktury;
  • Model RFC 2547 jest niezależny od warstwy łącza danych (drugiej).

IP VPN

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:

  • mniejsze koszty,
  • łatwa skalowalność,
  • minimalizacja zarządzania siecią,
  • uproszczenie topologii.

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:

  • skalowanie – dające możliwość tworzenia sieci o zróżnicowanych rozmiarach i przepływnościach;
  • bezpieczeństwo – realizowane przez tunelowanie, szyfrowanie, uwierzytelnianie pakietów, uwierzytelnianie użytkowników i kontrolę dostępu;
  • zróżnicowanie usług IP VPN – obejmujące sieci dostępowe, intranetowe i ekstranetowe;
  • zarządzanie siecią – dotyczące zarządzania pojemnością, gwarantowanie jakości usługi, zabezpieczenie przed przeciążeniem sieci;
  • kształtowanie trafiku – obejmujące klasyfikację pakietów i protokoły trasowania;
  • systemy zabezpieczeń – zawierające ochronę typu firewall i systemy wykrywania włamań do sieci.

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).

Rodzaje sieci IP VPN

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).

VPN przez przeglądarkę

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:

  • wzajemna autoryzacja serwera i klienta,
  • ustalenie algorytmów szyfrowania i poziomu bezpieczeństwa,
  • nawiązanie połączenia SSL.

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:

  • użytkownik może przeglądać pliki oraz kopiować je w obrębie sieci firmowej;
  • edycja i zapisywanie są możliwe wyłącznie w lokalizacji źródłowej;
  • dozwolone jest kopiowanie na maszynę kliencką, co jest rejestrowane przez system monitoringu.

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.

Translacja aplikacji

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.

Przekierowanie portów i rozszerzenie sieci

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.

Kontrola dostępu

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.

Uwierzytelnianie

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.

-
-