Menu Główne 1. Wstęp 2. GRE/PPTP 3. SSTP/L2TP/IPSec L2TP/IPSec 4. OpenVPN 5. Routing 6. VLAN 7. Bezpieczeństwo
1/40 Część 3: Zaawansowane i bezpieczne protokoły VPN
Wprowadzenie do zaawansowanych i bezpiecznych protokołów wirtualnych sieci prywatnych ze szczególnym uwzględnieniem SSTP, L2TP oraz standardu IPsec.
  • Poznaliśmy już standardy PPTP i GRE, które choć szybkie, nie oferują współczesnego poziomu bezpieczeństwa.
  • Teraz skoncentrujemy się na protokołach klasy korporacyjnej.
  • Omówimy SSTP - standard optymalny dla stacji roboczych z systemem Windows.
  • Zrozumiemy działanie L2TP oraz powód, dla którego wymaga on wsparcia IPSec.
  • Przeanalizujemy architekturę IPSec - uniwersalnego i najbezpieczniejszego obecnie standardu.
  • Wspomniane rozwiązania stanowią fundament bezpiecznej komunikacji w sektorze bankowym i korporacyjnym.
Protokół bezpieczeństwa warstwy sieciowej (Network Security Protocol): Zestaw standardów kryptograficznych operujących na poziomie warstwy internetowej lub transportowej, gwarantujących poufność, integralność oraz uwierzytelnienie węzłów transmisyjnych w nieufnych środowiskach sieciowych.
Slide 1

W trzeciej części semestralnego cyklu wykładów poświęconych technologiom VPN następuje zasadnicze przejście od historycznych rozwiązań bazujących na nieszyfrowanych lub skompromitowanych protokołach (GRE, PPTP) do współczesnych, wysoce bezpiecznych standardów teleinformatycznych. Dynamiczny rozwój zagrożeń w sieci publicznej oraz konieczność zapewnienia poufności danych biznesowych wymusiły opracowanie architektur opartych na silnej kryptografii symetrycznej i asymetrycznej. Szczegółowe informacje normatywne i techniczne publikuje Polskie Towarzystwo Informatyczne.

W ramach niniejszego modułu szczegółowej analizie poddane zostaną trzy fundamentalne technologie: Secure Socket Tunneling Protocol (SSTP), Layer 2 Tunneling Protocol (L2TP) oraz uniwersalny standard Internet Protocol Security (IPsec). Protokół SSTP zaprezentowany zostanie jako wysoce skuteczna odpowiedź na problem blokowania nietypowych portów przez zapory sieciowe, wykorzystująca bezpieczny kanał TLS na powszechnie otwartym porcie TCP 443.

Z kolei protokół L2TP omówiony zostanie w kontekście jego ewolucji od technologii L2F i PPTP, ze szczególnym uwzględnieniem faktu, że samodzielnie nie zapewnia on jakiegokolwiek szyfrowania danych. Prawdziwą siłę i powszechne zastosowanie w inżynierii sieciowej zyskał on dopiero w synergicznym połączeniu ze stosem IPsec w trybie transportowym (architektura L2TP/IPSec), tworząc bezpieczny standard powszechnie wspierany przez wiodące systemy operacyjne.

Szczególną uwagę poświęcimy architekturze IPsec, analizując działanie protokołów AH i ESP, tryby pracy Transport oraz Tunnel, a także złożone procedury negocjacji kluczy w ramach protokołów IKEv1 oraz nowoczesnego standardu IKEv2. Studenci zdobędą praktyczną wiedzę niezbędną do wdrożenia, diagnostyki i optymalizacji bezpiecznych tuneli site-to-site oraz remote-access w systemie MikroTik RouterOS i środowiskach stacji roboczych Windows.

Wyjaśnienie skrótów użytych na slajdzie:
SSTP - Secure Socket Tunneling Protocol - Protokół tunelowania VPN hermetyzujący ramki PPP w kanale TLS 443.
L2TP - Layer 2 Tunneling Protocol - Protokół tunelowania warstwy łącza danych operujący na porcie UDP 1701.
IPsec - Internet Protocol Security - Zestaw otwartych protokołów zapewniających bezpieczeństwo w warstwie IP.
TLS - Transport Layer Security - Kryptograficzny protokół zapewniający poufność i integralność transmisji.
IKE - Internet Key Exchange - Protokół uzgadniania kluczy sesyjnych i parametrów bezpieczeństwa dla IPsec.

2/40 SSTP (Secure Socket Tunneling Protocol)
Przedstawienie architektury, genezy i mechanizmów działania protokołu SSTP jako rozwiązania eliminującego blokady zapór sieciowych.
  • Standard opracowany przez Microsoft (debiut w Windows Vista / Server 2008).
  • Zasada działania: "Jeśli sieć pozwala na przeglądanie stron HTTPS, pozwoli również na połączenie VPN".
  • Wykorzystuje port TCP 443 (protokół SSL/TLS) - ten sam, co bezpieczny ruch WWW.
  • Główna zaleta: Wysoka skuteczność w przechodzeniu przez zapory sieciowe oraz mechanizmy NAT.
  • Wewnątrz bezpiecznego tunelu SSL przesyłane są standardowe ramki protokołu PPP.
Secure Socket Tunneling Protocol (SSTP): Własnościowy protokół tunelowania warstwy 2 firmy Microsoft hermetyzujący ramki protokołu PPP wewnątrz szyfrowanej sesji protokołu TLS na porcie TCP 443.
Slide 2

Protokół Secure Socket Tunneling Protocol (SSTP) został wprowadzony przez firmę Microsoft wraz z premierą systemów Windows Server 2008 oraz Windows Vista z dodatkiem Service Pack 1. Powstał jako bezpośrednia odpowiedź na narastające problemy eksploatacyjne starszych protokołów VPN (takich jak PPTP oraz L2TP/IPSec) w środowiskach sieciowych o restrykcyjnej filtracji pakietów, w tym w hotelach, na lotniskach czy w sieciach korporacyjnych z głęboką inspekcją ruchu. Szczegółowe informacje normatywne i techniczne publikuje Specyfikacja techniczna protokołu MS-SSTP.

Kluczową ideą inżynierską protokołu SSTP było wykorzystanie kanału szyfrowanego protokołu Transport Layer Security (TLS) zestawianego na standardowym porcie TCP 443. Z punktu widzenia urządzeń pośredniczących w transmisji (routerów dostępowych, zapór ogniowych oraz serwerów proxy) ruch SSTP jest całkowicie nieodróżnialny od zwykłego, bezpiecznego ruchu stron internetowych HTTPS. W efekcie połączenia SSTP przechodzą przez niemal każdą zaporę sieciową bez konieczności otwierania dedykowanych portów.

Wewnątrz bezpiecznego tunelu TLS protokół SSTP przesyła ramki protokołu Point-to-Point Protocol (PPP). Oznacza to, że SSTP dziedziczy wszystkie dojrzałe i sprawdzone mechanizmy kontroli łącza, negocjacji parametrów sieciowych (LCP/IPCP) oraz uwierzytelniania użytkowników (np. za pomocą protokołu MS-CHAPv2 lub nowoczesnych mechanizmów EAP), chroniąc je jednocześnie silnym szyfrowaniem kryptograficznym zapewnianym przez warstwę TLS.

Początkowo SSTP był standardem zamkniętym, dostępnym wyłącznie na platformach Windows. Z czasem Microsoft opublikował pełną specyfikację protokołu w ramach programu Open Specifications (dokument [MS-SSTP]), co umożliwiło powstanie niezależnych implementacji dla systemów linuksowych oraz bezpośrednią integrację serwera i klienta SSTP w systemie MikroTik RouterOS, czyniąc z niego uniwersalne narzędzie dla administratorów sieci.

Wyjaśnienie skrótów użytych na slajdzie:
SSTP - Secure Socket Tunneling Protocol - Protokół tunelowania VPN wykorzystujący sesję TLS.
TLS - Transport Layer Security - Protokół kryptograficzny warstwy transportowej.
PPP - Point-to-Point Protocol - Standard komunikacji punkt-punkt hermetyzowany w tunelu.
HTTPS - Hypertext Transfer Protocol Secure - Szyfrowana wersja protokołu HTTP operująca na porcie TCP 443.
EAP - Extensible Authentication Protocol - Rozszerzalny protokół uwierzytelniania w sieciach komputerowych.

3/40 Anatomia tunelu SSTP
Szczegółowa analiza wielowarstwowej struktury enkapsulacji pakietów w protokole SSTP.
  • Kolejne warstwy enkapsulacji: IP -> TCP (443) -> SSL/TLS -> Nagłówek SSTP -> PPP -> Dane IP.
  • Bezpieczeństwo bazuje na certyfikatach standardu X.509 (analogicznie do bankowości elektronicznej).
  • Serwer musi posiadać certyfikat SSL, który jest zaufany przez system klienta.
  • W przypadku stosowania certyfikatów własnych (Self-Signed), konieczny jest ich ręczny import do magazynu "Zaufanych głównych urzędów certyfikacji" na kliencie.
Enkapsulacja wielowarstwowa SSTP (SSTP Layered Encapsulation): Hierarchiczny proces pakowania jednostek danych użytkownika w ramki PPP, nagłówki sterujące SSTP, rekordy kryptograficzne TLS oraz segmenty transportowe TCP i pakiety IP.
Slide 3

Zrozumienie działania protokołu SSTP wymaga precyzyjnej dekompozycji kolejnych warstw enkapsulacji nakładanych na dane użytkownika w trakcie transmisji. Na samym dole hierarchii znajduje się oryginalny pakiet IP generowany przez stację roboczą (np. żądanie dostępu do serwera plikowego w sieci korporacyjnej). Pakiet ten trafia do wirtualnego interfejsu sieciowego WAN Miniport w systemie operacyjnym. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 8446 (Standard TLS 1.3).

W pierwszym etapie pakiet IP jest hermetyzowany w standardową ramkę protokołu PPP warstwy łącza danych. Następnie ramka PPP zostaje opatrzona 4-bajtowym nagłówkiem protokołu SSTP, który zawiera pole wersji (Version), pole zarezerwowane oraz 16-bitowe pole długości ładunku (Length) informujące o rozmiarze pakietu. Tak przygotowany blok danych SSTP stanowi ładunek aplikacyjny dla sesji kryptograficznej.

W kolejnym kroku blok SSTP jest szyfrowany i pakowany w rekordy protokołu TLS (np. TLS 1.2 lub TLS 1.3). Warstwa TLS odpowiada za nałożenie symetrycznego szyfru blokowego lub strumieniowego AEAD (np. AES-256-GCM) oraz kryptograficznego podpisu integralności MAC. Zaszyfrowany rekord TLS jest następnie dzielony na segmenty protokołu transportowego TCP zaadresowane na port docelowy 443 serwera VPN.

Na samym końcu segment TCP otrzymuje zewnętrzny nagłówek IPv4 lub IPv6, w którym adres docelowy wskazuje publiczny adres IP bramy korporacyjnej. Pomiędzy stacją kliencką a serwerem pakiety podróżują jako standardowy ruch warstwy transportowej TCP, co całkowicie eliminuje problemy z brakiem portów w translatorach PAT oraz zapobiega blokowaniu transmisji przez zapory sieciowe.

Wyjaśnienie skrótów użytych na slajdzie:
SSTP - Secure Socket Tunneling Protocol - Protokół tunelowania warstwy 2 w kanale TLS.
PPP - Point-to-Point Protocol - Protokół warstwy łącza danych.
TLS - Transport Layer Security - Warstwa zabezpieczeń kryptograficznych.
TCP - Transmission Control Protocol - Protokół warstwy transportowej na porcie 443.
AEAD - Authenticated Encryption with Associated Data - Nowoczesny tryb szyfrowania gwarantujący poufność i integralność.

4/40 Zalety i ograniczenia SSTP
Ewaluacja zalet wdrożeniowych oraz krytyczna analiza ograniczeń wydajnościowych protokołu SSTP ze szczególnym uwzględnieniem zjawiska TCP Meltdown.
  • Zalety protokołu SSTP:
    • Działa w niemal każdej sieci publicznej (wykorzystuje standardowy port TCP 443 identyczny jak ruch HTTPS).
    • Znakomicie omija zapory sieciowe i restrykcyjne translatory NAT w hotelach czy sieciach korporacyjnych.
    • Natywna integracja z systemami Windows bez oprogramowania stron trzecich.
    • Wysoki poziom poufności oparty na standardzie TLS 1.2 / TLS 1.3.
  • Krytyczne ograniczenia techniczne:
    • Zjawisko TCP-over-TCP Meltdown: Tunelowanie ruchu TCP wewnątrz nośnika TCP powoduje destrukcyjne nakładanie się retransmisji i gwałtowny spadek przepustowości przy niestabilnych łączach.
    • Złożoność wdrożenia: Bezwzględny wymóg poprawnej konfiguracji infrastruktury PKI i zaufania do certyfikatu.
    • Wyższy narzut procesora (CPU) wynikający z podwójnego stosu TCP.
Zjawisko TCP-over-TCP Meltdown: Drastyczna degradacja przepustowości połączenia tunelowego wynikająca z destrukcyjnej interferencji mechanizmów retransmisji i kontroli przeciążenia dwóch nałożonych na siebie warstw protokołu TCP w warunkach utraty pakietów.
Slide 4

Podstawową zaletą protokołu SSTP jest jego bezkonkurencyjna odporność na blokady zapór sieciowych i restrykcyjne polityki operatorów telekomunikacyjnych. Dzięki wykorzystaniu standardowego portu TCP 443 połączenie SSTP może zostać skutecznie zestawione w niemal każdym publicznym punkcie dostępowym Hotspot, sieci hotelowej czy korporacyjnej sieci gościnnej, gdzie wszelkie inne protokoły VPN (IPsec, GRE, OpenVPN UDP) są bezwzględnie filtrowane. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 5246 (Protokół TLS 1.2).

Dodatkowym atutem w środowiskach biznesowych opartych na ekosystemie Microsoft jest pełna natywna obsługa klienta SSTP wbudowana we wszystkie wersje systemów Windows, począwszy od Windows Vista SP1 po Windows 11. Pozwala to administratorom na masowe wdrażanie bezpiecznego dostępu zdalnego za pomocą zasad grupy (GPO) lub systemów zarządzania urządzeniami mobilnymi (MDM) bez konieczności dystrybucji i aktualizacji oprogramowania stron trzecich.

Głównym i najbardziej dotkliwym ograniczeniem inżynierskim protokołu SSTP jest zjawisko TCP-over-TCP Meltdown. Gdy pakiety generowane przez aplikacje użytkownika (korzystające z protokołu TCP) są hermetyzowane w zewnętrznym strumieniu TCP tunelu SSTP, dochodzi do kolizji dwóch niezależnych automatów kontroli przepływu. W sytuacji pojawienia się opóźnień lub strat pakietów na łączu fizycznym, wewnętrzna i zewnętrzna warstwa TCP równolegle wydłużają czasy oczekiwania i powtarzają transmisję, co prowadzi do lawinowego zapychania buforów i całkowitego załamania transferu.

Ponadto wdrożenie serwera SSTP nakłada wysokie wymagania organizacyjne w zakresie zarządzania infrastrukturą klucza publicznego (PKI). Serwer wymaga ważnego certyfikatu SSL/TLS wystawionego przez zaufany urząd certyfikacji, a wszelkie niezgodności w nazwach domenowych FQDN lub wygaśnięcie certyfikatu skutkują natychmiastowym zablokowaniem łączności przez mechanizmy bezpieczeństwa klienta Windows.

Wyjaśnienie skrótów użytych na slajdzie:
SSTP - Secure Socket Tunneling Protocol - Protokół tunelowania warstwy 2 przez kanał TLS 443.
TCP - Transmission Control Protocol - Połączeniowy protokół warstwy transportowej.
PKI - Public Key Infrastructure - Infrastruktura klucza publicznego zarządzająca certyfikatami X.509.
GPO - Group Policy Object - Obiekt zasad grupy w usłudze Microsoft Active Directory.
MDM - Mobile Device Management - System centralnego zarządzania urządzeniami mobilnymi.

5/40 SSTP w RouterOS: Generowanie certyfikatów (1)
Instruktaż tworzenia i podpisywania certyfikatów urzędu certyfikacji CA oraz certyfikatu serwera SSTP w systemie MikroTik RouterOS.
  • Niezbędne jest utworzenie certyfikatu urzędu certyfikacji (CA) oraz certyfikatu serwerowego.
  • # 1. Tworzenie lokalnego CA
/certificate add name=CA-VPN common-name="MojeCA" key-usage=key-cert-sign,crl-sign
/certificate sign CA-VPN

# 2. Tworzenie certyfikatu serwera (CN musi odpowiadać domenie lub IP routera!)
/certificate add name=Server-Cert common-name="vpn.firma.pl" subject-alt-name=IP:1.1.1.1
/certificate sign Server-Cert ca=CA-VPN
Certyfikat X.509 (X.509 Certificate): Cyfrowy dokument tożsamości wiążący klucz publiczny z tożsamością podmiotu za pomocą podpisu kryptograficznego zaufanego urzędu certyfikacji (CA).
Slide 5

Prawidłowe wdrożenie usługi serwera SSTP w systemie MikroTik RouterOS wymaga przygotowania hierarchicznej struktury certyfikatów cyfrowych X.509. Zgodnie z zasadami kryptografii asymetrycznej niezbędne jest wygenerowanie co najmniej dwóch certyfikatów: certyfikatu głównego urzędu certyfikacji (Root Certificate Authority - CA) oraz certyfikatu serwera SSTP podpisanego przez utworzone CA. Szczegółowe informacje normatywne i techniczne publikuje Dokumentacja MikroTik Zarządzanie Certyfikatami.

Procedurę w systemie RouterOS rozpoczyna się w gałęzi /certificate od wygenerowania szablonu urzędu certyfikacji. W poleceniu /certificate add name=CA-Root common-name="Firma CA" key-usage=key-cert-sign,crl-sign definiuje się czytelną nazwę oraz uprawnienia do podpisywania innych certyfikatów. Następnie za pomocą polecenia /certificate sign CA-Root generuje się klucze kryptograficzne i nadaje certyfikatowi status zaufanego CA w lokalnym magazynie systemu.

W drugim kroku administrator tworzy certyfikat dla samego serwera SSTP: /certificate add name=SSTP-Server common-name=vpn.firma.pl key-usage=digital-signature,key-encipherment,tls-server. Kardynalnym wymogiem inżynierskim jest, aby parametr common-name (lub rozszerzenie Subject Alternative Name - SAN) zawierał dokładnie taką samą nazwę domenową FQDN lub publiczny adres IP, jaki będzie wpisywany przez użytkowników w konfiguracji połączenia w systemie Windows.

