Tags Posts tagged with "openvpn"

openvpn

przez -
0 2068
Konfiguracja OpenVPN - slider

Na naszym portalu pojawiły się do tej porty dwa artykuły o OpenVPN. Jeden opisuje dokładną konfigurację serwera OpenVPN pod CentOS oraz na Windowsie. Drugi natomiast dotyczy dodania usługi w programie NetworkManagere. O ile w pierwszym przypadku wszystko działa od razu po konfiguracji, o tyle pod Linuksem są ogromne problemy z utrzymaniem połączenia. Dokładniejsza analiza dokonana przez nasz zespół wykryła opcji Keepalive i Ping, przez co nasze połączenie jest zrywane po pewnym czasie z serwerem. Zgłosiliśmy szybko owy błąd i powiedziano nam, abyś cierpliwie czekali.

Kilka dni temu deweloper Federico Mena Quintero dodał odpowiednie opcje do kodu NetworkManagera (network-manager-openvpn-bgo651657.patch), które potrafią poprawnie importować i eksportować następujące opcje z pliku konfiguracyjnego OpenVPN: ping, ping-exit, ping-restart, keepalive. Można by rzec, że funkcje dostępne od wielu lat pod Windowsem, do Linuksa są dodawane z dużym opóźnieniem. Niestety, nadal musimy czekać na dodanie odpowiednic opcji w graficznym interfejsie.

przez -
4 1488
OpenVPN logo

Społeczność projektu OpenVPN poinformowała o szybkim wydaniu OpenVPN 2.2.3 i OpenVPN 2.3.6. Pod koniec listopada użytkowniczka Dragana Damjanovic poinformowała deweloperów o krytycznym błędzie bezpieczeństwa typu Denial of Service w usłudze serwera OpenVPN (CVE-2014-8104). Wykorzystanie tej podatności przez uwierzytelnionego użytkownika, powoduje niedostępność usługi, poprzez wysłanie zbyt krótkiego Packet Data Control Channel (PDCCH) do serwera. Błąd występuje we wszystkich wydanych wersjach OpenVPN 2.x od 2005 roku.

Problem dotyczy tylko serwera OpenVPN (nie klientów). Nie są zagrożone również dane przesyłane do serwera, ani klucze użytkowników. Błąd pozwala jedynie na unieruchomienie usługi OpenVPN, w dodatku użytkownik przesyłający złośliwy pakiet, musi już być uwierzytelniony. Z tego powodu na atak najbardziej narażeni są dostawcy usług VPN.

Problem dotyczy wszystkich wersji OpenVPN 2.x wydanych po 2005 roku. Wersja OpenVPN 3.x nie jest narażona na ten atak.

Twórcy zalecają natychmiastową aktualizację, poprzez pobranie najnowszej wersji z oficjalnej strony lub z brancha master w oficjalnym repozytorium Git.

Zapraszamy także do zapoznania się z naszym artykułem o konfiguracji OpenVPN.

przez -
33 2649
OpenVPN logo

OpenVPN to zestaw oprogramowania, implementujący technikę tworzenia bezpiecznego połączenia punkt-punkt lub strona-strona w sieciach routowanych lub mostkowanych. W artykule zajmiemy się skonfigurowaniem połączenia do już gotowego serwera VPN, używając do tego NetworkManagera.

OpenVPN to zestaw oprogramowania, implementujący technikę tworzenia bezpiecznego połączenia punkt-punkt lub strona-strona w sieciach routowanych lub mostkowanych. Umożliwia on przekierowanie całego ruchu IP wykorzystując tylko jeden port do komunikacji klient-serwer. Jest to świetne narzędzie do szyfrowania przesyłanych informacji, wykorzystujące do tego celu biblioteki OpenSSL oraz protokołów SSLv3/TLSv1.

Na naszym portalu znajduje się bardzo ciekawy artykuł: Konfiguracja OpenVPN autorstwa Gerarda Stańczaka, który zgłębia tajniki konfiguracji, działania i wydajności, w tym utworzenie własnego serwera VPN.

W dzisiejszym artykule zajmiemy się głównie skonfigurowaniem połączenia do już gotowego serwera VPN, z poziomu systemu Xubuntu, używając do tego NetworkManagera.

Na początek sprawdźmy, czy mamy następujące pakiety: libpkcs11-helper1, network-manager-openvpn, openvpn, openvpn-blacklist. Jeżeli brakuje jakiegoś, to należy go zainstalować (w przypadku Xubuntu trzeba doinstalować wszystkie po kolei).

