Kerio у Linux: дати kvnet MAC, якого чекає сервер

Три речі мають збігтися, перш ніж тунель Kerio почне пропускати трафік: адреса на інтерфейсі kvnet, значення, яке записав клієнт, і те, чого чекає політика сервера або DHCP. Коли вони не збігаються, тунель усе одно проходить автентифікацію і все одно піднімається, і саме це робить збій заплутаним. Інтерфейс створюється при кожному підключенні, тому адреса, задана вручну, належить лише цьому сеансу й нічому більше. Така форма проблеми, а рішення — це хук, а не файл конфігурації. Решта — де читати значення і де його застосовувати.

Чому адреса постійно повертається

kvnet — це віртуальний адаптер, який клієнт створює на початку підключення і видаляє після його завершення. Тому ручний ip link set живе рівно стільки, скільки триває сеанс, до якого його застосовано, а наступне підключення починається з того, що призначить клієнт. На машині, де клієнт не може застосувати очікувану адресу, кожне перепідключення знову вносить ту саму невідповідність, і правило оренди або доступу знову відхиляє пристрій.

Ця закономірність сама по собі діагностична. Тунель, який працює один сеанс і зривається на наступному, не є проблемою облікових даних, бо облікові дані між підключеннями не змінюються.

Читайте значення у клієнта, а не в інтерфейсу

Клієнт Linux записує подробиці узгодження у свій журнал налагодження, і адреса, яку він має намір використати, з'являється там як останній токен у формі адреси в послідовності підключення. Порівняйте це з тим, що насправді тримає ядро, а це на один readlink далі: cat /sys/class/net/kvnet/address.

Якщо вони різняться, клієнт знав правильне значення і не зміг його застосувати, а хук, який застосовує його після появи інтерфейсу, закриває цю прогалину. Якщо в журналі взагалі немає адреси, проблема раніша й належить до версії клієнта або профілю сервера, а не до скрипту.

Застосуйте його після появи інтерфейсу

Користувачі NetworkManager можуть покласти скрипт у його каталог диспетчера і діяти лише тоді, коли інтерфейс VPN піднімається. Клієнт під керуванням systemd потребує більшої обачності: drop-in, який запускається на старті служби, зазвичай спрацьовує раніше, ніж з'являється адаптер, тому хук має чекати на інтерфейс, а не припускати його. Задайте адресу тоді, і якщо ядро відмовить, поки з'єднання підняте, опустіть його, задайте адресу і підніміть знову. Прочитайте витягнутий токен назад через шаблон MAC, перш ніж передати його в ip link, щоб неочікуваний рядок журналу не міг стати аргументом.

Усе, що виконується як root із журналу клієнта, заслуговує на вузьке володіння: файл, що належить root, недоступний для запису іншим і без інтерполяції оболонки понад перевірену адресу. Тримайте перевірку шаблону всередині скрипту. Не дозволяйте вмісту журналу вирішувати, яка команда виконується.

Перевіряйте оренду, а не з'єднання

ip -4 -o addr show dev kvnet має показати адресу в очікуваному діапазоні, ip neigh show dev kvnet має показати шлюз, а одна служба за VPN має відповісти. Потім відключіться і один раз підключіться знову; якщо адреса повертається, хук спрацьовує на неправильну подію або не спрацьовує взагалі.

Інтерфейс, який з'являється з правильною адресою і ніколи не отримує оренду, вказує на бік сервера. Це інша перевірка і зазвичай інша команда. Підтвердьте, що обліковий запис дозволено і що пул ще має адресу, перш ніж знову правити хук.

Перегляньте обхідний шлях після оновлення

Збірка клієнта, яка правильно задає адресу, залишає ваш хук застосовувати застаріле значення, а це нова несправність, внесена виправленням. Також ніколи не копіюйте MAC з іншої машини чи допису на форумі; використовуйте значення, яке цей клієнт записує для цього облікового запису, і занотуйте дату, коли ви його перевірили.

Тримайте скрипт достатньо коротким, щоб прочитати його за один присід. Обхідні шляхи, що розбирають журнали, за своєю природою тимчасові. Виживають ті, які майбутній читач зрозуміє без початкової теми.