Najprostszym sposobem postawienia tunelu VPN jest użycie wspólnego klucza. Jednak w bardziej zaawansowanych zastosowaniach się ten sposób nie sprawdzi. Jeśli istnieje potrzeba, aby do sieci firmowej (lub innej) zapewnić równoczesny dostęp wielu użytkownikom, to administrator musi się nieco potrudzić.
Zaczynamy ten opis od momentu, gdy już został zainstalowany pakiet openvpn.
PRZYGOTOWANIE
Najpierw należy otworzyć do edycji plik openssl.cnf w katalogu /etc/ssl. Najlepiej użyć do tego midnight commandera, w tym pliku musimy znaleźć linie wypisane poniżej i zmienić je tak jak w przykładzie:
#########ZMIANA######################
dir = /rootca # Where everything is kept
##########ZMIANA#############
certificate = $dir/certyfikat_rootca.pem # The CA certificate
##########ZMIANA###############
private_key = $dir/private/klucz_rootca.pem # The private key
Dla uproszczenia przyjmiemy, że w głównym katalogu założymy specjalny katalog roboczy, oszczędzi nam to kombinacji ze ścieżkami:
mkdir rootca
cd /rootca
Jesteśmy teraz w utworzonym katalogu i musimy utworzyć podkatalogi oraz dwa pliki – pusty index.txt oraz serial z wpisanymi dwoma zerami:
mkdir certs crl misc newcerts private
touch index.txt
echo 00 > serial
Teraz zabierzemy się za wygenerowanie certyfikatów i kluczy, potrwa to sporą chwilę. Z przeprowadzonych doświadczeń wynika, że trzeba to robić bardzo uważnie. Należy zadbać o zgodność wpisów w certyfikatach dotyczących serwera i klienta (powinny różnić się jedynie w polach NAME i MAIL).
#generujemy klucz wystawcy certyfikatów
openssl genrsa -des3 -out private/klucz_rootca.pem_haslo 1024
#usuwamy haslo z klucza
openssl rsa -in private/klucz_rootca.pem_haslo -out private/klucz_rootca.pem
#usuwamy klucz z haslem
rm private/klucz_rootca.pem_haslo
#generujemy certyfikat wytawcy certyfikatow
openssl req -new -x509 -days 1825 -key private/klucz_rootca.pem -out certyfikat_rootca.pem
#generujemy klucz bramy
openssl genrsa -des3 -out /etc/openvpn/klucz_bramy.pem_haslo 1024
#usuwamy haslo z klucza bramy
openssl rsa -in /etc/openvpn/klucz_bramy.pem_haslo -out /etc/openvpn/klucz_bramy.pem
#usuwamy klucz z haslem
rm /etc/openvpn/klucz_bramy.pem_haslo
#generujemy request dla certyfikatu bramy
openssl req -new -key /etc/openvpn/klucz_bramy.pem -out request_bramy.pem
#jako wystawca certyfikatu podpisujemy request
openssl ca -notext -in request_bramy.pem -out /etc/openvpn/certyfikat_bramy.pem
#usuwamy request
rm request_bramy.pem
#generujemy klucz użytkownika – te polecenia będzie trzeba powtórzyć tyle razy,
#ilu użytkowników chcemy dodać.
#kolejne klucze i certyfikaty nazywamy inną nazwą np. klucz_zosia.pem, certyfikat_zosia.pem
openssl genrsa -des3 -out klucz_usera.pem_haslo
#usuwamy haslo z klucza usera
openssl rsa -in klucz_usera.pem_haslo -out klucz_usera.pem
#usuwamy klucz usera z haslem
rm klucz_usera.pem_haslo
#generujemy request dla certyfikatu usera
openssl req -new -key klucz_usera.pem -out request_usera.pem
#jako wystawca certyfikatu podpisujemy request
openssl ca -notext -in request_usera.pem -out certyfikat_usera.pem -days 1825
#usuwamy request
rm request_usera.pem
#generujemy plik dh do szyfrowania
openssl dhparam -out /etc/openvpn/dh1024.pem 1024
Kilka uwag do powuższych operacji, w niektórych poleceniach mamy parametr -days 1825, standardowo jest -days 365 – ważnośc certyfikatu jest na rok, myśmy przyjęli,że robimy go na 5 lat. Oczywiście jeśli w dużej firmie są rozmaici pracownicy, do których nie mamy nadmiernego zaufania to certyfikaty użytkowników możemy ustawić tak, aby były ważne na przykład mieciąc lub pół roku. To już jest zadanie administratora i jego odpowiedzialność, żeby zapewnić bezpieczeństwo sieci. Jak widać też z kluczy były usuwane hasła, to jest normalna procedura, ponieważ nasze połączenia będą się opierać na szyfrowaniu tunelu i uwierzytelnianiu połączenia za pomocą kluczy i certyfikatów, co jest znacznie lepszym rozwiązaniem niż poleganie na hasłach. Wydaje się z praktyki, że znacznie trudniej przejąć pliki certyfikatów i niż hasła, które użytkownicy mogą zapisać na „sticku” przylepionym do monitora.
KONFIGURACJA SERWERA (NND)
Jeśli wszystkie powyższe operacje powiodły się, wyedytujemy plik konfiguracyjny serwera VPN. Należy zwrócić uwagę, na generowanie certyfikatów, czy przebiegły poprawnie, gdyby pojawiły się komunikaty o niezgodności wpisów, operację trzeba powtórzyć. Sprawdzmy teraz czy w /etc/openvpn mamy następujące pliki: certyfikat_bramy.pem, certyfikat_rootca.pem, dh1024.pem oraz klucz_bramy pem. Jeśli nie będzie pierwszego z nich kopiujemy go z katalogu /rootca.
Plik konfiguracyjny nazwaliśmy multi.conf (aby wiadomo było, że chodzi o konfigurację z wieloma połączeniami). W dodatkowych liniach zahaszowanych, które można pominąć, są wyjaśnienia niektórych opcji.
dev tun
tun-mtu 1500
port 1194
user nobody
group nobody
comp-lzo
proto tcp-server
ping 20
ping-restart 120
ping-timer-rem
persist-tun
persist-key
daemon
verb 4
log-append /var/log/openvpn.log
ca /etc/openvpn/certyfikat_rootca.pem
cert /etc/openvpn/certyfikat_bramy.pem
key /etc/openvpn/klucz_bramy.pem
tls-server
dh /etc/openvpn/dh1024.pem
mode server
# poniżej podany zakres sieci oznacza, że serwer na interfejsie tun0 będzie miał numer 192.168.10.1
# klienci dostaną numery od 2 wzwyż
server 192.168.10.0 255.255.255.0
# przed uruchomieniem serwera ten plik należy stworzyć
ifconfig-pool-persist /etc/openvpn/ipp.txt
#ponizsze opcje można zmieniać w zależności od potrzeb, DOMAIN zależy od grupy roboczej w jakiej jest serwer,
#można użyć domeny jeśli jest w niej sieć, serwer DNS należy wpisac taki jaki jest w danej sieci,
#route z kolei musi zawierać zakres realnej sieci za serwerem VPN,
#klasa ta nie może się pokrywać z siecią po stronie klientów
push „dhcp-option DOMAIN workgroup”
push „dhcp-option DNS 192.168.1.1”
push „route 192.168.2.0 255.255.255.0”
push „ping 20”
push „ping restart 120”
Przed uruchomieniem serwera musimy jeszcze utworzyć plik ipp.txt:
cd /etc/openvpn
touch ipp.txt
W tym pliku serwer będzie przechowywał informację o IP przydzielonych poszczególnym użytkownikom.
Jeśli wszystko już zostało przygotowane, uruchamiamy serwer VPN poleceniem:
openvpn –config /etc/openvpn/multi.conf
i sprawdzamy poleceniem ps aux – czy jest proces i zaglądamy do logu, aby potwierdzić działanie serwera (próbnie można usunąć linię daemon z pliku – wszystko się wyświetli na ekranie). Gdyby pojawiły sie błędy, będzie to oznaczać konieczność dokładnego powtórzenia procedury generowania certyfikatów i sprawdzenia konfiguracji pod kątem ewentualnych literówek. Zakładam jednak, że wszystko pójdzie dobrze.
KONFIGURACJA KLIENTA (LINUX)
Klientowi, który będzie używał połaczenia, administrator powinien dostarczyć 4 pliki:
- klucz_usera.pem
- certyfikat_usera.pem
- certyfikat_rootca.pem
- klient.conf
i te pliki posłużą do zbudowania połączenia. Oczywiście certyfikat i klucz, będą się nazywały tak, jak to zrobił administrator – niekoniecznie się to musi pokrywać z naszym przykładem.
Plik konfiguracyjny wygląda tak:
tls-client
dev tun
proto tcp-client
comp-lzo
persist-tun
persist-key
verb 4
ca /etc/openvpn/certyfikat_rootca.pem
cert /etc/openvpn/certyfikat_usera.pem
key /etc/openvpn/klucz_usera.pem
remote 192.168.1.9
pull
port 1194
ping 15
Zmienna remote musi zawierać prawdziwy adres serwera (zwykle to będzie publiczne IP). W linuksie operacje na interfejsach może wykonywac wyłącznie root, więc sugeruję pliki zapisać do /etc/openvpn, w innym przypadku należy użyć sudo, ale to się wiąże z dodatkowymi czynnościami, które już się w tym opisie nie mieszczą.
Teraz jako root wywołujemy openvpn –config /etc/openvpn/klient.conf
Połączenie VPN z reguły nie jest stałe, więc wywołujemy je ręcznie i komunikaty będą widoczne w konsoli. Można je oczywiście dodać do własnych plików startowych, ale nie zapomnijmy wtedy o dopisaniu opcji daemon.
Czy to działa? Sprawdzimy nasze połączenie wpisując ifconfig. Pojawi nam się interfejs wirtualny:
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:192.168.10.6 P-t-P:192.168.10.5 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
To już poczatek sukcesu. Teraz sprawdzamy ping do serwera VPN (ping 192.168.10.1), jeśli jest – to widać, że połaczenie zostało zestawione. Powinna się też zmienić tablica routingu:
[root@compaq ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.10.1 192.168.10.5 255.255.255.255 UGH 0 0 0 tun0
192.168.10.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.2.0 192.168.10.5 255.255.255.0 UG 0 0 0 tun0
192.168.1.0 0.0.0.0 255.255.255.0 U 10 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 10 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 192.168.1.1 0.0.0.0 UG 10 0 0 eth0
Widac na przykładzie, że serwer VPN dodał nam dodatkowy routing do podsieci 192.168.2.0, zatem możemy widzieć komputery po drugiej stronie tunelu. Najlepiej, żeby jakiś był włączony. Możemy zatem zrobić ping 192.168.2.5, połączyć się przez zdalny pulpit i zobaczyć jego pliki udostępnione (w moim doświadczeniu był to komputer z XP).
KONFIGURACJA KLIENTA (WINDOWS)
Połączenie przy użyciu systemu Windows nie będzie możliwe za pomocą wbudowanego klienta vpn. Jak zwykle Microsoft jest kompatibilny jedynie sam ze sobą. Musimy zainstalować program OpenVPN dla Windows. Jest to proste i szybkie. Po zainstalowaniu pojawi nam się trayu ikonka, której użyjemy wywołauąc połaczenie. Najpierw jednak zapiszemy konfigurację.
tls-client
dev tun
proto tcp-client
comp-lzo
persist-tun
persist-key
verb 4
ca C:/certyfikat_rootca.pem
cert C:/certyfikat_usera.pem
key C:/klucz_usera.pem
remote 192.168.1.9
pull
port 1194
ping 15
Plik konfiguracyjny jest taki sam, różnią się jedynie ścieżki do certyfikatów, aby nie pisać tasiemcowych linijek, zapisałem je bezpośrednio w głównym katalogu. Sam plik konfiguracyjny zapisujemy jako cert.ovpn w katalogu c:Program filesOpenVPNconfig. Następnie tworzymy nowe urządzenie tap-tun (jest odpowiednie polecenie w menu).
Teraz już za pomocą ikonki w trayu, wybieramy opcję Connect i połączenie się zaczyna.
Sprawdzamy je za pomocą polecenia w konsoli (cmd) – ipconfig /all – zobaczymy że jest nowy interfejs o adresie jaki nam przydzielił serwer VPN. Również w konsoli wpiszemy polecenie route PRINT:
==========================================
==========================================
Aktywne trasy:
Miejsce docelowe w sieci Maska sieci
0.0.0.0 0.0.0.0 19
127.0.0.0 255.0.0.0
192.168.1.0 255.255.255.0 19
192.168.1.5 255.255.255.255
192.168.1.255 255.255.255.255 19
192.168.2.0 255.255.255.0 192
192.168.10.1 255.255.255.255 192
192.168.10.4 255.255.255.252 192
192.168.10.6 255.255.255.255
192.168.10.255 255.255.255.255 192
224.0.0.0 224.0.0.0 19
224.0.0.0 224.0.0.0 192
255.255.255.255 255.255.255.255 192
Domyślna brama: 192.168.1.1.
==========================================
W tym wypadku również widać dodanie tras przez serwer VPN, zatem możemy przejść do praktycznego zastosowania.
W otoczeniu sieciowym wybieramy opcję dodawania nowego miejsca sieciowego, wpisujemy numer komputera w zdalnym LANie i mapujemy udostępnione przez niego katalogi. Dzięki temu możemy zdalne komputery widzieć tak – jak by były w naszej sieci, jednak bezpośrednio w otoczeniu sieciowym ich nie zobaczymy. Jeśli zdalny komputer to Windows 98 lub 2000 – raczej nie będzie problemów. W przypadku XP zauważyłem, że przeszkadza zapora, a ponieważ nie chciało mi się tego konfigurować – więc ją wyłączyłem.