🚦 LabGuide - AWS Transit Gateway

작성자 : ongja.cloudnet@

AWS Transit Gateway 참고 링크

AWS Transit Gateway 공식 문서
AWS Transit Gateway 개요
Multicast on AWS Transit Gateway
AWS Transit Gateway 모니터링 중앙 집중화
AWS Transit Gateway 요금

💡 AWS 서비스 관련해서는 항상 최우선으로 ‘AWS 설명서’ 를 읽어보는 것을 추천한다.
한글 번역이 매끄럽지 못하면 English 로 변경 후 읽어보길 바란다.

---

1. AWS Transit Gateway Theory

1.1 AWS Transit Gateway 란?

• AWS Transit Gateway는 VPC나 On-Premise 등의 네트워크를 단일 Gateway에 연결할 수 있도록 지원해 주는 서비스이다.
• AWS Transit Gateway를 사용하면 중앙 게이트웨이와 네트워크 전반의 단일 연결만 생성하여 관리하면 된다.
• Hub & Spoke 모델로 구성되며, 연결 된 네트워크들은 다른 네트워크에 연결할 필요 없이 AWS Transit Gateway에만 연결하면 되므로 관리를 크게 간소화하고 운영 비용을 크게 줄여 준다.

1.2 AWS Transit Gateway 주요 기능

• 라우팅

  : 동적 / 정적의 Layer 3 라우팅을 지원한다.

• 엣지 연결

  : VPN을 사용하여 AWS Transit Gateway와 온프레미스 게이트웨이 간에 VPN 연결을 생성할 수 있다.

• VPC 기능 상호 운용성

  : VPC에 있는 인스턴스가 AWS Transit Gateway에 연결된 다른 Amazon VPC에 있는 NAT 게이트웨이, Network Load Balancer, AWS PrivateLink 및 Amazon Elastic File System 등에 액세스할 수 있다.

• 모니터링

  : AWS Transit Gateway는 Amazon CloudWatch 및 Amazon VPC 흐름 로그와 같은 서비스에서 사용하는 통계와 로그를 제공한다.

• 리전 간 VPC 피어링

  : AWS Transit Gateway 리전 간 VPC 피어링은 AWS 글로벌 네트워크를 사용하여 AWS 리전을 통해 트래픽을 라우팅할 수 있도록 지원한다.

• 멀티캐스트

  : 고객이 클라우드에서 멀티캐스트 애플리케이션을 쉽게 구축하고 수백 개의 수신자까지 멀티캐스트 구성을 쉽게 모니터링, 관리 및 확장할 수 있도록 지원한다.

• 보안

  : AWS Transit Gateway는 Identity and Access Management(IAM)와 통합되므로, AWS Transit Gateway에 대한 액세스를 안전하게 관리할 수 있다.

• 지표

  : 성능과 송수신된 바이트, 패킷, 폐기된 패킷을 비롯한 트래픽 지표를 통해 글로벌 네트워크를 모니터링한다.

1.3 Non Transit Gateway vs Transit Gateway

그림 1.1 Transit Gateway 미사용 / 사용 비교 Diagram

• 다수의 VPC 환경이나 On-Premise 환경에 대해 Transit Gateway를 사용하지 않고, VPC Peering과 VPN, Direct Connect를 통한 개별 연결이 이루어져 복잡한 작업 환경

• Transit Gateway를 중심으로 연결만 하면 되어, 중앙 집중형 간략한 작업 환경

💡 Transit Gateway를 사용하면 복잡한 AWS 네트워크 아키텍처를 간소화 가능하여 관리 및 운용 효율이 보장되며, 향상된 보안과 멀티캐스트를 활용하여 유용한 통신이 가능하다.

1.4 AWS Transit Gateway Key Words

• Transit Gateway - VPC들의 접점이 되는 중앙 집중형 단일 Gateway로 Hub & Spoke 환경에서 Hub 역할

• Transit Gateway Attachment - VPC를 연결하는 방식 (현재 버전으로 3가지 방식 지원)

  • VPC Attachment : TGW와 동일 Region 내 VPC를 직접적으로 연결 (다른 계정에 생성한 VPC도 연결 가능)

  • VPN Attachment : TGW와 VPN를 연결 (Site to Site VPN)

  • TGW Peering : TGW와 다른 Region의 TGW 간 연결 (Inter Region TGW Peering)

• Transit Gateway Routing Table - TGW에서 관리하는 라우팅 테이블

• Transit Gateway Sharing - TGW를 공유하여 다른 AWS 계정에게 전달하여 연결 가능 (Resource Access Manager 활용)

• Transit Gateway Multicast - TGW를 통해 Multicast 트래픽을 전달

  • Multicast Domain : Multicast 트래픽을 처리할 TGW 지정

  • Multicast Associate : Multicast 트래픽을 처리할 TGW Attachment 지정

  • Multicast Group Source : Multicast Sender 대상 지정

  • Multicast Group Member : Multicast Reciever 대상 지정

• Transit Gateway Network Manager - 논리적 다이어그램 또는 지리적 맵으로 중앙 대시 보드에서 글로벌 네트워크를 시각화

---

2. AWS Transit Gateway Lab Preview

2.1 Lab Topology

그림 2.1 AWS Transit Gateway Lab Topology

① TGW Intra Region VPC Attachment - 버지니아에 MAIN SITE 구축 (동일 리전 내 VPC와 TGW를 생성하여 연결)