W menu NetworkManagera należy wybrać: Połączenia VPN -> Skonfiguruj VPN. Otworzy się nam nowe okno Połączenia sieciowe, z którego wybieramy Dodaj. Otworzy nam się okno, z którego możemy wybrać nowe połączenie OpenVPN lub zaimportować zapisaną konfigurację VPN.

Import konfiguracji pozwala na wybranie dwóch rodzajów plików: jeden z rozszerzeniem .opvpn (plik konfiguracyjny OpenVPN GUI pod Windows), a drugi .conf (plik z eksportu NetworkManagera). Nowe połączenie OpenVPN otworzy nam okno, z którego będziemy mogli wybrać typ Uwierzytelniania oraz wpisać nazwę naszej Bramy.

My zrobiliśmy uwierzytelnianie z Certyfikatem (TLS), oraz uzupełniliśmy odpowiednie pola w Zaawansowanych opcjach, w tym: Ogólne, Zabezpieczenia, Uwierzytelnianie TLS i Pośredniki. W przypadku wybrania Klucza statycznego, nie mamy zakładki Uwierzytelnianie TLS.

Po wypełnieniu wszystkiego poprawnie, zapisujemy i z poziomu ikonki NetworkManagera klikamy Połączenia VPN -> OpenVPN. Po chwili powinniśmy otrzymać komunikat poprawnego nawiązania połączenia.

Uwaga!
Zauważyliśmy, że wtyczka OpenVPN w NetworkManager nie posiada obsługi opcji Keepalive i Ping, przez co nasze połączenie jest zrywane po pewnym czasie. Chwilowym obejściem tego problemu jest uruchomienie polecenia ping na adres naszej bramy, zaraz po nawiązaniu połączenia.

Zaczęliśmy szukać, dlaczego brakuje tych funkcji i natrafiliśmy na 4 letnią propozycję dodania opcji Keepalive lub Ping, które można ustawić oraz byłyby obsługiwane podczas wczytywania gotowego pliku konfiguracyjnego: Bug 651657 – OpenVPN – unable to specify values for “ping” or “ping-exit” or related options. Skontaktowaliśmy się także z deweloperami projektu, którzy obiecali w ciągu najbliższych kilku tygodni dodać odpowiedni kod.

przez -
2 1141
OpenVPN logo

Wydano stabilną wersję OpenVPN 2.3.0 – oprogramowania służącego do zestawiania szyfrowanych tuneli VPN pomiędzy dwoma urządzeniami. W porównaniu z ostatnią stabilną wersją 2.2, wydaną w grudniu 2011 roku, dodano wiele nowych funkcji m.in. wsparcie dla IPv6, translacji NAT po stronie klienta (przydatnej w sytuacji gdy występuje konflikt w adresacji IP), czy nowego API dla pluginów i zewnętrznych aplikacji.

Do pozostałych zmian należy zaliczyć:

  • Obsługę PolarSSL – biblioteki kryptograficznej będącej alternatywą dla OpenSSL
  • Przebudowany system kompilacji, ułatwiający instalację pod Windows oraz platformy skrośne (cross-compilation)
  • Poprawioną autoryzację z wykorzystaniem PAM
  • możliwość importowania prywatnego klucza klienta ze zdalnej lokalizacji, np interfejsu zarządzającego (--management-external-key).
  • oznaczanie szyfrowanych danych w specjalny sposób, przydatne przy ustalaniu zaawansowaniego routingu dla wysyłanych pakietów (tylko pod Linux, opcja --mark)
  • Poprawioną obsługę UTF-8 z zachowaniem wstecznej kompatybilności
  • możliwość użycia pola certyfikatu X509 innego niż CN w celu identyfikacji (-- x509-username-field)
  • automatycznie usuwanie trasy routingu nieaktywnej przez długi okres czasu, celem zmniejszenia rozmiaru dynamicznej tablicy routingu (--stale-routes-check)
  • Poprawki dla znalezionych błędów oraz wydajności aplikacji.

W celu aktualizacji dla systemów Windows przygotowano instalator, dla systemów Debian, Ubuntu, Fedora oraz RHEL/CentOS/Scientific Linux 6 zaktualizowano repozytorium OpenVPN. Pliki źródłowe można pobrać ze strony projektu.

OpenVPN logo

