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 OpenVPN: wstęp i charakterystyka
Wprowadzenie do technologii OpenVPN, jej genezy w środowisku open-source oraz roli jako wszechstronnego standardu wirtualnych sieci prywatnych.
  • OpenVPN to standard de facto w świecie protokołów VPN typu otwartego oprogramowania (Open Source).
  • Projekt zainicjowany przez Jamesa Yonana w 2001 roku.
  • W odróżnieniu od IPSec, działa w przestrzeni użytkownika (User Space), co ułatwia jego implementację i przenośność.
  • Bazując na bibliotece OpenSSL, oferuje niezwykle szerokie możliwości kryptograficzne.
  • Dostępny na niemal każdą platformę: Windows, Linux, macOS, Android, iOS oraz systemy wbudowane (MikroTik, Ubiquiti, OpenWRT).
OpenVPN (Open Virtual Private Network): Wieloplatformowy, otwartoźródłowy standard wirtualnych sieci prywatnych stworzony przez Jamesa Yonana w 2001 roku, implementujący szyfrowane tunele warstwy 2 i 3 w oparciu o protokół SSL/TLS i bibliotekę OpenSSL.
Slide 1

Protokół OpenVPN stanowi jeden z najważniejszych kamieni milowych w rozwoju technologii wirtualnych sieci prywatnych. Opracowany w 2001 roku przez Jamesa Yonana jako projekt open-source, powstał w odpowiedzi na rygorystyczne ograniczenia i złożoność ówczesnych implementacji IPsec oraz kompromitację protokołu PPTP. Celem projektu było stworzenie elastycznego, bezpiecznego i łatwego w audycie narzędzia tunelującego. Szczegółowe informacje normatywne i techniczne publikuje Polskie Towarzystwo Informatyczne.

W przeciwieństwie do protokołów operujących wyłącznie w przestrzeni jądra (Kernel Space), OpenVPN został zaprojektowany jako aplikacja działająca w przestrzeni użytkownika (User Space). Do realizacji funkcji kryptograficznych wykorzystuje dojrzałą i powszechnie sprawdzoną bibliotekę OpenSSL, co zapewnia natychmiastowy dostęp do najnowocześniejszych szyfrów blokowych, funkcji skrótu oraz protokołów uzgadniania kluczy TLS.

Kluczowym atutem technologii OpenVPN jest jej absolutna neutralność względem medium transportowego. Może ona operować na dowolnym porcie sieciowym (zarówno w protokole UDP, jak i TCP), co pozwala na omijanie restrykcyjnych zapór ogniowych poprzez podszywanie się pod standardowy ruch internetowy HTTPS (port 443). Dodatkowo OpenVPN wspiera zaawansowane mechanizmy autoryzacji, w tym infrastrukturę klucza publicznego (PKI) oraz dwuskładnikowe uwierzytelnianie MFA.

W ramach niniejszego modułu studenci poznają pełną architekturę systemu: wirtualne sterowniki TUN/TAP, zasady generowania certyfikatów za pomocą narzędzia Easy-RSA, strukturę plików konfiguracyjnych .ovpn, zaawansowane dyrektywy routingu i wypychania opcji (push), a także specyfikę wdrożeń na platformach Linux oraz MikroTik RouterOS.

Wyjaśnienie skrótów użytych na slajdzie:
OpenVPN - Open Virtual Private Network - Wieloplatformowy standard VPN oparty na SSL/TLS.
SSL - Secure Sockets Layer - Historyczny protokół kryptograficzny zastąpiony przez TLS.
TLS - Transport Layer Security - Nowoczesny protokół bezpieczeństwa warstwy transportowej.
PKI - Public Key Infrastructure - Infrastruktura klucza publicznego zarządzająca certyfikatami X.509.
MFA - Multi-Factor Authentication - Uwierzytelnianie wieloskładnikowe podnoszące poziom bezpieczeństwa.

2/40 Architektura: SSL/TLS VPN
Przedstawienie architektury bezpieczeństwa opartej na modelu SSL/TLS VPN oraz separacji kanału sterowania i kanału danych.
  • OpenVPN to pełna implementacja SSL VPN.
  • Wykorzystuje protokół TLS do bezpiecznej wymiany kluczy i uwierzytelniania.
  • Unikalna elastyczność: może operować na dowolnym porcie (TCP lub UDP).
  • Standardowy port: UDP 1194.
  • Możliwość emulacji ruchu HTTPS (TCP 443) pozwala skutecznie omijać restrykcyjne zapory sieciowe i systemy cenzury.
Architektura SSL/TLS VPN: Model wirtualnej sieci prywatnej, w którym autoryzacja i wymiana kluczy sesyjnych realizowane są przez protokół TLS, natomiast właściwy przesył zaszyfrowanych pakietów odbywa się w wydzielonym, zoptymalizowanym kanale danych.
Slide 2

Architektura bezpieczeństwa OpenVPN opiera się na sprawdzonym paradygmacie SSL/TLS VPN. Zamiast tworzyć własne, niesprawdzone mechanizmy kryptograficzne, autorzy zintegrowali pełny stos protokołu TLS do realizacji procesu wzajemnego uwierzytelniania węzłów oraz bezpiecznej wymiany parametrów kryptograficznych. Szczegółowe informacje normatywne i techniczne publikuje Społeczność OpenVPN Community.

W architekturze tej występuje wyraźny podział na dwa logiczne kanały komunikacyjne: kanał sterowania (Control Channel) oraz kanał danych (Data Channel). Kanał sterowania jest standardową, w pełni chronioną sesją TLS. W ramach tej sesji serwer i klient legitymują się certyfikatami X.509, negocjują tożsamość, weryfikują listy unieważnień CRL oraz uzgadniają dynamiczne, symetryczne klucze szyfrujące za pomocą algorytmu Diffie-Hellmana (lub ECDH).

Po pomyślnym uzgodnieniu parametrów w kanale TLS, sterowanie przekazywane jest do kanału danych (Data Channel). Kanał danych odpowiada za właściwą hermetyzację i szyfrowanie pakietów sieciowych użytkownika. Pakiety są szyfrowane wynegocjowanym kluczem symetrycznym (np. AES-256-GCM) i opatrywane unikalnym numerem sekwencyjnym, co zapewnia maksymalną wydajność transferu bez narzutu ponownego uzgadniania sesji TLS dla każdego pakietu.

Klucze sesyjne w kanale danych są cyklicznie odnawiane w procesie zwanym renegocjacją (parametr reneg-sec, standardowo co 3600 sekund). Zapewnia to realizację zasady Perfect Forward Secrecy - nawet w przypadku przejęcia klucza sesyjnego napastnik jest w stanie odszyfrować jedynie jednookresowy fragment transmisji.

Wyjaśnienie skrótów użytych na slajdzie:
SSL - Secure Sockets Layer - Pierwowzór protokołu TLS.
TLS - Transport Layer Security - Protokół zabezpieczeń kryptograficznych.
CRL - Certificate Revocation List - Lista unieważnionych certyfikatów X.509.
ECDH - Elliptic Curve Diffie-Hellman - Wymiana kluczy oparta na krzywych eliptycznych.
PFS - Perfect Forward Secrecy - Właściwość gwarantująca niezależność przeszłych kluczy sesyjnych.

3/40 User Space vs Kernel Space
Analiza różnic architektonicznych pomiędzy operowaniem w przestrzeni użytkownika a przestrzeni jądra oraz ich wpływu na bezpieczeństwo i wydajność.
  • Stos OpenVPN tradycyjnie operuje w przestrzeni użytkownika (User Space), wykorzystując uniwersalny wirtualny sterownik TUN/TAP do wymiany ramek ze stosem sieciowym jądra systemu operacyjnego (Kernel Space).
  • Architektura i narzut wydajnościowy:
    • Przetwarzanie każdego pakietu wymaga wielokrotnego przełączania kontekstu (Context Switching) i kopiowania danych z buforów jądra do pamięci demona OpenVPN i z powrotem.
    • Przy łączach wielogigabitowych powoduje to wysokie obciążenie rdzenia CPU i wąskie gardło I/O.
  • Nowoczesne rozwiązanie inżynierskie - OpenVPN DCO (Data Channel Offload):
    • Wprowadzenie dedykowanego modułu jądra (dostępnego w OpenVPN 2.6+ i jądrach Linux 5.x+), który przejmuje operacje szyfrowania i deszyfrowania kanału danych (Data Channel) bezpośrednio w przestrzeni jądra.
    • Pozwala to osiągnąć wydajność porównywalną z rozwiązaniami WireGuard i sprzętowym IPsec.
Przestrzeń użytkownika (User Space): Uprzywilejowany obszar pamięci operacyjnej i tryb pracy procesora, w którym wykonywane są standardowe aplikacje, odizolowane od bezpośredniego dostępu do sprzętu i struktur jądra systemu operacyjnego.
Slide 3

Fundamentalną decyzją konstrukcyjną podjętą przez twórców OpenVPN było umieszczenie całego procesu demona w przestrzeni użytkownika (User Space), w przeciwieństwie do tradycyjnych protokołów takich jak IPsec czy WireGuard, które operują bezpośrednio w przestrzeni jądra systemu operacyjnego (Kernel Space). Decyzja ta niesie za sobą daleko idące konsekwencje inżynierskie. Szczegółowe informacje normatywne i techniczne publikuje Dokumentacja jądra Linux TUN/TAP.

Główną zaletą działania w przestrzeni użytkownika jest niespotykana stabilność, bezpieczeństwo oraz elastyczność. Ewentualny błąd programistyczny w kodzie aplikacji OpenVPN (np. przepełnienie bufora) powoduje jedynie awarię samego procesu użytkownika, nie doprowadzając do paniki jądra (Kernel Panic) ani całkowitego unieruchomienia serwera. Ponadto aplikacja może być łatwo przenoszona pomiędzy różnymi systemami operacyjnymi (Linux, Windows, macOS, FreeBSD, Android) bez konieczności kompilowania dedykowanych modułów jądra.

Ceną za to bezpieczeństwo jest narzut wydajnościowy wynikający z konieczności ciągłego przełączania kontekstu procesora (Context Switching) pomiędzy przestrzenią użytkownika a przestrzenią jądra. Aby przesłać pojedynczy pakiet, system musi skopiować dane z fizycznej karty sieciowej w jądrze do aplikacji OpenVPN w przestrzeni użytkownika w celu odszyfrowania, a następnie przekazać odszyfrowany pakiet z powrotem do jądra przez wirtualny interfejs sieciowy.

W nowoczesnych wersjach OpenVPN (wersja 2.6 i nowsze) wprowadzono przełomową technologię Data Channel Offload (DCO). DCO przenosi operacje szyfrowania i przełączania pakietów w kanale danych bezpośrednio do jądra Linuksa (moduł ovpn-dco), pozostawiając w przestrzeni użytkownika jedynie złożoną logikę kanału sterowania TLS, co pozwala na wielokrotne zwiększenie przepustowości i zrównanie wydajności z protokołem WireGuard.

Wyjaśnienie skrótów użytych na slajdzie:
DCO - Data Channel Offload - Technologia odciążania kanału danych OpenVPN do jądra systemu.
CPU - Central Processing Unit - Główny procesor komputera.
IPsec - Internet Protocol Security - Protokół VPN operujący tradycyjnie w przestrzeni jądra.
API - Application Programming Interface - Interfejs programistyczny komunikacji między warstwami systemu.

4/40 Wirtualne interfejsy: TUN vs TAP
Komparatywna analiza zasad działania wirtualnych interfejsów sieciowych TUN oraz TAP w systemach operacyjnych.
  • OpenVPN bazuje na wirtualnych sterownikach kart sieciowych.
  • TUN (Tunnel): Emuluje warstwę sieciową (L3). Przesyła pakiety IP. Optymalny dla klasycznego routingu. Jedyny tryb wspierany natywnie przez urządzenia mobilne (Android/iOS).
  • TAP (Network Tap): Emuluje warstwę łącza danych (L2). Przesyła pełne ramki Ethernet. Niezbędny do mostkowania (Bridging) sieci oraz obsługi protokołów nie-IP (np. gry LAN, stare standardy). Generuje jednak wyższy narzut ruchu (Broadcast).
Wirtualny sterownik sieciowy (Virtual Network Driver): Sterownik programowy w jądrze systemu operacyjnego emulujący fizyczną kartę sieciową, przekazujący ramki sieciowe do procesu w przestrzeni użytkownika zamiast do fizycznego medium transmisyjnego.
Slide 4

Mechanizmem umożliwiającym aplikacji OpenVPN wymianę pakietów ze stosem sieciowym systemu operacyjnego są wirtualne interfejsy programowe TUN (Network TUNnel) oraz TAP (Network TAP). Wybór pomiędzy tymi interfejsami determinuje warstwę modelu OSI, w której operuje tworzony tunel VPN. Szczegółowe informacje normatywne i techniczne publikuje Podręcznik ip-link w systemie Linux.

Interfejs typu TUN operuje w warstwie sieciowej (warstwa 3 modelu OSI). Przesyła on i odbiera czyste pakiety IP (IPv4 oraz IPv6), całkowicie pomijając nagłówki warstwy łącza danych (brak adresów MAC). Tunel oparty na interfejsie TUN działa jak wirtualne połączenie punkt-punkt łączące dwa routery. Charakteryzuje się najniższym narzutem nagłówka (brak 14 bajtów ramki Ethernet), nie przenosi zbędnego ruchu rozgłoszeniowego i jest powszechnie stosowany w połączeniach zdalnego dostępu oraz routingu międzyoddziałowym.

Interfejs typu TAP operuje w warstwie łącza danych (warstwa 2 modelu OSI). Emuluje on zachowanie wirtualnej karty Ethernet, przesyłając pełne ramki warstwy 2 wraz z adresami MAC nadawcy i odbiorcy. Umożliwia to bezpośrednie mostkowanie (bridging) tunelu z lokalną siecią fizyczną (Bridge), tworząc jedną wspólną domenę rozgłoszeniową. Tryb TAP jest niezbędny w specyficznych scenariuszach wymagających transmisji ruchu broadcast (np. gry sieciowe LAN, protokoły NetBIOS, wykrywanie maszyn wirtualnych) lub transportu protokołów innych niż IP.

W praktyce inżynierskiej bezwzględnie zaleca się stosowanie trybu TUN wszędzie tam, gdzie celem jest standardowy routing IP. Tryb TAP generuje wyższy narzut transmisyjny, niepotrzebnie obciąża łącza WAN ruchem rozgłoszeniowym ze stacji roboczych i nie jest wspierany na urządzeniach mobilnych (iOS, Android).

Wyjaśnienie skrótów użytych na slajdzie:
TUN - Network TUNnel - Wirtualny interfejs sieciowy warstwy 3 (routing IP).
TAP - Network TAP - Wirtualny interfejs sieciowy warstwy 2 (mostkowanie Ethernet).
OSI - Open Systems Interconnection - Siedmiowarstwowy model odniesienia standardów sieciowych.
MAC - Media Access Control - Adres fizyczny warstwy łącza danych.
WAN - Wide Area Network - Rozległa sieć transmisyjna.

5/40 Transport: UDP vs TCP
Przedstawienie kryteriów wyboru protokołu warstwy transportowej w technologii OpenVPN oraz analiza problemu TCP Meltdown.
  • OpenVPN oferuje wybór protokołu transportowego.
  • Dlaczego UDP jest zalecane? Unikamy zjawiska "TCP over TCP Meltdown".
  • W przypadku utraty pakietu w tunelu, mechanizmy retransmisji TCP aplikacji wewnętrznej (np. przeglądarki) kolidowałyby z retransmisjami protokołu VPN, powodując drastyczny wzrost opóźnień.
  • UDP (Fire-and-Forget) pozwala aplikacji wewnątrz tunelu samodzielnie zarządzać integralnością, co jest kluczowe dla stabilności połączenia.
  • TCP stosujemy wyłącznie w celach omijania blokad (np. port 443).
Protokół transportowy tunelu (Tunnel Transport Protocol): Protokół warstwy czwartej stosu TCP/IP wykorzystywany do fizycznego transportowania zaszyfrowanych pakietów tunelu pomiędzy punktami końcowymi.
Slide 5

Jedną z najbardziej unikalnych cech technologii OpenVPN jest pełna dowolność w wyborze protokołu warstwy transportowej: demon może zostać skonfigurowany do pracy w oparciu o protokół User Datagram Protocol (UDP) lub Transmission Control Protocol (TCP). Standardowym i domyślnym wyborem inżynierskim jest protokół UDP na porcie 1194 (oficjalnie przydzielonym przez organizację IANA). Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 768 (Protokół UDP).

