여러 클라이언트에 맞는 IKEv2 설정 계획하기

한 데스크톱에서 작동하는 프로필은 한 클라이언트에 대한 성공적인 테스트입니다. 그것은 여러 플랫폼에 걸친 배포가 아니며, 그렇게 취급하면 Windows는 연결되고, 휴대폰은 ID 검사에서 실패하며, 관리되는 노트북은 깨어날 때마다 다시 연결되는 익숙한 지원 패턴이 생깁니다. 차이는 실제이며 대부분 예측 가능하므로, 계획은 스크린샷이 아니라 행렬이어야 합니다.

먼저 ID 계약을 결정하세요

알고리즘을 논하기 전에 서버 ID, 인증서 신뢰, 클라이언트 인증 방식을 문서화하세요. 이 세 가지가 클라이언트가 인증할 수 있는지를 결정하며, 플랫폼마다 다르게 표현하는 부분입니다.

각 플랫폼이 예상 식별자를 어떻게 이름 붙이고 주체 대체 이름을 어떻게 처리하는지 확인하세요. 한 클라이언트에서 서버 이름을 받아들이는 프로필이 다른 클라이언트에서는 식별자 필드가 다른 값으로 채워지기 때문에 같은 인증서를 거부할 수 있습니다.

그다음 암호화 교집합을 고르세요

지원되는 각 클라이언트가 제시할 수 있는 제안을 비교하고 게이트웨이도 허용하는 현대적인 교집합을 고르되, 오래된 장치 하나가 연결되도록 지나치게 큰 레거시 목록을 켜지 마세요. 그 목록이 이후 모든 이에게 게이트웨이의 기본값이 되기 때문입니다. 각 레거시 옵션이 왜 아직 있는지 적어 두세요. 그것이 필요한 장치를 아무도 지목할 수 없다면, 그것은 요구 사항이 아닙니다.

계획에서 IKE와 CHILD 설정을 분리하세요. IKE 교환에 허용되는 제안이 보호된 트래픽에도 자동으로 허용되는 것은 아니며, 둘은 별도로 협상됩니다. 한 계층에서 제안을 수락하는 게이트웨이가 다른 계층에서는 거부할 수 있고, 로그에는 첫 계층이 성공한 것처럼 보이는 실패가 남습니다.

검증된 절차로 자격 증명을 제공하고, 사용자 비밀번호, 공유 비밀, 클라이언트 개인 키를 각자의 필드에 보관하세요. 비슷한 이름의 상자에서 시행착오를 거치는 것이 작동하는 테스트를 재현 불가능한 테스트로 만드는 길입니다.

정상 상태가 아니라 수명 주기를 테스트하세요

각 클라이언트에 대해 초기 인증, 의도한 애플리케이션, DNS 확인, 주소 패밀리 범위를 테스트하세요. 그다음 나중에야 나타나는 부분, 즉 갱신, 절전, 일반적인 네트워크 변경을 연습하세요.

MOBIKE 지원과 재인증 동작은 방금 측정한 정상 상태 결과와 다를 수 있습니다. 그 시점의 이벤트와 연결 상태를 기록하고, 인터페이스가 결국 연결된 것처럼 보이는지만 살피지 마세요.

VPN을 사용할 수 없을 때 직접 트래픽이 무엇을 할 수 있는지 정의하세요. 이는 클라이언트 재연결 여부와 별개의 정책 결정이며, 대부분의 배포는 첫 번째를 무시한 채 두 번째 질문에 답합니다. 답을 프로필 이름 옆의 배포 노트에 적으세요. 장애 중에 누군가 그것을 필요로 할 것이고, 재구성할 시간은 없을 것입니다.

한 플랫폼이 동의하지 않으면 서버 ID 검사를 사용하세요

프로필이 한 플랫폼에서 작동하는데 다른 플랫폼이 그 이름을 거부하면, 클라이언트가 실제로 보낸 식별자를 인증서가 가진 식별자와 비교하세요. 그 비교는 암호 목록을 바꾸는 것보다 이 사례 대부분을 더 빠르게 해결합니다.

테스트한 행렬을 구성 원본, 업데이트 절차와 함께 보관하세요. 오래된 클라이언트 지원이 끝나면 다음 감사가 찾도록 게이트웨이에 약한 호환성 설정을 숨겨 두는 대신 그 예외를 의도적으로 제거하세요. strongSwan의 IKEv2 문서는 교환이 어떻게 구성되는지에 대한 유용한 참고 자료입니다.