VPN kojarzony jest głównie z zastosowaniami biznesowymi gdzie za jego pośrednictwem łączy się oddalone od siebie sieci firmowe jak również z usługami anonimizującymi pozwalającymi na ukrycie tożsamości. Jest to również dobre narzędzie do szyfrowania przesyłanych informacji. W odróżnieniu od tunelowania SSH czy proxy umożliwia przekierowanie całego ruchu IP wykorzystując tylko jeden port do komunikacji klient-serwer. Jest to zatem doskonała recepta na publiczne hot spoty i ograniczenia napotykane w zaporach ogniowych. Dodatkowo, mając jedynie komputer z publicznym adresem IP, można korzystać z takiej usługi za darmo, budując ją w oparciu o otwarte oprogramowanie OpenVPN.

Konfiguracja OpenVPN - tunel VPN

Jako przykładową konfigurację użyjemy serwera z systemem GNU/Linux oraz klienta z systemem Windows oraz Linux. Wybór pomiędzy metodami uwierzytelniania i trybem przekazywania pakietów jest pozostawiony użytkownikowi.

Instalacja

Zarówno klient jak i serwer OpenVPN składają się na ten sam pakiet. Kod źródłowy można pobrać z openvpn.net, lub też ściągnąć i zainstalować bezpośrednio z repozytoriów. Po stronie serwera potrzebujemy również pakietu bridge-utils, jeśli chcemy używać trybu mostkowego(tap), zamiast routowania(tun).

Wersja dla Windows także zawiera serwer i klient w jednym, oraz dodatkowo nakładkę graficzną (OpenVPN GUI), która pozwala na łatwe przełączanie się między profilami połączeń. Sama instalacja nie powinna sprawiać wielu problemów, przechodzimy zatem do konfiguracji.

Konfiguracja

OpenVPN jest uruchamiany w trybie serwera, albo w trybie klienta, w zależności jaki plik konfiguracyjny podamy mu jako parametr. W przypadku systemów Windows pliki konfiguracyjne mają rozszerzenie .ovpn i znajdują się w C:\Program Files\OpenVPN\config, w przypadku systemów Unix domyślnie jest to .conf i katalog /etc/openvpn. Tuż po instalacji katalogi te są puste i należy utworzyć pliki konfiguracyjne ręcznie (lub posłużyć się plikami przykładowymi ze strony OpenVPN: server.conf, client.conf, które stanowią dobry punkt startowy). Dwie główne decyzje jakie należy podjąć, to metoda uwierzytelniania oraz wybór pomiędzy trybem routowania oraz mostka (bridge).

Przykładowy plik konfiguracyjny (dla klienta – client.conf/ovpn)

client #wskazuje że uruchamiamy openvpn jako klient
dev tun #wykorzystujemy tryb routowania(tun) lub bridge(tap)
proto udp #protokół udp (domyślnie) lub tcp
remote hostname.com 1194 #adres serwera, ip lub dns, oraz port (1194 domyślnie)
ca ca.crt #weryfikacja z użyciem certyfikatów
cert client.crt
key client.key

Przykładowy plik konfiguracyjny (dla serwera – server.conf/ovpn):

#wskazujemy ze openvpn ma być uruchomiony jako serwer w trybie tun
# z podsiecią łączącą 10.8.0.0/24 oraz weryfikować użytkowników w oparciu o certyfikaty
dev tun
port 1194
proto udp
server 10.8.0.0 255.255.255.0
ca ca.crt #weryfikacja z uzyciem certyfikatów
cert server.crt
key server.key
dh dh1024.pem

W dalszej części artykułu zajmiemy się uwierzytelnianiem oraz trybem routowania.

Uwierzytelnianie

OpenVPN oferuje kilka metod uwierzytelniania użytkowników, najczęściej spotykane to z użyciem pliku klucza (identycznego dla klienta i serwera) oraz z użyciem certyfikatów (Public Key Infrastructure – PKI). Użycie pliku klucza jest najprostszym i najszybszym rozwiązaniem, ale ma również pewne wady. Jego użycie ogranicza się praktycznie do jednego urządzenia-klienta, a w przypadku przejęcia klucza (który po stronie klienta trzymany jest w formie niezaszyfrowanej), oznacza ryzyko rozkodowania transmisji. Wymaga też, by klucz został dostarczony do klienta w bezpieczny sposób, tj nie ma możliwości wygenerowania go lokalnie (w przypadku PKI jest to możliwe). Użycie pliku klucza ma zatem uzasadnienie, gdy:

  • poza nami nikt nie będzie się łączył do naszej sieci
  • podłączamy się z zaufanej maszyny
  • chcemy w sposób szybki i prosty skonfigurować działającą sieć