Ostatnim etapem jest podpisanie certyfikatu serwera przez utworzone wcześniej CA poleceniem /certificate sign SSTP-Server ca=CA-Root. Wygenerowane klucze prywatne i publiczne są bezpiecznie przechowywane w pamięci chronionej routera. Dopiero posiadanie poprawnie podpisanego certyfikatu serwerowego pozwala na przejście do konfiguracji demona usługi SSTP.

Wyjaśnienie skrótów użytych na slajdzie:
CA - Certificate Authority - Główny urząd certyfikacji wystawiający i podpisujący certyfikaty cyfrowe.
FQDN - Fully Qualified Domain Name - Pełna nazwa domenowa węzła w hierarchii DNS.
SAN - Subject Alternative Name - Rozszerzenie certyfikatu X.509 definiujące dodatkowe tożsamości serwera.
CLI - Command Line Interface - Tekstowy interfejs wiersza poleceń RouterOS.
SSTP - Secure Socket Tunneling Protocol - Protokół tunelowania VPN.

6/40 SSTP w RouterOS: Konfiguracja serwerowa (2)
Przewodnik po aktywacji i parametryzacji usługi serwera SSTP w systemie RouterOS z wykorzystaniem wygenerowanego certyfikatu.
  • Uruchomienie usługi SSTP z wykorzystaniem utworzonego certyfikatu:
  • /interface sstp-server server set
enabled=yes
default-profile=profile-vpn
certificate=Server-Cert
authentication=mschap2
force-aes=yes
  • Pamiętaj: Należy udostępnić port TCP 443 w łańcuchu INPUT zapory systemowej.
Usługa serwera SSTP (SSTP Server Daemon): Proces systemowy w routerze nasłuchujący połączeń przychodzących na porcie TCP 443, realizujący negocjację sesji TLS oraz terminujący tunele danych PPP.
Slide 6

Po pomyślnym wygenerowaniu i podpisaniu certyfikatów administrator przystępuje do właściwej konfiguracji usługi serwera SSTP w gałęzi /interface sstp-server server. Usługa ta jest domyślnie wyłączona w systemie RouterOS i wymaga jawnej aktywacji oraz przypisania parametrów kryptograficznych i sieciowych. Szczegółowe informacje normatywne i techniczne publikuje Dokumentacja MikroTik SSTP.

Główne polecenie aktywujące serwer ma postać: /interface sstp-server server set enabled=yes certificate=SSTP-Server default-profile=default-encryption authentication=mschap2 port=443. Kluczowym parametrem jest wskazanie właściwego certyfikatu serwerowego (certificate=SSTP-Server). Bez tego wpisu usługa serwera nie wystartuje, a próba nawiązania połączenia TLS przez klienta zostanie natychmiast zresetowana.

W ramach konfiguracji serwera należy również zwrócić szczególną uwagę na parametr port. Domyślną i standardową wartością jest port 443, jednak RouterOS pozwala na zmianę portu nasłuchu na inny, co może być przydatne w sytuacji, gdy na routerze uruchomiony jest już serwer WWW (WebFig) lub inny proces korzystający z portu 443. Zmiana portu wymaga jednak jawnego podania numeru portu w adresie serwera u klienta Windows (np. vpn.firma.pl:8443).

Warto również skonfigurować parametr keepalive-timeout oraz verify-client-certificate. Domyślnie weryfikacja certyfikatu klienta jest wyłączona (uwierzytelnianie użytkownika następuje na poziomie protokołu MS-CHAPv2). Włączenie parametru verify-client-certificate=yes wymusza uwierzytelnianie dwukierunkowe (Mutual TLS), co podnosi bezpieczeństwo do poziomu korporacyjnego, lecz wymaga wdrożenia certyfikatów osobistych na wszystkich stacjach roboczych.

Wyjaśnienie skrótów użytych na slajdzie:
SSTP - Secure Socket Tunneling Protocol - Protokół tunelowania VPN w kanale TLS 443.
TLS - Transport Layer Security - Standard kryptograficzny warstwy transportowej.
MS-CHAPv2 - Microsoft Challenge Handshake Authentication Protocol v2 - Protokół uwierzytelniania wzajemnego użytkowników.
CLI - Command Line Interface - Interfejs wiersza poleceń RouterOS.
TCP - Transmission Control Protocol - Protokół transportowy.

7/40 Zaufanie klienta Windows do certyfikatu
Procedura instalacji certyfikatu urzędu certyfikacji CA w magazynie systemowym Windows w celu zagwarantowania zaufania do połączenia SSTP.
  • Procedura dla certyfikatu typu Self-Signed:
  • 1. Eksport pliku certyfikatu CA (tylko część publiczna, .crt) z routera.
  • 2. Przeniesienie pliku na stację roboczą klienta.
  • 3. Instalacja w systemie: Wybierz "Komputer lokalny" -> magazyn "Zaufane główne urzędy certyfikacji".
  • Brak zaufania skutkuje błędem o kodzie: 0x800B0109 (Łańcuch certyfikatów nie kończy się zaufanym certyfikatem głównym).
Magazyn zaufanych certyfikatów (Trusted Root Certification Authorities): Chroniony obszar rejestru systemowego Windows przechowujący certyfikaty zaufanych urzędów CA, wykorzystywany do automatycznej walidacji łańcucha zaufania połączeń SSL/TLS.
Slide 7

Najczęstszą barierą wdrożeniową przy uruchamianiu połączeń SSTP z wykorzystaniem certyfikatów generowanych lokalnie na routerze (self-signed CA) jest brak zaufania systemu operacyjnego klienta do wystawcy certyfikatu. System Windows posiada rygorystyczne mechanizmy walidacji łańcucha zaufania PKI i odrzuca każde połączenie, którego certyfikat serwera nie pochodzi od uznanego urzędu certyfikacji. Szczegółowe informacje normatywne i techniczne publikuje Usługi certyfikatów AD CS w Windows Server.

W celu umożliwienia stacji roboczej nawiązania sesji administrator musi wyeksportować publiczny certyfikat urzędu CA z routera MikroTik (/certificate export-certificate CA-Root type=pem), a następnie przekazać uzyskany plik certyfikatu na komputer użytkownika. Klucz prywatny urzędu CA bezwzględnie pozostaje na routerze - eksportowany jest wyłącznie klucz publiczny.

Na stacji roboczej użytkownik uruchamia konsolę zarządzania certyfikatami (polecenie certmgr.msc dla bieżącego użytkownika lub certlm.msc dla konta komputera lokalnego). Pobrany certyfikat CA należy zaimportować bezpośrednio do magazynu Zaufane główne urzędy certyfikacji (Trusted Root Certification Authorities). Umieszczenie certyfikatu w tym magazynie instruuje system Windows, że wszelkie certyfikaty podpisane przez ten urząd należy traktować jako w pełni bezpieczne i wiarygodne.

W przypadku środowisk domenowych Active Directory procedurę tę można zautomatyzować dla tysięcy stacji roboczych jednocześnie za pomocą obiektów zasad grupy (GPO). Po zaimportowaniu certyfikatu CA klient Windows bez przeszkód weryfikuje podpis serwera SSTP, co pozwala na bezproblemowe nawiązanie szyfrowanego tunelu.

Wyjaśnienie skrótów użytych na slajdzie:
CA - Certificate Authority - Urząd certyfikacji wystawiający certyfikaty tożsamości.
PKI - Public Key Infrastructure - Infrastruktura klucza publicznego.
GPO - Group Policy Object - Polityki grupy w domenie Active Directory.
PEM - Privacy Enhanced Mail - Format kodowania certyfikatów w formacie Base64.
GUI - Graphical User Interface - Graficzny interfejs konsoli zarządzania certyfikatami.

8/40 Diagnostyka problemów z protokołem SSTP
Metodyka identyfikacji i usuwania typowych błędów połączeniowych i kryptograficznych w eksploatacji protokołu SSTP w systemie Windows.
  • Niezgodność CN (Common Name): Jeśli w certyfikacie widnieje "vpn.firma.pl", a łączymy się przez IP "1.1.1.1", system Windows zablokuje połączenie ze względów bezpieczeństwa.
  • Konflikt portu 443: Jeśli na routerze aktywna jest administracja WWW przez SSL (WebFig) na porcie 443, usługa SSTP może kolidować. Rozwiązaniem jest zmiana portu WebFig.
  • Weryfikacja unieważnienia (CRL): Windows domyślnie próbuje sprawdzić listę odwołań certyfikatów. Przy certyfikatach własnych warto sprawdzić wpisy w rejestrze (NoCertRevocationCheck).
Błąd unieważnienia certyfikatu (Certificate Revocation Check Failure): Stan błędu klienta VPN, w którym system nie może zweryfikować listy unieważnionych certyfikatów (CRL) lub serwera OCSP, skutkujący zablokowaniem połączenia z kodem 0x80092013.
Slide 8

W eksploatacji protokołu SSTP inżynierowie sieciowi spotykają się ze specyficzną grupą błędów diagnostycznych, które w zdecydowanej większości wynikają z rygorystycznych mechanizmów weryfikacji kryptograficznej stosowanych przez stos sieciowy systemu Windows. Zrozumienie kodów błędów jest kluczem do szybkiego przywrócenia łączności. Szczegółowe informacje normatywne i techniczne publikuje Microsoft Learn Rozwiązywanie problemów VPN.

Najpowszechniejszym problemem jest błąd o kodzie 0x800B0109 (komunikat informujący, że łańcuch certyfikatów został przetworzony, ale zakończył się certyfikatem głównym, który nie jest zaufany przez dostawcę zaufania). Błąd ten jednoznacznie wskazuje, że certyfikat głównego urzędu CA nie został zaimportowany do magazynu Zaufane główne urzędy certyfikacji na komputerze klienta lub został umieszczony w niewłaściwym magazynie.

Drugim charakterystycznym problemem jest błąd niezgodności nazwy 0x800B010F (lub komunikat o błędnej nazwie CN). Występuje on w sytuacji, gdy adres wpisany w profilu połączenia VPN (np. publiczny adres IP 1.2.3.4) różni się od nazwy zdefiniowanej w polu Common Name certyfikatu (np. vpn.firma.pl). Klient Windows bezwzględnie wymaga idealnego dopasowania nazwy domenowej, traktując jakiekolwiek rozbieżności jako potencjalny atak podszywania się (Man-in-the-Middle).

Trzecim częstym problemem jest błąd 0x80092013 (brak możliwości sprawdzenia stanu unieważnienia certyfikatu, ponieważ serwer unieważnienia jest w trybie offline). Domyślnie system Windows próbuje pobrać listę unieważnień CRL lub odpytać serwer OCSP. W przypadku certyfikatów generowanych lokalnie na routerze listy CRL często nie istnieją. Rozwiązaniem doraźnym na stacji roboczej jest wyłączenie sprawdzania unieważnień w rejestrze za pomocą wartości NoCertRevocationCheck = 1 w kluczu HKLM\SYSTEM\CurrentControlSet\Services\SstpSvc\Parameters.

Wyjaśnienie skrótów użytych na slajdzie:
SSTP - Secure Socket Tunneling Protocol - Protokół tunelowania warstwy 2 w kanale TLS.
CN - Common Name - Pole nazwy głównej podmiotu w certyfikacie X.509.
CRL - Certificate Revocation List - Lista unieważnionych certyfikatów publikowana przez urząd CA.
OCSP - Online Certificate Status Protocol - Protokół sieciowy do sprawdzania stanu ważności certyfikatu w czasie rzeczywistym.
MitM - Man in the Middle - Atak polegający na potajemnym przechwytywaniu i modyfikowaniu komunikacji.

9/40 L2TP (Layer 2 Tunneling Protocol) - Charakterystyka
Przedstawienie architektury, historii powstania oraz właściwości protokołu Layer 2 Tunneling Protocol zdefiniowanego w RFC 2661.
  • Standard IETF (RFC 2661), powstały z połączenia technologii Cisco L2F oraz Microsoft PPTP.
  • Operuje w warstwie łącza danych (warstwa 2), hermetyzując pełne ramki PPP.
  • Wykorzystuje port transportowy UDP 1701 do przesyłania pakietów sygnalizacyjnych i danych.
  • Kardynalna zasada inżynierska: Czysty protokół L2TP nie zapewnia żadnego szyfrowania ani integralności danych (ruch przesyłany jest jawnym tekstem).
  • Służy wyłącznie jako mechanizm tunelowania warstwy 2. W celu zagwarantowania poufności standard branżowy wymusza łączenie go ze stosem kryptograficznym IPsec (standard L2TP/IPSec, RFC 3193).
Layer 2 Tunneling Protocol (L2TP): Protokół tunelowania warstwy łącza danych (warstwa 2) ustandaryzowany w RFC 2661, umożliwiający hermetyzację i transport ramek protokołu PPP przez sieci pakietowe IP na porcie UDP 1701.
Slide 9

Protokół Layer 2 Tunneling Protocol (L2TP) został opracowany przez grupę roboczą organizacji IETF i formalnie ustandaryzowany w dokumencie RFC 2661 w 1999 roku. Stanowił on kompromis inżynierski łączący dwie konkurencyjne technologie wczesnego tunelowania warstwy 2: protokół L2F (Layer 2 Forwarding) firmy Cisco Systems oraz protokół PPTP opracowany przez konsorcjum z udziałem firmy Microsoft. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 2661 (Specyfikacja L2TP).

W architekturze sieciowej L2TP operuje bezpośrednio na poziomie warstwy łącza danych modelu odniesienia OSI. Jego podstawową funkcją jest hermetyzacja pełnych ramek protokołu Point-to-Point Protocol (PPP) i ich przesyłanie przez sieci IP. Do transmisji komunikatów sygnalizacyjnych oraz pakietów danych L2TP wykorzystuje protokół transportowy UDP na porcie serwerowym 1701. W przeciwieństwie do PPTP, L2TP nie wymaga oddzielnego połączenia TCP do sterowania sesją.

Architektura L2TP definiuje dwa kluczowe węzły funkcjonalne: koncentrator dostępu LAC (L2TP Access Concentrator) oraz serwer sieciowy LNS (L2TP Network Server). W klasycznych sieciach telekomunikacyjnych LAC stanowił węzeł dostępowy operatora odbierający połączenie komutowane od klienta, a następnie tunelujący je przez sieć IP do serwera LNS zlokalizowanego w siedzibie korporacji. W nowoczesnych sieciach VPN stacja robocza pracownika pełni jednocześnie rolę klienta LAC.

Kardynalną cechą inżynierską protokołu L2TP, o której musi pamiętać każdy projektant sieci, jest całkowity brak wbudowanych mechanizmów szyfrowania i integralności danych. Protokół L2TP odpowiada wyłącznie za tworzenie wirtualnego tunelu i transport ramek PPP - dane przesyłane w portach UDP 1701 podróżują w postaci czystego tekstu. Aby zapewnić bezpieczeństwo teleinformatyczne, standard IETF nakazuje łączenie L2TP ze stosem kryptograficznym IPsec.

Wyjaśnienie skrótów użytych na slajdzie:
L2TP - Layer 2 Tunneling Protocol - Protokół tunelowania warstwy łącza danych przez sieci IP.
LAC - L2TP Access Concentrator - Węzeł koncentratora dostępowego inicjujący tunel L2TP.
LNS - L2TP Network Server - Węzeł serwera sieciowego terminujący tunel L2TP.
UDP - User Datagram Protocol - Bezpołączeniowy protokół warstwy transportowej na porcie 1701.
PPP - Point-to-Point Protocol - Protokół warstwy łącza danych hermetyzowany w tunelu.

10/40 Mechanizm współdziałania: L2TP + IPSec
Szczegółowa analiza modelu współpracy protokołów L2TP oraz IPsec w oparciu o standard RFC 3193.
  • Strukturę tunelu można porównać do wielowarstwowej osłony:
  • 1. Dane aplikacji są pakowane w ramki PPP.
  • 2. Ramki PPP są zamykane w pakietach L2TP (UDP 1701).
  • 3. Kompletny pakiet L2TP jest poddawany szyfrowaniu i umieszczany wewnątrz IPSec.
  • Dla sieci zewnętrznej widoczna jest tylko bezpieczna transmisja IPSec (ESP). Treść L2TP pozostaje niewidoczna do momentu odszyfrowania.
Architektura L2TP/IPSec (L2TP over IPsec): Hybrydowy standard wirtualnych sieci prywatnych (RFC 3193), w którym nieszyfrowany tunel L2TP jest zabezpieczany za pomocą protokołu IPsec ESP operującego w trybie transportowym.
Slide 10

W celu wyeliminowania krytycznej wady protokołu L2TP - całkowitego braku ochrony kryptograficznej - organizacja IETF opublikowała standard RFC 3193 precyzujący zasady bezpiecznej integracji protokołu L2TP ze stosem IPsec. W architekturze tej oba protokoły ściśle ze sobą współpracują, realizując odrębne, wyspecjalizowane zadania w wielowarstwowym procesie komunikacji. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 3193 (L2TP over IPsec).

Mechanizm zestawiania połączenia przebiega w ściśle określonej kolejności dwuetapowej. W pierwszym etapie urządzenia końcowe nawiązują wyłącznie sesję kryptograficzną IPsec za pośrednictwem protokołu IKE (port UDP 500). W toku negocjacji następuje wzajemne uwierzytelnienie urządzeń (za pomocą klucza współdzielonego PSK lub certyfikatów cyfrowych X.509) oraz uzgodnienie skojarzeń bezpieczeństwa (SA) dla protokołu ESP w trybie transportowym.

Dopiero po pełnym ustanowieniu szyfrowanego kanału IPsec ESP rozpoczyna się drugi etap: inicjalizacja tunelu L2TP. Wszystkie pakiety L2TP na porcie UDP 1701 są automatycznie przechwytywane przez politykę IPsec i szyfrowane w locie przez protokół ESP przed wysłaniem w sieć publiczną. Wewnątrz tunelu L2TP następuje standardowa negocjacja sesji PPP oraz uwierzytelnienie konkretnego użytkownika za pomocą protokołu MS-CHAPv2.

Taki model separacji odpowiedzialności zapewnia dwupoziomowe bezpieczeństwo: IPsec odpowiada za uwierzytelnienie maszyny (Machine Authentication) i silne szyfrowanie całego strumienia danych na poziomie warstwy sieciowej, natomiast L2TP/PPP realizuje uwierzytelnienie użytkownika (User Authentication) oraz dynamiczny przydział adresacji IP. Dzięki temu L2TP/IPSec stał się jednym z najbardziej uniwersalnych i bezpiecznych standardów VPN zdalnego dostępu.

