Клієнт проходить автентифікацію, журнал повідомляє «підключено», і жоден пакет не проходить через тунель. Сервер завершує спробу з 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 адреси тунелю сервера, потім хоста в його локальній мережі. Перше доводить канал даних, а друге — пересилання.

Схожі статті