Zastosowanie protokołu UDP gwarantuje optymalną charakterystykę transmisyjną: brak narzutu na potwierdzenia, minimalne opóźnienia oraz brak retransmisji na poziomie nośnika tunelu. Jeżeli aplikacja użytkownika przesyła dane protokołem TCP, mechanizmy kontroli przeciążenia i retransmisji działają wyłącznie raz - wewnątrz właściwego strumienia danych. Zapewnia to najwyższą możliwą płynność dla transmisji multimedialnych oraz gier online.

Wdrożenie OpenVPN w trybie TCP (najczęściej na porcie 443) stosuje się wyłącznie jako rozwiązanie awaryjne w sytuacjach, gdy lokalna zapora sieciowa blokuje wszelki ruch UDP. Przesyłanie tunelu przez TCP wiąże się jednak z nieuchronnym ryzykiem wystąpienia zjawiska TCP-over-TCP Meltdown. W warunkach utraty pakietów na łączu fizycznym, zewnętrzny i wewnętrzny stos TCP jednocześnie podejmują próby retransmisji, co prowadzi do lawinowego spadku przepustowości.

Dobrą praktyką w projektowaniu korporacyjnych węzłów OpenVPN jest uruchomienie dwóch równoległych instancji serwera na tej samej maszynie: instancji podstawowej na porcie UDP 1194 oraz instancji zapasowej na porcie TCP 443. Klient w pliku konfiguracyjnym otrzymuje obie dyrektywy remote, dzięki czemu stacja robocza automatycznie próbuje szybszego połączenia UDP, a w razie blokady płynnie przełącza się na port TCP 443.

Wyjaśnienie skrótów użytych na slajdzie:
UDP - User Datagram Protocol - Bezpołączeniowy protokół warstwy transportowej (port 1194).
TCP - Transmission Control Protocol - Połączeniowy protokół transportowy z retransmisją danych.
IANA - Internet Assigned Numbers Authority - Organizacja przydzielająca oficjalne numery portów sieciowych.
HTTPS - Hypertext Transfer Protocol Secure - Szyfrowana komunikacja WWW na porcie TCP 443.

6/40 Infrastruktura klucza publicznego (PKI)
Przedstawienie roli i zasad funkcjonowania infrastruktury klucza publicznego PKI w architekturze uwierzytelniania OpenVPN.
  • Domyślnym i bezwzględnie zalecanym protokołem transportowym OpenVPN jest UDP na porcie 1194 (przydzielonym oficjalnie przez organizację IANA).
  • Dlaczego UDP jest standardem inżynierskim:
    • Brak narzutu na trzykrotny uścisk dłoni (3-way handshake) i potwierdzenia warstwy transportowej tunelu.
    • Każdy wewnętrzny pakiet użytkownika jest enkapsulowany bezpośrednio w datagram UDP.
  • Ryzyko stosowania nośnika TCP (np. TCP 443):
    • Zjawisko TCP-over-TCP Meltdown: W przypadku tunelowania pakietów TCP wewnątrz nośnika TCP, utrata pakietów na niestabilnym łączu powoduje równoczesne uruchomienie mechanizmów retransmisji i obniżania okna przesyłania (Congestion Avoidance) w obu warstwach. Prowadzi to do gwałtownej degradacji pasma i zerwania sesji.
    • Protokół TCP port 443 należy traktować wyłącznie jako rozwiązanie awaryjne (Fallback) w środowiskach z restrykcyjnymi zaporami DPI.
Infrastruktura klucza publicznego (Public Key Infrastructure - PKI): Zbiór procedur, ról, polityk oraz technologii kryptograficznych niezbędnych do tworzenia, zarządzania, dystrybucji, używania, przechowywania i unieważniania certyfikatów cyfrowych X.509.
Slide 6

Fundamentem bezpieczeństwa technologii OpenVPN jest infrastruktura klucza publicznego (PKI). Zamiast polegać na podatnych na odgadnięcie i trudnych w dystrybucji hasłach statycznych, OpenVPN opiera proces weryfikacji tożsamości na asymetrycznych parach kluczy oraz certyfikatach cyfrowych standardu ITU-T X.509 (RFC 5280). Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 5280 (Standard certyfikatów X.509 PKIX).

Sercem infrastruktury PKI jest główny urząd certyfikacji (Root Certificate Authority - CA). Urząd CA generuje własną parę kluczy i podpisuje swój certyfikat (Self-Signed CA). Zadaniem CA jest wystawianie i kryptograficzne podpisywanie certyfikatów dla wszystkich węzłów w sieci: serwerów dostępowych oraz poszczególnych klientów mobilnych. Certyfikat publiczny CA jest dystrybuowany do wszystkich uczestników komunikacji, pełniąc rolę zaufanej kotwicy tożsamości.

W trakcie zestawiania sesji OpenVPN realizuje procedurę uwierzytelniania dwukierunkowego (Mutual Authentication). Serwer przesyła swój certyfikat do klienta, a klient weryfikuje, czy został on podpisany przez zaufane CA oraz czy nazwa domenowa jest poprawna. Jednocześnie klient przesyła swój certyfikat osobisty do serwera, który dokonuje analogicznej weryfikacji. Dopiero obustronne potwierdzenie ważności podpisów otwiera drogę do wymiany kluczy sesyjnych.

Niezwykle istotnym elementem PKI jest lista unieważnionych certyfikatów (Certificate Revocation List - CRL). W sytuacji, gdy pracownik odchodzi z firmy lub jego laptop zostanie skradziony, administrator unieważnia powiązany certyfikat za pomocą urzędu CA i publikuje zaktualizowany plik crl.pem na serwerze. Przy kolejnej próbie połączenia serwer OpenVPN natychmiast odrzuca żądanie, uniemożliwiając nieautoryzowany dostęp bez konieczności rekonfiguracji pozostałych klientów.

Wyjaśnienie skrótów użytych na slajdzie:
PKI - Public Key Infrastructure - Infrastruktura klucza publicznego zarządzająca zaufaniem cyfrowym.
CA - Certificate Authority - Główny urząd certyfikacji tożsamości.
CRL - Certificate Revocation List - Lista unieważnionych certyfikatów X.509.
RFC - Request for Comments - Dokument standaryzacyjny komitetu IETF.

7/40 Narzędzie Easy-RSA
Przewodnik po strukturze i wykorzystaniu zestawu skryptów Easy-RSA do zarządzania centrum certyfikacji dla OpenVPN.
  • Samodzielne zarządzanie certyfikatami w czystym OpenSSL jest procesem złożonym.
  • Narzędzie Easy-RSA (zestaw skryptów powłoki) automatyzuje i upraszcza proces PKI.
  • Typowy przebieg pracy (Workflow):
    • Inicjalizacja środowiska PKI.
    • Utworzenie centrum CA (plik ca.key musi być pilnie strzeżony!).
    • Wygenerowanie i podpisanie certyfikatu serwera.
    • Wygenerowanie i podpisanie certyfikatów dla użytkowników końcowych.
  • Systemy klasy RouterOS posiadają wbudowane menedżery certyfikatów, co eliminuje potrzebę stosowania Easy-RSA.
Narzędzie Easy-RSA (Easy-RSA Management Tool): Zestaw wyspecjalizowanych skryptów powłoki bazujących na poleceniach pakietu OpenSSL, automatyzujący proces inicjalizacji urzędu CA, generowania par kluczy oraz wystawiania i unieważniania certyfikatów X.509.
Slide 7

Bezpośrednie zarządzanie infrastrukturą PKI za pomocą natywnego narzędzia wiersza poleceń biblioteki OpenSSL wymaga biegłości w operowaniu dziesiątkami złożonych przełączników oraz ręcznego edytowania rozbudowanych plików konfiguracyjnych openssl.cnf. W celu uproszczenia tego procesu projekt OpenVPN dostarcza dedykowane narzędzie wspomagające - Easy-RSA. Szczegółowe informacje normatywne i techniczne publikuje Dokumentacja techniczna OpenVPN Community Resources.

Easy-RSA to zestaw skryptów powłoki zoptymalizowanych pod kątem typowych scenariuszy wdrożeniowych VPN. Praca z narzędziem rozpoczyna się od zainicjowania czystego środowiska za pomocą polecenia ./easyrsa init-pki, co tworzy strukturę katalogów roboczych. Następnie poleceniem ./easyrsa build-ca generuje się klucz prywatny urzędu oraz główny certyfikat ca.crt, chroniony silnym hasłem dostępowym.

W kolejnym kroku administrator wystawia certyfikat tożsamości dla serwera VPN poleceniem ./easyrsa build-server-full server1 nopass. Opcja nopass oznacza, że klucz prywatny serwera nie będzie zaszyfrowany hasłem, co jest niezbędne, aby demon OpenVPN mógł wystartować automatycznie po restarcie systemu bez konieczności ręcznego wpisywania hasła przez administratora w konsoli.

W identyczny sposób generuje się certyfikaty dla kolejnych użytkowników: ./easyrsa build-client-full user1 nopass (lub z hasłem, jeśli wymaga tego polityka bezpieczeństwa). Z punktu widzenia dobrych praktyk bezpieczeństwa teleinformatycznego katalog zawierający klucz prywatny CA (ca.key) powinien znajdować się na wydzielonej, odłączonej od sieci maszynie (Offline CA), a na produkcyjny serwer VPN wgrywa się wyłącznie publiczny plik ca.crt oraz plik listy CRL.

Wyjaśnienie skrótów użytych na slajdzie:
PKI - Public Key Infrastructure - Infrastruktura klucza publicznego.
CA - Certificate Authority - Urząd certyfikacji tożsamości cyfrowej.
CLI - Command Line Interface - Tekstowy interfejs wiersza poleceń.
SSL - Secure Sockets Layer - Pakiet narzędzi kryptograficznych OpenSSL.

8/40 Dodatkowa ochrona: TLS-Auth / TLS-Crypt
Przedstawienie mechanizmów wstępnego uwierzytelniania pakietów TLS-Auth oraz szyfrowania nagłówków TLS-Crypt w technologii OpenVPN.
  • W celu zabezpieczenia kanału sterowania OpenVPN wykorzystuje dodatkowy klucz symetryczny (PSK):
  • TLS-Auth (dyrektywa tls-auth ta.key 0/1):
    • Zabezpiecza każdy pakiet kanału sterowania podpisem kryptograficznym HMAC.
    • Pakiety bez ważnego podpisu są natychmiast bezgłośnie odrzucane przez serwer bez alokacji zasobów, chroniąc bramę przed atakami DoS / DDoS i skanowaniem portów (port knocking effect).
    • Ograniczenie: Sam uścisk dłoni TLS oraz wymieniane certyfikaty X.509 przesyłane są jawnym tekstem.
  • TLS-Crypt (dyrektywa tls-crypt tls-crypt.key, wprowadzona w OpenVPN 2.4+):
    • Dokonuje pełnego szyfrowania symetrycznego całego kanału sterowania TLS oraz nagłówków pakietów.
    • Skutecznie ukrywa metadane połączenia, tożsamość klienta zawartą w certyfikacie oraz zapobiega identyfikacji sygnatur przez zaawansowane systemy DPI (Deep Packet Inspection).
Mechanizm TLS-Crypt (TLS Encryption and Authentication): Zaawansowane rozszerzenie protokołu OpenVPN szyfrujące i podpisujące kryptograficznym kodem HMAC wszystkie pakiety kanału sterowania TLS za pomocą statycznego klucza współdzielonego, ukrywające tożsamość węzłów i chroniące przed atakami DoS.
Slide 8

W standardowej konfiguracji serwer OpenVPN nasłuchujący na publicznym porcie UDP odpowiada na każdy poprawnie sformatowany pakiet inicjalizacji TLS Handshake. Stwarza to istotne ryzyka bezpieczeństwa: bramy VPN mogą być łatwo wykryte przez publiczne skanery sieciowe (np. Shodan), a podatności w kodzie biblioteki TLS (przed procesem uwierzytelnienia użytkownika) mogłyby posłużyć do zdalnego wykonania kodu lub ataków wyczerpania zasobów (DoS). Szczegółowe informacje normatywne i techniczne publikuje Podręcznik referencyjny OpenVPN 2.6.

Pierwszą linią obrony opracowaną przez twórców OpenVPN był mechanizm TLS-Auth (dyrektywa tls-auth ta.key 0). Wykorzystuje on symetryczny klucz statyczny do podpisywania każdego pakietu sterującego kodem HMAC. Serwer po odebraniu pakietu najpierw sprawdza podpis HMAC za pomocą klucza ta.key. Jeżeli podpis jest niepoprawny lub go brakuje, pakiet jest natychmiast cicho porzucany bez angażowania zasobów procesora w negocjację TLS, czyniąc serwer całkowicie niewidocznym dla skanerów portów.

W nowoczesnych wersjach OpenVPN mechanizm ten został zastąpiony przez znacznie bardziej zaawansowany standard TLS-Crypt (dyrektywa tls-crypt tc.key). TLS-Crypt nie tylko podpisuje pakiety kodem HMAC, ale również w całości szyfruje całą sekwencję wymiany komunikatów TLS za pomocą algorytmu AES-256-CTR. Oznacza to, że certyfikaty przesyłane w trakcie negocjacji są całkowicie ukryte przed podsłuchem w sieci tranzytowej.

Wdrożenie TLS-Crypt zapewnia potężną odporność na cenzurę internetową oraz systemy głębokiej inspekcji pakietów (DPI), uniemożliwiając analizatorom ruchu rozpoznanie metadanych certyfikatów X.509. Z tego względu zastosowanie mechanizmu TLS-Crypt stanowi bezwzględną rekomendację bezpieczeństwa dla każdego nowo projektowanego środowiska OpenVPN.

Wyjaśnienie skrótów użytych na slajdzie:
HMAC - Hash-based Message Authentication Code - Kryptograficzny kod uwierzytelniania wiadomości.
DoS - Denial of Service - Atak sieciowy mający na celu zablokowanie usług serwera.
DPI - Deep Packet Inspection - Głęboka inspekcja pakietów stosowana przez zapory i cenzurę.
TLS - Transport Layer Security - Protokół zabezpieczeń kryptograficznych.

9/40 OpenVPN w RouterOS: podstawy (1)
Przedstawienie specyfiki, ewolucji oraz przygotowania podsystemu OpenVPN w systemie MikroTik RouterOS.
  • Konfiguracja wymaga wcześniejszego importu certyfikatów do bazy systemowej.
  • # 1. Definiowanie puli adresowej dla klientów VPN
/ip pool add name=ovpn-pool ranges=10.8.0.10-10.8.0.100
# 2. Konfiguracja profilu PPP (brama lokalna i DNS)
/ppp profile add name=ovpn-profile local-address=10.8.0.1 remote-address=ovpn-pool dns-server=8.8.8.8
Implementacja OpenVPN w RouterOS (RouterOS OVPN Subsystem): Zintegrowana w systemie MikroTik obsługa protokołu OpenVPN, powiązana z podsystemem profili PPP i certyfikatów X.509.
Slide 9

Wdrożenie protokołu OpenVPN w urządzeniach firmy MikroTik charakteryzuje się specyficznymi cechami inżynierskimi, które wynikają z głębokiej integracji tego protokołu z ogólnym podsystemem PPP w systemie RouterOS. Administratorzy migrujący konfiguracje z klasycznych serwerów linuksowych muszą być świadomi różnic architektonicznych występujących w oprogramowaniu MikroTik. Szczegółowe informacje normatywne i techniczne publikuje Dokumentacja MikroTik OpenVPN.

Historycznie, przez wiele lat w systemie RouterOS w wersji v6 implementacja OpenVPN posiadała istotne ograniczenia: wspierała wyłącznie protokół transportowy TCP (całkowity brak obsługi UDP), nie obsługiwała kompresji LZO ani nowoczesnego mechanizmu TLS-Auth. Wymuszało to stosowanie mniej wydajnego transportu TCP we wszystkich wdrożeniach opartych na RouterOS v6.

Przełom przyniosła premiera systemu RouterOS w wersji v7. Programiści MikroTik gruntownie przepisali podsystem OpenVPN, wprowadzając pełne wsparcie dla protokołu UDP, nowoczesnych szyfrów AEAD (AES-GCM), negocjacji parametrów NCP oraz kompatybilności z oficjalnymi klientami mobilnymi. Dzięki temu RouterOS v7 stał się pełnoprawną platformą dla przemysłowych węzłów OpenVPN.

