MikroTik PPTP falder? Ret ruten til serveren

En RouterOS PPTP-klient forbinder, sender lidt trafik og går derefter død, og loggen ser ud som et problem med legitimationsoplysninger eller serveren. Det er som regel ingen af delene. Tunnelen bærer sine egne transportpakker, fordi ruten til serveren også matcher den rute, tunnelen har installeret. Modparten holder op med at høre routeren, og sessionen dør, mens grænsefladen stadig påstår, at den er oppe.

Rettelsen er én rute, eller én indstilling, der holder serveren tilgængelig over den fysiske WAN. Hvilken afhænger af, om routeren skal være gateway for en fuld tunnel.

Symptomet: forbinder, sender trafik, dør

Mønstret gentager sig ved hver genopkobling, og det er det første brugbare spor. En afvist adgangskode fejler, før grænsefladen kommer op, en fejlkonfigureret firewall blokerer normalt én retning, og en routingløkke lader grænsefladen etablere sig og kvæler den derefter. Se på tællerne: tunnelen viser en byge af indledende pakker og derefter intet, mens WAN-grænsefladen fortsætter med at sende indkapslede kopier. Det er en router, der fodrer sin egen udgang tilbage i sig selv.

PPTP gør det let at fremkalde, fordi transporten er ren IP til serverens adresse, ikke en tunnel, hvis fjerne ende ligger på et andet undernet. Alt, der omdirigerer den adresse, omdirigerer transporten med den.

Hvorfor tunnelen sluger sine egne pakker

Når klienten forbinder, installerer den en rute, hvis gateway er tunnelgrænsefladen. Hvis profilen også installerer en standardrute, så opløses enhver destination uden et mere specifikt match, inklusive serverens offentlige adresse, til tunnelen. Routeren indkapsler pakken, adresserer den ydre pakke til serveren og slår ruten op igen: samme destination, samme standard, samme tunnel. Afhængigt af versionen droppes denne rekursion, sættes i kø eller køres i løkke, indtil modparten giver op og river sessionen ned.

Apparatproducenter tilføjer ofte automatisk en hostrute til deres egen server, netop for at undgå dette. RouterOS antager det ikke, så operatøren skal udtrykke undtagelsen eller undgå standardruten fra starten.

Fastgør serveradressen til WAN'et

Tilføj den snævrest mulige rute: en /32 til serverens offentlige adresse, med udbyderens gateway som næste hop, på den grænseflade, der når internettet. En /32 slår enhver standard på præfikslængde, og en lavere afstand vinder, hvis der allerede findes en anden rute til samme præfiks. Genopret derefter forbindelsen, og bekræft at ruten er aktiv og ikke blot til stede i listen.

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

Hvis udbyderens gateway læres via DHCP, brug den gatewayadresse, som DHCP installerede, eller bind ruten til grænsefladen, hvis versionen understøtter det. En hårdkodet gateway, der ændrer sig ved næste leje, er en forsinket fejl. Kontrollér adressen efter en WAN-genopkobling, for det er der, en forældet gateway dukker op, og tunnelen begynder at falde igen.

Eller stop tunnelen med at kræve standardruten

En filial, der har brug for ét fjernt LAN, bør holde PPTP-profilen helt væk fra standardruten. Slå den indstilling fra i klientprofilen, og tilføj i stedet en specifik rute til det fjerne præfiks gennem tunnelgrænsefladen. Almindelig trafik bliver på WAN'en, tunnelens egen transport beholder sin naturlige vej, og routingtabellen bliver lettere at forklare. Det er det bedre design til en filial, der har brug for et undernet, ikke til en router, der skal være stedets udgang.

Fuld tunnel har sine egne krav: policy routing for udvalgte kilder, en plan for returtrafik og en beslutning om, hvad der sker, når tunnelen falder. Intet af det løses af hostruten, som kun holder transporten i live.

Verificér i lag, og luk så administrationshullet

Test i lag: ping serverens offentlige adresse, før du forbinder, ping den fjerne gateway efter forbindelsen, og ping derefter en vært på det fjerne LAN. Tilføj masquerade på tunnelgrænsefladen, hvis værter bag routeren har brug for, at svar kommer tilbage gennem den.

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

Genstart derefter routeren, eller fremtving en WAN-genopkobling, og gentag de tre ping, for en rute, der kun findes i den kørende konfiguration, overlever ikke. En konfiguration, der eksporteres til en backupfil og gendannes senere, er det andet sted, dette brækker, da ruten kan mangle i eksporten, hvis den blev tilføjet under kørsel.

Begræns endelig Winbox og webadministration til kendte kildeadresser, før du offentliggør nogen VPN- eller ruteændring. En router, der terminerer tunneler, er et mål for administration, og port 80 åben mod verden er et større fund end den rute, du netop har rettet.