벤더 VPN 앱과 NetworkManager: 상태를 누가 소유하는가?
프로필은 플러그인의 이름을 지정할 뿐, 벤더 클라이언트의 동작을 말하지 않습니다. 관리형 노트북을 바꾸기 전에 등록, DNS, 차단, 업데이트의 소유자를 정리하세요.
프로필을 가져오는 것은 클라이언트를 교체하는 것과 같지 않습니다. NetworkManager는 플러그인 유형을 플러그인별 데이터와 비밀 값과 함께 저장하며, 그 유형을 소유한 플러그인이 연결이 할 수 있는 일을 결정합니다. 벤더 애플리케이션이 그 위에 얹는 모든 것, 즉 등록부터 상시 차단까지는 파일 밖에 존재합니다. 전환이 안전한지는 실제로 그 계층 중 무엇에 의존하는지에 달려 있습니다.
파일은 기능 집합이 아니라 플러그인의 이름을 지정합니다
NetworkManager의 VPN 설정 참조 는 플러그인을 선택하는 서비스 유형과 함께, 오직 플러그인만 해석하는 불투명한 데이터 사전과 비밀 사전을 설명합니다. 프로필은 하나의 구현과 맺는 계약이며, 어느 클라이언트든 재현할 수 있는 동작의 설명이 아닙니다. 두 클라이언트가 같은 프로토콜을 말하면서도 무엇을 협상하고 어떤 데이터 경로를 여는지에서는 다를 수 있습니다. 프로토콜 이름은 터널이 무엇인지 알려 줄 뿐, 주변 클라이언트가 그것으로 무엇을 하는지는 결코 알려 주지 않습니다.
그러니 포장이 아니라 요구 사항을 비교하세요. 질문은 대안이 연결될 수 있는지가 아니라(대개 연결됩니다) 원래 클라이언트를 받아들일 만하게 만든 모든 요구 사항이 이전 후에도 살아남는지입니다. 무엇이든 설치하기 전에 그 요구 사항을 적어 두세요, 그렇지 않으면 비교는 무엇이 먼저 깨지는지 찾는 일이 됩니다.
벤더 앱이 터널 주위에 더하는 것
벤더 클라이언트는 대개 등록과 기기 상태 점검, 자체 인터페이스를 가진 이차 인증 흐름, 상시 차단, 업데이트 채널, 지원 도구를 함께 묶습니다. 그중 일부는 프로토콜 옆에 있고, 일부는 설치 프로그램만 공유하는 별도 제품입니다. NetworkManager는 터널과 그 라우팅을 대체할 수 있고, 디스패처 스크립트는 연결 상태가 바뀔 때 동작을 실행할 수 있습니다. 그러나 차단 엔진, 인증서 갱신 절차, 어떤 사용자가 연결을 올릴 수 있는지에 대한 가정을 재현하지는 않습니다.
구성 요소가 많다고 더 안전한 것도, 적다고 더 약한 것도 아닙니다. 질문은 따르라고 지시받은 정책을 어느 구성 요소가 실제로 강제하는가입니다. 감사자가 터널이 끊겼을 때 무엇이 트래픽을 차단하는지 묻는다면, 답은 실제로 그렇게 하는 것을 지목해야 하며, 연결만 하는 프로필은 그 답이 아닙니다.
소유권이 실제로 갈리는 지점
이것은 체크리스트가 아니라 소유권 지도로 읽으세요. 아래의 실패는 소유권의 틈이며 클라이언트 설정을 아무리 쌓아도 메워지지 않고, 각 행은 계층, 오늘날 대개 그 계층을 쥐고 있는 쪽, 그리고 틈이 처음 드러나는 지점을 말합니다.
| Layer | Vendor application | NetworkManager connection | Where the gap shows up |
|---|---|---|---|
| Enrollment and posture | built into the client | absent unless something else supplies it | a managed device fails its next posture check |
| Address and resolver authority | the client sets both | the plugin plus dispatcher scripts | names resolve through the wrong resolver after a state change |
| Blocking on drop | a bundled engine | nothing by default | traffic continues in the clear after the tunnel dies |
| Upgrade path | the vendor's own channel | the distribution package and its plugin | a plugin update changes behaviour with no vendor note |
| Diagnostics and support | vendor tooling with client state | journal and dispatcher output | support cannot see why negotiation failed |
각 행에는 클라이언트에 대한 느낌이 아니라 반복할 수 있는 관찰을 붙이세요. 의도한 리졸버를 통해 해석된 이름, 터널이 멈출 때 사라지는 경로, 모의 단절 뒤 차단된 연결, 이 세 가지 관찰이 함께 표의 대부분을 덮습니다. 관찰은 그것이 증명하는 요구 사항 옆에 적고 실패한 것은 남겨 두세요, 실패한 관찰만이 다음 사고를 예측하는 기록의 일부이기 때문입니다.
소유권을 겹치지 않고 전환하기
같은 서비스에 대해 벤더 클라이언트와 NetworkManager 연결을 동시에 실행하는 것이 이런 비교가 잘못되는 가장 흔한 방식입니다. 둘 다 경로를 설치하고, 둘 다 DNS를 설정할 수 있으며, 둘 다 방화벽 상태를 건드릴 수 있습니다. 그러면 측정하는 것은 두 클라이언트 어느 쪽의 문서화된 동작과도 맞지 않는 세 번째 구성입니다.
nmcli -f NAME,UUID,TYPE connection show
nmcli connection show work --show-secrets | grep -E "^vpn\."
journalctl -u NetworkManager -b --since "10 min ago"첫 번째 명령은 프로필이 애초에 VPN 유형인지 알려 줍니다. 두 번째는 플러그인 서비스 유형과 어떤 비밀이 저장되었는지 보여 주며, 이는 키를 파일이 아니라 에이전트에서 기대할 때 중요합니다. 저널은 로드되었지만 협상하지 못한 플러그인이 그 사실을 말하는 곳입니다. 세 가지 중 어느 것도 문제를 보이지 않으면, 틈은 연결이 아니라 터널 위의 정책 계층에 있습니다.
새 연결을 활성화하기 전에 이전 클라이언트를 분리하고, 엔드포인트와 계정을 동일하게 유지하며, 경로와 리졸버 설정, 차단을 어느 구성 요소가 소유하는지 적어 두세요. 그 메모가 다음 업데이트가 두 명의 소유자로 끝나는 것을 막습니다.