Przygotowanie routera MikroTik do uruchomienia usługi wymaga wcześniejszego zaimportowania lub wygenerowania certyfikatów X.509 w gałęzi /certificate (certyfikatu CA oraz certyfikatu serwera) oraz zdefiniowania dedykowanego profilu PPP w gałęzi /ppp profile, w którym określa się pule adresowe przydzielane łączącym się klientom.

Wyjaśnienie skrótów użytych na slajdzie:
OVPN - OpenVPN Subsystem in RouterOS - Podsystem OpenVPN w urządzeniach MikroTik.
TCP - Transmission Control Protocol - Protokół transportowy wspierany historycznie w RouterOS v6.
UDP - User Datagram Protocol - Wysokowydajny protokół transportowy wprowadzony w RouterOS v7.
AEAD - Authenticated Encryption with Associated Data - Nowoczesne szyfry blokowe zintegrowane z uwierzytelnianiem.

10/40 OpenVPN w RouterOS: uruchomienie usługi (2)
Instruktaż uruchomienia i parametryzacji serwera OpenVPN w systemie MikroTik RouterOS v7.
  • Aktywacja serwera z wyborem bezpiecznych parametrów:
  • /interface ovpn-server server set
enabled=yes
certificate=Server-Certificate
require-client-certificate=yes
auth=sha256 cipher=aes128,aes256
default-profile=ovpn-profile
netmask=24
  • Uwaga: W RouterOS v7 zyskujemy wsparcie dla zalecanego protokołu UDP!
Serwer OpenVPN RouterOS (RouterOS OVPN Server): Usługa systemowa w RouterOS nasłuchująca żądań połączeń na wybranym porcie (standardowo UDP lub TCP 1194), zarządzająca tunelami danych w oparciu o profil PPP i certyfikat serwerowy.
Slide 10

Właściwe uruchomienie usługi serwera OpenVPN w systemie MikroTik RouterOS v7 odbywa się w gałęzi konfiguracyjnej /interface ovpn-server server. Usługa wymaga jawnej aktywacji przez administratora oraz powiązania z wcześniej przygotowanymi obiektami certyfikatów i profili sieciowych. Szczegółowe informacje normatywne i techniczne publikuje Dokumentacja MikroTik PPP.

Główne polecenie aktywujące serwer ma postać: /interface ovpn-server server set enabled=yes port=1194 protocol=udp mode=ip certificate=Server-Cert default-profile=ovpn-profile require-client-certificate=yes cipher=aes256-gcm,aes128-gcm auth=sha256. W parametrze protocol wybiera się wartość udp, co gwarantuje najwyższą wydajność transmisyjną.

Parametr mode=ip definiuje tryb pracy interfejsu jako TUN (warstwa 3 - routing pakietów IP). Gdyby wymagane było mostkowanie w warstwie 2, administrator wybrałby wartość mode=ethernet (odpowiednik trybu TAP). W parametrze cipher wskazuje się dozwolone algorytmy szyfrowania - zaleca się stosowanie wyłącznie nowoczesnych algorytmów z rodziny AES-GCM.

Kluczowym ustawieniem bezpieczeństwa jest require-client-certificate=yes. Wymusza ono, aby każdy łączący się klient posiadał unikalny certyfikat cyfrowy podpisany przez zaufane CA routera. Dodatkowo w zaporze sieciowej (/ip firewall filter) należy dodać regułę w łańcuchu input zezwalającą na ruch przychodzący na port docelowy UDP 1194 z publicznego interfejsu WAN.

Wyjaśnienie skrótów użytych na slajdzie:
OVPN - OpenVPN Protocol - Protokół wirtualnych sieci prywatnych.
UDP - User Datagram Protocol - Bezpołączeniowy protokół transportowy na porcie 1194.
WAN - Wide Area Network - Interfejs podłączony do sieci publicznej dostawcy.
CLI - Command Line Interface - Tekstowy interfejs zarządzania RouterOS.

11/40 Uwierzytelnianie: baza Secrets
Przedstawienie dwupoziomowego modelu uwierzytelniania w RouterOS łączącego certyfikaty X.509 z lokalną bazą kont PPP Secrets.
  • Choć OpenVPN bazuje na certyfikatach, MikroTik domyślnie wymaga również danych z bazy PPP Secrets.
  • Taka konfiguracja realizuje model Two-Factor Authentication (2FA) - użytkownik musi posiadać fizyczny certyfikat ORAZ znać hasło.
  • Tworzenie użytkownika: /ppp secret add name=jan password=SkomplikowaneHaslo123 profile=ovpn-profile
  • Zwiększa to drastycznie poziom bezpieczeństwa w razie kradzieży urządzenia klienckiego.
Dwupoziomowe uwierzytelnianie OpenVPN (Two-Tier Authentication): Model bezpieczeństwa w systemie RouterOS wymagający od klienta pomyślnej weryfikacji tożsamości kryptograficznej certyfikatem X.509 oraz podania prawidłowych poświadczeń (login i hasło) z bazy PPP Secrets.
Slide 11

W klasycznych instalacjach linuksowych serwer OpenVPN może operować w oparciu o samo uwierzytelnianie certyfikatami X.509 (użytkownik nie musi podawać żadnego hasła, jeśli posiada ważny certyfikat i klucz). W systemie MikroTik RouterOS ze względu na powiązanie z podsystemem PPP domyślnym paradygmatem jest uwierzytelnianie dwupoziomowe: certyfikat plus login i hasło. Szczegółowe informacje normatywne i techniczne publikuje Dokumentacja certyfikatów MikroTik.

W modelu tym stacja robocza najpierw przeprowadza pełną wymianę kryptograficzną TLS za pomocą certyfikatu klienta. Po pomyślnym zatwierdzeniu certyfikatu następuje faza weryfikacji tożsamości użytkownika (mechanizm auth-user-pass). Klient przesyła login i hasło, które router weryfikuje w swojej lokalnej bazie sekretów (/ppp secret) lub przekazuje do centralnego serwera RADIUS.

Konfiguracja konta w RouterOS sprowadza się do polecenia: /ppp secret add name=jan.kowalski password="SilneHaslo123!" service=ovpn profile=ovpn-profile. Ograniczenie parametru service do wartości ovpn jest zalecaną praktyką inżynierską, zapobiegającą logowaniu się użytkownika do innych usług tunelowych (np. SSTP lub L2TP).

Uwierzytelnianie dwuskładnikowe łączy zalety obu światów: zgubienie lub skradzenie pliku certyfikatu nie pozwala napastnikowi na nawiązanie połączenia bez znajomości hasła użytkownika, a przejęcie samego hasła jest bezużyteczne bez posiadania unikalnego certyfikatu cyfrowego zapisanego na urządzeniu pracownika.

Wyjaśnienie skrótów użytych na slajdzie:
PPP - Point-to-Point Protocol - Podsystem zarządzający kontami dostępowymi.
RADIUS - Remote Authentication Dial-In User Service - Centralny protokół uwierzytelniania korporacyjnego.
TLS - Transport Layer Security - Warstwa kryptograficzna weryfikująca certyfikaty.
OVPN - OpenVPN Service - Usługa tunelowania w RouterOS.

12/40 Struktura pliku .ovpn
Przegląd budowy, sekcji składowych i formatu jednolitego pliku konfiguracyjnego klienta OpenVPN.
  • Każdy klient OpenVPN wymaga pliku konfiguracyjnego z rozszerzeniem .ovpn.
  • Jest to czysty plik tekstowy zawierający instrukcje dla silnika VPN.
  • Najbardziej polecanym formatem jest tzw. Unified Config - model, w którym certyfikaty są zaszyte bezpośrednio w pliku, co eliminuje konieczność przesyłania wielu załączników.
Plik konfiguracyjny .ovpn (OpenVPN Profile File): Zunifikowany dokument tekstowy zawierający komplet dyrektyw sterujących, adresów serwerów, parametrów kryptograficznych oraz zintegrowanych kluczy i certyfikatów niezbędnych do nawiązania sesji VPN.
Slide 12

Podstawowym nośnikiem parametrów konfiguracyjnych po stronie klienta OpenVPN jest plik z rozszerzeniem .ovpn. Jest to zwykły plik tekstowy kodowany w standardzie UTF-8, interpretowany bezpośrednio przez oficjalne aplikacje klienckie (OpenVPN Connect, OpenVPN Community GUI) na wszystkich wspieranych platformach systemowych. Szczegółowe informacje normatywne i techniczne publikuje Oficjalny klient OpenVPN Connect dla Windows.

W architekturze pliku .ovpn wyróżnia się cztery zasadnicze sekcje: sekcję nagłówkową (deklarującą tryb pracy klienta i typ wirtualnego interfejsu), sekcję transportową (definiującą adresy IP serwerów, porty i protokoły), sekcję kryptograficzną (określającą algorytmy szyfrowania i uwierzytelniania) oraz sekcję materiału klucza PKI (zawierającą certyfikaty i klucze).

Tradycyjnie konfiguracja OpenVPN składała się z pliku tekstowego oraz kilku oddzielnych plików binarnych (.crt, .key). Współczesnym standardem inżynierskim jest tzw. profil jednolity (Unified Profile), w którym wszystkie certyfikaty i klucze są umieszczone bezpośrednio wewnątrz jednego pliku .ovpn w dedykowanych sekcjach XML/HTML. Pozwala to na przesłanie pracownikowi pojedynczego, kompletnego pliku konfiguracyjnego.

Struktura pliku cechuje się dużą elastycznością: administrator może umieszczać w nim komentarze rozpoczynające się od znaku średnika lub krzyżyka oraz definiować alternatywne adresy zapasowe bramy korporacyjnej, co zapewnia wysoką niezawodność łączności.

Wyjaśnienie skrótów użytych na slajdzie:
OVPN - OpenVPN Configuration Profile - Jednolity profil konfiguracyjny klienta OpenVPN.
UTF-8 - Unicode Transformation Format 8-bit - Standard kodowania znaków tekstowych.
PKI - Public Key Infrastructure - Materiał kluczy i certyfikatów osadzony w profilu.
XML - Extensible Markup Language - Format znaczników używany do wydzielania sekcji certyfikatów.

13/40 Analiza pliku .ovpn: sekcja nagłówkowa
Szczegółowa analiza kluczowych dyrektyw nagłówkowych i sieciowych w pliku konfiguracyjnym klienta.
  • Kluczowe dyrektywy klienta:
  • client
dev tun
proto udp
remote vpn.firma.pl 1194
resolv-retry infinite
nobind
persist-key
persist-tun
auth-user-pass
  • Komendy te definiują podstawowe zachowanie klienta: adres docelowy, typ tunelu oraz metodę nawiązywania połączenia.
Dyrektywy sterujące OpenVPN (OpenVPN Control Directives): Słowa kluczowe w pliku konfiguracyjnym determinujące rolę stacji (klient/serwer), typ tworzonego interfejsu wirtualnego, protokół transportowy oraz parametry ponawiania połączeń.
Slide 13

Sekcja nagłówkowa pliku .ovpn definiuje fundamentalne zachowanie klienta sieciowego. Pierwszą obowiązkową dyrektywą jest słowo kluczowe client, które instruuje aplikację, że ma działać w trybie węzła klienckiego (co automatycznie włącza domyślne reguły pobierania konfiguracji od serwera). Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 8446 (Standard TLS 1.3).

Kolejną kluczową dyrektywą jest dev tun (lub dev tap). Określa ona typ wirtualnego interfejsu sieciowego, jaki system operacyjny musi zainicjować. W 99% wdrożeń stosuje się wartość dev tun, co wymusza pracę w warstwie 3 (routing IP). Następnie dyrektywa proto udp (lub proto tcp) definiuje protokół transportowy, który musi być ściśle zgodny z konfiguracją serwera nasłuchującego.

W sekcji adresowej umieszcza się dyrektywę remote vpn.firma.pl 1194, określającą adres serwera (nazwę domenową FQDN lub publiczny adres IP) oraz port docelowy. Dopuszczalne jest podanie wielu kolejnych linii remote - klient będzie wówczas testował je sekwencyjnie w przypadku braku łączności z pierwszym węzłem.

Uzupełnieniem sekcji nagłówkowej są parametry optymalizujące stabilność: resolv-retry infinite (nakazujący bezterminowe ponawianie prób rozwiązywania nazwy w systemie DNS), nobind (instruujący system, aby przydzielił losowy port źródłowy dla klienta zamiast wiązania go na stałe) oraz persist-key i persist-tun, które zapobiegają zamykaniu wirtualnego interfejsu podczas krótkotrwałych przerw w transmisji i renegocjacji kluczy.

Wyjaśnienie skrótów użytych na slajdzie:
TUN - Network TUNnel - Wirtualny interfejs warstwy sieciowej IP.
TAP - Network TAP - Wirtualny interfejs warstwy łącza danych Ethernet.
FQDN - Fully Qualified Domain Name - Pełna nazwa domenowa serwera VPN.
DNS - Domain Name System - System rozwiązywania nazw mnemonicznych.

14/40 Analiza pliku .ovpn: szyfrowanie i NCP
Omówienie dyrektyw kryptograficznych w pliku klienta oraz zasady działania mechanizmu Negotiable Crypto Parameters.
  • cipher AES-256-GCM
auth SHA256
remote-cert-tls server
  • NCP (Negotiable Crypto Parameters): Nowoczesne wersje OpenVPN potrafią automatycznie wynegocjować najlepszy dla obu stron algorytm szyfrowania (np. AES-GCM dla wydajności sprzętowej).
  • Krytyczna zasada: Parametry kryptograficzne muszą być zgodne z możliwościami serwera, w przeciwnym razie połączenie zostanie przerwane.
Negotiable Crypto Parameters (NCP): Mechanizm protokołu OpenVPN umożliwiający dynamiczne wynegocjowanie najsilniejszego wspieranego przez obie strony algorytmu szyfrowania w kanale danych bez konieczności rekonfiguracji plików .ovpn.
Slide 14

Sekcja kryptograficzna pliku .ovpn odpowiada za zdefiniowanie algorytmów zabezpieczających kanał danych oraz reguł kontroli integralności. W starszych wersjach OpenVPN administratorzy musieli sztywno definiować dyrektywy cipher (np. cipher AES-256-CBC) oraz auth (np. auth SHA256) po stronie klienta, a jakakolwiek zmiana algorytmu na serwerze wymagała ponownego wygenerowania i rozesłania plików konfiguracyjnych do wszystkich użytkowników. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 5116 (Standard AEAD).

W nowoczesnych wydaniach protokołu (OpenVPN 2.4 i nowsze) wprowadzono rewolucyjny mechanizm Negotiable Crypto Parameters (NCP). Mechanizm ten pozwala serwerowi i klientowi na dynamiczne uzgodnienie najbezpieczniejszego dostępnego szyfru podczas nawiązywania sesji TLS. Nawet jeśli w pliku klienta wpisano starszy szyfr, serwer posiadający dyrektywę data-ciphers AES-256-GCM:AES-128-GCM automatycznie wymusi użycie nowoczesnego algorytmu AEAD.

Zastosowanie szyfrów AEAD (Authenticated Encryption with Associated Data), takich jak AES-256-GCM lub ChaCha20-Poly1305, eliminuje potrzebę definiowania oddzielnej dyrektywy auth dla kanału danych. Szyfry te posiadają wbudowane kryptograficzne tagi uwierzytelniające, co gwarantuje jednoczesną poufność i integralność pakietu z najwyższą możliwą wydajnością procesora.

Dyrektywa auth SHA256 w nowoczesnych plikach konfiguracyjnych odpowiada wyłącznie za zabezpieczenie kanału sterowania TLS i jest wykorzystywana w połączeniu z mechanizmem TLS-Auth. Wdrożenie NCP zapewnia pełną wsteczną kompatybilność i pozwala na bezproblemową modernizację kryptografii w całej organizacji.

Wyjaśnienie skrótów użytych na slajdzie:
NCP - Negotiable Crypto Parameters - Mechanizm dynamicznej negocjacji szyfrów w OpenVPN.
AEAD - Authenticated Encryption with Associated Data - Nowoczesny zintegrowany tryb kryptograficzny.
AES-GCM - Advanced Encryption Standard Galois Counter Mode - Szyfr blokowy AEAD o wysokiej wydajności.
CBC - Cipher Block Chaining - Tradycyjny tryb wiązania bloków szyfru.

