W tej części kursu przechodzimy do protokołów VPN, które stanowią standard w nowoczesnych sieciach korporacyjnych. SSTP, L2TP oraz IPSec to technologie dojrzałe, szeroko przebadane i stosowane w systemach wymagających najwyższego poziomu bezpieczeństwa. Każdy z tych protokołów wnosi unikalne cechy do architektury VPN.

SSTP wykorzystuje szyfrowanie TLS, co czyni go naturalnym wyborem dla środowisk z dominacją systemów Windows. L2TP samo w sobie nie oferuje szyfrowania, ale w połączeniu z IPSec tworzy solidną barierę ochronną. IPSec z kolei jest uniwersalnym frameworkiem zabezpieczającym ruch IP na poziomie sieciowym.

Zrozumienie różnic między tymi protokołami pozwala administratorowi świadomie dobierać rozwiązanie do konkretnych potrzeb. Nie każdy przypadek użycia wymaga tego samego poziomu bezpieczeństwa. W praktyce warto kierować się zasadą równowagi między bezpieczeństwem a wydajnością.

SSTP został zaprojektowany przez Microsoft z myślą o maksymalnej kompatybilności z istniejącą infrastrukturą sieciową. Wykorzystanie portu TCP 443 sprawia, że ruch SSTP jest praktycznie nieodróżnialny od standardowego ruchu HTTPS. Dzięki temu zapory sieciowe, które blokują inne protokoły VPN, zazwyczaj przepuszczają SSTP bez żadnych dodatkowych konfiguracji.

Protokół ten enkapsuluje ramki PPP w ramach sesji SSL/TLS, co zapewnia poufność i integralność danych. W systemie Windows SSTP jest dostępny jako natywny klient VPN, co eliminuje potrzebę instalowania dodatkowego oprogramowania. Proces nawiązywania połączenia rozpoczyna się od uzgodnienia parametrów TLS między klientem a serwerem.

Po zestawieniu bezpiecznego kanału SSL rozpoczyna się standardowa negocjacja PPP. SSTP wspiera różne metody uwierzytelniania, w tym EAP i MS-CHAPv2. W routerach MikroTik implementacja SSTP pozwala na wykorzystanie zaawansowanych funkcji, takich jak przypisywanie adresów IP z określonych pul.

Zrozumienie struktury enkapsulacji SSTP jest kluczowe dla diagnozowania problemów z wydajnością tego protokołu. Na najniższym poziomie mamy oryginalny pakiet IP generowany przez aplikację kliencką. Pakiet ten jest następnie przekazywany do interfejsu PPP, gdzie otrzymuje nagłówek protokołu PPP.

Kolejnym etapem jest dodanie nagłówka SSTP, który zawiera informacje sterujące specyficzne dla tego protokołu. Całość trafia do warstwy SSL/TLS, która odpowiada za szyfrowanie i uwierzytelnianie transmisji. Tak zabezpieczony blok danych jest następnie enkapsulowany w segment TCP z docelowym portem 443.

Każda z tych warstw dodaje pewien narzut, co wpływa na efektywną przepustowość. W przypadku utraty pakietu w warstwie TCP następuje retransmisja, która może powodować kaskadowe opóźnienia. Zjawisko to, znane jako TCP Meltdown, jest głównym ograniczeniem wydajności SSTP w sieciach o podwyższonym poziomie błędów.

Główną zaletą SSTP pozostaje jego zdolność do niezawodnego działania w środowiskach o restrykcyjnych politykach firewall. W praktyce oznacza to, że użytkownicy korzystający z publicznych hotspotów w hotelach czy na lotniskach mogą bezproblemowo nawiązać połączenie VPN.

Ograniczeniem, które należy mieć na uwadze, jest wspomniane zjawisko TCP Meltdown. Gdy warstwa transportowa TCP doświadcza strat pakietów, mechanizm retransmisji działa zarówno na poziomie tunelu, jak i wewnątrz niego, co prowadzi do wykładniczego wzrostu opóźnień. W praktyce objawia się to gwałtownym spadkiem przepustowości przy pierwszym utraconym pakiecie.

SSTP jest również protokołem zamkniętym w sensie prawnym, choć Microsoft udostępnił jego specyfikację. Implementacje na systemy Linux czy RouterOS są odwróconą inżynierią protokołu, co może prowadzić do subtelnych różnic w działaniu. W ekosystemie MikroTik warto zawsze aktualizować oprogramowanie do najnowszej wersji, aby uniknąć znanych błędów implementacyjnych.

Proces generowania certyfikatów w RouterOS wymaga zrozumienia relacji między urzędem certyfikacji a certyfikatem serwera. Urząd CA służy do podpisywania innych certyfikatów i powinien być przechowywany w bezpiecznym miejscu. Kluczową kwestią jest ustawienie odpowiedniego Common Name w certyfikacie serwera, który musi być zgodny z adresem DNS lub IP używanym przez klientów do łączenia się z serwerem.

Parametr subject-alt-name pozwala na dodanie alternatywnych nazw, co jest szczególnie przydatne, gdy serwer jest dostępny pod wieloma adresami. RouterOS używa wewnętrznej bazy certyfikatów, którą można przeglądać w menu /certificate. Po podpisaniu certyfikatu należy zwrócić uwagę na jego okres ważności, który domyślnie wynosi około trzech lat.

W środowisku produkcyjnym zaleca się eksport certyfikatu CA i przechowywanie go w bezpiecznym repozytorium. Pozwala to na szybkie odtworzenie konfiguracji w przypadku awarii routera. Należy pamiętać, że klucz prywatny certyfikatu CA musi pozostać tajny, ponieważ jego kompromitacja umożliwiłaby podszycie się pod nasz serwer VPN.

Po wygenerowaniu certyfikatu serwera należy skonfigurować usługę SSTP w menu interfejsów. Polecenie /interface sstp-server server set uruchamia serwer SSTP z podanymi parametrami. Ważne jest wskazanie odpowiedniego profilu PPP, który definiuje zakres adresów IP przydzielanych klientom oraz serwery DNS.

Parametr authentication=mschap2 określa metodę uwierzytelniania po stronie PPP. MS-CHAPv2 jest obecnie uznawany za akceptowalny standard, choć w środowiskach o podwyższonych wymaganiach bezpieczeństwa warto rozważyć EAP. Opcja force-aes=yes wymusza użycie szyfrowania AES w warstwie SSL, co eliminuje ryzyko negocjacji słabszych algorytmów.

