FEDORA CORE 14 Linux - Konfiguracja L2TP/IPsec

Chciałbym przedstawić sposób na skonfigurowanie połączenia L2TP/IPsec w Fedorze. Trochę się z tym tematem ostatnio pomęczyłem i jeżeli kouś to pomoże to przedstawię tutaj procedurę "krok po kroku" jak to wykonać.

No to zacznijmy od początku, czyli od ściągnięcia odpowiednich pakietów, czyli:
1. OpenSWAN
2. xl2tpd

Następnie zabieramy się za przygotowanie klucza i bazy kluczy NSS. Zakładam, że w posiadaniu jest klucz w postaci pkcs12, jeżeli nie a mamy 2 certyfikaty i klucz prywatny w osobnych plikach tekstowych (format PEM) to należy wykonać następującą komendę do stworzenia klucza pkcs12:

openssl pkcs12 -export -in cert.pem -inkey user.key -certfile cacert.pem -out certkey.p12 -name 'masl-12'

Oczywiście w powyższej instrukcji można użyć dowolnej nazwy, w tym przypadku należy zmianić 'masl-12' na dowolnie wybrany ciąg znaków. Po naciśnięciu w terminalu nastąpi prośba o podanie hasła do klucza prywatnego ("Enter pass phrase for user.key:"), które to hasło należy mieć i w tym momencie wpisać. Po wpisaniu poprawnym hasła powinno nastąpić pytanie o hasło exportu ("Enter Export Password:") tutaj wpisujemy dowolne hasło i po potwierdzamy wpisując je ponownie. Po wykonaniu powyżej opisanych króków powinein zostać utworzony w bieżącym katalogu plik o nazwie 'certkey.p12'.

Teraz plik z danymi PKCS#12 utworzony w poprzednim kroku należy zaimportować do bazy kluczy i certyfikatów. Wcześniej jednak musimy sobie stworzyć nową bazę (lub raczej nowe bazy) i robimy to przy pomocy następujacej komendy:

su -c "certutil -N -d /etc/ipsec.d"

Po jej wywołaniu zostaniemy poproszeni o podanie hasła ROOT-a (wpisujemy odpowiednie hasło) a następnie o nowe hasło i jego powtórzenie ("Enter new password:", "Re-enter password:") do nowotworzonej bazy kluczy. Można to hasło pozostawić puste poprzez wykonanie bez podawania czegokolwiek. Po tej operacji powinny zostać utworzone następujące pliki w katalogu '/etc/ipsec.d': cert8.db, key3.db, secmod.db.

Teraz import pliku z danymi PKCS#12 do nowoutworzonej bazy kluczy, wykonujemy następującą komendą:

su -c "pk12util -i certkey.p12 -d /etc/ipsec.d"

W trakcie wywołania powyższej komendy zostaniemy poproszeni o hasło ROOT-a, a następnie o hasło które wprowadziliśmy przy eksporcie. Jeżeli wszystko uda ło się zrobić tak jak trzeba powinien być na terminalu wpis pk12util: PKCS12 IMPORT SUCCESSFUL.

Super udało nam się zaimportować do bazy zawartość pliku z danymi PKCS#12 - przynajmniej wszystko na to wskazuje, ale sprawdźmy. Możemy to zrobić wykorzystując komendę:

su -c "certutil -L -d /etc/ipsec.d"

No dobrze wszystko gra w takim razie przechodzimy do konfiguracji IPSEC. Po pierwsze edytujemy plik /etc/ipsec/ipsec.secrets poprzez dodanie w nim następującej linii:

: RSA "masl-12" "[hasło]"

gdzie "masl-12" oznacza nazwę klucza wprowadzoną przy eksporcie przy użyciu 'openssl', a w miejsce [hasło] należy wpisać hasło w naszym przypadku jest to pusta wartość. Zapisujemy wyedytowany plik.

Co dalej. Dalej przechodzimy do edycji pliku /etc/ipsec/ipsec.conf i tutaj usuwamy to co jest już tam wpisane i zaczyna się od 'config setup' a następnie wpisujemy to co poniżej:

config setup
  nat_traversal=yes
  interfaces=%defaultroute  
  protostack=netkey
  #plutodebug=all  
  #plutostderrlog=/tmp/pluto.log

conn IPSEC-conn
  authby=rsasig
  pfs=no
  rekey=yes
  keyingtries=3
  type=transport
  left=0.0.0.0 ; <- tutaj wpisać lokalne IP (ifconfig)  
  leftid="C=PL, ST=Malopolska, L=Cracow, O=BleBle, CN=Marcin Slowik, E=masl@xxxx.pl" 
  leftcert="masl-12" ; <- nazwa certyfikatu wprowadzona w kroku z komendą openssl
  leftrsasigkey=%cert
  leftprotoport=17/1701
  right=
  rightrsasigkey=%cert
  rightca=%same
  rightid=@xx.yyyyy.zz
  rightprotoport=17/1701
  auto=add

Bardzo ważną sprawą jest podanie jako 'leftid' identyfikatora w formie DN (distinguished name) - gdy tego się nie poda przedstawimy się serwerowi w formie adresu IP i możemy mieć problem 'no RSA no RSA public key known for 0.0.0.0' na serwerze a na kliencie INVALID_KEY_INFORMATION. Pytanie skąd wziąć tą informację - odpowiedź - wykonać:

su -c "certutil -L -d /etc/ipsec.d -n masl-12"