15/40 Certyfikaty wewnątrz pliku (Inline)
Przedstawienie techniki osadzania materiału klucza PKI bezpośrednio wewnątrz jednolitego pliku konfiguracyjnego .ovpn.
  • Historycznie kompresja strumienia danych (dyrektywa comp-lzo) była powszechnie stosowana w celu redukcji zużycia pasma telekomunikacyjnego.
  • Krytyczna luka bezpieczeństwa VORACLE (CVE-2018-3977):
    • Podatność wykazuje, że jednoczesne kompresowanie i szyfrowanie danych umożliwia atakującemu podsłuchującemu ruch pasywny odzyskanie poufnych informacji (np. nagłówków autoryzacyjnych HTTP i ciasteczek sesyjnych) na podstawie różnic w rozmiarze skompresowanych bloków (atak zbliżony do CRIME/BREACH).
  • Bezwzględny standard inżynierski:
    • Całkowity zakaz stosowania kompresji: W plikach konfiguracyjnych serwera i klienta należy wyeliminować dyrektywy comp-lzo i compress.
    • W celu ochrony przed błędną rekonfiguracją po stronie klienta zaleca się wprowadzenie dyrektywy comp-lzo no lub dyrektywy blokującej kompresję.
Format Inline (Embedded PKI Format): Metoda integracji certyfikatów X.509 i kluczy prywatnych w formacie PEM bezpośrednio wewnątrz pliku .ovpn za pomocą dedykowanych znaczników XML.
Slide 15

W klasycznym modelu dystrybucji konfiguracji OpenVPN użytkownik końcowy otrzymywał archiwum ZIP zawierające plik tekstowy client.ovpn oraz co najmniej trzy oddzielne pliki kryptograficzne: certyfikat urzędu (ca.crt), certyfikat klienta (client.crt) oraz klucz prywatny (client.key). Model ten generował liczne problemy eksploatacyjne: gubienie plików przez użytkowników, błędy względnych ścieżek dostępu oraz trudności z importem na urządzeniach mobilnych. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 7468 (Format kodowania PEM).

Standardem przemysłowym stało się stosowanie techniki certyfikatów zintegrowanych (Inline Certificates). Polega ona na umieszczeniu zakodowanych w formacie Base64 (PEM) bloków danych kryptograficznych bezpośrednio na końcu pliku .ovpn, z wykorzystaniem dedykowanych sekcji znacznikowych przypominających składnię języka XML.

W strukturze pliku pojawiają się sekcje: ... (zawierająca publiczny certyfikat urzędu certyfikacji), ... (zawierająca certyfikat osobisty klienta), ... (zawierająca niejawny klucz prywatny użytkownika) oraz opcjonalnie ... (zawierająca symetryczny klucz ochrony kanału sterowania).

Zalety formatu Inline są niepodważalne: użytkownik otrzymuje dokładnie jeden plik konfiguracyjny, którego dwukrotne kliknięcie lub zaimportowanie w aplikacji mobilnej natychmiast instaluje kompletny, działający profil VPN. Drastycznie redukuje to obciążenie działu pomocy technicznej (Helpdesk) i eliminuje błędy ludzkie przy wdrożeniach.

Wyjaśnienie skrótów użytych na slajdzie:
PEM - Privacy Enhanced Mail - Tekstowy format kodowania certyfikatów i kluczy w Base64.
PKI - Public Key Infrastructure - Infrastruktura klucza publicznego.
XML - Extensible Markup Language - Format znaczników używany do wydzielania sekcji.
CA - Certificate Authority - Urząd certyfikacji tożsamości.

16/40 Oprogramowanie klienckie
Przegląd dostępnego oprogramowania klienckiego OpenVPN na wiodące platformy systemowe ze szczególnym uwzględnieniem OpenVPN Connect i Community GUI.
  • OpenVPN Community GUI: Klasyczne rozwiązanie dla systemu Windows (ikona w zasobniku systemowym). Pozwala na precyzyjny podgląd logów sesji.
  • OpenVPN Connect: Oficjalna aplikacja od twórców OpenVPN Inc. Oferuje nowoczesny interfejs graficzny, ułatwioną procedurę importu profili oraz optymalizacje dla systemów mobilnych.
  • Import pliku profilu realizuje metoda „przeciągnij i upuść" (drag-and-drop) lub menu „Import Profile".
Klient OpenVPN (OpenVPN Client Software): Aplikacja kliencka instalowana na stacji roboczej lub urządzeniu mobilnym, zarządzająca wirtualnym adapterem sieciowym oraz realizująca negocjację tunelu z serwerem dostępowym.
Slide 16

W przeciwieństwie do protokołów PPTP, L2TP czy SSTP, które posiadają wbudowane stosy w systemach Microsoft Windows, technologia OpenVPN wymaga zainstalowania dedykowanego oprogramowania klienckiego. Na rynku dominują dwa oficjalne rozwiązania rozwijane pod egidą projektu OpenVPN: OpenVPN Community GUI oraz OpenVPN Connect. Szczegółowe informacje normatywne i techniczne publikuje Oficjalny portal firmy OpenVPN Inc..

OpenVPN Community GUI to tradycyjna, otwartoźródłowa aplikacja przeznaczona głównie dla zaawansowanych użytkowników i administratorów systemów Windows. Działa w zasobniku systemowym (System Tray), wykorzystuje natywny silnik OpenVPN w przestrzeni użytkownika, operuje na plikach umieszczonych w katalogu C:\Users\\OpenVPN\config i oferuje pełny dostęp do szczegółowych logów diagnostycznych.

OpenVPN Connect to nowoczesny, oficjalny klient nowej generacji rozwijany przez firmę OpenVPN Inc., dostępny na platformy Windows, macOS, iOS oraz Android. Charakteryzuje się nowoczesnym, intuicyjnym interfejsem graficznym, zaawansowaną obsługą profili w chmurze, wsparciem dla wieloskładnikowego uwierzytelniania MFA oraz zoptymalizowanym silnikiem kryptograficznym napisanym w języku C++ (OpenVPN 3 Core Library).

W systemach uniksowych (Linux, FreeBSD) klient OpenVPN jest najczęściej uruchamiany jako demon systemowy zarządzany przez systemd (usługa openvpn-client@.service) lub integrowany bezpośrednio z apletem NetworkManager za pośrednictwem wtyczki network-manager-openvpn, co pozwala na bezszwowe sterowanie połączeniem z poziomu pulpitu graficznego GNOME lub KDE.

Wyjaśnienie skrótów użytych na slajdzie:
GUI - Graphical User Interface - Graficzny interfejs użytkownika aplikacji klienckiej.
MFA - Multi-Factor Authentication - Uwierzytelnianie wieloskładnikowe wspierane w kliencie.
OS - Operating System - System operacyjny stacji roboczej klienta.

17/40 Mechanizm Push: zdalne zarządzanie routingiem
Przedstawienie mechanizmu dynamicznego rozgłaszania tras i parametrów sieciowych za pomocą dyrektyw push w OpenVPN.
  • Dyrektywa serwera push "redirect-gateway def1" wymusza na stacji roboczej klienta przekierowanie całego ruchu internetowego przez wirtualny interfejs VPN (architektura Full Tunneling).
  • Mechanizm inżynierski flagi 'def1':
    • Zwykłe nadpisanie trasy domyślnej 0.0.0.0/0 bramą tunelu VPN skutkowałoby natychmiastowym zapętleniem routingu: klient próbując wysłać zaszyfrowany pakiet do publicznego adresu serwera OpenVPN kierowałby go do wnętrza tunelu, powodując załamanie łączności.
    • Flaga def1 nie usuwa pierwotnej trasy domyślnej, lecz instaluje w tablicy routingu klienta dwie specyficzne trasy obejmujące całą przestrzeń adresową IPv4:
  • 1. 0.0.0.0/1 (zakres 0.0.0.0 - 127.255.255.255)
  • 2. 128.0.0.0/1 (zakres 128.0.0.0 - 255.255.255.255)
    • Zgodnie z regułą Longest Prefix Match (LPM) trasy z maską /1 mają pierwszeństwo przed trasą domyślną /0, gwarantując bezpieczne tunelowanie całego ruchu bez pętli sieciowych.
Mechanizm Push (Dynamic Option Pushing): Procedura protokołu OpenVPN umożliwiająca serwerowi automatyczne przekazanie i zainstalowanie na stacji klienckiej tras routingu, adresów DNS oraz parametrów łącza bez modyfikacji lokalnego pliku .ovpn.
Slide 17

Jedną z najpotężniejszych przewag architektonicznych protokołu OpenVPN nad konkurencją jest mechanizm dynamicznego wypychania opcji (Options Pushing). W tradycyjnych rozwiązaniach VPN zmiana topologii sieci korporacyjnej (np. dodanie nowej podsieci w oddziale) wymagała ręcznej rekonfiguracji tablic routingu na komputerach wszystkich pracowników mobilnych. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 1918 (Adresacja prywatna).

W technologii OpenVPN serwer zarządza konfiguracją sieciową klientów w sposób w pełni scentralizowany za pomocą dyrektywy push umieszczonej w pliku server.conf. Po pomyślnym zakończeniu negocjacji TLS klient wysyła żądanie pobrania opcji, a serwer przesyła zdefiniowany pakiet instrukcji sieciowych.

Najważniejszym zastosowaniem mechanizmu jest rozgłaszanie tras do podsieci firmowych za pomocą dyrektywy push "route 192.168.20.0 255.255.255.0". Po odebraniu tej instrukcji klient automatycznie instaluje w swojej lokalnej tablicy routingu trasę wskazującą wirtualny interfejs TUN jako bramę dla danej podsieci, realizując model dzielonego tunelowania (Split Tunneling).

Poza trasami IP serwer może dynamicznie wypychać adresy korporacyjnych serwerów DNS (push "dhcp-option DNS 10.0.0.1"), domenowe sufiksy przeszukiwania (push "dhcp-option DOMAIN firma.local") oraz parametry czasu utrzymania sesji (push "ping 10", push "ping-restart 60"). Wszystkie te ustawienia są automatycznie czyszczone z systemu klienta w momencie zamknięcia tunelu.

Wyjaśnienie skrótów użytych na slajdzie:
DNS - Domain Name System - System nazw domenowych wypychany do klienta przez opcje push.
DHCP - Dynamic Host Configuration Protocol - Format opcji używany do przekazywania konfiguracji sieciowej.
TUN - Network TUNnel - Wirtualny interfejs sieciowy klienta.
IP - Internet Protocol - Protokół warstwy internetowej.

18/40 Pełne tunelowanie (Redirect Gateway)
Analiza mechanizmu pełnego tunelowania w OpenVPN oraz inżynierskiego schematu przekierowania bramy domyślnej 'def1'.
  • Implementacja serwera i klienta OpenVPN w systemie MikroTik RouterOS wymaga uwzględnienia generacji oprogramowania systemowego:
  • Ograniczenia architektury RouterOS v6 (starsza generacja):
    • Brak obsługi protokołu UDP: Przez ponad dekadę RouterOS v6 wspierał OpenVPN wyłącznie w trybie TCP, co uniemożliwiało tworzenie wydajnych tuneli UDP.
    • Brak wsparcia dla mechanizmu tls-auth / tls-crypt oraz brak dynamicznej negocjacji szyfrów (NCP).
  • Postęp technologiczny w RouterOS v7:
    • Wprowadzenie pełnej, stabilnej obsługi OpenVPN over UDP.
    • Wsparcie dla nowoczesnych algorytmów uwierzytelniania i szyfrów AEAD (AES-GCM).
    • Nadal brak pełnego wsparcia dla sterownika DCO w przestrzeni jądra RouterOS, co wymusza optymalizację doboru jednostki MTU.
Dyrektywa redirect-gateway def1: Zaawansowana reguła routingu OpenVPN instalująca dwie trasy cząstkowe z maską /1 w celu przejęcia całego ruchu stacji roboczej bez nadpisywania i usuwania oryginalnej bramy domyślnej fizycznego interfejsu.
Slide 18

W politykach bezpieczeństwa wielu organizacji bezwzględnym wymogiem jest realizacja modelu pełnego tunelowania (Full Tunneling). W modelu tym cały ruch generowany przez stację roboczą pracownika mobilnego - w tym cały ruch internetowy, przeglądanie stron WWW i poczta elektroniczna - musi zostać skierowany do tunelu VPN i poddany centralnej inspekcji przez korporacyjne systemy DLP oraz zapory ogniowe. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 1812 (Wymagania dla routerów IPv4).

W technologii OpenVPN wymuszenie pełnego tunelowania realizuje się za pomocą pojedynczej dyrektywy serwerowej: push "redirect-gateway def1". Sposób implementacji tej dyrektywy przez twórców OpenVPN stanowi wybitny przykład elegancji inżynierskiej, rozwiązujący fundamentalny problem pętli routingu.

Gdyby OpenVPN po prostu podmienił domyślną bramę 0.0.0.0/0 w systemie operacyjnym klienta na adres tunelu, komputer natychmiast straciłby łączność z samym serwerem VPN (ponieważ pakiety transportowe UDP/TCP tunelu próbowałyby lecieć przez ten sam tunel). Aby temu zapobiec, flaga def1 stosuje matematyczną zasadę najdłuższego dopasowania prefiksu (Longest Prefix Match).

Zamiast modyfikować trasę domyślną, OpenVPN instaluje dwie mniejsze trasy obejmujące dokładnie cały Internet: 0.0.0.0/1 oraz 128.0.0.0/1, skierowane do wirtualnego interfejsu TUN. Ponieważ maska 1-bitowa jest węższa niż maska 0-bitowa trasy domyślnej, cały ruch internetowy trafia do tunelu. Jednocześnie system zachowuje oryginalną bramę fizyczną oraz dodaje jawną trasę z maską /32 dla publicznego adresu serwera VPN, gwarantując idealną stabilność połączenia.

Wyjaśnienie skrótów użytych na slajdzie:
DLP - Data Loss Prevention - Systemy zapobiegania wyciekowi poufnych danych korporacyjnych.
TUN - Network TUNnel - Wirtualny interfejs sieciowy.
UDP - User Datagram Protocol - Protokół transportowy nośnika tunelu.
IP - Internet Protocol - Protokół warstwy sieciowej.

19/40 Kompresja danych a bezpieczeństwo (VORACLE)
Krytyczna ocena ryzyka bezpieczeństwa związanego z kompresją danych w tunelach szyfrowanych oraz analiza ataku VORACLE.
  • Historycznie popularne parametry (np. comp-lzo) są obecnie odradzane.
  • Podatność VORACLE: Atakujący może wyciągnąć informacje o zaszyfrowanej treści, analizując różnice w stopniu kompresji wstrzykniętych danych.
  • Zalecenie: Wyłącz kompresję dla zwiększenia bezpieczeństwa kryptograficznego.
  • Błąd "Bad Compression Stub" świadczy o niezgodności ustawień kompresji między klientem a serwerem.
Atak VORACLE (CVE-2018-3977): Kryptograficzny atak z wyrocznią kompresji ujawniony w 2018 roku, pozwalający podsłuchującemu napastnikowi na odzyskanie poufnych danych (np. ciasteczek sesyjnych HTTP) przesyłanych w kompresowanym tunelu VPN.
Slide 19

Przez wiele lat powszechną praktyką inżynierską przy konfigurowaniu serwerów OpenVPN było włączanie kompresji danych za pomocą dyrektyw comp-lzo lub compress lz4. Motywacją administratorów była chęć oszczędzania cennego pasma łączy telekomunikacyjnych oraz przyspieszenie transferu nieskompresowanych dokumentów tekstowych i plików bazodanowych. Szczegółowe informacje normatywne i techniczne publikuje Baza podatności NVD NIST (Podatność VORACLE).

W 2018 roku badacz bezpieczeństwa Ahamed Nafeez zaprezentował przełomowy wektor ataku znany jako VORACLE (oznaczony oficjalnym identyfikatorem podatności CVE-2018-3977). Atak ten udowodnił, że łączenie bezstratnej kompresji danych z szyfrowaniem symetrycznym stwarza śmiertelne zagrożenie dla poufności transmisji.

Zasada działania ataku VORACLE bazuje na analizie rozmiaru szyfrogramu. Algorytmy kompresji (np. LZO, Deflate) redukują rozmiar danych poprzez zastępowanie powtarzających się ciągów bajtów krótkimi odnośnikami. Jeżeli napastnik jest w stanie wstrzyknąć kontrolowany przez siebie kod do przeglądarki ofiary (np. poprzez złośliwy skrypt JavaScript na odwiedzanej stronie HTTP), może wymusić wysłanie żądania zawierającego zgadywany fragment poufnego ciasteczka sesyjnego.

