VPN 위의 BGP가 언더레이 경로를 제어하지 못하는 이유

두 사이트가 IPsec 터널 너머로 BGP를 피어링하고 서로의 프리픽스를 학습하면, 다이어그램은 경로 제어로 다시 이름 붙습니다. 바로 그 라벨이 혼란의 시작입니다. 세션은 분명히 도달 가능성을 교환하고 정책도 적용하지만, 어떤 제공자, 케이블, 라우터가 암호화된 패킷을 운반하는지에 대해서는 발언권이 없습니다. BGP 경로 변경이 세션이 결코 영향을 줄 수 없는 다른 광섬유 경로로 트래픽을 옮길 것이라고 기대하며 작동하던 터널을 다시 만든 팀을 본 적이 있습니다.

세션이 무엇을 사 준다고 사람들이 가정하는지

기대의 대부분은 실험실에서 경로 변경이 어떻게 보이는지에서 나옵니다. 터널 너머로 프리픽스를 광고하고, 먼 쪽이 그것을 설치하고, 트래픽이 움직입니다. 같은 순서가 트래픽 엔지니어링 손잡이를 실제로 가진 라우터에서도 일어나므로 둘이 혼동됩니다. 실험실에서는 보통 두 사이트가 하나의 액세스 링크를 공유하며, 바로 그래서 그곳에서는 차이가 결코 드러나지 않습니다.

BGP는 도달 가능성 프로토콜입니다. 프리픽스에 대해 패킷을 전달할 수 있다고 피어에게 알리고, 받은 제안을 각 측이 순위를 매기게 합니다. 이것은 터널 너머로 정말 유용합니다. 사이트가 생겨나고 사라지면서 프리픽스도 나타났다 사라지고, 각 엣지 장비에 정적 경로를 쓰지 않고도 범위를 거부할 수 있습니다. 하지 않는 일은 제공자의 라우터를 당신의 통제 아래 두는 것입니다.

언더레이는 외부 헤더를 운반합니다. 터널 끝점은 암호화된 패킷을 피어 주소로 보내고, 그 두 주소 사이의 네트워크는 운영자가 설치한 경로로 그것을 전달합니다. BGP 세션의 어떤 것도 그 결정을 바꾸지 않습니다. 같은 제공자가 그렇게 하는 지원 서비스를 제공하지 않는 한 말입니다.

세션이 실제로 운반하는 것

BGP 스피커는 피어의 179 포트로 TCP 연결을 열고, RFC 4271에 정의된 메시지 형식과 경로 속성을 사용합니다. 피어 주소가 터널 안에 있으면 세션이 시작되기도 전에 터널이 올라와 있어야 하고 그 주소에 도달할 수 있어야 합니다. 완료된 IKE 교환은 BGP 이웃이 아닙니다. 경로 기반 IPsec 구현은 일치하는 터널 경로가 있을 때만 트래픽을 통과시키고, 정책 기반 구현은 보호된 선택자 안에 피어 주소가 필요합니다. 이것을 거꾸로 하면 터널은 초록인데 세션은 유휴 상태로 앉아 있는 전형적인 상태가 됩니다.

세션이 올라오면 정책이 무엇이 그것을 통과할지 결정합니다. 프리픽스 목록, AS 경로 필터, 최대 프리픽스 상한, 기본 경로에 대한 명시적 결정이 최소한이며, 둘 다 양방향에 적용됩니다. 받는 것을 모두 수용하는 피어는 로컬 인터넷 액세스를 조용히 대체하는 기본 경로를 줄 수 있습니다. 두 방향에는 별도의 목록이 필요합니다. 피어에게서 받아들이는 것과 피어에게 광고하는 것은 다른 결정이기 때문입니다.

router bgp 65010
 neighbor 10.255.0.2 remote-as 65020
 address-family ipv4 unicast
  neighbor 10.255.0.2 prefix-list SITE-B-IN in
  neighbor 10.255.0.2 prefix-list SITE-B-OUT out
  neighbor 10.255.0.2 maximum-prefix 50

다음으로 MTU가 물어뜯습니다. 캡슐화가 사용 가능한 페이로드를 줄이므로, 큰 업데이트가 완벽하게 설정된 것처럼 보이는 세션을 멈출 수 있습니다. 피어는 올라와 있는데 프리픽스는 결코 도착하지 않고 로그에도 뚜렷한 것이 남지 않습니다. 필터를 탓하기 전에 터널 인터페이스에서 TCP MSS를 제한하거나 오버헤드를 위한 여유를 둔 터널 MTU를 설정하십시오.

외부 패킷은 그래도 어디로 가는가

한 사이트에서 다른 사이트로 가는 암호화된 패킷은 로컬 라우터가 피어의 공인 주소에 대해 선택하는 경로로 나갑니다. 두 사이트가 같은 제공자에게서 트랜짓을 사거나, 같은 메트로 시설을 지나거나, 한쪽이 캐리어급 NAT 뒤에 있다면, 터널이 제공자 장애를 살아남는 것은 우연일 뿐입니다. 모니터링 도구에서 터널 아이콘을 세는 것은 그에 대해 아무것도 알려주지 않습니다.

경로 선택과 포워딩 설치도 별개의 사건입니다. 프리픽스가 BGP 테이블에 최선으로 앉아 있어도 포워딩 테이블에는 빠져 있을 수 있습니다. 다음 홉이 해석되지 않거나 더 구체적인 경로가 이기기 때문입니다. 누군가 BGP가 프리픽스를 배웠지만 트래픽이 흐르지 않는다고 보고할 때 유용한 질문은 그것이 설치되었는지, 어느 다음 홉을 가리키는지입니다.

