터널은 살아 있는데 경로가 사라졌다: 두 VPN 장애 구분하기

터널 인터페이스가 여전히 설정되었다고 보고하는데도 한 호스트에 도달할 수 없게 되며, 두 관찰은 모순이 아니다. 무언가가 트래픽이 쓰던 경로를 제거했다. 이웃이 프리픽스를 철회했거나, 추적하던 정적 경로가 빠졌거나, 다른 경로가 선호되었다. 보안 연결은 세 경우 모두에서 완전히 건강할 수 있다. 사건을 분리한다는 것은 VPN이 실패했는지가 아니라 어느 계층이 먼저 바뀌었는지를 묻는 일이다.

하나의 사건처럼 보이는 세 단계

라우팅 결정에는 세 단계가 있다. 프리픽스를 수신하고, 최적으로 선택하고, 포워딩 테이블에 설치한다. 각 단계는 따로 실패할 수 있고, 애플리케이션 쪽에서는 실패가 똑같이 보인다. 학습되었지만 선택에서 진 프리픽스는, 포워딩 테이블만 본다면 결코 도착하지 않은 프리픽스와 구별할 수 없다.

그래서 첫 질문은 어느 프로토콜이 잘못했는가가 아니라 어느 단계가 깨졌는가이다. 답이 사건의 소유자와 다음 점검이 쓸 도구를 결정한다.

먼저 설치된 경로를 읽어라

커널에 장애가 난 목적지로 가는 트래픽이 실제로 어디로 가는지 물어라. ip route get 는 다음 홉, 인터페이스, 커널이 쓸 소스 주소를 출력하며, 전체 테이블이 아니라 한 목적지에 대해 답한다. 답이 터널을 가리키면 포워딩 테이블은 여전히 경로가 있다고 믿고 있으며 문제는 그 위에 있다.

ip route get 10.20.5.10
ip route show 10.20.0.0/16

«unreachable» 이라는 답은 설치된 경로가 전혀 없다는 뜻이며, 철회나 누락된 설치를 가리킨다. 물리 인터페이스를 가리키는 답은 아무도 결정하지 않았는데 트래픽이 터널을 떠났다는 뜻이고, 다음 점검은 이긴 우선순위다. 반면 패킷이 계속 사라지는데 답이 터널을 가리키면 경로 더 아래, 필터링이나 반대편을 가리킨다.

그다음 프로토콜 자체의 시점을 보라

라우팅 데몬은 하나 이상의 테이블을 유지하며, 흥미로운 비교는 그들 사이에 있다. BGP에서는 이웃 세션 상태, 수신한 광고, 설치된 경로가 세 가지 별개의 증거다. 프리픽스는 수신 테이블에 남아 있어도 더 짧은 관리 거리의 경로가 이기기 때문에 커널에 도달하지 못할 수 있다. 상대가 광고를 멈췄다고 결론 내리기 전에 세 가지를 모두 확인하라.

vtysh -c "show bgp summary"
vtysh -c "show bgp ipv4 unicast 10.20.0.0/16"

요약은 세션이 설정되었는지, 프리픽스별 보기는 프리픽스가 수락되었는지, 커널 조회는 설치되었는지를 알려준다. 이 순서로 읽으면 세션의 흔들림을 철회로, 철회를 정책 거부로 오인하지 않게 된다.

시계가 서로 어긋날 때

터널 로그, 라우팅 로그, 애플리케이션의 첫 실패를 실제 시간대를 사용해 하나의 시간선에 놓아라. 이웃 상실이 먼저 오면 터널이 경로를 함께 끌어내렸다. 철회가 먼저 오면 라우팅이 바뀌었고 터널이 나중에 반응했다. 이것은 소유자가 다른 별개의 사건이며, 순서가 발견의 전부다.

시계가 일 분만 어긋나도 그 결론은 뒤집힐 수 있으므로, 순서를 믿기 전에 시간대와 오프셋을 확인하라. 오프셋 없이 현지 시각으로 기록하는 장비가 자신만만하지만 틀린 시간선의 흔한 근원이다.

루프 없는 복구

철회 후에는 두 경로가 적격일 수 있다. 프로토콜이 선택하는 경로와 손으로 고정하는 경로다. 네트워크가 당신을 위해 계속 내리는 결정은 첫 번째뿐이므로, 수동 경로는 복구 계획이 아니라 임시방편이다. 대체 광고도 이미 설정된 세션의 방화벽이나 NAT 상태를 보존하지 않으므로, 원래 흐름이 깨진 채 새 흐름만 동작할 수 있다. 어느 백업이 활성화되어야 하는지, 원격 사이트가 그것을 통해 반환 경로를 받아들일지 확인하라.

철회가 왜 일어났는지 이해하기 전에 영구적인 정적 재정의를 설치하지 마라. 그 지름길은 트래픽을 실패한 경로에 고정하거나 의도적인 라우팅 정책을 조용히 우회할 수 있고, 원래 원인을 새 구성 아래 묻어버린다. 경로가 복구되면 애플리케이션을 다시 시험하고, 선택한 프리픽스에 테이블 항목만이 아니라 동작하는 데이터 경로가 있는지 확인하라.