Praktyczna implementacja sieci VPN na przykładzie OpenVPN

 

WSTĘP

Omówimy tu sieci VPN utworzone z wykorzystaniem bezpłatnego oprogramowania OpenVPN. Krótko zajmiemy się teorią i skupimy w głównej mierze na praktycznej implementacji dwóch scenariuszy wykorzystania tej technologii.

 

Czym są sieci VPN

Skrót oznacza Wirtualną Sieć Prywatną (ang. Virtual Private Network) czyli swego rodzaju tunel (lub tunele), odizolowany od publicznej sieci (zazwyczaj Internetu), pozwalający wymieniać się ruchem sieciowym.

Zwykle z określeniem VPN wiąże się bezpieczeństwo i sieci te są realizowane w taki sposób, aby dodać odpowiednią warstwę zabezpieczeń. Aczkolwiek nie jest to element niezbędny.

Istnieją implementacje, które pozwalają się ograniczyć tylko do enkapsulacji ruchu czyli „pakowania” go w taki sposób aby można było ruch przesłać przez sieć publiczną. Nie zapewniają żadnych zabezpieczeń – nie ma szyfrowania, autoryzacji ani uwierzytelnienia. Może się to wydawać nierozsądne, ale istnieją scenariusze, kiedy może się to przydać (np. fizyczna izolacja sieci czy szyfrowanie w innej warstwie) i wtedy głównym zyskiem jest wydajność takiej transmisji. Co ciekawe OpenVPN, o którym traktuje artykuł, pozwala także na wyłączenie wszystkich takich mechanizmów i pozostawienie „gołej” enkapsulacji.

 

Do czego można wykorzystać sieci VPN?

Tego typu rozwiązanie przydatne jest w wielu sytuacjach. Można przypuszczać, że najczęstszą i najpopularniejszą jest połączenie pracownika z centralnym biurem i jego zasobami – serwerem WWW, plików czy baz danych. Autor wykorzystuje go we własnej pracy do zapewnienia bezpiecznego dostępu do firmowej aplikacji CRM na wewnętrznym serwerze WWW oraz dostępu do oprogramowania finansowo-księgowego Symfonia.

Innym typowym rozwiązaniem jest połączenie zdalnego oddziału do centrali firmy i oprócz zdalnego dostępu do zasobów i aplikacji, pozwala na robienie kopii zapasowych w odległej lokalizacji. Przydatnym efektem ubocznym jest to, że wystarczy znać adres IP serwera (koncentratora VPN), natomiast adres IP stacji klienckiej (lub routera) może być zmienny. Dzięki temu można wykorzystać usługę dostępu do Internetu, która nie musi zapewniać jego stałości.

Jeszcze innym rozwiązaniem może być wykorzystywanie sieci VPN do „obejścia” translacji NAT. Może się zdarzyć, że za routerem znajduje się kilka maszyn, z którymi jest konieczna bezpośrednia łączność np. poprzez protokół RDP lub VNC. Aby nie robić wielu przekierowań portów, osoba zarządzająca komputerami może się łączyć poprzez VPN do takiej sieci i zarządzać nimi bezpośrednio, a dodatkowo może mieć szyfrowany do nich ruch, czego np. VNC w podstawowej wersji nie zapewnia. Kolejnym przydatnym przeznaczeniem może być tunelowanie całego ruchu poprzez koncentrator VPN, a dzięki temu zapewnienie sobie bezpiecznego dostępu do zasobów Internetu. Oczywiście ruch jest tylko zabezpieczony pomiędzy stacją kliencką a serwerem VPN. Dalej ruch jest przesyłany standardowo – czyli może być łatwy do podsłuchania lub modyfikacji.

 

Czy są naprawdę bezpieczne?

Współczesne implementacje sieci VPN takie jak np. OpenVPN dysponują wieloma mechanizmami, które pozwalają zapewnić bardzo wysoki poziom bezpieczeństwa. Wydawać by się mogło, że hasło i odpowiednie szyfrowanie to elementy wystarczające. Jednakże można wyróżnić trzy filary:

•  uwierzytelnienie (ang. authentication) – sprawdzenie czy dany system komputerowy jest w rzeczywistości tym, za który się podaje – tyczy się to tak samo serwera jak i klienta VPN. Pozwala to zapobiec dwóm niebezpiecznym sytuacjom – kiedy ktoś wejdzie w posiadanie elementu autoryzacyjnego (np. hasła) oraz kiedy następuje próba podszycia się pod serwer (koncentrator) VPN. Do uwierzytelniania zazwyczaj wykorzystywana jest infrastruktura klucza publicznego.

•  autoryzacja (ang. authorisation) – zweryfikowanie czy dany klient ma prawo dostępu do wybranej sieci (zasobu). Może to się odbywać na podstawie hasła, zestawu kluczy, lub jak to często jest implementowane w rzeczywistości – autoryzowany jest klient uwierzytelniony, tj. jeśli udaje nam się ustalić pozytywnie tożsamość klienta VPN, dopuszczamy go do dostępu do naszych zasobów (czyli dostęp do sieci mają znani nam klienci).

•  szyfrowanie (ang. cipher) – polega na zabezpieczeniu ruchu w taki sposób aby nie mógł zostać podsłuchany (poufność) ale także aby nie można było dokonać jego modyfikacji czy wręcz wstrzyknięcia obcej transmisji (integralność).

