Wstęp

Zaletą tego rodzaju tunelu jest to, że jego działanie opiera się na jednych z bardziej popularnych protokołach PPP oraz SSH. Komunikacja odbywa się na porcie 22. Dzięki temu nie zachodzi potrzeba otwierania dodatkowych portów komunikacyjnych w konfiguracji zapory ogniowej. Interfejsy tunelu uruchamiane są przez demona pppd. Posłużą nam one do zestawienia trasy między dwoma hostami lub sieciami w zależności od potrzeb. Do naszych celów będzie potrzebny demon pppd będący implementacją protokołu ppp oraz klient i serwer ssh implementujący protokół ssh.

Konfiguracja

Zanim przystąpimy do konfiguracji musimy zdecydować który komputer będzie serwerem a który klientem. Klient będzie inicjował połączenie z serwerem uruchamiając demona pppd.

Serwer

Zanim przystąpimy do konfiguracji należy sprawdzić czy system wyposażony jest w demona ppp oraz serwer ssh. Pakiety które to udostępniają to odpowiednio ppp oraz openssh-server. Przydatnym może się okazać pakiet openssh-clients zawierający jak sama nazwa wskazuje klienta ssh.

Po zainstalowaniu wyżej wymienionych pakietów przechodzimy do konfiguracji systemu. W pierwszej kolejności zakładamy konto użytkownika oraz przydzielamy mu grupę.

# groupadd vpn-users # useradd -m -s /usr/sbin/pppd -g vpn-users vpn # passwd vpn New UNIX password: Retype new UNIX password: passwd: password updated successfully

Efekt wykonanych poleceń możesz zobaczyć na listingu poniżej

# grep vpn /etc/passwd vpn:x:506:1005::/home/users/vpn:/usr/sbin/pppd #grep vpn-users /etc/group vpn-users:x:1005:

Wynik tych poleceń powinien odpowiadać temu co tutaj widać. GID grupy vpn-users wynosi 1005 czyli odpowiada GID ustawionemu w pliku /etc/passwd. Poleceniem passwd ustawiamy hasło dla tego konta, które zostało wpisane do /etc/shadow.

Istotnym dla konfiguracji elementem w katalogu użytkownika vpn jest katalog ~/.ssh. Możemy go stworzyć (o ile wcześniej zainstalowaliśmy) przy pomocy klienta ssh. Robimy to w dwóch krokach które obrazuje poniższy przykład

# su - vpn -s /bin/bash $ ssh domena.pl Warning: Permanently added 'domena.pl,xxx.xxx.xx.x' \ (RSA) to the list of known hosts. Password: ^C

Można też ręcznie utworzyć z poziomu konta vpn ten katalog poleceniem mkdir. Aby umożliwić użytkownikowi prawo do wykonania po zalogowaniu polecenia /usr/sbin/pppd należy nadać temu plikowi suida.

# chmod 4755 /usr/sbin/pppd

Konfigurację warstwy ssh mamy już za sobą. Możemy teraz przystąpić do konfiguracji demona pppd. Demon nie będzie wymagał autoryzacji, więc w pliku /etc/ppp/options wyszukujemy opcję auth i zmieniamy ją na noauth. Musimy teraz skonfigurować wierzchołek (tzw. peer) końca tunelu. Tworzymy więc plik /etc/ppp/peers/tunel określający wszystkie niezbędne parametry połączenia. Na listingu poniżej przykładowa konfiguracja wierzchołka.

# cat /etc/ppp/peers/tunel 192.168.1.100:192.168.1.101 noauth lcp-echo-interval 5 lcp-echo-failure 3

W pierwszej linijce oddzielone są dwukropkiem adresy IP wierzchołków tunelu. Ten po lewej stronie zostanie ustawiony na interfejsie serwera, ten po prawej klienta. Przedstawioną konfigurację należy potraktować jako przykład i dostosować ją do rzeczywistej. Oczywiście, jeżeli spełnia ona Twoje wymagania możesz ją zastosować.

• noauth - wyłączamy autoryzację ppp

• lcp-echo-interval - wartość przy tej opcji określa interwał w sekundach z jakim wysyłana będzie do peera ramka żądania o echo LCP. Demon sprawdza w ten sposób czy połączenie nadal jest aktywne.

• lcp-echo-failure - wartość podana przy tej opcji określa ile żądań o echo LCP ma zostać wysłanych jeżeli peer nie dał odpowiedzi. Po tylu próbach demon stwierdzi, że połączenie zostało utracone.

Klient

Konfiguracja po stronie klienta sprowadza się do wygenerowania kluczy rsa oraz odpowieniego ustawienia demona pppd. Klucze nam są potrzebne do autentykacji nie interaktywnej ssh. Inaczej nie uda nam się nawiązać połączenia z serwerem. Do zestawienia połączenia z serwerem po stronie klienta wymagana jest instalacja pakietów ppp oraz openssh-clients. Jeżeli ich nie posiadasz musisz je niezwłocznie zainstalować.

Przystępujemy do dalszej konfiguracji usługi po stronie klienta. Zaczniemy od wspomnianego na wstępie generowania kluczy.

$ ssh-keygen -b 1024 -f ~/.ssh/klucz -t rsa -P "" Generating public/private rsa key pair. Your identification has been saved in /home/users/foo/.ssh/klucz. Your public key has been saved in /home/users/foo/.ssh/klucz.pub. The key fingerprint is: c9:d8:17:bd:ba:82:a0:f0:47:7c:32:c2:e8:7e:32:e8 foo@pldmachine

