Współczesna architektura sieci rozległych opiera się na koncepcji wirtualizacji kanałów transmisyjnych, której historyczne fundamenty stanowiły klasyczne protokoły tunelowania. W dobie początkowego rozwoju sieci IP przedsiębiorstwa stawały przed wyzwaniem łączenia odległych oddziałów bez konieczności ponoszenia gigantycznych kosztów dzierżawy dedykowanych obwodów telekomunikacyjnych TDM. Odpowiedzią na tę potrzebę stała się technologia tunelowania, która pozwoliła na wykorzystanie publicznej infrastruktury pakietowej jako elastycznego nośnika dla prywatnego ruchu korporacyjnego. Szczegółowe informacje normatywne i techniczne publikuje Polskie Towarzystwo Informatyczne.

W ramach niniejszego modułu wykładowego szczegółowej analizie poddane zostaną trzy kluczowe technologie, które ukształtowały rozwój sieci VPN: Generic Routing Encapsulation (GRE), Point-to-Point Protocol (PPP) oraz Point-to-Point Tunneling Protocol (PPTP). Protokół GRE zdefiniował uniwersalny standard hermetyzacji pakietów warstwy sieciowej, umożliwiając przesyłanie wieloprotokołowego ruchu oraz informacji routingu dynamicznego przez jednorodne sieci tranzytowe. Standard PPP stworzył natomiast podwaliny pod bezpieczne zestawianie sesji punkt-punkt oraz zaawansowaną kontrolę łącza.

Zwieńczeniem tej ewolucji w latach dziewięćdziesiątych było opracowanie protokołu PPTP, który połączył mechanizmy ramkowania PPP z enkapsulacją GRE oraz kanałem sterowania opartym na protokole TCP. Rozwiązanie to zyskało ogromną popularność dzięki natywnej integracji z systemami operacyjnymi Microsoft Windows, stając się pierwszym powszechnym standardem zdalnego dostępu dla pracowników mobilnych. Mimo że współczesne standardy bezpieczeństwa uznają PPTP za przestarzały, zrozumienie jego architektury jest niezbędne do analizy podatności kryptograficznych.

W toku wykładu studenci zapoznają się z technicznymi aspektami budowy nagłówków, mechanizmami uzgadniania sesji, problematyką przechodzenia przez translację adresów NAT oraz konfiguracją urządzeń sieciowych w środowisku MikroTik RouterOS. Zrozumienie ograniczeń klasycznych protokołów tunelowania stanowi konieczny warunek do świadomego projektowania nowoczesnych, bezpiecznych sieci nakładkowych opartych na standardach IPsec oraz WireGuard.

Wyjaśnienie skrótów użytych na slajdzie:
GRE - Generic Routing Encapsulation - Uniwersalny protokół tunelowania warstwy sieciowej hermetyzujący pakiety wewnątrz pakietów IP.
PPP - Point-to-Point Protocol - Protokół łącza danych zapewniający komunikację punkt-punkt, uwierzytelnianie oraz negocjację parametrów sieciowych.
PPTP - Point-to-Point Tunneling Protocol - Protokół tunelowania VPN łączący kanał kontrolny TCP z danymi przesyłanymi w rozszerzonym protokole GRE.
IP - Internet Protocol - Podstawowy protokół warstwy internetowej odpowiedzialny za adresację i routing pakietów w sieciach komputerowych.
VPN - Virtual Private Network - Logiczna sieć prywatna zestawiana w publicznej infrastrukturze z zachowaniem separacji ruchu.
NAT - Network Address Translation - Mechanizm translacji adresów sieciowych umożliwiający współdzielenie publicznych adresów IP przez węzły lokalne.

Protokół Generic Routing Encapsulation (GRE) został zaprojektowany na początku lat dziewięćdziesiątych przez firmę Cisco Systems w celu rozwiązania problemu transportu heterogenicznych protokołów sieciowych przez jednorodne sieci IP. W ówczesnym środowisku teleinformatycznym powszechnie eksploatowano stosy protokołów takie jak IPX (Novell NetWare), AppleTalk czy DECnet, które nie posiadały wbudowanych mechanizmów routingu w globalnej sieci Internet. GRE umożliwił potraktowanie pakietów dowolnego z tych protokołów jako zwykłego ładunku danych. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 2784 (Specyfikacja GRE).

Wczesna specyfikacja protokołu została opisana w dokumencie informacyjnym RFC 1701 opublikowanym w 1994 roku. Wersja ta definiowała bardzo bogaty nagłówek zawierający liczne pola opcjonalne, w tym sumy kontrolne, klucze uwierzytelniające, numery sekwencyjne oraz mechanizmy routingu źródłowego. Nadmierna złożoność tej specyfikacji oraz brak powszechnej implementacji wszystkich opcji doprowadziły do konieczności uproszczenia protokołu w ramach prac standaryzacyjnych organizacji IETF.

Formalnym standardem internetowym stał się dokument RFC 2784 wydany w 2000 roku, który zdefiniował odchudzoną, uniwersalną postać nagłówka GRE o stałej długości 4 bajtów w wariancie podstawowym. Zredukowano w nim liczbę flag kontrolnych, zachowując jedynie opcjonalną sumę kontrolną oraz pole typu protokołu EtherType. Kolejny dokument, RFC 2890, wprowadził kompatybilne rozszerzenia przywracające opcjonalne pole klucza (Key) oraz numeru sekwencyjnego (Sequence Number), zachowując modularną strukturę ramki.

Kluczową cechą architektury GRE jest całkowity brak wbudowanych mechanizmów kryptograficznych. Protokół ten został zaprojektowany wyłącznie do enkapsulacji i routingu, co oznacza, że przesyłane dane podróżują przez sieć publiczną w postaci jawnej. Z tego względu w nowoczesnych projektach inżynierskich GRE jest powszechnie łączony ze stosem IPsec (technologia GRE over IPsec), gdzie GRE odpowiada za transport ruchu rozgłoszeniowego i protokołów routingu, a IPsec zapewnia poufność oraz integralność danych.

Wyjaśnienie skrótów użytych na slajdzie:
GRE - Generic Routing Encapsulation - Protokół tunelowania hermetyzujący pakiety sieciowe wewnątrz pakietów IP.
RFC - Request for Comments - Dokument techniczny publikowany przez IETF standaryzujący protokoły i technologie internetowe.
IETF - Internet Engineering Task Force - Międzynarodowa organizacja inżynieryjna zajmująca się rozwojem i standaryzacją protokołów internetowych.
PDU - Protocol Data Unit - Jednostka danych protokołu w określonej warstwie modelu odniesienia OSI.
IPX - Internetwork Packet Exchange - Protokół warstwy sieciowej wykorzystywany historycznie w systemach Novell NetWare.

Anatomia pakietu przesyłanego przez tunel GRE obejmuje trzy wyraźnie wydzielone warstwy danych: zewnętrzny nagłówek dostarczania (Delivery Header), nagłówek protokołu GRE oraz wewnętrzny pakiet ładunku (Payload Packet). Nagłówek dostarczania to standardowy nagłówek IPv4 lub IPv6, w którym pole Protocol (lub Next Header) przyjmuje stałą wartość dziesiętną 47. Adresy źródłowy i docelowy w tym nagłówku odpowiadają publicznym punktom końcowym tunelu. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 2890 (Klucz i sekwencja w GRE).

Sam nagłówek GRE w wariancie bazowym RFC 2784 ma długość 4 bajtów. Pierwsze dwa bajty zawierają bity flag kontrolnych oraz numer wersji protokołu (dla standardowego GRE pole wersji ma wartość 0). Najważniejszym elementem pierwszej części nagłówka jest flaga C (Checksum Present) - jej ustawienie na 1 oznacza, że nagłówek został powiększony o 4 bajty zawierające dwubajtową sumę kontrolną oraz dwubajtowe pole zarezerwowane. Druga połowa podstawowego nagłówka to 16-bitowe pole Protocol Type przechowujące kod EtherType ładunku.

W przypadku implementacji rozszerzeń opisanych w RFC 2890 nagłówek może zostać rozszerzony o kolejne pola opcjonalne. Ustawienie flagi K (Key Present) wprowadza 32-bitowe pole klucza (Key), które służy do logicznej identyfikacji przepływów lub podkanałów w ramach jednego tunelu GRE. Z kolei flaga S (Sequence Number Present) dodaje 32-bitowy numer sekwencyjny umożliwiający odbiorcy wykrywanie utraty pakietów lub wymuszenie zachowania pierwotnej kolejności ich dostarczania.

W praktyce laboratoryjnej minimalny narzut nagłówka GRE bez pól opcjonalnych wynosi dokładnie 4 bajty. Wraz z zewnętrznym nagłówkiem IPv4 o standardowym rozmiarze 20 bajtów łączny narzut enkapsulacji wynosi 24 bajty. Jeśli w konfiguracji routera włączona zostanie weryfikacja sumy kontrolnej lub obsługa klucza, narzut ten wzrasta odpowiednio do 28 lub 32 bajtów, co bezpośrednio wpływa na obniżenie maksymalnego rozmiaru jednostki MTU dostępnej dla ruchu wewnętrznego.

Wyjaśnienie skrótów użytych na slajdzie:
GRE - Generic Routing Encapsulation - Protokół enkapsulacji warstwy 3 modelu odniesienia OSI.
MTU - Maximum Transmission Unit - Maksymalny rozmiar jednostki danych protokołu, która może zostać przesłana bez fragmentacji.
CRC - Cyclic Redundancy Check - Cyklokodowa suma kontrolna stosowana do detekcji błędów transmisji danych.
EtherType - Ethernet Type Field - Dwubajtowe pole w ramkach sieciowych identyfikujące protokół enkapsulowany wewnątrz ładunku.
PDU - Protocol Data Unit - Jednostka danych przesyłana w danej warstwie architektury sieciowej.

Istotnym zagadnieniem inżynierskim związanym z eksploatacją tuneli GRE jest sposób ich identyfikacji w stosie TCP/IP. W przeciwieństwie do popularnych protokołów aplikacyjnych i sesyjnych, GRE nie korzysta z portów warstwy transportowej TCP ani UDP. Pakiety GRE są hermetyzowane bezpośrednio w nagłówku IP, w którym pole Protocol przyjmuje wartość dziesiętną 47 (szesnastkowo 0x2F). Brak numerów portów rodzi daleko idące konsekwencje dla urządzeń pośredniczących w transmisji. Szczegółowe informacje normatywne i techniczne publikuje Rejestr numerów protokołów IANA.

Największe wyzwanie techniczne stanowi współpraca protokołu GRE z mechanizmem translacji adresów sieciowych i portów (NAPT/PAT), powszechnie stosowanym w routerach brzegowych i u dostawców Internetu. Klasyczny PAT współdzieli jeden publiczny adres IP pomiędzy wiele stacji lokalnych, mapując poszczególne sesje na unikalne numery portów źródłowych TCP lub UDP. Ponieważ pakiet GRE nie posiada nagłówka warstwy czwartej, standardowy translator NAT nie ma możliwości rozróżnienia strumieni pochodzących od różnych hostów wewnętrznych.

W konsekwencji tradycyjne zapory sieciowe i routery konsumenckie bez dedykowanego wsparcia porzucają pakiety z protokołem IP 47 lub zezwalają na poprawne zestawienie tylko jednego aktywnego tunelu dla całej sieci lokalnej. Prawidłowa obsługa wielu równoległych tuneli GRE przez barierę NAT wymaga wdrożenia mechanizmów bramy warstwy aplikacji (ALG - Application Layer Gateway) lub zastosowania mapowania statycznego 1:1 NAT, co wiąże się z koniecznością dedykowania unikalnego adresu publicznego.

Podobne ograniczenia dotyczą polityk bezpieczeństwa w zaporach ogniowych korporacyjnych dostawców usług. Domyślne reguły zapór stanowych często blokują nietypowe protokoły warstwy internetowej, uznając je za potencjalne wektory ataków lub próby ominięcia inspekcji ruchu. Administrator wdrażający tunel GRE musi zatem jawnie zdefiniować reguły zezwalające na tranzyt pakietów IP z protokołem 47 w obu kierunkach na wszystkich węzłach brzegowych znajdujących się na trasie tunelu.

Wyjaśnienie skrótów użytych na slajdzie:
IANA - Internet Assigned Numbers Authority - Organizacja zarządzająca globalnymi rejestrami adresacji IP oraz numerów protokołów sieciowych.
NAT - Network Address Translation - Metoda translacji adresów IP między różnymi przestrzeniami adresowymi.
PAT - Port Address Translation - Odmiana NAT mapująca wiele prywatnych adresów IP na pojedynczy adres publiczny za pomocą portów.
ALG - Application Layer Gateway - Moduł zapory sieciowej analizujący i modyfikujący pakiety specyficznych protokołów przechodzących przez NAT.
TCP - Transmission Control Protocol - Połączeniowy protokół warstwy transportowej zapewniający niezawodną transmisję danych.
UDP - User Datagram Protocol - Bezpołączeniowy protokół warstwy transportowej oferujący szybki przesył datagramów.

Fundamentalną cechą determinującą zachowanie protokołu GRE w strukturze sieciowej jest jego całkowita bezstanowość (stateless nature). W architekturze GRE nie występuje żadna faza wstępnego nawiązywania połączenia, odpowiednik trójfazowego uzgadniania TCP (Three-Way Handshake) ani wymiana parametrów kryptograficznych znana z protokołów IPsec czy TLS. Router konfigurujący interfejs GRE zakłada, że zdalny punkt końcowy jest stale gotowy do odbioru danych. Szczegółowe informacje normatywne i techniczne publikuje Dokumentacja RouterOS GRE.

W domyślnej konfiguracji system operacyjny routera uznaje logiczny interfejs GRE za w pełni operacyjny (stan logiczny UP) natychmiast po przypisaniu mu poprawnego adresu IP i podaniu adresu zdalnego, o ile tylko fizyczny interfejs wychodzący WAN posiada łącze. Router będzie transmitował pakiety w stronę tunelu nawet w sytuacji, gdy zdalne urządzenie uległo awarii, zostało wyłączone lub ścieżka transmisyjna w sieci publicznej uległa przerwaniu.

Zjawisko to niesie ze sobą poważne konsekwencje dla architektury routingu IP. Skoro interfejs tunelu pozostaje w stanie UP, wszystkie trasy statyczne wskazujące ten interfejs jako bramę domyślną lub trasę docelową zachowują status aktywnych w tablicy routingu (Routing Information Base). Ruch kierowany do odległej podsieci trafia do tunelu i jest bezpowrotnie porzucany w sieci transmisyjnej (zjawisko czarnej dziury - blackholingu), a router lokalny nie podejmuje prób przełączenia na łącze zapasowe.

