Zadania projektowe - Wirtualne Sieci Prywatne

VPN_02 Definicja i struktura pakietu GRE. VPN_05 Routing dynamiczny w tunelach.

Celem projektu jest zaprojektowanie i wdrożenie wirtualnego połączenia między dwoma oddziałami firmy przy użyciu protokołu GRE (Generic Routing Encapsulation), który umożliwia enkapsulację różnych protokołów warstwy sieciowej wewnątrz tunelu IP. Projekt ma na celu zapewnienie automatycznej wymiany informacji o trasach między sieciami lokalnymi obu oddziałów za pomocą protokołu routingu dynamicznego OSPF, co eliminuje konieczność ręcznej konfiguracji tras statycznych i zapewnia wysoką skalowalność rozwiązania. Student zdobędzie praktyczne umiejętności konfiguracji tuneli GRE w środowisku Cisco Packet Tracer, nauczy się uruchamiać oraz weryfikować działanie protokołu OSPF w tunelach, a także analizować proces enkapsulacji i dekapsulacji pakietów w trybie symulacji.

Przedsiębiorstwo posiada dwa oddziały geograficznie oddalone od siebie: Centralę w dużym mieście oraz Oddział w mniejszej miejscowości. Każdy oddział dysponuje własną siecią lokalną LAN, a potrzeby biznesowe wymagają stałej, niezawodnej komunikacji między pracownikami obu lokalizacji oraz dostępu do wspólnych zasobów firmowych, takich jak serwery plików, bazy danych i systemy ERP. Ze względu na koszty oraz prostotę implementacji postanowiono wykorzystać tunel GRE, który stanowi lekki mechanizm tunelowania bez narzutu związanego z szyfrowaniem, jednak w środowisku produkcyjnym zaleca się łączenie go z IPsec. Protokół routingu OSPF ma zapewnić automatyczne wykrywanie tras i szybką zbieżność sieci w przypadku awarii. Oddział wymaga również dostępu do Internetu przez lokalnego dostawcę usług, co wymaga odpowiedniej konfiguracji routingu i translacji adresów NAT na routerze brzegowym.

• Wybór ruterów serii 2911 lub 4321 w programie Cisco Packet Tracer.
• Połączenie ruterów kablem miedzianym krosowanym lub przez chmurę Packet Tracer.
• Konfiguracja adresów IP na interfejsach fizycznych (np. GigabitEthernet 0/0).
• Podniesienie interfejsów fizycznych za pomocą komendy no shutdown.
• Utworzenie wirtualnego interfejsu Tunnel 0 na ruterze brzegowym R1.
• Konfiguracja adresu IP dla interfejsu Tunnel 0 z unikalnej podsieci.
• Określenie Tunnel Source jako fizyczny interfejs WAN rutera R1.
• Określenie Tunnel Destination jako publiczny adres IP rutera R2.
• Powtórzenie konfiguracji interfejsu Tunnel 0 na ruterze R2.
• Sprawdzenie drożności tunelu przy użyciu polecenia ping na adresy IP tunelu.
• Konfiguracja sieci lokalnych LAN za ruterami R1 i R2.
• Uruchomienie procesu OSPF na ruterze R1 (router ospf 1).
• Przypisanie sieci LAN do obszaru Area 0 w konfiguracji OSPF.
• Przypisanie sieci tunelu do obszaru Area 0 w celu rozgłaszania tras.
• Sprawdzenie nawiązania sąsiedztwa OSPF poleceniem show ip ospf neighbor.
• Weryfikacja tablicy routingu (show ip route) i szukanie tras OSPF.
• Test komunikacji między hostami w sieciach LAN (ping).
• Analiza ścieżki pakietu poleceniem traceroute.
• Obserwacja enkapsulacji GRE w trybie symulacji Packet Tracer.
• Zapisanie końcowej konfiguracji poleceniem copy running-config startup-config.

Dokumentacja powinna zawierać schemat logiczny i fizyczny sieci, tabelę adresacji IP dla wszystkich interfejsów oraz szczegółowy opis mechanizmu enkapsulacji GRE. Należy wyjaśnić, dlaczego GRE jest protokołem bezstanowym i jakie niesie to za sobą konsekwencje dla routingu. Opis powinien zawierać analizę procesu pakowania i odpakowywania pakietów w tunelu oraz różnice między trybem trasparentnym a routowanym w kontekście tego projektu.

1. Wprowadzenie do technologii tunelowania GRE i jej zastosowań w sieciach korporacyjnych
2. Analiza topologii sieci i projektowanie schematu adresacji IP dla obu oddziałów
3. Konfiguracja podstawowych parametrów interfejsów fizycznych routerów (adresacja, włączenie)
4. Tworzenie i konfiguracja interfejsu tunelowego Tunnel 0 na routerach R1 i R2
5. Konfiguracja parametrów źródła i celu tunelu GRE (Tunnel Source, Tunnel Destination)
6. Uruchomienie protokołu routingu OSPF na interfejsach tunelowych i fizycznych
7. Weryfikacja nawiązania sąsiedztwa OSPF i wymiany tras między routerami
8. Testowanie komunikacji między sieciami LAN obu oddziałów (ping, traceroute)
9. Analiza procesu enkapsulacji GRE w trybie symulacji Packet Tracer
10. Podsumowanie i wnioski z realizacji projektu

Podczas konfiguracji tunelu GRE pamiętaj o prawidłowym ustawieniu adresacji IP interfejsu tunelowego - musi być to inna podsieć niż sieci LAN i WAN. Sprawdź czy interfejsy fizyczne są w stanie "up/up" przed uruchomieniem tunelu. Na routerze Cisco użyj polecenia show interface tunnel 0 do weryfikacji stanu tunelu. W OSPF pamiętaj o dodaniu sieci tunelowej do obszaru Area 0, ponieważ domyślnie OSPF wymaga pełnej siatki (full-mesh) w jednym obszarze dla poprawnego działania. Użyj polecenia show ip ospf neighbor do sprawdzenia sąsiedztwa i show ip route do weryfikacji wpisów OSPF w tablicy routingu.

! KONFIGURACJA R1 - CENTRALA
R1#configure terminal
R1(config)#interface GigabitEthernet0/0
R1(config-if)#ip address 203.0.113.1 255.255.255.252
R1(config-if)#no shutdown
R1(config-if)#exit
R1(config)#interface GigabitEthernet0/1
R1(config-if)#ip address 192.168.1.1 255.255.255.0
R1(config-if)#no shutdown
R1(config-if)#exit

! KONFIGURACJA TUNELU GRE
R1(config)#interface Tunnel 0
R1(config-if)#ip address 10.0.0.1 255.255.255.252
R1(config-if)#tunnel source GigabitEthernet0/0
R1(config-if)#tunnel destination 203.0.113.2
R1(config-if)#no shutdown
R1(config-if)#exit

! KONFIGURACJA OSPF
R1(config)#router ospf 1
R1(config-router)#network 192.168.1.0 0.0.0.255 area 0
R1(config-router)#network 10.0.0.0 0.0.0.3 area 0
R1(config-router)#exit

! WERYFIKACJA - STAN TUNELU
R1#show interface Tunnel 0
! Tunnel0 is up, line protocol is up
! Encapsulation PPP, MTU 1484 bytes

! WERYFIKACJA - SĄSIEDZTWO OSPF
R1#show ip ospf neighbor
! Neighbor ID     Pri   State           Dead Time   Address         Interface
! 192.168.2.1       1   FULL/DR         00:00:31    10.0.0.2        Tunnel0

! WERYFIKACJA - TABLICA ROUTINGU
R1#show ip route
! O    192.168.2.0/24 [110/111] via 10.0.0.2, 00:02:15, Tunnel0

! TEST ŁĄCZNOŚCI
PC1#ping 192.168.2.10
! Reply from 192.168.2.10: bytes=32 time=1ms TTL=126
                    

VPN_03 Architektura IPsec: AH, ESP oraz fazy IKE.