설계 검토에 대한 정직한 답은 공유 의존성 목록입니다. 액세스 회선, 상위 제공자, 시설, 그리고 반환 경로의 모든 상태 저장 장치. 터널 너머의 세션은 자기가 그 위에 앉아 있지 않은 의존성을 제거할 수 없습니다.

분리할 가치가 있는 세 가지 결정

설계가 이것들을 섞으면 모든 장애 대화가 제자리를 맴돕니다. 먼저 종이 위에서 분리하고, 다음에 각각을 실제로 강제하는 장비에 매핑하십시오.

각 행에는 다른 소유자가 있습니다. 첫째는 협상, 둘째는 당신 장비의 구성, 셋째는 대부분 다른 사람의 네트워크입니다. 건드리는 행을 명시한 변경 요청은 BGP 문제라고 말하는 요청보다 승인하기 훨씬 쉽습니다.

계획할 가치가 있는 장애 모드

피어의 요약 경로를 수용하는 것이 가장 흔한 자해입니다. 누군가 교환을 단순화하려고 짧은 집계를 광고하고, 먼 쪽이 그것을 받아들이고, 터널 뒤에 없는 범위의 트래픽이 터널을 따라가 죽습니다. 정확히 기대하는 프리픽스로 필터링하거나 올바른 경계의 프리픽스 목록을 쓰고, 세션이 깔끔해 보인다고 해서 맨 집계를 결코 받아들이지 마십시오.

철회 타이밍이 둘째입니다. 탐지는 홀드 타이머, 활성화했다면 BFD, 터널의 데드 피어 탐지, 그리고 먼 쪽이 광고를 멈추는 속도에 달려 있습니다. 기존 세션은 별개의 문제입니다. 새 경로가 새 연결을 복구해도 이미 설정된 TCP 세션은 오래된 주소를 계속 쓰고, 경로의 상태 저장 방화벽이나 NAT는 더 이상 일치하지 않는 항목을 유지할 수 있습니다. 경로 변경이 모든 것을 해결한다고 가정하는 대신 애플리케이션 복구를 수용 기준에 넣으십시오.

셋째는 반환 경로 비대칭입니다. 트래픽이 터널로 도착하고 그것을 운반하도록 만들어진 적 없는 제공자 링크로 돌아갈 수 있으며, 이는 단방향 오디오, 실패한 핸드셰이크, 응답을 떨어뜨리는 방화벽으로 나타납니다. 두 방향을 따로 확인하십시오.

계약서에 무엇을 쓰고, 어떻게 검증할 것인가

허용된 프리픽스를 서면으로 요청하십시오. 각 범위를 생성할 권한이 누구에게 있는지, 기본 경로가 허용되는지, 터널 서비스가 어떤 주소 패밀리를 지원하는지. RFC 8212는 그것을 따르는 구현에서 명시적 가져오기와 내보내기 정책을 eBGP의 기대치로 만들었으므로, 여전히 암묵적인 전부 수용 동작에 기대는 피어는 질문할 가치가 있습니다.

그다음 다이어그램이 아니라 장비에서 검증하십시오. FRR 스타일 라우터에서 유용한 명령:

show bgp summary
show bgp ipv4 unicast 10.10.0.0/16
show bgp ipv4 unicast neighbors 10.255.0.2 advertised-routes
show ip route 10.10.0.0/16

라우팅 테이블이 줄 수 없는 두 가지 관찰을 추가하십시오. 캡슐화된 패킷이 실제로 어느 주소를 겨냥하는지 확인하려면, 예를 들어 tcpdump -ni eth0 udp port 51820WireGuard 터널의 경우나 IPsec의 ESP 필터로 외부 인터페이스에서 캡처하십시오. 그다음 피어의 공인 주소 쪽으로 트레이스하며 터널 내부의 트레이스와 홉을 비교하고, 둘 다 같은 제공자 체인을 따른다면 당신의 이중성은 네트워크가 아니라 라우팅 정책에 살고 있습니다.

마지막으로 철회를 의도적으로 테스트하십시오. 유지보수 창에서 터널을 내리고, 프리픽스가 얼마나 오래 설치된 채로 남는지, 기존 세션에 무슨 일이 생기는지, 먼 쪽이 정말로 받아들일 경로로 폴백하는지 기록하십시오. 그 연습은 어떤 다이어그램보다 설계에 대해 더 많이 말해줍니다.

경로는 승인이 아닙니다. 교환하기로 합의한 프리픽스는 어떤 사용자가 터널 뒤의 어떤 서비스에 도달할 수 있는지에 대해 아무것도 말하지 않으므로 인증, 허용된 서비스, 호스트 방화벽을 원래 있던 곳에 그대로 두십시오. 도달 가능한 피어도 무제한 트랜짓이나 임의 주소 생성에 대한 허가가 아니며, 그런 종류의 권한은 상업적 질문으로서 계약에 속하고 BGP 정책 줄에 속하지 않습니다.

• 각 측이 생성할 수 있는 프리픽스와 결코 받아들여서는 안 되는 프리픽스의 이름을 대십시오.
• 터널에서 MSS를 제한하고 큰 업데이트가 실제로 도착하는지 확인하십시오.
• 공유 언더레이 의존성을 나열하십시오, 터널 수가 아니라.
• 실제 철회 시간을 재고 애플리케이션이 무엇을 하는지 기록하십시오.