Изтичане на бисквитката на ConnMan OpenConnect, а не проблем със сертификата
Две повреди изглеждат еднакво в журнала. Сравнете закрепения отпечатък с бисквитката на сесията, обновете полето, чийто срок изтече, и рестартирайте демона.
ConnMan работи един следобед и после отказва, а редът в журнала споменава проверка на сертификат. Този ред праща хората към CA пакети, които никога не са били счупени. Две различни повреди дават почти същата форма на отказ: бисквитката на сесията изтича или сертификатът на сървъра наистина се е сменил. Различават се за около минута и само една от тях изобщо включва отпечатъка.
Две повреди, един объркващ ред в журнала
Различават се по две наблюдения и нито едно от тях не изисква втори прочит. Първото е кога е започнал отказът: изтекла бисквитка идва след часове или дни работа, а сменен сертификат идва веднага след смяна на шлюза.
| 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 означава да смените само бисквитката. Различен отпечатък означава, че сертификатът на сървъра наистина се е сменил, затова го закрепете наново умишлено и запишете кой е одобрил това.
Генерирайте материала, вместо да го въвеждате
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: е закрепването на сървъра. Бисквитката е артефактът на сесията с живот, който шлюзът определя. Отнасяйте се към тях като към различни видове тайни: изтичат по различен график и само една от тях се очаква да се промени.
Файлът носи и двете и те остаряват различно
Файлът за осигуряване се намира под /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Какво всъщност показва журналът
Подсказката в системната област няма да каже коя повреда имате. Журналът ще го направи, ако четете последователността, а не първия тревожен ред. Остаряла бисквитка обикновено показва, че TLS договарянето завършва, а HTTP слоят отхвърля след това — затова думите за сертификати стоят до отказ при оторизация.
Сравнете ново изпълнение на authenticate със стойностите във файла. Ако отпечатъкът съвпада и се различава само бисквитката, имате отговора, без да пипате настройките за доверие.
Обновете полето, чийто срок изтече
Повторете командата authenticate, заменете OpenConnect.Cookie и рестартирайте демона. Не пипайте отпечатъка, освен ако новият изход не показва различна стойност; в такъв случай сертификатът на сървъра наистина е бил сменен и повторното закрепване е решение, което някой трябва да запише, а не паста от съобщение за грешка.
Автоматизирането на обновяването е разумно: малък скрипт чете паролата от стандартния вход, изпълнява режим authenticate и пренаписва само реда с бисквитката. Дръжте удостоверението извън скрипта и четливо само за акаунта, който го изпълнява, а пренаписването правете атомарно, за да не остави неуспешно изпълнение недовършен файл.
Ако обновяването е нужно на всеки няколко часа, запишете интервала. Това е свойство на политиката за сесии на шлюза и решава дали да автоматизирате обновяването, или да поискате по-дълга сесия.