Celem projektu jest wdrożenie bezpiecznego tunelu VPN typu Site-to-Site integrującego dwie odległe lokalizacje przedsiębiorstwa przy użyciu protokołu IPsec. Projekt skupia się na zapewnieniu poufności (poprzez szyfrowanie), integralności (poprzez uwierzytelnianie i hashowanie) oraz uwierzytelniania stron połączenia (poprzez pre-share lub certyfikaty). Student nauczy się konfigurować dwufazowy proces IKE (Internet Key Exchange), który negocjuje parametry bezpieczeństwa między urządzeniami VPN, oraz zrozumie różnice między fazą pierwszą (Phase 1, Quick Mode) a fazą drugą (Phase 2, Main Mode). Praktyczne umiejętności obejmą również weryfikację działania tunelu oraz analizę zaszyfrowanego ruchu w trybie symulacji Packet Tracer.

Firma prowadzi działalność w dwóch lokalizacjach - Centrali i Oddziału - i wymaga bezpiecznej wymiany danych między nimi przez sieć publiczną Internet. Przesyłane dokumenty zawierają wrażliwe dane finansowe i osobowe klientów, które muszą być chronione przed podsłuchem i modyfikacją. Zarząd firmy podjął decyzję o wdrożeniu szyfrowanego tunelu VPN Site-to-Site z wykorzystaniem urządzeń Cisco router. Główne wymagania to: szyfrowanie AES-256 dla zapewnienia poufności danych, uwierzytelnianie SHA-256 dla integralności, pre-share dla prostoty obsługi (bez infrastruktury PKI), oraz grupa Diffie-HellmanaDH2 dla bezpiecznej wymiany kluczy sesyjnych. Tunel ma być przezroczysty dla użytkowników końcowych i automatycznie negocjowany po awarii łącza.

• Dobór ruterów z obsługą IOS Security (np. 1941 lub 2911).
• Konfiguracja podstawowej łączności IP między ruterami przez sieć ISP.
• Utworzenie polityki ISAKMP Phase 1 (crypto isakmp policy 10).
• Wybór algorytmu szyfrowania AES dla pierwszej fazy IKE.
• Wybór algorytmu haszującego SHA lub SHA256.
• Ustawienie metody uwierzytelniania na pre-share.
• Określenie grupy Diffie-Hellmana (np. group 2 lub 5).
• Konfiguracja klucza współdzielonego (crypto isakmp key) i adresu peer.
• Definicja parametrów Transform Set dla fazy drugiej (esp-aes esp-sha-hmac).
• Utworzenie listy ACL (Interesting Traffic) definiującej ruch do szyfrowania.
• Konfiguracja Crypto Map łączącej ACL, peer IP i transform set.
• Przypisanie Crypto Map do interfejsu wyjściowego WAN.
• Sprawdzenie statusu ISAKMP SA (show crypto isakmp sa) po wysłaniu ruchu.
• Sprawdzenie statusu IPsec SA (show crypto ipsec sa) i liczby zaszyfrowanych pakietów.
• Weryfikacja braku łączności przed zestawieniem tunelu i poprawnej po zestawieniu.
• Test komunikacji między stacjami roboczymi w sieciach LAN.
• Dokumentacja użytych algorytmów i parametrów bezpieczeństwa.
• Wyjaśnienie różnicy między Main Mode a Aggressive Mode.
• Analiza nagłówka ESP w trybie symulacji Packet Tracer.
• Zapisanie konfiguracji na obu ruterach.

Dokumentacja musi zawierać szczegółowy opis roli Diffie-Hellman w bezpiecznej wymianie kluczy sesyjnych oraz prezentację różnic między trybem transportowym a tunelowym IPsec. Należy wyjaśnić dlaczego w scenariuszu Site-to-Site stosuje się tryb tunelowy i jakie korzyści niesie ze sobą zastosowanie IKEv1 w fazie negocjacji. Dokument powinien zawierać schemat przepływu pakietów przez kolejne warstwy bezpieczeństwa IPsec.

1. Wprowadzenie do technologii IPsec i jej składowych (AH, ESP, IKE)
2. Analiza wymagań bezpieczeństwa i projekt topologii sieci VPN Site-to-Site
3. Konfiguracja podstawowej łączności IP między routerami przez sieć ISP
4. Tworzenie polityki ISAKMP Phase 1 z odpowiednimi parametrami bezpieczeństwa
5. Konfiguracja klucza współdzielonego (pre-shared key) dla obu peerów VPN
6. Definiowanie Transform Set dla fazy drugiej IPsec (ESP-AES, ESP-SHA)
7. Tworzenie listy ACL definiującej ruch podlegający szyfrowaniu (interesting traffic)
8. Konfiguracja Crypto Map i przypisanie jej do interfejsu WAN
9. Weryfikacja zestawienia tunelu ISAKMP i IPsec SA
10. Podsumowanie i wnioski z realizacji projektu

Podczas konfiguracji IPsec pamiętaj o właściwej kolejności działań - najpierw skonfiguruj podstawową łączność IP, następnie parametry ISAKMP, Transform Set, ACL i na końcu Crypto Map. Upewnij się, że lista ACL (interesting traffic) dokładnie odpowiada ruchowi między sieciami LAN, który chcesz chronić. Użyj polecenia show crypto isakmp sa do sprawdzenia stanu fazy IKE po wysłaniu ruchu przez tunel. Jeśli tunel się nie zestawia, sprawdź czy pakiety ISAKMP (UDP port 500) nie są blokowane przez NAT lub ACL. Weryfikuj też czy transform-set jest identyczny na obu końcach tunelu.

! KONFIGURACJA INTERFEJSÓW - R1
R1#configure terminal
R1(config)#interface GigabitEthernet0/0
R1(config-if)#ip address 203.0.113.1 255.255.255.252
R1(config-if)#no shutdown
R1(config-if)#exit
R1(config)#interface GigabitEthernet0/1
R1(config-if)#ip address 192.168.1.1 255.255.255.0
R1(config-if)#no shutdown
R1(config-if)#exit

! KONFIGURACJA IPSEC - POLITYKA ISAKMP
R1(config)#crypto isakmp policy 10
R1(config-isakmp)#encryption aes
R1(config-isakmp)#hash sha256
R1(config-isakmp)#authentication pre-share
R1(config-isakmp)#group 5
R1(config-isakmp)#exit

! KONFIGURACJA KLUCZA WSPÓŁDZIELONEGO
R1(config)#crypto isakmp key cisco123 address 203.0.113.2

! KONFIGURACJA TRANSFORM SET
R1(config)#crypto ipsec transform-set TS1 esp-aes esp-sha256-hmac
R1(cfg-crypto-trans)#exit

! KONFIGURACJA ACL DLA RUCHU DO SZYFROWANIA
R1(config)#access-list 110 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

! KONFIGURACJA CRYPTO MAP
R1(config)#crypto map CMAP 10 ipsec-isakmp
R1(config-crypto-m)#set peer 203.0.113.2
R1(config-crypto-m)#set transform-set TS1
R1(config-crypto-m)#match address 110
R1(config-crypto-m)#exit

! PRZYPISANIE CRYPTO MAP DO INTERFEJSU
R1(config)#interface GigabitEthernet0/0
R1(config-if)#crypto map CMAP

! WERYFIKACJA - STATUS ISAKMP SA
R1#show crypto isakmp sa
! dst             src             state          conn-id slot status
! 203.0.113.2    203.0.113.1    QM_IDLE           1001    0 ACTIVE

! WERYFIKACJA - STATUS IPSEC SA
R1#show crypto ipsec sa
! current_peer: 203.0.113.2
! #pkts encaps: 15, #pkts encrypt: 15
! #pkts decaps: 15, #pkts decrypt: 15
                    

VPN_03 Klasyfikacja VPN. VPN_07 Uwierzytelnianie wieloskładnikowe i praca zdalna.

Celem projektu jest stworzenie infrastruktury pozwalającej pracownikom mobilnym i zdalnym na bezpieczny dostęp do zasobów firmowych przez sieć publiczną Internet. Projekt obejmuje konfigurację routera Cisco jako serwera VPN typu Remote Access (Client-to-Site) z wykorzystaniem protokołu IPsec oraz symulację klienta zdalnego w programie Cisco Packet Tracer. Student nauczy się konfigurować pulę adresów IP dla klientów, uwierzytelnianie oparte na hasłach grupowych (group-key) oraz opcjonalne uwierzytelnianie XAuth. Projekt ma również na celu wyjaśnienie mechanizmu Split Tunneling, który pozwala zoptymalizować wykorzystanie pasma tunelu VPN.

