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ę.
Comentarios