PPTP a través dun punto de acceso: TCP 1723 é só a metade

Percorre as comprobacións en orde: se se abre a conexión de control, se GRE sobrevive á ruta, se o servidor acepta a chamada e se a autenticación se completa. Un cliente PPTP necesita tanto unha sesión TCP en 1723 como unha ruta GRE que transporte os datos, e un punto de acceso pode deixar pasar unha e descartar a outra. Facelo en orde diche que fronteira investigar en lugar de adiviñar. Os números de erro de Windows non o fan por ti.

GRE é o protocolo IP 47. Non é o porto 47 de TCP nin de UDP, e esa distinción explica a maior parte da confusión sobre as devasas.

Dúas rutas, unha conexión

A conexión de control é unha sesión TCP normal ao porto de destino 1723, que a maioría das redes permite sen obxeccións. A ruta de datos é GRE, protocolo 47, e unha devasa que permite o primeiro pode ignorar por completo o segundo. Esa combinación produce un cliente que parece arrincar e despois non transporta nada, un síntoma moito menos informativo que unha conexión rexeitada. Proba ambas as rutas por separado antes de concluír nada sobre o operador.

A tradución engade o seu propio requisito. As pasarelas que comparten portos adoitan necesitar un ALG que entenda PPTP para reescribir os identificadores de chamada xunto coas direccións, e unha sen el pode estragar a sesión de formas que parecen perda de paquetes. Ese comportamento é habitual pero depende da implementación, así que trata calquera límite dun fabricante como un exemplo e non como unha propiedade de todos os puntos de acceso.

O punto de acceso engade dúas fronteiras máis

O tráfico do cliente adoita atravesar o NAT de compartición do propio teléfono e despois unha tradución de nivel de operador antes de chegar ao servidor. Unha regra no router da oficina non pode reparar un dispositivo intermedio que pertence a outra persoa, e por iso o reenvío de portos no lado da casa raramente axuda. Un cliente saínte tampouco necesita un porto de entrada aberto; as respostas a unha conexión traducida volven polo estado que creou a pasarela. Un servidor aloxado detrás de NAT ten un conxunto de requisitos completamente distinto.

Un elemento de menú etiquetado como PPTP passthrough, cando existe, determina como manexa ese dispositivo este protocolo. Non é a mesma función que aloxar unha VPN no teléfono ou reenviar cada protocolo sen condicións, e activalo non é un permiso xeral para deixar pasar GRE.

Le o 807 como unha interrupción, non como un veredicto

Windows informa do 807 como unha conexión interrompida, o que describe o resultado e non unha causa. A súa táboa de erros trata o 806 por separado como a categoría relacionada con GRE, e esa diferenza merece coñecerse antes de construír unha teoría. Ningún dos dous números revela se o operador filtrou o protocolo 47, se o servidor quedou sen capacidade ou se as credenciais eran correctas. O erro di que a sesión rematou; a ruta di onde.

Unha proba de navegador que funciona no punto de acceso só demostra que unha ruta de aplicación normal funciona. Non di nada sobre GRE.

Illa a etapa que fallou

Mantén fixos o portátil, o servidor e o perfil, e cambia só a rede de acceso por outra aprobada. Se o resultado cambia, captura os intercambios TCP e GRE nas fronteiras que controlas e atopa a etapa máis temperá que nunca ocorre: establecemento do control, preparación da chamada, entrega de datos ou autenticación PPP. Cada unha deixa unha sinatura distinta nunha captura. Comparar unha rede que funciona cunha que falla é moito máis informativo que reler o texto do erro.

Todo isto diagnostica un despregamento que xa existe. Non é un argumento para levantar un servizo PPTP novo, e o protocolo non se pode sortear negociando: instalar un cliente distinto non fai que un servidor sen cambios fale outra cousa.

Para o acceso continuo, acorda unha migración compatible con quen sexa dono da VPN. A lista de comprobación remata cunha decisión en lugar de cun apaño.