Wyjaśnienie skrótów użytych na slajdzie:
L2TP - Layer 2 Tunneling Protocol - Protokół tunelowania warstwy 2.
IPsec - Internet Protocol Security - Zestaw protokołów kryptograficznych warstwy sieciowej.
ESP - Encapsulating Security Payload - Protokół szyfrowania i integralności danych w IPsec.
PSK - Pre-Shared Key - Współdzielony klucz statyczny wykorzystywany do wstępnego uwierzytelnienia.
SA - Security Association - Skojarzenie bezpieczeństwa definiujące parametry kryptograficzne sesji IPsec.

11/40 IPSec - Uniwersalny standard bezpieczeństwa
Przedstawienie genezy, fundamentów teoretycznych oraz architektury pakietu standardów Internet Protocol Security zdefiniowanych w RFC 4301.
  • IPSec (Internet Protocol Security) to kompleksowy zestaw standardów bezpieczeństwa.
  • Działa w warstwie sieciowej (warstwa 3), co czyni go przezroczystym dla aplikacji.
  • Zapewnia fundamenty bezpiecznej transmisji:
    • Poufność (zaawansowane szyfrowanie).
    • Integralność (zapewnienie, że dane nie zostały zmienione).
    • Uwierzytelnianie stron (PSKs, Certyfikaty).
    • Ochronę przed ponownym przesłaniem pakietów (Anti-Replay).
Architektura IPsec (IPsec Security Architecture): Zbiór otwartych standardów inżynieryjnych IETF operujących w warstwie sieciowej modelu OSI, zapewniających kryptograficzną ochronę komunikacji IP poprzez poufność, integralność, uwierzytelnianie pochodzenia danych oraz ochronę przed atakami powtórzeniowymi.
Slide 11

Internet Protocol Security (IPsec) nie jest pojedynczym protokołem komunikacyjnym, lecz potężnym, modularnym pakietem standardów inżynieryjnych opracowanych przez organizację IETF. Podstawy architektury bezpieczeństwa IPsec zostały zdefiniowane w fundamentalnym dokumencie RFC 4301 (będącym rozwinięciem wcześniejszego RFC 2401). IPsec został zaprojektowany jako natywny element protokołu IPv6 oraz zaadaptowany jako opcjonalne, powszechnie stosowane rozszerzenie dla protokołu IPv4. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 4301 (Architektura IPsec).

Fundamentalną właściwością wyróżniającą architekturę IPsec na tle innych technologii VPN jest jej operowanie bezpośrednio w warstwie sieciowej (warstwa 3 modelu OSI). Oznacza to, że mechanizmy kryptograficzne IPsec są całkowicie przezroczyste dla aplikacji użytkownika oraz protokołów wyższych warstw (TCP, UDP, ICMP). Programy sieciowe nie wymagają żadnych modyfikacji ani specjalnych bibliotek - cały proces inspekcji, szyfrowania i deszyfrowania pakietów odbywa się wewnątrz stosu sieciowego systemu operacyjnego.

Architektura IPsec realizuje cztery kluczowe cele bezpieczeństwa teleinformatycznego: poufność danych (ochrona przed podsłuchem za pomocą algorytmów AES), integralność danych bezpołączeniowych (wykrywanie nieautoryzowanej modyfikacji pakietu), uwierzytelnianie pochodzenia danych (potwierdzenie tożsamości nadawcy) oraz ochronę przed atakami typu powtórzenie (Replay Protection za pomocą numerów sekwencyjnych i mechanizmu przesuwnego okna weryfikacyjnego).

Modułowa konstrukcja standardu pozwala na niezależną ewolucję poszczególnych komponentów kryptograficznych. W miarę postępu kryptoanalizy przestarzałe algorytmy szyfrowania lub funkcje skrótu mogą być zastępowane nowymi, odporniejszymi rozwiązaniami bez konieczności zmiany całej architektury protokołu. Dzięki temu IPsec pozostaje od ponad dwóch dekad najważniejszym standardem przemysłowym w budowie bezpiecznych sieci rozległych.

Wyjaśnienie skrótów użytych na slajdzie:
IPsec - Internet Protocol Security - Standard kryptograficzny warstwy sieciowej IP.
IETF - Internet Engineering Task Force - Międzynarodowa organizacja inżynierska rozwijająca standardy Internetu.
OSI - Open Systems Interconnection - Siedmiowarstwowy model odniesienia standardów komunikacji.
AES - Advanced Encryption Standard - Nowoczesny symetryczny szyfr blokowy stosowany w IPsec.
RFC - Request for Comments - Oficjalny dokument standaryzacyjny komitetu IETF.

12/40 Struktura IPSec: protokoły AH oraz ESP
Komparatywna analiza protokołów Authentication Header oraz Encapsulating Security Payload w architekturze IPsec.
  • Stos IPsec (RFC 4301) definiuje dwa protokoły bezpieczeństwa warstwy sieciowej:
  • AH (Authentication Header - IP Protocol 51, RFC 4302):
    • Zapewnia wyłącznie uwierzytelnienie nadawcy i integralność danych (brak szyfrowania - dane jawne).
    • Oblicza podpis ICV z całego pakietu IP (w tym nagłówka zewnętrznego).
    • Całkowicie niezgodny z translacją NAT: Modyfikacja adresu IP przez router NAT unieważnia sumę ICV i powoduje odrzucenie pakietu. Protokół wycofany z nowoczesnych wdrożeń.
  • ESP (Encapsulating Security Payload - IP Protocol 50, RFC 4303):
    • Zapewnia pełną poufność (szyfrowanie), integralność oraz ochronę przed atakami powtórzeniowymi.
    • Szyfruje i podpisuje ładunek pakietu, pozostawiając zewnętrzny nagłówek IP nienaruszony.
    • W pełni współpracuje z NAT za pośrednictwem enkapsulacji UDP 4500 (NAT-T).
Wartość kontrolna integralności ICV (Integrity Check Value): Kryptograficzna suma kontrolna obliczana za pomocą funkcji skrótu z kluczem (HMAC), dołączana do pakietu IPsec w celu weryfikacji nienaruszalności danych i tożsamości nadawcy.
Slide 12

W architekturze IPsec bezpośrednią realizację usług bezpieczeństwa powierzono dwóm odrębnym protokołom warstwy sieciowej: Authentication Header (AH) oraz Encapsulating Security Payload (ESP). Protokoły te różnią się zakresem świadczonej ochrony kryptograficznej oraz budową nagłówków pakietu. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 4302 (Protokół IPsec AH).

Protokół Authentication Header (AH), zdefiniowany w dokumencie RFC 4302, operuje z numerem protokołu IP 51. Został zaprojektowany w celu zapewnienia bezpołączeniowej integralności danych, uwierzytelniania źródła pakietów oraz ochrony przed powtórzeniami. Kluczową cechą protokołu AH jest fakt, że nie zapewnia on jakiegokolwiek szyfrowania danych - ładunek pakietu podróżuje w postaci jawnej. Co więcej, AH oblicza sumę kontrolną ICV z całego pakietu, włączając niezmienne pola zewnętrznego nagłówka IP.

Z kolei protokół Encapsulating Security Payload (ESP), ustandaryzowany w RFC 4303, operuje z numerem protokołu IP 50. Zapewnia on pełen wachlarz usług bezpieczeństwa: poufność poprzez szyfrowanie ładunku, integralność danych, uwierzytelnienie źródła oraz ochronę przed atakami powtórzeniowymi. W protokole ESP podpis ICV obejmuje wyłącznie nagłówek ESP, zaszyfrowany ładunek oraz stopkę ESP (Trailer), pozostawiając zewnętrzny nagłówek IP nienaruszony.

Ta fundamentalna różnica w konstrukcji przesądziła o losach obu protokołów w nowoczesnych sieciach teleinformatycznych. Ponieważ protokół AH chroni nagłówek IP, jakakolwiek modyfikacja adresu przez router NAT natychmiast niszczy podpis ICV i skutkuje odrzuceniem pakietu przez odbiorcę. W efekcie protokół AH jest całkowicie bezużyteczny w środowiskach z translacją adresów i został w 99% wdrożeń produkcyjnych zastąpiony przez protokół ESP wspierany mechanizmem NAT-T.

Wyjaśnienie skrótów użytych na slajdzie:
AH - Authentication Header - Protokół integralności i uwierzytelniania IPsec o numerze IP 51.
ESP - Encapsulating Security Payload - Protokół szyfrowania i integralności IPsec o numerze IP 50.
ICV - Integrity Check Value - Wartość kontrolna integralności weryfikująca nienaruszalność pakietu.
NAT - Network Address Translation - Translacja adresów sieciowych unieważniająca podpisy w protokole AH.
HMAC - Hash-based Message Authentication Code - Mechanizm uwierzytelniania wiadomości oparty na funkcji skrótu.

13/40 Tryby pracy: transport vs tunnel
Szczegółowa analiza różnic architektonicznych i scenariuszy zastosowań pomiędzy trybem transportowym a trybem tunelowym w protokole IPsec.
  • Transport Mode: Szyfruje wyłącznie segment danych (payload) pakietu IP. Oryginalny nagłówek IP pozostaje widoczny. Stosowany w tunelach client-to-site (np. L2TP/IPSec).
  • Tunnel Mode: Szyfruje cały oryginalny pakiet IP i enkapsuluje go w nowy pakiet IPSec. Ukrywa adresację źródłową i docelową. Standard dla połączeń Site-to-Site (między routerami).
Tryb tunelowy IPsec (IPsec Tunnel Mode): Tryb pracy protokołu IPsec, w którym cały oryginalny pakiet IP (nagłówek wraz z ładunkiem) jest szyfrowany i hermetyzowany wewnątrz całkowicie nowego, zewnętrznego nagłówka IP.
Slide 13

Protokół IPsec (zarówno w implementacji ESP, jak i AH) może operować w dwóch zasadniczych trybach enkapsulacji: trybie transportowym (Transport Mode) oraz trybie tunelowym (Tunnel Mode). Wybór odpowiedniego trybu determinuje strukturę generowanych pakietów sieciowych oraz implikuje docelowe zastosowanie architektury VPN. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 4303 (Protokół IPsec ESP).

W trybie transportowym (Transport Mode) nagłówek IPsec (np. ESP) jest wstawiany bezpośrednio pomiędzy oryginalny nagłówek IP a nagłówek warstwy transportowej (TCP lub UDP). W tym wariancie szyfrowany jest wyłącznie ładunek danych (Payload), natomiast oryginalny nagłówek IP pozostaje odsłonięty i służy do routingu pakietu w sieci publicznej. Tryb transportowy wprowadza mniejszy narzut nagłówka, lecz ujawnia adresy IP stacji końcowych. Jest stosowany do bezpośredniej ochrony komunikacji host-to-host lub jako nośnik szyfrujący dla tuneli L2TP i GRE.

W trybie tunelowym (Tunnel Mode) następuje pełna hermetyzacja: cały oryginalny pakiet IP (wewnętrzny nagłówek IP wraz ze wszystkimi danymi) jest traktowany jako ładunek, w całości szyfrowany przez protokół ESP, a następnie opatrywany całkowicie nowym, zewnętrznym nagłówkiem IP. W zewnętrznym nagłówku jako adresy źródłowy i docelowy widnieją wyłącznie publiczne adresy bramek VPN. Adresacja wewnętrzna sieci LAN jest całkowicie ukryta przed podsłuchem.

Tryb tunelowy stanowi fundament bezpiecznych połączeń międzyoddziałowych typu router-router (Site-to-Site VPN). Umożliwia on transparentne łączenie odległych podsieci korporacyjnych o prywatnych adresach RFC 1918 przez publiczny Internet bez konieczności rekonfiguracji stacji roboczych użytkowników, stanowiąc dominujący model wdrożeniowy w inżynierii sieci rozległych.

Wyjaśnienie skrótów użytych na slajdzie:
IPsec - Internet Protocol Security - Standard kryptograficzny warstwy 3.
ESP - Encapsulating Security Payload - Protokół szyfrowania ładunku w IPsec.
TCP - Transmission Control Protocol - Protokół warstwy transportowej.
UDP - User Datagram Protocol - Bezpołączeniowy protokół transportowy.
LAN - Local Area Network - Lokalna sieć komputerowa chroniona przez bramę VPN.

14/40 Negocjacja kluczy: protokół IKE
Przedstawienie roli i architektury protokołu Internet Key Exchange w automatycznym zarządzaniu sesjami kryptograficznymi IPsec.
  • Przed rozpoczęciem bezpiecznej transmisji ESP, strony muszą ustalić parametry szyfrowania.
  • Za ten proces odpowiada protokół IKE (Internet Key Exchange), działający na porcie UDP 500.
  • Zestawianie tunelu realizowane jest w dwóch fazach (Faza 1 oraz Faza 2).
  • Błędy typu "Proposal mismatch" są najczęstszą przyczyną nieudanych prób połączenia (brak porozumienia co do metod szyfrowania).
Internet Key Exchange (IKE): Protokół sygnalizacyjny warstwy aplikacji operujący na porcie UDP 500, odpowiedzialny za wzajemne uwierzytelnianie węzłów, bezpieczne uzgadnianie kluczy sesyjnych za pomocą algorytmu Diffie-Hellmana oraz tworzenie skojarzeń bezpieczeństwa (SA).
Slide 14

Ręczne konfigurowanie statycznych kluczy szyfrujących oraz parametrów algorytmów na wielu routerach w sieci rozległej (tzw. Manual IPsec) jest wysoce nieefektywne, podatne na błędy i uniemożliwia realizację właściwości Perfect Forward Secrecy. Z tego względu nieodłącznym komponentem nowoczesnej architektury IPsec jest protokół automatycznego zarządzania kluczami - Internet Key Exchange (IKE). Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 2409 (Protokół IKEv1).

Protokół IKE operuje w warstwie aplikacji i wykorzystuje protokół transportowy UDP na porcie docelowym 500. Jego architektura bazuje na połączeniu trzech niezależnych standardów: protokołu ISAKMP (RFC 2408), który definiuje ogólne ramy wymiany komunikatów sygnalizacyjnych, protokołu Oakley (RFC 2412) opisującego matematyczną procedurę uzgadniania kluczy metodą Diffie-Hellmana, oraz protokołu SKEME odpowiedzialnego za mechanizmy uwierzytelniania.

Podstawowym zadaniem protokołu IKE jest wynegocjowanie skojarzeń bezpieczeństwa (Security Associations - SA). Skojarzenie SA to jednostronna umowa logiczna pomiędzy dwoma węzłami sieciowymi, określająca zbiór reguł kryptograficznych stosowanych do ochrony ruchu: wybrany algorytm szyfrowania (np. AES-256), funkcję integralności (np. SHA-256), czas życia kluczy oraz unikalny 32-bitowy identyfikator SPI (Security Parameter Index).

W ewolucji protokołu wyróżnia się dwie zasadnicze wersje: klasyczny protokół IKEv1 (zdefiniowany w dokumencie RFC 2409) oraz nowocześniejszy, zoptymalizowany standard IKEv2 (RFC 7296). Zrozumienie procedur negocjacji IKE jest kluczowe dla skutecznej diagnostyki problemów z zestawianiem tuneli VPN w środowiskach wieloproducenckich.

Wyjaśnienie skrótów użytych na slajdzie:
IKE - Internet Key Exchange - Protokół negocjacji kluczy i parametrów bezpieczeństwa dla IPsec.
ISAKMP - Internet Security Association and Key Management Protocol - Protokół zarządzania skojarzeniami bezpieczeństwa i wymiany kluczy.
SA - Security Association - Skojarzenie bezpieczeństwa definiujące parametry kryptograficzne sesji.
SPI - Security Parameter Index - 32-bitowy identyfikator jednoznacznie wskazujący skojarzenie SA w tablicy SAD.
UDP - User Datagram Protocol - Protokół transportowy wykorzystywany przez IKE na porcie 500.

15/40 Faza 1 (IKE Phase 1): uwierzytelnianie i kanał kontrolny
Szczegółowa analiza przebiegu pierwszej fazy negocjacji IKEv1 w trybach Main Mode oraz Aggressive Mode.
  • Cel: Uwierzytelnienie partnera i stworzenie bezpiecznej rury do dalszej negocjacji (ISAKMP SA).
  • Strony ustalają: Szyfr (AES), metodę skrótu (SHA), grupę Diffie-Hellman dla wymiany kluczy oraz formę autoryzacji (hasło PSK lub certyfikat).
  • Możliwe tryby: Main Mode (bezpieczniejszy, weryfikuje tożsamość chronionym kanałem) oraz Aggressive Mode (szybszy, ale przesyła skróty tożsamości jawnie).
ISAKMP SA (Skojarzenie fazy 1 IKE): Bezpieczny, dwukierunkowy kanał kryptograficzny zestawiany w fazie 1 IKE, służący do bezpiecznej wymiany komunikatów sygnalizacyjnych i negocjacji właściwych tuneli danych w fazie 2.
Slide 15

W klasycznej architekturze IKEv1 proces nawiązywania bezpiecznego połączenia został podzielony na dwie wyraźnie odseparowane fazy. Zadaniem Fazy 1 (IKE Phase 1) jest wzajemne uwierzytelnienie komunikujących się urządzeń brzegowych, bezpieczne wygenerowanie materiału klucza sesyjnego oraz zestawienie chronionego kanału kontrolnego zwanego ISAKMP SA. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 2408 (Architektura ISAKMP).

Faza 1 może zostać zrealizowana w jednym z dwóch trybów wymiany komunikatów: trybie głównym (Main Mode) lub trybie agresywnym (Aggressive Mode). Tryb Main Mode składa się z sekwencji sześciu pakietów wymienianych parami. W pierwszych dwóch pakietach routery uzgadniają politykę kryptograficzną (algorytm szyfrowania, funkcję skrótu, grupę Diffie-Hellmana i metodę uwierzytelniania). W pakietach 3 i 4 następuje właściwa wymiana kluczy publicznych DH oraz losowych wartości Nonce. Pakiety 5 i 6 przesyłają tożsamość węzłów i dane uwierzytelniające, przy czym są one w całości zaszyfrowane kluczem uzgodnionym w krokach 3 i 4, co gwarantuje pełną ochronę tożsamości przed podsłuchem.

Tryb Aggressive Mode redukuje liczbę wymienianych pakietów do trzech, łącząc negocjację parametrów, wymianę kluczy DH oraz przesyłanie tożsamości w pojedynczych datagramach. Choć tryb ten przyspiesza zestawianie łącza i umożliwia pracę ze stacjami o zmiennym adresie IP przy użyciu kluczy PSK, posiada krytyczną wadę bezpieczeństwa: tożsamość węzła oraz skrót klucza uwierzytelniającego są przesyłane jawnym tekstem, co pozwala podsłuchującemu napastnikowi na przeprowadzenie ataku słownikowego offline na klucz współdzielony PSK.

