up 및 down 훅으로 OpenVPN 클라이언트의 가동 시간을 측정하는 방법

대시보드는 연결이 얼마나 오래 유지되었는지 숫자를 요구하지만, OpenVPN 그런 값을 제공하지 않습니다. 클라이언트는 터널이 올라온 시각을 알고 있지만, 세션 상태가 사라지기 전에 누군가 그 순간을 기록해야만 합니다. 지원되는 위치는 up 훅이며, 저장할 가치가 있는 값은 형식화된 문자열이 아니라 원시 epoch 초입니다. 그 후의 모든 것은 산술이며, 숫자가 정직하게 유지되는지를 결정하는 몇 가지 순서 규칙이 더해집니다.

훅이 실제로 실행되는지 확인하세요

그 주위에 무엇이든 설계하기 전에 훅이 발동함을 증명하세요. 최소한의 클라이언트 구성에는 script-security 2 와 명시적인 경로 up 및 down 가 필요하며, 보안 줄이 없으면 OpenVPN은 스크립트 실행을 거부하고 그 사실을 분명히 말합니다. 동시에 up-restart 와 down-pre 를 추가해 재시작 및 해제 경로가 예측 가능하게 동작하도록 하세요.

훅의 첫 버전은 자기 환경을 파일에 덧붙이고 다른 일은 하지 않게 만들어, 빌드가 실제로 내보내는 변수 이름을 알 수 있습니다. 예를 들어 dev 와 script_type、 다른 버전에서 기억하는 이름 대신 실제 이름을 쓸 수 있습니다. 연결 한 번과 연결 해제 한 번을 실행한 뒤 파일을 읽으세요. 아무것도 나타나지 않으면, 절대 실행되지 않는 훅 위에 얹은 타임스탬프 설계가 몇 주 동안 모니터링 장애처럼 보이므로 여기서 멈추세요.

훅이 어떤 사용자로 실행되는지 확인하세요. user 와 group 가 설정되면 OpenVPN은 스크립트를 실행하기 전에 권한을 버리므로 root가 쓸 수 있는 디렉터리가 훅에는 닫혀 있을 수 있습니다. 경로는 자기 셸이 아니라 서비스의 관점에서 고르세요.

epoch 값을 하나 기록하고 의도적으로 지우세요

up 훅에 필요한 것은 다음 한 줄이며, date +%s > /run/openvpn-client.started, 경로는 인스턴스마다 조정합니다. epoch 값은 나중에 언어, 시간대, 형식에 대한 질문을 피하게 해주며, 모니터링 에이전트가 자기 시계와 비교할 수 있는 같은 숫자입니다.

지우는 것은 쓰는 것만큼 중요합니다. down 훅은 파일을 비우거나 제거해야 하며, down-pre 가 인터페이스가 닫히기 전에 그렇게 하므로 이미 사라진 터널을 파일이 설명하는 창이 없어집니다. up-restart 는 내부 재시작에서 타임스탬프를 새로 고치며 원래 값을 그대로 두지 않습니다. 그 짝이 없으면 ping 시간 초과 후 재시작 은 터널이 다시 설정되는 동안 계속 올라가는 숫자를 만듭니다.

수명이 알맞은 위치를 고르세요. /run 아래의 파일은 재부팅 시 사라지며 이는 현실과 맞지만, 반면 /tmp 아래의 파일은 예측할 수 없게 정리될 수 있고 설정 디렉터리의 파일은 오해를 부르는 방식으로 살아남습니다. 서비스 사용자와 모니터링 판독자만 읽을 수 있도록 권한을 설정하세요.

로그 줄을 믿지 않고 가동 시간을 계산하세요

저장된 초를 읽고, 현재 초를 읽고, 빼세요. 파일이 없거나 비어 있으면 정직한 답은 터널이 활성 상태가 아니라는 것이지 가동 시간이 영이라는 것이 아닙니다. 두 상태는 서로 다른 경보를 일으켜야 하므로, 원시 초는 모니터링 페이로드에 두고 날짜와 시간은 표시 계층에서 형식화하세요. 내보내기 도구 안에서 반올림하는 형식기는 사고 중에 누군가 원할 정밀도를 버립니다.

로그 타임스탬프를 파싱하는 것은 유혹적인 지름길이지만, 형식은 설정된 옵션을 따르고, 로테이션은 이력을 지우며, 재연결은 하나의 연속된 터널이 아니라 별개의 세션으로 나타나므로 세 가지로 실패합니다. 훅은 사건을 일어난 그 순간에 한 번만 기록합니다.

검사가 다른 호스트에서 실행되면 지속 시간 대신 타임스탬프를 보내 판독자가 자기 시계를 적용하게 하세요. 그러면 작은 음수 결과는 고장 난 훅이 아니라 시계 차이로 읽힙니다.

재연결, 재시작, 여러 인스턴스를 다루세요

호스트 하나에 터널 둘이면 파일 둘이 필요하며, 키는 서비스가 이미 쓰는 인스턴스 이름입니다. 경로를 공유하면 가장 최근 연결이 모든 프로필의 시작 시각을 덮어쓰고, 증상은 두 번째 터널이 시작될 때 숫자가 뒤로 튀는 것입니다.

재연결 동작은, 그럴듯한 설계가 조용히 틀린 것을 보고하는 곳이므로 따로 시험할 가치가 있습니다. 피어를 끊거나 프로세스에 신호를 보내 재시작을 강제한 뒤 인터페이스 상태와 파일을 비교하세요. 터널이 돌아온 순간 타임스탬프는 앞으로 나아가야 합니다.

서버 쪽에서 상태 파일은 클라이언트마다 connected-since 값을 담고 있으며, 서버가 그 피어를 마지막으로 본 때가 언제인지라는 다른 질문에 답합니다. 설명하는 세션과 함께 사라지므로 대체가 아니라 교차 확인에 쓰세요. 두 측정 모두 터널 뒤 애플리케이션의 건강에 대해서는 아무 말도 하지 않습니다.

순서 버그를 잡는 세 가지 검사를 실행하세요

정상 연결, 강제 재연결, 깨끗한 중지를 시험하고 각각 뒤에 인터페이스 목록과 파일을 함께 읽으세요. 깨끗한 중지 후에도 남아 있는 타임스탬프, 또는 인터페이스 목록에 없는 터널을 주장하는 파일은 훅 순서를 곧바로 가리킵니다. root 셸은 다른 파일을 보고 자신 있게 틀린 답을 낼 수 있으므로, 검사는 서비스 사용자로 서비스의 경로에서 실행하세요. 그다음 느린 폴러가 파일을 읽게 하고 절대 쓰지 않는지 확인하세요.

육십 초마다 하는 폴링이 경보를 감당하며, 어떤 훅도 그 폴러가 살아 있다고 기대서는 안 됩니다. 이 두 책임을 분리해 두면 어느 쪽을 다시 배포해도 숫자는 신뢰할 수 있습니다.