AWS Transit Gateway 관련 참고 링크
AWS 서비스 관련해서는 항상 최우선으로 'AWS 설명서' 를 읽어보는 것을 추천합니다.
한글 번역이 매끄럽지 못하면 언어를 영어로 변경 후 읽어보기 바랍니다.
1. AWS Transit Gateway 개요
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 등에 액세스할 수 있습니다.
◦
보안 그룹 참조 기능이 추가되어 VPC 간 트래픽 관리가 더욱 용이해졌습니다.
•
모니터링
◦
Amazon CloudWatch 및 Amazon VPC 흐름 로그와 같은 서비스에서 사용하는 통계와 로그를 제공합니다.
◦
가용 영역(AZ)별 지표도 지원하여 더 세밀한 모니터링이 가능합니다.
•
리전 간 VPC 피어링
◦
AWS Transit Gateway 리전 간 VPC 피어링은 AWS 글로벌 네트워크를 사용하여 AWS 리전을 통해 트래픽을 라우팅할 수 있도록 지원합니다.
•
멀티캐스트
◦
고객이 클라우드에서 멀티캐스트 애플리케이션을 쉽게 구축하고 수백 개의 수신자까지 멀티캐스트 구성을 쉽게 모니터링, 관리 및 확장할 수 있도록 지원합니다.
•
보안
◦
AWS IAM과 통합되어 AWS Transit Gateway에 대한 액세스를 안전하게 관리할 수 있습니다.
•
지표
◦
성능과 송수신된 바이트, 패킷, 폐기된 패킷을 비롯한 트래픽 지표를 통해 글로벌 네트워크를 모니터링합니다.
◦
Path MTU Discovery(PMTUD) 지원으로 MTU 불일치 문제를 완화할 수 있습니다.
1.3. Non Transit Gateway vs Transit Gateway
[Caption] Transit Gateway 미사용 / 사용 비교
•
AWS Transit Gateway 미사용
◦
다수의 VPC 환경이나 On-Premise 환경에 대해 Transit Gateway를 사용하지 않고, VPC Peering과 VPN, Direct Connect를 통한 개별 연결이 이루어져 복잡한 작업 환경
•
AWS Transit Gateway 사용
◦
Transit Gateway를 중심으로 연결만 하면 되어, 중앙 집중형 간략한 작업 환경
Transit Gateway를 사용하면 복잡한 AWS 네트워크 아키텍처를 간소화 가능하여 관리 및 운용 효율이 보장되며, 향상된 보안과 멀티캐스트를 활용하여 유용한 통신이 가능합니다.
1.4. AWS Transit Gateway 키워드
•
Transit Gateway
◦
VPC들의 접점이 되는 중앙 집중형 단일 Gateway로 Hub & Spoke 환경에서 Hub 역할
•
Transit Gateway Attachment
◦
VPC를 연결하는 방식 (현재 버전으로 4가지 방식 지원)
▪
VPC Attachment : TGW와 동일 Region 내 VPC를 직접적으로 연결 (다른 계정에 생성한 VPC도 연결 가능)
▪
VPN Attachment : TGW와 VPN를 연결 (Site to Site VPN)
▪
TGW Peering : TGW와 다른 Region의 TGW 간 연결 (Inter Region TGW Peering)
▪
TGW Connect: SD-WAN 어플라이언스와의 통합을 지원하며, 동적 라우팅과 향상된 대역폭을 제공
•
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
◦
논리적 다이어그램 또는 지리적 맵으로 중앙 대시 보드에서 글로벌 네트워크를 시각화
•
Security Group Referencing
◦
TGW와 연결된 VPC 간에 보안 그룹을 참조할 수 있는 기능이 2024년 9월에 추가
▪
보안 그룹 관리가 간소화되고, 네트워크 보안 태세가 강화
•
Path MTU Discovery (PMTUD)
◦
MTU 불일치 문제를 완화하기 위해 PMTUD를 지원
•
AZ별 CloudWatch 지표
◦
가용 영역(AZ)별로 트래픽 및 성능 지표를 제공하여 장애 해결 속도를 높이고 트래픽 패턴을 더 심층적으로 분석
•
Bandwidth Limits
◦
대역폭 제한 기능을 도입하여 네트워크 성능을 더 세밀하게 제어(2023년 기준)
2. AWS Transit Gateway 실습 준비
2.1. 실습 구성도
[Caption] AWS Transit Gateway 실습 구성도
① TGW Intra Region VPC Attach
•
버지니아 북부에 MAIN SITE 구축 (동일 리전 내 VPC와 TGW를 생성하여 연결)
② Multicast on TGW
•
버지니아 북부 MAIN SITE에서 Multicast 통신 테스트
③ TGW Multi Account VPC Attach
•
다른 계정의 버지니아 북부에 SUB SITE 구축 후 Resource Access Manager를 통해 TGW를 공유하고 다른 계정의 VPC와 연결
④ TGW Inter Region Peering
•
아일랜드 에 BRANCH SITE 구축 후 TGW 간 피어링 연결
⑤ TGW VPN Attach
•
서울에 OpenSwan VPN 서버를 설치 후 TGW와 연결
⑥ NATGW though TGW
•
Private Subnet 중 DEV 환경의 대상으로, TGW를 통해 버지니아 북부 MAIN SITE의 Egress VPC에 존재하는 NAT GW로 인터넷 통신
2.2. AWS 기본 설정
•
실습에서 활용할 AWS 리전은 버지니아 북부, 아일랜드, 서울 입니다.
◦
해당 리전에 대한 EC2-Key Pair를 생성 필요
•
TGW Multi Account VPC Attachment 테스트를 위해 본 계정 외에 서브 계정이 필요합니다.
•
모든 리전에 대한 기본적인 인프라는 CloudFormation에 의해 자동 구축합니다.
◦
모든 인프라가 구축되는 것은 아닙니다.
•
생성된 모든 EC2 인스턴스의 IP 주소는 X.X.X.10으로 고정하였습니다.
◦
예시: 10.1.1.10, 10.5.1.10 ...
2.3. CloudFormation Code
Virginia_TransitGW_Lab_CF.yaml
Ireland_TransitGW_Lab_CF.yaml
Seoul_TransitGW_Lab_CF.yaml
•
버지니아 북부, 아일랜드, 서울에 배포할 Cloud Formation 템플릿 파일입니다.
지금 바로 배포하지 않고, 실습 단계 별로 하나씩 배포할 것이니 일단 파일로 저장해 둡니다.
3. AWS Transit Gateway Intra Region VPC Attachment 테스트
•
이 번 단계의 실습은 동일 리전에 존재하는 VPC와 TGW 간의 연결을 테스트합니다.
•
실습 환경: Region - 버지니아 북부 , Account - AWS 본 계정
3.1. 버지니아 북부 CloudFormation 배포
•
앞서 정의한 Virginia_TransitGW_Lab_CF.yaml 파일을 배포합니다.
CloudFormation Condition에 의해 EnvType에 따라 생성되는 인프라가 다릅니다.
이번에는 파라미터 값을 Main으로 지정합니다.
[Caption] 버지니아 북부 CF 템플릿 생성
버지니아 북부 CF 생성 인프라
3.2. MAIN-MGT EC2 인스턴스 접속
•
현재 접속 가능한 퍼블릭 서브넷에 위치한 MAIN-MGT에 SSH 접속 후 작업합니다.
ping 테스트
cat <<EOF > 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
EOF
Bash
복사
# list.txt 파일 생성
cat <<EOF > 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
EOF
Bash
복사
# pingall.sh 스크립트 파일 생성
chmod +x pingall.sh
Bash
복사
# 스크립트 파일 권한 부여
•
pingall.sh 스크립트를 생성하고 권한을 부여합니다.
./pingall.sh
Bash
복사
# 스크립트 파일 실행
=========================================
OUTPUT:
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
:END
Bash
복사
•
./pingall.sh 로 전체 대상에 대한 Ping 테스트가 가능합니다.
•
현재 자기 자신과 외부 인터넷만 통신이 가능합니다.
3.3. Transit Gateway 생성
•
VPC → Transit Gateway → Transit Gateway 생성
[Caption] Transit Gateway 생성
•
이름 태그를 기입하고, 멀티캐스트 지원도 체크합니다.
•
1~2분 정도 대기하면, 상태가 available 로 변경 됩니다.
3.4. Transit Gateway Attachment 생성
•
VPC → Transit Gateway 연결 → Transit Gateway Attachment 생성
필드 | 설정 |
이름 태그 | MAIN-VPC01-ATT |
Transit gateway ID | MAIN-TGW 지정 |
연결 유형 | VPC |
VPC ID | MAIN-A |
필드 | 설정 |
이름 태그 | MAIN-VPC02-ATT |
Transit gateway ID | MAIN-TGW 지정 |
연결 유형 | VPC |
VPC ID | MAIN-B |
TGW 기준으로 Intra Region VPC 연결 작업으로 MAIN-A와 MAIN-B를 연결합니다.
[Caption] TGW Attachment 확인
3.5. Routing Table 수정
•
CloudFormation에 의해 생성된 3개의 라우팅 테이블에 경로를 추가합니다.
◦
라우팅 편집 → 라우팅 추가 → 10.0.0.0/8, MAIN-VPC01-ATT or MAIN-VPC02-ATT
[Caption] 라우팅 테이블 편집
3.6. 통신 검증
./pingall.sh
Bash
복사
# 스크립트 파일 실행
=========================================
OUTPUT:
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
:END
Bash
복사
•
./pingall.sh 스크립트를 수행하면 버지니아 MAIN 영역에 존재하는 인스턴스 간 통신이 가능합니다.
[Caption] 현재까지 완료된 구성도 확인
4. Multicast on Transit Gateway 테스트
•
이 번 단계의 실습은 TGW을 통해 Multicast 통신을 테스트합니다.
◦
MAIN-MGT 인스턴스: Multicast Sender
◦
MAIN-TEST 인스턴스: Multicast Receiver
◦
MAIN-DEV 인스턴스: Multicast Receiver
•
Multicast 트래픽의 UDP 포트 번호에 대해 Security Group에서 허용해야 합니다. (CloudFormation에서 미리 설정)
•
실습 환경: Region - 버지니아 북부 , Account - AWS 본 계정
4.1. Multicast 라우팅 설정 전 테스트
MAIN-MGT 인스턴스에 접속 (Sender)
omping -m 239.1.1.1 -p 10000 10.1.1.10
Bash
복사
# Multicast 트래픽 발생
=========================================
OUTPUT:
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.013ms
10.1.1.10 : multicast, seq=1, size=69 bytes, dist=0, time=0.018ms
10.1.1.10 : unicast, seq=2, size=69 bytes, dist=0, time=0.050ms
10.1.1.10 : multicast, seq=2, size=69 bytes, dist=0, time=0.057ms
...
:END
Bash
복사
•
Multicast IP: 239.1.1.1 , Port: UDP 10000
MAIN-TEST, MAIN-DEV 인스턴스에 접속 (Receiver)
•
MAIN-TEST, MAIN-DEV은 프라이빗 서브넷에 위치하여 다이렉트로 SSH 접근이 불가합니다.
•
MAIN-MGT에 접근 후 ssh root@10.2.1.10과 ssh root@10.2.2.10 명령어로 접근합니다.
•
SSH 키페어 없이 root 계정으로 접근하며, 암호는 qwe123 으로 설정했습니다.
ssh root@10.2.1.10
Bash
복사
# MAIN-TEST 접속
tcpdump ip dst 239.1.1.1 -nn
Bash
복사
# 239.1.1.1 트래픽 캡쳐
=========================================
OUTPUT:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
:END
Bash
복사
•
MAIN-DEV도 마찬가지로 접속하여 tcpdump 명령을 수행합니다.
[Caption] Multicast 라우팅 전 테스트
•
좌측 Multicast Sender에서 239.1.1.1 트래픽을 발생하지만, 우측 Multicast Receiver들로 인입되지 않습니다.
4.2. Transit Gateway Multicast 설정
Transit Gateway 멀티캐스트 도메인 생성
•
VPC → Transit Gateway 멀티캐스트 → Transit Gateway 멀티캐스트 도메인 생성
필드 | 설정 |
이름 태그 | TGW-MCAST-DOMAIN |
Transit gateway ID | MAIN-TGW 지정 |
Multicast 테스트는 IGMP Group을 통한 환경이라면 IGMPv2 지원을 체크한 후 구성할 수 있습니다.
[Caption] Transit Gateway 멀티캐스트 도메인 생성
Transit Gateway 멀티캐스트 도메인 - 연결 생성
•
Transit Gateway 멀티캐스트 도메인 선택 → 작업 → 연결 생성
필드 | 설정 |
연결할 연결 선택 | MAIN-VPC01-ATT |
연결한 서브넷 선택 | 선택 |
필드 | 설정 |
연결할 연결 선택 | MAIN-VPC02-ATT |
연결한 서브넷 선택 | 선택 |
[Caption] Transit Gateway 멀티캐스트 도메인 연결 대상 확인
Transit Gateway 멀티캐스트 도메인 - 그룹 멤버 추가
•
Transit Gateway 멀티캐스트 도메인 선택 → 작업 → 그룹 멤버 추가
필드 | 설정 |
그룹 IP 주소 | 239.1.1.1 |
사용 가능한 네트워크 인터페이스 | 대상 지정 |
대상은 MAIN-TEST와 MAIN-DEV의 ENI를 지정하는데 구분이 힘들어 VPC ID를 보고 동일한 대상 2개를 지정합니다.
[Caption] Transit Gateway 멀티캐스트 도메인 그룹 멤버 확인
4.3. Multicast 라우팅 설정 후 테스트
[Caption] Multicast 라우팅 후 테스트
•
Multicast Sender(MAIN-MGT)에서 발생하는 239.1.1.1 멀티캐스트 트래픽은 Multicast Receiver(MAIN-TEST, MAIN-DEV)로 인입됩니다.
[Caption] 현재까지 완료된 구성도 확인
5. AWS Transit Gateway Multi Account VPC Attachment 테스트
•
이 번 단계의 실습은 TGW을 정보를 다른 계정으로 공유하여 VPC 연결을 테스트합니다.
◦
서브 AWS Account가 필요합니다.
◦
버지니아 북부 리전에서 테스트합니다.
◦
CloudFormation 배포 전에 SSH 키페어를 미리 생성합니다.
•
실습 환경: Region - 버지니아 북부 , Account - AWS 본 계정 + AWS 서브 계정
동일한 브라우저에서 로그인하면 기존 계정은 로그아웃이 됩니다.
다른 브라우저 추가하여 실습하면 본 계정과 서브 계정을 같이 사용할 수 있습니다.
5.1. 버지니아 북부 CloudFormation 배포 (서브 계정)
CloudFormation 배포
•
앞서 정의한 Virginia_TransitGW_Lab_CF.yaml 파일을 배포합니다.
해당 작업은 AWS 서브 계정에서 진행하며, EnvType은 Sub로 지정합니다.
[Caption] 버지니아 북부 CF 템플릿 생성 (서브 계정)
버지니아 북부 CF 생성 인프라 (서브 계정)
5.2. RAM(Resource Access Manager)를 통한 TGW 공유
본 계정 - Resource Access Manager 리소스 공유 생성
•
Resource Access Manager → 내가 공유: 리소스 공유 → 리소스 공유 생성
필드 | 설정 |
Name | TGW-Sharing |
리소스 | 전송 게이트웨이 |
ID | MAIN-TGW 선택 |
보안 주체 유형 선택 | AWS 계정 |
AWS 계정 ID 입력 | 서브 계정의 Account ID |
# 내가 공유: 리소스 공유 대상 확인
서브 계정 - Resource Access Manager 리소스 공유 수락
•
Resource Access Manager → 나와 공유: 리소스 공유 → 리소스 공유 대상 클릭 → 리소스 공유 수락
# 나와 공유: 리소스 공유 대상 확인
# 나와 공유: 리소스 공유 수락
•
Resource Access Manager → 나와 공유: 공유 리소스
# 나와 공유: 공유 리소스 확인
서브 계정 - Multi Account VPC Attachment
서브 계정에 Transit Gateway에 진입하면 공유받은 TGW를 확인할 수 있습니다.
•
VPC → Transit Gateway 연결 → Transit Gateway Attachment 생성
필드 | 설정 |
이름 태그 | SUB-VPC03-ATT |
Transit gateway ID | 공유 받은 TGW 지정 |
연결 유형 | VPC |
VPC ID | SUB-A |
TGW 기준으로 Multi Account VPC 연결 작업으로 SUB-A를 연결합니다.
[Caption] TGW Attachment 확인
•
서브 계정에서 TGW VPC Attachment를 수행해도 바로 연결이 되지 않고 pending acceptance 상태입니다. (본 계정에서 Accept 필요)
본 계정 - Multi Account VPC Attachment
•
VPC → Transit Gateway 연결 → 대상 선택 → Transit Gateway Attachment 수락
# Transit Gateway Attachment 수락
Pending 상태에서 1~2분 후에 Available 상태로 전환됩니다.
5.3. 서브 계정 - Routing Table 수정
•
CloudFormation에 의해 생성된 2개의 라우팅 테이블에 경로를 추가합니다.
◦
라우팅 편집 → 라우팅 추가 → 10.0.0.0/8, SUB-VPC03-ATT
5.4. 통신 검증
./pingall.sh
Bash
복사
# 스크립트 파일 실행
=========================================
OUTPUT:
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
:END
Bash
복사
•
./pingall.sh 스크립트를 수행하면 버지니아 MAIN과 SUB 영역에 존재하는 인스턴스 간 통신이 가능합니다.
[Caption] 현재까지 완료된 구성도 확인
6. AWS Transit Gateway Inter Region Peering 테스트
•
이 번 단계의 실습은 MAIN SITE의 TGW와 다른 리전에 있는 BRANCH SITE의 TGW를 연결하여 테스트합니다.
•
실습 환경: Region - 아일랜드 , Account - AWS 본 계정
6.1. 아일랜드 리전에 CloudFormation 배포
CloudFormation 배포
•
앞서 정의한 Ireland_TransitGW_Lab_CF.yaml 파일을 배포합니다.
아일랜드 CF 생성 인프라
BRANCH SITE에 구성할 Transit Gateway와 내부 Transit Gateway Attachment는 CloudFormation으로 구성했습니다.
6.2. Inter Region Peering 설정
아일랜드 리전 - TGW Attachment - Inter Region Peering
•
VPC → Transit Gateway 연결 → Transit Gateway Attachment 생성
필드 | 설정 |
이름 태그 | MAIN-TGW-ATT |
Transit gateway ID | BRC-TGW 지정 |
연결 유형 | Peering Connection |
계정 | 내 계정 |
리전 | 미국 동부 (버지니아 북부) (us-east-1) 선택 |
Transit Gateway(수락자) | MAIN-TGW ID 입력 |
# 리전 간 TGW Peering을 위한 설정
# Transit Gateway 연결 대상 확인
리전 간 TGW Peering은 요청에 대한 수락 작업이 필요합니다.
버지니아 북부 리전에 방문 후 요청을 수락합니다.
버지니아 북부 리전 - TGW Attachment - Inter Region Peering
•
VPC → Transit Gateway 연결 → 대상 선택 → Transit Gateway Attachment 수락
# Inter Region TGW Peering 요청 수락
6.3. 아일랜드 리전 - Routing Table 수정
•
CloudFormation에 의해 생성된 2개의 라우팅 테이블에 경로를 추가합니다.
◦
라우팅 편집 → 라우팅 추가 → 10.0.0.0/8, TGW 대상 선택
6.4. Transit Gateway 라우팅 테이블 수정
버지니아 북부 리전 - MAIN-TGW의 라우팅 테이블 수정
•
VPC → Transit Gateway 라우팅 테이블 → 대상 선택 → 경로 탭 → 정적 경로 생성
필드 | 설정 |
CIDR | 10.0.0.0/8 |
유형 | 활성 |
연결 선택 | BRC-TGW 선택(peering) |
# TGW Peering 대상에 대한 정적 경로 생성
아일랜드 리전 - BRC-TGW의 라우팅 테이블 수정
•
VPC → Transit Gateway 라우팅 테이블 → 대상 선택 → 경로 탭 → 정적 경로 생성
필드 | 설정 |
CIDR | 10.0.0.0/8 |
유형 | 활성 |
연결 선택 | MAIN-TGW 선택(peering) |
# TGW Peering 대상에 대한 정적 경로 생성
6.5. 통신 검증
./pingall.sh
Bash
복사
# 스크립트 파일 실행
=========================================
OUTPUT:
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
:END
Bash
복사
•
./pingall.sh 스크립트를 수행하면 버지니아 MAIN과 SUB와 BRANCH 영역에 존재하는 인스턴스 간 통신이 가능합니다.
[Caption] 현재까지 완료된 구성도 확인
7. AWS Transit Gateway VPN Attachment
•
이 번 단계의 실습은 MAIN-TGW와 다른 리전에 있는 Site-to-Site VPN을 연결하는 테스트를 합니다.
•
서울 리전에 CloudFormation으로 인프라를 생성하고 VPN 서버를 구성해서 테스트합니다.
•
실습 환경: Region - 버지니아 북부, 서울 , Account - AWS 본 계정
7.1. 서울 리전에 CloudFormation 배포
CloudFormation 배포
•
앞서 정의한 Seoul_TransitGW_Lab_CF.yaml 파일을 배포합니다.
서울 CF 생성 인프라
7.2. AWS Site to Site VPN 설정
Transit Gateway 연결 생성
•
VPC → Transit Gateway 연결 → Transit Gateway Attachment 생성
필드 | 설정 |
이름 태그 | OPM-VPC06-ATT |
Transit Gateway ID | MAIN-TGW 선택 |
연결 유형 | VPN |
고객 게이트웨이 | 신규 |
IP 주소 | 서울 리전 EC2 인스턴스 IP |
라우팅 옵션 | 정적 |
# Transit Gateway 연결 중 VPN 대상 확인
Pending 상태에서 3~4분 후에 Available 상태로 전환됩니다.
Site-to-Site VPN 연결 확인
•
VPC → VPN → Site-to-Site VPN 연결 → 대상 선택 → 구성 다운로드
필드 | 설정 |
공급업체 | Openswan |
플랫폼 | Openswan |
소프트웨어 | Openswan 2.6.38+ |
IKE 버전 | Ikev1 |
[Caption] Site-To-Site VPN 연결 확인 및 Openswan 구성 다운로드
OpenSwan 구성 파일
7.3. OpenSwan VPN 서버 설정
•
서울리전에 생성한 EC2 인스턴스(OPM-MGT)에 SSH 접속해서 진행합니다.
aws-vpn.conf 생성 및 입력
sudo su -
Bash
복사
# 슈퍼 유저로 변경
cat <<EOF > /etc/ipsec.d/aws.conf
conn Tunnel1
authby=secret
auto=start
left=%defaultroute
leftid=13.209.80.36
right=23.21.226.238
type=tunnel
ikelifetime=8h
keylife=1h
phase2alg=aes128-sha1;modp1024
ike=aes128-sha1;modp1024
keyingtries=%forever
keyexchange=ike
leftsubnet=10.6.0.0/16
rightsubnet=10.0.0.0/8
dpddelay=10
dpdtimeout=30
dpdaction=restart_by_peer
conn Tunnel2
authby=secret
auto=start
left=%defaultroute
leftid=13.209.80.36
right=44.215.166.83
type=tunnel
ikelifetime=8h
keylife=1h
phase2alg=aes128-sha1;modp1024
ike=aes128-sha1;modp1024
keyingtries=%forever
keyexchange=ike
leftsubnet=10.6.0.0/16
rightsubnet=10.0.0.0/8
dpddelay=10
dpdtimeout=30
dpdaction=restart_by_peer
EOF
Bash
복사
# aws-vpn.conf 파일 생성
앞서 다운로드한 OpenSwan 구성 파일의 Tunnel_1의 내용을 입력합니다. (각자 설정)
추가적으로 leftsubnet: Local Network와 rightsubnet: Remote Network을 수정합니다.
aws-vpn.secrets 생성
cat <<EOF > /etc/ipsec.d/aws.secret
13.209.80.36 23.21.226.238: PSK "lZoevhySrJ8jnAMCce3hmDpnx745l9MJ"
13.209.80.36 44.215.166.83: PSK "DlzABkg3z0bHohiHYHMYEUEcESybnHQJ"
EOF
Bash
복사
# aws-vpn.secret 파일 생성
앞서 다운로드한 OpenSwan 구성 파일의 Tunnel_1의 내용을 입력합니다. (각자 설정)
OpenSwan VPN 서버 시작
systemctl enable ipsec
systemctl start ipsec
systemctl status ipsec
Bash
복사
# ipsec service 활성화 및 시작
=========================================
OUTPUT:
...
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 Wed 2024-12-18 13:10:43 UTC; 1min 12s ago
...
:END
Bash
복사
•
Active 상태임을 확인합니다.
7.4. Transit Gateway 라우팅 테이블 설정
•
VPC → Transit Gateway 라우팅 테이블 → 대상 선택 → 경로 탭 → 정적 경로 생성
필드 | 설정 |
CIDR | 10.6.0.0/16 |
유형 | 활성 |
연결 선택 | MAIN-TGW 선택(vpn) |
7.5. 통신 검증
./pingall.sh
Bash
복사
# 스크립트 파일 실행
=========================================
OUTPUT:
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
:END
Bash
복사
•
./pingall.sh 스크립트를 수행하면 모든 인스턴스 간 통신이 가능합니다.
[Caption] 현재까지 완료된 구성도 확인
8. NAT Gateway through AWS Transit Gateway 테스트
•
이 번 단계의 실습은 프라이빗 서브넷에 존재하는 인스턴스가 TGW를 통해 MAIN SITE의 EgressVPC에 존재하는 NAT GW로 외부 인터넷 통신을 테스트합니다.
•
프라이빗 서브넷에 TEST 환경과 DEV 환경으로 구분할 수 있는데 이 중에 DEV 환경만 NAT GW를 통해 외부 인터넷 통신을 하도록 구성합니다.
•
실습 환경: Region - 버지니아 북부 , Account - AWS 본 계정 + AWS 서브 계정
8.1. 버지니아 북부 CloudFormation 배포
CloudFormation 배포
•
앞서 정의한 Virginia_TransitGW_Lab_CF.yaml 파일을 배포합니다.
버지니아 북부 CF 생성 인프라 (NAT)
해당 작업은 AWS 본 계정에서 진행하며, EnvType은 Nat로 지정합니다.
8.2. Transit Gateway 연결
•
VPC → Transit Gateway 연결 → Transit Gateway Attachment 생성
필드 | 설정 |
이름 태그 | MAIN-VPCEG-ATT |
Transit gateway ID | MAIN-TGW 지정 |
연결 유형 | VPC |
VPC | EgressVPC |
8.3. 라우팅 테이블 수정
DEV 환경의 VPC 라우팅 설정
•
DEV 환경의 라우팅 테이블은 MAIN-DEV와 SUB-DEV 2개 대상으로 설정합니다.
◦
0.0.0.0/0 대역, TGW 타겟 ID
Transit Gateway 라우팅 설정
•
VPC → Transit Gateway 라우팅 테이블 → 대상 지정 → 경로 탭 → 정적 경로 생성
◦
0.0.0.0/0 대역, MAIN-VPCEG-ATT 대상 선택
VPCEG의 Private와 Public 라우팅 설정
•
2개의 라우팅 테이블을 수정합니다.
◦
10.0.0.0/8 대역, TGW 타겟 ID
8.4. 통신 검증
MAIN-TEST에서 검증
./pingall.sh
Bash
복사
# 스크립트 파일 실행
=========================================
OUTPUT:
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
:END
Bash
복사
•
./pingall.sh 스크립트를 수행하면 외부 인터넷 통신은 불가합니다.
MAIN-DEV에서 검증
./pingall.sh
Bash
복사
# 스크립트 파일 실행
=========================================
OUTPUT:
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
:END
Bash
복사
•
./pingall.sh 스크립트를 수행하면 모든 구간으로 통신이 가능합니다.
SUB SITE의 SUB-TEST와 SUB-DEV도 마찬가지 결과를 보입니다.
[Caption] 현재까지 완료된 구성도 확인
9. 자원 삭제
1.
서울 CloudFormation 스택 삭제
2.
아일랜드 TGW 연결에서 TGW Peering 대상 삭제
3.
아일랜드 CloudFormation 스택 삭제
4.
서브 계정 - Resource Access Manager에서 리소스 공유 나가기
5.
메인 계정 - Resource Access Manager에서 리소스 삭제
6.
서브 계정 - TGW 연결에서 VPC Attachment 대상 삭제
7.
서브 계정 - 버지니아 북부 CloudFormation 스택 삭제
8.
버지니아 북부 Site-to-Site VPN 연결 삭제 후 고객 게이트웨이 삭제
9.
버지니아 북부 TGW Multicast Domain 삭제 (우선 연결 대상 삭제)
10.
버지니아 북부 TGW 연결에 대상 모두 삭제
11.
버지니아 북부 Transit Gateway 삭제
12.
버지니아 북부 NAT CloudFormation 스택 삭제
13.
버지니아 북부 MAIN CloudFormation 스택 삭제
순서에 따라 진행하며, 모든 자원을 반드시 삭제해서 불필요한 과금이 발생하지 않도록 합니다.