Perché PPP CHAP da solo non può soddisfare un requisito MPPE

Un profilo PPTP che insiste sulla crittografia di solito fallisce nello stesso punto: PPP concorda uno scambio di autenticazione che non produce mai il materiale di chiave di cui MPPE ha bisogno. Il tunnel sembra mezzo vivo, la password viene accettata e il collegamento cade prima che vi passi qualsiasi traffico. Ricorrere al menu a discesa CHAP finché qualcosa si connette nasconde il difetto reale, che è un contratto tra il metodo di autenticazione e la politica di protezione. I controlli seguenti sono ordinati in modo che ciascuno escluda una causa più economica della successiva.

Due negoziazioni scorrono dentro una sola connessione PPTP

PPTP trasporta una normale sessione PPP dentro un tunnel GRE, e le due negoziano separatamente. Lo strato esterno decide come vengono incapsulati i pacchetti e quale canale di controllo esiste; la sessione PPP interna decide chi è il peer e quale protezione viaggia sopra. Una richiesta di password dimostra quindi qualcosa solo sullo strato interno, e un handshake esterno completato non dimostra nulla su nessuno dei due. I profili falliscono qui perché le persone eseguono il debug del tunnel mentre il disaccordo risiede dentro PPP.

CHAP semplice è lo scambio sfida-risposta della RFC 1994, costruito su un segreto condiviso e nient’altro. MS-CHAPv2 è uno scambio diverso con messaggi diversi e un output diverso, standardizzato nella RFC 2759. La parola condivisa nei due nomi è l’unica cosa che hanno in comune sul filo. Nessuno dei due nomi dice cosa produce lo scambio, ed è l’unica parte che conta.

Per questo un’opzione etichettata semplicemente CHAP è ambigua in un profilo vecchio. Quando il server vuole MS-CHAPv2 e il client offre CHAP semplice, il controllo del collegamento può comunque completarsi e una password può comunque essere accettata. Il guasto arriva più tardi, quando il server tenta di derivare chiavi di protezione da uno scambio che non ne ha prodotta alcuna.

Abbinate il metodo richiesto alle chiavi che può produrre

Le chiavi MPPE non sono una proprietà di PPP in generale. Per la famiglia Microsoft CHAP la derivazione è specificata nella RFC 3079, e prende come input l’output di uno scambio MS-CHAP anziché un segreto condiviso. I metodi EAP raggiungono lo stesso punto per un’altra via, con il server di autenticazione che restituisce le chiavi come attributi MS-MPPE-Recv-Key e MS-MPPE-Send-Key. CHAP semplice non compare in nessuno dei due percorsi, ed è tutta la ragione per cui esiste la discrepanza.

Una configurazione che richiede MPPE mentre rifiuta ogni metodo capace di fornire chiavi è internamente contraddittoria. pppd risolve quella contraddizione rifiutando il collegamento, non inventando chiavi, quindi il risultato visibile è una sessione che si autentica e poi termina durante la fase di rete. Riprovare il client non cambierà nulla finché il server rifiuta gli unici metodi che derivano qualcosa.

La regola che ne segue è breve: se il profilo richiede MPPE, il metodo deve essere una variante di MS-CHAP o un metodo EAP le cui chiavi il server restituisce. Rifiutare solo MS-CHAPv2 non lo impone, perché anche MS-CHAPv1 deriva chiavi e resta disponibile a meno che non venga rifiutato separatamente; rifiutare entrambi lascia CHAP semplice e PAP, che non derivano nulla e rendono il requisito insoddisfacibile. Nominate esplicitamente il metodo accettato invece di elencare quelli che non vi piacciono. Abbandonare il requisito di crittografia per far connettere un client è un degrado, non una riparazione.

Leggete le opzioni del server prima di modificare un client

