OpenVPN의 keepalive와 systemd 재시작, 어느 쪽이 복구할까

터널에서는 세 가지 다른 일이 잘못될 수 있고, 각각은 서로 다른 대응을 요구합니다. 상대가 응답을 멈추거나, 데몬 프로세스가 죽거나, 터널 뒤의 애플리케이션이 서비스를 멈춥니다. 이 중 어느 하나에서 서비스를 재시작하는 구성은 세심한 감독이 아니라, 서로 무관한 고장에 하나의 둔탁한 조치를 적용하는 것입니다. 각 메커니즘이 실제로 무엇을 관찰할 수 있는지 비교하면 역할 분담이 분명해집니다.

하나처럼 보이는 세 가지 고장

상대의 침묵은 반대편이 전송을 멈췄다는 뜻이고, OpenVPN은 하트비트를 스스로 소유하므로 그것을 직접 감지할 수 있습니다. 프로세스의 죽음은 데몬이 종료되었다는 뜻이며, 서비스 관리자는 알아채지만 OpenVPN은 알 수 없습니다. 애플리케이션 고장은 터널은 정상이고 그 뒤의 무언가가 정상이 아니라는 뜻이며, 다른 두 메커니즘 중 어느 것도 그것을 알 방법이 없습니다. 각각은 다른 대응이 필요하고, 어느 것도 터널이 살아 있음을 알아채는 것과 같지 않습니다.

이것들은 서로 다른 계층의 다른 신호이며, 각각은 추측 없이 행동할 수 있는 소유자가 있습니다. 이들을 섞으면 해석할 수 없는 증상에 재시작하는 시스템이 됩니다.

타이머를 바꾸기 전에 세 가지 사례를 적어 두십시오. 목록 자체가 보통 하나의 메커니즘에 세 가지를 모두 맡기고 있음을 보여줍니다.

keepalive가 실제로 무엇으로 확장되는가

keepalive 지시자는 약칭이며, 확장은 모드에 따라 다릅니다. 서버에서 keepalive 10 60은 십 초마다의 로컬 ping, 120초의 로컬 재시작 제한 시간, 그리고 클라이언트로 전달되는 10과 60 값이 됩니다. 서버의 제한 시간은 의도적으로 두 배가 되는데, 서버가 포기하기 전에 클라이언트가 재시작할 기회를 얻기 위해서입니다. 프로필의 약칭이 아니라 실행 중인 구성에서 확장된 형태를 읽으십시오.

이 두 배가 바로 양쪽 끝이 육십 초 후에 재시작한다는 어떤 설명도 틀린 이유입니다. 경로가 나빠질 때 양쪽 끝이 함께 흔들리지 않는 이유도 설명합니다.

하트비트는 OpenVPN의 상대 트래픽이며, 어떤 공용 호스트에 대한 ICMP 검사가 아닙니다. 응답은 터널의 먼 쪽이 살아 있음만 증명합니다. 사용자가 실제로 필요로 하는 데이터베이스나 웹 서비스에 대해서는 아무것도 말하지 않습니다.

Restart=on-failure가 지켜보지 않는 것

덮어쓰기를 추가하기 전에 설치된 유닛을 읽으십시오. Restart=on-failure은 문서화된 프로세스 고장 조건에 반응하며, 이는 연결 상태를 감시하는 것과 같지 않습니다. 내부 재연결이 시작되었다고 해서 발동하지 않으며, 정상 종료는 충돌과 의미가 다릅니다.

이 구분은 내부 재시작이 같은 프로세스를 살려 두기 때문에 중요합니다. 유닛은 아무것도 보지 못하고, 터널은 스스로 회복하며, 그것이 올바른 결과입니다.

RestartSec와 시작 제한을 의도적으로 설정하십시오. 그렇지 않으면 충돌 루프가 게이트웨이를 타격해 실제 오류를 재시작 메시지 아래 묻어 버리고, 발동한 재시작 제한은 유닛을 실패 상태로 남겨 그것은 보이지만 무제한 루프는 보이지 않습니다.

ping-restart와 ping-exit는 서로 바꿀 수 없습니다

ping-restart은 OpenVPN의 내부 재시작을 일으키고 프로세스를 유지합니다. ping-exit는 같은 종류의 제한 시간에 프로세스를 끝내며, 결정을 서비스 관리자에게 넘깁니다. 둘은 상호 배타적이고, 두 번째를 고르면 복구의 소유자가 바뀝니다. 차이는 누가 다시 시도할지 결정하는 것과 그 시도에서 얼마나 많은 상태가 살아남는가입니다.

제한 시간에 종료를 고른다면 유닛에는 맞는 재시작 정책과 종료 상태 처리가 필요합니다. 그렇지 않으면 생존성 고장이 영구 정지처럼 보이고, 지속성 옵션은 내부 재시작을 넘어 인터페이스와 경로를 보존할 수 있지만 프로세스 종료를 넘어서는 보존하지 못합니다.

배포마다 하나의 수명 주기를 고르고 이유를 적으십시오. 두 지시자를 모두 가진 프로필은 결정하지 않은 프로필입니다.

각 고장을 별개의 사례로 시험하십시오

승인된 시간 창에서 조용한 상대, 죽인 데몬, 사용할 수 없는 애플리케이션을 모사하고, 어떤 복구가 발동했는지 확인하십시오. 조용한 상대는 내부 재연결을, 죽인 프로세스는 유닛 재시작을, 애플리케이션 중단은 둘 다 아니어야 합니다. 두 사례가 같은 동작을 낳는다면 소유권은 여전히 섞여 있습니다.

반복되는 복구도 수리가 아닙니다. 거부된 자격 증명이나 같은 유효 이름을 공유하는 두 클라이언트는 계속 서로를 대체할 것이고, 더 빠른 타이머는 그 흔들림을 더 빠르게 만들 뿐입니다.