Avviso AF_INET di OpenVPN: ripiego innocuo o socket non riuscito?

Due righe del registro di OpenVPN iniziano con le stesse parole, e solo una di esse segnala un problema. Could not determine IPv4/IPv6 protocol. Using AF_INET è un avviso di ripiego: il profilo ha lasciato aperta la famiglia di indirizzi, quindi il demone ne ha scelta una e ha proseguito. Il ramo di errore segnala che nessun socket è stato creato e chiede un riavvio. Tutto ciò che segue il prefisso comune li separa, quindi legga oltre prima di cambiare qualcosa.

Che cosa segnala l'avviso di ripiego

OpenVPN accetta una famiglia esplicita tramite proto udp4 o proto udp6, e accetta proto udp quando la famiglia deve essere derivata all'avvio. Nel secondo caso il demone esamina le informazioni di collegamento locali e sceglie.

Quando quella derivazione funziona, l'avviso indica in quale direzione è andata e il processo continua a creare il socket. Un server con proto udp su un host a doppio stack finisce così su IPv4 abbastanza spesso. Niente in quel percorso è un errore, e niente in esso lascia intendere un attacco, un server web mancante o un account rifiutato. La riga è utile solo perché i controlli successivi dovrebbero essere confrontati con la famiglia che nomina.

La tratti come la risposta a una domanda, non come una diagnosi. Dice quale famiglia ha scelto questo processo, e nulla sul perché un client non riesca a connettersi.

Come appare il ramo di errore

Più avanti nello stesso codice del socket c'è un ramo in cui non esiste alcun socket. Registra il messaggio più corto sulla famiglia di indirizzi e chiede un riavvio, perché non resta nulla con cui continuare. Le parole iniziali coincidono con il ripiego; il risultato no.

Li distingua da ciò che segue. Se il demone continua a funzionare e segnala il suo ascoltatore, la riga era un'informazione. Se esce o si riavvia in un ciclo, ora la conversazione riguarda il collegamento.

Neppure un riscontro di grep identifica il ramo. La frase compare nei riepiloghi ruotati, nelle righe spezzate e negli estratti di registro che le persone incollano di seconda mano, quindi legga le righe vicine e l'ordine dei timestamp invece dell'unica corrispondenza.

Controlli l'ascoltatore invece dell'avviso

Un server in esecuzione risponde direttamente alla domanda della famiglia, senza inferenze dal testo del registro.

ss -lunp | grep openvpn
ss -ltnp | grep openvpn

Confronti famiglia, indirizzo e porta con il profilo. Una riga 0.0.0.0:1194 è solo IPv4, mentre una riga [::]:1194 su un host a doppio stack può accettare entrambe le famiglie a seconda dell'impostazione bindv6only. Se il profilo dice udp e il socket è IPv4, i client il cui resolver restituisce solo un record AAAA falliranno prima ancora che il tunnel venga negoziato.

Poi provi da un client simile ai suoi utenti: stesso percorso del resolver, stesso tipo di rete. Una connessione locale dal server dimostra molto poco sul traffico che attraversa un dispositivo NAT o una regola del firewall scritta per l'altra famiglia.

Quando forzare una famiglia è giusto

Fissare proto udp4 si adatta a una distribuzione solo IPv4: un nome DNS solo A, regole del firewall per un indirizzo v4, client dietro operatori che assegnano solo indirizzi v4. Elimina l'ambiguità e rende prevedibile la serie successiva di righe del registro.

Lo stesso ragionamento vale al contrario per un ambiente con IPv6 al primo posto, e udp6 davanti a una base di client solo A è un'interruzione autoinflitta. Forzare una famiglia solo per zittire un avviso innocuo è la versione classica di questo errore, perché ha cambiato chi può connettersi in cambio di un registro più tranquillo.

Scelga in base agli endpoint e ai client che devono raggiungerli. Il manuale di OpenVPN 2.6 documenta le forme di trasporto, e il messaggio è l'uscita di quella scelta, non un ingresso.

Tenga il verbale ristretto

Annoti la riga esatta con il suo timestamp, l'impostazione di trasporto effettiva del profilo in esecuzione, il socket così come lo segnala il kernel e la fase successiva che ha fallito. Questi quattro elementi risolvono quasi ogni domanda sollevata dal messaggio, e nessuno di essi richiede ipotesi su servizi non correlati. Sopravvivono anche a un passaggio di consegne, cosa che uno screenshot di grep non fa.

I suggerimenti sui pacchetti che arrivano insieme a questo avviso non hanno relazione finché un errore non nomina un eseguibile mancante.

Se ifconfig manca davvero, il demone lo dice per nome quando uno script lo chiama, e questo merita un'indagine propria. La riga AF_INET e un'utilità mancante sono errori diversi, e installare cose per vedere se l'avviso cambia è il modo in cui un host pulito diventa disordinato.