VGW의 BGP 광고와 VPC 라우트 테이블: 무엇이 무엇을 바꾸는가

VPC 서브넷 라우트 테이블에서 빠진 프리픽스와 고객 라우터에서 빠진 프리픽스는 서로 다른 두 장애이며, 그중 하나만 AWS 라우트 테이블 안에서 복구됩니다. 가상 프라이빗 게이트웨이는 자신의 VPC에 연결된 CIDR 블록을 광고하고, 서브넷 라우트 테이블은 워크로드가 응답을 어디로 보낼지 결정합니다. 두 번째를 첫 번째를 바꾸는 수단으로 취급하기 가 이 진단에서 가장 흔한 잘못된 갈림길입니다. 아래 점검을 순서대로 실행하고 두 방향을 분리해 두세요.

어떤 테이블을 읽기 전에 연결 유형부터 확인하세요

사이트 간 VPN은 가상 프라이빗 게이트웨이 또는 전송 게이트웨이에서 종료되며, 리소스 ID가 어떤 라우팅 모델이 적용되는지 결정합니다. 먼저 그것을 읽으세요: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'. 답을 보면 다음에 확인할 테이블이 VPC 라우트 테이블인지 전송 게이트웨이 라우트 테이블인지 알 수 있습니다.

VPN이 전송 게이트웨이에 연결되어 있다면 VPC 라우트 테이블을 제어 영역으로 취급하지 마세요. 그곳에서 VPC 테이블은 게이트웨이 연결을 가리키고, 연결과 전파는 전송 게이트웨이 라우트 테이블에서 일어납니다. 두 관점을 섞으면 잘못된 객체에 대해 확신에 찬 결론이 나옵니다.

AWS에서 사무실로 가는 방향은 광고입니다

VGW 연결의 경우 게이트웨이는 자신의 VPC에 연결된 CIDR 블록을 BGP를 통해 고객 게이트웨이에 광고합니다. 개별 서브넷 라우트를 추가하거나 라우트를 피어링된 VPC나 어플라이언스로 향하게 해도 다른 연결 CIDR이 추가되지 않으며 그 광고에 나타나지 않습니다. 사무실에서 프리픽스가 빠졌다면 어떤 라우트 테이블을 편집하기 전에 수신 라우트 목록을 VPC 연결과 비교하세요.

단순한 규칙에는 예외가 있으니 범위를 지켜 적용하세요. VPN CloudHub 구성은 고객 게이트웨이 사이에서 사이트 프리픽스를 다시 광고할 수 있고, 전송 게이트웨이는 자체 전파 규칙을 따릅니다. VGW가 자기 VPC만 광고한다는 서술은 유용한 기본값이지 마주칠 모든 토폴로지를 포괄하는 법칙은 아닙니다.

사무실에서 AWS로 가는 방향은 전파와 선택입니다

반대 방향에서는 VGW가 사무실 프리픽스를 학습하지만 그것만으로 워크로드가 움직이지는 않습니다. 서브넷 라우트 테이블에서 연결에 대한 전파가 활성화되어 있거나 같은 목적지로 가는 정적 라우트가 있어야 합니다. 하나의 프리픽스에 둘 다 있으면 정적 라우트가 이기고, 최장 프리픽스 일치는 둘보다 먼저 실행됩니다.

추측하지 말고 출처를 읽으세요: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'. 출처가 EnableVgwRoutePropagation인 항목은 BGP에서 온 것입니다. 출처가 CreateRoute인 항목은 사람이 입력한 것이며 누군가 삭제할 때까지 계속 이깁니다.

두 방향을 분리해 유지하는 런북

무엇이든 바꾸기 전에 AWS 쪽에서 네 가지 사실을 기록하세요. 연결 유형, 연결된 VPC CIDR, 문제의 프리픽스에 대한 서브넷 라우트 출처, 터널과 BGP 상태입니다. 같은 describe 호출은 터널별 수락된 라우트 수와 함께 VgwTelemetry를 반환하며, AWS가 라우트를 아예 수락했는지 알려줍니다. 그다음 고객 장비가 실제로 설치한 것과 비교하세요. BGP에는 있지만 전달 테이블에 없는 프리픽스는 로컬 가져오기나 최적 경로 문제이지 AWS 라우트 테이블 문제가 아닙니다.

서브넷 테이블에 프리픽스가 전혀 없다면 전파를 활성화하거나 정적 라우트를 추가한 뒤, 변경이 즉시였다고 가정하지 말고 전파 간격이 지난 후 같은 쿼리를 다시 읽으세요. 프리픽스가 있는데도 트래픽이 계속 실패하면 제어 영역은 그대로 두고 데이터 경로로 넘어가세요.

그곳에 있는 동안 바꾸지 말아야 할 것

빠진 프리픽스 하나를 고치려고 관계없는 라우트 테이블에서 전파를 켜거나 끄지 말고, 빠진 CIDR 하나를 덮으려고 기본 라우트를 추가하지 마세요. 두 변경 모두 영향 범위를 넓히고 다음 진단을 어렵게 만듭니다. 편집은 문제의 워크로드 서브넷을 담당하는 테이블로만 제한하세요.

데이터 경로는 이 모든 것과 별개입니다. 보안 그룹은 상태 저장이고 네트워크 ACL은 그렇지 않으며, 호스트 방화벽이나 비대칭 반환 경로는 라우팅이 올바르게 전달한 트래픽을 버릴 수 있습니다. 광고된 집계는 그 안의 모든 서비스에 권한을 주지도 않으므로, 주소가 우연히 BGP 광고에 나타나는지에 의존하지 말고 정책 경계에서 액세스를 제한하세요.

모든 라우트 테이블 쿼리의 변경 전과 변경 후를 변경 기록에 저장하세요. 변경이 상황을 악화시키면 이전 라우트를 복원하고 같은 쿼리로 확인하세요. 검증할 수 없는 롤백은 추측에 불과합니다.