Ta część wykładu koncentruje się na protokołach, które ukształtowały wczesny krajobraz technologii VPN i wciąż stanowią podstawę wielu współczesnych wdrożeń. Znajomość GRE, PPP i PPTP jest niezbędna do zrozumienia bardziej zaawansowanych rozwiązań, takich jak L2TP/IPSec czy OpenVPN, które często korzystają z tych samych mechanizmów enkapsulacji i negocjacji połączenia. GRE jest szczególnie interesujący ze względu na swoją uniwersalność - może przenosić praktycznie dowolny protokół warstwy wyższej, co czyni go niezwykle elastycznym narzędziem w rękach administratora sieci. PPP z kolei wprowadza warstwę kontroli sesji i uwierzytelniania, która jest niezbędna w kontekście zdalnego dostępu dla wielu użytkowników. PPTP, mimo swoich poważnych wad bezpieczeństwa, stanowi interesujący przypadek studyjny ilustrujący ewolucję myślenia o bezpieczeństwie w sieciach komputerowych.

Studenci powinni zwrócić szczególną uwagę na zależności między poszczególnymi protokołami - GRE stanowi warstwę transportową dla PPTP, a PPP dostarcza mechanizmy uwierzytelniania i adresacji. Zrozumienie tych powiązań jest kluczowe przy projektowaniu i diagnostyce sieci VPN w środowiskach produkcyjnych. W trakcie laboratoriów będziemy konfigurować każdy z tych protokołów na rzeczywistych urządzeniach MikroTik, co pozwoli na praktyczne utrwalenie omawianych zagadnień teoretycznych.

GRE jest protokołem tunelowania o niezwykle szerokim spektrum zastosowań, który mimo swojego podeszłego wieku wciąż znajduje zastosowanie w nowoczesnych sieciach. Jego główną zaletą jest prostota i niewielki narzut - nagłówek GRE ma zaledwie od 4 do 8 bajtów, co czyni go jednym z najmniej zasobożernych protokołów tunelujących. Należy jednak pamiętać, że GRE nie zapewnia żadnych mechanizmów bezpieczeństwa, takich jak szyfrowanie czy uwierzytelnianie, co w dzisiejszych czasach stanowi poważne ograniczenie. W praktyce GRE jest często stosowany w połączeniu z IPSec, który zapewnia warstwę kryptograficzną, podczas gdy GRE odpowiada za elastyczność transportową, w tym przenoszenie protokołów innych niż IP oraz ruchu multicast. Standard RFC 2784 definiuje podstawową specyfikację GRE, a RFC 2890 wprowadza opcjonalne rozszerzenia, takie jak pole Sequence Number do wykrywania utraty pakietów.

Z punktu widzenia konfiguracji na urządzeniach MikroTik, GRE jest stosunkowo prosty do skonfigurowania, ale wymaga starannego zaplanowania adresacji interfejsów tunelu i tras routingu. Należy również pamiętać o odpowiednim skonfigurowaniu zapory sieciowej, ponieważ protokół GRE (IP 47) jest często blokowany przez domyślne reguły firewalla na routerach i u dostawców Internetu. Nowoczesne implementacje GRE obsługują również mechanizm keepalive, który umożliwia monitorowanie stanu tunelu i automatyczne usuwanie nieaktywnych tras, co znacząco podnosi niezawodność połączeń Site-to-Site.

Zrozumienie budowy pakietu GRE jest kluczowe dla diagnostyki problemów sieciowych i optymalizacji wydajności tuneli. Zewnętrzny nagłówek IP zawiera publiczne adresy punktów końcowych tunelu i jest używany do routowania pakietu przez sieć publiczną. Nagłówek GRE, znajdujący się między zewnętrznym a wewnętrznym nagłówkiem IP, zawiera pole Protocol Type, które identyfikuje typ enkapsulowanego protokołu - dla IPv4 jest to wartość 0x0800, a dla IPv6 0x86DD. Opcjonalne pola w nagłówku GRE, takie jak Checksum, Key i Sequence Number, mogą być używane do weryfikacji integralności, identyfikacji strumienia danych oraz ochrony przed atakami typu replay. Wewnętrzny nagłówek IP zawiera adresy prywatne urządzeń w sieciach LAN po obu stronach tunelu, które są niewidoczne dla routerów pośredniczących w sieci publicznej.

W praktyce administratora sieci znajomość struktury pakietu GRE jest niezbędna przy analizie przechwyconego ruchu w narzędziach takich jak Wireshark. Dzięki filtrowaniu protokołu GRE można precyzyjnie prześledzić ścieżkę pakietu przez tunel, zidentyfikować ewentualne problemy z fragmentacją oraz zweryfikować poprawność konfiguracji tras routingu. W przypadku tuneli GRE over IPSec analiza staje się bardziej złożona, ponieważ pakiet GRE jest dodatkowo szyfrowany, co ukrywa jego strukturę przed narzędziami do przechwytywania pakietów na odcinku publicznym.

Fakt, że protokół GRE działa bezpośrednio na poziomie warstwy sieciowej z numerem protokołu IP 47, ma daleko idące konsekwencje zarówno dla konfiguracji zapór sieciowych, jak i dla kompatybilności z translacją adresów NAT. Większość administratorów, przyzwyczajonych do zarządzania ruchem za pomocą portów TCP i UDP, popełnia podstawowy błąd, konfigurując reguły firewalla wyłącznie dla portu TCP 1723 podczas wdrażania PPTP. Tymczasem bez otwarcia protokołu 47 na zaporze sieciowej tunel danych (GRE) nie będzie działał, mimo że kanał sterowania (TCP) zestawi się poprawnie, co prowadzi do mylących objawów awarii. W systemie Windows objawia się to błędem 619, który informuje o niemożności ustanowienia połączenia, nie precyzując jednak przyczyny. W zaawansowanych sieciach korporacyjnych protokół 47 bywa blokowany domyślnie przez polityki bezpieczeństwa, co wymaga świadomego wyjątku w regułach firewalla.

Problem dodatkowo komplikuje fakt, że nie wszystkie domowe routery poprawnie obsługują translację NAT dla protokołów innych niż TCP i UDP. Wiele tanich urządzeń konsumenckich nie implementuje helperów dla protokołu GRE, co uniemożliwia zestawienie tunelu PPTP zza takiego routera. Rozwiązaniem jest zastosowanie mechanizmu PPTP Passthrough, który jest dostępny w większości routerów średniej i wyższej półki, lub migracja na protokół VPN wykorzystujący wyłącznie UDP lub TCP, taki jak OpenVPN czy WireGuard.

Bezstanowość protokołu GRE jest zarówno jego zaletą, jak i wadą, w zależności od kontekstu zastosowania. W środowiskach operatorskich, gdzie sieć szkieletowa jest w pełni zarządzana i monitorowana, brak narzutu związanego z utrzymywaniem stanu połączenia przekłada się na wyższą wydajność i mniejsze opóźnienia. Z kolei w sieciach o nieprzewidywalnej topologii, takich jak połączenia przez publiczny Internet, bezstanowość oznacza, że router nie jest w stanie samodzielnie wykryć awarii drugiego końca tunelu bez dodatkowych mechanizmów. Dlatego właśnie w praktyce inżynierskiej GRE prawie zawsze konfiguruje się z mechanizmem keepalive, który emuluje zachowanie protokołu stanowego poprzez okresowe wysyłanie pakietów kontrolnych. Protokół keepalive w GRE polega na wysyłaniu przez jeden z routerów pustych pakietów GRE, które drugi router musi odesłać z powrotem, potwierdzając swoją dostępność.

