Zadania projektowe - Wirtualne Sieci Prywatne

VPN_03 Architektura IPsec, VPN_07 PKI i certyfikaty.

Celem projektu jest wdrożenie tunelu Site-to-Site opartego na standardzie IKEv2 między centralą instytucji a jej głównym węzłem chmurowym. Projekt zakłada rezygnację z PSK na rzecz wzajemnego uwierzytelniania opartego na certyfikatach cyfrowych wystawionych przez własny urząd certyfikacji (CA, Certificate Authority) jako wybór projektowy dla tego wdrożenia. Realizacja obejmuje pełną konfigurację infrastruktury PKI, w tym wygenerowanie hierarchii certyfikatów, wdrożenie list odwołania (CRL) oraz skonfigurowanie zaawansowanych mechanizmów szyfrowania z wykorzystaniem algorytmów AES-GCM i grup Diffie-Hellman zapewniających Perfect Forward Secrecy.

Instytucja finansowa, obsługująca wrażliwe dane klientów oraz prowadząca krytyczne transakcje bankowe, wymaga najwyższego stopnia bezpieczeństwa połączeń między centralą a głównym węzłem chmurowym, gdzie przechowywane są bazy danych i systemy transakcyjne. Obecna konfiguracja VPN oparta na kluczach PSK stwarza poważne ryzyko bezpieczeństwa, ponieważ przy braku PFS wyciek klucza może umożliwić odszyfrowanie wcześniej przechwyconego ruchu; zastosowanie PFS ogranicza ten skutek. W sektorze finansowym jest to niedopuszczalne ze względu na wymogi zgodności i ryzyko strat finansowych oraz utraty reputacji. Dodatkowo audyt bezpieczeństwa wykazał, że stosowane algorytmy szyfrowania nie spełniają wymogów PCI DSS, które nakazują stosowanie silnej kryptografii oraz uwierzytelniania wieloskładnikowego dla dostępu zdalnego. Certyfikaty X.509 są jednym z możliwych rozwiązań, ale nie są wprost wymagane przez standard (zob. wymaganie 8.4.3 PCI DSS v4.0.1). Konieczne jest zatem wdrożenie IKEv2 z algorytmami AES-256-GCM dla zapewnienia poufności i integralności przesyłanych danych, przy jednoczesnym zastąpieniu kluczy PSK własną infrastrukturą certyfikatów z wewnętrznym urzędem CA. Projekt wymaga również zapewnienia automatycznego odświeżania kluczy sesyjnych (rekey) przez parametry Lifetime oraz wdrożenia mechanizmu Dead Peer Detection (DPD) do monitorowania stanu tunelu, co pozwoli na automatyczne wykrycie utraty łączności z peerem i renegocjowanie połączenia.

• Ustanowienie dedykowanego serwera urzędu certyfikacji CA na systemie Linux z OpenSSL.
• Wygenerowanie klucza prywatnego Root CA z użyciem algorytmu RSA 4096-bit lub eliptycznego.
• Utworzenie i podpisanie własnego certyfikatu głównego urzędu certyfikacji.
• Wygenerowanie żądań podpisania certyfikatów CSR dla obu routerów brzegowych VPN.
• Podpisanie certyfikatów bram VPN przez Root CA z zachowaniem odpowiednich rozszerzeń.
• Konfiguracja dystrybucji list odwołania certyfikatów CRL (Certificate Revocation List) przez HTTPS albo OCSP (Online Certificate Status Protocol).
• Wdrożenie profilu IKEv2 z parametrami propozycji IKE (faza pierwsza) oraz propozycji IPsec (faza druga).
• Wybór szyfrowania AES-256-GCM dla fazy pierwszej i drugiej.
• Zastosowanie grupy Diffie-Hellman o numerze 14 lub wyższym dla zapewnienia PFS.
• Konfiguracja uwierzytelniania wzajemnego opartego wyłącznie na certyfikatach cyfrowych.
• Zdefiniowanie polityk IPsec określających ruch chroniony (Traffic Selectors).
• Uruchomienie interfejsów wirtualnych typu VTI (Virtual Tunnel Interface) w celu ułatwienia routingu.
• Konfiguracja parametrów Lifetime dla kluczy IKE i IPsec w celu wymuszenia renegocjacji.
• Wdrożenie mechanizmu Dead Peer Detection (DPD) do monitorowania stanu tunelu.
• Przeprowadzenie analizy pakietów w Wiresharku w celu potwierdzenia szyfrowania ESP.
• Weryfikacja aktywnej sesji poleceniem show crypto ikev2 sa oraz show crypto ipsec sa.
• Testowanie ciągłości połączenia przy pomocy narzędzia ping z dużym rozmiarem pakietu.

Dokumentacja projektowa powinna zawierać szczegółowy opis infrastruktury PKI, w tym schemat hierarchii certyfikatów (Root CA -> certyfikaty urządzeń) oraz procedurę generowania i odnawiania certyfikatów. Należy uwzględnić schemat logiczny i fizyczny topologii sieci z zaznaczeniem przepływu danych podczas wzajemnego uwierzytelniania IKEv2. Opis konfiguracji powinien zawierać analizę procesu wymiany kluczy Diffie-Hellman, wyjaśnienie działania mechanizmu AES-GCM oraz różnicę między uwierzytelnianiem RSA a PSK w kontekście bezpieczeństwa. W dokumentacji należy zamieścić tabelę z porównaniem grup DH pod kątem siły szyfrowania i wydajności oraz omówienie wymogów PCI DSS dotyczących silnej kryptografii i MFA oraz wskazanie, że certyfikaty X.509 są jednym z możliwych rozwiązań.

1. Wprowadzenie do technologii IKEv2 i infrastruktury PKI w sieciach korporacyjnych
2. Analiza wymogów bezpieczeństwa instytucji finansowej i wymogów zgodności
3. Projektowanie hierarchii urzędu certyfikacji CA z wykorzystaniem OpenSSL
4. Konfiguracja serwera Root CA na platformie Linux - generowanie kluczy i certyfikatów
5. Tworzenie żądań CSR i podpisywanie certyfikatów dla urządzeń VPN
6. Konfiguracja profilu IKEv2 z uwierzytelnianiem certyfikacyjnym na routerze Cisco
7. Wdrożenie polityk IPsec z algorytmami AES-GCM i grupami DH
8. Konfiguracja mechanizmów DPD i Lifetime dla automatycznej renegocjacji
9. Weryfikacja stanu tunelu poleceniami show crypto ikev2 sa i show crypto ipsec sa
10. Analiza pakietów ESP w Wiresharku - potwierdzenie szyfrowania
11. Podsumowanie i wnioski z realizacji projektu

VPN_04 OpenVPN TUN/TAP, VPN_06 mostkowanie L2.

Celem projektu jest zaprojektowanie i wdrożenie serwera OpenVPN w trybie TAP (mostkowanie), który umożliwi pracownikom zdalnym dostęp do specyficznych usług działających wyłącznie w warstwie drugiej modelu OSI. Należy zaznaczyć, że standardowe aplikacje OpenVPN na Androidzie i iOS obsługują TUN, a TAP wymaga komputera z odpowiednim sterownikiem lub uprawnień root. Projekt kładzie szczególny nacisk na bezpieczeństwo kanału kontrolnego poprzez implementację tls-auth, wymuszonego użycia TLS w wersji 1.3 (z możliwością dopuszczenia TLS 1.2 dla starszych klientów) oraz indywidualnej konfiguracji dla wybranych klientów za pomocą mechanizmu CCD (Client Config Directory). Zakres prac obejmuje również konfigurację mostka sieciowego (bridge) łączącego interfejs wirtualny TAP z fizyczną kartą LAN, co pozwoli na pełną transparentność warstwy drugiej dla klientów VPN.

