[실습] Amazon GWLB를 사용하여 Fortinet 방화벽 구성하기 (TGW, Split)-2편

안녕하세요 서후아빠입니다. ^_^

이번 세션은 TGW를 구성하여 VPC간에도 방화벽(fw) 통한 패킷 통제되는 실습을 해보겠습니다.

혹자는 이렇게까지 방화벽을 통과시킬 필요가 있느냐고 하시는 분도 있었지만, Onpremise (or Management VPC)에서 Production VPC 접근에 대해서 통제 및 Logging 역할로서 의미가 있지 않을까 생각합니다. 

---

구성도

vpcA의 "ingressA-rt"는 연결할 서브넷이 없고 igwA를 "엣지 연결"됩니다 구성 컨셉은 아래와 같습니다.    - vpcA, vpcC : 서비스 영역으로 각각 인터넷을 통해서 서비스 제공   - vpcB : 보안 영역으로 인터넷~vpcA(or vpcC) 구간, vpcA~vpcC 구간에 대하여 방화벽으로 패킷을 통제 vpcA~vpcC 통신을 하는 경우    ① pubA-ec2-a이 요청한 패킷은 라우팅 테이블(pubA-rt-a2) 참조하여 tgw-vpcA를 통해 tgw로 전송된다.   ② tgw로 요청한 패킷은 라우팅 테이블(ingress-rt) 참조하여 무조건 tgw-vpcB로 전송된다.   ③ tgw-vpcB에서 요청한 패킷은 라우팅 테이블(priB-rt-a2) 참조하여 무조건 gwlbB-ep-a1로 전송된다.   ④ gwlbB-ep-a1에서 요청한 패킷은 방화벽(fw-ec2-a) 정책을 통과하고 회신된다.   ⑤ gwlbB-ep-a1에서 회신된 패킷은 라우팅 테이블(priB-rt) 참조하여 무조건 tgw-vpcB를 통해 tgw로 전송된다.   ⑥ tgw로 요청한 패킷은 라우팅 테이블(egress-rt) 참조하여 tgw-vpcC로 전송된다.   ⑦ tgw-vpcC에서 요청한 패킷은 최종 목적지인 vpcC에 도착한다.

사전 작업

인프라 생성 : vpc, subnet, igw, routing table, ec2, elb 등은 설명 생략합니다.

2022.07.02 - [Networking] - [실습] Amazon VPC 구성요소 생성하기

[실습] Amazon VPC 구성요소 생성하기

1~2단계 : 설명 SKIP

2022.07.03 - [Networking] - [실습] Amazon GWLB를 사용하여 Fortinet 방화벽 구성하기 (PrivateLink, Auto Scaling)-1편

[실습] Amazon GWLB를 사용하여 Fortinet 방화벽 구성하기 (PrivateLink, Auto Scaling)-1편

1~2단계는 위 링크의 1~2단계와 동일하고, 2단계 마지막 부분에서 아래 내용(Cross-Zone Load Balancing)만 다릅니다.

EC2 > Load balancers > gwlb > Description (tab) > 속성 편집 > Cross-Zone Load Balancing (Enable)

3단계 : 엔드포인트 서비스 생성, 엔드포인트 생성

VPC >  Endpoint services > Create endpoint service

구분	Name	Load balacer type	Available load balancers
내용	gwlb-ep-svc	gateway	gwlb

Acceptance required : 엔드포인트 생성시 엔드포인트와 연결되는 엔드포인트 서비스에서 수락을 해주어야 엔드포인트가 활성화되게 하는 기능으로 귀찮으면 체크 해제하면 자동 수락됩니다.

VPC > Endpoint services > gwlb-ep-svc > Details (tab) > Service name 확인 (예: com.amazonaws.vpce.ap-northeast-2.vpce-svc-06e2134183abddfbc )
VPC > Endpoints > Create endpoint