Konsekwencją bezstanowości jest również fakt, że odpowiedzialność za niezawodną dostawę danych spoczywa w całości na protokołach warstw wyższych, głównie na TCP. W przypadku utraty pakietu GRE, protokół TCP wewnątrz tunelu wykryje brak potwierdzenia i zainicjuje retransmisję, co jest mechanizmem całkowicie przezroczystym dla warstwy tunelującej. Oznacza to, że GRE nie dodaje własnych opóźnień związanych z retransmisją, ale też nie oferuje żadnych gwarancji dostarczenia pakietów - jest to typowe zachowanie protokołu warstwy 3, który działa w modelu best-effort.

Mechanizm keepalive w protokole GRE jest niezbędny do utrzymania spójności tablic routingu w dynamicznych środowiskach sieciowych. Bez niego router musiałby polegać wyłącznie na protokołach routingu dynamicznego, takich jak OSPF, które również wykorzystują własne mechanizmy wykrywania dostępności sąsiadów. Keepalive w GRE działa na poziomie warstwy tunelu, co oznacza, że sprawdza nie tylko dostępność interfejsu sieciowego, ale także poprawność działania całej ścieżki komunikacyjnej między punktami końcowymi. W przypadku awarii łącza pośredniego w sieci publicznej, pakiety keepalive przestają docierać do celu, co powoduje oznaczenie tunelu jako nieaktywnego. W systemie RouterOS parametry keepalive konfiguruje się jako parę wartości: interwał wysyłania pakietów oraz liczbę nieudanych prób przed uznaniem tunelu za nieaktywny.

W praktyce warto pamiętać, że zbyt krótki interwał keepalive może generować niepotrzebny ruch sieciowy i obciążenie procesora, szczególnie w sieciach z wieloma tunelami GRE. Z kolei zbyt długi interwał opóźnia wykrycie awarii, co może prowadzić do przekierowywania ruchu przez uszkodzony tunel i utraty pakietów. Standardowe wartości interwału to od 5 do 10 sekund przy 3 do 10 nieudanych próbach, co daje wykrycie awarii w czasie od 15 do 100 sekund. W środowiskach o krytycznym znaczeniu czasu przywracania spójności stosuje się dodatkowe mechanizmy monitorowania, takie jak BFD (Bidirectional Forwarding Detection).

GRE znajduje zastosowanie w wielu scenariuszach wykraczających poza typowe połączenia VPN, co czyni go niezwykle wszechstronnym narzędziem w arsenale administratora sieci. Jednym z najważniejszych zastosowań jest transport protokołów routingu dynamicznego, takich jak OSPF czy EIGRP, które wymagają komunikacji multicast lub broadcast między routerami. Ponieważ IPSec nie przenosi natywnie ruchu grupowego, GRE z IPSec stanowi standardowe rozwiązanie w sieciach korporacyjnych, gdzie routing dynamiczny między oddziałami jest niezbędny. GRE jest również powszechnie stosowany do tunelowania IPv6 przez infrastrukturę IPv4 (6in4), co było kluczowe w okresie przejściowym między wersjami protokołu IP zanim dostawcy Internetu upowszechnili natywny IPv6. W środowiskach operatorskich GRE jest używany wewnątrz sieci MPLS do transportu ruchu klientów między punktami obecności.

Najbezpieczniejszym i najczęściej stosowanym wariantem GRE w praktyce korporacyjnej jest GRE over IPSec, który łączy elastyczność enkapsulacji GRE z solidnym szyfrowaniem IPSec. W tym modelu pakiet GRE jest najpierw enkapsulowany, a następnie całość jest szyfrowana przez IPSec, co zapewnia poufność, integralność i uwierzytelnianie na poziomie całego tunelu. Rozwiązanie to jest szczególnie popularne w sieciach Cisco i MikroTik, gdzie konfiguracja GRE over IPSec jest stosunkowo prosta i dobrze udokumentowana. Alternatywnym podejściem jest IPSec over GRE, gdzie szyfrowanie jest wykonywane przed enkapsulacją, ale jest to rozwiązanie rzadziej spotykane.

Konfiguracja GRE w systemie RouterOS jest procesem wieloetapowym, który wymaga zrozumienia logiki działania interfejsów wirtualnych w tym systemie. Pierwszym krokiem jest utworzenie samego interfejsu tunelu za pomocą polecenia /interface gre add, gdzie podaje się lokalny i zdalny publiczny adres IP. RouterOS automatycznie rozpoznaje typ protokołu na podstawie kontekstu - polecenie gre tworzy tunel GRE standardowy z IP Protocol 47. Po utworzeniu interfejsu należy go skonfigurować pod kątem adresacji IP, ponieważ tunel GRE zachowuje się jak wirtualny kabel łączący dwa routery. Najczęściej stosuje się adresację z podsieci /30, która zapewnia dwa użyteczne adresy IP - jeden dla każdego końca tunelu. Weryfikacja poprawności konfiguracji odbywa się za pomocą polecenia ping między adresami interfejsów tunelu.

Ważnym aspektem konfiguracji GRE w RouterOS jest zrozumienie różnicy między interfejsem GRE a interfejsem EoIP. GRE działa w warstwie 3 i przesyła pakiety IP, podczas gdy EoIP działa w warstwie 2 i przesyła ramki ethernetowe. Wybór między nimi zależy od wymagań - jeśli potrzebujemy routingu między sieciami, wybieramy GRE; jeśli potrzebujemy mostkowania sieci (ta sama podsieć po obu stronach), wybieramy EoIP. W praktyce GRE jest wybierany znacznie częściej ze względu na niższy narzut i lepszą wydajność w typowych scenariuszach łączenia oddziałów.

Po skonfigurowaniu interfejsu GRE i nadaniu mu adresacji IP, kolejnym krokiem jest dodanie tras statycznych, które umożliwią komunikację między sieciami LAN znajdującymi się za routerami. W przypadku prostego połączenia dwóch oddziałów wystarczy dodać po jednej trasie statycznej na każdym routerze, wskazując sieć LAN drugiej lokalizacji z bramą ustawioną na adres IP interfejsu tunelu po drugiej stronie. Dla bardziej rozbudowanych sieci z wieloma lokalizacjami zdecydowanie zaleca się stosowanie protokołów routingu dynamicznego, takich jak OSPF, które automatycznie wykrywają zmiany topologii i aktualizują tablice routingu. W systemie RouterOS konfiguracja OSPF na interfejsie GRE jest stosunkowo prosta - wystarczy dodać interfejs tunelu do konfiguracji OSPF i zdefiniować odpowiednie obszary.

Należy pamiętać, że trasy statyczne w połączeniach GRE nie są dynamicznie aktualizowane w przypadku awarii tunelu, co może prowadzić do blackholingu ruchu. Dlatego tak ważne jest stosowanie mechanizmu keepalive, który deaktywuje interfejs tunelu w przypadku utraty łączności, co z kolei powoduje usunięcie tras statycznych korzystających z tego interfejsu z tablicy routingu. W systemie RouterOS mechanizm ten działa automatycznie - gdy interfejs GRE zostanie oznaczony jako nieaktywny przez keepalive, wszystkie trasy korzystające z niego jako bramy są automatycznie usuwane z tablicy routingu, co zapobiega przekazywaniu ruchu w kierunku uszkodzonego tunelu.

Routing rekurencyjny jest jednym z najbardziej podstępnych błędów konfiguracyjnych w sieciach VPN, który może całkowicie unieruchomić tunel i jest trudny do zdiagnozowania bez odpowiedniego zrozumienia mechanizmów routingu. Problem pojawia się, gdy trasa domyślna lub trasa do zdalnego punktu końcowego tunelu prowadzi przez interfejs wirtualny tunelu, który dopiero próbujemy zestawić. W takiej sytuacji router próbując wysłać pakiet przez tunel, najpierw sprawdza tablicę routingu, aby znaleźć trasę do publicznego adresu IP drugiego końca tunelu, i odkrywa, że według tablicy powinien wysłać go przez tunel, który właśnie próbuje zestawić, co tworzy nieskończoną pętlę logiczną.