Ponad te trzy filary istnieją jeszcze inne mechanizmy, które mają zapewnić bezpieczeństwo przesyłanej transmisji. Przykładowo w OpenVPN jest wprowadzony ciekawy mechanizm HMAC (ang. keyed-Hash Message Authentication Code), który wykorzystuje osobny klucz do podpisania każdego pakietu kontrolnego przy uruchamianiu transmisji. Dane, które nie są odpowiednio podpisane takim kluczem są automatycznie odrzucane. Dzięki temu dla osoby z zewnątrz serwer (koncentrator) OpenVPN będzie niewidoczny, gdyż próby połączenia poskutkują takim komunikatem, jakby był zupełnie wyłączony. Jest to doskonałe zabezpieczenie przed atakami DoS, a także przed próbami szpiegowania (np. skanowanie portów w poszukiwaniu serwera OpenVPN). Jednocześnie jest to pewne utrudnienie przy uruchamianiu nowych klientów i znacznie utrudnia diagnostykę , gdyż otrzymujemy fałszywe komunikaty o niedostępności usługi.

Na koniec należy dodać, że sieci VPN są tylko narzędziem, które pozwala uzyskać zakładany cel. Dostarczają one mechanizmy szyfrowania, autoryzacji i uwierzytelnienia. Zapewniają bezpieczeństwo i integralność przesłanych danych. Jednak to my musimy dbać o bezpieczeństwo kluczy serwera oraz centrum certyfikacji, a użytkownicy o bezpieczeństwo swoich urządzeń. Powinny być przygotowane odpowiednie procedury na wypadek kradzieży np. laptopa, a także firewall na serwerze udostępniającym OpenVPN powinien być tak skonfigurowany aby po naszej sieci nie poruszał się zbędny ruch. Przykładowo jeśli używamy w sieci wewnętrznej tylko serwerów WWW, powinniśmy tylko dopuścić ruch na porcie 80, a całą resztę zablokować.

Musimy pamiętać o tym, że to użytkownik zawsze będzie najsłabszym ogniwem naszego systemu i to na jego zachowania powinniśmy zwracać szczególną uwagę. Bez względu na to czy chodzi o działanie świadomie czy nieświadome.

 

Dlaczego akurat OpenVPN?

Jest to wybór czysto subiektywny, wynikający z wieloletniej praktyki. OpenVPN opiera się o instalację jednego programu, a od strony klienckiej konfiguracja jest bardzo prosta. Ponadto protokół wykorzystywany do tworzenia tuneli nie ma większych problemów z pokonywaniem routerów z NATem i firewallami. Dzięki czytelnym logom mamy możliwość łatwej diagnostyki, bez uciekania się do snifferów.

Dużym atutem jest dobre wsparcie w systemach Linux, Windows oraz Mac a także możliwość rozgłaszania pojedynczych tras.

Niestety wadą jest brak właściwego wsparcia na urządzeniach z systemami mobilnymi jak Android (tutaj są wymagane uprawnienia root) i iOS, chociaż to się powoli zmienia. Tutaj alternatywą jest IPsec, którego implementacja jest dużo bardziej skomplikowana i nie pozwala np. rozgłaszać wybranych tras. Ale tak jak wspomniałem na wstępie do tego punktu – jest to wybór subiektywny.

OpenVPN zapewnia nam komplet mechanizmów, który pozwala nam zbudować bezpieczną sieć VPN – autoryzuje, uwierzytelnia, szyfruje i zapewnia integralność przesłanych danych. Ponadto chroni serwer (koncentrator) przed atakami DoS oraz sieć wirtualną przed wstrzykiwaniem obcych danych.

Wszystkie te rzeczy powodują, że OpenVPN jest doskonałym wyborem do większości zastosowań.

 

Typy tuneli

OpenVPN oferuje dwa rodzaje tuneli, których używamy w zależności od konkretnych potrzeb:

tun – tunele, które mają przydzielony po obu stronach adres IP i odbywa się klasyczny routing – wystarczy w większości przypadków takich jak dostęp do sieci firmowej czy do Internetu i takich będziemy używać w opisywanych scenariuszach

tap – tunel w warstwie 2, tutaj są przesyłane ramki pomiędzy końcami tuneli – nie odbywa się routing, a my musimy zapewnić odpowiednią obsługę takiego ruchu (np. serwer DHCP, adresy IP, routing itd.), dużo większe możliwości niż w przypadku tun, ale bardziej rozbudowana konfiguracja, tunele raczej używane rzadko, tylko do szczególnych rozwiązań (np. kiedy zależy nam na protokołach, które wymagają fizycznej spójności sieci np. wykrywanie komputerów w otoczeniu sieciowym Microsoftu, jednakże samo montowanie zasobów jest już możliwe poprzez tun).

 

Infrastruktura klucza publicznego

Proszę mieć na uwadze, że ten podrozdział ma za zadanie jedynie krótko wprowadzić czytelnika w tematykę kluczy, certyfikatów i całej infrastruktury, tak aby jaśniejsze były późniejsze operacje związane z własnym Centrum Certyfikacji. Jest to temat niesamowicie obszerny i nie sposób go wyczerpać w kilku akapitach.

