1.4 TGW 기반 VPC 트래픽 제어

Update : 2020-02-24

AWS Networking의 이해

"1.3 TGW 구성" 을 마치고, VPC간 통신이 되지 않으며 IT OCTANK VPC의 EC2 인스턴스를 제외한 모든 VPC의 EC2 인스턴스가 외부로 네트워크가 되지 않는 것을 확인하였습니다. 이제 그 이유를 살펴 보고 , 기업에서 효과적으로 VPC간의 트래픽을 제어하기 위한 방법을 살펴 보겠습니다.

먼저 AWS Networking을 이해할 필요가 있습니다. 우리의 랩 구성은 현재 아래와 같이 논리적으로 구성되어 있습니다. IT OCTANK와 A OCTANK 구성을 살펴 보겠습니다.

A OCTANK VPC에서 EC2 Instance 10.11.14.100의 서버 IT OCTANK VPC의 EC2 Instance 10.0.14.100 사이에 트래픽이 전송되지 않는 이유는 상호간에 VPC Private Route Table에 관련 정보가 없기 때문입니다. 아래 그림은 각 VPC에서 Private Route Table 에서의 경로 정보입니다. IT OCTANK VPC에서 EC2 Instance가 www.aws.com 으로 정상적으로 PING 응답이 되는 이유는 0.0.0.0/0 에 대한 경로가 NAT Gateway 로 지정되어 있기 때문입니다.

[VPC] - [Route Table]

[그림 1.4.1] 3에서 처럼 Transit Gateway에 연결된 A OCTANK VPC를 위한 Red Route Table에는 0.0.0.0/0 에 대한 경로가 이미 IT OCTANK VPC로 Static으로 선언 되어 있습니다.

"1.3 TGW 구성"에서 VPC간 통신이 되지 않았던 이유는, TGW 의 구성은 Cloudformation에서 모두 라우팅 구성이 되어 있지만, 각 VPC에서 Route Table에 경로가 없기 때문입니다. 실제 필드에서도 TGW는 모두 구성하여 연결하고, 필요에 따라 각 VPC에서는 Route Table에만 추가하면 원하는 데로 트래픽 경로를 처리할 수 있게 됩니다.

1.이제 A OCTANK와 IT OCTANK의 Private Route Table에서 Table을 추가하고, 각 EC2에서 다시 트래픽이 정상적으로 동작하는지를 확인해 봅니다.

[VPC] - [Route Table] - [Edit Route] -[10.0.0.0/8 Table 추가]

2. 네트워크 연결을 IT OCTANK EC2, A OCTANK EC2 에서 확인합니다.

aws ssm start-session --target i-0b8c62bb05385d50a

[ec2-user@ip-10-0-14-100 ~]$ ./pingshell.sh
Tue Feb 25 15:18:11 UTC 2020
target www.aws.com is up
target ITSVR-A is up
target ITSVR-B is up
target ASVR-A is up
target ASVR-B is up
target BSVR-A is down
target BSVR-B is down
target CSVR-A is down
target CSVR-B is down
target DSVR-A is down
target DSVR-B is down
target FSVR-A is down
target FSVR-B is down
target ZSVR-A is down
target ZSVR-B is down

상호간에 정상적으로 네트워크 통신이 이뤄지지만 A OCTANK의 Private Subnet에 존재하는 EC2는 여전히 인터넷으로 통신이 되지 않습니다. (www.aws.com이 down으로 결과 표시됩니다.) 이것은 NAT Gateway가 IT OCTANK Public Subnet에 있고 해당 경로에 대한 지정을 Public Route Table에서 설정하게 되어 있지만 A OCTANK에 대한 경로가 설정되어 있지 않기 때문입니다.