Rozwiązaniem tego problemu jest zapewnienie, że trasa do publicznego adresu IP zdalnego punktu końcowego tunelu zawsze prowadzi przez fizyczny interfejs sieci WAN, a nie przez trasę domyślną, która mogłaby kierować ruch w stronę tunelu. W systemie RouterOS najprostszym rozwiązaniem jest dodanie jawnej trasy statycznej dla zdalnego adresu publicznego z bramą ustawioną na adres IP routera dostawcy Internetu na interfejsie WAN. Taka trasa, mająca wyższy priorytet niż trasa domyślna, zapewnia, że ruch do zdalnego punktu końcowego tunelu zawsze będzie kierowany bezpośrednio przez sieć publiczną, niezależnie od konfiguracji tras domyślnych.

Problem MTU w tunelach GRE jest szczególnie istotny, ponieważ narzut nagłówków IP i GRE wynoszący 24 bajty powoduje, że standardowy pakiet o rozmiarze 1500 bajtów po enkapsulacji ma już 1524 bajty, co przekracza MTU sieci Ethernet. Konsekwencją jest fragmentacja pakietu na routerze wysyłającym, co zwiększa obciążenie procesora i może prowadzić do problemów wydajnościowych. W przypadku pakietów z ustawioną flagą Don't Fragment, nadmiarowy rozmiar skutkuje odrzuceniem pakietu i wygenerowaniem komunikatu ICMP Fragmentation Needed, co z kolei powoduje objawy zacinania się aplikacji sieciowych. Aby uniknąć tych problemów, administratorzy obniżają wartość MTU na interfejsie tunelu GRE do około 1476 bajtów, co po dodaniu nagłówków GRE i IP daje pełne 1500 bajtów.

Jeszcze skuteczniejszym rozwiązaniem niż ręczne obniżanie MTU jest zastosowanie mechanizmu MSS Clamping dla ruchu TCP przechodzącego przez tunel. MSS Clamping modyfikuje deklarowaną wartość MSS podczas trójfazowego uzgadniania połączenia TCP, wymuszając rozmiar segmentu danych uwzględniający narzut enkapsulacji GRE. W systemie RouterOS regułę MSS Clamping konfiguruje się w łańcuchu mangle zapory sieciowej, co pozwala na selektywne stosowanie tej modyfikacji wyłącznie do ruchu przechodzącego przez tunel GRE. Dla tunelu GRE standardowa wartość MSS wynosi 1436 bajtów, co po dodaniu nagłówków TCP (20 B) i IP (20 B) daje 1476 bajtów, czyli efektywne MTU tunelu.

Kwestia MTU w tunelach GRE jest często bagatelizowana przez początkujących administratorów, co prowadzi do trudnych do zdiagnozowania problemów wydajnościowych. Wartość MTU tunelu GRE wynika z prostego rachunku: standardowe MTU Ethernetu wynosi 1500 bajtów, od których należy odjąć 20 bajtów zewnętrznego nagłówka IP i 4 bajty nagłówka GRE, co daje 1476 bajtów dostępnych dla pakietu wewnętrznego. Gdy wewnętrzny pakiet IP ma rozmiar 1476 bajtów lub mniej, po enkapsulacji zmieści się w standardowej ramce ethernetowej bez konieczności fragmentacji. W praktyce wiele systemów operacyjnych automatycznie wykrywa MTU ścieżki za pomocą mechanizmu Path MTU Discovery i dostosowuje rozmiar wysyłanych pakietów, ale w przypadku tuneli VPN mechanizm ten często zawodzi, ponieważ routery pośredniczące nie zawsze generują komunikaty ICMP Fragmentation Needed.

W systemie RouterOS można skonfigurować MSS Clamping dla ruchu TCP przechodzącego przez tunel GRE, co jest zdecydowanie preferowanym rozwiązaniem w porównaniu z ręcznym obniżaniem MTU na interfejsach klienckich. Reguła MSS Clamping automatycznie modyfikuje deklarowaną wartość MSS w pakietach SYN, zapobiegając generowaniu segmentów TCP o rozmiarze powodującym fragmentację po enkapsulacji GRE. Administratorzy powinni również pamiętać, że niektóre implementacje GRE w starszych urządzeniach nie obsługują flagi DF, co może prowadzić do nieoczekiwanej fragmentacji pakietów na ścieżce między punktami końcowymi tunelu.

Protokół PPP, choć obecnie rzadko używany samodzielnie w nowoczesnych sieciach, stanowi fundament, na którym zbudowano wiele kluczowych technologii dostępowych i tunelujących. Jego największą zaletą jest elastyczność - PPP może działać na praktycznie każdym medium transmisyjnym, od łączy szeregowych, przez linie modemowe, aż po wirtualne interfejsy w sieciach VPN. W kontekście PPPoE, który jest powszechnie stosowany przez dostawców Internetu do zarządzania sesjami abonenckimi, PPP zapewnia mechanizmy autoryzacji, adresacji i rozliczania usług. W przypadku VPN protokół PPP jest wykorzystywany jako warstwa enkapsulacji dla danych użytkownika wewnątrz tuneli PPTP, L2TP i SSTP, dostarczając ram dla negocjacji parametrów połączenia oraz uwierzytelniania. Zrozumienie PPP jest zatem niezbędne do pełnego opanowania technologii VPN.

PPP działa w ramach trzech głównych komponentów: metody ramkowania umożliwiającej enkapsulację danych w ramki, protokołu LCP do zarządzania łączem oraz rodziny protokołów NCP do konfiguracji poszczególnych protokołów warstwy sieciowej. Standard PPP został zdefiniowany w RFC 1661 i od tego czasu przeszedł liczne rozszerzenia, z których najważniejsze to uwierzytelnianie CHAP i MS-CHAP, kompresja nagłówków (RFC 2507) oraz wielołącze (Multilink PPP). PPP obsługuje również wykrywanie błędów za pomocą sum kontrolnych FCS (Frame Check Sequence), co zapewnia integralność danych na poziomie łącza.

Protokół LCP (Link Control Protocol) jest odpowiedzialny za nawiązanie, utrzymanie i zakończenie połączenia PPP na poziomie warstwy łącza danych. W ramach wymiany pakietów Configure-Request, Configure-Ack i Configure-Nak negocjowane są takie parametry jak maksymalna jednostka transmisyjna MRU, rodzaj enkapsulacji, a także protokół uwierzytelniania, który będzie używany w dalszych fazach. W przypadku braku akceptacji proponowanych parametrów przez jedną ze stron, LCP może wielokrotnie modyfikować wartości w kolejnych pakietach Configure-Request, aż do osiągnięcia porozumienia lub zakończenia negocjacji po przekroczeniu limitu prób. Protokół LCP obsługuje również mechanizmy wykrywania błędów pętli (Loopback Detection) oraz testowania integralności łącza za pomocą pakietów Echo-Request i Echo-Reply. Każde z tych funkcji jest realizowane przez oddzielną klasę pakietów LCP, co czyni ten protokół niezwykle elastycznym narzędziem konfiguracyjnym.

Protokoły NCP, w szczególności IPCP (IP Control Protocol), przejmują kontrolę po pomyślnym zakończeniu fazy uwierzytelniania i odpowiadają za konfigurację parametrów warstwy sieciowej w tunelu PPP. W przypadku IPCP najważniejszym zadaniem jest negocjacja i przydzielenie adresu IP klientowi, a także dostarczenie adresów serwerów DNS. IPCP działa na podobnej zasadzie co LCP, wykorzystując pakiety Configure-Request i Configure-Ack, ale operuje na protokole sieciowym, a nie na parametrach łącza. W środowiskach VPN z protokołem PPTP, IPCP przydziela adres IP do wirtualnego interfejsu klienta, który jest unikalny w sieci lokalnej serwera.

