Zadania projektowe - Wirtualne Sieci Prywatne

VPN_03 Architektura IPSec, VPN_07 PKI i certyfikaty.

Celem projektu jest wdrożenie nowoczesnego tunelu Site-to-Site w oparciu o standard IKEv2, który zapewni najwyższy poziom bezpieczeństwa komunikacji między centralą instytucji a jej głównym węzłem chmurowym. Projekt zakłada całkowitą rezygnację z przestarzałych kluczy współdzielonych (PSK) na rzecz wzajemnego uwierzytelniania opartego na certyfikatach cyfrowych wystawionych przez wewnętrzny urząd certyfikacji (CA). 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ż w przypadku wycieku klucza atakujący może odszyfrować całą historię przechwyconego ruchu, co w sektorze finansowym jest niedopuszczalne ze względu na regulacje compliance i ryzyko ogromnych strat finansowych oraz utraty reputacji. Dodatkowo, audyt bezpieczeństwa wykazał, że stosowane algorytmy szyfrowania nie spełniają wymogów normy PCI-DSS, która nakazuje stosowanie silnych mechanizmów uwierzytelniania i szyfrowania z wykorzystaniem certyfikatów X.509. Konieczne jest zatem wdrożenie IKEv2 z algorytmami AES-GCM 256-bit dla zapewnienia poufności i integralności przesyłanych danych, przy jednoczesnym zastąpieniu podatnych na ataki kluczy PSK profesjonalną infrastrukturą certyfikatów z wewnętrznym urzędem CA. Projekt wymaga również zapewnienia automatycznej rotacji kluczy poprzez odpowiednie skonfigurowanie parametrów Lifetime oraz wdrożenia mechanizmu Dead Peer Detection (DPD) do ciągłego monitorowania stanu tunelu, co pozwoli na automatyczne renegocjowanie połączenia w przypadku jego przerwania przez awarię łącza lub atak DDoS.

• 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 mechanizmu dystrybucji list odwołania certyfikatów CRL (np. przez HTTP).
• Wdrożenie profilu IKEv2 z określeniem parametrów negocjacji fazy pierwszej.
• Wybór silnego szyfrowania AES-GCM 256 dla fali 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 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 -> Intermediate 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 infrastruktury kluczy publicznych.

1. Wprowadzenie do technologii IKEv2 i infrastruktury PKI w sieciach korporacyjnych
2. Analiza wymogów bezpieczeństwa instytucji finansowej i regulacji compliance
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 Bridging 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. Projekt kładzie ekstremalny nacisk na bezpieczeństwo kanału kontrolnego poprzez implementację TLS-Auth, wymuszonego użycia TLS w wersji 1.3 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 inżynieryjna specjalizująca się w projektowaniu infrastruktury przemysłowej musi umożliwić swoim pracownikom zdalnym dostęp do specyficznych usług działających tylko w warstwie 2, takich jak systemy SCADA, protokoły przemysłowe Modbus czy Profinet, oraz starsze aplikacje sieciowe wykorzystujące rozgłaszanie ramek broadcastowych. 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 exploitacji znanych podatności. Należy tak zabezpieczyć serwer, aby był on całkowicie niewidoczny dla skanerów internetowych poprzez zastosowanie mechanizmu TLS-Auth jako dodatkowej warstwy ochronnej, która odrzuca pakiety nieposiadające poprawnego klucza statycznego jeszcze przed rozpoczęciem negocjacji TLS. 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 ruterze łą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 dla najwyższego poziomu bezpieczeństwa.
• Wdrożenie katalogu Client Config Dir CCD do precyzyjnego zarządzania ustawieniami użytkowników.
• Przypisanie statycznych adresów IP oraz adresów MAC dla konkretnych klientów w plikach CCD.
• Wyłączenie kompresji LZO na rzecz bezpieczeństwa kanału przed atakami typu VORACLE.
• Konfiguracja silnych szyfrów danych AES-256-GCM oraz algorytmu skrótu SHA-512.
• 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 kompletnych plików konfiguracyjnych .ovpn zawierających wbudowane certyfikaty.
• Testowanie dostępu do usług L2 takich jak gry sieciowe lub starsze protokoły przemysłowe.
• 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 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, sieciowe gry
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 ruteró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 między węzłami klastra 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 poniesie ogromne konsekwencje prawne i finansowe za naruszenie przepisów dotyczących ochrony zdrowia. 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 rutery brzegowe pracujące w klastrze High Availability, które będą współdzielić wirtualny adres bramy VPN (VIP), przy czym każdy z nich będzie posiadał niezależne łącze internetowe od innego dostawcy, co zapewni rzeczywistą redundancję na poziomie infrastruktury telekomunikacyjnej.

