Gli errori di scrittura GRE su pptpd non sono un problema di password

Errore di scrittura GRE nel registro, e il primo istinto è reimpostare la password dell'utente. Quell'istinto è quasi sempre sbagliato. Questi messaggi descrivono il percorso dei dati, non il controllo delle credenziali: il client può essersi autenticato correttamente e poi essersi bloccato nella fase in cui si registra sulla rete. Due messaggi diversi indicano due guasti diversi, e nessuno dei due si risolve con una nuova password.

Due messaggi, due guasti diversi

Un errore di lettura significa che i pacchetti GRE non raggiungono mai il demone o vengono scartati all'ingresso. La connessione di controllo può sembrare perfettamente sana mentre nulla attraversa il percorso dei dati. L'autenticazione è l'unica cosa che ha funzionato in modo dimostrabile.

Un errore di scrittura di solito significa che la sessione ha negoziato qualcosa che il kernel o il client non possono usare. Il canale di controllo si è completato, e le opzioni concordate durante quello scambio non corrispondono a ciò che gli endpoint possono realmente fare. È un disaccordo di configurazione, non un evento di autenticazione.

Leggi quale dei due compare prima di cambiare qualsiasi cosa. Ti portano a livelli diversi, e trattarli come un solo sintomo è il motivo per cui lo stesso server viene corretto due volte per motivi non correlati. La riga di registro è l'unica diagnostica gratuita che ottieni.

Il protocollo 47 non è la porta 47

PPTP usa TCP 1723 per stabilire la chiamata e GRE per trasportare il carico utile. GRE è il protocollo IP 47, non un numero di porta, quindi una regola del firewall che apre la porta 47 non consente nulla di utile.

Un router sul percorso ha bisogno di una funzione passthrough PPTP o di un permesso GRE esplicito. Senza di essa, l'handshake TCP si completa e il tunnel non trasporta mai un pacchetto, il che produce esattamente l'errore di lettura sopra. Le regole sulla porta 47 in un firewall sono il pomeriggio più spesso sprecato di questo protocollo.

Osserva entrambe le direzioni insieme sul server invece di indovinare quale lato scarta il traffico: tcpdump -ni any port 1723 or proto gre.

Se 1723 mostra la configurazione della chiamata mentre GRE resta silenzioso, il blocco è a monte dell'host. Se GRE arriva e il demone fallisce ancora, il problema è locale e le opzioni sono il prossimo posto da guardare.

Consenti GRE dove l'host inoltra davvero

Inserire una regola forward per GRE è una prova ragionevole su un host che inoltra traffico di tunnel, e non è una politica. Una regola di prova che accetta tutto di un protocollo è una diagnostica, non un progetto. Lasciala abbastanza a lungo da imparare qualcosa, poi sostituiscila con una regola limitata.

Aggiungi una regola input per i pacchetti indirizzati al server stesso, perché la catena forward non li vede. Poi guarda i contatori della regola prima e dopo un tentativo di connessione, il che ti dice se i pacchetti arrivano.

Rendi persistente la regola tramite il servizio firewall della distribuzione invece di rieseguirla dopo ogni riavvio. Su un host nftables, fai corrispondere ip protocol gre sia nella catena input sia in quella forward.

Verifica che anche il modulo ppp_generic sia caricato e controlla se il tracciamento delle connessioni scarta la direzione di ritorno. Entrambi producono guasti che sembrano un problema di firewall e non lo sono. Un modulo del kernel mancante sembra esattamente un protocollo bloccato finché non controlli.

Adatta le opzioni al client che hai davvero

La correzione dell'altro rapporto si trova in /etc/ppp/pptpd-options, dove la ricetta rifiuta PAP, CHAP e MSCHAP, commenta le righe require corrispondenti e mantiene MPPE con stato. Quella ricetta è stata scritta per una miscela di client, e copiarla alla cieca rompe il caso comune. Leggi le righe di rifiuto come un'affermazione sui client che l'autore aveva, non come una raccomandazione.

Un client Windows di solito ha bisogno di MS-CHAPv2 con MPPE-128. Mantieni quei requisiti e rimuovi solo le opzioni che il client non può davvero negoziare.

# keep encryption; drop only what this client cannot negotiate
refuse-pap
refuse-chap
refuse-mschap
mppe-stateful
require-mschap-v2
require-mppe-128

Disattivare la crittografia per far riuscire una connessione è un degrado, non una riparazione. Prova una variante del genere su un collegamento di laboratorio, poi ripristina la crittografia prima che il servizio affronti client reali. La connessione che funziona in modo non sicuro è peggiore di quella che fallisce onestamente.

Leggi il numero di errore del client

Il codice numerico del client restringe la fase più in fretta del registro del server. Leggilo prima di leggere qualsiasi altra cosa. 691 significa che le credenziali sono state rifiutate, 721 significa che il server non ha mai risposto e 619 significa che la connessione è caduta. Due minuti con il numero fanno risparmiare un'ora con la configurazione.

Confronta quel codice con il registro del server prima di modificare qualcosa, e riprova con lo stesso client dopo ogni modifica. Altrimenti un secondo guasto si nasconde dietro il primo e la correzione sembra inefficace.

Quando l'accesso riesce e nessun traffico si muove, GRE resta il sospetto. È il momento di tornare alla cattura invece che all'archivio delle credenziali.