Firma projektująca infrastrukturę przemysłową musi umożliwić swoim pracownikom zdalnym dostęp do specyficznych usług działających tylko w warstwie 2, takich jak systemy SCADA oraz protokoły przemysłowe PROFINET RT, EtherCAT i Modbus TCP, a także starsze aplikacje sieciowe wykorzystujące rozgłaszanie ramek. PROFINET RT i EtherCAT działają bezpośrednio w ramkach Ethernet, natomiast Modbus TCP działa w warstwie 3 i może być transportowany przez TUN. Problem polega na tym, że standardowe rozwiązania VPN w trybie TUN (routing) nie obsługują tych protokołów, ponieważ operują wyłącznie na poziomie warstwy trzeciej i nie pozwalają na przesyłanie ramek Ethernet z oryginalnymi adresami MAC. Dodatkowo, firma działa w sektorze, gdzie konkurencja intensywnie skanuje internet w poszukiwaniu otwartych portów VPN, a wykrycie serwera OpenVPN może prowadzić do prób ataków brute-force lub eksploatacji znanych podatności. Mechanizm tls-auth dodaje podpis HMAC do pakietów handshake i pozwala odrzucić pakiety bez prawidłowego klucza. Utrudnia to skanowanie portów i rozpoznanie usługi, ale nie czyni serwera całkowicie niewidocznym. W nowych wdrożeniach często zaleca się tls-crypt, który dodatkowo szyfruje kanał kontrolny i ukrywa metadane certyfikatów. Równocześnie system musi pozwalać na precyzyjne przypisywanie uprawnień i statycznych adresów IP do konkretnych urządzeń końcowych, co jest niezbędne w środowisku przemysłowym, gdzie każda maszyna ma ściśle określoną rolę i musi mieć zagwarantowany dostęp tylko do swoich zasobów.

• Instalacja serwera OpenVPN na platformie Debian lub pfSense.
• Inicjalizacja infrastruktury Easy-RSA i wygenerowanie certyfikatów dla serwera i klientów.
• Konfiguracja interfejsu wirtualnego typu TAP dla mostkowania w warstwie drugiej.
• Utworzenie mostka sieciowego bridge na routerze łączącego TAP z fizyczną kartą LAN.
• Wygenerowanie statycznego klucza tls-auth dla ochrony przed atakami DoS i skanowaniem portów.
• Konfiguracja parametru tls-server oraz tls-version-min 1.3 z uwagą, że TLS 1.3 wymaga OpenVPN 2.6 lub nowszego i zgodnego klienta; dla starszych klientów można dopuścić TLS 1.2 jako minimum.
• Wdrożenie katalogu Client Config Dir CCD do precyzyjnego zarządzania ustawieniami użytkowników.
• Przypisanie statycznych adresów IP w plikach CCD (Client Config Directory) za pomocą ifconfig-push. Adres MAC nie jest przydzielany przez CCD.
• Wyłączenie kompresji LZO na rzecz bezpieczeństwa kanału przed atakami typu VORACLE.
• Konfiguracja szyfru AES-256-GCM oraz algorytmu uwierzytelniania kanału kontrolnego SHA-512. Przy szyfrze AEAD integralność danych zapewnia GCM, a parametr auth dotyczy przede wszystkim kanału kontrolnego i starszych trybów CBC.
• Ograniczenie uprawnień procesu OpenVPN poprzez użycie nieuprzywilejowanego użytkownika i grupy.
• Wdrożenie mechanizmu sprawdzania certyfikatów na liście odwołań CRL.
• Konfiguracja firewalla w celu dopuszczenia ruchu tylko na określonym porcie UDP.
• Eksport plików .ovpn z certyfikatem i kluczem w oddzielnych plikach albo z profilem zabezpieczonym hasłem. Nie należy osadzać prywatnego klucza w pliku przeznaczonym do szerokiego udostępniania.
• Testowanie dostępu do usług L2, takich jak PROFINET RT, EtherCAT lub starsze aplikacje korzystające z rozgłaszania.
• Analiza logów serwera w celu weryfikacji poprawności negocjacji kluczy TLS.
• Sprawdzenie tablicy ARP w celu potwierdzenia widoczności klientów w segmencie LAN.

Dokumentacja projektowa powinna zawierać szczegółowy opis architektury trybu TAP w OpenVPN, w tym schemat mostka sieciowego (bridge) łączącego interfejs wirtualny TAP z fizyczną kartą LAN. Należy wyjaśnić różnice między trybem TUN (routing warstwy 3) a trybem TAP (mostkowanie warstwy 2) oraz uzasadnić wybór trybu TAP dla konkretnych zastosowań przemysłowych. Dokumentacja powinna zawierać analizę mechanizmu tls-auth jako dodatkowej warstwy ochronnej przed atakami DoS i skanowaniem portów oraz omówienie tls-crypt oraz wyjaśnienie działania katalogu CCD (Client Config Directory) i przypisywania statycznych adresów IP. Należy zamieścić tabelę porównawczą szyfrów TLS i protokołów pod kątem bezpieczeństwa i wydajności.

1. Wprowadzenie do technologii OpenVPN w trybie TAP i zastosowań warstwy drugiej
2. Analiza wymagań sieci przemysłowej i protokołów działających w warstwie L2
3. Instalacja i konfiguracja serwera OpenVPN na platformie Debian
4. Infrastruktura certyfikatów Easy-RSA - generowanie PKI dla serwera i klientów
5. Konfiguracja interfejsu TAP i tworzenie mostka sieciowego bridge
6. Implementacja tls-auth dla ochrony przed atakami i skanowaniem
7. Konfiguracja katalogu CCD dla przypisywania statycznych adresów IP
8. Utwardzanie serwera OpenVPN - wyłączenie kompresji, silne szyfry, uprawnienia
9. Testowanie dostępu do usług L2 - protokoły przemysłowe i starsze aplikacje rozgłoszeniowe
10. Analiza logów serwera i weryfikacja negocjacji TLS
11. Podsumowanie i wnioski z realizacji projektu

VPN_05 Architektury Hub-and-Spoke, VPN_07 Dostępność usług.

Celem projektu jest zapewnienie ciągłości działania usług VPN poprzez wdrożenie pary redundantnych routerów pełniących funkcję bramy, które będą w stanie przejąć cały ruch w przypadku awarii jednego z węzłów bez utraty połączenia. Projekt zakłada automatyczne przełączanie ruchu (Failover) w czasie nieprzekraczającym kilku sekund, co jest krytyczne dla systemów wymagających ciągłej dostępności. Zakres prac obejmuje konfigurację protokołu VRRP dla redundancji bramy, synchronizację stanu połączeń IPsec za pomocą mechanizmu HA dostępnego na danej platformie (sam VRRP nie synchronizuje SA IPsec) oraz wdrożenie mechanizmów monitorowania łączy, które automatycznie zainicjują przełączenie w przypadku wykrycia problemów na interfejsie WAN.

Centrum medyczne obsługujące szpitalną sieć teleinformatyczną przesyła krytyczne dane pacjentów przez VPN do centralnej bazy danych, w tym wyniki badań diagnostycznych, obrazy z aparatury medycznej oraz recepty elektroniczne. Nawet kilkuminutowy brak łączności jest absolutnie niedopuszczalny, ponieważ przerwa w dostępie do systemów może skutkować opóźnieniem w udzieleniu pomocy medycznej, co w skrajnych przypadkach może zagrozić życiu pacjentów, a szpital musi uwzględnić wymogi RODO, w tym szczególną ochronę danych dotyczących zdrowia oraz wymogi krajowe dotyczące dokumentacji medycznej. Aktualnie centrum medyczne posiada tylko jedną bramę VPN, której awaria powoduje całkowitą utratę łączności z centralą, a czas naprawy sprzętu lub wymiany łącza może trwać godziny, co w praktyce oznacza paraliż pracy całej placówki. Należy skonfigurować dwa routery brzegowe pracujące w klastrze High Availability, które będą współdzielić wirtualny adres bramy VPN (VIP), przy czym oba routery należy podłączyć do wspólnego segmentu L2 i jednego dostawcy albo odejść od VRRP i zastosować rozwiązanie międzyoperatorskie, na przykład BGP multihoming z odpowiednim mechanizmem HA.