i skopiować wartość z pola 'Subject:'. Ważne jest to że w przypadku, gdy po wykonaniu komedy 'ipsec auto --up IPSEC-conn' (opisane w dalszej części) dostaniemy błąd 'INVALID_KEY_INFORMATION' należy skopiowane wartości odwrócić, czyli przekształcić z formy

E=masl@xxxx.pl,CN=Marcin Slowik,O=BleBle,L=Cracow,ST=Malopolska,C=PL

na formę

C=PL, ST=Malopolska, L=Cracow, O=BleBle, CN=Marcin Slowik, E=masl@xxxx.pl

. Jako 'left' należy podać lokalny adres sieciowy maszyny z której się łączymy, czyli jeżeli jesteśmy w sieci lokalnej np. 192.168.1.2. Można uzyć zamiast adresu IP wartości '%defaultroute' jednak polecam wartość IP na początek i jak wszystko zacznie działać to wprowadzenie '%defaultroute' ponieważ może to być przyczyną niepotrzebnych poszukiwań co jest nie tak. Jako 'right' należy podać adres IP lub nazwę hosta docelowego / serwera - polecam przy pierwszej próbie wpisać IP potem ewentualnie nazwę (tutaj też czasem są problemy których przy pierwszym podejściu proponuję unikać). Jako 'rightid' należy wpisać po małpce FQDN (Fully Qualified Domain Name) serwera.

No dobra zróbmy pierwszą próbę czy wszystko działa w miarę dobrze. Zróbmy następującą sekwencję komend:

su
service ipsec stop
service ipsec start

Po takiej sekwencji powinniśmy dostać po wykonaniu:

tail -f /var/log/secure

mniej więcej coś takiego na końcu:
Feb 16 22:34:00 fedora pluto[3874]: loaded private key for keyid: PPK_RSA:DwBnRRRR

Ważne jest jeszcze, żeby sprawdzić czy zostało dodane połączenie o nazwie 'IPSEC-conn', czyli sprawdzenie czy w pliku '/var/log/secure' znajduje się coś w tym stylu:
Feb 16 22:34:00 fedora pluto[3874]: added connection description "IPSEC-conn"

Teraz sprawdzamy poprawność połączenia i wymiany kluczy, czyli wykonujemy z linii komend:

ipsec auto --up IPSEC-conn

Jeżeli wszystko działa poprawnie powinniśmy dostać na konsoli coś w tym stylu:
117 "IPSEC-conn" #2: STATE_QUICK_I1: initiate
004 "IPSEC-conn" #2: STATE_QUICK_I2: sent QI2, IPsec SA established transport mode {ESP=>............}

No dobra jeżeli działa to przechodzimy do następnego kroku, czyli konfiguracji xl2tp. Konfiguracja xl2tp polega na modyfikacji trzech plików. Pierwszy to /etc/ppp/chap-secrets. W tym pliku dodajemy następującą linię:

test * test *

pierwsze 'test' to user-name drugie 'test' to hasło, czyli informacje potrzebne do podstawowej autentykacji połączenia z serwerem.

Następny plik to /etc/ppp/options.l2tpd.con. Ten plik tworzymy i wypełniamy następującą treścią:

ipcp-accept-local
ipcp-accept-remote
refuse-eap
noccp
noauth
crtscts
idle 1800
mtu 1410
mru 1410
nodefaultroute
debug
lock
connect-delay 5000

No i ostatni z plików to /etc/xl2tpd/xl2tpd.conf, w którym dodajemy to co następuje:

[global]
listen-addr = 192.168.1.2

[lac L2TPS]
lns = [FQDN for serwer]
require chap = yes
refuse pap = yes
require authentication = yes
name = test
ppp debug = yes
pppoptfile = /etc/ppp/options.l2tpd.con
length bit = yes

No dobra to w takim razie odpalamy xl2tpd:

service xl2tpd start

Jeżeli wszystko ok powinniśmy mieć w pliku /var/log/messages wpis:


Feb 16 23:29:06 fedora xl2tpd[4955]: Listening on IP address 192.168.1.2, port 1701

No dobra teraz odpalmy połączenie, czyli do wykonania są następujące komendy:

ipsec auto --up IPSEC-conn
echo "c L2TPS" > /var/run/xl2tpd/l2tp-control

Jeżeli po wykonaniu komend powyżej dostałeś w pliku /var/log/messages coś takiego:
Feb 17 00:40:31 fedora pppd[9709]: Warning: can't open options file /root/.ppprc: Permission denied

to proponuję przejść do ustawień polityki selinux raczej na pewno nie są to inne uprawnienia.

No dobrze dalej jak mamy połączenie to musimy zdefiniować routing dla adresów z podsieci na serwerze, ponieważ domyślnie mamy dostępny jeden adres. Można to zrobić np. dla całej puli adresów sieci prywatnej zaczynających się od 10. w sposób podany niżej:

ip route add 10.0.0.0/8 dev ppp0

Można jeszcze na przykład dodać name server, który znajduje się w sieci prywatnej na adresie 10.5.1.1 w sposób podany poniżej:

echo "nameserver 10.5.1.1" >> /etc/resolv.conf

Zamykanie wszystkiego po kolei to wykonanie skryptu:

ip route del 10.0.0.0
echo "d L2TPS" > /var/run/xl2tpd/l2tp-control
ipsec auto --down IPSEC-conn
service xl2tpd stop
service ipsec stop

To wszystko na ten temat. Mam nadzieję, że to komuś pomoże w konfiguracji połączenia VPN.