Do generowania kluczy służy znajdujące się w pakiecie openssh-clients polecenie ssh-keygen. Użyliśmy go z następującymi parametrami:

• -b - długość klucza w bitach. Wartość podana na listingu jest minimalną długością klucza która jest akceptowana przez demona sshd.

• -f - nazwa pliku (można podać ścieżkę do niego) zawierającego klucz prywatny.

• -t - typ klucza. Na listingu jest to RSA. RSA jest algorytmem służącym do generowania kluczy.

• -P - hasło klucza. Na potrzeby tunelu hasło musi pozostać puste. Inaczej tunel nie zadziała. Demon sshd będzie czekał na potwierdzenie hasłem klucza co nigdy nie nastąpi, gdyż sesja ssh będzie inicjowana poprzez demona pppd uniemożliwiając nam w sposób interaktywny jej przejęcie.

Kolejnym krokiem jest skopiowanie zawartości pliku klucz.pub do pliku ~vpn/.ssh/authorized_keys na serwerze. Możemy tego dokonać w następujący sposób.

$ scp ~/.ssh/klucz.pub [email protected]:~/.ssh/authorized_keys

Polecenie to zadziała tylko wtedy, kiedy na koncie vpn znajdującym się na serwerze zmienimy tymczasowo powłokę z /usr/sbin/pppd na standardową /bin/bash. Na tym etapie kończy się cała konfiguracja dotycząca ssh po obu stronach. Możemy więc przywrócić na serwerze w pliku /etc/passwd dla użytkownika vpn powłokę na /usr/sbin/pppd. Przystępujemy teraz do skonfigurowania demona pppd, który będzie wywoływał podczas ustanawiania połączenia klienta ssh.

Podobnie jak po stronie serwera w pliku /etc/ppp/options musimy opcję auth zmienić na noauth. Kiedy już to zrobimy, przystąpimy do konfiguracji wierzchołka (tzw. peera) dla klienta, który będzie inicjował połączenie. Nazwa pliku może być taka sama jak na serwerze. Poniżej na listingu znajduje się przykładowa konfiguracja wierzchołka dla klienta.

# cat /etc/ppp/peers/tunel 192.168.1.101:192.168.1.100 debug noauth pty "ssh -i ~/.ssh/klucz [email protected]" connect-delay 5000

Pierwsza linijka w pliku to dwa adresy IP oddzielone znakiem dwukropka. Adres po lewej stronie jest adresem tego końca tunelu, który właśnie konfigurujemy. Pamiętamy, że adres 192.168.1.100 został już przydzielony jako adres wierzchołka serwera. Pozostałe opcje zostały objaśnione poniżej.

• debug - włączamy raportowanie szczegółów połączenia ppp.

• noauth - wyłączamy autoryzację.

• pty - dzięki tej opcji możemy wykorzystać zewnętrzny skrypt jako ośrodek komunikacji zamiast konkretnego urządzenia terminalowego. Wykorzystujemy tutaj ssh.

• connect-delay - określony w milisekundach czas oczekiwanie na prawidłowy pakiet PPP od peera. Jeżeli taki w tym czasie nadejdzie pppd rozpocznie negocjację wysyłając pierwszy pakiet LCP.

W przypadku problemów z połączeniem możemy zwiększyć wartość connect-delay nawet dziesięciokrotnie jeżeli łącza pomiędzy którymi zestawiamy tunel będą sporo obciążone. Również po stronie klienta musimy nadać bit suid plikowi /usr/sbin/pppd.

# chmod 4755 /usr/sbin/pppd

Na tym kończymy konfigurację tunelu. Możemy przejść do fazy jego uruchomienia.

Uruchomienie

Skonfigurowane połączenie należy teraz zainicjować wykonując polecenie:

$ /usr/sbin/pppd call tunel

Udana próba połączenia połączenia powinna zaowocować zapisami w logach takimi jak poniżej na listingu.

Sep 2 12:35:34 pldmachine pppd[6623]: pppd 2.4.2b3 started by foo, uid 501 Sep 2 12:35:34 pldmachine pppd[6623]: Using interface ppp0 Sep 2 12:35:34 pldmachine pppd[6623]: Connect: ppp0 <--> /dev/pts/0 Sep 2 12:35:37 pldmachine pppd[6623]: Deflate (15) compression enabled Sep 2 12:35:37 pldmachine pppd[6623]: Cannot determine ethernet \ address for proxy ARP Sep 2 12:35:37 pldmachine pppd[6623]: local IP address 192.168.1.101 Sep 2 12:35:37 pldmachine pppd[6623]: remote IP address 192.168.1.100

Wykonując po obu stronach polecenie ifconfig zauważysz, że utworzone zostały interfejsy ppp służące do komunikacji. Wykorzystamy je do zestawienia prostej trasy pomiędzy dwoma sieciami.

Zakładając, że jedna sieć po stronie serwera ma adresację 192.168.0.0/24 a po stronie klienta 192.168.2.0/24 routing będzie wyglądał w sposób następujący.

Po stronie serwera:

# route add -net 192.168.2.0/24 gw 192.168.1.100

Po stronie klienta:

# route add -net 192.168.0.0/24 gw 192.168.1.101

W ten sposób oba komputery będą przechowywały w swoich tablicach routingu informacje o sieciach połączonych dzięki interfejsom tunelu.