Avís AF_INET d'OpenVPN: retrocés inofensiu o socket fallit?

Dues línies del registre d'OpenVPN comencen amb les mateixes paraules i només una d'elles informa d'un problema. Could not determine IPv4/IPv6 protocol. Using AF_INET és un avís de retrocés: el perfil va deixar la família d'adreces oberta, així que el dimoni en va triar una i va continuar. La branca de fallada informa que no s'ha creat cap socket i demana un reinici. Tot el que ve després del prefix compartit les separa, així que llegiu més enllà abans de canviar res.

Què informa l'avís de retrocés

OpenVPN accepta una família explícita mitjançant proto udp4 o proto udp6, i accepta proto udp quan la família s'ha de derivar a l'inici. En el segon cas, el dimoni inspecciona la informació d'enllaç local i tria.

Quan aquesta derivació funciona, l'avís indica cap a on ha anat i el procés continua creant el socket. Un servidor amb proto udp en un amfitrió de doble pila acaba així a IPv4 molt sovint. Res d'aquest camí no és un error, i res no hi insinua un atac, un servidor web absent o un compte rebutjat. La línia només és útil perquè les comprovacions posteriors haurien de comparar-se amb la família que anomena.

Tracteu-ho com una resposta a una pregunta, no com un diagnòstic. Us diu quina família ha triat aquest procés i res de res sobre per què un client no es pot connectar.

Com es veu la branca de fallada

Més endavant, en el mateix codi de socket, hi ha una branca on no hi ha cap socket. Registra el missatge més curt de família d'adreces i demana un reinici, perquè no queda res per continuar. Les paraules inicials coincideixen amb el retrocés; el resultat, no.

Distingiu-les pel que ve després. Si el dimoni continua en marxa i informa del seu oient, la línia era informació. Si surt o es reinicia en bucle, ara la conversa és sobre l'enllaç.

Trobar-la amb grep tampoc no identifica la branca. La frase apareix en resums rotats, en línies partides i en extractes de registre que la gent enganxa de segona mà, així que llegiu les línies veïnes i l'ordre de les marques de temps en lloc de la coincidència única.

Comproveu l'oient en lloc de l'avís

Un servidor en funcionament respon la pregunta de la família directament, sense inferències del text del registre.

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

Feu coincidir la família, l'adreça i el port amb el perfil. Una línia 0.0.0.0:1194 és només IPv4, mentre que una línia [::]:1194 en un amfitrió de doble pila pot acceptar les dues famílies segons el paràmetre bindv6only. Si el perfil diu udp i el socket és IPv4, els clients el resoledor dels quals només retorna un registre AAAA fallaran abans que el túnel arribi a negociar-se.

Després proveu des d'un client semblant als vostres usuaris: mateix camí de resoledor, mateix tipus de xarxa. Una connexió local des del servidor demostra molt poc sobre el trànsit que travessa un dispositiu NAT o una regla de tallafoc escrita per a l'altra família.

Quan és correcte forçar una família

Fixar proto udp4 va bé per a un desplegament només IPv4: un nom DNS només A, regles de tallafoc per a una adreça v4, clients darrere d'operadors que només donen adreces v4. Elimina l'ambigüitat i fa predictible el següent conjunt de línies del registre.

El mateix argument funciona a l'inrevés per a un entorn amb IPv6 primer, i udp6 davant d'una base de clients només A és una caiguda autoinfligida. Forçar una família només per silenciar un avís inofensiu és la versió clàssica d'aquest error, perquè heu canviat qui es pot connectar a canvi d'un registre més tranquil.

Trieu a partir dels extrems i dels clients que hi han d'arribar. El manual d'OpenVPN 2.6 documenta les formes de transport, i el missatge és la sortida d'aquesta tria, no una entrada.

Manteniu el registre estret

Anoteu la línia exacta amb la seva marca de temps, el paràmetre de transport efectiu del perfil en execució, el socket tal com l'informa el nucli i la següent etapa que ha fallat. Aquests quatre elements resolen gairebé totes les preguntes que planteja el missatge, i cap d'ells no necessita endevinar serveis no relacionats. També sobreviuen a un traspàs, cosa que una captura de pantalla d'un grep no fa.

Els suggeriments de paquets que arriben amb aquest avís no hi tenen relació fins que un error anomena un executable absent.

Si ifconfig realment falta, el dimoni ho diu pel nom quan un script el crida, i això mereix una investigació pròpia. La línia AF_INET i una utilitat absent són fallades diferents, i instal·lar coses per veure si l'avís canvia és com un amfitrió net es converteix en un de desordenat.