Zadania projektowe - Architektura Sieci Teleinformatycznych

W4 Architektura Spine-Leaf, sieci Overlay, protokół VXLAN.

Głównym celem projektu jest zaprojektowanie i wdrożenie nowoczesnej architektury sieci wewnątrz centrum danych, która całkowicie eliminuje ograniczenia narzucone przez tradycyjny protokół Spanning Tree Protocol (STP). Tradycyjne podejście oparte na STP wymusza zablokowanie części portów przełącznika, co skutkuje nieefektywnym wykorzystaniem dostępnej przepustowości łączy oraz ogranicza skalowalność infrastruktury sieciowej. W ramach projektu należy zrealizować pełną implementację płaskiej topologii warstwy 2 (L2) nad szkieletem routowanym warstwy 3 (L3), co umożliwi bezproblemową migrację maszyn wirtualnych między fizycznymi hostami bez konieczności zmiany adresacji IP. Dodatkowo projekt zakłada wykorzystanie enkapsulacji VXLAN (Virtual Extensible LAN) w celu tworzenia wielu oddzielnych segmentów sieciowych na wspólnej infrastrukturze fizycznej, co znacząco poprawia elastyczność zarządzania zasobami centrum danych. Efektem końcowym powinna być w pełni funkcjonalna sieć zapewniająca wysoką przepustowość, automatyczną zbieżność oraz możliwość dalszej rozbudowy bez przestojów infrastrukturalnych.

Centrum danych firmy przeznaczone do obsługi usług biznesowych dynamicznie się rozrasta, co wymaga częstej migracji maszyn wirtualnych między fizycznymi hostami hiperwizorami znajdującymi się w różnych segmentach sieci fizycznej. Tradycyjna architektura oparta na STP uniemożliwia elastyczną migrację, ponieważ maszyna wirtualna musiałaby zmienić adresację IP po przeniesieniu do innego VLAN, co powodowałoby przestoje w świadczeniu usług i wymagało rekonfiguracji wielu systemów. Dodatkowo dział IT potrzebuje izolowania ruchu różnych działów organizacji przy zachowaniu wspólnej infrastruktury fizycznej, co przy tradycyjnym podejściu wymagałoby rozbudowy przełączników warstwy dostępowej. W aktualnym rozwiązaniu pojawiają się również problemy z redundancją, ponieważ STP blokuje porty przełączające w celu zapobieżenia pętlom, co skutkuje marnowaniem połowicziny dostępnej przepustowości łączy. Należy więc wdrożyć dwuwarstwową architekturę sieci: sieć podkładową (Underlay) opartą na rutowaniu L3 zapewniającą osiągalność między wszystkimi węzłami oraz sieć nakładową (Overlay) wykorzystującą enkapsulację VXLAN do przesyłania ramek warstwy 2 w paczkach UDP przez sieć podkładową. Takie podejście umożliwia dowolną izolację segmentów przy zachowaniu pełnej przepustowości łączy oraz zapewnia mobilność maszyn wirtualnych bez zmiany adresacji IP.

• Budowa topologii Spine-Leaf z minimum dwoma przełącznikami Spine i trzema Leaf.
• Konfiguracja routingu Underlay (np. OSPF) zapewniającego pełną łączność dla interfejsów Loopback.
• Implementacja VXLAN z wykorzystaniem punktów końcowych VTEP.
• Weryfikacja przesyłania ruchu L2 między odległymi węzłami Leaf.

1. Utworzyć topologię fizyczną w GNS3/EVE-NG z dwoma przełącznikami Spine i trzema przełącznikami Leaf (polecenia VPCS lub VM do symulacji hostów).
2. Połączyć każdy Leaf z każdym Spine krosowo (full mesh) - łącznie 6 połączeń.
3. Skonfigurować adresy IP na interfejsach sieciowych między Spine a Leaf (np. 10.0.1.0/30, 10.0.2.0/30 itd.).
4. Skonfigurować interfejsy Loopback0 na każdym urządzeniu (Spine: 10.255.1.x, Leaf: 10.255.2.x) - będą używane jako źródło VTEP.
5. Skonfigurować OSPF Area 0 na wszystkich interfejsach Loopback i punkt-punkt między Spine-Leaf.
6. Zweryfikować osiągalność wszystkich interfejsów Loopback pingiem przed przejściem do VXLAN.
7. Na każdym Leaf skonfigurować funkcjonalność VTEP (interfejsy NVE - Network Virtualization Edge).
8. Utworzyć sieci VLAN dla segmentów klienckich (VLAN 10 - Serwery, VLAN 20 - Użytkownicy, VLAN 30 - Goście).
9. Przypisać identyfikatory VNI do każdego VLAN (VLAN 10 → VNI 10010, VLAN 20 → VNI 10020, VLAN 30 → VNI 10030).
10. Skonfigurować rozgłaszanie (broadcast, unknown-unicast, multicast) dla każdego VNI.
11. Zweryfikować sąsiedztwo VNI między Leafami (polecenie show nve vni).
12. Podłączyć hosty do portów dostępu Leaf i sprawdzić przydział adresów IP.
13. Wygenerować ruch L2 między hostami w różnych Leaf ale tym samym segmencie VLAN.
14. Przechwycić ruch Wireshark na interfejsie fizycznym i zidentyfikować enkapsulację VXLAN (port UDP 4789).
15. Zweryfikować tablice MAC i wpisy VNI na każdym Leaf (show mac address-table, show nve peers).

Przed przystąpieniem do konfiguracji VXLAN należy dokładnie zaplanować schemat adresacji podsieci podkładowej, aby zapewnić unikalność adresów Loopback dla każdego urządzenia Spine i Leaf. Adresy te będą źródłem punktów końcowych VTEP, więc muszą być routowalne w całej sieci podkładowej. Podczas konfiguracji OSPF na interfejsach punkt-punkt należy pamiętać o jawnej konfiguracji typu sieci jako point-to-point, ponieważ domyślny tryb broadcast może powodować problemy z sąsiedztwem na łączach typu point-to-point. W trakcie weryfikacji zaleca się rozpocząć od testów ping między interfejsami Loopback przed włączeniem VXLAN, co pozwala wyizolować problemy warstwy podkładowej od warstwy nakładki. Przy konfiguracji multicast dla VNI należy używać adresów z zakresu administracyjnego 239.0.0.0/8, aby uniknąć kolizji z innymi mechanizmami multicast w sieci. Podczas testowania enkapsulacji VXLAN w Wireshark należy filtrować port UDP 4789 lub używać filtru vxlan, co ułatwia identyfikację przesyłanych ramek.

!
! KONFIGURACJA INTERFEJSÓW SIEĆ PODSTAWOWA (UNDERLAY)
Leaf-1#configure terminal
Leaf-1(config)#interface Loopback0
Leaf-1(config-if)#ip address 10.255.2.1 255.255.255.255
Leaf-1(config-if)#ip ospf network point-to-point
Leaf-1(config-if)#exit
Leaf-1(config)#interface GigabitEthernet0/0
Leaf-1(config-if)#description Do_Spine-1
Leaf-1(config-if)#ip address 10.0.1.1 255.255.255.252
Leaf-1(config-if)#ip ospf network point-to-point
Leaf-1(config-if)#no shutdown
Leaf-1(config-if)#exit
Leaf-1(config)#interface GigabitEthernet0/1
Leaf-1(config-if)#description Do_Spine-2
Leaf-1(config-if)#ip address 10.0.2.1 255.255.255.252
Leaf-1(config-if)#ip ospf network point-to-point
Leaf-1(config-if)#no shutdown
Leaf-1(config-if)#exit

