MikroTik PPTP valt weg? Repareer de route naar de server

Een PPTP-client op RouterOS verbindt, verplaatst wat verkeer en valt dan stil, en de log ziet eruit als een probleem met inloggegevens of de server. Meestal is het geen van beide. De tunnel draagt zijn eigen transportpakketten omdat de route naar de server ook past bij de route die de tunnel heeft geïnstalleerd. De tegenpartij hoort de router niet meer, en de sessie sterft terwijl de interface nog beweert dat hij actief is.

De oplossing is één route, of één instelling, die de server bereikbaar houdt via de fysieke WAN. Welke, hangt af van of de router een gateway voor een volledige tunnel moet zijn.

Het symptoom: verbindt, verplaatst verkeer, valt weg

Het patroon herhaalt zich bij elke herverbinding, en dat is de eerste bruikbare aanwijzing. Een geweigerd wachtwoord faalt voordat de interface omhoogkomt, een verkeerde firewallconfiguratie blokkeert meestal één richting, en een routinglus laat de interface tot stand komen en wurgt hem daarna. Kijk naar de tellers: de tunnel toont een uitbarsting van eerste pakketten en daarna niets, terwijl de WAN-interface ingekapselde kopieën blijft sturen. Dat is een router die zijn eigen uitvoer terug in zichzelf voert.

PPTP maakt dit makkelijk te veroorzaken omdat het transport gewone IP naar het adres van de server is, geen tunnel waarvan het verre uiteinde in een ander subnet ligt. Alles wat dat adres omleidt, leidt het transport mee om.

Waarom de tunnel zijn eigen pakketten inslikt

Wanneer de client verbindt, installeert hij een route waarvan de gateway de tunnelinterface is. Installeert het profiel ook een standaardroute, dan wordt elke bestemming zonder specifiekere match, inclusief het openbare adres van de server, naar de tunnel herleid. De router kapselt het pakket in, adresseert het buitenste pakket aan de server en zoekt de route opnieuw op: dezelfde bestemming, dezelfde standaard, dezelfde tunnel. Afhankelijk van de versie wordt die recursie weggegooid, in de wachtrij gezet of in een lus gedraaid tot de tegenpartij opgeeft en de sessie afbreekt.

Apparaatfabrikanten voegen vaak automatisch een hostroute voor hun eigen server toe, juist om dit te voorkomen. RouterOS gaat daar niet van uit, dus de beheerder moet de uitzondering uitdrukken of de standaardroute vanaf het begin vermijden.

Pin het serveradres aan de WAN

Voeg de smalst mogelijke route toe: een /32 voor het openbare adres van de server, met de gateway van de provider als volgende hop, op de interface die het internet bereikt. Een /32 verslaat elke standaard op prefixlengte, en een kleinere afstand wint als er al een andere route voor dezelfde prefix bestaat. Verbind daarna opnieuw en bevestig dat de route actief is en niet alleen in de lijst staat.

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

Als de gateway van de provider via DHCP wordt geleerd, gebruik dan het gatewayadres dat DHCP heeft geïnstalleerd, of bind de route aan de interface als de versie dat ondersteunt. Een hardgecodeerde gateway die bij de volgende lease verandert, is een uitgestelde storing. Controleer het adres na een WAN-herverbinding, want dan duikt een verouderde gateway op en begint de tunnel weer weg te vallen.

Of voorkom dat de tunnel de standaard opeist

Een filiaal dat één extern LAN nodig heeft, moet het PPTP-profiel helemaal bij de standaardroute weghouden. Zet die optie uit in het clientprofiel en voeg in plaats daarvan een specifieke route voor de externe prefix toe via de tunnelinterface. Gewoon verkeer blijft op de WAN, het eigen transport van de tunnel houdt zijn natuurlijke pad, en de routingtabel wordt makkelijker uit te leggen. Dat is het betere ontwerp voor een filiaal dat één subnet nodig heeft, niet voor een router die de uitgang van de locatie moet zijn.

Een volledige tunnel heeft zijn eigen eisen: beleidsrouting voor geselecteerde bronnen, een plan voor retourverkeer en een beslissing over wat er gebeurt als de tunnel wegvalt. Niets daarvan wordt opgelost door de hostroute, die alleen het transport in leven houdt.

Verifieer in lagen en dicht dan het beheergat

Test in lagen: ping het openbare adres van de server voordat je verbindt, ping de externe gateway na het verbinden en ping daarna een host op het externe LAN. Voeg masquerade toe op de tunnelinterface als hosts achter de router antwoorden via die interface terug moeten krijgen.

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

Herstart daarna de router of forceer een WAN-herverbinding en herhaal de drie pings, want een route die alleen in de actieve configuratie bestaat, overleeft niet. Een configuratie die naar een back-upbestand wordt geëxporteerd en later wordt teruggezet, is de andere plek waar dit breekt, omdat de route in de export kan ontbreken als hij tijdens runtime is toegevoegd.

Beperk ten slotte Winbox en webbeheer tot bekende bronadressen voordat je een VPN- of routewijziging publiceert. Een router die tunnels beëindigt is een beheersdoel, en poort 80 die openstaat voor de wereld is een grotere vondst dan de route die je zojuist hebt gerepareerd.