Il listener di OpenVPN 2.5 su DD-WRT è morto? Leggi la configurazione generata

Un listener morto su DD-WRT di solito significa che il daemon è uscito mentre analizzava la sua configurazione, non che una regola del firewall abbia bloccato la porta. OpenVPN 2.5 ha irrigidito diversi valori predefiniti su cui facevano affidamento le configurazioni precedenti, e una configurazione generata che funzionava su una build più vecchia può essere rifiutata prima ancora che il socket venga aperto. Il motivo è nel log del router stesso e l’input nel file generato. Leggere entrambi in quest’ordine è più veloce di qualsiasi cattura di pacchetti.

Il daemon non è il firewall

La distinzione conta perché i due guasti sembrano identici dall’esterno: un client invia una stretta di mano e non riceve nulla. Uno è un processo che non è in esecuzione, l’altro è un processo che è in esecuzione e filtra.

Separali con due controlli prima di cambiare qualcosa, perché modificare il firewall su un daemon morto aggiunge solo una seconda variabile.

Leggi la configurazione generata da DD-WRT

DD-WRT non passa a OpenVPN il testo che hai digitato nell’interfaccia web. Scrive una configurazione generata in /tmp/openvpn/openvpn.conf e avvia il daemon con quel file, così i campi dell’interfaccia e qualsiasi testo in Additional Config vengono uniti prima che OpenVPN li veda. Se fai il debug del modulo invece del file generato, stai leggendo un’intenzione e non l’input reale. Copia quel file in un posto persistente prima che un riavvio /tmp lo cancelli.

Confronta il file generato con ciò che intendevi, soprattutto dove l’interfaccia scrive una direttiva che non hai mai scelto. Un menu a tendina che emette un’opzione obsoleta è invisibile nel modulo e fatale per il daemon.

Se il file generato è vuoto o manca, il daemon non è nemmeno arrivato all’avvio e il problema sta a monte di OpenVPN.

Cosa ha smesso di accettare OpenVPN 2.5

OpenVPN 2.5 ha sostituito ncp-ciphers con data-ciphers, e ha alzato la versione minima TLS predefinita a 1.2. Ha anche cambiato la gestione della compressione, così che un peer che offre compressione viene rifiutato se la configurazione non lo consente esplicitamente, e ha reso obsoleti nomi di opzione più vecchi come ns-cert-type a favore di remote-cert-tls. Ognuno di questi cambiamenti trasforma una configurazione che funzionava in un errore di analisi o di negoziazione.

La modalità di guasto dipende dalla direttiva. Un’opzione sconosciuta o rimossa ferma il daemon all’avvio, ed è il tuo listener morto. Un disallineamento di negoziazione lascia correre il daemon e rifiuta i client, cosa che dal lato client sembra un problema di firewall.

Leggi il primo errore nel log, non l’ultimo. L’analisi si ferma alla prima direttiva sbagliata e tutto ciò che segue è rumore dello spegnimento.

I prerequisiti specifici di Broadcom

Nelle build per Broadcom il dispositivo di tunnel deve esistere prima che il daemon possa usarlo. Controlla che il modulo tun sia caricato e che /dev/net/tun sia presente, perché un dispositivo mancante produce un guasto all’avvio che non ha nulla a che vedere con i certificati. Lo stesso vale per gli script ausiliari che DD-WRT genera per rotte e DNS: se mancano o non sono eseguibili, il daemon può partire e comunque non completare la sua configurazione.

Esegui il daemon in primo piano con maggiore verbosità sulla configurazione generata quando ti serve il messaggio reale. Un’esecuzione in primo piano stampa l’errore di analisi che lo script init ha inghiottito.

Poi ripristina il servizio normale, perché un daemon in primo piano e lo script init si contenderanno la porta.

Dimostra che il listener esiste prima di fare il debug dei client

Conferma il processo e il socket separatamente: un comando per il daemon in esecuzione, un altro per una porta UDP associata all’indirizzo atteso. Un processo senza socket significa che è ancora in configurazione o associato all’interfaccia sbagliata. La coppia è un test utile proprio perché una metà non può essere vera senza l’altra.

Il debug lato client ha senso solo dopo che il listener esiste. Allora controlla che cifratura e impostazioni TLS del client corrispondano alla lista data-ciphers del server e alla sua versione minima, e che la porta sia davvero inoltrata al router.

Conserva la configurazione generata e la riga di log che ha dimostrato la correzione. Il prossimo aggiornamento del firmware può cambiare di nuovo i valori predefiniti, e quella traccia è ciò che trasforma una ripetizione in un controllo di cinque minuti.