! KONFIGURACJA OSPF (ROUTING UNDERLAY)
Leaf-1(config)#router ospf 1
Leaf-1(config-router)#router-id 10.255.2.1
Leaf-1(config-router)#network 10.255.2.1 0.0.0.0 area 0
Leaf-1(config-router)#network 10.0.1.0 0.0.0.3 area 0
Leaf-1(config-router)#network 10.0.2.0 0.0.0.3 area 0
Leaf-1(config-router)#exit

! TWORZENIE VLAN DLA SEGMENTÓW
Leaf-1(config)#vlan 10
Leaf-1(config-vlan)#name SERWERY
Leaf-1(config-vlan)#exit
Leaf-1(config)#vlan 20
Leaf-1(config-vlan)#name UŻYTKOWNICY
Leaf-1(config-vlan)#exit
Leaf-1(config)#vlan 30
Leaf-1(config-vlan)#name GOSCIE
Leaf-1(config-vlan)#exit

! INTERFEJS NVE (VTEP) - NAKŁADKA VXLAN
Leaf-1(config)#interface nve1
Leaf-1(config-if)#no ip address
Leaf-1(config-if)#source-interface Loopback0
Leaf-1(config-if)#host-reachability protocol bgp
Leaf-1(config-if)#member vni 10010
Leaf-1(config-if-nve)#mcast-group 239.0.0.10
Leaf-1(config-if-nve)#exit
Leaf-1(config-if)#member vni 10020
Leaf-1(config-if-nve)#mcast-group 239.0.0.20
Leaf-1(config-if-nve)#exit
Leaf-1(config-if)#member vni 10030
Leaf-1(config-if-nve)#mcast-group 239.0.0.30
Leaf-1(config-if-nve)#exit
Leaf-1(config-if)#exit
Leaf-1(config)#exit

! WERYFIKACJA KONFIGURACJI
Leaf-1#show nve vni
Codes: CP - Control Plane, DP - Data Plane, UC - Unicast, UP - Unknown
Interface  VNI        Multicast      VNI State  Mode     Peer-IP    VC#  CP
nve1       10010      239.0.0.10     UP         L2CP     10.255.2.2  -   -
nve1       10020      239.0.0.20     UP         L2CP     10.255.2.2  -   -
nve1       10030      239.0.0.30     UP         L2CP     10.255.2.2  -   -

Leaf-1#show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
10.255.1.1        1   FULL/DR         00:00:35    10.0.1.2       GigabitEthernet0/0
10.255.1.2        1   FULL/DR         00:00:38    10.0.2.2       GigabitEthernet0/1

Leaf-1#show mac address-table vlan 10
          Mac Address Table
Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
 10     aaaa.bbbb.cccc    DYNAMIC     Gi0/2
 10     001d.46aa.1234    DYNAMIC     nve1    (VNI 10010)
 10     001d.46aa.5678    DYNAMIC     nve1    (VNI 10010)

Leaf-1#ping 10.255.2.2 source Loopback0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.255.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/5 ms
                    

Przykładowy schemat

W2 Routing IPv4/IPv6, mechanizmy przejścia, autokonfiguracja.

Głównym celem projektu jest zapewnienie pełnej łączności sieciowej w standardzie IPv6 przy jednoczesnym zachowaniu kompatybilności wstecznej z istniejącą infrastrukturą opartą na IPv4. Firma prowadzi stopniową migrację swoich systemów i usług do nowszego standardu adresacji, co wymaga równoległego działania obu protokołów w tej samej infrastrukturze. Projekt obejmuje szczegółowe planowanie schematu adresacji IPv6 z podziałem na logiczne segments dla poszczególnych działów organizacji, a także konfigurację routingu dynamicznego dla obu rodzin protokołów z wykorzystaniem OSPFv2 dla IPv4 oraz OSPFv3 dla IPv6. Dodatkowo zadaniem jest wdrożenie automatycznego pobierania adresów IPv6 przez stacje robocze z wykorzystaniem mechanizmu SLAAC (Stateless Address Autoconfiguration) wspieranego przez serwer DHCPv6 w trybie Stateless, co zapewnia elastyczność w zarządzaniu adresacją. Końcowym efektem projektu ma być w pełni funkcjonalna sieć korporacyjna obsługująca jednocześnie hosty IPv4 i IPv6 bez konieczności utrzymywania oddzielnych fizycznych infrastruktur.

Firma prowadzi intensywną modernizację swojej infrastruktury IT, której częścią jest stopniowa migracja do standardu IPv6 w celu zapewnienia dostępu do nowoczesnych usług internetowych oraz przygotowania na wyczerpanie puli adresów IPv4. Dział IT otrzymał od regionalnego dostawcy usług internetowych blok adresów IPv6 /48, który musi zostać właściwie podzielony na mniejsze podsieci dla poszczególnych departamentów. Część serwerów i stacji roboczych wspiera już adresację IPv6, jednak większość infrastruktury sieciowej nadal opiera się na IPv4. Należy więc wdrożyć mechanizm Dual-Stack na wszystkich routerach i przełącznikach warstwy L3, aby umożliwić jednoczesną komunikację w obu standardach. Dodatkowo hosty muszą mieć możliwość automatycznego pobierania adresów IPv6 bez ręcznej konfiguracji, co wymaga wdrożenia Router Advertisement (RA) z odpowiednimi flagami oraz opcjonalnego serwera DHCPv6 dostarczającego informacji uzupełniających takich jak serwery DNS.

• Podział prefiksu IPv6 /48 na podsieci dla różnych departamentów.
• Konfiguracja protokołu OSPFv3 z obsługą adresacji IPv4 i IPv6.
• Wdrożenie autokonfiguracji SLAAC oraz serwera Stateless DHCPv6.
• Implementacja list kontroli dostępu IPv6 ACL na brzegu sieci.

1. Zaplanować schemat adresacji IPv6: otrzymany prefiks /48 podzielić na /64 dla każdego działu (minimum 4 działy: IT, Księgowość, Zarząd, Goście).
2. Utworzyć topologię w GNS3/EVE-NG: 2 routery rdzeniowe, 2 przełączniki L3, po jednym VLAN dla każdego działu.
3. Skonfigurować adresy IPv4 na interfejsach routerów (sieć klasy B np. 172.16.0.0/22 lub prywatna 10.0.0.0/16).
4. Skonfigurować adresy IPv6 na interfejsach (np. 2001:db8:abcd::/48, każdy dział = kolejne /64).
5. Na routerach skonfigurować OSPFv2 dla IPv4 z area 0 na wszystkich łączach.
6. Skonfigurować OSPFv3 dla IPv6 z area 0 (uwaga: OSPFv3 wymaga osobnej konfiguracji i router-id).
7. Skonfigurować interfejsy VLAN na przełącznikach L3 z adresami IPv4 i IPv6 (SVI).
8. Na routerze brzegowym skonfigurować router NDP (Router Advertisement) z flagami O (Other config) dla SLAAC+DHCPv6.
9. Skonfigurować serwer DHCPv6 Stateless na routerze (informacje DNS, domain-name, bez adresów).
10. Na hostach (VPCS lub maszyny wirtualne) zweryfikować otrzymanie adresu IPv6 metodą SLAAC (EUI-64).
11. Skonfigurować listy ACL IPv6 na routerze brzegowym: blokowanie ruchu przychodzącego z zewnątrz, zezwolenie na established.
12. Przetestować łączność IPv4: ping między działami, traceroute.
13. Przetestować łączność IPv6: ping6, traceroute6.
14. Przechwycić ruch ICMPv6 w Wireshark i zidentyfikować komunikaty RS/RA, NS/NA.
15. Wygenerować ruch z jednego działu do drugiego i zweryfikować trasy w tablicy routowania IPv4 i IPv6.

