Transit VPC를 통한 Cloud HUB 디자인하기 – AWS 서드 파티 도구 기반

Amazon Virtual Private Cloud(VPC)는 AWS 클라우드의 가상네트워크 환경을 구성하는 기본 서비스로서, 필요에 따라 원하는 수 만큼의(기본: 리전당 5개) 가상 네트워크 환경을 생성하실 수 있습니다. 그러나, 기존 데이터 센터나 사무실의 온-프레미스 네트워크 혹은 복수의 VPC를 서로 연동해야하는 경우가 있습니다. 이때, VPC간 연결 혹은 VPC와 온 프레미스(데이터 센터)를 어떻게 연동할지, 그리고 더 나아가 구성된 네트워크 환경에서 운용될 어플리케이션 서비스의 트래픽 흐름은 어떻게 될지 등을 면밀히 검토해 보아야 합니다.

온 프레미스(데이터 센터)와 연결 구성시 추천하는 첫번째 방법은 AWS Direct Connect를 활용하여, 모든 VPC에 가상 회선(Virtual Circuit) 을 할당하여 상호간 라우팅이 가능하도록 구성하는 것입니다. 그런데, 단일 리전 연동이 아닌 복수개의 리전에 걸쳐 AWS클라우드 가상 네트워크 인프라를 구성해야 하는 요건이 있을 경우에는 모든 VPC에 Direct Connect의 가상 회선을 연결하는 것은 사실상 불가능에 가깝습니다.

이러한 상황에서 고려해 볼 수 있는 아키텍쳐 디자인이 바로, 두번째로 Transit VPC를 통한 Cloud HUB 디자인 입니다. Cloud HUB는 말그대로 하나의 VPC가 모든 연결을 맺는 HUB VPC가 되고, 온 프레미스(데이터센터) 및 다른 VPC들은 Spoke VPC 가 되게 한후, 모든 통신은 HUB VPC를 경유하게 하는 구성입니다.

CSR100V를 통한 Cloud HUB 디자인
이러한 구성을 위한 필수 요건으로 Transitive Routing(전달받은 라우팅 경로를 3자에게 전달 방식)이라고 하는 기능이 필요하며, AWS Marketplace의 Cisco 소프트웨어 라우터인 CSR1000V와 같은 서드 파티 제품을 사용하여 아래와 같이 구성할 수 있습니다.

[그림1. Cisco CSR1000V를 이용한 Transitive Routing 구성 방식]

Cisco CSR1000V는 Cisco의 하드웨어 라우터 제품 중 ASR(Aggregation Services Router) 이라고 하는 엔터프라이즈 엣지(Edge)용 라우터를 가상 머신(VM)의 형태로 출시한 소프트웨어 라우터입니다. OSPF, EIGRP, BGP 등의 다양한 라우팅 프로토콜 및 IPSEC VPN ,방화벽 등의 보안기능들을 지원합니다. 또한, CSR 이 가지고있는 IOS-XE라는 운영체제(OS)는 하드웨어 제품과 동일한 CLI 및 인터페이스를 제공하여 많은 네트워크 엔지니어 들에게 친숙한 구성 환경을 제공한다는 장점을 가지고 있습니다.

상기 디자인과 같이 CSR1000V를 HUB VPC의 라우터로 구성하면 Spoke VPC가 생성된 AWS리전에 상관없이 스포크 일대일(Spoke-to-Spoke)통신 또는 스포크와 허브간(Spoke-to-Hub) 통신이 IPSEC 터널을 통해 쉽게 이루어지 됩니다. 특히, Cisco 라우터 설정에 익숙하지 않은 사용자라고 할지라도 Transit Network VPC (Cisco CSR 1000V 기반 아키텍쳐) 백서에 포함된 CloudFormation 템플릿을 사용하면, 손쉽게 위와 같은 Cloud HUB구성을 하실 수 있습니다. 또한, 새로운 VPC 추가 시에도 간단히 VGW에 특정 태그(Tagging)만 추가하면 자동으로 Cloud HUB환경에 Spoke VPC로 등록 되는 환경이 만들어 집니다.