Współczesne przedsiębiorstwa coraz częściej zatrudniają pracowników zdalnych, którzy potrzebują bezpiecznego dostępu do wewnętrznych systemów firmy z dowolnej lokalizacji - z domu, hotelu czy podczas podróży służbowych. Zarząd firmy zdecydował o wdrożeniu rozwiązania VPN Remote Access opartego na urządzeniach Cisco, które pozwoli pracownikom na nawiązywanie bezpiecznych połączeń ze swoich laptopów i komputerów domowych. Pracownicy muszą mieć dostęp do serwera plików, wewnętrznej poczty e-mail oraz systemu ERP. Wymagane jest szyfrowanie całego ruchu do sieci korporacyjnej (bez split-tunneling) dla maksymalnego bezpieczeństwa. Każdy pracownik otrzyma dedykowane dane logowania składające się z nazwy grupy, klucza grupy oraz indywidualnego hasła.

• Konfiguracja interfejsów sieciowych na ruterze pełniącym rolę bramy VPN.
• Utworzenie puli adresów IP dla klientów zdalnych (ip local pool).
• Konfiguracja parametrów IKE Phase 1 (polityka ISAKMP).
• Konfiguracja klucza współdzielonego dla grupy (group-key).
• Definicja Transform Set dla IPsec ESP.
• Utworzenie Dynamic Crypto Map dla obsługi wielu klientów.
• Powiązanie Dynamic Map z główną statyczną Crypto Map.
• Konfiguracja uwierzytelniania użytkowników (aaa new-model, local database).
• Włączenie autoryzacji XAuth dla dodatkowego poziomu bezpieczeństwa.
• Konfiguracja parametrów grupowych VPN (DNS, domena, split-tunneling).
• Przypisanie Crypto Map do interfejsu zewnętrznego.
• Przygotowanie klienta PC w Packet Tracer do połączenia VPN.
• Wprowadzenie danych logowania na kliencie (IP, Group Name, Key, User, Pass).
• Nawiązanie połączenia i sprawdzenie przypisanego adresu IP z puli.
• Test dostępu do serwera wewnątrz sieci LAN firmy.
• Monitorowanie sesji na ruterze (show crypto session).
• Analiza działania Split Tunneling (ruch internetowy vs korporacyjny).
• Weryfikacja liczby enkapsulowanych pakietów na ruterze.
• Opis znaczenia Perfect Forward Secrecy w tym scenariuszu.
• Eksport logów z przebiegu autoryzacji klienta.

Dokumentacja powinna zawierać szczegółową analizę bezpieczeństwa modelu Remote Access w porównaniu do Site-to-Site, ze szczególnym uwzględnieniem zagrożeń związanych z klientami zdalnymi. Należy opisać znaczenie Perfect Forward Secrecy (PFS) w kontekście ochrony sesji zdalnych oraz wyjaśnić mechanizm działania Split Tunneling i jego wpływ na bezpieczeństwo. Dokument powinien zawierać tabelę porównawczą różnych metod uwierzytelniania w VPN.

1. Wprowadzenie do technologii VPN Remote Access i jej zastosowań w nowoczesnych organizacjach
2. Analiza wymagań i projekt topologii sieci z dostępem zdalnym
3. Konfiguracja interfejsów sieciowych routera pełniącego rolę bramy VPN
4. Tworzenie i konfiguracja puli adresów IP dla klientów zdalnych
5. Konfiguracja parametrów IKE Phase 1 dla połączeń Remote Access
6. Tworzenie grupy VPN i konfiguracja klucza współdzielonego
7. Definiowanie Dynamic Crypto Map dla obsługi wielu klientów
8. Konfiguracja uwierzytelniania użytkowników (AAA, XAuth)
9. Konfiguracja parametrów grupowych (DNS, domena, split-tunneling)
10. Podsumowanie i wnioski z realizacji projektu

Podczas konfiguracji VPN Remote Access pamiętaj o prawidłowej kolejności: najpierw skonfiguruj pule adresów, następnie politykę ISAKMP, grupę VPN, transform-set, dynamic crypto map i na końcu crypto map. W Packet Tracer użyj opcji VPN Client do nawiązania połączenia z routerem. Upewnij się, że dane logowania (group name, key, username, password) są poprawne po obu stronach. Użyj polecenia show crypto session do monitorowania aktywnych sesji VPN. Jeśli połączenie nie zestawia się, sprawdź czy interfejs WAN ma przypisaną publiczną adresację IP i czy nie ma blokady w ACL.

! KONFIGURACJA INTERFEJSÓW - R1 (BRAMA VPN)
R1#configure terminal
R1(config)#interface GigabitEthernet0/0
R1(config-if)#ip address 203.0.113.1 255.255.255.252
R1(config-if)#no shutdown
R1(config-if)#exit
R1(config)#interface GigabitEthernet0/1
R1(config-if)#ip address 192.168.1.1 255.255.255.0
R1(config-if)#no shutdown
R1(config-if)#exit

! KONFIGURACJA PULI ADRESÓW DLA KLIENTÓW
R1(config)#ip local pool VPN_POOL 10.10.10.1 10.10.10.50

! KONFIGURACJA GRUPY VPN
R1(config)#crypto isakmp client configuration group VPN_USERS
R1(config-isakmp-group)#key cisco123
R1(config-isakmp-group)#pool VPN_POOL
R1(config-isakmp-group)#domain ahe.lodz.pl
R1(config-isakmp-group)#exit

! KONFIGURACJA TRANSFORM SET
R1(config)#crypto ipsec transform-set TS1 esp-aes esp-sha-hmac

! KONFIGURACJA DYNAMIC CRYPTO MAP
R1(config)#crypto dynamic-map DYN_MAP 10
R1(config-crypto-m)#set transform-set TS1
R1(config-crypto-m)#reverse-route
R1(config-crypto-m)#exit

! KONFIGURACJA GŁÓWNEJ CRYPTO MAP
R1(config)#crypto map CMAP 10 ipsec-isakmp dynamic DYN_MAP

! PRZYPISANIE CRYPTO MAP DO INTERFEJSU
R1(config)#interface GigabitEthernet0/0
R1(config-if)#crypto map CMAP
R1(config-if)#exit

! WERYFIKACJA - SESJE VPN
R1#show crypto session
! Session status: UP-ACTIVE
! Virtual interface : Tunnel1
! Client IP: 10.10.10.5
                    

VPN_02 Protokół Point-to-Point (PPP) i metody autentykacji.

Celem projektu jest zabezpieczenie łącza szeregowego (Serial), które stanowi fundament dla dalszych technologii tunelowania w sieciach Cisco. Zadaniem studenta jest wdrożenie protokołu PPP (Point-to-Point Protocol) z bezpiecznym mechanizmem uwierzytelniania CHAP (Challenge Handshake Authentication Protocol). Projekt ma na celu zaprezentowanie różnic między protokołami PAP i CHAP, oraz wyjaśnienie mechanizmu trójkątnego uzgadniania (challenge-response), który zapewnia odporność na ataki powtórzeniowe (replay attacks). Student zdobędzie praktyczne umiejętności konfiguracji interfejsów szeregowych i diagnostyki protokołu PPP.

Przedsiębiorstwo posiada dwa biura w różnych częściach miasta połączone dedykowanym łączem dzierżawionym. Ze względu na wrażliwość przesyłanych danych finansowych zarządzono konieczność zabezpieczenia tego łącza przed nieautoryzowanym dostępem. Istniejące łącze wykorzystuje domyślny protokół HDLC, który nie zapewnia żadnego uwierzytelniania. Zdecydowano o przejściu na protokół PPP z uwierzytelnianiem CHAP, co wymaga wzajemnej konfiguracji nazw i haseł na obu routerach. Rozwiązanie musi zapewnić automatyczne ustanowienie łącza po włączeniu urządzeń.