!
! KONFIGURACJA ADRESACJI IPv4 ORAZ IPv6
Router#configure terminal
Router(config)#interface GigabitEthernet0/0
Router(config-if)#description LAN_IT
Router(config-if)#ip address 172.16.10.1 255.255.255.0
Router(config-if)#ipv6 address 2001:db8:abcd:10::1/64
Router(config-if)#ipv6 enable
Router(config-if)#no shutdown
Router(config-if)#exit

Router(config)#interface GigabitEthernet0/1
Router(config-if)#description LAN_KSIEGOWOSC
Router(config-if)#ip address 172.16.20.1 255.255.255.0
Router(config-if)#ipv6 address 2001:db8:abcd:20::1/64
Router(config-if)#ipv6 enable
Router(config-if)#no shutdown
Router(config-if)#exit

Router(config)#interface GigabitEthernet0/2
Router(config-if)#description ŁĄCZE_DO_INTERNETU
Router(config-if)#ip address 203.0.113.1 255.255.255.252
Router(config-if)#ipv6 address 2001:db8:ffff::1/126
Router(config-if)#no shutdown
Router(config-if)#exit

! OSPFv2 DLA IPv4
Router(config)#router ospf 1
Router(config-router)#router-id 1.1.1.1
Router(config-router)#network 172.16.10.0 0.0.0.255 area 0
Router(config-router)#network 172.16.20.0 0.0.0.255 area 0
Router(config-router)#exit

! OSPFv3 DLA IPv6
Router(config)#ipv6 router ospf 1
Router(config-rtr)#router-id 1.1.1.1
Router(config-rtr)#exit

Router(config)#interface GigabitEthernet0/0
Router(config-if)#ipv6 ospf 1 area 0
Router(config-if)#exit

Router(config)#interface GigabitEthernet0/1
Router(config-if)#ipv6 ospf 1 area 0
Router(config-if)#exit

! KONFIGURACJA ROUTER ADVERTISEMENT (SLAAC + DHCPv6 STATELESS)
Router(config)#ipv6 dhcp pool IT-DHCPV6
Router(config-dhcp)#dns-server 2001:db8:ffff::53
Router(config-dhcp)#domain-name firma.local
Router(config-dhcp)#exit

Router(config)#interface GigabitEthernet0/0
Router(config-if)#ipv6 nd other-config-flag
Router(config-if)#ipv6 dhcp server IT-DHCPV6
Router(config-if)#exit

Router(config)#ipv6 dhcp pool KSIEGOWOSC-DHCPV6
Router(config-dhcp)#dns-server 2001:db8:ffff::53
Router(config-dhcp)#domain-name firma.local
Router(config-dhcp)#exit

Router(config)#interface GigabitEthernet0/1
Router(config-if)#ipv6 nd other-config-flag
Router(config-if)#ipv6 dhcp server KSIEGOWOSC-DHCPV6
Router(config-if)#exit

! LISTA KONTROLI DOSTĘPU IPv6 (ACL)
Router(config)#ipv6 access-list BLOCK-EXTERNAL
Router(config-ipv6-acl)#permit icmpv6 any any echo-reply
Router(config-ipv6-acl)#permit icmpv6 any any time-exceeded
Router(config-ipv6-acl)#permit icmpv6 any any parameter-problem
Router(config-ipv6-acl)#permit tcp any any established
Router(config-ipv6-acl)#deny ipv6 any any log
Router(config-ipv6-acl)#exit

Router(config)#interface GigabitEthernet0/2
Router(config-if)#ipv6 traffic-filter BLOCK-EXTERNAL in
Router(config-if)#exit
Router(config)#exit

! WERYFIKACJA KONFIGURACJI
Router#show ipv6 route
IPv6 Routing Table - default - 9 entries
Codes: C - Connected, L - Local, S - Static, O - OSPF, B - BGP
C   2001:db8:abcd:10::/64 [0/0]
     via GigabitEthernet0/0, directly connected
L   2001:db8:abcd:10::1/128 [0/0]
     via GigabitEthernet0/0, receive
C   2001:db8:abcd:20::/64 [0/0]
     via GigabitEthernet0/1, directly connected
L   2001:db8:abcd:20::1/128 [0/0]
     via GigabitEthernet0/1, receive
O   2001:db8:abcd:30::/64 [110/2]
     via FE80::2, GigabitEthernet0/2
S   ::/0 [1/0]
     via 2001:db8:ffff::2

Router#show ipv6 ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           1   FULL/DR         00:00:32    FE80::2         Gi0/2

Router#show ipv6 dhcp binding
Client: FE80::2AA:BBFF:FECC:DD
  DUID: 00030001002AABFFCCDD
  IA PD: IA ID 0x1234, T1 43200, T2 69120
    Prefix: 2001:db8:abcd:10:2AA:BBFF:FECC:DD/64
    preferred lifetime 86400, valid lifetime 86400

Router#ping ipv6 2001:db8:abcd:20::10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:ABCD:20::10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Router#traceroute ipv6 2001:db8:abcd:30::1
Type escape sequence to abort.
Tracing the route to 2001:DB8:ABCD:30::1
  1 2001:db8:ffff::2 4 msec 2 msec 2 msec
  2 2001:db8:abcd:30::1 6 msec 4 msec 4 msec
                    

Przykładowy schemat

W2 Tunelowanie IP, W4 Koncepcja SD-WAN, hybrydowe łącza.

Głównym celem projektu jest wdrożenie nowoczesnej architektury programowalnej sieci rozległej (SD-WAN), która dynamicznie i inteligentnie wybiera optymalną ścieżkę transmisji danych między oddziałami a centralą. Tradycyjne podejście oparte na statycznych trasach i jednym dostawcy usług nie zapewnia elastyczności ani odporności na awarie. W ramach projektu należy zaimplementować rozwiązanie pozwalające na jednoczesne wykorzystanie łączy MPLS o wysokiej jakości oraz tańszych łącz szerokopasmowych, z automatycznym sterowaniem ruchem w zależności od stanu aplikacji i parametrów łącza. System powinien monitorować jakość każdego łącza w czasie rzeczywistym i automatycznie przełączać ruch krytyczny (np. systemy ERP, bazy danych) na łącze o lepszych parametrach, kierując ruch o niższym priorytecie (np. przeglądanie WWW, strumieniowanie wideo) na tańsze łącza. Efektem projektu ma być w pełni automatyczny system zapewniający ciągłość działania usług przy minimalnych kosztach infrastruktury.

Organizacja posiada trzy oddziały terenowe rozmieszczone geograficznie w różnych regionach, z których każdy jest połączony z centralą drogimi łączami MPLS zapewniającymi wysoką jakość transmisji, oraz dodatkowymi tańszymi łączami szerokopasmowymi (Internet) jako zapasowymi. Aktualnie ruch z każdego oddziału jest kierowany wyłącznie przez łącze MPLS, niezależnie od jego aktualnego obciążenia i jakości, co przy dużym ruchu powoduje opóźnienia i straty pakietów szczególnie dla aplikacji krytycznych. Dodatkowo awaria łącza MPLS skutkuje przestojem usług do czasu automatycznego lub ręcznego przełączenia na łącze zapasowe. Zarząd firmy oczekuje rozwiązania, które automatycznie będzie kierować ruch krytyczny (ERP, bazy danych) przez łącze MPLS, a ruch o mniejszym znaczeniu (WWW, strumienie wideo) przez tańsze łącze Internetowe, reagując na wzrost jittera powyżej określonego progu. Takie rozwiązanie pozwoli zmniejszyć koszty przy jednoczesnym zachowaniu wysokiej jakości usług krytycznych.