• 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 sesji conn-sync dla zachowania stanu połączeń.
• 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 w VRRP w celu uniknięcia efektu flapowania.
• 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 detail na obu węzłach.
• Konfiguracja logowania zdarzeń HA do centralnego serwera Syslog.
• Zapewnienie redundancji zasilania i łączy fizycznych dla każdego z ruterów.
• Sprawdzenie trwałości sesji SSH lub UDP podczas procesu przełączania Failover.
• 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 dwóch różnych dostawców internetu. 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 conn-sync dla zachowania sesji
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 detail
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ę rutera z serwerem RADIUS (NPS lub FreeRADIUS), w tym konfigurację atrybutów AAA dla sieciowego kontroli dostępu, oraz wdrożenie drugiego składnika autentykacji (MFA) 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, iOS i Android bez konieczności instalowania dodatkowego oprogramowania.

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ładnikowej autentykacji, która znacząco utrudni przejęcie konta nawet w przypadku skompromitowania hasła. Należy tak skonfigurować bramę VPN, aby pakiety autentykacyjne były przekazywane do centralnego serwera RADIUS (NPS 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 jednorazowym generowanym przez aplikację mobilną (Google Authenticator, Microsoft Authenticator) lub wysłanym SMS-em.

• 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 ruterze 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.
• Konfiguracja routera w trybie MS-CHAPv2 dla bezpiecznego przekazywania haseł.
• Weryfikacja komunikacji RADIUS za pomocą narzędzia radtest na serwerze.
• Testowanie połączenia z poziomu systemów Windows i Android bez instalacji dodatkowego oprogramowania.
• Analiza pakietów Access-Request i Access-Accept w Wiresharku na porcie UDP 1812.
• 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 i Access-Accept 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, iOS i Android
9. Analiza pakietów RADIUS w Wiresharku - Access-Request, Access-Accept
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, 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) 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 niezwykle kosztowne (nawet kilkadziesiąt tysięcy złotych miesięcznie), 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 medyczne, finansowe, osobowe), 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 ruterach MikroTik po obu stronach.
• Przypisanie unikalnego identyfikatora Tunnel ID dla wzajemnego powiązania końcówek.
• Zdefiniowanie polityk IPSec w trybie Transport Mode dla szyfrowania pakietów GRE/EoIP.
• Konfiguracja klucza współdzielonego lub certyfikatów dla autentykacji 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 wartości MTU na interfejsie EoIP do 1450 bajtów w celu uniknięcia fragmentacji.
• Włączenie mechanizmu MSS Clamping dla ruchu TCP przechodzącego przez tunel.
• Konfiguracja protokołu RSTP 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ń (Latency) i przepustowości (Throughput) między serwerami v lokalizacjach.
• Przeprowadzenie migracji testowej maszyny wirtualnej (vMotion) przy aktywnym tunelu.
• Monitorowanie obciążenia procesora na ruterach podczas szyfrowania dużego ruchu.
• Weryfikacja stanu polityk bezpieczeństwa poleceniem ip ipsec policy print.
• 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 Transport Mode, 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 Transport Mode 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, SSL/TLS, VPN_07 Firewall fingerprinting.