• Wybor routerów z interfejsami szeregowymi (Serial) w Packet Tracer.
• Polaczenie routerów kablem Serial DCE/DTE.
• Konfiguracja zegara (clock rate) na routerze z końcówką DCE.
• Ustawienie adresów IP na interfejsach Serial obu routerów.
• Zmiana domyślnej enkapsulacji HDLC na PPP (encapsulation ppp).
• Konfiguracja nazwy hosta (hostname) na każdym routerze.
• Dodanie lokalnego użytkownika z hasłem odpowiadającym nazwie drugiego routera.
• Włączenie uwierzytelniania CHAP na interfejsie Serial (ppp authentication chap).
• Sprawdzenie stanu interfejsu (up/up) poleceniem show interface serial.
• Debugowanie procesu uwierzytelniania (debug ppp authentication).
• Weryfikacja poprawności hasła i nazwy użytkownika po obu stronach.
• Analiza faz LCP (Link Control Protocol) podczas zestawiania lacza.
• Konfiguracja NCP (Network Control Protocol) dla protokołu IP.
• Test łączności między routerami (ping).
• Sprawdzenie działania łącza po celowej zmianie hasła na błędne.
• Obserwacja komunikatów Failure w logach systemowych.
• Wyjaśnienie mechanizmu wyzwania (Challenge) i odpowiedzi (Response).
• Wyjaśnienie, dlaczego hasło nie jest przesyłane otwartym tekstem.
• Porownanie z metoda PAP (Password Authentication Protocol).
• Zapisanie dzialajacej konfiguracji.

Dokumentacja powinna zawierać szczegółowe zestawienie porównawcze protokołów PAP i CHAP, z uzasadnieniem dlaczego CHAP jest odporny na ataki typu replay (poprzez unikalny challenge każdej sesji). Należy wyjaśnić mechanizm trójkątnego uzgadniania oraz przedstawić tabelę konfiguracji interfejsów z obu routerów. Dokument powinien zawierać analizę faz LCP podczas zestawiania łącza PPP.

1. Wprowadzenie do protokołu PPP i jego zastosowań w sieciach rozległych
2. Analiza topologii i projekt sieci z łączem dzierżawionym
3. Konfiguracja podstawowych parametrów interfejsów szeregowych
4. Zmiana enkapsulacji z HDLC na PPP i weryfikacja działania
5. Konfiguracja mechanizmu uwierzytelniania CHAP na obu routerach
6. Tworzenie lokalnej bazy użytkowników z odpowiednimi hasłami
7. Testowanie działania uwierzytelniania - poprawne i niepoprawne hasła
8. Analiza faz LCP i NCP w procesie negocjacji PPP
9. Diagnostyka i rozwiązywanie problemów z uwierzytelnianiem
10. Podsumowanie i wnioski z realizacji projektu

Podczas konfiguracji PPP z CHAP pamiętaj, że nazwa użytkownika na routerze R1 musi odpowiadać hostname routera R2 i odwrotnie - jest to wymaganie protokołu CHAP. Hasło musi być identyczne po obu stronach. Na routerze zakończenia DCE musisz skonfigurować clock rate (np. 64000 lub 128000). Użyj polecenia show interface serial do sprawdzenia czy enkapsulacja zmieniła się na PPP i czy interfejs jest w stanie up/up. Do debugowania użyj polecenia debug ppp authentication - obserwuj wyzwania (challenge) i odpowiedzi (response).

! KONFIGURACJA R1 - STRONA DCE
R1#configure terminal
R1(config)#hostname CENTRALA
CENTRALA(config)#username ODDZIAL password cisco123
CENTRALA(config)#interface Serial0/3/0
CENTRALA(config-if)#encapsulation ppp
CENTRALA(config-if)#ppp authentication chap
CENTRALA(config-if)#clock rate 64000
CENTRALA(config-if)#ip address 10.1.1.1 255.255.255.252
CENTRALA(config-if)#no shutdown
CENTRALA(config-if)#exit

! KONFIGURACJA R2 - STRONA DTE
R2#configure terminal
R2(config)#hostname ODDZIAL
ODDZIAL(config)#username CENTRALA password cisco123
ODDZIAL(config)#interface Serial0/3/0
ODDZIAL(config-if)#encapsulation ppp
ODDZIAL(config-if)#ppp authentication chap
ODDZIAL(config-if)#ip address 10.1.1.2 255.255.255.252
ODDZIAL(config-if)#no shutdown
ODDZIAL(config-if)#exit

! WERYFIKACJA - STAN INTERFEJSU
CENTRALA#show interface Serial0/3/0
! Serial0/3/0 is up, line protocol is up
! Encapsulation PPP, LCP Open

! WERYFIKACJA - ŁĄCZNOŚĆ
CENTRALA#ping 10.1.1.2
! Reply from 10.1.1.2: bytes=1000 time=20ms
                    

VPN_05 Problem NAT w tunelach VPN i techniki NAT-T.

Celem projektu jest rozwiązanie powszechnego konfliktu między translacją adresów (NAT) a ruchem VPN w scenariuszu Site-to-Site. Projekt ma na celu demonstrację poprawnej konfiguracji reguł "No-NAT" (NAT Exemption) dla ruchu kierowanego do tunelu IPsec, tak aby pakiety nie były translatowane przed zaszyfrowaniem. Student nauczy się konfigurować NAT w połączeniu z IPsec, rozumieć kolejność przetwarzania pakietów przez router (proces switching) oraz diagnozować problemy wynikające z nieprawidłowej konfiguracji NAT względem VPN.

Firma posiada dwie lokalizacje połączone tunelem IPsec Site-to-Site. Każda lokalizacja posiada router brzegowy z skonfigurowanym NAT (PAT) umożliwiającym dostęp pracowników do Internetu. Po wdrożeniu tunelu VPN zauważono, że komunikacja między oddziałami nie działa - pakiety nie docierają do celu. Analiza wykazała, że ruch z sieci LAN oddziału A do sieci LAN oddziału B jest nieprawidłowo translatowany przez NAT przed wysłaniem do tunelu IPsec, co powoduje odrzucenie pakietów przez urządzenie docelowe. Rozwiązaniem jest skonfigurowanie wyjątków NAT (No-NAT/NAT Exemption) dla ruchu między sieciami VPN.

• Konfiguracja topologii z routerem brzegowym, siecią LAN i symulowanym Internetem.
• Ustawienie adresacji IP na wszystkich interfejsach.
• Konfiguracja standardowego NAT Inside i Outside.
• Utworzenie listy ACL dla standardowego dostępu do Internetu (PAT).
• Konfiguracja polecenia ip nat inside source list... interface... overload.
• Wdrożenie tunelu IPsec Site-to-Site między oddziałami.
• Zidentyfikowanie problemu: pakiety do VPN są translatowane przez NAT.
• Utworzenie listy ACL dla NAT Exemption (tzw. No-NAT).
• Zmiana konfiguracji NAT tak, aby wykluczyć ruch między sieciami LAN oddziałów.
• Wykorzystanie deny w liście ACL dla NAT lub route-map do filtrowania.
• Weryfikacja kolejności przetwarzania pakietów przez router.
• Test ping z LAN1 do LAN2 i sprawdzenie tablicy translacji NAT.
• Potwierdzenie, że ruch do VPN NIE pojawia się w show ip nat translations.
• Test ping z LAN1 do Internetu i potwierdzenie poprawnej translacji.
• Monitorowanie liczby trafień (hits) w listach ACL.
• Analiza ścieżki pakietu (Packet Flow) w trybie symulacji.
• Dokumentacja regul sterujących ruchem na routerze brzegowym.
• Wyjaśnienie roli Checkpoint w procesie NAT-VPN.
• Opis różnicy między Static NAT a Dynamic NAT w kontekście tuneli.
• Zapisanie konfiguracji.

Dokumentacja powinna zawierać szczegółową analizę ścieżki pakietu (Packet Flow) wewnątrz routera z uwzględnieniem kolejności przetwarzania przez NAT i IPsec. Należy opisać dlaczego bez wyłączenia NAT ruch VPN często nie dochodzi do skutku i jakie konsekwencje niesie ze sobą translacja adresów dla zaszyfrowanych pakietów IPsec. Dokument powinien zawierać schemat przepływu pakietów z NAT i bez NAT.

1. Wprowadzenie do problematyki NAT w infrastrukturze VPN
2. Analiza topologii sieci z routerem brzegowym i tunelem VPN
3. Konfiguracja podstawowego NAT (PAT) na routerze brzegowym
4. Wdrożenie tunelu IPsec Site-to-Site między oddziałami
5. Identyfikacja problemu - ruch VPN poddawany translacji NAT
6. Tworzenie listy ACL dla NAT Exemption (No-NAT)
7. Modyfikacja konfiguracji NAT z uwzględnieniem wyjątków dla VPN
8. Weryfikacja - ruch do VPN nie pojawia się w tablicy translacji NAT
9. Testowanie łączności między oddziałami i do Internetu
10. Podsumowanie i wnioski z realizacji projektu

