L2TP si connette ma la negoziazione PPP fallisce: quale fase?

Il tunnel IPsec si stabilisce, il client mostra un peer protetto e poi la connessione muore prima che qualcosa raggiunga la sottorete privata. Quello scarto è PPP che fa il proprio lavoro: le opzioni del collegamento, l’autenticazione dell’utente e l’assegnazione dell’indirizzo avvengono tutte dopo che il tunnel cifrato esiste. Nulla in uno scambio riuscito di prima fase fornisce una password o un indirizzo interno. Leggi le fasi in ordine e il guasto di solito si nomina da solo.

Il tunnel è solo il primo strato

L2TP trasporta frame PPP dentro un tunnel protetto da IPsec, il che significa che due negoziazioni indipendenti devono riuscire prima che un pacchetto possa essere instradato. Quella esterna dimostra che i due estremi concordano su chiavi e identità. Quella interna decide i parametri del collegamento, se l’utente si autentica e quale indirizzo riceve il client.

Un guasto dentro PPP sembra un tunnel rotto in ogni client che mostra una sola spia di stato. Trattarlo come un problema di tunnel porta a rigenerare chiavi, riavviare servizi e infine a sostituire un segreto condiviso che non era mai sbagliato. La distinzione utile costa poco: se lo scambio con il peer si è concluso e il client è passato a una richiesta di nome utente o a una fase di autenticazione, il tunnel è a posto. Tutto ciò che segue quel punto appartiene a PPP.

Leggi l’ultima fase riuscita

Scorri il registro in avanti e fermati alla prima fase che non si è conclusa. Prima viene LCP, poi l’autenticazione, poi IPCP per i parametri IPv4.

sudo journalctl -u xl2tpd -b --no-pager | tail -n 40
sudo journalctl -b --no-pager | grep -i -E 'pppd|lcp|chap|ipcp'
ip -4 address show ppp0

Un timeout LCP significa che i due estremi non hanno mai concordato le opzioni di base del collegamento, cioè un profilo non corrispondente o un protocollo interno bloccato, non una password sbagliata. Un rifiuto esplicito dell’autenticazione è il caso opposto: il collegamento è salito e un lato ha respinto le credenziali. Un timeout IPCP dopo un’autenticazione riuscita indica pool di indirizzi o criteri del server. Ognuno di questi ha un proprietario diverso e una riparazione diversa, per questo la fase conta più del testo finale dell’errore.

Conserva l’estratto del registro insieme al nome della fase nel ticket. Una coda incollata senza il confine di fase invita il lettore successivo a indovinare, e indovinare qui costa un’ora.

Accordo tra il client e il server

Entrambi gli estremi devono accettare lo stesso metodo di autenticazione, e un profilo salvato può richiederne uno che il server ha ritirato nel trimestre scorso. Le distribuzioni gestite nascondono anche il lato server, dove il motivo del rifiuto viene di solito registrato sull’utente anziché sul dispositivo.

Attiva un metodo supportato invece di ogni opzione legacy, perché un client che ne offre cinque maschera quale ha fallito. Chiedi all’amministratore la politica lato server e il rifiuto esatto, il che non richiede che qualcuno pubblichi una password. Un metodo legacy attivato per salvare un solo client tende a diffondersi a ogni profilo che copia il file.

Verifica l’indirizzo, non l’accesso

Un accesso completato non è una sessione utilizzabile. IPCP negozia l’indirizzo interno, e un pool esaurito o una politica che nega il client possono comunque lasciare un tunnel connesso senza nulla da instradare.

ip -4 address show ppp0
ip route get 10.52.9.1
ping -c 2 10.52.9.1

Controlla prima l’indirizzo interno, poi la rotta e il resolver per la risorsa che ti serve davvero. Un indirizzo interno non è l’uscita pubblica che un sito web riporta, e confondere i due manda la gente a caccia di una fuga che non c’è. Prova la risorsa privata per indirizzo prima di provarla per nome, così un guasto DNS non viene scambiato per un guasto di instradamento.

Scrivi la fase, il metodo e l’indirizzo in un’unica nota e datala. Se lo stesso account fallisce di nuovo entro un mese, quella nota è la differenza tra un controllo di cinque minuti e un’indagine nuova. Guasti in fasi diverse sono incidenti diversi, anche quando il client mostra un solo dialogo.