② Multicast on TGW - 버지니아 MAIN SITE에서 Multicast 통신 테스트

③ TGW Multi Account VPC Attachment - 다른 계정의 버지니아에 SUB SITE 구축 후 Resource Access Manager를 통해 TGW를 공유하고 다른 계정의 VPC와 연결

④ TGW Inter Region Peering - 아일랜드 에 BRANCH SITE 구축 후 TGW 간 피어링 연결

⑤ TGW VPN Attachment - 서울에 OpenSwan VPN 서버를 설치 후 TGW와 연결

⑥ NATGW though TGW - Private Subnet 중 DEV 환경의 대상으로, TGW를 통해 버지니아 MAIN SITE의 Egress VPC에 존재하는 NAT GW로 인터넷 통신

⑦ TGW Network Manager - TGW 네트워크 매니저를 통해 글로벌 네트워크 시각화

2.2 AWS 기본 설정

• 본 실습에서 활용할 AWS Region은 버지니아, 아일랜드, 서울 이다. 해당 Region에 대한 EC2-Key Pair를 생성
• TGW Multi Account VPC Attachment 테스트를 위해 본 계정 외에 서브 계정이 필요
• 모든 Region에 대한 기본적인 인프라는 CloudFormation에 의해 자동 구축 (모든 인프라가 구축되는 것은 아니다.)
• 생성된 모든 EC2-Instance의 IP 주소는 X.X.X.10으로 고정하였다. (예시: 10.1.1.10, 10.5.1.10 …)

2.3 CloudFormation (Infrastructure as Code)

⤵ Download Virginia_TransitGW_Lab_CF.yaml

⤵ Download Ireland_TransitGW_Lab_CF.yaml

⤵ Download Seoul_TransitGW_Lab_CF.yaml

• 버지니아, 아일랜드, 서울에 배포할 Cloud Formation 템플릿이다.
• 지금 바로 배포하지 않고, 실습 단계 별로 하나씩 배포할 것이니 일단 다운로드만 받아 두자.

💡 본격적인 실습에 앞서, 리소스 당 소량의 과금이 불가피 하다.
자세한 사항은 Transit Gateway 요금 링크를 참고 바란다.

---

3. AWS Transit Gateway Intra Region VPC Attachment Test

• 이 번 단계의 실습은 동일 리전에 존재하는 VPC와 TGW 간의 연결을 테스트한다. (Intra Region VPC Attachment)
• 실습 환경: Region - 버지니아 , Account - 본 AWS 계정

3.1 버지니아 CloufFormation 배포

3.1.1) CloudFormation 배포

• 2.3항에서 제공한 Virginia_TransitGW_Lab_CF.yaml 파일을 배포하자.

💡 주의: CF Condition에 의해 Main Site와 Sub Site의 생성 인프라가 다르다. 파라미터 값을 Main으로 지정하자!

그림 3.1 버지니아 CF 템플릿 생성 중 EnvType 파라미터 값을 Main으로 지정

버지니아 CF 생성 인프라

- EC2-Instance 3개
- VPC 2개, Public Subnet 1개, Private Subnet 2개, Routing Table 3개, IGW 1개
- Security Group 2개

• 위 생성된 인프라가 정상적으로 올라왔는 지 확인하자.

3.1.2) MAIN-MGT EC2 접속

• 현재 접속 가능한 Public Subnet에 위치한 MAIN-MGT EC2에 SSH 접속

cat <<EOT >> list.txt
google.com
10.1.1.10
10.2.1.10
10.2.2.10
10.3.1.10
10.3.2.10
10.4.1.10
10.5.1.10
10.6.1.10
EOT

• list.txt 파일을 생성을 위해 위 값을 붙여넣자 (본 실습에서 생성될 모든 EC2 IP와 구글주소)

[root@MAIN-MGT ec2-user]# vi pingall.sh
#!/bin/bash
cat list.txt |  while read output
do
    ping -c 1 -W 1 "$output" > /dev/null
    if [ $? -eq 0 ]; then
    echo "node $output is up"
    else
    echo "node $output is down"
    fi
done
[root@MAIN-MGT ec2-user]# chmod +x pingall.sh

• vi pingall.sh 로 진입하여 위와 같이 스크립트를 생성한다.
• chmod +x pingall.sh 로 스크립트 권한을 부여한다.

[root@MAIN-MGT ec2-user]# ./pingall.sh
node google.com is up
node 10.1.1.10 is up
node 10.2.1.10 is down
node 10.2.2.10 is down
node 10.3.1.10 is down
node 10.3.2.10 is down
node 10.4.1.10 is down
node 10.5.1.10 is down
node 10.6.1.10 is down
[root@MAIN-MGT ec2-user]#

• ./pingall.sh 로 전체 타겟에 대한 Ping 테스트가 가능하다.
• 현재 자기 자신과 외부 인터넷만 가능하다.

3.2 Transit Gatewaay 생성

• VPC —> Transit Gateway —> Create Transit Gateway

그림 3.2 Create Transit Gateway

• Name Tag 기입하고, Multicast support enable을 반드시 체크 하자! (4장 Multicast on TGW 실습 때 필요하다. 추후 수정이 되지 않아 미리 활성화)
• 1~2분 정도 대기하면, 상태가 available 로 변경 된다.