Aspektem często pomijanym jest konieczność udostępnienia portu 443 w firewalu routera. W RouterOS reguła musi być dodana w łańcuchu INPUT, ponieważ serwer SSTP nasłuchuje na połączenia przychodzące. Bez tego połączenia klienckie będą odrzucane na poziomie zapory, co objawia się błędem timeout lub connection refused po stronie klienta.

System Windows domyślnie ufa tylko certyfikatom wydanym przez zaufane urzędy certyfikacji, takie jak DigiCert czy Let's Encrypt. W przypadku użycia własnego CA konieczne jest ręczne dodanie go do magazynu zaufanych certyfikatów. Proces ten polega na wyeksportowaniu z routera certyfikatu CA w formacie .crt i zaimportowaniu go na stacji klienckiej.

Błąd 0x800B0109 pojawia się, gdy klient nie może zweryfikować łańcucha certyfikatów. Oznacza to, że certyfikat serwera został podpisany przez CA, któremu system nie ufa. Aby rozwiązać ten problem, należy zaimportować certyfikat CA do magazynu Zaufane główne urzędy certyfikacji na komputerze lokalnym, a nie na poziomie bieżącego użytkownika.

W domenach Active Directory dystrybucja certyfikatu CA może być zautomatyzowana za pomocą Group Policy. W przypadku pojedynczych stacji roboczych proces można wykonać ręcznie przez konsolę certyfikatów. Po pomyślnym imporcie certyfikat CA będzie widoczny w odpowiednim magazynie, a połączenie SSTP powinno nawiązać się bez błędów.

Diagnostyka problemów SSTP wymaga systematycznego podejścia, ponieważ błędy mogą wynikać z różnych warstw protokołu. Pierwszym krokiem jest weryfikacja poprawności certyfikatu po stronie serwera, w tym sprawdzenie daty ważności i zgodności Common Name z adresem połączenia. Narzędziem pomocnym jest konsola certyfikatów MMC na serwerze Windows lub polecenie /certificate print w RouterOS.

Drugim częstym problemem jest blokada portu 443 przez firewall. Warto sprawdzić, czy na routerze nie działa inna usługa na tym samym porcie, na przykład WebFig czy www-ssl. Konflikt portów można rozwiązać, zmieniając port dla WebFig na alternatywny, na przykład 4443. W systemie Windows błąd 0x80072746 wskazuje na problem z połączeniem TCP, co sugeruje blokadę sieciową.

Trzecim aspektem jest weryfikacja listy odwołania certyfikatów. Windows próbuje pobrać CRL, co przy certyfikatach własnych może powodować opóźnienia. Wpis rejestru NoCertRevocationCheck w kluczu umożliwia wyłączenie tej kontroli, co przyspiesza nawiązywanie połączenia w przypadku braku dostępu do CRL w sieci.

L2TP wywodzi się z połączenia dwóch starszych technologii: PPTP firmy Microsoft oraz L2F firmy Cisco. Protokół ten został zaprojektowany jako warstwa tunelowania działająca niezależnie od używanego protokołu zabezpieczającego. L2TP operuje na porcie UDP 1701 i enkapsuluje pakiety PPP w swoim własnym formacie, dodając nagłówki sterujące.

Ponieważ L2TP sam w sobie nie zapewnia szyfrowania, przesyłane dane są przesyłane w postaci otwartego tekstu. W praktyce L2TP bez IPSec jest używany głównie w sieciach MPLS lub innych środowiskach, gdzie bezpieczeństwo jest zapewniane na niższych warstwach. W kontekście VPN zdalnego dostępu L2TP zawsze występuje w parze z IPSec, który zapewnia poufność i integralność.

Połączenie L2TP i IPSec jest na tyle ścisłe, że większość systemów operacyjnych traktuje je jako jeden protokół. Windows w kreatorze połączenia VPN oferuje typ L2TP/IPSec z kluczem wstępnym, co ukazuje tę współzależność. L2TP zapewnia jedynie mechanizm tunelowania, podczas gdy IPSec odpowiada za wszystkie aspekty bezpieczeństwa.

W architekturze L2TP/IPSec dane użytkownika przechodzą przez wieloetapowy proces enkapsulacji, zanim opuszczą interfejs sieciowy. Najpierw pakiet IP aplikacji jest przekazywany do interfejsu PPP, który dodaje swój nagłówek i trailer. Następnie ramka PPP jest enkapsulowana w pakiecie L2TP, który zawiera nagłówek L2TP i nagłówek UDP z portem źródłowym 1701.

W tym momencie pakiet L2TP/UDP jest przekazywany do podsystemu IPSec. IPSec dodaje nagłówek ESP, który zawiera parametry szyfrowania, a następnie szyfruje całą zawartość pakietu L2TP wraz z danymi PPP. Na końcu dodawany jest nagłówek IP nowego pakietu z adresem serwera VPN jako adresem docelowym. Dla obserwatora zewnętrznego widoczny jest tylko ruch ESP między dwoma adresami IP.

To wielowarstwowe podejście zapewnia, że nawet jeśli atakujący przechwyci pakiety, nie będzie w stanie odczytać ani oryginalnych adresów IP, ani treści przesyłanych danych. Proces deszyfrowania po stronie odbiorcy przebiega w odwrotnej kolejności: najpierw weryfikacja ESP, potem odtworzenie pakietu L2TP, a na końcu ekstrakcja oryginalnej ramki PPP.

IPSec nie jest pojedynczym protokołem, lecz kompleksowym frameworkiem składającym się z wielu komponentów. Główne elementy to protokoły zabezpieczające AH i ESP, protokół wymiany kluczy IKE oraz baza danych Security Policy Database i Security Association Database. IPSec działa w warstwie sieciowej, co oznacza, że jest przezroczysty dla aplikacji, które nie wymagają żadnych modyfikacji.

Mechanizm Anti-Replay w IPSec chroni przed atakami polegającymi na przechwyceniu i ponownym wysłaniu ważnych pakietów. Każdy pakiet ESP otrzymuje sekwencyjny numer, a odbiorca utrzymuje okno przesuwne, odrzucając pakiety o numerach spoza tego okna. Jest to szczególnie istotne w sieciach, gdzie atakujący może przechwycić i replikować pakiety.