다만, 아직 서울리전에는 Cisco CSR 1000V제품이 출시되어 있지않아 서울 리전을 HUB로 지정할 수는 없습니다. Cisco CSR1000V를 사용하기 어려울 시에는 AWS Marketplace에 등록되어 있는 Vyatta 또는 Fork버전인 VyOS 를 사용하여 유사한 구성을 하실 수 있습니다. Vyatta는 리눅스 기반으로 Qugga등의 오픈소스 라우팅 소프트웨어들이 패키지의 형태로 구성된 제품으로서, 현재 저렴한 커뮤니티 버전이 제공되며, AWS Marketplace를 통해 서울리전에서도 사용하실 수 있습니다. 이에 따라, 해당 제품을 기반으로 서울 리전을 HUB 로 구성가능한 Cloud HUB디자인을 살펴보도록 하겠습니다.

Vyatta 및 VyOS를 통한 Cloud HUB 디자인

[그림2. Vyatta 혹은 VyOS를 이용한 Transitive Routing 구성 방식]

상기 디자인은 앞에 사용된 Cisco CSR1000V 이 있던 자리를 Vyatta 혹은 VyOS라우터로 변경한 디자인 입니다. Vyatta 라우터도 CSR1000V과 같이 BGP를 포함한 다양한 라우팅 프로토콜을 지원하여, 기능적으로 손쉽게 CSR1000V과 같은 역할을 수행할 수 있습니다. 그런데, 실제 IPSEC 터널 구성을 해보면 아래와 같이, IP SEC 터널은 정상적으로 맺어져 UP 상태가 되더라도, BGP Neighbor로부터 아무 경로도 업데이트 받지 못하는 모습을 보시게 됩니다.

[그림 3. Transit VPC에서 확인하는 BGP 라우팅 테이블]

[그림 4. Spoke VPC의 IPSEC 터널 정보 : Tunnel UP상태지만 라우팅 정보는 수신 안됨]

위와 같은 증상은 타 리전간의 구성(AS Number가 다를 경우)에서는 나타나지 않고, 같은 리전 내의 VPC간 구성에서 나타납니다. 그 원인은 BGP 라우팅 프로토콜이 가진 기본적인 루프 방지 기능(Loop prevention)때문에, 동일 AS Number를 가진 BGP Neighbor로부터 들어오는 라우팅 업데이트는 차단을 하도록 되어 있는 라우팅 규칙 때문입니다.

Cisco CSR1000V 제품으로 구성된 이전 디자인에서는 정상적으로 라우팅 테이블이 업데이트 되는 모습을 보실수 있는데 , 이는 Cisco CSR1000V 의 경우 ‘as-override’ 라는 AS Number 정보를 무시하는(Override) 기능을 가지고 있기 때문인데, Vyatta 라우터의 경우는 아직 해당 기능을 제공하지 않습니다. 따라서, Vyatta라우터를 사용한 위와 같은 VPC 구성 시에는 Spoke VPC들이 서로 다른 리전(서로 다른 AS Number사용시)에 있을 때만 구성하실 수 있다는 제약이 있습니다.

단일 VPC(VGW)를 통한 Cloud HUB 디자인 아키텍처
이러한 Vyatta 라우터가 가진 제약을 극복할 수 있는 방안으로 고려해 보실 수 있는 새로운 VPC 디자인은 아래와 같이 하나의 VPC(VGW)를 HUB로 지정하고, 각각의 Spoke VPC에 Vyatta 라우터를 구성한 후 HUB VPC에 연결하는 방법입니다. 이때 각각의 Spoke VPC는 IPSEC 터널 구성시 원하는 숫자(지원 AS Number 대역 : 64512 ~ 65535)를 AS Number로 지정할 수 있으므로 이전 디자인상의 제약 사항 이었던 AS Number의 중복으로 인한 문제는 사라지게 됩니다.