Faza Link Dead to początkowy stan automatu stanów PPP, w którym oczekiwane jest pojawienie się nośnika fizycznego lub logicznego, na przykład zestawienie połączenia modemowego lub aktywacja wirtualnego interfejsu sieciowego. Po wykryciu nośnika następuje przejście do fazy Link Establishment, gdzie protokół LCP rozpoczyna wymianę pakietów konfiguracyjnych, ustalając między innymi maksymalny rozmiar ramki MRU oraz wybraną metodę uwierzytelniania. W przypadku braku akceptacji negocjowanych parametrów przez jedną ze stron, LCP może wielokrotnie powtarzać próby konfiguracji, aż do osiągnięcia konsensusu lub przekroczenia limitu czasowego. Faza ta kończy się wysłaniem pakietu LCP Configure-Ack przez obie strony, co oznacza gotowość do przejścia do etapu uwierzytelniania.

Faza uwierzytelniania Authentication stanowi kluczowy element bezpieczeństwa połączenia PPP, w ramach którego klient musi udowodnić swoją tożsamość za pomocą wynegocjowanego wcześniej protokołu, takiego jak CHAP lub MS-CHAPv2. Po pomyślnym uwierzytelnieniu następuje faza Network Layer Protocol, w której IPCP przydziela klientowi adres IP i konfiguruje parametry sieciowe, takie jak serwery DNS. Ostatnia faza Open oznacza pełną gotowość do transmisji danych użytkownika, gdzie ramki PPP są swobodnie wymieniane między klientem a serwerem aż do momentu zakończenia sesji.

Protokół PAP (Password Authentication Protocol) jest najstarszym i najsłabszym mechanizmem uwierzytelniania dostępnym w ramach stosu protokołów PPP, zdefiniowanym w dokumencie RFC 1334. Działanie PAP jest niezwykle proste - klient wysyła do serwera swoją nazwę użytkownika i hasło w postaci czystego tekstu, bez żadnego szyfrowania ani maskowania. Serwer porównuje otrzymane dane z wpisami w lokalnej bazie lub na serwerze RADIUS i odsyła pakiet Authenticate-Ack w przypadku zgodności lub Authenticate-Nak w przypadku błędu. PAP wykonuje tę operację tylko raz na początku sesji, co oznacza, że w trakcie trwania połączenia nie ma żadnej dodatkowej weryfikacji tożsamości.

Ze względu na przesyłanie hasła w formie jawnej, PAP jest wyjątkowo podatny na ataki typu sniffing, gdzie osoba atakująca może przechwycić pakiety PPP i natychmiast odczytać dane logowania. Co więcej, PAP nie zapewnia żadnej ochrony przed atakami typu replay, ponieważ przesłane hasło może być użyte wielokrotnie do nieautoryzowanego dostępu. Z tych powodów PAP powinien być stosowany wyłącznie w całkowicie kontrolowanych i izolowanych sieciach wewnętrznych, gdzie ryzyko przechwycenia pakietów jest znikome.

Protokół CHAP (Challenge Handshake Authentication Protocol) stanowi znaczący postęp w stosunku do PAP, eliminując problem przesyłania haseł w formie jawnej. Mechanizm działania CHAP opiera się na schemacie wyzwanie-odpowiedź, w którym serwer wysyła do klienta losową wartość zwaną wyzwaniem (challenge), zawierającą identyfikator sesji oraz losowy ciąg bajtów. Klient łączy otrzymane wyzwanie ze swoim hasłem przy użyciu funkcji skrótu MD5 i odsyła wynik działania jako odpowiedź. Serwer wykonuje identyczne obliczenia na swojej kopii hasła i porównuje wynik z odpowiedzią klienta, co pozwala na potwierdzenie znajomości hasła bez jego jawnego przesyłania.

CHAP wykonuje cykliczne uwierzytelnianie przez cały czas trwania sesji, wysyłając nowe wyzwania w losowych odstępach czasu, co zapewnia ochronę przed atakami typu replay. W przypadku zmiany adresu IP przez router pośredniczący, CHAP może również wymusić ponowne uwierzytelnienie dla zwiększenia bezpieczeństwa. Mimo że algorytm MD5 jest obecnie uznawany za przestarzały i podatny na ataki kolizyjne, protokół CHAP wciąż spełnia swoją rolę w środowiskach o niskim ryzyku, szczególnie gdy jest stosowany jako jedna z wielu warstw zabezpieczeń.

Protokół MS-CHAPv2 (Microsoft Challenge Handshake Authentication Protocol w wersji 2) został opracowany przez firmę Microsoft jako udoskonalenie wcześniejszej wersji MS-CHAPv1, eliminując problem jednostronnego uwierzytelniania i dodając wzajemną weryfikację obu stron połączenia. W praktyce oznacza to, że nie tylko serwer weryfikuje tożsamość klienta, ale również klient ma możliwość potwierdzenia, że łączy się z autoryzowanym serwerem VPN, co chroni przed atakami typu man-in-the-middle z wykorzystaniem fałszywych serwerów. Proces uwierzytelniania opiera się na dwóch rundach wyzwanie-odpowiedź - w pierwszej serwer weryfikuje klienta, a w drugiej klient weryfikuje serwer.

Kluczową funkcją MS-CHAPv2 jest generowanie kryptograficznych kluczy sesyjnych, które są następnie używane przez protokół MPPE do szyfrowania ruchu w tunelu PPTP. Klucze te są wyprowadzane z hasła użytkownika oraz wartości wyzwań wymienionych podczas uwierzytelniania przy użyciu algorytmu SHA-1 oraz funkcji wyprowadzania kluczy zdefiniowanych w specyfikacji Microsoft. Niestety, MS-CHAPv2 jest podatny na zaawansowane ataki słownikowe offline, gdzie przechwycone pary wyzwanie-odpowiedź mogą być wykorzystane do odgadnięcia hasła metodą brutalnej siły przy użyciu mocy obliczeniowej współczesnych procesorów graficznych.

MPPE (Microsoft Point-to-Point Encryption) jest rozszerzeniem protokołu PPP dodającym szyfrowanie strumieniowe do pakietów przesyłanych w ramach tunelu VPN. Mechanizm ten wykorzystuje algorytm RC4, który został zaprojektowany w latach 80. przez Rona Rivesta i jest stosowany w wielu starszych protokołach kryptograficznych. MPPE obsługuje trzy długości klucza - 40, 56 i 128 bitów, z czego ten ostatni jest zalecany jako zapewniający minimalny akceptowalny poziom bezpieczeństwa. Klucze szyfrujące są generowane dynamicznie podczas procesu uwierzytelniania MS-CHAPv2 i są okresowo odświeżane w trakcie sesji, co ma na celu ograniczenie ilości danych zaszyfrowanych tym samym kluczem.

Algorytm RC4, na którym opiera się MPPE, został wielokrotnie skompromitowany w literaturze kryptograficznej, a w szczególności wykazano, że pierwsze bajty strumienia klucza RC4 są wysoce przewidywalne, co umożliwia ataki na słabo zaszyfrowane nagłówki protokołów. Ponadto, MPPE nie zapewnia mechanizmu Perfect Forward Secrecy, co oznacza, że złamanie hasła użytkownika umożliwia odszyfrowanie całego ruchu VPN zarejestrowanego w przeszłości. Mimo tych wad, MPPE pozostaje integralną częścią protokołu PPTP i jest wymagane do uzyskania jakiegokolwiek poziomu poufności w tym standardzie.