• Konfiguracja bezpiecznych tuneli (np. IPsec) między oddziałami.
• Implementacja mechanizmu monitorowania SLA (opóźnienie, straty pakietów).
• Definicja polityk sterowania ruchem (Application-aware routing).
• Symulacja awarii łącza głównego i weryfikacja czasu zbieżności.

1. Utworzyć topologię w GNS3/EVE-NG: 2 routery w oddziale (Edge), 2 routery reprezentujące ISP, 1 serwer monitoringowy.
2. Skonfigurować interfejsyWAN na routerach oddziałowych: łącze do ISP1 (MPLS) i ISP2 (Internet).
3. Przydzielić numer AS dla firmy (np. AS 65001) i numery AS dla ISP (np. AS 65010 dla ISP1, AS 65020 dla ISP2).
4. Skonfigurować sesje eBGP między routerami oddziałowymi a routerami ISP.
5. Na routerze brzegowym skonfigurować statyczne trasy do sieci wewnętrznych i rozgłosić je przez BGP.
6. Skonfigurować atrybut Local Preference dla tras przychodzących od ISP1 (wyższa wartość dla pobierania).
7. Zastosować AS-Path Prepend na trasach wysyłanych do ISP2 (wydłużona ścieżka AS zachęca do wyjścia przez ISP1).
8. Skonfigurować Route Map do manipulacji atrybutami BGP.
9. Utworzyć Prefix List do filtrowania tras (zezwolić tylko na sieci należące do firmy).
10. Skonfigurować i włączyć BFD (Bidirectional Forwarding Detection) dla szybkiego wykrywania awarii.
11. Skonfigurować tunele IPsec przez łącze Internetowe (jako zapasowe).
12. Przetestować łączność przez oba łącza (ping do adresów publicznych przez oba ISP).
13. Wyłączyć fizycznie łącze do ISP1 i zweryfikować automatyczne przełączenie na ISP2.
14. Sprawdzić tablicę BGP: show ip bgp, show ip bgp neighbor, show ip bgp path.
15. Zweryfikować atrybuty tras w tabeli BGP (Local Preference, AS-Path, MED).

Przed konfiguracją BGP należy upewnić się, że istnieje pełna łączność IP między wszystkimi interfejsami WAN, ponieważ sesje BGP wymagają działającej warstwy trzeciej. Podczas konfiguracji atrybutu Local Preference należy pamiętać, że wyższa wartość oznacza wyższy priorytet trasy przy podejmowaniu decyzji o routowaniu w obrębie AS, więc dla preferowanego ISP1 należy ustawić wyższą wartość (np. 200), a dla drugiego ISP niższą (np. 100). AS-Path Prepend działa w przeciwnym kierunku - wydłużając ścieżkę AS dla tras wysyłanych do ISP2, zachęcamy zewnętrznych BGP do kierowania ruchu przez ISP1 z mniejszą liczbą AS w ścieżce. BFD powinno być skonfigurowane na wszystkich sesjach BGP dla szybkiego wykrywania awarii, przy czym interwał powinien być dopasowany do charakterystyki łącza (np. 50ms dla MPLS). Podczas testowania przełączenia awaryjnego zaleca się fizyczne odłączenie łącza, a nie wyłączenie interfejsu komendą shutdown, co pozwala na weryfikację zachowania BFD w warunkach rzeczywistych.

W2 Protokół BGP, systemy autonomiczne (AS), atrybuty Path Vector.

Głównym celem projektu jest zapewnienie pełnej redundancji i optymalizacja kosztów połączenia organizacji z Internetem poprzez wykorzystanie dwóch niezależnych dostawców usług (multihoming). Firma posiada własny publiczny blok adresów IP, który musi być dostępny przez oba łącza, zapewniając ciągłość działania nawet w przypadku awarii jednego z dostawców. Projekt obejmuje szczegółową konfigurację protokołu BGP z zaawansowaną manipulacją atrybutami w celu precyzyjnego sterowania ruchem wejściowym ( inbound) i wyjściowym (outbound). Należy skonfigurować atrybut Local Preference dla kontrolowania ruchu przychodzącego od dostawców, AS-Path Prepending dla optymalizacji kosztów ruchu wychodzącego oraz inne mechanizmy jak MED i BGP Community. Efektem projektu ma być w pełni redundantna infrastruktura zapewniająca ciągłość działania usług przy minimalnych kosztach połączeń.

Firma posiada własny publiczny blok adresów IP (/24) wykorzystywany do świadczenia usług internetowych oraz dwa niezależne łącza do różnych dostawców ISP zapewniające dostęp do Internetu. Aktualnie cały ruch jest kierowany przez jednego dostawcę (ISP1), co przy awarii tego łącza powoduje całkowitą niedostępność usług. Dodatkowo zarząd firmy oczekuje optymalizacji kosztów, czyli wykorzystania tańszego łącza ISP2 dla ruchu wychodzącego, przy zachowaniu ISP1 jako głównego dla ruchu przychodzącego. Należy więc wdrożyć rozwiązanie oparte na protokole BGP z zaawansowaną inżynierią ruchu: atrybut Local Preference pozwoli preferować trasy od ISP1 dla ruchu przychodzącego, AS-Path Prepend wydłuży ścieżkę AS dla tras reklamowanych do ISP2, zachęcając zewnętrzny ruch do kierowania przez ISP1, a MED (Multi-Exit Discriminator) umożliwi finezyjną kontrolę nad tym, którym łączem ruch wychodzi do poszczególnych dostawców.

• Konfiguracja sesji eBGP z dwoma różnymi numerami AS dostawców.
• Zastosowanie list prefiksów do ograniczania rozgłaszanych tras.
• Wykorzystanie Route-Maps do modyfikacji atrybutów wagowych.
• Wdrożenie sesji iBGP między routerami brzegowymi organizacji.

1. Utworzyć topologię w GNS3/EVE-NG: 2 routery brzegowe (Edge), routery ISP1 i ISP2, serwery wewnętrzne.
2. Skonfigurować interfejsy WAN z adresami publicznymi na obu routerach Edge.
3. Przydzielić numer AS dla organizacji (np. AS 65001) oraz numery AS dla ISP (AS 65010 i AS 65020).
4. Skonfigurować sesje eBGP z oboma dostawcami na obu routerach Edge.
5. Skonfigurować sesję iBGP między routerami Edge (trasy wewnętrzne BGP).
6. Skonfigurować Route Reflector na jednym z routerów Edge dla uproszczenia iBGP.
7. Utworzyć Prefix Lists do filtrowania tras przychodzących i wychodzących.
8. Skonfigurować Route Maps z atrybutem Local Preference dla sterowania ruchem przychodzącym.
9. Zastosować AS-Path Prepend na trasach rozgłaszanych do mniej preferowanego ISP.
10. Skonfigurować MED (Multi-Exit Discriminator) na trasach wysyłanych do ISP.
11. Skonfigurować BGP Community dla dalszej manipulacji trasami.
12. Zweryfikować tablicę BGP: show ip bgp, show ip bgp neighbors.
13. Przetestować łączność przez oba łącza i wyśledzić trasę (traceroute).
14. Symulować awarię jednego łącza i zweryfikować zbieżność (preemption).
15. Dokumentować proces podejmowania decyzji BGP (BGP Best Path Selection).

