Falta o passthrough de PPTP: corrixe o erro 807 de Windows VPN

Reenviar o TCP 1723 a miúdo abre a primeira parte de PPTP e deixa o resto roto, así que Windows segue devolvendo o erro 807 no intento. O seguinte impulso é engadir unha regra para o porto 47, e xusto ese paso é o que malgasta unha tarde: GRE é un número de protocolo na cabeceira IP, non un porto que unha táboa de reenvío poida emparellar. Ata que o router deixe pasar o protocolo 47 e o ate á mesma chamada, o túnel non pode arrincar. As seccións seguintes separan as dúas canles e despois próbana unha a unha.

Unha táboa de portos non ten fila para un número de protocolo

PPTP usa dúas conversas que fallan de xeitos distintos. A de TCP 1723 inicia a chamada, entrega a información da ligazón e péchaa cando o usuario se desconecta. O lado da carga útil corre dentro de GRE, que a cabeceira IP etiqueta co número de protocolo 47, e dentro dese túnel PPP negocia a ligazón mentres MS-CHAPv2 comproba as credenciais.

Como GRE non leva cabeceira de transporte, non expón ningún porto, así que unha regra escrita para portos non ten nada que emparellar. Un router que reenvía o 1723 crea unha asignación para esa sesión TCP e detense aí. O firmware que xestiona a segunda metade chama á función passthrough de PPTP ou PPTP ALG, e algúns firmwares non ofrecen ningunha das dúas e nunca mencionan o oco. A etiqueta da caixa importa menos que se o protocolo 47 se recoñece ou non.

Que informa Windows cando morre a ruta de datos

O erro 807 di que a conexión non se puido completar, o que na práctica significa que a chamada chegou ao servidor e a canle de datos non se ergueu. É un veredicto sobre o transporte, non sobre a conta. O erro 691 é o que apunta ás credenciais ou a un desaxuste do protocolo de autenticación, así que te envía a outro sitio por completo.

Traballa o transporte antes de tocar o contrasinal. Cambiar as credenciais para perseguir o 807 deixa o fallo real no seu sitio e fai que o seguinte intento sexa máis difícil de ler.

Por que un segundo cliente rompe un túnel que funciona

Sen portos que os distingan, un dispositivo NAT non pode separar dous clientes PPTP como separa dúas sesións HTTPS. Por iso moitos equipos domésticos permiten unha soa chamada PPTP e séguena por enderezo de orixe. Un portátil que funcionaba só deixa de completar en canto un segundo equipo marca, e desde o lado do cliente o fallo parece aleatorio. Ese patrón pertence ao firmware, e ningún cambio de perfil o alterará.

Observa a táboa de conexións mentres ambos os clientes marcan. Se só o primeiro equipo ten algunha vez unha asignación, o router chegou ao límite do que admite e ningún axuste do cliente o moverá.

Demostra que metade está fallando

Confirma que o TCP 1723 chega antes de cambiar nada no router, porque esa resposta decide que metade estás probando. Executa estes comandos desde o cliente Windows contra o teu propio nome de servidor. O primeiro imprime se o porto respondeu, e o segundo marca sen diálogo, o que fai comparables os intentos repetidos.

Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"

Un resultado certo na proba do porto significa que a canle de control está aberta e que GRE é o sospeitoso restante. Un resultado falso significa que o encamiñamento, un filtro ou o reenvío están rotos, e ningún cambio en GRE o salvará. O lado de datos debe vixiarse onde se poida ver, no servidor ou no router.

tcpdump -ni any proto 47

O equivalente en Wireshark é o filtro de visualización ip proto 47, que é máis fácil de pasar a alguén que non está cómodo nunha liña de ordes. Un GRE que chega sen que saia nada en resposta significa que hai que arranxar a ruta de volta.

Que arranxa realmente o erro

Onde o router expón o axuste, activa o passthrough de PPTP ou permite o protocolo 47 de forma explícita nun firmware que acepte regras. En RouterOS a regra de reenvío empareja o protocolo directamente, algo que un reenvío baseado en portos nunca podería facer. O firmware de consumo adoita esconder a mesma decisión tras unha caixa, ás veces nos axustes de seguridade e non no reenvío de portos. Se non existe tal control, nada no cliente o compensará.

/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre

Substituír PPTP é a outra opción e a miúdo a máis barata. Un router que termina a VPN el mesmo evita o dobre NAT para os clientes entrantes, e un protocolo que un NAT baseado en portos xa manexa non necesita ningún passthrough: OpenVPN sobre UDP, SSTP sobre TCP 443 ou L2TP/IPsec con NAT-T que envolve ESP en UDP 4500. PPTP tamén depende de MS-CHAPv2, cuxas debilidades documentadas o converten nunha mala elección para un despregamento novo mesmo despois de que o erro desapareza.

Anota que regra marcou a diferenza, porque o mesmo sitio atopará o mesmo límite cando o segundo usuario pida acceso. Unha corrección a nivel de protocolo pertence ás notas de rede, onde mirará o seguinte enxeñeiro.