Całość sprowadza się do wykonania polecenia (na serwerze bądź kliencie) openvpn --genkey --secret static.key, a następnie skopiowania wynikowego pliku na maszynę klienta i serwera. Do pliku konfiguracyjnego obu stron należy dodać linijkę:

secret sciezka_do_static.key

która wskazuje na lokalizację pliku klucza.

Uwierzytelnianie przy użyciu certyfikatów, jest ciut bardziej skomplikowane i wymaga pewnego przygotowania. Sprowadza się do wygenerowania głównego certyfikatu oraz klucza (root CA), w oparciu o które będziemy mogli generować certyfikaty dla serwerów i klientów. Ma to uzasadnienie, gdy chcemy dokładnie weryfikować czy maszyna, z którą się łączymy jest tą, za którą się podaje oraz daje możliwość większej kontroli nad każdym z klientów z osobna (w tym odwoływanie dostępu, bez konieczności przebudowy całej infrastruktury). Nie wymaga ono również bezpiecznego połączenia między klientem a serwerem w celu dostarczenia plików klucza – klient sam generuje swój klucz i wysyła prośbę do serwera głównego by ten podpisał jego certyfikat. Warto zatem użyć tej metody gdy:

  • poza nami ktoś jeszcze będzie korzystał z naszego vpn-a
  • potrzebujemy większego poziomu bezpieczeństwa (np. możliwość zablokowania klucza w razie jego utracenia)
  • klucz klienta nie może zostać dostarczony w bezpieczny sposób (brak bezpiecznego połączenia)

Zaczynamy od skopiowania skryptów powłoki które znacznie ułatwiają cały proces

cp -R /usr/share/doc/openvpn/examples/easy-rsa/2.0/ /etc/openvpn/easy-rsa
cd /etc/openvpn/easy-rsa

(ścieżki mogą się różnić – w zależności od użytej dystrybucji)

Następnie edytujemy plik vars i podmieniamy domyślne wartości które mają być widoczne w certyfikatach (warto to zrobić teraz by uniknąć ponownego wpisania ich później). Możemy też zwiększyć długość klucza RSA z 1024 (domyślne) do 2048 bitów.

Po edycji wykonujemy polecenia:

source ./vars
./clean-all

Powyższe polecenia wygenerują klucze oraz certyfikaty dla maszyny certyfikującej (CA), serwera oraz jednego klienta. W każdym przypadku można zaakceptować domyślne wartości i wybierając na końcu opcję zatwierdzenia certyfikatów ("Sign the certificate? [y/n]" oraz "x out of x certificate requests certified, commit? [y/n]"). Istotne jest by używać unikalnych nazw dla serwerów/klientów (tutaj użyto fraz „server” oraz „client1” ). Ostatnie polecenie wygeneruje plik zawierający dane przeznaczone dla protokołu Diffiego-Hellmana.

./build-ca
./build-key-server server
./build-key client1
./build-dh

W wyniku powyższych poleceń zostanie utworzony katalog keys, w którym będą się znajdowały pliki certyfikatów (z rozszerzeniem .crt) i prywatne pliki kluczy (z rozszerzeniem .key) oraz plik dfX.pem (gdzie X to domyślnie 1024 bity). Pliki .csr odnoszą się do sytuacji gdy generujemy plik klucza z dala od maszyny certyfikującej (posiadającej plik ca.key), czyli w sytuacji gdy nie mamy możliwości dostarczenia klucza do serwera/klienta w bezpieczny sposób. W tym przypadku robimy wszystko na tej samej maszynie, więc nie są one nam potrzebne (w pewnym sensie nie korzystamy tutaj z tego przywileju jaki daje nam architektura PKI).

Następnie dostarczamy odpowiednie pliki do odpowiednich urządzeń:

  • do serwera: ca.crt, dhX.pem, Server.crt, Server.key
  • do maszyny podpisującej certyfikaty (w naszym przypadku również jest to serwer): ca.key
  • do klienta/ów: ca.crt , clientX.crt, clientX.key

Pliki certyfikatów (.crt) mogą być publicznie dostępne, pliki kluczy (.key) są przeznaczone tylko dla tego dla kogo zostały wygenerowane, i powinny być trzymane w ukryciu (a zwłaszcza plik ca.key)

Na koniec umieszczamy odpowiednie wpisy w plikach konfiguracyjnych

  • po stronie serwera (w pliku server.conf)
    ca sciezka_do_ca.crt
    cert sciezka_do_server.crt
    key sciezka_do_server.key
    dh sciezka_do_dh1024.pem
  • po stronie klienta (w pliku client.conf/client.ovpn)
    ca sciezka_do_ca.crt
    cert sciezka_do_client.crt
    key sciezka_do_client.key

