TUN/TAP: neplatný argument — nesúlad rámcovania OpenVPN

Klient sa overí, protokol hlási pripojené a tunelom neprechádza žiadny paket. Server ukončí pokus s write to TUN/TAP: Invalid argument (code=22), čo vyzerá ako porucha ovládača a zvyčajne ňou nie je. Na routeroch a malých linuxových serveroch tento riadok najčastejšie znamená, že sa obe strany nezhodujú na tom, ako sa dátové pakety rámcujú, takže jadro odmietne dešifrovaný buffer, ktorý mu bol odovzdaný. Smerovanie v tom okamihu ešte nebolo testované.

Správna smerovacia tabuľka a rozbitá dohoda o rámcovaní vyzerajú z pohľadu klienta rovnako: pripojené a nič nefunguje.

Tunel sa zdvihne a nič ním neprechádza

Chyby zápisu na zariadení tunela vznikajú po dešifrovaní a pred smerovaním. Démon dešifruje paket, odovzdá ho rozhraniu a rozhranie ho odmietne, pretože buffer nezodpovedá tomu, čo toto zariadenie očakáva. Kód 22 je všeobecná odpoveď na neplatný argument, takže užitočná informácia je vrstva: ide o dátovú cestu, nie o handshake. Ak premávka včera fungovala a dnes sa zastavila bez zmeny konfigurácie, podozrievajte aktualizáciu balíka alebo firmvéru, ktorá posunula predvolenú hodnotu, skôr než budete podozrievať sieť.

Čítajte protokol okolo nastavenia dátového kanála namiesto prvú chybu. Vyjednaný režim kompresie, typ dev a vynútené voľby sa všetky objavujú pri vyššej podrobnosti a hovoria vám, ktorý z troch nesúladov máte.

Kompresia je rámcovanie, nie šírka pásma

Keď je kompresia zapnutá, každý dátový paket nesie hlavičku popisujúcu, ako bol zakódovaný, a oba konce sa na tejto hlavičke musia zhodnúť. Server, ktorý stále nesie comp-lzo zo starej ukážkovej konfigurácie, v spojení s klientom bez riadku kompresie vytvára presne túto chybu: server očakáva hlavičku, ktorú klient nikdy nenapísal. Miešanie comp-lzo s compress lz4-v2 zlyháva rovnako, pretože algoritmy sa líšia, aj keď sa oba nazývajú kompresia. Voľba je zmluva o rámcovaní, nie funkcia šírky pásma na moderných spojeniach.

Správanie verzií pridáva pascu. Séria 2.5 začala vydávať upozornenia na zastaranosť volieb kompresie a 2.6 vedie hranicu medzi odmietnutím komprimovaných paketov a jednoduchým ponechaním dát nekomprimovaných. Aktualizácia firmvéru routera preto môže zmeniť skutočnú dohodu bez toho, aby niekto upravil tunel.

Zosúlaďte oba konce alebo to z oboch odstráňte

Vymenujte každú direktívu kompresie: súbor servera, všetky vynútené voľby, súbory špecifické pre klienta a profil klienta. comp-lzo na serveri potrebuje to isté slovo na klientovi a adaptive je zdedená predvolená hodnota, ktorú holá voľba zvyčajne znamená v starších zostaveniach. Prepínač v GUI routera označený LZO alebo kompresia zapisuje tú istú voľbu, takže ho nastavte tak, aby zodpovedal, namiesto miešania algoritmov. Nepredpokladajte, že podobne vyzerajúci názov je kompatibilný.

Ak kompresiu nechcete, odstráňte ju zámerne z oboch koncov. allow-compression no na serveri odmieta komprimované pakety, ale až po tom, čo ich klienti prestali ponúkať; použitie v čase, keď klient stále posiela kompresiu, znovu vytvorí nesúlad v opačnom smere.

Skontrolujte vynútenie a typ zariadenia

Server môže vynútiť direktívu kompresie zo svojho hlavného súboru alebo zo súboru špecifického pre klienta a klient môže vynútené voľby zahodiť pomocou pull-filter. Pripojte jedného klienta s podrobnosťou 4, prečítajte si, čo server oznámil, proti tomu, čo klient prijal, a potom potvrďte, že to žiadny filter neodstránil. Ak sa obe strany teraz zhodujú a chyba pretrváva, pozrite sa na typ zariadenia: dev tap na jednom konci a dev tun na druhom si nemôžu vymieňať rámce a jadro zápis odmietne rovnako.

Nasadenie TAP s mostom vyžaduje skutočný most na serveri, nie len iný názov zariadenia. Premenovanie rozhrania na tap0 bez pridania do mosta vytvorí zariadenie, ktoré zápis prijme a nikam nevedie.

Potom to overte jedným klientom a jedným cieľom: pingnite adresu tunela servera, potom hostiteľa v jeho LAN. Prvé preukazuje dátový kanál a druhé preposielanie.