W drugim scenariuszu użytkownik łączy się ze stroną webową tak, jak w pierwszym przypadku, ale tylko po to, aby się uwierzytelnić. Następnie ze strony zostaje pobrany dodatek - w zależności od możliwości przeglądarki albo aplet Javy, albo kontrolka ActiveX. Dodatek ten umożliwia nawiązanie połączenia z koncentratorem VPN i uzyskanie łączności IP (klient otrzymuje własny adres IP). Dzięki temu możliwe jest połączenie z aplikacjami, czy zasobami, które nie mogą być udostępnione poprzez przeglądarkę. Ochrona jest realizowana w warstwie sieci. Ten tryb jest zatem bardzo zbliżony do tradycyjnych VPN-ów, opartych chociażby na Spiec, wymagających po stronie klienta instalacji odpowiedniego oprogramowania. Istnieją jednak pewne różnice. Po pierwsze, w przypadku SSL VPN instalacja jest prosta, a rozwiązanie z punktu widzenia użytkownika bezobsługowe. Po drugie, budowa tunelu jest jednak inna. Podobnie jak rozwiązania IPSec, także te oparte na SSL-u potrafią rozpoznawać ruch i kierować ten, który odnosi się do zasobów korporacyjnych przez tunel, a pozostały (np. przeglądanie stron) wypuszczać standardowym łączem (tzw. Split tunneling). Tryb ten stawia pewne wymogi wobec stacji roboczej, z której nawiązywane jest połączenie, np. przeglądarka musi zezwalać na uruchamianie apletów czy kontrolek. Po zakończeniu połączenia klient może zostać automatycznie zdeinstalowany.

I wreszcie hybryda, będąca połączeniem scenariusza 1 i 2. W tym przypadku użytkownik znowu łączy się z portalem, który oferuje jednak nieco większe możliwości w stosunku do scenariusza nr 1. W zależności od zasobów, z którymi chciałby się połączyć, dostaje się do nich albo bezpośrednio (przez portal), albo instalowany jest dodatek realizujący łączność na poziomie sieci w przypadku aplikacji niewebowych, a nawet wystawiana sama aplikacja, którą użytkownik może sobie uruchomić prawie bezpośrednio z koncentratora. Wariacji na temat tych trzech scenariuszy jest jeszcze kilka, ale te wymienione są najpopularniejsze.

Bez względu na tryb pracy, z wykorzystaniem SSL VPN wiążą się pewne dodatkowe wymagania. Musi on zapewniać mechanizmy bezpiecznego uwierzytelniania. Nie do zaakceptowania są rozwiązania pozbawione możliwości skorzystania z uwierzytelniania dwuelementowego (np. tokeny). Poza tym, w dużych środowiskach konieczne są odpowiednia skalowalność oraz segmentacja, łącznie z separacją zadań administracyjnych. Jeżeli dostęp zdalny jest usługą krytyczną, to należy sprawdzić wsparcie dla wysokiej dostępności. SSL/TLS VPN dają także masę dodatkowych "wodotrysków", które czasami się przydają, np. możliwość zdalnej pomocy użytkownikowi przez nawiązanie sesji do jego stacji (coś w rodzaju popularnego WebExa). Są również udostępniane komunikatory webowe, współdzielenie aplikacji czy określonego obszaru np. na pulpicie.

Szukając rozwiązania SSL VPN, dobrze jest odwiedzić wspomnianą już stronę VPN Consortium i sprawdzić, jakie funkcje możemy brać pod uwagę. Warto też pamiętać, że dla niektórych zastosowań wcale nie będziemy potrzebowali sprzętu za setki tysięcy dolarów. Istnieją znakomite rozwiązania darmowe, m.in. SSL Explorer (http://www.sslexplorer.org).

Ale SSL VPN to nie tylko połączenia client-to--site. Przykłady rozwiązań typu open source, np. OpenVPN (http://openvpn.net/), dowodzą, że technologia ta z powodzeniem może zostać wykorzystana również do budowania tuneli site-to-site, i to prawie zupełnie za darmo.

Teoretycznie więc główną zaletą tuneli realizowanych za pośrednictwem SSL VPN jest ich przyjazność dla użytkownika końcowego. Ostatecznie nie musi on dysponować żadnym dodatkowym oprogramowaniem poza przeglądarką, za pomocą której następuje połączenie z urządzeniem terminującym ruch.

Hard czy soft?

Bez względu na technologię, producenci dostarczają swoje rozwiązania w dwojakiej formie - albo urządzeń (appliances), albo samego oprogramowania. Te pierwsze to często zwykły serwer Dell, HP, czy IBM z innym logo, np. Secure Computing.

Czasami zdarza się, że dostawcy przygotowują własne rozwiązania sprzętowe, np. SonicWall, Juniper, Nortel. Niektórzy dogadują się również z producentami specjalistycznych urządzeń, jednocześnie umożliwiając instalację oprogramowania na standardowych maszynach - tak na przykład postępuje Check Point, zawierając porozumienie z Crossbeamem i Nokią.

Wybór rozwiązania to wiele kryteriów - nie tylko tryb połączenia, ale także skala. Coraz rzadziej, szczególnie w średnich lub małych firmach, stosuje się dedykowane rozwiązania VPN. Tutaj królują wszelkiej maści UTM-y, które w zależności od producenta umożliwiają zestawienie zarówno kanałów IPSec, jak i SSL/TLS. Nie mogą się one równać ani wydajnością, ani bogactwem funkcji z pełnokrwistymi bramami, ale pozwalają dosłownie w 5 minut zapewnić zdalny dostęp pracownikom, czy połączenie z partnerem handlowym.

Czy zmienić IPSec na SSL?

Jak zwykle odpowiedź na to pytanie nie jest prosta. Można śmiało powiedzieć, że IPSec zdecydowanie lepiej sprawdzi się w przypadku połączeń site-to-site. Przez lata ten zestaw protokołów wykorzystywany był również w połączeniach client-to-site.

Zgodnie ze starą zasadą administratorów - "jeżeli coś działa, to po co to zmieniać", można w dalszym ciągu używać IPSeca do tego typu łączności, ale raczej przy niewielkiej liczbie użytkowników. Jeśli jedynymi użytkownikami zdalnymi są osoby odpowiedzialne za utrzymanie dostępności usług, to IPSec sprawdzi się nieźle.

Problemy pojawiają się, gdy o dostęp zaczynają dopominać się zwykli użytkownicy. Wówczas nakład administracyjny potrzebny po pierwsze na konfigurację, po drugie bieżące utrzymanie infrastruktury sprawia, że przejście na SSL zaczyna mieć sens. Na przykład handlowcy muszą czasami dostać się do zasobów korporacji nie mając ze sobą komputera, a trudno sobie wyobrazić instalację agenta IPSec na komputerze w kawiarni internetowej.

Z łączeniem się z rozmaitych lokalizacji związane są jeszcze inne problemy, np. pokrywanie się adresacji, blokada portów niezbędnych do zestawienia tunelu, NAT...