VPN 장애 조치: 반환 경로가 이전 터널에 남아 있을 때

백업 터널이 올라오고 기본 터널이 내려가도 애플리케이션은 여전히 시간 초과가 납니다. 두 사이트 모두 터널 상태가 정상으로 보이며, 바로 그것이 혼란스럽습니다. 요청만 백업으로 옮기고 응답을 이전 경로에 두는 것은 장애 조치가 아닙니다. 아래 절차는 핸드셰이크만이 아니라 반환 경로를 시험합니다.

먼저 양쪽 끝의 경로를 기록하십시오; 한 사이트만 보는 시각으로는 비대칭 경로를 보여 줄 수 없습니다. 시간 압박 속에서 가장 자주 빠뜨리는 단계이기도 합니다.

시험 전에 두 사이트의 경로를 기록하십시오

보호되는 각 프리픽스에 대해 기본 경로, 백업 경로, 둘 중 하나를 고르는 우선순위를 적으십시오. 각 VPN 엔드포인트 뒤의 LAN 게이트웨이도, 엔드포인트가 마지막 홉인 경우가 드물기 때문에 포함하십시오.

정적 메트릭, 추적 경로, 동적 라우팅은 적합성을 서로 다르게 표현합니다. 설계가 어느 것을 쓰는지, 대체 경로가 활성화되려면 무엇이 필요한지 아십시오. 조건은 프로브가 실패할 때까지 더 낮은 메트릭을 두는 식으로 경로 옆에 적으십시오.

두 사이트 모두에서 하십시오. 한쪽에서 선호되고 다른 쪽에서 무시되는 백업은 피하려는 비대칭을 그대로 만듭니다.

각 단계에서 요청과 응답을 보십시오

무해하고 허용된 애플리케이션을 사용해 정상, 기본 경로 장애, 복구의 세 단계를 관찰하십시오. 각 단계에서 어느 터널이 요청을, 어느 터널이 응답을 나르는지 기록하십시오. 도달 가능한 피어 주소가 보호된 애플리케이션 경로의 작동을 증명하지는 않습니다. 단방향 흐름이 보이도록 두 사이트에서 기록하십시오.

요청은 움직이고 응답은 움직이지 않으면, 원격 사이트에서 클라이언트 프리픽스로 가는 경로와 백업에 대한 우선순위를 확인하십시오. 그것은 라우팅 결정이며 터널 장애가 아닙니다.

시험 후 원래 조건을 복원하고 기본 경로가 다시 선호되는지 확인하십시오. 복원된 기본 경로가 선호되지 않는다면 아직 끝나지 않은 장애 조치 설계입니다.

게이트웨이가 바뀔 때 세션 상태를 관리하십시오

방화벽과 NAT는 한 게이트웨이에 연결 상태를 보관할 수 있으며, 다른 게이트웨이로의 경로 변경은 그것을 옮기지 않습니다. 일부 애플리케이션은 스스로 다시 연결하고, 다른 것들은 세션이 재설정될 때까지 실패합니다. 백업이 공용 소스나 변환된 사설 주소를 바꾸면 원격 접속 규칙도 반응할 수 있습니다. 중단 없는 장애 조치를 약속하는 대신 예상되는 세션 재시작을 문서화하십시오.

애플리케이션이 요구하는 곳에서는 안정적인 주소 지정을 유지하십시오. 세션마다 소스 주소를 바꾸는 장애 조치 설계는 설계 선택이며, 기록해 두어야 합니다. 그 선택이 사용자가 실제로 알아차리는 중단의 크기를 결정합니다.

새 요청만이 아니라 긴 세션을 유지하는 애플리케이션도 시험하십시오.

기본 경로를 복원하고 플래핑을 확인하십시오

경로 광고나 우선순위가 진동 없이 안정되는지 확인하십시오. 플래핑하는 기본 경로는 전환마다 상태가 초기화되기 때문에 분명한 장애보다 더 혼란스러울 수 있습니다.

게이트웨이 관리를 복구 경로로 접근 가능하게 유지해 시험 자체가 당신을 잠그지 않게 하십시오. 단계, 관찰된 경로, 복구 시간을 기록하십시오. strongSwan의 전달 관련 메모는 엔드포인트가 Linux 호스트일 때 유용합니다.