Profil PPP w systemie RouterOS jest mechanizmem szablonowym, który grupuje parametry konfiguracyjne dla wielu użytkowników VPN, zapobiegając konieczności wielokrotnego definiowania tych samych ustawień dla każdego konta oddzielnie. Przy tworzeniu profilu administrator określa przede wszystkim adres lokalny interfejsu tunelu widziany z perspektywy routera oraz pulę adresów przydzielanych klientom w momencie nawiązywania połączenia. Parametr local-address przyjmuje pojedynczy adres IP, który staje się bramą dla klientów VPN, podczas gdy remote-address wskazuje na zdefiniowaną wcześniej pulę adresów lub pojedynczy adres IP. W przypadku szyfrowania parametr use-encryption=yes wymusza stosowanie MPPE, co skutkuje odrzuceniem połączeń klientów próbujących nawiązać sesję bez szyfrowania.

Dodatkowe opcje profilu PPP w RouterOS obejmują między innymi limit czasu sesji (session-timeout), limit czasu bezczynności (idle-timeout) oraz możliwość kompresji nagłówków za pomocą protokołów VJ Compression i MPPC. Profil może również definiować parametry warstwy sieciowej dla klienta, takie jak adresy serwerów DNS, adresy serwerów WINS czy domyślną bramę dla ruchu klienta. W środowiskach produkcyjnych często stosuje się kilka profili dla różnych grup użytkowników, na przykład osobny profil dla pracowników zdalnych i osobny dla połączeń Site-to-Site między oddziałami.

Baza ppp secret w systemie RouterOS stanowi lokalne repozytorium danych uwierzytelniających dla wszystkich usług VPN działających na routerze, w tym PPTP, L2TP, SSTP i PPPoE. Każdy wpis w bazie zawiera nazwę użytkownika, hasło, typ usługi, profil PPP oraz opcjonalnie statyczny adres IP, który ma być przydzielony klientowi przy każdym połączeniu. Hasła w bazie przechowywane są w formie zahashowanej z użyciem algorytmu MD5, co stanowi dodatkową warstwę ochrony przed nieautoryzowanym dostępem do plików konfiguracyjnych routera. Parametr service określa, z której usługi VPN może korzystać dany użytkownik, co pozwala na precyzyjne zarządzanie uprawnieniami.

RouterOS wspiera również integrację z zewnętrznymi serwerami RADIUS, co jest zalecane w środowiskach korporacyjnych z dużą liczbą użytkowników wymagających centralnego zarządzania dostępem. W przypadku integracji z RADIUS-em, lokalna baza ppp secret działa jako rezerwa, do której następuje odwołanie w przypadku braku odpowiedzi z serwera centralnego. Administratorzy mogą również korzystać z haseł tymczasowych z ograniczonym czasem ważności, co jest przydatne w scenariuszach udzielania dostępu gościom lub podwykonawcom na ograniczony czas.

Problem komunikacji między klientami VPN a urządzeniami w sieci lokalnej wynika z fundamentalnej różnicy między warstwą 2 a warstwą 3 w modelu OSI. Gdy klient VPN otrzymuje adres IP z tej samej podsieci co sieć LAN, urządzenia w sieci lokalnej próbują wysłać do niego ramkę ARP w celu poznania adresu MAC, ale ramka ta nigdy nie dociera do klienta przez tunel VPN, ponieważ PPP nie przenosi ramek warstwy 2. Router, który znajduje się między siecią LAN a klientem VPN, nie przekazuje zapytań ARP do tunelu, przez co adresacja IP staje się niespójna - komputer w LAN wie, że klient jest w tej samej sieci, ale nie zna jego adresu fizycznego.

Mechanizm Proxy-ARP rozwiązuje ten problem, nakazując routerowi odpowiadanie na zapytania ARP w imieniu klientów VPN, którzy znajdują się po drugiej stronie tunelu. Router przechowuje w swojej tablicy ARP informacje o adresacji klientów, ponieważ sam przydzielił im adresy IP w fazie IPCP, i może zastąpić brakującą odpowiedź ARP własnym adresem MAC. W systemie RouterOS włączenie Proxy-ARP na interfejsie bridge lub LAN powoduje, że router zaczyna aktywnie odpowiadać na zapytania ARP dla wszystkich adresów, które są osiągalne przez inne interfejsy - w tym przez interfejsy wirtualne klientów VPN.

Architektura protokołu PPTP opiera się na dwóch całkowicie oddzielnych kanałach komunikacyjnych, które pełnią odmienne funkcje i są zarządzane przez różne mechanizmy sieciowe. Kanał sterowania działa na porcie TCP 1723 i wykorzystuje protokół TCP do niezawodnej transmisji komunikatów kontrolnych, takich jak żądania zestawienia sesji, negocjacja parametrów tunelu oraz przekazywanie stanów połączenia. W ramach tego kanału wymieniane są również informacje o typie enkapsulacji, wersji protokołu PPTP oraz identyfikatory sesji Call ID, które umożliwiają korelację ruchu sterowania z ruchem danych. Kanał ten nawiązywany jest jako pierwszy, a jego zestawienie warunkuje możliwość transmisji danych.

Kanał danych, z kolei, wykorzystuje protokół GRE z modyfikacjami specyficznymi dla PPTP i nie korzysta z mechanizmów kontroli przepływu ani retransmisji TCP. Pakiety GRE przenoszą zaszyfrowane ramki PPP z danymi użytkownika i są opatrzone polem Call ID, które umożliwia serwerowi rozróżnienie wielu jednoczesnych sesji klienckich. Rozdzielenie kanałów sprawia, że administratorzy sieci często popełniają błąd, konfigurując zapory wyłącznie dla portu TCP 1723, co pozwala na zestawienie kanału sterowania, ale uniemożliwia transmisję danych, prowadząc do charakterystycznych objawów błędu 619 w systemie Windows.

Standardowy protokół GRE zdefiniowany w RFC 2784 nie zawiera mechanizmów umożliwiających multipleksowanie wielu sesji w ramach jednego tunelu, co stanowiło poważne ograniczenie dla wdrożeń PPTP w środowiskach z translacją adresów NAT. Aby rozwiązać ten problem, specyfikacja PPTP (RFC 2637) wprowadziła modyfikację w postaci dodania pól Call ID i Call Serial Number do nagłówka GRE, które pełnią funkcję identyfikatorów sesji. Call ID jest 16-bitową wartością przypisywaną przez serwer podczas zestawiania połączenia i umieszczaną w każdym pakiecie GRE pochodzącym z danej sesji, co pozwala na jednoznaczne skorelowanie pakietów danych z odpowiednią sesją PPP.

Dzięki polu Call ID, router realizujący translację NAT jest w stanie poprawnie kierować pakiety GRE do odpowiedniego klienta, nawet jeśli wielu klientów łączy się z tego samego publicznego adresu IP. W praktyce oznacza to, że PPTP może działać poprawnie za routerem domowym wyposażonym w helper PPTP Passthrough, który monitoruje kanał sterowania TCP i zapamiętuje przypisane wartości Call ID dla każdej sesji. Należy jednak pamiętać, że standardowy GRE nie oferuje tej funkcjonalności, co jest kolejnym argumentem przemawiającym za stosowaniem PPTP zamiast czystego GRE w scenariuszach dostępu zdalnego z różnych lokalizacji.

Mechanizm translacji adresów NAT (Network Address Translation) stanowi poważne wyzwanie dla protokołów sieciowych, które nie korzystają z portów TCP lub UDP, ponieważ algorytm NAT opiera się właśnie na numerach portów do jednoznacznej identyfikacji sesji. Protokół GRE, będący podstawą tunelu danych w PPTP, nie posiada portów - identyfikuje się wyłącznie przez numer protokołu IP 47, co uniemożliwia standardowemu algorytmowi NAT poprawne przekierowanie pakietów GRE do odpowiedniego klienta w sieci lokalnej. W efekcie, pakiety GRE docierające do routera z zewnątrz nie mogą być przypisane do konkretnego urządzenia w sieci wewnętrznej, co skutkuje odrzuceniem tych pakietów.

