Wygaśnięcie pliku cookie ConnMan OpenConnect, a nie problem z certyfikatem

ConnMan działa przez popołudnie, a potem odmawia, a wiersz dziennika wspomina weryfikację certyfikatu. Ten wiersz kieruje ludzi do pakietów CA, które nigdy nie były zepsute. Dwa różne błędy dają niemal taki sam kształt awarii: wygasa plik cookie sesji albo certyfikat serwera naprawdę się zmienił. Można je rozróżnić w około minutę, i tylko jeden z nich w ogóle dotyczy odcisku palca.

Dwa błędy, jeden mylący wiersz dziennika

Różnią się pod dwoma względami, z których żaden nie wymaga drugiego czytania. Pierwszy to moment rozpoczęcia awarii: wygasły plik cookie pojawia się po godzinach lub dniach pracy, a wymieniony certyfikat pojawia się zaraz po zmianie bramy.

Test minutowy to uruchomienie authenticate poniżej. Porównaj jego FINGERPRINT z OpenConnect.ServerCert w pliku. Identyczny odcisk palca z innym COOKIE oznacza wymianę tylko pliku cookie. Inny odcisk palca oznacza, że certyfikat serwera naprawdę się zmienił, więc przypnij go świadomie ponownie i zapisz, kto to zatwierdził.

Wygeneruj materiał zamiast go wpisywać

ConnMan nie ma kroku importu profilu OpenConnect, w przeciwieństwie do NetworkManagera. Czyta plik przygotowania, którego wartości trzeba wytworzyć wcześniej, a obsługiwanym sposobem ich wytworzenia jest tryb authenticate OpenConnect.

sudo openconnect --csd-wrapper=/home/user/.cisco/csd-wrapper.sh \
  --authenticate --user myuser vpn.example.com

Wyjście drukuje cztery wartości: POST, COOKIE, HOST i FINGERPRINT. Odcisk palca z prefiksem sha256: to przypięcie serwera. Plik cookie to artefakt sesji o czasie życia, który ustala brama. Traktuj je jako różne rodzaje sekretu: wygasają według różnych harmonogramów i tylko jeden powinien się zmieniać.

Plik zawiera oba, i starzeją się różnie

Plik przygotowania znajduje się w /var/lib/connman-vpn/ i jest czytany dla każdego połączenia przez usługę VPN, a nie przez aplet zasobnika. Trzymaj nazwę połączenia w sekcji globalnej, a szczegóły protokołu w sekcji dostawcy.

[global]
Name = Company VPN

[provider_openconnect]
Type = OpenConnect
Name = Company Cisco VPN
Host = vpn.example.com
Domain = corp.example
OpenConnect.ServerCert = sha256:...
OpenConnect.Cookie = ...

Używaj nazwy hosta, którą portal naprawdę obsługuje. Sam adres IP może przejść kontrolę certyfikatu i mimo to zawieść, bo urządzenie kieruje ruchem według hosta wirtualnego i oczekuje nazwy.

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

Co dziennik naprawdę pokazuje

Podpowiedź w zasobniku nie powie, który to błąd. Dziennik powie, jeśli czytasz sekwencję, a nie pierwszy alarmujący wiersz. Nieświeży plik cookie zwykle pokazuje, że negocjacja TLS się zakończyła, a warstwa HTTP następnie odrzuciła żądanie; dlatego słowa o certyfikatach stoją obok niepowodzenia autoryzacji.

Porównaj świeże uruchomienie authenticate z wartościami w pliku. Jeśli odcisk palca się zgadza i różni się tylko plik cookie, masz odpowiedź bez dotykania ustawień zaufania.

Odśwież wygasłe pole

Powtórz polecenie authenticate, zastąp OpenConnect.Cookie i uruchom ponownie usługę. Zostaw odcisk palca w spokoju, chyba że świeże wyjście pokazuje inną wartość; wtedy certyfikat serwera naprawdę wymieniono, a ponowne przypięcie jest decyzją, którą ktoś powinien zapisać, a nie wklejeniem z komunikatu o błędzie.

Automatyzacja odświeżania jest rozsądna: mały skrypt czyta hasło ze standardowego wejścia, uruchamia tryb authenticate i przepisuje tylko wiersz pliku cookie. Trzymaj dane logowania poza skryptem i czytelne tylko dla konta, które go uruchamia, a przepisywanie wykonuj atomowo, żeby nieudane uruchomienie nie zostawiło połowicznie zapisanego pliku.

Jeśli odświeżanie jest potrzebne co kilka godzin, zapisz ten interwał. To właściwość polityki sesji bramy i decyduje, czy automatyzować odświeżanie, czy prosić o dłuższą sesję.