Przed konfiguracją BGP kluczowe jest zrozumienie 13-stopniowego algorytmu BGP Best Path Selection, który określa kolejność preferowania tras. Local Preference ma najwyższy priorytet (krok 7), więc jest jednym z pierwszych atrybutów branych pod uwagę przy wyborze najlepszej trasy. Przy konfiguracji route-map dla manipulacji atrybutami należy pamiętać o właściwej kolejności reguł (sequence numbers), ponieważ przetwarzanie odbywa się sekwencyjnie. Route Reflector znacząco upraszcza topologię iBGP, eliminując potrzebę pełnej siatki połączeń między routerami wewnętrznymi - wystarczy jeden router skonfigurowany jako Route Reflector z pozostałymi jako klientami. Podczas testowania symulacji awarii zaleca się użycie polecenia shutdown na interfejsie, co powoduje naturalne przełączenie tras w tabeli BGP zgodne z algorytmem wyboru najlepszej ścieżki.

W4 Koncepcja NFV, wirtualizacja usług, load balancing.

Głównym celem projektu jest zastąpienie tradycyjnych, dedykowanych urządzeń sieciowych (router, firewall, load balancer) ich wirtualnymi odpowiednikami działającymi na standardowej infrastrukturze serwerowej. Firma planuje otwarcie nowego oddziału, gdzie ze względów budżetowych nie przewidziano zakupu dedykowanego sprzętu sieciowego. Decyzją zarządu ma zostać wdrożone rozwiązanie NFV (Network Functions Virtualization) oparte na maszynach wirtualnych uruchomionych na standardowych serwerach. Projekt obejmuje konfigurację wirtualnego routera (vRouter), wirtualnego firewalla (vFirewall) oraz wirtualnego load balancera, które połączone w logiczny łańcuch usług (Service Chain) zapewnią pełną funkcjonalność sieciową. Dodatkowo należy oszacować wydajność i zużycie zasobów (CPU, RAM) przez poszczególne funkcje sieciowe, porównując je z parametrami tradycyjnych urządzeń. Efektem projektu ma być w pełni funkcjonalne rozwiązanie, które może stanowić alternatywę dla kosztownego sprzętu dedykowanego.

Firma otwiera nowy oddział w innym mieście, którego budżet nie pozwala na zakup dedykowanych urządzeń sieciowych takich jak router brzegowy, firewall sprzętowy czy load balancer. Jednocześnie zarząd oczekuje pełnej funkcjonalności sieciowej porównywalnej z centralą: NAT, routing, filtrowanie ruchu, serwer DHCP, QoS oraz rozdzielanie obciążenia między serwerami WWW. Dział IT ma za zadanie wdrożyć rozwiązanie oparte na wirtualizacji funkcji sieciowych (NFV) przy wykorzystaniu dostępnych narzędzi jak MikroTik RouterOS (CHR) lub Cisco CSR1000v uruchomionych w środowisku VirtualBox lub GNS3. Wszystkie usługi muszą działać na standardowej infrastrukturze serwerowej z wystarczającymi zasobami. Należy skonfigurować vRouter realizujący NAT i routing, vFirewall zapewniający filtrowanie ruchu oraz vLoad Balancer rozdzielający ruch HTTP/HTTPS między dwoma serwerami WWW. Całość musi być udokumentowana od strony zużycia zasobów i wydajności.

• Implementacja minimum trzech funkcjonalności sieciowych jako maszyn wirtualnych.
• Konfiguracja wirtualnego Load Balancera rozdzielającego ruch do serwerów WWW.
• Zarządzanie zasobami (CPU/RAM) przypisanymi do instancji sieciowych.
• Weryfikacja wydajności (przepływność) wirtualnego stosu sieciowego.

1. Utworzyć środowisko wirtualne (VirtualBox lub GNS3) z routerem MikroTik CHR (RouterOS).
2. Utworzyć trzy maszyny wirtualne: vRouter (RouterOS), vFirewall (RouterOS), serwer WWW (Linux).
3. Skonfigurować interfejsy sieciowe: WAN, LAN, DMZ jako osobne Bridges lub VLANy.
4. Na vRouter skonfigurować NAT, routing między sieciami, serwer DHCP.
5. Na vFirewall skonfigurować reguły filtrowania, NAT, QoS.
6. Utworzyć wirtualny Load Balancer z wykorzystaniem IP Firewall (dwa serwery WWW w puli).
7. Skonfigurować Firewall NAT dla przekierowania ruchu HTTP/HTTPS do serwerów.
8. Utworzyć Profile w Proxy HTTP dla cache'owania i filtrowania treści.
9. Skonfigurować Simple Queue dla limitowania pasma użytkowników.
10. Przydzielić zasoby CPU/RAM do każdej maszyny wirtualnej i zmierzyć wykorzystanie.
11. Przeprowadzić testy wydajności: iperf3 między maszynami wirtualnymi.
12. Zweryfikować funkcjonalność Load Balancera (dostęp do serwera WWW przez wirtualny IP).
13. Zmierzyć opóźnienia i throughput przed i po włączeniu usług sieciowych.
14. Dokumentować wykorzystanie zasobów w tabeli vResources.

Przed uruchomieniem maszyn wirtualnych należy upewnić się, że system hosta (VirtualBox lub GNS3) ma wystarczające zasoby CPU i RAM dla wszystkich instancji. MikroTik CHR oferuje pełną funkcjonalność w darmowej wersji z limitem 1 Mbps, ale do celów projektowych (testy) to wystarczające - wersja płatna znosi limit. Przy konfiguracji DHCP server należy pamiętać o właściwym ustawieniu interfejsu, na którym nasługuje, oraz o definicji puli adresów (address-pool). Konfiguracja NAT masquerade jest niezbędna dla sieci LAN aby miała dostęp do Internetu przez WAN. Przy testowaniu Load Balancera metodą nth (round-robin) należy pamiętać, że działa na poziomie połączeń, a nie sesji, więc przy ruchu HTTP może wystąpić nierównomierowe rozłożenie. Do bardziej zaawansowanego load balancingu należy rozważyć Connection Rate Limiting lub PCC (Per Connection Classifier).

W4 Bezpieczeństwo IoT/OT, model Zero Trust, mikrosegmentacja.

Głównym celem projektu jest ochrona krytycznej infrastruktury przemysłowej (OT) oraz biurowych urządzeń IoT (Internet of Things), które posiadają ograniczone mechanizmy własnej obrony przed cyberzagrożeniami. Urządzenia te często operate na starszych protokołach bez szyfrowania i uwierzytelniania, co czyni je łatwym celem ataków. Projekt wymaga wdrożenia modelu bezpieczeństwa Zero Trust opierającego się na zasadzie "nigdy nie ufaj, zawsze weryfikuj", gdzie każde połączenie musi być jawnie autoryzowane, niezależnie od tego, skąd pochodzi. Należy zastosować mikrosegmentację sieci, która izoluje urządzenia IoT/OT od reszty infrastruktury, oraz zaimplementować inspekcję stanową ruchu na poziomie firewall. Efektem projektu ma być w pełni zabezpieczona infrastruktura, gdzie nieautoryzowany ruch jest blokowany na poziomie sieci, nawet jeśli atakujący uzyska dostęp do wewnętrznej sieci.

W sieci fabryki znajdują się sterowniki PLC (Programmable Logic Controller) sterujące procesami produkcyjnymi oraz czujniki temperatury i wilgotności zbierające dane środowiskowe. Te urządzenia komunikują się protokołami przemysłowymi (Modbus, BACnet, MQTT) i często nie wspierają żadnych mechanizmów szyfrowania. Dodatkowo w sieci biurowej działają urządzenia IoT jak kamery monitoringu IP, drukarki sieciowe, inteligentne oświetlenie i termostaty. Aktualnie wszystkie te urządzenia są w tej samej sieci co komputery pracowników, co stwarza poważne ryzyko - atakujący, który wejdzie w posiadanie laptopa pracownika lub wykorzysta lukę w drukarce, może uzyskać dostęp do sterowników PLC i potencjalnie zakłócić procesy produkcyjne. Należy więc odizolować ruch OT i IoT od sieci biurowej za pomocą osobnych VLAN oraz wdrożyć politykę Zero Trust: domyślnie blokuj wszystkie połączenia, zezwól tylko jawnie autoryzowane. Każde urządzenie musi być zidentyfikowane, a dostęp do niego ograniczony do minimalnych wymagań operacyjnych.

