MikroTik PPTP faller? Fiks ruten til serveren

En PPTP-klient på RouterOS kobler til, flytter litt trafikk og blir deretter død, og loggen ser ut som et problem med påloggingsinformasjon eller serveren. Som regel er det ingen av delene. Tunnelen bærer sine egne transportpakker fordi ruten til serveren også passer med ruten tunnelen installerte. Motparten slutter å høre ruteren, og økten dør mens grensesnittet fortsatt hevder at det er oppe.

Løsningen er én rute, eller én innstilling, som holder serveren tilgjengelig over det fysiske WAN-et. Hvilken avhenger av om ruteren skal være gateway for en full tunnel.

Symptomet: kobler til, flytter trafikk, dør

Mønsteret gjentar seg ved hver gjentilkobling, og det er det første nyttige sporet. Et avvist passord feiler før grensesnittet kommer opp, en feilkonfigurert brannmur blokkerer vanligvis én retning, og en rutingsløyfe lar grensesnittet etablere seg og kveler det deretter. Se på tellerne: tunnelen viser en byge av første pakker og deretter ingenting, mens WAN-grensesnittet fortsetter å sende innkapslede kopier. Det er en ruter som mater sin egen utgang tilbake i seg selv.

PPTP gjør dette lett å utløse fordi transporten er ren IP til serverens adresse, ikke en tunnel der den fjerne enden ligger i et annet subnett. Alt som omdirigerer den adressen, omdirigerer transporten med den.

Hvorfor tunnelen svelger sine egne pakker

Når klienten kobler til, installerer den en rute der gatewayen er tunellgrensesnittet. Hvis profilen også installerer en standardrute, løses hver destinasjon uten en mer spesifikk treff, inkludert serverens offentlige adresse, til tunnelen. Ruteren kapsler inn pakken, adresserer den ytre pakken til serveren og slår opp ruten igjen: samme destinasjon, samme standard, samme tunnel. Avhengig av versjonen blir denne rekursjonen forkastet, satt i kø eller kjørt i løkke til motparten gir opp og river ned økten.

Apparatprodusenter legger ofte automatisk til en vertsrute for sin egen server, nettopp for å unngå dette. RouterOS forutsetter det ikke, så operatøren må uttrykke unntaket eller unngå standardruten fra starten.

Fest serveradressen til WAN-et

Legg til den smaleste mulige ruten: en /32 for serverens offentlige adresse, med leverandørens gateway som neste hopp, på grensesnittet som når internett. En /32 slår enhver standard på prefikslengde, og kortere avstand vinner hvis det allerede finnes en annen rute for samme prefiks. Koble deretter til igjen og bekreft at ruten er aktiv og ikke bare til stede i listen.

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

Hvis leverandørens gateway læres via DHCP, bruk gatewayadressen DHCP installerte, eller bind ruten til grensesnittet hvis versjonen støtter det. En hardkodet gateway som endres ved neste leie er en forsinket feil. Sjekk adressen etter en WAN-gjentilkobling, for det er da en utdatert gateway dukker opp og tunnelen begynner å falle igjen.

Eller hindre tunnelen i å kreve standardruten

En filial som trenger ett eksternt LAN, bør holde PPTP-profilen helt unna standardruten. Slå av det alternativet i klientprofilen og legg i stedet til en spesifikk rute for det eksterne prefikset gjennom tunellgrensesnittet. Vanlig trafikk blir på WAN-et, tunnelens egen transport beholder sin naturlige vei, og rutetabellen blir enklere å forklare. Det er den bedre løsningen for en filial som trenger ett subnett, ikke for en ruter som skal være stedets utgang.

Full tunnel har sine egne krav: policy-ruting for utvalgte kilder, en plan for returtrafikk og en beslutning om hva som skjer når tunnelen faller. Ingenting av dette løses av vertsruten, som bare holder transporten i live.

Verifiser i lag, og lukk deretter administrasjonshullet

Test i lag: ping serverens offentlige adresse før du kobler til, ping den eksterne gatewayen etter tilkobling, og ping deretter en vert på det eksterne LAN-et. Legg til masquerade på tunellgrensesnittet hvis verter bak ruteren trenger at svarene kommer tilbake gjennom det.

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

Start deretter ruteren på nytt eller tving en WAN-gjentilkobling, og gjenta de tre pingene, for en rute som bare finnes i den kjørende konfigurasjonen overlever ikke. En konfigurasjon som eksporteres til en sikkerhetskopifil og gjenopprettes senere, er det andre stedet dette bryter, siden ruten kan mangle i eksporten hvis den ble lagt til under kjøring.

Til slutt, begrens Winbox og webadministrasjon til kjente kildeadresser før du publiserer noen VPN- eller ruteendring. En ruter som terminerer tunneler er et administrasjonsmål, og port 80 åpen mot verden er et større funn enn ruten du nettopp fikset.