Истечение cookie ConnMan OpenConnect, а не проблема с сертификатом
В журнале две неисправности выглядят одинаково. Сравните закреплённый отпечаток с cookie сеанса, обновите истёкшее поле и затем перезапустите демон.
ConnMan работает полдня, а затем отказывает, и строка журнала упоминает проверку сертификата. Эта строка отправляет людей к наборам CA, которые никогда не были повреждены. Две разные неисправности дают почти одинаковую форму отказа: истекает cookie сеанса или сертификат сервера действительно изменился. Их можно различить примерно за минуту, и только одна из них вообще связана с отпечатком.
Две неисправности, одна сбивающая с толку строка журнала
Они различаются по двум наблюдениям, и ни одно из них не требует второго прочтения. Первое — когда начался отказ: просроченный cookie приходит после часов или дней работы, а заменённый сертификат приходит сразу после смены шлюза.
| Signal | Expired cookie | Changed certificate |
|---|---|---|
| When it started | after hours or days of working | right after a gateway change |
| Fingerprint from a fresh authenticate | unchanged | different value |
| Usual log tail | HTTP CONNECT 401 / unauthorized | signer not found / verify failed |
| Repair | replace the cookie, restart | re-pin deliberately, then restart |
Проверка на минуту — это запуск authenticate ниже. Сравните его FINGERPRINT с OpenConnect.ServerCert в файле. Совпадающий отпечаток при другом COOKIE означает, что нужно заменить только cookie. Другой отпечаток означает, что сертификат сервера действительно изменился, поэтому закрепите его заново осознанно и запишите, кто это одобрил.
Создавайте материал, а не вводите его вручную
У ConnMan нет шага импорта профиля OpenConnect, в отличие от NetworkManager. Он читает файл подготовки, значения которого должны быть созданы заранее, а поддерживаемый способ их создать — режим authenticate в OpenConnect.
sudo openconnect --csd-wrapper=/home/user/.cisco/csd-wrapper.sh \
--authenticate --user myuser vpn.example.comВывод печатает четыре значения: POST, COOKIE, HOST и FINGERPRINT. Отпечаток с префиксом sha256: — это закрепление сервера. Cookie — артефакт сеанса со сроком жизни, который определяет шлюз. Относитесь к ним как к разным видам секрета: они истекают по разным графикам, и ожидается, что изменится только один.
Файл несёт оба, и они стареют по-разному
Файл подготовки находится в /var/lib/connman-vpn/ и читается для каждого подключения демоном VPN, а не апплетом в системном лотке. Держите имя подключения в глобальной секции, а детали протокола — в секции провайдера.
[global]
Name = Company VPN
[provider_openconnect]
Type = OpenConnect
Name = Company Cisco VPN
Host = vpn.example.com
Domain = corp.example
OpenConnect.ServerCert = sha256:...
OpenConnect.Cookie = ...Используйте то имя хоста, которое портал действительно обслуживает. Голый IP-адрес может пройти проверку сертификата и всё равно не сработать, потому что устройство маршрутизирует по виртуальному хосту и ожидает имя.
systemctl status connman-vpn --no-pager # is the daemon even installed and running
sudo systemctl restart connman-vpn # after the file edit
journalctl -u connman-vpn --since '1 hour ago' # after the connection attemptЧто на самом деле показывает журнал
Подсказка в лотке не скажет, какая у вас неисправность. Журнал скажет, если читать последовательность, а не первую тревожную строку. Устаревший cookie обычно показывает, что согласование TLS завершилось, а уровень HTTP после этого отказал; именно поэтому слова о сертификатах стоят рядом с отказом в авторизации.
Сравните свежий запуск authenticate со значениями в файле. Если отпечаток совпадает и отличается только cookie, ответ у вас есть, не трогая настройки доверия.
Обновите истёкшее поле
Повторите команду authenticate, замените OpenConnect.Cookie и перезапустите демон. Не трогайте отпечаток, если только свежий вывод не показывает другое значение; в этом случае сертификат сервера действительно заменили, и повторное закрепление — это решение, которое кто-то должен записать, а не вставить из сообщения об ошибке.
Автоматизировать обновление разумно: небольшой сценарий читает пароль из стандартного ввода, запускает режим authenticate и переписывает только строку cookie. Держите учётные данные вне сценария и доступными только той учётной записи, которая его запускает, а перезапись делайте атомарной, чтобы неудачный запуск не оставил недописанный файл.
Если обновление нужно каждые несколько часов, запишите интервал. Это свойство политики сеансов шлюза, и оно решает, автоматизировать обновление или просить более длинный сеанс.