IPsec 터널이 첫 CHILD SA 키 갱신까지만 동작하는 이유

터널이 올라왔고 ping이 응답했으며 모두가 승인했다. 네 시간 뒤 세션이 끊기고, 양쪽 피어가 제안 또는 키 교환 오류를 기록하며, 첫 추측은 네트워크에서 무언가 바뀌었다는 것이다. 아무것도 바뀌지 않았다. 트래픽을 실어 나르는 터널은 두 피어가 인증 방식과 첫 자식 연관을 보호하는 방식에 합의했다는 것만 증명했고, 갱신 시 요구할 키 교환에 대해서는 아무것도 증명하지 않았다. 불일치는 그 두 사건 사이의 틈에 자리한다.

연결되었다고 PFS 설정이 일치하는 것은 아니다

IKEv2에서는 첫 자식 연관이 인증 교환 중에 만들어지고, 그 키는 IKE 연관이 이미 만들어 낸 자재에서 파생된다. 그 자식을 위해 별도의 Diffie-Hellman 교환이 일어나지 않으므로, 갱신 시 그것을 요구하는 정책은 올라올 때 시험되지 않는다.

갱신은 다른 교환이다. 자식 연관의 키가 갱신될 때 피어는 제안에 적힌 그룹으로 새 키 교환을 수행할 수 있고, 그때가 그룹 설정을 처음 비교하는 순간이다. 그래서 합의하지 못한 두 피어가 인증하고 자식 연관을 설치해 트래픽을 통과시킨 뒤 갱신에서 실패할 수 있다.

제안 문자열에서 불일치가 숨는 곳

strongSwan에서는 그룹이 자식 제안에 덧붙기 때문에 aes256gcm16-prfsha256-ecp256 같은 문자열은 암호화 선택처럼 보이지만 키 교환 요구도 함께 담고 있다. 오직 aes256gcm16-prfsha256 만 제시하는 피어에는 그런 요구가 없고, 두 목록은 암호화에서 겹치지만 교환에서 어긋난다.

자식 제안과 IKE 제안을 별개의 목록으로 읽어라. IKE 목록에 나타난 그룹은 자식 목록에 대해 아무것도 말해 주지 않으며, 하나를 읽으면서 다른 하나를 편집하는 것이 이것을 놓치는 흔한 방식이다.

실패를 읽어라, 편집한 파일이 아니라

교환을 끝낸 notify를 찾아라. 수용 가능한 제안이 없다고 반환하는 자식 키 갱신은 제안 목록을 가리키고, 응답을 전혀 받지 못하는 갱신 요청은 경로나 듣기를 멈춘 피어를 가리킨다. 이 둘은 서로 다른 수정을 요구하며, 로그 한 줄의 문구가 둘을 갈라 준다.

디스크에 있는 것이 아니라 실행 중인 구성을 확인하라. 저장했지만 로드하지 않은 파일, 또는 다른 include에서 다시 읽은 연결은 눈에 보이는 파일을 아무리 편집해도 고칠 수 없는 불일치를 만든다.

모두 키 갱신이라 불리는 세 가지 사건

IKE 연관 키 갱신, IKE 재인증, 자식 연관 키 갱신은 각각 다른 제안 규칙을 가진 별개의 작업이다. 그중 하나에서 보고된 실패는 나머지에 대해 직접 아무것도 말해 주지 않으며, 이것들을 섞은 로그는 셋인데도 하나의 반복 고장처럼 읽힌다.

피어가 어떤 사건을 지목하는지 보고, 그 사건에 대해서만 제안을 확인하라. 목록 하나를 바꾸고 다시 로드한 뒤 같은 사건을 다시 강제하라. 로그가 재인증을 지목하면 읽어야 할 것은 IKE 제안이다. 자식 키 갱신을 지목하면 중요한 그룹은 자식 제안이 담고 있다.

갱신을 끄는 것은 해결이 아니다

키 갱신 시간을 영으로 두면 실패하는 교환이 억제되고, 터널은 해체되거나 피어가 재시작될 때까지 살아남는다. 당신이 산 것은 더 오래가는 키와, 마이그레이션·감사·벤더 업데이트 때 다시 만날 불일치다. 상대가 기대하는 정책을 훨씬 넘겨 늘린 수명도 마찬가지다.

대신 제안을 맞춰라. 양쪽 피어가 구현하는 그룹을 골라 양 끝의 자식 제안에 넣고, 갱신 정책은 조직이 실제로 요구하는 범위 안에 두어라.

실패한 교환으로 증명하라

정비 시간대에 자식 키 갱신 시간을 줄여 그 사건이 시간이 아니라 분 단위로 오게 하거나, 수동으로 자식 키 갱신을 일으킨 뒤 성공적인 갱신을 지켜보고 트래픽이 그 너머로 계속 흐르는지 확인하라. 왜냐하면 자식 연관은 설치하지만 응용 프로그램 흐름을 떨어뜨리는 새 핸드셰이크 는 다른 결함이기 때문이다.

그 뒤 정상 수명으로 되돌리고 실패한 기록과 성공한 기록을 모두 남겨라. 원하는 증거는 연결이 자기 수명 주기를 견딘다는 것이지, ping을 견뎠다는 것이 아니다.