Gdy zgadywany ciąg jest identyczny z prawdziwym ciasteczkiem, kompresor odnajduje powtórzenie i rozmiar skompresowanego pakietu maleje. Mimo że cały pakiet jest zaszyfrowany silnym szyfrem AES, podsłuchujący napastnik widzi zmianę długości pakietu na łączu fizycznym, co pozwala na odzyskanie pełnego ciasteczka bajt po bajcie. W rezultacie twórcy OpenVPN oficjalnie uznali kompresję za niebezpieczną i kategorycznie nakazali jej całkowite wyłączenie w nowoczesnych wdrożeniach.

Wyjaśnienie skrótów użytych na slajdzie:
VORACLE - Variable Oracle Attack on Compressed Encrypted Streams - Atak kryptoanalityczny wykorzystujący wyciek rozmiaru kompresji.
CVE - Common Vulnerabilities and Exposures - Globalny rejestr zidentyfikowanych podatności bezpieczeństwa.
LZO - Lempel-Ziv-Oberhumer - Algorytm bezstratnej kompresji danych.
AES - Advanced Encryption Standard - Symetryczny szyfr blokowy.
HTTP - Hypertext Transfer Protocol - Protokół przesyłania danych w sieci WWW.

20/40 Zastosowania w środowiskach Cloud
Przegląd wzorców architektonicznych wykorzystania OpenVPN w środowiskach chmur obliczeniowych (AWS, Azure, GCP).
  • OpenVPN jest idealny do łączenia infrastruktur chmurowych (AWS, Azure, GCP).
  • Ponieważ bazuje na standardowym ruchu UDP/TCP, nie napotyka barier na zaporach chmurowych, które często blokują specyficzne protokoły takie jak ESP (IPSec) czy Protocol 47 (GRE).
  • Wystarczy otwarcie jednego portu w tzw. grupie bezpieczeństwa (Security Group) dostawcy.
Brama Cloud VPN (Cloud VPN Gateway): Zwirtualizowana instancja serwera VPN wdrożona wewnątrz chmury publicznej, zapewniająca bezpieczny, szyfrowany dostęp do prywatnych podsieci wirtualnych (VPC/VNet).
Slide 20

Masowa migracja infrastruktury przedsiębiorstw do chmur publicznych (Amazon Web Services - AWS, Microsoft Azure, Google Cloud Platform - GCP) stworzyła nowe, krytyczne wyzwania w zakresie bezpiecznego zarządzania zasobami obliczeniowymi. Wystawianie interfejsów zarządzających serwerów bazodanowych i aplikacyjnych na publiczne adresy IP jest kategorycznym błędem bezpieczeństwa. Szczegółowe informacje normatywne i techniczne publikuje Portal Gov.pl Cyfryzacja.

W nowoczesnych architekturach chmurowych technologia OpenVPN jest powszechnie stosowana do budowy bezpiecznych węzłów dostępowych (Bastion VPN / Cloud Gateway) zlokalizowanych wewnątrz prywatnych chmur wirtualnych (Virtual Private Cloud - VPC). Wirtualna maszyna z serwerem OpenVPN posiada interfejs publiczny oraz interfejs w prywatnej podsieci chmurowej.

Pracownicy działów inżynierii i rozwoju oprogramowania (DevOps) łączą się z bramą OpenVPN za pomocą jednolitych profili .ovpn zintegrowanych z korporacyjnym dostawcą tożsamości (IdP) przez protokoły SAML lub OAuth2. Po pomyślnym zestawieniu tunelu uzyskują bezpośredni dostęp do prywatnej adresacji maszyn wirtualnych i klastrów Kubernetes bez narażania ich na ataki ze strony publicznego Internetu.

Dodatkową zaletą OpenVPN w chmurze jest możliwość zestawiania szyfrowanych połączeń tranzytowych pomiędzy różnymi regionami lub różnymi dostawcami chmurowymi (Multi-Cloud Interconnect) za ułamek kosztów dedykowanych łączy operatorskich, zapewniając pełną elastyczność i skalowalność środowiska IT.

Wyjaśnienie skrótów użytych na slajdzie:
VPC - Virtual Private Cloud - Logicznie wydzielona prywatna sieć w chmurze obliczeniowej.
AWS - Amazon Web Services - Platforma usług chmurowych firmy Amazon.
GCP - Google Cloud Platform - Platforma usług chmurowych firmy Google.
IdP - Identity Provider - Dostawca tożsamości pośredniczący w autoryzacji.
SAML - Security Assertion Markup Language - Otwarty standard wymiany danych uwierzytelniających.

21/40 CCD: personalizacja konfiguracji klienta
Instruktaż wdrażania mechanizmu Client Config Directory (CCD) do granulacji uprawnień, statycznej adresacji IP i izolacji klientów OpenVPN.
  • CCD (Client Config Directory): Pozwala na przypisanie unikalnych ustawień (np. konkretnego IP lub tras) dla specyficznego użytkownika.
  • W folderze CCD tworzymy plik o nazwie identycznej z Common Name (CN) certyfikatu klienta.
  • Daje to administratorowi pełną kontrolę nad granulacją uprawnień - np. dział HR dostaje dostęp tylko do serwera kadr, a dział IT do całej infrastruktury.
Katalog konfiguracji klienta (Client Config Directory - CCD): Katalog na serwerze OpenVPN zawierający indywidualne pliki konfiguracyjne odpowiadające nazwom w polu Common Name certyfikatów klientów, aplikowane dynamicznie w trakcie logowania.
Slide 21

W rozbudowanych środowiskach korporacyjnych rzadko występuje sytuacja, w której wszyscy pracownicy powinni posiadać identyczne uprawnienia sieciowe i dostęp do tych samych zasobów. Do realizacji zasady najmniejszych przywilejów (Principle of Least Privilege) w technologii OpenVPN służy mechanizm Client Config Directory (CCD). Szczegółowe informacje normatywne i techniczne publikuje Oficjalna dokumentacja referencyjna OpenVPN 2.6.

Mechanizm aktywuje się w pliku server.conf za pomocą dyrektywy client-config-dir /etc/openvpn/ccd. W wyznaczonym katalogu administrator tworzy zwykłe pliki tekstowe, których nazwy muszą dokładnie odpowiadać wartości pola Common Name (CN) zawartej w certyfikacie X.509 danego użytkownika (np. plik o nazwie jan.kowalski).

Wewnątrz pliku CCD administrator może zdefiniować dedykowany, statyczny adres IP przydzielany danemu pracownikowi za pomocą dyrektywy ifconfig-push 10.8.0.50 255.255.255.0. Pozwala to na precyzyjne wiązanie tożsamości użytkownika ze stałym adresem IP na potrzeby audytów oraz tworzenia ścisłych reguł zapory ogniowej w łańcuchu forward.

Co więcej, plik CCD pozwala na selektywne rozgłaszanie tras routingu. Zwykły pracownik może otrzymać wyłącznie dostęp do serwera pocztowego (push "route 192.168.10.5 255.255.255.255"), podczas gdy administrator systemów w swoim pliku CCD otrzymuje pełny dostęp do wszystkich podsieci serwerowych i konsol zarządzających, gwarantując precyzyjną segmentację.

Wyjaśnienie skrótów użytych na slajdzie:
CCD - Client Config Directory - Katalog indywidualnych profili konfiguracyjnych klientów.
CN - Common Name - Pole tożsamości w certyfikacie X.509 powiązane z plikiem CCD.
IP - Internet Protocol - Protokół warstwy internetowej.
CLI - Command Line Interface - Interfejs wiersza poleceń serwera.

22/40 Skrypty Up/Down - automatyzacja lokalna
Przedstawienie mechanizmów integracji skryptów zdarzeniowych Up i Down w cyklu życia połączenia OpenVPN.
  • Możliwość automatycznego uruchamiania zadań w systemie po zmianie statusu połączenia.
  • Scenariusze:
    • Automatyczne mapowanie dysków sieciowych po udanym logowaniu.
    • Dynamiczne czyszczenie tablic routingu po rozłączeniu.
    • Powiadomienia administratora (np. przez e-mail/Slack) o nowej sesji.
Skrypty zdarzeniowe OpenVPN (Event-Driven Hook Scripts): Programy lub skrypty powłoki uruchamiane automatycznie przez proces OpenVPN w kluczowych momentach cyklu życia tunelu, takich jak podniesienie interfejsu (up) lub jego zamknięcie (down).
Slide 22

Zarządzanie zaawansowaną infrastrukturą sieciową często wymaga wykonania dodatkowych operacji w systemie operacyjnym w momencie nawiązania lub zerwania połączenia VPN: dynamicznej rekonfiguracji reguł zapory ogniowej, modyfikacji ustawień serwerów nazw w mechanizmie resolvconf czy wysłania powiadomienia do systemów monitoringu SIEM. Szczegółowe informacje normatywne i techniczne publikuje Projekt Netfilter / Iptables.

Technologia OpenVPN dostarcza wbudowane haki zdarzeniowe (Hooks) definiowane za pomocą dyrektyw up /path/to/script.sh oraz down /path/to/script.sh. Skrypt zdefiniowany w dyrektywie up jest wykonywany natychmiast po pomyślnym utworzeniu wirtualnego interfejsu TUN/TAP, otrzymując jako argumenty nazwę interfejsu, rozmiar MTU oraz przydzielony adres IP.

W systemach linuksowych skrypty te są powszechnie wykorzystywane do integracji z demonem systemd-resolved w celu dynamicznego przełączania serwerów DNS oraz rejestrowania tras routingu w dedykowanych tablicach routingu (Policy Routing). Z kolei skrypt down odpowiada za posprzątanie środowiska sieciowego po zamknięciu tunelu, usuwając tymczasowe reguły zapory i przywracając stan pierwotny.

Ze względów bezpieczeństwa wykonywanie zewnętrznych skryptów jest domyślnie ograniczone przez dyrektywę script-security. Aby serwer lub klient mógł uruchamiać skrypty modyfikujące parametry sieciowe, administrator musi jawnie zdefiniować poziom script-security 2, co zapobiega nieautoryzowanemu wykonywaniu złośliwego kodu przekazanego w niezweryfikowanych opcjach.

Wyjaśnienie skrótów użytych na slajdzie:
DNS - Domain Name System - System nazw domenowych modyfikowany przez skrypty up.
SIEM - Security Information and Event Management - System centralnego zarządzania informacjami o bezpieczeństwie.
TUN - Network TUNnel - Wirtualny interfejs sieciowy.
MTU - Maximum Transmission Unit - Maksymalny rozmiar jednostki danych.

23/40 Integracja z MFA (uwierzytelnianie wieloskładnikowe)
Przewodnik po architekturze i konfiguracji uwierzytelniania wieloskładnikowego MFA w OpenVPN w oparciu o standard TOTP (RFC 6238).
  • Wsparcie dla wtyczek (Plugins) umożliwia integrację z systemami OTP (One-Time Password).
  • Najpopularniejsze: integracja z Google Authenticator lub serwerami RADIUS/AD.
  • Użytkownik przy logowaniu dopisuje dynamiczny kod z aplikacji mobilnej do swojego stałego hasła.
  • Gwarantuje to bezpieczeństwo nawet w przypadku kradzieży fizycznego klucza i hasła.
Uwierzytelnianie wieloskładnikowe MFA (Multi-Factor Authentication): Mechanizm kontroli dostępu wymagający od użytkownika przedstawienia co najmniej dwóch niezależnych kategorii dowodów tożsamości: wiedzy (hasło), posiadania (klucz/token TOTP) lub cechy biometrycznej.
Slide 23

We współczesnym krajobrazie cyberzagrożeń tradycyjne uwierzytelnianie oparte wyłącznie na nazwie użytkownika i haśle jest uznawane przez agencje cyberbezpieczeństwa za dalece niewystarczające. Kompromitacja stacji roboczej przez złośliwe oprogramowanie rejestrujące klawiaturę (Keylogger) lub ataki socjotechniczne (Phishing) pozwalają napastnikowi na natychmiastowe przejęcie poświadczeń VPN. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 6238 (Algorytm TOTP dla MFA).

Wdrożenie uwierzytelniania wieloskładnikowego (MFA) w technologii OpenVPN eliminuje to ryzyko poprzez wymuszenie podania dynamicznego, jednorazowego kodu weryfikacyjnego. Najpopularniejszym standardem przemysłowym jest algorytm Time-Based One-Time Password (TOTP), zdefiniowany w dokumencie RFC 6238, generujący 6-cyfrowy kod odnawiany co 30 sekund w aplikacji mobilnej (np. Google Authenticator, Microsoft Authenticator).

W środowisku serwera OpenVPN integrację realizuje się za pomocą modułu PAM (Pluggable Authentication Modules) i biblioteki libpam-google-authenticator, powiązanej z dyrektywą plugin /usr/lib/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn. Podczas logowania użytkownik wpisuje w polu hasła swoje stałe hasło domenowe z doklejonym na końcu bieżącym kodem TOTP (np. MojeHaslo123!482910).

Moduł serwerowy rozdziela ciąg, weryfikuje hasło w bazie katalogowej oraz potwierdza poprawność kodu czasowego za pomocą symetrycznego sekretu użytkownika. Połączenie certyfikatu cyfrowego na stacji roboczej (coś co masz jako sprzęt), hasła (coś co znasz) oraz kodu TOTP (coś co generujesz w telefonie) tworzy trójskładnikowy, niezwykle trudny do sforsowania mechanizm uwierzytelniania korporacyjnego.

Wyjaśnienie skrótów użytych na slajdzie:
MFA - Multi-Factor Authentication - Uwierzytelnianie wieloskładnikowe podnoszące poziom ochrony.
TOTP - Time-Based One-Time Password - Standard dynamicznych haseł jednorazowych bazujących na czasie (RFC 6238).
PAM - Pluggable Authentication Modules - Modularny podsystem uwierzytelniania w systemach Linux.
RFC - Request for Comments - Dokument standaryzacyjny komitetu IETF.

24/40 OpenVPN Access Server (wersja komercyjna)
Przedstawienie właściwości i różnic architektonicznych pomiędzy darmową wersją Community a komercyjnym pakietem OpenVPN Access Server.
  • Rozwiązanie korporacyjne z gotowym Panelem Administracyjnym (GUI).
  • Darmowa licencja pozwala na 2 jednoczesne połączenia (idealne do nauki/testów).
  • Główna zaleta: intuicyjne zarządzanie certyfikatami i użytkownikami bez konieczności pracy w konsoli Linuksa.
  • Udostępnia portal Web dla użytkowników, skąd mogą pobrać prekonfigurowane paczki instalacyjne.
OpenVPN Access Server (OpenVPN AS): Komercyjny, gotowy do wdrożenia pakiet oprogramowania firmy OpenVPN Inc., integrujący silnik OpenVPN z graficznym panelem zarządzania WWW, portalem samoobsługowym dla użytkowników oraz wbudowaną integracją z domenami LDAP/AD.
Slide 24

Poza bezpłatną, otwartoźródłową wersją OpenVPN Community Edition, firma OpenVPN Inc. rozwija i oferuje komercyjny pakiet oprogramowania znany jako OpenVPN Access Server (OpenVPN AS). Rozwiązanie to zostało zaprojektowane z myślą o przedsiębiorstwach poszukujących gotowej do użycia platformy VPN z graficznym interfejsem zarządzania. Szczegółowe informacje normatywne i techniczne publikuje Portal pakietu OpenVPN Access Server.

Kluczową zaletą Access Servera jest kompletny panel administracyjny dostępny przez przeglądarkę WWW (Admin Web UI). Pozwala on administratorom na wizualne konfigurowanie podsieci, zarządzanie trasami, definiowanie polityk dostępowych oraz monitorowanie aktywnych sesji bez konieczności ręcznego edytowania plików konfiguracyjnych w konsoli tekstowej Linuksa.

Drugim istotnym komponentem jest portal samoobsługowy dla pracowników (Client Web UI). Użytkownik loguje się do portalu swoimi poświadczeniami domenowymi Active Directory lub kontem Google Workspace, po czym może bezpośrednio pobrać dedykowanego klienta z automatycznie wygenerowanym, kompletnym profilem .ovpn zawierającym wszystkie niezbędne certyfikaty i klucze, co całkowicie eliminuje potrzebę ręcznej dystrybucji plików.

OpenVPN Access Server jest dystrybuowany w modelu licencyjnym opartym na liczbie jednocześnie połączonych urządzeń (wersja bezpłatna pozwala na maksymalnie dwa jednoczesne połączenia testowe). Dla większych organizacji komercyjny pakiet oferuje wbudowaną obsługę klastrowania wysokiej dostępności (Active/Active Cluster) oraz bezpośrednią integrację z systemami RADIUS i SAML.