3.3 Transit Gateway Attachment 생성

• VPC —> Transit Gateway Attachment —> Create Transit Gateway Attachment (😓 굳이 한글 번역을 해놔서 Attachment를 첨부파일로 표현함;)

  • Transit Gateway ID 지정

  • Attachment Type : VPC

  • Attachment Name Tag : MAIN-VPC01-ATT

  • VPC ID : VPC01 —> AZ & Subnet 지정

  ---

  • 상동

  • Attachment Name Tag : MAIN-VPC02-ATT

  • VPC ID : VPC02 —> AZ & Subnet 지정

• Transit Gateway Attachment 를 2개 생성 한다. (1~2분 정도 대기)

그림 3.3 TGW Attachment 정보 확인

• 생성된 2개의 TGW Attachment를 확인할 수 있다. (Resource Type: VPC, State: available)

3.4 Routing Table 설정

• CloudFormation에 의해 생성된 3개의 라우팅 테이블에 경로를 추가한다.

  • 라우팅 편집 —> 라우팅 추가 —> 10.0.0.0/8 대역, tgw-xxxx 타겟

그림 3.4 라우팅 테이블 편집 (10.0.0.0/8 대역을 TGW로 전달하는 경로 추가)

• 라우팅 테이블 3개 모두 라우팅 정책 추가

3.5 Verify

[root@MAIN-MGT ec2-user]# ./pingall.sh
node google.com is up
node 10.1.1.10 is up
node 10.2.1.10 is up
node 10.2.2.10 is up
node 10.3.1.10 is down
node 10.3.2.10 is down
node 10.4.1.10 is down
node 10.5.1.10 is down
node 10.6.1.10 is down
[root@MAIN-MGT ec2-user]#

• MAIN-MGT EC2에 접속하여 pingall.sh 스크립트를 수행한다.
• 버지니아 MAIN에 존재하는 EC2 끼리 통신이 가능하다.

3장 현재까지 완료된 구성도 확인

---

4. Multicast on Transit Gateway Test

• 이 번 단계의 실습은 TGW을 통해 Multicast 통신을 테스트한다. (Multicast on Transit Gateway)
• MAIN-MGT 인스턴스를 Multicast Sender로 하고, MAIN-TEST와 MAIN-DEV 인스턴스를 Multicast Receiver로 한다.
• Multicast 트래픽의 UDP 포트 번호에 대해 Security Group에서 허용해야 한다. (CF로 미리 설정해 놈)
• 실습 환경: Region - 버지니아 , Account - 본 AWS 계정

Multicast on transit gateways

참고 링크 : Multicast on transit gateway

Multicast 실습에 앞서 고려 사항

• 현재 Multicast 라우팅 기능은 버지니아 리전에서만 지원하고 있다.
• 해당 기능을 사용하려면 TGW를 생성할 때 Multicast Support를 활성해야 한다. (이미 활성화 함)
• IGMP는 미지원으로 TGW에서 Multicast Domain과 Sender / Receiver를 관리하여 라우팅 된다.
• EC2 인스턴스 타입이 Nitro 여야 Sender가 될 수 있고, Non Nitro가 Receicer가 될 수 있지만 Source/Destination Check를 비활성화해야 동작한다.
• 본 실습에서 CloudFormation으로 생성한 EC2 인스턴스 타입은 Nitro 타입으로 지정하였다.

4.1 Multicast 라우팅 설정 전에 테스트

4.1.1) MAIN-MGT 인스턴스에 접속 (Sender)

[root@MAIN-MGT ec2-user]# omping -m 239.1.1.1 -p 10000 10.1.1.10
10.1.1.10 : waiting for response msg
10.1.1.10 : joined (S,G) = (*, 239.1.1.1), pinging
10.1.1.10 :   unicast, seq=1, size=69 bytes, dist=0, time=0.016ms
10.1.1.10 : multicast, seq=1, size=69 bytes, dist=0, time=0.021ms
10.1.1.10 :   unicast, seq=2, size=69 bytes, dist=0, time=0.041ms
10.1.1.10 : multicast, seq=2, size=69 bytes, dist=0, time=0.046ms
10.1.1.10 :   unicast, seq=3, size=69 bytes, dist=0, time=0.050ms

• omping -m 239.1.1.1 -p 10000 10.1.1.10 명령어로 Multicast 트래픽을 발생 시킨다.
• Multicast IP 대역 : 239.1.1.1 , Port 번호 : UDP 10000

4.1.2) MAIN-TEST, MAIN-DEV 인스턴스에 접속 (Receiver)

• MAIN-TEST, MAIN-DEV은 Private Subnet에 위치하여 다이렉트로 SSH 접근이 불가하다.
• MAIN-MGT에 접근 후 ssh root@10.2.1.10과 ssh root@10.2.2.10 명령어로 거쳐서 접근한다.
• Key-Pair 없이 Root 계정으로 접근하며, 패스워드는 qwe123 이다.

[ec2-user@MAIN-MGT ~]$ ssh root@10.2.1.10
:
password:
:
[root@MAIN-TEST ~]#
[root@MAIN-TEST ~]# tcpdump ip dst 239.1.1.1 -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

• tcpdump ip dst 239.1.1.1 -nn 명령어로 목적지 IP가 239.1.1.1인 패킷을 잡아 출력한다.

그림 4.1 Multicast 라우팅 설정 전 테스트

