LCP terminato dal peer su PPTP: attivare prima MPPE

Il collegamento si autentica, il client segnala la connessione e un secondo dopo il log si chiude con LCP terminato dal peer. Quella riga proviene dalla negoziazione PPP dentro il tunnel GRE, quindi il trasporto funzionava già e i due estremi non erano d’accordo sulle opzioni del collegamento. Password e indirizzi del server di solito sono innocenti qui. La policy di cifratura è la prima cosa da confrontare e, su Linux, il file peer di pppd è il primo posto da guardare.

Che cosa dice il guasto LCP sulla fase PPP

PPTP incapsula PPP dentro GRE: la connessione di controllo TCP 1723 prepara la chiamata, GRE trasporta il carico e poi LCP negozia opzioni come il protocollo di autenticazione, la compressione e MPPE. Il peer termina LCP quando un’opzione obbligatoria non è accettabile dalla sua parte. Un log in cui lo scambio CHAP o MSCHAPv2 si completa e LCP finisce subito dopo è un rifiuto di policy, non un guasto di raggiungibilità. Se il tunnel non arriva mai alla negoziazione, controllate pppd e il suo plugin prima di leggere la riga LCP.

Due presupposti sfuggono facilmente. Il binario pppd deve esistere e il plugin PPTP indicato nel file peer deve essere installato; un pacchetto mancante chiude la chiamata prima che qualsiasi opzione venga discussa.

Attivate MPPE sul lato che lo richiede

La decisione vera è quale estremo possiede la policy di cifratura. Un client può offrire MPPE, richiederlo o rifiutarlo, e il server fa la stessa scelta. Quando entrambi lo richiedono il collegamento sale; quando uno lo richiede e l’altro lo rifiuta, LCP termina.

pty "pptp vpn.example.net --nolaunchpppd"
name alice
remotename PPTP
require-mppe-128

Caricate il modulo con modprobe ppp_mppe prima di comporre, perché require-mppe-128 fallisce senza. Su Windows il controllo equivalente è la scheda Sicurezza della voce VPN, dove bisogna dire al client di richiedere la cifratura invece di accettare ciò che il server offre. Se il server termina ancora LCP, chiedete al suo gestore se MPPE è obbligatorio, opzionale o disattivato, dato che un client non può negoziare una protezione che il server rifiuta. Disattivare la cifratura per far sparire il messaggio è la direzione sbagliata: elimina l’unica protezione che questo protocollo ha.

Salvate il file peer funzionante prima di modificarlo. Una riga require-mppe digitata male riproduce lo stesso guasto LCP generico e vi riporta all’inizio.

Leggete il log di pppd invece dell’applet

Le applet desktop mostrano la disconnessione e nascondono il motivo, quindi leggete il resoconto del demone su un singolo tentativo. Nei sistemi systemd il messaggio finisce nel journal; le installazioni più vecchie scrivono nei file di log tradizionali.

journalctl --since "10 min ago" | grep -i -E "pppd|lcp|mppe"
tail -n 50 /var/log/syslog

Cercate in una finestra attorno a una sola chiamata invece che in un’intera giornata di riconnessioni, così l’opzione rifiutata è facile da vedere. pppd di solito nomina l’opzione e la risposta del peer, il che vi dice se cambiare la vostra proposta o chiedere al lato server di allentare il requisito. Mantenete i tentativi con marca temporale, perché confrontare due log è utile solo quando sapete quali righe appartengono a quale chiamata. Quando non compare alcuno scambio LCP, il guasto è più a monte nella catena e MPPE non è il sospetto.

Mantenete la correzione tra le riconnessioni: nomi degli hook e MTU

Una volta che il collegamento resta su, due dettagli decidono se sopravvive a una riconnessione. Gli hook vivono in /etc/ppp/ip-up.d e /etc/network/if-up.d, e run-parts elabora entrambe le directory, con un filtro sui nomi dei file che rifiuta tutto ciò che contiene un punto. Perciò uno script chiamato set-pptp.sh viene saltato, mentre set-pptp viene eseguito. Controllate il nome prima di fare debug del contenuto dello script, poi impostate la MTU più piccola dall’interno di quell’hook perché ogni nuova interfaccia ppp la erediti senza un comando manuale.

run-parts --test /etc/ppp/ip-up.d
ip link set dev ppp0 mtu 1200

Per terminare una sessione di proposito, puntate al pid registrato da pppd invece di confrontare i nomi dei processi, perché uccidere tutto ciò che contiene ppp abbatte anche collegamenti non correlati. PPTP è obsoleto e MS-CHAPv2 è debole, quindi trattate questi controlli come manutenzione di un collegamento che deve continuare a funzionare, non come motivo per distribuire PPTP in posti nuovi.