Amazon VPC에서 IP SEC VPN을 구성하는 절차는 이 글의 주제에 포함되지 않으므로 자세히 말씀 드리진 않겠지만, 간략히 다음과 같은 단계에 의해 구성됩니다. (더 자세한 사항은 기술 문서를 참고하시기 바랍니다.)

CGW생성 : 생성시 온 프레미스 VPN장비의 Public IP 주소 설정 (또는 EC2 EIP)
VGW생성 후 구성을 원하는 Spoke VPC에 부착 (Attach)
생성한 CGW와 VGW를 연결하여 VPN 연결 설정 후, 라우터 설정 파일을 다운로드 받아 VPN장비(하드웨어 또는 EC2 인스턴스)에 설정

Amazon VPC는 사용자들이 보다 쉽고 빠르게 다양한 제품들과의 IPSEC 터널 구성을 지원하고 있는데, 아래 화면과 같이 다양한 장비에 대한 설정파일을 제공하고 있어서, 사용자는 손 쉽게 원하는 장비에 대한 설정파일을 받아 설정을 완료할 수 있습니다.

Cloud HUB 구성 시작하기
본격적으로 Vyatta에 대한 설정파일을 다운로드 받아, 해당 내용을 그대로 Vyatta 라우터에 적용하여 구성해보겠습니다. 이때 주의할 사항으로 Vyatta인스턴스에 해당 설정을 적용할 때에는, 기본적으로 Public IP(EIP) 정보가 설정되어 있는 로컬 어드레스(Local-address) 부분에 현재 Vyatta 라우터 인스턴스의 eth0인터페이스에 할당되어 있는 Private IP정보로 변경해 주시면 됩니다.

set vpn ipsec ike-group AWS lifetime '28800'
set vpn ipsec ike-group AWS proposal 1 dh-group '2'
set vpn ipsec ike-group AWS proposal 1 encryption 'aes128'
set vpn ipsec ike-group AWS proposal 1 hash 'sha1'
set vpn ipsec site-to-site peer 52.193.81.195 authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer 52.193.81.195 authentication pre-shared-secret '@#$@#$'
set vpn ipsec site-to-site peer 52.193.81.195 description 'VPC tunnel 1'
set vpn ipsec site-to-site peer 52.193.81.195 ike-group 'AWS'                                    
set vpn ipsec site-to-site peer 52.193.81.195 local-address '52.197.159.126' -> Private IP변경
set vpn ipsec site-to-site peer 52.193.81.195 vti bind 'vti0'
set vpn ipsec site-to-site peer 52.193.81.195 vti esp-group 'AWS'

또한, BPG 라우팅 설정 부분에서도 아래와 같이 Spoke VPN의 Subnet중 원하는 대역 혹은 VPC의 모든 CIDR대역을 HUB로 광고(Advertise)하는 설정을 추가해야 합니다.

이때 만약 Vyatta인스턴스가 속한 Subnet이 아닌 VPC 전체에 대한 CIDR범위를 BGP 설정에 추가하면, 정상적으로 HUB VPC에 라우팅이 광고 되지 않으며, 반대로 Vyatta 인스턴스가 속한 Subnet 범위에 맞는 CIDR 범위만 을 BGP설정에 추가하면, 정상적으로 라우팅이 HUB VPC(VGW)로 광고 되는 모습을 볼 수 있지만, 해당 VPC가 가지는 다른 Subnet 영역에 대한 경로들은 추가되지 않아 궁극적으로 우리가 원하는 Spoke VPC의 Private Subnet 간 통신을 위한 라우팅 구성이 불가하게 됩니다.

위의 문제를 해결하기 위해서는, 각 Spoke VPC의 Vyatta 라우터 설정에서, 통신을 위해 라우팅 설정이 필요한 VPC CIDR 범위를 Static 라우팅을 통해 먼저 설정한 후, BGP설정에도 해당 대역을 추가해 주어야 합니다.

