MikroTik PPTP pada? Napraw trasę do serwera

Klient PPTP w RouterOS łączy się, przenosi trochę ruchu i gaśnie, a log wygląda na problem z poświadczeniami albo z serwerem. Zwykle nie jest to ani jedno, ani drugie. Tunel niesie własne pakiety transportowe, bo trasa do serwera pasuje też do trasy, którą zainstalował tunel. Druga strona przestaje słyszeć router, a sesja umiera, podczas gdy interfejs nadal twierdzi, że działa.

Poprawka to jedna trasa, albo jedno ustawienie, które utrzymuje serwer osiągalny przez fizyczny WAN. Które, zależy od tego, czy router ma być bramą pełnego tunelu.

Objaw: łączy się, przenosi ruch, umiera

Wzór powtarza się przy każdym ponownym połączeniu i to pierwsza użyteczna wskazówka. Odrzucone hasło zawodzi, zanim interfejs wstanie, zła konfiguracja zapory zwykle blokuje jeden kierunek, a pętla routingu pozwala interfejsowi się zestawić, a potem go dusi. Patrz na liczniki: tunel pokazuje wybuch pierwszych pakietów, a potem nic, podczas gdy interfejs WAN dalej wysyła hermetyzowane kopie. To router, który karmi własnym wyjściem sam siebie.

PPTP ułatwia to wywołać, bo transport to zwykłe IP do adresu serwera, a nie tunel, którego drugi koniec leży w innej podsieci. Cokolwiek przekieruje ten adres, przekierowuje też transport.

Dlaczego tunel połyka własne pakiety

Gdy klient się łączy, instaluje trasę, której bramą jest interfejs tunelu. Jeśli profil instaluje też trasę domyślną, to każde miejsce docelowe bez bardziej szczegółowego dopasowania, łącznie z publicznym adresem serwera, trafia do tunelu. Router hermetyzuje pakiet, adresuje pakiet zewnętrzny do serwera i znów szuka trasy: ten sam cel, ta sama domyślna, ten sam tunel. W zależności od wersji ta rekurencja jest odrzucana, kolejkowana albo zapętlana, aż druga strona się podda i zerwie sesję.

Producenci urządzeń często automatycznie dodają trasę do hosta dla własnego serwera, właśnie żeby tego uniknąć. RouterOS tego nie zakłada, więc operator musi wyrazić wyjątek albo od początku unikać trasy domyślnej.

Przypnij adres serwera do WAN

Dodaj najwęższą możliwą trasę: /32 dla publicznego adresu serwera, z bramą dostawcy jako następnym skokiem, na interfejsie, który wychodzi do internetu. /32 bije każdą domyślną po długości prefiksu, a mniejszy dystans wygrywa, jeśli dla tego samego prefiksu istnieje już inna trasa. Potem połącz się ponownie i potwierdź, że trasa jest aktywna, a nie tylko obecna na liście.

/ip route add dst-address=198.51.100.10/32 gateway=192.0.2.1 distance=10

Jeśli brama dostawcy jest poznawana przez DHCP, użyj adresu bramy, który zainstalował DHCP, albo przypnij trasę do interfejsu, jeśli wersja to obsługuje. Zaszyta na stałe brama, która zmieni się przy następnym wynajmie, to odroczona awaria. Sprawdź adres po ponownym połączeniu WAN, bo wtedy pojawia się nieaktualna brama i tunel znowu zaczyna padać.

Albo nie pozwól tunelowi zawłaszczyć trasy domyślnej

Oddział, który potrzebuje jednej zdalnej sieci LAN, powinien trzymać profil PPTP całkowicie z dala od trasy domyślnej. Wyłącz tę opcję w profilu klienta i zamiast tego dodaj konkretną trasę do zdalnego prefiksu przez interfejs tunelu. Zwykły ruch zostaje na WAN, własny transport tunelu zachowuje naturalną drogę, a tabela routingu staje się łatwiejsza do wyjaśnienia. To lepszy projekt dla oddziału, który potrzebuje jednej podsieci, a nie dla routera, który ma być wyjściem lokalizacji.

Pełny tunel ma własne wymagania: routing polityk dla wybranych źródeł, plan ruchu powrotnego i decyzję, co się dzieje, gdy tunel padnie. Niczego z tego nie rozwiązuje trasa hosta, która tylko utrzymuje transport przy życiu.

Sprawdzaj warstwami, a potem zamknij dziurę zarządzania

Testuj warstwami: pinguj publiczny adres serwera przed połączeniem, pinguj zdalną bramę po połączeniu, a potem pinguj hosta w zdalnej sieci LAN. Dodaj masquerade na interfejsie tunelu, jeśli hosty za routerem potrzebują odpowiedzi wracających przez niego.

/ip firewall nat add chain=srcnat out-interface=pptp-out1 action=masquerade

Potem zrestartuj router albo wymuś ponowne połączenie WAN i powtórz trzy pingi, bo trasa istniejąca tylko w działającej konfiguracji nie przetrwa. Konfiguracja wyeksportowana do pliku kopii zapasowej i później przywrócona to drugie miejsce, w którym to się psuje, ponieważ trasy może brakować w eksporcie, jeśli dodano ją w czasie działania.

Na koniec ogranicz Winbox i zarządzanie przez web do znanych adresów źródłowych, zanim opublikujesz jakąkolwiek zmianę VPN lub trasy. Router, który kończy tunele, jest celem zarządzania, a port 80 otwarty na świat to większe znalezisko niż trasa, którą właśnie naprawiłeś.