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 — гэта спадчыннае значэнне па змаўчанні, якое звычайна азначае голы параметр у старых зборках. Перамыкач графічнага інтэрфейсу маршрутызатара з пазнакай LZO або сцісканне запісвае той жа параметр, таму ўсталюйце яго адпаведна, а не змешвайце алгарытмы. Не мяркуйце, што падобная назва сумяшчальная.

Калі сцісканне не патрэбна, выдаліце яго свядома з абодвух бакоў. allow-compression no на серверы адмаўляе сціснутыя пакеты, але толькі пасля таго, як кліенты перасталі іх прапаноўваць; ужыванне яго, пакуль кліент яшчэ штурхае сцісканне, зноў стварае несупадзенне ў іншы бок.

Праверце прасоўванне і тып прылады

Сервер можа прасоўваць дырэктыву сціскання са свайго асноўнага файла або з файла для канкрэтнага кліента, а кліент можа адкідаць прасунутыя параметры з дапамогай pull-filter. Падключыце адзін кліент пры шматслоўнасці 4, прачытайце, што абвясціў сервер, у параўнанні з тым, што прыняў кліент, потым пацвердзіце, што фільтр не выдаліў гэта. Калі абодва бакі цяпер згодныя, а памылка застаецца, паглядзіце на тып прылады: dev tap на адным баку і dev tun на другім не могуць абменьвацца кадрамі, і ядро адхіляе запіс гэтак жа.

Разгортванне TAP з мастом патрабуе сапраўднага маста на серверы, а не проста іншай назвы прылады. Перайменаванне інтэрфейса ў tap0 без дадання яго ў мост стварае прыладу, якая прымае запіс і нікуды не ідзе.

Потым праверце адным кліентам і адным пунктам прызначэння: запінгвайце адрас тунеля сервера, потым хост у яго лакальнай сетцы. Першае даказвае канал даных, а другое — перасылку.