VPN i Linux I


Konfiguracja

VPN i Linux I

Krótko i bezboleśnie - nasz plik konfiguracyjny Free S/WAN.

Nasz brama bezpieczeństwa powinna działać jednocześnie jako firewall i łączyć zewnętrzne komputery o dowolnym adresie IP z uwierzytelnieniem za pomocą certyfikatu X.509 z wewnętrzną siecią (172.16.0.0/16). Brama dysponuje w tym celu dwoma interfejsami eth0 (wewnętrzny, 172.16.0.0/16) i eth1 (zewnętrzny). Pomiędzy tymi interfejsami musi być uruchomione forwardowanie adresów IP.

Najpierw należy zadbać o to, by firewall bramy bezpieczeństwa akceptował odpowiednie pakiety AH i ESP. Tak więc należy zezwolić na przyjmowanie przez interfejs zewnętrzny - w naszym przypadku eth1 - pakietów UDP w porcie 500 (ESP) oraz pakietów IP (AH) w porcie 50.

Konfiguracja samego Free S/WAN odbywa się poprzez plik /etc/ipsec.conf. Potrzebne są trzy grupy parametrów - config setup zawiera podstawowe ustawienia, conn %default - podstawowe ustawienia dla wszystkich połączeń. Trzeci parametr, również o nazwie config i dowolnym rozszerzeniu, ustala parametry połączenia o nazwie identycznej z rozszerzeniem. W naszym przykładzie pozwolimy sobie na nieco ekstrawagancji i nazwiemy go tak, jak brzmi modne dziś określenie pracownika mobilnego - conn Roadwarrior.

/etc/ipsec.conf

W config setup należy najpierw podać interfejs, do którego będą kierowane zapytania o nawiązanie połączenia IPsec. Z reguły wystarczy tu interfaces =%defaultroute, alternatywnie można podać adres IP interfejsu. Wyłączamy debugowanie, wprowadzając none dla klipsdebug i pluto debug. plutoload i plutostart ustawiamy na %search, żeby połączenia były zestawiane dopiero na żądanie strony przeciwnej. Uniqueids ustawiamy na no, dzięki czemu wystarczy tylko jeden opis połączenia dla wszystkich roadwarriors. W przeciwnym razie musielibyśmy sporządzić opis połączenia dla każdego pracownika mobilnego.

W conn %default zmuszamy bramę za pomocą keyingtries=0 do wykazania możliwie dużej cierpliwości w trakcie ponownej negocjacji kluczy. Jako metodę uwierzytelniania wykorzystujemy authby=rsasig, przy czym obie strony winny wylegitymować się certyfikatami: leftrsasigkey=%cert i rightrsasigkey=%cert. Jako left podajemy ponownie %defaultroute, jako leftsubnet naszą sieć wewnętrzną (tutaj: 172.16.0.0/16). Później uzupełnimy jeszcze parametr leftid. Chodzi tu o wystawcę naszego certyfikatu bramy.

Na korzystanie z naszego połączenia conn Roadwarrior zezwalamy wszystkim, którzy mogą się wykazać posiadaniem certyfikatu - right=%any. Jako typ połączenia wybieramy type=tunnel; wymiana kluczy winna odbywać się przez IKE (keyexchange=ike) z Perfect Forwarding Secrecy (pfs=yes). Za pomocą auto=add instruujemy Free S/WAN, że połączenie ma być negocjowane dopiero na żądanie wojownika drogi.

Certyfikaty

W ten oto sposób Free S/WAN został skonfigurowany do nawiązywania połączeń z silnym szyfrowaniem na odstawie wymiany certyfikatów. Niezbędne certyfikaty dla bramy i wojowników wystawimy sobie sami. W tym celu wykorzystamy możliwości OpenSSL (http://www.openssl.org ).

Najpierw wygenerujemy strukturę katalogu do generowania certyfikatów. W naszym przykładzie znajduje się ona w /etc/fenrisCA - korzystamy tu z nazwy hosta naszej bramy. Tworzymy więc katalogi certs i newcerts (magazyny certyfikatów), crl (na certyfikaty unieważnione; Certification Revocation List) oraz private (klucze prywatne). Do katalogu private, jak również do znajdujących się tam kluczy dostęp powinien mieć z oczywistych względów tylko root.

W /etc/fenrisCA potrzebne są jeszcze pliki index.txt i serial. Za pomocą touch zakładamy index.txt jako pusty plik. W tym pliku OpenSSL będzie później prowadzić listę wystawionych certyfikatów. Kolejne numery certyfikatów openssl będzie pobierać z pliku serial. Nadajemy na początek wartość 00.

Teraz w pliku konfiguracyjnym openssl.cnf (zależnie od dystrybucji, najczęściej w /usr/ssl lub /usr/share/ssl) podajemy ścieżkę dostępu do naszego katalogu CA jako parametr dir. Opcjonalnie można też podać wartości domyślne ciągów identyfikacyjnych, takie jak country, state i organizationName. Dzięki temu później, w trakcie wystawiania certyfikatów, oszczędzimy nieco wklepywania danych. W trakcie dalszych czynność związanych z openssl katalog CA (w naszym przypadku /etc/fenrisCA) musi być cały czas aktualnym katalogiem roboczym.

Root CA

VPN i Linux I

Pytanie za pytaniem - tak wygląda wystawianie certyfikatu Root CA.

Zajmijmy się teraz Root CA. Na początek należy wygenerować klucz prywatny RSA o długości 2048 bitów:

openssl genrsa -des3 -out private/caKey.pem 2048

}

Opcja des3 zaszyfruje nasz klucz algorytmem TripleDES gdy podamy hasło, dzięki któremu osoby niepowołane nie będą mogły posłużyć się nim do podpisania certyfikatu. Oczywiście, my też nie, jeżeli zapomnimy hasło.

Teraz generujemy certyfikat Root CA i określamy jego termin ważności, ze względów praktycznych niezbyt krótki:

openssl req -new -x509 -days=1825 -key private/caKey.pem -out caCert.pem

Jako hasło należy podać hasło naszego dopiero co wygenerowanego klucza prywatnego. Na koniec openssl zapyta o poszczególne elementy opisowe podmiotów, które służą do identyfikacji posiadacza certyfikatu. Poszczególne elementy składowe są praktycznie oczywiste, oprócz Common Name. Common Name może być praktycznie dowolnym oznaczeniem, choć ze względów praktycznych powinno w prosty sposób kojarzyć z podmiotem. Przynależny element "e-mail" opisuje, w jaki sposób można skontaktować się z posiadaczem certyfikatu.

Możemy sprawdzić, czy wszystko przebiegło pomyślnie, przeglądając certyfikat w wersji tekstowej:

openssl x509 -in caCert.pem -noout -text

W końcu kopiujemy nasz certyfikat Root CA do /etc/ipsec.d/cacerts/, czyli tam, gdzie Free S/WAN będzie spodziewał się go znaleźć.