OpenVPN AF_INET-Warnung: harmloser Rückfall oder fehlgeschlagener Socket?

Zwei OpenVPN-Protokollzeilen beginnen mit denselben Worten, und nur eine davon meldet ein Problem. Could not determine IPv4/IPv6 protocol. Using AF_INET ist ein Rückfallhinweis: Das Profil ließ die Adressfamilie offen, also wählte der Daemon eine und machte weiter. Der Fehlerzweig meldet, dass kein Socket angelegt wurde, und verlangt einen Neustart. Alles nach dem gemeinsamen Präfix trennt beide, lesen Sie also darüber hinaus, bevor Sie etwas ändern.

Was der Rückfallhinweis meldet

OpenVPN akzeptiert eine ausdrückliche Familie über proto udp4 oder proto udp6 und akzeptiert proto udp, wenn die Familie beim Start abgeleitet werden soll. Im zweiten Fall prüft der Daemon die lokalen Bind-Informationen und wählt.

Wenn diese Ableitung funktioniert, nennt die Warnung die Richtung, und der Prozess fährt mit dem Anlegen des Sockets fort. Ein Server mit proto udp auf einem Dual-Stack-Host landet so recht häufig bei IPv4. Nichts auf diesem Weg ist ein Fehler, und nichts darin deutet auf einen Angriff, einen fehlenden Webserver oder ein abgelehntes Konto hin. Die Zeile ist nur nützlich, weil spätere Prüfungen mit der genannten Familie verglichen werden sollten.

Behandeln Sie sie als Antwort auf eine Frage, nicht als Diagnose. Sie sagt, welche Familie dieser Prozess gewählt hat, und nichts darüber, warum ein Client keine Verbindung aufbauen kann.

Wie der Fehlerzweig aussieht

Später im selben Socket-Code gibt es einen Zweig, in dem überhaupt kein Socket existiert. Er protokolliert die kürzere Adressfamilien-Meldung und fordert einen Neustart an, weil nichts mehr zum Fortsetzen bleibt. Die Anfangsworte stimmen mit dem Rückfall überein; das Ergebnis nicht.

Unterscheiden Sie beide an dem, was folgt. Läuft der Daemon weiter und meldet seinen Listener, war die Zeile eine Information. Beendet er sich oder startet er in einer Schleife neu, geht es jetzt um das Binden.

Auch ein grep-Treffer ist keine Identifikation des Zweigs. Der Ausdruck taucht in rotierten Zusammenfassungen, in umbrochenen Zeilen und in Protokollauszügen auf, die Leute aus zweiter Hand einfügen, lesen Sie also die Nachbarzeilen und die Reihenfolge der Zeitstempel statt des einzelnen Treffers.

Prüfen Sie den Listener statt der Warnung

Ein laufender Server beantwortet die Familienfrage direkt, ohne Schlussfolgerungen aus dem Protokolltext.

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

Vergleichen Sie Familie, Adresse und Port mit dem Profil. Eine 0.0.0.0:1194-Zeile ist nur IPv4, während eine [::]:1194-Zeile auf einem Dual-Stack-Host je nach bindv6only-Einstellung beide Familien annehmen kann. Sagt das Profil udp und ist der Socket IPv4, werden Clients, deren Resolver nur einen AAAA-Eintrag liefert, scheitern, bevor der Tunnel überhaupt ausgehandelt wird.

Testen Sie dann von einem Client aus, der Ihren Nutzern ähnelt: gleicher Resolver-Pfad, gleiche Netzart. Eine lokale Verbindung vom Server beweist sehr wenig über Verkehr, der ein NAT-Gerät oder eine für die andere Familie geschriebene Firewall-Regel passiert.

Wann das Erzwingen einer Familie richtig ist

Das Festschreiben von proto udp4 passt zu einem reinen IPv4-Betrieb: ein DNS-Name nur mit A, Firewall-Regeln für eine v4-Adresse, Clients hinter Anbietern, die nur v4-Adressen vergeben. Es beseitigt Mehrdeutigkeit und macht den nächsten Satz Protokollzeilen vorhersagbar.

Dasselbe Argument gilt umgekehrt für eine Umgebung mit IPv6 an erster Stelle, und udp6 vor einer Clientbasis mit nur A ist ein selbst verursachter Ausfall. Eine Familie nur zu erzwingen, um eine harmlose Warnung zum Schweigen zu bringen, ist die klassische Variante dieses Fehlers, denn Sie haben geändert, wer sich verbinden kann, im Tausch gegen ein ruhigeres Protokoll.

Wählen Sie anhand der Endpunkte und der Clients, die sie erreichen müssen. Das OpenVPN-2.6-Handbuch dokumentiert die Transportformen, und die Meldung ist das Ergebnis dieser Wahl, nicht ihre Eingabe.

Halten Sie den Befund eng

Notieren Sie die genaue Zeile mit ihrem Zeitstempel, die wirksame Transporteinstellung aus dem laufenden Profil, den Socket so, wie der Kernel ihn meldet, und die nächste Stufe, die fehlgeschlagen ist. Diese vier Punkte klären fast jede Frage, die die Meldung aufwirft, und keiner davon verlangt eine Vermutung über unbeteiligte Dienste. Sie überstehen auch eine Übergabe, was ein Screenshot eines grep nicht tut.

Paketvorschläge, die zusammen mit dieser Warnung eintreffen, sind unerheblich, bis ein Fehler eine fehlende ausführbare Datei nennt.

Fehlt ifconfig tatsächlich, nennt der Daemon es beim Namen, wenn ein Skript es aufruft, und das verdient eine eigene Untersuchung. Die AF_INET-Zeile und ein fehlendes Hilfsprogramm sind verschiedene Fehler, und Dinge zu installieren, um zu sehen, ob sich die Warnung ändert, ist der Weg, auf dem ein sauberer Host zu einem unordentlichen wird.