• 좌측 Multicast Sender에서 239.1.1.1 트래픽을 발생하고 있지만, 우측 Multicast Receiver들로 인입되지 않는다.

4.2 Transit Gateway Multicast 설정

4.2.1) Create Transit Gateway Multicast Domain

• VPC —> Transit Gateway Multicast —> Create Transit Gateway Multicast Domain

  • Transit Gateway ID 지정

그림 4.2 Transit Gateway Multicast Domain 확인

4.2.2) Create Association

• VPC —> Transit Gateway Multicast —> 작업 —> Create Association

  • Choose attachment to associate : MAIN-VPC01-ATT

  • Choose Subnets to associate : Subnet 선택

  ---

  • Choose attachment to associate : MAIN-VPC02-ATT

  • Choose Subnets to associate : Subnet 선택

• 3장에서 생성한 2개의 TGW Attachment를 선택한 후 Subnet을 지정한다. (TGW-VPC01-ATT, TGW-VPC02-ATT)

그림 4.3 TGW Multicast Domain의 Assoiciate 정보 & 지정된 Subnet 확인

4.2.3) Add group sources

• VPC —> Transit Gateway Multicast —> 작업 —> Add group sources

  • Group IP Address : 239.1.1.1

  • Choose network interfaces : MAIN-MGT 지정

• EC2 인스턴스 MAIN-MGT 지정을 할 때 구분이 힘들다. (설정 전에 MAIN-MGT에 대한 정보를 확인 후 지정하자)

그림 4.4 Group Source 확인

• Groups 탭에 진입하면 대상 별 Source와 Member 확인이 가능하다. (MAIN-MGT를 source 로 지정)

4.2.4) Add group members

• VPC —> Transit Gateway Multicast —> 작업 —> Add group members

  • Group IP Address : 239.1.1.1

  • Choose network interfaces : MAIN-TEST와 MAIN-DEV 지정

• 마찬가지로 대상 구분이 힘들어 미리 확인 후 2개의 대상 지정한다.

그림 4.5 Group Member 확인

• MAIN-TEST와 MAIN-DEV를 member 로 지정

4.3 Verify

• 4.1.2항과 같이 테스트를 해본다.

그림 4.6 Multicast on Transit Gateway 테스트 결과

• MAIN-MGT (Multicast Sender)에서 발생하는 239.1.1.1 Multicast 트래픽은 MAIN-TEST와 MAIN-DEV (Multicast Receiver)로 인입된다.
• 즉, TGW가 Multicast Group을 관리하여 라우팅하여 Source 정보를 Member에게 전달해 준다.
• TGW에서 Multicast 설정을 하면 바로 적용되지 않고 1~2분정도 대기 시간이 필요하다.

💡 현재 Transit Gateway 상에서 동작하는 Multicast는 미완성 서비스이며, 버지니아 리전에만 동작하는 제약이 있다. 향후 다른 리전까지 서비스가 동작하거나 기능이 추가되면, 추가적인 실습을 진행할 예정이다.
그리고, 현재 실습 상 Multicast 동작은 강제로 트래픽을 인입하는 형태의 실습이라 추후 기회가 되면 실제 Multicast Stram을 통해 실습을 진행해 보도록 하겠다.

---

5. AWS Transit Gateway Multi Account VPC Attachment Test

• 이 번 단계의 실습은 TGW을 정보를 다른 계정으로 공유하여 VPC 연결을 테스트한다. (Multi Account VPC Attachment)
• 이 번 단계에서는 서브 AWS 계정이 필요하다. (버지니아 리전에서 테스트하며, CF 배포 전에 Key-Pair를 미리 생성해 두자)
• 동일한 브라우저에서 로그인 시 기존 계정은 로그아웃이 된다. 다른 브라우저 추가하여 실습하면 본 계정과 서브 계정을 같이 사용할 수 있다.
• 실습 환경: Region - 버지니아 , Account - 본 AWS 계정 + 서브 AWS 계정

AWS Transit Gateway 출시 - VPC 네트워크 아키텍처 단순화 가능 (서울 리전 포함) | Amazon Web Services

참고 링크 : Resource Access Manager를 활용하여 Multi Account VPC Attachment

5.1 버지니아 CloufFormation 배포 (서브 계정)

5.1.1) CloudFormation 배포

• 2.3항에서 제공한 Virginia_TransitGW_Lab_CF.yaml 파일을 배포하자.

💡 주의: CF Condition에 의해 Main Site와 Sub Site의 생성 인프라가 다르다. 파라미터 값을 Sub로 지정하자!

그림 5.1 서브 계정에서 버지니아 CF 템플릿 생성 중 EnvType 파라미터 값을 Sub로 지정

• 서브 계정으로 로그인 후 버지니아에서 CloudFormation 템플릿을 실행한다.
• EnvType은 Sub로 지정하자!!

버지니아 CF 생성 인프라 (서브 계정)

- EC2-Instance 2개
- VPC 1개, Private Subnet 2개, Routing Table 2개
- Security Group 1개

• 위 생성된 인프라가 정상적으로 올라왔는 지 확인하자

5.2 Resource Access Manager를 활용하여 TGW 공유 (본 계정 & 서브 계정)

5.2.1) Resource Access Manager 리소스 공유 생성 (본 계정)

그림 5.2 본 계정에서 Resource Access Manager 진입

