Menu Główne 1. Wstęp 2. GRE/PPTP 3. SSTP/L2TP/IPSec L2TP/IPSec 4. OpenVPN 5. Routing 6. VLAN 7. Bezpieczeństwo
1/40 Część 5: Routing w tunelach - fundamenty przepływu danych
Przedstawienie roli i zasad implementacji mechanizmów routingu pakietów w wirtualnych sieciach prywatnych oraz omówienie struktury modułu dydaktycznego.
  • Samo skuteczne zestawienie tunelu VPN (np. GRE czy OpenVPN) to dopiero połowa drogi do sukcesu.
  • Tunel można porównać do "kabla" - to router musi zdecydować, jakie dane w niego skierować.
  • Mechanizmy routingu determinują, czy pakiet trafi do odległego oddziału, czy do publicznego Internetu.
  • Błędy w tablicy routingu to najczęstsza przyczyna zgłoszeń typu: "Tunel jest aktywny (UP), ale brak komunikacji".
Routing w tunelach VPN: Proces wyznaczania ścieżki i przekazywania pakietów sieciowych pomiędzy odległymi węzłami z wykorzystaniem logicznych interfejsów tunelowych, łączący mechanizmy enkapsulacji z tablicami routingu warstwy 3.
Slide 1

Zestawienie wirtualnego tunelu VPN stanowi zaledwie pierwszy krok do stworzenia funkcjonalnego połączenia pomiędzy odległymi lokalizacjami sieciowymi. Sam interfejs tunelowy działa jak wirtualny przewód łączący dwa punkty lub węzły wielopunktowe, lecz bez odpowiedniej konfiguracji tablicy routingu pakiety generowane przez stacje robocze i serwery nie będą kierowane do nowo powstałego kanału transmisyjnego. Szczegółowe informacje normatywne i techniczne publikuje Specyfikacja wymagań dla routerów IPv4 (RFC 1812).

W architekturze sieci teleinformatycznych wyróżnia się dwie fundamentalne warstwy: warstwę transportową podkładową (Underlay Network), odpowiedzialną za fizyczne dostarczenie enkapsulowanych datagramów pomiędzy publicznymi adresami IP bram, oraz warstwę nakładkową (Overlay Network), reprezentującą logiczną topologię prywatną. Poprawne zdefiniowanie relacji routingu pomiędzy tymi warstwami jest warunkiem bezwzględnym stabilnej wymiany danych.

Podczas projektowania routingu w tunelach inżynier sieciowy staje przed wyborem pomiędzy routingiem statycznym a dynamicznymi protokołami wektora odległości lub stanu łącza. Decyzja ta zależy od skali sieci, liczby oddziałów, zmienności topologii oraz wymagań dotyczących redundancji i automatycznego przełączania ruchu w przypadku awarii jednego z operatorów telekomunikacyjnych.

W niniejszym module laboratoryjnym przeanalizowane zostaną szczegółowo mechanizmy tras statycznych, protokołu OSPFv2/OSPFv3 w tunelach, zapobieganie pętlom routingu, izolacja ruchu za pomocą VRF oraz polityki Policy Based Routing. Standardy routingu pakietów IPv4 definiuje oficjalna specyfikacja IETF RFC 1812.

Wyjaśnienie skrótów użytych na slajdzie:
VPN - Virtual Private Network - Wirtualna sieć prywatna.
OSPF - Open Shortest Path First - Protokół stanu łącza do wewnętrznego trasowania pakietów.
VRF - Virtual Routing and Forwarding - Technologia wirtualizacji tablic routingu w obrębie jednego routera.
PBR - Policy Based Routing - Routing oparty na politykach i regułach zapory sieciowej.
IP - Internet Protocol - Protokół warstwy sieciowej modelu OSI/ISO.

2/40 Interfejsy punkt-punkt (Point-to-Point)
Wyjaśnienie charakterystyki interfejsów wirtualnych typu Point-to-Point oraz zasad adresacji łącza tunelowego bez wykorzystania protokołu ARP.
  • Większość technologii VPN tworzy interfejsy logiczne typu P2P.
  • Różnica względem Ethernetu: brak adresu rozgłoszeniowego (Broadcast).
  • Struktura opiera się na parze: Adres lokalny oraz Adres zdalny (Remote Address).
  • W tablicy routingu trasy wskazują najczęściej bezpośrednio na nazwę interfejsu lub IP punktu końcowego.
  • System RouterOS oznacza takie trasy flagami DAC (Dynamic Active Connected).
Interfejs Punkt-Punkt (Point-to-Point - P2P): Logiczny interfejs sieciowy łączący dokładnie dwa węzły transmisyjne, w którym każdy wysłany pakiet trafia bezpośrednio do jedynego odbiorcy na drugim końcu kanału, eliminując potrzebę rozgłoszeń ARP.
Slide 2

Większość technologii tunelowania warstwy 3 (takich jak GRE, IPIP, PPTP, L2TP czy interfejsy tunelowe OpenVPN w trybie TUN) tworzy w systemie operacyjnym interfejsy sieciowe o charakterystyce Punkt-Punkt. W przeciwieństwie do tradycyjnych interfejsów Ethernetowych (Broadcast Multi-Access), interfejs P2P nie posiada adresu warstwy łącza danych MAC ani nie obsługuje zapytań protokołu Address Resolution Protocol (ARP). Szczegółowe informacje normatywne i techniczne publikuje Standard masek 31-bitowych na łączach Point-to-Point (RFC 3021).

Każdy datagram skierowany przez tablicę routingu na interfejs typu Punkt-Punkt jest bezwarunkowo enkapsulowany i przesyłany do zdalnego punktu końcowego tunelu. W systemach Linux i MikroTik RouterOS interfejs taki identyfikowany jest flagą POINTTOPOINT i wymaga podania adresu lokalnego oraz adresu odległego partnera (tzw. remote address).

W nowoczesnych sieciach inżynierowie powszechnie stosują na łączach punkt-punkt podsieci o maskach 31-bitowych (/31) zgodnie z RFC 3021, co eliminuje marnotrawstwo adresów na adres sieci i broadcast, lub korzystają z konfiguracji bezadresowej (Unnumbered Interface), pożyczającej adres IP z interfejsu Loopback.

Zrozumienie specyfiki interfejsów P2P jest kluczowe dla poprawnej konfiguracji routingu. Wpisując trasę statyczną do odległej podsieci za tunelem, administrator może wskazać bezpośrednio nazwę interfejsu wyjściowego (np. gateway=gre-tunnel1) zamiast konkretnego adresu IP następnego skoku (Next-Hop IP).

Wyjaśnienie skrótów użytych na slajdzie:
P2P - Point-to-Point - Model komunikacji bezpośredniej pomiędzy dwoma węzłami.
ARP - Address Resolution Protocol - Protokół odwzorowywania adresów IP na adresy fizyczne MAC.
MAC - Media Access Control - Adres sprzętowy warstwy łącza danych.
GRE - Generic Routing Encapsulation - Protokół hermetyzacji pakietów dowolnego protokołu w pakietach IP.

3/40 Metoda klasyczna: routing statyczny
Przedstawienie zasad projektowania i wdrażania tras statycznych w celu kierowania ruchu prywatnego do odległych sieci przez tunele VPN.
  • Polega na ręcznym definiowaniu tras przez administratora.
  • Scenariusz: Biuro A (192.168.1.0/24) ↔ Biuro B (192.168.2.0/24).
  • Router A: dst-address=192.168.2.0/24 gateway=Tunel-do-B.
  • Router B: dst-address=192.168.1.0/24 gateway=Tunel-do-A.
  • Zalety: Pełna przewidywalność, brak narzutu na procesor, prostota w małych sieciach.
  • Wady: Trudne zarządzanie przy dużej liczbie węzłów, brak automatycznej reakcji na awarie łącza.
Routing statyczny: Ręczne definiowanie reguł przekazywania pakietów w tablicy routingu przez administratora sieci, określających prefiks sieci docelowej oraz adres następnego skoku lub interfejs wyjściowy.
Slide 3

Routing statyczny jest najbardziej elementarną i powszechnie stosowaną metodą kierowania ruchu przez wirtualne tunele sieciowe w małych i średnich wdrożeniach. Polega na ręcznym dodaniu do tablicy routingu (FIB/RIB) reguły informującej router, że w celu dotarcia do podsieci prywatnej odległego oddziału (np. 192.168.20.0/24) pakiety muszą zostać skierowane na wirtualny adres IP bramy oddziału lub bezpośrednio na interfejs tunelowy. Szczegółowe informacje normatywne i techniczne publikuje Protokół internetowy IPv4 (RFC 791).

W systemie MikroTik RouterOS dodanie trasy realizuje się poleceniem w gałęzi IP Route: /ip route add dst-address=192.168.20.0/24 gateway=10.0.0.2. W systemach z jądrem Linux odpowiada temu polecenie pakietu iproute2: ip route add 192.168.20.0/24 via 10.0.0.2 dev tun0. Trasa taka posiada domyślny dystans administracyjny równy 1, co oznacza wysoki priorytet zaufania.

Główną zaletą routingu statycznego jest jego absolutna prostota, brak narzutu procesora na przeliczanie algorytmów trasowania oraz całkowity brak ruchu sygnalizacyjnego na łączu WAN. W małych sieciach typu Site-to-Site z pojedynczym tunelem stanowi on optymalne, niezawodne i wysoce przewidywalne rozwiązanie inżynierskie.

Ograniczeniem tras statycznych jest brak automatycznej adaptacji do zmian w strukturze połączeń. W przypadku awarii tunelu trasa statyczna może pozostać aktywna w tablicy (tzw. zjawisko trasy czarnej dziury), kierując pakiety w nicość, chyba że zostanie powiązana z mechanizmem monitorowania dostępności bramy lub rekurencyjnym sprawdzaniem ścieżki.

Wyjaśnienie skrótów użytych na slajdzie:
FIB - Forwarding Information Base - Baza informacji o przekazywaniu pakietów używana przez procesor sieciowy.
RIB - Routing Information Base - Baza informacyjna routingu zawierająca wszystkie wyuczone trasy.
WAN - Wide Area Network - Rozległa sieć telekomunikacyjna.
CLI - Command Line Interface - Tekstowy interfejs wiersza poleceń.

4/40 Mechanizm Check Gateway (monitorowanie bramy)
Analiza mechanizmów detekcji awarii łączy tunelowych i dynamicznego unieważniania tras statycznych za pomocą technologii Check Gateway i routingu rekurencyjnego.
  • Problem inżynierski: Wirtualny interfejs tunelowy może utrzymywać stan Link UP, podczas gdy w fizycznej sieci operatora ISP nastąpiła utrata pakietów (powstanie tzw. czarnej dziury - Blackhole).
  • Podstawowy mechanizm Check Gateway:
    • Router wysyła zapytania ICMP Echo Request do zadeklarowanego adresu bramy co 10 sekund; brak 2 odpowiedzi wycofuje trasę z tablicy FIB.
    • Składnia: /ip route add dst-address=192.168.20.0/24 gateway=10.0.0.2 check-gateway=ping
  • Krytyczne ograniczenie i rozwiązanie zaawansowane - Routing rekurencyjny:
    • Standardowy Check Gateway bada wyłącznie bezpośredni następny skok (Next-Hop IP), co na łączach wirtualnych jest niewystarczające do weryfikacji dostępności całego toru transmisyjnego (End-to-End).
    • W celu badania faktycznej łączności ze światem inżynierowie konfigurują routing rekurencyjny w RouterOS, tworząc statyczne trasy hostowe do publicznych serwerów referencyjnych (np. 1.1.1.1 lub 8.8.8.8) z parametrem scope=10 i trasę domyślną z target-scope=11.
Mechanizm Check Gateway: Wbudowana funkcja systemu operacyjnego routera (np. MikroTik RouterOS) okresowo weryfikująca osiągalność bramy domyślnej lub następnego skoku za pomocą sond ICMP Echo Request lub ARP.
Slide 4

W sieciach korporacyjnych częstym problemem jest sytuacja, w której wirtualny interfejs tunelowy zachowuje status Link Up (np. tunel GRE lub IPIP), podczas gdy fizyczne łącze internetowe u operatora uległo awarii lub nastąpiła utrata pakietów w szkielecie ISP. W takiej sytuacji klasyczna trasa statyczna pozostaje w tablicy routingu, powodując powstawanie 'czarnej dziury' (Blackhole) i utratę łączności z oddziałem. Szczegółowe informacje normatywne i techniczne publikuje Dokumentacja routingu IP i recursive routing w MikroTik RouterOS.

W systemie MikroTik RouterOS mechanizm Check Gateway pozwala na automatyczne monitorowanie bramy trasy statycznej poprzez dodanie parametru check-gateway=ping lub check-gateway=arp. Router wysyła do adresu bramy pakiety kontrolne ICMP co 10 sekund; w przypadku braku odpowiedzi na dwa kolejne zapytania trasa zostaje automatycznie oznaczona flagą 'unreachable' i wycofana z tablicy FIB.

Wycofanie nieaktywnej trasy pozwala na natychmiastowe uaktywnienie alternatywnej trasy zapasowej o wyższej wartości dystansu administracyjnego (np. przez zapasowe łącze komórkowe LTE lub drugiego operatora ISP). Po powrocie odpowiedzi ICMP trasa podstawowa jest bezzwłocznie przywracana do obsługi ruchu produkcyjnego.

W przypadku tuneli wielohopowych lub konieczności badania spójności całej ścieżki transmisyjnej (End-to-End) standardowy Check Gateway ograniczony do sąsiedniego IP może okazać się niewystarczający. Wówczas inżynierowie konfigurują tzw. routing rekurencyjny w RouterOS, sprawdzający dostępność publicznych serwerów referencyjnych (np. 1.1.1.1 lub 8.8.8.8) przez konkretny interfejs z wykorzystaniem parametrów scope i target-scope.

Wyjaśnienie skrótów użytych na slajdzie:
ICMP - Internet Control Message Protocol - Protokół komunikatów kontrolnych w sieciach IP.
ISP - Internet Service Provider - Dostawca usług internetowych.
LTE - Long Term Evolution - Standard bezprzewodowej transmisji danych sieci komórkowych.
FIB - Forwarding Information Base - Aktywna tablica przekazywania pakietów w pamięci routera.

5/40 Priorytety tras: parametr Distance
Przedstawienie zasad funkcjonowania dystansu administracyjnego (Distance) jako kryterium wyboru najbardziej wiarygodnej trasy w tablicy routingu.
  • Możliwość definiowania łączy podstawowych i zapasowych (np. Główny L2TP ↔ Zapasowy OpenVPN).
  • Distance (Dystans administracyjny) określa stopień zaufania do trasy (np. statyczna: 1, OSPF: 110).
  • Trasa o niższym dystansie (np. 1) jest zawsze wybierana jako pierwsza.
  • Trasa zapasowa (np. distance 10) zostaje aktywowana dopiero, gdy trasa o niższym dystansie zniknie z tablicy routingu.
Dystans administracyjny (Administrative Distance): Numeryczna miara wiarygodności źródła informacji o trasie w systemie operacyjnym routera, wykorzystywana do wyboru trasy aktywnej w przypadku otrzymania informacji o tym samym prefiksie z różnych protokołów.
Slide 5

W złożonych strukturach sieciowych router może otrzymywać informacje o ścieżce dotarcia do tej samej podsieci docelowej z wielu niezależnych źródeł: z konfiguracji statycznej, protokołu OSPF, BGP czy połączeń dynamicznych VPN. Do rozstrzygnięcia, która trasa powinna zostać zainstalowana w aktywnej tablicy przekazywania FIB, służy parametr dystansu administracyjnego (Distance). Szczegółowe informacje normatywne i techniczne publikuje Specyfikacja protokołu RIP Version 2 (RFC 1723).

Zasada działania dystansu jest jednoznaczna: im niższa wartość liczbowa parametru Distance, tym wyższa wiarygodność trasy i wyższy priorytet jej instalacji w tablicy routingu. Trasy połączone bezpośrednio (Connected) posiadają dystans równy 0, klasyczne trasy statyczne posiadają dystans 1, trasy protokołu OSPF posiadają dystans 110, trasy protokołu RIP posiadają dystans 120, natomiast sesje eBGP dystans 20.

W kontekście redundancji tuneli VPN parametr Distance stanowi podstawę budowy mechanizmu 'Floating Static Route'. Administrator konfiguruje trasę główną przez szybki tunel światłowodowy z dystansem 1, a trasę zapasową przez tunel zapasowy z dystansem 10. Dopóki trasa główna jest aktywna, cały ruch płynie tunelem szybkim; w momencie wykrycia awarii przez Check Gateway trasa z dystansem 10 automatycznie przejmuje ruch.

