Закінчення терміну cookie ConnMan OpenConnect, а не проблема із сертифікатом

ConnMan працює півдня, а потім відмовляє, і рядок журналу згадує перевірку сертифіката. Цей рядок відправляє людей до наборів CA, які ніколи не були пошкоджені. Дві різні несправності дають майже однакову форму відмови: термін cookie сеансу закінчується або сертифікат сервера справді змінився. Їх можна розрізнити приблизно за хвилину, і лише одна з них узагалі стосується відбитка.

Дві несправності, один заплутаний рядок журналу

Вони розрізняються за двома спостереженнями, і жодне не потребує другого прочитання. Перше — коли почалася відмова: прострочений cookie приходить після годин або днів роботи, а замінений сертифікат приходить одразу після зміни шлюзу.

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

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