VPN 세컨더리는 하나의 Wi-Fi 프로필에 속하며 모든 프로필에 속하지 않습니다

VPN을 홈 Wi-Fi 연결의 세컨더리로 구성하면 모든 것이 작동하지만, 노트북이 다른 액세스 포인트에 연결되면 터널은 내려간 채로 남습니다. 새 연결은 고유한 UUID를 가진 별도의 구성 객체이며, 이전 연결을 위해 만든 결합을 알 이유가 없습니다. 아무것도 고장 나지 않았고, 연관은 애초에 존재하지 않았을 뿐입니다.

NetworkManager의 연결 참조는 세컨더리를 특정 기본 연결과 함께 활성화되는 UUID로 정의합니다. 또한 일반 VPN 프로필은 기본 연결처럼 자동 활성화를 구현하지 않는다고 명시합니다. 두 진술 모두 연관은 프로필별이며 누군가가 각각의 새 프로필에 대해 만들어야 한다는 같은 결론으로 이어집니다.

세컨더리란 실제로 무엇인가

기본 연결에는 식별자, UUID, 세컨더리 목록이 있습니다. 활성화되면 관리자는 해당 세컨더리도 순서대로 활성화하며, 이렇게 VPN이 수동 클릭 없이 Wi-Fi 네트워크를 따라갑니다. 관계는 기본 연결에 존재하며 이름이 아닌 UUID 문자열로 기록됩니다. 이 표현 선택은 우연이 아니며, 이름 변경 후에도 연관이 살아남게 하는 것이 바로 이것입니다.

이름에 관한 그 세부 사항은 보이는 것보다 중요합니다. VPN 프로필의 이름을 바꿔도 UUID는 그대로이므로 기존 연관은 계속 작동합니다. 이전 프로필을 삭제하고 새 프로필을 가져오면 새 UUID가 생성되며, 이전 프로필을 가리키던 모든 연관은 이제 아무것도 가리키지 않습니다.

추가하기 전에 기존 목록을 검사하십시오. 세컨더리 하나를 가진 홈 프로필은 모든 SSID에 맞는 규칙이 아니라 하나의 객체에 있는 한 행일 뿐이며, 다른 기본 연결이 활성화될 때 참조되지 않습니다.

연관을 프로필이 생성되는 곳에 두십시오

개인 컴퓨터에서는 의도한 세컨더리를 연결하는 것을 허용된 각 Wi-Fi 프로필을 추가하는 절차의 일부로 만드십시오. 기능이 아니라 습관이지만 일관된 상태를 만드는 습관이며, 네트워크당 명령 하나 또는 대화 상자 방문 두 번이 필요합니다. 목록이 곧 정책이므로 어떤 네트워크가 터널을 담당해야 하는지 짧게 기록해 두십시오.

관리되는 장치에서는 프로비저닝 워크플로가 Wi-Fi 항목과 그 VPN 연관을 같은 단계에서 만들도록 하고, 이미 존재하는 허용된 프로필에도 같은 처리를 적용하십시오. VPN 프로필만 배포하면 기본 관계가 지정되지 않은 채로 남으며, 이렇게 하면 플릿의 절반만 사용하는 터널이 생깁니다.

사용자가 여전히 관리 경로 밖에서 프로필을 만들 수 있는 곳에서는 그 항목에 어떤 일이 일어날지 명시적으로 결정하십시오. 연관을 상속한다고 가정하는 것은 정책이 아니라 지원 비용이 따르는 희망입니다.

VPN의 식별자가 바뀌는 것을 계획하십시오

프로비저닝 소스에는 누군가 추측한 표시 이름이 아니라 의도한 VPN의 UUID가 필요합니다. 유지보수에서 해당 VPN을 새로 가져온 객체로 교체할 때는 같은 변경에서 프로비저닝 템플릿과 영향을 받는 기존 연관을 업데이트하십시오. 이름 변경은 교체가 아니며, 둘을 동등하게 취급하는 것이 작동하던 배포가 일주일 뒤 깨지는 방식입니다.

UUID를 그것이 존재하는 이유 옆에 저장하십시오. 세컨더리 목록에서 맨 UUID를 발견한 미래의 엔지니어는 그것이 최신인지 알 방법이 없고, 정리하다가 삭제할 가능성이 큽니다.

활성화는 강제가 아닙니다

세컨더리 요청은 활성화 시점에 발생합니다. 인증이 완료되기 전 구간에서 애플리케이션을 차단하지 않으며, 터널이 실패한 후 트래픽을 중지하지도 않습니다. 이것들은 서로 다른 메커니즘이 제공하는 서로 다른 속성이며, 이를 혼동하면 프로필에서는 엄격해 보이지만 실제로는 관대한 설계가 됩니다.

직접 트래픽 차단은 자체 구성과 자체 실패 모드를 가진 별도 기능이며, 어떤 터널이 존재하기 전에 네트워크에 도달해야 하는 트래픽(캡티브 포털, 로그인 페이지, 엔드포인트 자체)을 고려해야 합니다. 인증 전에 충족될 수 없는 차단 정책은 머신을 정작 필요한 네트워크에서 잠급니다.

그 구분을 사용자가 실제로 읽는 지침에 넣으십시오. 새 Wi-Fi 네트워크는 터널을 요청할 수 있지만, 강제는 연결할 수 없을 때 무언가 나갈 수 있는지를 결정합니다. 앞부분만 들은 사용자는 설계가 깨졌다고 보고할 것입니다.

진짜 새 프로필로 테스트하십시오

이미 작동하는 홈 항목이 아니라 승인된 테스트 네트워크와 새로 만든 기본 프로필을 사용하십시오. 기본 활성화, 요청된 세컨더리 UUID, 모든 인증 프롬프트를 순서대로 관찰하고, 멈춘다면 어느 단계에서 멈추는지 기록하십시오. 데스크톱 로그인 후에 사용 가능해지는 시크릿 에이전트는 모든 시작 컨텍스트에 자동으로 존재하지 않으므로 재부팅도 테스트 계획에 포함해야 합니다. 그런 다음 의도한 리소스와 실패 경로(애플리케이션이 필요로 하기 전에 터널이 올라오는지, 인증이 실패할 때 그 애플리케이션에 무슨 일이 일어나는지)를 확인하십시오.

그런 다음 의도한 리소스와 실패 경로(애플리케이션이 필요로 하기 전에 터널이 올라오는지, 터널이 인증할 수 없을 때 그 애플리케이션에 무슨 일이 일어나는지)를 확인하십시오. 이 두 관찰이 수용 기준이며, 둘 다 프로필 자체에서는 보이지 않습니다.