Rozwiązaniem jest mechanizm PPTP Passthrough, zwany również helperem GRE, który jest zaimplementowany w większości nowoczesnych routerów domowych i biznesowych. Helper monitoruje ruch na porcie TCP 1723, wyciąga z niego informacje o wartościach Call ID podczas zestawiania sesji PPTP, a następnie wykorzystuje te informacje do poprawnego kierowania pakietów GRE do odpowiednich urządzeń w sieci lokalnej. Bez aktywnego PPTP Passthrough, połączenie PPTP zza routera NAT nie będzie działać, a klient otrzyma błąd 619 informujący o niemożności ustanowienia połączenia z serwerem zdalnym.

Protokół PPTP został poddany szczegółowej analizie bezpieczeństwa przez niezależnych badaczy, którzy zidentyfikowali szereg poważnych luk kryptograficznych czyniących go nieodpowiednim do ochrony współczesnych transmisji danych. Kluczowym problemem jest słabość algorytmu DES stosowanego w MS-CHAPv2 do generowania kluczy sesyjnych - klucz DES o długości zaledwie 56 bitów może być złamany metodą brutalnej siły w czasie od kilku minut do kilku godzin przy użyciu współczesnych procesorów graficznych lub usług chmurowych. Po złamaniu klucza MS-CHAPv2, atakujący uzyskuje dostęp do haseł użytkowników oraz do kluczy szyfrujących MPPE, co umożliwia całkowite odszyfrowanie całego ruchu w tunelu PPTP.

Kolejnym poważnym problemem jest brak mechanizmu Perfect Forward Secrecy w protokole PPTP, co oznacza, że złamanie pojedynczego hasła użytkownika umożliwia odszyfrowanie wszystkich nagranych wcześniej sesji tego użytkownika. W połączeniu ze słabościami algorytmu RC4 stosowanego w MPPE, które umożliwiają ataki statystyczne na zaszyfrowany strumień danych, protokół PPTP nie zapewnia praktycznie żadnej ochrony przed zdeterminowanym atakującym posiadającym dostęp do sieci. Z tych powodów wszystkie instytucje zajmujące się bezpieczeństwem IT, w tym National Institute of Standards and Technology NIST, jednoznacznie zalecają wycofanie protokołu PPTP z użytku produkcyjnego.

Konfiguracja serwera PPTP w systemie RouterOS wymaga kilku precyzyjnych kroków konfiguracyjnych, które decydują o stabilności i bezpieczeństwie całej usługi VPN. Podstawowym poleceniem jest /interface pptp-server server set enabled=yes, które aktywuje nasłuchiwanie na porcie TCP 1723 i przygotowuje router do przyjmowania połączeń przychodzących. Parametr authentication określa dozwolone metody uwierzytelniania - zaleca się pozostawienie wyłącznie metody mschap2 i wyłączenie starszych protokołów pap i chap, które są podatne na ataki. Właściwe ustawienie parametrów max-mtu i max-mru na poziomie 1450 bajtów pozwala uniknąć problemów z fragmentacją pakietów, które mogą wynikać z narzutu nagłówków PPTP, GRE i MPPE.

Parametr default-profile wskazuje na wcześniej utworzony profil PPP, który definiuje pulę adresów IP dla klientów oraz inne ustawienia sieciowe. RouterOS umożliwia również zaawansowaną konfigurację serwera PPTP, w tym ustawienie limitu jednoczesnych połączeń (max-sessions), limit czasu sesji oraz adresację dla połączeń przychodzących. Po skonfigurowaniu serwera należy koniecznie zweryfikować jego działanie za pomocą komendy /interface pptp-server server print, która wyświetli aktualny stan usługi oraz listę aktywnych połączeń klienckich.

Konfiguracja reguł zapory sieciowej dla usług PPTP jest często źródłem błędów, które uniemożliwiają poprawne działanie tunelu VPN nawet przy prawidłowo skonfigurowanym serwerze. Najważniejszą zasadą jest konieczność zezwolenia na dwa oddzielne typy ruchu przychodzącego - TCP na porcie 1723 dla kanału sterowania oraz protokół IP 47 dla tunelu danych GRE. Reguły te powinny być dodane do łańcucha input zapory sieciowej, ponieważ zarówno kanał sterowania, jak i tunel danych są adresowane bezpośrednio do routera jako punktu końcowego tunelu. Kolejność reguł w łańcuchu input ma znaczenie - reguły zezwalające na PPTP powinny znajdować się przed domyślnymi regułami blokującymi.

W środowiskach produkcyjnych zaleca się dodatkowo ograniczenie dostępu do serwera PPTP wyłącznie z zaufanych adresów IP źródłowych, co znacząco redukuje ryzyko ataków typu brute-force na hasła użytkowników. W systemie RouterOS można to zrealizować, dodając parametr src-address do reguł firewalla, lub stosując listy adresów (address lists) do grupowania dozwolonych źródeł. Dodatkowo warto rozważyć zastosowanie reguł limitowania połączeń na porcie TCP 1723 w celu ochrony przed zmasowanymi atakami typu SYN flood, które mogłyby doprowadzić do przeciążenia serwera VPN.

Konfiguracja połączenia PPTP w systemie Windows rozpoczyna się w panelu Ustawienia w sekcji Sieć i Internet, gdzie należy wybrać kategorię VPN i kliknąć przycisk Dodaj połączenie VPN. W nowoczesnych wersjach Windows interfejs konfiguracyjny został znacząco uproszczony w porównaniu z klasycznym panelem sterowania, co ułatwia konfigurację, ale ogranicza dostęp do zaawansowanych opcji. W pierwszym kroku należy wybrać dostawcę Windows wbudowane oraz nadać połączeniu dowolną nazwę identyfikującą, na przykład VPN Firmowy PPTP. Adres serwera to publiczny adres IP lub nazwa domenowa bramy VPN, która musi być osiągalna z poziomu sieci klienta.

Wybór odpowiedniej nazwy połączenia ma znaczenie praktyczne w przypadku korzystania z wielu różnych połączeń VPN na jednym komputerze, ponieważ ułatwia identyfikację poszczególnych konfiguracji. Adres serwera może być podany zarówno w formie adresu IPv4, jak i w formie w pełni kwalifikowanej nazwy domenowej FQDN, co jest zalecane w przypadku dynamicznych adresów IP serwera VPN. Po wypełnieniu podstawowych pól, Windows zapisuje konfigurację i udostępnia możliwość edycji zaawansowanych parametrów przed pierwszym logowaniem.

W drugim kroku konfiguracji PPTP w systemie Windows kluczowym wyborem jest typ sieci VPN, który domyślnie ustawiony jest na Automatyczny, ale zdecydowanie zaleca się ręczne wybranie protokołu PPTP w celu przyspieszenia procesu negocjacji. Wybór automatyczny wymusza na kliencie sekwencyjne próby zestawienia połączenia z użyciem różnych protokołów, co może wydłużyć czas logowania nawet o kilkadziesiąt sekund. Jawnie wybrany typ PPTP eliminuje zbędne próby negocjacji z innymi protokołami, takimi jak L2TP/IPSec czy SSTP, i przechodzi bezpośrednio do zestawiania sesji z serwerem.

Typ informacji logowania powinien być ustawiony na Nazwa użytkownika i hasło, co odpowiada standardowemu mechanizmowi uwierzytelniania MS-CHAPv2 stosowanemu w PPTP. Dane logowania muszą być zgodne z wpisami w bazie ppp secret na serwerze RouterOS, przy czym należy zwrócić uwagę na wielkość liter w nazwie użytkownika oraz hasle. Windows oferuje również możliwość zapisania danych logowania, co jest wygodne, ale stwarza zagrożenie w przypadku dostępu do komputera przez osoby niepowołane - zaleca się stosowanie dodatkowej ochrony systemowej w postaci szyfrowania dysku i blokady ekranu.

