AWS Transit Gateway에서 여러 VPC를 위한 하나의 사이트 간 VPN

VPN을 한 번 연결하고 각 VPC를 하나의 전송 게이트웨이에 연결한 뒤 연결과 전파를 분리하면, 스포크는 사무실에는 닿지만 서로에게는 닿지 않습니다.

이번 분기에 두 VPC가 사무실 네트워크를 필요로 하며, 견적이 깨지는 곳은 바로 두 번째 터널입니다. AWS Transit Gateway는 공유 라우팅 허브 역할을 할 수 있습니다: VPN은 한 번 연결되고, 각 VPC는 같은 허브에 연결됩니다. 그러면 온프레미스 네트워크가 하나의 연결로 연결된 모든 VPC에 도달합니다. 이는 라우팅 결정의 소유자가 누구인지를 바꾸며, 대부분의 설계가 틀리는 부분이 바로 여기입니다.

VPN 연결과 VPC 연결은 같은 게이트웨이 위의 별개 객체이므로, 라우팅 관계는 그 뒤에 구축해야 합니다.

On-premises network <-> Site-to-Site VPN <-> Transit Gateway
                                            |- VPC A
                                            |- VPC B

피어링이 사람들이 기대하는 지름길이 아닌 이유

솔깃한 대안은 VPN을 VPC A에서 종료하고 VPC B를 그것에 피어링하는 것입니다. 일반적인 VPC 피어링은 A의 VPN 연결을 통한 가장자리 간 전송을 제공하지 않습니다. 피어는 피어링 자체가 제공하는 주소에만 도달하며, VPN 가장자리는 그중 하나가 아닙니다. 전송은 허브가 주는 것이고, 피어링은 한 쌍을 줍니다.

그 제한은 피어링의 속성이지 올릴 수 있는 할당량이 아닙니다.

연결과 전파는 다른 일을 합니다

전송 게이트웨이 내부에서 연결은 연결부에서 들어오는 트래픽을 조회하는 데 쓰이는 라우팅 테이블을 선택합니다. 전파는 어느 테이블이 연결부의 학습되거나 연결된 프리픽스를 받을지 정합니다. 하나의 연결부가 한 테이블에 연결되면서 여러 테이블로 전파될 수 있습니다. 둘을 혼동하는 것이 아무도 계획하지 않은 도달 가능성으로 설계가 끝나는 방식입니다.

완전히 연결된 작은 허브는 쉬운 경우입니다.

모든 연결부를 하나의 테이블에 넣으면 VPN과 두 VPC 프리픽스가 깔끔하게 해석됩니다. 이는 조직이 의도한 적 없을 수 있는 VPC 간 도달 가능성도 허용합니다, 공유 테이블에는 스포크라는 개념이 없기 때문입니다.

워크로드 경로는 다른 곳에 있습니다

각 워크로드 서브넷은 의도한 온프레미스 프리픽스를 위해 전송 게이트웨이로 향하는 자체 경로가 여전히 필요합니다. 그 VPC 라우팅 테이블은 전송 게이트웨이 자체의 테이블과 별개인 객체입니다. 필요한 프리픽스를 추가하고 모든 대상을 새 기본값으로 바꾸는 대신 기존 경로를 유지하십시오. 서브넷 경로는 고객 장치에 아무것도 광고하지도 않습니다.

피어링은 어느 쪽도 제공하지 않으므로 동적 또는 정적 라우팅을 의도적으로 선택하십시오.

온프레미스 접근을 잃지 않고 스포크 격리하기

A와 B가 모두 사무실에 도달할 수 있지만 서로 라우팅해서는 안 된다면 테이블을 나누십시오. VPN 연결부의 연결된 테이블은 VPC 프리픽스를 담습니다. VPC 연결부의 연결된 테이블은 온프레미스 프리픽스를 담고, A와 B를 잇는 경로는 없습니다. 전파가 그 관계를 만들어 내므로 모든 기본 연결을 받아들일 필요가 없습니다.

이것은 라우팅 격리이며, 애플리케이션 권한 부여가 아닙니다.

보안 그룹, 네트워크 ACL, 호스트 방화벽, 각 서비스 자체의 권한이 여전히 어떤 트래픽이 허용되는지 결정합니다. 검사가 필요하면 허브가 해 주리라 가정하지 말고 지원되는 경로를 명시적으로 설계하십시오.

허브가 고치지 못하는 것

주소 계획은 여전히 겹치지 않아야 합니다, 허브는 하나의 프리픽스가 두 워크로드를 식별하게 두지 않기 때문입니다. 각 VPC 연결부는 워크로드가 기대하는 Availability Zone 범위가 필요합니다. BGP를 쓰면 고객 장치의 각 필수 프리픽스로 돌아가는 경로가 설계와 그 가져오기 정책에 맞아야 합니다. 빠진 광고는 끊긴 터널과 똑같이 보입니다.

VPN 연결과 전송 게이트웨이는 이제 공유 인프라입니다.

터널 이중화, 장치 용량, 모니터링, 유지보수는 각 VPC를 독립적으로 연결된 것으로 다루지 말고 모든 의존 VPC를 중심으로 계획하십시오.

기존 virtual private gateway 구성에서의 마이그레이션도 같은 명시적 계획이 필요합니다. 연결부와 정책을 만들고, 통제된 워크로드 경로 하나를 옮기고, 이전 경로를 폐기하기 전에 허용된 관계와 거부된 관계를 확인하십시오. 중앙 집중화는 네트워크 팀에 공유 연결을 관리할 한 곳을 줄 때 도움이 되고, 하나의 큰 테이블 뒤에 누가 누구에게 닿을 수 있는지를 감출 때 해가 됩니다.

관련 글