Wartości domyślne dystansu i metryk tras opisują wytyczne protokołów trasowania wewnętrznego, w tym oficjalny standard IETF RFC 1723 dla protokołu RIP v2.

Wyjaśnienie skrótów użytych na slajdzie:
BGP - Border Gateway Protocol - Protokół bramy zewnętrznej służący do wymiany tras miedzy systemami autonomicznymi.
RIP - Routing Information Protocol - Historyczny protokół wektora odległości.
eBGP - External Border Gateway Protocol - Sesja protokołu BGP pomiędzy różnymi systemami autonomicznymi AS.
FIB - Forwarding Information Base - Struktura danych przekazywania pakietów w jadre routera.

6/40 Tunelowanie dzielone (Split Tunneling): optymalizacja pasma
Charakterystyka architektury Split Tunneling, analiza zysków wydajnościowych oraz identyfikacja ryzyk związanych z omijaniem firmowych systemów bezpieczeństwa.
  • Technika rozdzielania ruchu użytkownika zdalnego.
  • Do tunelu kierowany jest wyłącznie ruch do zasobów firmowych (np. 10.0.0.0/8).
  • Ruch prywatny (YouTube, media społecznościowe) omija VPN i wychodzi bezpośrednio przez bramę domową użytkownika.
  • Zaleta: Oszczędność przepustowości łącza w centrali firmy.
  • Wada: Brak możliwości filtrowania i kontroli całości ruchu pracownika (ryzyko infekcji).
Tunelowanie dzielone (Split Tunneling): Konfiguracja połączenia VPN klienta lub oddziału, w której wyłącznie ruch skierowany do ściśle określonych zasobów korporacyjnych jest przesyłany tunelem, podczas gdy pozostały ruch internetowy trafia bezpośrednio do lokalnego łącza ISP.
Slide 6

W scenariuszach pracy zdalnej (Road Warrior) oraz połączeń oddziałowych Site-to-Site kluczową decyzją architektoniczną jest podział strumienia pakietów generowanych przez użytkowników. W modelu Split Tunneling na stacji roboczej klienta instalowane są trasy statyczne wskazujące wyłącznie wewnętrzne podsieci przedsiębiorstwa (np. 10.0.0.0/8 lub 192.168.0.0/16) przez interfejs VPN, natomiast trasa domyślna (0.0.0.0/0) pozostaje skierowana na lokalny router domowy lub hotelowy. Szczegółowe informacje normatywne i techniczne publikuje Opcja 121 protokołu DHCP dla tras statycznych (RFC 3442).

Główną zaletą architektury Split Tunneling jest radykalna redukcja obciążenia łącza internetowego w centrali firmy. Ruch multimedialny o wysokim zapotrzebowaniu na pasmo, taki jak wideokonferencje, strumieniowanie wideo czy pobieranie aktualizacji systemowych, jest kierowany bezpośrednio do sieci publicznej, nie obciążając brzegowych bram VPN ani procesorów urządzeń centralnych.

Krytycznym mankamentem tego podejścia jest obniżenie poziomu bezpieczeństwa stacji roboczych. Komputer użytkownika z aktywnym Split Tunneling staje się urządzeniem dwudomnym (Dual-Homed Host). Jeśli stacja zostanie zainfekowana szkodliwym oprogramowaniem z niezabezpieczonej sieci lokalnej, komputer może posłużyć intruzowi jako pomost tranzytowy do nieautoryzowanej penetracji zasobów wewnątrz chronionej sieci firmowej.

W celu automatycznego rozgłaszania tras w architekturze Split Tunneling wykorzystuje się opcję 121 protokołu DHCP (Classless Static Route Option) zdefiniowaną w standardzie IETF RFC 3442.

Wyjaśnienie skrótów użytych na slajdzie:
DHCP - Dynamic Host Configuration Protocol - Protokół dynamicznej konfiguracji parametrów sieciowych stacji.
ISP - Internet Service Provider - Operator świadczący usługę dostępu do Internetu.
VPN - Virtual Private Network - Wirtualna sieć prywatna.
LAN - Local Area Network - Lokalna sieć komputerowa.

7/40 Pełne tunelowanie (Full Tunneling): maksymalne bezpieczeństwo
Przedstawienie koncepcji Full Tunneling, wymuszenia inspekcji ruchu przez centralną zaporę ogniową oraz implikacji dla przepustowości węzła centralnego.
  • Wymuszenie, aby CAŁY ruch ze stacji roboczej przechodził przez infrastrukturę firmy.
  • Trasa domyślna (0.0.0.0/0) zostaje skierowana do tunelu.
  • Wymaga poprawnej konfiguracji NAT (Masquerade) na routerze brzegowym w biurze.
  • Standard w korporacjach dbających o zapobieganie wyciekom danych (DLP) oraz przy korzystaniu z niepewnych sieci publicznych.
Pełne tunelowanie (Full Tunneling): Polityka sieciowa wymuszająca przekierowanie całości generowanego ruchu (w tym zapytań do Internetu i zapytań DNS) przez wirtualny tunel VPN do centralnej bramy bezpieczeństwa.
Slide 7

W środowiskach o rygorystycznych wymaganiach w zakresie cyberbezpieczeństwa (np. sektor bankowy, administracja publiczna, infrastruktura krytyczna) powszechnie wdraża się model Full Tunneling. W tym wariancie cała aktywność sieciowa zdalnego pracownika lub całego oddziału jest bezwzględnie kierowana do centrali za pośrednictwem wirtualnego interfejsu tunelowego. Szczegółowe informacje normatywne i techniczne publikuje Alokacja prywatnych przestrzeni adresowych IPv4 (RFC 1918).

Wymuszenie Full Tunneling pozwala na poddanie całego ruchu wychodzącego z urządzeń użytkowników rygorystycznej inspekcji przez centralne zapory sieciowe nowej generacji (NGFW), systemy wykrywania i zapobiegania włamaniom (IDS/IPS), serwery proxy z filtrowaniem treści oraz skanery antywirusowe. Centralizacja ta eliminuje ryzyko bezpośrednich ataków z sieci lokalnych, w których tymczasowo przebywa użytkownik.

Dodatkowo Full Tunneling rozwiązuje problem wycieków zapytań domenowych (DNS Leaks). Wszelkie translacje nazw domenowych są realizowane wyłącznie przez wewnętrzne serwery DNS w chronionej strefie DMZ centrali, co chroni przed profilowaniem zachowań pracowników przez lokalnych operatorów telekomunikacyjnych.

Ceną za maksymalne bezpieczeństwo jest wymóg posiadania bardzo wydajnych łączy internetowych w centrali oraz silnych jednostek sprzętowych zdolnych do równoczesnego deszyfrowania, inspekcji i powtórnego szyfrowania ruchu setek lub tysięcy sesji. Przydział prywatnych bloków adresowych dla struktur korporacyjnych reguluje standard RFC 1918.

Wyjaśnienie skrótów użytych na slajdzie:
NGFW - Next-Generation Firewall - Zapora sieciowa nowej generacji z głęboka inspekcja pakietów.
IDS - Intrusion Detection System - System wykrywania nieautoryzowanych intruzji w sieci.
IPS - Intrusion Prevention System - System aktywnego blokowania ataków sieciowych.
DMZ - Demilitarized Zone - Strefa zdemilitaryzowana dla publicznie dostępnych usług serwerowych.

8/40 Pętla routingu w pełnym tunelowaniu (Full Tunneling)
Szczegółowa analiza pułapki zapętlenia routingu przy próbie nadpisania trasy domyślnej oraz inżynierskie metody eliminacji problemu za pomocą tras /1 i tras hostowych /32.
  • Mechanizm powstania pętli: Zastąpienie dotychczasowej trasy domyślnej 0.0.0.0/0 bramą wewnątrz tunelu VPN powoduje, że pakiet transportowy niosący zaszyfrowany ładunek zostaje skierowany z powrotem do wirtualnego interfejsu, wywołując natychmiastowe zerwanie łączności.
  • Inżynierskie metody eliminacji pętli:
  • 1. Trasa hostowa /32: Dodanie bezwzględnej trasy hostowej do publicznego IP serwera VPN wskazującej lokalną fizyczną bramę dostawcy ISP przed zmianą trasy domyślnej.
  • 2. Mechanizm dwóch tras /1 (technika OpenVPN redirect-gateway def1):
    • Zamiast usuwać lub modyfikować trasę 0.0.0.0/0, instaluje się w tablicy routingu dwie specyficzne trasy:
  • * 0.0.0.0/1 (zakres 0.0.0.0 - 127.255.255.255)
  • * 128.0.0.0/1 (zakres 128.0.0.0 - 255.255.255.255)
    • Zgodnie z fundamentalną regułą Longest Prefix Match (RFC 4632) procesor sieciowy wybiera trasy z maską /1 dla całego ruchu użytkownika, podczas gdy fizyczna łączność z serwerem VPN jest realizowana przez pierwotną bramę lokalną.
Pętla routingu w tunelu (VPN Routing Loop): Błąd logiczny konfiguracji tablicy routingu, w którym pakiety transportowe niosące zaszyfrowany ładunek tunelu zostają skierowane z powrotem do wnętrza tego samego wirtualnego interfejsu, powodując natychmiastowe załamanie łączności.
Slide 8

Podczas konfiguracji pełnego tunelowania najczęstszym i najbardziej krytycznym błędem popełnianym przez początkujących administratorów jest bezmyślna zamiana dotychczasowej trasy domyślnej (0.0.0.0/0 gateway=lokalny_router) na trasę wskazującą bramę tunelu (0.0.0.0/0 gateway=tunel_vpn). W momencie wykonania tej zmiany dochodzi do natychmiastowego zerwania połączenia z serwerem VPN. Szczegółowe informacje normatywne i techniczne publikuje Bezklasowy routing międzydomenowy CIDR i dopasowanie najdłuższego prefiksu (RFC 4632).

Mechanizm awarii wynika z faktu, że aby przesłać wirtualny pakiet, router musi wysłać zewnętrzny fizyczny datagram (np. UDP 1194 dla OpenVPN lub UDP 4500 dla IPsec) do publicznego adresu IP serwera. Jeśli trasa domyślna wskazuje na wnętrze tunelu, router próbuje wysłać ten zewnętrzny pakiet do wirtualnego interfejsu, którego działanie zależy od wysłania owego pakietu. Następuje logiczne zapętlenie i całkowity krach komunikacji.

W celu zapobieżenia temu zjawisku stosuje się bezwzględnie jedną z dwóch technik inżynierskich. Pierwsza polega na dodaniu przed zmianą trasy domyślnej jawnej trasy hostowej o masce 32-bitowej (/32) do publicznego adresu IP serwera VPN, wskazującej lokalną fizyczną bramę dostawcy ISP.

Druga technika, spopularyzowana przez oprogramowanie OpenVPN pod nazwą 'redirect-gateway def1', polega na pozostawieniu pierwotnej trasy domyślnej 0.0.0.0/0 i zainstalowaniu dwóch specyficznych tras obejmujących dokładnie całą przestrzeń adresową: 0.0.0.0/1 oraz 128.0.0.0/1. Zgodnie z zasadą Longest Prefix Match (RFC 4632) procesor sieciowy wybiera trasy /1, kierując ruch do tunelu, podczas gdy trasa fizyczna /32 lub zapytanie do serwera korzysta z lokalnego połączenia.

Wyjaśnienie skrótów użytych na slajdzie:
LPM - Longest Prefix Match - Algorytm wyboru trasy o najdłuższej masce podsieci w tablicy routingu.
UDP - User Datagram Protocol - Bezpołączeniowy protokół warstwy transportowej.
ISP - Internet Service Provider - Lokalny operator dostępowy stacji roboczej.
IP - Internet Protocol - Protokół warstwy sieciowej.

9/40 Zastosowanie OSPF w strukturach VPN
Przedstawienie korzyści z zastosowania protokołu dynamicznego trasowania stanu łącza OSPF w rozbudowanych wielooddziałowych sieciach VPN.
  • W miarę wzrostu liczby oddziałów (powyżej 3-5), routing statyczny staje się nieefektywny.
  • OSPF (Open Shortest Path First): Automatycznie wykrywa zmiany w topologii sieci.
  • Dodanie nowej podsieci w odległym oddziale skutkuje niemal natychmiastową aktualizacją tablic routingu w całej firmie.
  • Zapewnia pełną redundancję - w razie awarii tunelu głównego, OSPF sam przeliczy trasę przez węzeł zapasowy.
Protokół OSPF (Open Shortest Path First): Wewnętrzny hierarchiczny protokół bramy bazujący na algorytmie Dijkstry (SPF), synchronizujący topologiczną bazę danych stanu łączy (LSDB) pomiędzy wszystkimi routerami w obszarze.
Slide 9

W miarę jak organizacja rozrasta się do kilkunastu lub kilkudziesięciu oddziałów połączonych wirtualnymi tunelami, zarządzanie dziesiątkami statycznych tras staje się podatne na błędy ludzkie i logistycznie niemożliwe do utrzymania. Wszelkie zmiany podsieci w centrali lub dodanie nowego oddziału wymagałyby ręcznej rekonfiguracji tablic routingu na wszystkich urządzeniach brzegowych. Szczegółowe informacje normatywne i techniczne publikuje Standard protokołu OSPF Version 2 (RFC 2328).

Wdrożenie otwartego protokołu OSPFv2 (RFC 2328) w strukturach tunelowych automatyzuje cały proces rozgłaszania dostępnych podsieci. Routery w sposób ciągły monitorują status swoich sąsiadów za pomocą pakietów OSPF Hello, a w przypadku wykrycia awarii tunelu lub dodania nowej trasy błyskawicznie propagują pakiety LSA (Link-State Advertisement), wymuszając przeliczenie najkrótszych ścieżek przez algorytm SPF.

Dzięki protokołowi OSPF sieć VPN zyskuje zdolność do samonaprawiania (Self-Healing). Jeśli w topologii siatkowej (Mesh) tunel bezpośredni pomiędzy oddziałem A i B ulegnie przerwaniu, OSPF natychmiast wykryje zmianę topologii i skieruje pakiety ścieżką tranzytową przez węzeł centralny C w czasie rzędu setek milisekund.

Ponadto OSPF pozwala na podział sieci na obszary (Areas) ze szkieletowym obszarem Area 0 (Backbone), co umożliwia agregację i filtrowanie tras na granicach obszarów (routery ABR), ograniczając rozmiar tablic routingu na urządzeniach w małych oddziałach.

Wyjaśnienie skrótów użytych na slajdzie:
OSPF - Open Shortest Path First - Hierarchiczny protokół trasowania stanu łącza.
SPF - Shortest Path First - Algorytm wyznaczania najkrótszej ścieżki w grafie połączeń.
LSDB - Link-State Database - Baza danych stanu lacz współdzielona przez routery w obszarze OSPF.
LSA - Link-State Advertisement - Jednostka ogłoszenia stanu łącza w protokole OSPF.
ABR - Area Border Router - Router graniczny łączący obszar peryferyjny z obszarem szkieletowym Area 0.

10/40 Wymagania protokołu OSPF względem tunelu
Identyfikacja wymogów technicznych stawianych łączom wirtualnym przez protokół OSPF, w szczególności obsługi ruchu rozgłoszeniowego i grupowego (Multicast).
  • Protokół OSPF opiera swoją komunikację na Multicastach (224.0.0.5).
  • Ograniczenie: Standardowy IPSec (tryb oparty na politykach) nie obsługuje natywnie multicastów.
  • Rozwiązanie: Należy użyć tuneli interfejsowych, takich jak GRE, IPIP lub VTI.
  • Najczęstszy model to "OSPF over GRE over IPSec" - zapewnia zarówno bezpieczeństwo, jak i inteligentny routing.
Obsługa Multicast w tunelach: Zdolność wirtualnego interfejsu sieciowego do enkapsulacji i przesyłania pakietów kierowanych na specjalne adresy grupowe warstwy 3 (np. 224.0.0.5 i 224.0.0.6), niezbędna do dynamicznego wykrywania sąsiadów w protokole OSPF.
Slide 10

Protokół OSPF opiera mechanizm dynamicznego wykrywania sąsiadów (Neighbor Discovery) na wysyłaniu okresowych pakietów Hello na zastrzeżone adresy grupowe: 224.0.0.5 (AllSPFRouters - wszystkie routery OSPF) oraz 224.0.0.6 (AllDRouters - routery desygnowane i zapasowe). Aby relacja sąsiedztwa (Adjacency) mogła zostać pomyślnie zestawiona, tunel VPN musi bezwzględnie zapewniać transmisję ruchu Multicast. Szczegółowe informacje normatywne i techniczne publikuje Rozszerzenia protokołu IP dla transmisji grupowej Multicast (RFC 1112).

