ASA의 failback: 경로가 돌아올 때 실제로 움직이는 것

uplink가 둘인 ASA에서 failback은 failover의 반대가 아닙니다. peer로 가는 경로가 바뀌고, 그다음 플랫폼은 세 개의 별개 상태 기계를 조정해야 합니다. 라우팅 테이블, IKE와 IPsec 보안 연관, 그리고 연결 테이블입니다. 각각은 다른 것보다 뒤처질 수 있고, 사람들이 돌아오지 않는 터널이라고 부르는 것이 바로 그 지연입니다.

failback이 실제로 바꾸는 것

경로 조회는 눈에 보이는 부분입니다. 감시 객체가 복구되면 peer의 외부 주소로 가는 감시 경로가 돌아오고, ASA가 보내는 다음 패킷은 다시 주 링크를 따릅니다. 그 뒤의 모든 것은 기존 상태가 새 경로와 일치하는지에 달려 있습니다.

ARP와 NAT는 조용한 의존 관계입니다. 새 next hop에는 확인 가능한 게이트웨이와 원격 끝과 여전히 맞는 변환이 필요합니다. 그렇지 않으면 failback 후 첫 패킷이 아무 데도 가지 않고, 아무것도 동작하지 않는데 경로만 정상으로 보입니다.

하나의 시간선 위에 놓인 네 가지 시각

전환 전, 전환 중, 전환 후에 같은 네 가지를 기록하십시오. 한 장의 스냅숏으로는 어느 계층이 움직였는지 알 수 없습니다.

한 번도 바뀌지 않은 경로와, 오래된 연결이 전달 상태를 유지한 채 바뀐 경로는 같은 불만과 전혀 다른 증거를 만들어 냅니다.

오래된 연결이 백업 경로에 남는 이유

ASA는 경로가 바뀌었다고 흐름을 끊지 않습니다. 이미 설정된 연결은 만들어질 때의 전달 결정을 그대로 유지하며, 플랫폼은 그 허용 시간에 대해 별도 제어를 제공합니다. floating-connection timeout과 connection holddown입니다. Cisco의 ASA 9.24 연결 설정 가이드는 이 둘을 서로 다른 질문으로 다루며, 실제 동작도 정확히 그렇습니다. 하나는 기존 흐름의 생존을, 다른 하나는 새 흐름이 선호 경로를 쓸 수 있는 시점을 다스립니다.

둘 중 하나를 바꾸기 전에 해당 릴리스의 유효 값을 읽으십시오. 값을 낮추면 사람들이 아직 쓰는 세션이 닫힙니다. 값을 높이면 failback이 없었던 것처럼 보입니다. 새 연결이 그 시간 동안 계속 옛 경로를 택하기 때문입니다.

경로가 돌아왔다고 터널이 키를 다시 협상하지는 않는다

IPsec 보안 연관은 자체 협상된 수명을 지니며, 자신을 실어 나른 경로 변경을 견뎌 냅니다. 그래서 터널은 failback을 넘겨 살아 있을 수 있지만 외부 주소 지정은 사용 중인 경로와 더 이상 맞지 않습니다. 이것이 DPD와, peer 주소를 떠다니게 두지 않고 고정하는 설계의 근거입니다.

crypto-map과 VTI 설계는 여기서 다르게 동작합니다, 그리고 Cisco의 9.24 VTI 문서는 경로 기반 옵션을 설명합니다. ASA가 경로 기반 VPN을 돌릴 수 없다는 예전의 일괄 주장은 지원되는 릴리스에는 해당하지 않습니다.

증거는 이 순서로 읽으십시오

제어 평면부터 시작하십시오. 선택된 경로에는 show route, 링크 상태에는 show interface, 감시 객체에는 SLA 모니터의 카운터를 씁니다. 다음으로 어떤 peer가 살아 있는지 보려고 show crypto ikev2 sa, 또는 IKEv1 등가 명령을 읽고, 이어서 보호된 흐름에는 show crypto ipsec sa를 봅니다. 그다음 show conn address <host>로 연결 테이블을 좁히고 옛 항목과 새 항목에서 인터페이스 열을 비교하십시오. 출력은 시간 표시와 함께 적어 두십시오. 그 순서가 곧 진단입니다.

애플리케이션 테스트로 마무리하십시오. 이미 존재하던 흐름 하나와 경로가 돌아온 뒤 만들어진 흐름 하나입니다. 옛 흐름이 실패하고 새 흐름이 동작하면 연결 상태의 이야기가 됩니다. 둘 다 실패하면 터널이나 정책이 잘못된 것이고 연결 테이블은 주의를 흩뜨리는 대상입니다.

그 기록을 세 단계 모두에서 같은 형태로 유지하고 정확한 릴리스를 적어 두십시오. 시간선이 계속 하나의 전환만 가리키면 버그 ID를 추측하지 말고 기록을 지원 팀에 보내십시오.