TUN/TAP: érvénytelen argumentum — OpenVPN-keretezési eltérés

Az ügyfél hitelesít, a napló azt írja, csatlakozva, és egyetlen csomag sem halad át az alagúton. A kiszolgáló write to TUN/TAP: Invalid argument (code=22) üzenettel fejezi be a kísérletet, ami illesztőprogram-hibának tűnik, és általában nem az. Az útválasztókon és kis Linux-kiszolgálókon ez a sor leggyakrabban azt jelenti, hogy a két fél nem ért egyet abban, hogyan keretezik az adatcsomagokat, ezért a kernel elutasítja a kapott visszafejtett puffert. Az útválasztást ezen a ponton még nem tesztelték.

A helyes útválasztási tábla és a hibás keretezési megállapodás az ügyfél felől ugyanúgy néz ki: csatlakozva, és semmi sem működik.

Az alagút feljön, és semmi sem halad át rajta

Az alagút-eszközön fellépő írási hibák a visszafejtés után és az útválasztás előtt történnek. A démon visszafejt egy csomagot, átadja a felületnek, és a felület elutasítja, mert a puffer nem egyezik azzal, amit az az eszköz elvár. A 22-es kód az érvénytelen argumentum általános válasza, ezért a hasznos információ a réteg: ez az adatútvonal, és nem a kézfogás. Ha a forgalom tegnap működött, és ma konfigurációmódosítás nélkül leállt, gyanakodjon egy csomag- vagy firmware-frissítésre, amely elmozdított egy alapértelmezett értéket, mielőtt a hálózatra gyanakodna.

Az első hiba helyett az adatcsatorna beállítása körüli naplót olvassa. Az egyeztetett tömörítési mód, a dev típus és a továbbított beállítások mind nagyobb részletességnél jelennek meg, és megmondják, melyik a három eltérés közül.

A tömörítés keretezés, nem sávszélesség

Ha a tömörítés engedélyezett, minden adatcsomag hordoz egy fejlécet, amely leírja, hogyan kódolták, és mindkét végnek meg kell egyeznie ebben a fejlécben. Egy kiszolgáló, amely még comp-lzo beállítást hordoz egy régi mintakonfigurációból, párosítva egy ügyféllel, amelynek nincs tömörítési sora, pontosan ezt a hibát eredményezi: a kiszolgáló olyan fejlécet vár, amelyet az ügyfél soha nem írt. A comp-lzo és a compress lz4-v2 keverése ugyanígy meghiúsul, mivel az algoritmusok eltérnek, bár mindkettőt tömörítésnek nevezik. A beállítás keretezési szerződés, nem sávszélesség-funkció a modern kapcsolatokon.

A verziók viselkedése csapdát rejt. A 2.5 sorozat elkezdte az elavulási figyelmeztetéseket kiadni a tömörítési beállításokhoz, és a 2.6 határt húz a tömörített csomagok elutasítása és az adatok tömörítetlenül hagyása között. Ezért az útválasztó firmware-frissítése megváltoztathatja a tényleges megállapodást anélkül, hogy bárki szerkesztené az alagutat.

Igazítsa össze mindkét végét, vagy távolítsa el mindkettőből

Sorolja fel az összes tömörítési direktívát: a kiszolgálófájlt, az esetleges továbbított beállításokat, az ügyfélspecifikus fájlokat és az ügyfélprofilt. A kiszolgálón a comp-lzo ugyanazt a szót igényli az ügyfélen, és a adaptive az a régi alapértelmezés, amelyet a csupasz beállítás a régebbi buildekben általában jelent. Az útválasztó LZO vagy tömörítés címkével ellátott GUI-kapcsolója ugyanazt a beállítást írja, ezért állítsa egyezésre ahelyett, hogy algoritmusokat keverne. Ne feltételezze, hogy egy hasonló nevű kompatibilis.

Ha a tömörítés nem kívánatos, távolítsa el szándékosan mindkét végről. A kiszolgálón a allow-compression no elutasítja a tömörített csomagokat, de csak miután az ügyfelek abbahagyták azok felajánlását; ha olyankor alkalmazzák, amikor egy ügyfél még továbbítja a tömörítést, az eltérés a másik irányban újra létrejön.

Ellenőrizze a továbbítást és az eszköz típusát

A kiszolgáló továbbíthat egy tömörítési direktívát a fő fájljából vagy egy ügyfélspecifikus fájlból, és az ügyfél a továbbított beállításokat a pull-filter használatával eldobhatja. Csatlakoztasson egy ügyfelet 4-es részletességen, olvassa el, mit hirdetett a kiszolgáló ahhoz képest, amit az ügyfél elfogadott, majd erősítse meg, hogy semmilyen szűrő nem távolította el. Ha mindkét oldal most egyetért, és a hiba megmarad, nézze meg az eszköz típusát: a dev tap az egyik végén és a dev tun a másikon nem tud kereteket cserélni, és a kernel ugyanígy elutasítja az írást.

A hidalt TAP-telepítéshez valódi híd kell a kiszolgálón, nemcsak egy másik eszköznév. Ha egy felületet tap0 névre nevez át anélkül, hogy hídhoz adná, olyan eszközt kap, amely elfogadja az írást, és sehová sem jut.

Ezután ellenőrizze egy ügyféllel és egy céllal: pingelje a kiszolgáló alagút-címét, majd egy hosztot a LAN-ján. Az első az adatcsatornát bizonyítja, a második a továbbítást.