W tym artykule pokaże na przykładzie jak krok po kroku utworzyć tunel Site-to-Site. W moim przypadku będzie to tunel pomiędzy infrastrukturą zlokalizowaną w chmurze AWS a infrastrukturą zlokalizowana w chmurze Azure. Taki tunel można też uruchomić pomiędzy dowolną infrastrukturą, ważne żeby konfiguracja tunelu uwzględniała zewnętrzne IP które widzą się miedzy sobą. W tym artykule skupię się na pokazaniu konfiguracji od strony AWS i pakietu StrongSwan. Na tą chwilę nie będzie tu opisu czynności konfiguracyjnych niezbędnych do przeprowadzenia po stronie chmury Azure.
Wprowadzenie – czym jest tunel IPSEC?
IPsec to grupa protokołów służących do zabezpieczania połączeń między urządzeniami. IPsec umożliwia ochronę danych przesyłanych przez sieci publiczne. Jest często wykorzystywany do konfigurowania sieci VPN i działa poprzez szyfrowanie pakietów IP wraz z uwierzytelnianiem źródła, z którego pochodzą pakiety. W określeniu „IPsec” „IP” oznacza „Protokół internetowy”, a „sec” oznacza „bezpieczny”. Protokół IPsec jest bezpieczny, ponieważ dodaje do tego procesu szyfrowanie* i uwierzytelnianie.
Do czego służy VPN?
Wirtualna sieć prywatna (VPN) to szyfrowane połączenie między dwoma lub większą liczbą komputerów. Połączenia VPN odbywają się za pośrednictwem sieci publicznych, ale dane wymieniane za pośrednictwem VPN są nadal prywatne, ponieważ są szyfrowane. Sieci VPN umożliwiają bezpieczny dostęp i wymianę poufnych danych za pośrednictwem współdzielonej infrastruktury sieciowej, takiej jak publiczny Internet. Jako przykład można tutaj podać dostęp pracowników przebywających poza biurem do wewnętrznych zasobów organizacji.
Jakie rozwiązania technologiczne pozwolą na uruchomienie tunelu Site to Site?
Możliwości jest bardzo dużo. Wszystko zależy od potrzeb, lokalizacji infrastruktury, koniecznych nakładów pracy, nakładów finansowych oraz często uwarunkowań regulacyjno prawnych.
Poniżej kilka możliwości:
- rozwiązanie natywne dla chmury AWS Site to Site VPN
- rozwiązanie natywne dla chmure Azure Site to Site VPN
- rozwiązania komercyjne na urządzeniach brzegowych (Checkpoint, F5, Cisco, Fortinet i wielu innych)
- rozwiązania opensource (StrongSwan, OPENVPN, pfSense i wielu innych)
Tworzymy tunel Site to Site: modyfikujemy ustawienia maszyny wirtualnej EC2
Potrzebne będzie uruchomienie maszyny wirtualnej EC2 z systemem Linux na której zainstalowane będzie oprogramowanie StrongSwan. W moim środowisku jest to maszyna t2.nano, do której podpięty jest publiczny adres IP. W AWS jes to usługa EIP. Ja w swoim środowisku użyłem instancji z Linux Ubuntu 20.04 LTS. Wszystkie niezbędne pakiety zainstalowałem za pomocą polecenia:
sudo apt install strongswan strongswan-pki libcharon-extra-plugins libcharon-extauth-plugins libstrongswan-extra-plugins libtss2-tcti-tabrmd0 -yWarto skonfigurować aplikację StrongSwan tak żeby automatycznie uruchamiała się po uruchomieniu systemu, można to zrobić za pomocą polecenia:
sudo systemctl enable strongswan-starterNależy jeszcze edytować plik /etc/sysctl.conf w taki sposób żeby aktywny był parametr:
net.ipv4.ip_forward=1
Po tej zmianie należy odświeżyć ustawienia poniższym poleceniem lub wykonać restart maszyny. Polecenie odświeżające ustawienia:sudo sysctl -pTworzymy tunel Site to Site: konfigurujemy ipsec.secrets
W Ubuntu 20.04 LTS plik ten znajduje się w ścieżce /etc/ipsec.secrets, w zależności od użytej dystrybucji plik ten może znajdować się w innym miejscu.
W pliku tym musisz skonfigurować tzw. PSK (Pre-Shared Key), kluczowy element w konfiguracji tunelu mający na celu uwierzytelnienie stron które biorą udział w zestawieniu tunelu. U mnie plik ma taką konfigurację:
# This file holds shared secrets or RSA private keys for authentication.
# RSA private key for this host, authenticating it to any other host
# which knows the public part.
193.194.195.196 196.195.194.193 : PSK "www.tematyka.it_klucz_PSK"
Gdzie:
- 193.194.195.196 – to IP po stronie maszyny ze StrongSwan
- 196.195.194.193 – to IP publiczne po stronie tunelu z którą chcemy się połączyć
- www.tematyka.it_klucz_PSK – klucz PSK uzgodniony i przekazany drugiej stronie, do wpisania po obu stronach tunelu w konfiguracji
Pamiętaj, aby zachować poufność klucza PSK przekaż go w dedykowany, bezpieczny sposób. Pod tym adresem znajdziesz zasady bezpieczeństwa związane z przekazywaniem haseł.
Tworzymy tunel Site to Site: konfigurujemy ipsec.conf
W zależności od użytej dystrybucji, wspomniany plik może znajdować się w innym miejscu. W mojej konfiguracji plik znajduje się w lokalizacji /etc/ipsec.conf
U mnie plik ma taką konfigurację:
config setup
charondebug="all"
uniqueids=yes
conn TEMATYKA.IT
type=tunnel
auto=start
keyexchange=ikev2
authby=secret
left=%defaultroute
leftid=193.194.195.196
leftsubnet=172.31.1.0/24
right=196.195.194.193
rightsubnet=10.20.30.0/24,10.20.40.0/24
ike=aes256-sha256-modp2048
esp=aes256-sha256
aggressive=no
keyingtries=%forever
ikelifetime=28800s
lifetime=3600s
dpddelay=30s
dpdtimeout=120s
dpdaction=restart
Poniżej opis poszczególnych wpisów:
- type – definicja typu połączenia;
- auto – ta opcja oznacza, że po uruchomieniu usługi StrongSwan, podejmie ona próbę nawiązania połączenia zdefiniowanego w pliku konfiguracyjnym /etc/ipsec.conf;
- keyexchange – definiuje jaka wersja protokołu IKE zostanie wykorzystana;
- authby – definiuje jak końce tunelu powinny się uwierzytelnić;
- left – określa zasady dla routingu;
- leftid – określa zewnętrzne IP z którego ruch skierowany jest do maszyny ze StrongSwan, określa tzw. lewą stronę;
- leftsubnet – określa adresację którą chcemy użyć w tunelu;
- right – określa zewnętrzne IP na którym ustanowiony jest drugi koniec tunelu, określa tzw. prawą stronę;
- ike – określa listę algorytmów używanych w Phase 1;
- esp – określa listę algorytmów używanych w Phase 2;
- aggressive – definiuje tryb negocjacji w IKE Phase 1;
- keyingtries – definiuje ilość prób negocjacji kluczy;
- ikelifetime – definiuje czas życia fazy IKE;
- lifetime – definiuje czas życia klucza ESP;
- dpddelay – definiuje czas opóźnienia przed wysłaniem pierwszego zapytania DPD pomagające w wykryciu niedziałającej drugiej strony;
- dpdtimeout -definiuje czas w jakim będzie oczekiwani na odpowiedź drugiej strony w ramach wykrywania niedziałającego partnera;
- dpdaction – definiuje akcję jaką system ma podjąć w przypadku wykrycia niedziałającej strony za pomocą mechanizmu DPD (Dead Peer Detection).
Tworzymy tunel Site to Site: konfigurujemy security group
W Amazon Web Services (AWS), Security Group to jeden z mechanizmów zarządzania bezpieczeństwem, który kontroluje ruch sieciowy do i z zasobów w chmurze AWS. Jest to rodzaj firmy zapory ogniowej, która działa na poziomie instancji EC2 i innych zasobów wirtualnych maszyn.
Jest to niezbędny krok w którym zdefiniujemy zasady obowiązujące ruch sieciowy. Pamiętaj o tym żeby reguły ustawiać bardzo szczegółowe, tzn. jasno definiować źródło, cel i protokół sieciowy wychodzący jak i przychodzący. Unikaj reguł sieciowych zbyt szerokich, oraz ustawiaj wszystko od razu, żeby nie zapomnieć niezbędnego kontekstu i otworzyć tylko taki ruch który jest niezbędny z punktu widzenia zadania. Ja w swojej konfiguracji posłużyłem się konfiguracją zawierającą wpisy dla sieci z maską 24 bity. Poniżej przykładowa Security Group dla hosta na którym jest StrongSwan.
Ruch wychodzący do drugiego końca tunelu (prawej strony).
Ruch przychodzący z drugiego końca tunelu (prawej strony).
Dodatkowo do maszynach które mają brać udział w komunikacji w tunelu należy należy przypisać odpowiednią grupę. W moim przykładzie chodzi tylko o ruch wychodzący.
Tworzymy tunel Site to Site: konfigurujemy niezbędny routing
Pamiętaj że niezbędne jest jeszcze dodanie routingu, tak żeby maszyny z których inicjujesz ruch miały informację gdzie szukać sieci zdalnej. Ustawienia te są zawarte w menu Route tables. W zależności od Twojej konfiguracji może być niezbędna zmiana w innym miejscu. U mnie każda podsieć ma oddzielną tablicę routingu i to w niej definiuje dodatkowe parametry tylko dla tej sieci.
Pamiętaj żeby routing do sieci docelowej ustawić przez instancję, tzn. przez maszynę EC2 na której jest koniec tunelu i zainstalowany StrongSwan. Tak prościej znaleźć odpowiedni host. U mnie AWS później automatycznie zamienia to na interfejs, ale po interfejsach trudniej może być szukać.
Poniżej moja konfiguracja:
Tworzymy tunel Site to Site: testujemy rozwiązanie
Przed fazą testów warto sprawdzić kilka razy czy na pewno wszędzie zostały wpisane takie parametry jak zakładaliśmy. Pozwoli to uniknąć stresu na etapie testów i przemyśleń co i dlaczego jest źle.
Testy należy rozpocząć od zestawienia tunelu pomiędzy stronami. Konfiguracja testowa która zaprezentowałem zakłada że zestawienie tunelu zostanie zainicjowane po restarcie oprogramowania ipsec.
Zatem najpierw trzeba wykonać poniższe polecenie:
sudo ipsec restartKolejne polecenie to już weryfikacja stanu tunelu:
sudo ipsec status TEMATYKA.ITWynik polecenia w momencie gdy tunel zestawił się prawidłowo jest taki:
Security Associations (1 up, 0 connecting):
TEMATYKA.IT[1]: ESTABLISHED 2 seconds ago, 172.31.22.3[193.194.195.196]...196.195.194.193[196.195.194.193]
TEMATYKA.IT{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c4320172_i rtffef_o
TEMATYKA.IT{1}: 172.31.1.0/24 === 10.20.30.0/24 10.20.40.0/24 Ostateczny test można wykonać za pomocą narzędzia telent z maszyny umieszczonej w sieci 172.31.1.0/24 za pomocą polecenia:
telnet 10.20.30.7 22Uzyskany prawidłowy efekt:
Trying 10.20.30.7...
Connected to 10.20.30.7.
Escape character is '^]'.
Tworzymy tunel Site to Site: Debug jeśli nie działa
Kilka przyczyn które mogą spowodować że nie udało się zestawić połączenia:
- nie kompatybilne algorytmy pomiędzy stronami
- błędy i braki w Security Group
Warto w przypadku problemów zajrzeć w logi, w moim przypadku znajdowały się w /var/log/syslog.
Tam warto rozpocząć poszukiwania dlaczego tunel nie chce się zestawić. Jeśli tunel się podniósł prawidłowo ale nie ma możliwości wykonania testu poprzez telnet, warto użyć tcpdump.
Narzędziem tym można podsłuchać ruch na interfejsach sieciowych i na maszynie ze StrongSwan zweryfikować czy widać ruch z maszyny z której ten ruch inicjujemy. Jeśli nie ma tego ruchu to znaczy że blokuje nas jakaś reguła po stronie AWS i tam trzeba szukać przyczyny problemu.
Tworzymy tunel Site to Site: podsumowanie
Poniższy sposób to tylko jedna z możliwości połączenia środowisk w bezpieczny sposób. Jest ona o tyle ciekawa że generuje bardzo małe koszty, przy okazji mając duże możliwości konfiguracji. Wymaga jednak trochę czasu na zrozumienie zasad działania i konfiguracji.