이 작업까지 완료하면, Vyatta 라우터가 위치한 Subnet 뿐만 아니라, 전체 VPC의 CIDR을 HUB VPC의 VGW로 광고하게 되며, 모든 경로(Route)들은 HUB VPC에 연결된 Spoke VPC로 전파되어 Any to Any 의 라우팅 경로가 구성됩니다. 아래는 Spoke VPC A – CIDR : 10.0.0.0/16 설정 예시입니다.

set protocols bgp 65002 network 0.0.0.0/0
set protocols static 10.0.0.0/16 next-hop 10.0.0.1 distance 10
#(10.0.0.0/16은 VPC 전체의 CIDR이며, 10.0.0.1은 해당 VPC에서 사용하는 Default G/W로써, 여러분이 사용하시는 VPC CIDR의 .1 주소는 기본적으로 Default G/W로 설정되어 있습니다.)
set protocols bgp 65002 network 10.0.0.0/16 
# BGP에 해당 CIDR (10.0.0.0/16)을 추가

모든 설정을 마치면, 아래와 같이 HUB VPC의 VPN 터널의 상태가 UP으로 변경됩니다.

라우팅 경로가 모든 VPC에 제대로 업데이트 되었는지 여부는 다음과 같이 확인해 볼 수 있습니다.

HUB VPC : VGW로부터 연결된 Spoke VPC 들의 경로가 자동으로 업데이트 되는지 확인
Spoke VPC A : HUB VPC – 100.64.127.224/27 , Spoke VPC B – 20.0.0.0/16 경로 확인
Spoke VPC A 의 Route 테이블 확인
Spoke VPC B : HUB VPC – 100.64.127.224/27 , Spoke VPC A – 10.0.0.0/16 경로 확인
Spoke VPC B 의 Route 테이블 확인

Cloud HUB 구성 테스트 하기

위와 같이 라우팅 정보가 정상적으로 확인되면 모든 설정이 끝난 것입니다. 마지막으로 Spoke to Spoke VPC 의 통신이 제대로 이루어 지는지 Ping테스트를 통해 확인해 보도록 하겠습니다.

Spoke VPC A 의 Private Subnet 에 있는 EC2 인스턴스(0.1.40) 에서 Spoke VPC B의 Private Subnet 에 있는 EC2인스턴스(20.0.1.138)로 Ping 테스트
Spoke VPC A 의 Private Subnet 에 있는EC2인스턴스(0.1.40) 에서 HUB VPC의 Private Subnet에 있는 EC2인스턴스(100.64.127.231)로 Ping 테스트

이 글에서 우리는 Cloud HUB VPC 구성을 위한 몇 가지 옵션들과 주의점들을 살펴 보았습니다. 만약 여러분이 글로벌 어플리케이션 서비스 혹은 공유 서비스 기반의 멀티 테넌트 어플리케이션 서비스를 구축 하시고자 한다면, 이 글에 설명된 것처럼Cloud HUB VPC 디자인을 통해 IP SEC 터널 기반의 멀티 VPC연동을 통한 확장성 있는 네트워크 인프라를 구성하실 수 있습니다.

자세한 것은 차근 차근 순서대로 설정 방법을 담은 가이드 문서를 참고하시기 바랍니다.

Transit-VPC-Network-Vyatta-KO-v1.0.pdf

더 자세히 알아보기

본 글은 아마존웹서비스 코리아의 솔루션즈 아키텍트가 국내 고객을 위해 전해 드리는 AWS 활용 기술 팁을 보내드리는 코너로서, 이번 글은 김용우 솔루션즈 아키텍트께서 작성해주셨습니다.
speaker_Kevin1

Amazon Web Services 한국 블로그

Transit VPC를 통한 Cloud HUB 디자인하기 – AWS 서드 파티 도구 기반

주요 링크 모음

팔로우하기