Split Tunneling to technika konfiguracji sieci VPN, w której tylko ruch kierowany do sieci firmowej jest przesyłany przez tunel VPN, podczas gdy cały pozostały ruch internetowy jest kierowany bezpośrednio przez lokalne łącze klienta bez szyfrowania. Domyślnie system Windows stosuje model Full Tunneling, w którym cały ruch klienta, w tym zapytania DNS i ruch do serwisów internetowych, jest przesyłany przez tunel VPN, co może znacząco obciążać łącze firmowe i zwiększać opóźnienia dla aplikacji internetowych. Split Tunneling jest szczególnie przydatny w scenariuszach, w których pracownicy zdalni potrzebują jednoczesnego dostępu do zasobów firmowych oraz do ogólnego Internetu, na przykład w celach badawczych lub komunikacyjnych.

Włączenie Split Tunneling w Windows odbywa się przez odznaczenie opcji Użyj domyślnej bramy w sieci zdalnej w zaawansowanych ustawieniach protokołu IPv4 dla karty sieciowej VPN. Po odznaczeniu tej opcji, Windows nie dodaje trasy domyślnej przez interfejs tunelu VPN, a jedynie trasy do sieci firmowych, które są skonfigurowane statycznie lub otrzymane z serwera za pomocą protokołu IPCP. Należy pamiętać, że Split Tunneling zmniejsza poziom bezpieczeństwa, ponieważ ruch internetowy nie jest chroniony szyfrowaniem VPN, co może być istotne w przypadku korzystania z niezabezpieczonych sieci publicznych, takich jak hotspoty Wi-Fi w kawiarniach czy na lotniskach.

Kod błędu 619 w systemie Windows jest jednym z najczęściej występujących komunikatów diagnostycznych podczas próby zestawienia połączenia PPTP i w większości przypadków wskazuje na problem z transmisją pakietów GRE między klientem a serwerem. Szczegółowy komunikat informuje, że nie można ustanowić połączenia z komputerem zdalnym, co często wynika z blokowania protokołu IP 47 przez zaporę sieciową po stronie klienta, po stronie serwera lub gdziekolwiek na ścieżce sieciowej między nimi. W praktyce błąd 619 pojawia się w momencie, gdy kanał sterowania TCP na porcie 1723 został już zestawiony, ale router nie może nawiązać komunikacji przez tunel GRE z powodu braku odpowiedzi na pakiety danych.

Aby zdiagnozować błąd 619, należy przede wszystkim sprawdzić, czy router domowy klienta posiada włączoną funkcję PPTP Passthrough, która jest odpowiedzialna za poprawne przekierowanie pakietów GRE do urządzenia klienckiego. W przypadku korzystania z publicznych sieci Wi-Fi, dostawca Internetu może blokować protokoły inne niż TCP i UDP, co uniemożliwia działanie GRE na poziomie sieci szkieletowej. Dodatkową przyczyną błędu 619 może być niewłaściwa konfiguracja zapory na samym serwerze VPN, która zezwala na ruch TCP 1723, ale blokuje protokół IP 47 na interfejsie wewnętrznym lub na routerze brzegowym sieci firmowej.

Kody błędów 800 i 807 w systemie Windows wskazują na całkowity brak łączności z serwerem VPN, co odróżnia je od błędu 619, który pojawia się po częściowym zestawieniu połączenia. Błąd 800 The remote connection was not made informuje, że klient nie może nawiązać nawet wstępnego kontaktu z serwerem na porcie TCP 1723, co wynika najczęściej z blokady tego portu na zaporze sieciowej lub z nieosiągalności serwera w ogóle. Błąd 807 The connection was prevented because of a policy configured on your RAS/VPN server wskazuje z kolei na odrzucenie połączenia przez serwer po nawiązaniu wstępnej komunikacji, co może być spowodowane błędną konfiguracją polityk dostępu lub wyczerpaniem limitów połączeń.

Diagnostyka błędów 800 i 807 powinna rozpocząć się od sprawdzenia dostępności serwera za pomocą narzędzia telnet lub Test-NetConnection w PowerShell, które pozwalają na weryfikację, czy port TCP 1723 odpowiada na zapytania z sieci zewnętrznej. W przypadku RouterOS pomocne jest sprawdzenie logów systemowych za pomocą komendy /log print, gdzie mogą znajdować się wpisy o odrzuconych połączeniach z określeniem przyczyny. Należy również zweryfikować, czy serwer VPN posiada poprawnie skonfigurowany publiczny adres IP i czy reguły NAT na routerze brzegowym poprawnie przekierowują ruch na porcie TCP 1723 do wewnętrznego adresu serwera.

Kod błędu 691 to sygnał, że proces uwierzytelniania zakończył się niepowodzeniem, co oznacza, że klient dostarczył nieprawidłowe dane logowania lub metody uwierzytelniania między klientem a serwerem nie są zgodne. W przeciwieństwie do błędów 619 i 800, błąd 691 wskazuje, że kanał sterowania TCP oraz tunel GRE zostały pomyślnie zestawione, ale serwer odrzucił próbę logowania na etapie uwierzytelniania PPP. Serwer RouterOS zapisuje szczegółowe informacje o nieudanych próbach logowania w logach systemowych, co pozwala na szybkie zidentyfikowanie konta, z którego próbowano nawiązać połączenie z nieprawidłowym hasłem.

Najczęstszą przyczyną błędu 691 jest niezgodność metod uwierzytelniania między klientem a serwerem - serwer może wymagać wyłącznie MS-CHAPv2, podczas gdy klient próbuje użyć przestarzałego PAP lub CHAP. W systemie Windows problem ten rozwiązuje się, wchodząc we właściwości połączenia VPN, zakładkę Zabezpieczenia i jawnie wybierając dozwolone metody uwierzytelniania. Należy również upewnić się, że nazwa użytkownika i hasło są wprowadzone poprawnie, z uwzględnieniem wielkości liter oraz ewentualnych znaków specjalnych, które mogą być nieprawidłowo interpretowane przez formularz logowania.

Model Site-to-Site z wykorzystaniem PPTP w systemie RouterOS umożliwia połączenie dwóch odrębnych sieci lokalnych w jedną spójną infrastrukturę sieciową przy minimalnym nakładzie konfiguracyjnym. W tym scenariuszu jeden router pełni funkcję serwera PPTP, a drugi router działa jako klient PPTP, który inicjuje połączenie za pomocą interfejsu pptp-client. Klient PPTP konfiguruje się poprzez polecenie /interface pptp-client add z parametrami connect-to określającym publiczny adres serwera oraz user i password, które odpowiadają wpisom w bazie ppp secret na serwerze. Po nawiązaniu połączenia na obu routerach pojawia się wirtualny interfejs, który może być używany do dalszej konfiguracji routingu.

Po zestawieniu tunelu Site-to-Site konieczne jest dodanie tras statycznych na obu routerach, które umożliwią komunikację między sieciami LAN znajdującymi się po obu stronach połączenia. Alternatywnie można skonfigurować protokół routingu dynamicznego, taki jak OSPF lub RIP, który będzie automatycznie propagował informacje o sieciach dostępnych przez tunel. Model Site-to-Site PPTP jest często stosowany w małych i średnich przedsiębiorstwach do szybkiego łączenia oddziałów, ale ze względu na ograniczenia bezpieczeństwa nie powinien być używany do transmisji danych wrażliwych bez dodatkowego szyfrowania warstwy aplikacyjnej.

Wydajność protokołu PPTP jest często wskazywana jako jego główna zaleta w porównaniu z nowszymi protokołami VPN, szczególnie w kontekście urządzeń o ograniczonej mocy obliczeniowej, takich jak tanie routery domowe czy starsze serwery. Niski narzut wydajnościowy wynika przede wszystkim ze stosowania algorytmu szyfrowania RC4, który jest znacząco mniej wymagający obliczeniowo niż algorytm AES stosowany w IPSec, szczególnie na urządzeniach pozbawionych sprzętowego wsparcia dla kryptografii. W praktyce oznacza to, że na routerze z procesorem o niskiej częstotliwości taktowania PPTP może osiągnąć przepustowość nawet dwukrotnie wyższą niż L2TP/IPSec przy tych samych warunkach sieciowych.

