NO_PROPOSAL_CHOSEN su L2TP? Esamina prima il gateway

Un client L2TP/IPsec che fallisce prima della richiesta del nome utente non ha mai concordato la fase 1. Esamina l’insieme delle proposte del gateway invece di incollare stringhe di cifratura.

La richiesta del nome utente non compare mai e il client segnala NO_PROPOSAL_CHOSEN. A quel punto le credenziali e la chiave precondivisa sono irrilevanti, perché i due estremi non hanno concordato come proteggere la fase 1. La maggior parte delle persone reagisce incollando una stringa di cifratura trovata online. Un’analisi del gateway risponde alla stessa domanda con prove e richiede più o meno lo stesso tempo.

Che cosa esclude il messaggio

Il rifiuto avviene in modalità principale, prima di qualsiasi scambio L2TP o PPP, quindi né il tunnel né il database utenti sono stati interrogati. La fase 1 negozia cifratura, integrità e un gruppo Diffie-Hellman. La fase 2 negozia la proposta ESP per i dati. Un guasto della fase 1 non si risolve cambiando un’impostazione PFS della fase 2, e un’associazione IKE completata non dimostra che la proposta ESP sia adatta.

Annota il backend prima di modificare la sintassi: ipsec --version. libreswan e strongSwan accettano grafie diverse della proposta per gli stessi algoritmi.

Poi leggi il rifiuto nel contesto con journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

Esamina il gateway per il suo insieme di trasformazioni

Uno scanner chiede direttamente al gateway quali trasformazioni negozierà. Ferma prima il servizio IPsec locale, così la sonda non compete con il tuo client, poi leggi le righe SA. Tratta l’elenco come prova sul peer, non come un menu da attivare in blocco.

sudo ipsec stop
sudo ike-scan --trans=3des-sha1-modp1024 10.10.10.250 | grep SA=

I dispositivi più vecchi offrono spesso 3DES, SHA1 e MODP1024, perché erano i valori predefiniti alla spedizione del prodotto e nessuno li ha riesaminati. Conserva l’output grezzo dell’analisi, perché è l’unica registrazione di ciò che il peer offriva quel giorno. Se è la sovrapposizione più forte disponibile, l’escalation corretta va al proprietario del gateway, non a una configurazione client che riattiva crittografia debole per tutti.

Fai combaciare la sovrapposizione senza disattivare la sicurezza

Inserisci solo le trasformazioni presenti sia nell’analisi sia nella tua politica. L’esempio seguente rispecchia un gateway che offre 3DES, SHA1 e MODP1024 nella fase 1. Nota l’avvertenza sul backend: libreswan 4.x non compila il gruppo modp1024, quindi questo vale per strongSwan o per una build di libreswan con supporto DH2. Verifica la versione prima di concludere che il client sia guasto.

Phase 1: 3des-sha1-modp1024
Phase 2: aes256-sha1,aes128-sha1,3des-sha1

Un punto esclamativo finale fissa una singola proposta. Usalo per isolare un test, poi rimuovilo perché il gateway possa negoziare qualcosa di più forte in seguito.

Controlla il demone e la porta prima di riprovare

NetworkManager-l2tp avvia una propria istanza di xl2tpd. Se il servizio di sistema possiede già la porta UDP 1701, il client ripiega su una porta sorgente effimera, cosa che il RFC 3193 consente e che alcuni server scartano in silenzio. Controlla il proprietario del socket prima del tentativo successivo.

sudo ss -unlp | grep 1701
sudo systemctl stop xl2tpd.service
sudo systemctl disable xl2tpd.service

I segreti generati obsoleti sono un’altra causa silenziosa. I file sotto /etc/ipsec.d/ intitolati a una vecchia connessione possono sopravvivere al profilo che li ha creati, quindi rimuovi quelli a cui nulla fa riferimento e riprova.

Infine, controlla da dove viene il consiglio. Un ipsec.conf scritto per IKEv1 XAuth descrive un altro tipo di VPN, e la sua proposta non è l’unica riga che sarà sbagliata in un profilo L2TP. Annota l’insieme di trasformazioni inserito accanto al profilo, così la persona successiva non ripeterà la sonda.

Articoli correlati