Autor: Marcin Pietrzak Strona 27 z 41

Założenie miałem bardzo proste.

Jest sobie serwer M który ma mieć tunele z serwerami A i B. Ruch przez tunel ma być skompresowany, a autoryzacja używa certyfikatów SSL.

Pierwszym krokiem było zainstalowanie openvpn’a na wszystkich maszynach, ale ponieważ instalacja szła z pakietów debiana, więc była po prostu nudna, choć samo środowisko w którym rzecz się działa dostarczyło powodów do zastanowienia się. W ramach rozrzucania usług po chrootach, wytworzyłem nowego chroota o dumnej nazwie vpn. Przy okazji grsecurity dał o sobie znać, ponieważ go nie wyłączyłem (jak wyłączyć grsecurity?) to proces zakładanie chroota się nie powiódł.

Po wyłączeniu wszystko poszło jak po maśle i nie było żadnych problemów z dalszą instalacją.

Następnym krokiem jest generacja kluczy. Najprostszym sposobem jest na przygotowanie środowiska jest skopiowanie z katalogu  (podaje cały czas dla ubuntu) :

/usr/share/doc/openvpn/examples/easy-rsa/2.0

w jakąś lokalizację w której łatwo będzie korzystać. Ja przeniosłem ten katalog w takie miejsce:

/etc/openvpn/easy-rsa/

pomijając już „2.0”. W środku znajdziemy narzędzia, które służą do generowania kluczy. Całość zaczynamy od edycji pliku vars, który służy do ustawiania domyślnych wartości dla zmiennych środowiskowych wykorzystywanych w procesie generowania certyfikatów. W moim przypadku uzupełniłem dane związane z wystawiającym oraz zwiększyłem długość klucza do 2048 bajtów, co dokumentacja kwituje krótkim:

Increase this to 2048 if you are paranoid.

Samo generowanie kluczy jest już potem trywialne i sprowadziło się do sekwencji komend:

• . ./vars – ustawienie zmiennych uwaga na kropkę przed, ja się nadziałem – kilka razy zanim zajarzyłem
• ./clean-all – przygotowanie katalogu dla kluczy
• ./build-ca – wygenerowanie klucza CA
• ./build-key-server <nazwa> – zbudowanie klucza serwera
• ./build-dh – zbudowanie Diffie Hellman

Kolejną rzeczą potrzebną do zestawienia tunelu zgodnie z założeniami, jest wygenerowanie kluczy dla serwerów, co wykonujemy powtarzając do wyczerpania komendą:

./build-key client1
./build-key client2
...

Do wystartowania nadal konfiguracji serwera, czyli modyfikacja pliku /etc/openvpn/server.conf, który szczęśliwie jest świetnie opisany i na dodatek większości opcji nie dotykam, bo działa na domyślnych. Zmieniam rzeczy związane z konfiguracją:

• local czyli IP przypisane do tunelu
• port – żeby na standardowym nie wisiało
• dev – explicite podaję nazwę device’a żeby się nie losowało, bo ustawianie reguł na firewall’u przy zmieniającej się nazwie interface’u jest możliwe, ale prościej przy zadeklarowanym
• zmieniam ścieżki do certyfikatów
• server – wybranie i ustawienie odpowiedniej podsieci dla vpn’a
• push – zdefiniowanie IP’ków wpychanych klientowi w ramach routingu
• odkomentowałem comp-lzo w celu zapewnienia kompresji danych w tunelu

Teoretycznie można już wystartować: /etc/init.d/openvpn restart

Start się nie powiódł z powodu błędu z dostępem do /lib/udev/devices/net/tun i nie była to niestety kwestia uprawnień, tylko jak się okazało opcja chroot_deny_mknod nie pozwoliła na dostęp z chroota do tego node’a. Koniec końców chroot został skasowany a openvpn wylądował w głównym systemie.

Kolejna już próba odpalenia servera vpn powiodła się, ale ruch po połączeniu to już nie bardzo. Główną regułą firewall’a jest DROP od której są później wyjątki. I tu przydało się zdefiniowanie nazwy dla interface’u tunelu, bo dzięki temu łatwo dodać regułę: iptables -A INPUT -i tun34 -j ACCEPT dzięki której wszystko co przychodzi z tunelu jest akceptowane.

Kolejne połączenie i wszystko śmiga, czego i Wam życzę.