Wyjaśnienie skrótów użytych na slajdzie:
AS - Access Server - Komercyjny serwer dostępowy OpenVPN.
LDAP - Lightweight Directory Access Protocol - Protokół dostępu do usług katalogowych.
AD - Active Directory - Usługa katalogowa firmy Microsoft.
UI - User Interface - Interfejs graficzny użytkownika.

25/40 Diagnostyka: błąd "TLS Error"
Metodyka diagnozowania i eliminacji krytycznych błędów negocjacji kryptograficznej sygnalizowanych komunikatem 'TLS Error'.
  • Komunikat: TLS key negotiation failed to occur within 60 seconds.
  • Interpretacja: Pakiety klienta nie uzyskują odpowiedzi od serwera.
  • Przyczyny:
    • Zapora (Firewall) blokuje port UDP 1194.
    • Niezgodność protokołów (np. klient próbuje TCP, serwer nasłuchuje na UDP).
    • Błędny klucz TLS-Auth (jeśli włączony).
Błąd negocjacji TLS (TLS Handshake Failure): Krytyczny błąd połączenia w technologii OpenVPN oznaczający niemożność pomyślnego zakończenia wymiany komunikatów kryptograficznych w kanale sterowania z przyczyn certyfikatowych, sieciowych lub klucza TLS-Auth.
Slide 25

Komunikat w dzienniku zdarzeń o treści TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) należy do najczęstszych problemów diagnostycznych w eksploatacji OpenVPN. Błąd ten informuje, że aplikacja kliencka wysłała inicjujące pakiety sterujące, lecz nie zdołała sfinalizować bezpiecznego kanału TLS z serwerem. Szczegółowe informacje normatywne i techniczne publikuje Projekt OpenSSL.

Najpowszechniejszą przyczyną tego problemu jest blokada ruchu warstwy transportowej na trasie transmisyjnej. Jeżeli serwer nasłuchuje na porcie UDP 1194, a lokalny dostawca Internetu lub zapora ogniowa odrzuca pakiety UDP, pakiety powitalne klienta nigdy nie docierają do celu. Weryfikację przeprowadza się poprzez czasowe przełączenie na port TCP 443 lub inspekcję reguł zapory na serwerze za pomocą narzędzia tcpdump.

Drugą powszechną przyczyną jest rozbieżność w konfiguracji mechanizmu TLS-Auth lub TLS-Crypt. Jeżeli serwer posiada aktywną dyrektywę tls-auth ta.key 0, a w pliku konfiguracyjnym klienta brakuje odpowiadającej linii tls-auth ta.key 1 (lub użyto innego, niezgodnego pliku klucza), serwer cicho porzuca wszystkie przychodzące pakiety bez generowania jakiejkolwiek odpowiedzi, co klient interpretuje jako przekroczenie limitu czasu.

Trzecim źródłem błędu TLS jest problem z weryfikacją tożsamości podmiotu w certyfikacie X.509. Jeżeli w pliku klienta umieszczono dyrektywę remote-cert-tls server, a certyfikat serwera nie posiadał w rozszerzeniu pola Extended Key Usage flagi TLS Web Server Authentication, klient natychmiast zerwie sesję ze względów bezpieczeństwa.

Wyjaśnienie skrótów użytych na slajdzie:
TLS - Transport Layer Security - Kryptograficzny protokół warstwy transportowej.
UDP - User Datagram Protocol - Bezpołączeniowy protokół transportowy.
EKU - Extended Key Usage - Rozszerzenie certyfikatu X.509 definiujące dozwolone zastosowania klucza.
CLI - Command Line Interface - Interfejs wiersza poleceń używany do diagnostyki.

26/40 Diagnostyka: pętle routingu (Routing Loop)
Identyfikacja mechanizmów powstawania pętli routingu przy pełnym tunelowaniu oraz procedury przywracania prawidłowego przekazywania pakietów.
  • Błąd logiczny: Próba skierowania ruchu do publicznego adresu serwera przez ten sam tunel, który go tworzy.
  • OpenVPN zazwyczaj dodaje automatyczny wyjątek (/32) dla adresu IP serwera, ale błędy w statycznym routingu mogą doprowadzić do zawieszenia sesji (tzw. incepcja pakietu szyfrowanego w szyfrowanym).
Pętla routingu VPN (VPN Routing Loop): Anomalny stan tablicy routingu stacji roboczej, w którym pakiety transportowe niosące zaszyfrowany tunel VPN są kierowane do wnętrza tego samego tunelu, powodując natychmiastowe zamrożenie komunikacji sieciowej.
Slide 26

Zjawisko pętli routingu (Routing Loop) w technologii OpenVPN występuje najczęściej podczas wdrażania modelu pełnego tunelowania (dyrektywa redirect-gateway). Pętla pojawia się w momencie, gdy system operacyjny klienta błędnie skieruje pakiety transportowe UDP/TCP, w których hermetyzowany jest tunel, do wnętrza wirtualnego interfejsu TUN. Szczegółowe informacje normatywne i techniczne publikuje Rejestr protokołów IANA.

W takiej sytuacji dochodzi do katastrofalnego zapętlenia logicznego: aby wysłać pakiet przez tunel, proces OpenVPN musi nadać zaszyfrowany datagram UDP zaadresowany do publicznego IP serwera. Jeśli tablica routingu nakazuje wysyłać cały ruch przez bramę tunelu, pakiet UDP trafia z powrotem do interfejsu TUN, proces próbuje go ponownie zaszyfrować i wysłać, co prowadzi do natychmiastowego wysycenia buforów i całkowitej utraty łączności.

Prawidłowa implementacja pełnego tunelowania w OpenVPN musi bezwzględnie instalować w tablicy routingu klienta jawną trasę statyczną dla publicznego adresu IP serwera VPN z maską /32, wskazującą jako bramę oryginalny router fizyczny w sieci lokalnej (np. bramę domowego routera Wi-Fi). Trasa ta, posiadając najwęższy możliwy prefiks (/32), ma bezwzględny priorytet nad trasami ogólnymi.

W przypadku ręcznego konfigurowania tras administrator musi upewnić się, że żadna dyrektywa push "route ..." nie obejmuje podsieci publicznej, w której znajduje się interfejs serwera OpenVPN. Do diagnostyki pętli służy analiza tablicy routingu poleceniem ip route show na Linuksie lub route print w systemie Windows.

Wyjaśnienie skrótów użytych na slajdzie:
TUN - Network TUNnel - Wirtualny interfejs sieciowy.
UDP - User Datagram Protocol - Protokół warstwy transportowej.
IP - Internet Protocol - Protokół warstwy sieciowej.
FIB - Forwarding Information Base - Sprzętowa tablica przekazywania pakietów.

27/40 Problemy z czasem systemowym (Clock Skew)
Wyjaśnienie wpływu desynchronizacji zegarów systemowych na proces walidacji certyfikatów X.509 w OpenVPN.
  • Diagnostyka zaburzeń transmisyjnych w tunelach OpenVPN obejmuje dwa krytyczne zjawiska:
  • 1. Pętle routingu i utrata łączności:
    • Występuje, gdy trasa do publicznego IP serwera OpenVPN zostaje przekierowana do interfejsu tunelu tun0.
    • Weryfikacja: Analiza tablicy routingu (ip route show na Linuksie lub route print w Windows) - trasa hostowa /32 do publicznego IP bramy VPN musi bezwzględnie wskazywać bramę lokalną (interfejs fizyczny).
  • 2. Zjawisko 'Black Hole MTU' i fragmentacja pakietów:
    • Narzut nagłówków tunelu (IP + UDP + OpenVPN + TLS MAC/Tag) zmniejsza efektywną jednostkę MTU z 1500 bajtów do około 1420 bajtów.
    • Rozwiązanie inżynierskie: Bezwzględne wdrożenie mechanizmu MSS Clamping za pomocą dyrektywy mssfix 1400 w konfiguracji serwera i klienta, co zmusza sesje TCP do obniżenia parametru MSS i całkowicie eliminuje fragmentację pakietów.
Rozbieżność zegarów (Clock Skew): Różnica pomiędzy czasem wskazywanym przez zegar systemowy stacji klienckiej a czasem serwera VPN, prowadząca do błędów walidacji okresu ważności certyfikatów cyfrowych (notBefore / notAfter).
Slide 27

Wielu początkujących inżynierów sieciowych nie zdaje sobie sprawy, jak krytyczną rolę w bezpieczeństwie i poprawnym działaniu protokołu OpenVPN odgrywa precyzyjna synchronizacja czasu systemowego. Certyfikaty cyfrowe standardu X.509 posiadają ściśle zdefiniowane ramy czasowe ważności: datę początkową (notBefore) oraz datę wygaśnięcia (notAfter). Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 5905 (Protokół NTP).

W sytuacji, gdy zegar na stacji roboczej klienta lub na serwerze VPN ulegnie rozsynchronizowaniu (np. z powodu rozładowania baterii podtrzymującej zegar RTC na płycie głównej lub błędnej konfiguracji strefy czasowej), proces walidacji kryptograficznej kończy się natychmiastowym fiaskiem. Typowym objawem jest komunikat błędu biblioteki OpenSSL: Certificate is not yet valid lub Certificate has expired.

Błąd typu not yet valid występuje bardzo często na świeżo wdrożonych serwerach: administrator generuje certyfikaty na maszynie z poprawnym czasem, a klient próbujący połączyć się z routera bez zsynchronizowanego czasu (który po resecie wystartował z datą 1 stycznia 1970 roku) odrzuca certyfikat serwera jako pochodzący z dalekiej przyszłości.

Z tego względu bezwzględnym wymogiem inżynierskim dla każdego serwera i klienta OpenVPN jest uruchomienie automatycznej synchronizacji czasu za pomocą protokołu Network Time Protocol (NTP, RFC 5905). W systemie MikroTik RouterOS odpowiada za to pakiet ntp lub sntp (/system ntp client set enabled=yes servers=pool.ntp.org), co gwarantuje milisekundową zgodność zegarów.

Wyjaśnienie skrótów użytych na slajdzie:
NTP - Network Time Protocol - Protokół sieciowy synchronizacji czasu zegarów komputerowych.
RTC - Real-Time Clock - Sprzętowy zegar czasu rzeczywistego zasilany bateria.
SSL - Secure Sockets Layer - Biblioteka weryfikująca ramy czasowe certyfikatów.
RFC - Request for Comments - Dokument standaryzacyjny komitetu IETF.

28/40 Analiza logów systemowych
Metodyka inspekcji dzienników zdarzeń OpenVPN oraz sterowanie poziomem szczegółowości za pomocą parametru verb.
  • Parametr verb reguluje poziom szczegółowości logów (standardowo 3).
  • W przypadku problemów zwiększamy poziom do 5 lub 6.
  • Podgląd w MikroTik: /system logging add topics=ovpn,debug.
  • Logi są pierwszym miejscem, w którym widać różnice w szyfrach lub błędy autoryzacji.
Poziom szczegółowości logowania (Verbosity Level - verb): Dyrektywa konfiguracyjna w OpenVPN przyjmująca wartości od 0 do 11, regulująca ilość informacji diagnostycznych i komunikatów debugowania generowanych do dziennika systemowego.
Slide 28

Podstawowym i najważniejszym narzędziem inżyniera sieciowego w procesie usuwania awarii (Troubleshooting) systemu OpenVPN jest szczegółowa analiza dzienników zdarzeń generowanych przez demona. OpenVPN oferuje wyjątkowo precyzyjny mechanizm logowania, sterowany dyrektywą verb w pliku konfiguracyjnym. Szczegółowe informacje normatywne i techniczne publikuje CSIRT NASK / CERT Polska.

Domyślnym poziomem w środowiskach produkcyjnych jest verb 3. Zapewnia on optymalny kompromis: rejestruje zdarzenia nawiązania i zerwania sesji, przydzielone adresy IP, błędy certyfikatów oraz ostrzeżenia sieciowe bez niepotrzebnego zapychania dysku tysiącami komunikatów o każdym pakiecie.

W trakcie diagnozowania trudnych problemów z zestawianiem sesji TLS administrator powinien tymczasowo podnieść poziom do verb 4 lub verb 5. Poziom 4 wyświetla parametry negocjacji kryptograficznej i opcje wymiany R/W, natomiast poziom 5 uwidacznia powtarzane pakiety sterujące. Poziomy powyżej 6 (np. verb 7 lub 9) są przeznaczone wyłącznie dla programistów badających kod źródłowy, ponieważ zrzucają surowe heksadecymalne zawartości pakietów i kluczy.

W systemach linuksowych logi OpenVPN trafiają do dziennika systemd (dostępnego za pomocą journalctl -u openvpn-server@server -f) lub do dedykowanego pliku wskazanego dyrektywami log /var/log/openvpn.log oraz status /var/log/openvpn-status.log. Plik statusu jest szczególnie przydatny, ponieważ w czytelnym formacie tabelarycznym prezentuje listę aktualnie połączonych klientów, ich publiczne adresy IP, przydzieloną adresację wirtualną oraz liczbę przesłanych bajtów.

Wyjaśnienie skrótów użytych na slajdzie:
CLI - Command Line Interface - Interfejs wiersza poleceń.
TLS - Transport Layer Security - Warstwa bezpieczeństwa, której komunikaty są logowane.
SIEM - Security Information and Event Management - System centralnego monitorowania logów korporacyjnych.

29/40 Charakterystyka wydajnościowa
Analiza ograniczeń wydajnościowych jednowątkowej architektury OpenVPN oraz metody ich przezwyciężania za pomocą DCO.
  • OpenVPN jest natywnie jednowątkowy.
  • Cała obsługa wszystkich klientów wykonuje się na jednym rdzeniu procesora.
  • Na domowych routerach SOHO ze słabym CPU wydajność często nie przekracza 30 Mbps.
  • Stąd bierze się popularność protokołu WireGuard, który jest wielowątkowy i lżejszy.
Architektura jednowątkowa (Single-Threaded Process Architecture): Model wykonawczy aplikacji, w którym cały proces obsługi zdarzeń sieciowych, szyfrowania i dekapsulacji pakietów jest realizowany przez pojedynczy wątek roboczy procesora.
Slide 29

Zrozumienie charakterystyki wydajnościowej OpenVPN wymaga uwzględnienia jego wewnętrznej architektury wykonawczej. Tradycyjny demon OpenVPN jest aplikacją ściśle jednowątkową (Single-Threaded). Oznacza to, że pojedyncza instancja serwera może w danym momencie wykorzystywać zasoby obliczeniowe tylko jednego fizycznego rdzenia procesora, niezależnie od tego, czy serwer posiada procesor 4-, 16- czy 64-rdzeniowy. Szczegółowe informacje normatywne i techniczne publikuje Dokumentacja podsystemów jądra Linux.

W konsekwencji maksymalna przepustowość pojedynczego tunelu jest ograniczona wydajnością pojedynczego wątku (Single-Core IPC) danego procesora oraz narzutem przełączania kontekstu do przestrzeni użytkownika. Na starszych maszynach lub wirtualnych instancjach chmurowych pojedyncza instancja OpenVPN osiągała przepustowości rzędu 200-400 Mb/s, co przy łączach gigabitowych stanowiło wąskie gardło infrastruktury.

Tradycyjnym obejściem tego ograniczenia było uruchamianie wielu równoległych instancji OpenVPN na różnych portach (np. 1194, 1195, 1196), powiązanych z różnymi rdzeniami CPU za pomocą powinowactwa procesora (CPU Affinity) i równoważonych za pomocą reguł zapory ogniowej lub zewnętrznego load balancera.

Prawdziwą rewolucję przyniosło wprowadzenie technologii OpenVPN Data Channel Offload (DCO). DCO implementuje moduł jądra ovpn-dco, który przejmuje przetwarzanie pakietów kanału danych bez opuszczania przestrzeni jądra. Dzięki temu szyfrowanie AES-GCM i przełączanie pakietów jest wielowątkowe i odciążone, pozwalając na osiąganie przepustowości przekraczających 5-10 Gb/s przy minimalnym obciążeniu procesora.

Wyjaśnienie skrótów użytych na slajdzie:
DCO - Data Channel Offload - Sprzętowo-jądrowy moduł odciążania pakietów w OpenVPN.
CPU - Central Processing Unit - Główny procesor obliczeniowy serwera.
IPC - Instructions Per Cycle - Liczba instrukcji wykonywanych przez rdzeń procesora w jednym cyklu zegara.
AES-GCM - Advanced Encryption Standard Galois Counter Mode - Szyfr blokowy AEAD.