구분	Endpoint settings	Service settings	VPC
1	Name : gwlbA-ep-a1 Service category : Other endpoint services	com.amazonaws.vpce.ap-northeast-2.vpce-svc-06e2134183abddfbc	VPC :  vpcA Subnet :  pubA-sn-a
2	Name : gwlbA-ep-c1 Service category : Other endpoint services	com.amazonaws.vpce.ap-northeast-2.vpce-svc-06e2134183abddfbc	VPC :  vpcA Subnet :  pubA-sn-c
3	Name : gwlbB-ep-a1 Service category : Other endpoint services	com.amazonaws.vpce.ap-northeast-2.vpce-svc-06e2134183abddfbc	VPC :  vpcB Subnet :  priB-sn-a
4	Name : gwlbB-ep-c1 Service category : Other endpoint services	com.amazonaws.vpce.ap-northeast-2.vpce-svc-06e2134183abddfbc	VPC :  vpcB Subnet :  priB-sn-c
5	Name : gwlbC-ep-a1 Service category : Other endpoint services	com.amazonaws.vpce.ap-northeast-2.vpce-svc-06e2134183abddfbc	VPC :  vpcC Subnet :  pubC-sn-a
6	Name : gwlbC-ep-c1 Service category : Other endpoint services	com.amazonaws.vpce.ap-northeast-2.vpce-svc-06e2134183abddfbc	VPC :  vpcC Subnet :  pupC-sn-c

VPC > Endpoint services > gwlb-ep-svc > Endpoint connections > Endpoint service 선택 > Actions > Accept endpoint connection request > Accept 

4단계 : TGW 생성

VPC > Transit gateways > Create transit gateway

구분	Name	ASN	Configure the transit gateway (체크 항목)
내용	tgw	Auto	Check (DNS & VPN ECMP supportInfo) Uncheck (Default route table association & propagationInfo) Check (Auto accept shared attachments)

Default route table association & propagationInfo은 6단계에서 수동으로 설정하기 때문에 꼭 Uncheck하시기 바랍니다.

5단계 : TGW에 VPC 연결

VPC > Transit gateway attachments > Create transit gateway attachment

구분	Name	Transit gateway ID	Attachment type	VPC attachment
1	tgw-vpcA	tgw	VPC	DNS support : check VPD ID : vpcA Subnet IDs : pubA-sn-a2, pubA-sn-c2
2	tgw-vpcB	tgw	VPC	DNS support : check VPD ID : vpcB Subnet IDs : priB-sn-a2, priB-sn-c2
3	tgw-vpcC	tgw	VPC	DNS support : check VPD ID : vpcC Subnet IDs : pubC-sn-a2, pubC-sn-c2

지정되는 Subnet IDs에 tgw-eni(인터페이스)가 생성됩니다.

6단계 : TGW Route tables 생성

VPC > Transit gateway route tables > Create transit gateway route table

구분	Name			Transit gateway ID
1	ingress-rt			tgw
2	egress-rt			tgw

VPC > Transit gateway route tables > ingress-rt 선택 > Associations (tab) > Create association > tgw-vpcA, tgw-vpcC

VPC > Transit gateway route tables > ingress-rt 선택 > Routes (tab) > Create route

구분	CIDR	Type	Choose attachment
1	0.0.0.0/0	Active	tgw-vpcB

VPC > Transit gateway route tables > ingress-rt 선택 > Routes (tab) : Route state “활성“ 확인

VPC > Transit gateway route tables > egress-rt 선택 > Associations (tab) > Create association > tgw-vpcB

VPC > Transit gateway route tables > egress-rt 선택 > Routes (tab) > Create route

구분	CIDR	Type	Choose attachment
1	10.0.0.0/16	Active	tgw-vpcA
2	30.0.0.0/16	Active	tgw-vpcC

VPC > Transit gateway route tables > ingress-rt 선택 > Routes (tab) : Route state “활성“ 확인

7단계 : TGW device mode 활성화 (중요)

AWS CLI로 접속하여 아래 명령어 실행

# 어플라이언스 장비가 연결된 Transit Gateway Attachment ID를 지정(예 : tgw-vpcB)
aws ec2 modify-transit-gateway-vpc-attachment --transit-gateway-attachment-id tgw-vpcB --options ApplianceModeSupport=enable

