Avertissement AF_INET d'OpenVPN : repli inoffensif ou socket en échec ?

Deux lignes du journal d'OpenVPN commencent par les mêmes mots, et une seule d'entre elles signale un problème. Could not determine IPv4/IPv6 protocol. Using AF_INET est un avis de repli : le profil a laissé la famille d'adresses ouverte, le démon en a choisi une et a continué. La branche d'échec indique qu'aucun socket n'a été créé et demande un redémarrage. Tout ce qui suit le préfixe commun les sépare, alors lisez au-delà avant de changer quoi que ce soit.

Ce que signale l'avis de repli

OpenVPN accepte une famille explicite via proto udp4 ou proto udp6, et accepte proto udp lorsque la famille doit être déduite au démarrage. Dans le second cas, le démon examine les informations de liaison locales et choisit.

Lorsque cette déduction fonctionne, l'avertissement indique dans quel sens elle est allée et le processus poursuit la création du socket. Un serveur avec proto udp sur un hôte à double pile aboutit ainsi à IPv4 assez souvent. Rien dans ce chemin n'est une erreur, et rien n'y laisse entendre une attaque, un serveur web manquant ou un compte rejeté. La ligne n'est utile que parce que les vérifications ultérieures devraient être comparées à la famille qu'elle nomme.

Traitez-la comme une réponse à une question, non comme un diagnostic. Elle dit quelle famille ce processus a choisie, et rien du tout sur la raison pour laquelle un client ne peut pas se connecter.

À quoi ressemble la branche d'échec

Plus loin dans le même code de socket, il existe une branche où aucun socket n'existe. Elle journalise le message plus court de famille d'adresses et demande un redémarrage, car il ne reste rien pour continuer. Les mots d'ouverture correspondent au repli ; le résultat non.

Distinguez-les par ce qui suit. Si le démon continue de tourner et signale son écouteur, la ligne était une information. S'il sort ou redémarre en boucle, la conversation porte désormais sur la liaison.

Une occurrence dans grep n'est pas non plus une identification de branche. La phrase apparaît dans des résumés rotatifs, dans des lignes coupées et dans des extraits de journal que les gens collent de seconde main, alors lisez les lignes voisines et l'ordre des horodatages plutôt que la correspondance unique.

Vérifiez l'écouteur plutôt que l'avertissement

Un serveur en fonctionnement répond directement à la question de la famille, sans inférence à partir du texte du journal.

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

Faites correspondre la famille, l'adresse et le port au profil. Une ligne 0.0.0.0:1194 est IPv4 seulement, tandis qu'une ligne [::]:1194 sur un hôte à double pile peut accepter les deux familles selon le réglage bindv6only. Si le profil indique udp et que le socket est IPv4, les clients dont le résolveur ne renvoie qu'un enregistrement AAAA échoueront avant même que le tunnel ne soit négocié.

Testez ensuite depuis un client semblable à vos utilisateurs : même chemin de résolveur, même type de réseau. Une connexion locale depuis le serveur prouve très peu de choses sur le trafic qui traverse un appareil NAT ou une règle de pare-feu écrite pour l'autre famille.

Quand forcer une famille est justifié

Épingler proto udp4 convient à un déploiement IPv4 uniquement : un nom DNS de type A seulement, des règles de pare-feu pour une adresse v4, des clients derrière des opérateurs qui n'attribuent que des adresses v4. Cela supprime l'ambiguïté et rend la série suivante de lignes de journal prévisible.

Le même argument vaut dans l'autre sens pour un environnement IPv6 d'abord, et udp6 devant une base de clients de type A seulement est une panne auto-infligée. Forcer une famille uniquement pour faire taire un avertissement inoffensif est la version classique de cette erreur, car vous avez changé qui peut se connecter en échange d'un journal plus calme.

Choisissez d'après les extrémités et les clients qui doivent les atteindre. Le manuel d'OpenVPN 2.6 documente les formes de transport, et le message est la sortie de ce choix, non une entrée.

Gardez la trace étroite

Notez la ligne exacte avec son horodatage, le réglage de transport effectif du profil en cours, le socket tel que le noyau le signale et l'étape suivante qui a échoué. Ces quatre éléments règlent presque toutes les questions que le message soulève, et aucun n'exige de supposition sur des services sans rapport. Ils survivent aussi à une passation, ce qu'une capture d'écran d'un grep ne fait pas.

Les suggestions de paquets qui arrivent avec cet avertissement sont sans rapport tant qu'une erreur ne nomme pas un exécutable manquant.

Si ifconfig manque réellement, le démon le dit par son nom lorsqu'un script l'appelle, et cela mérite sa propre enquête. La ligne AF_INET et un utilitaire manquant sont des échecs différents, et installer des choses pour voir si l'avertissement change est la façon dont un hôte propre devient désordonné.