IKEv2: 키 갱신과 재인증의 차이 — 연결이 나중에 끊기는 이유

터널은 아침에 올라와 몇 시간 동안 동작한다. 그러다 끊기고, 한 번의 재시도 끝에 다시 연결되며, 다음 날에도 같은 일을 반복한다. 네트워크에는 아무 변화가 없었고 누구도 비밀번호를 건드리지 않았다. 갱신 경계에서 실패하는 세션은 보통 두 가지 다른 작업 중 하나를 넘고 있으며, 그중 하나만 자격 증명을 다시 확인한다. 어느 쪽이 발동했는지 읽는 것이 진단의 전부다.

밖에서 보면 비슷해 보이는 두 작업

키 갱신은 프로토콜이 정의한 교환 범위에서 보안 연관 또는 키 자료를 교체한다. 인증은 반복되지 않으므로 세션 시작 시 수용된 신원은 그대로 이어진다.

재인증은 더 나아간다: 새로 인증된 관계를 수립하므로 자격 증명이 다시 평가된다. 만료되었거나, 폐기되었거나, 디렉터리에서 변경된 모든 것이 그 순간 드러난다.

키 갱신이 실제로 교체하는 것

IKEv2는 수명 주기가 분리된 두 종류의 연관을 유지한다. IKE SA는 제어 채널을 보호하고 CHILD SA는 실제 트래픽을 보호한다. 하나를 갱신하는 것은 클라이언트를 다시 연결하는 것과 같은 말이 아니다.

이 분리가 익숙한 패턴을 설명한다: 트래픽이 잘 흐르다가 CHILD SA가 갱신되고, 몇 주 전에 한쪽에서 2단계를 편집했기 때문에 제안이 더 이상 맞지 않는다. 그 변경은 갱신이 그것을 시험할 때까지 무해하게 그 자리에 있었다.

수명 불일치도 같은 방식으로 동작한다. 먼저 한계에 도달한 쪽이 교환을 시작하고, 다른 쪽은 그것을 받아들여야 한다.

재인증이 다시 평가하는 것

재인증에서는 로그인 시 유효했던 클라이언트 인증서가 이제 만료되었을 수 있다. 폐기된 자격 증명, 교체된 비밀번호, 사용할 수 없는 두 번째 요소가 모두 여기서 드러나며, 갱신 시점이 아니다.

그래서 모든 수명을 늘리는 것이 수정처럼 느껴지지만 수정이 아니다. 검사를 통과하는 대신 미룬 것이다. 다음 갱신은 같은 결함과 함께, 그것을 알아차릴 더 짧은 중단 창을 가지고 온다.

일부 구현은 재인증 중에 이전 상태와 새 상태를 겹친다. 다른 구현은 짧은 공백을 만든다. 그래서 두 공급업체에서 동일한 설정이 서로 다른 사용자 경험을 줄 수 있다. 표준이 그렇게 정한다고 가정하지 말고 동작을 시험하라.

무엇이든 바꾸기 전에 타임스탬프를 읽어라

실패 순간을 연관의 이전 및 이후 상태와 함께 기록하라. 이전 연관이 인증 교환 없이 교체되었다면 갱신 경계에 있었던 것이다. 실패 직전에 AUTH 교환이 나타난다면 재인증에 있었던 것이다.

strongSwan은 이를 별도 설정으로 노출한다: rekey는 키 갱신을 제어하고, reauth는 새 인증이 일어나는지를 제어하며, margin 값은 각각이 만료 전 얼마나 먼저 시작할지를 결정한다. 키 갱신 문서 가 상호 작용을 설명하며, 포럼 게시물에서 수명을 복사하기 전에 읽을 가치가 있다.

이 모든 것을 단순한 네트워크 손실과 구분하라. 끊긴 링크는 죽은 피어 감지 이벤트나 재전송 폭풍을 만들지, 제안이 일치하는 깔끔한 교환을 만들지 않는다.

실패한 것을 바꿔라

자격 증명 거부라면 신원 문제를 고쳐야 한다: 인증서를 갱신하고, 계정을 복원하고, 요소를 다시 등록하라. 제안이나 수명 불일치라면 양쪽의 매개변수를 비교해야 한다.

증상을 피하려고 수명을 늘리는 것은 항상 효과가 있었던 것처럼 보이고 결코 효과가 없는 유일한 선택지다.

통제된 갱신을 시험하라

하루를 기다리는 대신 갱신을 강제하라. 그다음 배포가 지원한다면 재인증으로 반복하고, 양쪽 끝을 관찰하라.

성공적인 최초 로그인은 이것들 중 아무것도 연습하지 않는다. 그 뒤의 수명 주기가 바로 이런 배포가 실제로 깨지는 지점이다.