Z drugiej strony bezstanowość zapewnia protokołowi GRE niezwykłą prostotę obliczeniową i minimalne zużycie zasobów procesora. Węzły sieciowe nie muszą alokować struktur pamięciowych dla śledzenia stanu sesji tysięcy klientów, co pozwala na osiąganie bardzo wysokich przepustowości transmisji na układach sprzętowych o ograniczonej mocy. Aby pogodzić wysoką wydajność z koniecznością detekcji awarii, inżynierowie sieciowi stosują mechanizmy asynchronicznego monitorowania żywotności łącza (keepalive).

Wyjaśnienie skrótów użytych na slajdzie:
GRE - Generic Routing Encapsulation - Bezstanowy protokół hermetyzacji pakietów warstwy 3.
RIB - Routing Information Base - Baza informacji routingu przechowująca wszystkie trasy wyuczone przez router.
FIB - Forwarding Information Base - Tablica przekazywania pakietów wykorzystywana przez procesor do szybkiego przełączania ruchu.
WAN - Wide Area Network - Rozległa sieć telekomunikacyjna łącząca odległe węzły korporacyjne.
TCP - Transmission Control Protocol - Protokół transportowy zorientowany połączeniowo ze śledzeniem stanu sesji.

W celu wyeliminowania problemu czarnych dziur w routingu wynikającego z bezstanowości protokołu, inżynierowie opracowali wyspecjalizowany mechanizm monitorowania żywotności łącza - GRE Keepalive. Mechanizm ten pozwala routerowi na autonomiczną weryfikację, czy odległy koniec tunelu jest osiągalny i zdolny do przetwarzania ruchu, bez konieczności wprowadzania skomplikowanych protokołów sygnalizacyjnych. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 1701 (Wczesna enkapsulacja GRE).

Zasada działania mechanizmu opiera się na genialnej koncepcji zapętlenia pakietu (loopback packet). Router lokalny (np. router A) generuje specjalny pakiet kontrolny, w którym wewnętrzny nagłówek IP posiada adres źródłowy ustawiony na router zdalny (Router B), a adres docelowy na router lokalny (Router A). Następnie pakiet ten jest hermetyzowany w standardowy nagłówek GRE i wysyłany przez sieć publiczną z adresem docelowym Routera B. Gdy Router B odbierze pakiet, zdejmuje zewnętrzny nagłówek GRE i stwierdza, że otrzymał zwykły pakiet IP zaadresowany do Routera A, po czym natychmiast odsyła go z powrotem.

Kluczową zaletą tego rozwiązania jest fakt, że router zdalny nie musi posiadać żadnej specjalnej konfiguracji ani nawet wspierać mechanizmu keepalive w swoim oprogramowaniu - wystarczy, że poprawnie dekapsuluje pakiety GRE i wykonuje standardowy routing IP. Jeśli router wysyłający nie otrzyma odbitego pakietu w zdefiniowanym czasie i po określonej liczbie prób (parametry Keepalive Interval oraz Keepalive Retries), uznaje tunel za uszkodzony.

W momencie stwierdzenia awarii system operacyjny routera zmienia status logiczny interfejsu GRE na DOWN. Zmiana ta natychmiast wyzwala aktualizację tablicy routingu: powiązane trasy statyczne zostają wycofane, a protokoły routingu dynamicznego mogą rozpocząć procedurę konwergencji i przekierować ruch na łącza zapasowe. Po przywróceniu komunikacji pakiety keepalive ponownie docierają do nadawcy, a interfejs samoczynnie powraca do stanu UP.

Wyjaśnienie skrótów użytych na slajdzie:
GRE - Generic Routing Encapsulation - Protokół tunelowania pakietów sieciowych.
ICMP - Internet Control Message Protocol - Protokół komunikatów kontrolnych i diagnostycznych stosowany w sieciach IP.
RTT - Round Trip Time - Czas potrzebny na przesłanie pakietu do odbiorcy i odebranie potwierdzenia zwrotnego.
IP - Internet Protocol - Protokół warstwy sieciowej odpowiedzialny za adresację pakietów.
WAN - Wide Area Network - Sieć rozległa stanowiąca medium transportowe dla tunelu.

Uniwersalny charakter protokołu GRE sprawia, że mimo braku natywnego szyfrowania znajduje on szerokie zastosowanie w korporacyjnych architekturach teleinformatycznych. Podstawowym obszarem wdrożeń jest łączenie odległych sieci lokalnych przedsiębiorstw za pośrednictwem bezpiecznych sieci operatorskich, takich jak dedykowane obwody MPLS VPN. W takim środowisku poufność jest gwarantowana przez izolację na poziomie operatora, a GRE służy jako wydajny nośnik transparentnego transportu. Szczegółowe informacje normatywne i techniczne publikuje Ministerstwo Cyfryzacji.

Kluczową przewagą GRE nad standardowymi tunelami IPsec w trybie tunelowym jest pełne wsparcie dla transmisji pakietów rozgłoszeniowych (broadcast) oraz grupowych (multicast). Zdolność ta jest krytyczna w przypadku stosowania protokołów routingu dynamicznego, takich jak OSPF czy EIGRP, które wykorzystują pakiety multicast do automatycznego wykrywania sąsiadów i wymiany tablic routingu. Czysty IPsec nie potrafi hermetyzować ruchu multicast, dlatego standardem branżowym stało się nakładanie szyfrowania IPsec na tunel GRE (architektura GRE over IPsec).

Protokół GRE odgrywa również kluczową rolę w strategiach migracji sieciowych, umożliwiając transport protokołu IPv6 przez infrastrukturę wspierającą wyłącznie protokół IPv4 (mechanizm 6in4 / IPv6 over GRE). Pozwala to organizacjom na stopniowe wdrażanie nowoczesnego stosu adresowego w oddziałach bez konieczności kosztownej wymiany urządzeń brzegowych u pośredniczących dostawców Internetu.

W nowoczesnych architekturach sieci definiowanych programowo (SD-WAN) oraz środowiskach chmurowych tunele GRE są wykorzystywane do zestawiania połączeń tranzytowych z centrami danych i węzłami Direct Connect. Niewielki narzut nagłówka oraz prostota konfiguracji sprawiają, że GRE pozostaje niezastąpionym narzędziem inżyniera sieciowego w scenariuszach wymagających wysokiej przepustowości i elastycznego routingu.

Wyjaśnienie skrótów użytych na slajdzie:
GRE - Generic Routing Encapsulation - Protokół enkapsulacji warstwy sieciowej.
OSPF - Open Shortest Path First - Hierarchiczny protokół routingu dynamicznego stanu łącza.
EIGRP - Enhanced Interior Gateway Routing Protocol - Zaawansowany wektorowo-odległościowy protokół routingu dynamicznego.
MPLS - Multiprotocol Label Switching - Technika komutacji etykiet stosowana w sieciach szkieletowych operatorów telekomunikacyjnych.
IPsec - Internet Protocol Security - Zestaw protokołów zapewniających szyfrowanie i uwierzytelnianie na poziomie IP.
SD-WAN - Software-Defined Wide Area Network - Architektura sieci rozległej sterowana programowo w oparciu o sieci nakładkowe.

Konfiguracja tunelu GRE w systemie MikroTik RouterOS przebiega wieloetapowo i rozpoczyna się od zdefiniowania logicznego interfejsu tunelowego. Do zarządzania tymi interfejsami służy gałąź konfiguracyjna /interface gre. Utworzenie interfejsu wymaga podania unikalnej nazwy oraz określenia dwóch kluczowych parametrów adresowych: lokalnego adresu publicznego (local-address) oraz publicznego adresu IP zdalnego routera (remote-address). Szczegółowe informacje normatywne i techniczne publikuje Dokumentacja MikroTik RouterOS.

W środowisku laboratoryjnym przyjmujemy model połączenia dwóch lokalizacji: Biura A o publicznym adresie 1.1.1.1 oraz Biura B o adresie 2.2.2.2. Na Routerze A polecenie tworzące interfejs przyjmuje postać: /interface gre add name=gre-to-B remote-address=2.2.2.2 local-address=1.1.1.1. Na Routerze B konfiguruje się interfejs symetryczny o nazwie gre-to-A, odwracając przypisanie adresów IP. Podanie jawnego parametru local-address jest dobrą praktyką inżynierską, zapobiegającą błędom w przypadku routerów posiadających wiele adresów WAN.

W trakcie tworzenia interfejsu RouterOS automatycznie przypisuje domyślne wartości parametrów transmisyjnych. Domyślny rozmiar jednostki MTU jest ustawiany na 1476 bajtów, co uwzględnia standardowy 24-bajtowy narzut nagłówków IPv4 i GRE. Ponadto system domyślnie włącza mechanizm keepalive z interwałem 10 sekund i limitem 10 nieudanych prób, co gwarantuje automatyczne wykrywanie stanu łącza bez konieczności ręcznej ingerencji.

Warto podkreślić, że samo utworzenie interfejsu logicznego w systemie RouterOS nie pozwala jeszcze na przesyłanie danych użytkowych. Nowo utworzony interfejs reprezentuje jedynie niezaadresowany wirtualny kabel sieciowy. Aby stał się on użyteczny z punktu widzenia routingu IP, konieczne jest przejście do kolejnego etapu, którym jest nadanie mu właściwej adresacji logicznej ze wspólnej podsieci tranzytowej.

Wyjaśnienie skrótów użytych na slajdzie:
GRE - Generic Routing Encapsulation - Protokół tunelowania pakietów sieciowych.
CLI - Command Line Interface - Tekstowy interfejs wiersza poleceń służący do zarządzania systemem RouterOS.
WAN - Wide Area Network - Interfejs podłączony do sieci publicznej dostawcy Internetu.
MTU - Maximum Transmission Unit - Maksymalny rozmiar pakietu przesyłany przez interfejs bez podziału na fragmenty.
OS - Operating System - System operacyjny zarządzający pracą platformy sprzętowej routera.

Po poprawnym zdefiniowaniu logicznych interfejsów tunelowych na obu końcach łącza kolejnym krokiem inżynierskim jest przydzielenie im logicznej adresacji IP. Tunel GRE funkcjonuje w architekturze sieciowej jako klasyczne medium punkt-punkt (Point-to-Point). Oznacza to, że do komunikacji wewnętrznej między routerami wymagana jest wydzielona, prywatna przestrzeń adresowa zgodna ze standardem RFC 1918, która nie koliduje z adresacją istniejących podsieci LAN. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 1918 (Prywatne podsieci IP).

W praktyce sieciowej najpopularniejszym standardem adresowania łączy tunelowych jest stosowanie 30-bitowej maski podsieci (/30), która oferuje dokładnie dwa użyteczne adresy hostów, adres sieci oraz adres rozgłoszeniowy. W naszym scenariuszu konfigurujemy pulę tranzytową 10.0.0.0/30: Router A otrzymuje adres 10.0.0.1/30 przypisany do interfejsu gre-to-B (/ip address add address=10.0.0.1/30 interface=gre-to-B), natomiast Router B konfiguruje adres 10.0.0.2/30 na interfejsie gre-to-A.

W nowoczesnych sieciach szkieletowych dopuszcza się również stosowanie masek 31-bitowych (/31) zgodnie z RFC 3021, co eliminuje marnowanie adresów na identyfikator podsieci i broadcast, oszczędzając cenną przestrzeń adresową. Niezależnie od wybranej maski, kluczowym krokiem weryfikacyjnym po nadaniu adresów jest wykonanie testu osiągalności za pomocą narzędzia ping ze stacji lokalnej do adresu wewnętrznego odległego końca tunelu (np. ping 10.0.0.2 z Routera A).

Poprawna odpowiedź na test ping potwierdza, że pakiety ICMP Echo Request są prawidłowo hermetyzowane w nagłówki GRE, przesyłane przez sieć WAN i pomyślnie dekapsulowane po stronie odbiorcy. Warto pamiętać, że na tym etapie komunikacja zachodzi wyłącznie między samymi routerami. Komputery znajdujące się w sieciach lokalnych za routerami nie mają jeszcze dostępu do zasobów zdalnego oddziału, dopóki administrator nie zdefiniuje odpowiednich reguł w tablicy routingu.

Wyjaśnienie skrótów użytych na slajdzie:
IP - Internet Protocol - Protokół warstwy internetowej odpowiedzialny za adresowanie hostów.
GRE - Generic Routing Encapsulation - Protokół hermetyzacji pakietów warstwy sieciowej.
RFC - Request for Comments - Dokument standaryzacyjny wydawany przez organizację IETF.
ICMP - Internet Control Message Protocol - Protokół przesyłania komunikatów diagnostycznych i błędów w sieciach IP.
LAN - Local Area Network - Lokalna sieć komputerowa znajdująca się za bramą tunelu.
CIDR - Classless Inter-Domain Routing - Bezklasowa metoda przydzielania adresów IP i agregacji tras.

Ostatnim etapem uruchamiania funkcjonalnego tunelu site-to-site jest konfiguracja routingu umożliwiającego wymianę danych pomiędzy podsieciami LAN w obu lokalizacjach. Posiadanie skonfigurowanego interfejsu GRE i zaadresowanego kanału tranzytowego tworzy logiczną ścieżkę komunikacji, lecz routery nie przekierują do niej ruchu użytkowników, dopóki nie zostaną o tym poinstruowane przez wpisy w tablicy routingu. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 2328 (Specyfikacja OSPF v2).

W przypadku prostych połączeń dwupunktowych najczęściej stosuje się trasy statyczne definiowane w gałęzi /ip route. Na Routerze A, obsługującym sieć lokalną 192.168.10.0/24, dodaje się trasę do sieci odległej 192.168.20.0/24, wskazując jako bramę adres IP drugiego końca tunelu: /ip route add dst-address=192.168.20.0/24 gateway=10.0.0.2. Na Routerze B wykonuje się operację symetryczną, wskazując sieć 192.168.10.0/24 z bramą 10.0.0.1. Od tej chwili pakiety generowane przez stacje robocze trafiają bezpośrednio do tunelu.

W bardziej rozbudowanych architekturach korporacyjnych, obejmujących wiele oddziałów lub łącza zapasowe, zarządzanie dziesiątkami tras statycznych staje się nieefektywne i podatne na błędy ludzkie. W takich scenariuszach optymalnym rozwiązaniem jest uruchomienie protokołu routingu dynamicznego, takiego jak OSPF (Open Shortest Path First). Interfejs GRE dodaje się do obszaru OSPF (Area), co pozwala routerom na automatyczną wymianę tras, dynamiczne wykrywanie nowych podsieci oraz natychmiastowe reagowanie na awarie.

