iOS IKEv2에서 strongSwan으로: 프로포절이 선택되지 않을 때 목록 고치기

iPhone이 터널을 올리면 게이트웨이는 아무것도 답하지 않고 휴대폰은 일반적인 실패만 보여 준다. strongSwan 로그는 더 구체적이다: no proposal chosen. 이 메시지는 허용되는 암호 스위트 목록 두 개가 한 번도 겹치지 않아 인증이 시작되기 전에 교환이 끝났다는 뜻이다. 짝 맞추기 문제이며, 해결책은 두 목록을 교차시키는 것이다.

게이트웨이가 정책을 선언하는 곳

strongSwan은 설정 파일에 정책을 적고, 끝에 붙는 느낌표가 그 정책을 읽는 방식을 결정한다. 느낌표가 있으면 목록은 완전하며, 그 항목만 받아들이고 다른 것은 받지 않는다. 없으면 같은 줄은 선호 순서가 되고 데몬은 의도하지 않은 것을 고를 수 있다. 같은 클라이언트에 대해 둘의 동작이 다르므로 무엇이든 번역하기 전에 어떤 형식이 배포되어 있는지 물어야 한다. 느낌표까지 포함한 정확한 줄을 기록하고 그것에 대고 시험하라.

더 넓은 목록을 제시하는 클라이언트도 양쪽에 조합 하나만 겹치면 고정된 게이트웨이에 접속할 수 있다. 일어날 수 없는 것은 고정된 집합 밖에서의 협상이다.

그래서 다른 VPN 앱에서 복사한 프로파일이 되는 곳에서 내 것이 안 되는 경우가 있는데, 그 앱은 다른 목록을 실어 보냈기 때문이다.

이름은 같아야 하고, 더 좋아지면 안 된다

strongSwan의 값을 iOS로 옮길 때 사람을 잡는 번역이 둘 있다. IKE 프로포절에 SHA1로 적힌 무결성 알고리즘은 잘린 형태로 전달되며 iOS는 그것을 .SHA96이라고 부른다. modp1024로 적힌 Diffie-Hellman 그룹은 그룹 2이고 iOS는 그것을 .group2라고 부른다. SHA-256이나 그룹 14로 바꾸어도 옛 쌍만 받아들이는 게이트웨이와는 협상되지 않는다. 클라이언트는 더 강한 알고리즘이 아니라 같은 알고리즘을 적어야 한다.

NEVPNProtocolIKEv2에서 그 값을 명시적으로 설정하라. 기본값은 바꾸려는 프로파일보다 넓거나 좁을 수 있고, 그 차이는 핸드셰이크가 실패할 때에야 드러난다.

자식 프로포절은 더 늦게, 더 조용히 실패한다

자식 보안 연계도 IKE와 함께 구성하라. IKE 매개변수만 맞으면 터널은 인증을 통과한 뒤 트래픽을 나르지 않는데, 이는 거부보다 훨씬 조용한 실패다. 자식의 암호화, 무결성, 그룹, 수명을 같은 단계에서 설정하라. 클라이언트 수명은, 더 길게 고집하면 다른 원인에서 같은 no proposal chosen 메시지가 나오므로, 게이트웨이 값 이하로 유지하라. 그곳의 불일치는 로그의 IKE 불일치와 똑같이 보인다.

설정을 보는 김에 프로파일이 인증서로 인증하는지 공유 비밀로 인증하는지 확인하라. 프로포절 거부와 인증 거부는 다른 줄에 나타나며, 잘못된 쪽을 고치면 하루가 날아간다. 변경할 때마다 새 연결로 시험하되, 캐시된 상태가 어느 매개변수가 움직였는지 감추므로 한 번에 변수 하나만 움직여라.

레거시 스위트는 필요한 동안만 남겨라

SHA-1을 1024비트 그룹과 함께 고정하는 것은 다리이지 목적지가 아니다. 둘 다 사용 중단되었고 더 새로운 클라이언트는 아예 거부할 수 있으며, 그러면 당신 쪽 변경 없이 다음 기기에서 프로파일이 실패한다. 고정을 임시로 취급하고 기록에도 그렇게 적어라.

strongSwan이 당신 것이라면 현대적 프로포절을 추가하고 레거시 항목은 옛 기기를 위해 남긴 채 양쪽이 위로 협상하게 하라. 데몬의 상태 출력을 읽어 각 연결이 실제로 어느 스위트를 썼는지 확인하라. 현대적 쌍이 확인되면 클라이언트 쪽 고정을 제거하라. 터널이 올라온 것만으로는, 은퇴시키려던 스위트로 올라올 수도 있으므로 증거가 부족하다. strongSwan IKEv2 문서에 프로포절 구문과 strict 표식이 설명되어 있다.