W celu bezpiecznej komunikacji potrzebna była metoda na skuteczne uwierzytelnianie jej uczestników oraz zapewnianie jej integralności. W tym celu stworzono infrastrukturę klucza publicznego czyli zespół elementów pozwalający na tworzenie kluczy, certyfikatów, ich podpisywanie, odwoływanie oraz weryfikację.

Całością zajmuje się Centrum Certyfikacji (ang. Certificate Authority). Jest to zaufana organizacja, której zadaniem jest podpisywanie oraz odwoływanie podpisanych przez siebie certyfikatów. Może to być urząd państwowy, prywatna firma lub nawet pojedyncza osoba zarządzająca certyfikatami w firmie.

CA dysponuje prywatnym kluczem, który służy do podpisywania certyfikatów oraz publicznym certyfikatem, który służy do weryfikowania takich podpisów. Aby była możliwa taka weryfikacja każdy uczestnik transmisji (w tym wypadku serwer i stacja kliencka), muszą mieć zainstalowany certyfikat CA.

Podmiot, który chce posiadać certyfikat podpisany przez CA zaczyna od stworzenia pary – swojego klucza prywatnego i publicznego certyfikatu oraz tworzy tzw. CSR – czyli żądanie podpisania certyfikatu. Następnie CSR jest dostarczone do Centrum Certyfikacji, gdzie po odpowiedniej weryfikacji wnioskodawcy, jest podpisywany certyfikat aplikanta (lub nie jeśli tożsamość podmiotu budzi wątpliwości). Tak podpisany certyfikat zostaje dostarczony wnioskodawcy. Dodatkowo warto zwrócić uwagę na zabezpieczenie jakim jest przeznaczenie certyfikatu (pole nsCertType), które decyduje czy jest to certyfikat kliencki czy serwerowy. Dzięki temu nawet jeśli posiadamy certyfikat podpisany przez nasze CA, ale nie jest on typu serwerowego, to nie uruchomimy własnego serwera. Dzięki temu niemożliwe jest podszycie się klienta z poprawnym certyfikatem klienckim pod koncentrator VPN.

Od tego momentu podmiot może wykorzystywać swój klucz. Oczywiście do zapewnienia bezpiecznej transmisji, konieczne jest aby wszyscy uczestnicy posiadali swoje pary – klucz prywatny oraz podpisany certyfikat. Ich wykorzystanie w uproszczeniu wygląda tak:

•  KLIENT łączy się do SERWERA i przedstawia swój podpisany przez CA certyfikat, SERWER weryfikuje jego poprawność za pomocą certyfikatu CA
•  SERWER przedstawia swój podpisany przez CA certyfikat a KLIENT go weryfikuje na podstawie certyfikatu CA
•  SERWER szyfruje transmisję do KLIENTA za pomocą publicznego klucza KLIENTA, a KLIENT za pomocą swojego prywatnego go odszyfrowuje
•  KLIENT szyfruje transmisję do SERWERA za pomocą publicznego klucza SERWERA, a SERWER za pomocą swojego prywatnego go odszyfrowuje
•  SERWER za pomocą swojego prywatnego klucza podpisuje (zapewnia integralność i pewność pochodzenia) dane do KLIENTA, a KLIENT weryfikuje to za pomocą publicznego klucza SERWERA
•  KLIENT za pomocą swojego prywatnego klucza podpisuje dane do SERWERA, a SERWER weryfikuje to za pomocą publicznego klucza KLIENTA

Istnieje jeszcze opcjonalny krok polegający na sprawdzeniu czy certyfikat partnera transmisji nie został odwołany (ang. revoke) i robi się to za pomocą weryfikacji list CRL, które udostępnia CA na stronie WWW.

Cała procedura zapewnia, że uczestnik transmisji jest tym za kogo się podaje (oczywiście musimy zaufać, że CA dokonało odpowiedniej weryfikacji) oraz że transmisja została zaszyfrowana i zabezpieczona przed modyfikacją przez osoby trzecie.

 

Przykładowa konfiguracja

Przedstawię tutaj dwa scenariusze, które są użytkowane przeze mnie na co dzień i bardzo dobrze się sprawdzają. Pierwszy dotyczy sytuacji, kiedy posiadamy sieć firmową (tzw. intranet), w której jest serwer plików, drukarka sieciowa, serwer WWW itd. Będąc poza miejscem pracy chcielibyśmy uzyskać bezpieczny dostęp do tych zasobów, w taki sposób aby nie narazić tej sieci na dostęp niepowołany czy podsłuchanie naszej transmisji.

Zaczniemy od przygotowania części, która będzie wspólna dla obu scenariuszy – instalacji oprogramowania OpenVPN na serwerze oraz stacji klienckiej, a także przygotowania centrum certyfikacji i za jego pomocą odpowiednich generacja zestawów kluczy i certyfikatów.

Całość jest pokazana na przykładzie Debiana 6.0 (Squeeze). Dla łatwiejszego rozróżnienia serwer ma nazwę ustawioną na server i to on będzie przyjmował połączenia OpenVPN, natomiast client będzie je inicjował.

1. Instalacja OpenVPN

Najpierw instalujemy pakiet OpenVPN, jest to krok identyczny dla serwera jak i klienta:

Dzięki niemu uzyskamy dostęp do dołączonego oprogramowania EasyRSA, które będzie nam potrzebne do tworzenia kluczy i certyfikatów.