Jeśli zajdzie potrzeba odwołania któregoś z podpisanych certyfikatów wystarczy wykonać

./revoke-full <identyfikator klienta>

w wyniku którego do katalogu keys zostanie zapisany plik ctr.pem, do którego ścieżkę należy podać w konfiguracji serwera: crl-verify crl.pem

dev tun vs dev tap

OpenVPN umożliwia nam podłączenie się do naszej sieci na dwa sposoby – w trybie routowania (tun) oraz w trybie mostkowania, czyli bridge (tap).

Konfiguracja OpenVPN - bridge

W trybie bridge (tap) jesteśmy podłączeni bezpośrednio do sieci LAN serwera, otrzymując IP z tej samej podsieci co reszta urządzeń. Wymaga to zestawienia mostka pomiędzy wirtualnym interfejsem OpenVPN (tap0) oraz interfejsem mającym dostęp do sieci LAN serwera (np eth0). Pozwala na to m.in. narzędzie brctl, znajdujące się w pakiecie bridge-utils.

Konfiguracja OpenVPN - route

W trybie routowania (tun) tworzona jest osobna prywatna podsieć, która łączy się z siecią po stronie serwera, ustalając statyczny routing. Po podłączeniu otrzymujemy adres z innej podsieci, niż ta docelowa, przez co przynależymy do osobnej domeny rozgłoszeniowej. Jest to z reguły prostsze i mniej kłopotliwe rozwiązanie, aniżeli ustanawianie mostka, ale powoduje też, że takie usługi jak otoczenie sieciowe lub zasoby dyskowe Windows nie będą dla nas dostępne (za wyjątkiem samby, która umożliwia ominięcie tego ograniczenia).

Jeśli nie potrzebujemy dostępu do zasobów w ramach domeny rozgłoszeniowej i nie wykorzystujemy OpenVPN do uruchamiania usług opartych LAN (np. serwerów gier), to lepiej korzystać z dev tun (również z punktu widzenia bezpieczeństwa routing, umożliwia większą kontrolę nad klientami). Do celów przedstawionych w artykule (użycie tunelu VPN do szyfrowania transmisji), tryb routowania (tun) jest wystarczający.

Jeśli chcemy pracować w trybie routowania w konfiguracji serwera musimy zadeklarować:

dev tun
server 10.8.0.0 255.255.255.0

gdzie 10.8.0.0/24 będzie stanowić podsieć, do której będą przynależeć klienci. Istotne jest, by podsieć ta była unikalna, tj nie może się pokrywać z tą, do której aktualnie przynależymy (kawiarenka, hot spot), inaczej wystąpi konflikt, przy routowaniu pakietów.

Po stronie klienta wystarczy deklaracja

dev tun

Następnie musimy włączyć przekazywania pakietów między interfejsami (pomiędzy eth0 a tun0). W tym celu wykonujemy polecenie:

echo 1 > /proc/sys/net/ipv4/ip_forward

Zmiana ta będzie brana pod uwagę, do momentu restartu systemu. Aby zastosować ją na stałe należy edytować plik /etc/sysctl.conf oraz zmienic wartość net.ipv4.ip_forward na 1.

Dodatkowo musimy zadbać aby pozostałe hosty w sieci wiedziały jak się z nami komunikować. Ponieważ używamy dodatkowej sieci łączącej (10.8.0.0) musimy ustanowić statyczny routing na bramie sieciowej (np routerze) kierujący do sieci vpn (10.8.0.0) przez maszynę z uruchomionym demonem openvpn. Krok ten wykonujemy tylko jeśli serwer openvpn i brama domyślna dla innych urządzeń (router) nie są tym samym urządzeniem. Alternatywnie można posłużyć się NAT (o którym za chwilę).

W sytuacji, gdy chcemy zastosować mostek (dev tap), musimy mieć zainstalowany w systemie pakiet bridge-utils (a konkretnie mieć do dyspozycji narzędzie brctl). Proces tworzenia i usuwania mostka możemy zautomatyzować, korzystając ze skryptu znajdującego się na stronie OpenVPN. W skrypcie startowym należy podmienić adresy IP, na odpowiadające im ustawienia interfejsu eth0 (przyłączonego do sieci LAN po stronie serwera, chcemy by br0 „przejął” adres IP i maske eth0). W skrypcie usuwającym mostek, zalecałbym również dodanie na końcu:

service networking restart

