[AWS] Private NAT Gateway Test (+ TGW, VPC Flow Log)

 

https://aws.amazon.com/ko/about-aws/whats-new/2021/06/aws-removes-nat-gateways-dependence-on-internet-gateway-for-private-communications/

AWS, 프라이빗 통신을 위한 인터넷 게이트웨이에 대한 NAT 게이트웨이의 종속성 제거

 

이제 NAT GW를 IGW, EIP 없이 프라이빗한 용도로 사용할 수 있다고 한다...................?

 

도대체 NAT GW를 프라이빗한 용도로 어따 쓴다는 걸까

다른 VPC와 통신을 위한다해도 어차피 TGW나 피어링은 사용해야할텐데

 

계속 고민을 해봤는데, 아무래도 범용적으로 유용하게 사용할 수 있다기보다 특수한 상황에서 고려해볼만한 솔루션이 하나 늘었다고 생각하는게 맞을듯하다 (쓸 일이 생길지는 모르겠다)

 

난 일단 VPC끼리 통신할 때, Private NAT GW를 거치면 하나의 사설IP를 통해 트래픽을 보내게 되므로 관리 엔드포인트가 줄고 보안상 안전해진다는 것에 중점을 두고, 실제로 트래픽이 들어올 때 NAT GW 사설 IP로만 들어오는지를 테스트해보도록 하겠다

 

목차

0. 실습 시나리오

1. Private NAT Gateway 생성

2. 통신 테스트 (Ping)

3. Flow Log 확인

---

 

0. 실습 시나리오

---

 

• Source Subnet
  • Target Server로 직접 Ping을 날릴 서버(Source Server) 존재
  • 내가 SSH로 접속해야 하므로 igw가 붙어있으며 퍼블릭 IP를 할당받는다

 

• NAT Subnet
  • NAT GW 존재
  • Source Server에서 온 트래픽을 TGW로 보내줘야 한다

 

• TGW
  • VPC1(10.0.0.0/16)과 VPC2(10.50.0.0/16)에 대한 Attachment 있어야 함

 

• Target Subnet
  • 최종적으로 핑 트래픽을 받을 Target Server 존재
  • VPC Flow Logs를 활성화 해 실제로 들어오는 트래픽의 Source IP가 NAT GW의 IP인지 확인

 

 

실습을 편하게 하기 위해 VPC, EC2, TGW, Flow Log 설정은 모두 CloudFormation으로 만들어 두었다

 

VPCforPrivateNAT.yml

0.01MB

 

 

AWS Console > CloudFormation > 스택 생성을 통해 리소스들을 모두 프로비저닝한 후 시작하도록 하자

※ 버지니아, 오하이오, 캘리포니아, 오레곤, 도쿄, 서울만 가능

※ 해당 리전에 Key Pair가 존재해야한다 (없으면 만들어두자)

 

TGW도 만드느라 좀 오래걸린다....

 

 

1. Private NAT Gateway 생성

---

콘솔 > VPC > NAT 게이트웨이 > NAT 게이트웨이 생성

 

 

이름은 원하는대로, 서브넷은 VPC1-NAT, Connectivity type은 Private으로 지정한 후 생성해주자

Connectivity type을 Private으로 바꾸니 Private NAT gateway는 internet이랑 통신할 필요 없다는 문구가 뜬다

 

NAT GW가 Pending되는 동안 NAT로 트래픽을 보내야 하는 Source Server의 라우팅 테이블을 수정해주자

콘솔 > VPC > 라우팅 테이블 > VPC1 - SourceRT 선택 > 라우팅 > 라우팅 편집

 

 

Target Server로 보내야 하는 트래픽을 방금 만든 Private NAT GW를 바라보게 해주자

 

 

생성된 NAT GW의 사설 IP를 확인하고 넘어가자

나는 10.0.20.201이다

 

 

2. 통신 테스트 (Ping)

---

콘솔 > EC2로 들어와보면 아래와 같이 SourceEC2와 TargetEC2가 만들어져 있다

 

 

EC2들의 IP도 확인하고 넘어가겠다

• SourceEC2
  • Public IP : 3.36.96.160
  • Private IP : 10.0.10.63
• Target IP
  • Private IP : 10.50.10.196

 

각자 SSH 클라이언트 프로그램을 가지고 SourceEC2(Public IP로)에 접속해보자 (본인은 mobaXterm 사용)

키는 처음 CloudFormation 스택을 생성할 때 지정해준 키를 사용하면 된다

login as: ec2-user

혹시 모르는 사람 있을까봐 login user 적어둔다

 

이제 Target Server로 Ping을 날려보겠다

[ec2-user@ip-10-0-10-63 ~]$ ping 10.50.10.196
PING 10.50.10.196 (10.50.10.196) 56(84) bytes of data.
64 bytes from 10.50.10.196: icmp_seq=1 ttl=253 time=4.12 ms
64 bytes from 10.50.10.196: icmp_seq=2 ttl=253 time=2.24 ms
64 bytes from 10.50.10.196: icmp_seq=3 ttl=253 time=2.14 ms
64 bytes from 10.50.10.196: icmp_seq=4 ttl=253 time=2.06 ms
64 bytes from 10.50.10.196: icmp_seq=5 ttl=253 time=2.16 ms
64 bytes from 10.50.10.196: icmp_seq=6 ttl=253 time=2.10 ms
64 bytes from 10.50.10.196: icmp_seq=7 ttl=253 time=2.10 ms
64 bytes from 10.50.10.196: icmp_seq=8 ttl=253 time=2.12 ms

Ping 통신이 아주 잘 이루어지는걸 확인할 수 있다

 

 

3. Flow Log 확인

---

콘솔 > CloudWatch > 로그 > 인사이트 로 들어가서 VPC2 로그 그룹을 선택해주자

 

 

그리고 예시 쿼리문을 지우고 아래와 같이 적어준 후, 쿼리 실행을 눌러주자

fields @timestamp, srcAddr, dstAddr, protocol, action, logStatus
 | filter srcAddr LIKE "10.0."
 | sort @timestamp desc

 

 

srcAddr이 Source Server(10.0.10.63)가 아닌 NAT GW(10.0.20.201)인걸 확인할 수 있다

 

---

 

뭐...통신해보고 소스IP 확인만 해보는 간단한 실습이었지만, 각 VPC 안에 같은 대역을 사용하는 서브넷이 있어서 TGW나 VPC 피어링을 사용하지 못하는 경우에도 사용할 수 있는 것 같다 (참조 :  https://zigispace.net/1135)

 

※ 리소스는 NAT GW -> CloudFormation Stack 순으로 지워주자

※ 그리고 왜인진 모르겠다만 로그 그룹은 스택을 지워도 남아있다...직접 지워주자

 

 

 

끝