Cel każdej z nich jest taki sam, natomiast drogi do jego realizacji - różne. Na przestrzeni ostatnich lat o prym walczyło kilka różnych technologii. Z punktu widzenia telepracy najistotniejsze są dwie technologie oparte na IPSec/IKE i SSL/TLS.

IPSec najlepszy do "site-to-site"

IPSec jest jedną z najszerzej wykorzystywanych technologii do budowy wirtualnych tuneli. W przeciwieństwie do rozwiązań SSL VPN (znakomicie nadających się do realizacji połączeń w trybie client-to-site) - prym w połączeniach site-to-site wiodą właśnie rozwiązania spod znaku IPSec. Są trochę bardziej skomplikowane niż SSL VPN. Wymagają również wykorzystania kilku protokołów - w zależności od celu, jaki chcemy osiągnąć. Cztery najważniejsze z nich to: AH (Authentication Header), ESP (Encapsulating Security Payload), IKE (Internet Key Exchange) oraz IPComp (IP Payload Compression).

AH zapewnia integralność nagłówka pakietu oraz zawartych w nim danych, jak również niesie informacje uwierzytelniające. Może pracować w dwóch trybach - tunelowania oraz transportowym. Pierwszy wykorzystywany jest najczęściej w połączeniach site-to--site, drugi w client-to-site. Niestety, AH nie potrafi zaszyfrować samego pakietu - adresy IP (źródła i celu) nie są w żaden sposób ukryte, co powoduje, że AH nie jest kompatybilny z NAT-em. W związku z tym stosowany jest coraz rzadziej, a niektóre rozwiązania w ogóle go nie obsługują.

Protokół ESP w zależności od wersji jest w stanie zapewnić zarówno szyfrowanie, jak i kontrolę integralności. Obie te funkcje powinny być stosowane łącznie, a w skrajnych przypadkach osobno. Obecnie standardem jest wersja 2, trwają jednak prace nad wersją 3. Podobnie jak AH, tak i ESP może pracować w trybie transportowym i tunelowania. Tylko ten drugi jest kompatybilny z NAT-em.

Podczas nawiązywania połączenia przez protokół, jego poszczególne parametry muszą zostać bezpiecznie wynegocjowane. Do wypełnienia właśnie tego zadania stworzono protokół IKE, który tworzy tzw. związki bezpieczeństwa (Security Associations), będące rezultatem wynegocjowania wielu parametrów kanału, takich jak algorytmu szyfrowania (np. AES czy 3DES), metody uwierzytelniania połączenia (np. klucz współdzielony czy certyfikat), jednej z 10 grup algorytmu Diffie Helman (odpowiedzialnego za wygenerowanie klucza współdzielonego pomiędzy stronami połączenia). Aby spełnić swoją misję, IKE działa w dwóch fazach. W pierwszej tworzy najpierw kanał szyfrowany do wymiany wrażliwych danych. W zależności od konfiguracji IKE może skorzystać z jednego z dwóch trybów: main lub aggressive. Każdy z nich ma wady i zalety. "Main mode" jest bezpieczniejszy - do ustanowienia związku bezpieczeństwa wykorzystuje się tutaj trzy pary wiadomości. Niestety, tryb ten nie zalicza się do szybkich podczas zestawiania połączenia. Dlatego też stworzono tryb "aggressive", który zamiast trzech par, używa jedynie trzech pojedynczych wiadomości. Jest przez to mniej bezpieczny (np. brak możliwości uzgadniania grupy DH) i daje mniejsze możliwości, ale za to jest szybki. Po wykonaniu tej pracy może zostać nawiązana faza druga, która służy zestawieniu związków bezpieczeństwa właściwego połączenia IPSec. Tutaj na szczęście mamy tylko jeden tryb: "quick mode", który podobnie jak "aggressive mode" do wynegocjowania parametrów używa jedynie trzech wiadomości. Kanał ten szyfrowany jest za pomocą takich algorytmów, jakie zostały wynegocjowane w fazie pierwszej.

