macOS에서 VPN 프로파일을 가져오지 못할 때: 먼저 페이로드를 읽어 보세요
한 Mac에서는 거부되고 다른 Mac에서는 받아들여지는 프로파일은 대개 페이로드 문제입니다. XML을 비교하고 생성기가 무엇을 추가했는지 확인한 뒤 서비스를 검증하세요.
프로파일이 한 Mac에서는 문제없이 설치되고 다른 Mac에서는 거부된다면 아직 네트워크까지 도달하지 못한 것이므로 인증서나 게이트웨이, 비밀번호를 탓할 이유가 없습니다. 설치 프로그램은 받아들이지 않을 페이로드에서 멈췄고 보통 어느 것인지 기록합니다. 그 결과 프로파일 파일과 그것을 만든 모든 것이 작업할 수 있는 유일하게 합리적인 장소로 남고, 클라이언트의 설정을 지우는 일은 복구가 아니라 증거를 없애는 일이 됩니다.
Mac을 초기화하는 대신 프로파일을 읽으세요
.mobileconfig을 내보내고 클라이언트를 건드리기 전에 실제로 무엇이 들어 있는지 확인하세요:
plutil -p profile.mobileconfig | head -60
VPN 프로파일은 실제로 서로 다른 일을 하는 두 개의 페이로드로, com.apple.vpn.managed은 연결을 담고 com.apple.dnsSettings.managed은 리졸버 설정을 담습니다. 설치는 설치 프로그램이 거부하는 첫 페이로드에서 멈추고, 그 거부는 해당 페이로드 이름과 함께 시스템 로그에 남으므로 어느 섹션을 열어야 하는지는 로그가 알려 줍니다. 그 파일이 차이를 재는 기준이 되므로, 마지막으로 가져오기에 성공한 프로파일의 사본을 남겨 두세요.
생성기가 조용히 추가한 것
Apple Configurator 2.15 빌드 7A23은 자사의 DNS 페이로드 안에 다음 블록을 내보냈습니다:
<key>DNS</key>
<dict>
<key>SupplementalMatchDomainsNoSearch</key>
<integer>0</integer>
</dict>
macOS 12.1에서 그 빌드가 작성한 프로파일은 가져올 때 거부되었습니다. Configurator 2.11.1로 만든 연결은 아무 불평 없이 들어갔는데, 그 릴리스는 키를 아예 쓰지 않았기 때문입니다. DNS 사전 전체를 지우거나 문제가 된 키만 지우고 다시 저장한 다음, 다른 무엇이든 바꾸기 전에 같은 기기에서 다시 시도하세요. 보통 그 한 번의 수정이 복구의 전부입니다.
이 도구에는 믿기 전에 알아 둘 함정이 있습니다. 키를 지운 뒤 같은 연결을 저장해도 키는 돌아오지 않았고, 연결을 처음부터 만들었을 때만 다시 나타났습니다. 새로 만든 프로파일은, 특히 연결을 한자리에서 대량으로 만든 경우에는 모두 의심스러운 것으로 보고 점검하세요.
MDM 경로는 다른 곳에서 실패합니다
같은 프로파일을 밀어 넣는 관리 서비스는 다른 지점에서 실패할 수 있는데, 클라이언트는 VPN 서비스가 아예 만들어지지 않았다고 불평합니다. 보고된 사례에서는 인증서 인증용으로 설정된 페이로드가 그런데도 비밀번호 필드를 요구했고, 자리 표시자로 채우자 프로파일이 적용되었지만 그 값은 인증에 전혀 쓰이지 않았습니다.
그 경로를 택한다면 더미 문자열을 저장하고 실제 자격 증명은 절대 저장하지 말며, 진짜 비밀은 프로파일 본문 밖에 두세요. 작동하는 비밀번호를 품은 프로파일은 키처럼 보호해야 하는 파일이 되고, 그것은 처음의 가져오기 실패보다 훨씬 큰 문제입니다. 프로파일을 배포하기 전에 그 자리 표시자의 주인을 정해 두면 나중에 아무도 교체할 만한 값으로 오해하지 않습니다. 왜 존재하는지 한 줄 적어 두면 반년 뒤의 논쟁 하나를 줄일 수 있습니다.
프로파일이 실제로 적용되었는지 확인하세요
가져오기 성공은 작동하는 서비스가 아닙니다, 그러니 다음 순서로 확인하세요:
profiles show -type configuration
scutil --nc list
scutil --nc start "Your VPN Service"
scutil --nc status "Your VPN Service"
scutil --dns | head -20
첫 명령은 설치된 페이로드를 나열하고, 두 번째는 VPN 서비스가 존재하는지 알려 줍니다. 연결한 뒤 실행하는 마지막 명령은 시스템이 실제로 사용할 리졸버를 보여 줍니다. 이 순서대로 읽고, 서비스가 없으면 리졸버에 관한 어떤 질문도 의미가 없으므로 사슬이 끊기는 지점에서 멈추세요. 프로파일이 설치된 것으로 나열되면서도 쓸 만한 것을 전혀 갖지 못할 수 있는데, 이 순서는 바로 그 상태를 드러내기 위해 마련된 것입니다.
서비스 항목에 아직 쓸 만한 이름이 없는데 터널이 올라온다면 표시 이름 필드가 내보내기에서 사라진 것이며, 해법은 클라이언트에서 이름을 바꾸는 것이 아니라 프로파일을 다시 만드는 것입니다. 리졸버가 계속 로컬을 가리킨다면 DNS 페이로드가 의도보다 더 철저히 제거된 것입니다.
배포는 단계적으로, 한 번에 Mac 한 대씩
같은 OS 빌드에서 실행되는 관리 대상 Mac 한 대에 설치한 다음 서비스가 나타나는지, 리졸버가 바뀌는지, 실제 내부 요청 하나가 성공하는지 세 가지를 따로 확인하세요. 세 가지가 모두 확인된 뒤에야 범위를 넓혀야 합니다.
이것은 서로 다르게 실패하는 세 가지 결과이며, 그래서 시험용 기기 한 대가 그 십 분의 값을 합니다. 가져오기가 되는 프로파일은 작동하는 프로파일이 아니며, 첫 단계 기기는 나머지 장비들이 어느 쪽도 보기 전에 두 가지 실패를 모두 잡아냅니다.