• Wdrożenie technologii Private VLAN lub list ACL do izolacji urządzeń IoT.
• Konfiguracja uwierzytelniania opartego na tożsamości urządzenia (np. MAB).
• Implementacja inspekcji stanowej ruchu OT na firewallu krawędziowym.
• Zastosowanie ograniczeń pasma dla urządzeń w celu ochrony przed botnetami.

1. Utworzyć topologię w GNS3/VirtualBox: router MikroTik jako brama, przełącznik L2, urządzenia IoT (kamera, czujnik), stacja robocza.
2. Skonfigurować sieć VLAN: VLAN 10 (biuro), VLAN 20 (IoT), VLAN 30 (OT/PLC), VLAN 99 (management).
3. Skonfigurować interfejsy VLAN na routerze i przełączniku.
4. Na routerze skonfigurować Firewall z domyślną polityką DROP dla ruchu przychodzącego.
5. Utworzyć reguły firewall dla mikrosegmentacji: zezwolić tylko na dozwoloną komunikację.
6. Skonfigurować Address List dla urządzeń IoT z ich znanymi adresami MAC/IP.
7. Zaimplementować filtrowanie na podstawie protokołów (MQTT, Modbus, BACnet).
8. Skonfigurować limitowanie pasma (rate limiting) dla sieci IoT.
9. Utworzyć reguły NAT dla autoryzowanego dostępu z zewnątrz.
10. Skonfigurować logowanie zdarzeń firewall (action=log).
11. Zweryfikować izolację między VLANami (ping z VLAN20 do VLAN10 powinien być zablokowany).
12. Przetestować dostęp do urządzeń IoT z autoryzowanej stacji roboczej.
13. Sprawdzić logi firewall i zidentyfikować próby nieautoryzowanego dostępu.
14. Utworzyć matrycę separacji w formie tabeli.

Przy konfiguracji VLAN dla IoT/OT należy pamiętać o właściwym tagowaniu na portach - urządzenia końcowe zwykle nie rozumieją VLAN, więc port dostępu powinien mieć tryb access (bez tagowania), a trunk powinien być na porcie do routera. Domyslna polityka DROP jest kluczowa dla Zero Trust - najpierw blokujemy wszystko, potem jawnie zezwalamy na dozwolony ruch. Przy konfiguracji MAB (MAC Authentication Bypass) należy pamiętać, że to mechanizm uwierzytelniania urządzeń na podstawie adresu MAC - przydatny dla urządzeń bez loginu. Filtrowanie protokołów OT jak Modbus (port 502) i MQTT (port 1883) powinno być bardzo restrykcyjne - zezwól tylko na niezbędne połączenia do serwera SCADA/MQTT broker. Rate limiting dla sieci IoT chroni przed atakami DDoS z botnetów zbudowanych z zhakowanych kamer czy rejestratorów.

W2 QoS L3, W3 Jitter, opóźnienia, mechanizmy TCP/UDP.

Głównym celem projektu jest zapewnienie stabilnej i wysokiej jakości pracy usług multimedialnych czasu rzeczywistego (VoIP, wideokonferencje) w warunkach dużego obciążenia sieci ruchem danych. Współczesne sieci korporacyjne obsługują zarówno tradycyjny ruch danych jak i aplikacje czasu rzeczywistego, które wymagają niskich opóźnień i minimalnej utraty pakietów.Tradycyjne podejście typu best-effort nie zapewnia odpowiedniej jakości dla ruchu time-sensitive. Projekt wymaga wdrożenia zaawansowanych mechanizmów QoS (Quality of Service) obejmujących klasyfikację i markowanie ruchu, a także inteligentne zarządzanie kolejkami z wykorzystaniem mechanizmów LLQ (Low Latency Queuing) i CBWFQ (Class-Based Weighted Fair Queuing). Należy również skonfigurować Traffic Shaping dla dopasowania do łącza WAN oraz przeprowadzić pomiary parametrów jakości (jitter, opóźnienia, MOS) przed i po wdrożeniu QoS.

Na styku sieci lokalnej z WAN (łącze do ISP) pojawia się wąskie gardło, które powoduje wysoką utratę pakietów i znaczne opóźnienia szczególnie podczas jednoczesnego korzystania z telefonii VoIP i wysyłania dużych załączników e-mail. Pracownicy działu sprzedaży skarżą się na przerwania i zniekształcenia głosu podczas rozmów telefonicznych przez Internet, co negatywnie wpływa na wizerunek firmy przy kontaktach z klientami. Ruch VoIP konkuruje o dostępne pasmo z ruchem generowanym przez pozostałych pracowników, który w tym samym priorytecie powoduje opóźnienia przekraczające 150ms, co jest nieakceptowalne dla komunikacji głosowej. Wąskie gardło na styku z siecią WAN powoduje wysoką utratę pakietów w rozmowach głosowych podczas wysyłania dużych załączników e-mail. Należy wdrożyć mechanizmy QoS zapewniające priorytetowy dostęp do pasma dla ruchu VoIP (DSCP EF - Expedited Forwarding) kosztem ruchu o niższym priorytecie, niezależnie od obciążenia łącza. Ruch masowy (bulk data) powinien być kształtowany (shaped) do określonej przepustowości, aby nie zagłuszał ruchu krytycznego. Rekomendowana jest priorytetyzacja LLQ (Low Latency Queuing) dla ruchuVoIP.

Wąskie gardło na styku z siecią WAN powoduje wysoką utratę pakietów w rozmowach głosowych podczas wysyłania dużych załączników e-mail. Należy wdrożyć priorytetyzację Low Latency Queuing (LLQ).

• Klasyfikacja i markowanie ruchu (DSCP) na przełącznikach warstwy dostępu.
• Wdrożenie hierarchicznego QoS (HQoS) na routerach seryjnych lub WAN.
• Zastosowanie mechanizmu Traffic Shaping w celu unikania odrzutów na policerze ISP.
• Pomiary jittera i opóźnień przed i po wdrożeniu mechanizmów (np. za pomocą IP SLA).

1. Utworzyć topologię w GNS3: router brzegowy, przełącznik L3, serwer VoIP, hosty generujące ruch danych.
2. Skonfigurować adresy IP na interfejsach routera i przełącznika.
3. Na przełączniku warstwy dostępu skonfigurować VLANy dla VoIP (VLAN 10) i danych (VLAN 20).
4. Skonfigurować interfejsy dostępu z obsługą Voice VLAN (auto qos voip).
5. Na routerze utworzyć Class Map dla klasyfikacji ruchu (VoIP, Video, Data, Scavenger).
6. Skonfigurować Policy Map z LLQ dla ruchu VoIP i CBWFQ dla pozostałych klas.
7. Zastosować Service Policy na interfejsie WAN (outbound).
8. Skonfigurować Traffic Shaping dla dopasowania do łącza ISP (np. 10 Mbps).
9. Skonfigurować IP SLA dla monitorowania jittera i opóźnień do serwera VoIP.
10. Wygenerować ruch obciążeniowy (np. iperf) i zweryfikować kolejkowanie.
11. Przeprowadzić testy jakości VoIP (MOS) przed i po QoS.
12. Sprawdzić statystyki kolejek: show policy-map interface.
13. Zweryfikować markowanie DSCP na pakietach (Wireshark).