• Przygotowanie dwóch identycznych routerów (Master i Slave) w tej samej podsieci zewnętrznej.
• Konfiguracja protokołu VRRP na interfejsach WAN obu urządzeń z priorytetami.
• Ustanowienie wirtualnego adresu IP VIP pełniącego rolę publicznej bramy VPN.
• Synchronizacja bazy certyfikatów i kluczy między obiema bramami VPN.
• Konfiguracja mechanizmu synchronizacji stanu dostępnego na danej platformie, na przykład Cisco SSO/HA albo rozwiązania producenta.
• Wdrożenie protokołu VRRP na interfejsach wewnętrznych LAN dla zapewnienia bramy lokalnej.
• Konfiguracja reguł firewalla dopuszczających pakiety protokołu VRRP (multicast).
• Uruchomienie usługi monitorowania łącza zewnętrznego w celu wymuszenia przełączenia.
• Konfiguracja opóźnienia preempcji i progów monitorowania w celu uniknięcia niestabilnego przełączania.
• Testowanie scenariusza awarii routera głównego poprzez fizyczne odłączenie zasilania.
• Pomiar czasu zbieżności i przerwy w transmisji danych podczas przełączania ról.
• Weryfikacja stanu klastra poleceniem show vrrp lub show vrrp brief, zależnie od platformy.
• Konfiguracja logowania zdarzeń HA do centralnego serwera Syslog.
• Zapewnienie redundancji zasilania i łączy fizycznych dla każdego z routerów.
• Ocena wpływu przełączenia na sesje TCP i UDP oraz wyjaśnienie, które sesje wymagają ponownego zestawienia.
• Optymalizacja parametrów timerów VRRP dla skrócenia czasu wykrywania awarii.
• Dokumentacja architektury klastra z uwzględnieniem topologii fizycznej i logicznej.

Dokumentacja projektowa powinna zawierać szczegółowy opis architektury klastra High Availability, w tym schemat topologii fizycznej z zaznaczeniem redundantnych łączy do dostawcy oraz wspólnego segmentu L2 wymaganego przez VRRP. Należy uwzględnić schemat logiczny przedstawiający mechanizm VRRP i przejmowanie ruchu przez węzeł zapasowy. Dokumentacja powinna zawierać analizę procesu failover, w tym czas zbieżności i stratę pakietów podczas przełączania. Należy zamieścić tabelę z pomiarami czasu przełączania dla różnych scenariuszy awaryjnych oraz omówić wymagania ciągłości działania w sektorze medycznym.

1. Wprowadzenie do technologii High Availability w sieciach VPN
2. Analiza wymagań ciągłości działania w placówce medycznej
3. Projektowanie architektury klastra z dwoma routerami brzegowymi
4. Konfiguracja protokołu VRRP na interfejsach WAN obu routerów
5. Ustanowienie wirtualnego adresu IP VIP dla bramy VPN
6. Synchronizacja certyfikatów i stanu połączeń IPsec między węzłami
7. Konfiguracja mechanizmu synchronizacji stanu dostępnego na danej platformie
8. Uruchomienie monitorowania łącza i testowanie automatycznego przełączania
9. Pomiary czasu failover i straty pakietów w różnych scenariuszach
10. Weryfikacja stanu klastra poleceniem show vrrp lub show vrrp brief
11. Podsumowanie i wnioski z realizacji projektu

VPN_03 L2TP/IPsec, VPN_07 MFA, AAA.

Celem projektu jest wdrożenie skalowalnego systemu dostępu zdalnego, w którym baza użytkowników jest całkowicie oddzielona od bramy VPN, co pozwala na centralne zarządzanie uprawnieniami niezależnie od urządzenia sieciowego. Projekt obejmuje pełną integrację routera z serwerem RADIUS (Remote Authentication Dial-In User Service; NPS lub FreeRADIUS), w tym konfigurację atrybutów AAA dla kontroli dostępu sieciowego (NAC) oraz wdrożenie drugiego składnika uwierzytelniania (MFA, Multi-Factor Authentication) z wykorzystaniem TOTP (Time-based One-Time Password) lub push-notification. Zakres prac obejmuje również konfigurację protokołu L2TP/IPsec jako transportu dla ruchu VPN, co zapewnia kompatybilność z natywnymi klientami w systemach Windows, macOS i iOS. W Androidzie 12 i nowszych usunięto natywną obsługę L2TP/IPsec, więc potrzebna jest aplikacja OpenVPN, IKEv2 albo inny klient.

Duża korporacja posiadająca tysiące kont pracowniczych w Active Directory potrzebuje wdrożyć bezpieczny dostęp VPN dla pracowników zdalnych, jednocześnie centralizując proces zarządzania użytkownikami i ich uprawnieniami w istniejącej infrastrukturze IT. Obecne rozwiązanie, gdzie hasła użytkowników są przechowywane lokalnie na routerach VPN, jest nieskalowalne i niebezpieczne - każdy pracownik odchodzący z firmy wymaga ręcznego usunięcia z każdej bramy VPN, a hasło współdzielone przez wielu użytkowników stwarza ryzyko nieautoryzowanego dostępu w przypadku jego wycieku. Dodatkowo, pojawiające się regulacje dotyczące ochrony danych osobowych (RODO) oraz wewnętrzne audyty bezpieczeństwa wymagają wdrożenia wieloskładnikowego uwierzytelniania, które znacząco utrudni przejęcie konta nawet w przypadku skompromitowania hasła. Należy tak skonfigurować bramę VPN, aby pakiety uwierzytelniające były przekazywane do centralnego serwera RADIUS (NPS - Network Policy Server w środowisku Windows lub FreeRADIUS w środowisku Linux), który dokona weryfikacji poświadczeń użytkownika w Active Directory, a następnie wymusi na użytkowniku potwierdzenie tożsamości kodem TOTP z aplikacji mobilnej albo powiadomieniem push. SMS warto wskazać jako metodę słabszą, podatną na przejęcie numeru.

• Konfiguracja serwera RADIUS (np. FreeRADIUS) z bazą użytkowników w pliku lub bazie SQL.
• Dodanie routera VPN jako klienta NAS w pliku clients.conf serwera RADIUS.
• Ustanowienie bezpiecznego wspólnego klucza Shared Secret dla komunikacji RADIUS.
• Konfiguracja usługi L2TP na routerze z określeniem puli adresów IP dla klientów.
• Wdrożenie ochrony IPsec dla ruchu L2TP z użyciem silnego klucza PSK lub certyfikatu.
• Konfiguracja routera do korzystania z zewnętrznego serwera AAA dla uwierzytelniania.
• Wdrożenie modułu Google Authenticator lub podobnego na serwerze RADIUS dla obsługi MFA.
• Konfiguracja atrybutów RADIUS określających uprawnienia użytkownika (np. Framed-IP-Address).
• Uruchomienie logowania Accounting w celu rejestracji czasu trwania sesji pracowników, z serwerem RADIUS na porcie UDP 1813 oraz atrybutami Acct-Status-Type i Acct-Session-Id.
• Konfiguracja L2TP/IPsec z uwierzytelnianiem użytkowników przez RADIUS. MS-CHAPv2 można pokazać jako rozwiązanie starsze, ale w nowym wdrożeniu preferuje się EAP-TLS, EAP-TTLS albo IKEv2 z certyfikatami.
• Weryfikacja komunikacji RADIUS za pomocą narzędzia radtest na serwerze.
• Testowanie połączenia z poziomu systemów Windows i iOS bez instalacji dodatkowego oprogramowania oraz z Androida 12+ z użyciem IKEv2 lub OpenVPN.
• Analiza pakietów Access-Request, Access-Challenge i Access-Accept na porcie UDP 1812 oraz pakietów Accounting-Request na porcie UDP 1813.
• Wdrożenie polityki wymuszającej okresową zmianę haseł przez użytkowników.
• Konfiguracja komunikatów powitalnych i ostrzegawczych dla logujących się osób.
• Sprawdzenie raportów aktywności użytkownika na podstawie logów serwera RADIUS.
• Opracowanie instrukcji dla użytkownika końcowego dotyczącej konfiguracji MFA na telefonie.

Dokumentacja projektowa powinna zawierać szczegółowy opis architektury systemu AAA (Authentication, Authorization, Accounting) z centralnym serwerem RADIUS, w tym schemat przepływu pakietów Access-Request, Access-Challenge, Access-Accept oraz Accounting-Request między klientem VPN a serwerem. Należy wyjaśnić rolę protokołu L2TP/IPsec jako transportu dla ruchu PPP oraz mechanizm działania uwierzytelniania wieloskładnikowego MFA z wykorzystaniem TOTP. Dokumentacja powinna zawierać analizę atrybutów RADIUS określających uprawnienia użytkowników (Framed-IP-Address, Tunnel-Type) oraz omówienie integracji z Active Directory. Należy zamieścić instrukcję konfiguracji aplikacji MFA na urządzeniach mobilnych.