• Resource Access Manager —> 리소스 공유 생성

  • 이름 : CloudNeta-TGW-Sharing

  • 리소스 유형 선택 : 전송 게이트웨이 —> MAIN SITE에 생성한 TGW 지정

  • 프린시펄 AWS 계정 번호 —> 서브 AWS 계정 번호 입력

그림 5.3 서브 계정에서 내 보안 자격 증명에 진입하여 AWS 계정 ID 확인

그림 5.4 리소스 공유 설정 화면

5.2.2) Resource Access Manager 리소스 공유 수락 (서브 계정)

그림 5.5 서브 계정에서 RAM에 진입하여 리소스 공유 초대 확인

• 본 계정에서 공유한 TGW를 선택 후 리소스 공유 수락

그림 5.6 서브 계정에서 공유 리소스 확인

• 공유 리소스 메뉴로 접근하여 공유된 TGW 정보 확인

5.2.3) Multi Account VPC Attachment (본 계정 / 서브 계정)

• VPC —> Transit Gateway로 진입하면 공유 받은 TGW 정보 확인 (서브 계정)

• VPC —> Transit Gateway Attachment (서브 계정)

  • Transit Gateway ID : 지정

  • Attachment Type : VPC

  • Attachment Name Tag : SUB-VPC03-ATT

  • VPC ID : MAIN-A —> AZ & Subnet 지정

• VPC —> Transit Gateway Attachment —> 작업 —> Accept (본 계정)

그림 5.7 서브 계정에서 TGW Attachment 상태 확인

• 서브 계정에서 TGW VPC Attachment를 수행해도 바로 연결이 되지 않고 pending acceptance 상태이다.
• 본 계정에 진입하여 Accept 해준다. (1~2분 후 성공)

5.3 Routing Table 설정 (서브 계정)

• CloudFormation에 의해 생성된 2개의 라우팅 테이블에 경로를 추가한다.

  • 라우팅 편집 —> 라우팅 추가 —> 10.0.0.0/8 대역, tgw-xxxx 타겟

5.4 Verify

[root@MAIN-MGT ec2-user]# ./pingall.sh
node google.com is up
node 10.1.1.10 is up
node 10.2.1.10 is up
node 10.2.2.10 is up
node 10.3.1.10 is up
node 10.3.2.10 is up
node 10.4.1.10 is down
node 10.5.1.10 is down
node 10.6.1.10 is down
[root@MAIN-MGT ec2-user]#

• MAIN-MGT EC2에 접속하여 pingall.sh 스크립트를 수행한다.
• 버지니아 MAIN과 SUB SITE에 존재하는 EC2 끼리 통신이 가능하다.

5장 현재까지 완료된 구성도 확인

---

6. AWS Transit Gateway Inter Region Peering Test

• 이 번 단계의 실습은 MAIN SITE TGW와 다른 리전에 있는 BRANCH SITE TGW를 연결하여 테스트한다. (Inter Region Peering TGW Attachment)
• 참고로 Inter-Regional-Peering은 버지니아, 오하이오, 오레곤, 아일랜드, 프랑크푸르트 리전 에서만 지원한다.
• 실습 환경: Region - 아일랜드 , Account - 본 AWS 계정

AWS Transit Gateway Adds Multicast and Inter-Regional Peering | Amazon Web Services

참고 링크 : AWS Transit Gateway Adds Multicast & Inter Regional Peering

6.1 아일랜드 CloufFormation 배포

6.1.1) CloudFormation 배포

• 2.3항에서 제공한 Ireland_TransitGW_Lab_CF.yaml 파일을 배포하자.

아일랜드 CF 생성 인프라

- EC2-Instance 2개
- VPC 2개, Public Subnet 1개, Private Subnet 1개, Routing Table 2개, IGW 1개
- Security Group 2개
- Transit Gateway 1개, Transit Gateway Attachment 2개

• 위 생성된 인프라가 정상적으로 올라왔는 지 확인하자
• 아일랜드에서 사용할 인프라를 CloudFormation에서 모두 정의하였다. (TGW까지 포함)
• Routing Table 추가는 정의하지 않아 수동으로 작업 (🤢TGW 생성 및 Attachment 되는 딜레이가 발생하여 경로 설정을 못하고 타임 아웃)

6.2 Inter Region Peering 설정

6.2.1) TGW Attachment - Inter Region Peering

• VPC —> Transit Gateway Attachment —> Create Transit Gateway Attachment (아일랜드)

  • Transit Gateway ID : BRC-TGW 대상 지정

  • Attachment Type : Peering

  • Attachment Name Tag : MAIN-TGW-ATT

  • Region : N. Virginia

  • Transit Gateway (accepter) : MAIN-TGW 대상 지정 (버지니아에 집입하여 TGW ID를 확인 후 직접 입력해야 한다)

그림 6.1 아일랜드 리전에서 Inter Region Peering 설정

그림 6.2 Transit Gateway Attachment Inter Region Peering 은 바로 적용이 되지 않음 (버지니아에서 수락)

• VPC —> Transit Gateway Attachment —> 대상 지정 —> 작업 —> Accept (버지니아)

그림 6.3 Transit Gateway Attachment Inter Region Peering 확인

• Inter Region Peering Attachment 된 것을 확인 할 수 있다. (구분을 위해 BRC-TGW-ATT로 Tag함)