Integracja routingu z tunelem GRE wymaga zachowania szczególnej ostrożności inżynierskiej. Niewłaściwe zdefiniowanie tras - w szczególności skierowanie trasy do zdalnego publicznego adresu tunelu przez sam tunel - prowadzi do natychmiastowego wystąpienia krytycznego błędu znanego jako routing rekurencyjny. Zjawisko to paraliżuje pracę routera i stanowi jeden z najbardziej podstępnych problemów diagnostycznych w sieciach VPN.

Wyjaśnienie skrótów użytych na slajdzie:
OSPF - Open Shortest Path First - Standardowy protokół routingu dynamicznego stanu łącza.
BGP - Border Gateway Protocol - Protokół bramy zewnętrznej stosowany w sieciach szkieletowych i tranzytowych.
GRE - Generic Routing Encapsulation - Protokół enkapsulacji warstwy sieciowej.
IP - Internet Protocol - Protokół warstwy internetowej odpowiedzialny za dostarczanie pakietów.
LAN - Local Area Network - Sieć lokalna łącząca urządzenia końcowe w oddziale firmy.
WAN - Wide Area Network - Rozległa sieć publiczna stanowiąca fizyczne medium transmisyjne.

Zjawisko routingu rekurencyjnego (Recursive Routing) stanowi jedną z najbardziej podstępnych pułapek konfiguracyjnych w inżynierii sieci VPN. Problem pojawia się w sytuacji, gdy wpis w tablicy routingu powoduje, że router próbuje wysłać zewnętrzny pakiet transportowy tunelu przez ten sam logiczny interfejs tunelowy, który ten pakiet dopiero hermetyzuje. Tworzy to zamkniętą pętlę logiczną w procesie podejmowania decyzji o przekazywaniu pakietów. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 1812 (Wymagania dla routerów IPv4).

W praktyce laboratoryjnej błąd ten najczęściej powstaje po dodaniu zbyt ogólnej trasy statycznej (np. trasy domyślnej 0.0.0.0/0 kierującej cały ruch w tunel) lub w wyniku nieostrożnej redystrybucji tras w protokołach routingu dynamicznego OSPF czy BGP. Gdy router stwierdzi, że publiczny adres IP zdalnego punktu końcowego (np. 2.2.2.2) jest osiągalny przez interfejs tunelu GRE, podejmuje próbę hermetyzacji pakietu GRE w kolejny nagłówek GRE, co prowadzi do natychmiastowego załamania transmisji.

W systemie MikroTik RouterOS mechanizm jądra wykrywa zapętlenie rekurencyjne i natychmiast deaktywuje powiązany interfejs, oznaczając go statusem DOWN lub generując komunikat o błędzie trasy. W tym momencie trasa tunelowa znika z tablicy routingu, a publiczny adres zdalny ponownie staje się osiągalny przez fizyczny interfejs WAN. Wówczas interfejs tunelu automatycznie wraca do stanu UP, trasa błędna zostaje ponownie zainstalowana i cykl powtarza się w nieskończoność (zjawisko trzepotania trasy - route flapping).

Jedynym skutecznym rozwiązaniem tego problemu jest bezwzględne zagwarantowanie, że trasa do publicznego adresu IP zdalnego punktu końcowego tunelu zawsze prowadzi przez fizyczny interfejs dostawcy Internetu. Osiąga się to poprzez dodanie jawnej trasy statycznej dla konkretnego hosta (/32) ze wskazaniem bramy WAN dostawcy Internetu (/ip route add dst-address=2.2.2.2/32 gateway=WAN_GATEWAY). Trasa o węższej masce ma wyższy priorytet (Longest Prefix Match), co trwale zapobiega przejęciu ruchu transportowego przez trasy tunelowe.

Wyjaśnienie skrótów użytych na slajdzie:
GRE - Generic Routing Encapsulation - Protokół hermetyzacji pakietów warstwy sieciowej.
RIB - Routing Information Base - Baza informacyjna routingu przechowująca zbiór wszystkich tras.
FIB - Forwarding Information Base - Tablica przekazywania pakietów wykorzystywana w procesie routingu sprzętowego.
WAN - Wide Area Network - Fizyczny interfejs podłączony do infrastruktury publicznej dostawcy Internetu.
OSPF - Open Shortest Path First - Protokół routingu dynamicznego stanu łącza.
BGP - Border Gateway Protocol - Protokół bramy zewnętrznej wymieniający prefiksy sieciowe.

Właściwe zarządzanie parametrami transmisyjnymi łącza, w szczególności maksymalnym rozmiarem jednostki transmisyjnej (MTU), jest kluczowe dla stabilności i wydajności tuneli GRE. W standardowej sieci Ethernet maksymalny rozmiar ramki wynosi 1500 bajtów. Dodanie enkapsulacji tunelowej wprowadza dodatkowy narzut nagłówków: 20 bajtów zewnętrznego nagłówka IPv4 oraz 4 bajty podstawowego nagłówka GRE, co daje łączny narzut 24 bajtów. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 1191 (Path MTU Discovery).

