플로팅 VPN 백업 경로가 인계하지 않음: 페일오버 점검 목록

플로팅 VPN 경로가 구성되어 있고 백업 거리가 기본 경로보다 크지만 아무것도 움직이지 않습니다. 또는 움직였다가 몇 분 뒤 되돌아오는데 무선 링크는 여전히 끊겨 있습니다. 두 경우 모두 관심 있는 장애가 아닌 다른 무언가가 경로 적격성을 결정하고 있습니다.

이 점검을 순서대로 수행합니다. 각각 정지 조건이 있고, 실패한 점검은 뒤따르는 점검으로 구제할 수 없습니다. 예제는 RouterOS 구문을 사용하는데, 거리와 게이트웨이 도달 가능성, 재귀적 다음 홉이 그곳 구성에서 모두 보이기 때문입니다. 다만 순서 자체는 추적된 정적 경로가 있는 모든 라우터에 적용됩니다.

백업이 감당해야 할 장애를 이름 붙이기

«기본 경로가 다운»은 네 가지 다른 관측입니다. 피어를 잃는 라디오, 캐리어를 잃는 인터페이스, 응답을 멈추는 원격 게이트웨이, 동작을 멈추는 애플리케이션은 라우터의 자리에서 모두 다르게 보입니다. 누군가 거리 값을 바꾸기 전에 설계가 어느 것에 대한 것인지 적어 두십시오.

다음으로 독립성을 확인합니다. VPN의 외부 전송이 같은 무선 경로를 지나거나, 같은 상위 회선을 공유하는 액세스 링크를 지난다면 백업은 두 번째 장애 도메인이 아니며 필요한 바로 그때 다운됩니다. 종이 위에서 기본 케이블을 뽑아 보십시오. 터널 자체의 전송이 함께 죽는다면 플로팅 경로는 구성 실수만 감당하고 장애는 감당하지 못합니다.

거리에게 무언가를 감지하라고 요구하는 것을 멈추기

거리가 클수록 경로의 선호도는 낮아집니다. 그게 전부입니다. 기본 정적 경로가 적격인 동안 플로팅 경로는 비활성으로 남고, 이는 버그가 아니라 올바른 동작입니다. 장애는 기본 경로가 철회되거나 도달 불가로 표시될 때만 보입니다.

정적 경로에는 명시적 추적기가 필요합니다:

/ip route
add dst-address=10.20.0.0/24 gateway=192.0.2.1 distance=1 check-gateway=ping
add dst-address=10.20.0.0/24 gateway=wg-backup distance=10

이것이 무엇을 시험하는지 읽어 보십시오. 목적지가 아니라 다음 홉입니다. 로컬 쪽에서는 여전히 응답하지만 그 너머로의 전달이 끊긴 라디오는 기본 경로를 활성으로 유지합니다. 이것이 조용한 경우이며 거리와 게이트웨이 점검으로는 잡지 못합니다. 그 경우가 중요하다면 감지는 먼 쪽을 관찰하는 무언가에서 와야 합니다. 라우팅 프로토콜 인접성, 또는 경로와 결과 규칙을 직접 정의한 프로브입니다.

프로브 자체의 패킷이 어디로 가는지 추적하기

상태 프로브에도 경로가 있습니다. 데이터 트래픽이 VPN으로 넘어가면 같은 원격 주소로 가는 제약 없는 프로브가 그것을 따라가 성공하고, 기본 경로가 복구되었다는 증거로 읽힐 수 있습니다. 트래픽은 끊긴 경로로 돌아가고 주기가 반복됩니다.

프로브를 판정해야 할 경로에 고정합니다. RouterOS에서 보통 방법은 기본 게이트웨이를 통해 모니터링 대상으로 가는 호스트 경로이며, 다른 어떤 경로도 해석할 수 없을 만큼 작은 범위를 둡니다. RouterOS 설명서의 재귀 페일오버 예제가 만드는 것이 바로 이것입니다. 구성 주석이 아니라 백업이 활성인 상태의 라이브 테이블에서 확인하십시오:

/ip route print detail where dst-address=203.0.113.10
# gateway should still be the primary next hop

대상을 추가하기 전에 프로브 결과의 의미를 정의하기

ICMP를 거부하거나 유지보수에 들어가는 대상 하나는 경로 장애와 똑같이 보이고, 규칙 없는 세 대상은 세 가지 의견만 줍니다. 먼저 규칙을 정하고 나서 구현하십시오. 예를 들어 세 대상 중 둘이 두 번 연속 간격에서 실패하면 기본 경로를 다운으로 계산하고, 다음 사람이 찾을 운영 설명서에 적어 둡니다.

패킷 하나가 손실되어도 사이트가 움직이지 않도록 장애와 복구 임계값을 설정합니다. 히스테리시스는 감지 시간을 조금 쓰고 안정성을 되삽니다. 간격은 프로브가 얼마나 빨리 돌 수 있는지가 아니라 장애를 얼마나 오래 견딜 수 있는지에서 고르고, 복귀는 페일오버보다 느리게 두어 기본 경로가 트래픽을 되찾기 전에 스스로를 증명하게 하십시오.

복귀 경로와 세션 이야기 확인하기

바깥 방향으로만 동작하는 페일오버는 절반의 설계입니다. 원격 사이트에는 VPN을 통해 소스 범위로 돌아가는 경로가 필요합니다, 그렇지 않으면 복귀 트래픽이 예상치 못한 주소에서 도착해 더 이상 일치하지 않는 방화벽 상태에 부딪힙니다. 새 연결이 동작해도 기존 세션은 끊기므로 전송이 살아남는다고 약속하는 대신 수용 기준에 넣으십시오.

관리 접근을 시험 대상 경로에서 떼어 두십시오. 유일한 진입로가 기본 경로라면 페일오버 시험이 잘못 동작하는 장비에서 당신을 잠급니다.

수용 순서 실행하기

세 가지 시험이 대부분을 덮습니다. 기본 경로의 물리적 손실, 인터페이스가 살아 있는 조용한 전달 장애, 기본 경로 복구입니다. 각각에 대해 프로브의 소스와 다음 홉, 활성 목적지 경로, 양방향의 새로 허용된 애플리케이션 교환을 기록하십시오.

설계를 가르는 것은 조용한 경우입니다. 백업이 거기서 인계하지 않는다면 경로 모니터가 아니라 링크 모니터를 만든 것입니다. 그것이 수용 가능한지 결정하고, 제한을 온콜 엔지니어가 읽을 곳에 적으십시오. 두 번째로 연결된 터널은 그 자체로 완성된 백업 정책이 아닙니다.