DEVOCEAN

기존에는 VPC에 선언된 CIDR 내에 속한 네트워크 대역에 대해서는 라우팅 설정을 할 수 없었습니다.

따라서, VPC 내  라우팅 최 우선순위는 VPC에 선언된 CIDR 대역 전체에 대해서 기본 값으로 설정되는 Local 라우팅이었습니다.

< VPC 내의 라우팅 테이블에는 VPC의 CIDR을 Target으로 하는 local routing이 존재 >          

하지만, 올 해 9월 달에 이러한 제약 사항이 없어져서, 이제는 VPC 내에 속한 CIDR에 대해서도 VPC 내에서 라우팅 설정이 가능해졌습니다.

따라서, 라우팅 최우선 순위인 Longest Match Rule에 의해 좀 더 구체화 된 Target을 1순위로 경로 설정을 할 수 있습니다.

이를 통해서 VPC 내에서 통신하는 East-West Traffic은 물론 Transit Gateway를 통해서 VPC 간의 Traffic의 경우에도 별도의 분석을 위한 VPC 분리 없이 VPC 내에서 모든 Traffic을 경유하도록 하여 분석할 수 있습니다.

본 포스팅에서는 Transit Gateway로 연결된 두 VPC 간의 통신 시에,  상세 라우팅을 통해서 특정 인스턴스를 경유하는 예제를 다룹니다. 여기에서는 일반 EC2 인스턴스로 단순히 통신 트래픽을 경유하는 것만 체크해보지만, 실제 환경에서는 분석/보안 솔루션을 사용하여 모든 트래픽에 대한 확인 및 제어가 가능합니다.

다음은 오늘 다룰 구성도 입니다.

ZIGI-VPC1과 ZIGI-VPC2 라는 2개의 VPC가 Transit Gateway를 통해서 연결되어 있습니다.

ZIGI-VPC1에는 ZIGI-SUB-3에, ZIGI-VPC-2에는 ZIGI-SUB-4에 각각 Transit Gateway Attachment가 연결되어 있습니다.

ZIGI-VPC2에 ZIGI-Client에서 ZIGI-VPC1의 ZIGI-WEB으로 통신 시에,

Inbound와 Outbound 방향 모두 ZIGI-VM1을 경유하도록 ZIGI-VPC1 내의 서브넷 별 라우팅 설정을 합니다.

먼저 Transit Gateway와 연결된 ZIGI-SUB-3 서브넷에 적용되는 라우팅 테이블입니다.

ZIGI-VPC2와 통신하기 위해서 ZIGI-VPC2의 네트워크 대역인 10.1.0.0/22 에 대해서 Transit Gateway를 향하도록 설정합니다.

ZIGI-WEB과 통신하기 위해서는 ZIGI-VM1을 경유하도록 ZIGI-WEB이 있는 ZIGI-SUB-2 서브넷 대역인 10.0.1.0/24에 대해서, ZIGI-VM1을 Target으로 설정합니다.

설정 시에는 ZIGI-VM1 인스턴스 자체를 설정하거나, ZIGI-VM1의 네트워크 인터페이스를 설정하면 됩니다.

< Target으로 '인스턴스' 혹은 '네트워크 인터페이스'로 설정이 가능 >

다음은 ZIGI-SUB-1 서브넷에 적용되는 라우팅 테이블입니다.

ZIGI-SUB-1의 경우에는 ZIGI-SUB-2 서브넷을 가기 위한 모든 트래픽이 경유하게 될 ZIGI-VM1 이 있는 서브넷으로,

ZIGI-SUB-2에 대한 라우팅은 기본 로컬 라우팅으로 처리가 되기 때문에, ZIGI-VPC2와 통신하기 위한 10.1.0.0/24 대역에 대해서만 Transit Gateway를 Target으로 처리합니다.

마지막으로 ZIGI-SUB-2 서브넷에 적용되는 라우팅 테이블입니다.

ZIGI-WEB이 있는 서브넷인  ZIGI-SUB-2에서는  ZIGI-VPC2와 통신하기 위한 라우팅을 ZIGI-VM1을 경유하도록, 10.1.0.0/24 대역에 대해서 ZIGI-VM1 인스턴스를 Target으로 설정합니다.

만약, 서비스 요청 트래픽에 대해서만 트래픽 감시가 필요한 솔루션의 경우에는 응답에 대한 라우팅을 바로 Transit Gateway로 잡아서 구성해도 무방합니다.

ZIGI-VM1의 위치에 들어갈 솔루션에 따라서, 응답 경로를 설정하시면 됩니다.

여기에서는 모든 요청 트래픽과 응답 트래픽을 경유 하도록 구성하기 위해서 ZIGI-VM1을 Target으로 잡았습니다.

라우팅 설정이 끝나면, ZIGI-VM1이 트래픽을 경유할 수 있도록 추가 설정을 2가지 합니다.

먼저 ZIGI-VM1 인스턴스의 네트워크 설정에서 소스/대상 확인 옵션에 대해서 '중지'를 합니다.

이 옵션 값은 기본적으로 활성화 상태이며, 활성화 된 상태에서는 패킷의 출발지나 목적지가 해당 인스턴스에 속하지 않으면 패킷이 폐기됩니다.

만약, 활성화를 하게 되면, 출발지나 목적지가 해당 인스턴스에 속하지 않더라도 폐기 시키지 않고 forwarding이 가능합니다.

다음으로 Linux에서 패킷을 Forwarding 할 수 있도록, 아래와 같이, ip_forward 값을 1(enable)로 설정합니다.

그럼 이제 통신 테스트를 해보겠습니다.

ZIGI-VPC2에 존재하는 ZIGI-Client(10.1.0.203)에서 ZIGI-WEB(10.0.1.65)로 Ping을 보내면 정상적으로 통신되는 것을 볼 수 있습니다.

ZIGI-WEB(10.0.1.65)에서 tcpdump로 확인해 보면, ZIGI-Client의 IP에서 직접 호출되는 것을 확인 할 수 있습니다.

즉, 중간에 ZIGI-VM1을 경유하더라도 별도의 NAT 과정을 거치지 않아도 된다는 의미입니다.   

그럼 실제, ZIGI-VM1(10.0.0.31)에서 ZIGI-Client(10.1.0.203)과 ZIGI-WEB(10.0.1.65) 간의 통신이 경유하는지 보면,

아래와 같이 정상적으로 경유하는 트래픽이 보이는 것을 확인 할 수 있습니다.

이 때, 동일한 패킷이 2개씩 보이는 것은 ZIGI-VM1이 하나의 ENI로 구성되어 있기 때문입니다.

만약, ZIGI-VM1에 위치하는 솔루션에 대해서 In-bound와 Out-Bound를 각각 다른 ENI로 구성하게 되면, 각 인터페이스에서 1번씩만 확인이 될 것입니다.

물론 이 경우에는 위와 같은 서브넷 배치와, 라우팅을 일부 수정해서 사용하는 것이 좋습니다.

여기까지 VPC 내부 대역에 대한 세부 라우팅 설정 제약과 관련하여 변경된 사항에 대해서 확인해 보았습니다.

기존의 VPC Ingress-Routing 기능에 대한 출시도 마찬가지였지만, 서비스가 단순히 통신하는 데 그치지 않고 트래픽에 대한 분석이나 보안 요건 등을 위한 네트워크 경로 설정에 대한 기능들에 대해서도 점점 나아지는 것 같습니다.