PPTP di que o teu contrasinal é incorrecto: que corrección vai primeiro?
Un contrasinal PPTP rexeitado adoita ser un desaxuste do método PPP, non un segredo malo. Le primeiro a negociación e despois escolle a corrección máis pequena que aguante.
Os perfís PPTP que insisten en que o teu contrasinal é incorrecto están a dicir algo máis estreito do que parece. O segredo proba no final mesmo dunha cadea que comeza coa negociación de capacidades, así que calquera desaxuste anterior nesa cadea aparece como un fallo de autenticación. Por iso, restablecer o contrasinal, volver escribilo ou recrear o perfil non cambia nada. Le primeiro a negociación e despois escolle a corrección segundo canto do camiño controlas.
Por que o segredo nunca chega a probarse
A autenticación PPP negóciase: o servidor propón métodos, o cliente responde co que pode facer e ambos acordan un antes de que se intercambie calquera credencial. Cando o servidor ofrece só EAP-PEAP e o pppd do cliente non o implementa, a conversa remata na fase de proposta. O servidor rexistra un fallo de autenticación porque esa é a fase que fallou, non porque se comparase o contrasinal e se atopase insuficiente.
Por iso o erro é idéntico para un contrasinal incorrecto e para un desaxuste de método. Só o rexistro os distingue, e só se se permite que o cliente sexa detallado.
Le a negociación, non o último erro
Executa a conexión en primeiro plano coa depuración activada e le as liñas de autenticación desde arriba. O rexistro nomea o método proposto, o método aceptado e onde se detivo o intercambio. Un perfil que nunca sae de CHAP ou MSCHAPv2 mentres o servidor espera PEAP é un problema de método, non de credenciais. A última liña dese rexistro é onde o cliente se rendeu, non onde está a causa.
sudo pppd call provider debug nodetachGarda esa saída. Tamén é a proba que o propietario da rede necesita antes de cambiar a política do servidor, e resolve a cuestión de se o contrasinal chegou a intervir.
A segunda causa agochase no ficheiro de segredos
Se o rexistro mostra que os métodos coinciden, mira o ficheiro que garda o segredo. Un salto de liña ou un espazo final escrito no campo do contrasinal envíanse como parte do contrasinal, así que o servidor compara unha cadea distinta da que tecleaches. O ficheiro parece correcto nun editor, e por iso mesmo sobrevive a tantos intentos.
sudo cat -A /etc/ppp/chap-secretsO signo de dólar marca o final de cada liña nesa saída. Un campo de contrasinal con algo antes desa marca, ou un espazo solto entre campos, hai que reescribilo coas comiñas que documenta a ferramenta.
Escolle a corrección segundo quen sexa o dono do servidor
Se o servidor é teu, permitir MSCHAPv2 para esa conta é o cambio máis pequeno, e deberías deixar constancia de que aceptaches un método máis feble a propósito. Se é doutra persoa, a corrección honesta é un cliente que implemente EAP-PEAP; parchear pppd converte a incompatibilidade no teu problema de mantemento. Se a elección de protocolo segue aberta, PPTP é a parte máis feble do deseño e a migración adoita ser máis barata que manter vivo un cliente parcheado. Escribe esa decisión xunto ao perfil para que a seguinte persoa non a volva abrir.
Escollas a ruta que escollas, proba despois desde unha segunda máquina noutra rede. Un perfil gardado pode seguir ofrecendo o método antigo e facer que un servidor corrixido pareza roto. Despois retira o axuste de depuración, xa que os rexistros PPP detallados poden capturar máis do que queres nunha estación de traballo compartida.