¿Se cae el PPTP de MikroTik? Arregla la ruta al servidor

Un cliente PPTP de RouterOS conecta, mueve algo de tráfico y luego muere, y el registro parece un problema de credenciales o del servidor. Normalmente no es ninguna de las dos cosas. El túnel transporta sus propios paquetes porque la ruta al servidor también coincide con la ruta que instaló el túnel. El otro extremo deja de oír al router, y la sesión muere mientras la interfaz sigue diciendo que está activa.

La solución es una ruta, o un ajuste, que mantenga el servidor accesible por el WAN físico. Cuál depende de si el router debe ser una puerta de enlace de túnel completo.

El síntoma: conecta, mueve tráfico, muere

El patrón se repite en cada reconexión, y esa es la primera pista útil. Una contraseña rechazada falla antes de que la interfaz suba, una configuración errónea del cortafuegos normalmente bloquea una dirección, y un bucle de enrutamiento deja que la interfaz se establezca y luego la estrangula. Mira los contadores: el túnel muestra una ráfaga de paquetes iniciales y luego nada, mientras la interfaz WAN sigue transmitiendo copias encapsuladas. Eso es un router alimentando su propia salida de vuelta hacia sí mismo.

PPTP lo hace fácil de provocar porque el transporte es IP simple hacia la dirección del servidor, no un túnel cuyo extremo lejano está en otra subred. Cualquier cosa que redirija esa dirección redirige el transporte con ella.

Por qué el túnel se traga sus propios paquetes

Cuando el cliente conecta, instala una ruta cuya puerta de enlace es la interfaz del túnel. Si el perfil también instala una ruta por defecto, entonces cada destino sin una coincidencia más específica, incluida la dirección pública del servidor, se resuelve hacia el túnel. El router encapsula el paquete, direcciona el paquete exterior al servidor y vuelve a buscar la ruta: mismo destino, mismo defecto, mismo túnel. Según la versión, esa recursión se descarta, se encola o se deja en bucle hasta que el otro extremo se rinde y corta la sesión.

Los fabricantes de equipos suelen añadir automáticamente una ruta de host para su propio servidor, precisamente para evitar esto. RouterOS no lo presupone, así que el operador tiene que expresar la excepción o evitar la ruta por defecto desde el principio.

Fija la dirección del servidor en el WAN

Añade la ruta más estrecha posible: una /32 para la dirección pública del servidor, con la puerta de enlace del proveedor como siguiente salto, en la interfaz que llega a internet. Una /32 gana a cualquier ruta por defecto por longitud de prefijo, y una distancia menor gana si ya existe otra ruta para el mismo prefijo. Luego reconecta y confirma que la ruta está activa y no solo presente en la lista.

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

Si la puerta de enlace del proveedor se aprende por DHCP, usa la dirección que instaló DHCP, o ata la ruta a la interfaz si la versión lo admite. Una puerta de enlace codificada a mano que cambia en el siguiente arrendamiento es un fallo diferido. Revisa la dirección tras una reconexión del WAN, porque es cuando aparece una puerta de enlace obsoleta y el túnel empieza a caer de nuevo.

O impide que el túnel reclame la ruta por defecto

Una sucursal que necesita una sola LAN remota debería mantener el perfil PPTP totalmente lejos de la ruta por defecto. Desactiva esa opción en el perfil del cliente y añade en su lugar una ruta específica para el prefijo remoto a través de la interfaz del túnel. El tráfico normal se queda en el WAN, el transporte del túnel conserva su camino natural, y la tabla de enrutamiento se vuelve más fácil de explicar. Ese es el diseño mejor para una sucursal que necesita una subred, no para un router que debe ser la salida del sitio.

El túnel completo tiene sus propios requisitos: enrutamiento por políticas para fuentes seleccionadas, un plan para el tráfico de retorno y una decisión sobre qué pasa cuando el túnel cae. Nada de eso lo resuelve la ruta de host, que solo mantiene vivo el transporte.

Verifica por capas y luego cierra el agujero de gestión

Prueba por capas: haz ping a la dirección pública del servidor antes de conectar, haz ping a la puerta de enlace remota después de conectar, y luego haz ping a un host de la LAN remota. Añade masquerade en la interfaz del túnel si los hosts detrás del router necesitan que las respuestas vuelvan por ella.

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

Después reinicia el router o fuerza una reconexión del WAN y repite los tres ping, porque una ruta que solo existe en la configuración en ejecución no sobrevivirá. Una configuración exportada a un archivo de copia de seguridad y restaurada después es el otro lugar donde esto se rompe, ya que la ruta puede faltar en la exportación si se añadió en tiempo de ejecución.

Por último, limita Winbox y la gestión web a direcciones de origen conocidas antes de publicar cualquier cambio de VPN o de ruta. Un router que termina túneles es un objetivo de gestión, y el puerto 80 abierto al mundo es un hallazgo mayor que la ruta que acabas de arreglar.