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 без добавления его в мост создаёт устройство, которое принимает запись и никуда не идёт.

Затем проверьте одним клиентом и одним адресатом: выполните ping адреса туннеля сервера, затем хоста в его локальной сети. Первое доказывает канал данных, а второе — пересылку.