안녕하세요.
오늘은 Transit Gateway와 Network Firewall를 이용하여 Hub and Spoke 환경을 구성해 보겠습니다.
# Transit Gateway
Transit Gateway(TGW)는 여러 VPC와 온프레미스 네트워크를 하나의 중앙 허브처럼 연결해주는 네트워크 서비스입니다.
저희는 각 VPC를 TGW를 이용하여 연결하고 모든 통신이 AWS Network Firewall를 통해서 이루어지게 하겠습니다.
VPC에서 `transit gateway`를 선택하여 "생성"을 클릭합니다.
이름을 설정합니다.
각 구성에 대해 설명드리자면
DNS 지원: Transit Gateway를 통해 연결된 네트워크(예: VPC, VPN, Direct Connect)에서도 Route 53 등 AWS DNS 서비스를 사용할 수 있게 하여, 네트워크 전체에서 도메인 이름 기반의 통신이 가능하도록 지원합니다.
보안 그룹 참조 지원: 서로 다른 VPC의 보안 그룹을 참조하여 TGW를 통해 연결된 리소스간의 트래픽 제어가 가능합니다. 즉, TGW 넘어 다른 VPC의 보안 그룹 규칙까지 양쪽에서 적용, 관리가 가능합니다.
VPN ECMP 지원: ECMP(Equal Cost Multi-Path)를 통해 여러 Site-to-Site VPN 연결에서 부하 분산(로드밸런싱)이 가능합니다. 동일 우선순위의 경로를 병렬로 활용함으로써 트래픽을 더욱 효율적으로 처리할 수 있습니다.
기본 라우팅 테이블 연결: TGW에 추가되는 VPC/VPN 연결(Attachment)이 기본 라우팅 테이블과 자동으로 연결(Association)되는 기능입니다. 신규 Attachment가 기본 라우팅 테이블을 따라 네트워크 라우팅을 처리할 수 있습니다.
기본 라우팅 테이블 전파: 새롭게 연결된 네트워크에 대한 라우팅 정보가 기본 TGW 라우팅 테이블에 자동으로 추가(Propagation)됩니다. 관리자가 직접 경로를 하나하나 지정하지 않아도 되어 운용이 간편합니다.
멀티캐스트 지원: TGW에서 멀티캐스트 트래픽(특정 그룹에 한 번에 데이터를 전송)이 가능합니다. 예를 들어, 여러 서버에 동시에 데이터나 파일을 배포할 때 사용하며, 멀티캐스트 송수신이 필요한 워크로드에 적합합니다.
저희는 아무것도 사용하지 않아도 되니 모두 체크 해제하겠습니다.
교차 계정 공유 옵션 : Cross Account 간 연결 시 수락을 자동으로 하게 하는 옵션입니다.
Transit Gateway CIDR 블록 : 연결할 대역을 선택합니다.
이제 생성하겠습니다.
이제 VPC에 연결하기 위해 Transit Gateway 연결을 생성해야하는데요.
Transit Gateway 연결을 눌러 생성을 클릭합니다.
Transit Gateway와 연결할 VPC를 선택한 뒤 생성합니다.
위 과정을 VPC 갯수 만큼 즉, 3번 반복합니다.
이제 Transit Gateway Routeable을 생성하겠습니다.
Transit Gateway Routetable은 Transit Gateway로 들어오는 트래픽을 라우팅 하는 테이블로 VPC Route Table과는 별개입니다.
VPC Route Table을 통해 Transit Gateway로 트래픽이 들어오면 거기서 Transit Gateway Route Table로 한번 더 경로를 지정하는 것입니다.
Transit Gateway라우팅 테이블을 선택 후 생성을 클릭합니다.
Spoke에서 Inspection으로 라우팅 할 라우팅 테이블을 생성합니다.
이번에는 Inspection VPC에서 들어올 트래픽을 라우팅 할 라우팅 테이블을 생성합니다.
이제 경로 설정을 해주겠습니다.
Transit Gateway에 들어온 트래픽은 모두 Inspection으로 향하게 설정 후 생성합니다.
이제 Inspection VPC에서 들어오는 트래픽을 각 Spoke에 알맞게 보낼 수 있게 경로를 생성하겠습니다.
아래 두개 경로를 생성합니다.
경로 설정이 끝났으면 각 transit gateway 연결에 테이블을 연결하겠습니다.
inspection-RouteTable 부터 설정하겠습니다.
Inspection VPC에 연결하기 위해 아까 생성한 Inspection VPN용 연결에 연결합니다.
이번에는 각 Spoke vpc에 연결하겠습니다.
아래 과정을 통해 각 Spoke1,2 VPC에 연결합니다.
이제 transit gateway에서의 설정은 모두 끝났고 network firewall 설정을 진행하겠습니다.
# Network Firewall
말 그대로 네트워크 레벨 방화벽으로 AWS에서 제공하는 서비스입니다.
저희는 이 방화벽을 이용하여 모든 트래픽이 해당 방화벽을 통해 필터링되게 하겠습니다.
방화벽으로 들어가 생성을 클릭합니다.
이름 설정 후 다음으로 넘어갑니다.
VPC-Inspection에 방화벽을 배포하겠습니다.
그리고 아래 방화벽 엔드포인트를 배포할 서브넷을 선택합니다.
저희는 모든 설정을 끄고 넘어가겠습니다.
정책도 생성합니다.
규칙 평가 순서에는 "엄격한 순서"와 "작업 순서"가 있는데 엄격한 순서로 선택하겠습니다.
엄격한 순서 : 엄격에서는 평가 순서를 커스텀하는 것이 가능
작업 순서 : [패스] [드롭] [얼러트]의 순서로 룰 평가 진
그리고 생성을 진행합니다.
방화벽이 생성 완료되었으면 방화벽 정책으로 들어가 규칙을 생성합니다.
이제 룰을 생성해주어야 하는데요.
Stateless 룰과 Stateful 룰이 있습니다.
간단히 둘의 차이를 설명드리자면 stateless는 상태 비저장 방식으로 상태를 저장하지 않는 것입니다.
상태를 저장하지 않는다고 하면 쉽게 와닿지 않으실텐데요.
A PC에서 B PC로 통신을 했을 때 상태 비저장 방화벽에서는 A에서 B로 가는 통신만 허용했다고 가정해보겠습니다.
그러면 위 그림처럼 B PC에서 응답을 한 트래픽은 방화벽에 의해서 차단되고 말 것입니다.
왜냐하면 Source B에서 Destination A로 가는 트래픽은 따로 허용을 안했기 때문입니다.
이 처럼 모든 통신에 규칙을 하나 하나 다 설정해야 하는 방식을 Stateless 상태 비저장 방식이라고 합니다.
Stateful 방식은 그 반대라고 생각하시면 됩니다.
Source A에서 Destination B로 가는 통신을 방화벽은 기억하고 있다가 B가 응답을 했을 때 따로 규칙을 확인하지 않고 "아 너는 아까 A에서 B로 가는 통신에 대한 응답이구나" 하면서 통신을 허용하게 되는 것입니다.
이제 다시 AWS 방화벽 정책으로 돌아오면
AWS 방화벽 통신의 경우 먼저 상태 비저장 규칙으로 검토를 하게 됩니다.
그리고 그 데이터를 허용할지 말지 정하거나 또는 상태 저장 규칙으로 넘길지를 정합니다.
저희는 여기서 상태 비저장 규칙에 들어온 데이터를 상태 저장 방식으로 넘기도록 설정하겠습니다.
상태 비저장 기본 작업에서 편집을 클릭합니다.
상태 저장 규칙 그룹으로 전달을 선택합니다.
이제 상태 저장 규칙 그룹에서 작업을 클릭 후 상태 유지 규칙 그룹 생성을 클릭합니다.
이름을 설정하고 용량은 간단하게 10으로 설정합니다.
규칙 수인데 저희는 테스트를 위해 한 개만 생성할 것이라 1보다 크면 아무것이나 상관없습니다.
규칙을 하나 생성하겠습니다.
프로토콜 : SSH
source : 10.0.0.0/16
destination : 11.0.0.0/16
규칙을 추가합니다.
그 후 다음 다음 다음을 눌러 규칙 그룹을 생성합니다.
# VPC Route Table 설정
이제 배포해 두었던 VPC들의 Route Table을 설정하겠습니다.
총 4개의 Route Table이 필요합니다.
spoke1-RouteTable (Spoke1 VPC)
0.0.0.0/0이 있는 이유는 테스트를 확인하기 위해 일단 SSH로 붙어야 하기 때문에 넣어둔 것이지 테스트와는 관련이 없습니다.
11.0.0.0/0 으로 향하는 트래픽은 Transit Gateway로 향하게 합니다.
테스트 VM이 있는 서브넷과 Transit Gateway의 ENI가 있는 서브넷 모두 연결합니다.
spoke2-RouteTable (Spoke2 VPC)
0.0.0.0/0으로 설정하여 모든 트래픽이 Transit Gateway로 향하게 합니다.
테스트 VM이 있는 서브넷과 Transit Gateway의 ENI가 있는 서브넷 모두 연결합니다.
TGW-ENI-RouteTable (Inspection VPC)
여기가 중요한데요.
Inspection VPC의 Transit Gateway ENI로 들어오는 모든 패킷을 방화벽으로 향하게 합니다.
그래야 방화벽에서 모든 패킷을 검토 가능하기 때문입니다.
그리고 Transit Gateway ENI가 있는 서브넷에 연결합니다.
FW-RouteTable (Inspection VPC)
이제 Inspection VPC의 방화벽 서브넷으로 들어오는 패킷을 다시 Trainsit Gateway로 향하게 하는 경로를 추가합니다.
방화벽 서브넷에 추가합니다.
# 테스트
이제 테스트를 진행하겠습니다.
spoke1 ec2에서 spoke2로 ssh 통신을 해보겠습니다.
정상적으로 통신이 되는 것을 확인 가능합니다.
감사합니다.