Aviso AF_INET de OpenVPN: retroceso inofensivo ou socket fallido?

Dúas liñas do rexistro de OpenVPN comezan coas mesmas palabras e só unha delas informa dun problema. Could not determine IPv4/IPv6 protocol. Using AF_INET é un aviso de retroceso: o perfil deixou aberta a familia de enderezos, así que o daemon escolleu unha e seguiu. A rama de fallo informa de que non se creou ningún socket e pide un reinicio. Todo o que vén despois do prefixo común sepáraas, así que lea máis alá antes de cambiar nada.

Que informa o aviso de retroceso

OpenVPN acepta unha familia explícita mediante proto udp4 ou proto udp6, e acepta proto udp cando a familia debe derivarse no arrinque. No segundo caso o daemon inspecciona a información de enlace local e escolle.

Cando esa derivación funciona, o aviso indica cara a onde foi e o proceso continúa creando o socket. Un servidor con proto udp nun equipo de dobre pila acaba así en IPv4 con bastante frecuencia. Nada nese camiño é un erro, e nada nel insinúa un ataque, un servidor web ausente ou unha conta rexeitada. A liña só é útil porque as comprobacións posteriores deberían compararse coa familia que nomea.

Tráteo como unha resposta a unha pregunta, non como un diagnóstico. Di que familia escolleu este proceso, e nada de nada sobre por que un cliente non pode conectarse.

Como se ve a rama de fallo

Máis adiante, no mesmo código do socket, hai unha rama na que non existe ningún socket. Rexistra a mensaxe máis curta de familia de enderezos e solicita un reinicio, porque non queda nada co que continuar. As palabras iniciais coinciden co retroceso; o resultado non.

Distinga unha da outra polo que segue. Se o daemon segue executándose e informa do seu oínte, a liña era información. Se sae ou se reinicia en bucle, agora a conversa trata do enlace.

Tampouco un acerto de grep identifica a rama. A frase aparece en resumos rotados, en liñas cortadas e en extractos de rexistro que a xente pega de segunda man, así que lea as liñas veciñas e a orde das marcas de tempo en lugar da coincidencia única.

Comprobe o oínte en lugar do aviso

Un servidor en execución responde a pregunta da familia directamente, sen inferencias do texto do rexistro.

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

Faga coincidir a familia, o enderezo e o porto co perfil. Unha liña 0.0.0.0:1194 é só IPv4, mentres que unha liña [::]:1194 nun equipo de dobre pila pode aceptar ambas as familias segundo o axuste bindv6only. Se o perfil di udp e o socket é IPv4, os clientes cuxo resolutor só devolve un rexistro AAAA fallarán antes de que o túnel chegue a negociarse.

Logo probe desde un cliente semellante aos seus usuarios: mesma ruta de resolutor, mesmo tipo de rede. Unha conexión local desde o servidor demostra moi pouco sobre o tráfico que cruza un dispositivo NAT ou unha regra de devasa escrita para a outra familia.

Cando é correcto forzar unha familia

Fixar proto udp4 convén a un despregamento só IPv4: un nome DNS só A, regras de devasa para un enderezo v4, clientes tras operadores que só entregan enderezos v4. Elimina a ambigüidade e fai previsible o seguinte conxunto de liñas do rexistro.

O mesmo argumento funciona ao revés para un contorno con IPv6 primeiro, e udp6 ante unha base de clientes só A é unha caída autoinxerida. Forzar unha familia só para silenciar un aviso inofensivo é a versión clásica deste erro, porque cambiou quen pode conectarse a cambio dun rexistro máis tranquilo.

Escolla a partir dos extremos e dos clientes que deben alcanzalos. O manual de OpenVPN 2.6 documenta as formas de transporte, e a mensaxe é a saída desa escolla, non unha entrada.

Manteña o rexistro estreito

Anote a liña exacta coa súa marca de tempo, o axuste de transporte efectivo do perfil en execución, o socket tal como o informa o núcleo e a seguinte etapa que fallou. Eses catro elementos resolven case todas as preguntas que suscita a mensaxe, e ningún deles precisa adiviñar servizos non relacionados. Tamén sobreviven a un traspaso, cousa que unha captura de pantalla dun grep non fai.

As suxestións de paquetes que chegan xunto a este aviso non teñen relación ata que un erro nomea un executable ausente.

Se ifconfig falta de verdade, o daemon dío polo seu nome cando un script o chama, e iso merece a súa propia investigación. A liña AF_INET e unha utilidade ausente son fallos distintos, e instalar cousas para ver se o aviso cambia é a forma en que un equipo limpo se converte nun desordenado.