Jest to istotne, gdyż skrypt ten usunie adresy IP interfejsów eth0 oraz tap0, połączy je (utworzy most) w jeden interfejs br0 (bridge), a przy usuwaniu nie przywraca adresacji do pierwotnej postaci (przez co możemy utracić połączenie).

W pliku konfiguracyjnym serwera podajemy:

dev tap0
server-bridge 192.168.55.10 255.255.255.0 192.168.55.30 192.168.55.40

gdzie pierwszy adres odnosi się do interfejsu br0, a dwa ostatnie adresy to przedział z jakiego przydzielony zostanie adres IP klientom.

Na koniec dodajemy regułki do firewalla, pozwalające na przesył pakietów:

iptables -A INPUT -i tap0 -j ACCEPT
iptables -A INPUT -i br0 -j ACCEPT
iptables -A FORWARD -i br0 -j ACCEPT

Procedura uruchamiania OpenVPN, wygląda w tym przypadku następująco:

  1. wykonujemy skypt start.sh by utworzyć mostek (możemy chwilowo utracić połączenie)
  2. uruchamiamy usługę OpenVPN (/etc/init.d/openvpn start)
  3. zatrzymujemy OpenVPN (/etc/init.d/openvpn stop)
  4. wykonujemy skrypt stop.sh by usunąć mostek

Dodatkowe ustawienia

Jest kilka ustawień, które warto uwzględnić w konfiguracji (klienta i serwera), by poprawić ogólną wydajność i bezpieczeństwo.

  • persist-tun – zachowuje i uwzględnia dodatkowe parametry między restartami usługi
  • persist-key
  • keepalive 10 60 – wysyła ping co 10 sekund z timeout=60s, zmniejsza podatność na przerwanie połączenia
  • comp-lzo – włącza kompresje, zmniejsza zuzycie transferu
  • remote-cert-tls server – ustawiamy tylko w pliku klienta – sprawdza czy pole nsCertType w certyfikacie serwera jest ustawione na „server” (wybór dokonywany przy generowaniu certyfikatu serwera), podnosi bezpieczeństwo
  • Z poniższej opcji można skorzystać jeśli już korzystamy z weryfikacji opartej na certyfikatach. Wykorzystuje ona ten sam mechanizm i jest generowana tak samo jak statyczny plik klucza, dodatkowo zwiększając ochronę przed atakami DoS oraz skanowaniem portów:
    • tsl-auth ta.key 0 – dla serwera
    • tsl-auth ta.key 1 – dla klienta
  • user nobody – zmniejsza uprawnienia procesu, tylko systemy unixowe
  • group nobody
  • cipher AES-256-CBC – jeśli chcemy zwiększyć długość symetrycznego klucza użytego przy szyfrowaniu możemy użyć algorytmu AES z kluczem 256 bitowym

Przekierowywanie pakietów IP przez VPN

Zbliżamy się do sedna artykułu, czyli przekierowywania całego ruchu przez tunel VPN. Na tym etapie powinniśmy mieć już w pełni działające połączenie do serwera (działające pingi), a na wyjściu do Internetu zaszyfrowane pakiety. Konfiguracja jest identyczna dla trybu bridge (tap) jak i routingu (tun).

Dodajemy do pliku server.conf

push "redirect-gateway def1"
push "dhcp-option DNS 8.8.8.8"     #serwery dns google
push "dhcp-option DNS 8.8.4.4"

Instrukcja redirect-gateway modyfikuje tablice routingu w systemie tak, by trasa przez tunel VPN miała niższą metrykę niż na zwykłym interfejsie eth0 (dzięki czemu pakiety będą przekierowywane przez tun/tap).

Na systemie Windows z włączonym UAC, klient musi mieć podniesione uprawnienia (zostać uruchomionym z prawami administratora), by instrukcja redirect-gateway odniosła skutek.

Jeśli korzystamy z trybu routowania (tun) musimy również ustalić translację adresów (NAT) na serwerze. Można to zrobić następująco

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

W większości przypadków, jeśli modyfikujemy plik konfiguracyjny OpenVPN, musimy uruchomić ponownie usługę. Jeśli uruchomiliśmy ją wcześniej, należy wykonać ponowny rozruch.

To tyle, jeśli chodzi o konfigurację. Po wejściu na dowolną stronę sprawdzającą adres IP, powinniśmy być identyfikowani jako serwer a nie komputer, z którego nawiązujemy połączenie. Dodatkowo cały ruch na odcinku klient-serwer jest szyfrowany domyślnie przy użyciu algorytmu Blowfish 128bit.

