TUN/TAP: ungültiges Argument — OpenVPN-Framing stimmt nicht überein

Der Client authentifiziert sich, das Log meldet verbunden, und kein Paket durchquert den Tunnel. Der Server beendet den Versuch mit write to TUN/TAP: Invalid argument (code=22), was wie ein Treiberfehler klingt und es meist nicht ist. Auf Routern und kleinen Linux-Servern bedeutet diese Zeile meist, dass die beiden Gegenstellen uneinig darüber sind, wie Datenpakete geframt werden, sodass der Kernel den entschlüsselten Puffer ablehnt, den er erhalten hat. Das Routing wurde zu diesem Zeitpunkt noch nicht getestet.

Eine korrekte Routing-Tabelle und eine kaputte Framing-Vereinbarung sehen vom Client aus gleich aus: verbunden, und nichts funktioniert.

Der Tunnel kommt hoch und nichts durchquert ihn

Schreibfehler am Tunnelgerät treten nach der Entschlüsselung und vor dem Routing auf. Der Daemon entschlüsselt ein Paket, übergibt es an die Schnittstelle, und die Schnittstelle lehnt es ab, weil der Puffer nicht dem entspricht, was dieses Gerät erwartet. Code 22 ist die allgemeine Antwort auf ein ungültiges Argument, die nützliche Information ist also die Schicht: Das ist der Datenpfad und nicht der Handshake. Wenn der Verkehr gestern lief und heute ohne Konfigurationsänderung stoppt, verdächtigen Sie eine Paket- oder Firmware-Aktualisierung, die einen Standard verschoben hat, bevor Sie das Netzwerk verdächtigen.

Lesen Sie das Log rund um die Einrichtung des Datenkanals statt den ersten Fehler. Der ausgehandelte Komprimierungsmodus, der dev-Typ und die gepushten Optionen erscheinen alle bei höherer Ausführlichkeit, und sie sagen Ihnen, welche der drei Abweichungen Sie haben.

Komprimierung ist Framing, nicht Bandbreite

Bei aktivierter Komprimierung trägt jedes Datenpaket einen Header, der beschreibt, wie es kodiert wurde, und beide Enden müssen sich auf diesen Header einigen. Ein Server, der noch comp-lzo aus einer alten Beispielkonfiguration trägt, zusammen mit einem Client ohne Komprimierungszeile, erzeugt genau diesen Fehler: Der Server erwartet einen Header, den der Client nie geschrieben hat. comp-lzo mit compress lz4-v2 zu mischen scheitert genauso, da sich die Algorithmen unterscheiden, auch wenn beide Komprimierung heißen. Die Option ist ein Framing-Vertrag und kein Bandbreitenmerkmal auf modernen Verbindungen.

Das Versionsverhalten fügt eine Falle hinzu. Die 2.5-Reihe begann, Veraltungswarnungen für Komprimierungsoptionen auszugeben, und 2.6 zieht eine Grenze zwischen dem Ablehnen komprimierter Pakete und dem bloßen Belassen unkomprimierter Daten. Ein Router-Firmware-Update kann daher die wirksame Vereinbarung ändern, ohne dass jemand den Tunnel bearbeitet.

Beide Enden ausrichten oder an beiden entfernen

Zählen Sie jede Komprimierungsdirektive auf: die Serverdatei, alle gepushten Optionen, klientspezifische Dateien und das Client-Profil. comp-lzo auf dem Server braucht dasselbe Wort auf dem Client, und adaptive ist der alte Standard, den die nackte Option in älteren Builds meist bedeutet. Ein GUI-Schalter des Routers mit der Bezeichnung LZO oder Komprimierung schreibt dieselbe Option, stellen Sie ihn also passend ein, statt Algorithmen zu mischen. Nehmen Sie nicht an, dass ein ähnlich aussehender Name kompatibel ist.

Wenn Komprimierung nicht gewünscht ist, entfernen Sie sie bewusst an beiden Enden. allow-compression no auf dem Server lehnt komprimierte Pakete ab, aber erst, nachdem Clients aufgehört haben, sie anzubieten; es anzuwenden, während ein Client noch Komprimierung pusht, erzeugt die Abweichung in der anderen Richtung erneut.

Prüfen Sie den Push und den Gerätetyp

Ein Server kann eine Komprimierungsdirektive aus seiner Hauptdatei oder aus einer klientspezifischen Datei pushen, und ein Client kann gepushte Optionen mit pull-filter verwerfen. Verbinden Sie einen Client bei Ausführlichkeit 4, lesen Sie, was der Server angekündigt hat, gegen das, was der Client akzeptiert hat, und bestätigen Sie dann, dass kein Filter es entfernt hat. Wenn beide Seiten jetzt übereinstimmen und der Fehler bleibt, sehen Sie sich den Gerätetyp an: dev tap an einem Ende und dev tun am anderen können keine Frames austauschen, und der Kernel lehnt das Schreiben genauso ab.

Eine gebrückte TAP-Bereitstellung benötigt eine echte Bridge auf dem Server, nicht nur einen anderen Gerätenamen. Eine Schnittstelle ohne Hinzufügen zu einer Bridge in tap0 umzubenennen, erzeugt ein Gerät, das das Schreiben akzeptiert und nirgendwo hinführt.

Prüfen Sie dann mit einem Client und einem Ziel: Pingen Sie die Tunneladresse des Servers, dann einen Host in dessen LAN. Das erste beweist den Datenkanal und das zweite die Weiterleitung.