La maggior parte di queste discrepanze è visibile sul server in due file, e leggerli costa meno che ricostruire un client. Su un endpoint PPTP Linux le impostazioni rilevanti vivono nel file di opzioni di pppd che pptpd passa. Eseguitelo sul server, non da una schermata di stato del client. Iniziate dalle righe che richiedono, rifiutano o nominano una modalità di protezione:

sudo grep -nE 'require-|refuse-|mppe|mschap' /etc/ppp/options.pptpd

Leggete l’output come un contratto e non come un elenco di flag. Una riga che richiede MPPE mentre rifiuta le due varianti MS-CHAP non può essere soddisfatta da nessun client, e un requisito assente per un metodo MS-CHAP lascia la porta aperta a scambi che non danno chiavi. Poi controllate chi può autenticarsi in assoluto, cosa che decide il file dei segreti:

sudo sed -n '1,20p' /etc/ppp/chap-secrets
sudo pppd --version

Annotate tre valori prima di cambiare qualcosa: il protocollo esterno, il metodo di autenticazione richiesto dal server e se la protezione è obbligatoria o facoltativa. Quei tre determinano ogni decisione successiva, e indovinarli da una finestra di dialogo del client è il modo in cui un profilo finisce mezzo configurato. Tenete il file aperto mentre lavorate, perché la sezione successiva ha bisogno degli stessi tre valori.

Localizzate il guasto per fase PPP

PPP segnala i guasti per fasi, e la fase dice quale clausola del contratto si è rotta. Un collegamento che non lascia mai il controllo del collegamento ha un problema di incapsulamento o di negoziazione, mentre uno che si autentica e poi muore di solito ha un problema di politica o di chiave. Un collegamento che resta su e non trasporta nulla è passato all’instradamento, che è un’altra indagine.

Il journal conserva le righe di fase, e sono più utili di un livello di debug più alto. Chiedete i processi PPP e i messaggi di protezione, poi leggete il risultato dell’autenticazione prima di ogni altra cosa. Le ultime righe di solito nominano la clausola che ha rifiutato:

sudo journalctl -b --no-pager | grep -iE 'pppd|pptpd|mppe|chap' | tail -40

In quell’output, cercate prima il risultato dell’autenticazione e poi una lamentela che la protezione era richiesta ma non negoziata. Il secondo messaggio è la firma della contraddizione qui sopra, e nessuna quantità di tentativi lo cancella finché il server rifiuta l’unico metodo in grado di produrre chiavi. Vale la pena nominare due trappole: alzare il livello di debug senza leggere le righe di fase produce rumore, e catturare materiale di sfida o password trasforma un compito di configurazione in una fuga di credenziali. Registrate quella fase prima di cambiare qualsiasi opzione.

Pianificate l’uscita prima che l’endpoint vecchio venga spento

MPPE è un meccanismo storico di protezione del collegamento, e la sua presenza non rende PPTP una scelta sensata per un nuovo dispiegamento. Le attuali linee guida Microsoft sconsigliano già PPTP e L2TP/IPsec con chiave precondivisa per i nuovi dispiegamenti di accesso remoto. Mantenere in vita un endpoint legacy è una decisione su un servizio esistente, non un modello per il successivo.

Quando l’endpoint deve restare, scrivete il contratto: protocollo esterno, metodo di autenticazione richiesto, protezione obbligatoria e la versione di client che la negozia. Quando può andarsene, scegliete l’identità del gateway del sostituto, la sua autenticazione client e dove vivranno le credenziali prima di toccare il profilo vecchio. Poi pianificate rotte, DNS e le risorse a cui ogni utente è autorizzato. Validate il client previsto rispetto ai requisiti del proprietario e non rispetto a una connessione funzionante.

Un rifiuto deliberato deve restare un rifiuto, perché tornare a una modalità non protetta per far passare un test trasforma un guasto di politica in un’esposizione. Lo stato finale è un contratto supportato e documentato, non il più piccolo insieme di modifiche che fa riuscire una vecchia connessione. Lasciate il profilo vecchio al suo posto, inutilizzato e documentato, finché il sostituto non supera gli stessi controlli.