W zaawansowanych projektach sieciowych wymóg bezpieczeństwa nakazuje bezwzględne stosowanie trybu Main Mode. Po pomyślnym zakończeniu fazy 1 oba urządzenia dysponują wspólnym, poufnym kanałem kontrolnym, który pozwala na przejście do negocjacji tunelu danych w fazie 2.

Wyjaśnienie skrótów użytych na slajdzie:
IKE - Internet Key Exchange - Protokół zarządzania kluczami w IPsec.
ISAKMP - Internet Security Association and Key Management Protocol - Protokół ramowy wymiany komunikatów sygnalizacyjnych.
DH - Diffie-Hellman - Kryptograficzny protokół uzgadniania kluczy przez nieufny kanał.
SA - Security Association - Logiczne skojarzenie parametrów bezpieczeństwa.
PSK - Pre-Shared Key - Współdzielony klucz statyczny.

16/40 Faza 2 (IKE Phase 2): zestawianie tunelu danych
Przedstawienie mechanizmu negocjacji tunelu danych w Fazie 2 IKEv1 w trybie Quick Mode oraz roli deskryptorów ruchu i mechanizmu PFS.
  • Cel: Ustalenie finalnych parametrów szyfrowania dla właściwego tunelu danych (IPSec SA).
  • Negocjacja odbywa się wewnątrz bezpiecznego tunelu utworzonego w Fazie 1.
  • Konkretne parametry ESP są ustalane ponownie (często mogą różnić się od tych z Fazy 1).
  • Definiowane są tzw. "Policies" (Polityki) - określające precyzyjnie, jaki ruch sieciowy ma zostać skierowany do szyfrowania.
IPsec SA (Skojarzenie fazy 2): Jednokierunkowa umowa kryptograficzna definiująca algorytmy szyfrowania i uwierzytelniania dla właściwego strumienia danych użytkownika; pełna komunikacja dwukierunkowa wymaga zestawienia dokładnie dwóch IPsec SA.
Slide 16

Po pomyślnym zestawieniu bezpiecznego kanału kontrolnego w fazie 1, protokół IKE przechodzi do realizacji Fazy 2 (IKE Phase 2). W architekturze IKEv1 faza ta nosi nazwę trybu szybkiego (Quick Mode). Jej podstawowym celem jest wynegocjowanie finalnych parametrów kryptograficznych dla tunelu danych oraz utworzenie skojarzeń bezpieczeństwa IPsec SA, które będą bezpośrednio chronić pakiety przesyłane przez protokół ESP. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 2407 (IPsec DoI).

Wszystkie komunikaty trybu Quick Mode są przesyłane wewnątrz zaszyfrowanego i uwierzytelnionego kanału ISAKMP SA utworzonego w fazie 1, co uniemożliwia ich podsłuchanie lub sfałszowanie przez podmioty trzecie. Negocjacja w trybie Quick Mode obejmuje wymianę zaledwie trzech pakietów, w których węzły uzgadniają zestaw propozycji (IPsec Proposal): protokół bezpieczeństwa (standardowo ESP), algorytm szyfrowania (np. AES-GCM lub AES-CBC), funkcję integralności oraz czas życia kluczy (Lifetime).

Niezwykle istotnym elementem negocjacji fazy 2 jest uzgodnienie selektorów ruchu (Traffic Selectors / Proxy ID). Selektory ruchu określają zakresy adresacji IP podsieci lokalnej i zdalnej, których komunikacja ma być kierowana do tunelu szyfrowanego. W systemie MikroTik RouterOS selektory te odpowiadają regułom zdefiniowanym w politykach IPsec (/ip ipsec policy). Jakakolwiek niezgodność w maskach sieciowych lub adresach pomiędzy stronami skutkuje natychmiastowym odrzuceniem propozycji i niepowodzeniem negocjacji fazy 2.

W trakcie fazy 2 administrator może opcjonalnie wymusić aktywację mechanizmu Perfect Forward Secrecy (PFS). Włączenie PFS powoduje wykonanie dodatkowej, niezależnej wymiany kluczy Diffie-Hellmana dla każdego nowego skojarzenia IPsec SA. Gwarantuje to, że nawet całkowite skompromitowanie klucza głównego fazy 1 nie pozwoli napastnikowi na odszyfrowanie danych przesłanych w tunelu fazy 2, zapewniając najwyższy poziom odporności kryptograficznej.

Wyjaśnienie skrótów użytych na slajdzie:
IKE - Internet Key Exchange - Protokół uzgadniania kluczy sesyjnych.
ESP - Encapsulating Security Payload - Protokół szyfrowania danych w warstwie IP.
PFS - Perfect Forward Secrecy - Właściwość gwarantująca niezależność kluczy sesyjnych od klucza głównego.
SA - Security Association - Jednokierunkowe skojarzenie bezpieczeństwa.
SPI - Security Parameter Index - Indeks wskazujący odpowiedni rekord SA w tablicy SAD.

17/40 Problem NAT a IPSec (mechanizm UDP 4500)
Wyjaśnienie przyczyn kolizji protokołu IPsec z translatorami adresów sieciowych oraz zasady działania mechanizmu NAT Traversal (RFC 3948).
  • Standardowa translacja NAPT/PAT koliduje z architekturą protokołu IPsec:
  • 1. Protokół ESP (IP Protocol 50) nie posiada portów warstwy 4, co uniemożliwia współdzielenie jednego publicznego adresu IP przez wiele sesji.
  • 2. Modyfikacja nagłówka IP przez NAT narusza integralność w protokole AH oraz unieważnia sumy kontrolne TCP/UDP w trybie transportowym ESP.
  • Rozwiązanie inżynierskie: Mechanizm NAT-T (RFC 3947 / RFC 3948):
    • Urządzenia podczas fazy IKE (UDP 500) wykrywają obecność translatora NAT poprzez porównanie skrótów NAT-D.
    • Po wykryciu NAT sesja automatycznie przepina się na pływający port UDP 4500.
    • Pakiety IKE na porcie 4500 posiadają 4-bajtowy Non-ESP Marker (same zera), natomiast pakiety danych ESP zaczynają się od niezerowego numeru SPI, co pozwala odbiorcy na natychmiastowe rozróżnienie danych od sygnalizacji.
NAT Traversal (NAT-T): Standard rozszerzenia protokołu IPsec (RFC 3947 i RFC 3948) hermetyzujący pakiety protokołu ESP wewnątrz datagramów warstwy transportowej UDP na porcie 4500 w celu przezwyciężenia ograniczeń translacji NAPT/PAT.
Slide 17

Wdrożenie standardu IPsec w środowiskach wykorzystujących translację adresów sieciowych (NAT) przez wiele lat stanowiło jedno z najpoważniejszych wyzwań inżynierii sieciowej. Klasyczna translacja portów (NAPT/PAT) współdzieli pojedynczy publiczny adres IP pomiędzy wiele stacji roboczych poprzez modyfikację portów warstwy transportowej TCP lub UDP. Tymczasem protokół ESP operuje bezpośrednio na poziomie warstwy internetowej jako protokół IP o numerze 50 i nie posiada żadnych numerów portów, co uniemożliwia tradycyjnemu routerowi NAT powiązanie powracających pakietów z konkretnym hostem lokalnym. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 3948 (Enkapsulacja UDP dla IPsec ESP).

Drugi, jeszcze poważniejszy problem dotyczy integralności nagłówków. W trybie transportowym protokołu ESP, sumy kontrolne zawarte w nagłówkach TCP i UDP są obliczane z uwzględnieniem tzw. pseudo-nagłówka IP, zawierającego adresy IP nadawcy i odbiorcy. Gdy router NAT podmienia prywatny adres IP na publiczny, suma kontrolna wewnątrz zaszyfrowanego ładunku staje się niepoprawna. Ponieważ router NAT nie może odszyfrować pakietu, nie może również zaktualizować sumy kontrolnej, co skutkuje cichym odrzuceniem pakietu przez stację docelową.

Rozwiązaniem tych problemów stał się mechanizm NAT Traversal (NAT-T), ustandaryzowany w dokumentach RFC 3947 oraz RFC 3948. W trakcie wstępnej fazy negocjacji IKE na porcie UDP 500 węzły wymieniają specjalne ładunki NAT-Discovery (NAT-D) zawierające kryptograficzne skróty adresów IP i portów. Jeżeli wyliczone skróty nie zgadzają się z adresem odebranego pakietu, routery automatycznie stwierdzają obecność urządzenia NAT na trasie transmisji.

Po wykryciu translatora NAT urządzenia natychmiast przełączają całą komunikację z portu UDP 500 na dedykowany, pływający port UDP 4500. W kanale tym pakiety danych ESP są pakowane wewnątrz standardowych nagłówków UDP 4500, co pozwala translatorom PAT na bezproblemowe śledzenie sesji i modyfikację portów. Aby odróżnić pakiety kontrolne IKE od danych ESP na tym samym porcie, pakiety IKE są poprzedzane 4 bajtami zerowymi (Non-ESP Marker), natomiast pakiety ESP rozpoczynają się od niezerowego indeksu SPI.

Wyjaśnienie skrótów użytych na slajdzie:
NAT-T - NAT Traversal - Mechanizm tunelowania pakietów ESP przez translację NAT za pomocą UDP 4500.
ESP - Encapsulating Security Payload - Protokół szyfrowania danych IPsec (IP Protocol 50).
PAT - Port Address Translation - Translacja adresów sieciowych ze współdzieleniem portów transportowych.
SPI - Security Parameter Index - Identyfikator skojarzenia bezpieczeństwa odróżniający pakiety ESP od IKE.
UDP - User Datagram Protocol - Protokół warstwy transportowej.

18/40 L2TP/IPSec w systemie RouterOS
Przegląd architektury wdrożeniowej oraz mechanizmów automatyzacji konfiguracji L2TP/IPSec w systemie MikroTik RouterOS.
  • Konfiguracja w systemie MikroTik jest uproszczona dzięki modułowi "one-click IPSec".
  • Serwer L2TP potrafi automatycznie generować odpowiednie polityki bezpieczeństwa IPSec w tle.
  • Administrator nie musi ręcznie konfigurować wszystkich parametrów w menu IP -> IPSec.
  • Wystarczy aktywować opcję "Use IPSec: yes" i ustalić wspólne hasło ("IPSec Secret" / PSK).
Dynamiczne skojarzenie IPsec (Dynamic IPsec Generation): Mechanizm systemu RouterOS, który na podstawie pojedynczego parametru use-ipsec automatycznie tworzy w tle wymagane profile, węzły peer, tożsamości oraz dynamiczne polityki IPsec dla przychodzących połączeń L2TP.
Slide 18

Implementacja hybrydowej technologii L2TP/IPSec w systemie MikroTik RouterOS wyróżnia się wyjątkową elegancją inżynierską oraz wysokim stopniem automatyzacji. W klasycznych systemach sieciowych uruchomienie tego typu połączenia wymagało niezależnego, ręcznego konfigurowania dwóch odrębnych podsystemów: serwera L2TP oraz złożonego zestawu reguł, węzłów peer i polityk w podsystemie IPsec. Szczegółowe informacje normatywne i techniczne publikuje Dokumentacja MikroTik L2TP.

W systemie RouterOS inżynierowie wprowadzili mechanizm automatycznego generowania struktur IPsec bezpośrednio z poziomu konfiguracji serwera L2TP. Aktywacja parametru use-ipsec=yes oraz zdefiniowanie klucza współdzielonego ipsec-secret instruuje jądro systemu o konieczności automatycznego utworzenia w tle dynamicznych wpisów w tablicy /ip ipsec identity oraz wygenerowania dynamicznych polityk szyfrujących dla każdego zgłaszającego się klienta.

Gdy zdalny pracownik nawiązuje łączność ze stacji roboczej, RouterOS najpierw dynamicznie zestawia skojarzenie IKE na porcie UDP 500 (lub UDP 4500 w przypadku obecności NAT), a po jego pomyślnym uwierzytelnieniu automatycznie instaluje w jądrze politykę IPsec w trybie transportowym dla portu UDP 1701. Cały ruch L2TP zostaje objęty szyfrowaniem ESP w locie, w sposób całkowicie przezroczysty dla administratora.

Taka architektura drastycznie skraca czas wdrożenia, eliminuje błędy konfiguracyjne związane z ręcznym doborem selektorów ruchu oraz zapewnia doskonałą skalowalność. Administrator może zarządzać setkami jednoczesnych połączeń pracowników mobilnych bez konieczności definiowania statycznych adresów IP dla poszczególnych klientów.

Wyjaśnienie skrótów użytych na slajdzie:
L2TP - Layer 2 Tunneling Protocol - Protokół tunelowania warstwy łącza danych.
IPsec - Internet Protocol Security - Kryptograficzny standard bezpieczeństwa warstwy sieciowej.
ESP - Encapsulating Security Payload - Protokół szyfrowania danych.
CLI - Command Line Interface - Tekstowy interfejs zarządzania routerem.
NAT - Network Address Translation - Translacja adresów sieciowych.

19/40 Konfiguracja serwera L2TP/IPSec
Instruktaż krok po kroku konfiguracji bezpiecznego serwera L2TP/IPSec w systemie MikroTik RouterOS.
  • /interface l2tp-server server set
enabled=yes
default-profile=profile-vpn
authentication=mschap2
use-ipsec=yes
ipsec-secret="HasloWspolneDlaWszystkich"
  • Ta prosta komenda powoduje automatyczne stworzenie obiektów Peer, Identity oraz Policy w konfiguracji IPSec.
Klucz współdzielony IPsec (IPsec Pre-Shared Key): Niejawny ciąg znaków alfanumerycznych skonfigurowany symetrycznie na serwerze i stacji klienckiej, wykorzystywany w fazie 1 IKE do wzajemnego uwierzytelnienia maszyn.
Slide 19

Praktyczne uruchomienie serwera L2TP z ochroną kryptograficzną IPsec w systemie MikroTik RouterOS realizuje się w gałęzi /interface l2tp-server server. Konfiguracja wymaga precyzyjnego zdefiniowania dozwolonych metod uwierzytelniania, przypisania profilu sesji PPP oraz określenia parametrów integracji ze stosem IPsec. Szczegółowe informacje normatywne i techniczne publikuje Dokumentacja MikroTik IPsec.

Podstawowe polecenie wdrożeniowe ma postać: /interface l2tp-server server set enabled=yes default-profile=default-encryption authentication=mschap2 use-ipsec=yes ipsec-secret="TajnyKluczFirmowy123!" caller-id-type=ip-address. W parametrze authentication należy bezwzględnie ograniczyć dozwolone protokoły do mschap2, wyłączając podatne na podsłuch mechanizmy pap i chap. Zapewnia to bezpieczną autoryzację użytkownika na poziomie sesji PPP.

Parametr use-ipsec=yes jest kluczem do aktywacji ochrony kryptograficznej. Wartość yes wymusza, aby router odrzucał wszelkie próby nawiązania połączenia L2TP, które nie są zabezpieczone tunelem IPsec, co wyklucza ryzyko przypadkowego przesyłania danych w postaci jawnej. Z kolei parametr ipsec-secret definiuje klucz PSK, który musi zostać wprowadzony przez użytkownika podczas konfigurowania połączenia w systemie operacyjnym Windows.

Dodatkowo dobrą praktyką inżynierską jest powiązanie serwera z dedykowaną pulą adresową (/ip pool) zdefiniowaną w profilu PPP oraz wskazanie korporacyjnych serwerów DNS. Po zatwierdzeniu konfiguracji serwer przechodzi w stan nasłuchu na publicznym interfejsie WAN, oczekując na pakiety sygnalizacyjne IKE oraz L2TP.

Wyjaśnienie skrótów użytych na slajdzie:
L2TP - Layer 2 Tunneling Protocol - Protokół tunelowania warstwy 2.
IPsec - Internet Protocol Security - Kryptograficzny standard bezpieczeństwa.
PSK - Pre-Shared Key - Współdzielony klucz statyczny.
DNS - Domain Name System - System nazw domenowych.
CLI - Command Line Interface - Wiersz poleceń RouterOS.

20/40 Konfiguracja firewalla dla L2TP/IPSec
Projektowanie kompletnego zestawu reguł filtrujących zapory sieciowej na styku WAN dla obsługi ruchu L2TP/IPSec.
  • Niezbędne reguły w łańcuchu INPUT:
  • # 1. Port dla negocjacji IKE
add action=accept chain=input protocol=udp dst-port=500 comment="IKE"
# 2. Port dla NAT-Traversal
add action=accept chain=input protocol=udp dst-port=4500 comment="NAT-T"
# 3. Ruch szyfrowany ESP (Protocol 50)
add action=accept chain=input protocol=ipsec-esp comment="ESP"
# 4. Port sterujący L2TP
add action=accept chain=input protocol=udp dst-port=1701 comment="L2TP"
Filtracja pakietów L2TP/IPsec (L2TP/IPsec Packet Filtering): Zestaw reguł w łańcuchu wejściowym zapory sieciowej (Input Chain) zezwalający wyłącznie na uprawniony ruch negocjacyjny IKE, pakiety danych ESP oraz hermetyzowane datagramy UDP.
Slide 20

Prawidłowe zaprojektowanie reguł zapory ogniowej (Firewall) na styku z publicznym Internetem (interfejs WAN) jest niezbędnym warunkiem sprawnego działania usług L2TP/IPSec. Ponieważ w architekturze tej dane i sygnalizacja są przesyłane za pomocą kilku różnych protokołów, pominięcie choćby jednej reguły w łańcuchu wejściowym (Input Chain) skutkuje natychmiastowym zablokowaniem sesji. Szczegółowe informacje normatywne i techniczne publikuje Projekt Netfilter / Iptables.

Pierwszą i fundamentalną regułą jest otwarcie portu UDP 500, na którym realizowana jest Faza 1 negocjacji IKE: /ip firewall filter add chain=input protocol=udp dst-port=500 in-interface=WAN action=accept comment="IPsec IKE negocjacja". Bez tej reguły router odrzuci wstępny pakiet negocjacyjny i stacja kliencka natychmiast zgłosi błąd braku odpowiedzi serwera.

Druga reguła dotyczy obsługi mechanizmu NAT Traversal na porcie UDP 4500: /ip firewall filter add chain=input protocol=udp dst-port=4500 in-interface=WAN action=accept comment="IPsec NAT-T pakiety". Trzecia reguła musi zezwalać na ruch samego protokołu szyfrującego ESP (IP Protocol 50): /ip firewall filter add chain=input protocol=ipsec-esp in-interface=WAN action=accept comment="IPsec ESP dane szyfrowane". Jest to krytyczne dla klientów łączących się z publicznych adresów IP bez barier NAT.