1. Wprowadzenie do technologii L2TP/IPsec i uwierzytelniania wieloskładnikowego MFA
2. Analiza wymagań korporacyjnego systemu dostępu zdalnego z centralnym AD
3. Instalacja i konfiguracja serwera FreeRADIUS z integracją LDAP
4. Konfiguracja routera VPN jako klienta NAS serwera RADIUS
5. Wdrożenie L2TP/IPsec na routerze z pulą adresów dla klientów
6. Konfiguracja modułu MFA (Google Authenticator) na serwerze RADIUS
7. Uruchomienie Accounting dla rejestracji czasu trwania sesji
8. Testowanie uwierzytelniania z Windows, macOS i iOS oraz z Androida 12+ przez IKEv2 lub OpenVPN
9. Analiza pakietów RADIUS w Wiresharku - Access-Request, Access-Challenge, Access-Accept i Accounting-Request
10. Weryfikacja raportów aktywności użytkowników na serwerze RADIUS
11. Podsumowanie i wnioski z realizacji projektu

VPN_06 EoIP, VPN_03 IPsec Encapsulation.

Celem projektu jest realizacja koncepcji Data Center Interconnect (DCI), która polega na stworzeniu bezpiecznego "wirtualnego kabla ethernetowego" rozciągniętego na dystansie setek kilometrów między dwoma centrami danych, umożliwiającego swobodną migrację maszyn wirtualnych (vMotion) w czasie rzeczywistym bez przerywania działania usług. Projekt zakłada pełne szyfrowanie danych przesyłanych między lokalizacjami przy użyciu technologii EoIP (Ethernet over IP), która jest protokołem własnym MikroTik opartym na GRE i nie jest standardem IETF, opakowanej w tunel IPsec, co chroni przed podsłuchem i modyfikacją ramek Ethernet przez nieautoryzowane podmioty w publicznym internecie. Zakres prac obejmuje konfigurację tuneli EoIP z unikalnymi identyfikatorami, mostków sieciowych (bridge) z tagowaniem VLAN, mechanizmów RSTP zapobiegających pętlom oraz optymalizację parametrów MTU dla zapewnienia maksymalnej przepustowości przy zachowaniu bezpieczeństwa.

Firma posiadająca dwa centra danych wykonane w technologii MikroTik (lub kompatybilnej) potrzebuje rozciągnąć VLAN serwerowy między lokalizacjami, aby umożliwić działającym w nich serwerom komunikację w tej samej domenie rozgłoszeniowej, co jest niezbędne dla klastrów baz danych, rozproszonych systemów plików oraz mechanizmów migracji maszyn wirtualnych. Problem polega na tym, że fizyczne łącze dzierżawione typu L2 między centrami danych jest kosztowne, a alternatywne rozwiązanie oparte na publicznym internecie niesie ze sobą ogromne ryzyko bezpieczeństwa - bez odpowiedniej ochrony ramki Ethernet przesyłane przez internet mogą być przechwycone przez atakujących wykorzystujących techniki ARP spoofing lub man-in-the-middle. Dodatkowo, firma musi zapewnić zgodność z regulacjami dotyczącymi przetwarzania danych wrażliwych (dane osobowe, w tym dane dotyczące zdrowia i dane finansowe, objęte szczególnymi wymogami RODO), które nakazują stosowanie szyfrowania podczas transmisji danych między lokalizacjami. Należy zatem wdrożyć rozwiązanie, które pozwoli na przesyłanie ramek Ethernet z pełnym szyfrowaniem IPsec, przy jednoczesnym zachowaniu natywnego zachowania warstwy drugiej (transparent bridge), tak, aby serwery w obu lokalizacjach "widziały" się w tej samej sieci LAN, niezależnie od fizycznej odległości.

• Ustalenie adresacji IP dla interfejsów WAN w obu centrach danych.
• Utworzenie interfejsu tunelowego EoIP na routerach MikroTik po obu stronach.
• Przypisanie unikalnego identyfikatora Tunnel ID dla wzajemnego powiązania końcówek.
• Zdefiniowanie polityk IPsec w trybie transportowym dla ochrony pakietów GRE/EoIP. Tryb transportowy nie dodaje drugiego nagłówka IP.
• Konfiguracja klucza współdzielonego lub certyfikatów dla uwierzytelniania IPsec.
• Utworzenie mostka sieciowego bridge w każdym DC i dodanie do niego tunelu EoIP.
• Skonfigurowanie tagowania VLAN na mostku w celu rozciągnięcia konkretnych sieci L2.
• Obniżenie MTU na interfejsie EoIP do 1400 bajtów lub mniej, zależnie od narzutu IPsec, oraz włączenie MSS clamping.
• Włączenie mechanizmu MSS Clamping dla ruchu TCP przechodzącego przez tunel.
• Konfiguracja protokołu RSTP (Rapid Spanning Tree Protocol) na mostku w celu zapobiegania pętlom sieciowym.
• Wdrożenie QoS na łączu WAN w celu priorytetyzacji ruchu między centrami danych.
• Testowanie opóźnień i przepustowości między serwerami w lokalizacjach.
• Przeprowadzenie migracji testowej maszyny wirtualnej (vMotion) przy aktywnym tunelu.
• Monitorowanie obciążenia procesora na routerach podczas szyfrowania dużego ruchu.
• Weryfikacja stanu polityk bezpieczeństwa poleceniem ip ipsec policy print (polecenie RouterOS, nie Cisco IOS).
• Sprawdzenie tablicy Bridge Hosts w celu potwierdzenia nauki adresów MAC z drugiego końca.
• Dokumentacja schematu adresacji VLAN i struktury ramek przesyłanych w tunelu.

Dokumentacja projektowa powinna zawierać szczegółowy opis koncepcji Data Center Interconnect (DCI) z wykorzystaniem tuneli EoIP over IPsec, w tym schemat topologii przedstawiający dwa centra danych połączone "wirtualnym kablem ethernetowym". Należy wyjaśnić mechanizm enkapsulacji EoIP (Ethernet over IP) i sposób jego opakowania w IPsec w trybie transportowym oraz omówić różnice między tym rozwiązaniem a tradycyjnym MPLS VPLS. Dokumentacja powinna zawierać analizę struktury ramek Ethernet z podwójnym tagowaniem (VLAN wewnętrzne) oraz wyjaśnienie konfiguracji MTU i MSS Clamping dla uniknięcia fragmentacji. Należy zamieścić pomiary opóźnień i przepustowości oraz opis testu migracji maszyn wirtualnych.

1. Wprowadzenie do technologii Data Center Interconnect DCI
2. Analiza wymagań rozciągnięcia VLAN między centrami danych
3. Projektowanie topologii DCI z wykorzystaniem EoIP over IPsec
4. Konfiguracja tuneli EoIP na urządzeniach MikroTik w obu lokalizacjach
5. Wdrożenie IPsec w trybie transportowym dla szyfrowania ruchu EoIP
6. Tworzenie mostków sieciowych bridge z tagowaniem VLAN
7. Konfiguracja RSTP na mostkach dla zapobiegania pętlom
8. Optymalizacja MTU i MSS Clamping dla tuneli
9. Pomiary opóźnień i przepustowości między centrami danych
10. Test migracji maszyn wirtualnych vMotion przez tunel DCI
11. Podsumowanie i wnioski z realizacji projektu

VPN_03 SSTP, TLS, VPN_07 Firewall fingerprinting.