Wiele popularnych technologii tunelowania warstwy 3, takich jak czysty protokół IPsec w trybie tunelowym, natywnie nie wspiera enkapsulacji pakietów rozgłoszeniowych ani grupowych (obsługuje wyłącznie pakiety Unicast). Próba uruchomienia protokołu OSPF bezpośrednio na interfejsie takiego tunelu zakończy się całkowitym niepowodzeniem.

Rozwiązaniem tego problemu jest zastosowanie technologii tunelowania wspierającej pakiety grupowe, takich jak protokół GRE (Generic Routing Encapsulation) lub IPIP z obsługą multicastu, a następnie zabezpieczenie całego tunelu za pomocą IPsec w trybie transportowym (tzw. GRE over IPsec). W takim modelu OSPF widzi logiczny interfejs GRE o pełnej przepuszczalności multicastów.

W przypadku wdrożeń, w których stosuje się technologie z natury bezrozgłoszeniowe (NBMA), administrator zmuszony jest do ręcznego definiowania sąsiadów (dyrektywa nbma-neighbor) lub rekonfiguracji typu sieci OSPF na Point-to-Multipoint Non-Broadcast. Zasady transmisji grupowej definiuje standard IETF RFC 1112.

Wyjaśnienie skrótów użytych na slajdzie:
NBMA - Non-Broadcast Multi-Access - Sieć wielodostępowa nieobsługująca natywnego rozgłoszenia multicast.
GRE - Generic Routing Encapsulation - Standard hermetyzacji dowolnych pakietów warstwy 3.
DR - Designated Router - Router desygnowany pełniący role centralnego punktu wymiany w sieci wielodostępowej.
BDR - Backup Designated Router - Zapasowy router desygnowany przejmujący zadania DR w przypadku awarii.

11/40 Podstawowa konfiguracja OSPF (MikroTik RouterOS)
Przedstawienie procedury konfiguracyjnej procesu OSPFv2 w systemie MikroTik RouterOS v7 z uwzględnieniem instancji, obszarów i szablonów interfejsów.
  • Procedura dla tunelu GRE (10.0.0.1 ↔ 10.0.0.2):
  • # 1. Definiowanie sieci dla komunikacji OSPF
/routing ospf network add network=10.0.0.0/30 area=backbone
# 2. Rozgłaszanie lokalnej sieci LAN oddziału
/routing ospf network add network=192.168.1.0/24 area=backbone
  • Po wykonaniu tych kroków routery zaczną wymieniać pakiety typu Hello przez tunel.
Szablon interfejsu OSPF (Interface Template): Struktura konfiguracyjna w systemie MikroTik RouterOS v7 służąca do powiązania interfejsów sieciowych z odpowiednim obszarem OSPF, definiująca koszty, typ sieci oraz parametry uwierzytelniania.
Slide 11

Wraz z premierą systemu MikroTik RouterOS v7 architektura podsystemu routingu przeszła gruntowną transformację, zastępując dawny stos OSPF nowym silnikiem opartym na architekturze modułowej. W nowym modelu zrezygnowano ze statycznego definiowania sieci w gałęzi /routing ospf network na rzecz zaawansowanych szablonów interfejsów (Interface Templates). Szczegółowe informacje normatywne i techniczne publikuje Specyfikacja opcji obszarów NSSA w protokole OSPF (RFC 3101).

Konfiguracja OSPF rozpoczyna się od utworzenia instancji z unikalnym 32-bitowym identyfikatorem routera (Router ID), np. /routing ospf instance add name=ospf-inst router-id=10.0.0.1. Następnie definiuje się szkieletowy obszar Area 0: /routing ospf area add name=backbone area-id=0.0.0.0 instance=ospf-inst.

Kluczowym krokiem jest aktywacja procesu na wirtualnym interfejsie tunelowym za pomocą szablonu: /routing ospf interface-template add area=backbone interfaces=gre-tunnel1 networks=10.255.0.0/30 type=ptp cost=10. Wskazanie typu sieci ptp (Point-to-Point) jest krytyczną optymalizacją, która eliminuje zbędne wybory routera desygnowanego (DR/BDR).

W celu zabezpieczenia wymiany pakietów OSPF przed nieautoryzowanym wstrzykiwaniem fałszywych tras należy bezwzględnie wdrożyć kryptograficzne uwierzytelnianie komunikatów za pomocą funkcji skrótu SHA-256 lub HMAC-MD5 w parametrach szablonu interfejsu. Zaawansowane opcje obszarów stub i NSSA standaryzuje dokument IETF RFC 3101.

Wyjaśnienie skrótów użytych na slajdzie:
RID - Router ID - Unikalny 32-bitowy identyfikator routera w domenie OSPF.
PTP - Point-to-Point - Typ interfejsu OSPF dla połączeń dwupunktowych.
NSSA - Not-So-Stubby Area - Specjalny typ obszaru OSPF dopuszczający redystrybucje tras zewnętrznych.
SHA - Secure Hash Algorithm - Rodzina bezpiecznych kryptograficznych funkcji skrótu.

12/40 Typy sieci OSPF (Network Type)
Porównanie charakterystyki typów sieci protokołu OSPF oraz uzasadnienie wyboru typu Point-to-Point w tunelach VPN.
  • Wybór typu sieci w protokole OSPF (RFC 2328) determinuje zachowanie procesu sąsiedztwa na interfejsie logicznym:
  • Ryzyko trybu domyślnego Broadcast:
    • Wiele systemów (w tym RouterOS i Linux) domyślnie przypisuje wirtualnym interfejsom tunelowym tryb Broadcast.
    • Wymusza to uruchomienie 40-sekundowego mechanizmu wyborów DR / BDR, co na łączu dwupunktowym jest zbędnym błędem sztuki inżynierskiej opóźniającym zbieżność sieci.
  • Rekomendacja inżynierska - Typ Point-to-Point (PTP):
    • Całkowicie eliminuje fazę wyborów routera desygnowanego (DR/BDR).
    • Pakiety Hello przesyłane są bezpośrednio na adres grupowy 224.0.0.5.
    • Relacja sąsiedztwa osiąga docelowy stan Full w ułamku sekundy po podniesieniu łącza.
    • W RouterOS v7 konfiguracja: /routing ospf interface-template add area=backbone interfaces=gre-tun1 type=ptp.
Typ sieci OSPF (Network Type): Klasyfikacja medium transmisyjnego w protokole OSPF determinująca sposób wysyłania pakietów Hello (multicast vs unicast), czasy oczekiwania timerów oraz konieczność wyboru routera DR/BDR.
Slide 12

Protokół OSPF definiuje kilka odmiennych modeli zachowania w zależności od typu warstwy łącza danych: Broadcast (domyślny dla sieci Ethernet), Point-to-Point (dla łączy dwupunktowych), Non-Broadcast Multi-Access (NBMA), Point-to-Multipoint oraz Point-to-Multipoint Non-Broadcast. Wybór niewłaściwego typu sieci na wirtualnym interfejsie tunelowym jest jedną z najczęstszych przyczyn niestabilności relacji sąsiedztwa. Szczegółowe informacje normatywne i techniczne publikuje Specyfikacja protokołu OSPF dla protokołu IPv6 - OSPFv3 (RFC 5340).

Domyślnie wiele systemów operacyjnych traktuje tunele wirtualne (szczególnie wielopunktowe tunele GRE lub wirtualne mosty EoIP) jako medium typu Broadcast. W tym trybie OSPF uruchamia 40-sekundowy proces wyborów Routera Desygnowanego (DR) oraz Zapasowego (BDR), co w przypadku zwykłego łącza dwupunktowego stanowi całkowicie zbędny narzut czasowy i obliczeniowy.

Wdrożenie typu Point-to-Point (PTP) na łączach tunelowych przynosi natychmiastowe korzyści inżynierskie: całkowicie wyłącza mechanizm wyborów DR/BDR, a pakiety Hello przesyłane są bezpośrednio na adres 224.0.0.5. Powoduje to, że relacja sąsiedztwa przechodzi do docelowego stanu Full w ułamku sekundy po podniesieniu tunelu.

Dla struktur wielooddziałowych Hub-and-Spoke z pojedynczym interfejsem centralnym (np. DMVPN) optymalnym wyborem staje się typ Point-to-Multipoint, w którym centrala traktuje każdy oddział jako niezależne łącze punkt-punkt bez konieczności powoływania DR. Ewolucję protokołu OSPF dla nowoczesnego stosu IPv6 definiuje specyfikacja IETF RFC 5340.

Wyjaśnienie skrótów użytych na slajdzie:
PTP - Point-to-Point - Typ sieci dwupunktowej w protokole OSPF.
DR - Designated Router - Router zarządzający rozgłoszeniami w sieci wielodostępowej.
BDR - Backup Designated Router - Zapasowy router desygnowany.
DMVPN - Dynamic Multipoint Virtual Private Network - Dynamiczna wielopunktowa wirtualna sieć prywatna Cisco/MikroTik.

13/40 MTU - pułapka w protokole OSPF
Wyjaśnienie mechanizmu zawieszania się sąsiedztwa OSPF w stanach ExStart i Exchange w wyniku niedopasowania jednostki MTU na końcach tunelu.
  • W fazie synchronizacji bazy LSDB routery OSPF wymieniają pakiety Database Description (DBD), deklarując w ich nagłówkach wartość parametru Interface MTU:
  • Mechanizm awarii (MTU Mismatch):
    • Zgodnie ze standardem RFC 2328, jeśli router otrzyma pakiet DBD z wartością MTU większą niż na interfejsie lokalnym, pakiet zostaje bezwzględnie odrzucony.
    • Objaw inżynierski: Relacja sąsiedztwa utyka permanentnie w stanie ExStart lub Exchange i trasy nie zostają zainstalowane w tablicy routingu.
  • Pułapka doraźnego parametru 'mtu-ignore':
    • Włączenie opcji mtu-ignore=yes pozwala wymusić przejście do stanu Full, lecz niesie wysokie ryzyko: duże pakiety aktualizacji LSU (Link-State Update) przekraczające MTU łącza zostaną pofragmentowane lub odrzucone, prowadząc do asynchronii bazy LSDB.
    • Prawidłowe rozwiązanie inżynierskie: Precyzyjne ujednolicenie jednostki MTU po obu stronach tunelu z uwzględnieniem narzutu nagłówków (GRE + IPsec).
Niedopasowanie MTU w OSPF (MTU Mismatch): Stan niezgodności wartości Maximum Transmission Unit zadeklarowanych w pakietach Database Description (DBD) pomiędzy sąsiednimi routerami, blokujący pełną synchronizację bazy LSDB.
Slide 13

Podczas nawiązywania relacji sąsiedztwa OSPF, po pomyślnej wymianie pakietów Hello, routery przechodzą do fazy synchronizacji topologicznej bazy danych LSDB w stanach ExStart oraz Exchange. W tej fazie urządzenia wymieniają pakiety Database Description (DBD), w których nagłówkach przesyłana jest informacja o maksymalnym rozmiarze jednostki transmisyjnej (Interface MTU). Szczegółowe informacje normatywne i techniczne publikuje Mechanizm wykrywania MTU ścieżki - PMTUD (RFC 1191).

Zgodnie ze standardem RFC 2328, jeżeli router otrzyma pakiet DBD wskazujący, że sąsiad posiada wyższą wartość MTU niż lokalny interfejs odbiorczy, router odbiorczy bezwarunkowo odrzuca taki pakiet. Skutkuje to zawieszeniem relacji sąsiedztwa w nieskończonej pętli stanów ExStart / Exchange i całkowitym brakiem instalacji tras w tablicy routingu.

W tunelach VPN zjawisko to występuje powszechnie ze względu na zróżnicowany narzut nagłówków enkapsulacji (np. fizyczne MTU 1500 bajtów pomniejszone o 24 bajty GRE i do 73 bajtów IPsec ESP daje efektywne MTU 1400 bajtów). Jeśli administrator na jednym końcu tunelu ustawił MTU 1400, a na drugim pozostawił domyślne 1500, sąsiedztwo OSPF nigdy nie osiągnie stanu stabilnego Full.

Doraźnym obejściem problemu jest aktywacja flagi mtu-ignore=yes w konfiguracji OSPF, jednak jest to praktyka ryzykowna, gdyż duże pakiety aktualizacji stanu łącza (LSU) przekraczające faktyczne MTU łącza zostaną bezpowrotnie pofragmentowane lub odrzucone. Prawidłowym rozwiązaniem inżynierskim jest precyzyjna kalkulacja narzutu nagłówków i ujednolicenie MTU po obu stronach. Mechanizmy wykrywania MTU ścieżki opisuje standard IETF RFC 1191.

Wyjaśnienie skrótów użytych na slajdzie:
MTU - Maximum Transmission Unit - Maksymalny rozmiar jednostki danych warstwy sieciowej bez fragmentacji.
DBD - Database Description - Pakiet opisujący zawartość topologicznej bazy danych OSPF.
LSDB - Link-State Database - Baza danych stanu lacz protokołu OSPF.
LSU - Link-State Update - Pakiet aktualizacji zawierający szczegółowe ogłoszenia LSA.

14/40 Architektura Hub-and-Spoke (centrala i oddziały)
Przedstawienie topologii Hub-and-Spoke, zasad agregacji ruchu w węźle centralnym oraz implementacji dynamicznych protokołów NHRP i DMVPN.
  • Centralny węzeł (Hub) utrzymuje połączenia ze wszystkimi oddziałami (Spokes).
  • Oddziały nie posiadają bezpośrednich połączeń między sobą.
  • Komunikacja między oddziałami odbywa się tranzytem przez Hub.
  • Wyzwanie: Hub staje się tzw. punktem krytycznym (SPOF - Single Point of Failure) oraz potencjalnym wąskim gardłem całej struktury.
Architektura Hub-and-Spoke: Topologia sieci VPN typu gwiazda, w której wszystkie węzły brzegowe (Spoke) zestawiają stałe tunele wyłącznie z jednym centralnym węzłem koncentrującym (Hub), pośredniczącym w wymianie całego ruchu.
Slide 14

Architektura Hub-and-Spoke jest klasycznym i najczęściej wdrażanym modelem wielooddziałowych sieci korporacyjnych. Centralny router (Hub) posiada stały, publiczny adres IP oraz wydajne łącze światłowodowe, natomiast routery w oddziałach terenowych (Spokes) mogą pracować na dynamicznych adresach IP przydzielanych przez lokalnych dostawców konsumenckich. Szczegółowe informacje normatywne i techniczne publikuje Protokół rozwiązywania następnego skoku NBMA - NHRP (RFC 2332).

W klasycznym modelu Hub-and-Spoke komunikacja pomiędzy dwoma oddziałami (np. ze Spoke 1 do Spoke 2) odbywa się zawsze w sposób tranzytowy przez centralę. Węzeł centralny odbiera zaszyfrowany pakiet od Spoke 1, deszyfruje go, sprawdza tablicę routingu, po czym powtórnie szyfruje i przesyła tunelem do Spoke 2, co powoduje zjawisko podwójnego narzutu opóźnień (Hairpinning) i obciąża łącze centralne.

W celu wyeliminowania wad sztywnego modelu gwiazdy w zaawansowanych sieciach wdraża się technologie dynamicznych tuneli wielopunktowych (DMVPN) oparte na protokole Next Hop Resolution Protocol (NHRP). W tej architekturze węzeł centralny służy jedynie jako serwer rejestracji adresowej (NHS), a routery oddziałowe po otrzymaniu zapytania zestawiają bezpośrednie tunele dynamiczne Spoke-to-Spoke 'na żądanie'.

Niezależnie od wybranego wariantu architektura ta wymaga starannego zaplanowania dystrybucji tras, aby uniknąć przeciążenia pamięci słabych routerów oddziałowych, co osiąga się poprzez rozgłaszanie przez Hub wyłącznie trasy domyślnej 0.0.0.0/0 lub zsumaryzowanych prefiksów regionalnych. Standard protokołu NHRP dla sieci NBMA standaryzuje dokument IETF RFC 2332.

Wyjaśnienie skrótów użytych na slajdzie:
NHRP - Next Hop Resolution Protocol - Protokół rozwiązywania następnego skoku w sieciach wielodostępowych.
NHS - Next Hop Server - Serwer rejestracji adresów fizycznych w architekturze NHRP.
DMVPN - Dynamic Multipoint Virtual Private Network - Zaawansowana technologia elastycznych tuneli wielopunktowych.
IP - Internet Protocol - Protokół warstwy sieciowej.