Czwarta reguła dotyczy bezpośrednio protokołu L2TP na porcie UDP 1701: /ip firewall filter add chain=input protocol=udp dst-port=1701 in-interface=WAN action=accept comment="L2TP serwer". W celu maksymalizacji bezpieczeństwa regułę L2TP można dodatkowo obwarować warunkiem ipsec-policy=in,ipsec, co zagwarantuje, że router przyjmie pakiet L2TP wyłącznie wtedy, gdy został on uprzednio odszyfrowany przez silnik IPsec.

Wyjaśnienie skrótów użytych na slajdzie:
IKE - Internet Key Exchange - Protokół negocjacji kluczy na porcie UDP 500.
NAT-T - NAT Traversal - Tunelowanie IPsec przez NAT na porcie UDP 4500.
ESP - Encapsulating Security Payload - Protokół szyfrowania IPsec o numerze IP 50.
UDP - User Datagram Protocol - Protokół transportowy warstwy 4.
WAN - Wide Area Network - Interfejs podłączony do sieci publicznej.

21/40 Konfiguracja klienta w systemie Windows
Przewodnik po konfiguracji połączenia L2TP/IPSec w systemie operacyjnym Windows z uwzględnieniem klucza współdzielonego i właściwości zabezpieczeń.
  • Podobnie jak w PPTP, korzystamy z systemowego kreatora, wybierając:
  • Typ sieci VPN: L2TP/IPSec z kluczem wstępnym.
  • W polu Klucz wstępny (Pre-shared Key) wprowadzamy hasło ustawione jako "ipsec-secret".
  • Dane użytkownika (login/hasło) podajemy zgodnie z bazą Secrets routera.
  • Uwaga: Połączenie może wymagać dodatkowych kroków, jeśli router serwera jest za NAT-em dostawcy.
Właściwości zaawansowane L2TP (L2TP Advanced Security Settings): Panel konfiguracyjny w systemie Windows definiujący rodzaj uwierzytelnienia maszynowego dla IPsec (klucz wstępny PSK lub certyfikat komputera) oraz metody weryfikacji tożsamości użytkownika w protokole PPP.
Slide 21

Podobnie jak w przypadku protokołów PPTP oraz SSTP, system operacyjny Windows posiada w pełni zintegrowanego, natywnego klienta L2TP/IPSec. Konfigurację rozpoczyna się w aplecie Ustawienia -> Sieć i Internet -> VPN poprzez dodanie nowego połączenia. Jako dostawcę wybiera się Windows (wbudowane), wprowadza czytelną nazwę połączenia oraz publiczny adres IP lub nazwę FQDN bramy VPN. Szczegółowe informacje normatywne i techniczne publikuje Microsoft Learn Sieci Windows Server.

W polu Typ sieci VPN należy jawnie wybrać opcję Protokół L2TP/IPsec z kluczem wstępnym (lub z certyfikatami, jeśli wdrożono infrastrukturę PKI). Poniżej wprowadza się dokładnie taki sam ciąg znaków klucza współdzielonego, jaki został zdefiniowany w parametrze ipsec-secret na routerze MikroTik. Klucz ten jest wykorzystywany przez stos sieciowy Windows do zestawienia Fazy 1 negocjacji IKE.

W celu zagwarantowania stabilności połączenia i uniknięcia błędów negocjacji należy otworzyć aplet połączeń sieciowych (ncpa.cpl), wejść we Właściwości karty VPN i przejść do zakładki Zabezpieczenia. W polu Szyfrowanie danych należy ustawić opcję Wymagaj szyfrowania, natomiast w sekcji protokołów uwierzytelniania zaznaczyć wyłącznie Microsoft CHAP Version 2 (MS-CHAP v2), odznaczając nieszyfrowane metody PAP i CHAP.

Warto pamiętać, że w systemie Windows domyślnie aktywowana jest opcja pełnego tunelowania (Full Tunneling). Jeżeli celem wdrożenia jest skierowanie do tunelu wyłącznie ruchu przeznaczonego dla sieci korporacyjnej z zachowaniem lokalnego wyjścia do Internetu, administrator powinien pouczyć użytkowników o konieczności wyłączenia opcji 'Użyj domyślnej bramy w sieci zdalnej' we właściwościach protokołu IPv4.

Wyjaśnienie skrótów użytych na slajdzie:
L2TP - Layer 2 Tunneling Protocol - Protokół tunelowania warstwy 2.
IPsec - Internet Protocol Security - Kryptograficzny standard warstwy 3.
PSK - Pre-Shared Key - Współdzielony klucz statyczny.
MS-CHAPv2 - Microsoft Challenge Handshake Authentication Protocol v2 - Protokół uwierzytelniania użytkownika.
GUI - Graphical User Interface - Graficzny interfejs konfiguracji połączeń Windows.

22/40 L2TP za NAT - ważna korekta rejestru Windows
Wyjaśnienie przyczyn blokowania połączeń L2TP/IPSec za translatorami NAT przez system Windows oraz procedura modyfikacji rejestru systemowego.
  • System Windows z powodów bezpieczeństwa domyślnie blokuje zestawianie tuneli L2TP/IPSec, gdy serwer VPN znajduje się za barierą translacji NAT.
  • Objawy: Natychmiastowy błąd 789 (brak negocjacji parametrów zabezpieczeń) lub błąd 809 (brak odpowiedzi serwera).
  • Procedura naprawcza w rejestrze systemowym Windows:
  • 1. Otwórz edytor rejestru (regedit.exe).
  • 2. Przejdź do klucza: HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent
  • 3. Utwórz nową wartość DWORD (32-bit) o nazwie: AssumeUDPEncapsulationContextOnSendRule
  • 4. Przypisz wartość: 2 (pozwala na poprawne działanie, gdy zarówno serwer, jak i stacja robocza znajdują się za translatorami NAT).
  • 5. Wymagany pełny restart systemu operacyjnego.
Wartość rejestru AssumeUDPEncapsulationContextOnSendRule: Parametr konfiguracyjny usługi IPsec PolicyAgent w systemie Windows determinujący dopuszczalność enkapsulacji pakietów IPsec w datagramach UDP w warunkach obecności translatorów NAT po stronie serwera i klienta.
Slide 22

Jednym z najbardziej frustrujących problemów, z jakimi spotykają się inżynierowie wdrażający serwery L2TP/IPSec na routerach MikroTik, jest domyślne zachowanie stosu sieciowego systemu Windows w środowiskach z translacją adresów NAT. Mimo całkowicie poprawnej konfiguracji serwera i zapory próba połączenia z systemu Windows kończy się natychmiastowym błędem o kodzie 789 lub 809. Szczegółowe informacje normatywne i techniczne publikuje Microsoft Wdrażanie L2TP/IPSec za urządzeniem NAT-T.

Przyczyną tego zjawiska jest celowe ograniczenie bezpieczeństwa zaimplementowane przez firmę Microsoft. Domyślnie system Windows uznaje zestawianie połączeń IPsec w trybie transportowym za urządzeniem NAT (tzw. NAT Traversal) za scenariusz podwyższonego ryzyka (np. ryzyko kolizji portów lub niejednoznaczności odwzorowań w translatorach PAT) i bezwzględnie blokuje wysyłanie pakietów enkapsulowanych w UDP 4500, jeśli serwer znajduje się za barierą NAT.

W celu odblokowania możliwości zestawiania połączeń konieczna jest jednorazowa modyfikacja rejestru systemowego Windows na komputerze klienta. W edytorze rejestru (regedit.exe) należy przejść do gałęzi: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent. W kluczu tym należy utworzyć nową wartość DWORD (32-bitowa) o nazwie AssumeUDPEncapsulationContextOnSendRule.

Parametr ten przyjmuje wartość 0 (domyślna blokada), 1 (zezwolenie, gdy tylko serwer jest za NAT) lub 2 (zezwolenie, gdy zarówno serwer, jak i stacja robocza klienta znajdują się za barierami NAT). W praktyce inżynierskiej bezwzględnie ustawia się wartość 2, co pozwala pracownikom na łączenie się z domowych routerów Wi-Fi. Zmiana parametru wymaga pełnego ponownego uruchomienia komputera, po czym połączenie zestawia się bez przeszkód.

Wyjaśnienie skrótów użytych na slajdzie:
NAT - Network Address Translation - Translacja adresów sieciowych.
L2TP - Layer 2 Tunneling Protocol - Protokół tunelowania warstwy 2.
IPsec - Internet Protocol Security - Standard kryptograficzny warstwy sieciowej.
DWORD - Double Word - 32-bitowy typ danych rejestru systemowego Windows.
PAT - Port Address Translation - Odmiana translacji NAT operująca na portach warstwy transportowej.

23/40 Tunel IPSec Site-to-Site (między oddziałami)
Przedstawienie architektury, zalet i wymagań bezpiecznych połączeń międzyoddziałowych Site-to-Site z wykorzystaniem czystego protokołu IPsec w trybie tunelowym.
  • Służy do łączenia całych sieci LAN poprzez Internet (np. centrala <-> oddział).
  • W tym modelu nie stosuje się wirtualnych interfejsów (brak potrzeby adresacji IP tunelu).
  • Bazujemy na tzw. Policy Based Routing.
  • Router monitoruje ruch: "Jeśli pakiet leci z sieci A do sieci B, przechwyć go, zaszyfruj i wyślij tunelem".
  • Model ten oferuje najwyższą przepustowość dzięki optymalizacji sprzętowej.
Tunel IPsec Site-to-Site (Site-to-Site IPsec Tunnel): Stałe połączenie kryptograficzne w warstwie 3 zestawione bezpośrednio pomiędzy dwoma routerami brzegowymi, integrujące odrębne sieci lokalne przedsiębiorstwa przez publiczny Internet bez udziału oprogramowania na stacjach roboczych.
Slide 23

W architekturze korporacyjnej sieci rozległej najważniejszym mechanizmem bezpiecznej integracji zasobów rozproszonych geograficznie oddziałów przedsiębiorstwa jest tunel IPsec Site-to-Site. W przeciwieństwie do rozwiązań zdalnego dostępu (Remote Access), połączenie to jest konfigurowane wyłącznie na poziomie routerów brzegowych i działa w sposób całkowicie przezroczysty dla pracowników oraz stacji roboczych w sieci LAN. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 1918 (Adresacja prywatna IPv4).

Czysty tunel IPsec Site-to-Site operuje w trybie tunelowym protokołu ESP (Tunnel Mode). W tym modelu router brzegowy w oddziale lokalnym przechwytuje pakiety generowane przez komputery w sieci LAN, szyfruje je w całości algorytmem symetrycznym (np. AES-256-GCM), dokłada zewnętrzny nagłówek IP zaadresowany do publicznego interfejsu routera centrali i przesyła przez nieufną infrastrukturę dostawców Internetu.

Fundamentalną zaletą czystego IPsec Site-to-Site jest minimalny narzut nagłówków oraz brak konieczności uruchamiania dodatkowych protokołów tunelujących (takich jak GRE czy L2TP). Pozwala to na osiąganie najwyższych możliwych przepustowości na układach sieciowych zintegrowanych ze sprzętowymi akceleratorami kryptograficznymi AES. Jednocześnie komunikacja jest zabezpieczona przed podsłuchem, manipulacją oraz atakami typu Replay.

Warto jednak pamiętać o ograniczeniach czystego IPsec: standardowo nie obsługuje on transmisji pakietów rozgłoszeniowych (broadcast) ani grupowych (multicast), co uniemożliwia bezpośrednie uruchomienie protokołów routingu dynamicznego stanu łącza (np. OSPF) bez wdrożenia technologii VTI (Virtual Tunnel Interface) lub nakładki GRE. W prostych scenariuszach dwupunktowych ruch jest przekazywany w oparciu o statyczne polityki bezpieczeństwa (Policy-Based IPsec).

Wyjaśnienie skrótów użytych na slajdzie:
IPsec - Internet Protocol Security - Standard kryptograficzny warstwy 3.
ESP - Encapsulating Security Payload - Protokół szyfrowania danych w trybie tunelowym.
LAN - Local Area Network - Lokalna podsieć w oddziale przedsiębiorstwa.
WAN - Wide Area Network - Sieć rozległa stanowiąca publiczne medium transportowe.
VTI - Virtual Tunnel Interface - Logiczny interfejs tunelowy umożliwiający routowanie ruchu przez IPsec.

24/40 Konfiguracja IPSec Peer (MikroTik) - faza 1
Instruktaż konfiguracji profilu kryptograficznego, tożsamości oraz węzła partnerskiego IPsec Peer dla Fazy 1 w systemie MikroTik RouterOS v7.
  • # 1. Definicja profilu (standardy bezpieczeństwa)
/ip ipsec profile add name=s2s_profile enc-algorithm=aes-256 dh-group=modp2048

# 2. Definicja Peera (drugiego routera)
/ip ipsec peer add name=peer_B address=2.2.2.2 profile=s2s_profile

# 3. Ustawienie hasła autoryzacji (Identity)
/ip ipsec identity add peer=peer_B secret="KluczWspolny"
Węzeł partnerski IPsec Peer (IPsec Peer): Obiekt konfiguracyjny w systemie RouterOS definiujący adres zdalnej bramy VPN, powiązany profil kryptograficzny IKE oraz metodę wymiany kluczy w Fazie 1.
Slide 24

Konfiguracja połączenia IPsec Site-to-Site w nowoczesnych wersjach systemu MikroTik RouterOS (wersja RouterOS v7) została zorganizowana w modularną strukturę obiektową, ściśle odzwierciedlającą podział na Fazę 1 oraz Fazę 2 negocjacji IKE. Pierwszym etapem inżynierskim jest zdefiniowanie parametrów Fazy 1 w tabelach /ip ipsec profile, /ip ipsec peer oraz /ip ipsec identity. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 3526 (Grupy Diffie-Hellmana dla IKE).

W pierwszej kolejności tworzy się profil kryptograficzny w gałęzi /ip ipsec profile add name=profile-siteB enc-algorithm=aes-256 hash-algorithm=sha256 dh-group=modp2048 nat-traversal=yes. W profilu tym precyzuje się algorytmy, które będą stosowane do ochrony samego kanału sterującego ISAKMP. Zgodnie z nowoczesnymi standardami należy bezwzględnie unikać słabych grup Diffie-Hellmana (modp768, modp1024), stosując co najmniej grupę 14 (modp2048) lub grupy krzywych eliptycznych (ecp256).

Następnie konfiguruje się węzeł partnerski: /ip ipsec peer add name=peer-siteB address=2.2.2.2/32 profile=profile-siteB exchange-mode=ike2. Parametr address wskazuje publiczny adres IP zdalnego routera brzegowego, natomiast exchange-mode określa protokół sygnalizacyjny (zaleca się jawne wskazanie nowoczesnego protokołu ike2 zamiast przestarzałego ike1 w trybie main).

Ostatnim elementem konfiguracji Fazy 1 jest definicja tożsamości w gałęzi /ip ipsec identity add peer=peer-siteB auth-method=pre-shared-key secret="BardzoBezpiecznyKluczSiteToSite123!". W obiekcie identity wskazuje się metodę uwierzytelniania maszynowego oraz niejawny klucz PSK. Od tej chwili router jest gotowy do rozpoczęcia negocjacji Fazy 1 natychmiast po pojawieniu się ruchu spełniającego kryteria polityk bezpieczeństwa.

Wyjaśnienie skrótów użytych na slajdzie:
IKE - Internet Key Exchange - Protokół negocjacji parametrów i kluczy.
DH - Diffie-Hellman - Matematyczny algorytm bezpiecznego uzgadniania kluczy.
PSK - Pre-Shared Key - Współdzielony klucz statyczny w Fazie 1.
CLI - Command Line Interface - Tekstowy interfejs zarządzania RouterOS.
IPsec - Internet Protocol Security - Standard bezpieczeństwa warstwy sieciowej.

25/40 Definiowanie polityk (Policy) - faza 2
Przewodnik po tworzeniu propozycji kryptograficznych oraz polityk bezpieczeństwa Fazy 2 w systemie MikroTik RouterOS.
  • Określenie zakresu adresów podlegających szyfrowaniu:
  • # Konfiguracja na Routerze A
/ip ipsec policy add
peer=peer_B
src-address=192.168.10.0/24
dst-address=192.168.20.0/24
action=encrypt tunnel=yes
  • Pamiętaj: Konfiguracja na obu routerach musi być lustrzanym odbiciem względem adresów IP.
Polityka IPsec (IPsec Security Policy): Reguła w bazie SPD (Security Policy Database) nakazująca routerowi przechwytywanie pakietów spełniających kryteria adresów źródłowych i docelowych oraz ich szyfrowanie zgodnie ze skojarzeniem SA.
Slide 25

Po poprawnym skonfigurowaniu Fazy 1 kolejnym etapem jest zdefiniowanie reguł Fazy 2, które bezpośrednio decydują o tym, jaki ruch sieciowy podlega ochronie kryptograficznej i jakimi algorytmami jest szyfrowany. Konfiguracja w systemie RouterOS obejmuje dwa powiązane ze sobą elementy: propozycję kryptograficzną (/ip ipsec proposal) oraz właściwą politykę bezpieczeństwa (/ip ipsec policy). Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 4106 (AES-GCM w IPsec ESP).

W gałęzi proposal definiuje się zbiór algorytmów dla tunelu danych ESP: /ip ipsec proposal add name=prop-siteB auth-algorithms=sha256 enc-algorithms=aes-256-gcm pfs-group=modp2048 lifetime=8h. Zastosowanie szyfrowania AEAD (aes-256-gcm) jest wysoce zalecane, ponieważ łączy ono operacje szyfrowania i obliczania integralności w pojedynczym, zoptymalizowanym sprzętowo procesie, drastycznie redukując obciążenie procesora.

Właściwą politykę tworzy się w tabeli /ip ipsec policy add peer=peer-siteB src-address=192.168.10.0/24 dst-address=192.168.20.0/24 tunnel=yes action=encrypt proposal=prop-siteB. Parametry src-address oraz dst-address stanowią selektory ruchu (Traffic Selectors) - instruują one jądro systemu, że każdy pakiet podążający z lokalnej sieci LAN A (192.168.10.0/24) do odległej podsieci LAN B (192.168.20.0/24) musi zostać przechwycony, opieczętowany tunelem IPsec i zaszyfrowany.

