Aviso AF_INET de OpenVPN: ¿retroceso inofensivo o socket fallido?

Dos líneas del registro de OpenVPN comienzan con las mismas palabras y solo una de ellas informa de un problema. Could not determine IPv4/IPv6 protocol. Using AF_INET es un aviso de retroceso: el perfil dejó abierta la familia de direcciones, así que el demonio eligió una y siguió. La rama de fallo informa de que no se creó ningún socket y pide un reinicio. Todo lo que viene después del prefijo común las separa, así que lea más allá antes de cambiar nada.

Qué informa el aviso de retroceso

OpenVPN acepta una familia explícita mediante proto udp4 o proto udp6, y acepta proto udp cuando la familia debe derivarse al arrancar. En el segundo caso el demonio inspecciona la información de enlace local y elige.

Cuando esa derivación funciona, el aviso indica hacia dónde fue y el proceso continúa creando el socket. Un servidor con proto udp en un equipo de doble pila acaba así en IPv4 con bastante frecuencia. Nada en ese camino es un error, y nada en él insinúa un ataque, un servidor web ausente o una cuenta rechazada. La línea solo es útil porque las comprobaciones posteriores deberían compararse con la familia que nombra.

Trátelo como una respuesta a una pregunta, no como un diagnóstico. Dice qué familia eligió este proceso, y nada en absoluto sobre por qué un cliente no puede conectarse.

Cómo se ve la rama de fallo

Más adelante, en el mismo código del socket, hay una rama en la que no existe ningún socket. Registra el mensaje más corto de familia de direcciones y solicita un reinicio, porque no queda nada con lo que continuar. Las palabras iniciales coinciden con el retroceso; el resultado no.

Distinga una de otra por lo que sigue. Si el demonio sigue ejecutándose e informa de su oyente, la línea era información. Si sale o se reinicia en bucle, ahora la conversación trata del enlace.

Tampoco un acierto de grep identifica la rama. La frase aparece en resúmenes rotados, en líneas partidas y en extractos de registro que la gente pega de segunda mano, así que lea las líneas vecinas y el orden de las marcas de tiempo en lugar de la coincidencia única.

Compruebe el oyente en lugar del aviso

Un servidor en ejecución responde a la pregunta de la familia directamente, sin inferencias del texto del registro.

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

Haga coincidir la familia, la dirección y el puerto con el perfil. Una línea 0.0.0.0:1194 es solo IPv4, mientras que una línea [::]:1194 en un equipo de doble pila puede aceptar ambas familias según el ajuste bindv6only. Si el perfil dice udp y el socket es IPv4, los clientes cuyo resolutor solo devuelve un registro AAAA fallarán antes de que el túnel llegue a negociarse.

Luego pruebe desde un cliente parecido a sus usuarios: misma ruta de resolución, mismo tipo de red. Una conexión local desde el servidor demuestra muy poco sobre el tráfico que cruza un dispositivo NAT o una regla de cortafuegos escrita para la otra familia.

Cuándo es correcto forzar una familia

Fijar proto udp4 conviene a un despliegue solo IPv4: un nombre DNS solo A, reglas de cortafuegos para una dirección v4, clientes tras operadores que solo entregan direcciones v4. Elimina la ambigüedad y hace predecible el siguiente conjunto de líneas del registro.

El mismo argumento funciona al revés para un entorno con IPv6 primero, y udp6 ante una base de clientes solo A es una caída autoinfligida. Forzar una familia solo para silenciar un aviso inofensivo es la versión clásica de este error, porque ha cambiado quién puede conectarse a cambio de un registro más tranquilo.

Elija a partir de los extremos y de los clientes que deben alcanzarlos. El manual de OpenVPN 2.6 documenta las formas de transporte, y el mensaje es la salida de esa elección, no una entrada.

Mantenga el registro estrecho

Anote la línea exacta con su marca de tiempo, el ajuste de transporte efectivo del perfil en ejecución, el socket tal como lo informa el núcleo y la siguiente etapa que falló. Esos cuatro elementos resuelven casi todas las preguntas que plantea el mensaje, y ninguno necesita adivinar servicios no relacionados. También sobreviven a un traspaso, cosa que una captura de pantalla de un grep no hace.

Las sugerencias de paquetes que llegan junto a este aviso no tienen relación hasta que un error nombra un ejecutable ausente.

Si ifconfig falta de verdad, el demonio lo dice por su nombre cuando un script lo llama, y eso merece su propia investigación. La línea AF_INET y una utilidad ausente son fallos distintos, e instalar cosas para ver si el aviso cambia es la forma en que un equipo limpio se convierte en uno desordenado.