Kluczem do sukcesu jest prawidłowa kolejność wpisów w liście ACL - deny (wykluczenie) musi być przed permit (translacja). Listę ACL stosuje się do polecenia ip nat inside source list. Pamiętaj, że NAT przetwarza pakiety przed IPsec, więc musisz wykluczyć ruch do VPN z translacji. Użyj polecenia show ip nat translations do weryfikacji czy ruch VPN nie jest translatowany. Polecenie debug ip nat pomoże zobaczyć szczegóły translacji pakietów.

! KONFIGURACJA INTERFEJSÓW
R1#configure terminal
R1(config)#interface GigabitEthernet0/0
R1(config-if)#ip address 203.0.113.1 255.255.255.252
R1(config-if)#no shutdown
R1(config-if)#exit
R1(config)#interface GigabitEthernet0/1
R1(config-if)#ip address 192.168.1.1 255.255.255.0
R1(config-if)#no shutdown
R1(config-if)#exit

! KONFIGURACJA NAT - INSIDE/OUTSIDE
R1(config)#interface GigabitEthernet0/0
R1(config-if)#ip nat outside
R1(config-if)#exit
R1(config)#interface GigabitEthernet0/1
R1(config-if)#ip nat inside
R1(config-if)#exit

! KONFIGURACJA ACL DLA NAT EXEMPTION (NO-NAT)
R1(config)#access-list 105 deny ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
R1(config)#access-list 105 permit ip 192.168.1.0 0.0.0.255 any

! KONFIGURACJA NAT Z WYJĄTKIEM DLA VPN
R1(config)#ip nat inside source list 105 interface GigabitEthernet0/0 overload

! WERYFIKACJA - TABLICA TRANSLACJI NAT
R1#show ip nat translations
! Pro -- Inside Global -- Inside Local -- Outside Local -- Outside Global
! tcp 203.0.113.1:49152 -- 192.168.1.10:80 -- 8.8.8.8:80 -- 8.8.8.8:80
! (ruch VPN NIE jest translatowany)

! WERYFIKACJA - STATYSTYKI NAT
R1#show ip nat statistics
! Total active translations: 1
! Peak translations: 10, Peak uses: 5 mins ago
                    

VPN_05 Routing sterowany polityką (PBR) i Mangle.

Celem projektu jest wdrożenie inteligentnego wyboru drogi dla ruchu sieciowego za pomocą Policy-Based Routing (PBR). Projekt zakłada, że tylko wybrany ruch (np. do serwerów baz danych lub wrażliwych systemów) ma przechodzić przez tunel VPN, podczas gdy reszta ruchu korzysta z bezpośredniego łącza internetowego. Student nauczy się tworzyć polityki routingu oparte na kryteriach innych niż adres docelowy, rozumieć mechanizm działania route-map oraz konfigurować warunkowe przekierowywanie ruchu do określonych next-hop.

Przedsiębiorstwo posiada dwa oddziały połączone tunelem VPN oraz wspólne łącze do Internetu. Istnieje serwer baz danych w oddziale B, do którego muszą mieć dostęp wybrani pracownicy z oddziału A. Ze względu na wrażliwość danych, ruch do tego serwera musi być przekierowany przez tunel VPN (z szyfrowaniem). Jednocześnie zwykły ruch internetowy (przeglądanie stron www, poczta) powinien iść bezpośrednio do ISP, bez obciążania tunelu VPN. Rozwiązaniem jest zastosowanie PBR, który na podstawie listy ACL kieruje ruch do odpowiedniej ścieżki.

• Przygotowanie topologii z dwoma alternatywnymi wyjściami (VPN i ISP).
• Konfiguracja adresacji IP na routerze brzegowym i hostach.
• Zestawienie tunelu VPN do oddziału zdalnego.
• Utworzenie listy ACL identyfikującej ruch uprzywilejowany (np. serwer WWW).
• Utworzenie polityki routingu (route-map o nazwie PBR_MAP).
• Użycie instrukcji match address dla wskazania wcześniej utworzonej ACL.
• Użycie instrukcji set ip next-hop dla skierowania ruchu do tunelu.
• Konfiguracja routingu domyślnego (default route) przez standardowe łącze ISP.
• Zastosowanie route-map na interfejsie wejściowym LAN (ip policy route-map).
• Weryfikacja działania PBR przy użyciu traceroute z różnych hostów.
• Sprawdzenie, czy ruch normalny omija tunel i idzie bezpośrednio do ISP.
• Monitorowanie statystyk route-map (show route-map).
• Test odporności: co stanie się, gdy następny skok (next-hop) jest nieosiągalny.
• Konfiguracja opcji set ip next-hop verify-availability (jeśli dostępna).
• Analiza obciążenia procesora rutera przy dużej liczbie reguł PBR.
• Porównanie tradycyjnego routingu opartego na adresie docelowym z PBR.
• Dokumentacja logicznych kroków podejmowania decyzji przez router.
• Wyjaśnienie pojęcia Mangle w kontekście znakowania pakietów.
• Testy wydajnościowe (opóźnienia) dla obu ścieżek.
• Zapisanie projektu.

Dokumentacja powinna zawierać opis korzyści biznesowych PBR, ze szczególnym uwzględnieniem oszczędności pasma tunelu VPN. Należy przedstawić zrzuty z CLI potwierdzające działanie polityki routingu oraz tabelę porównawczą tras dla różnych typów ruchu. Dokument powinien zawierać analizę różnic między tradycyjnym routingiem opartym na adresie docelowym a PBR.

1. Wprowadzenie do routingu sterowanego polityką (PBR) i jego zastosowań
2. Analiza topologii z wieloma ścieżkami wyjściowymi (VPN, ISP)
3. Konfiguracja podstawowego routingu i tunelu VPN
4. Tworzenie listy ACL identyfikującej ruch uprzywilejowany
5. Konfiguracja route-map z instrukcjami match i set
6. Przypisanie polityki PBR do interfejsu LAN
7. Testowanie działania PBR - różne typy ruchu idą różnymi ścieżkami
8. Analiza zachowania gdy next-hop jest nieosiągalny
9. Diagnostyka i optymalizacja reguł PBR
10. Podsumowanie i wnioski z realizacji projektu

Podczas konfiguracji PBR pamiętaj, że polityka jest stosowana na interfejsie wejściowym (LAN), a nie wyjściowym. Użyj instrukcji match address w route-map do wskazania ACL definiującej ruch, który ma być przekierowany. Instrukcja set ip next-hop określa adres IP, na który ma być wysłany pakiet. Użyj polecenia show route-map do weryfikacji statystyk trafień. PBR ma wyższy priorytet niż zwykły routing - PBR jest przetwarzany przed tradycyjną tablicą routingu.

! KONFIGURACJA PODSTAWOWEGO ROUTINGU
R1#configure terminal
R1(config)#interface GigabitEthernet0/0
R1(config-if)#ip address 203.0.113.1 255.255.255.252
R1(config-if)#no shutdown
R1(config-if)#exit
R1(config)#interface GigabitEthernet0/1
R1(config-if)#ip address 192.168.1.1 255.255.255.0
R1(config-if)#no shutdown
R1(config-if)#exit

! KONFIGURACJA TRASY DOMYŚLNEJ (DO ISP)
R1(config)#ip route 0.0.0.0 0.0.0.0 203.0.113.2

! KONFIGURACJA ACL DLA RUCHU UPRZYWILEJOWANEGO
R1(config)#access-list 150 permit ip host 192.168.1.50 any
R1(config)#access-list 150 permit ip host 192.168.1.51 any

! KONFIGURACJA ROUTE-MAP DLA PBR
R1(config)#route-map PBR_MAP permit 10
R1(config-route-map)#match address 150
R1(config-route-map)#set ip next-hop 10.0.0.2
R1(config-route-map)#exit

! PRZYPISANIE PBR DO INTERFEJSU LAN
R1(config)#interface GigabitEthernet0/1
R1(config-if)#ip policy route-map PBR_MAP
R1(config-if)#exit

! WERYFIKACJA - STATYSTYKI ROUTE-MAP
R1#show route-map
! route-map PBR_MAP, permit, sequence 10
!   Match clauses:
!     ip address (access-lists): 150
!   Set clauses:
!     ip next-hop 10.0.0.2
!   Policy routing: matches: 15
                    

