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

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