VPN 사이트에서 라우팅 루프와 라우트 플래핑을 구분하는 방법
라우팅 루프와 플래핑하는 라우트는 같은 간헐적 손실을 일으킵니다. 게이트웨이에서의 세 가지 확인으로 무엇이든 바꾸기 전에 둘을 구분할 수 있습니다.
두 사이트, 하나의 터널, 그리고 한동안 응답하다가 조용해지는 원격 프리픽스. 반사적으로 라우팅 루프라고 부르게 되고, 때로는 정확히 그것이기도 합니다. 그러나 루프와 플래핑하는 라우트는 같은 불만을 만들고 서로 반대되는 수리를 요구합니다: 하나는 결코 끝나지 않는 포워딩 결정이고, 다른 하나는 계속 테이블을 떠나는 프리픽스입니다. 세 가지 관찰이 둘을 구분하며, 필터를 만지거나 터널을 다시 시작하기 전에 게이트웨이 명령줄에서 세 가지를 모두 수집할 수 있습니다.
루프는 홉 단위로 결정됩니다. 사이트 A가 목적지의 다음 홉으로 B를 선택하고, B가 같은 목적지에 A를 선택하면 패킷은 두 번 왕복한 뒤 TTL에서 만료됩니다. 플래핑은 대신 라우팅 프로토콜이 결정합니다: 프리픽스가 철회되거나 다시 설치되거나 대체 다음 홉으로 교체되므로, 어떤 패킷은 라우트가 전혀 없고 다른 패킷은 완전히 좋은 라우트를 따릅니다.
질문을 정리하는 세 가지 확인
첫 판단에 패킷 캡처는 필요하지 않습니다. 양 끝의 프리픽스 상태, 각 측이 선택하는 다음 홉, 그리고 반복되거나 그렇지 않은 홉 수가 필요합니다. 트래픽이 실패하는 동안 프리픽스가 같은 다음 홉으로 설치된 채 남아 있다면 루프는 포워딩 경로에 있습니다. 프리픽스가 사라졌다가 돌아오면 결함은 포워딩 위에 있고 수리는 라우팅 프로토콜에 속하며 정적 라우트가 아닙니다.
| Observation | Routing loop | Route flapping |
|---|---|---|
| Prefix in the table | Installed, same next hop throughout | Withdrawn and reinstalled, or next hop alternates |
| Hop count | Reaches zero at the same two gateways | Expires only while the prefix is missing |
| Failure shape | Consistent loss for that prefix from every source | Bursts, often after a link or peer event |
| Where the fix belongs | The site that owns the prefix, plus filters on the transit path | Advertisement, hold timers, or the flapping link |
시작하기 전 경고 하나. 루프가 도는 터널을 통해 이 글을 읽고 있다면 라우트를 바꾸는 순간 세션이 죽습니다. 수리하려는 프리픽스에 의존하지 않는 콘솔이나 관리 경로를 여십시오.
확인 하나: 프리픽스가 안정적인가, 흔들리는가
설정 파일이 약속하는 것이 아니라 커널이 무엇을 설치했는지 물으십시오. 리눅스 게이트웨이에서 ip route get 10.20.30.40 는 포워딩 경로가 실행하는 것과 같은 조회를 정책 테이블까지 포함해 실행하고, ip route show 10.20.30.0/24 는 항목 자체를 보여줍니다. ip monitor route 는 모든 변경을 발생 순간에 흘려보내며, 이것이 프리픽스가 오고 가는 것을 보는 가장 빠른 방법입니다.
FRR이나 BIRD를 돌리는 라우터에서 흥미로운 것은 포워딩 테이블이 아닙니다. show ip bgp 10.20.30.0/24 는 선택된 경로와 그 가동 시간을 돌려줍니다: 몇 분마다 재설정되는 가동 시간은 이름 붙일 수 있는 플래핑이지 루프가 아닙니다. show ip bgp summary 는 이웃 상태와 프리픽스 수를 보여주므로 계속 떨어지는 피어는 포워딩 경로에서 책임을 덜어냅니다.
무엇이든 바꾸기 전에 답을 적어 두십시오. 핑이 실패하는 동안 십 분 동안 안정적이었는지, 십 분에 네 번 사라졌는지에 따라 다음 단계가 달라집니다. 후자라면 정적 라우트 이론은 모두 무의미합니다.
확인 둘: 다음 홉이 도착 터널로 되돌아가는가
루프에는 두 게이트웨이의 합의가 필요합니다. 패킷을 받는 사이트에서, 정책 규칙이 메인 테이블과 다르게 답할 수 있으므로 실제 출발지 주소를 붙인 ip route get 10.20.30.40 from 10.10.5.20 로 패킷이 나갈 경로를 보십시오. 그다음 보낸 사이트에서 같은 조회를 반복하십시오. 양쪽이 같은 프리픽스의 다음 홉으로 서로를 선택하면 루프가 증명되고 어떤 캡처도 더할 것이 없습니다.
원인은 거의 항상 터널을 넘어서는 안 되었던 광고입니다. 터널로 재분배된 기본 라우트, 원격 사이트 자체의 서브넷을 덮는 집계, 만약을 위한 피어 방향 정적 라우트는 모두 같은 상호 다음 홉을 만듭니다. 터널이 완전히 수립되어 있어도 트래픽이 원을 그릴 수 있으며, strongSwan의 포워딩 노트가 그 요구의 라우팅 측면을 설명합니다.
WireGuard는 탓할 광고가 없으므로 자기만의 주석이 필요합니다. wg show 는 각 피어의 AllowedIPs를 나열하고, 커널은 그 범위 안에 들어오는 목적지만 피어용으로 받아들입니다. 그곳의 루프는 겹치는 AllowedIPs 범위나 인터페이스를 넘어 되돌아가는 정적 라우트이므로 수리는 그 두 곳에만 있습니다.
확인 셋: 별표가 아니라 홉 수를 읽으십시오
traceroute -n -I 10.20.30.40 와 mtr -n -r -c 20 10.20.30.40 는 둘 다 경로를 보여주고, ICMP 모드는 UDP 프로브를 먹어 치우는 필터링을 종종 견뎌냅니다. 루프는 같은 두 게이트웨이 주소가 짧게 반복되고 TTL이 매번 올라가는 모습입니다. 드롭은 응답한 마지막 게이트웨이 뒤의 별표처럼 보이며, 조용한 홉 하나는 아무것도 증명하지 못합니다.
경로가 모호할 때는 회선에서 TTL을 읽으십시오. 두 게이트웨이에서 tcpdump -ni any -vv icmp 를 실행하면 각 패킷의 TTL과 시간 초과 응답마다의 출발지 주소가 보입니다. 패킷이 경로에 있을 수 있는 홉 수보다 낮은 TTL로 원격 사이트에 도착한다면 무언가 traceroute가 보여주지 않는 홉을 더하고 있으며, 이는 한 사이트의 방화벽이 다른 사이트를 대신해 프로브에 응답할 때 생깁니다.
프리픽스의 소유자를 고치고 나서 양방향을 검증하십시오
어느 사이트가 목적지를 만들고 어떤 트랜짓 경로가 허용되는지 정한 다음 그 소유자에서 광고나 정적 라우트를 바꾸십시오. 받는 사이트를 고치는 것은 매력적이고 대개 틀립니다: 한 프리픽스의 루프를 숨기고 다음 프리픽스를 위해 나쁜 광고를 그대로 두기 때문입니다. 라우트 태그, 디스트리뷰트 리스트, split-horizon 규칙은 이를 근원에서 막기 위해 존재하며 단일 프리픽스와 일치하는 필터보다 저렴합니다.
변경 후에는 루프가 블랙홀로 바뀌어도 증상이 눈에 띄게 나아지지 않을 수 있으므로 가는 방향과 돌아오는 방향을 따로 검증하십시오. 양 끝에서 ip route get 를 실행하고, 게이트웨이가 아닌 호스트에서 트래픽을 보내며, 플래핑을 수리로 오인하지 않도록 ip monitor route 를 적어도 홀드 타이머 하나 동안 켜 두십시오.
무엇이든 바꾸기 전에 다음 다섯 가지를 확인하십시오: 프리픽스가 안정적인지 흔들리는지, 양 끝의 다음 홉이 터널을 가리키는지, 홉 수가 반복되는지, 프리픽스를 소유한 사이트가 하나인지, 그리고 변경을 견디는 관리 경로가 있는지. 다섯 중 하나라도 모르면 나머지 넷은 추측입니다.