바쁜 IPsec 터널이 일찍 키를 갱신하는 이유: 시간 대 볼륨 한도

대략 오십 분마다 혼잡한 링크의 터널이 몇 초 동안 끊기며, 첫 번째 용의자는 시계입니다. 연결은 시간 한도나 바이트 수로 끝날 수 있으며, 어느 경계가 먼저 오든 그것이 연결을 은퇴시킵니다. 실제 트래픽을 나르는 링크에서는 볼륨 한도가 설정된 한 시간이 끝나기 훨씬 전에 발동할 수 있습니다. 따라서 «너무 이르다»는 시계에 대한 진술이지 연결에 대한 것이 아닙니다.

인터페이스가 아니라 연결이 세는 것을 세십시오

인터페이스의 바이트 합계, 대시보드의 결합 처리량, 연결 자체의 카운터는 세 개의 별도 숫자이며, 그중 하나만 한도와 비교됩니다. 들어오는 연결과 나가는 연결을 식별자와 함께 따로 기록하면 한 방향을 건드리는 키 갱신이 수수께끼가 아니라 방향성 사건으로 나타납니다. 연결 카운터도 키 갱신 시 다시 시작되므로 인터페이스에서 가져온 합계는 늘어나는 반면 중요한 값은 초기화됩니다.

계산을 한 번 해 두면 규모의 차수가 임의로 느껴지지 않습니다. 분당 일정한 128 메비바이트로 소진되는 일 기비바이트의 계산된 예산은 팔 분 만에 고갈되며, 이는 단위 변환이지 터널의 측정이 아닙니다. 결과 숫자가 시간 한도보다 훨씬 낮다면 볼륨이 메커니즘이며 시계를 들여다보는 것으로는 간격이 설명되지 않습니다. 훨씬 높다면 바이트 한도가 방아쇠가 아니며 탐색은 다른 곳에 속합니다.

소프트 임계값과 하드 임계값은 서로 다른 사건입니다

소프트 임계값은 하드 한도가 연결을 끝내기 훨씬 전에 교체를 요구하며, 구현은 설정한 것 위에 자체 여유와 무작위화를 더합니다. 그래서 관측된 간격은 거의 결코 둥근 숫자가 아닙니다. IPsec 아키텍처은 시간과 바이트 수로 표현된 수명을 두 가지 임계값 유형과 함께 설명하며, 더 이른 만료가 우선합니다. 인쇄된 수명 하나를 일정표로 취급하면 여유만큼 틀립니다.

여유는 구현에 속하며 여러분의 의도에 속하지 않으므로, 실제 정책은 파일 속 숫자에서 추론하지 말고 실행 상태에서 읽으십시오. 증상을 잠재우려고 한도를 최대까지 늘리려는 유혹에 저항하십시오: 일정대로 키를 갱신하는 터널은 설계대로 동작하며, 더 긴 수명은 사건을 미룰 뿐 침해된 키를 더 오래 사용 가능하게 둡니다. 교체 자체가 실패할 때 한도는 책임이 아니라 전령입니다.

실행 상태에서 실제 수명을 읽으십시오

strongSwan에서 swanctl --list-sas은 연결 요약을 키 갱신 및 수명 시간과 함께 출력하므로 데몬이 적용하려는 값이 추측 없이 보입니다. 데몬 보기가 없는 Linux 호스트에서는 ip xfrm state이 구성된 소프트 및 하드 바이트와 패킷 한도를 현재 카운터 옆에 보고합니다. 그 두 판독값은 서로 다른 질문에 답하며 둘 다 티켓에 남길 가치가 있습니다.

swanctl --list-sas
ip -s xfrm state

하드 한도 아래 여유로 시작하는 교체는 정상이고 결코 시작하지 않는 교체는 그렇지 않으므로, 인쇄된 소프트 임계값을 측정한 간격과 비교하십시오. 데몬이 한 수명을 보여 주고 커널 상태가 다른 수명을 보여 준다면 서로 맞지 않는 두 계층을 보고 있는 것이며, 그것 자체가 발견입니다.

SA를 교체하는 교환을 지켜보십시오

세 가지 갱신은 실패 방식이 다르므로 분리해 두십시오: IKE SA 키 갱신은 새 제어 연결을 만들고, CHILD SA 키 갱신은 데이터 연결을 교체하며, 재인증은 신원 교환을 반복합니다. IKEv2에서는 각 피어가 하나의 공유 값을 협상하는 대신 자체 수명을 결정하므로 여러분이 시작하지 않은 교환은 정상입니다. perfect forward secrecy 불일치는 새 child SA가 정확히 키 갱신 간격에서 죽는 흔한 원인이며, 누군가 제안을 읽기 전까지는 정확히 타이머 결함처럼 보입니다.

이전 연결을 후속 연결 및 그것을 만들어 낸 교환과 비교하십시오. 식별자가 사라지는 것은 일상적 교체입니다; 거부된 제안, 빠진 응답, 사용 가능한 후속 상태의 부재는 다른 소유자의 다른 사건입니다. 버전별 노트, 피어의 제안, 협상된 수명이야말로 로그가 순환한 일주일 뒤에도 사건을 읽을 수 있게 하므로, 무엇이든 바꾸기 전에 그 증거를 보존하십시오.

숨기지 말고 갱신을 증명하십시오

배포는 여러분에게 일어나는 갱신이 아니라 계획한 갱신을 통과하여 받아들이십시오. 유지보수 창 안에서 키 갱신을 한 번 강제한 다음, 이후 양방향이 데이터를 나르고 애플리케이션 결과가 변하지 않았는지, 터널 표시가 녹색인 것만이 아니라 확인하십시오. 어떤 한도가 발동했고 어떤 교환이 관련되었는지 기록하십시오.

그런 형태의 결론은 검증을 견디지만, 연결을 한나절 조용해 보이게 한 변경된 타이머 값은 견디지 못합니다. 타이머만 움직였다면 증거도 함께 움직였습니다.