TUN/TAP: neplatný argument — neshoda rámování OpenVPN

Klient se ověří, protokol hlásí připojeno a tunelem neprochází žádný paket. Server ukončí pokus s write to TUN/TAP: Invalid argument (code=22), což vypadá jako závada ovladače a obvykle jí není. Na routerech a malých linuxových serverech tento řádek nejčastěji znamená, že se obě strany neshodnou na tom, jak se datové pakety rámují, takže jádro odmítne dešifrovaný buffer, který mu bylo předáno. Směrování v tomto okamžiku ještě nebylo testováno.

Správná směrovací tabulka a rozbitá dohoda o rámování vypadají z pohledu klienta stejně: připojeno a nic nefunguje.

Tunel se zvedne a nic jím neprochází

Chyby zápisu na zařízení tunelu vznikají po dešifrování a před směrováním. Démon dešifruje paket, předá ho rozhraní a rozhraní ho odmítne, protože buffer neodpovídá tomu, co toto zařízení očekává. Kód 22 je obecná odpověď na neplatný argument, takže užitečná informace je vrstva: jde o datovou cestu, nikoli o handshake. Pokud provoz včera fungoval a dnes se zastavil bez změny konfigurace, podezřívejte aktualizaci balíčku nebo firmwaru, která posunula výchozí hodnotu, dříve než budete podezřívat síť.

Čtěte protokol kolem nastavení datového kanálu, ne první chybu. Vyjednaný režim komprese, typ dev a vynucené volby se všechny objevují při vyšší podrobnosti a říkají vám, kterou ze tří neshod máte.

Komprese je rámování, ne šířka pásma

Když je komprese zapnutá, každý datový paket nese hlavičku popisující, jak byl zakódován, a oba konce se na této hlavičce musí shodnout. Server, který stále nese comp-lzo ze staré ukázkové konfigurace, ve spojení s klientem bez řádku komprese vytváří přesně tuto chybu: server očekává hlavičku, kterou klient nikdy nenapsal. Míchání comp-lzo s compress lz4-v2 selhává stejně, protože algoritmy se liší, i když se oba nazývají komprese. Volba je smlouva o rámování, nikoli funkce šířky pásma na moderních spojích.

Chování verzí přidává past. Řada 2.5 začala vydávat upozornění na zastaralost voleb komprese a 2.6 vede hranici mezi odmítnutím komprimovaných paketů a pouhým ponecháním dat nekomprimovaných. Aktualizace firmwaru routeru tedy může změnit skutečnou dohodu, aniž by někdo upravil tunel.

Slaďte oba konce nebo to z obou odstraňte

Vyjmenujte každou direktivu komprese: soubor serveru, všechny vynucené volby, soubory specifické pro klienta a profil klienta. comp-lzo na serveru potřebuje stejné slovo na klientu a adaptive je zděděná výchozí hodnota, kterou holá volba obvykle znamená u starších sestavení. Přepínač v GUI routeru označený LZO nebo komprese zapisuje tutéž volbu, takže ho nastavte tak, aby odpovídal, místo abyste míchali algoritmy. Nepředpokládejte, že podobně vypadající název je kompatibilní.

Pokud kompresi nechcete, odstraňte ji záměrně z obou konců. allow-compression no na serveru odmítá komprimované pakety, ale teprve poté, co je klienti přestali nabízet; použití ve chvíli, kdy klient stále posílá kompresi, znovu vytvoří neshodu v opačném směru.

Zkontrolujte vynucení a typ zařízení

Server může vynutit direktivu komprese ze svého hlavního souboru nebo ze souboru specifického pro klienta a klient může vynucené volby zahodit pomocí pull-filter. Připojte jednoho klienta s podrobností 4, přečtěte si, co server oznámil, proti tomu, co klient přijal, a pak potvrďte, že to žádný filtr neodstranil. Pokud se obě strany nyní shodují a chyba zůstává, podívejte se na typ zařízení: dev tap na jednom konci a dev tun na druhém si nemohou vyměňovat rámce a jádro zápis odmítne stejně.

Nasazení TAP s mostem vyžaduje skutečný most na serveru, ne jen jiný název zařízení. Přejmenování rozhraní na tap0 bez přidání do mostu vytvoří zařízení, které zápis přijme a nikam nevede.

Pak to ověřte jedním klientem a jedním cílem: pingněte adresu tunelu serveru, potom hostitele v jeho LAN. První prokazuje datový kanál a druhé předávání.