ConnMan OpenConnect 쿠키 만료이지 인증서 문제가 아닙니다

로그에서는 두 고장이 똑같아 보입니다. 고정된 지문을 세션 쿠키와 비교하고, 만료된 항목을 갱신한 뒤 데몬을 다시 시작하십시오.

ConnMan은 반나절쯤 동작하다가 거부하고, 저널 줄은 인증서 검증을 언급합니다. 그 한 줄이 사람들을 한 번도 깨진 적 없는 CA 번들로 보냅니다. 서로 다른 두 고장이 거의 같은 형태의 실패를 만듭니다. 세션 쿠키가 만료되었거나, 서버 인증서가 실제로 바뀐 것입니다. 둘은 일 분 남짓이면 구분되며, 지문이 관련되는 것은 둘 중 하나뿐입니다.

두 고장, 하나의 혼란스러운 로그 줄

둘은 두 가지 관찰로 갈라지며, 어느 쪽도 두 번 읽을 필요가 없습니다. 첫째는 실패가 언제 시작되었는지입니다. 만료된 쿠키는 몇 시간이나 며칠 동작한 뒤에 나타나고, 교체된 인증서는 게이트웨이 변경 직후에 나타납니다.

SignalExpired cookieChanged certificate
When it startedafter hours or days of workingright after a gateway change
Fingerprint from a fresh authenticateunchangeddifferent value
Usual log tailHTTP CONNECT 401 / unauthorizedsigner not found / verify failed
Repairreplace the cookie, restartre-pin deliberately, then restart

일 분짜리 시험은 아래의 authenticate 실행입니다. 그 FINGERPRINT를 파일 안의 OpenConnect.ServerCert과 비교하십시오. 지문이 같고 COOKIE가 다르면 쿠키만 바꾸면 됩니다. 지문이 다르면 서버 인증서가 실제로 바뀐 것이므로 의도적으로 다시 고정하고 누가 승인했는지 기록하십시오.

입력하지 말고 생성하십시오

ConnMan에는 NetworkManager와 달리 OpenConnect 프로필을 가져오는 단계가 없습니다. 값들을 미리 만들어 두어야 하는 프로비저닝 파일을 읽으며, 그것을 만드는 지원되는 방법이 OpenConnect의 authenticate 모드입니다.

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 모드를 실행하고, 쿠키 줄만 다시 씁니다. 자격 증명은 스크립트 밖에 두고 실행하는 계정만 읽을 수 있게 하며, 다시 쓰기는 원자적으로 하여 실패한 실행이 반쯤 쓰인 파일을 남기지 않게 하십시오.

갱신이 몇 시간마다 필요하다면 그 간격을 적어 두십시오. 그것은 게이트웨이 세션 정책의 성질이며, 갱신을 자동화할지 더 긴 세션을 요청할지 결정합니다.

관련 글