Os fallos de escritura GRE en pptpd non son un problema de contrasinal

Fallo de escritura GRE no rexistro, e o primeiro instinto é restablecer o contrasinal do usuario. Ese instinto case sempre é erróneo. Estas mensaxes describen a ruta de datos, non a comprobación de credenciais: o cliente pode autenticarse correctamente e logo quedar atascado na etapa na que se rexistra na rede. Dúas mensaxes distintas apuntan a dous fallos distintos, e ningún se resolve cun contrasinal novo.

Dúas mensaxes, dous fallos distintos

Un fallo de lectura significa que os paquetes GRE nunca chegan ao daemon ou se descartan á entrada. A conexión de control pode parecer perfectamente san mentres nada cruza a ruta de datos. A autenticación é o único que funcionou de forma demostrable.

Un fallo de escritura adoita significar que a sesión negociou algo que o núcleo ou o cliente non poden usar. A canle de control completouse, e as opcións acordadas durante ese intercambio non coinciden co que os extremos poden facer realmente. É un desacordo de configuración, non un evento de autenticación.

Lea cal dos dous aparece antes de cambiar nada. Levan a capas distintas, e tratalos como un só síntoma é a razón pola que o mesmo servidor se parchea dúas veces por motivos non relacionados. A liña do rexistro é o único diagnóstico gratuíto que obtén.

O protocolo 47 non é o porto 47

PPTP usa TCP 1723 para establecer a chamada e GRE para transportar a carga útil. GRE é o protocolo IP 47, non un número de porto, así que unha regra de cortalumes que abre o porto 47 non permite nada útil.

Un encamiñador na ruta necesita unha función de paso de PPTP ou un permiso explícito de GRE. Sen iso, o saúdo TCP complétase e o túnel nunca transporta un paquete, o que produce exactamente o fallo de lectura anterior. As regras do porto 47 nun cortalumes son a tarde máis desaproveitada deste protocolo.

Observe ambas as direccións á vez no servidor en lugar de adiviñar que lado descarta o tráfico: tcpdump -ni any port 1723 or proto gre.

Se 1723 mostra o establecemento da chamada mentres GRE permanece en silencio, o bloqueo está por riba do host. Se GRE chega e o daemon segue fallando, o problema é local e as opcións son o seguinte lugar onde mirar.

Permita GRE onde o host reenvía de verdade

Inserir unha regra forward para GRE é unha proba razoable nun host que reenvía tráfico de túnel, e non é unha política. Unha regra de proba que acepta todo dun protocolo é un diagnóstico, non un deseño. Déixea o tempo suficiente para aprender algo e logo substitúaa por unha regra limitada.

Engada unha regra input para os paquetes dirixidos ao propio servidor, porque a cadea forward non os ve. Despois observe os contadores da regra antes e despois dun intento de conexión, o que lle di se os paquetes chegan.

Faga persistente a regra mediante o servizo de cortalumes da distribución en lugar de volver executala tras cada reinicio. Nun host nftables, faga coincidir ip protocol gre tanto na cadea input como na forward.

Confirme que o módulo ppp_generic tamén está cargado e comprobe se o seguimento de conexións descarta a dirección de retorno. Ambos producen fallos que parecen un problema de cortalumes e non o son. Un módulo do núcleo ausente parece exactamente un protocolo bloqueado ata que o comproba.

Axuste as opcións ao cliente que realmente ten

A corrección do outro informe está en /etc/ppp/pptpd-options, onde a receita rexeita PAP, CHAP e MSCHAP, comenta as liñas require correspondentes e mantén MPPE con estado. Esa receita escribiuse para unha mestura de clientes, e copiala ás cegas rompe o caso habitual. Lea as liñas de rexeitamento como unha afirmación sobre que clientes tiña o autor, non como unha recomendación.

Un cliente de Windows normalmente necesita MS-CHAPv2 con MPPE-128. Manteña eses requisitos e elimine só as opcións que o cliente realmente non pode negociar.

# keep encryption; drop only what this client cannot negotiate
refuse-pap
refuse-chap
refuse-mschap
mppe-stateful
require-mschap-v2
require-mppe-128

Desactivar o cifrado para que unha conexión funcione é unha degradación, non unha reparación. Proba esa variante nunha ligazón de laboratorio e logo restableza o cifrado antes de que o servizo se enfronta a clientes reais. A conexión que funciona de forma insegura é peor que a que falla con honestidade.

Lea o número de erro do cliente

O código numérico do cliente estreita a etapa máis rápido que o rexistro do servidor. Léao antes de ler calquera outra cousa. 691 significa que se rexeitaron as credenciais, 721 significa que o servidor nunca respondeu e 619 significa que a conexión caeu. Dous minutos co número aforran unha hora coa configuración.

Compare ese código co rexistro do servidor antes de editar nada e volva probar co mesmo cliente tras cada cambio. Doutro xeito, un segundo fallo escóndese detrás do primeiro e a corrección parece ineficaz.

Cando o inicio de sesión ten éxito e non se move tráfico, GRE segue sendo o sospeitoso. Ese é o momento de volver á captura en lugar do almacén de credenciais.