6.3 Routing Table 설정

6.3.1) BRANCH SITE VPC의 Routing Table 설정

• CloudFormation에 의해 생성된 2개의 라우팅 테이블에 경로를 추가한다.

  • 라우팅 편집 —> 라우팅 추가 —> 10.0.0.0/8 대역, tgw-xxxx 타겟

6.3.2) MAIN-TGW의 Routing Table 설정

• VPC —> Transit Gateway Routing Table —> 대상 선택 —> Route 탭 —> Create Route

  • 10.0.0.0/8 대역, BRANCH-TGW 타겟 (tgw-xxxx)

6.3.3) BRANCH-TGW의 Routing Table 설정

• VPC —> Transit Gateway Routing Table —> 대상 선택 —> Route 탭 —> Create Route

  • 10.0.0.0/8 대역, MAIN-TGW 타겟 (tgw-xxxx)

6.4 Verify

[ec2-user@MAIN-MGT ~]$ ./pingall.sh
node google.com is up
node 10.1.1.10 is up
node 10.2.1.10 is up
node 10.2.2.10 is up
node 10.3.1.10 is up
node 10.3.2.10 is up
node 10.4.1.10 is up
node 10.5.1.10 is up
node 10.6.1.10 is down
[ec2-user@MAIN-MGT ~]$

• MAIN-MGT EC2에 접속하여 pingall.sh 스크립트를 수행한다.
• 버지니아 MAIN / SUB / BRANCH SITE에 존재하는 EC2 끼리 통신이 가능하다.

6장 현재까지 완료된 구성도 확인

---

7. AWS Transit Gateway VPN Attachment

• 이 번 단계의 실습은 MAIN SITE TGW와 다른 리전에 있는 Site-to-Site VPN을 연결하는 테스트를 한다. (AWS Transit Gateway VPN Attachment)
• 서울 리전에 VPC를 생성하여 VPN 서버를 배치하는데, 가상으로 On-Premise 환경이라 가정하여 테스트 한다.
• 실습 환경: Region - 버지니아, 서울 , Account - 본 AWS 계정

7.1 서울 CloufFormation 배포

7.1.1) CloudFormation 배포

• 2.3항에서 제공한 Seoul_TransitGW_Lab_CF.yaml 파일을 배포하자.

• 서울 CF 생성 인프라

  • EC2-Instance 1개

  • VPC 1개, Public Subnet 1개, Routing Table 1개, IGW 1개

  • Security Group 1개

• 위 생성된 인프라가 정상적으로 올라왔는 지 확인하자.

7.2 AWS Site to Site VPN 설정

7.2.1) Custom Gateway 생성

• VPC —> VPN —> 고객 게이트웨이 —> 고객 게이트웨이 생성 (버지니아)

  • 이름 : CloudNeta-CGW

  • 라우팅 : 정적

  • IP 주소 : 서울에 위치한 EC2 Public IP 주소

7.2.2) TGW VPN Attachment

• VPC —> Transit Gateway Attachment —> 사이트 간 VPN 연결 —> VPN 연결 생성 (버지니아)

  • Transit Gateway ID : MAIN-TGW 선택

  • Attachment Type : VPN

  ---

  • 고객 게이트웨이 : Existing

  • Customer Gateway ID : 생성한 CGW 선택

  ---

  • 라우팅 옵션 : 정적

7.2.3) VPN 구성 다운로드

• VPC —> VPN —> 사이트 간 VPN에 접근한다
• 일정 시간이 지나면 Site to Site VPN 연결 상태는 사용 가능 상태로 전환된다.
• AWS에서는 연결 할 상대방 VPN 서버에 대한 구성 정보를 친절히 제공하고 있다.
• 구성 다운로드 —> 공급업체 : Openswan 선택

7.3 OpenSwan VPN 서버 설정

• 서울에 생성한 EC2-Instance에 SSH 접속을 한다.

7.3.1) aws-vpn.conf 생성 및 입력

[ec2-user@OPM-VPN ~]$ sudo su
[root@OPM-VPN ec2-user]#
[root@OPM-VPN ec2-user]# vi /etc/ipsec.d/aws-vpn.conf

• vi 편집기 모드로 /etc/ipsec.d/aws-vpn.conf 파일을 생성하여 접근한다.

vi /etc/ipsec.d/aws-vpn.conf
--------------------------------------------------------------------------
conn Tunnel1
	authby=secret
	auto=start
	left=%defaultroute
	leftid=54.180.131.143
	right=34.231.125.200
	type=tunnel
	ikelifetime=8h
	keylife=1h
	phase2alg=aes128-sha1;modp1024
	ike=aes128-sha1;modp1024
	~~auth=esp~~ 삭제
	keyingtries=%forever
	keyexchange=ike
	leftsubnet=<LOCAL NETWORK> 10.6.0.0/16 으로 입력
	rightsubnet=<REMOTE NETWORK> 10.0.0.0/8 으로 입력
	dpddelay=10
	dpdtimeout=30
	dpdaction=restart_by_peer

• 해당 코드 정보는 7.2.3항에서 다운 받은 TXT 파일에서 4항의 내용을 사용한다. (☢ 위 코드 값을 넣으라는 것이 아니라 각자 다운받은 TXT 파일을 참조해서 설정)

