MikroTik PPTP kopplar ner? Fixa vägen till servern

En PPTP-klient i RouterOS ansluter, flyttar lite trafik och dör sedan, och loggen ser ut som ett problem med autentiseringsuppgifter eller servern. Oftast är det inget av dem. Tunneln bär sina egna transportpaket eftersom vägen till servern också matchar den väg som tunneln installerade. Motparten slutar höra av routern och sessionen dör medan gränssnittet fortfarande påstår att det är uppe.

Lösningen är en rutt, eller en inställning, som håller servern nåbar över det fysiska WAN-et. Vilken av dem beror på om routern ska vara en gateway med full tunnel.

Symtomet: ansluter, flyttar trafik, dör

Mönstret upprepas vid varje återanslutning, och det är den första användbara ledtråden. Ett avvisat lösenord misslyckas innan gränssnittet kommer upp, en felaktig brandväggskonfiguration blockerar oftast en riktning, och en routingloop låter gränssnittet etableras och stryper det sedan. Titta på räknarna: tunneln visar en skur av inledande paket och sedan inget, medan WAN-gränssnittet fortsätter skicka inkapslade kopior. Det är en router som matar tillbaka sin egen utdata i sig själv.

PPTP gör det lätt att utlösa eftersom transporten är vanlig IP till serverns adress, inte en tunnel vars bortre ände ligger i ett annat subnät. Allt som omdirigerar den adressen omdirigerar transporten med den.

Varför tunneln sväljer sina egna paket

När klienten ansluter installerar den en rutt vars gateway är tunnelns gränssnitt. Om profilen också installerar en standardrutt löses varje destination utan mer specifik matchning, inklusive serverns publika adress, mot tunneln. Routern kapslar in paketet, adresserar det yttre paketet till servern och slår upp rutten igen: samma destination, samma standard, samma tunnel. Beroende på version släpps den rekursionen, köas eller loopas tills motparten ger upp och river sessionen.

Tillverkare av utrustning lägger ofta automatiskt till en värdrutt för sin egen server, just för att undvika detta. RouterOS antar inte det, så operatören måste uttrycka undantaget eller undvika standardrutten från början.

Fäst serverns adress på WAN

Lägg till den smalaste möjliga rutten: en /32 för serverns publika adress, med internetleverantörens gateway som nästa hopp, på gränssnittet som når internet. En /32 slår varje standardrutt på prefixlängd, och ett lägre avstånd vinner om det redan finns en annan rutt för samma prefix. Återanslut sedan och bekräfta att rutten är aktiv och inte bara finns i listan.

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

Om gatewayen lärs in via DHCP använder du den gatewayadress som DHCP installerade, eller binder rutten till gränssnittet om versionen stöder det. En hårdkodad gateway som ändras vid nästa lease är ett fördröjt fel. Kontrollera adressen efter en WAN-återanslutning, för det är då en inaktuell gateway dyker upp och tunneln börjar tappa igen.

Eller hindra tunneln från att ta standardrutten

En filial som behöver ett enda avlägset LAN bör hålla PPTP-profilen helt borta från standardrutten. Stäng av det alternativet i klientprofilen och lägg i stället till en specifik rutt för det avlägsna prefixet via tunnelns gränssnitt. Vanlig trafik stannar på WAN, tunnelns egen transport behåller sin naturliga väg och routingtabellen blir lättare att förklara. Det här är bättre design för en filial som behöver ett subnät, inte för en router som ska vara platsens utgång.

Full tunnel har egna krav: policybaserad routing för valda källor, en plan för returtrafik och ett beslut om vad som händer när tunneln faller. Inget av det löses av värdrutten, som bara håller transporten vid liv.

Verifiera i lager och stäng sedan hanteringshålet

Testa i lager: pinga serverns publika adress före anslutning, pinga den avlägsna gatewayen efter anslutning och pinga sedan en värd på det avlägsna LAN-et. Lägg till masquerade på tunnelns gränssnitt om värdar bakom routern behöver få svar tillbaka genom det.

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

Starta sedan om routern eller tvinga fram en WAN-återanslutning och upprepa de tre pingarna, för en rutt som bara finns i den körande konfigurationen överlever inte. Den andra platsen där detta brister är en konfiguration som exporteras till en säkerhetskopia och återställs senare, eftersom rutten kan saknas i exporten om den lades till vid körning.

Begränsa slutligen Winbox och webbhanteringen till kända källadresser innan du publicerar någon VPN- eller ruttändring. En router som avslutar tunnlar är ett mål för hantering, och port 80 öppen mot världen är ett större fynd än rutten du just fixade.