Należy jednak pamiętać, że wyższa wydajność PPTP odbywa się kosztem znacznie niższego poziomu bezpieczeństwa, co czyni ten wybór akceptowalnym wyłącznie w scenariuszach, w których ochrona danych nie jest priorytetem. Współcześnie nawet tanie urządzenia sieciowe często posiadają sprzętowe akceleratory kryptograficzne wspierające AES, co niweluje przewagę wydajnościową PPTP nad bezpieczniejszymi alternatywami. Dodatkowo narzut związany z enkapsulacją GRE i PPP w PPTP jest porównywalny z narzutem innych protokołów, a różnice w przepustowości wynikają głównie z szybkości szyfrowania, a nie z samej struktury pakietów.

Protokół EoIP (Ethernet over IP) jest autorskim rozwiązaniem firmy MikroTik, które rozszerza możliwości standardowego tunelu GRE o przenoszenie pełnych ramek warstwy 2, w tym nagłówków ethernetowych, co pozwala na stworzenie przezroczystego połączenia między dwoma segmentami sieci lokalnej. W przeciwieństwie do tunelu GRE warstwy 3, który przenosi wyłącznie pakiety IP, EoIP enkapsuluje całe ramki ethernetowe, umożliwiając pracę protokołów warstwy 2, takich jak DHCP, ARP czy protokoły rozgłoszeniowe, przez tunel. Dzięki temu urządzenia w dwóch różnych lokalizacjach mogą znajdować się w tej samej domenie rozgłoszeniowej, co jest szczególnie przydatne w przypadku potrzeby mostkowania sieci zamiast routingu.

EoIP wykorzystuje ten sam numer protokołu IP 47 co GRE, ale stosuje własny nagłówek zawierający dodatkowe pole identyfikatora tunelu EoIP Tunnel ID, które umożliwia multipleksowanie wielu tuneli EoIP między tymi samymi routerami. W systemie RouterOS EoIP może być łączony z szyfrowaniem IPSec w celu zapewnienia poufności danych, co tworzy rozwiązanie EoIP over IPSec, będące bezpieczną alternatywą dla rozciągania sieci warstwy 2 przez Internet. EoIP jest często stosowany w środowiskach operatorskich i u dostawców Internetu do dostarczania klientom przezroczystego połączenia warstwy 2 między oddziałami, umożliwiając migrację maszyn wirtualnych i innych usług wymagających ciągłości warstwy 2.

W sytuacjach, gdy użycie PPTP jest wymuszone przez ograniczenia sprzętowe lub organizacyjne, wdrożenie zestawu dobrych praktyk może znacząco podnieść poziom bezpieczeństwa wdrożenia. Podstawą jest wymuszenie stosowania bardzo długich i złożonych haseł, składających się z minimum 14 znaków zawierających małe i duże litery, cyfry oraz znaki specjalne, co zwiększa odporność na ataki słownikowe i brute-force. Administrator powinien również regularnie zmieniać hasła użytkowników VPN oraz niezwłocznie dezaktywować konta osób, które utraciły uprawnienia dostępu. W RouterOS warto skonfigurować limit nieudanych prób logowania z użyciem mechanizmu address list, który automatycznie blokuje adres IP źródłowego po przekroczeniu progu błędnych logowań.

Ograniczenie dostępu do serwera PPTP wyłącznie do zaufanych adresów IP źródłowych jest jednym z najskuteczniejszych sposobów redukcji ryzyka ataków, ponieważ eliminuje możliwość prób logowania z nieznanych lokalizacji. Zmiana domyślnego portu TCP 1723 na inny, mniej oczywisty numer portu, utrudnia działanie automatycznym skanerom sieciowym poszukującym serwerów VPN, choć nie stanowi skutecznej ochrony przed zdeterminowanym atakującym. Dodatkowo zaleca się wdrożenie monitorowania logów serwera w czasie rzeczywistym z wykorzystaniem narzędzi takich jak Syslog lub skryptów wysyłających powiadomienia o nietypowej aktywności, co umożliwia szybką reakcję na próby włamania.

Naturalnym następcą protokołu PPTP w ekosystemie Windows jest L2TP/IPSec, który łączy elastyczność tunelowania PPP z solidnymi mechanizmami kryptograficznymi pakietu IPSec, w tym szyfrowaniem AES i uwierzytelnianiem za pomocą certyfikatów lub kluczy pre-shared. L2TP/IPSec eliminuje wszystkie główne słabości PPTP - zamiast słabego RC4 stosuje AES, zamiast podatnego MS-CHAPv2 wykorzystuje certyfikaty X.509 lub Kerberos, a także zapewnia Perfect Forward Secrecy, chroniąc przeszłe sesje przed odszyfrowaniem po kompromitacji klucza długoterminowego. Niestety, L2TP/IPSec charakteryzuje się wyższym narzutem wydajnościowym i większą złożonością konfiguracji, szczególnie w zakresie zarządzania certyfikatami i konfiguracji IPSec.

Alternatywą dla scenariuszy wymagających łatwej konfiguracji i przechodzenia przez zapory sieciowe jest protokół SSTP (Secure Socket Tunneling Protocol), który wykorzystuje port TCP 443 i protokół HTTPS, co czyni go praktycznie nieblokowalnym na większości firewalli korporacyjnych. SSTP oferuje solidne szyfrowanie z użyciem SSL/TLS z certyfikatami serwera, zapewniając poziom bezpieczeństwa porównywalny z bezpiecznymi połączeniami HTTPS stosowanymi w bankowości internetowej. W nowoczesnych środowiskach coraz większą popularność zdobywa również WireGuard, który łączy prostotę konfiguracji z nowoczesną kryptografią opartą na protokole Noise i algorytmie Curve25519, oferując przy tym doskonałą wydajność nawet na słabszych urządzeniach.

W drugiej części kursu przeanalizowaliśmy trzy kluczowe technologie sieciowe - GRE, PPP i PPTP - które stanowią fundament historycznego i technicznego rozwoju protokołów VPN. Generic Routing Encapsulation okazał się być niezwykle elastycznym protokołem tunelowania, zdolnym do przenoszenia praktycznie dowolnego protokołu warstwy wyższej, ale pozbawionym jakichkolwiek mechanizmów bezpieczeństwa. Protokół PPP dostarczył nam wglądu w mechanizmy negocjacji połączenia, uwierzytelniania i adresacji, które są wykorzystywane przez wiele nowoczesnych protokołów VPN, w tym L2TP, SSTP i PPPoE. PPTP, mimo swoich poważnych wad bezpieczeństwa wynikających ze stosowania słabych algorytmów kryptograficznych, pozostaje interesującym przypadkiem studyjnym ilustrującym ewolucję technologii VPN.

Z praktycznego punktu widzenia, znajomość konfiguracji GRE i PPTP w systemie RouterOS jest cenną umiejętnością w środowiskach, gdzie starsze protokoły są wciąż używane z powodów kompatybilności lub ograniczeń budżetowych. Jednocześnie świadomość ograniczeń bezpieczeństwa tych protokołów pozwala na podejmowanie świadomych decyzji architektonicznych i migrację do bezpieczniejszych rozwiązań tam, gdzie jest to uzasadnione. Zachęcamy do wykonania zadania domowego polegającego na samodzielnym zestawieniu tunelu PPTP z wykorzystaniem klienta mobilnego, co pozwoli na praktyczne utrwalenie omawianych zagadnień przed przejściem do bardziej zaawansowanych protokołów w kolejnej części kursu.