VPN_07 Hardening serwera VPN i zasada najniższych uprawnień.

Celem projektu jest wzmocnienie bezpieczeństwa sieci korporacyjnej poprzez wdrożenie selektywnego filtrowania ruchu wewnątrz zestawionego tunelu VPN. Projekt ma zapobiegać lateralnemu przemieszczaniu się (lateral movement) potencjalnych zagrożeń z oddziałów do centrali poprzez zastosowanie zasady najniższych uprawnień (principle of least privilege). Student nauczy się tworzyć rozszerzone listy ACL, rozumieć różnicę między ACL standardowymi a rozszerzonymi oraz konfigurować filtrowanie na poziomie interfejsów routera.

Po wdrożeniu tunelu VPN Site-to-Site zauważono, że ruch między oddziałami jest w pełni nieskrępowany - każdy host z oddziału może komunikować się z dowolnym hostem w centrali. Dział bezpieczeństwa IT zidentyfikował ryzyko związane z potencjalnymi atakami lateralnymi - w przypadku przejęcia jednego hosta w oddziale, attacker mógłby się przenieść do sieci centrali. Zdecydowano o wdrożeniu list ACL na routerze w centrali, które będą zezwalać tylko na niezbędne usługi: HTTP/HTTPS (serwisy web), RDP (zdalny dostęp administratorów) oraz ICMP (diagnostyka). Wszelki inny ruch ma być blokowany i logowany.

• Zestawienie działającego połączenia VPN Site-to-Site.
• Weryfikacja swobodnego przepływu ruchu między sieciami LAN.
• Analiza potrzeb bezpieczeństwa: identyfikacja usług krytycznych i zabronionych.
• Utworzenie rozszerzonej listy ACL na ruterze w centrali.
• Dodanie reguły zezwalającej na ruch HTTP/HTTPS (porty 80, 443).
• Dodanie reguły zezwalającej na ruch zdalnego pulpitu RDP (port 3389).
• Dodanie reguły zezwalającej na zapytania DNS i ICMP dla testów.
• Dodanie jawnej reguły blokującej (deny ip any any) na końcu listy.
• Zdefiniowanie listy w sposób minimalizujący ryzyko lateral movement.
• Przypisanie listy ACL do interfejsu Tunnel lub Crypto Map.
• Alternatywne przypisanie ACL na interfejsie fizycznym w kierunku LAN.
• Test zablokowania protokołu Telnet (port 23) przez tunel.
• Test poprawnego działania WWW i RDP.
• Sprawdzenie logów (log keyword w ACL) dla prób nieautoryzowanego dostępu.
• Weryfikacja tablicy trafień w liście ACL (show access-lists).
• Dokumentacja schematu Zero Trust zastosowanego w projekcie.
• Analiza wpływu list ACL na wydajność procesową bramy VPN.
• Wyjaśnienie różnicy między ACL standardową a rozszerzoną.
• Opis znaczenia kierunku ruchu (in vs out) przy stosowaniu filtrów.
• Zapisanie konfiguracji.

Dokumentacja powinna zawierać uzasadnienie doboru reguł w kontekście modelu Zero Trust. Należy przedstawić tabelę z opisem każdej linii w liście ACL i jej przeznaczeniem. Dokument powinien zawierać analizę różnic między ACL standardowymi a rozszerzonymi oraz wyjaśnienie znaczenia kierunku ruchu (in vs out) przy stosowaniu filtrów.

1. Wprowadzenie do filtrowania ruchu i zasady najniższych uprawnień
2. Analiza topologii VPN i identyfikacja punktów filtracji
3. Konfiguracja działającego tunelu VPN Site-to-Site
4. Analiza potrzeb bezpieczeństwa - identyfikacja usług krytycznych
5. Tworzenie rozszerzonej listy ACL z selektywnymi regułami
6. Przypisanie listy ACL do interfejsu tunelowego
7. Testowanie - weryfikacja dozwolonego i blokowanego ruchu
8. Konfiguracja logowania prób nieautoryzowanego dostępu
9. Analiza wyników i optymalizacja reguł filtrowania
10. Podsumowanie i wnioski z realizacji projektu

Przy tworzeniu list ACL pamiętaj o zasadzie "wszystko co nie jest dozwolone jest zabronione" - zawsze dodawaj jawną regułę deny ip any any na końcu listy. Używaj rozszerzonych list ACL (ip access-list extended), które pozwalają na filtrowanie po adresach źródłowych, docelowych i portach. Pamiętaj o kierunku stosowania ACL - in (przychodzący) lub out (wychodzący). Do weryfikacji użyj polecenia show access-lists z licznikiem trafień. Dodaj słowo kluczowe log do reguł deny, aby monitorować próby nieautoryzowanego dostępu.

! KONFIGURACJA ROZSZERZONEJ ACL
R1#configure terminal
R1(config)#ip access-list extended VPN_INBOUND
R1(config-ext-nacl)#permit tcp 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255 eq 80
R1(config-ext-nacl)#permit tcp 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255 eq 443
R1(config-ext-nacl)#permit tcp 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255 eq 3389
R1(config-ext-nacl)#permit icmp any any echo
R1(config-ext-nacl)#permit icmp any any echo-reply
R1(config-ext-nacl)#deny ip any any log
R1(config-ext-nacl)#exit

! PRZYPISANIE ACL DO INTERFEJSU TUNELU
R1(config)#interface Tunnel 0
R1(config-if)#ip access-group VPN_INBOUND in
R1(config-if)#exit

! WERYFIKACJA - LISTA ACL Z LICZNIKAMI
R1#show access-lists VPN_INBOUND
! 10 permit tcp 192.168.2.0 255.255.255.0 ... eq 80 (25 matches)
! 20 permit tcp 192.168.2.0 255.255.255.0 ... eq 443 (10 matches)
! 30 permit tcp 192.168.2.0 255.255.255.0 ... eq 3389 (5 matches)
! 40 permit icmp any any echo (30 matches)
! 50 deny ip any any log (3 matches)
                    

VPN_05 High Availability w architekturach VPN.

Celem projektu jest zapewnienie ciągłości komunikacji między oddziałami firmy w przypadku awarii głównego tunelu VPN lub łącza WAN. Projekt polega na wdrożeniu zapasowej ścieżki (Backup Link), która aktywuje się automatycznie po wykryciu awarii łącza głównego. Student nauczy się konfigurować trasy statyczne z różnymi wartościami dystansu administracyjnego (AD), rozumieć mechanizm działania Floating Static Route oraz wykorzystywać IP SLA do monitorowania dostępności ścieżek sieciowych.

Firma posiada dwa oddziały połączone głównym tunelem VPN przez dostawcę ISP 1. Jest to jedyne połączenie między oddziałami, a jego awaria powoduje paraliż komunikacyjny i straty finansowe. Zarząd zdecydował o wdrożeniu zapasowego łącza przez alternatywnego dostawcę ISP 2. Główne łącze ma być wykorzystywane domyślnie (preferowane), a łącze zapasowe ma przejmować ruch automatycznie po awarii głównego. Koszt łącza zapasowego jest niższy, więc nie ma potrzeby utrzymywania go w stanie aktywnym - ma być wykorzystywane tylko w awarii.

• Budowa topologii z routerem oddziału połączonym dwoma różnymi ruterami ISP.
• Konfiguracja IP na wszystkich łączach WAN i LAN.
• Utworzenie głównego tunelu VPN (np. GRE) przez ISP 1.
• Konfiguracja routingu statycznego przez tunel z domyślnym AD (wartość 1).
• Konfiguracja zapasowej trasy statycznej przez ISP 2 z wyższym AD (np. 200).
• Konfiguracja technologii IP SLA do monitorowania łączności (icmp-echo).
• Utworzenie harmonogramu (schedule) dla operacji IP SLA.
• Powiązanie trasy statycznej z obiektem śledzącym (track 10 ip sla 1 state).
• Weryfikacja stanu obiektu track (show track).
• Test symulowanego zerwania łącza głównego (wyłączenie interfejsu).
• Obserwacja automatycznego przełączenia tablicy routingu na trasę zapasową.
• Pomiar czasu potrzebnego na wykrycie awarii i przełączenie (zbieżność).
• Test powrotu do łącza głównego po przywróceniu sprawności ISP 1.
• Weryfikacja płynności sesji użytkowników podczas przełączania.
• Konfiguracja komunikatów syslog informujących o zmianie stanu łączy.
• Analiza kosztów i korzyści stosowania redundancji.
• Opis pojęcia Floating Static Route i dlaczego nazywa się pływająca.
• Dokumentacja priorytetów tras w tablicy routingu.
• Wykorzystanie SNMP lub logów do raportowania dostępności usług.
• Zapisanie projektu PKT.

