El túnel dividido de PPTP no funciona: arregla primero la ruta GRE

Observe cómo se levanta una conexión PPTP y es fácil creer que la parte difícil ya está hecha: el cliente se autentica, aparece un adaptador ppp0 o WAN Miniport y la ventana de estado se pone verde. Luego la primera petición a un host interno expira y se culpa al perfil. En la práctica hay dos capas independientes que superar: el transporte exterior que lleva TCP 1723 y GRE, y la política interior que decide qué destinos usan la interfaz PPP. Un estado verde solo demuestra que la primera capa ha negociado; no dice nada de la segunda.

Siga al cliente desde el perfil hasta el socket de control

Abra el registro del cliente y encuentre el punto en que contacta con el servidor. PPTP abre primero una conexión TCP al puerto 1723 y negocia los parámetros del túnel por ese canal. Si este paso falla, nada posterior importa, y el error suele indicar la dirección del servidor o un tiempo de espera agotado.

Confirme la conexión de control en el cable antes de tocar cualquier ruta. En el cliente o en un puerto espejo, capture TCP 1723 para un intento de conexión:

sudo tcpdump -ni any 'tcp port 1723' -c 20

Un apretón de manos completado y una sesión establecida significan que el canal de control exterior funciona. Un SYN que nunca recibe un SYN-ACK apunta a un cortafuegos, a una dirección de servidor incorrecta o a un proveedor que filtra el puerto. Un apretón de manos seguido de un reinicio inmediato suele significar que el servidor rechazó las credenciales o el tipo de túnel.

GRE es un segundo protocolo, no un puerto

PPTP lleva la carga PPP dentro de GRE mejorado, el protocolo IP 47, que no tiene número de puerto que un enrutador pueda seguir. Por eso una regla que permite TCP 1723 todavía puede dejar el túnel sin ruta de datos. Los dispositivos NAT con estado deben entender el identificador de llamada dentro de GRE para mapear las respuestas, y muchos no lo hacen. La especificación de PPTP mantiene el canal de control y la carga GRE como piezas separadas, y su plan de pruebas también debe hacerlo.

Vigile el protocolo 47 en la misma captura y luego compare lo que sale con lo que vuelve:

sudo tcpdump -ni any 'proto gre' -c 20

Los paquetes que salen sin respuestas, mientras TCP 1723 sigue sano, son la firma clásica de GRE bloqueado. El paso de PPTP en un enrutador doméstico es una función de ese firmware concreto, así que una red de hotel que funciona no demuestra nada sobre la siguiente. Si el enrutador no ofrece paso y no puede cambiarlo, el problema es la elección de protocolo, no la tabla de rutas.

Demuestre que el túnel mueve un paquete

Cuando GRE fluye, la negociación PPP asigna una dirección a la interfaz del cliente. Lea la asignación en lugar de suponerla:

ip -4 addr show ppp0

Haga ping a la dirección del par que se muestra como destino del enlace punto a punto. Una respuesta en esta etapa demuestra que la ruta encapsulada funciona de extremo a extremo y que el servidor responde dentro del túnel. Si el par responde pero los hosts internos no, el transporte exterior está bien y el fallo se ha movido hacia dentro.

Hágalo antes de añadir cualquier ruta dividida. Un cambio de ruta hecho mientras el transporte está roto crea una segunda variable y oculta la primera.

Escriba la política dividida, DNS incluido

El enrutamiento dividido es una lista de decisiones, no una casilla de verificación. Cada prefijo privado que debe cruzar el túnel necesita una ruta por la interfaz PPP, y cada prefijo que debe quedarse local tiene que estar ausente de ella. Una ruta para una subred de aplicación sin una ruta correspondiente a su resolución privada es una forma habitual de crear una caída que parece una aplicación rota.

Compruebe la decisión que toma el núcleo para una dirección de cada categoría:

ip route get 10.20.5.10
ip route get 203.0.113.25

La primera debe nombrar ppp0, la segunda la puerta de enlace normal. Si ambas nombran la misma interfaz, la política no está dividida en absoluto. Añada la dirección del propio servidor DNS a la lista tunelizada, si no la resolución de nombres para hosts internos sale por el resolutor local y no devuelve nada útil.

Una comprobación repetible en cinco pasos

Ejecute las capas en orden y deténgase en la primera que falle: canal de control, visibilidad de GRE, respuesta del par PPP, ruta dividida para una dirección interna y una petición de aplicación por el túnel. Cada paso tiene su propio comando, así que un fallo es atribuible en lugar de misterioso.

Una versión compacta para un cliente Linux es así:

sudo tcpdump -ni any 'tcp port 1723 or proto gre' -c 40
ip -4 addr show ppp0
ping -c 3 192.0.2.1
ip route get 10.20.5.10

En Windows se aplica el mismo orden con route print y el estado del adaptador que muestra el cliente. PPTP es un protocolo heredado, y si el servidor ofrece SSTP o IKEv2, moverse suele ser un mejor uso del tiempo que ajustar una ruta que depende de que el protocolo 47 pase en cada salto. Compruebe el certificado y el contrato de autenticación del reemplazo en lugar de copiar un perfil antiguo en una versión nueva.