W efekcie efektywne MTU dla pakietu wewnętrznego w tunelu GRE spada do wartości 1500 - 24 = 1476 bajtów (a w przypadku użycia sumy kontrolnej lub klucza RFC 2890 odpowiednio do 1472 lub 1468 bajtów). Jeżeli stacja robocza wygeneruje pełny pakiet o rozmiarze 1500 bajtów, router po dodaniu nagłówków GRE otrzyma pakiet o rozmiarze 1524 bajtów, który przekracza fizyczne MTU interfejsu WAN. Prowadzi to do konieczności fragmentacji pakietu na poziomie warstwy IP lub jego bezpowrotnego odrzucenia, gdy w nagłówku ustawiono flagę DF (Don't Fragment).

Fragmentacja pakietów drastycznie degraduje wydajność routera, wymuszając operacje buforowania i podziału w procesorze (CPU) oraz podwajając liczbę pakietów w sieci. Co gorsza, mechanizm automatycznego wykrywania MTU ścieżki (Path MTU Discovery - PMTUD, RFC 1191) bardzo często zawodzi, ponieważ pośredniczące zapory sieciowe w Internecie powszechnie blokują niezbędne komunikaty ICMP Fragmentation Needed (Typ 3, Kod 4). Prowadzi to do zjawiska tzw. czarnej dziury PMTUD, objawiającego się zawieszaniem ładowania stron WWW i transferów plików.

W środowiskach produkcyjnych standardowym rozwiązaniem inżynierskim jest wdrożenie mechanizmu MSS Clamping na routerze brzegowym. Ponieważ segmenty TCP posiadają nagłówek TCP (20 B) i nagłówek IP (20 B), maksymalny użyteczny ładunek danych (MSS) dla MTU 1476 wynosi dokładnie 1436 bajtów. Reguła zapory w łańcuchu mangle przechwytuje pakiety nawiązujące połączenie TCP (flaga SYN) i automatycznie zmniejsza deklarowaną przez klientów wartość MSS do 1436 bajtów, trwale eliminując ryzyko fragmentacji bez konieczności rekonfiguracji systemów końcowych.

Wyjaśnienie skrótów użytych na slajdzie:
MTU - Maximum Transmission Unit - Maksymalny dopuszczalny rozmiar pakietu przesyłany w pojedynczej ramce sieciowej.
MSS - Maximum Segment Size - Maksymalny rozmiar bloku danych użytkownika przesyłany w pojedynczym segmencie TCP.
GRE - Generic Routing Encapsulation - Protokół hermetyzacji pakietów warstwy 3.
PMTUD - Path MTU Discovery - Standardowa procedura automatycznego wykrywania minimalnego MTU na trasie pakietu.
ICMP - Internet Control Message Protocol - Protokół przesyłania komunikatów kontrolnych w sieciach IP.
DF - Don't Fragment - Flaga nagłówka IP zabraniająca routerom fragmentacji pakietu.

Protokół Point-to-Point Protocol (PPP) został opracowany przez organizację IETF na początku lat dziewięćdziesiątych i formalnie ustandaryzowany w dokumencie RFC 1661. Powstał jako bezpośredni następca przestarzałego i prymitywnego protokołu SLIP (Serial Line Internet Protocol), który nie posiadał żadnych wbudowanych mechanizmów negocjacji adresacji, uwierzytelniania użytkowników ani obsługi protokołów innych niż podstawowy IPv4. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 1661 (Protokół PPP).

W przeciwieństwie do protokołów sieci rozgłoszeniowych (takich jak Ethernet), PPP został zaprojektowany z myślą o bezpośrednich połączeniach dwupunktowych, gdzie w medium transmisyjnym występują dokładnie dwa węzły: nadawca i odbiorca. Konstrukcja ta wyeliminowała konieczność stosowania adresowania fizycznego (brak adresów MAC) oraz skomplikowanych algorytmów wykrywania kolizji (CSMA/CD), kładąc nacisk na niezawodną kontrolę jakości łącza oraz dynamiczną rekonfigurację parametrów.

Struktura ramki PPP bazuje na standardzie HDLC (High-Level Data Link Control) i obejmuje jednobajtowe znaczniki początku i końca (flagi 0x7E), stałe pola adresu (0xFF) i kontroli (0x03), dwubajtowe pole identyfikatora protokołu oraz ładunek danych zabezpieczony 16- lub 32-bitową sumą kontrolną FCS. Pole protokołu pozwala odbiorcy na natychmiastowe rozpoznanie, czy odebrana ramka niesie pakiet LCP, komunikat uwierzytelniania, czy jednostkę danych protokołu wyższej warstwy.

Choć klasyczne modemy telefoniczne stanowią dziś relikt historii techniki, architektura PPP przetrwała i stanowi fundament współczesnych technologii telekomunikacyjnych. Mechanizmy ramkowania i negocjacji PPP zostały zaadaptowane w szerokopasmowych sieciach dostępowych DSL i FTTH za pośrednictwem standardu PPPoE (PPP over Ethernet, RFC 2516) oraz stały się rdzeniem protokołów VPN zdalnego dostępu, takich jak PPTP, L2TP oraz SSTP.

Wyjaśnienie skrótów użytych na slajdzie:
PPP - Point-to-Point Protocol - Protokół warstwy łącza danych dla połączeń bezpośrednich.
SLIP - Serial Line Internet Protocol - Historyczny protokół transmisji pakietów IP przez łącza szeregowe.
HDLC - High-Level Data Link Control - Standard ramkowania synchronicznego i asynchronicznego poziomu łącza danych.
FCS - Frame Check Sequence - Pole sumy kontrolnej w ramce służące do detekcji błędów transmisji.
LCP - Link Control Protocol - Protokół kontroli łącza odpowiedzialny za negocjację parametrów sesji PPP.
NCP - Network Control Protocol - Rodzina protokołów PPP negocjujących parametry warstwy sieciowej.

Architektura protokołu PPP wyróżnia się wysoce modularną, trójwarstwową konstrukcją, która zapewnia niespotykaną elastyczność i możliwość adaptacji do różnorodnych mediów fizycznych. Zgodnie ze specyfikacją RFC 1661 protokół składa się z trzech zasadniczych komponentów: metody hermetyzacji wieloprotokołowych datagramów, protokołu sterowania łączem LCP (Link Control Protocol) oraz rodziny protokołów kontroli warstwy sieciowej NCP (Network Control Protocols). Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 1332 (Protokół IPCP dla PPP).

Podprotokół LCP operuje bezpośrednio na poziomie warstwy łącza danych i odpowiada za pełny cykl życia połączenia. Do jego zadań należy uzgodnienie maksymalnego rozmiaru odbieranej jednostki danych (MRU - Maximum Receive Unit), weryfikacja integralności łącza za pomocą pakietów Echo-Request i Echo-Reply oraz wykrywanie zapętleń fizycznych za pomocą losowo generowanych liczb magicznych (Magic Numbers). Ponadto LCP negocjuje protokół uwierzytelniania, który zostanie zastosowany po zestawieniu łącza.

Po pomyślnym zakończeniu fazy LCP i uwierzytelnienia sterowanie przejmują wyspecjalizowane protokoły NCP. Każdy protokół warstwy sieciowej posiada dedykowany moduł NCP - dla protokołu IPv4 jest to IPCP (Internet Protocol Control Protocol, RFC 1332), a dla protokołu IPv6 moduł IPv6CP (RFC 5072). Moduł IPCP odpowiada za dynamiczne przydzielenie adresu IP dla klienta, przekazanie adresów serwerów DNS oraz ewentualną negocjację kompresji nagłówków TCP/IP.

Taka separacja odpowiedzialności gwarantuje, że awaria lub rekonfiguracja warstwy sieciowej nie wpływa na stabilność łącza fizycznego, a samo łącze PPP może równolegle transportować wiele niezależnych protokołów sieciowych. Z punktu widzenia projektanta VPN architektura ta umożliwiła łatwe przeniesienie całego stosu PPP do środowisk wirtualnych, co dało początek protokołom PPTP i L2TP.

Wyjaśnienie skrótów użytych na slajdzie:
LCP - Link Control Protocol - Podprotokół PPP odpowiedzialny za parametry fizyczne i logiczne łącza.
NCP - Network Control Protocol - Podprotokoły PPP konfigurujące parametry poszczególnych protokołów warstwy 3.
IPCP - Internet Protocol Control Protocol - Moduł NCP konfigurujący parametry IPv4 oraz serwery DNS w sesji PPP.
MRU - Maximum Receive Unit - Maksymalny rozmiar jednostki danych, jaką węzeł PPP może przyjąć.
DNS - Domain Name System - Hierarchiczny system nazw domenowych tłumaczący nazwy na adresy IP.

Proces nawiązywania, eksploatacji i zamykania połączenia PPP jest ściśle zdefiniowany przez sformalizowany automat skończony stanów. Zgodnie z normą RFC 1661 każda sesja PPP przechodzi przez sekwencję pięciu następujących po sobie faz: Link Dead, Link Establishment, Authentication, Network Layer Protocol oraz Link Termination. Zrozumienie tych faz jest kluczowe dla skutecznej diagnostyki problemów z łącznością. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 1570 (Rozszerzenia protokołu LCP).

W fazie początkowej Link Dead łącze fizyczne pozostaje nieaktywne lub oczekuje na sygnał nośnej. Wykrycie obecności medium transmisyjnego powoduje automatyczne przejście do fazy Link Establishment, w której węzły wymieniają komunikaty protokołu LCP. Strona inicjująca wysyła pakiet Configure-Request zawierający proponowane opcje konfiguracyjne (MRU, typ uwierzytelniania, liczbę magiczną). Druga strona odpowiada pakietem Configure-Ack (akceptacja), Configure-Nak (odrzucenie wartości z propozycją nowej) lub Configure-Reject (całkowite odrzucenie opcji).

Po obustronnym zatwierdzeniu pakietów Configure-Ack następuje przejście do opcjonalnej fazy Authentication. Jeśli faza ta została wynegocjowana, węzły dokonują weryfikacji tożsamości za pomocą protokołu PAP, CHAP lub MS-CHAPv2. Dopiero pomyślne zakończenie uwierzytelnienia otwiera fazę Network Layer Protocol, w której protokoły NCP (np. IPCP) negocjują adresację IP i konfigurację tras. Po zakończeniu negocjacji sieć wchodzi w stan otwarty (Opened), w którym realizowany jest normalny transfer pakietów użytkownika.

Sesja kończy się przejściem do fazy Link Termination. Rozłączenie może nastąpić w wyniku jawnego żądania jednego z węzłów (wymiana pakietów LCP Terminate-Request i Terminate-Ack), fizycznej utraty nośnej, przekroczenia limitu błędów transmisji lub wygaśnięcia czasu sesji. Router zwalnia wówczas zaalokowane adresy IP, usuwa dynamiczne wpisy z tablic routingu i powraca do stanu Link Dead.

Wyjaśnienie skrótów użytych na slajdzie:
LCP - Link Control Protocol - Protokół kontroli łącza sterujący fazą zestawiania sesji.
NCP - Network Control Protocol - Protokoły kontroli warstwy sieciowej aktywowane po uwierzytelnieniu.
IPCP - Internet Protocol Control Protocol - Moduł negocjujący adresację IP w fazie sieciowej.
ACK - Acknowledgment - Komunikat potwierdzenia poprawnego odebrania pakietu lub akceptacji parametrów.
NAK - Negative Acknowledgment - Komunikat negatywnej odpowiedzi żądający modyfikacji proponowanych opcji.

Password Authentication Protocol (PAP) to najstarszy i najbardziej elementarny mechanizm weryfikacji tożsamości zdefiniowany dla sesji PPP w dokumencie RFC 1334. Został zaprojektowany w epoce, gdy połączenia modemowe były realizowane przez wydzielone, komutowane linie telefoniczne, a ryzyko podsłuchu pakietów w sieci transmisyjnej uważano za znikome. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 1334 (Uwierzytelnianie PAP).

Mechanizm działania protokołu PAP opiera się na prostym dwufazowym uzgadnianiu (Two-Way Handshake). Po zakończeniu fazy LCP stacja kliencka wysyła do serwera dostępowego pakiet Authenticate-Request, zawierający nazwę użytkownika oraz hasło zakodowane w formacie czystego tekstu (plaintext). Serwer porównuje otrzymane poświadczenia ze swoją lokalną bazą kont lub weryfikuje je na zewnętrznym serwerze RADIUS, po czym odsyła komunikat Authenticate-Ack (w przypadku sukcesu) lub Authenticate-Nak (w przypadku błędnych danych).

Z punktu widzenia współczesnej inżynierii cyberbezpieczeństwa protokół PAP reprezentuje całkowity brak ochrony kryptograficznej. Ponieważ login i hasło podróżują przez sieć w postaci jawnej, każdy nieuprawniony podmiot posiadający dostęp do węzła tranzytowego lub posługujący się analizatorem ruchu (np. Wireshark) jest w stanie natychmiast przechwycić poświadczenia użytkownika bez konieczności łamania jakichkolwiek szyfrów.

Ponadto PAP jest całkowicie bezbronny wobec ataków typu powtórzenie (Replay Attack) oraz podszywania się pod serwer dostępowy (brak uwierzytelnienia wzajemnego). Z tego względu stosowanie protokołu PAP w środowiskach produkcyjnych jest kategorycznie zakazane przez współczesne wytyczne bezpieczeństwa teleinformatycznego, a w konfiguracjach routerów MikroTik powinien on zostać bezwzględnie zablokowany.

Wyjaśnienie skrótów użytych na slajdzie:
PAP - Password Authentication Protocol - Prymitywny protokół uwierzytelniania przesyłający hasło jawnym tekstem.
PPP - Point-to-Point Protocol - Protokół łącza danych dla połączeń bezpośrednich.
RADIUS - Remote Authentication Dial-In User Service - Protokół centralnego uwierzytelniania, autoryzacji i rozliczania użytkowników.
RFC - Request for Comments - Dokument standaryzacyjny wydawany przez organizację IETF.
CLI - Command Line Interface - Interfejs wiersza poleceń służący do konfiguracji urządzeń sieciowych.

Odpowiedzią organizacji IETF na krytyczne słabości protokołu PAP było opracowanie standardu Challenge Handshake Authentication Protocol (CHAP), opisanego w dokumencie RFC 1994. Podstawowym celem inżynierskim przyświecającym twórcom protokołu było całkowite wyeliminowanie konieczności przesyłania hasła użytkownika przez nieufne medium transmisyjne. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 1994 (Protokół CHAP).

Architektura CHAP bazuje na kryptograficznym schemacie wyzwanie-odpowiedź (Challenge-Response) i obejmuje trzyetapową sekwencję komunikatów. W pierwszym kroku serwer uwierzytelniający generuje unikalny identyfikator sesji oraz pseudolosowy ciąg bajtów zwany wyzwaniem (Challenge) i przesyła go do klienta w pakiecie CHAP Challenge. W drugim kroku klient pobiera swoje hasło w postaci jawnej, łączy je z odebranym wyzwaniem oraz identyfikatorem, a następnie oblicza kryptograficzny skrót za pomocą jednokierunkowej funkcji skrótu MD5.

Wyliczony skrót wraz z nazwą użytkownika jest odsyłany do serwera w pakiecie CHAP Response. W trzecim kroku serwer wyszukuje hasło danego użytkownika w swojej bazie danych, wykonuje identyczną operację skrótu na podstawie zapamiętanego wyzwania i porównuje oba rezultaty. Jeśli wyliczone wartości skrótu są tożsame, serwer odsyła pakiet CHAP Success, potwierdzając pomyślne uwierzytelnienie. Dodatkową zaletą protokołu jest możliwość okresowego powtarzania procedury wyzwania w trakcie trwania sesji.

Zastosowanie losowego wyzwania skutecznie chroni sesję przed podsłuchem oraz atakami typu powtórzenie (każda sesja korzysta z innego ziarna losowego). Niemniej jednak klasyczny CHAP posiada istotne ograniczenia: po pierwsze, serwer musi przechowywać hasła użytkowników w postaci jawnej lub odwracalnej, co stwarza ogromne ryzyko w przypadku kompromitacji bazy kont; po drugie, protokół oferuje jedynie uwierzytelnienie jednostronne, nie zabezpieczając klienta przed podszyciem się pod fałszywy serwer dostępowy.

Wyjaśnienie skrótów użytych na slajdzie:
CHAP - Challenge Handshake Authentication Protocol - Protokół uwierzytelniania wyzwanie-odpowiedź z funkcją MD5.
MD5 - Message Digest Algorithm 5 - Kryptograficzna funkcja skrótu generująca 128-bitowy skrót wiadomości.
PPP - Point-to-Point Protocol - Protokół warstwy łącza danych dla połączeń dwupunktowych.
HMAC - Hash-based Message Authentication Code - Mechanizm uwierzytelniania wiadomości oparty na funkcji skrótu i kluczu.
RFC - Request for Comments - Oficjalny dokument normalizacyjny komitetu IETF.

Protokół MS-CHAPv2 (zdefiniowany w dokumencie informacyjnym RFC 2759) został opracowany przez firmę Microsoft jako dedykowany mechanizm uwierzytelniania dla wirtualnych sieci prywatnych PPTP oraz połączeń wdzwanianych w środowiskach Windows NT i nowszych. Wprowadził on fundamentalną innowację w postaci uwierzytelniania wzajemnego (Mutual Authentication) - w procesie negocjacji nie tylko serwer weryfikuje tożsamość klienta, ale również klient upewnia się, że nawiązuje łączność z autentycznym serwerem korporacyjnym. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 2759 (Specyfikacja MS-CHAPv2).

W architekturze MS-CHAPv2 wyeliminowano konieczność przechowywania haseł w postaci jawnej po stronie serwera. Zamiast tego operacje kryptograficzne bazują na skrócie hasła NT-Hash (obliczanym jako funkcja MD4 z hasła zapisanego w standardzie UTF-16LE). Wyzwanie generowane jest dwustronnie: serwer wysyła 16-bajtowe wyzwanie autentykatora, a klient odpowiada własnym 16-bajtowym wyzwaniem rówieśnika (Peer Challenge). Na podstawie obu wyzwań oraz skrótu hasła wyliczane są 24-bajtowe bloki odpowiedzi oraz unikalne klucze sesyjne wykorzystywane później do szyfrowania danych.

Mimo wieloletniej dominacji na rynku protokół MS-CHAPv2 został całkowicie skompromitowany pod względem bezpieczeństwa. W 2012 roku podczas konferencji DEF CON badacze Moxie Marlinspike i David Hulton zaprezentowali praktyczny atak udowadniający, że architektura generowania odpowiedzi w MS-CHAPv2 redukuje całą przestrzeń klucza do pojedynczego 56-bitowego szyfru DES. Dzięki zastosowaniu wyspecjalizowanych klastrów sprzętowych opartych na układach FPGA możliwe stało się złamanie dowolnej sesji MS-CHAPv2 w czasie poniżej 24 godzin ze 100% gwarancją sukcesu.

Odzyskanie pierwotnego skrótu NT-Hash pozwala atakującemu nie tylko na natychmiastowe odczytanie całej zaszyfrowanej komunikacji przechwyconej w tunelu VPN, ale również na wielokrotne podszywanie się pod użytkownika w innych usługach domeny Windows Active Directory. Z tego powodu agencje bezpieczeństwa teleinformatycznego (w tym NIST oraz BSI) jednoznacznie zakazują stosowania protokołu MS-CHAPv2 w środowiskach przetwarzających wrażliwe dane.

Wyjaśnienie skrótów użytych na slajdzie:
MS-CHAPv2 - Microsoft Challenge Handshake Authentication Protocol version 2 - Protokół uwierzytelniania wzajemnego firmy Microsoft.
DES - Data Encryption Standard - Przestarzały symetryczny szyfr blokowy o 56-bitowej długości klucza roboczego.
MD4 - Message Digest 4 - Historyczna funkcja skrótu wykorzystywana w algorytmie NT-Hash.
FPGA - Field-Programmable Gate Array - Programowalne macierze bramek logicznych wykorzystywane do kryptoanalizy sprzętowej.
PFS - Perfect Forward Secrecy - Właściwość uniemożliwiająca odszyfrowanie przeszłego ruchu po kompromitacji klucza głównego.

Protokół Microsoft Point-to-Point Encryption (MPPE), ustandaryzowany w dokumencie RFC 3078, powstał w celu zapewnienia poufności danych przesyłanych przez tunele PPP i PPTP. Ponieważ bazowy protokół PPP nie posiada wbudowanych funkcji kryptograficznych, MPPE operuje w warstwie łącza danych, szyfrując jednostki danych protokołu (PDU) tuż przed ich przekazaniem do enkapsulacji w nagłówek transportowy. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 3078 (Szyfrowanie MPPE).

Sercem kryptograficznym protokołu MPPE jest symetryczny algorytm strumieniowy RC4 (Rivest Cipher 4). Protokół wspierał historycznie trzy długości klucza: eksportowe warianty 40-bitowe i 56-bitowe (będące pokłosiem ówczesnych amerykańskich restrykcji eksportowych na kryptografię) oraz standardowy klucz 128-bitowy. Klucze szyfrujące dla transmisji w obu kierunkach są wyliczane dynamicznie podczas fazy uwierzytelniania MS-CHAPv2, co teoretycznie eliminuje potrzebę ręcznej dystrybucji kluczy statycznych.

Najpoważniejszą wadą konstrukcyjną protokołu MPPE jest całkowity brak kryptograficznego mechanizmu weryfikacji integralności wiadomości (Message Authentication Code - MAC). MPPE szyfruje pakiety, ale w żaden sposób nie chroni ich przed modyfikacją w locie. Wykorzystanie szyfru strumieniowego sprawia, że zmiana pojedynczego bitu w szyfrogramie powoduje przewidywalną zmianę odpowiadającego mu bitu w odszyfrowanym tekście jawnym (podatność na ataki typu Bit-Flipping), co pozwala aktywnemu napastnikowi na manipulowanie zawartością pakietów.

Dodatkowo algorytm RC4 został w toku wieloletnich badań kryptoanalitycznych uznany za całkowicie złamany z powodu statystycznych odchyleń w generowanym strumieniu klucza (atak Fluhrera-Mantina-Shamira oraz podatności ujawnione w projekcie Bar Mitzvah). W połączeniu ze skompromitowanym mechanizmem uzgadniania kluczy w MS-CHAPv2 protokół MPPE nie zapewnia dziś realnej poufności i nie powinien być stosowany do ochrony jakiejkolwiek komunikacji biznesowej.

Wyjaśnienie skrótów użytych na slajdzie:
MPPE - Microsoft Point-to-Point Encryption - Protokół szyfrowania połączeń PPP oparty na algorytmie RC4.
RC4 - Rivest Cipher 4 - Symetryczny algorytm szyfrowania strumieniowego podatny na kryptoanalizę statystyczną.
MAC - Message Authentication Code - Kryptograficzny kod uwierzytelniania wiadomości zapewniający integralność danych.
AEAD - Authenticated Encryption with Associated Data - Nowoczesny tryb szyfrowania gwarantujący jednocześnie poufność i nienaruszalność.
PDU - Protocol Data Unit - Jednostka danych przesyłana w danej warstwie stosu sieciowego.

W systemie MikroTik RouterOS zarządzanie parametrami sesji tunelowych bazujących na protokole PPP zostało zorganizowane wokół mechanizmu profili (PPP Profiles). Profil stanowi nadrzędny wzorzec konfiguracyjny, który agreguje zbiór reguł sieciowych, adresowych i bezpieczeństwa, aplikowanych automatycznie do każdego nowo zestawianego połączenia tunelowego PPTP, L2TP, SSTP czy OpenVPN. Szczegółowe informacje normatywne i techniczne publikuje Dokumentacja RouterOS PPP.

Konfiguracja profilu odbywa się w gałęzi /ppp profile add. Do fundamentalnych parametrów profilu należy określenie adresu lokalnego (local-address) oraz zdalnego (remote-address). Parametr local-address definiuje adres IP routera widziany przez klienta jako brama domyślna wewnątrz tunelu. Z kolei remote-address wskazuje statyczny adres IP lub odwołuje się do wcześniej utworzonej puli adresów (/ip pool), z której system dynamicznie przydziela unikalną adresację dla kolejnych logujących się użytkowników zdalnych.

W ramach profilu administrator precyzuje również krytyczne ustawienia stosu sieciowego i bezpieczeństwa. Wpis dns-server wymusza adresy serwerów nazw przekazywane klientom przez protokół IPCP, co pozwala na rozwiązywanie lokalnych nazw korporacyjnych. Parametr use-encryption (przyjmujący wartości yes, no lub required) determinuje, czy sesja wymaga aktywacji szyfrowania MPPE, natomiast flaga change-tcp-mss automatycznie aplikuje mechanizm MSS Clamping, zapobiegając problemom z fragmentacją segmentów TCP.

Dobrą praktyką w zarządzaniu siecią korporacyjną jest tworzenie dedykowanych profili dla różnych grup użytkowników lub typów usług (np. profil dla administratorów o nieograniczonym paśmie i profil dla pracowników mobilnych z limitem rate-limit). Centralizacja parametrów w profilu ułatwia późniejsze audyty bezpieczeństwa i eliminuje ryzyko błędów przy ręcznym dodawaniu poszczególnych kont dostępowych.

Wyjaśnienie skrótów użytych na slajdzie:
PPP - Point-to-Point Protocol - Protokół łącza danych stanowiący bazę dla profili sesji.
DNS - Domain Name System - Protokół mapujący czytelne nazwy mnemoniczne na adresy IP.
MPPE - Microsoft Point-to-Point Encryption - Mechanizm szyfrowania połączeń PPP.
MSS - Maximum Segment Size - Maksymalny rozmiar segmentu danych przesyłany w protokole TCP.
CLI - Command Line Interface - Tekstowy interfejs zarządzania urządzeniem sieciowym.

Zarządzanie tożsamością i uprawnieniami użytkowników w podsystemie PPP systemu MikroTik RouterOS bazuje na strukturze rekordów uwierzytelniających zwanych potocznie sekretami (/ppp secret). Każdy wpis w tej tabeli reprezentuje unikalne konto klienckie, dla którego administrator definiuje nazwę logowania (name), hasło (password), typ dozwolonej usługi (service) oraz przypisany profil parametrów sesji (profile). Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 2865 (Protokół RADIUS).

W konfiguracji konta kluczowe znaczenie ma parametr service. Mimo że RouterOS pozwala na ustawienie wartości any (co umożliwia logowanie za pomocą tego samego poświadczenia do dowolnej usługi PPP), dobrą praktyką inżynierską jest ścisłe ograniczenie typu połączenia (np. service=pptp). Dodatkowo administrator może zdefiniować statyczny adres IP przydzielany konkretnemu użytkownikowi (remote-address) oraz określić dozwolony adres MAC lub publiczny adres IP klienta (caller-id), co drastycznie ogranicza ryzyko logowania ze skradzionych poświadczeń.

W przypadku małych organizacji liczących do kilkunastu pracowników utrzymywanie lokalnej bazy kont na routerze jest rozwiązaniem prostym i wystarczającym. Jednak w przedsiębiorstwach o rozproszonej strukturze lub zatrudniających setki pracowników zarządzanie lokalnymi kontami staje się nieefektywne. W takich środowiskach standardem jest integracja podsystemu PPP z zewnętrznym serwerem uwierzytelniania, autoryzacji i rozliczania AAA za pośrednictwem protokołu RADIUS (RFC 2865).

Włączenie obsługi RADIUS (/ppp aaa set use-radius=yes) przenosi cały proces weryfikacji poświadczeń do centralnego katalogu korporacyjnego (np. Microsoft Active Directory lub FreeRADIUS). Pozwala to na natychmiastowe blokowanie dostępu byłym pracownikom we wszystkich węzłach sieciowych jednocześnie oraz centralne rejestrowanie zdarzeń logowania na potrzeby audytów bezpieczeństwa teleinformatycznego.

Wyjaśnienie skrótów użytych na slajdzie:
PPP - Point-to-Point Protocol - Protokół łącza danych stanowiący bazę sesji dostępowych.
RADIUS - Remote Authentication Dial-In User Service - Standardowy protokół sieciowy do centralnego zarządzania uwierzytelnianiem i autoryzacją.
AAA - Authentication, Authorization, and Accounting - Koncepcja architektoniczna kontroli dostępu: uwierzytelnianie, autoryzacja i audytowalność.
MAC - Media Access Control - Unikalny fizyczny adres karty sieciowej w warstwie łącza danych.
CLI - Command Line Interface - Tekstowy interfejs wiersza poleceń w RouterOS.

W klasycznym modelu integracji zdalnych pracowników z siecią korporacyjną administratorzy stają przed dylematem wyboru architektury adresowej dla klientów VPN. Tradycyjne podejście polega na wydzieleniu dedykowanej podsieci dla użytkowników zdalnych (np. 10.10.0.0/24). Wymaga to jednak poprawnej konfiguracji routingu lub bram domyślnych na wszystkich serwerach i stacjach roboczych w lokalnej sieci LAN, aby wiedziały one, jak odsyłać pakiety do nowej podsieci VPN. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 1027 (Mechanizm Proxy-ARP).

W sytuacjach, gdy rekonfiguracja infrastruktury LAN jest utrudniona, rozwiązaniem jest przydzielanie klientom VPN adresów IP bezpośrednio z puli istniejącej fizycznej podsieci LAN (np. 192.168.1.200-250 w ramach sieci 192.168.1.0/24). Prowadzi to jednak do problemu w warstwie łącza danych: gdy lokalny serwer w biurze chce odpowiedzieć klientowi VPN, uznaje, że znajduje się on w tym samym segmencie Ethernet, i wysyła rozgłoszeniowe zapytanie ARP (Who has 192.168.1.200?). Ponieważ klient jest połączony logicznym tunelem PPP, zapytanie to nigdy do niego nie dotrze.

Rozwiązaniem tego problemu jest aktywacja mechanizmu Proxy-ARP na interfejsie mostka sieci lokalnej routera (/interface bridge set bridge-lan arp=proxy-arp). Zgodnie ze standardem RFC 1027 router posiadający tę funkcję podsłuchuje zapytania ARP w sieci fizycznej. Gdy wykryje zapytanie o adres IP należący do podłączonego klienta VPN, odpowiada na nie, odsyłając swój własny adres fizyczny MAC interfejsu LAN.

W rezultacie lokalny serwer wysyła ramki Ethernet bezpośrednio do routera, a router po ich odebraniu zdejmuje nagłówek warstwy 2 i przekazuje pakiet IP do odpowiedniego tunelu PPP. Choć technika ta znakomicie upraszcza wdrożenie i eliminuje potrzebę zmian w tablicach routingu urządzeń stacjonarnych, niesie za sobą ryzyko zaciemnienia topologii sieci, powiększenia tablic ARP oraz utrudnia diagnozowanie potencjalnych konfliktów adresowych.

Wyjaśnienie skrótów użytych na slajdzie:
ARP - Address Resolution Protocol - Protokół odwzorowania adresów warstwy sieciowej IP na adresy fizyczne MAC.
MAC - Media Access Control - Adres sprzętowy warstwy łącza danych.
LAN - Local Area Network - Lokalna sieć komputerowa w siedzibie przedsiębiorstwa.
PPP - Point-to-Point Protocol - Protokół łącza danych wykorzystywany w tunelu klienckim.
RFC - Request for Comments - Dokument standaryzacyjny komitetu IETF.

Protokół Point-to-Point Tunneling Protocol (PPTP) został opracowany przez konsorcjum złożone z firm Microsoft, Ascend Communications, 3Com, ECI Telecom oraz US Robotics, a jego formalna specyfikacja została opublikowana w dokumencie RFC 2637 w 1999 roku. Podstawowym celem projektu było stworzenie wydajnego, elastycznego protokołu zdalnego dostępu, zdolnego do hermetyzacji ramek PPP wewnątrz powszechnej infrastruktury IP. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 2637 (Specyfikacja PPTP).

Architektura komunikacyjna protokołu PPTP wyróżnia się podziałem na dwa całkowicie niezależne kanały transmisyjne operujące równolegle: kanał sterowania (Control Channel) oraz kanał danych (Data Channel). Kanał sterowania nawiązywany jest jako standardowe, zorientowane połączeniowo połączenie TCP na porcie serwera 1723. Służy ono wyłącznie do sygnalizacji: inicjalizacji sesji, wymiany komunikatów Start-Control-Connection-Request, uzgadniania numerów wywołań (Call ID) oraz cyklicznego badania stanu połączenia za pomocą pakietów Echo-Request.

Kanał danych realizowany jest z wykorzystaniem zmodyfikowanego protokołu Generic Routing Encapsulation (IP Protocol 47). Po pomyślnym zestawieniu sesji sterującej TCP pakiety użytkownika są hermetyzowane w standardowe ramki PPP, opcjonalnie szyfrowane za pomocą algorytmu MPPE, a następnie pakowane w nagłówki GRE i transportowane bezpośrednio przez sieć publiczną jako pakiety IP.

Rozdzielenie funkcji sterowania i transmisji danych przyniosło protokołowi PPTP istotne korzyści inżynierskie. Niezawodny protokół TCP gwarantuje bezbłędną wymianę parametrów sygnalizacyjnych, podczas gdy bezpołączeniowy protokół GRE zapewnia minimalny narzut nagłówka i niskie opóźnienia przy transferze danych użytkownika. Jednocześnie taka hybrydowa konstrukcja stworzyła ogromne wyzwania dla translatorów adresów sieciowych (NAT) oraz zaporowych reguł filtracji pakietów.

Wyjaśnienie skrótów użytych na slajdzie:
PPTP - Point-to-Point Tunneling Protocol - Protokół tunelowania VPN łączący sesję TCP z danymi GRE.
GRE - Generic Routing Encapsulation - Protokół hermetyzacji warstwy sieciowej operujący z protokołem IP 47.
TCP - Transmission Control Protocol - Niezawodny, połączeniowy protokół transportowy.
IP - Internet Protocol - Protokół warstwy internetowej odpowiedzialny za routing pakietów.
MPPE - Microsoft Point-to-Point Encryption - Mechanizm szyfrowania ładunku PPP.

Powszechnym błędem popełnianym przez początkujących inżynierów sieciowych jest przekonanie, że protokół PPTP korzysta ze standardowego nagłówka GRE opisanego w dokumencie RFC 2784. W rzeczywistości autorzy specyfikacji PPTP w dokumencie RFC 2637 wprowadzili głębokie modyfikacje do struktury GRE, tworząc wyspecjalizowany standard znany w inżynierii jako Enhanced GRE. Modyfikacje te były konieczne, aby umożliwić multipleksowanie wielu sesji użytkowników oraz kontrolę przepływu. Szczegółowe informacje normatywne i techniczne publikuje Wireshark - Narzędzie analizy protokołów.

W nagłówku Enhanced GRE pole typu protokołu (Protocol Type) przyjmuje zawsze stałą wartość szesnastkową 0x880B, co jednoznacznie identyfikuje hermetyzowany ładunek jako ramkę PPP. Ponadto pole wersji protokołu (Version) zostało zmienione z wartości 0 (standardowe GRE) na wartość 1. Kluczową innowacją jest całkowite przedefiniowanie 32-bitowego pola klucza (Key Field): w PPTP zostało ono podzielone na dwa 16-bitowe pola: Payload Length (rozmiar właściwego ładunku danych w bajtach) oraz Call ID (unikalny identyfikator wywołania).

Pole Call ID pełni fundamentalną funkcję adresową - pozwala serwerowi VPN na bezbłędne przypisanie przychodzącego pakietu GRE do konkretnej sesji tunelowej konkretnego użytkownika w sytuacji, gdy wielu klientów łączy się równolegle z tego samego publicznego adresu IP. Dodatkowo nagłówek Enhanced GRE wprowadza obowiązkowe 32-bitowe pole Sequence Number oraz opcjonalne pole Acknowledgment Number (aktywowane flagą A).

Obecność pól numeru sekwencyjnego i potwierdzenia umożliwiła zaimplementowanie w kanale GRE zaawansowanego mechanizmu kontroli przepływu opartego na oknie przesuwnym (Sliding Window Flow Control). Pozwala to odbiorcy na wykrywanie zagubionych pakietów, eliminowanie duplikatów oraz dynamiczne buforowanie ramek w celu przywrócenia ich pierwotnej kolejności przed przekazaniem do dekapsulacji PPP, co jest kluczowe dla zachowania ciągłości strumieni audio i wideo.

Wyjaśnienie skrótów użytych na slajdzie:
GRE - Generic Routing Encapsulation - Protokół tunelowania pakietów sieciowych.
PPTP - Point-to-Point Tunneling Protocol - Protokół tunelowania warstwy 2 przez sieci IP.
ACK - Acknowledgment - Pole potwierdzenia odbioru danych w protokole transmisyjnym.
PPP - Point-to-Point Protocol - Protokół łącza danych hermetyzowany wewnątrz PPTP GRE.
RFC - Request for Comments - Standard techniczny publikowany przez IETF.

Jednym z najpoważniejszych problemów eksploatacyjnych w historii protokołu PPTP była jego ograniczona interoperacyjność z mechanizmami translacji adresów sieciowych (NAT), a w szczególności z powszechnie stosowaną translacją portów (NAPT/PAT). Klasyczny translator PAT modyfikuje porty źródłowe warstwy transportowej TCP i UDP, aby umożliwić tysiącom stacji wewnętrznych jednoczesne korzystanie z jednego publicznego adresu IP. Szczegółowe informacje normatywne i techniczne publikuje IETF RFC 3022 (Tradycyjny translator NAT).

W przypadku protokołu PPTP sesja sterująca TCP na porcie 1723 przechodzi przez translator NAT bez przeszkód, ponieważ jest to standardowy ruch warstwy czwartej. Problem pojawia się w momencie uruchomienia kanału danych bazującego na protokole GRE (IP Protocol 47). Ponieważ nagłówek GRE nie posiada koncepcji portów źródłowych ani docelowych, tradycyjny router NAT nie ma technicznej możliwości ustalenia, do którego komputera w sieci lokalnej należy przekazać powracający pakiet GRE z serwera zewnętrznego.

Aby umożliwić klientom domowym zestawianie połączeń PPTP przez routery dostępowe, producenci sprzętu sieciowego musieli wdrożyć dedykowaną funkcję zwaną PPTP Passthrough, opartą na module bramy warstwy aplikacji (ALG - Application Layer Gateway). Moduł ten dokonuje głębokiej inspekcji pakietów sygnalizacyjnych TCP 1723, odczytuje przydzielone podczas negocjacji identyfikatory Call ID i dynamicznie tworzy w tablicy stanu powiązanie pomiędzy numerem Call ID w nagłówku Enhanced GRE a prywatnym adresem IP stacji klienckiej.

W systemach opartych na jądrze Linux (w tym MikroTik RouterOS) funkcję tę realizuje moduł śledzenia połączeń nf_conntrack_pptp wraz z pomocnikiem translacji nf_nat_pptp. W sytuacji, gdy router pośredniczący nie posiada aktywnego modułu PPTP ALG, z sieci lokalnej może połączyć się w danym momencie tylko jeden użytkownik VPN, a próba nawiązania sesji przez drugiego klienta kończy się niepowodzeniem i błędem zerwania łącza.

Wyjaśnienie skrótów użytych na slajdzie:
NAT - Network Address Translation - Translacja adresów sieciowych pomiędzy przestrzenią prywatną a publiczną.
PAT - Port Address Translation - Odmiana NAT współdzieląca adres publiczny w oparciu o numery portów.
ALG - Application Layer Gateway - Moduł zapory sieciowej wspomagający translację złożonych protokołów.
PPTP - Point-to-Point Tunneling Protocol - Protokół tunelowania VPN.
GRE - Generic Routing Encapsulation - Protokół enkapsulacji warstwy sieciowej.

Z punktu widzenia współczesnych standardów cyberbezpieczeństwa protokół PPTP jest uznawany za rozwiązanie całkowicie przestarzałe, skompromitowane kryptograficznie i bezwzględnie nieodpowiednie do ochrony jakiejkolwiek poufnej komunikacji korporacyjnej. Choć przez wiele lat cieszył się ogromną popularnością ze względu na prostotę konfiguracji, seria fundamentalnych odkryć kryptoanalitycznych obnażyła krytyczne wady jego architektury. Szczegółowe informacje normatywne i techniczne publikuje CSIRT NASK / CERT Polska.

Głównym źródłem dyskwalifikacji protokołu jest mechanizm uwierzytelniania MS-CHAPv2. Jak wykazano podczas konferencji DEF CON 20, algorytm ten generuje trzy niezależne bloki szyfrogramu za pomocą algorytmu DES, z których ostatni korzysta z klucza o efektywnej długości zaledwie 16 bitów, a pozostałe dwa z kluczy 56-bitowych. Oznacza to, że atakujący podsłuchujący ruch może natychmiast odzyskać część klucza, a pozostałą przestrzeń przeszukać za pomocą dedykowanych klastrów FPGA (np. serwis CloudCracker) w czasie poniżej 24 godzin.

Drugim krytycznym mankamentem jest brak właściwości Perfect Forward Secrecy (PFS). W nowoczesnych protokołach (IPsec, WireGuard, OpenVPN) klucze sesyjne są uzgadniane za pomocą algorytmu Diffie-Hellmana i usuwane po zakończeniu sesji. W PPTP klucze MPPE są wyprowadzane bezpośrednio z hasła użytkownika. Jeżeli napastnik przechwyci i zarchiwizuje zaszyfrowaną transmisję, a po roku złamie lub pozna hasło użytkownika, będzie w stanie odszyfrować całą historyczną komunikację zarejestrowaną w tym okresie.

Dodatkowe zagrożenia wynikają z podatności szyfru strumieniowego RC4 oraz całkowitego braku integralności kryptograficznej nagłówków i danych (brak kodu HMAC). Wszystkie wiodące instytucje normalizacyjne i rządowe zespoły reagowania na incydenty komputerowe - w tym NIST (publikacja SP 800-131A), CERT Polska oraz ENISA - jednoznacznie nakazują natychmiastowe wycofanie protokołu PPTP ze wszystkich systemów produkcyjnych i migrację do bezpiecznych standardów.

Wyjaśnienie skrótów użytych na slajdzie:
PPTP - Point-to-Point Tunneling Protocol - Wycofany i skompromitowany kryptograficznie protokół tunelowania VPN.
DES - Data Encryption Standard - Złamany algorytm symetryczny o 56-bitowym kluczu.
RC4 - Rivest Cipher 4 - Algorytm szyfrowania strumieniowego o udowodnionych podatnościach statystycznych.
PFS - Perfect Forward Secrecy - Kryptograficzna ochrona poufności historycznych sesji po kompromitacji poświadczeń.
NIST - National Institute of Standards and Technology - Amerykański instytut normalizacyjny definiujący standardy kryptograficzne.

Wdrożenie usługi serwera PPTP w systemie MikroTik RouterOS wymaga przeprowadzenia precyzyjnej konfiguracji w gałęzi /interface pptp-server server. Usługa serwera jest domyślnie wyłączona ze względów bezpieczeństwa i wymaga jawnej aktywacji przez administratora. Podczas konfiguracji należy zwrócić szczególną uwagę na dozwolone metody uwierzytelniania oraz przypisanie domyślnego profilu sesji. Szczegółowe informacje normatywne i techniczne publikuje Dokumentacja RouterOS PPTP.

Podstawowe polecenie aktywujące serwer ma postać: /interface pptp-server server set enabled=yes authentication=mschap2 default-profile=default-encryption keepalive-timeout=30. Z perspektywy inżynierskiej kardynalnym wymogiem jest jawne ograniczenie parametru authentication wyłącznie do metody mschap2. Pozostawienie domyślnych, słabszych mechanizmów (pap, chap, mschap1) stwarza bezpośrednie ryzyko przeprowadzenia ataku obniżenia standardu zabezpieczeń (Downgrade Attack), w którym napastnik wymusza uwierzytelnienie czystym tekstem.

Parametr keepalive-timeout definiuje czas oczekiwania na pakiety kontrolne od klienta przed uznaniem sesji za zerwaną (standardowo 30 sekund). Wartość ta zapobiega zawieszaniu się martwych interfejsów wirtualnych w systemie w sytuacji, gdy klient nagle utraci połączenie z Internetem bez wysłania komunikatu rozłączenia. Ponadto administrator może aktywować opcję max-mtu i max-mru, ograniczając maksymalny rozmiar ramki negocjowanej przez protokół LCP.

W systemie RouterOS każde aktywne połączenie klienckie jest reprezentowane jako dynamiczny interfejs wirtualny oznaczony flagą . Administrator może jednak utworzyć statyczne powiązanie interfejsu (/interface pptp-server add name=pptp-user1 user=user1), co jest wysoce zalecaną praktyką w środowiskach produkcyjnych, gdyż umożliwia wiązanie specyficznych reguł zapory sieciowej, kolejkowania QoS oraz polityk routingu ze stałą nazwą interfejsu.

Wyjaśnienie skrótów użytych na slajdzie:
PPTP - Point-to-Point Tunneling Protocol - Protokół tunelowania VPN.
MS-CHAPv2 - Microsoft Challenge Handshake Authentication Protocol v2 - Protokół uwierzytelniania wzajemnego.
QoS - Quality of Service - Mechanizmy zapewniania jakości transmisji i priorytetyzacji ruchu.
MTU - Maximum Transmission Unit - Maksymalny rozmiar pakietu sieciowego.
CLI - Command Line Interface - Interfejs wiersza poleceń systemu RouterOS.

Prawidłowe zaprojektowanie reguł zapory ogniowej (Firewall) jest krytycznym warunkiem pomyślnego uruchomienia usług PPTP na routerze brzegowym. Ponieważ serwer PPTP nasłuchuje na publicznym interfejsie WAN, ruch przychodzący od klientów zdalnych trafia do łańcucha wejściowego zapory (Input Chain). Konfiguracja wymaga odblokowania dokładnie dwóch odrębnych typów ruchu sieciowego. Szczegółowe informacje normatywne i techniczne publikuje Projekt Netfilter / Iptables.

Pierwsza reguła musi zezwalać na ruch w kanale kontrolnym TCP. Na routerze MikroTik dodaje się regułę zezwalającą na pakiety przychodzące z interfejsu WAN na port docelowy 1723: /ip firewall filter add chain=input protocol=tcp dst-port=1723 in-interface=WAN action=accept comment="Zezwalaj na kanał kontrolny PPTP". Bez tej reguły klient w ogóle nie nawiąże sesji TCP, a próba połączenia natychmiast zakończy się błędem braku osiągalności serwera.

Druga reguła jest równie istotna, lecz bardzo często pomijana przez mniej doświadczonych administratorów - dotyczy ona kanału danych i musi zezwalać na pakiety protokołu GRE: /ip firewall filter add chain=input protocol=gre in-interface=WAN action=accept comment="Zezwalaj na kanał danych GRE PPTP". Warto zauważyć, że w regule tej parametrem protocol jest wartość gre (odpowiadająca protokołowi IP 47), a nie numer portu, gdyż nagłówek GRE portów nie posiada.

W celu podniesienia poziomu bezpieczeństwa zaleca się ograniczenie dostępu do portu 1723 za pomocą dynamicznych list adresowych (Address Lists) lub reguł chroniących przed atakami brute-force. Zbyt duża liczba nieudanych prób logowania w krótkim czasie powinna skutkować automatycznym dodaniem publicznego adresu IP atakującego do czarnej listy (Blacklist) na określony czas, co skutecznie neutralizuje próby masowego odgadywania haseł kont VPN.

Wyjaśnienie skrótów użytych na slajdzie:
PPTP - Point-to-Point Tunneling Protocol - Protokół tunelowania VPN.
GRE - Generic Routing Encapsulation - Protokół warstwy internetowej o numerze 47.
TCP - Transmission Control Protocol - Protokół sterujący sesją sygnalizacyjną PPTP.
WAN - Wide Area Network - Interfejs publiczny narażony na ataki sieciowe.
CLI - Command Line Interface - Interfejs tekstowy do zarządzania zaporą.

Jedną z głównych przyczyn wieloletniej popularności protokołu PPTP w środowiskach biznesowych była jego natywna integracja ze wszystkimi wersjami systemów operacyjnych Microsoft Windows, począwszy od Windows 95 i Windows NT 4.0. Użytkownik końcowy nie musiał instalować żadnego dedykowanego oprogramowania firm trzecich, a cała konfiguracja sprowadzała się do wypełnienia prostego kreatora w panelu sieciowym. Szczegółowe informacje normatywne i techniczne publikuje Microsoft Learn - Sieci Windows Server.

W nowoczesnych wersjach systemów Windows 10 oraz Windows 11 procedurę rozpoczyna się od przejścia do panelu Ustawienia -> Sieć i Internet -> VPN, a następnie wybrania opcji Dodaj połączenie VPN. W nowo otwartym formularzu kreatora pole Dostawca sieci VPN należy ustawić na wartość Windows (wbudowane), co instruuje system o konieczności użycia natywnego stosu sterowników WAN Miniport.

W polu Nazwa połączenia wprowadza się dowolną, czytelną dla użytkownika etykietę mnemoniczną (np. Biuro VPN), natomiast w polu Nazwa lub adres serwera podaje się publiczny adres IP bramy VPN lub jej w pełni kwalifikowaną nazwę domenową (FQDN). Zastosowanie nazwy domenowej jest wysoce zalecane, gdyż umożliwia elastyczną zmianę adresu IP routera brzegowego po stronie firmy bez konieczności rekonfiguracji stacji roboczych wszystkich pracowników mobilnych.

Kluczowym ustawieniem na tym etapie jest parametr Typ sieci VPN. System domyślnie ustawia wartość Automatycznie, co powoduje sekwencyjne testowanie protokołów IKEv2, SSTP, L2TP i PPTP. Aby skrócić czas zestawiania połączenia i uniknąć niejednoznaczności, należy jawnie wybrać z listy opcję Protokół PPTP (Point-to-Point Tunneling Protocol), a w sekcji Typ informacji logowania wskazać Nazwę użytkownika i hasło.

Wyjaśnienie skrótów użytych na slajdzie:
VPN - Virtual Private Network - Wirtualna sieć prywatna zdalnego dostępu.
PPTP - Point-to-Point Tunneling Protocol - Protokół tunelowania warstwy 2 zintegrowany z systemem Windows.
FQDN - Fully Qualified Domain Name - Pełna nazwa domenowa węzła w hierarchii DNS.
GUI - Graphical User Interface - Graficzny interfejs użytkownika systemu operacyjnego.
OS - Operating System - System operacyjny stacji roboczej klienta.

Wstępne utworzenie profilu VPN w nowoczesnym interfejsie Ustawienia systemu Windows nie wyczerpuje wymogów poprawnej i bezpiecznej konfiguracji połączenia. Kreator systemowy stosuje domyślnie permisywne reguły negocjacji, które mogą doprowadzić do zestawienia nieszyfrowanego połączenia ze słabymi metodami uwierzytelniania. Konieczne jest przejście do klasycznego apletu połączeń sieciowych (polecenie ncpa.cpl). Szczegółowe informacje normatywne i techniczne publikuje Microsoft Learn - Zarządzanie łączami VPN.

Po kliknięciu prawym przyciskiem myszy na utworzoną wirtualną kartę VPN i wybraniu Właściwości należy przejść do zakładki Zabezpieczenia. W polu Szyfrowanie danych należy bezwzględnie zmienić domyślne ustawienie opcjonalne na Wymagaj szyfrowania (rozłącz, jeśli serwer odrzuci). Wymuszenie tego parametru gwarantuje, że stacja robocza natychmiast zerwie sesję, jeżeli serwer VPN nie wynegocjuje aktywnego szyfrowania MPPE.

W sekcji Uwierzytelnianie należy zaznaczyć opcję Zezwalaj na następujące protokoły, a następnie pozostawić zaznaczoną wyłącznie pozycję Microsoft CHAP Version 2 (MS-CHAP v2). Należy bezwzględnie upewnić się, że pola Nieszyfrowane hasło (PAP) oraz Protokół CHAP są odznaczone. Zezwolenie na protokoły PAP lub CHAP otwiera podatność na ataki typu downgrade, w których podsłuchujący napastnik może wymusić przesłanie poświadczeń otwartym tekstem.

W środowiskach korporacyjnych zarządzanych przez domeny Active Directory administratorzy mogą dodatkowo zaznaczyć opcję Automatycznie użyj mojej nazwy logowania i hasła systemu Windows (i domeny, jeśli istnieje). Umożliwia to realizację mechanizmu pojedynczego logowania (Single Sign-On - SSO), w którym pracownik logujący się do laptopa uzyskuje automatyczny dostęp do zasobów VPN bez konieczności ponownego wpisywania poświadczeń domenowych.

Wyjaśnienie skrótów użytych na slajdzie:
PPTP - Point-to-Point Tunneling Protocol - Protokół tunelowania VPN.
MS-CHAPv2 - Microsoft Challenge Handshake Authentication Protocol version 2 - Protokół uwierzytelniania wzajemnego.
MPPE - Microsoft Point-to-Point Encryption - Mechanizm szyfrowania połączenia.
SSO - Single Sign-On - Mechanizm pojedynczego logowania w środowiskach sieciowych.
GUI - Graphical User Interface - Graficzny interfejs konfiguracji parametrów sieciowych.

W domyślnej konfiguracji klienta VPN system operacyjny Windows wymusza model pełnego tunelowania (Full Tunneling). Oznacza to, że po pomyślnym zestawieniu połączenia system przypisuje interfejsowi VPN najwyższy priorytet i instaluje w tablicy routingu nową trasę domyślną 0.0.0.0/0 z niższą metryką niż fizyczna karta sieciowa. W rezultacie cały ruch stacji roboczej - w tym pobieranie dużych plików, transmisje strumieniowe oraz przeglądanie publicznych stron WWW - jest przesyłany przez łącze centrali firmy. Szczegółowe informacje normatywne i techniczne publikuje Urząd Ochrony Danych Osobowych.

W większości scenariuszy biznesowych pełne tunelowanie prowadzi do drastycznego i nieuzasadnionego przeciążenia łącza internetowego w siedzibie przedsiębiorstwa, generując wysokie opóźnienia dla systemów produkcyjnych. Rozwiązaniem tego problemu jest wdrożenie dzielonego tunelowania (Split Tunneling). W systemie Windows procedurę realizuje się we właściwościach adaptera VPN: w zakładce Sieć należy wybrać Protokół internetowy w wersji 4 (TCP/IPv4), kliknąć Właściwości, następnie Zaawansowane i odznaczyć pole Użyj domyślnej bramy w sieci zdalnej.

Wyłączenie domyślnej bramy powoduje, że stacja robocza kieruje ruch internetowy bezpośrednio przez lokalnego dostawcę Internetu (np. domowe łącze światłowodowe lub Wi-Fi). Aby klient mógł komunikować się z serwerami korporacyjnymi, konieczne jest jednak przekazanie mu tras do konkretnych podsieci firmowych. Można to zrealizować poprzez polecenie PowerShell Add-VpnConnectionRoute, wdrożenie protokołu DHCP z opcją 121 (Classless Static Route) na serwerze dostępowym lub dynamiczne rozgłaszanie tras w protokole IPCP.

Należy jednak pamiętać o kardynalnym kompromisie z zakresu bezpieczeństwa: stacja robocza z aktywnym dzielonym tunelowaniem staje się urządzeniem o podwójnym połączeniu (Dual-Homed Host). Jeżeli domowa sieć pracownika zostanie zainfekowana przez złośliwe oprogramowanie, komputer może posłużyć cyberprzestępcom jako niekontrolowany pomost tranzytowy do przeniknięcia bezpośrednio do chronionej sieci korporacyjnej, omijając brzegowe systemy inspekcji ruchu IDS/IPS.

Wyjaśnienie skrótów użytych na slajdzie:
VPN - Virtual Private Network - Wirtualna sieć prywatna zdalnego dostępu.
LAN - Local Area Network - Lokalna sieć komputerowa w siedzibie firmy lub domu pracownika.
WAN - Wide Area Network - Łącze dostępu do sieci rozległej.
DHCP - Dynamic Host Configuration Protocol - Protokół automatycznej konfiguracji parametrów sieciowych.
IDS - Intrusion Detection System - System detekcji intruzów analizujący ruch pod kątem anomalii.
IPS - Intrusion Prevention System - System aktywnego zapobiegania włamaniom blokujący złośliwy ruch.

Błąd 619 (o oficjalnej treści: Nie można ustanowić połączenia z komputerem zdalnym, więc port używany dla tego połączenia został zamknięty) należy do najczęściej spotykanych i najbardziej charakterystycznych komunikatów diagnostycznych w eksploatacji protokołu PPTP. Z perspektywy inżynierskiej błąd ten sygnalizuje asymetryczną awarię stosu transmisyjnego: sesja kontrolna TCP na porcie 1723 została pomyślnie zainicjowana, lecz kanał danych GRE nie był w stanie nawiązać dwukierunkowej komunikacji. Szczegółowe informacje normatywne i techniczne publikuje Baza podatności NVD NIST.

W przeważającej większości przypadków bezpośrednią przyczyną błędu 619 jest zablokowanie pakietów z protokołem IP 47 na trasie transmisyjnej między klientem a serwerem. Blokada ta może wynikać z restrykcyjnych polityk dostawcy Internetu (ISP), filtracji ruchu w publicznych sieciach hotelowych i kawiarnianych Wi-Fi lub braku odpowiedniej reguły zezwalającej w łańcuchu wejściowym zapory sieciowej na routerze centralnym.

Drugą powszechną przyczyną jest niepoprawne działanie translatora NAT w routerze domowym użytkownika. Jeżeli urządzenie dostępowe klienta nie posiada poprawnej implementacji mechanizmu PPTP Passthrough (modułu ALG), nie potrafi powiązać powracających pakietów GRE z lokalnym komputerem, co powoduje ich ciche porzucenie. Problem ten występuje ze szczególnym nasileniem, gdy z tej samej sieci domowej próbują połączyć się równolegle dwie stacje robocze.

Procedura diagnostyczna inżyniera sieciowego w przypadku błędu 619 polega na uruchomieniu analizatora Wireshark na stacji roboczej klienta oraz inspekcji logów zapory na serwerze MikroTik. Jeżeli w zrzucie pakietów widoczne jest poprawne trójfazowe uzgadnianie TCP na porcie 1723, a po nim następuje wysłanie pakietu GRE ze strony klienta przy całkowitym braku pakietów odpowiedzi, problem jednoznacznie leży w blokadzie protokołu IP 47 po stronie sieci dostępowej lub zapory.

Wyjaśnienie skrótów użytych na slajdzie:
PPTP - Point-to-Point Tunneling Protocol - Protokół tunelowania VPN.
GRE - Generic Routing Encapsulation - Protokół hermetyzacji pakietów warstwy sieciowej (IP 47).
TCP - Transmission Control Protocol - Protokół sterowania sesją na porcie 1723.
NAT - Network Address Translation - Translacja adresów sieciowych.
ALG - Application Layer Gateway - Brama warstwy aplikacji wspomagająca przechodzenie protokołów przez NAT.
ISP - Internet Service Provider - Dostawca usług internetowych pośredniczący w transmisji.

Kody błędów 800 oraz 807 w systemie Windows reprezentują awarie na najniższych szczeblach stosu komunikacyjnego VPN. Błąd 800 (komunikat informujący, że serwer VPN jest nieosiągalny lub parametry zabezpieczeń są nieprawidłowe) wskazuje na całkowity brak możliwości nawiązania nawet wstępnego połączenia TCP na porcie 1723. Klient nie otrzymuje żadnej odpowiedzi na wysłany pakiet TCP SYN, co uniemożliwia rozpoczęcie jakichkolwiek negocjacji sesji. Szczegółowe informacje normatywne i techniczne publikuje Urząd Komunikacji Elektronicznej.

Główną przyczyną błędu 800 jest błąd w konfiguracji adresu serwera (literówka w adresie IP lub brak możliwości rozwiązania nazwy domenowej FQDN w systemie DNS). Inne częste źródła problemu to fizyczna awaria łącza po stronie serwera, wyłączenie usługi PPTP w systemie RouterOS, zmiana publicznego adresu IP serwera przez dostawcę bez aktualizacji rekordu DNS lub całkowita blokada portu TCP 1723 przez zaporę sieciową dostawcy Internetu.

Weryfikację problemu przeprowadza się za pomocą narzędzi diagnostycznych wiersza poleceń. Pierwszym krokiem jest sprawdzenie translacji nazw za pomocą polecenia nslookup, a następnie przetestowanie otwarcia portu warstwy transportowej za pomocą polecenia PowerShell: Test-NetConnection -ComputerName vpn.firma.pl -Port 1723. Brak odpowiedzi TCP jednoznacznie lokalizuje problem po stronie osiągalności serwera lub konfiguracji reguł zapory na styku WAN.

Z kolei błąd 807 pojawia się zazwyczaj w trakcie trwania aktywnej sesji lub pod sam koniec procesu negocjacji i oznacza nagłe zerwanie połączenia przez zakłócenia transmisyjne. Najczęściej wynika on z drastycznej niestabilności łącza radiowego (wysoki jitter, gwałtowne skoki opóźnień RTT przekraczające limit keepalive), restartu routera pośredniczącego lub agresywnego resetowania sesji przez systemy zapobiegania włamaniom (IPS) analizujące ruch w sieciach tranzytowych.

Wyjaśnienie skrótów użytych na slajdzie:
VPN - Virtual Private Network - Wirtualna sieć prywatna.
TCP - Transmission Control Protocol - Protokół transportowy sterujący kanałem sygnalizacyjnym.
DNS - Domain Name System - System nazw domenowych tłumaczący nazwy hostów na adresy IP.
FQDN - Fully Qualified Domain Name - Pełna nazwa domenowa serwera VPN.
RTT - Round Trip Time - Czas obiegu pakietu w obie strony w medium transmisyjnym.
IPS - Intrusion Prevention System - System aktywnego zapobiegania atakom w sieciach teleinformatycznych.

W przeciwieństwie do błędów sieciowych i transportowych, kod błędu 691 (komunikat: Połączenie zdalne zostało odrzucone, ponieważ podana kombinacja nazwy użytkownika i hasła jest nierozpoznana lub wybrany protokół uwierzytelniania jest niedozwolony) świadczy o pełnej sprawności łącza transmisyjnego. Zarówno kanał kontrolny TCP, jak i kanał danych GRE działają poprawnie, a problem występuje w logicznej fazie uwierzytelniania sesji PPP. Szczegółowe informacje normatywne i techniczne publikuje CSIRT KNF - Sektor finansowy.

W toku negocjacji serwer dostępowy weryfikuje poświadczenia przekazane w pakiecie odpowiedzi MS-CHAPv2. Jeżeli wyliczona wartość skrótu nie zgadza się ze wzorcem zapisanym w lokalnej bazie sekretów (/ppp secret) lub w centralnym katalogu RADIUS, serwer przesyła komunikat Authenticate-Failure (lub LCP Terminate-Request), co klient interpretuje jako odmowę dostępu i prezentuje użytkownikowi kod 691.

Do typowych przyczyn wystąpienia tego błędu należą: prosta pomyłka pisarska w nazwie użytkownika lub haśle (w tym uwzględnianie wielkości liter), wygaśnięcie ważności hasła domenowego w systemie Active Directory, zablokowanie konta z powodu przekroczenia limitu nieudanych prób logowania lub brak uprawnień pracownika do korzystania z usług zdalnego dostępu (brak członkostwa w dedykowanej grupie zabezpieczeń).

Błąd 691 może wynikać również z restrykcji zdefiniowanych w profilu serwera RouterOS. Przykładowo, jeżeli konto użytkownika posiada jawne ograniczenie parametru caller-id, a pracownik próbuje nawiązać połączenie z innego adresu publicznego lub z nowej karty sieciowej, router natychmiast odrzuci próbę logowania. Skuteczna weryfikacja problemu po stronie administratora polega na analizie dziennika zdarzeń routera (/log print where topics~"ppp"), gdzie system rejestruje precyzyjny powód odrzucenia sesji.

Wyjaśnienie skrótów użytych na slajdzie:
PPP - Point-to-Point Protocol - Protokół poziomu łącza danych.
MS-CHAPv2 - Microsoft Challenge Handshake Authentication Protocol v2 - Protokół uwierzytelniania wzajemnego.
RADIUS - Remote Authentication Dial-In User Service - Centralny serwer poświadczeń i polityk dostępowych.
AAA - Authentication, Authorization, and Accounting - Standard kontroli dostępu do zasobów sieciowych.
CLI - Command Line Interface - Interfejs tekstowy wiersza poleceń RouterOS.

Mimo że protokół PPTP został zaprojektowany z myślą o scenariuszach zdalnego dostępu dla pojedynczych stacji roboczych (model Remote Access), elastyczność systemu MikroTik RouterOS pozwala na wykorzystanie go do budowy stałych połączeń międzyoddziałowych typu router-router (Site-to-Site). W takim modelu jeden z routerów pełni rolę serwera PPTP, natomiast router w odległym oddziale konfiguruje się jako stałego klienta PPTP. Szczegółowe informacje normatywne i techniczne publikuje Naukowa i Akademicka Sieć Komputerowa.

Konfiguracja klienta w systemie RouterOS sprowadza się do utworzenia logicznego interfejsu w gałęzi /interface pptp-client add. Administrator podaje adres publiczny serwera centralnego (connect-to), poświadczenia logowania (user i password) oraz przypisuje profil sesji. Kluczowym parametrem jest add-default-route=no - w połączeniach Site-to-Site router oddziałowy nie powinien podmieniać swojej bramy internetowej, a jedynie wymieniać ruch z konkretnymi podsieciami centrali.

Po zestawieniu tunelu w systemie pojawia się logiczny interfejs punkt-punkt, który otrzymuje adresację IP z serwera centralnego. Aby umożliwić komputerom z sieci LAN w oddziale komunikację z serwerami w centrali, administrator dodaje trasę statyczną (/ip route add dst-address=192.168.10.0/24 gateway=pptp-out1) lub uruchamia instancję protokołu routingu dynamicznego OSPF na interfejsie tunelowym.

Wdrożenie modelu Site-to-Site w oparciu o PPTP było w przeszłości chętnie stosowane ze względu na niezwykłą prostotę konfiguracji za translatorami NAT oraz minimalne obciążenie tanich routerów brzegowych. Współcześnie jednak stosowanie PPTP do łączenia oddziałów jest kardynalnym błędem architektonicznym ze względu na całkowitą kompromitację kryptograficzną protokołu. Ruch przesyłany między oddziałami należy traktować jako całkowicie jawny i podatny na manipulację.

Wyjaśnienie skrótów użytych na slajdzie:
PPTP - Point-to-Point Tunneling Protocol - Protokół tunelowania warstwy 2.
OSPF - Open Shortest Path First - Protokół routingu dynamicznego stanu łącza.
LAN - Local Area Network - Lokalna sieć komputerowa w oddziale firmy.
WAN - Wide Area Network - Infrastruktura publiczna łącząca routery.
CLI - Command Line Interface - Interfejs wiersza poleceń RouterOS.

Jedynym wymiernym parametrem technicznym, w którym protokół PPTP wykazuje przewagę nad wieloma konkurencyjnymi rozwiązaniami, jest jego bardzo niska złożoność obliczeniowa i wysoka wydajność pakietowa. Wynika to bezpośrednio z prostoty konstrukcji protokołu oraz specyfiki zastosowanego mechanizmu szyfrowania MPPE. Szczegółowe informacje normatywne i techniczne publikuje Dokumentacja jądra Linux.

Wykorzystywany w MPPE algorytm RC4 jest szyfrem strumieniowym, którego operacje matematyczne ograniczają się do prostych permutacji w 256-bajtowej tablicy stanu oraz operacji bitowych XOR na strumieniu danych. W przeciwieństwie do zaawansowanych szyfrów blokowych AES operujących w trybach CBC lub GCM, RC4 nie wymaga skomplikowanych przekształceń macierzowych w ciałach Galois ani intensywnych obliczeniowo operacji mnożenia wielomianów.

W epoce wczesnych platform sieciowych opartych na jednoukładowych, jednordzeniowych procesorach MIPS lub ARM o taktowaniu rzędu kilkuset megaherców (np. popularne routery MikroTik serii RB750 czy RB951), implementacja szyfrowania AES w protokole IPsec prowadziła do natychmiastowego wysycenia procesora do 100%, ograniczając przepustowość tunelu do zaledwie 10-15 Mb/s. Na tym samym sprzęcie tunel PPTP z szyfrowaniem MPPE bez trudu osiągał pełną prędkość interfejsów 100 Mb/s.

Współcześnie argument wydajnościowy całkowicie stracił rację bytu. Nowoczesne procesory stosowane w routerach i stacjach roboczych posiadają dedykowane instrukcje sprzętowe wspomagające kryptografię AES (instrukcje AES-NI) oraz sprzętowe silniki kryptograficzne, które pozwalają na szyfrowanie AES-GCM z prędkościami rzędu wielu gigabitów na sekundę bez obciążania rdzeni głównych. Ponadto protokoły nowej generacji, takie jak WireGuard, osiągają wyższą wydajność niż PPTP przy zachowaniu bezkompromisowego bezpieczeństwa.

Wyjaśnienie skrótów użytych na slajdzie:
PPTP - Point-to-Point Tunneling Protocol - Protokół tunelowania VPN.
CPU - Central Processing Unit - Główny procesor obliczeniowy urządzenia sieciowego.
AES - Advanced Encryption Standard - Współczesny symetryczny szyfr blokowy.
RC4 - Rivest Cipher 4 - Lekki obliczeniowo, lecz złamany kryptograficznie szyfr strumieniowy.
ARM - Advanced RISC Machine - Architektura procesorów o zredukowanym zestawie instrukcji.
MIPS - Microprocessor without Interlocked Pipelined Stages - Architektura procesorów stosowana w routerach sieciowych.

Protokół Ethernet over IP (EoIP) to własnościowe rozwiązanie inżynierskie opracowane przez firmę MikroTik, mające na celu przezwyciężenie fundamentalnego ograniczenia standardowego protokołu GRE, który operuje wyłącznie w warstwie 3 modelu OSI. Protokół EoIP umożliwia hermetyzację pełnych ramek standardu Ethernet (warstwa 2) wewnątrz pakietów IP, co pozwala na przezroczyste mostkowanie odległych segmentów sieci lokalnych przez sieć publiczną. Szczegółowe informacje normatywne i techniczne publikuje Dokumentacja RouterOS EoIP.

W warstwie transportowej EoIP bazuje bezpośrednio na protokole GRE (IP Protocol 47) z nagłówkiem zgodnym z wczesną specyfikacją RFC 1701. W nagłówku GRE umieszczany jest 16-bitowy identyfikator tunelu (Tunnel ID). Po obu stronach połączenia administrator konfiguruje interfejs EoIP (/interface eoip add remote-address=... tunnel-id=...), a następnie dodaje go do lokalnego mostka sieciowego (Bridge) wraz z fizycznymi portami Ethernet. W ten sposób powstaje jednolita domena rozgłoszeniowa rozciągnięta pomiędzy odległymi miastami.

Niezwykle istotnym zagadnieniem inżynierskim przy stosowaniu protokołu EoIP jest narzut nagłówków ramki. Pakiet EoIP składa się z: zewnętrznego nagłówka IP (20 B), nagłówka GRE z identyfikatorem (8 B) oraz pełnej wewnętrznej ramki Ethernetowej wraz z nagłówkiem MAC (14 B). Łączny narzut wynosi dokładnie 42 bajty. Jeśli fizyczna sieć Ethernet ma MTU 1500 bajtów, efektywne MTU dla danych wewnątrz mostka spada do 1458 bajtów, co bez odpowiedniej konfiguracji MSS Clamping lub powiększenia L2MTU na łączach tranzytowych prowadzi do fragmentacji.

Mostkowanie sieci przez Internet za pomocą EoIP znajduje zastosowanie w specyficznych scenariuszach przemysłowych, systemach automatyki budynkowej (gdzie sterowniki PLC wymagają wspólnej podsieci i komunikacji broadcastowej) oraz przy migracji wirtualnych maszyn bez zmiany adresacji IP. Należy jednak pamiętać, że przenoszenie ruchu rozgłoszeniowego przez Internet stwarza ogromne ryzyko powstawania burz rozgłoszeniowych (Broadcast Storms), co wymusza bezwzględne stosowanie protokołów drzewa rozpinającego (STP/RSTP).

Wyjaśnienie skrótów użytych na slajdzie:
EoIP - Ethernet over IP - Autorski protokół MikroTik tunelujący ramki warstwy 2 wewnątrz IP/GRE.
GRE - Generic Routing Encapsulation - Protokół bazowy dla pakietów transportowych EoIP.
MAC - Media Access Control - Adres fizyczny warstwy łącza danych przesyłany w tunelu.
VLAN - Virtual Local Area Network - Wirtualna sieć lokalna standardu IEEE 802.1Q.
STP - Spanning Tree Protocol - Protokół drzewa rozpinającego zapobiegający pętlom w warstwie 2.
RSTP - Rapid Spanning Tree Protocol - Szybka wersja protokołu drzewa rozpinającego.

W praktyce inżynierii sieciowej administratorzy nierzadko spotykają się ze stanem zastanym, w którym natychmiastowa rezygnacja z protokołu PPTP jest niemożliwa z przyczyn biznesowych, organizacyjnych lub z powodu obecności przestarzałych urządzeń przemysłowych nieobsługujących nowocześniejszych standardów. W takich wyjątkowych okolicznościach bezwzględnym obowiązkiem inżyniera jest wdrożenie strategii minimalizacji ryzyka (Risk Mitigation). Szczegółowe informacje normatywne i techniczne publikuje Niemiecki Federalny Urząd Bezpieczeństwa Informacji (BSI).

Pierwszą i najważniejszą linią obrony jest radykalne zaostrzenie polityki haseł. Ponieważ podatność MS-CHAPv2 redukuje bezpieczeństwo do 56-bitowego klucza DES, a narzędzia kryptoanalityczne w pierwszej kolejności wykorzystują słowniki tęczowe i ataki słownikowe, hasła użytkowników PPTP muszą być generowane w sposób całkowicie losowy i liczyć co najmniej 25-30 znaków (wielkie i małe litery, cyfry oraz znaki specjalne). Złożone hasło o wysokiej entropii skutecznie uniemożliwia odgadnięcie skrótu metodami słownikowymi.

Drugim filarem bezpieczeństwa jest rygorystyczna izolacja strefowa (Zone Isolation). Ruch przychodzący z tuneli PPTP nie może pod żadnym pozorem trafiać bezpośrednio do głównej sieci produkcyjnej LAN. Pule adresowe PPTP należy zamknąć w odrębnej strefie zdemilitaryzowanej (DMZ) lub wydzielonym VLAN-ie, a na zaporze ogniowej zezwolić wyłącznie na ściśle zdefiniowane połączenia do pojedynczych serwerów pośredniczących (np. bramy pulpitów zdalnych RDP z aktywnym uwierzytelnianiem MFA).

Dodatkowo zaleca się filtrowanie dostępu do portu TCP 1723 za pomocą białych list adresowych (IP Whitelisting), dopuszczając połączenia wyłącznie ze znanych, statycznych adresów IP pracowników. Wszystkie te działania należy traktować wyłącznie jako tymczasowe środki zaradcze. Równolegle kierownictwo działu IT powinno opracować formalny harmonogram całkowitej migracji do nowoczesnych, bezpiecznych technologii VPN.

Wyjaśnienie skrótów użytych na slajdzie:
PPTP - Point-to-Point Tunneling Protocol - Protokół tunelowania VPN podwyższonego ryzyka.
DMZ - Demilitarized Zone - Wydzielona strefa sieciowa o kontrolowanym poziomie zaufania.
VLAN - Virtual Local Area Network - Logicznie wyodrębniona podsieć lokalna.
RDP - Remote Desktop Protocol - Protokół zdalnego pulpitu firmy Microsoft.
MFA - Multi-Factor Authentication - Uwierzytelnianie wieloskładnikowe wymagające dodatkowego tokena.
BSI - Bundesamt für Sicherheit in der Informationstechnik - Niemiecki Federalny Urząd Bezpieczeństwa Informacji.

Wycofanie protokołu PPTP wymusiło na inżynierach sieciowych wdrożenie bezpiecznych alternatyw, które łączą wysoki poziom poufności i integralności z prostotą obsługi przez użytkowników końcowych. W ekosystemie systemów Microsoft Windows najbardziej naturalnym i bezpośrednim następcą PPTP stał się protokół SSTP (Secure Socket Tunneling Protocol). SSTP hermetyzuje ramki PPP wewnątrz bezpiecznego tunelu TLS na porcie TCP 443, co gwarantuje bezproblemowe przechodzenie przez dowolne zapory ogniowe i translatory NAT. Szczegółowe informacje normatywne i techniczne publikuje Agencja Unii Europejskiej ds. Cyberbezpieczeństwa (ENISA).

W środowiskach korporacyjnych wymagających najwyższego poziomu standaryzacji i bezpieczeństwa dominuje protokół IKEv2/IPsec. Jest on natywnie wspierany przez wszystkie nowoczesne systemy operacyjne (Windows, macOS, iOS, Android, Linux) i oferuje zaawansowane szyfrowanie blokowe AES-GCM z uwierzytelnianiem asymetrycznym za pomocą certyfikatów X.509. Kluczową zaletą IKEv2 jest obsługa standardu MOBIKE (RFC 4555), co pozwala pracownikom mobilnym na płynne przełączanie sesji VPN pomiędzy sieciami Wi-Fi a łączami komórkowymi LTE/5G bez przerywania transmisji.

Niezwykle silną pozycję na rynku utrzymuje technologia OpenVPN, oparta na bibliotece OpenSSL. Umożliwia ona elastyczny transport danych w protokołach UDP lub TCP na dowolnym porcie oraz oferuje zaawansowane mechanizmy dystrybucji konfiguracji i integracji z wieloskładnikowym uwierzytelnianiem MFA. Z kolei w rozwiązaniach infrastruktury chmurowej i nowoczesnych sieciach szkieletowych bezapelacyjnym liderem stał się protokół WireGuard.

WireGuard redefiniuje prostotę i wydajność w sieciach VPN, wykorzystując ultranowoczesne algorytmy kryptograficzne: symetryczny szyfr ChaCha20 z tagiem uwierzytelniającym Poly1305 oraz krzywą eliptyczną Curve25519 do wymiany kluczy. Dzięki implementacji bezpośrednio w przestrzeni jądra systemu operacyjnego (Kernel Space) WireGuard oferuje najniższe opóźnienia i maksymalną przepustowość, stanowiąc doskonały wybór dla nowoczesnych projektów teleinformatycznych.

Wyjaśnienie skrótów użytych na slajdzie:
SSTP - Secure Socket Tunneling Protocol - Protokół tunelowania warstwy 2 przez szyfrowany kanał TLS 443.
IKEv2 - Internet Key Exchange version 2 - Protokół negocjacji kluczy i parametrów bezpieczeństwa dla IPsec.
IPsec - Internet Protocol Security - Standardowy zestaw protokołów kryptograficznych warstwy sieciowej.
TLS - Transport Layer Security - Protokół kryptograficzny warstwy transportowej.
AES - Advanced Encryption Standard - Współczesny szyfr blokowy.
MOBIKE - IKEv2 Mobility and Multihoming Protocol - Rozszerzenie IKEv2 umożliwiające płynny roaming klienta VPN.

Druga część cyklu wykładów poświęconego technologiom wirtualnych sieci prywatnych dostarczyła studentom dogłębnej wiedzy na temat ewolucji i zasad działania klasycznych protokołów tunelowania. Szczegółowo przeanalizowano protokół GRE (IP Protocol 47), który mimo braku wbudowanego szyfrowania pozostaje niezastąpionym standardem enkapsulacji ruchu wieloprotokołowego i rozgłoszeniowego w sieciach szkieletowych, wymagając jednak precyzyjnego zarządzania parametrami MTU i mechanizmem MSS Clamping. Szczegółowe informacje normatywne i techniczne publikuje Polski Komitet Normalizacyjny.

W module poświęconym standardowi PPP omówiono modularną architekturę podprotokołów LCP i NCP, formalny automat stanów oraz metody uwierzytelniania użytkowników. Przeanalizowano historyczną ewolucję mechanizmów weryfikacji tożsamości - od nieszyfrowanego protokołu PAP, przez schemat wyzwanie-odpowiedź w CHAP, aż po wzajemne uwierzytelnianie MS-CHAPv2 i szyfrowanie ładunku za pomocą mechanizmu MPPE.

Studenci zapoznali się również z architekturą protokołu PPTP, mechanizmami separacji kanału sterującego TCP 1723 i kanału danych Enhanced GRE, specyfiką przechodzenia przez translację adresów NAT oraz konfiguracją urządzeń w systemie MikroTik RouterOS i stacji klienckich Windows. Krytyczna ocena kryptoanalityczna jednoznacznie wykazała, że podatności MS-CHAPv2, podatności szyfru RC4 oraz brak Perfect Forward Secrecy dyskwalifikują protokół PPTP z jakichkolwiek zastosowań produkcyjnych.

W ramach przygotowania do kolejnych zajęć laboratoryjnych studenci zobowiązani są do wykonania ćwiczenia polegającego na uruchomieniu tunelu GRE w środowisku wirtualnym oraz analizie zrzutu pakietów w programie Wireshark. Na kolejnym wykładzie przejdziemy do szczegółowego omówienia protokołów wyższej generacji: standardu SSTP opartego na protokole TLS oraz architektury L2TP zintegrowanej ze stosem IPsec.

Wyjaśnienie skrótów użytych na slajdzie:
GRE - Generic Routing Encapsulation - Protokół enkapsulacji warstwy sieciowej.
PPP - Point-to-Point Protocol - Standard komunikacji punkt-punkt.
PPTP - Point-to-Point Tunneling Protocol - Klasyczny protokół VPN zdalnego dostępu.
SSTP - Secure Socket Tunneling Protocol - Protokół VPN bazujący na kanale TLS 443.
L2TP - Layer 2 Tunneling Protocol - Protokół tunelowania warstwy 2 integrowany z IPsec.
IPsec - Internet Protocol Security - Kryptograficzny standard bezpieczeństwa warstwy IP.