MikroTik PPTP cau? Arregleu la ruta al servidor

Un client PPTP de RouterOS connecta, mou una mica de trànsit i després mor, i el registre sembla un problema de credencials o del servidor. Normalment no és ni l'una ni l'altra. El túnel transporta els seus propis paquets perquè la ruta al servidor també coincideix amb la ruta que ha instal·lat el túnel. L'altre extrem deixa de sentir el router, i la sessió mor mentre la interfície encara afirma que està activa.

La solució és una ruta, o un paràmetre, que mantingui el servidor accessible pel WAN físic. Quina cal depèn de si el router ha de ser una passarel·la de túnel complet.

El símptoma: connecta, mou trànsit, mor

El patró es repeteix a cada reconnexió, i és la primera pista útil. Una contrasenya rebutjada falla abans que la interfície pugi, una configuració errònia del tallafoc normalment bloqueja una direcció, i un bucle d'encaminament deixa que la interfície s'estableixi i després l'ofega. Mireu els comptadors: el túnel mostra una ràfega de paquets inicials i després res, mentre la interfície WAN continua transmetent còpies encapsulades. És un router que torna a donar la seva pròpia sortida a si mateix.

PPTP ho fa fàcil de provocar perquè el transport és IP pla a l'adreça del servidor, no un túnel amb l'altre extrem en una altra subxarxa. Qualsevol cosa que redirigeixi aquesta adreça redirigeix el transport amb ella.

Per què el túnel s'empassa els seus propis paquets

Quan el client connecta, instal·la una ruta la passarel·la de la qual és la interfície del túnel. Si el perfil també instal·la una ruta per defecte, llavors cada destinació sense una coincidència més específica, inclosa l'adreça pública del servidor, es resol cap al túnel. El router encapsula el paquet, adreça el paquet exterior al servidor i torna a buscar la ruta: mateixa destinació, mateix defecte, mateix túnel. Segons la versió, aquesta recursió es descarta, s'encua o es fa entrar en bucle fins que l'altre extrem es rendeix i trenca la sessió.

Els fabricants d'aparells sovint afegeixen automàticament una ruta d'amfitrió per al seu propi servidor, precisament per evitar-ho. RouterOS no ho pressuposa, així que l'operador ha d'expressar l'excepció o evitar la ruta per defecte des del principi.

Fixeu l'adreça del servidor al WAN

Afegiu la ruta més estreta possible: una /32 per a l'adreça pública del servidor, amb la passarel·la del proveïdor com a salt següent, a la interfície que arriba a internet. Una /32 guanya qualsevol ruta per defecte per longitud de prefix, i una distància més baixa guanya si ja existeix una altra ruta per al mateix prefix. Després reconnecteu i confirmeu que la ruta està activa i no només present a la llista.

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

Si la passarel·la del proveïdor s'aprèn per DHCP, feu servir l'adreça de passarel·la que ha instal·lat el DHCP, o lligueu la ruta a la interfície si la versió ho admet. Una passarel·la codificada fixa que canvia en el proper arrendament és una fallada ajornada. Comproveu l'adreça després d'una reconnexió del WAN, perquè és llavors quan apareix una passarel·la obsoleta i el túnel torna a caure.

O atureu que el túnel reclami la ruta per defecte

Una sucursal que necessita una sola LAN remota hauria de mantenir el perfil PPTP totalment lluny de la ruta per defecte. Desactiveu aquesta opció al perfil del client i afegiu en el seu lloc una ruta específica per al prefix remot a través de la interfície del túnel. El trànsit ordinari es queda al WAN, el transport del túnel conserva el seu camí natural, i la taula d'encaminament es fa més fàcil d'explicar. Aquest és el disseny millor per a una sucursal que necessita una subxarxa, no per a un router que ha de ser la sortida del lloc.

El túnel complet té els seus requisits: encaminament per política per a fonts seleccionades, un pla per al trànsit de retorn i una decisió sobre què passa quan el túnel cau. Res d'això no ho resol la ruta d'amfitrió, que només manté viu el transport.

Verifiqueu per capes i després tanqueu el forat de gestió

Proveu per capes: feu ping a l'adreça pública del servidor abans de connectar, feu ping a la passarel·la remota després de connectar, i després feu ping a un amfitrió de la LAN remota. Afegiu masquerade a la interfície del túnel si els amfitrions darrere del router necessiten que les respostes tornin per ella.

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

Després reinicieu el router o forceu una reconnexió del WAN i repetiu els tres pings, perquè una ruta que només existeix a la configuració en execució no sobreviurà. Una configuració exportada a un fitxer de còpia de seguretat i restaurada després és l'altre lloc on això es trenca, ja que la ruta pot faltar a l'exportació si es va afegir en temps d'execució.

Finalment, limiteu Winbox i la gestió web a adreces d'origen conegudes abans de publicar qualsevol canvi de VPN o de ruta. Un router que acaba túnels és un objectiu de gestió, i el port 80 obert al món és una troballa més gran que la ruta que acabeu d'arreglar.