이 설정을 하지 않는 경우 비대칭 라우팅(가용영역이 2개 이상, 가용영역 A의 어플라이언스 장비로 요청이 오고, 가용영역 B의 어플라이언스 장비가 응답) 발생 시 장애가 발생합니다.

8단계 : VPC별 Route tables 생성 

구성도 라우팅 테이블을 참조하여 생성
엣지 연결 : VPC > Route tables > ingress-rt > Edge associations (tab) > Edit edge associations > vpcA는 igwA 선택, vpcC는 igwC 선택 > Save

엣지 연결   - vpcA의 경우 : 인터넷에서 들어오는 모든 패킷을 igwA에서 gwlbA-ep-a1 또는 gwlbA-ep-c1로 직접 전달하는 기능   - vpcC의 경우 : 인터넷에서 들어오는 모든 패킷을 igwC에서 gwlbC-ep-a1 또는 gwlbC-ep-c1로 직접 전달하는 기능

9단계 : Fortinet Firewall 설정

방화벽을 SSH로 접속하여 GENEVE 통신을 위한 가상 인터페이스 생성 : ID/PW는 방화벽 웹 접속과 동일

# 가상 인터페이스 생성
config system geneve
edit "awsgeneve"

# port1은 방화벽 인터페이스 번호(방화벽 웹 > 네트워크 > 인터페이스 확인)
set interface "port1"
set type ppp

# fw-ec2-a는 priB-sn-a1의 gwlb 인터페이스 ip, fw-ec2-c는 priB-sn-c1의 gwlb 인터페이스 ip 입력
set remote-ip  20.0.1.12
next
end

# 설정 값 확인
show

# 관리자 연결에 대한 라우팅 설정을 위해 정보(20.0.1.1) 확인
get router info routing-table details
S* 0.0.0.0/0 [5/0] via 20.0.1.1, port1, [1/0 ]
C  20.0.1.0/24 is directly connected, port1

GWLB 삭제 후 다시 생성하면 GWLB 인터페이스 IP가 변경되므로 "set remote-ip" 수정이 필요합니다. 수정 전에 방화벽 정책과 라우팅에서 awsgeneve 인터페이스 제거하시기 바랍니다.  물론, "set remote-ip" 수정 후에는 다시 방화벽 정책과 라우팅에서 awsgeneve 인터페이스 설정이 필요합니다.

방화벽 웹 액세스 > Interface : Port1을 마우스 왼쪽 버튼으로 클릭하여 awsgeneve 생성 확인 (Tunnel Interface : Disabled)

Static route > Create New

구분	Gateway Address	Interface	Administrative Distance
관리자 접근(최우선 설정)	관리자 PC 대역 (public or private), 20.0.1.1	port1	3
서비스 접근	0.0.0.0/0.0.0.0, 0.0.0.0	awsgeneve	4

관리자 접근에 대한 라우팅을 제일 우선 설정을 하되, 서비스 접근보다 우선순위가 높아야 합니다. ("Adminitrative Distance" 수치가 낮을수록 우선순위가 높습니다.) 관리자가 접근하는 IP는 아마도 Fortinet Firewall과 동일한 대역이 아니므로 Default route table(0.0.0.0/0)을 적용받게 됩니다.  그러므로 서비스 접근 라우팅 테이블을 적용받게 되므로 관리를 위해 방화벽 접속을 하고 싶어도 접근이 되지 않습니다. 또한, "get router info rouing-table details"결과값에서 "0.0.0.0/0"의 라인값이 fw-ec2-a와 fw-ec2-c가 다르기 때문에 구분하여서 입력해야 합니다.

방화벽을 SSH로 접속하여 라우팅 설정 (관리자 대역 예시 : 40.0.1.0/24) 

# 기본 라우팅 변경, 관리자 대역은 추가 확인
get router info routing-table details
S* 0.0.0.0/0 [4/0] is directly connected, awsgeneve, [1/0]  
C  20.0.1.0/24 is directly connected, port1
S  40.0.1.0/24 [3/0] via 20.0.1.1, port1, [1/0]

방화벽 웹 접근 > Policy & Objects > Firewall Policy