15/40 Przekazywanie ruchu (Forwarding) przez węzeł centralny
Przeanalizowanie warunków wymaganych do poprawnego tranzytu pakietów w węźle centralnym, w tym reguł zapory ogniowej w łańcuchu Forward oraz mechanizmów QoS.
  • Aby Oddział A mógł rozmawiać z Oddziałem B, Hub musi pozwalać na routing "z tunelu do tunelu".
  • Standardowo systemy blokują przekazywanie pakietów między interfejsami wirtualnymi ze względów bezpieczeństwa.
  • Należy precyzyjnie skonfigurować łańcuch FORWARD w zaporze sieciowej (IP Firewall Filter).
Przekazywanie tranzytowe (IP Forwarding): Zdolność węzła sieciowego do odbierania pakietów na jednym interfejsie i przesyłania ich na inny interfejs docelowy, pod warunkiem że router nie jest ostatecznym adresatem danego datagramu.
Slide 15

W architekturach tunelowych, w których centrala pośredniczy w komunikacji pomiędzy oddziałami lub zapewnia oddziałom dostęp do zasobów chmurowych, sam routing pakietów nie wystarcza do poprawnego działania sieci. W systemach bazujących na jądrze Linux oraz RouterOS kluczową rolę odgrywa podsystem filtracji pakietów zapory sieciowej (Firewall). Szczegółowe informacje normatywne i techniczne publikuje Definicja pola Differentiated Services (DS Field) w nagłówku IPv4 i IPv6 (RFC 2474).

Wielu inżynierów spotyka się z sytuacją, w której tablica routingu w centrali poprawnie wskazuje trasy do obu oddziałów, pakiety ICMP wysyłane z centrali docierają do obu stron, ale stacje robocze w oddziale A nie mogą skomunikować się ze stacjami w oddziale B. Przyczyną jest najczęściej domyślna reguła blokująca (Drop) w łańcuchu forward zapory sieciowej centralnego routera.

Aby umożliwić legalny tranzyt danych pomiędzy tunelami, w centralnym routerze MikroTik należy dodać regułę zezwalającą: /ip firewall filter add chain=forward in-interface=tunel-oddział-A out-interface=tunel-oddział-B action=accept comment="Zezwolenie na tranzyt miedzy oddziałami".

W przypadku intensywnej wymiany danych tranzytowych węzeł centralny staje się punktem krytycznym pod kątem jakości usług (QoS). Niezbędne staje się wdrożenie mechanizmów kolejkowania pakietów (np. HTB, Cake lub FQ-CoDel) oraz znakowania priorytetów DSCP w celu zagwarantowania niskich opóźnień dla transmisji głosu VoIP i wideokonferencji. Standard kodowania DSCP definiuje specyfikacja IETF RFC 2474.

Wyjaśnienie skrótów użytych na slajdzie:
QoS - Quality of Service - Zestaw mechanizmów gwarantujących wymagana jakość transmisji pakietów.
DSCP - Differentiated Services Code Point - Pole w nagłówku IP definiujące klasę jakości usługi.
VoIP - Voice over IP - Technologia cyfrowej transmisji głosu w sieciach IP.
HTB - Hierarchical Token Bucket - Hierarchiczny algorytm kształtowania i zarządzania pasmem.

16/40 Routing oparty na politykach (PBR - Policy Based Routing)
Przedstawienie koncepcji PBR pozwalającej na podejmowanie decyzji o trasowaniu na podstawie adresu źródłowego, portu aplikacji lub protokołu.
  • Tradycyjny routing bierze pod uwagę wyłącznie adres docelowy.
  • PBR rozszerza tę logikę o dodatkowe kryteria:
    • Adres źródłowy (konkretny dział/komputer).
    • Typ protokołu/aplikacji (np. tylko ruch bazodanowy).
    • Wielkość pakietu lub port docelowy.
  • Zastosowanie: Skierowanie ruchu ERP do tunelu VPN, przy jednoczesnym wysyłaniu poczty e-mail bezpośrednio przez ISP.
Routing oparty na politykach (Policy-Based Routing - PBR): Zaawansowany mechanizm wyznaczania tras pakietów, w którym decyzja o wyborze bramy wyjściowej zależy od kryteriów innych niż wyłącznie docelowy adres IP, takich jak adres źródłowy, port warstwy 4 czy znacznik pakietu.
Slide 16

Klasyczny routing IP (tzw. Destination-Based Routing) opiera się wyłącznie na analizie docelowego adresu IP pakietu. Każdy pakiet zmierzający pod ten sam adres docelowy opuści router dokładnie tą samą ścieżką, bez względu na to, jaki host go nadał i jaka aplikacja go wygenerowała. W wielu zaawansowanych scenariuszach laboratoryjnych i produkcyjnych zachowanie to jest niewystarczające. Szczegółowe informacje normatywne i techniczne publikuje Podręcznik narzędzia ip-rule w systemie Linux (iproute2).

Routing oparty na politykach (PBR) przełamuje to ograniczenie, umożliwiając administratorowi tworzenie elastycznych reguł sterowania ruchem. Za pomocą PBR można skierować ruch kadry kierowniczej przez szybki tunel światłowodowy, ruch gości hotelowych przez wolne łącze LTE, a zapytania do baz danych przez dedykowany, szyfrowany kanał IPsec.

W architekturze systemów uniksowych mechanizm PBR jest realizowany za pomocą reguł bazy zasad routingu (Routing Policy Database - RPDB) sterowanych narzędziem ip rule. Pozwala to na przypisywanie strumieni pakietów spełniających określone kryteria (np. from 192.168.1.0/24 lub dport 443) do niezależnych, dedykowanych tablic routingu.

PBR odgrywa fundamentalną rolę w hybrydowych sieciach SD-WAN, dynamicznie kierując pakiety krytycznych aplikacji biznesowych przez łącza o najniższych w danym momencie opóźnieniach i najmniejszej stopie utraty pakietów (Jitter/Loss). Podręcznik reguł trasowania w Linuksie udostępnia dokumentacja man ip-rule.

Wyjaśnienie skrótów użytych na slajdzie:
PBR - Policy Based Routing - Routing bazujący na zaawansowanych kryteriach i politykach administratora.
RPDB - Routing Policy Database - Baza reguł polityki trasowania pakietów w jądrze Linux.
SD-WAN - Software-Defined Wide Area Network - Programowo definiowalne sieci rozlegle.
VoIP - Voice over IP - Cyfrowa transmisja głosu.

17/40 Zastosowanie Mangle i Routing Marks
Przedstawienie techniki znakowania pakietów w łańcuchu Prerouting zapory sieciowej MikroTik oraz przypisywania ich do dedykowanych tablic routingu w RouterOS v7.
  • W systemie MikroTik RouterOS v7 architektura tablic routingu uległa fundamentalnej zmianie, wymagając ścisłej separacji tablic FIB:
  • Prawidłowa procedura inżynierska w RouterOS v7:
  • 1. Rejestracja dedykowanej tablicy FIB: Każda tablica używana w PBR musi zostać uprzednio jawnie zadeklarowana:
    /routing table add name=przez-vpn fib
  • 2. Znakowanie ruchu w łańcuchu Prerouting:
  • /ip firewall mangle add chain=prerouting src-address=192.168.1.50 action=mark-routing new-routing-mark=przez-vpn passthrough=no
  • 3. Dodanie trasy do zadeklarowanej tablicy FIB: W nowym systemie stosuje się parametr routing-table=... zamiast dawnego routing-mark=...:
    /ip route add dst-address=0.0.0.0/0 gateway=Tunel-VPN routing-table=przez-vpn
Znacznik routingu (Routing Mark): Metadana przypisywana pakietowi sieciowemu podczas przetwarzania w zaporze sieciowej (łańcuch Mangle), zmuszająca silnik routingu do wyboru określonej wirtualnej tablicy routingu zamiast tablicy głównej (main).
Slide 17

W systemie MikroTik RouterOS implementacja mechanizmu PBR opiera się na ścisłej współpracy modułu zapory sieciowej (Mangle) oraz podsystemu tablic routingu. Proces składa się z dwóch niezależnych kroków inżynierskich: oznaczenia pakietu odpowiednią etykietą logiczną, a następnie skierowania oznakowanego ruchu do właściwej tablicy FIB. Szczegółowe informacje normatywne i techniczne publikuje Model informacyjny polityk sieciowych - PCIM (RFC 3644).

W pierwszym kroku, w łańcuchu prerouting zapory Mangle, administrator definiuje regułę filtrującą ruch i przypisuje jej akcję mark-routing: /ip firewall mangle add chain=prerouting src-address=192.168.10.0/24 action=mark-routing new-routing-mark=do-centrali passthrough=no. Parametr passthrough=no kończy przetwarzanie reguł Mangle dla tego pakietu, oszczędzając cykle procesora.

Kluczową różnicą pomiędzy starszą wersją RouterOS v6 a nową wersją RouterOS v7 jest sposób deklaracji tablicy routingu. W systemie RouterOS v7 każda nazwa użyta jako routing-mark musi zostać uprzednio jawnie zarejestrowana jako tablica FIB w gałęzi: /routing table add name=do-centrali fib.

Dopiero po zdefiniowaniu tablicy FIB administrator może dodać do niej trasę domyślną kierującą oznakowane pakiety do wnętrza tunelu VPN: /ip route add dst-address=0.0.0.0/0 gateway=gre-tunel1 routing-table=do-centrali. Pakiety nieoznaczone będą korzystać ze standardowej tablicy main, co gwarantuje precyzyjną separację ruchu. Zasady konfiguracji polityk sieciowych standaryzuje dokument IETF RFC 3644.

Wyjaśnienie skrótów użytych na slajdzie:
FIB - Forwarding Information Base - Baza informacyjna przekazywania pakietów powiązana z tablica routingu.
PBR - Policy Based Routing - Routing oparty na politykach zapory.
Mangle - Mangle Facility - Wewnętrzny moduł zapory służący do znakowania i modyfikacji pakietów.
IP - Internet Protocol - Protokół warstwy sieciowej.

18/40 Mechanizmy przełączania awaryjnego (Failover) w rozwiązaniach PBR
Przedstawienie metod zagwarantowania niezawodności i automatycznego przełączania ścieżek (Failover) w konfiguracjach routingu opartego na politykach.
  • W PBR brak aktywnej bramy w specyficznej tablicy routingu może skutkować całkowitym odcięciem hosta od sieci.
  • Należy zawsze definiować trasy alternatywne lub upewnić się, że w przypadku awarii pakiet może wrócić do głównej tablicy (Main).
  • Monitorowanie statusu tunelu za pomocą check-gateway staje się tu krytyczne.
Przełączanie awaryjne w PBR (PBR Failover): Zestaw reguł warunkowych zapewniających, że w przypadku awarii dedykowanego tunelu lub łącza przypisanego do reguły PBR ruch zostanie automatycznie przekierowany na ścieżkę rezerwową lub cofnięty do tablicy głównej.
Slide 18

Wdrożenie polityk PBR niesie ze sobą istotne ryzyko operacyjne. Jeśli administrator skieruje pakiety danej podsieci do dedykowanej tablicy routingu, a tunel VPN powiązany z tą tablicą ulegnie awarii, stacje robocze utracą całkowitą łączność ze światem, nawet jeśli fizyczne łącze internetowe w tablicy głównej main funkcjonuje bez zarzutu. Szczegółowe informacje normatywne i techniczne publikuje Specyfikacja protokołu VRRP w wersji 3 dla IPv4 i IPv6 (RFC 5798).

W celu zabezpieczenia sieci przed taką ewentualnością stosuje się mechanizmy 'Fallback to Main' lub konfigurację alternatywnych tras rezerwowych wewnątrz samej dedykowanej tablicy routingu. W systemie MikroTik dodaje się do tablicy specjalnej trasę podstawową z check-gateway=ping i distance=1 oraz trasę zapasową z distance=10.

Dodatkowo w regułach Routing Rules w RouterOS v7 można zastosować regułę warunkową z parametrem action=lookup-only-in-table (która odrzuca pakiety w przypadku braku trasy) lub bezpieczniejszą opcję domyślną action=lookup, która w sytuacji braku aktywnej ścieżki w tablicy specjalnej automatycznie odsyła pakiet do standardowej tablicy głównej main.

W środowiskach korporacyjnych o podwyższonych rygorach dostępności do monitorowania stanu ścieżek PBR zaprzęga się zaawansowane protokoły detekcji dwukierunkowej BFD (Bidirectional Forwarding Detection) lub mechanizmy redundancji bram VRRP zdefiniowane w oficjalnym standardzie IETF RFC 5798.

Wyjaśnienie skrótów użytych na slajdzie:
BFD - Bidirectional Forwarding Detection - Protokół subsekundowej detekcji przerw w ciągłości toru transmisyjnego.
VRRP - Virtual Router Redundancy Protocol - Protokół redundancji domyślnej bramy w sieci lokalnej.
PBR - Policy Based Routing - Routing bazujący na zaawansowanych kryteriach.
FIB - Forwarding Information Base - Aktywna tablica przekazywania pakietów.

19/40 Wykorzystanie NAT wewnątrz VPN
Przeanalizowanie konieczności stosowania translacji NAT wewnątrz tuneli VPN w przypadku konfliktów nakładających się przestrzeni adresowych (Overlapping Subnets).
  • Zalecana praktyka: "Unikaj NAT w sieciach wewnętrznych". Utrudnia on audyt i monitorowanie ruchu.
  • Sytuacje przymusowe: Konflikt adresacji. Firma A i Firma B używają tych samych sieci (np. 192.168.1.0/24).
  • Zastosowanie Maskarady na interfejsie tunelu pozwala ukryć całą wewnętrzną adresację i rozwiązać problem "nakładających się sieci".
Translacja adresów wewnątrz tunelu (VPN In-Tunnel NAT): Zastosowanie mechanizmów Source NAT lub Destination NAT do modyfikacji adresów IP pakietów przesyłanych przez wirtualny tunel w celu rozwiązania problemu nakładających się identycznych podsieci w łączonych lokalizacjach.
Slide 19

Podręcznikowym i pożądanym stanem przy projektowaniu sieci korporacyjnej jest zachowanie unikalnej, spójnej numeracji IP we wszystkich lokalizacjach (np. centrala: 10.1.0.0/16, oddział 1: 10.2.0.0/16, oddział 2: 10.3.0.0/16). W realiach biznesowych, zwłaszcza podczas fuzji przedsiębiorstw lub podłączania sieci partnerów zewnętrznych, bardzo często dochodzi jednak do konfliktu nakładających się podsieci (Overlapping Subnets). Szczegółowe informacje normatywne i techniczne publikuje Specyfikacja tradycyjnego translatora IP NAT (RFC 3022).

Sytuacja, w której zarówno sieć centrali, jak i sieć przejętego oddziału korzystają z identycznej domyślnej podsieci 192.168.1.0/24, uniemożliwia tradycyjny routing IP, gdyż router nie jest w stanie rozstrzygnąć, czy adres docelowy znajduje się lokalnie na interfejsie LAN, czy za tunelem VPN. Jedynym bezinwazyjnym rozwiązaniem tego problemu bez konieczności natychmiastowej rekonfiguracji setek komputerów staje się translacja NAT.

W takich scenariuszach inżynierowie wdrażają podwójną translację NAT (Twice NAT lub 1:1 NAT). Router oddziału przed wpuszczeniem pakietu do tunelu dokonuje translacji źródłowej (Src-NAT) lokalnej podsieci na unikalną wirtualną przestrzeń tranzytową (np. 172.16.1.0/24), a centrala odbiera pakiety z nowej, jednoznacznej puli.

Należy jednak pamiętać, że translacja NAT wewnątrz VPN narusza zasadę spójności połączeń End-to-End, utrudnia działanie protokołów wymagających jawnych adresów w ładunku aplikacji (np. SIP/VoIP, FTP) oraz uniemożliwia bezpośrednią weryfikację tożsamości hosta w logach inspekcji. Zasady tradycyjnej translacji adresów IP reguluje standard IETF RFC 3022.

Wyjaśnienie skrótów użytych na slajdzie:
NAT - Network Address Translation - Translacja adresów sieciowych miedzy różnymi przestrzeniami IP.
SIP - Session Initiation Protocol - Sygnalizacyjny protokół inicjowania sesji multimedialnych VoIP.
FTP - File Transfer Protocol - Protokół przesyłania plików podatny na translacje NAT.
LAN - Local Area Network - Lokalna sieć komputerowa przedsiębiorstwa.