IPSec oferuje również elastyczność w zakresie zarządzania kluczami. Administrator może wybrać między ręcznym ustawieniem kluczy a automatyczną wymianą za pomocą IKE. W praktyce produkcyjnej zawsze stosuje się IKE, ponieważ ręczne zarządzanie kluczami jest podatne na błędy i nie skaluje się do większej liczby tuneli.

Protokół AH jest rzadko używany w nowoczesnych sieciach VPN z kilku powodów. Po pierwsze, AH nie szyfruje danych, zapewniając jedynie integralność i uwierzytelnianie. Po drugie, AH działa na oryginalnym nagłówku IP, co powoduje problemy z translacją NAT. Modyfikacja adresu IP przez NAT narusza integralność obliczaną przez AH, co powoduje odrzucenie pakietu.

ESP jest zdecydowanie dominującym wyborem, ponieważ zapewnia zarówno szyfrowanie, jak i integralność. W trybie tunelowym ESP enkapsuluje cały oryginalny pakiet IP, co pozwala na bezpieczne przesyłanie ruchu między sieciami. ESP używa protokołu IP numer 50, który musi być przepuszczany przez zapory sieciowe.

W praktyce konfiguracyjnej na routerach MikroTik domyślnie używany jest ESP, co jest właściwym wyborem. Jeśli w konfiguracji widzimy opcję wyboru między AH a ESP, zawsze należy wybrać ESP. Warto również pamiętać, że nowoczesne implementacje IPSec obsługują tryb ESP z integralnością, co eliminuje potrzebę stosowania AH nawet w scenariuszach wymagających wyłącznie weryfikacji autentyczności.

Transport mode jest często używany w połączeniu z L2TP, gdzie L2TP zapewnia tunelowanie, a IPSec zabezpiecza tylko zawartość pakietu. W tym trybie nagłówek IP pozostaje oryginalny, co oznacza, że adresy źródła i miejsca przeznaczenia są widoczne dla urządzeń pośredniczących. Jest to dopuszczalne w scenariuszach klient-serwer, gdzie tożsamość klienta nie musi być ukrywana.

Tunnel mode tworzy zupełnie nowy pakiet IP z nowymi adresami źródła i docelowymi, najczęściej odpowiadającymi bramom VPN. Oryginalny pakiet IP jest całkowicie ukryty wewnątrz nowego pakietu IPSec. Jest to zalecany tryb dla połączeń Site-to-Site, gdzie chcemy ukryć wewnętrzną topologię sieci przed światem zewnętrznym.

Wybór między trybem transportowym a tunelowym ma również wpływ na wielkość narzutu protokołowego. Tunnel mode dodaje dodatkowy nagłówek IP, co zwiększa rozmiar pakietu o około 20 bajtów więcej niż transport mode. W praktyce dla połączeń L2TP/IPSec i tak używany jest transport mode, ponieważ tunelowanie zapewnia już warstwa L2TP, a IPSec chroni tylko dane.

Protokół IKE jest fundamentem bezpiecznej komunikacji IPSec, ponieważ bez uprzedniego uzgodnienia kluczy żadne szyfrowanie nie może nastąpić. IKE działa na porcie UDP 500 i wykorzystuje protokół ISAKMP do ramowej struktury komunikacji. Sam proces wymiany kluczy opiera się na algorytmie Diffie-Hellmana, który pozwala dwóm stronom na uzgodnienie wspólnego sekretu nawet przez niezabezpieczone medium.

Bezpieczeństwo IKE opiera się na koncepcji Perfect Forward Secrecy. Oznacza to, że nawet jeśli atakujący przechwyci klucz prywatny jednej sesji, nie będzie w stanie odszyfrować poprzednich ani przyszłych sesji. Każda nowa negocjacja IKE generuje nowe klucze sesyjne, które są matematycznie niezależne od poprzednich.

Błąd Proposal mismatch jest jednym z najbardziej frustrujących w diagnostyce IPSec, ponieważ nie zawsze wiadomo, który parametr nie jest zgodny. W logach RouterOS komunikaty typu no acceptable proposal pojawiają się, gdy proponowane algorytmy szyfrowania, metody skrótu lub grupy DH nie pokrywają się między stronami. Rozwiązaniem jest systematyczne dopasowywanie kolejnych parametrów aż do uzyskania zgodności.

Faza 1 IKE, znana również jako ustanowienie ISAKMP SA, jest najważniejszym etapem negocjacji bezpiecznego kanału. Podczas tej fazy obie strony uzgadniają zestaw algorytmów kryptograficznych, metody uwierzytelniania oraz grupę Diffie-Hellmana. Wynikiem Fazy 1 jest bezpieczny kanał kontrolny, który będzie używany do ochrony dalszej komunikacji IKE.

Main Mode składa się z sześciu pakietów wymienianych w trzech parach. W pierwszej parze strony negocjują propozycje algorytmów. W drugiej parze następuje właściwa wymiana kluczy Diffie-Hellmana. W trzeciej parze strony uwierzytelniają się nawzajem za pomocą PSK lub certyfikatów. Aggressive Mode przyspiesza proces do trzech pakietów kosztem niższego bezpieczeństwa, ponieważ tożsamość stron jest przesyłana wcześniej.

Wybór grupy Diffie-Hellmana ma bezpośredni wpływ na bezpieczeństwo wymiany kluczy. Grupa 1 i grupa 2 są obecnie uznawane za słabe. Grupa 14 jest minimalnym zalecanym poziomem, a grupa 16 zapewnia wysoki margines bezpieczeństwa. Większe grupy DH zwiększają bezpieczeństwo, ale również wydłużają czas obliczeń podczas inicjalizacji tunelu.

Po pomyślnym ustanowieniu ISAKMP SA w Fazie 1 rozpoczyna się Faza 2, której celem jest utworzenie właściwych stowarzyszeń bezpieczeństwa IPSec SA dla ruchu danych. Negocjacja Fazy 2 odbywa się wewnątrz chronionego kanału ustanowionego w Fazie 1, co oznacza, że wszystkie przesyłane parametry są już szyfrowane.

W Fazie 2 strony uzgadniają konkretne algorytmy ESP, które mogą różnić się od tych użytych w Fazie 1. Na przykład Faza 1 może używać AES-256 z SHA-256, podczas gdy Faza 2 będzie używać AES-128 z SHA-1 dla większej wydajności. Strony określają również sieci źródłowe i docelowe, które mają być chronione, co jest kluczowe dla polityk IPSec.