Kluczowym parametrem jest tunnel=yes, który wymusza operowanie w trybie tunelowym (dodanie nowego zewnętrznego nagłówka IP). Na routerze w oddziale B należy skonfigurować regułę symetryczną, odwracając przypisanie adresów źródłowych i docelowych. Jakakolwiek niezgodność w selektorach ruchu (np. inna maska podsieci po stronie zdalnej) spowoduje odrzucenie negocjacji w Fazie 2 z błędem 'no policy found'.

Wyjaśnienie skrótów użytych na slajdzie:
SPD - Security Policy Database - Baza polityk bezpieczeństwa decydująca o szyfrowaniu pakietów.
ESP - Encapsulating Security Payload - Protokół szyfrowania danych.
PFS - Perfect Forward Secrecy - Wymuszenie nowej wymiany DH w Fazie 2.
LAN - Local Area Network - Prywatna podsieć lokalna.
AEAD - Authenticated Encryption with Associated Data - Nowoczesny zintegrowany tryb kryptograficzny.

26/40 Wyjątki NAT w tunelach IPSec (NAT-Exemption)
Analiza konfliktu pomiędzy translacją adresów NAT a politykami IPsec oraz metodyka wdrażania reguł NAT-Exemption.
  • Standardowa reguła maskarady (NAT) dla Internetu może "popsuć" ruch VPN.
  • Jeśli NAT zmieni adres prywatny pakietu przed jego zaszyfrowaniem IPSec...
  • ...polityka IPSec nie rozpozna pakietu i nie wyśle go do tunelu.
  • Rozwiązanie: Należy dodać regułę typu NAT ACCEPT przed regułą maskarady.
  • chain=srcnat src-address=192.168.10.0/24 dst-address=192.168.20.0/24 action=accept
Wyjątek translacji NAT (NAT Exemption): Reguła w łańcuchu srcnat zapory sieciowej umieszczana przed regułą maskarady, wykluczająca pakiety przesyłane pomiędzy podsieciami VPN z translacji adresów IP.
Slide 26

W architekturze routera brzegowego zarządzającego ruchem sieci lokalnej standardowym elementem konfiguracji jest reguła maskarady (Source NAT / Masquerade). Reguła ta zamienia prywatne adresy źródłowe stacji roboczych (np. 192.168.10.x) na publiczny adres interfejsu WAN, umożliwiając komputerom korzystanie z globalnego Internetu. W momencie uruchomienia tunelu IPsec Site-to-Site zachowanie to prowadzi do krytycznego konfliktu logicznego. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 3022 (Translacja NAT).

Zgodnie z architekturą przepływu pakietów w systemie MikroTik RouterOS (Packet Flow), łańcuch translacji srcnat w zaporze ogniowej jest wykonywany PRZED mechanizmem dopasowywania polityk bezpieczeństwa IPsec (SPD). W rezultacie pakiet wysłany z sieci LAN do zdalnego oddziału najpierw trafia do reguły maskarady, która podmienia jego adres źródłowy na publiczny adres IP routera WAN. W tym momencie pakiet przestaje spełniać kryteria polityki IPsec (która oczekuje źródła 192.168.10.0/24) i zostaje wysłany do Internetu jawnym tekstem zamiast trafić do tunelu.

Rozwiązaniem tego problemu jest wdrożenie mechanizmu zwanego wyjątkiem z translacji (NAT-Exemption). Na routerze należy dodać jawną regułę w gałęzi /ip firewall nat z akcją accept, umieszczoną na samej górze tablicy NAT, powyżej ogólnej reguły maskarady. Reguła ta ma postać: /ip firewall nat add chain=srcnat action=accept src-address=192.168.10.0/24 dst-address=192.168.20.0/24 place-before=0 comment="Wyjątek NAT dla tunelu IPsec do Oddziału B".

Gdy pakiet spełnia kryteria tej reguły, system wykonuje akcję accept (co w tablicy NAT oznacza zakończenie przetwarzania bez modyfikacji nagłówka) i zachowuje oryginalny prywatny adres źródłowy. W kolejnym etapie przetwarzania pakiet trafia do silnika IPsec, idealnie dopasowuje się do selektorów polityki bezpieczeństwa i zostaje prawidłowo zaszyfrowany przez protokół ESP.

Wyjaśnienie skrótów użytych na slajdzie:
NAT - Network Address Translation - Translacja adresów sieciowych.
SPD - Security Policy Database - Baza polityk decydująca o przechwytywaniu pakietów przez IPsec.
LAN - Local Area Network - Prywatna sieć lokalna oddziału.
WAN - Wide Area Network - Interfejs podłączony do sieci publicznej.
CLI - Command Line Interface - Interfejs wiersza poleceń RouterOS.

27/40 Konflikt z mechanizmem FastTrack
Wyjaśnienie mechanizmu kolizji pomiędzy sprzętowym przyspieszeniem FastTrack a silnikiem polityk IPsec w RouterOS oraz metody eliminacji problemu.
  • Mechanizm FastPath / FastTrack w systemie RouterOS pozwala na sprzętowe przyspieszenie routingu poprzez pomijanie inspekcji zapory dla ustanowionych połączeń.
  • Krytyczny błąd bezpieczeństwa: FastTrack przetwarza pakiety przed silnikiem polityk IPsec, w wyniku czego pakiety przeznaczone do tunelu są wysyłane w sieć publiczną jawnym tekstem bez szyfrowania lub bezpowrotnie porzucane!
  • Prawidłowa konfiguracja reguły w RouterOS:
  • W łańcuchu forward reguła FastTrack musi jawnie wykluczać pakiety podlegające politykom IPsec:
    /ip firewall filter add chain=forward action=fasttrack-connection connection-state=established,related ipsec-policy=out,none comment="FastTrack z pominięciem tuneli IPSec"
Mechanizm FastTrack (FastPath / FastTrack): Mechanizm optymalizacji jądra RouterOS przyspieszający przekazywanie pakietów poprzez pomijanie inspekcji zapory sieciowej, kolejek QoS oraz transformacji pakietów dla ustanowionych połączeń.
Slide 27

W systemie MikroTik RouterOS domyślna konfiguracja zapory sieciowej zawiera regułę wykorzystującą akcję fasttrack-connection w łańcuchu forward. Mechanizm FastTrack stanowi potężne narzędzie optymalizacyjne - pozwala procesorowi routera na błyskawiczne przełączanie zatwierdzonych pakietów z pominięciem większości modułów jądra, co pozwala na osiąganie gigabitowych przepustowości na tanich urządzeniach domowych i biurowych. Szczegółowe informacje normatywne i techniczne publikuje Oficjalny portal pomocy technicznej MikroTik.

W środowiskach wykorzystujących tunele IPsec mechanizm FastTrack staje się jednak źródłem krytycznych błędów bezpieczeństwa i awarii łączności. Dzieje się tak, ponieważ pakiety oznaczone do szybkiej ścieżki FastTrack omijają zaawansowane procedury sprawdzania polityk w bazie SPD. W efekcie pakiety, które bezwzględnie powinny zostać przechwycone przez silnik IPsec i zaszyfrowane w nagłówki ESP, są wysyłane przez domyślną bramę sieci WAN jawnym tekstem w postaci niezaszyfrowanej lub są bezpowrotnie gubione.

Skutkiem tego zjawiska jest całkowity brak komunikacji między sieciami LAN w tunelu IPsec lub wysoce niebezpieczny wyciek poufnych danych korporacyjnych do sieci publicznej w postaci czystego tekstu. Zjawisko to występuje sporadycznie i jest trudne do zdiagnozowania, ponieważ pierwsze pakiety nowej sesji mogą zostać zaszyfrowane poprawnie, po czym całe połączenie nagle zamiera po przejściu w stan FastTrack.

Jedynym poprawnym rozwiązaniem inżynierskim jest zmodyfikowanie domyślnej reguły FastTrack w zaporze sieciowej tak, aby jawnie wykluczała ruch podlegający politykom IPsec. W systemie RouterOS realizuje się to poprzez dodanie parametru ipsec-policy=out,none: /ip firewall filter add chain=forward action=fasttrack-connection connection-state=established,related ipsec-policy=out,none comment="FastTrack z wykluczeniem IPSec". Zapewnia to maksymalną prędkość dla ruchu internetowego przy zachowaniu pełnej ochrony tuneli VPN.

Wyjaśnienie skrótów użytych na slajdzie:
FastTrack - FastTrack FastPath Forwarding - Mechanizm przyspieszonego przełączania pakietów w RouterOS.
SPD - Security Policy Database - Baza polityk decydująca o szyfrowaniu IPsec.
ESP - Encapsulating Security Payload - Protokół szyfrowania danych w warstwie IP.
QoS - Quality of Service - Mechanizmy zarządzania pasmem i jakością transmisji.
WAN - Wide Area Network - Interfejs publiczny narażony na wyciek nieszyfrowanych pakietów.

28/40 Narzędzia diagnostyczne: analiza pakietów
Przegląd wbudowanych i zewnętrznych narzędzi diagnostycznych do monitorowania, analizy i debugowania tuneli IPsec.
  • Jak sprawdzić działanie VPN na interfejsie zewnętrznym (WAN)?
  • Przy poprawnym działaniu: Powinniśmy widzieć wyłącznie pakiety ESP (Protocol 50). Treść i adresy wewnętrzne są ukryte.
  • Widoczny ruch na portach UDP 500/4500: Faza negocjacji sesji lub podtrzymywanie połączenia.
  • Pakiety adresów prywatnych (np. 192.168.x.x) widoczne na WAN bez szyfrowania: Alarm! Błąd konfiguracji (brak przechwycenia przez politykę).
Narzędzie Packet Sniffer (Inspektor pakietów): Wbudowane w system operacyjny routera narzędzie do przechwytywania surowych ramek sieciowych w czasie rzeczywistym i ich eksportu do analizatorów protokołów takich jak Wireshark.
Slide 28

Diagnostyka złożonych problemów z zestawianiem i stabilnością tuneli IPsec wymaga od inżyniera sieciowego biegłości w posługiwaniu się wyspecjalizowanymi narzędziami diagnostycznymi. Ze względu na to, że pakiety IPsec podlegają szyfrowaniu, tradycyjne narzędzia weryfikacji warstwy wyższej (np. proste testy aplikacji) dostarczają znikomych informacji o przyczynach awarii. Szczegółowe informacje normatywne i techniczne publikuje Analizator pakietów Wireshark.

W systemie MikroTik RouterOS podstawowym punktem wyjścia jest inspekcja tablicy skojarzeń bezpieczeństwa za pomocą polecenia /ip ipsec installed-sa print. W tabeli tej administrator weryfikuje obecność aktywnych rekordów SA dla obu kierunków transmisji. Kluczowym wskaźnikiem jest licznik bajtów i pakietów (current-bytes, current-packets). Jeżeli licznik w jednym kierunku rośnie, a w przeciwnym wynosi zero, wskazuje to na problem asymetrii routingu, blokadę zapory na routerze zdalnym lub niepoprawną regułę NAT-Exemption.

Niezwykle potężnym narzędziem jest wbudowany Packet Sniffer (/tool sniffer). Umożliwia on bezpośrednie przechwytywanie ruchu na fizycznym interfejsie WAN oraz strumieniowanie surowych pakietów do zewnętrznego programu Wireshark na stacji administratora za pomocą protokołu TZSP. W analizatorze Wireshark inżynier może precyzyjnie zaobserwować sekwencję wymiany komunikatów IKE na porcie UDP 500/4500 oraz zweryfikować przepływ zaszyfrowanych pakietów ESP.

Dodatkowo niezastąpionym źródłem wiedzy są szczegółowe logi systemowe. Włączenie dedykowanego tematu logowania dla podsystemu IPsec (/system logging add topics=ipsec,!packet action=memory) pozwala na bieżące śledzenie komunikatów negocjacyjnych, inspekcję proponowanych algorytmów oraz natychmiastowe wychwytywanie rozbieżności w konfiguracji fazy 1 i fazy 2.

Wyjaśnienie skrótów użytych na slajdzie:
SA - Security Association - Skojarzenie bezpieczeństwa w tablicy SAD.
TZSP - Tazmen Sniffer Protocol - Protokół hermetyzacji przechwyconych pakietów przesyłanych do Wiresharka.
ESP - Encapsulating Security Payload - Protokół szyfrowania danych IPsec.
IKE - Internet Key Exchange - Protokół negocjacji kluczy.
WAN - Wide Area Network - Publiczny interfejs transmisyjny poddawany inspekcji.

29/40 Nowoczesny standard IKEv2
Analiza usprawnień architektonicznych, odporności na ataki oraz zaawansowanych funkcji protokołu IKEv2 zdefiniowanego w RFC 7296.
  • Następca IKEv1, oferujący większą szybkość, niezawodność i odporność na błędy.
  • Wsparcie dla MOBIKE: Pozwala na zachowanie aktywnego tunelu przy zmianie adresu IP klienta (np. płynne przejście z mobilnego Wi-Fi na LTE).
  • Zredukowana liczba pakietów niezbędnych do nawiązania bezpiecznej sesji.
  • Standard natywnie wspierany we wszystkich nowoczesnych systemach (Windows, macOS, iOS).
  • Obecnie traktowany jako "złoty standard" dla rozwiązań IPSec.
Internet Key Exchange version 2 (IKEv2): Zoptymalizowany standard IETF (RFC 7296) zastępujący protokół IKEv1, redukujący liczbę komunikatów negocjacyjnych, wprowadzający natywną obsługę mobilności MOBIKE oraz wbudowane mechanizmy ochrony przed atakami DoS.
Slide 29

Wieloletnie doświadczenia eksploatacyjne z klasycznym protokołem IKEv1 ujawniły szereg jego istotnych wad: nadmierną złożoność negocjacji, dużą liczbę wymienianych pakietów (od 6 do 9 w zależności od trybu), podatność na ataki typu odmowa usługi (DoS) oraz brak natywnego wsparcia dla urządzeń mobilnych zmieniających adresację IP. W odpowiedzi na te wyzwania organizacja IETF opracowała od podstaw całkowicie nowy standard - IKEv2, opublikowany w dokumencie RFC 7296 (aktualizującym RFC 4306). Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 7296 (Specyfikacja IKEv2).

Najbardziej widoczną innowacją w IKEv2 jest radykalne uproszczenie procesu negocjacji. Cała procedura zestawiania bezpiecznego tunelu została zredukowana do wymiany zaledwie czterech pakietów (dwóch par żądanie-odpowiedź). Pierwsza para, zwana wymianą IKE_SA_INIT, odpowiada za negocjację polityk bezpieczeństwa i wymianę kluczy Diffie-Hellmana. Druga para, zwana IKE_AUTH, przesyła zaszyfrowane dane tożsamości, przeprowadza uwierzytelnienie i od razu instaluje pierwsze skojarzenie tunelu danych (Child SA).

W architekturze IKEv2 zaimplementowano zaawansowane mechanizmy obronne przed atakami DoS wykorzystującymi fałszowanie adresów IP (IP Spoofing). W warunkach wysokiego obciążenia serwer może zażądać od klienta odesłania kryptograficznego ciasteczka (Cookie) przed zaalokowaniem struktur pamięciowych dla wymiany Diffie-Hellmana, co skutecznie chroni zasoby procesora przed wyczerpaniem.

Kolejnym rewolucyjnym rozszerzeniem protokołu IKEv2 jest standard MOBIKE (IKEv2 Mobility and Multihoming Protocol, RFC 4555). MOBIKE pozwala stacji roboczej lub smartfonowi na dynamiczną zmianę adresu IP (np. podczas przejścia z firmowej sieci Wi-Fi na łącze komórkowe LTE/5G) bez konieczności zrywania i ponownego negocjowania tunelu IPsec. Pakiety są płynnie przekierowywane na nowy adres, zapewniając nieprzerwaną ciągłość sesji aplikacyjnych.

Wyjaśnienie skrótów użytych na slajdzie:
IKEv2 - Internet Key Exchange version 2 - Nowoczesny protokół negocjacji kluczy dla IPsec.
MOBIKE - IKEv2 Mobility and Multihoming Protocol - Standard bezprzerwowego roamingu i zmiany adresacji w IPsec.
DoS - Denial of Service - Atak sieciowy mający na celu przeciążenie i zablokowanie usług serwera.
SA - Security Association - Skojarzenie bezpieczeństwa w architekturze IPsec.
RFC - Request for Comments - Oficjalny standard publikowany przez IETF.

30/40 Wymuszanie IKEv2 w systemie RouterOS
Instruktaż konfiguracji nowoczesnego serwera VPN opartego na protokole IKEv2 z uwierzytelnianiem EAP w systemie MikroTik RouterOS.
  • Starsze wersje mogą domyślnie używać IKEv1.
  • Aby wymusić nowszy standard: W menu /ip ipsec peer wybieramy exchange-mode=ike2.
  • Konfiguracja pod system Windows wymaga poprawnych certyfikatów maszynowych lub zaawansowanej autoryzacji EAP.
  • Mimo wyższej trudności początkowej konfiguracji, IKEv2 oferuje najlepszą stabilność pracy.
Uwierzytelnianie EAP w IKEv2 (IKEv2 EAP Authentication): Zintegrowana w IKEv2 metoda uwierzytelniania użytkownika za pomocą nazwy i hasła (EAP-MSCHAPv2) chroniona asymetrycznym certyfikatem serwera, eliminująca potrzebę dystrybucji kluczy współdzielonych PSK.
Slide 30

W systemie MikroTik RouterOS obsługa protokołu IKEv2 jest w pełni zintegrowana z podsystemem IPsec. Ze względów bezpieczeństwa oraz wydajności nowoczesne wytyczne inżynierskie zalecają całkowitą rezygnację ze starszego protokołu IKEv1 na rzecz wymuszenia IKEv2, w szczególności w scenariuszach zdalnego dostępu dla pracowników mobilnych. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 4555 (Rozszerzenie IKEv2 MOBIKE).

Konfigurację rozpoczyna się od utworzenia węzła peer w gałęzi /ip ipsec peer add name=peer-ike2 passive=yes exchange-mode=ike2 profile=profile-modern. Ustawienie parametru exchange-mode=ike2 bezwzględnie odrzuca próby nawiązania sesji za pomocą przestarzałego standardu IKEv1. Flaga passive=yes oznacza, że router oczekuje na inicjalizację połączenia ze strony zdalnych klientów.

W przypadku klientów mobilnych łączących się z systemów Windows, macOS lub urządzeń mobilnych standardem branżowym jest konfiguracja tożsamości z uwierzytelnianiem EAP: /ip ipsec identity add peer=peer-ike2 auth-method=eap-mschapv2 certificate=Server-Cert generate-policy=port-strict mode-config=cfg-client. W modelu tym serwer legitymuje się zaufanym certyfikatem SSL/TLS (co chroni klienta przed podszywaniem się pod bramę), natomiast użytkownik loguje się swoim indywidualnym loginem i hasłem.