20/40 Src-NAT vs Masquerade w praktyce
Porównanie charakterystyki akcji action=src-nat oraz action=masquerade w zapaporze sieciowej pod kątem obciążenia procesora i stabilności połączeń w tunelach.
  • Wybór metody translacji źródłowej w zaporze sieciowej ma krytyczny wpływ na stabilność i wydajność tuneli VPN:
  • Krytyczne wady akcji Masquerade w tunelach:
    • Zaprojektowana wyłącznie dla zmiennych łączy dostępowych (DHCP, PPPoE, LTE).
    • Czyszczenie tablicy Conntrack: Każde chwilowe opuszczenie interfejsu tunelowego (zdarzenie Link Down) powoduje natychmiastowe usunięcie wszystkich powiązanych wpisów śledzenia połączeń, bezpowrotnie zrywając setki aktywnych sesji TCP użytkowników.
    • Każdy nowy pakiet wymusza dynamiczne odpytanie jądra o bieżący adres IP interfejsu, generując zbędny narzut CPU.
  • Standard inżynierski - Akcja Src-NAT:
    • Na stałych tunelach VPN należy bezwzględnie stosować deterministyczną akcję action=src-nat ze wskazanym adresem IP: /ip firewall nat add chain=srcnat out-interface=gre-tun1 action=src-nat to-addresses=10.0.0.1.
Maskarada (Masquerade): Specjalna odmiana translacji Source NAT zoptymalizowana pod kątem łączy o dynamicznie zmiennym adresie IP, automatycznie czyszcząca powiązane wpisy w tablicy Conntrack przy każdej zmianie stanu interfejsu wyjściowego.
Slide 20

W implementacjach zapory sieciowej (Netfilter w Linuksie oraz IP Firewall w systemie MikroTik RouterOS) administratorzy konfigurujący translację adresów mają do dyspozycji dwie główne akcje: action=src-nat oraz action=masquerade. Choć obie realizują podmianę źródłowego adresu IP w nagłówku pakietu, mechanizm ich działania i wpływ na zasoby routera są diametralnie różne. Szczegółowe informacje normatywne i techniczne publikuje Oficjalna dokumentacja mechanizmów NAT w projekcie Netfilter.

Akcja masquerade została zaprojektowana wyłącznie dla niestabilnych łączy dostępowych z dynamicznym przydziałem adresu IP (np. połączenia PPPoE, modemy LTE, klienci DHCP). Przy każdym podniesieniu lub opuszczeniu interfejsu (zdarzenie Link Down / Link Up) sterownik maskarady bezwzględnie czyści całą tablicę śledzenia połączeń (Conntrack) powiązaną z tym interfejsem, aby zapobiec wysyłaniu pakietów ze starym, nieaktualnym adresem IP.

W przypadku wirtualnych tuneli Site-to-Site ze stałą adresacją (np. GRE, IPIP, IPsec) stosowanie maskarady jest poważnym błędem sztuki inżynierskiej. Każda chwilowa fluktuacja tunelu spowoduje bezpowrotne zerwanie setek aktywnych sesji TCP użytkowników. Ponadto maskarada przy każdym nowym pakiecie dynamicznie odpytuje jądro o aktualny adres interfejsu, generując niepotrzebny narzut na procesor routera.

Prawidłową praktyką inżynierską w tunelach jest stosowanie akcji action=src-nat z jawnym wskazaniem stałego adresu IP w parametrze to-addresses: /ip firewall nat add chain=srcnat out-interface=gre-tun1 action=src-nat to-addresses=10.0.0.1. Taka konfiguracja jest deterministyczna, wysoce wydajna obliczeniowo i odporna na fluktuacje łącza. Szczegóły implementacji modułów NAT zawiera dokumentacja projektu Netfilter.

Wyjaśnienie skrótów użytych na slajdzie:
NAT - Network Address Translation - Translacja adresów sieciowych.
PPPoE - Point-to-Point Protocol over Ethernet - Protokół hermetyzacji ramek PPP w sieciach Ethernet dostawców ISP.
DHCP - Dynamic Host Configuration Protocol - Dynamiczna konfiguracja adresu IP.
TCP - Transmission Control Protocol - Połączeniowy protokół transportowy z gwarancja dostarczenia danych.

21/40 Zjawisko Split Horizon w protokole OSPF
Przedstawienie wpływu reguły Split Horizon na rozgłaszanie tras w architekturach wielopunktowych oraz metod jej mitygacji w protokołach trasowania.
  • Zjawisko specyficzne dla topologii Hub-and-Spoke.
  • Hub odbiera informację o sieci z Oddziału A na wirtualnym interfejsie. Zgodnie z regułą Split Horizon, nie może jej rozgłosić z powrotem na ten sam interfejs do Oddziału B.
  • Rozwiązanie: Stosowanie unikalnych interfejsów PtP dla każdego oddziału lub zmiana typu sieci OSPF na Point-to-Multipoint (PtMP).
Reguła Split Horizon: Zasada w protokołach wektora odległości zapobiegająca pętlom routingu, zabraniająca odsyłania informacji o trasie przez ten sam interfejs logiczny, przez który została ona odebrana.
Slide 21

W klasycznych protokołach wektora odległości (takich jak RIP czy EIGRP) podstawowym mechanizmem zapobiegania powstawaniu nieskończonych pętli routingu (Routing Loops) jest reguła Split Horizon. Zgodnie z tą zasadą router, który nauczył się ścieżki do danej podsieci przez określony interfejs, nigdy nie rozgłosi tej trasy z powrotem na ten sam interfejs fizyczny lub logiczny. Szczegółowe informacje normatywne i techniczne publikuje Specyfikacja protokołu RIP i reguły Split Horizon (RFC 1058).

W wielooddziałowych strukturach tunelowych Hub-and-Spoke opartych na pojedynczym wirtualnym interfejsie wielopunktowym (np. DMVPN lub pojedynczy interfejs multipoint GRE w centrali) reguła ta staje się poważną pułapką architektoniczną. Router centralny Hub odbiera informację o sieci LAN z oddziału Spoke 1, lecz ze względu na Split Horizon nie przekaże jej do oddziału Spoke 2, ponieważ oba oddziały są obsługiwane przez ten sam interfejs w centrali.

W efekcie komunikacja pomiędzy oddziałami zostaje całkowicie zablokowana. W przypadku protokołów wektora odległości administrator zmuszony jest do ręcznego wyłączenia reguły (no ip split-horizon) lub podziału interfejsu centralnego na niezależne podinterfejsy logiczne.

Chociaż protokół OSPF jako protokół stanu łącza (Link-State) nie podlega klasycznej regule Split Horizon (ponieważ routery synchronizują pełną bazę danych LSDB, a nie wektory odległości), to w topologiach Hub-and-Spoke wymaga on odpowiedniej konfiguracji typu sieci (Point-to-Multipoint) w celu uniknięcia problemów z brakiem widoczności sąsiadów. Podstawy reguły Split Horizon w protokołach internetowych definiuje standard IETF RFC 1058.

Wyjaśnienie skrótów użytych na slajdzie:
EIGRP - Enhanced Interior Gateway Routing Protocol - Zaawansowany protokół wektora odległości firmy Cisco.
RIP - Routing Information Protocol - Podstawowy protokół wektora odległości.
DMVPN - Dynamic Multipoint Virtual Private Network - Wielopunktowa wirtualna sieć prywatna.
LSDB - Link-State Database - Baza danych stanu lacz protokołu OSPF.

22/40 Wybór protokołu routingu dla VPN
Porównanie protokołów OSPF i BGP w środowiskach tuneli korporacyjnych i chmurowych pod kątem skalowalności, polityk i odporności na pętle.
  • RIP: Rozwiązanie przestarzałe, powolna zbieżność. Niepolecane w nowoczesnych strukturach.
  • OSPF: Standard korporacyjny (protokół typu IGP - Interior Gateway Protocol). Optymalny dla większości wdrożeń VPN.
  • BGP / iBGP: Wykorzystywany w rozwiązaniach operatorskich oraz architekturach takich jak DMVPN (Cisco). Niezrównana skalowalność i łatwość przechodzenia przez tunele dzięki komunikacji Unicast (TCP 179).
Protokół BGP (Border Gateway Protocol): Protokół wektora ścieżki (Path-Vector) stanowiący standard trasowania w globalnym Internecie oraz rozległych korporacyjnych sieciach WAN, operujący na atrybutach prefiksów i zaawansowanych filtrach polityk.
Slide 22

Wybór właściwego protokołu routingu dla rozległej sieci wirtualnych tuneli jest jedną z najważniejszych decyzji projektowych architekta sieci. O ile dla małych i średnich sieci kampusowych (do 50 węzłów) optymalnym rozwiązaniem pozostaje protokół OSPF ze względu na szybką zbieżność i prostotę implementacji, o tyle w środowiskach wielkoskalowych uwidaczniają się jego ograniczenia. Szczegółowe informacje normatywne i techniczne publikuje Specyfikacja protokołu BGP Version 4 (RFC 4271).

W protokole OSPF każdy router w danym obszarze musi posiadać identyczną kopię bazy LSDB i przeliczać algorytm Dijkstry przy każdej fluktuacji dowolnego łącza w sieci. Przy setkach tuneli fluktuacje łączy konsumenckich w odległych oddziałach mogą wywołać tzw. 'burzę SPF', doprowadzając procesory routerów centralnych do permanentnego przeciążenia.

Z tego powodu w nowoczesnych strukturach korporacyjnych, architekturach SD-WAN oraz w integracji z chmurami publicznymi (AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect) standardem stał się protokół BGP (w wariantach iBGP oraz eBGP). BGP nie przelicza topologii całego grafu, lecz operuje na wektorze ścieżki i rozsyła wyłącznie modyfikowane prefiksy sieciowe.

Dodatkowo BGP oferuje niezrównane możliwości sterowania ruchem za pomocą bogatych atrybutów ścieżki (AS-Path prepending, Local Preference, Multi-Exit Discriminator - MED, Communities), co pozwala na precyzyjną realizację skomplikowanych umów SLA i polityk bezpieczeństwa. Standard protokołu BGP-4 definiuje dokument IETF RFC 4271.

Wyjaśnienie skrótów użytych na slajdzie:
BGP - Border Gateway Protocol - Protokół wektora ścieżki zarządzający trasowaniem WAN.
SLA - Service Level Agreement - Umowa gwarantująca jakość i parametry usług telekomunikacyjnych.
MED - Multi-Exit Discriminator - Atrybut BGP sugerujący sąsiadowi preferowany punkt wejścia.
AWS - Amazon Web Services - Globalna platforma usług chmurowych.

23/40 Wirtualne tablice routingu (VRF - Virtual Routing and Forwarding)
Przedstawienie technologii wirtualizacji routingu VRF w celu separacji i bezpiecznej izolacji ruchu różnych grup użytkowników wewnątrz wspólnej infrastruktury VPN.
  • VRF umożliwia stworzenie wielu odizolowanych tablic routingu w obrębie jednego routera fizycznego.
  • Pozwala na współistnienie identycznych adresacji IP (np. dwóch różnych klientów w firmie outsourcingowej) bez ryzyka konfliktów.
  • Kluczowa technologia w sieciach dostawców usług VPN typu MPLS.
Wirtualna tablica routingu (VRF): Technologia wirtualizacji warstwy sieciowej pozwalająca na równoległe funkcjonowanie wielu niezależnych instancji tablic routingu i przekazywania na pojedynczym fizycznym routerze.
Slide 23

W nowoczesnych sieciach przedsiębiorstw, instytucji naukowych i operatorów telekomunikacyjnych kluczowym wymogiem stała się rygorystyczna separacja danych różnych segmentów organizacyjnych: ruchu gości, systemów automatyki budynkowej (BMS/IoT), sieci płatności PCI-DSS oraz wewnętrznej sieci pracowniczej. Tradycyjny model z jedną wspólną tablicą routingu uniemożliwia gwarancję pełnej izolacji. Szczegółowe informacje normatywne i techniczne publikuje Architektura sieci BGP/MPLS IP VPN i VRF (RFC 4364).

Technologia VRF (Virtual Routing and Forwarding) przenosi koncepcję wirtualnych sieci VLAN z warstwy 2 do warstwy 3 modelu OSI. Na jednym fizycznym urządzeniu router powołuje do życia odrębne, całkowicie odizolowane tablice routingu, do których przypisuje dedykowane interfejsy fizyczne, wirtualne podinterfejsy 802.1Q oraz interfejsy tuneli VPN.

Dzięki VRF różne działy przedsiębiorstwa mogą nawet korzystać z identycznej przestrzeni adresowej IP (np. dwa niezależne tunele VPN z podsiecią 10.0.0.0/24 w dwóch różnych instancjach VRF) bez ryzyka konfliktu adresowego czy nieuprawnionego wycieku pakietów pomiędzy strefami.

W systemie MikroTik RouterOS v7 konfiguracja VRF została uproszczona i zintegrowana z mechanizmem Routing Tables: administrator tworzy tablicę w gałęzi /ip vrf add name=GOSCIE interfaces=vlan-goście,tunel-goście, co całkowicie odcina ruch gości od produkcyjnej sieci firmowej. Zasady implementacji architektur VRF standaryzuje dokument IETF RFC 4364.

Wyjaśnienie skrótów użytych na slajdzie:
VRF - Virtual Routing and Forwarding - Wirtualizacja instancji routingu i przekazywania w warstwie 3.
VLAN - Virtual Local Area Network - Wirtualna sieć lokalna w warstwie 2.
IoT - Internet of Things - Urządzenia Internetu Rzeczy.
OSI - Open Systems Interconnection - Model referencyjny warstw sieciowych ISO/OSI.

24/40 Wielobieżność o równym koszcie (ECMP - Equal Cost Multi-Path)
Analiza mechanizmu ECMP umożliwiającego jednoczesne równoważenie obciążenia (Load Balancing) na wielu równoległych tunelach VPN o identycznym koszcie.
  • ECMP (Equal Cost Multi-Path): Równoległe korzystanie z dwóch lub więcej tuneli do tego samego celu.
  • Konfiguracja trasy z wieloma bramami: gateway=10.0.0.1,10.0.0.2.
  • Ostrzeżenie: Rozdzielanie pakietów pojedynczej sesji na różne tunele może prowadzić do zmiany ich kolejności (pakiety Out-of-order) i spadku wydajności TCP.
  • Zalecane stosowanie hashowania na podstawie par adresów IP.
Wielobieżność o równym koszcie (ECMP): Mechanizm przekazywania pakietów w routerze pozwalający na dystrybucję strumieni danych przez wiele równorzędnych tras o tej samej metryce i dystansie administracyjnym.
Slide 24

W środowiskach, w których pojedynczy tunel VPN nie zapewnia wystarczającej przepustowości lub gdy firma dysponuje dwoma niezależnymi łączami internetowymi od różnych operatorów, doskonałym rozwiązaniem inżynierskim jest zestawienie dwóch równoległych tuneli VPN pomiędzy centralą a oddziałem i uruchomienie mechanizmu ECMP (Equal-Cost Multi-Path). Szczegółowe informacje normatywne i techniczne publikuje Analiza algorytmów wielobieżności o równym koszcie ECMP (RFC 2992).

ECMP aktywuje się w momencie, gdy w tablicy routingu pojawiają się co najmniej dwie aktywne trasy do tej samej podsieci docelowej, posiadające identyczny dystans administracyjny oraz identyczną metrykę (np. dwie trasy statyczne z wieloma bramami: /ip route add dst-address=192.168.20.0/24 gateway=tunel1,tunel2).

W celu zapobieżenia zjawisku odbierania pakietów w niewłaściwej kolejności (Packet Reordering), które doprowadziłoby do drastycznego spadku wydajności protokołu TCP w wyniku fałszywych retransmisji, nowoczesne procesory sieciowe nie dzielą ruchu pakiet po pakiecie (Round-Robin). Zamiast tego stosują funkcję skrótu (Hashing) z nagłówka (tzw. 5-tuple: IP źródłowe/docelowe, port źródłowy/docelowy, protokół).

W rezultacie wszystkie pakiety należące do jednej sesji TCP są zawsze kierowane przez ten sam tunel, gwarantując właściwą kolejność dostarczania danych, podczas gdy różne sesje są równomiernie rozkładane pomiędzy dostępne łącza. Analizę algorytmów równoważenia obciążenia ECMP przedstawia standard IETF RFC 2992.

Wyjaśnienie skrótów użytych na slajdzie:
ECMP - Equal-Cost Multi-Path - Mechanizm routingu wielobieznego po ścieżkach o równym koszcie.
TCP - Transmission Control Protocol - Połączeniowy protokół transportowy.
SLA - Service Level Agreement - Gwarancja poziomu jakości usług sieciowych.
IP - Internet Protocol - Protokół warstwy sieciowej.

25/40 Diagnostyka: Traceroute wewnątrz tunelu
Przedstawienie metodyki diagnostycznej narzędzia Traceroute w tunelach VPN oraz interpretacji odpowiedzi ICMP Time Exceeded i zachowania pola TTL.
  • Podstawowe narzędzie weryfikacji ścieżki pakietu.
  • Jeśli na liście przeskoków (hops) widzisz adresy wewnętrzne tunelu (np. 10.8.0.1) - routing odbywa się poprawnie przez VPN.
  • Gwiazdki (*) lub adresy publiczne ISP oznaczają "wyciek" ruchu poza zabezpieczony tunel.
