PPTP dice che la password è sbagliata: quale correzione viene prima?

I profili PPTP che insistono che la password sia sbagliata dicono qualcosa di più stretto di quanto sembri. Il segreto viene provato proprio alla fine di una catena che inizia con la negoziazione delle capacità, quindi qualsiasi disallineamento precedente in quella catena si manifesta come un errore di autenticazione. Reimpostare la password, riscriverla o ricreare il profilo non cambia quindi nulla. Leggi prima la negoziazione, poi scegli la correzione in base a quanta parte del percorso controlli.

Perché il segreto non viene mai provato

L'autenticazione PPP viene negoziata: il server propone i metodi, il client risponde con ciò che sa fare e entrambi ne concordano uno prima che venga scambiata qualsiasi credenziale. Quando il server offre solo EAP-PEAP e il pppd del client non lo implementa, la conversazione si ferma allo stadio della proposta. Il server registra un errore di autenticazione perché è quello lo stadio che ha fallito, non perché la password sia stata confrontata e giudicata insufficiente.

Per questo l'errore è identico per una password sbagliata e per un disallineamento di metodo. Solo il registro li distingue, e solo se al client è consentito essere dettagliato.

Leggi la negoziazione, non l'ultimo errore

Avvia la connessione in primo piano con il debug attivo e leggi le righe di autenticazione dall'alto. Il registro indica il metodo proposto, il metodo accettato e dove lo scambio si è fermato. Un profilo che non lascia mai CHAP o MSCHAPv2 mentre il server si aspetta PEAP è un problema di metodo, non di credenziali. L'ultima riga di quel registro è dove il client si è arreso, non dove sta la causa.

sudo pppd call provider debug nodetach

Conserva quell'output. È anche la prova che il proprietario della rete deve avere prima di cambiare la politica del server, e risolve la questione se la password sia mai entrata in gioco.

La seconda causa si nasconde nel file dei segreti

Se il registro mostra che i metodi concordano, guarda il file che memorizza il segreto. Un fine riga o uno spazio finale scritti nel campo della password vengono inviati come parte della password, quindi il server confronta una stringa diversa da quella digitata. Il file sembra corretto in un editor, ed è proprio per questo che sopravvive a tanti tentativi.

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

Il segno del dollaro segna la fine di ogni riga in quell'output. Un campo password con qualcosa prima di quel segno, o uno spazio vagante tra i campi, va riscritto con le virgolette che lo strumento documenta.

Scegli la correzione in base a chi possiede il server

Se il server è tuo, consentire MSCHAPv2 per quell'account è la modifica più piccola, e dovresti annotare che hai accettato di proposito un metodo più debole. Se appartiene a qualcun altro, la correzione onesta è un client che implementa EAP-PEAP; correggere pppd rende l'incompatibilità un tuo problema di manutenzione. Se la scelta del protocollo è ancora aperta, PPTP è la parte più debole del progetto e la migrazione di solito costa meno che tenere in vita un client corretto. Scrivi quella decisione accanto al profilo, così la persona successiva non la riapre.

Qualunque strada scegli, prova poi da una seconda macchina su un'altra rete. Un profilo salvato può continuare a offrire il vecchio metodo e far sembrare rotto un server corretto. Poi rimuovi l'impostazione di debug, perché i registri PPP dettagliati possono catturare più di quanto vuoi su una postazione condivisa.