Parametr lifetime dla IPSec SA jest zazwyczaj krótszy niż dla ISAKMP SA i wynosi standardowo od 1 do 8 godzin. Po wygaśnięciu lifetime tunelu IPSec następuje automatyczna renegocjacja, która powinna przebiegać płynnie bez przerywania transmisji danych. W RouterOS ważne jest monitorowanie stanu IPSec SA za pomocą polecenia /ip ipsec active-peers print, które pokazuje aktualnie aktywne tunele.

Problem NAT z protokołem ESP wynika z fundamentalnej różnicy między warstwą sieciową a transportową. ESP nie używa portów TCP ani UDP, ponieważ jest protokołem warstwy IP o numerze 50. Urządzenia NAT muszą śledzić połączenia na podstawie portów, a w przypadku ESP nie mają takiej możliwości, co uniemożliwia prawidłową translację adresów.

Mechanizm NAT-Traversal rozwiązuje ten problem poprzez enkapsulację pakietów ESP w ramki UDP z portem 4500. Dodatkowo podczas negocjacji IKE strony wymieniają payload NAT-Discovery, który pozwala wykryć obecność urządzeń NAT między nimi. Jeśli NAT zostanie wykryty, ruch ESP jest automatycznie przełączany na UDP 4500.

W konfiguracji firewalla należy uwzględnić zarówno porty IKE, jak i NAT-T. Otwarcie tylko UDP 500 i protokołu 50 może nie wystarczyć, jeśli klient znajduje się za NATem. W takim przypadku niezbędne jest również otwarcie UDP 4500. W RouterOS należy upewnić się, że opcja ipsec-encapsulation jest włączona w konfiguracji peera, aby umożliwić NAT-T.

RouterOS oferuje znacznie uproszczoną konfigurację L2TP/IPSec w porównaniu do ręcznego ustawiania wszystkich parametrów IPSec. Funkcja one-click IPSec automatycznie tworzy niezbędne wpisy w menu IP IPSec, w tym obiekty Peer, Identity i Policy. Administrator musi jedynie określić wspólny sekret IPSec i włączyć opcję use-ipsec w konfiguracji serwera L2TP.

Automatycznie generowane polityki IPSec używają domyślnych ustawień proposal, które mogą nie być optymalne dla wszystkich scenariuszy. W niektórych przypadkach administrator może potrzebować dostosować algorytmy szyfrowania w menu /ip ipsec proposal. Domyślnie RouterOS oferuje szeroki wachlarz algorytmów, co zwiększa kompatybilność kosztem bezpieczeństwa.

Mimo automatyzacji warto ręcznie zweryfikować wygenerowane obiekty IPSec po pierwszym uruchomieniu. Czasami konieczne jest dostosowanie parametrów takich jak lifetime czy grupa DH, aby zapewnić zgodność z klientami innych producentów. Dobrą praktyką jest przeglądnięcie zakładki IP IPSec Peers i upewnienie się, że tryb wymiany jest odpowiedni dla planowanych klientów.

Konfiguracja serwera L2TP/IPSec w RouterOS sprowadza się do kilku kluczowych poleceń, które uruchamiają cały stos protokołów. Parametr use-ipsec=yes jest przełącznikiem, który aktywuje automatyczne generowanie polityk bezpieczeństwa. Wartość ipsec-secret jest wspólnym kluczem wstępnym używanym przez wszystkich klientów, co ma zarówno zalety, jak i wady.

Użycie jednego PSK dla wszystkich klientów upraszcza konfigurację, ale zmniejsza bezpieczeństwo. Jeśli klucz zostanie skompromitowany, każdy klient będzie musiał zostać przekonfigurowany. W środowiskach wymagających wyższego poziomu bezpieczeństwa warto rozważyć użycie certyfikatów zamiast PSK. RouterOS wspiera uwierzytelnianie certyfikatami dla L2TP/IPSec, choć wymaga to bardziej zaawansowanej konfiguracji.

Profil PPP ustawiony w default-profile określa pulę adresów IP, serwery DNS oraz inne parametry sieciowe dla klientów. Właściwe skonfigurowanie profilu jest kluczowe, ponieważ klienci otrzymają adresy IP z tej puli, a routing na routerze automatycznie skieruje ruch do tych adresów przez interfejs tunelowy. Należy również pamiętać o dodaniu reguł NAT dla ruchu wychodzącego z sieci VPN do Internetu.

Reguły firewalla dla L2TP/IPSec muszą precyzyjnie przepuszczać ruch związany z negocjacją i transmisją tunelu. Łańcuch INPUT jest tutaj kluczowy, ponieważ serwer VPN musi akceptować połączenia przychodzące od klientów. Każda z czterech reguł pokazanych na slajdzie odpowiada za inny aspekt komunikacji IPSec.

Reguła dla UDP 500 pozwala na ruch IKE, czyli negocjację parametrów bezpieczeństwa. Reguła dla UDP 4500 umożliwia NAT-T, który jest niezbędny dla klientów znajdujących się za translacją adresów. Reguła dla protokołu ESP przepuszcza właściwy ruch szyfrowany. Reguła dla UDP 1701 jest potrzebna dla sterowania L2TP, choć w praktyce ruch L2TP jest chroniony przez IPSec.

Warto również dodać reguły w łańcuchu FORWARD dla ruchu przechodzącego przez tunel. Bez tego pakiety klientów VPN nie będą mogły dotrzeć do zasobów w sieci wewnętrznej. Dodatkowo należy upewnić się, że reguły NAT w łańcuchu srcnat nie modyfikują pakietów przeznaczonych do sieci VPN, ponieważ może to zakłócić działanie IPSec.

Konfiguracja klienta Windows dla L2TP/IPSec różni się nieco od konfiguracji PPTP, głównie ze względu na konieczność podania klucza wstępnego IPSec. W kreatorze połączenia sieciowego należy wybrać opcję L2TP/IPSec z kluczem wstępnym, a następnie wprowadzić ten sam klucz, który został zdefiniowany na serwerze jako ipsec-secret.

Właściwości połączenia VPN w systemie Windows pozwalają na dodatkowe dostosowanie parametrów. W zakładce Zabezpieczenia można wybrać typ szyfrowania oraz metodę uwierzytelniania. Dla L2TP/IPSec zaleca się ustawienie szyfrowania wymaganego, co uniemożliwi połączenie w przypadku, gdy serwer nie będzie mógł zapewnić szyfrowania.