Narzędzie Traceroute: Program diagnostyczny mapujący sekwencję kolejnych routerów warstwy 3 na ścieżce do węzła docelowego poprzez inkrementację pola Time to Live (TTL) w nagłówku pakietów IP.
Slide 25

Weryfikacja poprawności przepływu danych w strukturach tunelowych wymaga biegłej znajomości działania narzędzia Traceroute (tracert w Windows). Narzędzie to wysyła serię pakietów sondujących z celowo ustawionym niskim polem Time to Live (począwszy od TTL=1). Każdy kolejny router pośredniczący na ścieżce zmniejsza wartość TTL o jeden; gdy wartość osiągnie zero, router odrzuca pakiet i odsyła do nadawcy komunikat ICMP Type 11 (Time Exceeded). Szczegółowe informacje normatywne i techniczne publikuje Specyfikacja śledzenia tras Traceroute w protokole IP (RFC 1393).

W przypadku badania ścieżki przechodzącej przez tunel VPN zachowanie Traceroute zależy od typu enkapsulacji oraz implementacji stosu sieciowego. W czystych tunelach warstwy 3 (takich jak GRE lub OpenVPN TUN) routery wirtualne widoczne są jako bezpośrednie skoki logiczne z prywatnymi adresami IP, a fizyczne routery operatorów ISP w Internecie pozostają całkowicie niewidoczne.

W środowiskach IPsec z włączonym mechanizmem ukrywania topologii (Tunnel Mode) węzły tranzytowe mogą nie dekrementować wewnętrznego pola TTL ładunku lub zapory sieciowe mogą blokować generowanie zwrotnych komunikatów ICMP. W takim przypadku w wyniku diagnostycznym pojawia się sekwencja gwiazdek (* * *), co nie oznacza awarii, lecz celową politykę bezpieczeństwa bramy.

Zaawansowaną diagnostykę ułatwia uruchomienie Traceroute z jawnym wskazaniem interfejsu źródłowego lub rozmiaru ładunku pakietu, co pozwala na natychmiastowe zidentyfikowanie punktu, w którym dochodzi do niepożądanej fragmentacji lub porzucenia pakietu. Standard opcji śledzenia tras definiuje specyfikacja IETF RFC 1393.

Wyjaśnienie skrótów użytych na slajdzie:
TTL - Time to Live - Pole w nagłówku IP określające maksymalny czas życia pakietu w skokach routerów.
ICMP - Internet Control Message Protocol - Protokół komunikatów diagnostycznych i kontrolnych IP.
ISP - Internet Service Provider - Dostawca usług internetowych.
IP - Internet Protocol - Protokół warstwy sieciowej.

26/40 Kluczowe flagi w tablicy IP Route
Przedstawienie i interpretacja flag statusowych w tablicy routingu systemu MikroTik RouterOS i uniksowym narzędziu ip route.
  • Szczegółowa lista tras: /ip route print detail.
  • A (Active): Trasa aktywna, wykorzystywana przez system do przekazywania pakietów.
  • S (Static): Trasa statyczna, wpisana ręcznie przez administratora.
  • D (Dynamic): Trasa dynamiczna, utworzona automatycznie przez protokół (np. OSPF).
  • Brak flagi A przy trasie statycznej oznacza, że jej brama jest nieosiągalna (np. tunel jest w statusie Down).
Flagi tablicy routingu: Jednoliterowe oznaczenia statusu i pochodzenia wpisu w tablicy routingu routera, określające jego aktywność, źródło wyuczenia oraz gotowość do przekazywania pakietów.
Slide 26

Podczas bieżącego administrowania i usuwania awarii w systemie MikroTik RouterOS kluczową umiejętnością inżyniera jest bezbłędna interpretacja flag wyświetlanych przy trasach w poleceniu /ip route print. Flagi te stanowią natychmiastowe źródło informacji o stanie logicznym i fizycznym każdego zdefiniowanego kierunku ruchu. Szczegółowe informacje normatywne i techniczne publikuje Podręcznik polecenia ip-route w systemie Linux (iproute2).

Najważniejszą flagą jest litera 'A' (Active). Oznacza ona, że trasa została pomyślnie zainstalowana w sprzętowej lub programowej tablicy przekazywania FIB i aktywnie uczestniczy w forwardowaniu pakietów. Brak litery 'A' (trasa nieaktywna) oznacza, że router posiada lepszą alternatywną ścieżkę o niższym dystansie lub brama docelowa została uznana za nieosiągalną (unreachable) przez mechanizm Check Gateway.

Kolejne kluczowe flagi to 'D' (Dynamic - trasa wygenerowana automatycznie, np. przez protokół OSPF, klienta DHCP lub interfejs tunelowy po nawiązaniu sesji), 'S' (Static - trasa zdefiniowana ręcznie przez administratora) oraz 'C' (Connect - bezpośrednio podłączona podsieć logiczna interfejsu).

W systemach Linux z pakietem iproute2 odpowiadają im deskryptory stanu w poleceniu ip route show (np. proto kernel dla tras połączonych, proto static dla statycznych oraz flaga linkdown w przypadku awarii fizycznego interfejsu). Podręcznik narzędzi manipulacji tablicami trasowania udostępnia dokumentacja man ip-route.

Wyjaśnienie skrótów użytych na slajdzie:
FIB - Forwarding Information Base - Aktywna baza przekazywania pakietów procesora sieciowego.
DHCP - Dynamic Host Configuration Protocol - Protokół dynamicznej konfiguracji adresacji.
CLI - Command Line Interface - Tekstowy interfejs wiersza poleceń.
IP - Internet Protocol - Protokół warstwy sieciowej.