IT OCTANK Public Routing Table에서 왜 10.11.0.0/16 의 경로를 Transit Gateway로 설정하지 않고, 10.0.0.0/8의 경로 설정할까요? 10.11.0.0/16 으로 지정하게 되면 향후 10.x.0.0/16 단위의 VPC 경로를 그때 마다 지정해야 합니다. 따라서 우리는 10.0.0.0/8 로 Route Summary / IP Suppernetting 을 하게 되면 , 단 한줄을 라우팅 구성으로 VPC 전체를 인터넷 통신을 할 수 있게 할 수 있습니다. 이것이 중요한 이유는 Transit Gateway, VPC Peering 등 모든 구성에서 Routing Table 에 대한 한계가 있기 때문에 되도록이면 Route Summary를 해주는 것이 좋습니다.

이러한 구성을 보통 Route Summary 또는 IP Supernetting 이라고 부릅니다.

IT OCTANK Public Routing Table에서는 10.0.0.0/8 에 대한 경로를 Transit Gateway로 보내면 정상적으로 인터넷이 될 것입니다.

3. IT OCTANK에서 Public Routing Table에 10.0.0.0/8의 경로를 Transit Gateway로 추가합니다.

4. A OCTANK EC2 인스턴스에서 네트워크 연결을 확인합니다.

[ec2-user@ip-10-11-14-100 ~]$ ./pingshell.sh
Tue Feb 25 15:38:33 UTC 2020
node www.aws.com is up

### A OCTANK Private Subnet의 EC2 인스턴스는 NAT GW, IGW 없이, TGW-IT OCTANK VPC
NAT Gateway를 통해 인터넷에 연결됩니다.

node ITSVR-A is up
node ITSVR-B is up
node ASVR-A is up
node ASVR-B is up
node BSVR-A is down
node BSVR-B is down
node CSVR-A is down
node CSVR-B is down
... 이하 생

아래 그림은 지금까지 구성한 네트워크 구성에 대해 라우팅 경로를 설명합니다. [그림 1.4.1]과 비교해 보십시요. [그림 1.4.7]에서 빨간색 Box가 신규 추가된 라우팅 테이블입니다. 테이블이 추가됨에 따라 서로간의 경로를 이해 할 수 있게 됩니다.

[그림 1.4.8]은 VPC Route Table, TGW Route Table을 통해 Control Plane (제어부)를 통해 , 네트워크 흐름을 어떻게 제어하고 있는지 논리적으로 표현한 것입니다.

5.이제 B OCTANK, C OCTANK에도 동일하게 Routing Table을 추가해서 모든 네트워크가 통신이 되도록 만듭니다. IT OCTANK Private Route Table과 Public Routing Table은 더 이상 추가할 내용이 없습니다. (IP Supernetting을 했기 때문입니다.)

6.이제 A,B,C,IT OCTANK Private Subnet에 존재하는 EC2 Instance들의 네트워크 트래픽을 다시 점검해 봅니다. 모든 VPC의 EC2에서 정상적으로 트래픽이 허용되는 것을 확인 할 수 있습니다.

[ec2-user@ip-10-0-14-100 ~]$ ./pingshell.sh
Tue Feb 25 16:17:00 UTC 2020
target www.aws.com is up
target ITSVR-A is up
target ITSVR-B is up
target ASVR-A is up
target ASVR-B is up
target BSVR-A is up
target BSVR-B is up
target CSVR-A is up
target CSVR-B is up
target DSVR-A is down
target DSVR-B is down
target FSVR-A is down
target FSVR-B is down
target ZSVR-A is down

IT OCTANK VPC의 Private Subnet에 연결되어 있는 EC2 인스턴스와 A OCTANK VPC의 Private Subnet에 연결되어 있는 EC2 인스턴스와의 통신은 아래와 같은 논리적인 흐름으로 VPC-TGW-VPC 연결이 됩니다.

외부 인터넷과 A OCTANK VPC의 Private Subnet에 연결되어 있는 EC2 인스턴스 통신은 아래와 같이 논리적인 흐름을 통해 연결됩니다.