• 코드 내용 중 수정이 필요한 사항

  • LOCAL NETWORK는 VPC-OPM의 대역으로 10.6.0.0/16 입력한다.

  • REMOTE NETWORK는 AWS 대역으로 10.0.0.0/8 입력한다.

  • auto=esp 삭제

  • 나머지는 있는 그대로 사용

7.3.2) aws-vpn.secrets 생성

[root@OPM-VPN ec2-user]# vi /etc/ipsec.d/aws-vpn.secrets

• vi 편집기 모드로 /etc/ipsec.d/aws-vpn.secrets 파일을 생성하여 접근한다.

vi /etc/ipsec.d/aws-vpn.conf
--------------------------------------------------------------------------
54.180.131.143 34.231.125.200: PSK "DWJ2n0smRq6gDlMUuIweGa45m8c_RvZ3"

• 해당 코드 정보는 7.2.3항에서 다운 받은 TXT 파일에서 5항의 내용을 사용한다. (☢ 위 코드 값을 넣으라는 것이 아니라 각자 다운받은 TXT 파일을 참조해서 설정)

7.3.3) OpenSwan VPN 서버 시작

[root@OPM-VPN ec2-user]# chkconfig ipsec on
:
[root@OPM-VPN ec2-user]# service ipsec start
:
[root@OPM-VPN ec2-user]# service ipsec status
Redirecting to /bin/systemctl status ipsec.service
● ipsec.service - Internet Key Exchange (IKE) Protocol Daemon for IPsec
   Loaded: loaded (/usr/lib/systemd/system/ipsec.service; enabled; vendor preset: disabled)
   Active: active (running) since Fri 2020-05-08 07:49:18 UTC; 10s ago
     Docs: man:ipsec(8)
           man:pluto(8)
           man:ipsec.conf(5)
  Process: 4718 ExecStopPost=/usr/sbin/ipsec --stopnflog (code=exited, status=0/SUCCESS)
:

• OpenSwan의 상태가 Active 임을 확인 한다.

• 버지니아 Site to Site VPN 상태를 보면 Tunnel 1이 작동 상태로 올라왔다.

7.4 TGW 라우팅 테이블 설정

• Transit Gateway 라우팅 테이블에서 On-Premise 대역에 대한 라우팅을 잡아야 한다.

• VPC —> Transit Gateway 라우팅 테이블 —> TGW 대상 지정 —> Route 탭 —> Create Route

  • CIDR : 10.6.0.0/16

  • Choose Attachment : 위에 생성한 VPN Attachment 지정

    

7.5 Verify

[root@MAIN-MGT ec2-user]# ./pingall.sh
node google.com is up
node 10.1.1.10 is up
node 10.2.1.10 is up
node 10.2.2.10 is up
node 10.3.1.10 is up
node 10.3.2.10 is up
node 10.4.1.10 is up
node 10.5.1.10 is up
node 10.6.1.10 is up
[root@MAIN-MGT ec2-user]#

• MAIN-MGT EC2에 접속하여 pingall.sh 스크립트를 수행한다.
• 드디어 모든 구간으로 통신이 가능하다.

7장 현재까지 완료된 구성도 확인

---

8. NAT Gateway through AWS Transit Gateway

• 이 번 단계의 실습은 Private Subnet에 존재하는 인스턴스를 TGW를 통해 MAIN SITE의 Egress VPC에 존재하는 NAT GW를 통해 외부 인터넷 통신을 테스트한다.
• 본 실습에서 Private Subnet은 크게 TEST 환경과 DEV 환경으로 구분할 수 있다. 이 중에 DEV 환경만 NAT GW를 통해 외부 인터넷 통신을하고, TEST 환경은 폐쇄망 성격으로 외부 인터넷 통신을 하지 않도록 하는 컨셉이다.
• 실습 환경: Region - 버지니아 , Account - 본 AWS 계정 + 서브 AWS 계정

8.1 버지니아 CloufFormation 배포

8.1.1) CloudFormation 배포

• 2.3항에서 제공한 Virginia_TransitGW_Lab_CF.yaml 파일을 배포하자.

💡 주의: CF Condition에 의해 파라미터 값을 Nat로 지정하자!

그림 8.1 NAT 용도의 CloudFormation 생성 (EnvType을 Nat로 지정)

버지니아 CF 생성 인프라 (NAT)

- NAT Gateway 1개

- VPC 1개, Public Subnet 1개, Private Subnet 1개, Routing Table 2개, IGW 1개

• 위 생성된 인프라가 정상적으로 올라왔는 지 확인하자.

8.2 TGW Attachment

• VPC —> Transit Gateway Attachment —> Create Transit Gateway Attachment

  • Transit Gateway ID 지정

  • Attachment Type : VPC

  • Attachment Name Tag : MAIN-VPCEG-ATT

  • VPC ID : VPC01 —> AZ & Subnet 지정

8.3 Routing Table 설정

8.3.1) DEV 환경의 라우팅 설정

• DEV 환경은 MAIN-DEV와 SUB-DEV 2군데만 설정 이다.

• VPC —> 라우팅 테이블 —> 대상 지정 (본 계정, 서브계정 모두 설정)

  • 라우팅 편집 —> 라우팅 추가 —> 0.0.0.0/0 대역, TGW 타겟(tgw-xxxx)

8.3.2) TGW의 라우팅설정

• VPC —> Transit Gateway 라우팅 테이블 —> 대상 지정 —> Route 탭 —> Create Route

  • 0.0.0.0/0 대역, MAIN-VPCEG-ATT 대상 지정

