Истицање колачића 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 и преписује само линију колачића. Држите акредитиве изван скрипте и читљиве само налогу који је покреће, а преписивање учините атомским да неуспешно покретање не остави пола написане датотеке.
Ако је освежавање потребно сваких неколико сати, запишите интервал. То је својство политике сесија пролаза и одлучује да ли да се освежавање аутоматизује или да се затражи дужа сесија.