Dokumentacja powinna zawierać szczegółowy opis pojęcia "Administrative Distance" i jego roli w wyborze trasy. Należy wyznaczyć i przedstawić czasy zbieżności sieci podczas symulowanej awarii, a także analizę kosztów i korzyści stosowania redundancji. Dokument powinien zawierać schemat topologii z dwoma dostawcami ISP i opis działania mechanizmu Floating Static Route.

1. Wprowadzenie do wysokiej dostępności (HA) w infrastrukturze VPN
2. Analiza topologii z dwoma dostawcami ISP i redundantnym łączem
3. Konfiguracja podstawowych parametrów sieci i tunelu głównego
4. Konfiguracja trasy statycznej z domyślnym AD przez tunel główny
5. Konfiguracja trasy zapasowej (floating) z wyższym AD przez ISP 2
6. Konfiguracja IP SLA do monitorowania dostępności łącza głównego
7. Tworzenie obiektu track i powiązanie z trasą statyczną
8. Testowanie - symulacja awarii łącza głównego
9. Pomiar czasu zbieżności i automatyczne przełączenie na zapasowe
10. Podsumowanie i wnioski z realizacji projektu

Podczas konfiguracji Floating Static Route pamiętaj, że trasa zapasowa musi mieć wyższy dystans administracyjny (np. AD=200) niż trasa główna (domyślnie AD=1 dla tras statycznych), aby była używana tylko w przypadku niedostępności trasy głównej. IP SLA pozwala na aktywne monitorowanie dostępności łącza - użyj polecenia icmp-echo do wysyłania testowych pakietów ICMP. Obiekt track jest powiązany z IP SLA i decyduje o stanie trasy. Użyj polecenia show track do weryfikacji stanu i show ip route do sprawdzenia aktywnych tras.

! KONFIGURACJA PODSTAWOWYCH INTERFEJSÓW
R1#configure terminal
R1(config)#interface GigabitEthernet0/0
R1(config-if)#ip address 203.0.113.1 255.255.255.252
R1(config-if)#no shutdown
R1(config-if)#exit
R1(config)#interface GigabitEthernet0/1
R1(config-if)#ip address 198.51.100.1 255.255.255.252
R1(config-if)#no shutdown
R1(config-if)#exit

! KONFIGURACJA IP SLA
R1(config)#ip sla 1
R1(ip-sla)#icmp-echo 8.8.8.8 source-interface GigabitEthernet0/0
R1(ip-sla)#frequency 5
R1(ip-sla)#exit
R1(config)#ip sla schedule 1 life forever start-time now

! KONFIGURACJA TRACK
R1(config)#track 10 ip sla 1 state

! KONFIGURACJA TRAS STATYCZNYCH
R1(config)#ip route 0.0.0.0 0.0.0.0 203.0.113.2 track 10
R1(config)#ip route 0.0.0.0 0.0.0.0 198.51.100.2 200

! WERYFIKACJA - STAN TRACK
R1#show track
! Track 10
!   IP SLA 1 state: Up

! WERYFIKACJA - TABLICA ROUTINGU
R1#show ip route
! S*    0.0.0.0/0 [1/0] via 203.0.113.2
                    

VPN_03 Ograniczenia IPsec. VPN_06 Łączenie warstw i tunelowanie hybrydowe.

Celem projektu jest integracja elastyczności protokołu GRE (obsługa ruchu Multicast i Broadcast) z bezpieczeństwem zapewnianym przez IPsec. Jest to rozwiązanie niezbędne w nowoczesnych sieciach korporacyjnych korzystających z multicastu do przesyłania strumieni wideo, aktualizacji oprogramowania czy protokołów routingu. Student nauczy się konfigurować tunel GRE chroniony przez IPsec (GRE over IPsec), rozumieć strukturę podwójnej enkapsulacji oraz diagnozować problemy związane z MTU i fragmentacją pakietów.

Firma wdrożyła system dystrybucji materiałów szkoleniowych wideo wykorzystujący ruch multicast. Potrzebuje również bezpiecznej komunikacji między oddziałami przez tunel VPN. Problem polega na tym, że sam IPsec nie obsługuje ruchu multicast - protokoły routingu (OSPF) oraz aplikacje multicastowe nie mogą pracować przez zaszyfrowany tunel. Rozwiązaniem jest zastosowanie tunelu GRE, który hermetyzuje dowolny ruch (w tym multicast), a następnie zaszyfrowanie całego ruchu GRE przez IPsec. Daje to elastyczność GRE i bezpieczeństwo IPsec w jednym rozwiązaniu.

• Wybór ruterów pozwalających na złożoną enkapsulację.
• Konfiguracja interfejsów fizycznych i pętli zwrotnych Loopback.
• Utworzenie tunelu GRE (Tunnel 0) i nadanie adresów IP końcówkom.
• Uruchomienie protokołu routingu OSPF na interfejsach Tunnel.
• Potwierdzenie rozsyłania tras przez samo GRE (bez szyfrowania).
• Konfiguracja polityki ISAKMP i Transform Set dla IPsec.
• Utworzenie listy ACL chroniącej ruch GRE (match gre any any).
• Utworzenie Crypto Map i powiązanie jej z ACL oraz peerem.
• Przypisanie Crypto Map do interfejsu fizycznego WAN.
• Weryfikacja zestawienia tunelu IPsec (show crypto isakmp/ipsec sa).
• Sprawdzenie, czy pakiety OSPF (multicast 224.0.0.5) są szyfrowane.
• Analiza struktury nagłówków w trybie symulacji (IP-ESP-GRE-IP-OSPF).
• Obliczenie wpływu nagłówków na MTU (zmiana z 1500 na mniejszą).
• Konfiguracja ip tcp adj-mss na interfejsach tunelowych.
• Test ping z dużym rozmiarem pakietu i wymuszonym bitem DF.
• Dokumentacja zalet łączenia obu technologii (routing + bezpieczeństwo).
• Wyjaśnienie problemu Recursive Routing w tunelach GRE.
• Analiza wpływu podwójnej enkapsulacji na opóźnienia.
• Weryfikacja działania sieci LAN za tunelami.
• Zapisanie konfiguracji.

Dokumentacja powinna zawierać szczegółowe przedstawienie struktury "podwójnego nagłówka" (IP-IPsec-GRE-IP-Dane). Należy wyjaśnić dlaczego sam IPsec nie obsługuje ruchu Multicast i jak rozwiązuje to GRE. Dokument powinien zawierać analizę wpływu podwójnej enkapsulacji na MTU i opóźnienia, oraz omówienie problemu Recursive Routing w tunelach GRE.

1. Wprowadzenie do problematyki GRE over IPsec i zastosowań multicastu w VPN
2. Analiza topologii i projektowanie sieci z routingiem dynamicznym
3. Konfiguracja tunelu GRE i uruchomienie OSPF w trybie multicast
4. Konfiguracja IPsec do ochrony ruchu GRE
5. Tworzenie listy ACL dla ruchu GRE (match gre any any)
6. Konfiguracja Crypto Map i przypisanie do interfejsu WAN
7. Weryfikacja szyfrowania pakietów OSPF multicast
8. Analiza struktury podwójnego nagłówka w trybie symulacji
9. Rozwiązywanie problemów z MTU i fragmentacją pakietów
10. Podsumowanie i wnioski z realizacji projektu

Podczas konfiguracji GRE over IPsec pamiętaj, że ACL musi matchować ruch GRE między adresami IP interfejsów zewnętrznych routerów, nie adresy IP tuneli. Do weryfikacji użyj poleceń show crypto isakmp sa i show crypto ipsec sa. W trybie symulacji sprawdź czy pakiety OSPF (multicast 224.0.0.5) są prawidłowo enkapsulowane. Z powodu podwójnej enkapsulacji (GRE + IPsec) konieczne może być zmniejszenie MTU na interfejsie tunelowym - użyj polecenia ip mtu 1400.