Klasyfikacja ruchu powinna odbywać się jak najbliżej źródła - na przełącznikach warstwy dostępu lub bezpośrednio na urządzeniach końcowych (np. telefon IP markuje ruch RTP jako DSCP EF). DSCP jest preferowanym mechanizmem markowania nad ToS, ponieważ ma więcej wartości i jest rozpoznawany w całym pathway sieci. LLQ dla VoIP jest implementowany jako kolejka priorytetowa z gwarantowanym pasmem - ruch VoIP jest obsługiwany natychmiast, bez czekania w kolejce. CBWFQ dla pozostałych klas gwarantuje minimalne pasmo, ale nie blokuje innych klas w przypadku niskiego ruchu. IP SLA jest wbudowanym mechanizmem monitorowania w Cisco, który generuje ruch UDP do serwera VoIP i mierzy jitter - wyniki powinny być porównane przed i po wdrożeniu QoS. Traffic Shaping powinien być ustawiony nieco niżej niż CIR (Committed Information Rate) od ISP, aby uniknąć odrzutów na policerze ISP (policing).

W3 SNMP, NTP, Syslog, W4 SIEM/SOAR.

Głównym celem projektu jest utworzenie centralnego punktu widoczności (visibility) infrastruktury sieciowej, który pozwala na zautomatyzowane wykrywanie anomalii zachowań i szybkie reagowanie na incydenty sieciowe. Współczesne centra danych i sieci korporacyjne składają się z dziesiątek lub setek urządzeń, co uniemożliwia skuteczny manualny monitoring. Projekt wymaga wdrożenia kompletnego systemu monitoringu obejmującego protokół SNMPv3 zapewniający bezpieczny (szyfrowany, uwierzytelniany) odczyt liczników urządzeń, system Syslog do centralnego gromadzenia logów ze wszystkich urządzeń w jednej bazie danych, serwer NTP do synchronizacji czasu dla zapewnienia poprawnej korelacji zdarzeń oraz opcjonalnie integrację z systemem SIEM do korelacji zdarzeń i generowania alertów. Efektem projektu ma być w pełni funkcjonalny system monitoringu pozwalający na proaktywne wykrywanie problemów i szybką reakcję na incydenty bezpieczeństwa.

Administratorzy sieci w firmie spędzają znaczną część czasu na ręczną diagnostykę urządzeń i logowanie do każdego z nich indywidualnie w celu sprawdzenia statusu. Dodatkowo gdy pojawia się problem, ustalenie jego przyczyny jest bardzo trudne, ponieważ logi są rozproszone po różnych urządzeniach i nie mają spójnej sygnatury czasu. Zarząd oczekuje wdrożenia systemu monitoringu, który zapewni centralny widok całej infrastruktury w jednym miejscu z alertami w czasie rzeczywistym. Należy więc wdrożyć SNMPv3 z szyfrowaniem AES i uwierzytelnianiem SHA dla bezpiecznego monitoringu, Syslog do centralizacji logów (Graylog, ELK lub rsyslog), serwer NTP dla spójnej sygnatury czasu oraz reguły alertów dla krytycznych zdarzeń (awaria łącza, błąd uwierzytelniania, przekroczenie progu wykorzystania). Całość powinna umożliwiać szybką diagnostykę i korelację zdarzeń w czasie.

• Konfiguracja serwera NTP i synchronizacja czasu w całej infrastrukturze.
• Wdrożenie SNMPv3 z szyfrowaniem AES i uwierzytelnianiem SHA.
• Uruchomienie serwera Syslog (np. Graylog lub ELK) i korelacja zdarzeń.
• Definicja progów alarmowych (traps) dla krytycznych zdarzeń (np. awaria łącza).

1. Utworzyć topologię w GNS3: router, przełącznik, serwer Syslog (np. Ubuntu z rsyslog lub Graylog).
2. Skonfigurować adresy IP na urządzeniach i zapewnić łączność do serwera Syslog.
3. Skonfigurować serwer NTP na routerze i synchronizację czasu na wszystkich urządzeniach.
4. Skonfigurować SNMPv3 z uwierzytelnianiem SHA i szyfrowaniem AES na przełączniku.
5. Utworzyć widoki SNMP (snmp-server view) i grupy (snmp-server group).
6. Skonfigurować użytkowników SNMPv3 z odpowiednimi uprawnieniami.
7. Skonfigurować przesyłanie logów do serwera Syslog (logging host x.x.x.x).
8. Ustawić poziomy logowania (logging trap level) dla różnych kategorii zdarzeń.
9. Skonfigurować SNMP Traps dla krytycznych zdarzeń (linkUp, linkDown, authFailure).
10. Zweryfikować działanie SNMP (snmpget).
11. Sprawdzić logi na serwerze Syslog.
12. Utworzyć prosty dashboard w Graylog lub ELK do wizualizacji zdarzeń.
13. Zdefiniować reguły korelacji zdarzeń (np. wielokrotne błędy auth = potencjalny atak).

Konfiguracja NTP jest kluczowa dla korelacji zdarzeń - wszystkie urządzenia muszą być zsynchronizowane do tego samego serwera NTP z tą samą strefą czasową. SNMPv3 wymaga właściwej konfiguracji zarówno na urządzeniu (użytkownik, grupa, widok), jak i na stacji zarządzającej (hasełko). Wersja priv (privacy) zapewnia szyfrowanie, authSHA lub authMD5 tylko uwierzytelniają. Dla Syslog zalecany jest protokół UDP na porcie 514 - jest prostszy i wydajniejszy od TCP dla logowania. Graylog oferuje prosty interfejs webowy do przeglądania logów, ale ELK (Elasticsearch, Logstash, Kibana) jest bardziej skalowalny. Przy definiowaniu alertów w SIEM należy unikać false positives - reguły powinny być oparte na powtarzających się zdarzeniach, a nie pojedynczych przypadkach. Trap SNMP jest wysyłany asynchronicznie do stacji zarządzającej, ale może być gubiony przy dużym obciążeniu - dlatego też należy również pollować (odpytywać) urządzenia periodycznie.

W1 Bezpieczeństwo portów, STP Guard, W2 ACL, filtrowanie.

Głównym celem projektu jest wzmocnienie odporności warstwy dostępowej sieci na różnego rodzaju ataki wewnętrzne, które stanowią najpoważniejsze zagrożenie w bezpieczeństwie sieciowym. Atakujący działający wewnątrz sieci (insider threat) lub osoba, która uzyskała dostęp do sieci lokalnej, może przeprowadzać ataki podszywania się pod bramę (ARP spoofing), generować pętle sieciowe powodujące przeciążenie, lub podłączyć nieautoryzowany sprzęt. Projekt wymaga wdrożenia kompletnej strategii Defense in Depth obejmującej Port Security zapobiegający nieautoryzowanemu dostępowi do portów, DHCP Snooping i Dynamic ARP Inspection chroniące przed atakiem na warstwie 2, oraz zabezpieczenia STP (BPDU Guard, Root Guard) chroniące przed manipulacją drzewem rozpinającym. Efektem projektu ma być w pełni zabezpieczona warstwa dostępowa minimalizująca ryzyko ataków wewnętrznych.