30/40 Swoistość implementacji w MikroTik
Przegląd specyficznych cech, zalet i ograniczeń podsystemu OpenVPN w systemie MikroTik RouterOS v7.
  • Pamiętaj: o ograniczeniach starszych wersji (brak UDP w RouterOS v6).
  • Przy konfiguracji klienta pod router MikroTik, zawsze wyłączaj kompresję LZO w pliku .ovpn (nie jest wspierana).
  • Wersja 7 wprowadziła długo oczekiwany Hardware Offload dla szyfrowania w niektórych modelach.
Implementacja MikroTik OVPN (RouterOS OVPN Proprietary Nuances): Zbiór cech funkcjonalnych podsystemu OpenVPN w RouterOS, odróżniający go od standardowych instalacji linuksowych pod względem konfiguracji, obsługi protokołów i zarządzania klientami.
Slide 30

Wdrażanie serwerów oraz klientów OpenVPN na platformie sprzętowej MikroTik wymaga od inżyniera precyzyjnej znajomości specyfiki systemu RouterOS. Mimo że w wersji RouterOS v7 dodano kluczowe wsparcie dla protokołu UDP oraz nowoczesnych szyfrów, pewne elementy konfiguracji wciąż różnią się od standardowego demona openvpn znanego z systemów Linux. Szczegółowe informacje normatywne i techniczne publikuje Oficjalna pomoc techniczna MikroTik.

W systemie RouterOS OpenVPN jest ściśle zintegrowany z mechanizmami podsystemu Point-to-Point Protocol (PPP). Każde zestawiane połączenie tworzy dynamiczny interfejs wirtualny , a parametry adresowe, serwery DNS oraz limity pasma (rate-limit) są aplikowane za pośrednictwem profilu PPP (/ppp profile), a nie przez klasyczne linuksowe dyrektywy push.

RouterOS posiada również własne podejście do uwierzytelniania: nie pozwala na nawiązanie połączenia w oparciu o sam certyfikat bez podania loginu i hasła. Nawet jeśli w konfiguracji serwera włączono weryfikację certyfikatu klienta (require-client-certificate=yes), użytkownik musi posiadać odpowiadający mu wpis w bazie sekretów /ppp secret z przypisanym hasłem.

Warto również pamiętać o kwestii kompresji: system RouterOS celowo nie obsługuje kompresji LZO ani LZ4, co stanowi doskonałą decyzję architektoniczną chroniącą użytkowników przed opisanym wcześniej atakiem VORACLE. Konfigurując plik klienta .ovpn do łączenia się z serwerem MikroTik, należy bezwzględnie upewnić się, że wyłączono w nim wszelkie dyrektywy kompresji.

Wyjaśnienie skrótów użytych na slajdzie:
OVPN - OpenVPN - Podsystem tunelowania w systemie RouterOS.
PPP - Point-to-Point Protocol - Podsystem zarządzania sesjami i poświadczeniami w RouterOS.
DNS - Domain Name System - System nazw domenowych.
VORACLE - Variable Oracle Attack on Compressed Encrypted Streams - Atak kryptoanalityczny na kompresowane tunele VPN.

31/40 Krok 1: budowa własnego CA (warsztat)
Praktyczny instruktaż laboratoryjny inicjalizacji środowiska PKI oraz wygenerowania głównego certyfikatu urzędu CA.
  • Użycie Easy-RSA w środowisku Linux/WSL:
  • git clone https://github.com/OpenVPN/easy-rsa.git
cd easy-rsa/easyrsa3
./easyrsa init-pki
./easyrsa build-ca nopass
  • Otrzymujemy: ca.crt (certyfikat publiczny) oraz ca.key (klucz główny - tajny).
Główny urząd certyfikacji CA (Root Certificate Authority): Kotwica zaufania w architekturze PKI; podmiot nadrzędny, którego klucz publiczny służy do weryfikacji tożsamości wszystkich podległych serwerów i klientów w sieci VPN.
Slide 31

Pierwszym krokiem warsztatowym przy budowie bezpiecznego środowiska OpenVPN w systemie operacyjnym Linux (np. Debian lub Ubuntu) jest zainicjowanie dedykowanego centrum certyfikacji za pomocą pakietu Easy-RSA. Zaleca się realizację tej procedury na wydzielonej stacji roboczej lub maszynie wirtualnej. Szczegółowe informacje normatywne i techniczne publikuje Polski Komitet Normalizacyjny.

Procedurę rozpoczyna się od skopiowania szablonów konfiguracyjnych i przejścia do katalogu roboczego: make-cadir ~/openvpn-ca && cd ~/openvpn-ca. W katalogu tym należy utworzyć i dostosować plik vars, definiując parametry organizacyjne certyfikatu: długość klucza (set_var EASYRSA_KEY_SIZE 2048 lub 4096), czas ważności oraz parametry tożsamości kraju i organizacji.

Następnie wykonuje się polecenie inicjalizujące strukturę bazy danych certyfikatów: ./easyrsa init-pki. Polecenie to tworzy czysty katalog pki zawierający szablony indeksów oraz magazyn kluczy. Kluczowym momentem jest wygenerowanie głównej pary kluczy urzędu certyfikacji za pomocą polecenia ./easyrsa build-ca.

Podczas wykonywania tego polecenia inżynier definiuje silne hasło (Passphrase) chroniące klucz prywatny urzędu ca.key oraz wprowadza czytelną nazwę Common Name (np. Korporacja VPN Root CA). W wyniku tej operacji powstaje publiczny certyfikat ca.crt, który będzie dystrybuowany do wszystkich węzłów sieciowych.

Wyjaśnienie skrótów użytych na slajdzie:
CA - Certificate Authority - Główny urząd certyfikacji tożsamości cyfrowej.
PKI - Public Key Infrastructure - Infrastruktura klucza publicznego.
CLI - Command Line Interface - Interfejs wiersza poleceń systemu operacyjnego.
RSA - Rivest-Shamir-Adleman - Asymetryczny algorytm kryptograficzny.

32/40 Krok 2: certyfikacja serwera
Praktyczny przewodnik po generowaniu żądania podpisania, wystawianiu certyfikatu serwera oraz parametrów Diffie-Hellmana.
  • ./easyrsa build-server-full server1 nopass
  • Opcja 'nopass' jest powszechnie stosowana dla usług serwerowych, aby umożliwić ich automatyczny start po restarcie serwera (bez konieczności interwencji administratora).
Certyfikat serwera TLS (TLS Server Certificate): Certyfikat cyfrowy X.509 posiadający rozszerzenie EKU z flagą serverAuth, potwierdzający autentyczność bramy VPN wobec łączących się stacji klienckich.
Slide 32

Po poprawnym zainicjowaniu głównego urzędu certyfikacji kolejnym krokiem warsztatowym jest wygenerowanie certyfikatu tożsamości dla samego serwera dostępowego OpenVPN. W środowisku Easy-RSA operację tę realizuje się za pomocą zintegrowanego polecenia build-server-full. Szczegółowe informacje normatywne i techniczne publikuje Microsoft Learn Sieci Windows Server.

Administrator wykonuje polecenie: ./easyrsa build-server-full server1 nopass. Użycie flagi nopass jest w pełni uzasadnione inżyniersko: eliminuje konieczność wpisywania hasła przy każdym uruchomieniu usługi systemowej OpenVPN, co jest niezbędne dla bezobsługowego startu maszyny po awarii zasilania lub restarcie administracyjnym.

Podczas generowania certyfikatu skrypt Easy-RSA automatycznie dodaje do struktury certyfikatu rozszerzenie Extended Key Usage (EKU) z flagą TLS Web Server Authentication. Flaga ta jest bezwzględnie wymagana przez nowoczesnych klientów OpenVPN (weryfikacja dyrektywą remote-cert-tls server), chroniąc użytkowników przed próbami podszycia się pod serwer przez złośliwego klienta posiadającego zwykły certyfikat użytkownika.

Dodatkowo należy wygenerować parametry kryptograficzne algorytmu Diffie-Hellmana za pomocą polecenia ./easyrsa gen-dh, co tworzy plik dh.pem (standardowo o długości 2048 bitów), oraz wygenerować symetryczny klucz podpisu kanału sterowania openvpn --genkey secret tc.key (dla mechanizmu TLS-Crypt). Komplet plików (ca.crt, server1.crt, server1.key, dh.pem, tc.key) kopiuje się do katalogu /etc/openvpn/server/.

Wyjaśnienie skrótów użytych na slajdzie:
TLS - Transport Layer Security - Standard kryptograficzny serwera.
EKU - Extended Key Usage - Rozszerzenie określające dozwolone zastosowania certyfikatu.
DH - Diffie-Hellman - Plik parametrów wymiany kluczy asymetrycznych.
CLI - Command Line Interface - Wiersz poleceń systemu Linux.

33/40 Krok 3: przygotowanie tożsamości klienta
Procedura generowania kluczy, podpisywania certyfikatu użytkownika oraz budowy jednolitego pliku .ovpn.
  • ./easyrsa build-client-full mobilny_user nopass
  • Dystrybucja plików (Zasada ograniczonego zaufania):
    • Serwer: ca.crt, server1.crt, server1.key.
    • Klient: ca.crt, mobilny_user.crt, mobilny_user.key.
Certyfikat klienta TLS (TLS Client Certificate): Certyfikat cyfrowy X.509 posiadający rozszerzenie EKU z flagą clientAuth, identyfikujący konkretnego pracownika lub urządzenie w procesie dwustronnego uwierzytelniania VPN.
Slide 33

Trzecim etapem prac warsztatowych jest wygenerowanie certyfikatu osobistego dla użytkownika końcowego oraz zintegrowanie wszystkich komponentów w jednolity plik profilu .ovpn. W urzędzie certyfikacji administrator generuje tożsamość klienta za pomocą polecenia ./easyrsa build-client-full jan.kowalski nopass (lub z hasłem, w zależności od wymogów polityki firmy). Szczegółowe informacje normatywne i techniczne publikuje Zespół CSIRT KNF.

W wyniku tego procesu powstaje klucz prywatny jan.kowalski.key oraz certyfikat jan.kowalski.crt, opatrzony przez Easy-RSA rozszerzeniem EKU z flagą clientAuth. Następnie administrator przystępuje do montażu jednolitego pliku konfiguracyjnego na bazie szablonu base.conf.

W pliku szablonu umieszcza się ogólne dyrektywy: client, dev tun, proto udp, remote vpn.firma.pl 1194, resolv-retry infinite, nobind, persist-key, persist-tun, remote-cert-tls server oraz data-ciphers AES-256-GCM:AES-128-GCM.

Na końcu pliku szablonu dokleja się zawartość poszczególnych plików kryptograficznych wewnątrz znaczników XML: [zawartość ca.crt] , [zawartość jan.kowalski.crt] , [zawartość jan.kowalski.key] oraz [zawartość tc.key] . Gotowy plik jan.kowalski.ovpn jest bezpiecznie przekazywany pracownikowi.

Wyjaśnienie skrótów użytych na slajdzie:
EKU - Extended Key Usage - Flaga clientAuth definiująca certyfikat użytkownika.
XML - Extensible Markup Language - Format znaczników zintegrowanych certyfikatów.
OVPN - OpenVPN Profile - Kompletny plik konfiguracyjny klienta.
AES-GCM - Advanced Encryption Standard Galois Counter Mode - Zalecany szyfr blokowy.

34/40 Fragment pliku server.conf (Linux)
Szczegółowa analiza parametrów i struktury produkcyjnego pliku konfiguracyjnego serwera OpenVPN w systemie Linux.
  • port 1194
proto udp
dev tun
ca ca.crt
cert server1.crt
key server1.key
dh dh.pem
server 10.8.0.0 255.255.255.0
keepalive 10 120
Główny plik konfiguracyjny serwera (server.conf): Centralny plik tekstowy demona OpenVPN determinujący port nasłuchu, interfejs wirtualny, adresację podsieci VPN, ścieżki do certyfikatów oraz polityki routingu i uprawnień.
Slide 34

Konfiguracja produkcyjnego serwera OpenVPN w systemie operacyjnym Linux bazuje na pliku /etc/openvpn/server/server.conf. Zrozumienie poszczególnych dyrektyw jest niezbędne do właściwego zabezpieczenia i optymalizacji demona. Szczegółowe informacje normatywne i techniczne publikuje Dokumentacja sieciowa jądra Linux.

Początek pliku definiuje parametry sieciowe i transportowe: port 1194, proto udp, dev tun oraz topology subnet. Dyrektywa topology subnet jest współczesnym standardem zalecanym przez IETF - sprawia, że wirtualna sieć VPN zachowuje się jak standardowa podsieć IP, gdzie każdy klient otrzymuje pojedynczy adres IP i jednolitą maskę podsieci (zastępując przestarzały model net30 marnujący 4 adresy na klienta).

Sekcja adresowa i kryptograficzna obejmuje: server 10.8.0.0 255.255.255.0 (definiujący przestrzeń adresową przydzielaną klientom), ca ca.crt, cert server1.crt, key server1.key, dh dh.pem oraz tls-crypt tc.key. Dodatkowo umieszcza się dyrektywę data-ciphers AES-256-GCM:AES-128-GCM, gwarantującą stosowanie nowoczesnych szyfrów AEAD.

W sekcji zarządzania ruchem definiuje się dyrektywy wypychania: push "route 192.168.10.0 255.255.255.0" oraz push "dhcp-option DNS 10.8.0.1". Zwieńczeniem pliku są dyrektywy ograniczania uprawnień procesu: user nobody oraz group nogroup, które instruują demona o konieczności porzucenia uprawnień roota natychmiast po zainicjowaniu interfejsów sieciowych.

Wyjaśnienie skrótów użytych na slajdzie:
UDP - User Datagram Protocol - Wysokowydajny protokół transportowy.
TUN - Network TUNnel - Wirtualny interfejs warstwy 3.
DNS - Domain Name System - System nazw domenowych.
AEAD - Authenticated Encryption with Associated Data - Nowoczesny tryb szyfrowania uwierzytelnionego.

35/40 Firewall i IP Forwarding (Linux)
Przewodnik po konfiguracji przekazywania pakietów w jądrze Linuksa oraz reguł zapory Iptables / Nftables dla serwera OpenVPN.
  • W środowiskach produkcyjnych demon OpenVPN nie może pracować z nadrzędnymi uprawnieniami konta administratora (root).
  • Kompletna procedura utwardzania serwera (Hardening):
  • 1. Porzucenie uprawnień roota (Privilege Dropping): Po otwarciu wirtualnego interfejsu TUN i portu 1194 demon musi natychmiast przekazać uprawnienia nieuprzywilejowanemu kontu za pomocą dyrektyw:
    user nobody
    group nogroup
  • 2. Środowisko więzienia (Chroot Jail): Umieszczenie procesu w odizolowanym katalogu za pomocą chroot /etc/openvpn/jail uniemożliwia intruzowi dostęp do nadrzędnego systemu plików w przypadku kompromitacji pamięci procesu.
  • 3. Ograniczenie uprawnień systemd: Konfiguracja pliku jednostki systemowej z parametrami ProtectSystem=strict, ProtectHome=true oraz NoNewPrivileges=true.
Przekazywanie pakietów IP (IP Forwarding): Opcja jądra systemu Linux (net.ipv4.ip_forward) umożliwiająca systemowi operacyjnemu routing pakietów pomiędzy różnymi fizycznymi i wirtualnymi interfejsami sieciowymi.
Slide 35

Pomyślne uruchomienie demona OpenVPN i nawiązanie sesji przez stację kliencką nie oznacza jeszcze, że użytkownik będzie w stanie komunikować się z serwerami w sieci korporacyjnej. Domyślnie system operacyjny Linux odrzuca wszystkie pakiety sieciowe, których adres docelowy nie należy do lokalnych interfejsów maszyny. Szczegółowe informacje normatywne i techniczne publikuje Narzędzie Iptables w projekcie Netfilter.

W pierwszej kolejności administrator musi włączyć przekazywanie pakietów na poziomie jądra. W pliku /etc/sysctl.conf należy odkomentować linię net.ipv4.ip_forward = 1, a następnie zaaplikować zmiany poleceniem sysctl -p. Bez tego ustawienia serwer terminujący tunel zachowuje się jak zwykły host końcowy, a pakiety kierowane do podsieci lokalnej LAN są natychmiast porzucane.

Drugim etapem jest właściwe skonfigurowanie zapory ogniowej (Iptables lub nowoczesnego podsystemu Nftables). W łańcuchu FORWARD należy jawnie zezwolić na przekazywanie pakietów pomiędzy wirtualnym interfejsem tunelu tun0 a fizycznym interfejsem sieci lokalnej eth0: iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT oraz iptables -A FORWARD -i eth0 -o tun0 -m state --state ESTABLISHED,RELATED -j ACCEPT.

