Duas linhas do registo do OpenVPN começam com as mesmas palavras, e apenas uma delas relata um problema. Could not determine IPv4/IPv6 protocol. Using AF_INET é um aviso de fallback: o perfil deixou a família de endereços aberta, por isso o daemon escolheu uma e continuou. O ramo de falha relata que nenhum socket foi criado e pede um reinício. Tudo depois do prefixo comum separa as duas, por isso leia para além dele antes de mudar alguma coisa.

O que o aviso de fallback relata

O OpenVPN aceita uma família explícita através de proto udp4 ou proto udp6, e aceita proto udp quando a família deve ser derivada no arranque. No segundo caso o daemon inspeciona a informação de ligação local e escolhe.

Quando essa derivação funciona, o aviso indica a direção seguida e o processo continua a criar o socket. Um servidor com proto udp num anfitrião de pilha dupla acaba assim em IPv4 com bastante frequência. Nada nesse caminho é erro, e nada nele sugere um ataque, um servidor web em falta ou uma conta rejeitada. A linha só é útil porque as verificações posteriores devem ser comparadas com a família que ela nomeia.

Trate-a como resposta a uma pergunta, não como diagnóstico. Diz qual família este processo escolheu, e nada sobre por que um cliente não consegue ligar-se.

Como é o ramo de falha

Mais adiante no mesmo código do socket há um ramo em que não existe socket nenhum. Regista a mensagem mais curta de família de endereços e pede um reinício, porque não resta nada com que continuar. As palavras iniciais coincidem com o fallback; o resultado não.

Distinga-os pelo que vem a seguir. Se o daemon continuar a correr e relatar o seu ouvinte, a linha era informação. Se sair ou reiniciar em ciclo, a conversa passa a ser sobre a ligação.

Também um achado do grep não identifica o ramo. A frase aparece em resumos rotativos, em linhas quebradas e em excertos de registo que as pessoas colam em segunda mão, por isso leia as linhas vizinhas e a ordem das marcas temporais em vez da correspondência única.

Verifique o ouvinte em vez do aviso

Um servidor em execução responde à pergunta da família diretamente, sem inferências a partir do texto do registo.

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

Compare a família, o endereço e a porta com o perfil. Uma linha 0.0.0.0:1194 é apenas IPv4, enquanto uma linha [::]:1194 num anfitrião de pilha dupla pode aceitar as duas famílias consoante a definição bindv6only. Se o perfil disser udp e o socket for IPv4, os clientes cujo resolver devolve apenas um registo AAAA falharão antes de o túnel chegar a ser negociado.

Depois teste a partir de um cliente semelhante aos seus utilizadores: mesmo caminho de resolver, mesmo tipo de rede. Uma ligação local a partir do servidor prova muito pouco sobre tráfego que atravessa um dispositivo NAT ou uma regra de firewall escrita para a outra família.

Quando forçar uma família é correto

Fixar proto udp4 adequa-se a uma implantação só IPv4: um nome DNS só com A, regras de firewall para um endereço v4, clientes atrás de operadoras que só atribuem endereços v4. Elimina a ambiguidade e torna o conjunto seguinte de linhas do registo previsível.

O mesmo argumento funciona ao contrário para um ambiente com IPv6 primeiro, e udp6 à frente de uma base de clientes só A é uma interrupção autoinfligida. Forçar uma família só para silenciar um aviso inofensivo é a versão clássica deste erro, porque mudou quem se pode ligar em troca de um registo mais calmo.

Escolha a partir dos pontos finais e dos clientes que têm de os alcançar. O manual do OpenVPN 2.6 documenta as formas de transporte, e a mensagem é a saída dessa escolha, não uma entrada.

Mantenha o registo estreito

Anote a linha exata com a sua marca temporal, a configuração de transporte efetiva do perfil em execução, o socket tal como o kernel o relata e a etapa seguinte que falhou. Esses quatro elementos resolvem quase todas as perguntas que a mensagem levanta, e nenhum deles exige adivinhar serviços não relacionados. Sobrevivem também a uma passagem de testemunho, o que uma captura de ecrã de um grep não faz.

As sugestões de pacotes que chegam juntamente com este aviso não têm relação até um erro nomear um executável em falta.

Se ifconfig faltar mesmo, o daemon diz o nome quando um script o chama, e isso merece uma investigação própria. A linha AF_INET e um utilitário em falta são falhas diferentes, e instalar coisas para ver se o aviso muda é a forma como um anfitrião limpo se torna desarrumado.

Artigos relacionados