8.3.3) VPCEG의 Private와 Public 라우팅 설정 (2 군데 설정)

• VPC —> 라우팅 테이블 —> 대상 지정

  • 라우팅 편집 —> 라우팅 추가 —> 10.0.0.0/8 대역, TGW 타겟(tgw-xxxx)

8.3 Verify

• MAIN-TEST, MAIN-DEV, SUB-TEST, SUB-DEV에 SSH로 접근하여 pingall.sh 수행 (root계정 암호: qwe123)

8.3.1) MAIN-TEST 테스트

• View Result

  [root@MAIN-TEST ~]# ./pingall.sh
  node google.com is down
  node 10.1.1.10 is up
  node 10.2.1.10 is up
  node 10.2.2.10 is up
  node 10.3.1.10 is up
  node 10.3.2.10 is up
  node 10.4.1.10 is up
  node 10.5.1.10 is up
  node 10.6.1.10 is up
  [root@MAIN-TEST ~]#

  • 내부 인프라와는통신되지만 외부 인터넷 통신은 불가하다.

8.3.2) MAIN-DEV 테스트

• View Result

  [root@MAIN-DEV ~]# ./pingall.sh
  node google.com is up
  node 10.1.1.10 is up
  node 10.2.1.10 is up
  node 10.2.2.10 is up
  node 10.3.1.10 is up
  node 10.3.2.10 is up
  node 10.4.1.10 is up
  node 10.5.1.10 is up
  node 10.6.1.10 is up
  [root@MAIN-DEV ~]#

  • 모든 영역으로 통신이 가능하다.

8.3.3) SUB-TEST 테스트

• View Result

  [root@SUB-TEST ~]# ./pingall.sh
  node google.com is down
  node 10.1.1.10 is up
  node 10.2.1.10 is up
  node 10.2.2.10 is up
  node 10.3.1.10 is up
  node 10.3.2.10 is up
  node 10.4.1.10 is up
  node 10.5.1.10 is up
  node 10.6.1.10 is up
  [root@SUB-TEST ~]#

  • 내부 인프라와는통신되지만 외부 인터넷 통신은 불가하다.

8.3.4) SUB-DEV 테스트

• View Result

  [root@SUB-DEV ~]# ./pingall.sh
  node google.com is up
  node 10.1.1.10 is up
  node 10.2.1.10 is up
  node 10.2.2.10 is up
  node 10.3.1.10 is up
  node 10.3.2.10 is up
  node 10.4.1.10 is up
  node 10.5.1.10 is up
  node 10.6.1.10 is up
  [root@SUB-DEV ~]#

  • 모든 영역으로 통신이 가능하다.

8장 현재까지 완료된 구성도 확인

---

9. AWS Transit Gateway Network Manager

• 이 번 단계의 실습은 TGW Network Manager 기능을 통해 가시성 있게 Global Network를 모니터링한다.

9.1 Create Global Network

• VPC —> Transit Gateway —> 네트워크 관리자 —> Create a Global Network

  • 이름 : CloudNeta-GN

9.2 Transit Gateway 등록

• 네트워크 관리자 데시보드에서 전송 게이트웨이 추가한다.

  • CloudNeta-MAIN-TGW

  • BRC-TGW

그림 9.1 TGW Global Network 네트워크 관리자에서 Transit Gateway 등록

9.3 Verify

9.3.1) 지리적 정보

그림 9.2 TGW의 지리적 위치 표현

9.3.2) 토폴로지

그림 9.3 Global Network 연결 토폴로지 확인

9.3.4) 모니터링

그림 9.4 Global Network 모니터링 정보

9.3.5) Route Analyzer

그림 9.5 경로 분석기 (Route Analyzer) 정보 입력

그림 9.6 경로 분석기 결과 확인

AWS Transit Gateway 네트워크 관리자 Route Analyzer 발표

참고 링크 : AWS TGW 네트워크 관리 Route Analyzer 발표

---

10. Delete Resources

01) TGW 네트워크 매니저 전송 게이트웨이 등록 취소

02) 글로벌 네트워크 삭제

03) 서울 CloudFormation 스택 삭제

04) 아이랜드 TGW Attachment에서 TGW Peering 대상 삭제

05) 아일랜드 CloudFormation 스택 삭제

06) 서브 계정 Resource Access Manager에서 리소스 공유 나가기

07) 메인 계정 Resource Access Manager에서 리소스 삭제

08) 서브 계정 TGW Attachment에서 VPC Attachment 대상 삭제

09) 서브 계정 버지니아 CloudFormation 스택 삭제

10) 버지니아 사이트 간 VPN 연결 삭제 후 고객 게이트웨이 삭제

11) 버지니아 TGW Multicast Domain 삭제 (우선 Delete Association 후 삭제)

12) 버지니아 TGW Attachment 대상 모두 삭제

13) 버지니아 Trasit Gateway 삭제

14) 버지니아 NAT CloudFormation 스택 삭제

15) 버지니아 MAIN CloudFormation 스택 삭제

🔔 CloudFormation 스택을 삭제 시 일정 시간이 소요되는데, 너무 시간이 오래 걸린다면 수동으로 관련 인프라를 삭제해야 한다.
반드시, 실습을 위해 생성한 리소스는 삭제한다.