keepalive는 재연결이 아닙니다: 지금 겪는 장애로 고르세요

keepalive와 재연결은 같은 호흡으로 설정되지만 서로 다른 문제를 풀기 때문에, 하나를 조정해도 다른 하나가 고쳐지는 경우는 드뭅니다. keepalive는 작은 트래픽을 보내 상태 항목을 살려 두거나 상대가 응답을 멈춘 것을 알아챕니다. 재연결은 키, 주소, 경로까지 포함해 망가진 것을 걷어내고 관계를 다시 세웁니다. 이미 아는 손잡이가 아니라 장애에 맞는 방식을 고르세요. 두 가지 질문이 이를 결정합니다: 경로가 죽은 것인가, 아니면 상대 사이의 무언가가 경로를 잊고 있는가?

매핑이 문제일 때

몇 분의 침묵 뒤에야 죽는 터널은 보통 상대가 아니라 변환 항목을 잃습니다. WireGuard의PersistentKeepaliveNAT와 방화벽 상태를 위해 존재하며, 프로젝트 자체 노트도 그것을 상태 점검이 아니라 바로 그렇게 설명합니다. 수십 초 간격은 항목을 따뜻하게 유지하지만, 매초 보내는 패킷은 배터리 결정이지 신뢰성 결정이 아닙니다.OpenVPN같은 지점에ping와ping-restart로 도달해, 먼저 침묵을 알아채고 그다음에 행동합니다.

이 설정들은 프로토콜 사이에서 서로 바꿀 수도 없고, IKEv2의 죽은 피어 정책, OpenVPN의 ping 타이머, WireGuard의 keepalive는 같은 질문에 세 가지 문법과 세 가지 기본값으로 답합니다. 그래서 숫자를 그대로 옮기는 것은 조정의 옷을 입은 추측입니다.

관계가 사라졌을 때

상대가 주소를 바꾸거나 자격 증명이 만료되거나 원격 쪽이 재시작하면 작은 패킷은 수리가 아닙니다.재연결은 상태를 다시 세워야 합니다: 주소를 얻고, 경로를 다시 설치하고, 키를 다시 협상하며, 일부 배포에서는 사용자를 다시 인증합니다.

감독 없이 재연결하는 클라이언트는 인증서나 저장된 비밀을 보유합니다. 사람에게 물을 클라이언트는 아무도 없는 바로 그때 실패하며, 그것이 재연결이 중요했던 시나리오입니다. 이는 몇 달 전에 내린 설계 결정이지 장애 중에 바꿀 수 있는 설정이 아닙니다.

둘 다 증명하지 못하는 것

터널은 재연결되고 키와 경로를 갖추었어도 그 뒤의 서비스가 죽어 있으면 소용이 없습니다. keepalive는 서버가 몇 시간 전에 사라진 세션을 위해 매핑을 열어 둘 수 있는데, 정말 중요한 것이 사용할 수 없을 때 두 방식 모두 성공을 보고할 수 있습니다.

그래서 시험은 실제 요청에서 끝납니다. 관심 있는 간격이 지난 뒤 터널로 무언가를 보내고, 다음으로 설계한 장애를 따로 일으키세요——매핑의 경우 유휴 기간, 재연결의 경우 재시작이나 주소 변경입니다.

직접 트래픽을 막는 것은 별개의 결정

재연결 루프가 완전히 건강해도 애플리케이션이 조용히 일반 경로를 쓰고 있다면 그것은 장애가 아니라 누출입니다. 터널 밖으로 아무것도 나가지 않아야 한다는 요구라면 클라이언트 설정에 명시하고, 터널을 내린 뒤 무엇이 여전히 연결되는지 보며 증명하세요. 어느 방식도 그 동작을 함축하지 않으며, 재시도 규율을 아무리 갖춰도 확립되지 않습니다.

어떤 방식이 실행되었고 그 뒤 새 요청이 성공했는지 기록하세요. 다음 엔지니어에게 필요한 것은 그 두 가지 사실이며, 둘 다 상태 아이콘에는 보이지 않습니다. 클라이언트가 재연결했다는 로그 한 줄은 성공한 요청과 같지 않습니다.

방침을 쓰세요, 숫자만이 아니라

두 값을 한 문장에 담으세요——유휴 간격, 생존 임계값,무엇이 재구성을 촉발하는지, 그리고 재시도하는 동안 클라이언트가 무엇을 하는지. 그 문장이 없으면 앞으로의 모든 장애에서 keepalive가 너무 짧은지 재연결이 너무 느린지 같은 논쟁이 다시 열립니다.

제한에 관한 WireGuard 노트는 keepalive가 중간 장치를 위한 우회책이지 일반적인 생존 설계가 아님을 알려 줍니다. 해결할 수 없는 문제에 대응해 빈도를 올리기 전에 그 제한을 읽으세요.