Wydajność

Krótki test wydajności mający poglądowo pokazać, wpływ tunelowania VPN na prędkość i stabilność przesyłu danych.

Do testów wykorzystałem instancję EC2w chmurze Amazonu, z dostępem do jednego rdzenia procesora Intel Xeon E5430 @2.66Ghz oraz 600MB pamięci RAM (dostępnej dla użytkownika). Serwer oparty na Ubuntu Server Cloud Guest 11.04 64bit z lokalizacją w Irlandii. Testowałem z peryferiów Łodzi, mały lokalny ISP, Internet 6Mb/1Mb

Wykorzystałem trzy scenariusze, jeden stanowiło standardowe połączenie z Internetem (bez vpn), drugi przy przekierowywaniu całego ruchu przez serwery Amazon bez kompresji comp-lzo, trzeci z kompresją. Pobierałem dwa pliki – instalator Mozilla Firefox o ze strony mozilla.org (16.5MB) oraz BitDefender Internet Security 2012 ze strony dobreprogramy.pl (233mb). Statystyki zmierzyłem wgetem. Zmierzyłem też czas odpowiedzi na ping do 4 różnych serwisów (rozmiar pinga standardowy, 10 próbek, podana średnia) oraz 100 pingów do jednego serwisu (celem sprawdzenia niezawodności).

Konfiguracja OpenVPN - pobieranie plików

W przypadku BitDefendera różnica prawie 170kB/s może wynikać z lokalizacji serwera hostującego plik (Polska) oraz kraju do jakiego jest on pobierany (Irlandia). Natomiast w przypadku Firefoxa różnica między pobieraniem z kompresją włączoną, a wyłączoną może być spowodowana charakterystycznym sposobem pobierania – przy kompresji włączonej prędkość pobierania rosła w określonym tempie, a przy wyłączonej od początku ściągane było z maksymalna prędkością. Ponieważ plik był mały, prędkość pobierania nie zdążyła się „rozpędzić”. Test powtórzyłem dla pewności trzy razy – wyniki były podobne.

Konfiguracja OpenVPN - ping

W przypadku pinga wpływ tunelowania powoduje ponad dwukrotny wzrost opóźnienia, ale tak jak wyżej wspomniano – głównym czynnikiem jest tutaj lokalizacja serwera VPN. Jeśli chodzi o komfort przeglądania stron, nie było widać znaczących różnic w szybkości pobierania i prezentowania www, czy też przeglądaniu klipów na Youtube.

Przeprowadziłem również test wysłania 100 ping-ów w domenę Google.pl dla trzech scenariuszy. Każdy z nich posiadał 100% skuteczność oraz średni czas taki jak na wykresie.

Troubleshooting OpenVPN

Oto kilka błędów na które się natknąłem i które mogą się wam przydarzyć w trakcie instalacji / korzystania z OpenVPN:

  • Znaczna część problemów z połączeniem dotyczy ustawień firewalla. Należy sprawdzić czy wirtualny interfejs nie jest filtrowany oraz czy nie są blokowane porty wychodzące dla używanej konfiguracji (domyślnie jest to port 1194 UDP)
  • Jeśli przy uruchamianiu vpn-a otrzymujemy błąd:
    Starting virtual private Network demon : Server failed!
    warto zajrzeć do sysloga po więcej informacji. (/var/log/syslog). W większości przypadków błąd ten dotyczy literówek w plikach konfiguracyjnych lub odnoszeniu się do nieistniejących interfejsów (tap0/tun0).
  • errno=2 lub errno=13 w syslogu – błąd ten może występować w przypadku systemów uruchamianych na OpenVZ. OpenVPN może mieć problem z utworzeniem interfejsu wirtualnego tun/tap. Należy wtedy zrobić to ręcznie korzystając z poniższych poleceń:
    • mkdir –p /dev/net
    • mknod /dev/net/tun c 10 200
    • chmod 600 /dev/net/tun

    Poleceniem cat /dev/net/tun sprawdzamy czy wszystko przebiegło pomyślnie.

  • Jeśli otrzymamy wynik cat: /dev/net/tun: No such device najlepiej skontaktować się z dostawcą VPS po informację czy tworzenie interfejsów tun/tap jest u nich dozwolone.
  • W przypadku problemów z przekierowywaniem pakietów warto sprawdzać systemową tablice routingu by mieć pewność że pakiety są wysyłane tam gdzie powinny (polecenie route pod Unix/Windows). Przykładowa sytuacja – mamy działajace połączenie do interfejsów serwera ale sieć wewnętrzna (oraz Internet jeśli przekierowujemy cały ruch) jest dla nas niedostępna (timeout). Oznaczać to może brak routingu w sieci – należy wtedy ustalić translację adresów NAT lub dodać regułki ręcznie na bramie domyślnej w sieci serwera.

