스크립트는 VPN을 시작할 뿐, 프로비저닝하지 않습니다

연결 이름으로 scutil --nc start을 실행하는 스크립트를 작성합니다 — 내 Mac에서는 작동하지만 사무실의 새로 설치된 모든 컴퓨터에서는 실패합니다. 스크립트가 고장 난 것은 아닙니다. 애초에 할 수 없었던 일을 요구받고 있습니다: 기존 연결을 시작하는 것은 새 연결을 만드는 것과 같은 작업이 아닙니다.

프로비저닝과 세션 제어는 두 명의 담당자가 있는 두 가지 작업이며, 그 반대를 가정한 워크플로는 작성된 컴퓨터에서만 모든 테스트를 통과합니다.

시작 명령이 실제로 대화하는 대상

세션 제어 명령은 이미 존재하고 이미 승인된 구성을 대상으로 합니다. 이전에 저장된 서버 설정, ID 참조, 정책을 사용해 그 이름의 연결을 올리도록 시스템에 요청합니다. 그것들이 한 번도 설치되지 않았다면 시작할 것이 없습니다.

그래서 실패는 새 하드웨어에서 나타나고 관리자의 노트북에서는 나타나지 않습니다. 그 노트북은 몇 달 전에 자신이 그렇게 했다는 사실을 잊은 사람이 프로비저닝한 것입니다. 시작 명령을 지난 분기에 누군가 배선한 초인종이라고 생각해 보십시오. 버튼을 누르는 것은 배선을 까는 것과 같지 않습니다.

VPN 구성의 세 주인

조직이 관리하는 프로필은 기기 관리에서 옵니다. 프로필은 서버 주소, 인증 방식, 조직이 요구하는 정책을 담고 있으며 VPN 관리자가 그것을 제공하는 사람입니다. 스크립트가 목록에서 찾은 표시 이름으로 그 설정을 다시 구성해서는 안 됩니다.

기본 개인 VPN 구성은 Apple의 Network Extension API로 생성되며, 내장된 IPsec과 IKEv2 프로토콜을 포함합니다. 이것은 저장 단계와 사용자 승인이 있는 애플리케이션 인터페이스이며, 공급업체가 제공하는 모든 터널 유형을 조용히 만드는 셸 명령이 아닙니다.

타사 클라이언트는 자체 가져오기 형식, 자체 관리 도구, 흔히 자체 권한 있는 도우미를 가진 세 번째 경우입니다. 그 세션은 해당 공급업체의 프로세스가 소유합니다. 비슷한 이름의 시스템 서비스를 찾는 것은 시스템 명령이 터널을 제어한다는 증거가 아니며, 그렇게 가정하면 공급업체가 클라이언트를 업데이트할 때까지 작동하는 것처럼 보이는 스크립트가 만들어집니다.

기본 프로비저닝에는 저장과 승인이 있습니다

Apple의 모델은 불러오기, 수정, 저장입니다. 애플리케이션은 실행 후 첫 저장 전에 기존 환경설정을 불러오고 구성을 변경한 뒤 저장합니다. 저장은 지속할 수 없을 때 오류를 보고하며, 그 결과를 무시하면 프로비저닝 실패가 세 단계 뒤 연결 실패로 바뀝니다.

첫 저장에는 사용자가 애플리케이션을 승인해야 합니다. 이것은 의도된 보안 경계이며, 새 Mac에서 첫 실행은 대화형이지만 이후의 모든 연결과 해제는 자동화할 수 있습니다. 첫 실행은 사람이 참석하는 인간 작업으로 계획하십시오. 두 번째 실행부터 자동화하고, 아무도 불가능을 약속하지 않도록 런북에 그렇게 적으십시오. 완전히 무인인 첫 실행을 약속하는 배포 계획은 플랫폼이 제공하지 않는 것을 약속하는 것입니다.

Apple은 또한 API에 의존하기 전에 구성 프로필로 서버 호환성을 검증할 것을 권장합니다. 이 확인을 먼저 하면 «서버가 이 클라이언트를 받아들이지 않는다»와 «클라이언트가 설정을 한 번도 저장하지 않았다»가 분리되며, 이는 서로 다른 팀을 위한 서로 다른 티켓입니다.

반복 가능한 시작 명령이 가정할 수 있는 것

프로비저닝 후 스크립트는 소유자의 인터페이스를 통해 안전하게 기존 연결을 대상으로 삼을 수 있습니다. 연결의 안정적인 식별자와 원하는 작업만 전달하고 그 외에는 아무것도 전달하지 마십시오. 추측한 환경설정 경로를 읽어서는 안 되며, 메뉴에 표시된 이름이 시스템 전체에서 고유하다고 가정해서도 안 됩니다.

기본 연결의 경우 scutil --nc start 같은 이름 있는 세션 요청은 제어 작업입니다. 서버 설정을 설치하지 않고 자격 증명을 가져오지 않으며 첫 저장 승인도 수행하지 않습니다. 체인의 마지막 단계로 취급하고, 체인 전체로는 절대 취급하지 마십시오.

비밀은 명령줄 인수와 일반 진단 출력 밖에 두십시오. 배포가 선택한 ID 메커니즘이 바로 시작 명령이 의존해야 하는 것이며, 셸 기록에 붙여 넣은 비밀번호는 어떤 검토에서든 발견 사항입니다.

두 가지 승인 점검

첫 번째 점검은 프로비저닝입니다. 새로 설치한 Mac을 가져와 구성이 존재하고 올바른 관리자가 소유하며 완전히 승인되었음을 증명하고, 프로비저닝되지 않은 컴퓨터의 연결 테스트는 스크립트에 대해 아무것도 증명하지 않으므로 연결을 테스트하기 전에 이것을 하십시오.

두 번째 점검은 세션입니다. 연결하고, 승인된 리소스에 도달하고, 깔끔하게 해제하십시오. 이제 모든 실패에 주인이 생기며, 그것이 두 작업을 나누는 실질적인 이점입니다. 프로필 누락은 전달 문제, 저장 오류는 승인 문제, 거부된 로그인은 인증 문제, 성공적인 시작 후의 시간 초과는 세션 계층이며, 그중 어느 것도 «스크립트가 고장 났다»가 아닙니다.