PPTP sê jou wagwoord is verkeerd: watter herstel kom eerste?

PPTP-profiele wat volhou dat jou wagwoord verkeerd is, sê iets smaller as wat dit klink. Die geheim word heel aan die einde van ’n ketting getoets wat met vermoë-onderhandeling begin, so enige wanpassing vroeër in daardie ketting kom na vore as ’n verifikasiefout. Om die wagwoord te herstel, oor te tik of die profiel te herskep, verander dus niks. Lees eers die onderhandeling en kies dan die herstel volgens hoeveel van die pad jy beheer.

Waarom die geheim nooit getoets word nie

PPP-verifikasie word onderhandel: die bediener stel metodes voor, die kliënt antwoord met wat dit kan doen, en albei kom op een ooreen voordat enige geloofsbrief uitgeruil word. Wanneer die bediener net EAP-PEAP aanbied en die kliënt se pppd dit nie implementeer nie, eindig die gesprek by die voorstelstadium. Die bediener teken ’n verifikasiefout aan omdat dit die stadium is wat gefaal het, nie omdat die wagwoord vergelyk en te kort bevind is nie.

Daarom is die fout identies vir ’n verkeerde wagwoord en vir ’n metode-wanpassing. Net die log onderskei tussen hulle, en net as die kliënt toegelaat word om uitvoerig te wees.

Lees die onderhandeling, nie die laaste fout nie

Voer die verbinding in die voorgrond uit met ontfouting aan en lees die verifikasielyne van bo af. Die log noem die metode wat voorgestel is, die metode wat aanvaar is en waar die uitruiling gestop het. ’n Profiel wat nooit CHAP of MSCHAPv2 verlaat terwyl die bediener PEAP verwag, is ’n metode-probleem, nie ’n geloofsbrief-probleem nie. Die laaste reël van daardie log is waar die kliënt opgegee het, nie waar die oorsaak sit nie.

sudo pppd call provider debug nodetach

Hou daardie uitvoer. Dit is ook die bewys wat ’n netwerk-eienaar nodig het voordat die bedienerbeleid verander word, en dit besleg die vraag of die wagwoord ooit in spel was.

Die tweede oorsaak skuil in die geheimbêre lêer

As die log wys dat die metodes ooreenstem, kyk na die lêer wat die geheim stoor. ’n Nuwereël of ’n sleepspasie wat in die wagwoordveld geskryf is, word as deel van die wagwoord gestuur, so die bediener vergelyk ’n ander string as die een wat jy getik het. Die lêer lyk korrek in ’n redigeerder, en dit is presies waarom dit soveel herprobeersels oorleef.

sudo cat -A /etc/ppp/chap-secrets

Die dollarteken merk die einde van elke reël in daardie uitvoer. ’n Wagwoordveld met enigiets voor daardie merk, of ’n los spasie tussen velde, moet herskryf word met die aanhaling wat die gereedskap dokumenteer.

Kies die herstel volgens wie die bediener besit

As die bediener joune is, om MSCHAPv2 vir daardie rekening toe te laat is die kleinste verandering, en jy moet aanteken dat jy doelbewus ’n swakker metode aanvaar het. As dit aan iemand anders behoort, is ’n kliënt wat EAP-PEAP implementeer die eerlike herstel; om pppd te pleister maak die onversoenbaarheid jou instandhoudingsprobleem. As die protokeuse nog oop is, is PPTP die swakste deel van die ontwerp en die migrasie is gewoonlik goedkoper as om ’n gepleisterde kliënt aan die lewe te hou. Skryf daardie besluit langs die profiel neer sodat die volgende persoon dit nie weer oopmaak nie.

Watter roete jy ook al volg, toets daarna vanaf ’n tweede masjien op ’n ander netwerk. ’n Gestoor profiel kan aanhou om die ou metode voor te stel en ’n reggestelde bediener laat lyk asof dit stukkend is. Verwyder dan die ontfoutinstelling, want uitvoerige PPP-logs kan meer vasvang as wat jy op ’n gedeelde werkstasie wil hê.