Wi-Fi는 스스로 연결되고, VPN에는 보조 연결이 필요하다

노트북은 앉기도 전에 Wi-Fi에 연결되고, VPN은 여전히 클릭을 기다린다. VPN 프로필에서 자동 연결을 설정해도 아무것도 바뀌지 않는데, 그 스위치는 프로필 자체의 활성화를 제어하고 NetworkManager는 VPN을 기본 연결의 동반자로 취급하기 때문이다. 문서화된 메커니즘은 기본 연결의 보조 목록이며, 그것은 다른 위치에 있는 다른 속성이다.

자동 연결은 VPN 스위치가 아니다

Wi-Fi 또는 Ethernet 프로필은 장치를 소유하므로 스스로 활성화될 수 있다. VPN 플러그인 프로필은 같은 의미에서 장치를 소유하지 않으며, 장치를 소유한 연결 옆에서 시작된다. 그래서 VPN의 자동 연결 플래그는 올바르게 보이고, 올바르게 저장되며, 터널을 만들지 않는다. 그 플래그는 프로필에 대한 질문에 답할 뿐, 필요한 네트워크에 대한 것이 아니다.

모델을 이렇게 읽으면 실패 방식도 설명된다. 기본 연결이 되고, 아무것도 VPN에 시작을 요청하지 않으며, 데스크톱은 연결된 네트워크 옆에 끊긴 VPN을 표시한다. 고장 난 것은 없고, 연결은 애초에 만들어지지 않았다.

UUID로 두 프로필을 식별한다

nmcli -f NAME,UUID,TYPE connection show

터널을 시작해야 하는 Wi-Fi 또는 Ethernet 프로필을 고르고, 그다음 의도한 VPN 프로필을 고른다. 이름 대신 UUID를 사용하는데, 이름은 복제하거나 편집할 수 있는 레이블이고, 활성화 경로가 실제로 해석하는 것은 UUID이기 때문이다.

프로필 이름을 인터페이스 이름이나 머신이 지금 가진 주소와 혼동하지 않는다. 터미널에서 우연히 비슷해 보이는 세 가지 식별자이며, 이를 섞으면 아무것도 겨냥하지 않는 변경이 된다.

VPN을 기본 연결에 추가한다

nmcli connection modify uuid "PRIMARY_UUID" +connection.secondaries "VPN_UUID"

플러스 형식은 기존 목록에 덧붙이며, 이를 생략하면 목록이 대체되어 이미 설정된 다른 보조 연결이 조용히 제거된다. 먼저 현재 값을 확인하고 무엇이든 바꾸기 전에 기록해 둔다.

NetworkManager의 연결 설정은 보조 연결을 기본 연결과 함께 시작되는 VPN 연결로 설명한다. 네이티브 WireGuard 프로필이 같은 종류의 객체인지는 NetworkManager가 그것을 어떻게 관리하는지에 달려 있으므로, VPN 플러그인이 아니라 인터페이스로 나타나는 터널에는 같은 명령이 잘못된 도구일 수 있다.

이것은 연결 정책의 변경이며 런타임 토글이 아니다. 배포가 승인하는 재연결 프로세스를 통해 적용하고, 변경 후 첫 활성화가 지금 앉아 있는 세션과 다르게 동작할 것으로 예상한다.

시크릿은 연결의 일부가 아니다

보조 항목은 «이것을 저것과 함께 시작하라»고 말한다. 그 안에는 비밀번호를 넘겨주거나 키링을 잠금 해제하거나 프롬프트에 응답하는 것이 없다. 데스크톱 로그인 후 잘 인증되는 프로필도 시크릿 에이전트가 없는 컨텍스트에서 활성화되면 실패할 수 있다.

실제 배포에는 지원되는 시스템 또는 시크릿 에이전트 방식을 사용한다. 터널이 감독 없이 시작되도록 모든 사람의 비밀번호를 스크립트에 저장하는 것은 인증 설계를 소유자의 고용보다 오래 사는 파일로 바꾼다.

두 이벤트를 읽고, 그다음 리소스를 확인한다

한 번의 시도 동안 기본 연결과 VPN 활성화를 관찰한다. VPN 이벤트가 없으면 트리거가 구성된 적이 없거나 UUID가 잘못된 것이다. VPN 이벤트 뒤에 인증 실패가 오면 트리거는 실행되었고 남은 문제는 자격 증명이며, 그것은 다른 수정이다.

활성화 후에는 아이콘을 믿는 대신 설정의 계기가 된 리소스를 요청한다. 그런 다음 의도적으로 연결을 끊고 다음에 무슨 일이 일어나는지 관찰하는데, 자동 시작 연결은 킬 스위치가 아니며 끝없는 재시도를 약속하지 않기 때문이다. 요구가 «터널 없이는 트래픽도 없다»라면 그것은 자체 구성과 자체 테스트가 필요한 별도의 정책이다. 둘을 혼동하면 사용자가 보호받는다고 믿는 동안 머신이 루프로 재연결하게 된다.