przez -
5 596
Linux Tux

Na zlecenie amerykańskiego Departamentu Bezpieczeństwa Wewnętrznego (DHS) przeprowadzono badania dotyczące liczby luk bezpieczeństwa w kodzie popularnych opensource’owych programów. Specjaliści przyjrzeli się m.in. Sambie, PHP, Perlowi czy Amandzie. Z badań wynika, że w tego typu oprogramowaniu można znaleźć średnio 1 błąd bezpieczeństwa na 1000 linii kodu.

Od czasu, gdy DHS rozpoczął swój projekt poprawiania luk w programach typu Open Source, naprawiono 7826 takich dziur, czyli jedną co dwie godziny.

Departament w marcu 2006 roku zapłacił firmie Coverity 300 000 dolarów za sprawdzenie kodu 180 opensource’owych programów, z których wiele jest używanych przez agendy amerykańskiego rządu.

Przyjrzyjmy się zatem, jak sprawowały się najpopularniejsze z tych programów.

W Sambie znaleziono 236 błędów w 450 000 linii. Tak więc wypada ona znacznie lepiej, niż przecięty opensource’owy projekt. Z tych 236 błędów poprawiono 228.

Bardzo dobrze wypada też Linux. W jądrze 2.6 odkryto 0,127 błędu na 1000 linii. Jądro to składa się z 3 milionów 639 tysięcy 322 linii. Kolejne badania dowiodły, że w ciągu ostatnich dwóch lat developerzy Linuksa usunęli 452 błędy w jądrze, 48 jest potwierdzonych, ale jeszcze niezałatanych, a kolejnych 413 błędów czeka na potwierdzenie i łaty.

Z kolei we FreeBSD znaleziono 1 błąd na 2615 linii kodu, jednak dotychczas twórcy tego systemu nie poprawili żadnego z 605 niedociągnięć.

Serwer Apache składa się ze 135 916 linii, a liczba błędów wynosi 0,14 na 1000 linii. Dotychczas poprawiono 3 błędy, potwierdzono istnienie 7, które jeszcze nie zostały załatane, a 12 dalszych czeka na potwierdzenie i łaty.

Bardzo dobrym rezultatem może poszczycić się system bazodanowy PostgreSQL. Wśród 909 148 linii częstotliwość występowania błędów wynosi 0,041 na 1000 linii. Dotychczas załatano 53 luki znalezione przez Coverity, czyli wszystkie, których istnienie potwierdzono. Na weryfikację i łaty czeka 37 dziur.

Jednak najlepszy wynik osiągnął jeden z najczęściej używanych przez developerów programów, biblioteka glibc. W 588 931 liniach kodu wykryto jedynie 83 błędy, które zostały załatane na bieżąco. Teraz w glibc nie istnieje żaden znany błąd. Podobnie zresztą jak w Amandzie (99 073 linie) i courier-maildir (82 229 linii).

Coverity zbadało też graficzne interfejsy użytkownika.

W KDE w 4 712 273 liniach kodu poprawiono 1554 błędy, zweryfikowano 25, a na potwierdzenie czeka jeszcze 65. Z kolei Gnome w 430 809 liniach poprawiło 357 błędów, potwierdzono istnienie 5, a 214 czeka na weryfikację.

W popularnym OpenVPN znaleziono tylko 1 błąd (na 69 223 linie), ale nie został on jeszcze poprawiony. Z kolei OpenSSL składa się z 221 194 linii kodu. Dotychczas poprawiono 24 luki, 1 potwierdzono, a 24 czekają na weryfikację.

Coverity nie chciał natomiast ujawnić wyników testowania produktów o zamkniętym kodzie. Firma na zlecenie swoich klientów sprawdziła 400 takich produktów. Nasi klienci nie byliby zadowoleni, gdybyśmy ujawnili liczbę błędów w ich kodzie – stwierdzili przedstawiciele Coverity.

Mariusz Błoński

źródło: IT News

Polecane

Jesień Linuksowa

1 667
Polska Grupa Użytkowników Linuksa ma zaszczyt zaprosić na konferencję Jesień Linuksowa 2017, która odbędzie się w dniach 22 – 24 września 2017 roku. Jako...