Jeśli połączenie nie nawiązuje się od razu, warto sprawdzić ustawienia zaawansowane w Panelu sterowania. W systemie Windows 10 i 11 domyślnym ustawieniem jest próba automatycznego wykrycia typu VPN, co może prowadzić do błędów. Zawsze jawnie określaj typ VPN jako L2TP/IPSec z kluczem wstępnym, aby uniknąć problemów z nieprawidłowym wykrywaniem protokołu.

Problem z połączeniem L2TP/IPSec za NAT wynika z domyślnych ustawień bezpieczeństwa systemu Windows. System domyślnie nie akceptuje enkapsulacji UDP dla IPSec, gdy serwer znajduje się za NAT, ponieważ może to być próba ataku typu man-in-the-middle. Klucz rejestru AssumeUDPEncapsulationContextOnSendRule kontroluje to zachowanie i wymaga ustawienia wartości 2.

Wartość 2 oznacza, że klient Windows będzie zakładał, że zarówno klient, jak i serwer mogą znajdować się za NAT. Jest to najbezpieczniejsza opcja umożliwiająca połączenie. Wartość 1 zakłada NAT tylko po stronie klienta, a wartość 0 wyłącza obsługę NAT. Po zmianie rejestru konieczne jest ponowne uruchomienie komputera lub usługi Policy Agent.

Scenariusz, w którym ta modyfikacja jest niezbędna, występuje niezwykle często w praktyce. Wielu dostawców Internetu używa translacji adresów w swojej sieci szkieletowej, nawet jeśli klient ma publiczny adres IP na swoim routerze. Bez tej zmiany klienci Windows zgłaszają błąd 789 lub 809, które są mylnie interpretowane jako problem z firewallem lub certyfikatami.

Tunel IPSec Site-to-Site różni się zasadniczo od rozwiązań zdalnego dostępu. W tym modelu nie ma serwera i klienta, lecz dwie równe sobie bramy VPN, które łączą ze sobą całe sieci LAN. Każdy host w sieci A może komunikować się z dowolnym hostem w sieci B bez potrzeby instalowania dodatkowego oprogramowania, ponieważ routery automatycznie szyfrują i deszyfrują ruch.

Brak wirtualnych interfejsów w tym modelu oznacza, że nie trzeba definiować adresacji IP dla tunelu. Router podejmuje decyzję o szyfrowaniu na podstawie adresów źródłowych i docelowych pakietów. Jeśli pakiet pochodzi z sieci lokalnej i jest adresowany do sieci zdalnej, zostaje przechwycony przez politykę IPSec, zaszyfrowany i wysłany przez tunel.

Policy Based Routing w Site-to-Site pozwala na bardzo precyzyjne definiowanie, jaki ruch ma być szyfrowany. W praktyce jednak najczęściej szyfruje się cały ruch między sieciami. Wydajność takiego rozwiązania jest wysoka, ponieważ nowoczesne routery oferują akcelerację sprzętową AES, co pozwala osiągnąć przepustowość bliską prędkości interfejsów fizycznych.

Konfiguracja profilu IPSec w RouterOS definiuje zestaw parametrów dla Fazy 1 negocjacji IKE. Wybór algorytmu szyfrowania enc-algorithm oraz grupy DH dh-group ma kluczowe znaczenie dla bezpieczeństwa połączenia. W profilu s2s_profile używamy AES-256 z grupą modp2048, co stanowi solidny standard bezpieczeństwa dla połączeń między oddziałami.

Definicja peera określa zdalną bramę VPN, z którą nawiązywany jest tunel. Adres IP peera to publiczny adres drugiego routera. Ważne jest, aby adres ten był statyczny lub aby skonfigurować dynamiczne DNS, jeśli adres IP zmienia się w czasie. RouterOS obsługuje również połączenia z peerami o dynamicznych adresach IP, ale wymaga to użycia trybu Aggressive Mode.

Identity to obiekt przechowujący klucz uwierzytelniający dla danego peera. W przypadku PSK hasło jest używane podczas Fazy 1 do wzajemnego potwierdzenia tożsamości. Należy pamiętać, że klucz PSK jest przechowywany w konfiguracji routera w postaci zaszyfrowanej, ale jego siła zależy od długości i złożoności. Zaleca się używanie haseł o długości co najmniej 20 znaków zawierających znaki specjalne.

Polityki IPSec definiują, który ruch sieciowy ma być szyfrowany i jakie parametry ESP mają być użyte. Parametry src-address i dst-address określają odpowiednio sieć źródłową i docelową, które podlegają ochronie. W przypadku Routera A sieć źródłowa to 192.168.10.0/24, a docelowa to 192.168.20.0/24, czyli sieci LAN po obu stronach tunelu.

Parametr action=encrypt nakazuje szyfrowanie pakietów spełniających kryteria polityki. Opcja tunnel=yes włącza tryb tunelowy, w którym cały oryginalny pakiet IP jest enkapsulowany w nowy pakiet IPSec. Jest to standardowy wybór dla połączeń Site-to-Site. W trybie transportowym opcja tunnel=no enkapsuluje tylko dane, pozostawiając oryginalny nagłówek IP bez zmian.

Zasada lustrzanego odbicia oznacza, że polityka na Routerze B musi być przeciwna: src-address=192.168.20.0/24 i dst-address=192.168.10.0/24. Jeśli polityki nie są lustrzane, tunel nie zostanie zestawiony lub ruch będzie przesyłany nieszyfrowany. Warto również sprawdzić parametry proposal w polityce, które określają algorytmy ESP dla Fazy 2.

Interakcja między NAT a IPSec jest jednym z najczęstszych źródeł problemów w konfiguracji VPN. Gdy router wykonuje maskaradę na ruchu przeznaczonym do sieci VPN, zmienia adres źródłowy pakietu przed jego zaszyfrowaniem. Polityka IPSec nie rozpoznaje już pakietu jako przeznaczonego do ochrony, ponieważ adres źródłowy nie zgadza się z definicją src-address.

Reguła wyjątku NAT działa poprzez jawną akceptację ruchu między sieciami VPN jeszcze przed regułą maskarady. W RouterOS reguły w łańcuchu srcnat są przetwarzane od góry do dołu, więc pierwsza dopasowana reguła decyduje o działaniu. Umieszczenie reguły accept dla ruchu VPN na początku łańcucha zapobiega jego modyfikacji przez regułę masquerade znajdującą się niżej.