2. Własne centrum certyfikacji

Na cele naszego serwera OpenVPN utworzymy własne centrum certyfikacji. Jego celem jest zarządzanie kluczami oraz certyfikatami klienckimi, czyli także ich odwoływanie (ang. revoke), kiedy podejrzewamy że klucz dostał się w niepowołane ręce (np. kradzież sprzętu przenośnego). Nic nie stoi na przeszkodzie, aby centrum certyfikacji było na innym sprzęcie lub wręcz abyśmy korzystali z usług komercyjnego dostawcy, co jednak wiąże się z niemałymi kosztami. Na potrzeby niewielkiej firmy własne CA jest rozwiązaniem wystarczającym.

Skorzystamy z mechanizmu dołączonego do OpenVPN – EasyRSA. Jest to zestaw skryptów, które ułatwiają zarządzanie naszym centrum certyfikacji. Zacznijmy od skopiowania katalogu ze skryptami w inne miejsce, proponuję np. /etc/mojeCA, chociaż oczywiście jest to kwestia prywatnych preferencji, równie dobrze można korzystać z domyślnej lokalizacji tj. /usr/share/doc/openvpn/examples/easyrsa/2.0.

Następnie edytując plik vars w ulubionym edytorze tekstu modyfikujemy parametry w ostatnich liniach:

Są to parametry domyślne wykorzystywane przy tworzeniu certyfikatów, proponuję także trochę wcześniej w pliku zmienić także KEY_SIZE z domyślnej wartości 1024 na 2048, co zwiększy zdecydowanie bezpieczeństwo naszego rozwiązania.

Mając już skonfigurowane EasyRSA, możemy utworzyć nasze CA. Pamiętajmy aby przed używaniem jakichkolwiek skryptów wejść do katalogu a następnie poleceniem source ustawić odpowiednie zmienne, które edytowaliśmy w pliku vars:

Widoczne ostrzeżenie, to tylko przypomnienie aby upewnić się, że podane są właściwe ścieżki, gdyż w wypadku skryptu clean-all jest kasowany katalog keys, a jeśli dokonaliśmy złej konfiguracji, możemy usunąć coś czego nie planowaliśmy. Następnie rozpoczynamy tworzenie CA. Większość pól zatwierdzamy wartością domyślną (warto zauważyć, że są ustawione tak jak w pliku vars). Jedynie jako pole Organizational Unit Name podajemy Centrum Certyfikacji.

Następnie wytwarzamy klucz dla algorytmu Diffie-Hellman. Jest to odpowiednio duża liczba pierwsza wykorzystywana w protokole wymiany kluczy prywatnych wykorzystywanych podczas szyfrowania. Sugerowana wielkość to 2048 bitów i takiej długości będzie to liczba. Robimy to poleceniem build-dh. Może potrwać dość długo w zależności od rozmiaru klucza, gdyż musi być uzyskany odpowiedni stopień entropii (losowości). Na testowej maszynie dla klucza 2048 bitów trwało to około trzech minut.

Na koniec tworzymy jeszcze plik ta.key, który będzie wykorzystywany do polecenia tls-auth, które dodaje dodatkową warstwę zabezpieczenia. Pozwala na weryfikacje spójności pakietów podczas nawiązywania połączenia. Dzięki temu komputer, który nie posiada pliku ta.key nie jest w stanie nawet spróbować nawiązać połączenia, pakiety zostają natychmiast odrzucone. Pozwala to zabezpieczyć się przed próbami wykorzystania błędów w implementacji TLS czy atakami DoS, a także nie pozwala na wykrycie portu na którym działa OpenVPN, gdyż skaner rozpozna go jako zamknięty.

Teraz kiedy przejrzymy zawartość katalogu /etc/mojeCA/keys to znajdziemy tam następujące pliki (ważne z punktu widzenia konfiguracji):

ca.crt – certyfikat naszego CA, ten plik przekazujemy do stacji klienckich, więc jego uprawnienia mogą pozwalać na odczyt przez każdego (chmod 644)

ca.key – plik z kluczem prywatnym naszego CA, musi pozostać odpowiednio zabezpieczony, jego wyciek zagrozi bezpieczeństwu całego systemu certyfikacji, odczyt dozwolony tylko dla właściciela (chmod 600)

dh2048.pem – klucz algorytmu DH, pozostaje jak wyżej również tajny (chmod 600)

Ponadto bezpośrednio w katalogu /etc/mojeCA znajduje się plik ta.key, który też musimy odpowiednio zabezpieczyć (chmod 600), jednakże plik ten będzie rozprowadzany wśród klientów, więc zabezpieczenie dotyczy tylko lokalnych użytkowników serwera OpenVPN tak aby nie uzyskali niepowołanego dostępu do tego pliku. Ten plik oraz dh2048.pem są już częścią konfiguracji serwera OpenVPN. Natomiast ca.crt i ca.key przynależą do centrum certyfikacji.

