애플리케이션 하나 때문에 터널이 끊기고, 누군가 peer로 한정된 IPsec clear를 실행하며, 명령이 받아들여졌다는 이유로 티켓이 닫힙니다. 그 과정 어디에도 장애가 고쳐졌다는 증거는 없습니다. ASA에서 reset이라는 단어는 세 가지 별개의 범위를 덮고, peer로 한정된 clear는 그중 정확히 하나만 건드립니다. 그래서 같은 터널이 운영자가 출력을 다 읽기 전에 다시 올라오는 일이 흔합니다.

한 단어 뒤에 숨은 세 가지 범위

IPsec SA 쌍은 데이터 경로 자체이며, 방향마다 하나의 연결이 있고 순번과 카운터를 가집니다. IKE SA는 그 연결들을 만들어 냈고 여전히 peer와의 관계를 붙들고 있는 협상 채널입니다. VPN 세션은 사용자, 사이트 간 peer, 또는 클라이언트 없는 연결에 대한 세션 데이터베이스의 레코드입니다.

ScopeWhat a clear removesWhat usually survives
IPsec SAData-path associations for the matching peer or selectorIKE SA, session records, crypto-map or tunnel-group config
IKE SANegotiation channel and the IPsec children derived from itSession records until they age out or are cleared
VPN sessionSession-database entry for that user or peer typeConfiguration, and any SA that is not tied to the session

범위들은 서로 충분히 독립적이어서 하나를 지워도 나머지는 계속 동작하며, 이 독립성이 혼란의 대부분을 만듭니다. IKE SA가 건강한 상태에서 IPsec SA를 지우면 트래픽이 몇 초 안에 새 연결을 만들기 때문에 터널이 스스로 치유된 것처럼 보입니다. 하지만 바탕에 있는 제안 불일치, 경로 공백, 인증 실패는 그대로 남아 있습니다.

장애가 협상에 있다면 IPsec clear는 관측 가능한 것을 바꾸지 않습니다.

상태가 남아 있는 동안 읽으세요

무엇이든 건드리기 전에 peer 주소, 사용 중인 IKE 버전, 보호되는 네트워크, 방향별 카운터를 기록하세요. 지원되는 보기는 릴리스마다 다르지만 형식은 안정적입니다. show crypto ipsec sa peer, show crypto ikev2 sa detailed 또는 IKEv1에 해당하는 명령, 그리고 세션 계층에는 show vpn-sessiondb입니다.

그 출력 옆에 타임스탬프와 사용자가 겪는 정확한 장애를 적으세요. 한 peer가 여러 보호 네트워크를 나르는 일이 흔하므로 peer로 한정된 clear의 영향 범위는 그 peer의 모든 셀렉터이지 티켓의 애플리케이션 하나가 아닙니다. 사전 그림이 없는 reset은 나중에 진단할 수 없습니다. clear가 비교에 쓸 카운터 자체를 지우기 때문입니다.

먼저 증거를 확보하세요. clear가 증거를 지우고, 나중에 찍은 스크린샷은 무엇이 다시 만들어졌는지 알려 줄 뿐 무엇이 고장 났었는지는 알려 주지 않습니다.

peer로 한정된 clear가 실제로 하는 일

Cisco의 clear 명령 참조에 peer로 한정된 IPsec 형식이 설명되어 있습니다. 문서용 주소를 넣으면 이런 모습입니다.

clear crypto ipsec sa peer 198.51.100.42

이 명령은 peer와 일치하는 IPsec 연결을 끊습니다. IKE SA를 제거하지 않고, 설정을 지우지 않으며, 세션 데이터베이스를 초기화하지 않습니다. 변경하는 터널에 의존하지 않는 관리 경로에서 실행하세요. 그 터널 안으로 지나가는 SSH 세션은 함께 끊기고 스스로 돌아오지 않을 수 있습니다. 장치의 나머지는 계속 동작하기에 명령이 무해해 보입니다.

대상 찾기가 불확실할 때는 조건 없는 clear로 물러서지 마세요. 더 넓은 형식은 장치의 모든 peer에 닿고, 만들어 내는 장애는 호출받은 이유보다 커집니다.

고치려던 계층을 검증하세요

clear 후에는 peer 목록이 다시 채워졌다는 이유로 reset이 통했다고 가정하지 말고, 연결이 새 카운터와 함께 돌아왔는지 확인하세요. 그다음 티켓이 지목한 애플리케이션을 시험하세요. ping 성공은 서비스 권한이나 만료된 세션에 대해 아무것도 말해 주지 않습니다.

연결이 다시 만들어져도 애플리케이션이 계속 실패한다면 남은 후보는 IKE 계층과 세션 계층입니다. 상태를 아직 확인할 수 있는 쪽을 고르세요. 실제로 실행 중인 버전에 맞는 표적 작업을 쓰세요. IKEv2 clear, IKEv1 clear, 또는 올바른 세션 유형으로 한정한 세션 데이터베이스 clear입니다. 재구성을 강제하려고 영구 crypto-map 설정을 지우고 다시 만드는 것은 되돌림이 더 긴 추측입니다.

다시 지우는 대신 전과 후 두 그림을 함께 붙여 에스컬레이션하세요.

reset이 장애를 길게 만들 때

반복되는 clear는 reset으로 고칠 수 없는 장애를 숨긴다: 빠진 경로, 새 서브넷과 더 이상 맞지 않는 셀렉터, 한쪽에서 바뀐 사전 공유 키, peer가 받아들이지 않을 제안에서 계속 실패하는 키 갱신입니다. clear를 할 때마다 그 peer의 모든 셀렉터에서 정상 트래픽이 끊기고 진짜 원인은 그대로 남습니다. 이렇게 다섯 분짜리 조사가 변경 작업 창이 됩니다.

범위를 좁힌 reset은 여전히 쓸모가 있습니다. 쓸모 있는 판은 표적이 분명하고, 기록되며, 고쳤어야 할 계층을 확인하는 데까지 이어지는 판입니다.

작업 순서: peer, 버전, 셀렉터, 카운터를 기록한다. 장애가 어느 범위에 속하는지 확인한다. 맞는 가장 좁은 clear를 실행한다. 연결과 애플리케이션을 검증한다. 계층은 회복됐는데 증상이 남으면 증거와 함께 에스컬레이션한다.

관련 글