Name	Incoming	Outgoing	Source	Destination	Service	Action	NAT
Allow_Inbound	awsgeneve	awsgeneve	all	10.0.3.0/24 10.0.4.0/24 30.0.3.0/24 30.0.4.0/24 (or all)	HTTP, HTTPS	ACCEPT	disabled
Allow_Outbound	awsgeneve	awsgeneve	10.0.3.0/24 10.0.4.0/24 30.0.3.0/24 30.0.4.0/24 (or all)	all	ALL	ACCEPT	disabled
Allow_ALL	awsgeneve	awsgeneve	all	all	ALL	ACCEPT	disabled

방화벽에 어느 정도 아시면  Allow_Inbound/All_Outbond처럼 세분화 하셔서 정책을 설정하시고, 방화벽에 대해서 잘 모르시면 Allow_ALL로 정책을 설정하시기 바랍니다.

방화벽을 SSH로 접속하여 Port1에서 작동하는 GENEVE 프로토콜 확인

※ IP 예시 : fw-ec2-a (20.0.1.13), gwlb (20.0.1.12)
fw-ec2-a # diagnose sniffer packet port1 “port 6081”
Using Original Sniffing Mode
Interfaces=[port1]
Filters=[port 6081]
0.4294921751 20.0.1.12.6081 -> 20.0.1.13.6081: udp 68

10단계 : Fortinet Firewall을 통한 패킷 통제 테스트

브라우져에서 pubA-ec2-a or pubA-ec2-c(또는 pubC-ec2-a or pubC-ec2-c)으로 Web Service 접근 : Success

방화벽을 SSH로 접속하여 Web Service 접근에 대한 패킷 확인

fw-ec2-a # diagnose sniffer packet awsgeneve “port 80”
Using Original Sniffing Mode
Interfaces=[awsgeneve]
Filters=[port 80]
1047.693800 106.6.10.4.22656 -> 10.0.3.3.80: psh 4041148978 ack 1533777421
1048.4294861919 10.0.3.3.22656 -> 106.6.10.4.80: psh 4041148978 ack 1533777421

방화벽 정책 수정 : Policy & Objects > Firewall Policy > Allow_Inbound > Edit > Service에서 HTTP and HTTPS 제거

  - Allow_ALL 정책만 설정한 경우는 Service에서 ALL 제거

브라우져에서 pubA-ec2-a or pubA-ec2-c(또는 pubC-ec2-a or pubC-ec2-c)으로 Web Service 접근 : Fail (blocked by firewall policy) 

  - Allow_ALL 정책만 설정한 경우는 다음 테스트를 위해 Service에서 ALL 추가

pubA-ec2-a or pubA-ec2-c(또는 pubC-ec2-a or pubC-ec2-c)에서 "ping 8.8.8.8" 요청 시도 : Success

pubA-ec2-a or pubA-ec2-c에서 "ping x.x.x.x" (x.x.x.x : pubC-ec2-a or pubC-ec2-c 사설IP) 요청 시도 : Success

방화벽 정책 수정 : Policy & Objects > Firewall Policy > Allow_Outbound > Edit > Service에서 ALL 제거

  - Allow_ALL 정책만 설정한 경우는 Service에서 ALL 제거

pubA-ec2-a or pubA-ec2-c(또는 pubC-ec2-a or pubC-ec2-c)에서 "ping 8.8.8.8" 요청 시도 : Fail (blocked by firewall policy) 

pubA-ec2-a or pubA-ec2-c에서 "ping x.x.x.x" (x.x.x.x : pubC-ec2-a or pubC-ec2-c 사설IP) 요청 시도 : Fail (blocked by firewall policy) 

현재 구성의 장점 및 제한 사항

방화벽 한 세트를 구성하고, GWLB를 통해 여러 서비스에서 공유 가능
방화벽을 통해 모든 서비스를 제어할 수 있어 통합 관리 및 실시간 로그 확인 가능
  ※ AWS 네이티브 서비스는 실시간 로그 확인이 어렵다.
라우팅 개념이 없으면 구성이 어려움

서비스 통신뿐만 아니라 VPC 통신도 통제 가능