Krokiem kolejnym jest utworzenie certyfikatu i klucza serwera OpenVPN. Robimy to poleceniem specjalnie do tego przeznaczonym – build-key-server, jako parametr podajemy nazwę, proponuję po prostu server. Jako Organizational Unit podajemy Serwer OpenVPN (to tylko opis w celu rozróżnienia kluczy). Najważniejsze jest kolejne pole tj. Common Name, gdzie wpisujemy nazwę, z którą będą się łączyć klienci. Jeśli mamy swoją firmową domenę możemy przygotować adres w postaci vpn.firma.pl. Tutaj nie mamy żadnej przykładowej domeny, więc podamy słowo server. Ponadto musimy zwrócić uwagę na to, że tworzymy certyfikat serwera za pomocą polecenia build-key-server a nie build-key. To pierwsze ustawia tzw. przeznaczenie certyfikatu nsCertType na „server”. Dzięki temu klienci nie będą mogli być oszukani przez posiadaczy certyfikatu klienckiego, którzy chcieliby zainstalować fałszywy serwer (dba o to linia ns-cert-type server w pliku konfiguracyjnym klientów).

Dodatkową nowością jest pytanie o hasło, które pozostawiamy pustym (w przeciwnym wypadku przy każdym starcie usługi serwera OpenVPN musielibyśmy je podawać) oraz na koniec zapytanie czy zgadzamy się na podpisanie certyfikatu za pomocą naszego klucza CA.

Po tej operacji w katalogu keys pojawiły się pliki server.key i server.crt. Są to kolejne pliki, które będą niezbędne do konfiguracji serwera.

 

Certyfikaty klienckie

Tworzymy pliki certyfikatu oraz klucza dla urządzenia klienckiego. Mamy do wyboru polecenie build-key oraz build-key-pass. Różnią się tym, że to drugie pyta nas o hasło, które w przyszłości będzie musiał podawać klient podczas połączenia. Jest to mocno zalecana metoda ze względu na zmniejszenie ryzyka dostania się do sieci firmowej w sytuacji, gdy ktoś uzyska dostęp urządzenia klienckiego (kradzież, zagubienie). Na przykładzie generujemy pliki z hasłem:

Jako Common Name podajemy nazwę, na podstawie której OpenVPN rozpozna klienta i przekaże mu odpowiednią konfigurację, w praktyce stosuję inicjał i nazwisko np. mmargula, ale tutaj wybraliśmy client.

 

Dodatek: Odwoływanie certyfikatów

W dalszej perspektywie zazwyczaj okazuje się, że będzie potrzebne odwołanie jednego z certyfikatów. Może się tak zdarzyć przy zagubieniu lub kradzieży sprzętu, a także wtedy kiedy dana osoba nie potrzebuje już dostępu do tunelu VPN. Odwołany certyfikat (a razem z nim i klucz) tracą ważność i od tego momentu nie mogą być wykorzystywane do autoryzacji.

Wykorzystujemy do tego polecenie revoke-full podając jako parametr nazwę certyfikatu, który chcemy odwołać. Przed jego wywołaniem oczywiście uruchamiamy source vars, aby wczytać parametry konfiguracyjne.

Od tego momentu w pliku /etc/mojeCA/keys/crl.pem znajduje się lista odwołanych certyfikatów. Musimy o niej jeszcze poinformować serwer OpenVPN, a robimy to dodając poniższą linię do konfiguracji:

crl-verify crl.pem

Po jego dodaniu konieczny będzie restart demona OpenVPN. Od tego momentu przy każdym połączeniu będzie sprawdzana obecność certyfikatu klienta w pliku crl.pem i jeśli się tam znajdzie, połączenie zostanie odrzucone, nawet jeśli wciąż istnieje plik konfiguracyjny dla danego klienta. Co ważne przy odwoływaniu następnych certyfikatów nie będzie już konieczny restart demona, będzie on samoczynnie odczytywał nową wersję pliku crl.pem.

 

Konfiguracja klienta – Linux

Wygenerowane pliki – client.key, client.crt oraz server.crt, ca.crt oraz ta.key – kopiujemy do osobnego katalogu (np. /tmp/client), umieszczamy tam także plik openvpn.conf o treści:

 # Nazwa naszego klucza i certyfikatu
cert client.crt
key client.key

remote 93.94.184.193 1194 # Adres IP i port docelowy
client
fragment 1000
dev tun
proto udp
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ca ca.crt
ns-cert-type server # Upewniamy sie ze laczymy sie z serwerem
tls-auth ta.key 1
cipher AES-256-CBC
verb 3

Jako ciekawostkę można podać fakt, że można podać kilka linijek z parametrem remote. Dzięki temu klient próbuje połączyć się z serwerami OpenVPN w kolejności takiej jak podana w konfiguracji. Autor wykorzystuje z powodzeniem to rozwiązanie w swojej pracy.

Następnie z całości zebranych plików tworzymy archiwum.

