TUN/TAP: невалиден аргумент — несъответствие на рамкирането в OpenVPN

Клиентът се удостоверява, журналът казва „свързан“, и нито един пакет не пресича тунела. Сървърът прекратява опита с write to TUN/TAP: Invalid argument (code=22), което изглежда като дефект в драйвера и обикновено не е. На рутери и малки Linux сървъри този ред най-често означава, че двете страни не се разбират как да рамкират пакетите с данни, затова ядрото отхвърля разшифрования буфер, който му е подаден. Маршрутизацията на този етап още не е проверена.

Правилна таблица за маршрутизация и развалено споразумение за рамкиране изглеждат еднакво от страна на клиента: свързано, и нищо не работи.

Тунелът се вдига и нищо не го пресича

Грешките при запис на устройството на тунела се случват след разшифроването и преди маршрутизацията. Демонът разшифрова пакет, подава го на интерфейса, а интерфейсът го отхвърля, защото буферът не съвпада с това, което това устройство очаква. Код 22 е общият отговор за невалиден аргумент, затова полезната информация е слоят: това е пътят на данните, а не ръкостискането. Ако трафикът е вървял вчера и е спрял днес без промяна в конфигурацията, подозирайте актуализация на пакет или фърмуер, която е преместила настройка по подразбиране, преди да подозирате мрежата.

Четете журнала около настройката на канала за данни, а не първата грешка. Договореният режим на компресия, типът dev и изпратените опции се появяват при по-висока подробност и ви казват кое от трите несъответствия имате.

Компресията е рамкиране, не честотна лента

Когато компресията е включена, всеки пакет с данни носи заглавка, описваща как е кодиран, и двете страни трябва да се съгласят за тази заглавка. Сървър, който все още носи comp-lzo от стар примерен конфигурационен файл, съчетан с клиент без ред за компресия, дава точно тази грешка: сървърът очаква заглавка, която клиентът никога не е записал. Смесването на comp-lzo с compress lz4-v2 се проваля по същия начин, тъй като алгоритмите се различават, макар и двата да се наричат компресия. Опцията е договор за рамкиране, а не функция за честотна лента при съвременните връзки.

Поведението на версиите добавя капан. Серията 2.5 започна да издава предупреждения за остаряване на опциите за компресия, а 2.6 поставя граница между отказването на компресирани пакети и простото оставяне на данните некомпресирани. Затова актуализация на фърмуера на рутера може да промени действителното споразумение, без никой да редактира тунела.

Изравнете двата края или го премахнете от двата

Избройте всяка директива за компресия: файла на сървъра, всички изпратени опции, файловете за конкретни клиенти и профила на клиента. comp-lzo на сървъра изисква същата дума на клиента, а adaptive е наследствената стойност по подразбиране, която голата опция обикновено означава при по-стари сборки. Превключвателят в GUI на рутера с етикет LZO или компресия записва същата опция, затова го настройте да съвпада, вместо да смесвате алгоритми. Не предполагайте, че подобно име е съвместимо.

Ако компресията не е желана, премахнете я умишлено от двата края. allow-compression no на сървъра отхвърля компресирани пакети, но само след като клиентите са спрели да ги предлагат; прилагането му, докато клиент все още изпраща компресия, пресъздава несъответствието в обратната посока.

Проверете изпращането и типа на устройството

Сървърът може да изпрати директива за компресия от основния си файл или от файл за конкретен клиент, а клиентът може да отхвърли изпратени опции с pull-filter. Свържете един клиент при подробност 4, прочетете какво е обявил сървърът спрямо какво е приел клиентът, след което потвърдете, че нито един филтър не го е премахнал. Ако двете страни вече са съгласни, а грешката остава, вижте типа на устройството: dev tap в единия край и dev tun в другия не могат да обменят кадри и ядрото отхвърля записа по същия начин.

Разгръщане на TAP с мост изисква действителен мост на сървъра, а не само различно име на устройство. Преименуването на интерфейс на tap0 без добавянето му към мост създава устройство, което приема записа и не отива никъде.

След това проверете с един клиент и една дестинация: пуснете ping към адреса на тунела на сървъра, после към хост в неговата LAN. Първото доказва канала за данни, а второто — препращането.