27/40 Mechanizm MSS Clamping: rozwiązywanie problemów z fragmentacją
Przedstawienie inżynierskiego rozwiązania problemu fragmentacji pakietów w tunelach za pomocą manipulacji polem TCP Maximum Segment Size (MSS Clamping).
  • Przyczyna inżynierska zjawiska 'Black Hole MTU':
    • Narzut nagłówków tunelu (GRE, IPsec ESP, UDP) zmniejsza MTU poniżej standardowych 1500 bajtów (np. do 1400 bajtów).
    • Pakiety ICMP (ping) o rozmiarze kilkudziesięciu bajtów przechodzą bez zakłóceń, podczas gdy pełnowymiarowe pakiety HTTPS (1500 bajtów) z flagą DF (Don't Fragment) są po cichu odrzucane przez sieć.
  • Prawidłowa implementacja reguły MSS Clamping w MikroTik RouterOS:
  • W łańcuchu forward zapory Mangle należy dodać regułę dynamicznie obniżającą pole MSS w pakietach nawiązywania połączenia TCP:
    /ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn tcp-mss=1401-65535 action=change-mss new-tcp-mss=clamp-to-pmtu passthrough=yes comment="TCP MSS Clamping dla tuneli VPN"
Zaciskanie MSS (TCP MSS Clamping): Technika zapory sieciowej polegająca na inspekcji i dynamicznym obniżaniu zadeklarowanej wartości pola MSS w nagłówkach pakietów TCP SYN w celu dopasowania rozmiaru segmentu do obniżonego MTU tunelu.
Slide 27

Jednym z najbardziej uciążliwych i podstępnych problemów w sieciach VPN jest sytuacja, w której narzędzia diagnostyczne ICMP (ping) o małym ładunku działają wzorowo, natomiast ruch produkcyjny (strony WWW HTTPS, transfer plików, sesje RDP) zawiesza się lub działa z drastycznie obniżoną prędkością. Przyczyną jest przekroczenie jednostki MTU przez pełnowymiarowe pakiety TCP. Szczegółowe informacje normatywne i techniczne publikuje Specyfikacja parametru TCP Maximum Segment Size (RFC 879).

Każdy tunel VPN dodaje do oryginalnego pakietu własne nagłówki transportowe i kryptograficzne (IP, UDP/GRE, nagłówki bezpieczeństwa ESP, podpisy ICV/MAC), co zmniejsza dostępną przestrzeń dla danych użytkownika (MTU spada np. z 1500 do 1400 bajtów). Jeżeli stacja robocza nada pakiet o rozmiarze 1500 bajtów z ustawioną flagą DF (Don't Fragment), a w sieci zablokowano pakiety ICMP Type 3 Code 4, następuje ciche odrzucenie pakietu (Black Hole MTU).

Mechanizm MSS Clamping rozwiązuje ten problem bezpośrednio na routerze brzegowym bez konieczności rekonfiguracji systemów operacyjnych na setkach stacji roboczych. Zapora sieciowa monitoruje pakiety nawiązywania połączenia TCP z ustawioną flagą SYN i dynamicznie modyfikuje zawarte w nich pole opcji Maximum Segment Size, obniżając je do bezpiecznej wartości.

W systemie MikroTik regułę implementuje się w łańcuchu forward zapory Mangle: /ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn tcp-mss=1401-65535 action=change-mss new-tcp-mss=clamp-to-pmtu passthrough=yes. Sprawia to, że stacje końcowe od samego początku nadają mniejsze segmenty, trwale eliminując fragmentację. Standard parametru MSS definiuje dokument IETF RFC 879.

Wyjaśnienie skrótów użytych na slajdzie:
MSS - Maximum Segment Size - Maksymalny rozmiar ładunku segmentu danych TCP bez nagłówków.
MTU - Maximum Transmission Unit - Maksymalny rozmiar jednostki ramki w warstwie sieciowej.
DF - Don't Fragment - Flaga w nagłówku IP zabraniająca fragmentacji pakietu.
RDP - Remote Desktop Protocol - Protokół zdalnego pulpitu firmy Microsoft.

28/40 Mechanizm Proxy-ARP: symulacja wspólnej sieci (L2)
Przedstawienie zasady działania i ryzyk związanych z mechanizmem Proxy-ARP umożliwiającym symulację jednolitej przestrzeni adresowej przez router warstwy 3.
  • Proxy-ARP stosowane, gdy chcemy udawać, że hosty w oddziale są częścią tej samej podsieci co w centrali bez budowania mostu L2.
  • Router odpowiada na zapytania ARP w imieniu zdalnych hostów.
  • Rozwiązanie ryzykowne i trudne w diagnostyce - zalecane jedynie w specyficznych, rzadkich scenariuszach.
Proxy-ARP: Technika, w której router odpowiada własnym adresem sprzętowym MAC na zapytania ARP skierowane do hostów znajdujących się w innej podsieci lub za tunelem wirtualnym, pośrednicząc w transmisji.
Slide 28

W niektórych specyficznych scenariuszach wdrożeniowych zachodzi potrzeba przydzielenia zdalnym klientom VPN (np. pracownikom łączącym się przez SSTP lub L2TP) adresów IP pochodzących z dokładnie tej samej podsieci co lokalna sieć LAN w centrali (np. 192.168.1.0/24), bez stosowania zaawansowanych tuneli warstwy 2 (mostkowania). Szczegółowe informacje normatywne i techniczne publikuje Implementacja przezroczystych bram podsieci za pomocą Proxy-ARP (RFC 1027).

W normalnych warunkach komputery w sieci LAN szukając innego adresu z tej samej podsieci wysyłają zapytanie rozgłoszeniowe ARP: 'Kto ma adres 192.168.1.200?'. Ponieważ zdalny klient znajduje się za logicznym interfejsem warstwy 3, zapytanie rozgłoszeniowe do niego nie dociera i stacja lokalna nie może przesłać ramki do partnera.

Aktywacja mechanizmu Proxy-ARP na wewnętrznym interfejsie routera centralnego (arp=proxy-arp) zmusza router do podsłuchiwania zapytań ARP. Jeśli zapytanie dotyczy adresu IP, do którego router posiada trasę przez tunel VPN, router odpowiada na zapytanie ARP, podstawiając swój własny adres MAC karty Ethernet, po czym odbiera ramki i przekazuje je do tunelu.

Chociaż Proxy-ARP jest szybkim i wygodnym rozwiązaniem doraźnym, niesie ze sobą poważne zagrożenia: maskuje błędy konfiguracji masek podsieci, zanieczyszcza tablice ARP stacji roboczych i może prowadzić do powstawania trudnych do zdiagnozowania pętli sieciowych w przypadku błędnej rekonfiguracji. Standard implementacji mechanizmu Proxy-ARP standaryzuje dokument IETF RFC 1027.

Wyjaśnienie skrótów użytych na slajdzie:
ARP - Address Resolution Protocol - Protokół rozwiązywania adresów logicznych IP na adresy fizyczne MAC.
MAC - Media Access Control - Fizyczny adres sprzętowy karty sieciowej.
LAN - Local Area Network - Lokalna sieć komputerowa.
SSTP - Secure Socket Tunneling Protocol - Protokół tunelowania bezpiecznych gniazd firmy Microsoft.

29/40 Zjawisko wycieku tras (Route Leaking)
Przedstawienie ryzyk związanych z przypadkowym wyciekiem tras prywatnych do sieci publicznej lub pomiędzy odizolowanymi instancjami VRF.
  • Analiza zjawiska wycieku tras (Route Leaking) obejmuje dwa odmienne aspekty inżynierskie:
  • 1. Zagrożenie: Niekontrolowany wyciek tras prywatnych:
    • Błędna konfiguracja protokołu BGP rozgłaszająca prefiksy prywatne (RFC 1918) do operatorów ISP lub przypadkowe wstrzyknięcie tras domyślnych do OSPF.
    • Mitygacja: Bezwzględne wdrażanie rygorystycznych filtrów tras (Routing Filters) na każdym punkcie styku sieci.
  • 2. Praktyka inżynierska: Kontrolowany wyciek tras w VRF (Inter-VRF Leaking):
    • Celowe udostępnianie określonych zasobów (np. centralnej bramy internetowej lub serwera bazodanowego) pomiędzy odseparowanymi wirtualnymi tablicami routingu.
    • W systemie RouterOS v7 realizuje się go za pomocą tablicy reguł: /routing rule add dst-address=10.0.0.0/8 action=lookup table=main.
Wyciek tras (Route Leaking): Nieautoryzowana lub błędna propagacja wewnętrznych prefiksów sieciowych poza wyznaczone granice administracyjne, np. rozgłoszenie prywatnych adresów RFC 1918 do globalnego Internetu.
Slide 29

Wyciek tras (Route Leaking) jest jednym z najpoważniejszych incydentów konfiguracyjnych w teleinformatyce. Może występować na styku sieci korporacyjnej z operatorem ISP (rozgłoszenie tras prywatnych przez BGP) lub wewnątrz infrastruktury wielotenantowej (niezamierzona wymiana tras pomiędzy ściśle odseparowanymi instancjami VRF). Szczegółowe informacje normatywne i techniczne publikuje Oficjalny portal krajowego zespołu CERT Polska (NASK).

W przypadku wycieku tras do globalnego Internetu, nieprawidłowo skonfigurowany router brzegowy ogłasza do zewnętrznych dostawców prefiksy prywatne lub wewnętrzne podsieci firmy. O ile odpowiedzialni operatorzy filtrują bloki bogon i RFC 1918, o tyle błąd może spowodować niepożądane przejęcie ruchu tranzytowego lub ujawnienie wewnętrznej topologii sieci korporacyjnej atakującym.

W wirtualizacji VRF kontrolowany wyciek tras (Inter-VRF Route Leaking) bywa stosowany celowo, np. w celu zapewnienia różnym klientom dostępu do wspólnego serwera bazodanowego lub bramy internetowej. W systemie RouterOS realizuje się go za pomocą tablic reguł w /routing rule z parametrem action=lookup, precyzyjnie definiując dozwolone prefiksy docelowe.

Niekontrolowany wyciek tras stanowi naruszenie strefy bezpieczeństwa sieci i może umożliwić intruzowi z niezabezpieczonej sieci gościnnej bezpośredni atak na infrastrukturę zarządzającą routerami. Ocenę incydentów sieciowych i bezpieczeństwa teleinformatycznego w Polsce publikuje oficjalny zespół CERT Polska.

Wyjaśnienie skrótów użytych na slajdzie:
VRF - Virtual Routing and Forwarding - Wirtualna tablica trasowania.
BGP - Border Gateway Protocol - Protokół routingu międzydomenowego.
ISP - Internet Service Provider - Dostawca usług internetowych.
CSIRT - Computer Security Incident Response Team - Zespół reagowania na incydenty bezpieczeństwa komputerowego.

30/40 Praktyka: Konfiguracja OSPF Point-to-Point
Przedstawienie kompletnego scenariusza laboratoryjnego konfiguracji protokołu OSPFv2 na wirtualnym tunelu GRE z wykorzystaniem RouterOS v7.
  • # Konfiguracja routera oddziałowego
/routing ospf instance add name=default-ospf
/routing ospf interface add interface=tunel-gre-1 network-type=point-to-point
/routing ospf network add network=10.0.0.0/30 area=backbone
/routing ospf network add network=192.168.10.0/24 area=backbone
  • Użycie typu point-to-point gwarantuje najszybszą stabilizację połączenia sąsiedzkiego.
Wdrożenie OSPF Point-to-Point: Procedura inżynierska uruchomienia procesu routingu dynamicznego na dedykowanym interfejsie dwupunktowym, zapewniająca natychmiastowe nawiązanie relacji Full Adjacency bez powoływania ról DR i BDR.
Slide 30

W części praktycznej modułu laboratoryjnego studenci realizują pełne wdrożenie protokołu OSPFv2 na łączu tunelowym GRE zestawionym pomiędzy routerem centralnym R1 a routerem oddziałowym R2. Po zestawieniu tunelu z wirtualną adresacją 10.255.0.0/30 przystępuje się do konfiguracji procesu trasowania. Szczegółowe informacje normatywne i techniczne publikuje Praktyki zapobiegania wyciekom tras i filtrowania w routingu (RFC 7454).

Na routerze R1 tworzy się instancję OSPF z unikalnym identyfikatorem router-id=1.1.1.1 oraz definiuje szkieletowy obszar Area 0. Następnie w nowej architekturze RouterOS v7 tworzy się szablon interfejsu przypisany do utworzonego tunelu: /routing ospf interface-template add area=backbone interfaces=gre-tun-r2 networks=10.255.0.0/30 type=ptp cost=10.

Analogiczną konfigurację wprowadza się na routerze oddziałowym R2, ustawiając router-id=2.2.2.2. Dodatkowo w osobnym szablonie deklaruje się lokalną sieć LAN (np. 192.168.20.0/24) jako interfejs pasywny (passive=yes), co pozwala na rozgłoszenie trasy do oddziału w pakietach LSA bez wysyłania zbędnych komunikatów Hello do stacji roboczych pracowników.

Weryfikacja poprawności polega na sprawdzeniu stanu sąsiada w /routing ospf neighbor print. Status powinien natychmiast przyjąć wartość 'Full'. W tablicy /ip route print pojawi się automatycznie dynamiczna trasa z flagami 'DAo' (Dynamic, Active, OSPF). Wytyczne dotyczące filtrowania i zapobiegania wyciekom tras określa standard IETF RFC 7454.

Wyjaśnienie skrótów użytych na slajdzie:
GRE - Generic Routing Encapsulation - Standardowy protokół tunelowania pakietów IP.
OSPF - Open Shortest Path First - Hierarchiczny protokół trasowania wewnętrznego.
PTP - Point-to-Point - Model komunikacji bezpośredniej dwupunktowej.
LSA - Link-State Advertisement - Jednostka ogłoszenia stanu łącza w protokole OSPF.

31/40 Praktyka: PBR dla wybranych gości
Przedstawienie laboratoryjnej implementacji Policy-Based Routing wymuszającej skierowanie ruchu sieci gościnnej przez wirtualny tunel VPN.
  • Separacja ruchu: Goście (VLAN 20) kierowani do zapasowego łącza mobilnego.
  • /ip firewall mangle add chain=prerouting src-address=192.168.20.0/24 
action=mark-routing new-routing-mark=do_sieci_lte
/ip route add gateway=192.168.8.1 routing-mark=do_sieci_lte
/ip route add gateway=1.1.1.1 (Brama główna bez oznaczeń)
Wdrożenie PBR dla podsieci: Praktyczna konfiguracja reguł znakowania pakietów i wirtualnych tablic routingu, zmuszająca pakiety pochodzące z określonej podsieci do korzystania z wyznaczonego tunelu wyjściowego.
Slide 31

Scenariusz laboratoryjny zakłada wymuszenie polityki bezpieczeństwa, w której komputery podłączone do sieci gościnnej (VLAN 100, podsieć 172.20.100.0/24) nie mogą korzystać z bezpośredniego wyjścia do Internetu przez lokalne łącze brzegowe, lecz ich cały ruch musi zostać przetransportowany tunelem VPN do centralnego węzła inspekcji treści. Szczegółowe informacje normatywne i techniczne publikuje Podręcznik narzędzia iptables w systemie Linux (Netfilter).

Pierwszym krokiem w RouterOS v7 jest utworzenie dedykowanej tablicy FIB: /routing table add name=ruch-goście fib. Następnie w łańcuchu prerouting zapory Mangle administrator tworzy regułę znakującą pakiety ze źródłem gości: /ip firewall mangle add chain=prerouting src-address=172.20.100.0/24 action=mark-routing new-routing-mark=ruch-goście passthrough=no.

W kolejnym etapie do nowo utworzonej tablicy FIB dodaje się trasę domyślną wskazującą wirtualny interfejs tunelowy: /ip route add dst-address=0.0.0.0/0 gateway=tunel-centrala routing-table=ruch-goście. Ruch z sieci produkcyjnej LAN (np. 192.168.1.0/24) pozostaje nieoznaczony i korzysta ze standardowej tablicy main.

Weryfikacja polega na uruchomieniu polecenia traceroute ze stacji gościa: pierwszy skok po bramie lokalnej wskazuje od razu wewnętrzny adres centrali, podczas gdy stacja administratora wychodzi bezpośrednio przez bramę ISP. Narzędzia inspekcji i modyfikacji nagłówków pakietów w Linuksie opisuje podręcznik man iptables.

Wyjaśnienie skrótów użytych na slajdzie:
PBR - Policy Based Routing - Routing oparty na regułach zapory i politykach.
FIB - Forwarding Information Base - Tablica przekazywania pakietów powiązana z tablica routingu.
VLAN - Virtual Local Area Network - Wirtualna sieć lokalna.
ISP - Internet Service Provider - Operator telekomunikacyjny.

32/40 Metryki i sterowanie kosztem (Cost)
Przedstawienie metod inżynierskiego sterowania ścieżkami przepływu pakietów w sieciach VPN za pomocą manipulacji parametrem kosztu (Cost) w OSPF.
  • W OSPF wybór trasy bazuje na najniższym sumarycznym koszcie (Cost).
  • Standardowo koszt zależy od prędkości medium (tzw. Reference Bandwidth).
  • Administrator może ręcznie "podnieść koszt" łącza zapasowego (np. tunelu na łączu satelitarnym), aby był on wykorzystywany tylko w ostateczności.
  • /routing ospf interface set tunel-gre-1 cost=1000.
Koszt łącza OSPF (Interface Cost): Odwrotność przepustowości łącza stanowiąca metrykę przypisaną do interfejsu w protokole OSPF, decydująca o sumarycznym koszcie ścieżki obliczanym przez algorytm SPF.
Slide 32

W protokole OSPF algorytm Dijkstry wyznacza ścieżkę o najniższym łącznym koszcie metryki od węzła źródłowego do podsieci docelowej. Domyślnie koszt interfejsu obliczany jest ze wzoru: Cost = Reference_Bandwidth / Interface_Bandwidth. Administrator posiada pełną kontrolę nad ręcznym nadpisywaniem tego parametru na każdym interfejsie tunelowym. Szczegółowe informacje normatywne i techniczne publikuje Specyfikacja protokołu RIPv2 i analiza metryk trasowania (RFC 2453).

Sterowanie kosztem jest podstawowym narzędziem inżynierii ruchu (Traffic Engineering). Jeśli oddział posiada dwa równoległe tunele VPN: główny tunel światłowodowy o dużej przepustowości oraz tunel rezerwowy zestawiony przez łącze komórkowe LTE o ograniczonej pojemności, administrator przypisuje tunelowi głównemu niski koszt (np. cost=10), a tunelowi LTE wysoki koszt (np. cost=100).

Dopóki oba tunele funkcjonują, OSPF skieruje całość ruchu przez tunel o niższym koszcie. W momencie fizycznej awarii łącza podstawowego OSPF automatycznie przekieruje ruch na tunel rezerwowy. Po usunięciu awarii ruch bezzwłocznie powróci na ścieżkę podstawową bez konieczności jakiejkolwiek interwencji administratora.

Warto zauważyć, że domyślna przepustowość referencyjna OSPF (100 Mbps) jest przestarzała w dobie łączy wielogigabitowych (traktuje łącze 1 Gbps i 10 Gbps z tym samym kosztem równym 1). W nowoczesnych wdrożeniach należy podnieść parametr reference-bandwidth w instancji OSPF do wartości minimum 10 Gbps lub 100 Gbps. Ewolucję metryk w protokołach trasowania opisuje dokument IETF RFC 2453.

Wyjaśnienie skrótów użytych na slajdzie:
OSPF - Open Shortest Path First - Hierarchiczny protokół trasowania stanu łącza.
SPF - Shortest Path First - Algorytm najkrótszej ścieżki w grafie połączeń.
LTE - Long Term Evolution - Standard łączności komórkowej czwartej generacji.
Gbps - Gigabits per second - Miliard bitów na sekundę.

33/40 Redystrybucja tras zewnętrznych
Przedstawienie zasad bezpiecznej redystrybucji tras pomiędzy routingiem statycznym, trasami bezpośrednio podłączonymi a protokołem OSPF.
  • Mechanizm włączania tras "nie-OSPF" do tablic oddziałów.
  • Najczęstszy przypadek: Rozgłaszanie bramy domyślnej (Internetu) z Centrali do Oddziałów.
  • W ustawieniach instancji: distribute-default=if-installed-as-type-1.
  • Uwaga: Nieprzemyślana redystrybucja wszystkich tras podłączonych (Connected) może prowadzić do powstania pętli routingu.
Redystrybucja tras (Route Redistribution): Proces importowania i tłumaczenia informacji o prefiksach sieciowych z jednego protokołu routingu (lub ze źródeł statycznych/connected) do bazy danych innego protokołu trasowania.
Slide 33

W środowiskach laboratoryjnych i produkcyjnych bardzo rzadko spotyka się sytuację, w której cała organizacja korzysta wyłącznie z jednego protokołu routingu. Często zachodzi potrzeba przekazania tras wyuczonych ze statycznych połączeń VPN do protokołu dynamicznego OSPF działającego w centrali, aby wszystkie routery rdzeniowe dowiedziały się o istnieniu odległych podsieci. Szczegółowe informacje normatywne i techniczne publikuje Mechanizmy kontroli polityk i redystrybucji tras w sieciach IP (RFC 5130).

Proces ten nosi nazwę redystrybucji tras. Router wykonujący redystrybucję do OSPF staje się w terminologii protokołu autonomicznym routerem granicznym ASBR (Autonomous System Boundary Router) i generuje specjalne ogłoszenia LSA Typu 5 (External LSA), rozsyłane po całej domenie OSPF.

W systemie RouterOS v7 redystrybucję konfiguruje się bezpośrednio w instancji OSPF za pomocą parametru redistribute: /routing ospf instance set ospf-inst redistribute=static,vpn,connect. Można również określić domyślny typ metryki (Type 1 - koszt sumuje się po drodze, lub Type 2 - koszt zewnętrzny jest stały w całej domenie).

Kardynalną zasadą inżynierską przy redystrybucji jest bezwzględna konieczność stosowania filtrów tras (Routing Filters). Bezmyślna redystrybucja bez filtrów może doprowadzić do wstrzyknięcia do OSPF trasy domyślnej 0.0.0.0/0 lub niepożądanych tras dostawców ISP, wywołując paraliżujący pętlę routingu w całej korporacji. Standardy bezpiecznej redystrybucji reguluje dokument IETF RFC 5130.

Wyjaśnienie skrótów użytych na slajdzie:
ASBR - Autonomous System Boundary Router - Router graniczny redystrybuujacy trasy zewnętrzne do OSPF.
LSA - Link-State Advertisement - Ogłoszenie stanu łącza w protokole OSPF.
AS - Autonomous System - System autonomiczny pod jednolita kontrola administracyjna.
OSPF - Open Shortest Path First - Protokół trasowania stanu łącza.

34/40 Filtrowanie tras (Routing Filters)
Przedstawienie architektury filtrów routingu w RouterOS v7 w celu kontroli propagacji prefiksów i zapobiegania infekcjom tablic routingu.
  • Bezpieczeństwo: Nie chcemy, aby oddział w Gdańsku widział trasy oddziału w Krakowie.
  • Używamy Routing Filters do akceptacji tylko określonych prefiksów IP.
  • Filtr wejściowy chroni tabelę lokalną przed błędami sąsiada.
  • Zasada: action=accept dla moich sieci, action=discard dla całej reszty świata.
Filtry routingu (Routing Filters): Programistyczny zestaw reguł warunkowych w routerze pozwalający na akceptowanie, odrzucanie lub modyfikację atrybutów tras sieciowych przed ich instalacją w tablicy FIB lub wysłaniem do sąsiadów.
Slide 34

W rozbudowanych sieciach tunelowych filtracja tras jest podstawowym mechanizmem gwarantującym stabilność i cyberbezpieczeństwo infrastruktury. Router nie powinien bezkrytycznie ufać wszystkim prefiksom rozgłaszanym przez sąsiadów, zwłaszcza jeśli łącze tunelowe łączy sieć firmową z zewnętrznym partnerem biznesowym lub podwykonawcą. Szczegółowe informacje normatywne i techniczne publikuje Analiza bezpieczeństwa i zagrożeń w protokołach routingu (RFC 4272).

W systemie MikroTik RouterOS v7 podsystem Routing Filters został całkowicie przepisany na nowoczesny, wysoce wydajny język skryptowy przypominający składnię języków programowania. W nowym modelu reguły definiuje się w gałęzi /routing filter rule, tworząc tzw. łańcuchy (chains) filtrowania.

Przykładowa reguła chroniąca przed przyjęciem nieautoryzowanych tras prywatnych może przyjąć postać: /routing filter rule add chain=filtr-ospf-in rule="if (dst in 10.0.0.0/8 && dst-len <= 24) { accept } else { reject }". Taki filtr bezwzględnie odrzuca próby wstrzyknięcia zbyt szczegółowych tras hostowych (/32) lub tras spoza przydzielonego zakresu organizacyjnego.

Stosowanie rygorystycznych filtrów tras wejściowych (Inbound) i wyjściowych (Outbound) zapobiega powstawaniu pętli routingu, chroni przed atakami typu Route Hijacking oraz uniemożliwia przypadkowy wyciek poufnych podsieci laboratoryjnych na zewnątrz. Analizę podatności i metod zabezpieczania protokołów trasowania przedstawia dokument IETF RFC 4272.

Wyjaśnienie skrótów użytych na slajdzie:
FIB - Forwarding Information Base - Baza informacyjna przekazywania pakietów.
OSPF - Open Shortest Path First - Protokół trasowania wewnętrznego.
CLI - Command Line Interface - Tekstowy interfejs wiersza poleceń.
IP - Internet Protocol - Protokół warstwy sieciowej.

35/40 Routing IPv6 w tunelach
Przedstawienie specyfiki trasowania nowoczesnego protokołu IPv6 w tunelach VPN z uwzględnieniem adresacji Link-Local i protokołu OSPFv3.
  • Nowoczesne protokoły routingu (np. OSPFv3) wspierają natywną adresację IPv6.
  • Powszechnie stosuje się tunele typu Dual-Stack (IPv4+IPv6) lub tunele IPv6 "przerzucone" nad infrastrukturą IPv4 (tzw. Tunnel Broker).
  • Tablice routingu dla IPv6 są w systemach sieciowych całkowicie odseparowane od tradycyjnych tablic IPv4.
Routing IPv6 w tunelach: Kierowanie pakietów 128-bitowej przestrzeni adresowej IPv6 przez wirtualne interfejsy tunelowe, wykorzystujące adresy lokalne łącza (Link-Local fe80::/10) jako adresy następnego skoku.
Slide 35

Współczesne sieci korporacyjne w coraz większym stopniu wdrażają podwójny stos protokołów (Dual-Stack IPv4/IPv6). W przypadku tuneli VPN rodzi to konieczność równoległego trasowania pakietów IPv6 wewnątrz tych samych wirtualnych kanałów transmisyjnych (np. GRE, WireGuard, OpenVPN lub IPsec). Szczegółowe informacje normatywne i techniczne publikuje Specyfikacja protokołu Internet Protocol Version 6 - IPv6 (RFC 8200).

Fundamentalną różnicą inżynierską pomiędzy routingiem IPv4 a IPv6 jest rola adresów lokalnych łącza (Link-Local Addresses z prefiksu fe80::/10). W protokole IPv6 routery nie używają adresów globalnych (GUA) do wyznaczania następnego skoku w tablicy routingu; zamiast tego brama trasy wskazuje bezpośrednio adres Link-Local sąsiedniego routera powiązany z danym interfejsem tunelowym (np. via fe80::1 dev gre-tun1).

Do dynamicznej wymiany tras IPv6 w tunelach służy dedykowany protokół OSPFv3 zdefiniowany w RFC 5340. Protokół ten działa niezależnie od warstwy sieciowej, przesyłając komunikaty sterujące bezpośrednio na adresy grupowe IPv6: ff02::5 (AllSPFRouters) oraz ff02::6 (AllDRouters).

Ponieważ w protokole IPv6 zrezygnowano z mechanizmu fragmentacji pakietów na routerach pośredniczących (fragmentacji może dokonać wyłącznie host źródłowy), kwestia poprawnego skonfigurowania MTU tunelu oraz prawidłowego działania komunikatów ICMPv6 Packet Too Big (Typ 2) staje się kwestią krytyczną dla utrzymania łączności. Standard architektury IPv6 określa oficjalna specyfikacja IETF RFC 8200.

Wyjaśnienie skrótów użytych na slajdzie:
IPv6 - Internet Protocol Version 6 - Protokół internetowy nowej generacji ze 128-bitowa adresacja.
GUA - Global Unicast Address - Globalny unikalny publiczny adres IPv6.
MTU - Maximum Transmission Unit - Maksymalna wielkość ramki sieciowej.
ICMPv6 - Internet Control Message Protocol for IPv6 - Protokół kontrolny i diagnostyczny dla IPv6.

36/40 Podsumowanie: statyczny czy dynamiczny?
Synteza kryteriów doboru metody routingu w tunelach VPN w zależności od skali wdrożenia, topologii, wymagań SLA i kompetencji kadry.
  • Routing Statyczny: Idealny do małych struktur (1-3 punkty). Prosty w wdrażaniu, ale absorbujący przy zmianach.
  • Routing Dynamiczny (OSPF): Niezbędny w sieciach o wysokim tempie rozwoju. Gwarantuje samonaprawianie się ścieżek i łatwość zarządzania tysiącami hostów.
  • Rada dla administratora: Automatyzuj wtedy, gdy ręczne wpisy zaczynają generować błędy.
Macierz decyzyjna routingu VPN: Zestawienie inżynierskich kryteriów technicznych i operacyjnych determinujących wybór pomiędzy routingiem statycznym, OSPF a protokołem BGP w środowiskach tunelowych.
Slide 36

Wybór optymalnej strategii trasowania w wirtualnych sieciach prywatnych wymaga wyważenia pomiędzy prostotą wdrożenia a elastycznością i odpornością sieci na awarie. Nie istnieje jedno uniwersalne rozwiązanie dobre dla każdego scenariusza inżynierskiego. Szczegółowe informacje normatywne i techniczne publikuje Wytyczne bezpieczeństwa protokołów routingu brzegowego - NIST SP 800-54.

Dla prostych połączeń dwupunktowych Site-to-Site (np. połączenie głównego biura z małym magazynem) oraz połączeń zdalnych użytkowników mobilnych w zupełności wystarcza klasyczny routing statyczny wsparty mechanizmem Check Gateway lub opcją DHCP 121. Rozwiązanie to jest bezobsługowe, stabilne i nie generuje żadnego ruchu kontrolnego.

W przypadku średnich i dużych przedsiębiorstw posiadających topologię siatkową (Full/Partial Mesh) lub powyżej pięciu oddziałów bezwzględnym standardem staje się protokół dynamiczny OSPFv2/OSPFv3. Zapewnia on błyskawiczne samonaprawianie ścieżek, automatyczne rozgłaszanie nowych podsieci i przejrzystą segmentację na obszary logiczne.

Z kolei w środowiskach operatorskich, rozległych sieciach SD-WAN oraz w hybrydowych połączeniach z chmurami publicznymi dominuje protokół BGP, gwarantujący pełną skalowalność, zaawansowane filtrowanie atrybutów oraz izolację awarii. Zalecenia dotyczące projektowania bezpiecznych architektur trasowania publikuje agencja NIST w publikacji specjalnej SP 800-54.

Wyjaśnienie skrótów użytych na slajdzie:
SLA - Service Level Agreement - Gwarancja poziomu jakości usług sieciowych.
OSPF - Open Shortest Path First - Wewnętrzny protokół trasowania stanu łącza.
BGP - Border Gateway Protocol - Zewnętrzny protokół wektora ścieżki.
SD-WAN - Software-Defined Wide Area Network - Programowo definiowalne sieci rozlegle.

37/40 Katalog najczęstszych błędów
Identyfikacja, analiza przyczyn i metody usuwania najczęstszych błędów konfiguracyjnych w routingu tuneli VPN.
  • 1. Asymetryczny routing: Pakiet wychodzi jedną drogą, a system próbuje odesłać go inną (Firewall często blokuje taki ruch).
  • 2. Nakładanie się adresacji (Overlapping): Stosowanie identycznych podsieci LAN po obu stronach tunelu uniemożliwia poprawny routing.
  • 3. Błędy związane z rozmiarem MTU: Parametry uniemożliwiające przesyłanie pełnych ramek danych przez tunel.
  • 4. Braki w Firewallu: Zapomnienie o odblokowaniu protokołów routingu (np. OSPF Multicast) wewnątrz tunelu.
Błąd asymetrii routingu (Asymmetric Routing): Zjawisko, w którym pakiety przesyłane z węzła A do węzła B wędrują inną ścieżką sieciową niż pakiety odpowiedzi z węzła B do węzła A, powodujące blokowanie sesji przez stanowe zapory sieciowe.
Slide 37

Wieloletnia praktyka inżynierska i laboratoryjna pozwala na wyodrębnienie powtarzających się schematów błędów popełnianych podczas wdrażania routingu w strukturach tunelowych. Najpoważniejszym z nich jest asymetria routingu (Asymmetric Routing). Występuje ona, gdy pakiet zapytania trafia do celu szybkim tunelem VPN, natomiast pakiet odpowiedzi wraca przez inne łącze lub Internet. Szczegółowe informacje normatywne i techniczne publikuje Dokumentacja filtrów protokołu OSPF w analizatorze Wireshark.

W obecności stanowych zapór ogniowych (Stateful Firewall) asymetria skutkuje natychmiastowym porzuceniem pakietu powrotnego, ponieważ zapora na routerze odbierającym odpowiedź nie widziała pakietu inicjującego SYN i traktuje pakiet jako nielegalną anomalię (flaga TCP Invalid State).

Drugim kardynalnym błędem jest brak wykluczenia ruchu szyfrowanego z mechanizmu FastTrack w systemie MikroTik RouterOS. Pakiet dopasowany przez FastTrack omija tablice polityk IPsec i zostaje wysłany do Internetu jawnym tekstem bez zaszyfrowania lub bezpowrotnie porzucony przez router dostępowy.

Trzecim powszechnym problemem jest zignorowanie narzutu nagłówków i brak konfiguracji MSS Clamping, objawiający się poprawnym działaniem prostych komend tekstowych przy całkowitym paraliżu transmisji wielkich wolumenów danych w protokole HTTPS. Narzędzia do analizy i deszyfrowania pakietów OSPF udostępnia oficjalna dokumentacja projektu Wireshark.

Wyjaśnienie skrótów użytych na slajdzie:
SYN - Synchronize Flag - Flaga nawiązywania połączenia w protokole TCP.
TCP - Transmission Control Protocol - Połączeniowy protokół transportowy.
MTU - Maximum Transmission Unit - Maksymalna jednostka danych warstwy sieciowej.
IPsec - Internet Protocol Security - Zestaw standardów kryptograficznych warstwy IP.

38/40 Niezbędnik diagnostyczny
Przedstawienie zestawu poleceń i procedur inżynierskich służących do systematycznej diagnostyki zaburzeń routingu w tunelach VPN.
  • Traceroute - pokazuje faktyczną ścieżkę pakietu i węzły tranzytowe.
  • Torch / Sniffer - narzędzia pozwalające podejrzeć ruch na żywo na interfejsach VPN.
  • Routing Print Detail - ujawnia ukryte flagi i przyczyny nieaktywności poszczególnych tras.
  • Ping z zadanym rozmiarem MTU - test do weryfikacji problemów z fragmentacją i MTU.
Niezbędnik diagnostyczny inżyniera sieci: Usystematyzowany zestaw narzędzi systemowych i procedur analitycznych weryfikujący krok po kroku spójność warstw fizycznej, łącza danych, sieciowej i transportowej.
Slide 38

W przypadku wystąpienia awarii w tunelu VPN inżynier sieciowy powinien postępować według rygorystycznej metodologii opartej na modelu warstwowym ISO/OSI, eliminując potencjalne przyczyny od najniższej do najwyższej warstwy, zamiast podejmować chaotyczne próby modyfikacji konfiguracji. Szczegółowe informacje normatywne i techniczne publikuje Oficjalny podręcznik analizatora pakietów tcpdump.

Diagnostykę rozpoczyna się od warstwy 3 podkładowej: weryfikacji osiągalności publicznych adresów IP bram za pomocą polecenia ping oraz sprawdzenia stanu fizycznego interfejsu WAN. Następnie bada się stan logiczny wirtualnego interfejsu tunelu (flagi 'R' - Running w systemie RouterOS).

Kolejnym etapem jest analiza tablicy routingu: polecenie /ip route print detail pozwala zweryfikować obecność flagi 'A' (Active) przy trasie do odległej podsieci oraz sprawdzić status następnego skoku (reachable). W przypadku protokołów dynamicznych polecenia /routing ospf neighbor print oraz /routing ospf route print ujawniają stan relacji sąsiedztwa i wyliczone metryki ścieżek.

W sytuacjach nietypowych niezastąpionym narzędziem staje się wbudowany w systemy RouterOS i Linux sniffer pakietów (Packet Sniffer / tcpdump). Przechwycenie ruchu na fizycznym porcie WAN oraz logicznym porcie tunelowym pozwala natychmiast stwierdzić, czy pakiety są poprawnie enkapsulowane i czy router otrzymuje pakiety powrotne. Podręcznik narzędzia do analizy ruchu sieciowego udostępnia dokumentacja tcpdump.

Wyjaśnienie skrótów użytych na slajdzie:
OSI - Open Systems Interconnection - Model referencyjny warstw sieciowych.
WAN - Wide Area Network - Łącze rozlegle podłączone do Internetu.
OSPF - Open Shortest Path First - Dynamiczny protokół trasowania.
CLI - Command Line Interface - Tekstowy interfejs wiersza poleceń.

39/40 Zadania do samodzielnej analizy
Sformułowanie problemów inżynierskich i scenariuszy awaryjnych przeznaczonych do samodzielnego rozwiązania w środowisku laboratoryjnym.
  • 1. Zestaw dwa wirtualne routery połączone tunelem.
  • 2. Uruchom protokół OSPF i sprawdź, po jakim czasie trasa zniknie po celowym przerwaniu połączenia.
  • 3. Zmodyfikuj priorytet trasy (Distance), aby wymusić ruch przez konkretny tunel.
  • 4. Wykorzystaj mechanizm PBR do skierowania określonego typu ruchu (np. DNS) przez alternatywną ścieżkę.
Scenariusze laboratoryjne VPN: Praktyczne zadania inżynierskie odwzorowujące rzeczywiste wyzwania projektowe i awaryjne w wielooddziałowych sieciach korporacyjnych.
Slide 39

W celu utrwalenia wiedzy inżynierskiej i zdobycia praktycznych umiejętności diagnostycznych studenci otrzymują zestaw zaawansowanych scenariuszy problemowych do samodzielnej realizacji na stanowiskach laboratoryjnych wyposażonych w routery MikroTik. Szczegółowe informacje normatywne i techniczne publikuje Wytyczne cyberbezpieczeństwa sektora finansowego CSIRT KNF.

Zadanie pierwsze polega na zaprojektowaniu i wdrożeniu mechanizmu routingu rekurencyjnego (Recursive Routing) z wykorzystaniem dwóch niezależnych dostawców ISP. Studenci muszą skonfigurować tablicę routingu w taki sposób, aby router brzegowy badał dostępność publicznych serwerów referencyjnych przez każde z łączy i automatycznie przełączał tunel VPN w czasie poniżej 5 sekund od awarii łącza podstawowego.

Zadanie drugie wymaga skonfigurowania polityki PBR, w której cały ruch wygenerowany przez serwery bazodanowe w strefie DMZ jest kierowany przez tunel szyfrowany IPsec z priorytetem QoS, podczas gdy ruch stacji roboczych korzysta z tunelu GRE z dynamicznym OSPF.

Zadanie trzecie obejmuje diagnozę celowo wprowadzonego błędu asymetrii routingu i zablokowania sąsiedztwa OSPF na skutek sztucznego ograniczenia jednostki MTU. Studenci muszą zidentyfikować przyczynę awarii za pomocą narzędzi packet sniffer i traceroute oraz wdrożyć regułę MSS Clamping. Wytyczne dotyczące odporności infrastruktury teleinformatycznej publikuje CSIRT KNF.

Wyjaśnienie skrótów użytych na slajdzie:
DMZ - Demilitarized Zone - Strefa zdemilitaryzowana dla usług serwerowych.
QoS - Quality of Service - Mechanizmy zapewniania jakości transmisji pakietów.
GRE - Generic Routing Encapsulation - Protokół enkapsulacji pakietów.
MTU - Maximum Transmission Unit - Maksymalny rozmiar jednostki ramki w warstwie sieciowej.

40/40 Zapowiedź: część 6 - transmisja w warstwie 2 (L2 Extensions)
Przedstawienie zakresu tematycznego kolejnego modułu laboratoryjnego poświęconego rozszerzeniom warstwy 2 (L2 VPN, EoIP, VXLAN i BCP).
  • W kolejnym odcinku wyjdziemy poza tradycyjny routing L3: Tunele Ethernetowe i VLANy
  • Technologie EoIP oraz BCP.
  • VLANy wewnątrz bezpiecznych tuneli.
  • VXLAN - nowoczesne podejście do wirtualizacji sieci i tunelowania L2.
  • Kiedy mostkowanie sieci przez Internet jest błędem projektowym?
Wirtualna sieć prywatna warstwy 2 (L2 VPN): Technologia tunelowania pozwalająca na przezroczystą hermetyzację i transmisję pełnych ramek Ethernetowych (warstwa 2) przez sieć IP, tworząca logiczny wspólny segment rozgłoszeniowy pomiędzy odległymi lokalizacjami.
Slide 40

W niniejszym module laboratoryjnym skupiono się na routingu w warstwie 3 modelu OSI, gdzie odległe lokalizacje sieciowe posiadają odmienne podsieci logiczne, a pakiety są przekazywane przez routery na podstawie tablicy routingu i adresów IP. Podejście to jest wydajne, skalowalne i stanowi fundament współczesnych sieci korporacyjnych. Szczegółowe informacje normatywne i techniczne publikuje Specyfikacja technologii wirtualnych sieci nakładkowych VXLAN (RFC 7348).

Istnieją jednak liczne scenariusze przemysłowe i serwerowe, w których urządzenia w różnych lokalizacjach muszą znajdować się w dokładnie tym samym segmencie rozgłoszeniowym warstwy 2 (wspólna podsieć, współdzielona przestrzeń adresów MAC, konieczność migracji wirtualnych maszyn w klastrach bez zmiany IP lub obsługa urządzeń przemysłowych PLC komunikujących się wyłącznie ramkami Ethernet).

W kolejnej części kursu (Część 6: Tunele i VLANy) szczegółowo przeanalizujemy technologie przezroczystego mostkowania przez sieci rozległe WAN. Omówiony zostanie autorski protokół MikroTik EoIP (Ethernet over IP), protokół BCP (Bridge Control Protocol w PPP) oraz nowoczesne standardy centrów danych VXLAN (Virtual eXtensible LAN).

Zbadamy również wyzwania inżynierskie związane z narzutem nagłówków warstwy 2, ryzykiem powstawania pętli rozgłoszeniowych i koniecznością wdrażania protokołu drzewa rozpinającego RSTP (Rapid Spanning Tree Protocol) na łączach tunelowych. Standard enkapsulacji VXLAN opisuje dokument IETF RFC 7348.

Wyjaśnienie skrótów użytych na slajdzie:
EoIP - Ethernet over IP - Własnościowy protokół MikroTik hermetyzujący ramki Ethernet w pakietach IP.
VXLAN - Virtual eXtensible Local Area Network - Standard tunelowania warstwy 2 w nagłówkach UDP.
BCP - Bridge Control Protocol - Protokół mostkowania ramek w połączeniach PPP.
RSTP - Rapid Spanning Tree Protocol - Szybki protokół drzewa rozpinającego zapobiegający pętlom L2.