iPhone의 Always On VPN과 VPN On Demand: 무엇을 배포할까

On Demand는 규칙이 일치할 때 터널을 열고, 관리형 Always On은 감독 대상 기기에서 커버리지를 강제합니다. 하나를 고르고 작동을 증명하는 절차입니다.

두 iPhone이 모두 VPN이라고 말하면서 전혀 다르게 동작할 수 있습니다. On Demand는 규칙이 일치할 때 터널을 열고, 사용자는 설정에서 여전히 끌 수 있습니다. 관리형 Always On은 감독 대상 기기에서 터널이 올라오지 못하는 순간까지 포함해 커버리지를 강제로 유지합니다. 사용자가 아무것도 하지 않을 때 무엇이 참이어야 하는지 물어 고르고, 정상 상태가 아니라 전환을 시험하십시오. 아래 단계는 배포가 실제로 실패하는 순서를 따릅니다.

단계 1: 기기가 무엇을 강제할 수 있는지 확인

Always On은 감독 대상 기기용 기능입니다. 기기군이 감독 대상이 아니면 논의는 시작 전에 끝나며, 어떤 payload 키도 감독 없는 기기를 강제 기기로 만들지 않습니다. 관리 측과 기기 양쪽에서 감독 여부를 확인하고, 이어서 프로파일 서명자를 확인하십시오.

기기에서는 설정, 일반, VPN 및 기기 관리 순으로 엽니다. 프로파일 항목에 소유자가 표시되며, 손으로 설치한 개인 프로파일은 관리 서비스가 배포한 것과 다르게 보입니다. 프로파일 이름이나 공급업체의 마케팅 표기로 강제 여부를 추론하지 마십시오. 표기는 플랫폼 정책이 아닙니다.

구성을 만지기 전에 세 가지 사실을 적으십시오. 감독 여부, 관리형인지 개인 프로파일인지, 어떤 클라이언트가 터널을 나르는지입니다. 이후 단계는 모두 이 셋에 달려 있으며, 개인 기기의 동작을 관리형 프로파일로 옮기는 것이 잘못된 기준으로 배포를 승인하는 길입니다.

단계 2: 기능 이름이 아니라 on-demand 규칙을 읽으십시오

On Demand는 순서대로 평가되는 규칙 목록입니다. 각 규칙은 동작과 그것을 선택하는 조건을 지정하며, 조건이 핵심입니다. 인터페이스 유형, Wi-Fi SSID, DNS 도메인 접미사, 또는 탐침 URL입니다. 절대 일치하지 않는 규칙 집합은 절대 연결되지 않는 기능입니다.

<key>OnDemandRules</key>
<array>
  <dict>
    <key>Action</key><string>EvaluateConnection</string>
    <key>InterfaceTypeMatch</key><string>WiFi</string>
    <key>SSIDMatch</key><array><string>Office-WiFi</string></array>
  </dict>
</array>

배열 전체를 읽고 규칙마다 두 가지를 물으십시오. 이 조건이 이 기기군에서 참이 될 수 있는지, 어떤 규칙도 일치하지 않을 때 무슨 일이 일어나는지입니다. 기업 네트워크는 액세스 포인트 이름을 바꾸고 SSID를 합치며 DNS 접미사를 바꾸고, 그 각각의 편집이 규칙을 현실에서 조용히 떼어냅니다.

DNS 접미사 조건은 현장에서 가장 자주 틀립니다. 게스트 네트워크에서 기기가 보고하는 접미사는 기업 리졸버가 제공하는 접미사가 아니기 때문입니다. 규칙을 신뢰하기 전에 기기가 실제로 해석하는 이름을 확인하십시오.

단계 3: 정적 연결이 아니라 전환을 시험하십시오

보고 있는 동안 올라와 있는 터널은 거의 아무것도 증명하지 못합니다. 각 전환을 의도적으로 수행하고 기기가 무엇을 하는지 기록하되, 결과를 비교할 수 있도록 매번 같은 사설 리소스를 사용하십시오.

  • 규칙이 일치해야 하는 네트워크에 접속한 뒤 사설 리소스를 요청하고 로드되는지 확인합니다.
  • 앱을 백그라운드에 둔 채 셀룰러로 전환하고, 다시 앞으로 가져와 요청을 반복합니다.
  • 캡티브 포털이 있는 Wi-Fi에 연결해 포털에 도달하는지, 인증 전에 강제가 막는지 봅니다.
  • 감독 대상 기기에서 터널을 수동으로 끄고 스스로 돌아오는지, 얼마나 빨리 돌아오는지 확인합니다.

감독 없는 기기가 있다면 같은 목록을 실행합니다. 두 결과의 차이가 배포의 실제 동작이며, 연결된 터널의 스크린샷이 결코 보여주지 않는 부분입니다.

단계 4: 두 가지 실패 형태를 알라

강제 커버리지는 차단으로 실패합니다. 터널이 성립하지 않으면 기기는 사설 리소스와 함께 일반 인터넷 접근을 잃고, 사용자는 온라인이지만 탐색할 수 없는 기기를 겪습니다. 재연결과 차단은 별개의 관측이므로 둘 다 기록하고, 인터넷 부재를 하나의 증상으로 다루지 마십시오.

On Demand는 발동하지 않아 실패합니다. 규칙이 일치하지 않고 터널이 나타나지 않으며 사설 리소스는 그저 시간 초과됩니다. 클라이언트가 설정대로 동작하므로 서버 문제로 오진하기 쉽습니다.

캡티브 포털은 둘 사이에 있습니다. 터널이 존재하기 전에 연결이 필요하므로, 터널이 올라올 때까지 모두 차단하는 정책은 포털을 통과하는 문서화된 경로가 필요합니다. 설계에서 결정하고 헬프데스크에서 결정하지 마십시오.

단계 5: 검증하고 롤백을 연습하십시오

검증은 무해한 트래픽으로 실제 경로에서 합니다. 공개되어서는 안 되는 사설 리소스를 요청하고, 기기가 외부에 제시하는 주소를 확인하고, 재부팅 후 다시 반복해 시작 순서를 보십시오. 따뜻한 상태만으로는 부족합니다.

그다음 운영에서 필요해지기 전에 시험 기기에서 제거를 연습하십시오. 프로파일을 제거하면 기기는 이전 상태로 돌아가며, 얼마나 걸리는지와 사용자가 무엇을 보는지 아는 것이 runbook의 일부입니다. Apple의 VPN 보안 안내서는 플랫폼이 이 정책에 대해 문서화하는 내용의 참조이며, 플랫폼보다 더 주장하는 구성을 쓰기 전에 읽을 가치가 있습니다.

첫 단계의 세 가지 사실을 규칙 집합과 시험 결과 옆에 두십시오. 다음 사람이 왜 어떤 기기는 한 네트워크에서 연결되고 다른 네트워크에서는 안 되는지 물을 때, 이 메모가 다시 만드는 대신 일 분 만에 답합니다.

관련 글