W biurze typu open space, gdzie dostęp do gniazdek sieciowych mają zarówno pracownicy, jak i goście, regularnie zdarzają się próby podłączenia nieautoryzowanych urządzeń - pracownicy chcą podłączyć własny router nebo access point, a goście próbują uzyskać dostęp do wewnętrznej sieci. Dodatkowo pojawiły się podejrzane zachowania wskazujące na próby ARP spoofing - odnotowano przypadki, gdzie tablice ARP wskazywały na nieprawidłowe adresy MAC dla bramy, co może wskazywać na atak typu man-in-the-middle. Należy więc wdrożyć zabezpieczenia Port Security z limitowaniem adresów MAC i akcją shutdown przy naruszeniu, DHCP Snooping do budowania tablicy zaufanych urządzeń, DAI do weryfikacji zgodności adresów ARP z tablicą DHCP Snooping, oraz BPDU Guard na portach dostępowych, aby zapobiec wpięciu nieautoryzowanego przełącznika przejmującego rolę root bridge.

• Port Security (Sticky MAC) z blokadą portu po naruszeniu.
• Wdrożenie DHCP Snooping i Dynamic ARP Inspection (DAI).
• Zabezpieczenie drzewa rozpinającego (BPDU Guard, Root Guard).
• Konfiguracja list kontroli dostępu ACL na interfejsach SVI.

1. Utworzyć topologię w GNS3: przełącznik L2 z portami dostępu, router brzegowy.
2. Skonfigurować VLANy: VLAN 10 (serwery), VLAN 20 (użytkownicy), VLAN 99 (management).
3. Skonfigurować Port Security na portach dostępu z limitowaniem do 3 adresów MAC.
4. Włączyć Sticky MAC dla automatycznego uczenia się adresów.
5. Skonfigurować akcję przy naruszeniu (shutdown lub restrict).
6. Skonfigurować DHCP Snooping na przełączniku (zaufane porty, niezaufane porty).
7. Skonfigurować Dynamic ARP Inspection (DAI) na VLANach.
8. Skonfigurować BPDU Guard na portach dostępu (portfast).
9. Skonfigurować Root Guard na portach gdzie nie powinien być root bridge.
10. Utworzyć ACL na SVI routera dla filtrowania ruchu między VLANami.
11. Przetestować atak ARP Spoofing - uruchomić atak i sprawdzić logi.
12. Zweryfikować tablice: show port-security, show ip dhcp snooping, show ip arp inspection.

Port Security z opcją sticky MAC automatycznie zapisuje dopuszczone adresy MAC do konfiguracji startowej, co upraszcza wdrożenie na wielu portach. Tryb violation restrict loguje naruszenia, ale nie blokuje portu (zalecany w produkcji), shutdown natychmiast wyłącza port (bardziej restrycyjny). DHCP Snooping musi mieć wskazany port zaufany (trusted) - zwykle do routera brzegowego, porty dostępowe muszą być niezaufane (untrusted). DAI działa tylko na VLAN objętych DHCP Snooping, ponieważ wykorzystuje tablicę Binding do weryfikacji. BPDU Guard jest konieczny dla portów dostępowych z włączonym PortFast - bez niego podłączenie switcha spowoduje pętlę lub zmianę root bridge. Root Guard chroni przed próbami "przejęcia" roli root bridge przez atakującego na sąsiednim porcie. ACL na SVI mogą filtrować ruch między VLANami, ale najpierw należy upewnić się, że routing między VLANami jest prawidłowo skonfigurowany.

W2 BGP, VPN, NAT, W4 Architektury VPC/Cloud.

Głównym celem projektu jest budowa skalowalnego i bezpiecznego połączenia między lokalnym centrum danych (on-premise) a publiczną chmurą obliczeniową (AWS, Azure lub GCP), które zapewni bezpieczną wymianę danych i dynamiczny routing między infrastrukturami. Coraz więcej firm migruje częściowo swoje zasoby do chmury hybrydowej, co wymaga bezpiecznego i wydajnego połączenia. Projekt obejmuje konfigurację tunelu VPN typu Site-to-Site z wykorzystaniem IPsec z silnymi algorytmami szyfrowania, wdrożenie sesji BGP między lokalnym routerem a bramą chmurową dla dynamicznej wymiany tras oraz zaprojektowanie wirtualnej sieci prywatnej (VPC) z odpowiednim podziałem na podsieci publiczne i prywatne. Dodatkowo należy zdefiniować polityki bezpieczeństwa (Security Groups, Firewall) kontrolujące ruch między lokalnym centrum danych a chmurą.

Firma prowadzi stopniową migrację części zasobów (bazy danych, serwery aplikacji) do chmury publicznej, co wymaga bezpiecznego i wydajnego połączenia z infrastrukturą lokalną. Aktualnie połączenie odbywa się przez zwykły VPN przez Internet, co jest niewystarczające dla krytycznych systemów biznesowych ze względu na zmienną jakość i potencjalne zagrożenia bezpieczeństwa. Zarząd oczekuje wdrożenia stałego, szyfrowanego połączenia typu Site-to-Site z wykorzystaniem IPsec, które zapewni bezpieczny tunneling ruchu między lokalnym centrum danych a VPC w chmurze. Dodatkowo wymagana jest dynamiczna wymiana tras za pomocą protokołu BGP, aby routery lokalne mogły automatycznie "widzieć" podsieci chmurowe i kierować do nich ruch bez manualnej konfiguracji tras statycznych. Połączenie musi obsługiwać ruch w obie strony z odpowiednimi zasadami bezpieczeństwa.

• Zaprojektowanie wirtualnej sieci prywatnej (VPC) w chmurze z odpowiednim podziałem na podsieci.
• Konfiguracja tunelu IPsec VTI z silnymi algorytmami szyfrowania (np. IKEv2).
• Wdrożenie sesji BGP pieringującej lokalny ruter z bramą chmurową.
• Przygotowanie polityk Firewall/Security Groups kontrolujących ruch między środowiskami.

1. Utworzyć topologię w GNS3: router lokalny (Cisco), maszyna z bramą chmurową, serwer lokalny.
2. Skonfigurować adresy IP na routerze lokalnym i interfejsie chmurowym.
3. Skonfigurować tunel IPsec Site-to-Site między lokalnym routerem a bramą chmurową.
4. Skonfigurować IKEv2 z silnymi algorytmami (AES256, SHA256, DH Group 14).
5. Skonfigurować transform-set i crypto map dla IPsec.
6. Skonfigurować sesję BGP między lokalnym routerem a bramą chmurową (ASN prywatne).
7. Utworzyć VPC w chmurze z podsieciami: Public-Subnet, Private-Subnet.
8. Skonfigurować Security Groups dla ruchu między lokalnym centrum danych a chmurą.
9. Zweryfikować ustanowienie tunelu IPsec (show crypto ipsec sa).
10. Sprawdzić sąsiedztwo BGP (show ip bgp neighbor).
11. Przetestować łączność z podsiecią chmurową (ping, traceroute).

Adresy IP po stronie tunelu IPsec mogą być dowolne z przestrzeni RFC 1918 - tunel jest enkapsulowany w UDP/IP. IKEv2 jest preferowany nad IKEv1 ze względu na lepszą obsługę mobilności (rekeying). Transform-set określa algorytmy szyfrowania i integralności - ESP-AES256 + ESP-SHA-HMAC jest uznawany za bezpieczny. Crypto map musi być przypisany do interfejsu zewnętrznego (WAN). BGP przez VPN wymaga osobnego neighbor na interfejsie Tunnel lub bezpośrednio przez VTI. Numery ASN po obu stronach muszą być różne dla eBGP - dla chmury używa się ASN z zakresu 64512-65534 dla AWS, 65536 dla Azure. Security Groups w chmurze są stanowe - zezwolenie na ruch wychodzący automatycznie zezwala na ruch przychodzący. Weryfikacja tunelu: show crypto ipsec sa pokazuje liczniki pakietów zaszyfrowanych/deszyfrowanych. Peer BGP musi być dostępny przez tunel IPsec - test ping przez Tunnel0.