IKEv2의 죽은 피어 탐지는 앱을 검사하지 않는다

IKEv2 생존 확인은 보호된 제어 관계에서 상대 피어가 여전히 응답하는가라는 한 가지 질문만 합니다. 내부 애플리케이션이 건강한지, 게이트웨이 뒤에 경로가 있는지, 브라우징이 빠르게 느껴지는지는 측정하지 않습니다. 터널 뒤의 모든 쓸모 있는 것이 실패해도 이 확인은 통과할 수 있습니다.

타이머를 바꾸기 전에 두 종류의 증거를 따로 읽으십시오.

생존 확인이 실제로 묻는 것

생존 교환은 이미 설정된 IKE 보안 연관 안에서 전송되며 구성된 창 안에 응답을 기대합니다. 성공은 피어의 IKE 구현이 여전히 존재하고 여전히 대화할 의향이 있다는 것입니다. 트래픽을 나르는 자식 보안 연관에 대해서는 아무 말도 하지 않고, 게이트웨이 너머의 라우팅에 대해서도, 터널을 연 목적의 서비스에 대해서도 아무 말도 하지 않습니다. 이는 세 가지 별개의 질문이며 세 가지 별개의 실패 방식이 있습니다.

세션이 조용해질 때 어디를 볼지 결정하는 것이 그 차이입니다. 데이터 경로가 끊긴 동안에도 계속 응답하는 피어는 정책, 라우팅 또는 하위 서비스를 가리킵니다. 응답을 멈추는 피어는 도달 가능성이나 원격 끝의 자체 상태를 가리킵니다.

브라우저보다 보안 연관을 먼저 읽으십시오

데몬에 물으면 제어 상태와 데이터 상태가 따로 나열되고, 카운터는 무언가 시도되었는지까지 알려 줍니다. 한 번도 설치되지 않은 자식 연관은 설치된 뒤 패킷 전달을 멈춘 연관과 전혀 달라 보이지만, 둘 다 같은 사용자 불만을 만듭니다.

ipsec statusall | head -n 40
swanctl --list-sas
ip xfrm state | grep -E 'proto|mode'

불만이 생긴 순간의 카운터와 함께 상태 이름을 티켓에 그대로 적으십시오. 터널 다운 같은 설명은 두 연관 중 어느 것이 끝났는지를 숨기며, 보통 그것이 유일하게 남길 가치가 있는 사실입니다.

경로 실패는 죽은 피어와 똑같이 보인다

게이트웨이는 제어 교환에 응답할 수 있지만 그 사이 사설 서버가 오프라인이거나, 전달 경로가 없거나, 내부 이름 해석이 완전히 실패할 수 있습니다. 클라이언트 입장에서는 그 모두가 세션은 살아 있고 목적지는 살아 있지 않은 것으로 보입니다. 돌아오는 경로는 원격 측의 비대칭 라우팅이 한 방향에서만 침묵을 만들기 때문에 가는 경로만큼 주의 깊게 확인하십시오.

터널이 살아 있는지 시험하는 대신 의도한 애플리케이션을 직접 시험하고 그것이 시도한 주소를 지목하십시오. 게이트웨이로의 핑은 게이트웨이가 응답한다는 것을 증명하지만, 애플리케이션이 응답했다는 것은 결코 증명하지 못했습니다. 애플리케이션이 시도한 정확한 주소를 기록하십시오. 그 문자열은 나중에 수색을 좁히며, 티켓이 보통 빠뜨리는 유일한 사실입니다.

타이머를 진단에서 빼두십시오

탐지 간격을 줄이는 것은 성능 변경이 아니며 용량을 늘리지 않습니다. 패킷 손실 아래에서는 실패가 얼마나 빨리 인식되는지를 바꾸며, 이는 아무것도 나아지지 않은 채 증상을 다르게 보이게 할 수 있습니다. 먼저 실패의 실제 시각을 기록하고, 그다음 실제로 가진 링크에 허용치가 잘못되었는지 판단하십시오.

NAT 매핑 갱신도 같은 범주에 속합니다. 변환된 경로를 쓸 수 있게 유지할 뿐이며, 원격 애플리케이션이 동작한다는 증거는 아닙니다.

완전한 복구 정책은 피어가 죽었다고 선언될 때 클라이언트가 무엇을 해야 하는지, 즉 재시작, 종료, 유지를 정하고, 그동안 다른 트래픽이 무엇을 해도 되는지 정합니다. 그것이 없으면 같은 사건이 분기마다 처음부터 다시 진단됩니다.