! KONFIGURACJA INTERFEJSÓW
R1#configure terminal
R1(config)#interface GigabitEthernet0/0
R1(config-if)#ip address 203.0.113.1 255.255.255.252
R1(config-if)#no shutdown
R1(config-if)#exit
R1(config)#interface GigabitEthernet0/1
R1(config-if)#ip address 192.168.1.1 255.255.255.0
R1(config-if)#no shutdown
R1(config-if)#exit

! KONFIGURACJA TUNELU GRE
R1(config)#interface Tunnel 0
R1(config-if)#ip address 10.0.0.1 255.255.255.252
R1(config-if)#tunnel source GigabitEthernet0/0
R1(config-if)#tunnel destination 203.0.113.2
R1(config-if)#ip mtu 1400
R1(config-if)#exit

! KONFIGURACJA OSPF
R1(config)#router ospf 1
R1(config-router)#network 192.168.1.0 0.0.0.255 area 0
R1(config-router)#network 10.0.0.0 0.0.0.3 area 0
R1(config-router)#exit

! KONFIGURACJA IPSEC DLA GRE
R1(config)#crypto isakmp policy 1
R1(config-isakmp)#exit
R1(config)#crypto ipsec transform-set TS_GRE esp-aes esp-sha-hmac
R1(cfg-crypto-trans)#exit
R1(config)#access-list 101 permit gre host 203.0.113.1 host 203.0.113.2
R1(config)#crypto map CMAP 10 ipsec-isakmp
R1(config-crypto-m)#match address 101
R1(config-crypto-m)#exit

! PRZYPISANIE CRYPTO MAP
R1(config)#interface GigabitEthernet0/0
R1(config-if)#crypto map CMAP
R1(config-if)#exit

! WERYFIKACJA - IPSEC SA
R1#show crypto ipsec sa
! #pkts encaps: 50, #pkts encrypt: 50
! #pkts decaps: 50, #pkts decrypt: 50
                    

VPN_07 Bezpieczeństwo serwera, silne hasła i aktualizacje.

Celem projektu jest zabezpieczenie samego urządzenia pełniącego rolę bramy VPN przed nieautoryzowanym dostępem i atakami. Projekt skupia się na elementach zarządzania routerem (Management Plane), aby zapobiec przejęciu kontroli nad tunelem przez osoby nieuprawnione. Student nauczy się konfigurować protokół SSH zamiast Telnet, wdrażać system uwierzytelniania AAA (Authentication, Authorization, Accounting), tworzyć polityki haseł oraz stosować listy ACL do ograniczenia dostępu zarządzania.

Po wdrożeniu tuneli VPN w firmie zauważono, że zarządzanie routerami odbywa się przez protokół Telnet, który przesyła hasła otwart tekstem. Dodatkowo dostęp do routerów jest możliwy z dowolnego adresu IP w sieci, co stwarza ryzyko ataków brute-force. Zdecydowano o wdrożeniu kompleksowego hardeningu: przejście na SSH v2, wdrożenie AAA z lokalną bazą użytkowników, ograniczenie dostępu zarządzania do konkretnych adresów IP adminów, włączenie szyfrowania haseł w konfiguracji oraz dodanie banerów ostrzegawczych. Celem jest zgodność z best practices bezpieczeństwa urządzeń sieciowych.

• Wykonanie podstawowej konfiguracji IP i tunelu VPN na ruterze.
• Zmiana domyślnego hasła enable na silne i zaszyfrowane (enable secret).
• Wyłączenie usługi Telnet (transport input ssh na liniach vty).
• Wyłączenie serwera HTTP (no ip http server).
• Generowanie kluczy RSA dla usługi SSH (crypto key generate rsa).
• Ustawienie wersji SSH na 2 (ip ssh version 2).
• Konfiguracja limitu czasu bezczynności i liczby prób logowania dla SSH.
• Utworzenie lokalnej bazy użytkowników z różnymi poziomami uprawnień.
• Konfiguracja modelu AAA (aaa new-model).
• Definicja metody uwierzytelniania dla logowania do konsoli i VTY.
• Konfiguracja uwierzytelniania enable przez AAA.
• Symulacja połączenia z serwerem RADIUS (jeśli dostępny w Packet Tracer).
• Utworzenie listy ACL typu Management ACL dla linii VTY.
• Zezwolenie na dostęp do administracji ruterem tylko z konkretnego IP.
• Zaszyfrowanie haseł w pliku konfiguracyjnym (service password-encryption).
• Konfiguracja banerów ostrzegawczych (banner motd).
• Wyłączenie nieużywanych interfejsów fizycznych (shutdown).
• Dokumentacja polityki bezpieczeństwa wprowadzonej na ruterze.
• Testy penetracyjne: próba logowania z niedozwolonego adresu IP.
• Zapisanie końcowej, bezpiecznej konfiguracji.

Dokumentacja powinna zawierać szczegółowy opis standardów "Best Practices" dla zabezpieczania routerów brzegowych. Należy przedstawić analizę ryzyka związanego z brakiem zabezpieczeń Management Plane. Dokument powinien zawierać tabelę z listą wdrożonych zabezpieczeń i ich uzasadnieniem.

1. Wprowadzenie do bezpieczeństwa urządzeń sieciowych i płaszczyzn zarządzania
2. Analiza zagrożeń i projektowanie polityki bezpieczeństwa routera
3. Konfiguracja podstawowego tunelu VPN i testowanie działania
4. Generowanie kluczy RSA i konfiguracja SSH v2
5. Konfiguracja AAA z lokalną bazą użytkowników
6. Tworzenie listy ACL dla dostępu zarządzania (Management ACL)
7. Konfiguracja banerów ostrzegawczych i szyfrowania haseł
8. Wyłączenie nieużywanych usług i interfejsów
9. Testowanie - weryfikacja zablokowania Telnet i dostępu SSH
10. Podsumowanie i wnioski z realizacji projektu

Podczas hardeningu routera zacznij od wyłączenia wszystkich niepotrzebnych usług (Telnet, HTTP). Pamiętaj o włączeniu szyfrowania haseł (service password-encryption) - chroni hasła w konfiguracji, ale nie jest tak bezpieczne jak enable secret z algorytmem type 5. Przed wyłączeniem Telnet upewnij się, że SSH działa poprawnie. Klucze RSA muszą być wygenerowane przed włączeniem SSH. Użyj polecenia show ip ssh do weryfikacji konfiguracji SSH. Management ACL powinna zawierać tylko adresy IP administratorów - nigdy nie zostawiaj 0.0.0.0/0.

! GENEROWANIE KLUCZY RSA
R1#configure terminal
R1(config)#ip domain-name ahe.lodz.pl
R1(config)#crypto key generate rsa modulus 1024

! KONFIGURACJA SSH
R1(config)#ip ssh version 2
R1(config)#ip ssh time-out 60
R1(config)#ip ssh authentication-retries 3

! KONFIGURACJA AAA
R1(config)#aaa new-model
R1(config)#username admin privilege 15 secret cisco123

! KONFIGURACJA HASŁA ENABLE
R1(config)#enable secret StrongeHaslo123!

! SZYFROWANIE HASEŁ
R1(config)#service password-encryption

! BANER OSTRZEGAWCZY
R1(config)#banner motd #UWAGA: Dostep dozwolony tylko dla autoryzowanych uzytkownikow#

! LINIE VTY - SSH TYLKO
R1(config)#line vty 0 4
R1(config-line)#transport input ssh
R1(config-line)#login local
R1(config-line)#exit

! MANAGEMENT ACL
R1(config)#access-list 50 permit 192.168.1.10
R1(config)#access-list 50 permit 192.168.1.11
R1(config)#line vty 0 4
R1(config-line)#access-class 50 in
R1(config-line)#exit

! WYLĄCZENIE NIUŻYWANYCH USŁUG
R1(config)#no ip http server
R1(config)#no service pad

! WERYFIKACJA SSH
R1#show ip ssh
! SSH Enabled - version 2.0
! Authentication timeout: 60 secs
! Authentication retries: 3

! WERYFIKACJA UZYTKOWNIKÓW
R1#show users
!   Line  User      Host(s)   Idle Location
!   0    con 0     idle       00:00:00
!  68   vty 0     admin      idle 00:02:15 192.168.1.10