Podobny problem może wystąpić w firewalu FastTrack, który przyspiesza ruch pomijając przetwarzanie reguł. Ruch objęty FastTrack nie trafia do polityk IPSec, więc tunel nie działa. Rozwiązaniem jest dodanie reguły w tabeli RAW, która wyłącza FastTrack dla ruchu VPN. Właściwe skonfigurowanie wyjątków NAT i FastTrack jest warunkiem koniecznym działania IPSec Site-to-Site w routerach MikroTik.

FastTrack to mechanizm przyspieszający działanie routera poprzez pomijanie zaawansowanego przetwarzania pakietów w firewalii. Gdy połączenie jest kwalifikowane do FastTrack, pakiety nie są już sprawdzane przez reguły filter ani NAT, co znacznie zwiększa przepustowość. Niestety oznacza to również, że IPSec nie ma szansy przechwycić tych pakietów do zaszyfrowania.

Objawem konfliktu FastTrack z IPSec jest sytuacja, w której tunel IPSec jest zestawiony i widoczny jako aktywny, ale ruch między sieciami nie jest szyfrowany. Pakiety przesyłane są w postaci otwartego tekstu, co można potwierdzić za pomocą sniffera pakietów na interfejsie WAN. Aby rozwiązać ten problem, należy dodać regułę w tabeli RAW, która wyłącza FastTrack dla ruchu przeznaczonego do tunelu.

Przykładowa reguła RAW w RouterOS wygląda następująco: /ip firewall raw add chain=prerouting src-address=192.168.10.0/24 dst-address=192.168.20.0/24 action=notrack. Reguła ta nakazuje nie śledzić pakietów między sieciami VPN, co zapobiega ich przyspieszeniu przez FastTrack. Dzięki temu pakiety trafiają do normalnego przetwarzania i mogą być przechwycone przez politykę IPSec.

Analiza pakietów jest podstawowym narzędziem diagnostycznym w przypadku problemów z IPSec. Narzędzie Sniffer w RouterOS pozwala na przechwytywanie pakietów na dowolnym interfejsie i wyświetlanie ich w czasie rzeczywistym. Aby potwierdzić działanie tunelu, należy uruchomić sniffer na interfejsie WAN i obserwować typ pakietów wysyłanych między bramami VPN.

Prawidłowo działający tunel IPSec generuje wyłącznie pakiety ESP na interfejsie WAN. Pakiety te mają stałą długość, ponieważ szyfrowanie maskuje rzeczywistą wielkość danych. Jeśli na interfejsie WAN widoczne są pakiety z adresami prywatnymi sieci LAN, oznacza to, że polityka IPSec nie przechwytuje ruchu. Jest to alarmująca sytuacja, ponieważ dane są przesyłane bez szyfrowania przez Internet.

Dodatkowo obecność pakietów UDP 500 lub 4500 na interfejsie WAN jest normalna podczas negocjacji lub odświeżania sesji. Stały strumień tych pakietów może wskazywać na problem z utrzymaniem sesji IKE. W takim przypadku warto sprawdzić logi IPSec w RouterOS za pomocą /log print where topics ipsec, które często zawierają szczegółowe informacje o błędach negocjacji.

IKEv2 został zaprojektowany od podstaw, aby rozwiązać problemy wydajnościowe i bezpieczeństwa występujące w IKEv1. Najważniejszą innowacją jest redukcja liczby wymienianych pakietów z sześciu do czterech dla ustanowienia bezpiecznego kanału. Przekłada się to na szybsze nawiązywanie połączenia, co jest szczególnie istotne w sieciach komórkowych o zmiennej latencji.

Mechanizm MOBIKE jest prawdopodobnie najważniejszą funkcją IKEv2 z punktu widzenia użytkowników mobilnych. Pozwala on na zmianę adresu IP klienta bez konieczności ponownej negocjacji całego tunelu. Jeśli użytkownik przełącza się z Wi-Fi na LTE, tunel VPN pozostaje aktywny, a zmiana adresu IP jest obsługiwana w tle bez przerywania połączeń aplikacji.

IKEv2 wspiera również zaawansowane metody uwierzytelniania, w tym EAP, co pozwala na integrację z istniejącą infrastrukturą AAA. W środowiskach korporacyjnych oznacza to możliwość użycia kart smart, certyfikatów czy jednorazowych haseł. RouterOS wspiera IKEv2 od wersji 6.x, ale niektóre starsze urządzenia mogą wymagać aktualizacji oprogramowania.

RouterOS domyślnie używa IKEv1 dla zachowania kompatybilności z szeroką gamą urządzeń. Aby włączyć IKEv2, należy ręcznie zmienić parametr exchange-mode w konfiguracji peera na ike2. Warto przy tym pamiętać, że obie strony muszą obsługiwać IKEv2, w przeciwnym razie negocjacja zakończy się błędem. Nie ma możliwości automatycznego przełączenia między IKEv1 a IKEv2 w trakcie negocjacji.

Konfiguracja klienta Windows dla IKEv2 jest bardziej wymagająca niż dla L2TP/IPSec z PSK. Windows wymaga certyfikatów maszynowych do uwierzytelnienia klienta lub zaawansowanej konfiguracji EAP. W środowisku domenowym certyfikaty mogą być automatycznie dystrybuowane przez Group Policy. W przypadku pracy grupowej konieczne jest ręczne wygenerowanie i zainstalowanie certyfikatu klienckiego.

Pomimo wyższej złożoności początkowej, IKEv2 oferuje najlepsze parametry użytkowe. Łącza mobilne charakteryzujące się częstymi zmianami adresu IP działają stabilniej niż przy użyciu IKEv1. Dodatkowo IKEv2 jest bardziej odporny na ataki DoS, ponieważ opóźnia kosztowne obliczenia kryptograficzne do momentu potwierdzenia tożsamości klienta.

SSTP i L2TP/IPSec reprezentują dwa różne podejścia do zabezpieczania ruchu VPN. SSTP stawia na maksymalną kompatybilność z istniejącą infrastrukturą sieciową, wykorzystując powszechnie otwarty port 443. L2TP/IPSec stawia na wydajność dzięki protokołowi UDP, ale wymaga otwarcia wielu portów w firewalii. Wybór między nimi zależy od środowiska, w którym będą pracować użytkownicy.

