Zdalny dostęp do wewnętrznych usług sieciowych to mniejsze koszty funkcjonowania firmy i większa wygoda pracowników pod względem zarządzania informacjami. Administrator systemów jest w stanie szybko zareagować na incydent, bez konieczności dyżurowania na miejscu w późnych godzinach, a przebywający na rozmowie u klienta handlowiec może pobrać potrzebne do przeprowadzenia prezentacji pliki z folderu znajdującego się w intranecie.
Najłatwiejszym sposobem osiągnięcia wspomnianego wyżej stanu jest upublicznienie potrzebnych usług w taki sposób, że staną się one widoczne dla każdego podłączonego do Internetu. Sieć wewnętrzna jest wtedy częściowo lub całkowicie otwarta na komunikację z potencjalnie niezaufanymi klientami. Problem polega jednak na tym, że po pierwsze w popularnych aplikacjach sieciowych i systemach operacyjnych często znajdowane są usterki bezpieczeństwa, a po wtóre wiele z narzędzi i protokołów z różnych względów nie zapewnia poufności czy integralności przesyłanych danych. Wdrożenie tej strategii oznaczałoby więc w najlepszym przypadku ryzyko ujawnienia tajemnic przedsiębiorstwa – włączając w to dane uwierzytelniające i dane osobowe pracowników – a w najgorszym przejęcie przez intruza pełnej kontroli nad istotnymi dla funkcjonowania biznesu usługami.
Tunele
W reakcji na potrzebę gwarantowania wydzielonych kanałów komunikacyjnych łączących węzły znajdujące się w oddalonych podsieciach pojawiły się rozwiązania techniczne zwane tunelami. W fizycznym świecie tunel to przejście, które łączy miejsca oddzielone jakąś przeszkodą, np. górą czy zbiornikiem wodnym, pozwalając pojazdom i ludziom na szybkie przemieszczanie się, bez konieczności jej omijania.
Tunele sieciowe działają podobnie – pozwalają na łączność pomimo przeszkód komunikacyjnych (np. barier ochronnych w postaci niepublicznych adresacji, różnych protokołów komunikacyjnych na pewnych odcinkach czy reguł zapór sieciowych), zaś szlak, po którym wędrują dane tworzony jest przez strumienie pakietów odpowiednich protokołów tunelujących. W procesie tym istotne jest, że strony, mimo że wymieniają informacje przechodzące przez wiele punktów, mają wrażenie bezpośredniego połączenia ze sobą.
Przykładami tunelowania są tzw. trakty cyfrowe w sieciach bazujących na protokołach Frame Relay czy ATM. Klient, który zamawia usługę zestawienia połączenia między dwoma lokalizacjami, nie jest w stanie zauważyć, że przesyłane pakiety danych w istocie przechodzą przez wiele miejsc pośrednich (np. węzłów wymiany ruchu). Z poziomu dostarczonego mu tunelu obserwuje jedynie drugi jego koniec, może więc nie być świadom rzeczywistej ścieżki przesyłu czy protokołów przenoszących informacje między kolejnymi urządzeniami aktywnymi.
Sieci wirtualne
Specyficznymi rodzajami tunelów są takie, dla których nośnikiem wymiany danych nie są protokoły związane z danym medium, lecz protokoły wyższych warstw modelu ISO/OSI, na przykład zaliczany do protokołów sieci rozległych protokół internetowy (ang. Internet Protocol, skr. IP), z którego każdego dnia korzystają miliony internautów.
Pakiety większości protokołów komunikacyjnych składają się z nagłówka (ang. header) i ładunku (ang. payload), zwanego też zawartością lub danymi (ang. data). Ładunek może składać się z danych pochodzących od aplikacji, ale może również służyć do przenoszenia pakietów innych protokołów, np. umiejscowionych wyżej w modelu ISO/OSI. Powszechnym przykładem, z którym każdy użytkownik sieci Internet ma do czynienia, jest transport pakietów TCP jako ładunku przenoszonego w pakietach IP. Proces ten nosi nazwę kapsułkowania lub enkapsulacji (ang. encapsulation).
Jeżeli ładunkiem pakietów protokołu warstwy sieciowej (np. IP) będą datagramy protokołu tej samej lub niższej warstwy (np. pakiety IP lub ramki Ethernet przenoszone w pakietach IP), to mamy do czynienia z siecią wirtualną (ang. virtual network). Taka sieć (stworzona na bazie innej sieci) może mieć własną, różną od publicznej adresację w obrębie skomunikowanych węzłów, korzystać z innych niż przyjęte w sieci bazowej protokołów wymiany danych, a także pełnić funkcję tranzytową, tzn. pomagać w wymianie pakietów między dwoma lub więcej podsieciami podłączonymi do bram znajdujących się po obu stronach tunelu.
Zobrazowaniem tunelu, na bazie którego powstaje sieć wirtualna, może być przewóz samochodów wagonami kolejowymi. Z punktu widzenia tachografu umieszczonego w aucie, przebyta odległość będzie krótka, a trasa zupełnie różna od rzeczywiście przebytej drogi między punktem wyjazdu a miejscem docelowym. Również na poziomie infrastruktury tego rodzaju transport jest dla kierowcy przezroczysty – nie musi się on przejmować topologią torów kolejowych, ani właściwymi ustawieniami zwrotnic, aby pokonać istotny odcinek.
Sieci wirtualne są specyficznym podzbiorem tzw. sieci nakładkowych (ang. overlay networks), w których wykorzystuje się protokoły sieciowe do transportowania datagramów innych protokołów komunikacyjnych. Pojęcie to jest bardzo szerokie, bo nawet dowolna aplikacja działająca w modelu klient-serwer i posiadająca własny protokół wymiany danych (warstwy aplikacyjnej, np. SMTP czy HTTP), będzie tworzyła tego rodzaju sieć.
Wirtualne sieci prywatne
Wirtualna sieć prywatna (ang. Virtual Private Network, skr. VPN) to taki rodzaj sieci wirtualnej, w którym zachowana jest poufność i integralność przekazywanych danych, a często również wymagane jest uwierzytelnienie, aby komunikacja była możliwa. Mechanizm działania jest taki sam, jak w przypadku sieci wirtualnych, jednak transportowane pakiety tuż przed umieszczeniem w tunelu są szyfrowane.
Odnosząc się do przedstawionej wcześniej analogii z samochodami, można powiedzieć, że mamy tu do czynienia z odpowiednio zabezpieczonym ładunkiem, ukrytym przed ciekawskimi w zamkniętych wagonach, których pilnują strażnicy. Nawet jeżeli poszczególne auta nie będą należycie zabezpieczone, to podczas przejazdu przez podejrzane rejony ochronę zapewni transportujący.
Do tworzenia wirtualnych sieci prywatnych można używać na przykład niewymagającego protokołu PPTP (z ang. Point-To-Point Tunelling Protocol), zaawansowanego zestawu mechanizmów o nazwie IP Security (skr. IPSec) lub właśnie pakietu OpenVPN – tworzonego przez wolontariuszy z całego świata serwera i klienta prywatnych sieci wirtualnych, który jest wolnym oprogramowaniem.
Uproszczony schemat tunelu między komputerem podłączonym do Internetu, a siecią LAN – czerwona strzałka oznacza bezpośrednie połączenie dwóch stacji wykorzystujące prywatną adresację IP, natomiast seledynowa rurka połączenie VPN zapewniające szyfrowaną łączność dwóch stron w Internecie (IP, adresacja publiczna)
Wirtualne interfejsy
Podłączając komputer do sieci korzystamy zawsze z jakiegoś medium komunikacyjnego i kompatybilnego z nim sprzętu: karty Ethernet, adaptera Wi-Fi czy modemu. Żeby oprogramowanie mogło posługiwać się takim urządzeniem (np. wysyłać i odbierać dane), potrzebna jest obsługa konkretnego modelu sprzętu w systemie operacyjnym, a dokładniej odpowiedni podprogram obsługi zwany sterownikiem urządzenia (ang. device driver). Dzięki niemu system może aktywować pewien zasób zwany interfejsem sieciowym (ang. network interface). Będzie on miał, w zależności od medium i użytych protokołów pewne właściwości: przypisany (lub nie) pewien adres, włączone (lub nie) odpowiednie mechanizmy kolejkowania danych oraz negocjowania prędkości połączenia itd. Do interfejsu z kolei będą odwoływały się istniejące w jądrze systemowym funkcje obsługi połączeń sieciowych, wykorzystywane przez aplikacje.
W przypadku sieci wirtualnych również mamy do czynienia z interfejsem sieciowym, z tym że nie jest on powiązany z fizycznym nośnikiem, lecz z odpowiednim podprogramem odpowiedzialnym za zestawienie i utrzymywanie tunelu. Pakiety lub ramki wprowadzane przez oprogramowanie tunelujące do takiego interfejsu sieci wirtualnej (ang. virtual-network interface) są traktowane przez system (np. przez stos TCP/IP) tak samo, jak gdyby pochodziły z rzeczywistej sieci.
Istnieją dwa popularne rodzaje wirtualnych interfejsów sieciowych: wirtualny interfejs tunelujący i wirtualny interfejs nasłuchowy. Ten pierwszy pozwala w sposób programowy na tworzenie i odbieranie pakietów sieciowych (np. IP), natomiast drugi umożliwia to samo, lecz na poziomie łącza danych (np. ramek Ethernet).
Czym różni się programowe tworzenie i odbieranie pakietów bądź ramek od zwyczajnej komunikacji międzyprocesowej, która odbywa się przez sieć? Chodzi tu o dostęp uprzywilejowanej aplikacji do niskopoziomowych funkcji wysyłania i odbierania datagramów bezpośrednio w interfejsie, z pominięciem abstrakcyjnej warstwy międzyprocesowej.
Działający w systemie program, który po prostu chce komunikować się z innym, używając jakiegoś protokołu sieciowego, ma dostęp wyłącznie do podsystemu gniazd sieciowych (ang. network sockets) i nie jest w stanie kontrolować zawartości nagłówków wysyłanych pakietów czy mieć wglądu w dane pochodzące z warstwy łącza. W przypadku wirtualnego interfejsu i upoważnionej do jego użytkowania aplikacji sprawa przedstawia się zupełnie inaczej. Taki program może budować pakiety lub ramki i wypełniać ich nagłówki dowolnymi informacjami, a następnie transmitować je wirtualnym urządzeniem sieciowym, skąd zostaną pobrane przez inną aplikację lub przekazane dalej. Może również odbierać datagramy i dokonywać pełnej inspekcji ich zawartości. Oczywiście to wszystko w granicach protokołu, do którego przypisano wirtualny interfejs.
W zależności od tego, czy wirtualny interfejs ma być użyty do operowania na pakietach warstwy sieciowej (interfejs tunelujący) czy ramek warstwy łącza (interfejs nasłuchowy), użyty będzie odpowiedni sterownik: TUN (dla dwupunktowego tunelu sieciowego) i TAP (dla mostka nasłuchowego).
Dokumentacja kernela Linux nazywa TUN urządzeniem sieciowym wirtualnej łączności punkt–punkt (ang. Virtual Point-to-Point network device), a TAP urządzeniem sieciowym wirtualnego Ethernetu (ang. Virtual Ethernet network device). Wynika to z ich przeznaczenia: TUN pozwala łączyć dwa węzły sieciowe (warstwa 3), a TAP przechwytywać pakiety z całego segmentu znajdującego się w lokalnym zasięgu (warstwa 2).
Rodzaje VPN
Istnieje wiele rodzajów wirtualnych sieci prywatnych, a głównymi kryteriami ich rozróżniania są:
- mechanizmy uwierzytelniające,
- mechanizmy zabezpieczające dane (szyfrujące i zapewniające integralność),
- protokoły wykorzystywane do przenoszenia ruchu (wytworzenia tunelu),
- protokoły przenoszone w tunelu,
- warstwa modelu ISO/OSI obsługiwana przez interfejsy tunelujące,
- lokalizacja bramy tunelującej (np. W komputerze lub w sieci lokalnej),
- rodzaj usługobiorcy (końcowi klienci lub cała podsieć),
- rodzaj dostępu (na żądanie lub utrzymywany na stałe),
- model nawiązywania łączności (klient-serwer lub serwer-serwer),
- obecność mechanizmów wyznaczania tras (własne mechanizmy trasowania, trasowanie z pomocą systemu, brak trasowania).
Obsługa VPN
Aplikacja obsługująca wirtualną sieć prywatną (np. OpenVPN) z jednej strony utrzymuje połączenie tunelujące, a z drugiej zarządza interfejsem wirtualnym. Aby wymieniać dane z drugą stroną, często – podobnie jak każdy inny program – wykorzystuje standardową komunikację (np. interfejs gniazd) i nie ma dostępu do niskopoziomowych funkcji konwencjonalnego interfejsu sieciowego (np. sterownika karty Ethernet).
Inaczej sprawa się ma z interfejsem wirtualnym. Jeżeli odbierze on pakiet lub ramkę (mogą one pochodzić z oprogramowania działającego na lokalnej stacji lub z innego interfejsu sieciowego), to taki datagram trafi bezpośrednio do aplikacji obsługującej interfejs (ewentualnie do odpowiedniego podprogramu jądra, gdy korzystamy z niskopoziomowej implementacji VPN). Dokona ona jego kapsułkowania i umieści jako ładunek w pakietach wędrujących wspomnianym wyżej, konwencjonalnym połączeniem sieciowym do odpowiedniego oprogramowania po drugiej stronie. Gdy z kolei do gniazda sieciowego skojarzonego z połączeniem tunelującym dotrą jakieś dane wysłane z drugiego końca tunelu, to zostanie przeprowadzona operacja odwrotna: po udanym wypakowaniu ładunku, znajdujące się tam pakiety lub ramki zostaną wprowadzone na wejście wirtualnego interfejsu. Stamtąd mogą trafić do lokalnej aplikacji lub zostać przez system przekazane dalej.
Uproszczony schemat połączenia nawiązywanego przez przeglądarkę WWW korzystającą z interfejsu tunelującego (tun0), który jest obsługiwany przez OpenVPN; rzeczywisty interfejs sieciowy (eth0) wykorzystywany jest do utrzymywania tunelu
Aby w przypadku interfejsu TUN zachodziła komunikacja między większą liczbą stacji sieciowych niż tylko bezpośrednio obecne na końcach tunelu, należy dodatkowo skonfigurować przekazywania pakietów (ang. forwarding) i zadbać o właściwe trasowanie (ang. routing).
Trasowanie pakietów z jednej sieci lokalnej do drugiej z użyciem tunelu w Internecie; serwer OpenVPN odpowiedzialny jest za zarządzanie interfejsem tun0 i przekazywanie pakietów szyfrowanym połączeniem nawiązanym przez publiczny interfejs (eth0)
Program odpowiedzialny za enkapsulację pakietów może dodatkowo szyfrować kanał komunikacyjny, którym przesyłane są dane. W przypadku OpenVPN wykorzystywane są w tym celu możliwości biblioteki kryptograficznej OpenSSL, włączając w to obsługę mechanizmów SSL i TLS. Oznacza to, że do dyspozycji mamy różne zestawy szyfrów symetrycznych do zabezpieczania sesji (np. 3DES), możliwość korzystania z asymetrycznego szyfrowania (np. RSA) i mechanizmów wymiany klucza (np. D-H czy ECDHE) w celu ustanowienia bezpiecznego połączenia. Aby zapewnić integralność komunikatów w przypadku pakietu OpenVPN wykorzystywany jest też kod uwierzytelniania wiadomości kluczowany skrótem (ang. keyed-Hash Message Authentication Code, skr. HMAC).
Poza przekazywaniem zaszyfrowanego strumienia danych oprogramowanie obsługujące wirtualne sieci prywatne musi też w jakiś sposób wymieniać wiadomości kontrolne, na przykład raz na jakiś czas odświeżać klucz sesyjny, badać czy druga strona jest dostępna, negocjować parametry połączenia itp. W tym celu niektóre implementacje posługują się dodatkowym połączeniem, które służy wyłącznie do kontroli warunków pracy. Może to być kłopotliwe w sytuacjach, gdy po obu lub po jednej ze stron działa restrykcyjnie skonfigurowana zapora sieciowa, szczególnie w przypadku komunikatów wysyłanych bezpołączeniowo (np. z użyciem protokołu UDP lub wyspecjalizowanego protokołu danej implementacji). Rozwiązaniem tego problemu jest zastosowanie zwielokrotniania kanałów z użyciem programowego multipleksera. Strategii tej używa m.in. OpenVPN, dzięki czemu jednym połączeniem przesyłane są zarówno wymieniane dane, jak również dodatkowe informacje kontrolne.
Za poprawną wymianę informacji między dwoma tworzącymi tunel procesami odpowiada odpowiedni protokół. Decyduje on o kształcie wiadomości używanych do transportowania pakietów lub ramek wirtualną siecią, a także o sposobach ustanawiania i negocjowania parametrów połączenia. W przypadku OpenVPN jest to protokół OpenVPN, o którego cechach będzie można przeczytać w kolejnym odcinku serii „OpenVPN bez tajemnic”.