Parametr mode-config pozwala na automatyczne przekazanie stacji roboczej adresu IP z dedykowanej puli, masek podsieci oraz adresów serwerów DNS (odpowiednik konfiguracji DHCP wewnątrz tunelu IPsec). Wdrożenie czystego IKEv2 z uwierzytelnianiem EAP zapewnia najwyższy możliwy poziom bezpieczeństwa kryptograficznego, eliminuje podatności kluczy PSK oraz gwarantuje natywną zgodność z nowoczesnymi systemami operacyjnymi.

Wyjaśnienie skrótów użytych na slajdzie:
IKEv2 - Internet Key Exchange version 2 - Nowoczesny protokół negocjacji sesji IPsec.
EAP - Extensible Authentication Protocol - Rozszerzalny standard uwierzytelniania w sieciach IP.
DNS - Domain Name System - System nazw domenowych przekazywany klientom w mode-config.
CLI - Command Line Interface - Interfejs tekstowy wiersza poleceń RouterOS.
PSK - Pre-Shared Key - Współdzielony klucz statyczny zastępowany przez EAP.

31/40 Bezpośrednie porównanie: SSTP oraz L2TP/IPSec
Zestawienie komparatywne protokołów SSTP oraz L2TP/IPSec pod kątem wydajności, podatności na blokady zaporowe i złożoności wdrożeniowej.
  • SSTP:
    • + Skutecznie omija większość blokad sieciowych (HTTPS).
    • + Minimalna konfiguracja na kliencie Windows.
    • - Duży narzut protokołu TCP (niższa prędkość przy dużym ruchu).
  • L2TP/IPSec:
    • + Wysoka wydajność dzięki protokołowi UDP.
    • + Bardzo szerokie wsparcie na starszych i nowych urządzeniach.
    • - Podatny na blokady portów UDP w sieciach publicznych.
    • - Możliwe problemy konfiguracyjne z podwójnym NAT.
Analiza komparatywna protokołów VPN (VPN Protocol Tradeoff Analysis): Inżynierskie porównanie cech funkcjonalnych, charakterystyk wydajnościowych oraz odporności na zakłócenia transmisyjne różnych protokołów tunelujących w celu optymalnego doboru technologii do wymagań środowiskowych.
Slide 31

Wybór pomiędzy protokołami SSTP a L2TP/IPSec stanowi jeden z klasycznych dylematów architektonicznych przed jakimi staje projektant korporacyjnych sieci zdalnego dostępu. Obie technologie oferują silne mechanizmy kryptograficzne oraz natywne wsparcie w systemach operacyjnych Microsoft Windows, jednak różnią się diametralnie zachowaniem w środowiskach transmisyjnych. Szczegółowe informacje normatywne i techniczne publikuje Portal Ministerstwa Cyfryzacji Gov.pl.

Pod względem przepuszczalności przez zapory sieciowe i translatory NAT bezapelacyjnym zwycięzcą jest protokół SSTP. Operując na standardowym porcie TCP 443, SSTP jest w stanie nawiązać połączenie w niemal każdych warunkach, skutecznie omijając restrykcje sieci publicznych i hotelowych. Protokół L2TP/IPSec wymaga natomiast drożności portów UDP 500, UDP 4500 oraz protokołu IP 50 (ESP), przez co jest regularnie blokowany przez zapory ogniowe w niekontrolowanych sieciach dostępowych.

Z kolei pod względem wydajności transmisyjnej oraz opóźnień zdecydowaną przewagę wykazuje protokół L2TP/IPSec. Wykorzystanie protokołu bezpołączeniowego UDP eliminuje zjawisko TCP-over-TCP Meltdown, zapewniając płynną transmisję ruchu w czasie rzeczywistym (telefonia VoIP, wideokonferencje, strumieniowanie). Ponadto szyfrowanie ESP w L2TP/IPSec może być bezpośrednio odciążane przez układy akceleracji sprzętowej procesora, podczas gdy SSTP obciąża rdzenie ogólnego przeznaczenia obsługą podwójnego stosu TCP.

W nowoczesnej praktyce inżynierskiej rekomenduje się podejście hybrydowe: wdrożenie standardu L2TP/IPSec (lub czystego IKEv2) jako podstawowego, wysokowydajnego kanału komunikacji dla pracowników mobilnych oraz jednoczesne utrzymanie usługi SSTP jako zapasowego rozwiązania awaryjnego (Failover VPN), uruchamianego w sytuacjach, gdy pracownik znajduje się w sieci blokującej pakiety UDP.

Wyjaśnienie skrótów użytych na slajdzie:
SSTP - Secure Socket Tunneling Protocol - Protokół tunelowania warstwy 2 w kanale TLS 443.
L2TP - Layer 2 Tunneling Protocol - Protokół tunelowania warstwy 2.
IPsec - Internet Protocol Security - Kryptograficzny standard bezpieczeństwa warstwy sieciowej.
VoIP - Voice over Internet Protocol - Transmisja głosu przez sieci pakietowe IP wrażliwa na jitter.
UDP - User Datagram Protocol - Bezpołączeniowy protokół transportowy.

32/40 Diagnostyka: Błąd "Phase 2 state failed"
Metodyka diagnostyki i eliminacji błędów negocjacji Fazy 2 w protokole IPsec na przykładzie błędu 'Phase 2 state failed'.
  • Komunikaty błędu: "no phase2 proposals selected" lub "failed to get valid proposal".
  • Najczęstsza przyczyna: Rozbieżność w doborze algorytmów szyfrowania (Proposal) między stronami.
  • Przykład: Router A oferuje AES-256, natomiast Router B oczekuje AES-128.
  • Konieczna weryfikacja zgodności parametrów w menu: /ip ipsec proposal po obu stronach.
Błąd negocjacji Fazy 2 (IPsec Phase 2 Negotiation Failure): Stan błędu sygnalizowany przez demona IKE informujący o pomyślnym zestawieniu kanału kontrolnego ISAKMP SA, lecz niemożności uzgodnienia propozycji kryptograficznej lub selektorów ruchu dla tunelu danych.
Slide 32

W trakcie uruchamiania i eksploatacji tuneli IPsec inżynierowie najczęściej napotykają błędy związane z załamaniem negocjacji Fazy 2, rejestrowane w dzienniku zdarzeń RouterOS komunikatem 'phase2 negotiation failed' lub 'no phase2 proposal chosen'. Zrozumienie natury tego błędu pozwala na błyskawiczne zlokalizowanie rozbieżności w konfiguracji. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 3602 (Algorytm AES-CBC w IPsec).

Pojawienie się tego komunikatu niesie ze sobą kluczową informację diagnostyczną: Faza 1 negocjacji IKE zakończyła się pełnym sukcesem! Oznacza to, że adresy IP punktów końcowych są osiągalne, klucze współdzielone PSK (lub certyfikaty) są poprawne, a zapory ogniowe przepuszczają pakiety UDP 500/4500. Problem tkwi wyłącznie w parametrach zdefiniowanych dla tunelu danych.

Pierwszą potencjalną przyczyną jest niedopasowanie propozycji kryptograficznych (/ip ipsec proposal). Jeżeli router lokalny proponuje szyfrowanie AES-256-GCM z funkcją skrótu SHA256, a router zdalny akceptuje wyłącznie AES-CBC z funkcją SHA1, węzły nie będą w stanie znaleźć wspólnego mianownika kryptograficznego i negocjacja zostanie natychmiast zerwana.

Drugą, jeszcze powszechniejszą przyczyną jest brak zgodności selektorów ruchu w politykach bezpieczeństwa (/ip ipsec policy). Router lokalny oczekuje szyfrowania ruchu pomiędzy podsieciami 192.168.10.0/24 a 192.168.20.0/24. Jeżeli na routerze zdalnym administrator popełnił błąd pisarski w masce podsieci (np. wpisał 192.168.20.0/25) lub zapomniał o odwróceniu relacji źródło/cel, polityki nie dopasują się i Faza 2 zakończy się fiaskiem.

Wyjaśnienie skrótów użytych na slajdzie:
IKE - Internet Key Exchange - Protokół negocjacji sesji IPsec.
SA - Security Association - Skojarzenie bezpieczeństwa w tablicy SAD.
ESP - Encapsulating Security Payload - Protokół szyfrowania danych w warstwie IP.
PFS - Perfect Forward Secrecy - Opcjonalna wymiana kluczy DH w Fazie 2.
CLI - Command Line Interface - Interfejs wiersza poleceń RouterOS.

33/40 Diagnostyka: Błąd "Peer not reachable"
Analiza przyczyn występowania błędu braku osiągalności węzła partnerskiego 'Peer not reachable' oraz procedury weryfikacji Fazy 1 IKE.
  • Cykliczny komunikat w logach: "retransmit phase1...".
  • Przyczyna: Pakiety negocjacyjne UDP 500 nie docierają do celu.
  • Zweryfikuj poprawność adresu IP partnera oraz reguły firewalla po stronie odbiorcy.
  • Należy upewnić się, czy dostawca usług internetowych nie narzuca blokad na ruch typu VPN.
  • Użyj wbudowanego narzędzia Sniffer, aby potwierdzić obecność pakietów na porcie 500.
Błąd osiągalności węzła (Peer Not Reachable Failure): Stan błędu wskazujący na całkowity brak możliwości wymiany komunikatów sygnalizacyjnych IKE na porcie UDP 500 z powodu awarii łącza, blokady zapory lub błędnej konfiguracji adresu docelowego.
Slide 33

Komunikat 'peer not reachable' lub cykliczne wpisy w dzienniku zdarzeń o treści 'retransmitting packet' sygnalizują fundamentalną awarię na samym początku procesu negocjacji tunelu IPsec. Wskazuje to, że proces jądra wysyła inicjujący pakiet IKE_SA_INIT lub Main Mode na porcie UDP 500, lecz w zdefiniowanym czasie nie otrzymuje żadnej odpowiedzi od zdalnego punktu końcowego. Szczegółowe informacje normatywne i techniczne publikuje Narodowa baza podatności NVD NIST.

W pierwszej kolejności inżynier sieciowy powinien zweryfikować poprawność konfiguracji adresu docelowego w obiekcie peer (/ip ipsec peer). Prosta pomyłka pisarska w publicznym adresie IP zdalnego routera lub niepoprawne rozwiązanie nazwy domenowej FQDN w systemie DNS natychmiast uniemożliwia nawiązanie kontaktu.

Drugim krokiem diagnostycznym jest zbadanie osiągalności sieciowej w warstwie 3 za pomocą narzędzi ping oraz traceroute. Jeżeli zdalny adres publiczny odpowiada na pakiety ICMP, należy sprawdzić konfigurację zapory ogniowej na routerze zdalnym oraz u pośredniczących dostawców Internetu. Brak reguły zezwalającej na ruch UDP 500 w łańcuchu wejściowym zapory skutkuje cichym porzuceniem pakietu negocjacyjnego.

Trzecim źródłem problemu może być niesymetryczna konfiguracja tożsamości. Jeżeli router zdalny posiada zmienny adres IP (np. dynamiczne łącze LTE) lub został skonfigurowany w trybie pasywnym bez wpisu odpowiadającego naszemu adresowi publicznemu, odrzuci pakiet bez wysyłania odpowiedzi. Skutecznym narzędziem weryfikacji jest analiza zrzutu pakietów za pomocą narzędzia Packet Sniffer na publicznym interfejsie WAN.

Wyjaśnienie skrótów użytych na slajdzie:
IKE - Internet Key Exchange - Protokół negocjacji sesji na porcie UDP 500.
ICMP - Internet Control Message Protocol - Protokół komunikatów kontrolnych używany przez narzędzie ping.
FQDN - Fully Qualified Domain Name - Pełna nazwa domenowa bramy VPN.
WAN - Wide Area Network - Interfejs podłączony do sieci publicznej dostawcy Internetu.
DNS - Domain Name System - System nazw domenowych tłumaczący nazwy na adresy IP.

34/40 Bezpieczeństwo: dobór algorytmów kryptograficznych
Przegląd aktualnych standardów kryptograficznych rekomendowanych przez instytucje normalizacyjne dla bezpiecznych wdrożeń IPsec.
  • Zgodnie z formalnymi zaleceniami agencji NIST SP 800-131A oraz BSI TR-02102 należy stosować następujące wytyczne:
  • Algorytmy szyfrowania:
    • Kategorycznie zakazane: DES, 3DES, RC4 oraz tryby CBC bez mechanizmu HMAC.
    • Standard zalecany: Szyfry AEAD (np. AES-128-GCM, AES-256-GCM) gwarantujące jednoczesne szyfrowanie i integralność z minimalnym narzutem procesora.
  • Funkcje skrótu i uwierzytelniania:
    • Wycofane: MD5 oraz SHA-1 (podatności na kolizje skrótów).
    • Rekomendowane: Rodzina SHA-2 (SHA-256, SHA-384, SHA-512).
  • Grupy Diffie-Hellmana (DH):
    • Wycofane: Grupa 1 (768 bit), Grupa 2 (1024 bit), Grupa 5 (1536 bit).
    • Rekomendowane: Minimum Grupa 14 (modp 2048 bit) oraz grupy eliptyczne ECDH: Grupa 19 (256-bit ECP) i Grupa 20 (384-bit ECP).
Utwardzanie kryptograficzne (Cryptographic Hardening): Proces eliminacji przestarzałych algorytmów szyfrowania i funkcji skrótu na rzecz sprawdzonych standardów gwarantujących odporność na współczesną kryptoanalizę matematyczną i sprzętową.
Slide 34

Właściwy dobór algorytmów kryptograficznych stanowi fundament bezpieczeństwa wdrożenia sieci VPN opartej na standardzie IPsec. Stosowanie silnych protokołów transportowych nie chroni organizacji przed kompromitacją, jeżeli w konfiguracji profili pozostawiono przestarzałe, złamane algorytmy szyfrowania lub podatne funkcje skrótu. Szczegółowe informacje normatywne i techniczne publikuje Niemiecki Federalny Urząd Bezpieczeństwa Informacji (BSI).

Zgodnie z oficjalnymi wytycznymi wiodących agencji cyberbezpieczeństwa - w tym amerykańskiego instytutu NIST (publikacja SP 800-131A) oraz niemieckiego urzędu BSI (wytyczne techniczne BSI TR-02102) - z konfiguracji produkcyjnych należy bezwzględnie usunąć szyfry symetryczne DES, 3DES oraz algorytm strumieniowy RC4. Szyfry te posiadają zbyt krótkie klucze efektywne i są podatne na złamanie metodami brute-force.

W sferze integralności danych kategorycznie zakazuje się stosowania funkcji skrótu MD5 oraz SHA-1, w których udowodniono istnienie praktycznych kolizji kryptograficznych (w tym projekt badawczy SHAttered). Standardem branżowym jest rodzina funkcji SHA-2, w szczególności SHA-256, SHA-384 oraz SHA-512. Podobnie w doborze grup Diffie-Hellmana (DH) należy całkowicie wycofać grupy poniżej 14 (minimalna zalecana długość modułu to 2048 bitów), preferując nowoczesne grupy oparte na krzywych eliptycznych ECDH (grupy 19, 20 i 21).

Absolutnym standardem branżowym w doborze algorytmów szyfrowania dla protokołu ESP stał się algorytm Advanced Encryption Standard w trybie Galois/Counter Mode (AES-GCM z kluczami 128 lub 256 bitów). Jako szyfr typu AEAD zapewnia on jednoczesne szyfrowanie i kryptograficzne uwierzytelnianie danych z najwyższą odpornością matematyczną oraz optymalnym wykorzystaniem sprzętowych instrukcji kryptograficznych procesorów.

Wyjaśnienie skrótów użytych na slajdzie:
AES-GCM - Advanced Encryption Standard Galois Counter Mode - Zintegrowany szyfr blokowy AEAD zapewniający poufność i integralność.
NIST - National Institute of Standards and Technology - Amerykański instytut standaryzacji definiujący normy kryptograficzne.
BSI - Bundesamt für Sicherheit in der Informationstechnik - Niemiecki Federalny Urząd Bezpieczeństwa Informacji.
ECDH - Elliptic Curve Diffie-Hellman - Wymiana kluczy oparta na kryptografii krzywych eliptycznych.
AEAD - Authenticated Encryption with Associated Data - Nowoczesny tryb szyfrowania uwierzytelnionego.

35/40 Akceleracja sprzętowa (hardware AES)
Przedstawienie roli sprzętowych silników kryptograficznych oraz instrukcji procesora w optymalizacji przepustowości tuneli IPsec.
  • Szyfrowanie danych to proces silnie obciążający jednostkę centralną (CPU).
  • Nowoczesne routery MikroTik (np. hEX, CCR) dysponują procesorami z instrukcjami AES-NI (Hardware Acceleration).
  • Wpływ na wydajność:
    • Przetwarzanie programowe: 30-50 Mbps przy pełnym obciążeniu CPU.
    • Wsparcie sprzętowe: 500-1000 Mbps przy znikomym obciążeniu CPU.
  • Warunek działania: Wybór algorytmów wspieranych przez dany chip (zazwyczaj AES-CBC lub AES-GCM).
Akceleracja sprzętowa kryptografii (Hardware Crypto Acceleration): Wykorzystanie dedykowanych układów scalonych (ASIC) lub rozszerzeń zestawu instrukcji procesora (np. AES-NI) do wykonywania operacji kryptograficznych z pominięciem ogólnych cykli obliczeniowych CPU.
Slide 35

Szyfrowanie i deszyfrowanie strumieni pakietów sieciowych z prędkościami gigabitowymi wymaga wykonywania miliardów intensywnych operacji matematycznych na sekundę. W przypadku routerów realizujących operacje kryptograficzne wyłącznie programowo za pomocą standardowych instrukcji procesora ogólnego przeznaczenia (Software Encryption), obciążenie CPU gwałtownie wzrasta do 100%, powodując drastyczne ograniczenie przepustowości tunelu oraz wysokie opóźnienia. Szczegółowe informacje normatywne i techniczne publikuje Oficjalna dokumentacja jądra Linux.

W celu przezwyciężenia tej bariery współczesne platformy sieciowe (w tym urządzenia MikroTik serii Cloud Core Router CCR oraz nowsze modele serii hEX i RB) integrują wyspecjalizowane sprzętowe silniki kryptograficzne. W architekturze x86 oraz nowoczesnych układach ARM standardem są dedykowane instrukcje procesora wspomagające przetwarzanie szyfru AES (zestaw instrukcji Intel AES-NI oraz ARMv8 Cryptography Extensions).