Celem projektu jest zbudowanie rozwiązania VPN opartego na protokole SSTP (Secure Socket Tunneling Protocol), które wykorzystuje port 443 identyczny z ruchem HTTPS. Rozwiązanie jest trudniejsze do zablokowania niż klasyczne tunele IPsec, ale nie jest nieblokowalne, ponieważ systemy Deep Packet Inspection (DPI) mogą rozpoznać wzorce handshake, certyfikat i charakter ruchu. Projekt obejmuje wdrożenie mechanizmów maskowania ruchu, które uniemożliwiają systemom inspekcji pakietów rozpoznanie ruchu jako VPN poprzez eliminację charakterystycznych wzorców w nagłówkach i payloadach. Zakres prac obejmuje instalację i konfigurację serwera SSTP na platformie Windows Server lub kompatybilnej, pozyskanie certyfikatu TLS od zaufanego publicznego urzędu certyfikacji (np. Let's Encrypt, DigiCert) oraz implementację zaawansowanych mechanizmów bezpieczeństwa warstwy transportowej TLS 1.3 z wyłączeniem starszych, podatnych wersji.

Pracownicy korporacji przebywający w delegacjach w krajach lub sieciach o restrykcyjnej filtracji ruchu nie mogą korzystać ze standardowych narzędzi komunikacyjnych i dostępu do zasobów firmy, ponieważ lokalne systemy filtrowania ruchu internetowego aktywnie blokują znane protokoły VPN takie jak IPsec, OpenVPN czy WireGuard na podstawie analizy wzorców pakietów i charakterystycznych nagłówków. Problem jest tym poważniejszy, że pracownicy ci potrzebują stałego dostępu do wewnętrznych systemów firmy, poczty elektronicznej, baz danych oraz narzędzi do współpracy, a alternatywne metody komunikacji (telefony satelitarne, specjalistyczne usługi VPN) są albo zbyt drogie, albo niewystarczająco bezpieczne dla przesyłania wrażliwych danych biznesowych. Dodatkowo, próby użycia otwartego proxy lub nieznanych usług VPN w tych krajach mogą prowadzić do zablokowania dostępu do internetu lub nawet konsekwencji prawnych dla użytkownika. Należy wdrożyć serwer SSTP na porcie 443 TCP z certyfikatem TLS od zaufanego publicznego wystawcy, tak, aby ruch VPN był podobny do zwykłego ruchu HTTPS. Należy pamiętać, że SSTP ma charakterystyczny handshake HTTP i wzorce pakietów, więc nie jest całkowicie nieodróżnialny od przeglądania stron, a dostępność poszczególnych usług zależy od kraju i operatora.

• Rejestracja nazwy domenowej FQDN wskazującej na publiczny adres IP bramy VPN.
• Pozyskanie certyfikatu TLS od zaufanego urzędu (np. Let's Encrypt) dla domeny.
• Import certyfikatu i klucza prywatnego do konfiguracji serwera SSTP.
• Uruchomienie serwera SSTP na standardowym porcie TCP 443 (HTTPS).
• Konfiguracja uwierzytelniania klientów za pomocą certyfikatów, EAP-TLS albo MS-CHAPv2 wyłącznie jako rozwiązanie zgodnościowe.
• Wdrożenie polityki blokowania adresów IP po kilku nieudanych próbach logowania.
• Weryfikacja, jakie elementy ruchu SSTP są widoczne dla DPI, oraz omówienie ograniczeń maskowania.
• Ustawienie TLS 1.2 i 1.3 z wyłączeniem SSL oraz TLS 1.0/1.1. TLS 1.3 jest dostępny w Windows Server 2022 i Windows 11 oraz nowszych.
• Testowanie połączenia z sieci chronionej przez restrykcyjny firewall (np. uczelniany).
• Analiza nagłówków HTTP podczas procesu zestawiania tunelu SSTP.
• Porównanie skuteczności SSTP z protokołami IPsec i OpenVPN w trudnych warunkach.
• Konfiguracja klienta wbudowanego w system Windows w celu ominięcia restrykcji.
• Monitorowanie opóźnień i wpływu enkapsulacji TCP w TCP (TCP-in-TCP) na wydajność oraz omówienie ograniczeń tego modelu.
• Wdrożenie mechanizmu CRL do unieważniania skradzionych certyfikatów klienckich.
• Optymalizacja parametrów stosu TCP na serwerze SSTP w celu poprawy wydajności tunelu.
• Opisanie różnic w wykrywaniu ruchu przez systemy IDS typu Snort czy Suricata.
• Sprawdzenie logów firewalla pod kątem odrzuconych pakietów z innych portów VPN.

Dokumentacja projektowa powinna zawierać szczegółowy opis protokołu SSTP i mechanizmu działania TLS w kontekście tunelowania VPN, w tym schemat przedstawiający proces negocjacji TLS i nawiązywania tunelu SSTP. Należy wyjaśnić, dlaczego SSTP na porcie 443 jest trudniejszy do zablokowania przez systemy DPI i firewalle niż klasyczne tunele, jakie elementy ruchu pozostają widoczne oraz jakie są ograniczenia maskowania. Dokumentacja powinna zawierać analizę różnic między SSTP, OpenVPN i IPsec w kontekście odporności na filtrowanie, porównanie TLS 1.2 i 1.3 pod kątem bezpieczeństwa oraz omówienie scenariuszy użycia w krajach z restrykcyjnym filtrowaniem internetu. Należy zamieścić wyniki testów łączności z różnych sieci.

1. Wprowadzenie do protokołu SSTP i technik omijania zapór ogniowych
2. Analiza mechanizmów Deep Packet Inspection i filtrowania ruchu
3. Instalacja i konfiguracja serwera SSTP na Windows Server
4. Pozyskanie certyfikatu TLS od publicznego urzędu CA
5. Konfiguracja TLS 1.3 z wyłączeniem podatnych wersji
6. Weryfikacja widoczności ruchu SSTP dla DPI i omówienie ograniczeń maskowania
7. Testowanie łączności z sieci restrykcyjnych (firewall korporacyjny)
8. Analiza nagłówków HTTP podczas negocjacji SSTP
9. Porównanie skuteczności SSTP z innymi protokołami VPN
10. Weryfikacja logów serwera i firewalla
11. Podsumowanie i wnioski z realizacji projektu

VPN_05 Dynamic Routing, VPN_02 GRE encapsulation.

Celem projektu jest zaprojektowanie i wdrożenie wydajnego i automatycznego systemu routingu dla sieci obsługujących zarówno protokół IPv4 jak i IPv6, który zapewni optymalne trasowanie ruchu między wszystkimi oddziałami firmy przy minimalnym nakładzie pracy administracyjnej. Projekt łączy elastyczność tuneli GRE (Generic Routing Encapsulation), umożliwiających przesyłanie dowolnego ruchu warstwy trzeciej, z bezpieczeństwem zapewnianym przez IPsec w trybie transportowym, który chroni pakiet GRE bez dodawania drugiego nagłówka IP oraz automatyzacją oferowaną przez protokół routingu OSPFv3, który samodzielnie wykrywa zmiany w topologii sieci i aktualizuje tablice routingu. Zakres prac obejmuje konfigurację tuneli GRE między wszystkimi lokalizacjami, ich zabezpieczenie poprzez IPsec, wdrożenie OSPFv3 z odpowiednią hierarchią obszarów oraz optymalizację kosztów interfejsów dla zapewnienia najkrótszych ścieżek do każdej sieci.

Firma prowadząca rozległą sieć oddziałów na terenie całego kraju migruje stopniowo do standardu IPv6, zachowując jednocześnie pełną kompatybilność wsteczną z IPv4, ponieważ wiele systemów partnerskich i dostawców nadal działa wyłącznie w przestrzeni adresowej IPv4. Każdy z oddziałów posiada obecnie kilkanaście do kilkudziesięciu sieci lokalnych obu rodzin protokołów, a całkowita liczba prefiksów wymienianych między lokalizacjami sięga tysięcy, co sprawia, że ręczne zarządzanie trasami statycznymi jest niewykonalne - każda zmiana w topologii (dodanie nowego oddziału, awaria łącza, zmiana dostawcy internetu) wymagałaby manualnej rekonfiguracji na każdym urządzeniu, co w praktyce prowadzi do opóźnień i błędów konfiguracyjnych. Dodatkowo, firma obsługuje krytyczne aplikacje czasu rzeczywistego (wideokonferencje, VoIP, systemy transakcyjne), które wymagają najniższych możliwych opóźnień i automatycznego omijania awaryjnych łączy w czasie rzeczywistym, bez oczekiwania na interwencję administratora. Należy stworzyć stabilną i bezpieczną strukturę szkieletową opartą na tunelach GRE/IPsec, która obsłuży dynamiczną wymianę tysięcy prefiksów IPv4 i IPv6 bez konieczności ręcznego wpisywania tras statycznych, wykorzystując protokół OSPFv3 do automatycznej zbieżności sieci i optymalizacji ścieżek routingu w oparciu o aktualny stan łączy.

• Ustalenie globalnych prefiksów IPv6 dla obu lokalizacji oraz sieci tranzytowej.
• Konfiguracja interfejsów GRE (Generic Routing Encapsulation) między routerami.
• Szyfrowanie ruchu GRE przy użyciu IPsec w trybie transportowym dla oszczędności nagłówka.
• Przypisanie adresów IPv6 link-local na końcach tunelu GRE.
• Uruchomienie procesu routingu OSPFv3 na obu routerach brzegowych.
• Zdefiniowanie obszarów OSPF (Area 0) i przypisanie do nich interfejsów tunelowych.
• Konfiguracja OSPFv3 dla IPv6 oraz OSPFv2 dla IPv4. Alternatywnie można użyć OSPFv3 Address Families (RFC 5838), jeśli platforma to obsługuje.
• Ustawienie parametrów kosztu łączy w celu wymuszenia optymalnych ścieżek.
• Wdrożenie ochrony OSPFv3 za pomocą IPsec AH lub ESP zgodnie z RFC 4552. OSPFv3 nie ma własnego pola uwierzytelniania w nagłówku.
• Konfiguracja routerów jako ASBR (Autonomous System Boundary Router) w przypadku łączenia z innymi systemami autonomicznymi.
• Testowanie zbieżności sieci po wyłączeniu jednego z łączy zapasowych.
• Analiza bazy LSDB pod kątem Router LSA, Network LSA, Link LSA i Intra-Area-Prefix LSA.
• Weryfikacja tablicy routingu poleceniem show ipv6 route ospf.
• Implementacja filtracji tras za pomocą Prefix-list w celu ograniczenia rozgłaszanych sieci.
• Sprawdzenie poprawności enkapsulacji pakietów OSPF wewnątrz IPsec-GRE.
• Dokumentacja planu adresacji z uwzględnieniem agregacji prefiksów IPv6.
• Monitorowanie obciążenia procesora podczas przesyłania aktualizacji bazy topologii.

Dokumentacja projektowa powinna zawierać szczegółowy opis routingu dynamicznego z wykorzystaniem OSPFv3 w środowisku dual-stack (IPv4/IPv6), w tym schemat topologii sieci z zaznaczeniem obszarów OSPF i interfejsów tunelowych GRE. Należy wyjaśnić mechanizm enkapsulacji GRE i sposób jej szyfrowania przez IPsec w trybie transportowym oraz omówić różnice między OSPFv2 a OSPFv3, a także sposób obsługi IPv4 i IPv6 w trybie dual-stack. Dokumentacja powinna zawierać analizę bazy danych LSDB (Link-State Database), typów LSA (Router LSA, Network LSA, Link LSA, Intra-Area-Prefix LSA) i procesu zbieżności protokołu. Należy zamieścić plan adresacji IPv6 z uwzględnieniem agregacji prefiksów oraz wyniki testów zbieżności po awarii łącza.

1. Wprowadzenie do routingu dynamicznego OSPFv3 w sieciach dual-stack
2. Analiza wymagań migracji do IPv6 w sieci korporacyjnej
3. Projektowanie topologii sieci i plan adresacji IPv4/IPv6
4. Konfiguracja tuneli GRE między routerami brzegowymi
5. Wdrożenie IPsec w trybie transportowym dla szyfrowania GRE
6. Konfiguracja OSPFv3 dla IPv6 na interfejsach tunelowych
7. Konfiguracja OSPFv3 dla IPv6 oraz OSPFv2 dla IPv4 (lub OSPFv3 Address Families, jeśli platforma to obsługuje)
8. Analiza LSDB i typów LSA w protokole OSPFv3 (Router, Network, Link i Intra-Area-Prefix)
9. Testowanie zbieżności po awarii łącza zapasowego
10. Weryfikacja tablicy routingu poleceniem show ipv6 route ospf
11. Podsumowanie i wnioski z realizacji projektu

VPN_06 Q-in-Q, VLAN tagging, Ethernet over Tunnels.

Celem projektu jest realizacja techniki 802.1ad (Provider Bridges, Q-in-Q) w usłudze L2VPN, która pozwala na przesyłanie wielu VLAN-ów klienta (C-VLAN) wewnątrz jednego tagu usługowego (S-VLAN) dostarczanego przez tunel L2VPN, przy jednoczesnym ukryciu wewnętrznej struktury sieci klienta przed dostawcą usług telekomunikacyjnych. Projekt obejmuje konfigurację mechanizmu Double Tagging, gdzie ramki Ethernet klienta otrzymują dodatkowy zewnętrzny znacznik VLAN należący do dostawcy, co umożliwia ich izolację i transport przez infrastrukturę ISP bez konieczności analizowania lub modyfikowania wewnętrznej numeracji VLAN. Zakres prac obejmuje konfigurację urządzeń brzegowych obsługujących standard 802.1ad, mapowanie VLAN klienta na VLAN dostawcy, ustawienie odpowiednich wartości MTU dla obsługi rozszerzonych nagłówków oraz testowanie poprawności działania mechanizmu z różnymi typami ruchu sieciowego.

Dostawca usług telekomunikacyjnych (ISP) musi dostarczyć niezawodne połączenie warstwy drugiej L2 między dwiema fabrykami klienta przemysłowego, które znajdują się w odległych lokalizacjach i potrzebują wspólnej infrastruktury sieciowej dla swoich systemów produkcyjnych, systemów SCADA oraz wewnętrznej telefonii VoIP działającej w wydzielonych VLAN-ach. Klient posiada własną strukturę VLAN obejmującą wiele sieci (produkcja, logistyka, administracja, monitoring, VoIP), które są krytyczne dla jego działalności i które dostawca nie chce ani nie musi analizować ani modyfikować - ISP zapewnia jedynie "rurę" transportową, nie wchodząc w szczegóły ruchu klienta. Problem polega na tym, że tradycyjne metody tunelowania L2VPN (jak MPLS VPLS) są kosztowne i wymagają specjalistycznego sprzętu, podczas gdy klient chce prostej, elastycznej usługi, która zachowa pełną transparentność jego struktury VLAN bez względu na to, jak będzie ją w przyszłości modyfikować. Należy zaimplementować technikę Q-in-Q (802.1ad), która "zapakowuje" wszystkie VLAN-y klienta w jeden zewnętrzny tag usługowy dostawcy, tworząc wirtualny segment sieci LAN rozciągnięty między fabrykami, przy czym wewnętrzne VLAN-y klienta pozostają niewidoczne i niezmienione dla infrastruktury ISP.

• Przygotowanie przełączników z obsługą standardu IEEE 802.1ad (Provider Bridges).
• Konfiguracja portów klienckich do przyjmowania ramek z tagami 802.1Q.
• Ustanowienie tunelu L2, na przykład VXLAN albo L2TPv3, jako szkieletu usługi. VXLAN wymaga większego MTU niż Q-in-Q.
• Konfiguracja mapowania VLAN klienckich (C-VLAN) do wspólnego tagu dostawcy (S-VLAN).
• Zdefiniowanie EtherType dla tagu zewnętrznego S-VLAN na wartość 0x88A8.
• Ustawienie MTU na interfejsach fizycznych na co najmniej 1522 bajty dla ramek z podwójnym tagiem. Jeśli używany jest VXLAN, należy przyjąć co najmniej 1550 bajtów.
• Weryfikacja zachowania znacznika Priority (PCP) po przejściu przez tunel.
• Konfiguracja przełącznika brzegowego do usuwania tagu zewnętrznego przy wyjściu do klienta.
• Testowanie separacji ruchu między różnymi VLAN-ami klienta w jednym tunelu.
• Analiza struktury ramek Double Tagging w zrzutach pakietów z Wiresharka.
• Sprawdzenie poprawności nauki adresów MAC w poszczególnych domenach rozgłoszeniowych.
• Konfiguracja mechanizmów zapobiegających pętlom (STP) oraz L2PT (Layer 2 Protocol Tunneling) dla ramek STP, CDP i VTP klienta.
• Monitorowanie wykorzystania pasma przez poszczególne S-VLAN-y.
• Opisanie wyzwań związanych z fragmentacją pakietów IP przy zwiększonym nagłówku L2.
• Dokumentacja schematu mapowania VLAN na brzegach sieci dostawcy.
• Weryfikacja stabilności połączenia przy przesyłaniu dużej ilości małych ramek Ethernet.
• Porównanie wydajności Q-in-Q z technologią MPLS VPLS w podobnym scenariuszu.

Dokumentacja projektowa powinna zawierać szczegółowy opis techniki Q-in-Q (802.1ad) i mechanizmu Double Tagging w sieciach operatora, w tym schemat przedstawiający strukturę ramek Ethernet z podwójnym tagowaniem (C-VLAN wewnątrz S-VLAN). Należy wyjaśnić różnice między standardem 802.1Q (pojedynczy tag) a 802.1ad (podwójny tag) oraz omówić zastosowania w modelu L2VPN dla klientów korporacyjnych. Dokumentacja powinna zawierać analizę wartości MTU (minimum 1522 bajty dla ramek z podwójnym tagiem), obsługi protokołów warstwy 2 (STP, CDP, VTP) przez tunel oraz wymagań EtherType. Należy zamieścić porównanie Q-in-Q z MPLS VPLS pod kątem kosztów i możliwości.

1. Wprowadzenie do technologii Q-in-Q (802.1ad) w sieciach operatora
2. Analiza wymagań dostawcy usług dla połączenia L2 między fabrykami
3. Projektowanie architektury sieci z wykorzystaniem Provider Bridges
4. Konfiguracja portów klienckich do przyjmowania ramek 802.1Q
5. Implementacja mapowania C-VLAN na S-VLAN na urządzeniach brzegowych
6. Ustawienie EtherType dla zewnętrznego tagu S-VLAN (0x88A8)
7. Konfiguracja MTU 1522+ na interfejsach fizycznych (1550+ przy VXLAN)
8. Obsługa protokołów L2 (STP, CDP) przez tunel Q-in-Q
9. Testowanie separacji ruchu między VLAN-ami klienta
10. Analiza struktury ramek Double Tagging w Wiresharku
11. Porównanie Q-in-Q z MPLS VPLS
12. Podsumowanie i wnioski z realizacji projektu

VPN_05 PBR, NAT w tunelach, VPN_07 Wydajność VPN.

Celem projektu jest stworzenie inteligentnego systemu zarządzania ruchem w tunelach VPN, który łączy sterowanie ścieżką pakietu na podstawie jego typu (Policy-Based Routing) z gwarancją pasma dla usług czasu rzeczywistego (Quality of Service), zapewniając optymalne wykorzystanie dostępnych zasobów sieciowych przy jednoczesnej ochronie krytycznych aplikacji. Projekt obejmuje implementację wielopoziomowych kolejek priorytetowych, klasyfikację ruchu na podstawie portów, protokołów i znaczników DSCP oraz automatyczne przełączanie ruchu między tunelami w przypadku degradacji jakości łącza. Mechanizmy należy dobrać do platformy: w Linuksie tc z HTB (Hierarchical Token Bucket), HFSC (Hierarchical Fair Service Curve), SFQ i FQ-CoDel; w Cisco CBWFQ i LLQ; w MikroTik queue tree i simple queues. Zakres prac obejmuje konfigurację znakowania pakietów, utworzenie oddzielnych tablic routingu dla różnych klas ruchu oraz wdrożenie mechanizmów monitorowania jakości (RTT, jitter, packet loss) z automatyczną reakcją na pogorszenie parametrów.

Główne łącze VPN łączące centralę firmy z oddziałami jest systematycznie przeciążone, ponieważ przez tunel przesyłane są jednocześnie krytyczne aplikacje biznesowe (systemy ERP, bazy danych, RDP), ruch czasu rzeczywistego (wideokonferencje VoIP, telefon IP) oraz niskopriorytetowe operacje takie jak synchronizacja plików, aktualizacje oprogramowania i kopie zapasowe wykonywane w tle. Problem polega na tym, że brak jakiejkolwiek kontroli jakości powoduje, że niskopriorytetowy ruch (np. wielogigabajtowe kopiowanie plików) zwiększa opóźnienia i ogranicza przepustowość potrzebną dla VoIP i RDP, co skutkuje "zamrożeniem" ekranu podczas zdalnej pracy, przerwanymi rozmowami telefonicznymi oraz ogólnym spowolnieniem pracy wszystkich użytkowników, co bezpośrednio przekłada się na straty produktywności i frustrację pracowników. Dodatkowo, firma posiada dwa niezależne łącza internetowe (jedno szybkie, ale droższe, drugie wolniejsze, ale tańsze), które są wykorzystywane nieefektywnie - oba pracują z podobnym obciążeniem, zamiast inteligentnie rozdzielać ruch według jego charakterystyki i wymagań. Należy wdrożyć kompleksową politykę zarządzania ruchem, według której ruch pocztowy, transfery plików i kopie zapasowe automatycznie kierowane są do tańszego tunelu o mniejszej wadze, natomiast ruch terminalowy (RDP), głosowy (VoIP) oraz wideokonferencje mają zagwarantowany priorytet, dedykowane pasmo i najniższe możliwe opóźnienia na szybszym łączu, z automatycznym przełączeniem awaryjnym w przypadku problemów.

• Uruchomienie dwóch niezależnych tuneli VPN (np. WireGuard i IPsec) o różnej wadze.
• Konfiguracja znakowania pakietów DSCP w zależności od platformy: iptables -t mangle w Linuksie, ip firewall mangle w RouterOS albo set ip dscp w route-map Cisco.
• Utworzenie oddzielnych tablic routingu dla różnych klas ruchu sieciowego.
• Implementacja reguł RPDB (Routing Policy Database, ip rule) w Linuksie albo route-map z PBR w Cisco.
• Konfiguracja kolejek QoS dla każdego z interfejsów tunelowych: HTB w Linuksie, CBWFQ/LLQ w Cisco albo queue tree w MikroTik.
• Zdefiniowanie klas priorytetowych z gwarantowanym pasmem (CIR) i nadmiarowym (EIR).
• Zastosowanie algorytmu SFQ, FQ-CoDel albo fq_codel w zależności od platformy, w celu sprawiedliwego podziału pasma wewnątrz klasy.
• Ograniczenie pasma dla ruchu o niskim priorytecie, na przykład aktualizacji systemu i kopii zapasowych.
• Wdrożenie mechanizmu monitorowania opóźnień (RTT) dla każdego tunelu.
• Konfiguracja skryptów automatycznie przełączających ruch VoIP w przypadku degradacji łącza.
• Testowanie zachowania wideokonferencji podczas sztucznego generowania dużego pobierania.
• Graficzna analiza zajętości pasma na poszczególnych kolejkach w czasie rzeczywistym.
• Weryfikacja oznaczania pakietów poleceniem iptables -t mangle -L -v w Linuksie albo /ip firewall mangle print stats w RouterOS.
• Pomiar parametrów jittera (wariacji opóźnienia) i utraty pakietów przed i po wdrożeniu mechanizmów QoS.
• Konfiguracja limitów pasma dla poszczególnych adresów IP lub podsieci użytkowników.
• Dokumentacja polityki QoS z podziałem na klasy: Real-time, Business-Critical i Bulk.
• Wyjaśnienie, że po szyfrowaniu DPI nie widzi nagłówków wewnętrznych, dlatego klasyfikację trzeba wykonać przed szyfrowaniem, na przykład przez DSCP.

Dokumentacja projektowa powinna zawierać szczegółowy opis systemu zarządzania ruchem z wykorzystaniem QoS i Policy-Based Routing, w tym schemat topologii z zaznaczeniem dwóch tuneli VPN i kolejek priorytetowych. Należy wyjaśnić mechanizm działania znaczników DSCP, kolejkowania HTB oraz algorytmów SFQ i FQ-CoDel dla sprawiedliwego podziału pasma. Dokumentacja powinna zawierać analizę różnic między ruchem Real-time, Business-Critical i Bulk, polityki klasyfikacji pakietów oraz automatyczne przełączanie ruchu między tunelami. Należy zamieścić pomiary opóźnień, jittera (wariacji opóźnienia) i utraty pakietów przed i po wdrożeniu QoS oraz wykresy wykorzystania pasma.

1. Wprowadzenie do QoS i Policy-Based Routing w sieciach VPN
2. Analiza wymagań zarządzania ruchem w przeciążonym łączu
3. Projektowanie topologii z dwoma niezależnymi tunelami VPN
4. Konfiguracja znakowania pakietów DSCP w zależności od platformy
5. Implementacja kolejek QoS dla gwarantowanego pasma (HTB w Linuksie; CBWFQ/LLQ w Cisco; queue tree w MikroTik)
6. Konfiguracja algorytmów SFQ i FQ-CoDel (Linux) lub odpowiedników platformowych
7. Wdrożenie PBR dla kierowania ruchu na podstawie typu
8. Konfiguracja automatycznego przełączania VoIP przy degradacji łącza
9. Pomiary opóźnień i jittera (wariacji opóźnienia) przed i po QoS
10. Analiza wykorzystania pasma na kolejkach w czasie rzeczywistym
11. Podsumowanie i wnioski z realizacji projektu

VPN_07 Utwardzanie VPN, Zero Trust, filtrowanie ruchu.

Celem projektu jest wdrożenie najbardziej restrykcyjnego modelu bezpieczeństwa dostępu do sieci VPN, opartego na filozofii Zero Trust, która zakłada, że żaden użytkownik ani urządzenie nie jest domyślnie zaufany i musi udowodnić swoją tożsamość oraz stan bezpieczeństwa przy każdej próbie dostępu do zasobów. Projekt koncentruje się na utwardzeniu samej infrastruktury bramy VPN poprzez ukrycie jej przed nieautoryzowanymi skanerami, wdrożenie zaawansowanych mechanizmów wykrywania i blokowania ataków oraz implementację systemu weryfikacji Endpoint Compliance, który sprawdza stan bezpieczeństwa komputera klienta (aktualność systemu operacyjnego, obecność i aktualność oprogramowania antywirusowego, obecność firewalla) przed dopuszczeniem do sieci. Zakres prac obejmuje konfigurację mechanizmu Port Knocking lub Single Packet Authorization (SPA), instalację i konfigurację skryptów sprawdzających zgodność urządzeń, implementację list ACL ograniczających dostęp na podstawie certyfikatów urządzeń oraz konfigurację zaawansowanego logowania i monitorowania zdarzeń bezpieczeństwa.

Firma z sektora finansowego, obsługująca wrażliwe dane klientów i podlegająca rygorystycznym wymogom bezpieczeństwa, w tym PCI DSS i RODO, żywi poważne obawy, że zainfekowane laptopy pracowników mogą przenieść ransomware, malware lub inne zagrożenia do sieci centralnej, powodując wyciek danych klientów lub paraliż operacji biznesowych. Problem polega na tym, że tradycyjne modele bezpieczeństwa zakładają, że użytkownik, który poprawnie się uwierzytelnił, jest zaufany i ma pełny dostęp do zasobów sieci, co w erze nowoczesnych zagrożeń jest niewystarczające - atakujący mogą przejąć poświadczenia pracownika (phishing, keylogger) lub wykorzystać podatności w jego komputerze, uzyskując dostęp do wszystkich zasobów bez dodatkowej weryfikacji. Dodatkowo, historia pokazuje, że wiele ataków ransomware zaczęło się od zainfekowanego laptopa podłączonego do korporacyjnej sieci VPN, gdzie złośliwe oprogramowanie rozprzestrzeniło się na serwery centralne, powodując milionowe straty. Należy wdrożyć mechanizm port knocking lub Single Packet Authorization (SPA), który utrudnia wykrycie bramy i ogranicza ataki na zamknięte usługi, ale nie czyni jej całkowicie niewidoczną, a porty otwierają się tylko dla wcześniej uwierzytelnionych klientów, którzy "zapukali" w odpowiedni sposób. Równocześnie, przed nawiązaniem pełnego tunelu VPN, system musi sprawdzić zgodność komputera klienta z polityką bezpieczeństwa (endpoint compliance): czy system operacyjny i oprogramowanie antywirusowe są zaktualizowane, czy firewall jest włączony, czy nie są obecne podejrzane procesy - tylko spełnienie tych warunków daje dostęp do pełnych zasobów sieci.

• Konfiguracja reguł firewalla blokujących całkowicie dostęp do portów VPN z zewnątrz.
• Wdrożenie skryptu monitorującego logi pod kątem sekwencji pakietów Port Knocking.
• Konfiguracja bramy tak, aby otwierała port protokołu VPN (UDP lub TCP, zależnie od wybranego rozwiązania) dla adresu IP klienta na określony czas.
• Wygenerowanie unikalnych certyfikatów dla każdego urządzenia końcowego.
• Implementacja sprawdzania tożsamości klienta w oparciu o certyfikat oraz login/hasło.
• Konfiguracja skryptu sprawdzającego na kliencie obecność zaktualizowanego antywirusa.
• Weryfikacja sum kontrolnych krytycznych plików systemowych przed dopuszczeniem do sieci.
• Ograniczenie uprawnień zalogowanego użytkownika przy użyciu list ACL i Firewall.
• Wyłączenie zbędnych usług i protokołów na systemie operacyjnym bramy VPN.
• Konfiguracja mechanizmu logowania wszystkich zdarzeń do bazy danych zabezpieczonej przed modyfikacją.
• Wdrożenie automatycznego unieważniania sesji po wykryciu nietypowego zachowania (np. skanowanie portów).
• Zastosowanie najnowszych bibliotek OpenSSL i regularna aktualizacja oprogramowania routera.
• Testowanie odporności bramy na ataki SYN flood i brute-force przy zamkniętym porcie.
• Analiza ryzyka związanego z kradzieżą urządzenia końcowego i procedury blokady dostępu.
• Sprawdzenie zgodności konfiguracji z zaleceniami bezpieczeństwa CIS Benchmarks (https://www.cisecurity.org/cis-benchmarks); serwis może blokować automatyczne zapytania i zwracać 403.
• Dokumentacja polityki bezpieczeństwa Clean Desk i Clean Endpoint dla pracowników zdalnych.
• Weryfikacja skuteczności ukrycia bramy za pomocą Nmap i skanerów zewnętrznych. Shodan nie wykonuje skanowania na żądanie, więc jego wynik może być nieaktualny.

Dokumentacja projektowa powinna zawierać szczegółowy opis modelu Zero Trust w kontekście bezpieczeństwa VPN, w tym schemat architektury przedstawiający proces weryfikacji urządzenia i użytkownika przed dopuszczeniem do sieci. Należy wyjaśnić mechanizm działania Port Knocking/Single Packet Authorization (SPA) oraz systemu Endpoint Compliance Checking sprawdzającego stan bezpieczeństwa komputera klienta. Dokumentacja powinna zawierać analizę różnic między tradycyjnym modelem perimeter security a Zero Trust, procedury weryfikacji antywirusa, firewalla i aktualności systemu operacyjnego. Należy zamieścić wyniki testów odporności bramy na ataki przed i po utwardzeniu.

1. Wprowadzenie do modelu Zero Trust w sieciach VPN
2. Analiza zagrożeń ransomware i obaw przed zainfekowanymi laptopami
3. Projektowanie architektury Zero Trust dla bramy VPN
4. Implementacja Port Knocking dla ukrycia bramy przed skanerami
5. Konfiguracja Single Packet Authorization (SPA)
6. Wdrożenie systemu Endpoint Compliance Checking
7. Sprawdzanie antywirusa, firewalla i aktualności OS klienta
8. Utwardzanie systemu operacyjnego bramy VPN
9. Generowanie unikalnych certyfikatów dla urządzeń końcowych
10. Testowanie odporności na ataki brute-force i DoS
11. Weryfikacja ukrycia bramy za pomocą Nmap i skanerów zewnętrznych
12. Podsumowanie i wnioski z realizacji projektu