TGW기 VPC 트래픽 제어

이 랩의 목적은 기업 환경에서 VPC들이 TGW를 통해 NAT G.W, IGW 등과 같은 자원을 공유하여 비용 최적화를 하고, 기업 내부의 VPC간의 효과적인 트래픽을 제어하는 것입니다.

따라서 모든 트래픽을 허용하는 것은 바람직하지 못합니다. 이 랩에서는 A OCTANK와 B OCTANK, IT OCTANK 간에는 트래픽을 허용하고, C OCTANK는 A,B OCTANK와 트래픽을 제어하는 것을 구성해 봅니다.

위의 목적으로 구성하는 방법은 여러가지 방법이 있습니다. [그림 1.4.12]는 지금까지 구성한 랩의 논리적인 구성입니다. 지금까지 구성한 환경에서는 TGW에 연결된 모든 VPC의 자원들이 트래픽을 허용하고 있습니다.트래픽 제어를 위해서는 라우팅 테이블 설정을 세밀하게 하는 방법도 있지만, 이러한 방법은 TGW Route Table, 각 VPC의 Route Table을 모두 세밀하게 설정해야 하기 때문에 관리적으로 복잡성을 가져올 수 있습니다. 또한 Security Group , Network ACL을 통해서 제어하는 방법도 있습니다. 이 방법 역시 세밀한 구성 관리가 필요하므로 VPC간 제어에 관리적 부담이 요구됩니다.

랩에서는 Transit Gateway에서 제공되는 Blackhole Routing 을 통해서 VPC간 연결제어에 대한 예를 소개합니다.

Blackhole Routing 기법은 네트워크에서 오랜 동안 전통적으로 사용해 오던 기법입니다. 특정 목적지로 향하는 트래픽을 Null Routing 처리하여 폐기시키는 방식입니다. TGW 에서 트래픽을 받고 Route Table에서 Blackhole로 폐기하여 , Drop 시키는 역할을 합니다.

아래와 같이 구성하여 트래픽을 제어합니다. 모든 VPC의 Private Subenet 은 인터넷을 허용하고, IT OCTANK의 EC2자원은 모든 VPC에서 트래픽을 상호 허용합니다. 또한 A VPC EC2, B VPC EC2도 상호 연결을 허용합니다. 하지만 C VPC EC2는 A,B VPC 접근을 불허하고 IT VPC 및 인터넷만 가능하게 하는 예입니다.

인터넷 NAT GW

IT OCTANK

Private EC2

A OCTANK

Private EC2

B OCTANK

Private EC2

C OCTANK

Private EC2

인터넷 NAT GW

Permit

Permit

Permit

Permit

IT OCTANK

Private EC2

Permit

Permit

Permit

Permit

A OCTANK

Private EC2

Permit

Permit

Permit

Deny

B OCTANK

Private EC2

Permit

Permit

Permit

Deny

C OCTANK

Private EC2

Permit

Permit

Deny

Deny

1.아래와 같이 TGW Route Table에서 Blackhole로 처리하고 각 EC2에서 트래픽 허용을 확인합니다.

2. 각 VPC EC2 인스턴스에서 네트워크 연결 상태를 확인합니다.

[ec2-user@ip-10-0-14-100 ~]$ ./pingshell.sh
Wed Feb 26 12:50:23 UTC 2020
target www.aws.com is up
target ITSVR-A is up
target ITSVR-B is up
target ASVR-A is up
target ASVR-B is up
target BSVR-A is up
target BSVR-B is up
target CSVR-A is up
target CSVR-B is up

Chapter 1을 모두 완료하게 되면 아래와 같은 네트워크 구성이 완료 됩니다.

해당 웹사이트는 크롬, 파이어폭스, 사파리 웹 브라우저에 최적화되어 있습니다. 인터넷 익스플로러에서는 원할하게 보이지 않을 수 있습니다.

Last updated