Wydajność L2TP/IPSec jest zazwyczaj wyższa niż SSTP przy stabilnych łączach, ponieważ UDP nie ma narzutu retransmisji. Jednak w sieciach z agresywnym QoS lub limitowaniem przepustowości UDP, SSTP może działać lepiej, ponieważ ruch TCP 443 jest często traktowany priorytetowo. Testy porównawcze pokazują, że L2TP/IPSec osiąga około 20-30% wyższą przepustowość przy niskiej latencji.

Z punktu widzenia bezpieczeństwa oba protokoły oferują porównywalny poziom ochrony przy właściwej konfiguracji. SSTP używa TLS, który jest szeroko audytowany, podczas gdy IPSec jest standardem IETF z wieloletnią historią analiz kryptograficznych. Rzeczywista różnica w bezpieczeństwie zależy bardziej od doboru algorytmów i zarządzania kluczami niż od samego protokołu.

Błąd Phase 2 state failed jest jednym z najczęstszych komunikatów diagnostycznych w logach IPSec. Pojawia się, gdy negocjacja Fazy 2 nie może dojść do skutku, mimo że Faza 1 przebiegła pomyślnie. Najczęstszą przyczyną jest niezgodność parametrów ESP między stronami, takich jak algorytm szyfrowania czy metoda integralności.

Aby zdiagnozować ten błąd, należy porównać konfigurację proposal po obu stronach. W RouterOS polecenie /ip ipsec proposal print wyświetla listę dostępnych propozycji. Należy upewnić się, że istnieje co najmniej jedna wspólna propozycja między routerami. W przypadku dłuższej listy propozycji RouterOS negocjuje pierwszą pasującą, dlatego kolejność ma znaczenie.

Inną przyczyną błędu może być niezgodność sieci źródłowych i docelowych w politykach. Jeśli polityka na Routerze A definiuje src 192.168.10.0/24 i dst 192.168.20.0/24, a na Routerze B src 192.168.20.0/24 i dst 192.168.10.0/24, wszystko jest w porządku. Jeśli jednak któryś z parametrów jest inny, negocjacja zakończy się błędem Phase 2 failed. Warto również sprawdzić, czy polityki nie pomijają niezbędnego ruchu.

Błąd Peer not reachable sygnalizuje, że router nie może nawiązać komunikacji IKE z zdalną bramą VPN. W logach pojawia się komunikat retransmit phase1, który oznacza, że Router A wysyła pakiety IKE do Routera B, ale nie otrzymuje odpowiedzi. Najczęstszą przyczyną jest blokada ruchu UDP 500 na którymś z firewalli po drodze.

Proces diagnostyki należy rozpocząć od sprawdzenia podstawowej łączności sieciowej. Polecenie ping do adresu peera pozwoli potwierdzić, że routery mają wzajemną connectivity. Jeśli ping działa, ale IKE nie, problem leży w firewalii. W RouterOS warto sprawdzić liczniki reguł firewall, aby przekonać się, czy pakiety IKE są akceptowane czy odrzucane.

Dostawcy Internetu coraz częściej blokują ruch protokołów VPN na swoich routerach brzegowych. W niektórych krajach blokada IKE i ESP jest standardową praktyką. W takim przypadku rozwiązaniem może być przejście na protokół SSTP lub skonfigurowanie IPSec przez NAT-T z użyciem portu 4500 zamiast 500. Narzędzie Sniffer w RouterOS jest nieocenione w tym scenariuszu.

Dobór algorytmów kryptograficznych ma bezpośredni wpływ na bezpieczeństwo tunelu VPN. AES w trybie GCM jest obecnie rekomendowanym wyborem, ponieważ łączy szyfrowanie z uwierzytelnianiem w jednym, wydajnym procesie. W przeciwieństwie do AES-CBC, który wymaga oddzielnego algorytmu HMAC dla integralności, AES-GCM produkuje tag uwierzytelniający jako integralną część procesu szyfrowania.

Mechanizmy skrótu używane w IPSec służą do zapewnienia integralności komunikatów IKE oraz danych ESP. SHA-256 zapewnia 256-bitową wartość skrótu, która jest praktycznie odporna na kolizje przy obecnym stanie wiedzy kryptograficznej. SHA-1, mimo że nadal szeroko stosowany, ma znane słabości teoretyczne i powinien być stopniowo wycofywany.

Grupy Diffie-Hellmana określają siłę wymiany kluczy w Fazie 1. Grupa 14 jest minimalnym zalecanym poziomem zgodnie z wytycznymi NIST. Grupa 16 oferuje jeszcze wyższy poziom bezpieczeństwa, ale kosztem dłuższego czasu obliczeń przy inicjalizacji tunelu. W sieciach o niskim budżecie obliczeniowym można rozważyć grupy krzywych eliptycznych, które oferują porównywalne bezpieczeństwo przy niższym zapotrzebowaniu na moc obliczeniową.

Akceleracja sprzętowa AES to technologia, która znacząco podnosi wydajność szyfrowania w routerach. Procesory wyposażone w instrukcje AES-NI wykonują operacje szyfrowania bezpośrednio na poziomie sprzętowym, bez konieczności ładowania danych do pamięci operacyjnej. W praktyce oznacza to, że router może przetwarzać szyfrowany ruch z prędkością zbliżoną do prędkości interfejsów fizycznych.

Routery MikroTik z serii CCR, hEX czy RB4011 posiadają sprzętowe wsparcie dla AES, co jest kluczowe przy planowaniu wydajności VPN. Różnica między szyfrowaniem programowym a sprzętowym może być dziesięciokrotna. Router RB951 bez AES-NI osiąga około 30 Mbps przez tunel IPSec, podczas gdy hEX z AES-NI osiąga ponad 500 Mbps przy minimalnym obciążeniu procesora.

Warunkiem wykorzystania akceleracji sprzętowej jest wybór algorytmów wspieranych przez dany układ. Większość układów wspiera AES-CBC i AES-GCM, ale niekoniecznie inne tryby. W RouterOS należy upewnić się, że użyte propozycje IPSec zawierają algorytmy obsługiwane przez hardware. Jeśli router nie wspiera AES-NI, jedynym rozwiązaniem dla wysokich przepustowości jest użycie lżejszego protokołu VPN.

Scenariusze praktyczne pokazują, że nie istnieje uniwersalny protokół VPN odpowiedni do wszystkich sytuacji. Dla użytkowników mobilnych podróżujących i korzystających z sieci hotelowych SSTP jest najbezpieczniejszym wyborem, ponieważ port 443 jest prawie zawsze otwarty. W przypadku korporacyjnych stacji roboczych, które łączą się z biura lub domu, L2TP/IPSec oferuje dobrą równowagę między wydajnością a bezpieczeństwem.