zip /tmp/client.zip /tmp/client/*

Przekazujemy tak wygenerowane archiwum osobie, która będzie zestawiała tunel po stronie klienckiej. Pliki najlepiej przekazać osobiście na przenośnej pamięci, dzięki temu będziemy wiedzieć że trafiło to do właściwej osoby i nie będzie ryzyka przechwycenia, które mogłoby się pojawić gdybyśmy je wysyłali pocztą elektroniczną. Zestaw jest na tyle uniwersalny, że działa pod każdym obsługiwanym system operacyjnym (jedynie w przypadku Windowsa konieczna jest zmiana nazwy pliku z openvpn.conf na openvpn.ovpn). W naszym przykładzie rozpakowujemy zawartość katalogu na stacji klienckiej do /etc/openvpn. Próbę uruchomienia klienta OpenVPN odłożymy do momentu, kiedy będzie gotowa konfiguracja po stronie serwera.

Zanim rozpoczniemy dalsze kroki sprawdźmy czy mamy łączność z serwerem OpenVPN za pomocą polecenia ping:

Jak widać wszystko działa poprawnie. Jesteśmy gotowi przejść do dalszej części konfiguracji.

 

Scenariusz 1 – Dostęp do sieci firmowej

W tym scenariuszu mamy sytuację, gdzie sieć firmowa ma adresację 10.100.0.0/24 (maska 255.255.255.0). Klienci OpenVPN, którzy chcą uzyskać do niej dostęp będą mieli przydzielane adresy IP z zakresu 10.0.0.0/24 (maska 255.255.255.0).

Na serwerze tworzymy plik /etc/openvpn/openvpn.conf o treści:

local 93.94.184.193 # Adres IP naszego serwera
port 1194 # Port na którym nasluchujemy
proto udp
dev tun # Rodzaj tunelu
mssfix 1000 # Wartosci dobrane eksperymentalnie
fragment 1000 # Wartosci dobrane eksperymentalnie
keepalive 10 120 # Czestotliwosc pakietow keepalive
ca /etc/mojeCA/keys/ca.crt
cert /etc/mojeCA/keys/server.crt
key /etc/mojeCA/keys/server.key
dh /etc/mojeCA/keys/dh2048.pem
tls-auth /etc/mojeCA/ta.key 0
cipher AES-256-CBC
server 10.0.0.0 255.255.255.0 # Adresy IP klientow
ifconfig-pool-persist ipp.txt
push "route 10.100.0.0 255.255.255.0" # Trasa do sieci firmowej
client-config-dir firma # Katalog ustawien klientow
ccd-exclusive # Dopuszczamy tylko ZNANYCH klientow

Praktycznie wszystkie istotne informacje zawarłem w komentarzach do pliku konfiguracyjnego. Szerszego wyjaśnienia wymaga polecenie push. Jego zadaniem jest przekazywanie poleceń konfiguracyjnych sieci klientom, tutaj przykładowo wysyła żądanie dodania trasy do 10.0.0.0/24 (maska 255.255.255.0) poprzez tunel. Dzięki temu urządzenia klienckie zainstalują sobie taką trasę w tablicy i będą wiedziały jak dotrzeć do sieci wewnętrznej. Pozostały ruch (inny niż do 10.0.0.0/24) będzie nadal wysyłany przez bramę domyślną klienta.

Natomiast jeśli chodzi o wartości mssfix i fragment, odpowiadają one za wielkość przesyłanych pakietów przez tunele i zostały dobrane eksperymentalnie, tak aby działały przez sieci komórkowe. Bardzo ważną jest także dyrektywa ccd-exclusive, która powoduje że będą się mogli łączyć tylko i wyłącznie klienci, którzy mają w katalogu firma swój plik konfiguracyjny o nazwie takiej samej jak Common Name ich certyfikatu. Pozwoli to na czasowe zablokowanie dostępu dla wybranego klienta bez konieczności anulowania jego certyfikatu (revoke). Przy stałej blokadzie nadal zalecanym jest odwoływanie certyfikatu, o czym napiszę dalej.

W polu Cipher wybieramy szyfr i algorytm szyfrowania. Podany przykład wybiera AES z kluczem długości 256 bitów i algorytmem CBC. Jest to połączenie zapewniające dość dobre bezpieczeństwo. Należy mieć jednak na uwadze, że nie wszystkie zestawy są bezpieczne (np. DES lub wręcz none czyli brak szyfrowania). Dokumentacja OpenVPN wyraźnie zaleca wykorzystanie algorytmu CBC, więc wybierając zestawy algorytmów z kluczem 256 nasz wybór ogranicza się do AES-256-CBC i CAMELLIA-256-CBC. AES wybrano jako bardziej znany.

Oczywiście naszym obowiązkiem pozostaje zabezpieczenie dostępu do sieci firmowej w taki sposób aby dopuszczał tylko naszych klientów podłączonych przez OpenVPN, przykładowo można to uzyskać dzięki iptables:

iptables -N FIRMA-przychodzacy
iptables -A FIRMA-przychodzacy -s 10.0.0.0/24 -j RETURN
iptables -A FIRMA-przychodzacy -j DROP

iptables -N FIRMA-wychodzacy
iptables -A FIRMA-wychodzacy -s 10.0.0.0/24 -j RETURN
iptables -A FIRMA-wychodzacy -j DROP

iptables -A FORWARDING -d 10.100.0.0 -j FIRMA-przychodzacy
iptables -A FORWARDING -s 10.100.0.0 -j FIRMA-wychodzacy

Oczywiście jest to bardzo prosty przykład, który przepuszcza tylko i wyłącznie ruch między klientami OpenVPN a siecią wewnętrzną, a pozostały blokuje. Zazwyczaj musi być tutaj jeszcze odpowiednio ustawiony dostęp sieci wewnętrznej do Internetu (jeśli taki jest wymagany). Szczegółowa konfiguracja firewalla wykracza poza tematykę tego artykułu.

Następnie musimy uaktywnić routing pakietów między interfejsami, za pomocą odkomentowania w pliku /etc/sysctl.conf linijki o treści net.ipv4.ip_forward = 1. Następnie za pomocą polecenia sysctl -p aktualizujemy ustawienia. Ich poprawność możemy zweryfikować zaglądając do pliku /proc/sys/net/ipv4/ip_forward – powinna się tam znajdować wartość 1.

Pozostaje nam jeszcze konfiguracja ustawień klienckich po stronie serwera. Do tego celu tworzymy katalog /etc/openvpn/firma, gdzie będą znajdowały się pliki z ustawieniami. Nazewnictwo plików jest wprost powiązane z nazwą umieszczoną w Common Name certyfikatu klienta, dzięki temu serwer wie który plik wykorzystać dla danego połączenia. W naszym przypadku plik będzie się nazywał client i miał następującą postać:

ifconfig-push 10.0.0.5 10.0.0.6

Polecenie to konfiguruje adresy IP tunelu – 10.0.0.5 po stronie serwera oraz 10.0.0.6 po stronie klienta. Musimy mieć jednak na uwadze, że dobór tych adresów nie jest zupełnie dowolny. Pary adresów muszą się znajdować w jednej podsieci /30 (maska 255.255.255.252). Dla ułatwienia przedstawiam pomocny wykaz (pobrany ze strony http://www.imped.net/oss/misc/openvpn-2.0-howto-edit.html#policy):

[ 1, 2] [ 5, 6] [ 9, 10] [ 13, 14] [ 17, 18]
[ 21, 22] [ 25, 26] [ 29, 30] [ 33, 34] [ 37, 38]
[ 41, 42] [ 45, 46] [ 49, 50] [ 53, 54] [ 57, 58]
[ 61, 62] [ 65, 66] [ 69, 70] [ 73, 74] [ 77, 78]
[ 81, 82] [ 85, 86] [ 89, 90] [ 93, 94] [ 97, 98]
[101,102] [105,106] [109,110] [113,114] [117,118]
[121,122] [125,126] [129,130] [133,134] [137,138]
[141,142] [145,146] [149,150] [153,154] [157,158]
[161,162] [165,166] [169,170] [173,174] [177,178]
[181,182] [185,186] [189,190] [193,194] [197,198]
[201,202] [205,206] [209,210] [213,214] [217,218]
[221,222] [225,226] [229,230] [233,234] [237,238]
[241,242] [245,246] [249,250] [253,254]

Ograniczenie to jest narzucone przez wymóg kompatybilności z klientami w systemach operacyjnych serii Windows. Ogranicza to ilość tuneli w jednej puli /24 do 64 sztuk, ale zawsze możemy taką pulę powiększyć.

 

Uruchomienie klienta

Dostarczamy na stację kliencką plik client.zip i rozpakowujemy go do katalogu /etc/openvpn, a następnie uruchamiamy:

Widać tutaj pytanie o hasło, które podawaliśmy podczas tworzenia certyfikatu i klucza klienckiego. Po odczekaniu kilkunastu sekund połączenie powinno być nawiązane. Weryfikujemy to sprawdzając czy został założony interfejs tun0, zainstalowane zostały odpowiednie trasy oraz próbując pingować adres z sieci firmowej:

Wszystko wskazuje na to, że całość działa poprawnie. Jeśli jednak masz jakieś problemy polecam zajrzeć do rozdziału Diagnostyka.

 

Scenariusz 2 – Dostęp do Internetu przez tunel

Drugi scenariusz dotyczy sytuacji, kiedy podłączamy się do Internetu z sieci, której nie ufamy np. publicznego punktu WiFi. Chcąc zabezpieczyć przesyłane przez nas dane, możemy je tunelować do zaufanego punktu – naszego serwera OpenVPN. Jest to istotne ze względu na to, że nie zawsze mamy wpływ na to w jakiej postaci dane przesyłają aplikacje zapisane na naszym komputerze (chodzi zazwyczaj o różnego rodzaju komunikatory). Tunelując ruch unikamy ryzyka ataku Man In The Middle wykonywanego w sieci, z której obecnie korzystamy, gdyż weryfikacja certyfikatów zapobiegnie takiej sytuacji. Także zabezpieczamy się przed podsłuchem naszego ruchu wysyłanego między klientem a serwerem VPN.

Oczywiście musimy mieć na uwadze bardzo ważną rzecz – ruch szyfrowany jest tylko do naszego serwera, a później od niego wychodzi już w takiej postaci w jakiej nadają je programy zainstalowane na naszym komputerze. Czyli uruchamiając połączenie przez telnet i tak istnieje ryzyko jego podsłuchania na odcinku między naszym serwerem OpenVPN, a adresem IP do którego poprzez telnet się łączymy. Krótko mówiąc – to nie jest uniwersalne rozwiązanie na nasze bolączki, wskazany jest jak zawsze zdrowy rozsądek.

Konfiguracja serwera różni się praktycznie dwoma linijkami, pierwsza która zajmuje się wysyłaniem tras do klienta. W tym wypadku zmieniamy tą linię na push „route 0.0.0.0 0.0.0.0”, która spowoduje że od tego momentu będziemy także wymuszać na klientach dodanie bramy domyślnej wskazującej na koniec tunelu po stronie serwera. Druga natomiast to push „redirect-gateway”, która nakazuje przekierowywanie całego ruchu do tunelu VPN. Dzięki temu cały ruch trafi właśnie tam. Dodatkowo musimy zapewnić obsługę tego ruchu, np. poprzez prosty NAT:

iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j SNAT \
–-to 93.94.184.193

Oczywiście jest to najprostszy możliwy przykład i w rzeczywistości będzie bardziej rozbudowany, ale ponownie wykracza to poza tematykę tego artykułu.

Tak jak w pierwszym scenariuszu musimy teraz sprawdzić czy pojawił się interfejs tun0, brama domyślna oraz jak wygląda trasa do wybranego punktu w Internecie:

Widać, że ruch jest kierowany przez adres IP 10.0.0.1, który należy do serwera OpenVPN. Wszystko działa więc poprawnie.

 

Dodatek: Konfiguracja klienta pod systemem Windows

Jako dodatek przedstawiam jak krok po kroku ustawić komputer działający pod kontrolą systemu Windows. Instalujemy klienta o nazwie OpenVPN GUI ze strony www.openvpn.net.

Proces instalacyjny jest bardzo prosty, dlatego ograniczę się do opisu słownego bez dodatkowych zrzutów ekranu. Po ściągnięciu instalatora, uruchamiamy go i w pierwszym oknie wybieramy Next. W kolejnym pojawia się licencja, gdzie klikamy I Agree. Dalsze okienko pozwala wybrać elementy, które chcemy zainstalować, ale zostawiamy je domyślnie i klikamy Next. Przy pytaniu o ścieżkę instalacji zostawiamy tą domyślną lub wybieramy inną jeśli jest taka nasza wola, a następnie klikamy Next. Po chwili program się zainstaluje i w tym oknie również dajemy Next. W ostatnim odznaczamy Show Readme i dajemy Finish.

Następnie do podkatalogu config w katalogu którym został umieszczony program (domyślnie jest to C:\Program Files\OpenVPN) rozpakowujemy plik client.zip, który utworzyliśmy wcześniej dla klienta linuksowego. Musimy jeszcze zmienić nazwę pliku konfiguracyjnego z openvpn.conf na openvpn.ovpn tak aby program je rozpoznał. Zrzuty ekranu są dla Windowsa XP, w innych wersjach instalacja może się różnić, w szczególności jeśli chodzi o ustawianie właściwych uprawnień.

Następnie po instalacji i uruchomieniu programu, klikamy prawym klawiszem myszy jego ikonę w zasobniku systemowym i wybieramy Connect:

A następnie podajemy hasło przyporządkowane naszemu kluczowi:

Po prawidłowo nawiązanym połączeniu ikona OpenVPN w zasobniku przybierze kolor zielony. Następnie za pomocą programu tracert możemy zweryfikować, którędy przesyłany jest ruch do Internetu (tutaj przykładowo dla scenariusza 2, czyli tunel dla całego ruchu):

Na koniec możemy spróbować wejść na stronę, która podaje nasz adres IP, osobiście używam strony http://www.pokapoka.pl/ ale może też być np. http://whatismyipaddress.com/. Powinien tam się pojawić adres IP naszego serwera OpenVPN. Wtedy wiemy, że ruch do Internetu odbywa się poprzez tunel, a sam serwer przeprowadza właściwie translację NAT:

 

Diagnostyka

Jeśli mimo wszystko mamy problem ze zestawieniem naszego tunelu jest kilka kroków, które powinniśmy sprawdzić, zazwyczaj jest to wystarczające.

1. W konfiguracji serwera i klienta powinny być zbieżne najważniejsze elementy takie jak fragment oraz cipher
2. Na serwerze w katalogu z konfiguracjami klientów powinien znajdywać się plik o nazwie takiej samej jak Common Name w certyfikacie klienta
3. Wykorzystywanie pliku ta.key i odpowiednia z nim związana konfiguracja, to jest szczególnie ważne, gdyż w przypadku pominięcia tego ustawienia po stronie klienckiej, skutek będzie taki jakby nie było połączenia sieciowego między klientem a serwerem (pakiety są odrzucane).
4. Jeśli tunel się łączy, ale nie przechodzi przez niego żaden ruch, zazwyczaj nie jest włączony IP forwarding na serwerze OpenVPN i/lub NAT.

 

Uwagi końcowe

Zazwyczaj stosuję w praktyce rozwiązanie z dwoma instancjami OpenVPN – jedna do kontaktu tylko z zasobami firmowymi na porcie 1194, a druga na porcie 1195 która rozprowadza dostęp do Internetu. Jest to konfiguracja trochę bardziej skomplikowana, ale pozwala na elastyczny dostęp do wewnętrznej sieci. Wymaga osobnych adresacji dla obu tuneli.

Stosując rozwiązanie z rozsyłaniem bramy domyślnej, musimy mieć na uwadze że daje to dostęp także do każdej sieci wewnętrznej podłączonej do serwera OpenVPN, chyba że właśnie o to nam chodzi. W przeciwnym wypadku konieczna jest szczegółowa konfiguracja firewalla.

Bibliografia

• http://openvpn.net/index.php/open-source/documentation/howto.html
• http://openvpn.net/index.php/open-source/documentation/security-overview.html
• http://www.imped.net/oss/misc/openvpn-2.0-howto-edit.html
• http://www.rsa.com/rsalabs/node.asp?id=2248

— Michał Margula (michal<<at>>margula.pl)