AWS VPN에 온프레미스 서브넷 추가하기: VGW와 Transit Gateway 비교

기존 Site-to-Site VPN이 10.60.0.0/16을 전달하고 있고, 같은 온프레미스 게이트웨이 뒤에 새 서비스 네트워크가 10.70.0.0/16으로 나타났으며, 누군가 프록시가 필요한지 묻습니다. 보통은 필요하지 않습니다. 라우팅된 경로가 프리픽스를 전달할 수는 있지만 세 가지가 맞아떨어질 때만 가능하며, 그 세 가지가 무엇인지는 이미 운영 중인 AWS 아키텍처에 달려 있습니다. 가상 프라이빗 게이트웨이에는 라우팅 테이블 경계가 하나 있고, 트랜짓 게이트웨이는 두 번째를 더합니다. 광고는 맞고 테이블이 틀리면 정상으로 보이지만 아무것도 전달하지 못하는 세션이 만들어집니다.

게이트웨이가 실제로 전달할 수 있는 프리픽스를 광고하십시오

어떤 광고든 의미를 가지려면 온프레미스 게이트웨이에 새 네트워크로 향하는 경로가 먼저 있어야 합니다. BGP로 10.70.0.0/16을 광고하면 그 범위의 패킷을 어디로 보낼지 AWS에 알려 주지만, 반대편에서 그 범위에 도달할 수 있게 하는 로컬 전달 경로를 만들지는 않습니다. 게이트웨이에 해당 프리픽스를 보유한 장비를 가리키는 경로가 있고, 그 장비가 해당 주소에 응답하도록 구성되어 있는지 확인하십시오. 다음 제약은 내보내기 정책과 허용되는 프리픽스 한도입니다. 세션이 걸러낸 프리픽스는 AWS에 아예 도달하지 않습니다.

집계 경로와 더 구체적인 경로는 의도적으로 유지하십시오. 두 방향에서 들어오는 중복 경로는 설계 결정이며, 나중에 발견할 세부 사항이 아닙니다.

경로 하나: 가상 프라이빗 게이트웨이 경계

가상 프라이빗 게이트웨이의 경우 AWS VPN 라우팅 문서는 두 가지 배포 모드, 즉 정적 경로와 BGP 광고를 설명하며, 둘 다 애플리케이션이 실제로 사용하는 서브넷 라우팅 테이블에 의존합니다. 전체 범위를 제어할 때는 전파가 편리하고, 목적지를 대상 옆에 나열해 보고 싶을 때는 명시적 경로가 따지기 쉽습니다. 어느 쪽이든 점검은 같습니다. 특정 애플리케이션 서브넷의 테이블에 새 프리픽스에 대한 VPN 대상으로 가는 작동 경로가 있는지, 그리고 더 구체적인 경로를 이기는지 확인합니다.

정상적인 BGP 세션은 채널이 존재함을 증명합니다. 특정 서브넷 테이블이 그 경로를 받아들였는지에 대해서는 아무것도 말해 주지 않습니다.

경로 둘: 트랜짓 게이트웨이가 테이블을 하나 더한다

트랜짓 게이트웨이는 그 하나의 질문을 둘로 나눕니다. VPC 서브넷은 목적지를 트랜짓 게이트웨이 연결로 보내야 하고, 그다음 트랜짓 게이트웨이 라우팅 테이블이 같은 프리픽스에 대해 VPN 연결을 선택해야 합니다. 연결과 전파 설정이 어떤 연결된 네트워크가 경로를 받는지 결정하므로, VPN이 프리픽스를 올바로 광고해도 테이블이 올바른 라우팅 테이블과 연결된 적이 없는 VPC에는 끝내 도달하지 않을 수 있습니다.

흔한 실패는 한 테이블에는 있고 다른 테이블에는 없는 경로이며, 각 팀은 자기 쪽이 맞다고 확신합니다. 두 아키텍처를 비교하면 이 추가 경계가 전부입니다. 살펴볼 곳이 더 많고, 누가 경로를 받는지 더 정밀하게 제어할 수 있습니다.

경로 전파도 모든 연결에 프리픽스를 주지는 않습니다. 받도록 구성된 테이블에 배포할 뿐입니다.

반환 경로는 그 자체로 정책 결정입니다

들어오는 트래픽은 교환의 절반에 불과합니다. 새 온프레미스 네트워크에는 올바른 게이트웨이를 통해 AWS 원본 프리픽스로 돌아가는 경로가 필요하고, 양쪽의 보안 정책이 그 원본과 목적지 쌍을 허용해야 합니다. 터널이 트래픽 선택자로 보호 범위를 협상한다면 새 프리픽스가 그 안에 있어야 하며, 그렇지 않으면 어떤 라우팅 테이블도 참조되기 전에 패킷이 버려집니다.

주소 중복은 또 다른 함정입니다. 겹치지 않고 명시적으로 소유한 범위는 이 문제를 단순하게 만듭니다. 겹치는 범위는 변환 또는 재설계를 뜻하며, 둘 중 어느 것도 같은 절차의 호환 가능한 변형이 아닙니다.

새 네트워크의 원본과 애플리케이션 서브넷의 목적지로 시험하고, 다음으로 반대 방향에서 반복하십시오. 한 방향 시험은 한 방향만 증명합니다.

프록시가 정말로 더 나은 경계가 될 때

요구 사항이 좁은 서비스 인터페이스일 때, 애플리케이션이 이미 그 아키텍처를 전제로 할 때, 또는 원하지 않는 변환 없이는 네트워크 경로가 프리픽스를 나를 수 없을 때 프록시는 제자리를 얻습니다. 아무도 확인하지 않은 라우팅 테이블 항목의 대체 수단은 아닙니다.

다음 순서로 판단하십시오. 로컬 전달, 광고, 테이블 경계, 반환 정책입니다. 처음 실패한 것을 고치고, 그다음에야 라우팅된 경로가 과연 정답인지 물으십시오.