Połączenia między oddziałami firmy to domena czystego IPSec w trybie tunelowym. W tym scenariuszu nie ma potrzeby użycia L2TP ani PPP, ponieważ routery łączą całe sieci LAN. IPSec Site-to-Site zapewnia najwyższą przepustowość przy najniższym narzucie protokołowym, szczególnie gdy routery obsługują akcelerację sprzętową AES.

W praktyce warto stosować strategię hybrydową. Firma może używać IPSec Site-to-Site do połączenia oddziałów, SSTP dla mobilnych użytkowników Windows, a IKEv2 dla urządzeń z systemami iOS i Android. Takie podejście pozwala optymalnie dopasować protokół do konkretnego przypadku użycia, zapewniając najlepsze parametry wydajnościowe i bezpieczeństwa dla każdej grupy użytkowników.

Podsumowanie konfiguracji w RouterOS stanowi praktyczny checklist dla administratora wdrażającego VPN. Pierwszym krokiem zawsze jest przygotowanie profilu PPP, który definiuje pulę adresów IP dla klientów oraz serwery DNS. W profilu można również ustawić parametry QoS, limity czasowe połączenia oraz inne zaawansowane opcje, takie jak transparentowanie proxy czy przekierowanie domyślnej trasy.

Definicja kont użytkowników w PPP Secrets jest kolejnym etapem. Każdy klient VPN potrzebuje indywidualnego loginu i hasła, które będą używane podczas uwierzytelniania PPP. W RouterOS można również ustawić statyczne przypisanie adresów IP dla konkretnych użytkowników. Po skonfigurowaniu serwera i użytkowników należy aktywować odpowiednią usługę serwerową.

Ostatnim, ale często pomijanym krokiem jest konfiguracja firewalla. Otwarcie portów w łańcuchu INPUT jest niezbędne dla ruchu przychodzącego, ale równie ważne jest skonfigurowanie odpowiednich reguł FORWARD dla ruchu przechodzącego przez tunel. Bez tego klienci VPN nie będą mogli komunikować się z zasobami sieci wewnętrznej. Należy również pamiętać o regułach NAT, jeśli klienci VPN mają mieć dostęp do Internetu przez router.

Konfiguracja stacji Windows wymaga uwagi na kilka krytycznych szczegółów, które decydują o powodzeniu połączenia. Przede wszystkim należy jawnie wybrać typ VPN w zaawansowanych ustawieniach połączenia, zamiast polegać na trybie automatycznym. Automatyczne wykrywanie często prowadzi do błędów, ponieważ Windows próbuje kolejnych protokołów i może utknąć na nieodpowiednim.

Modyfikacja rejestru dla scenariuszy NAT jest niezbędna w przypadku, gdy klient Windows łączy się z serwerem L2TP/IPSec znajdującym się za translacją adresów. Wpis AssumeUDPEncapsulationContextOnSendRule z wartością 2 rozwiązuje ten problem. Bez tej zmiany klient będzie zgłaszał błąd 789, który wielu administratorów błędnie interpretuje jako problem z certyfikatami lub hasłem.

Split Tunneling to technika, która pozwala klientowi VPN na jednoczesny dostęp do sieci lokalnej i Internetu bez kierowania całego ruchu przez tunel. W Windows można to skonfigurować w zaawansowanych ustawieniach protokołu TCP/IP połączenia VPN, odznaczając opcję Użyj bramy domyślnej w sieci zdalnej. Należy pamiętać o konsekwencjach bezpieczeństwa tej konfiguracji.

OpenVPN stanowi naturalną ewolucję w stosunku do omawianych protokołów, łącząc zalety SSTP i IPSec w jednym rozwiązaniu. Podobnie jak SSTP, OpenVPN może działać na porcie TCP 443, co zapewnia łatwe przechodzenie przez zapory sieciowe. Jednocześnie, podobnie jak IPSec, oferuje niezwykle elastyczną konfigurację algorytmów kryptograficznych oraz obsługę różnych metod uwierzytelniania.

Otwarty kod źródłowy OpenVPN jest jego największą zaletą z punktu widzenia bezpieczeństwa. Kod jest publicznie dostępny i podlega ciągłym audytom oraz przeglądom przez społeczność. W przeciwieństwie do SSTP, który jest protokołem własnościowym Microsoftu, OpenVPN może być swobodnie implementowany na dowolnej platformie. Jest to szczególnie istotne w heterogenicznych środowiskach sieciowych.

W routerach MikroTik OpenVPN jest dostępny od wersji 6.x i oferuje zbliżoną funkcjonalność do SSTP. Konfiguracja wymaga importu certyfikatów i utworzenia konfiguracji serwera, ale jest bardziej elastyczna niż SSTP. OpenVPN jest szczególnie polecany w środowiskach, gdzie wymagana jest maksymalna elastyczność konfiguracji i niezależność od producenta.

Zadania samodzielne mają na celu praktyczne utrwalenie wiedzy zdobytej podczas tej części kursu. Konfiguracja serwera L2TP/IPSec i próba połączenia z urządzenia mobilnego pozwoli zrozumieć rzeczywiste wyzwania związane z różnymi systemami operacyjnymi. Warto zwrócić uwagę na różnice w konfiguracji między systemem Android, iOS i Windows, szczególnie w zakresie wsparcia dla IKEv2.

Generowanie i podpisywanie certyfikatów dla SSTP jest umiejętnością niezbędną przy wdrażaniu bezpiecznych połączeń w środowisku produkcyjnym. Ćwicząc ten proces, należy zwrócić uwagę na znaczenie Common Name i subject-alt-name, które decydują o zaufaniu klienta do serwera. Import certyfikatu do Windows wymaga uprawnień administracyjnych i wyboru odpowiedniego magazynu certyfikatów.

Test wydajności porównujący GRE z IPSec jest szczególnie pouczający. Pozwala on zobaczyć realny wpływ szyfrowania na przepustowość i obciążenie procesora. Warto przeprowadzić test z różnymi algorytmami szyfrowania, aby zrozumieć, jaki wpływ na wydajność ma wybór AES-128 vs AES-256. Te eksperymenty budują intuicję niezbędną do projektowania wydajnych i bezpiecznych sieci VPN.