Celem projektu jest zbudowanie niemal nieblokowalnego rozwiązania VPN bazującego na protokole SSTP (Secure Socket Tunneling Protocol), które wykorzystuje port 443 identyczny z ruchem HTTPS, co pozwala na omijanie restrykcyjnych zapór ogniowych i systemów Deep Packet Inspection (DPI). 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 SSL 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 o wysokiej cenzurze internetowej (Chiny, Iran, Rosja, niektóre kraje arabskie) 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 SSL od zaufanego publicznego wystawcy, tak aby ruch VPN był całkowicie nieodróżnialny od zwykłego przeglądania stron bankowych lub korzystania z usług takich jak Gmail czy Microsoft 365, które w żadnym kraju nie są blokowane ze względu na ich powszechność i znaczenie gospodarcze.

• Rejestracja nazwy domenowej FQDN wskazującej na publiczny adres IP bramy VPN.
• Pozyskanie certyfikatu SSL 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 przy pomocy certyfikatów lub MS-CHAPv2.
• Wdrożenie polityki blokowania adresów IP po kilku nieudanych próbach logowania.
• Konfiguracja mechanizmów maskowania ruchu w celu upodobnienia go do HTTPS.
• Ustawienie silnych szyfrów TLS 1.2/1.3 z wyłączeniem podatnych wersji SSL.
• 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 jakości połączenia pod kątem opóźnień wprowadzanych przez TCP wewnątrz TCP.
• Wdrożenie mechanizmu CRL do unieważniania skradzionych certyfikatów klienckich.
• Optymalizacja parametrów stosu TCP na ruterze 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 SSL/TLS w kontekście tunelowania VPN, w tym schemat przedstawiający proces negocjacji SSL i nawiązywania tunelu SSTP. Należy wyjaśnić, dlaczego SSTP na porcie 443 jest trudny do zablokowania przez systemy DPI i firewalle oraz jakie techniki maskowania ruchu można zastosować. Dokumentacja powinna zawierać analizę różnic między SSTP, OpenVPN i IPSec w kontekście odporności na filtrowanie, porównanie TLS 1.2 vs 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 SSL od publicznego urzędu CA
5. Konfiguracja TLS 1.3 z wyłączeniem podatnych wersji
6. Wdrożenie mechanizmów maskowania ruchu dla DPI bypass
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 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 ruterami.
• 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 ruterach brzegowych.
• Zdefiniowanie obszarów OSPF (Area 0) i przypisanie do nich interfejsów tunelowych.
• Konfiguracja instancji OSPFv3 dla obsługi równoległego routingu IPv4 i IPv6.
• Ustawienie parametrów kosztu łączy w celu wymuszenia optymalnych ścieżek.
• Wdrożenie uwierzytelniania pakietów OSPFv3 w celu zabezpieczenia bazy link-state.
• Konfiguracja routerów jako ASBR w przypadku łączenia z innymi systemami autoryzacyjnymi.
• Testowanie zbieżności sieci po wyłączeniu jednego z łączy zapasowych.
• Analiza bazy danych LSDB pod kątem router LSA i network 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 (IPv4) a OSPFv3 (IPv6). Dokumentacja powinna zawierać analizę bazy danych LSDB (Link-State Database), typów LSA (Router LSA, Network 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. Uruchomienie instancji OSPFv3 dla równoległego routingu IPv4 i IPv6
8. Analiza LSDB i typów LSA w protokole OSPFv3
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 zaawansowanej techniki 802.1ad (Provider Bridges, Q-in-Q) wewnątrz tunelu VPN, 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ą, rozbudowaną strukturę VLAN obejmującą kilkanaście różnych 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 routerów z obsługą standardu IEEE 802.1ad (Provider Bridges).
• Konfiguracja portów klienckich do przyjmowania ramek z tagami 802.1Q.
• Ustanowienie tunelu L2 (np. VXLAN lub L2TPv3) jako szkieletu dla usług ISP.
• Konfiguracja mapowania VLAN klienckich (C-VLAN) do wspólnego tagu dostawcy (S-VLAN).
• Zdefiniowanie EtherType dla tagu zewnętrznego na wartość 0x88a8.
• Ustawienie maksymalnego rozmiaru ramek MTU na interfejsach fizycznych (min. 1522 bajty).
• Weryfikacja zachowania znacznika Priority (PCP) po przejściu przez tunel.
• Konfiguracja routera 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 mechanizmu zapobiegających pętlom (STP/L2PT) dla ramek 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 (0x88a8)
7. Konfiguracja MTU 1522+ na interfejsach fizycznych
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 within tunnels, 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 z wykorzystaniem mechanizmów HTB (Hierarchical Token Bucket) i HFSC (Hierarchical Fair Service Curve), 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. Zakres prac obejmuje konfigurację reguł Mangle do oznaczania 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) zabija opóźnienia i przepustowość potrzebne dla VoIP i RDP, co skutkuje "zamrozeniem" 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 reguł firewalla typu Mangle do oznaczania pakietów VoIP znacznikiem DSCP.
• Utworzenie oddzielnych tablic routingu dla różnych klas ruchu sieciowego.
• Implementacja reguł Route Policy Database (RPDB) do kierowania ruchu na podstawie znaczników.
• Konfiguracja drzew hierarchicznych HTB dla każdego z interfejsów tunelowych.
• Zdefiniowanie klas priorytetowych z gwarantowanym pasmem (CIR) i nadmiarowym (EIR).
• Zastosowanie algorytmu SFQ lub FQ-CoDel w celu sprawiedliwego podziału pasma wewnątrz klasy.
• Ograniczenie pasma dla ruchu o niskim priorytecie (np. aktualizacje systemu, torrenty).
• Wdrożenie mechanizmu monitorowania jakości 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 mangle print stats.
• Pomiar parametrów Jitter i Packet Loss 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.
• Sprawdzenie wpływu szyfrowania na możliwości inspekcji pakietów i ich klasyfikacji.

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 i packet loss 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 reguł Mangle do oznaczania pakietów DSCP
5. Implementacja kolejek HTB dla gwarantowanego pasma
6. Konfiguracja algorytmów SFQ i FQ-CoDel
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 przed i po QoS
10. Analiza wykorzystania pasma na kolejkach w czasie rzeczywistym
11. Podsumowanie i wnioski z realizacji projektu

VPN_07 VPN Hardening, Zero Trust, Firewalling.

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 compliance 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 regulacjom bezpieczeństwa (PCI-DSS, RODO), żywi poważne obawy, że zainfekowane laptops 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 malware rozprzestrzenił się na serwery centralne, powodując milionowe straty. Należy wdrożyć system "pukania do portów" (Port Knocking) lub Single Packet Authorization (SPA), który sprawia, że brama VPN jest całkowicie niewidoczna dla skanerów i atakujących, a ports otwierają się tylko dla wcześniej autoryzowanych klientów, którzy "zapukali" w odpowiedni sposób. Równocześnie, przed nawiązaniem pełnego tunelu VPN, system musi sprawdzić, czy komputer klienta spełnia minimalne wymogi bezpieczeństwa: 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 UDP 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 rutera.
• Testowanie odporności bramy na ataki typu 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).
• Dokumentacja polityki bezpieczeństwa Clean Desk i Clean Endpoint dla pracowników zdalnych.
• Weryfikacja skuteczności ukrycia bramy za pomocą narzędzi do skanowania zewnętrznego (np. Shodan, Nmap).

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 obawa 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 w Shodan/Nmap
12. Podsumowanie i wnioski z realizacji projektu