부팅 시 시작된 VPN 서비스가 키링을 읽지 못하는 이유
부팅 시점의 VPN에는 빌려 쓸 잠금 해제된 시크릿 에이전트가 없습니다. 서버가 한 번도 거부한 적 없는 비밀번호를 재설정하기 전에 연결의 시크릿 플래그를 읽으십시오.
로그인 후에는 동작하지만 그 전에는 실패하는 연결은 보통 부팅 시점의 시도가 시크릿을 얻지 못했다는 뜻이며, 서버가 시크릿을 거부했다는 뜻은 아닙니다. 자격 증명은 존재합니다. 그것을 요청하는 컨텍스트가 없을 뿐입니다. 이 한 가지 구분이 불필요한 비밀번호 재설정을 아껴 줍니다.
요청을 따라가 보십시오. 데스크톱 세션이 생기기 전에 무언가가 연결을 시작하고, 평소 응답하던 시크릿 저장소는 아직 잠금 해제되지 않았습니다. 두 컨텍스트는 시크릿의 소유자에 대해 의견이 다르며, 프로필은 둘 중 어느 쪽이 제공해야 하는지를 기록합니다.
부팅 경로가 실제로 요구하는 것
부팅 시 NetworkManager는 사용자 세션, 세션 D-Bus, 잠금 해제된 키링 없이 시스템 서비스로 시작합니다. 연결 프로필은 여전히 올릴 수 있지만, 서비스가 스스로 닿을 수 있는 시크릿으로만 가능합니다. 시크릿 에이전트가 소유한 것은 사람이 로그인해 에이전트가 나타날 때까지 기다립니다. 서비스는 구성이 말하는 대로 정확히 동작합니다. 바뀌어야 하는 것은 프로필입니다.
실패는 키링에 숨겨진 것이 아니라 연결 자체에 적혀 있습니다.
연결의 시크릿 플래그 읽기
데스크톱이 기억하는 것이 아니라 연결이 무엇을 기대하는지 물으십시오. 플래그 열이 그 질문에 곧바로 답하며, 디스크의 프로필 파일에서 재부팅을 넘어 유지됩니다.
프로필 목록부터 시작해 어느 연결이 스스로 올라오도록 설정되었는지 확인하십시오. 그다음 연결 하나를 덤프하고 비밀번호 플래그를 읽으십시오:
nmcli -f NAME,UUID,TYPE,AUTOCONNECT connection show nmcli connection show "Work VPN" | grep -i -E "password|secret|key" journalctl -b -u NetworkManager --grep "secret"
첫 명령은 어떤 프로필이 있는지, 하나가 자동 연결로 설정되었는지를 확인하며, 무인 시도가 시작되는 경로가 바로 이것입니다. 두 번째는 플래그 값을 드러내고, 세 번째는 주어진 시크릿에 어떤 에이전트도 응답하지 않았다고 서비스가 불평하는 모습을 보여 줍니다. 시크릿을 에이전트 소유라고 지목하는 로그 한 줄이 곧 한 문장으로 된 전체 진단입니다.
| Flag value | Where the secret lives | Behaviour before login |
|---|---|---|
| 0 | Stored in the connection profile | Available to the system service |
| 1 | Owned by a secret agent | Blocks until the agent is unlocked |
| 2 | Never stored | Prompts on every activation |
| 4 | Not required | Never requested at all |
연결을 시스템 범위로 옮기면 답이 달라지는 이유
사용자 소유 연결은 그 사용자의 에이전트 아래에서 활성화되므로 데스크톱이 올라오면 완벽하게 동작합니다. 시스템 범위로 옮기면 에이전트가 경로에서 빠지므로, VPN 구성 한 줄도 바꾸지 않은 채 같은 프로필이 다르게 동작합니다.
그 이동은 정당한 설계이며 한 가지 요구를 지닙니다. 시크릿이 시스템 서비스에서 닿을 수 있어야 합니다. 프로필에 저장하거나, 시스템 범위 자격 증명으로 제공하거나, 적절한 순간에 대화형 프롬프트를 받아들이는 것은 모두 유효한 답입니다. 플래그 1을 남겨 두고 기대하는 것은 아닙니다.
자체 암호 문구가 있는 개인 키는 두 번째 층을 더합니다. 저장된 계정 비밀번호조차 암호 문구를 요구하는 키를 열지 못하므로, 무엇이든 바꾸기 전에 실패하는 단계가 실제로 어느 시크릿을 요구하는지 확인하십시오.
하지 말아야 할 것과 대신 해야 할 것
모든 자격 증명 파일을 누구나 읽을 수 있게 하거나, 프롬프트가 필요 없도록 인증을 끄는 것은 시작 시의 불편을 영구적인 노출과 맞바꾸는 일입니다. 둘 다 의존성을 해결하기보다 숨기며, 다음 이미지 업데이트에서 같은 실패가 되돌아옵니다.
그 단계에서는 배포판이 무인 활성화를 위해 문서화한 메커니즘을 사용하고, 그다음 프로필의 플래그가 그것과 일치하는지 확인하십시오. 결과는 이미 에이전트가 있는 셸이 아니라 깨끗한 부팅에서 확인하십시오. 연결 소유자, 시크릿 출처, 동작해야 하는 단계를 적어 두면, 나중의 자동 시작 변경이 누군가 먼저 데스크톱을 잠금 해제해야 한다는 의존성을 조용히 되살릴 수 없습니다. 문서화가 고친 서비스와 다음 분기에 다시 깨지는 서비스의 차이입니다.
로그인 후 수동 재시도가 아니라 통제된 깨끗한 부팅에서 시험하십시오. 재시도가 성공하는 이유는 부팅 시도가 실패한 바로 그 이유이며, 빠른 시험이 파괴하는 증거가 바로 그것입니다.