OpenVPN to otwarte oprogramowanie umożliwiające tworzenie szyfrowanych tuneli VPN między urządzeniami, co zapewnia bezpieczny sposób komunikacji i dostępu do zasobów sieciowych.
W tym poście pokażemy jak stworzyć bezpieczny tunel do połączenia się z Asteriskiem. Zainstalujemy na nim serwer VPN, organ certyfikacji i wygenerujemy niezbędne klucze. Następnie skonfigurujemy narzędzie i wykonamy testowe połączenie. Potem wykorzystamy tunel do pracy z Asteriskiem przykładowo logując telefon.
Spis treści
1) Instalacja serwera OpenVPN
W pierwszej kolejności zainstalujemy sam serwer OpenVPN oraz zestaw narzędzi pozwalających na zarządzanie i tworzenie infrastruktury kluczy oraz certyfikatów. Potrzebne będą nam dwa pakiety openvpn i easy-rsa
yum -y install openvpn easy-rsa
Po prawidłowo przeprowadzonej instalacji skopiujemy plik konfiguracyjny serwera OpenVPN server.conf do innej lokalizacji, w której ze względów bezpieczeństwa ustawimy uprawnienia dla innego użytkownika niż root. Gwiazdka w nazwie pliku pozwala nam się uniezależnić od wersji najnowszego pakietu.
cp /usr/share/doc/openvpn-*/sample/sample-config-files/server.conf /etc/openvpn/
2) Generowanie kluczy
Teraz wygenerujemy niezbędne klucze. Zanim zaczniemy tę część konfiguracji usuniemy wszystkie pliki tymczasowe oraz ewentualne pliki konfiguracyjne związane z aktualną infrastrukturą kluczy i certyfikatów, które mogły zostać kiedyś utworzone za pomocą narzędzia EasyRSA
cd /usr/share/easy-rsa/3.0.8/
./easyrsa clean-all
Kolejnym poleceniem wygenerujemy nowy certyfikat główny (CA – Certificate Authority) bez konieczności wprowadzania hasła.
./easyrsa build-ca nopass
Opcja “nopass“ wskazuje, że nie chcesz używać hasła dla klucza głównego. W normalnych przypadkach, podczas tworzenia klucza prywatnego lub certyfikatu, jesteś zwykle proszony o wprowadzenie hasła dla zabezpieczenia klucza prywatnego. Użycie “nopass” oznacza, że klucz prywatny zostanie zapisany bez hasła, co może być wygodne, ale również może być mniej bezpieczne, ponieważ klucz prywatny jest wtedy mniej zabezpieczony. W naszym przykładzie wszędzie zrezygnujemy z tego dodatkowego zabezpieczenia. Ułatwi nam to później automatyzację całego procesu w kolejnych instalacjach i w automatycznej komunikacji z naszym środowiskiem.
Przechowywanie kluczy prywatnych bez hasła może być mniej bezpieczne, ponieważ klucz prywatny jest wtedy mniej zabezpieczony. Dlatego ważne jest, aby stosować odpowiednie środki ostrożności, zwłaszcza w przypadku kluczy prywatnych używanych do zabezpieczania komunikacji w środowiskach produkcyjnych.
Kolejnym poleceniem wygenerujemy pełny zestawu certyfikatów serwera bez konieczności podawania hasła. Ten zestaw zazwyczaj zawiera certyfikat serwera, klucz prywatny serwera oraz certyfikat główny (CA), który podpisuje certyfikat serwera.
./easyrsa build-server-full server nopass
Argument “server“, który wskazuje nazwę serwera lub identyfikator, który będzie używany do nazwania wygenerowanych certyfikatów.
“nopass“: To opcja, która oznacza, że klucz prywatny, który zostanie wygenerowany dla serwera, nie będzie zabezpieczony hasłem. To może być wygodne, ale również może wiązać się z pewnym ryzykiem bezpieczeństwa o czym pisaliśmy powyżej.
Teraz wygenerujemy parametry Diffie-Hellmana (da). Wykonanie tego polecenia może zająć trochę czasu więc okaż cierpliwość.
./easyrsa gen-dh
Parametry Diffie-Hellmana obejmują dużą liczbę pierwszą oraz odpowiadający jej generator, które są wykorzystywane w procesie wymiany klucza Diffie-Hellmana. Ten proces jest zasadniczy w ustanawianiu bezpiecznej komunikacji, zwłaszcza w protokołach takich jak TLS/SSL, gdzie parametry Diffie-Hellmana są używane do negocjowania wspólnej tajemnicy między klientem a serwerem.
Diffie-Hellman (DH) to algorytm kryptograficzny wykorzystywany do ustalania wspólnej tajemnicy (shared secret) między dwiema stronami w niezabezpieczonym kanale komunikacyjnym. Ta wspólna tajemnica może być następnie wykorzystywana do bezpiecznej komunikacji lub do wygenerowania kluczy szyfrowania.
Na koniec wygenerujemy certyfikat klienta.
./easyrsa build-client-full client01 nopass
To polecenie EasyRSA, stworzy nam pełny zestaw certyfikatów i kluczy dla klienta o nazwie client01. W ramach tego polecenia zostaną wygenerowane certyfikat klienta oraz klucz publiczny i prywatny powiązane z tym certyfikatem. Opcja “nopass” wskazuje oczywiście na to, że klucz prywatny nie będzie zabezpieczony hasłem i nie będzie wymagał podania hasła podczas używania.
Wszystkie generowane klucze wylądowały automatycznie w podkatalogu pki. Możemy je sobie podejrzeć
ls -lR pki/
Dla bezpieczeństwa przeniesiemy klucze serwera do nowego podkatalogu w miejscu, gdzie już skopiowaliśmy plik konfiguracyjny serwera OpenVPN
mkdir /etc/openvpn/keys
cp pki/ca.crt /etc/openvpn/keys/
cp pki/dh.pem /etc/openvpn/keys/
cp pki/private/server.key /etc/openvpn/keys/
cp pki/issued/server.crt /etc/openvpn/keys/
Certyfikat i klucz klienta będzie nam potrzebny później do połączenia się z naszą maszyną
3) Konfiguracja serwera OpenVPN
Posiadając już przykładowy plik server.conf skopiowany z katalogu instalacyjnego zmienimy parametry wskazujące na klucze.
sed -i 's|^ca ca.crt$|ca /etc/openvpn/keys/ca.crt|' /etc/openvpn/server.conf
sed -i 's|^cert server.crt$|cert /etc/openvpn/keys/server.crt|' /etc/openvpn/server.conf
sed -i 's|^key server.key.*$|key /etc/openvpn/keys/server.key|' /etc/openvpn/server.conf
sed -i 's|^dh dh2048.pem$|dh /etc/openvpn/keys/dh.pem|' /etc/openvpn/server.conf
Zrezygnujemy z dodatkowej autentykacji dla warstwy zabezpieczeń na poziomie Transport Layer Security (TLS). Wykracza ona poza standardowy poziom zabezpieczeń na poziomie SSL/TLS
sed -i 's|^tls-auth ta.key.*$|; &|' /etc/openvpn/server.conf
Ustawimy też użytkownika i grupę nobody dla środowiska uruchomieniowego OpenVPN. Oznacza to, że OpenVPN będzie uruchamiany z uprawnieniami użytkownika i grupy nobody, co jest właściwą praktyką bezpieczeństwa, w celu ograniczenia potencjalnych zagrożeń wynikających z dostępu do uprawnień administracyjnych, gdyby uruchamiać OpenVPN na użytkowniku z wysokimi uprawnieniami. W tym celu odkomentujemy istniejące już propozycje takiego działania w pliku konfiguracyjnym.
sed -i 's|^;user nobody$|user nobody|' /etc/openvpn/server.conf
sed -i 's|^;group nobody$|group nobody|' /etc/openvpn/server.conf
4) Uruchomienie i przetestowanie OpenVPN
Najpierw dodamy OpenVPN do autostartu
systemctl enable openvpn@server.service
Następnie uruchomimy usługę i sprawdzimy jej status
systemctl start openvpn@server.service
systemctl status openvpn@server.service
Otrzymamy ekran podobny do poniższego.
5) Połączenie się z z serwerem za pomocą OpenVPN
Posiadając wygenerowane klucze stworzymy plik konfiguracyjny klienta OpenVPN służący do połączenia się z naszym środowiskiem po VPN. W notatniku tworzymy plik z rozszerzeniem ovpn o następującej strukturze
client
dev tun
remote N.N.N.N 1194 udp
cipher AES-256-CBC
data-ciphers AES-256-CBC
tls-cipher TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256
auth SHA1
nobind
resolv-retry infinite
persist-key
persist-tun
verb 0
auth-nocache
<ca>
-----BEGIN CERTIFICATE-----
//Tu wklejamy certyfikat z pliku ca.crt //
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
//Tu wklejamy certyfikat z pliku client01.crt //
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
//Tu wklejamy certyfikat z pliku client01.key //
-----END PRIVATE KEY-----
</key>
Jeżeli mamy zainstalowane oprogramowanie do OpenVPN w środowisku Windows (na przykład OpenVPN) możemy klikając dwukrotnie w taki plik zaimportować go a następnie wybrać opcję połącz. Powinniśmy uzyskać połączenie i uzyskać adres IP
Od tej chwili możemy już korzystać z bezpiecznego połączenia po VPN
5) Wykorzystanie połączenia OpenVPN do pracy z systemem Asterisk
Posiadając już bezpieczne połączenie z naszym serwerem gdzie mamy zainstalowany system Asterisk, możemy się łączyć teraz z jego usługami za pomocą tunelu VPN. Dzięki temu nie musimy martwić się o odblokowywanie wrażliwych portów na naszym firewallu i wystawiania ich na świat. Od tej pory nasi klienci będą się łączyć do systemu Asterisk po adresach wewnętrznych. Spójrzmy na obecną konfigurację sieci.
ip a
Na pozycji nr 3 opisanej jako tun0: mamy adres naszej centrali, który możemy wykorzystać do bezpiecznego połączenia. To 10.8.0.1. Jeżeli wywołamy teraz polecenie pokazujące status naszego tunelu zobaczymy ten adres jak i nasze połączenie.
systemctl status openvpn@server.service -l
Nasz windowsowy klient: client-01 otrzymał adres 10.8.0.6 i połaczył się z serwerem na adresie 10.8.0.1. Teraz możemy wykorzystać to połączenie do bezpiecznego zalogowania naszego telefonu do centrali Asterisk za pomoca prywatnego adresu IP. W konfiguracji softphone wpisujemy prywatny adres zamiast publicznego.
Po zalogowaniu telefonu na centrali widzimy go z poziomu konsoli CLI jako dostępnego przez prywatny adres IP, który otrzymaliśmy po połaczeniu się za pomoca tunelu 10.8.0.6
asterisk -rx "sip show peers"
Dodatkowo w logach Asteriska widzimy wykonaną przed chwilą aktywność.
tail -f /var/log/asterisk/messages
Tak utworzony tunel możemy wykorzystać do połączenia się z Managerem naszej centrali Asterisk (AMI) lub na przykład z wystawioną stroną www zainstalowaną na naszym serwerze (np. we FreePBX lub Elastix). Nie musimy wówczas zmniejszać bezpieczeństwa naszego systemu przez wystawianie wrażliwych portów na świat.
Czy wiesz co tak na prawdę dzieje się na Twojej centrali? Wypróbuj nasze autorskie oprogramowanie VOIPERO.
Instalacja i konfiguracja zajmuje kilka minut a system jest obecnie udostępniany całkowicie za darmo.
Dowiedz się jakie możliwości ma system VOIPERO jeżeli chodzi o raportowanie i monitorowanie na żywo systemów VoIP bazujących na Asterisku.