W celu skompresowania ładunku, który niesiony jest w kanale IPSec, wykorzystywany jest kolejny protokół - IPComp. Jest on na tyle sprytny, że nie próbuje upakowywać wszystkiego hurtem, a rozpoznaje te typy informacji, które faktycznie dają się ścisnąć.

Jednym z większych problemów, jakie mogą napotykać rozwiązania IPSec, jest NAT. Wprowadzane są różnego rodzaju techniki pozwalające jednak na korzystanie z translacji adresów. Stosuje się enkapsulację pakietów ESP w UDP, w przypadku ruchu takiego jak VIP, czy FTP bramy aplikacyjne (ALG - Application Layer Gateway), czy też NAT-T (NAT Traversal) - rozszerzenie do protokołu IKE. Do tego dochodzą dodatkowe elementy, takie jak współpraca z L2TP (Layer 2 Tunneling Protocol) lub PFS (Perfect Forward Secrecy).

Mimo tego skomplikowania IPSec jest wydajną i bezpieczną technologią, choć niestety nie pozbawioną wad. Jeżeli realizujemy połączenia client-to-site, musimy zainstalować i skonfigurować odpowiedniego agenta na stacji roboczej. Mimo że IPSec jest standardem, to każdy producent ma własnego agenta, który raczej nie będzie bezproblemowo działał z innymi rozwiązaniami. Pojawiają się więc firmy, które dostrzegły lukę i tworzą klientów uniwersalnych, np. Greenbow (http://www.greenbow.fr) - oczywiście za odpowiednim wynagrodzeniem.

W razie problemów i konieczności reinstalacji oprogramowania będziemy mieli kłopoty - w korporacjach rzadko który użytkownik ma uprawnienia administratora, które są wymagane do instalacji takiego agenta.

SSL/TLS VPN nie tylko do "client-to-site"

Technologia SSL/TLS VPN skutecznie toruje sobie drogę wszędzie tam, gdzie pojawiają się użytkownicy mobilni. Producenci najczęściej reklamują swoje rozwiązania tej klasy jako niewymagające instalacji klienta (clientless VPN). Jest to jednak tylko część prawdy. Wszystko zależy od trybu, w którym ustanawiane jest połączenie. Klasyczny SSL VPN może być realizowany w zasadzie w trzech scenariuszach:

W pierwszym, użytkownik łączy się z określoną stroną webową wystawiającą portal dostępowy, uwierzytelnia się i na tej podstawie uzyskuje autoryzację do poszczególnych zasobów. Są więc one dostępne bezpośrednio z poziomu przeglądarki. Najczęściej w ten sposób są udostępniane aplikacje webowe (np. CRM), poczta web mailowa czy baza dokumentów. Jest to najmniej wymagający scenariusz, choć dużo zależy od aplikacji. Użytkownik nie musi mieć na stacji żadnych rozszerzonych uprawnień. Jedyne, czego potrzebuje to przeglądarka internetowa. Jednak nie wszystkie zasoby są dostępne za pomocą mechanizmów webowych, np. udziały sieciowe. W takim przypadku SSL VPN działa jako translator (tzw. application translator), przekształcając natywny protokół aplikacji na taki, który może być przeczytany przez przeglądarkę. SSL VPN pracujący w tym trybie, to możliwość zabezpieczenia ruchu HTTP przez dodanie ochrony w postaci protokołu SSL lub TLS w warstwie transportowej. To z kolei pozwala na zaszycie informacji, które spływają z warstw wyższych (także z warstwy 7). Problemów związanych z tym trybem jest kilka. Najpoważniejszym jest jednak fakt, że brama VPN musi "przepisać" aplikacje - działa jak proxy pomiędzy nimi a klientem. To sprawia, że aplikacje webowe bardziej złożone, zawierające np. JavaScript, dodatkowe kontrolki czy inną zawartość aktywną, mogą nie dać się łatwo przepisać. Niektóre rozwiązania w ogóle sobie z nimi nie radzą.