N2SVPC를 Cloudformation에서 앞서 과정과 동일하게 생성합니다. 다운로드 받은 Yaml 파일들 중에 N2SVPC 선택해서 생성합니다.스택 이름을 생성하고, GWLBVPC의 VPC Endpoint 서비스 이름을 "VPCEndpointServiceName" 에 입력합니다. 또한 나머지 파라미터들도 입력합니다. 대부분 기본값을 사용합니다.
스택이름 : N2SVPC
AvailabilityZone A : ap-northeast-2a
AvailabilityZone B : ap-northeast-2b
VPCCIDRBlock: 10.11.0.0
PublicSubnetABlock: 10.11.11.0/24
PublicSubnetBBlock: 10.11.12.0/24
PrivateSubnetABlock:10.11.21.0/24
PrivateSubnetBBlock:10.11.22.0/24
TGWSubnetABlock:10.11.251.0/24
TGWSubnetBBlock:10.11.252.0/24
DefaultRouteBlock: 0.0.0.0/0 (Default Route Table 주소를 선언합니다.)
VPC1CIDRBlock : 10.1.0.0/16 (VPC1의 CIDR Block 주소를 선언합니다.)
VPC2CIDRBlock: 10.2.0.0/16 (VPC2의 CIDR Block 주소를 선언합니다.)
VPCEndpointServiceName : 앞서 복사해둔 GWLBVPC의 VPC endpoint service name을 입력합니다.
**AWS 관리 콘솔 -VPC 대시보드 - 가상 프라이빗 클라우드 - 라우팅테이블**에서 각 Private-Subnet-A,B-RT 라우팅 테이블을 확인합니다.
VPC01,02-Private-Subnet-A,B-RT : 0.0.0.0/0 - tgw
GWLB 구성 확인
GWLBVPC 구성을 확인해 봅니다.
GWLB 구성
GWLB Target Group 구성
VPC Endpoint 와 Service 확인
Appliance 확인
7.GWLB 구성
AWS 관리 콘솔 - EC2 - 로드밸런싱 - 로드밸런서 메뉴를 선택합니다. Gateway LoadBalancer 구성을 확인할 수 있습니다. ELB 유형이 **"gateway"**로 구성된 것을 확인 할 수 있습니다.
8.GWLB Target Group 구성
**AWS 관리 콘솔 - EC2 - 로드밸런싱 - 대상 그룹**을 선택합니다. GWLB가 로드밸런싱을 하게 되는 대상그룹(Target Group)을 확인 할 수 있습니다.
프로토콜 : GENEVE 6081 (포트 6081의 GENGEVE 프로토콜을 사용하여 모든 IP 패킷을 수신하고 리스너 규칙에 지정된 대상 그룹에 트래픽을 전달합니다.)
등록된 대상 : GWLB가 로드밸런싱을 하고 있는 Target 장비를 확인합니다.
AWS 관리 콘솔 - EC2 - 로드밸런싱 - 대상 그룹 - 상태검사 메뉴를 확인합니다.
ELB와 동일하게 대상그룹(Target Group)에 상태를 검사할 수 있습니다. 이 랩에서는 HTTP Path / 를 통해서 **Health Check**를 하도록 구성했습니다.
9. VPC Endpoint Service 확인
N2SVPC Private link로 연결하기 위해, GWLB VPC에 Endpoint Service를 구성하였습니다. 이를 확인해 봅니다.
**AWS 관리 콘솔 - VPC - 엔드포인트 서비스**를 선택합니다. 생성된 VPC Endpoint Service를 확인할 수 있습니다.
서비스 이름 - 예 com.amazonaws.vpce.ap-northeast-2.vpce-svc-082d152b9180f8ad0
유형 : GatewayLoadBalancer
가용영역 : ap-northeast-2a, ap-northeast-2b
2개 영역에 걸쳐서 GWLB에 대해 VPC Endpoint Service를 구성하고 있습니다.
**AWS 관리 콘솔 - VPC - 엔드포인트 서비스-엔드포인트 연결**를 선택합니다.
N2SVPC의 각 가용영역들과 연결된 것을 확인 할 수 있습니다. VPC별 2개의 가용영역의 Private Subnet에 배치된 VPC Endpoint에 연결된 것을 확인 합니다.
10. Appliance 확인
AWS 관리 콘솔 - EC2 - 인스턴스 메뉴를 선택하고, "appliance" 키워드로 필터링 해 봅니다. 4개의 리눅스 기반의 appliance가 설치되어 있습니다.
Appliance 구성 정보를 확인해 봅니다.
**AWS 관리콘솔 - Cloudformation - 스택**을 선택하면, 앞서 배포했던 Cloudformation 스택들을 확인 할 수 있습니다. **"GWLBVPC"**를 선택합니다. 그리고 출력을 선택합니다. 값을 확인해 보면 공인 IP 주소를 확인 할 수 있습니다.
앞서 사전 준비에서 생성한 Code-Server 터미널에서 Appliance로 직접 접속해 봅니다.
아래와 같이 구성합니다.
#기존 Appliance 정보를 삭제
sudo sed '/Appliance/d' ~/.bash_profile
#SSM 연결을 위한 Shell 실행
~/environment/gwlb/appliance_ssm.sh
각 Appliance에서 아래 명령을 통해 , GWLB IP와 어떻게 매핑되었는지 확인합니다. Code-Server에서 새로운 터미널 4개를 탭에서 추가해서 4개 Appliance를 모두 확인해 봅니다.
GENEVE 터널링의 GWLB IP주소는 10.254.12.101 이며, Appliance IP와 터널링 된 것을 확인 할 수 있습니다.
이렇게 GWLB 에서 생성된 IP주소와 각 Appliance의 IP간에 UDP 6081 포트로 터널링되어 , 외부의 IP 주소와 내부의 IP 주소를 그대로 유지할 수 있습니다. 또한 터널링으로 인입시 5Tuple (출발지 IP, Port, 목적지 IP, Port, 프로토콜)의 정보를 TLV로 Encapsulation하여 분산처리할 때 사용합니다.
외부 연결용 VPC 확인
이제 외부 연결 VPC에서 실제 구성과 트래픽을 확인해 봅니다.
VPC Endpoint 확인
Private Subnet Route Table 확인
Ingress Routing Table 확인
아래 흐름과 같이 트래픽이 처리됩니다.
VPC1,2 인스턴스는 외부로 향하기 위해 TransitGateway로 접근
VPC 1,2 Private Subnet Route Table을 참조해서, Transit Gateway로 전
TransitGateway Routing Table을 참조해서, N2SVPC Attachment로 전
N2SVPC 로 인입된 트래픽은 N2SVPC TGW Routing Table에 의해 VPC Endpoint로 전달.
[ec2-user@ip-10-254-11-102 ~]$ sudo tcpdump -nvv 'port 6081'
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:12:15.788834 IP (tos 0x0, ttl 255, id 0, offset 0, flags [none], proto UDP (17), length 152)
10.254.11.107.60000 > 10.254.11.102.6081: [udp sum ok] Geneve, Flags [none], vni 0x0, options [class Unknown (0x108) type 0x1 len 12 data f583215d 2e66b39c, class Unknown (0x108) type 0x2 len 12 data 00000000 00000000, class Unknown (0x108) type 0x3 len 8 data 6742cc6d]
IP (tos 0x0, ttl 253, id 62598, offset 0, flags [DF], proto ICMP (1), length 84)
10.1.21.101 > 99.86.206.123: ICMP echo request, id 32496, seq 4971, length 64
15:12:15.788867 IP (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto UDP (17), length 152)
10.254.11.102.60000 > 10.254.11.107.6081: [udp sum ok] Geneve, Flags [none], vni 0x0, options [class Unknown (0x108) type 0x1 len 12 data f583215d 2e66b39c, class Unknown (0x108) type 0x2 len 12 data 00000000 00000000, class Unknown (0x108) type 0x3 len 8 data 6742cc6d]
IP (tos 0x0, ttl 253, id 62598, offset 0, flags [DF], proto ICMP (1), length 84)
10.1.21.101 > 99.86.206.123: ICMP echo request, id 32496, seq 4971, length 64
15:12:15.790832 IP (tos 0x0, ttl 255, id 0, offset 0, flags [none], proto UDP (17), length 152)
10.254.11.107.60000 > 10.254.11.102.6081: [udp sum ok] Geneve, Flags [none], vni 0x0, options [class Unknown (0x108) type 0x1 len 12 data f583215d 2e66b39c, class Unknown (0x108) type 0x2 len 12 data 00000000 00000000, class Unknown (0x108) type 0x3 len 8 data 6742cc6d]
IP (tos 0x0, ttl 237, id 27319, offset 0, flags [none], proto ICMP (1), length 84)
99.86.206.123 > 10.1.21.101: ICMP echo reply, id 32496, seq 4971, length 64
15:12:15.790847 IP (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto UDP (17), length 152)
10.254.11.102.60000 > 10.254.11.107.6081: [udp sum ok] Geneve, Flags [none], vni 0x0, options [class Unknown (0x108) type 0x1 len 12 data f583215d 2e66b39c, class Unknown (0x108) type 0x2 len 12 data 00000000 00000000, class Unknown (0x108) type 0x3 len 8 data 6742cc6d]
IP (tos 0x0, ttl 237, id 27319, offset 0, flags [none], proto ICMP (1), length 84)
99.86.206.123 > 10.1.21.101: ICMP echo reply, id 32496, seq 4971, length 64
Source IP와 Destination IP가 모두 유지된 채로 통신하는 것을 확인 할 수 있습니다.
이제 다른 VPC(VPC01,VPC02)와 다른 서브넷의 EC2에서도 트래픽이 정상적으로 처리되는지 확인해 봅니다.
자원 삭제
AWS 관리콘솔 - Cloudformation - 스택 을 선택하고 생성된 Stack을 삭제합니다.
GWLBTGW,VPC01,VPC02,N2SVPC,GWLBVPC 순으로 삭제합니다.(Code-Server은 계속 사용하기 위해 삭제 하지 않습니다.)