Jeżeli sieć lokalna LAN za serwerem nie posiada statycznych tras powrotnych do podsieci VPN (10.8.0.0/24), konieczne jest dodatkowo uruchomienie translacji adresów (Maskarady) w tablicy NAT zapory: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. Sprawia to, że ruch z tunelu pojawia się w sieci lokalnej z adresem IP samego serwera VPN.

Wyjaśnienie skrótów użytych na slajdzie:
NAT - Network Address Translation - Translacja adresów sieciowych w tablicy nat zapory.
LAN - Local Area Network - Lokalna sieć przedsiębiorstwa chroniona zaporą.
CLI - Command Line Interface - Interfejs wiersza poleceń zarządzający zaporą.
IP - Internet Protocol - Protokół warstwy sieciowej.

36/40 Hardening: utwardzanie konfiguracji usługi
Zbiór rygorystycznych zaleceń inżynierskich dotyczących redukcji powierzchni ataku i utwardzania środowiska serwera OpenVPN.
  • Zmniejszenie uprawnień procesu: user nobody / group nogroup.
  • Obligatoryjne użycie TLS-Crypt zamiast starszego TLS-Auth.
  • Stosowanie nowoczesnych szyfrów z grupy AEAD (np. AES-256-GCM).
  • Dbałość o aktualność bibliotek OpenSSL (pamiętaj o historycznych lukach typu Heartbleed).
Utwardzanie serwera OpenVPN (OpenVPN Hardening): Zastosowanie zaawansowanych mechanizmów izolacji procesów, rygorystycznych ograniczeń kryptograficznych oraz separacji uprawnień w celu minimalizacji podatności na ataki sieciowe.
Slide 36

W korporacyjnych wdrożeniach produkcyjnych domyślna konfiguracja serwera OpenVPN musi zostać poddana procedurze utwardzania (Hardening). Ogranicza to potencjalne wektory ataku i chroni system operacyjny hosta przed kompromitacją w przypadku ujawnienia podatności w oprogramowaniu. Szczegółowe informacje normatywne i techniczne publikuje Niemiecki Federalny Urząd Bezpieczeństwa Informacji (BSI).

Pierwszym filarem utwardzania jest zasada minimalizacji uprawnień procesu (PoLP). W pliku konfiguracyjnym należy bezwzględnie zdefiniować dyrektywy user nobody oraz group nogroup. Sprawia to, że po otwarciu portu sieciowego i zainicjowaniu interfejsu TUN proces OpenVPN natychmiast zrzuca uprawnienia administratora roota i działa jako użytkownik nieuprzywilejowany.

Dodatkowo wysoce zalecane jest umieszczenie procesu w odizolowanym środowisku za pomocą dyrektywy chroot /etc/openvpn/jail. W razie hipotetycznego przejęcia kontroli nad procesem OpenVPN przez napastnika, jego dostęp do systemu plików zostanie trwale zablokowany w pustym katalogu klatki chroot, uniemożliwiając odczytanie innych plików systemowych.

W sferze kryptografii utwardzanie obejmuje: wymuszenie protokołu TLS 1.3 lub minimum TLS 1.2 (dyrektywa tls-version-min 1.2), włączenie mechanizmu TLS-Crypt (tls-crypt tc.key), zablokowanie przestarzałych szyfrów oraz cykliczne odpytywanie list unieważnień certyfikatów CRL (crl-verify crl.pem). Tak skonfigurowany serwer spełnia najwyższe wymagania normatywne bezpieczeństwa teleinformatycznego.

Wyjaśnienie skrótów użytych na slajdzie:
PoLP - Principle of Least Privilege - Zasada najmniejszych przywilejów w zarządzaniu procesami.
TLS - Transport Layer Security - Nowoczesny standard kryptograficzny.
CRL - Certificate Revocation List - Lista unieważnionych certyfikatów tożsamości.
TUN - Network TUNnel - Wirtualny interfejs sieciowy.

37/40 OpenVPN vs WireGuard (perspektywy)
Komparatywna analiza technologiczna standardu OpenVPN oraz protokołu WireGuard w kontekście wydajności i elastyczności.
  • WireGuard przewyższa prostotą (4000 linii kodu) i szybkością.
  • OpenVPN pozostaje liderem w sytuacjach:
    • Konieczności omijania cenzury poprzez ruch TCP.
    • Złożonych struktur korporacyjnych wymagających certyfikatów z okresem ważności.
    • Wsparcia dla systemów starszej generacji.
Protokół WireGuard (WireGuard Protocol): Nowoczesny, minimalistyczny protokół VPN operujący bezpośrednio w przestrzeni jądra, wykorzystujący nowoczesną kryptografię sztywną (Noise Protocol, ChaCha20-Poly1305, Curve25519) i koncepcję Cryptokey Routing.
Slide 37

Pojawienie się i gwałtowny rozwój protokołu WireGuard (autorstwa Jasona Donenfelda) zredefiniowały standardy nowoczesnych wirtualnych sieci prywatnych, stawiając go w roli bezpośredniego konkurenta dla dojrzałego standardu OpenVPN. Zrozumienie fundamentalnych różnic pomiędzy tymi technologiami jest kluczem do świadomego projektowania architektur VPN. Szczegółowe informacje normatywne i techniczne publikuje Oficjalny portal projektu WireGuard.

Największym atutem protokołu WireGuard jest jego niezwykła prostota i wydajność. Kod źródłowy WireGuard liczy zaledwie około 4000 linii (w porównaniu do ponad 100 000 linii kodu OpenVPN wraz z biblioteką OpenSSL), co czyni go nieporównywalnie łatwiejszym do audytu bezpieczeństwa. Implementacja bezpośrednio w przestrzeni jądra Linuksa pozwala na osiąganie maksymalnych przepustowości przy minimalnym narzucie na procesor.

Z kolei niepodważalną przewagą technologii OpenVPN pozostaje jej niezrównana elastyczność i bogactwo funkcji sieciowych. OpenVPN oferuje pełne wsparcie dla infrastruktury PKI z dynamicznym unieważnianiem certyfikatów (CRL), zaawansowany mechanizm dynamicznego wypychania opcji i tras (push), obsługę protokołu TCP na porcie 443 (omijanie restrykcyjnych firewalli), autoryzację wieloskładnikową MFA oraz wsparcie dla mostkowania warstwy 2 (TAP).

W nowoczesnej inżynierii teleinformatycznej obie technologie doskonale się uzupełniają: WireGuard jest idealnym standardem dla wysokowydajnych połączeń szkieletowych router-router (Site-to-Site) oraz integracji chmurowych, podczas gdy OpenVPN pozostaje niezastąpionym standardem dla korporacyjnych systemów zdalnego dostępu pracowników (Remote Access) wymagających integracji z katalogami tożsamości.

Wyjaśnienie skrótów użytych na slajdzie:
WireGuard - WireGuard Secure VPN Tunnel - Nowoczesny minimalistyczny protokół VPN w przestrzeni jądra.
PKI - Public Key Infrastructure - Zaawansowana infrastruktura klucza publicznego wspierana w OpenVPN.
TCP - Transmission Control Protocol - Protokół nośnika tunelu na porcie 443 w OpenVPN.
CRL - Certificate Revocation List - Dynamiczne unieważnianie dostępu pracownikom.

38/40 Podsumowanie części 4
Podsumowanie wiedzy o architekturze, konfiguracji i diagnostyce OpenVPN w środowiskach linuksowych i routerach MikroTik.
  • OpenVPN to najbardziej uniwersalny i elastyczny standard VPN.
  • Bazuje na sprawdzonych fundamentach SSL/TLS.
  • Wymaga świadomego zarządzania infrastrukturą PKI.
  • Oferuje zaawansowane mechanizmy sterowania ruchem (Push, CCD).
  • Jest odporny na trudne warunki sieciowe i restrykcyjne firewalle.
Synteza technologii OpenVPN (OpenVPN Technology Synthesis): Całościowe zestawienie zasad działania architektury SSL/TLS VPN, separacji kanałów sterowania i danych oraz mechanizmów zarządzania ruchem.
Slide 38

Czwarty moduł semestralnego kursu wirtualnych sieci prywatnych dostarczył studentom kompleksowej wiedzy na temat technologii OpenVPN - najbardziej uniwersalnego i elastycznego standardu VPN wywodzącego się ze świata open-source. Przeanalizowano architekturę SSL/TLS VPN, w której dojrzała biblioteka OpenSSL gwarantuje najwyższy poziom bezpieczeństwa kryptograficznego. Szczegółowe informacje normatywne i techniczne publikuje Agencja Unii Europejskiej ds. Cyberbezpieczeństwa (ENISA).

Szczegółowo omówiono różnice funkcjonalne pomiędzy wirtualnymi interfejsami warstwy 3 (TUN) a warstwy 2 (TAP), zasady wyboru protokołu transportowego UDP oraz mechanizmy obronne TLS-Auth i TLS-Crypt, które skutecznie chronią serwery dostępowe przed skanowaniem portów i atakami typu DoS.

W części warsztatowej studenci poznali metodykę wdrażania własnego centrum certyfikacji PKI za pomocą narzędzia Easy-RSA, strukturę i dyrektywy jednolitego pliku profilu .ovpn, zaawansowane mechanizmy dynamicznego wypychania tras (push) oraz inżynierski schemat pełnego tunelowania redirect-gateway def1. Dokonano również krytycznej analizy podatności VORACLE, uzasadniając konieczność całkowitej rezygnacji z kompresji danych.

W toku zajęć laboratoryjnych studenci zapoznają się z praktyczną konfiguracją serwera OpenVPN w systemie Linux oraz specyfiką podsystemu OVPN w routerach MikroTik RouterOS v7, przygotowując się do kolejnego modułu poświęconego zaawansowanym topologiom routingu w sieciach VPN.

Wyjaśnienie skrótów użytych na slajdzie:
OpenVPN - Open Virtual Private Network - Wieloplatformowy standard VPN oparty na SSL/TLS.
TUN - Network TUNnel - Wirtualny interfejs warstwy sieciowej IP.
TAP - Network TAP - Wirtualny interfejs warstwy łącza danych Ethernet.
PKI - Public Key Infrastructure - Infrastruktura klucza publicznego X.509.
MFA - Multi-Factor Authentication - Uwierzytelnianie wieloskładnikowe.

39/40 Zadania do samodzielnej analizy
Przedstawienie ćwiczeń laboratoryjnych i analiz powdrożeniowych utrwalających wiedzę z zakresu technologii OpenVPN.
  • 1. Przeanalizuj logi połączenia OpenVPN i zidentyfikuj moment wymiany kluczy TLS.
  • 2. Przygotuj plik .ovpn i przetestuj go na urządzeniu mobilnym przy wykorzystaniu sieci LTE.
  • 3. Wykonaj test prędkości w trybie TCP oraz UDP - zaobserwuj różnice w opóźnieniach (Ping).
  • 4. Spróbuj skonfigurować usługę na niestandardowym porcie (np. TCP 443).
Ćwiczenia warsztatowe OpenVPN (OpenVPN Hands-On Assignment): Zadania praktyczne obejmujące wdrożenie serwera OpenVPN na maszynie wirtualnej Linux, konfigurację profilu CCD, integrację z mechanizmem MFA oraz weryfikację bezpieczeństwa za pomocą analizatora Wireshark.
Slide 39

W ramach utrwalenia wiedzy zdobytej w czwartej części kursu studenci zobowiązani są do wykonania zestawu samodzielnych zadań inżynierskich w środowisku laboratoryjnym opartym na systemie Linux Debian oraz wirtualnym routerze MikroTik CHR. Szczegółowe informacje normatywne i techniczne publikuje Urząd Ochrony Danych Osobowych.

Zadanie pierwsze polega na kompletnym uruchomieniu serwera OpenVPN w przestrzeni systemu Linux: zainicjowaniu PKI przy użyciu Easy-RSA 3, wystawieniu certyfikatu serwera oraz certyfikatu klienta, wygenerowaniu klucza TLS-Crypt oraz skonfigurowaniu pliku server.conf na porcie UDP 1194 z szyfrowaniem AES-256-GCM.

Zadanie drugie wymaga przygotowania jednolitego profilu klienta .ovpn (format Inline) i przetestowania połączenia z poziomu oficjalnego klienta OpenVPN Connect na stacji roboczej Windows lub urządzeniu mobilnym z Androidem. Należy zweryfikować poprawność działania mechanizmu push oraz brak wycieków DNS (DNS Leak Test).

Zadanie trzecie, o charakterze zaawansowanym, obejmuje wdrożenie mechanizmu CCD: utworzenie dedykowanego pliku konfiguracyjnego dla wybranego użytkownika, przydzielenie mu statycznego adresu IP oraz ograniczenie dostępu wyłącznie do jednego wskazanego serwera w sieci LAN za pomocą reguł zapory Iptables w łańcuchu FORWARD, weryfikując poprawność blokady za pomocą zrzutu pakietów w programie Wireshark.

Wyjaśnienie skrótów użytych na slajdzie:
PKI - Public Key Infrastructure - Infrastruktura klucza publicznego.
CCD - Client Config Directory - Katalog indywidualnych profili klientów.
DNS - Domain Name System - System nazw domenowych poddawany testom wycieków.
LAN - Local Area Network - Prywatna sieć chroniona regułami zapory.

40/40 Zapowiedź: część 5 - routing i topologie
Wprowadzenie do tematyki części piątej kursu poświęconej routingowi w tunelach, protokołowi OSPF, topologiom Hub-and-Spoke oraz technologii VRF.
  • W kolejnej części zmierzymy się z wyzwaniami dotyczącymi przepływu danych: Sztuka routingu w tunelach
  • Routing statyczny vs OSPF przez VPN.
  • Dzielone tunelowanie (Split Tunneling) w zastosowaniach korporacyjnych.
  • Hub-and-Spoke: Architektura gwiazdy w VPN.
Topologia sieci VPN (VPN Overlay Topology): Struktura logicznych powiązań komunikacyjnych pomiędzy węzłami sieci nakładkowej (np. Hub-and-Spoke, Full Mesh), determinująca ścieżki przepływu danych i tablice routingu.
Slide 40

Pomyślne opanowanie technologii tunelowania pakietów (GRE, PPTP, SSTP, L2TP/IPSec oraz OpenVPN) stanowi solidny fundament inżynierski. Jednak samo utworzenie szyfrowanego kanału komunikacyjnego pomiędzy dwoma węzłami rozwiązuje zaledwie ułamek problemów, przed jakimi staje architekt korporacyjnej sieci teleinformatycznej. Szczegółowe informacje normatywne i techniczne publikuje Naukowa i Akademicka Sieć Komputerowa.

W rzeczywistych środowiskach biznesowych infrastruktura obejmuje dziesiątki odległych fabryk, biur regionalnych, centrów przetwarzania danych oraz środowisk chmurowych, które muszą wymieniać ze sobą tysiące tras sieciowych. W piątej części kursu przejdziemy do szczegółowego omówienia fundamentów routingu w tunelach VPN.

Szczegółowej analizie poddane zostaną zaawansowane topologie sieciowe: klasyczny model gwiazdy (Hub-and-Spoke), architektura pełnej siatki (Full Mesh) oraz dynamiczne tunele DMVPN. Studenci poznają zasady uruchamiania protokołów routingu dynamicznego OSPF i BGP na interfejsach tunelowych, rozwiązywanie problemów z metrykami i kosztami tras oraz problematykę MTU w protokołach stanu łącza.

Ponadto omówimy routing oparty na politykach (Policy-Based Routing - PBR), separację ruchu w wirtualnych tablicach routingu (VRF), mechanizmy równoważenia obciążenia ECMP oraz techniki automatycznego przełączania awaryjnego (Failover), co pozwoli na budowę wysoce odpornych, samonaprawiających się sieci korporacyjnych.

Wyjaśnienie skrótów użytych na slajdzie:
OSPF - Open Shortest Path First - Protokół routingu dynamicznego stanu łącza analizowany w części 5.
BGP - Border Gateway Protocol - Protokół bramy zewnętrznej.
VRF - Virtual Routing and Forwarding - Wirtualne tablice routingu zapewniające separację podsieci.
PBR - Policy-Based Routing - Routing oparty na politykach i znacznikach pakietów.
ECMP - Equal-Cost Multi-Path - Równoważenie obciążenia na trasach o równym koszcie.