안녕하세요 서후아빠입니다. ^_^
이번 세션은 2022년도에 서울 리전에 런칭한 Amazon GWLB에 대해서 실습을 해보겠습니다.
어플라이언스 장비의 경우 가용성, 효율성, 관리성 등 다양한 요소로 구성에 대한 고민이 많습니다. GWLB를 통한 보안장비를 공유하게 되면 많은 이점이 있는데요 이 부분에 대해서도 알아보도록 하겠습니다.
구성도
vpcA의 "ingressA-rt"는 연결할 서브넷이 없고 igwA를 "엣지 연결"됩니다 방화벽(fw)를 위해 별도의 VPC(vpcB)를 구성하지 않고pubA-sn-a1/c1에 배포하여도 됩니다. 위 구성에서 방화벽(fw)를 Public Subnet으로 구성한 이유는 방화벽(fw)접속의 편의성을 위한 것이며, 방화벽(fw)을 Private Subnet에 구성할 경우는 VPN or DX와 같이 별도의 접속할 수 있는 방안을 강구해야 합니다. 만약 별도의 VPC(ex : vpcC)에 새로운 서비스를 구성할 경우, 방화벽 추가 필요없이 GWLB Endpoint만 생성하여 vpcB에 위치한 방화벽을 이용할 수 있습니다. |
사전 작업
인프라 생성 : vpc, subnet, igw, routing table, ec2, nlb 등은 설명 생략합니다.
ELB 구성은 아래 링크를 참조하여 생성하시기 바랍니다.
2022.07.13 - [Networking] - [실습] Amazon ELB 구성하기 (ALB, NLB)-1편
1단계 : Fortinet Firewall 생성 및 접속
구독 인증 : EC2 > Instances > Launch Instances > Fortinet FW AMI 선택 및 진행 > 배포 실패 > Fortinet FW가 구독 중임을 이메일 확인
인스턴스 생성 : AWS Marketplace > Manage subscriptions > 새 인스턴스 시작(Fortinet Firewall) > 리전 선택(ap-northeast-2) > EC2를 통해 계속 실행 > EC2 생성 진행 (설명 SKIP)
Fortinet Firewall을 처음 사용하시는 분들은 구독을 한다는 메일 인증을 최초 1회 진행하셔야 합니다. 구독 인증 후에는 Fortinet Firewall을 EC2처럼 생성하여 생성하시며 됩니다. (단, 생성 시 최소 사양은 t3.small, 2022.07 기준) Fortinet Firewall의 경우 AMI를 BYOL로 선택하여 설치하는 경우만 국내 총판에서 기술지원을 받을 수 있습니다. GWLB 구성없이 In-Line 방식으로 멀티 AZ으로 구성할 경우 Active-Standby 구성만 지원되며, 8개의 Subnet이 필요합니다. |
인스턴스 ID 확인(최초 패스워드) : EC2 > Instances > Fortinet Firewall의 인스턴스 ID 확인
Fortinet Firewall 웹 접속 : https://firewall-IP > ID/PW(admin/instance ID) > 초기 비밀번호 변경
방화벽 웹 > System > FortiGuard : 라이선스 상태 Licensed 확인
클라우드용 Fortinet Firewall은 라이선스 및 IPS 패턴 업데이트 이슈로 항상 인터넷(아웃바운드) 통신이 되어야 합니다. |
2단계 : GWLB 생성
EC2 > Target groups > Create a target group
구분 | Specify group details | Target registration | ||
내용 | Choose the target type : Instance target group name : fw-tg Protocol(Version):Port : GENEVE:6081 VPC : vpcB health check protocol : HTTP(/) or HTTPS(/) Port : 80(/) or 443(/) Tag : 설정하지 말 것 |
available instances : fw-ec2-a, fw-ec2-c Ports for selected instances : 80 or 443 (Include as pending below) ※ 포트 상태 정상 확인 |
GENEVE(General Network Virtualization Encapsulation : UTP 통해 구현된 캡슐화) 프로토콜은 태그 설정 시 Target registration 실패합니다. Fortinet Firewall은 기본적으로 HTTP, HTTPS 모두 사용합니다. 때문에 Health check를 HTTP or HTTPS 선택 가능합니다. |
EC2 > Load balancers > Create a load balancer > Gateway load balancer > Create
구분 | basic configuration | network mapping | listeners and routing |
내용 | Load balancer name : gwlb | VPC : vpcB Subnet : pubB-sn-a, pubB-sn-c |
fw-tg |
EC2 > Target groups > fw-tg > Target (tab) > Health status "Healthy"
EC2 > Load balancers > gwlb > Description (tab) > 속성 편집 > Cross-Zone Load Balancing (Disabled)
Fortinet 방화벽은 Cloud에서 HA 통한 세션 싱크를 할 수 없다고 합니다. 때문에 Cross-Zone Load Balancing를 활성화 한 경우, 장애가 발생할 수 있습니다. 다만, TGW를 구성하는 경우는 다를 수 있습니다. |
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 : gwlb-ep-a1 Service category : Other endpoint services |
com.amazonaws.vpce.ap-northeast-2.vpce-svc-06e2134183abddfbc | VPC : vpcA Subnet : pubA-sn-a1 |
2 | Name : gwlb-ep-c1 Service category : Other endpoint services |
com.amazonaws.vpce.ap-northeast-2.vpce-svc-06e2134183abddfbc | VPC : vpcA Subnet : pubA-sn-c1 |
인바운드 트래픽의 경우는 꼭 Public Subnet에 위치한 GWLB Endpoint를 거쳐야 통신이 됩니다. 이번 구성에는 고려하지 않았지만, Private Subnet에 위치한 Instance가 GWLB Endpoint를 거쳐서 인터넷 통신을 하기 위해서는 최종적으로 NAT Gateway를 거쳐야 하며, 위 구성에서 추가적으로 서브넷 및 라우팅 설정이 변경이 발생합니다. (라우팅 순서 : Private instance > GWLB Endpoint > NAT Gateway > IGW) |
VPC > Endpoint services > gwlb-ep-svc > Endpoint connections > Endpoint service 선택 > Actions > Accept endpoint connection request > Accept
4단계 : VPC별 Route tables 생성
구성도 라우팅 테이블을 참조하여 생성
엣지 연결 : VPC > Route tables > ingressA-rt > Edge associations (tab) > Edit edge associations > igwA 선택 > Save
엣지 연결은 인터넷에서 들어오는 모든 패킷을 igwA에서 gwlb-ep-a1 또는 gwlb-ep-c1로 직접 전달하는 기능입니다. |
5단계 : Fortinet Firewall 설정
방화벽을 SSH로 접속하여 GENEVE 통신을 위한 가상 인터페이스 생성 : ID/PW는 방화벽 웹 접속과 동일
# probe-response 기능 추가 (2022년 10월 기준, cli에서만 설정 가능)
config system interface
edit "port1"
set allowaccess ping https ssh http fgfm probe-response
next
end
# 가상 인터페이스 생성
config system geneve
edit "awsgeneve"
# port1은 방화벽 인터페이스 번호(방화벽 웹 > 네트워크 > 인터페이스 확인)
set interface "port1"
set type ppp
# fw-ec2-a는 pubB-sn-a의 gwlb 인터페이스 ip, fw-ec2-c는 pubB-sn-c의 gwlb 인터페이스 ip 입력
set remote-ip 20.0.1.12
next
show
end
# 관리자 연결에 대한 라우팅 설정을 위해 정보(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)
방화벽 웹 > Network > Static route > Create New
구분 | Gateway Address | Interface | Administrative Distance |
관리자 접근(최우선 설정) | 관리자 PC 대역 (public or private), 20.0.1.1 | port1 | 1 |
서비스 접근 | 0.0.0.0/0.0.0.0, 0.0.0.0 | awsgeneve | 5 (priority 100) |
fw-ec2-c의 경우는 Subnet이 다르기 때문에 Gateway를 20.0.1.1이 아닌 20.0.2.1로 설정해야 합니다. 관리자 접근에 대한 라우팅을 제일 우선 설정을 하되, 서비스 접근보다 우선순위가 높아야 합니다. ("Adminitrative Distance" 수치가 낮을수록 우선순위가 높습니다.) awsgeneve의 경우 Distance는 5 (priority 100)로 고정하세요 관리자가 접근하는 IP는 아마도 Fortinet Firewall과 동일한 대역이 아니므로 Default route table(0.0.0.0/0)을 적용받게 됩니다. 그러므로 서비스 접근 라우팅 테이블을 적용받게 되므로 관리를 위해 방화벽 접속을 하고 싶어도 접근이 되지 않습니다. |
방화벽 웹 > Network > Policy route > Create New
Incoming interface | Source Addresses | Destination Addresses | Protocol | Outgoing interface | Gateway |
awsgeneve | 0.0.0.0/0 | 10.0.0.0/16 | ANY | awsgeneve | - |
awsgeneve | 10.0.0./16 | 0.0.0.0/0 | ANY | awsgeneve | - |
awsgeneve 인터페이스로 인입된 패킷은 awsgeneve 인터페이스로 응답하라는 IP기반의 PBR 설정입니다. Gateway는 빈값으로 두되, 경우에 따라서는 GWLB IP를 설정하기도 합니다. 테스트 시 방화벽으로 패킷 인입은 보이는데, 방화벽에서 응답이 없다면 100% Static route & Policy route 문제입니다. |
방화벽 웹 > Dashboard > Network > Routing 더블 클릭 : 아래처럼 출력되는지 확인
Network | Gateway IP | Interfaces | Distance | Type |
0.0.0.0/0 | 20.0.1.1 | port1 | 5 | Static |
0.0.0.0/0 | 0.0.0.0 | awsgeneve | 5 | Static |
20.0.1.0/24 | 0.0.0.0 | port1 | 0 | Connected |
관리자 대역 | 20.0.1.1 | port1 | 1 | Static |
fw-2의 경우는 Subnet이 다르기 때문에 Gateway IP가 20.0.1.1이 아닌 20.0.2.1로 출력됩니다. 첫번째, 두번째 라인의 Distance값이 5로 동일하게 출력되어야지만 방화벽이 인터넷 아웃바운드 통신이 되고, GENEVE 통신도 정상적으로 동작합니다. 네번째 라인의 Distance값은 첫번째, 두번째 라인의 Distance 값보다 작아야 우선순위가 높아서 방화벽 접근이 됩니다. |
방화벽 웹 > 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 |
HTTP, HTTPS |
ACCEPT | disabled |
Allow_Outbound | awsgeneve | awsgeneve | 10.0.3.0/24 10.0.4.0/24 |
all | ALL | ACCEPT | disabled |
Allow_ALL | awsgeneve | awsgeneve | all | all | ALL | ACCEPT | disabled |
GWLB-HC | port1 | port1 | GWLB 인터페이스 IP 2개 | 20.0.1.0/24 20.0.2.0/24 |
HTTP, HTTPS UDP 6081 |
ACCEPT | disabled |
방화벽에 어느 정도 아시면 Allow_Inbound/All_Outbond처럼 세분화 하셔서 정책을 설정하시고, 방화벽에 대해서 잘 모르시면 Allow_ALL로 정책을 설정하시기 바랍니다. 통신 상태(or 관리)를 확인하기 위한 로깅 설정 : Log Allowed Traffic을 All Sessions or Security Events |
방화벽을 SSH로 접속하여 GWLB 동작 확인
# IP 예시 : fw-ec2-a (20.0.1.13), gwlb (20.0.1.12, 20.0.2.12)
# Port1에서 작동하는 GENEVE 프로토콜 확인
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
# Port1에서 확인되는 GWLB Health check
fw-ec2-a # diagnose sniffer packet port1 “port 80”
Using Original Sniffing Mode
Interfaces=[port1]
Filters=[port 80]
1.996675 20.0.1.12.57670 -> 20.0.1.13.80: syn 4234483336
...
1.512972 20.0.2.12.35073 -> 20.0.1.13.80: syn 4001990525
6단계 : Fortinet Firewall을 통한 패킷 통제 테스트
브라우져에서 nlbA으로 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 제거
브라우져에서 nlbA으로 Web Service 접근 : Fail (blocked by firewall policy)
- Allow_ALL 정책만 설정한 경우는 다음 테스트를 위해 Service에서 ALL 추가
pubA-ec2-a or pubA-ec2-c에서 "ping 8.8.8.8" 요청 시도 : Success
방화벽 정책 수정 : Policy & Objects > Firewall Policy > Allow_Outbound > Edit > Service에서 ALL 제거
- Allow_ALL 정책만 설정한 경우는 Service에서 ALL 제거
pubA-ec2-a or pubA-ec2-c에서 "ping 8.8.8.8" 요청 시도 : Fail (blocked by firewall policy)
기타 : Auto Scaling 설정 (구성은 가능하나, 국내 총판에서 라이선스 구매 불가능하므로 기술지원을 받을 수 없음)
EC2 > Instances > fw-ec2-a (or fw-ec2-c) 선택 > Actions > Image and templates > Create image > Image name(fw-ec2-a-ami (or fw-ec2-c-ami)
pubB-sn-a과 pubB-sn-c에 설치된 방화벽에 대해서 각각 Auto Scaling 설정을 해야 합니다. 왜냐하면 방화벽에 Static하게 설정된 부분이 상이하기 때문입니다. AMI가 생성되면서 자동으로 스냅샷도 생성되며, AMI 생성 후에는 fw-ec2-a or fw-ec2-c가 불필요하므로 삭제 가능합니다. 구축 이후 방화벽 정책/설정이 변경되는 경우는 아래 순서대로 진행해야 합니다. 1) 현재 동작중인 EC2(FW 2대)에 대해서 AMI를 각각 생성 2) 신규 AMI를 이용하여 신규 “Launch Configurations” 생성 3) 신규 Launch Configurations를 이용하여 신규 “Auto Scaling Groups” 생성 4) 기존 “Auto Scaling Groups”, “Launch Configurations”, “AMI” 삭제 |
EC2 > Launch Configurations > Create launch configuration
Launch configuration name | Amazon machine image (AMI) | Instance type | Security groups | Key pair (login) |
Name : fw-ec2-a-lc | fw-ec2-a-ami | t3.small | Assign a security group : 기존 SG 선택 | Key pair options : Choose an existing key pair Existing key pair : 기존 key 선택 I acknowledge that …my instance. : Enable |
fw-ec2-c-lc도 fw-ec2-c-ami를 선택하여 위와 같은 설정으로 생성합니다. Additional configuration, Storage (volumes) 등 추가 옵션 설정도 가능합니다. Security groups은 추후 인스턴스가 생성될 VPC의 것으로 선택해야 하며, UDP 6081과 TCP 80(or 443)를 허용되어야 합니다. |
EC2 > Instances > Auto Scaling Groups > Create Auto Scaling group
Choose launch template or configuration | Choose instance launch options | Configure advanced options |
Name : fw-ec2-a-asg Launch configuration : fw-ec2-a-lc |
VPC : vpcB Availability Zones and subnets : pubB-sn-a |
Load balancing : Attach to an existing load balancer Attach to an existing load balancer : Choose from your load balancer target groups Existing load balancer target groups : fw-tg Health check type : EC2 (& ELB) Health check grace period : 300 Sec Monitoring : Enable (with CloudWatch) Default instance warmup : Enable, 60 Sec |
Configure group size and scaling policies | Add notifications |
Desired capacity : 1 Minimum capacity : 1 Maximum capacity : 2 Scaling policies : Target tracking scaling policy Scaling policy name : Target Tracking Policy Metric type : Average CPU utilization Target value : 50 Instances need : 60 seconds warm up before including in metric |
Auto Scaling 동작 시 SNS 알림 설정 |
fw-ec2-c-asg도 fw-ec2-c-lc를 선택하여 pubB-sn-c에 배포합니다. Metric type : Average CPU utilization, Average network in, Average network out, Application Load Balancer request count per target |
EC2 > Instances > Auto Scaling Groups > fw-ec2-a-asg or fw-ec2-c-asg 선택 > Automatic scaling (tab) > Scheduled actions > Create scheduled action
Name | Desired / Min / Max | Recurrence | Time zone | Specific start time | End by (옵션) |
fw-ec2-a-asg-sa | 10 / 10 / 20 | Every day | Asia/Seoul | yyyy/mm/dd hh:mm | yyyy/mm/dd hh:mm |
스케줄 설정이 필요한 경우 위 경로에서 위 예시처럼 설정하면 됩니다. Recurrence : Cron, Every week / day / 1h / 30m / 5m, Once 주말과 명절 등을 고려하여 여러 개의 Schedule을 생성하여 보다 효율적인 운영 가능합니다. 등록된 Schedule이 동작하면 start time에 Instance가 배포되고, Schedule 목록에서 삭제됩니다. |
기타 : Fortinet Firewall 상세 패킷 캡쳐 명령어
# 인터페이스 미지정(any), 방향성 출력 (4 0 l)
fw-ec2-a # diagnose sniffer packet any "host 218.236.84.11 and port 80" 4 0 l
2022-10-20 19:48:39.604301 awsgeneve in 218.236.84.11.42277 -> 10.0.3.41.80: syn 1561837565
# ICMP 캡쳐
fw-ec2-a # diagnose sniffer packet any "host [IP] and icmp" 4 0 l
2022-10-20 20:38:45.153924 awsgeneve in 218.236.84.11 -> 10.0.0.41: icmp: echo request
# 방화벽에서 Ping 테스트
fw-ec2-a # execute ping X.X.X.X
현재 구성의 장점 및 제한 사항
방화벽 한 세트를 구성하고, GWLB를 통해 여러 서비스에서 공유 가능
방화벽을 통해 모든 서비스를 제어할 수 있어 통합 관리 및 실시간 로그 확인 가능
※ AWS 네이티브 서비스는 실시간 로그 확인이 어렵다.
라우팅 개념이 없으면 구성이 어려움
여러 개의 VPC(vpcA, vpcC, vpcD, ...)가 존재하고 VPC간 통신도 GWLB로 통제하고 싶은 경우 Trasit gateway 필요
참고 URL
'Networking' 카테고리의 다른 글
[이론] Amazon GWLB 구성 기본 개념 (1) | 2022.07.05 |
---|---|
[실습] Amazon GWLB를 사용하여 Fortinet 방화벽 구성하기 (TGW, Split)-2편 (0) | 2022.07.03 |
[이론] Amazon ELB 기본 개념 (0) | 2022.07.02 |
[실습] Amazon VPC 구성요소 생성하기 (0) | 2022.07.02 |
[이론] Amazon VPC 구성요소 기본 개념 (0) | 2022.07.01 |