클라우드 VPN에는 BGP가 필요하다: 다른 라우팅 프로토콜이 실패하는 이유

IPsec 보안 연관은 올라와 있고 터널 카운터도 움직이는데 클라우드 프리픽스로 가는 트래픽이 사라진다. 그러면 운영자는 고객 라우터에서 OSPF를 활성화하려 하고 이웃이 형성되기를 기대하지만 아무 일도 일어나지 않는다. 터널은 애초에 빠진 조각이 아니었다. 관리형 클라우드 VPN은 명확히 정의된 라우팅 계약을 제공하며, 대형 플랫폼에서 그 계약은 BGP다. 세션이 존재하고 프리픽스가 수락되기 전까지 터널은 뒤에 목적지가 없는 암호화된 경로일 뿐이다.

터널은 올라와 있는데 경로가 없다

1단계와 2단계의 완료는 양측이 보호에 합의했음을 증명할 뿐, 어느 쪽이 트래픽을 어디로 보낼지 안다는 뜻은 아니다. 이들은 서로 다른 장애 모드를 가진 별개의 상태 머신이다.

순서대로 세 가지를 물어야 한다. 프리픽스가 광고되었는가, 상대가 수락했는가, 포워딩을 위해 설치되었는가. 광고된 뒤 필터링된 프리픽스는 정책 문제다. 한 번도 광고되지 않은 프리픽스는 세션 또는 구성 문제다. 수락되었지만 설치되지 않은 프리픽스는 경로 선택 문제이며, 각 답은 구성의 다른 부분을 가리킨다.

공급자가 실제로 제공하는 것

관리형 VPN 게이트웨이는 제한 없는 라우터가 아니다. 공급자는 지원되는 피어 주소, 자율 시스템 설정, 프리픽스 한도, 정의된 장애 동작을 갖춘 게이트웨이를 제공한다. 그 표면이 곧 제품이다.

Google Cloud는 HA VPN용 동적 BGP 라우팅을 문서화하며, Cloud Router가 피어 경로를 학습하고 적격한 사용자 정의 동적 경로를 VPC에 공급한다. AWS Site-to-Site VPN은 정적 라우팅과 동적 라우팅 사이의 선택을 문서화하고, BGP 생존 확인이 터널 페일오버에 유용하다고 설명하면서 BGP가 없는 장비를 위한 상태 확인도 지원한다. 어느 플랫폼의 동작도 다른 쪽 제품 이름에서 추론해서는 안 된다.

실무적 결론은 먼저 관리형 모드를 선택하고 그다음 지원되는 매개변수를 읽는다는 것이다. 서비스가 제공하지 않는 인접 유형을 가정한 설계는 고객 라우터에서 풀 구성 문제가 아니다.

터널 보호와 도달성은 별개의 작업이다

IPsec은 터널용으로 선택된 트래픽을 보호한다. BGP는 프리픽스를 적격하게 만드는 도달성 정보를 공급한다. 터널이 동작한다고 해서 기대한 프리픽스가 광고, 수락, 설치되었다는 증거는 아니다.

두 개의 적격한 터널 경로로 10.42.0.0/16을 광고하는 지점을 상상해 보자. 사용 가능한 경로 하나를 제거하면 누구도 각 워크로드의 경로를 편집하지 않아도 경로 선택이 바뀔 수 있다. 감지, 경로 선택, 애플리케이션 복구는 즉각적이지 않고 배포마다 동일하지도 않으므로, 페일오버 시험은 통과한 첫 패킷이 아니라 전체 순서를 관찰해야 한다.

클라우드 프리픽스에 도달할 수 없을 때는 암호화를 건드리기 전에 세션 상태와 학습된 경로를 확인한다. 뒤에 경로가 없는 채로 올라온 SA가 이 증상의 가장 흔한 형태다.

OSPF 가정이 깨지는 지점

IPsec 터널 내부에서 OSPF, IS-IS 또는 다른 프로토콜을 사용하는 것은 양 끝과 포워딩 설계를 직접 소유한 자체 관리 어플라이언스에서는 충분히 가능하다. 그 사실은 동적 라우팅 모드로 BGP만 제공하는 관리형 서비스에 대해서는 아무것도 말해 주지 않는다.

제안된 설계가 서비스가 지원하지 않는 인접을 필요로 한다면 아키텍처를 의도적으로 바꿔야 한다. 선택지에는 VPC 내 자체 관리 어플라이언스, 서비스가 지원하는 범위의 정적 라우팅, 또는 다른 연결 제품이 있다. 고객 라우터에서만 프로토콜을 구성해서는 존재하지 않는 클라우드 측 피어를 추가할 수 없고, 프리픽스가 나타나지도 않는다.

한 공급자의 답을 다른 공급자의 게이트웨이로 옮기지 말아야 한다. 동적 라우팅이나 터널 페일오버 같은 같은 단어가 서로 다른 메커니즘과 다른 한계를 가리킬 수 있다.

서비스 요구 사항을 읽고 나서 설계하라

첫 구성 줄 전에 이웃 주소, 자율 시스템 번호, 광고하고 수락할 프리픽스, 경로 한도, 터널 장애 시 기대 동작을 적어 둔다. 그 다섯 항목이 설계의 기준이 되는 계약이다.

그다음 같은 순서로 검증한다. 세션 설정, 프리픽스 수신, VPC 경로 테이블에 경로 존재, 서비스 주소로의 실제 흐름이다. 강제 페일오버 후에 반복하라. 다시 설정된 세션은 다른 경로 집합으로 돌아올 수 있기 때문이다. 설계가 초 단위 이하의 수렴에 의존한다면 가정하지 말고 측정하라.

서비스 계약은 변경 기록과 함께 보관한다. 나중에 누군가 터널에서 OSPF를 돌릴 수 없는 이유를 묻는다면, 답은 프로토콜 제한이 아니라 제품 경계이며 기록에도 그렇게 적어야 한다.