Erro PPTP 800 fronte a 812 e cortes despois dun minuto

Tres mensaxes de erro dun mesmo cliente PPTP adoitan describir tres avarías distintas. O erro 800 significa que o túnel nunca chegou a formarse, o erro 812 significa que o servidor rexeitou o método de autenticación, e un corte despois dun minuto é un temporizador de keepalive que decide que un par san se marchou. Cada etapa falla pola súa propia razón, así que cada unha necesita a súa propia comprobación.

O erro 800 significa que o túnel nunca chegou a formarse

Windows xera o erro 800 cando non pode construír o túnel en absoluto, e o texto sobre un servidor inalcanzable ou parámetros de seguridade inadecuados é un resumo e non un diagnóstico. PPTP necesita dúas cousas separadas da rede antes de que se examine calquera credencial. TCP 1723 transporta a canle de control, e o protocolo IP 47, GRE, transporta a carga encapsulada.

Proba esa ruta exterior desde fóra da túa propia LAN, porque unha conexión que funciona dentro da oficina non demostra nada sobre a beira:

$ nc -vz vpn.example.net 1723
Connection to vpn.example.net 1723 port [tcp/*] succeeded!
$ sudo tcpdump -ni eth0 proto gre
tcpdump: listening on eth0, link-type EN10MB

Se o 1723 responde e a captura queda baleira mentres o cliente tenta conectarse, a ruta está a descartar o protocolo 47. Un router co 1723 reenviado pero o paso PPTP desactivado produce exactamente ese patrón: o aperto de mans TCP complétase, despois os paquetes GRE desaparecen, así que o fallo parece un problema de credenciais aínda que non se tentou ningún inicio de sesión.

Dirixe o reenvío ao enderezo LAN actual do servidor, activa o paso PPTP onde o router o ofreza e volve tentalo desde o mesmo punto exterior. Cando o GRE se filtra augas arriba e non podes cambialo, SSTP sobre TCP 443 ou L2TP/IPsec sobre UDP 500 e 4500 ten mellores posibilidades que calquera cambio que poidas facer no lado de Windows.

O erro 812 é o servidor rexeitando o teu método de autenticación

O erro 812 volve despois de que o túnel está levantado, por iso se sente como un problema de contrasinal. O servidor rexeita o método de autenticación negociado para a conexión, non necesariamente o contrasinal en si. No cliente, abre a entrada VPN, vai á pestana de seguridade, pon o tipo en Point-to-Point Tunneling Protocol, escolle a lista explícita de protocolos e marca Microsoft CHAP versión 2.

Podes ler o axuste actual sen pasar polo diálogo:

$ Get-VpnConnection -Name "Office" | Select-Object -ExpandProperty AuthenticationMethod
MsChapv2

Un servidor que esixe MS-CHAP v2 rexeita un cliente deixado en PAP ou nun tipo automático que negocia algo máis débil, e o erro chega antes de que se avalíe calquera contrasinal de usuario. O formato da conta é a outra metade do mesmo rexeitamento. Nun caso, Windows enviou unha identidade de conta de Microsoft coa forma MicrosoftAccount\[email protected] mentres o servidor quería unha conta local ou de dominio. Escribir SERVERNAME\username díxolle a Windows que almacén de contas consultar e borrou o erro. Introduce o nome a man en lugar de deixar que unha credencial gardada reproduza un formato anterior.

Os cortes despois dun minuto son unha decisión de keepalive

Cando o túnel se conecta, pasa algo de tráfico e logo se desconecta, mira o comportamento de eco LCP do servidor antes de tocar o cliente. O demo pide periodicamente ao par que confirme que segue aí. Se chegan moi poucas respostas dentro do orzamento configurado, a sesión derrúbase aínda que o usuario teña aínda unha ligazón funcional.

Nun servidor Linux pptpd eses valores viven en /etc/ppp/options.pptpd, e a reparación habitual é ampliar o orzamento en lugar de acurtar o intervalo:

# /etc/ppp/options.pptpd
lcp-echo-failure 30
lcp-echo-interval 5
# then
sudo systemctl restart pptpd

Trinta fallos cun intervalo de cinco segundos perdoan unha parada breve en lugar de declarar que o par se marchou. Reducir a conta a un ou dous converte o jitter normal nunha ruta traducida nunha desconexión aproximadamente cada minuto. Se o teu servidor é Windows RRAS en lugar de pptpd, mira en cambio o tempo de espera da sesión PPP e a política de desconexión por inactividade. Eses viven noutro sitio, e editar un ficheiro pppd que non existe non cambiará nada.

As subredes superpostas rompen a ruta de datos

Un túnel PPTP pode autenticarse limpiamente e aínda así non chegar a nada cando ambos os sitios usan o mesmo rango privado, por exemplo 192.168.1.0/24 na oficina e na casa. O cliente non pode dicir a que host se refire un enderezo dado, e algunhas pilas néganse a instalar a ruta de todo en lugar de escoller unha.

Trátao como un defecto de deseño e renumera un lado, ou entrega ao cliente un rango de acceso traducido a propósito. Depurar o cliente PPTP non pode arranxar un espazo de enderezos que existe dúas veces, e o síntoma seguirá parecendo un corte aleatorio.

Comeza pola etapa que fallou: GRE para o 800, o método e a cadea de conta para o 812, axustes de eco para un túnel que morre segundo o horario.