상태 표시등 하나만 믿지 말고 라우터 VPN을 모니터링하세요

상태 페이지는 연결됨이라고 하고 표시등은 초록색이지만 사무실은 파일 서버에 도달하지 못합니다. 이 사실 중 하나는 터널에 관한 것이고 다른 하나는 그 안을 지나는 경로에 관한 것입니다. 둘 다 모니터링하는 것이 조치할 수 있는 경보와 무시하는 법을 배우는 경보의 차이입니다.

피어에서 바깥쪽으로 다섯 가지 점검을 순서대로 진행합니다.

점검 1: 피어 또는 연결 상태

각 프로토콜은 자체 상태를 노출합니다. WireGuard는 wg show 를 통해 피어별 최신 핸드셰이크와 전송 카운터를 보여줍니다. OpenVPN은 세션 상태를 상태 파일이나 관리 인터페이스에 쓰고, IPsec은 ipsec statusall 같은 도구로 보안 연결을 노출합니다. 함정은 타임스탬프를 판정으로 읽는 것이며, 보낼 것이 없는 유휴 WireGuard 피어가 최근에 핸드셰이크하지 않는 것은 장애가 아닙니다.

누군가를 부르기 전에 타임스탬프를 예상 트래픽과 keepalive 설정과 비교하세요.

점검 2: 선택된 경로

터널 인터페이스가 존재하더라도 그 안으로 아무것도 라우팅되지 않을 수 있습니다. 관심 있는 목적지에 대해 전달 테이블을 확인하고, 터널 자체의 서브넷을 보지 마세요. 접두사가 없거나 다른 곳을 가리키면 피어 상태는 무관합니다.

그 점검은 상태 표시등이 결코 보여주지 않는 고장을 잡아냅니다.

유용한 두 번째 점검은 원본 주소도 비교합니다. ip route get 10.20.5.10 는 다음 홉, 인터페이스, 기본 원본을 반환하며, 잘못된 원본은 원격 끝에서 반환 트래픽을 끊기에 충분합니다. 예상 삼중항을 한 번 기록하고, 어떤 요소든 바뀌면 경보를 울리세요. 그 한 줄이 NAT 변경, 인터페이스 변동, 정책 라우팅 오류를 잡아냅니다.

점검 3: 허용된 애플리케이션 경로

실제 요구 사항을 대표하는 것을 시험하세요. 라우터에서 시작한 핑은 라우터 자체의 주소와 정책에서 나가며, 이는 전달되는 LAN 트래픽과 다를 수 있고, 많은 호스트가 ICMP를 제한합니다. 요구 사항이 사설 서비스라면 그 서비스를 실제 포트에서 시험하세요.

프로브 양을 적당히 유지하세요. 모니터링 루프가 측정하는 트래픽 자체가 되어서는 안 됩니다.

점검 4: 무엇이 언제 바뀌었는가

WAN 변경, 키 갱신, 경로 철회, 애플리케이션 실패를 하나의 타임라인에서 연관 지으세요. 터널 장애와 일반 인터넷 접속을 조용히 복구하는 대체 경로는 동일한 사용자 보고와 정반대의 진단을 낳기 때문에 구분해야 합니다. 시간대 오류는 순서를 뒤집으므로 비교 전에 정규화하세요. 네 가지 점검을 원인으로 바꾸는 것이 바로 타임라인입니다.

로그는 전환을 위해 보존하고, 페이로드를 위해 보존하지 마세요.

점검 5: 경보는 경계를 지목해야 합니다

VPN이 다운됐다고 말하는 경보는 절반의 경우 사람을 잘못된 곳으로 보냅니다. 피어 핸드셰이크가 십이 분째 오래됐다, 10.20.0.0/16 경로가 없다, 또는 포트 445 로의 프로브가 실패한다고 말하는 경보는 특정 점검을 가리킵니다.

페이로드를 훑는 대신 운영 카운터를 유지하세요. 카운터는 필요하지 않은 콘텐츠를 수집하지 않고 모니터링 질문에 답합니다.

그리고 다음에 무슨 일이 일어날지는 페일오버 정책이 결정하게 하세요. 모니터링은 어느 경계가 실패했는지 식별해야 하며, 프로브가 실패할 때마다 광범위한 우회를 허용해서는 안 됩니다. OpenVPN 2.6 설명서는 첫 번째 점검을 스크립트 가능하게 만드는 상태 파일과 관리 인터페이스를 문서화합니다.