L2TP/IPsec non funziona: isolare IPsec, l’autenticazione del tunnel o il login PPP

Tre cose si autenticano dentro una singola connessione L2TP/IPsec, e solo una di esse coinvolge la persona che compone il numero. IPsec dimostra gli estremi del tunnel, la connessione di controllo L2TP può dimostrare di nuovo i peer con un proprio segreto, e PPP dimostra poi l’account utente dentro la sessione. Un guasto in qualsiasi stadio appare come un errore di login generico nella finestra del client e appare del tutto diverso nel log del server. Percorri gli stadi in ordine e fermati al primo che fallisce, perché ogni stadio sotto uno non testato è anch’esso non testato.

Tre stadi di autenticazione, tre identità diverse

IPsec dimostra chi possiede gli estremi, usando una chiave pre-condivisa o un certificato. Quell’identità appartiene a macchine o gateway, mai alla persona davanti alla tastiera. Quando i peer non riescono a mettersi d’accordo in questo stadio, non viene scambiato alcun pacchetto L2TP.

La connessione di controllo L2TP può aggiungere un secondo scambio sfida-risposta separato, guidato da un segreto condiviso che entrambi gli estremi devono possedere.

RFC 2661 rende facoltativa quell’autenticazione della connessione di controllo, il che spiega perché lo stesso errore produca sintomi diversi su due server. Un’implementazione che non ha mai configurato un segreto del tunnel salta lo stadio del tutto; una che lo ha configurato solo su un lato fallisce prima che PPP venga mai offerto. PPP autentica poi l’utente con PAP, CHAP o MSCHAPv2 e consegna il nome a un archivio account che può essere locale, in chap-secrets o su RADIUS. Una password sbagliata a quel punto ti lascia comunque con un tunnel funzionante e una sessione fallita.

Leggi il punto di arresto prima di modificare una configurazione

Parti da ipsec --version per sapere se l’output di stato appartiene a strongSwan o a Libreswan. Poi leggi il log del server, non la finestra del client, perché il server registra quale stadio ha rifiutato.

Una riga di solito chiude il ticket: una lamentela su IKE o sulle proposte è lo stadio uno, un messaggio sulla connessione di controllo è lo stadio due e un rifiuto del metodo PPP o dell’account è lo stadio tre. Copia quella riga nel ticket con il timestamp. Tirare a indovinare dal lato client spreca l’unica prova che hai già.

Tieni materiale di chiave e password fuori da quell’incollaggio; il nome dello stadio indirizza il lavoro, e una chiave pre-condivisa divulgata riapre il ticket con conseguenze peggiori.

Primo stadio: IPsec ha un’associazione?

Esegui ipsec statusall su strongSwan o ipsec whack --status su Libreswan e cerca un’associazione figlia stabilita con contatori diversi da zero. ip xfrm state mostra la vista del kernel su entrambi. Una coppia di SA installata con contatori che salgono significa che il primo stadio è fatto e puoi proseguire.

L’assenza totale di associazione punta all’indirizzo del peer, all’insieme di proposte o alla chiave pre-condivisa, e a volte a un dispositivo che riscrive UDP 500 mentre scarta UDP 4500. Un’associazione che si stabilisce e poi sparisce dopo pochi secondi è di solito un disallineamento di durata tra i due estremi e non un problema di credenziali. Controlla se entrambi i lati elencano le stesse proposte di cifratura e hash prima di ridigitare qualcosa. Se non lo fanno, nessuna chiave funzionerà mai.

Fermati finché l’associazione manca. Modificare le opzioni PPP a quel punto non cambia nulla e nasconde il guasto reale alla persona successiva.

Secondo stadio: la connessione di controllo L2TP si è autenticata?

Una volta che IPsec è attivo, osserva il demone L2TP in cerca di una connessione di controllo che raggiunga uno stato stabilito, dato che PPP non può iniziare prima. Un rifiuto sulla connessione di controllo significa che il segreto del tunnel differisce tra gli estremi, oppure che un estremo richiede un segreto che l’altro non invia mai. I client espongono spesso un solo campo etichettato shared secret, e di norma appartiene a IPsec e non a L2TP. Compilarlo non configura il segreto del tunnel, e cancellarlo non lo disattiva.

Se nessuno dei due lati ha configurato un segreto del tunnel, salta questo stadio e tratta un guasto della connessione di controllo come un problema di raggiungibilità. Conferma che UDP 1701 raggiunga il demone e che entrambi gli estremi concordino sulla stessa incapsulatura. Una regola del firewall scritta per una di quelle due condizioni è una causa comune di una connessione che si apre a metà.

Solo una sessione che inizia a negoziare PPP ha davvero superato lo stadio del tunnel.

Terzo stadio: PPP sta rifiutando l’account?

Un guasto PPP appare diverso dall’esterno: il tunnel è stabilito, la sessione parte e il demone registra un guasto del metodo di autenticazione o un rifiuto dell’account. Leggi il metodo nominato in quel messaggio. PAP e CHAP falliscono per motivi diversi, e un server che rifiuta uno respingerà un client che offre solo quello.

Su un server Linux, ispeziona il file delle opzioni che il demone passa a PPP, di solito /etc/ppp/options.xl2tpd, e conferma quali metodi sono accettati e dove vengono risolti gli account. Un nome che esiste in RADIUS ma non nel file dei segreti locale fallisce in modo pulito e sembra una password sbagliata. Poi controlla che il client offra un metodo che il server accetta, invece di uno più forte che il server rifiuta di negoziare. Cambiare la chiave pre-condivisa per riparare questo stadio spreca un pomeriggio e non cambia nulla.

Quando la sessione finalmente sale, l’assegnazione degli indirizzi, il DNS e le rotte non sono ancora state verificate, e ciascuno fallisce in silenzio a modo suo. Tieni separati i tre livelli nelle tue note: una chiave corretta con un account sbagliato fallisce sempre, e riparare un livello non ripara mai l’altro.