O túnel dividido de PPTP non funciona: arranxa primeiro a ruta GRE

Observe como se levanta unha conexión PPTP e é fácil crer que a parte difícil xa está feita: o cliente autentícase, aparece un adaptador ppp0 ou WAN Miniport e a xanela de estado ponse verde. Despois a primeira petición a un host interno caduca e cúlpase o perfil. Na práctica hai dúas capas independentes que superar: o transporte exterior que leva TCP 1723 e GRE, e a política interior que decide que destinos usan a interface PPP. Un estado verde só demostra que a primeira capa negociou; non di nada da segunda.

Siga o cliente desde o perfil ata o socket de control

Abra o rexistro do cliente e atope o punto no que contacta co servidor. PPTP abre primeiro unha conexión TCP ao porto 1723 e negocia os parámetros do túnel por esa canle. Se este paso falla, nada posterior importa, e o erro adoita indicar o enderezo do servidor ou un tempo de espera esgotado.

Confirme a conexión de control no cable antes de tocar calquera ruta. No cliente ou nun porto espello, capture TCP 1723 para un intento de conexión:

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

Un aperto de mans completado e unha sesión establecida significan que a canle de control exterior funciona. Un SYN que nunca recibe un SYN-ACK apunta a un devasador, a un enderezo de servidor incorrecto ou a un provedor que filtra o porto. Un aperto de mans seguido dun reinicio inmediato adoita significar que o servidor rexeitou as credenciais ou o tipo de túnel.

GRE é un segundo protocolo, non un porto

PPTP leva a carga PPP dentro de GRE mellorado, o protocolo IP 47, que non ten número de porto que un enrutador poida seguir. Por iso unha regra que permite TCP 1723 aínda pode deixar o túnel sen ruta de datos. Os dispositivos NAT con estado deben entender o identificador de chamada dentro de GRE para mapear as respostas, e moitos non o fan. A especificación de PPTP mantén a canle de control e a carga GRE como pezas separadas, e o seu plan de probas tamén debe facelo.

Vixie o protocolo 47 na mesma captura e despois compare o que sae co que volve:

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

Os paquetes que saen sen respostas, mentres TCP 1723 segue san, son a sinatura clásica de GRE bloqueado. O paso de PPTP nun enrutador doméstico é unha función dese firmware concreto, así que unha rede de hotel que funciona non demostra nada sobre a seguinte. Se o enrutador non ofrece paso e non pode cambialo, o problema é a elección de protocolo, non a táboa de rutas.

Demostre que o túnel move un paquete

Cando GRE flúe, a negociación PPP asigna un enderezo á interface do cliente. Lea a asignación en lugar de supoñela:

ip -4 addr show ppp0

Faga ping ao enderezo do par que se mostra como destino da ligazón punto a punto. Unha resposta nesta etapa demostra que a ruta encapsulada funciona de extremo a extremo e que o servidor responde dentro do túnel. Se o par responde pero os hosts internos non, o transporte exterior está ben e o fallo moveuse cara a dentro.

Fágao antes de engadir calquera ruta dividida. Un cambio de ruta feito mentres o transporte está roto crea unha segunda variable e oculta a primeira.

Escriba a política dividida, DNS incluído

O encamiñamento dividido é unha lista de decisións, non unha caixa de verificación. Cada prefixo privado que debe cruzar o túnel necesita unha ruta pola interface PPP, e cada prefixo que debe quedar local ten que estar ausente dela. Unha ruta para unha subrede de aplicación sen unha ruta correspondente ao seu resolvedor privado é unha forma habitual de crear unha caída que parece unha aplicación rota.

Comprobe a decisión que toma o núcleo para un enderezo de cada categoría:

ip route get 10.20.5.10
ip route get 203.0.113.25

A primeira debe nomear ppp0, a segunda a pasarela normal. Se ambas nomean a mesma interface, a política non está dividida en absoluto. Engada o enderezo do propio servidor DNS á lista tunelizada, se non a resolución de nomes para hosts internos sae polo resolvedor local e non devolve nada útil.

Unha comprobación repetible en cinco pasos

Execute as capas en orde e detéñase na primeira que falle: canle de control, visibilidade de GRE, resposta do par PPP, ruta dividida para un enderezo interno e unha petición de aplicación polo túnel. Cada paso ten o seu propio comando, así que un fallo é atribuíble en lugar de misterioso.

Unha versión compacta para un cliente Linux é 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 aplícase a mesma orde con route print e o estado do adaptador que mostra o cliente. PPTP é un protocolo herdado, e se o servidor ofrece SSTP ou IKEv2, moverse adoita ser un mellor uso do tempo que axustar unha ruta que depende de que o protocolo 47 pase en cada salto. Comprobe o certificado e o contrato de autenticación do substituto en lugar de copiar un perfil antigo nunha versión nova.