Dzięki akceleracji sprzętowej złożone rundy przekształceń szyfru AES oraz operacje mnożenia w ciałach Galois dla trybu GCM są wykonywane w dedykowanych blokach logicznych krzemu w pojedynczych cyklach zegara. Pozwala to na osiąganie niemal pełnej prędkości fizycznych łączy światłowodowych (Wire-Speed Encryption) przy obciążeniu procesora głównego routera na poziomie zaledwie kilku procent.

W systemie MikroTik RouterOS administrator może w prosty sposób zweryfikować, czy aktywne skojarzenie IPsec korzysta z przyspieszenia sprzętowego. W poleceniu /ip ipsec installed-sa print akcelerowane sprzętowo wpisy SA są oznaczane charakterystyczną flagą H (Hardware). Brak flagi H oznacza wykonywanie operacji programowo i sygnalizuje konieczność weryfikacji doboru algorytmów pod kątem możliwości danego układu SoC.

Wyjaśnienie skrótów użytych na slajdzie:
AES-NI - Advanced Encryption Standard New Instructions - Zestaw instrukcji sprzętowych procesora wspomagający szyfrowanie AES.
ASIC - Application-Specific Integrated Circuit - Dedykowany układ scalony zoptymalizowany pod kątem operacji sieciowych.
CPU - Central Processing Unit - Główny procesor obliczeniowy urządzenia.
SoC - System on a Chip - Zintegrowany jednoukładowy system mikroprocesorowy.
CCR - Cloud Core Router - Linia wysokowydajnych routerów wielordzeniowych firmy MikroTik.

36/40 Scenariusze praktyczne: dobór rozwiązania
Przewodnik decyzyjny dla projektantów sieci dotyczący właściwego doboru technologii VPN w zależności od wymagań środowiskowych i architektury sieci.
  • Dobór zależy od wymagań środowiskowych:
  • Wsparcie dla użytkowników mobilnych (hotele): Wybierz SSTP - gwarantuje największą szansę na nawiązanie połączenia.
  • Stacje robocze IT (mieszane systemy): L2TP/IPSec lub IKEv2 - oferują spójny poziom bezpieczeństwa.
  • Połączenia między oddziałami firmy: Czysty IPSec Tunnel Mode - zapewnia bezkonkurencyjną wydajność transferu.
Macierz decyzyjna VPN (VPN Architecture Decision Matrix): Zbiór kryteriów inżynierskich uwzględniających topologię sieci, ograniczenia zapór ogniowych, charakterystykę klientów oraz wymagania wydajnościowe, determinujący optymalny wybór protokołu VPN.
Slide 36

W praktyce projektowania infrastruktury teleinformatycznej nie istnieje jedno, uniwersalne rozwiązanie VPN, które sprawdziłoby się optymalnie we wszystkich możliwych scenariuszach wdrożeniowych. Doświadczony inżynier sieciowy musi dokonać świadomego wyboru technologii, analizując kompromisy pomiędzy bezpieczeństwem, przepustowością, odpornością na blokady a prostotą zarządzania. Szczegółowe informacje normatywne i techniczne publikuje Agencja Unii Europejskiej ds. Cyberbezpieczeństwa (ENISA).

W scenariuszu łączenia stałych lokalizacji przedsiębiorstwa (oddziały korporacji, centra przetwarzania danych) bezwzględnym standardem pierwszego wyboru jest czysty tunel IPsec Site-to-Site w trybie tunelowym (lub architektura GRE over IPsec w przypadku konieczności uruchomienia routingu dynamicznego OSPF). Zapewnia on maksymalną wydajność, pełną akcelerację sprzętową oraz transparentność dla urządzeń w sieciach LAN.

W scenariuszach zdalnego dostępu dla pracowników mobilnych kluczowe znaczenie ma charakterystyka środowiska sieciowego użytkownika końcowego. Jeżeli pracownicy łączą się głównie z domowych łączy szerokopasmowych lub korzystają z łączności komórkowej LTE/5G, optymalnym wyborem jest standard IKEv2 z uwierzytelnianiem EAP i obsługą technologii MOBIKE, gwarantujący najwyższy poziom bezpieczeństwa i bezprzerwowy roaming.

Z kolei dla pracowników często podróżujących i korzystających z restrykcyjnych sieci hotelowych, kawiarnianych lub sieci publicznych na lotniskach, niezastąpionym rozwiązaniem pozostaje protokół SSTP. Zdolność SSTP do bezproblemowego omijania zapór sieciowych za pośrednictwem portu TCP 443 gwarantuje ciągłość biznesową w warunkach, w których pakiety UDP protokołów IPsec są bezwzględnie blokowane.

Wyjaśnienie skrótów użytych na slajdzie:
IPsec - Internet Protocol Security - Standard kryptograficzny warstwy sieciowej.
SSTP - Secure Socket Tunneling Protocol - Protokół VPN operujący w kanale TLS 443.
IKEv2 - Internet Key Exchange version 2 - Nowoczesny protokół negocjacji sesji z technologią MOBIKE.
OSPF - Open Shortest Path First - Hierarchiczny protokół routingu dynamicznego stanu łącza.
GRE - Generic Routing Encapsulation - Protokół enkapsulacji warstwy sieciowej.

37/40 Podsumowanie kroków w RouterOS
Syntetyczne zestawienie procedur konfiguracyjnych w systemie MikroTik RouterOS dla protokołów SSTP, L2TP/IPSec oraz IPsec Site-to-Site.
  • 1. Przygotowanie profilu PPP (zakresy IP, serwery DNS).
  • 2. Definicja kont użytkowników (PPP Secrets).
  • 3. Aktywacja serwera SSTP lub L2TP z wymuszeniem IPSec.
  • 4. Konfiguracja zapory (INPUT): odblokowanie portów 443, 500, 4500 oraz protokołu 50.
  • 5. Opcjonalnie: Prawidłowe wdrożenie certyfikatów SSL dla usługi SSTP.
Procedura wdrożeniowa RouterOS (RouterOS Deployment Workflow): Ustrukturyzowana sekwencja poleceń konfiguracyjnych obejmująca zarządzanie profilami PPP, certyfikatami X.509, tożsamościami IPsec oraz regułami filtracji zapory ogniowej.
Slide 37

Wdrożenie zaawansowanych usług VPN w systemie MikroTik RouterOS wymaga zachowania rygorystycznej dyscypliny inżynierskiej i sekwencyjnego wykonywania poszczególnych etapów konfiguracji. Pominięcie elementu przygotowawczego (np. brak puli adresowej lub brak reguły zapory) jest najczęstszą przyczyną niepowodzenia całego projektu. Szczegółowe informacje normatywne i techniczne publikuje Zespół CSIRT KNF.

Dla protokołu SSTP procedura obejmuje: wygenerowanie i podpisanie certyfikatu urzędu CA oraz certyfikatu serwera z poprawnym polem CN/SAN, utworzenie profilu PPP z adresacją i serwerami DNS, aktywację serwera SSTP ze wskazaniem certyfikatu, odblokowanie portu TCP 443 w łańcuchu input zapory oraz wyeksportowanie certyfikatu CA dla stacji roboczych.

Dla protokołu L2TP/IPSec sekwencja konfiguracyjna obejmuje: zdefiniowanie profilu PPP i bazy sekretów, włączenie serwera L2TP z parametrem use-ipsec=yes i silnym kluczem ipsec-secret, oraz skonfigurowanie reguł zapory dla portów UDP 500, UDP 4500, UDP 1701 i protokołu IP 50 (ESP).

Dla czystego tunelu IPsec Site-to-Site procedura wymaga: zdefiniowania profilu Fazy 1 (z grupą DH co najmniej 14), utworzenia obiektu peer z adresem zdalnym, zdefiniowania tożsamości z kluczem PSK, przygotowania propozycji Fazy 2 (AES-GCM), utworzenia polityki IPsec w trybie tunelowym ze wskazaniem selektorów ruchu oraz bezwzględnego dodania reguły wyjątku NAT-Exemption na szczycie tablicy NAT.

Wyjaśnienie skrótów użytych na slajdzie:
SSTP - Secure Socket Tunneling Protocol - Protokół tunelowania VPN w kanale TLS.
L2TP - Layer 2 Tunneling Protocol - Protokół tunelowania warstwy 2.
IPsec - Internet Protocol Security - Standard bezpieczeństwa warstwy IP.
PPP - Point-to-Point Protocol - Podsystem zarządzania sesjami i poświadczeniami.
CLI - Command Line Interface - Wiersz poleceń RouterOS.

38/40 Podsumowanie konfiguracji stacji Windows
Zestawienie krytycznych ustawień systemowych i rejestrowych stacji roboczych Windows dla zapewnienia stabilnej łączności VPN.
  • Kwestie krytyczne: Jawny wybór "Typu VPN" zamiast trybu automatycznego.
  • Konieczność modyfikacji rejestru (DWORD: AssumeUDP...) w specyficznych konfiguracjach sieciowych.
  • Zapewnienie zaufania systemowego do certyfikatu CA (dla usługi SSTP).
  • Wykorzystanie techniki Split Tunneling dla zachowania optymalnej prędkości połączenia internetowego klienta.
Profil klienta VPN Windows (Windows VPN Connection Profile): Zestaw parametrów sieciowych, poświadczeń i reguł kryptograficznych w systemie Windows determinujący sposób nawiązywania połączenia tunelowego z bramą korporacyjną.
Slide 38

Pomyślne wdrożenie korporacyjnej sieci VPN zależy w równej mierze od poprawnej konfiguracji serwera brzegowego, jak i od właściwego przygotowania stacji roboczych użytkowników końcowych. System operacyjny Windows posiada rozbudowany, lecz wymagający precyzyjnej konfiguracji stos obsługi wirtualnych sieci prywatnych. Szczegółowe informacje normatywne i techniczne publikuje Urząd Ochrony Danych Osobowych.

W przypadku protokołu SSTP absolutnym warunkiem sukcesu jest poprawna instalacja publicznego certyfikatu urzędu CA w magazynie Zaufane główne urzędy certyfikacji oraz bezwzględna zgodność nazwy wpisywanej w polu adresu serwera z polem Common Name certyfikatu. W razie problemów z serwerami unieważnień należy zaaplikować wpis rejestru NoCertRevocationCheck.

W przypadku protokołu L2TP/IPSec krytycznym krokiem inżynierskim jest zaaplikowanie w rejestrze wartości AssumeUDPEncapsulationContextOnSendRule = 2 w kluczu PolicyAgent, co eliminuje domyślną blokadę połączeń przez urządzenia NAT. Ponadto we właściwościach zabezpieczeń adaptera należy jawnie wymusić protokół MS-CHAPv2 oraz zaznaczyć opcję wymuszania szyfrowania.

Niezwykle istotnym zagadnieniem organizacyjnym jest właściwe skonfigurowanie routingu na stacji roboczej: podjęcie świadomej decyzji o wdrożeniu pełnego tunelowania (Full Tunneling) dla maksymalnej kontroli nad ruchem pracownika lub dzielonego tunelowania (Split Tunneling) w celu oszczędzania pasma łącza firmowego z wykorzystaniem polecenia Add-VpnConnectionRoute.

Wyjaśnienie skrótów użytych na slajdzie:
SSTP - Secure Socket Tunneling Protocol - Protokół tunelowania VPN przez TLS 443.
L2TP - Layer 2 Tunneling Protocol - Protokół tunelowania warstwy 2 z IPsec.
CA - Certificate Authority - Urząd certyfikacji tożsamości cyfrowej.
NAT - Network Address Translation - Translacja adresów sieciowych.
MS-CHAPv2 - Microsoft Challenge Handshake Authentication Protocol v2 - Protokół uwierzytelniania wzajemnego.

39/40 Kolejny krok: standard OpenVPN
Wprowadzenie do tematyki kolejnego wykładu poświęconego technologii OpenVPN, architekturze SSL/TLS oraz wirtualnym interfejsom TUN/TAP.
  • IPSec oferuje potężne możliwości, ale cechuje go wysoka złożoność.
  • SSTP jest rozwiązaniem optymalnym, lecz zawężonym do ekosystemu Windows.
  • W kolejnej części przeanalizujemy OpenVPN.
  • Standard ten łączy uniwersalność portów SSL ze skrajną elastycznością oraz otwartością kodu.
  • Obecnie najczęściej wybierany standard w środowiskach Open Source i administracji sieci.
Technologia OpenVPN (OpenVPN Protocol): Otwarty, wieloplatformowy standard wirtualnych sieci prywatnych wykorzystujący bibliotekę OpenSSL, protokół TLS do wymiany kluczy oraz wirtualne interfejsy warstwy sieciowej (TUN) lub łącza danych (TAP).
Slide 39

Zrealizowany materiał trzeciej części kursu zaprezentował zaawansowane technologie VPN wbudowane natywnie w komercyjne systemy operacyjne: protokół SSTP firmy Microsoft oraz uniwersalny standard L2TP/IPSec. Mimo ogromnych zalet rozwiązania te posiadają pewne ograniczenia w zakresie elastyczności konfiguracji oraz przenośności na zróżnicowane platformy uniksowe i mobilne. Szczegółowe informacje normatywne i techniczne publikuje Społeczność OpenVPN Community.

Naturalnym kolejnym krokiem w rozwoju kompetencji inżyniera sieciowego jest zapoznanie się ze standardem OpenVPN, który stanowi bezapelacyjnego lidera w świecie oprogramowania open-source. OpenVPN redefiniuje podejście do budowy wirtualnych sieci prywatnych, uniezależniając się od ograniczeń protokołów warstwy jądra na rzecz elastycznej aplikacji przestrzeni użytkownika (User Space).

W ramach kolejnego wykładu studenci poznają zasady działania wirtualnych interfejsów TUN (warstwa 3 - routing IP) oraz TAP (warstwa 2 - mostkowanie ramek Ethernetowych), mechanizmy transportu w protokołach UDP oraz TCP na dowolnie wybranych portach, a także pełną strukturę infrastruktury klucza publicznego opartej na narzędziu Easy-RSA.

Szczegółowej analizie poddane zostaną mechanizmy dynamicznego rozgłaszania tras i parametrów sieciowych (dyrektywa push), integracja z uwierzytelnianiem wieloskładnikowym (MFA), personalizacja konfiguracji klientów (Client Config Dir) oraz praktyczna konfiguracja serwera OpenVPN w systemie Linux oraz MikroTik RouterOS.

Wyjaśnienie skrótów użytych na slajdzie:
OpenVPN - Open Virtual Private Network - Wieloplatformowy standard VPN oparty na OpenSSL.
TUN - Network TUNnel - Wirtualny interfejs sieciowy warstwy 3 modelu OSI.
TAP - Network TAP - Wirtualny interfejs sieciowy warstwy 2 modelu OSI.
SSL - Secure Sockets Layer - Historyczny protokół kryptograficzny zastąpiony przez TLS.
PKI - Public Key Infrastructure - Infrastruktura klucza publicznego zarządzająca certyfikatami.

40/40 Zadania do samodzielnej realizacji
Przedstawienie zakresu zadań laboratoryjnych i projektowych utrwalających praktyczne umiejętności konfiguracji SSTP, L2TP/IPSec oraz IPsec Site-to-Site.
  • 1. Skonfiguruj aktywny serwer L2TP/IPSec i spróbuj uzyskać dostęp z urządzenia mobilnego.
  • 2. Przećwicz proces generowania i podpisywania certyfikatów na potrzeby serwera SSTP.
  • 3. Przeprowadź proces importu certyfikatu CA do systemu Windows i wyeliminuj błąd zaufania.
  • 4. Wykonaj testy wydajnościowe routera porównując tunelowanie nieszyfrowane GRE z tunelem szyfrowanym IPSec - obserwuj statystyki obciążenia procesora.
Laboratorium projektowe VPN (VPN Hands-On Laboratory): Ćwiczenie praktyczne w środowisku wirtualnym lub sprzętowym polegające na samodzielnym zaprojektowaniu, wdrożeniu, zabezpieczeniu i przetestowaniu tuneli komunikacyjnych zgodnie ze specyfikacją techniczną.
Slide 40

Zwieńczeniem trzeciego modułu wykładowego jest zestaw zadań laboratoryjnych przeznaczonych do samodzielnej realizacji przez studentów w środowisku wirtualnym (np. MikroTik Cloud Hosted Router - CHR na platformie GNS3, EVE-NG lub VMware Workstation) oraz na fizycznych routerach laboratoryjnych. Szczegółowe informacje normatywne i techniczne publikuje Polski Komitet Normalizacyjny.

Zadanie pierwsze polega na kompletnym uruchomieniu serwera SSTP na routerze MikroTik: wygenerowaniu lokalnego urzędu CA, wystawieniu i podpisaniu certyfikatu serwerowego z odpowiednią nazwą FQDN, wyeksportowaniu certyfikatu CA i zaimportowaniu go do magazynu zaufanych certyfikatów na stacji Windows, a następnie zestawieniu stabilnego połączenia szyfrowanego.

Zadanie drugie obejmuje wdrożenie serwera L2TP/IPSec z silnym kluczem PSK i uwierzytelnianiem MS-CHAPv2. Studenci zobowiązani są do skonfigurowania reguł zapory sieciowej na styku WAN dla portów UDP 500, UDP 4500, UDP 1701 i protokołu ESP, zaaplikowania korekty rejestru AssumeUDPEncapsulationContextOnSendRule na stacji klienckiej za NAT oraz zweryfikowania obecności flagi akceleracji sprzętowej H w tabeli installed-sa.

Zadanie trzecie, o charakterze zaawansowanym, wymaga zestawienia tunelu IPsec Site-to-Site w trybie tunelowym pomiędzy dwoma wirtualnymi routerami RouterOS. Należy poprawnie skonfigurować węzły peer w oparciu o protokół IKEv2, dobrać nowoczesne algorytmy szyfrowania AES-256-GCM, zdefiniować selektory ruchu dla podsieci LAN obu oddziałów oraz bezbłędnie zaimplementować regułę wyjątku NAT-Exemption, weryfikując poprawność przepływu pakietów za pomocą narzędzia traceroute i analizatora Wireshark.

Wyjaśnienie skrótów użytych na slajdzie:
CHR - Cloud Hosted Router - Wersja systemu MikroTik RouterOS przeznaczona dla środowisk wirtualnych.
SSTP - Secure Socket Tunneling Protocol - Protokół tunelowania warstwy 2 przez TLS.
L2TP - Layer 2 Tunneling Protocol - Protokół tunelowania warstwy 2.
IPsec - Internet Protocol Security - Standard bezpieczeństwa warstwy IP.
GNS3 - Graphical Network Simulator-3 - Środowisko emulacji złożonych sieci teleinformatycznych.