성공적인 연결은 양쪽 끝이 수용하는 값 집합을 찾았다는 것만 증명합니다. 관리형 Mac IKEv2 프로필에는 보안 연결 사전이 두 개 들어 있고, 게이트웨이에는 자체 제안 목록이 있으며, 연결은 양측이 허용하는 교집합에서 성립합니다. 아래 점검을 순서대로 수행하고, 또 다른 암호를 추가해 도움이 되는지 보는 대신 양쪽 끝이 불일치하는 지점에서 멈추세요. 각 단계는 프로필의 서로 다른 계층을 배제합니다.

값을 편집하기 전에 두 사전을 모두 확인하세요

VPN 페이로드의 IKEv2 설정에서 IKESecurityAssociationParameters은 IKE 연결을, ChildSecurityAssociationParameters은 Child SA를 설명합니다. Apple 스키마는 두 번째 사전이 없을 때 IKE 매개변수가 Child SA에도 적용된다고 명시합니다. 이 상속은 편리하며, 바로 이렇게 해서 프로필에 아무도 의식적으로 선택하지 않은 값이 남습니다.

<key>IKESecurityAssociationParameters</key>
<dict>
  <key>EncryptionAlgorithm</key><string>AES-256</string>
  <key>IntegrityAlgorithm</key><string>SHA-256</string>
  <key>DiffieHellmanGroup</key><integer>14</integer>
  <key>LifeTimeInMinutes</key><integer>1440</integer>
</dict>

값이 일치하더라도 두 행을 모두 배포 기록에 기록하세요. 그러면 검토자는 Child SA가 우연히 상속된 것이 아니라 검토되었음을 알 수 있고, 나중에 한 행을 변경해도 다른 행이 조용히 바뀌지 않습니다.

문자열을 복사하기 전에 각 키의 의미를 확인하세요

네 개의 키는 다른 제품의 제안 문자열과 서로 바꿀 수 없습니다. 알고리즘 이름은 구현에 따라 다르므로 Apple 필드에 strongSwan 제안을 붙여 넣는 대신 각 측의 문서화된 구문으로 선택한 제품군을 번역하세요.

KeyHoldsCommon mistake
EncryptionAlgorithmCipher for that associationAssuming an AEAD name also sets integrity
IntegrityAlgorithmIntegrity for the chosen suiteLeaving it set for an AEAD suite that does not use one
DiffieHellmanGroupNumeric group identifierReading the number as key size in bits
LifeTimeInMinutesAssociation lifetimeSetting it shorter than the gateway's renewal margin

«가장 큰 그룹 번호를 사용하세요»는 선택 방법이 아닙니다. 그룹 식별자는 서로 다른 구성을 가리키며, 숫자가 크다고 해서 같은 것의 더 강한 버전이라는 뜻은 아닙니다. 제품군은 전체로서 유효하거나 무효이므로 게이트웨이 소유자에게 전체 조합을 승인받으세요. 승인되지 않은 그룹과 함께 승인된 암호는 승인되지 않은 제안이며, 실패하거나 어느 쪽도 문서화하지 않은 무언가로 조용히 대체됩니다.

오래된 알고리즘을 퇴역시키는 버전 제한을 확인하세요

Apple 페이로드 스키마는 DES, 3DES, SHA1-96, SHA1-160 및 Diffie-Hellman 그룹 1, 2, 5를 26 이전의 macOS 버전으로 제한합니다. 이전 배포에서 가져온 프로필에는 여전히 그런 값이 남아 있고 여전히 오래된 게이트웨이에 연결될 수 있으며, 바로 그런 경우에 작동하는 구성이 퇴역 날짜를 숨깁니다.

프로필을 구축하기 전에 지원되는 Mac 버전과 게이트웨이가 유지하는 제안 정책을 확보하세요. 그런 다음 교집합을 선택하고 나머지 옵션이 제외된 이유를 기록하세요. «게이트웨이는 여전히 구형 클라이언트에 그룹 2를 제공한다»는 메모는 이력이 없는 암호 목록보다 가치가 있습니다. 그 메모가 없으면 다음 검토자는 의도적인 예외와 누락을 구분할 수 없습니다.

인증은 별도의 행에서 확인하세요

제안에 대한 합의가 잘못된 서버 ID를 고치지는 않습니다. 게이트웨이 ID, 인증서 신뢰, 사용자 또는 장치 자격 증명은 별개의 결정이며, 알고리즘이 완벽하게 정렬되어 있어도 각각 실패할 수 있습니다. 인증서의 서명 알고리즘을 변경하는 것은 IKE 암호화 알고리즘을 선택하는 것과 같은 행위가 아니지만, 둘 다 같은 검토에 나타납니다.

예상 서버 ID를 기록에서 제안 옆에 두세요. 인증서 변경 후 연결이 실패하면 그 짝이 다음 사람에게 협상과 신뢰 결정 중 무엇이 먼저 움직였는지 알려줍니다.

리비전 하나를 배포하고 무엇이 협상되었는지 검사하세요

조직이 지원하는 배포 워크플로를 사용하고 프로필 식별자, 리비전, 대상 Mac 버전, 일치하는 게이트웨이 정책을 기록하세요. 연결할 수 없는 장치에는 문서화된 복구 경로를 제공하고, 소유권을 아무도 확인할 수 없는 같은 이름의 두 번째 프로필을 만들지 마세요.

승인 중에 승인된 진단 도구로 설치된 구성과 협상된 IKE 및 Child 연결을 검사한 다음 통제된 갱신을 강제하세요. 첫 연결은 초기 협상이 작동했다는 것만 증명하며, 수명 불일치는 보통 배포가 승인된 훨씬 뒤의 첫 키 교환에서 나타납니다.

승인된 제품군을 리비전 기록과 함께 보관하세요. 그러면 다음 macOS 업데이트나 게이트웨이 변경 시 오늘 우연히 연결되는 프로필이 아니라 비교할 기준선이 생깁니다.

관련 글