06QoS 튜토리얼QoS Tutorial
이 장은 예제 하나를 처음부터 끝까지 따라가며 QoS 정책을 직접 만들어 보는 실습 입니다. 시스템 구성요소를 설치하고, 새 QoS 정책을 만들고, 정책 종류를 고르고, 네트워크 객체와 서비스를 구성한 뒤, 규칙을 짜고, 마지막으로 게이트웨이에 정책을 설치하는 전 과정을 한 흐름으로 보여 줍니다. 이 튜토리얼을 제대로 활용하려면 다음 Check Point 제품과 개념에 어느 정도 익숙한 것이 좋습니다.
- Security Gateway 와 관리 서버(management server)
- 보안 정책(Security Policy)과 Rule Base
- SmartConsole 과 SmartDashboard
- Firewall 과 관련 Software Blade
이 튜토리얼의 배포 시나리오
그림 속 번호가 가리키는 구성요소는 다음과 같습니다.
| 번호 | 구성요소 |
|---|---|
| 1 | Oxford — Security Management Server |
| 2 | Cambridge — SmartConsole 클라이언트 |
| 3 | LAN(로컬 네트워크) — Engineering·Marketing 부서 |
| 4 | London — QoS가 켜진 Security Gateway |
| 4a | 인터페이스 eth2 — 199.199.199.32 |
| 4b | 인터페이스 eth1 — 199.32.43.32 |
| 4c | 인터페이스 eth0 — 199.32.32.32 |
| 5 | Web·FTP 서버가 있는 DMZ |
| 6 | 인터넷 |
시나리오는 London·Oxford·Cambridge 세 곳에 사무실을 둔 조직입니다. QoS Security Gateway는 London 에 있고 인터페이스가 셋인데 그중 하나가 인터넷에 연결됩니다. Security Management Server는 Oxford, SmartConsole은 Cambridge 에 있습니다. 로컬 네트워크에는 Marketing 부서와 Engineering 부서가 들어 있습니다.
튜토리얼의 전체 흐름
이 튜토리얼은 QoS 작업을 단순하게 압축해 보여 주는 연습으로, 다음 일곱 단계를 차례로 다룹니다.
- 시스템 구성요소를 설치하고 구성 합니다.
- SmartConsole로 새 QoS 정책을 생성 합니다.
- 다음 두 가지 QoS 정책 종류 중 하나를 선택 합니다.
- Express — 기본적인 QoS 정책을 빠르게 만듭니다.
- Recommended — QoS 기능 전체를 쓰는 고급 정책을 만듭니다.
- QoS 규칙이 사용할 네트워크 객체를 구성 합니다.
- QoS 규칙에 쓸 특수 서비스를 구성 합니다.
- QoS 정책 규칙을 생성 합니다.
- Security Gateway에 정책을 설치 합니다.
시스템 구성요소 설치
먼저 시스템 구성요소를 설치하고 구성하는 단계입니다. 순서대로 다음을 진행합니다.
- London Security Gateway에서 QoS·Firewall 등 필요한 Software Blade를 켭 니다.
- Oxford 서버 플랫폼에 Security Management Server를 설치합니다.
- Cambridge PC에 SmartConsole을 설치합니다.
- SmartConsole에서 Cambridge를 신뢰 클라이언트(trusted client)로 지정 합니다.
- SmartConsole에서 QoS 정책을 관리할 관리자(administrator)를 정의 합니다.
- Oxford의 Security Management Server와 London의 QoS Security Gateway 사이에 SIC 신뢰가 맺어졌는지 확인 합니다.
SmartConsole 시작하기
이 단계에서는 SmartDashboard를 열고 QoS 탭 에 접근하는 법을 익힙니다. 새 QoS 정책을 만들면 SmartDashboard가 열리고, 거기서 QoS 규칙을 짜게 됩니다.
새 QoS 정책 만들기
새 QoS 정책을 만드는 절차는 다음과 같습니다.
- 게이트웨이에서 QoS 블레이드가 켜져 있는지 확인 합니다.
- SmartConsole의 File 메뉴에서 Manage Policies and Layers 를 선택합니다.
- New 를 누릅니다.
- Policy 창에서 정책 이름(Policy name)을 입력합니다. 이 이름에는 다음 제약이 있습니다.
- 예약어(reserved word)나 공백을 넣으면 안 됩니다.
- 숫자로 시작하면 안 됩니다.
- 다음 문자를 하나라도 포함하면 안 됩니다.
% # ' & * ! @ ? < > / \ : .
- 다음 접미사로 끝나면 안 됩니다 —
.pf,.W - QoS 를 선택한 다음 QoS 정책 종류를 고릅니다.
- Express — 기본적인 QoS 정책을 빠르게 만듭니다.
- Recommended(기본값) — QoS 기능 전체를 쓰는 고급 정책을 만듭니다.
- OK 를 누릅니다.
OK 를 누르면 시스템이 새 정책을 저장하고 SmartDashboard가 자동으로 열립니다. 바로 여기서 규칙을 정의하기 시작할 수 있습니다.
QoS 정책 설계하기
좋은 QoS 정책을 짜려면 먼저 네트워크가 실제로 어떻게 쓰이는지 파악 해야 합니다. 어떤 종류의 트래픽이 흐르는지 식별해 우선순위를 매기고, 사용자가 누구이며 무엇을 필요로 하는지 확인합니다. 이 예제에서 세운 방침은 다음 두 가지입니다.
- HTTP 트래픽에 RealAudio보다 많은 대역폭 을 배정합니다.
- Marketing 부서에 Engineering 부서보다 많은 대역폭 을 배정합니다.
Security Gateway 구성하기
게이트웨이 구성에서는 다음 네트워크 객체를 정의합니다.
- London — QoS가 켜진 Security Gateway
- Marketing·Engineering 부서의 서브넷(sub-network)
London 게이트웨이 정의
London Security Gateway 객체를 만드는 절차입니다.
- SmartConsole에서 Gateways & Servers 를 클릭합니다.
- New > Gateway > Classic Mode 를 클릭합니다.
- General Properties 창에서 다음 파라미터를 구성합니다.
| 필드 | 값 | 비고 |
|---|---|---|
| Name | London | 네트워크에서 이 객체를 식별하는 이름으로, hostname 명령의 응답값과 같습니다. |
| Platform | 어플라이언스 종류 또는 Open Server 선택 | R82를 지원하는 플랫폼 이어야 합니다. |
| SIC | Communication 클릭 | Security Gateway와 관리 서버 사이에 보안 통신 채널 을 맺습니다. |
| Version | R82 | |
| OS | Gaia | |
| IP Address | 192.32.32.32 | DNS에서 호스트 이름에 연결된 인터페이스 주소로, Get Address 를 눌러 가져옵니다. 게이트웨이의 IP는 항상 외부(external) 인터페이스 주소 를 씁니다. |
그리고 Network Security 탭에서 Firewall 과 QoS 를 켭니다.
게이트웨이에 인터페이스 정의
이 단계에서는 각 인터페이스와 그 QoS 속성을 구성합니다. 인터페이스 속성을 설정하는 절차는 다음과 같습니다.
- 탐색 트리에서 Network Management 를 클릭합니다.
- 도구 모음에서 Get Interfaces 를 클릭합니다. 그러면 Network Management 창에 인터페이스가 나타납니다.
- 각 인터페이스를 더블클릭해 Interface > General 창에서 파라미터를 구성합니다.
eth0
| 필드 | 값 | 비고 |
|---|---|---|
| Net Address | 192.32.32.32 | |
| Net Mask | 255.255.255.0 | |
| Topology Settings | (Modify 클릭) | |
| Internet | External | 이 인터페이스는 인터넷에 연결됩니다. |
| Anti-Spoofing | 인터페이스 토폴로지 기반 Anti-Spoofing 수행 | 들어오는 패킷마다 출발지 IP가 유효한지 검사합니다. |
| Spoof Tracking | Log | Anti-Spoofing 이벤트를 로그로 남깁니다. |
eth1
| 필드 | 값 | 비고 |
|---|---|---|
| Net Address | 192.32.42.32 | |
| Net Mask | 255.255.255.0 | |
| Topology Settings | (Modify 클릭) | |
| Internet | External | 이 인터페이스는 인터넷에 연결됩니다. |
| Anti-Spoofing | 인터페이스 토폴로지 기반 Anti-Spoofing 수행 | 들어오는 패킷마다 출발지 IP가 유효한지 검사합니다. |
| Spoof Tracking | Log | Anti-Spoofing 이벤트를 로그로 남깁니다. |
eth2
| 필드 | 값 | 비고 |
|---|---|---|
| Net Address | 192.199.199.32 | |
| Net Mask | 255.255.255.0 | |
| Topology Settings | (Modify 클릭) | |
| Internet | External | 이 인터페이스는 인터넷에 연결됩니다. |
| Anti-Spoofing | 인터페이스 토폴로지 기반 Anti-Spoofing 수행 | 들어오는 패킷마다 출발지 IP가 유효한지 검사합니다. |
| Spoof Tracking | Log | Anti-Spoofing 이벤트를 로그로 남깁니다. |
인터페이스의 QoS 속성 설정
각 인터페이스의 QoS 속성을 설정하는 절차입니다.
- Interface 창에서 QoS 탭 을 클릭합니다.
- Inbound Active 와 Outbound Active 를 켭니다.
- Inbound Active·Outbound Active 전송률을 모두 192000 — T1(1.5 Mbps) 로 설정합니다.
서비스 정의
이 튜토리얼에 필요한 QoS 정책은 새로 전용(proprietary) 서비스를 정의할 필요가 없습니다. 여기서 쓰는 HTTP와 RealAudio는 QoS에 이미 정의 되어 있기 때문입니다.
규칙 생성과 구성
네트워크 객체와 서비스를 정의했다면, 다음 단계는 QoS 정책 규칙을 만드는 것입니다. 이 튜토리얼에서는 간단한 QoS 규칙 두 개를 만들어 봅니다. 새 QoS 정책에는 항상 Default Rule이 포함 된다는 점을 기억하세요(기본 규칙에 관한 자세한 내용은 기본 정책 관리 참고).
새 정책을 만드는 절차를 다시 정리하면 다음과 같습니다.
- SmartConsole의 File 메뉴에서 New 를 선택하면 New Policy 창이 열립니다.
- New policy Package Name 필드에 이름을 입력합니다.
- QoS 를 선택합니다.
- QoS policy (recommended) 를 선택합니다.
- OK 를 누릅니다.
그러면 새 정책이 Default Rule과 함께 생성되어 QoS 탭 에 표시됩니다.
새 규칙 만들기
새 QoS 정책을 만들면 시스템이 기본 규칙(Default Rule)을 자동으로 추가하며, 이 규칙은 반드시 정책의 맨 마지막 에 있어야 합니다. 그러니 새로 만드는 규칙은 모두 기본 규칙 위 에 넣어야 합니다.
여기서는 Web Rule 과 RealAudio Rule 두 규칙을 만듭니다.
- SmartDashboard > QoS 탭 에서 기본 규칙을 선택합니다.
- Before current rule 아이콘을 클릭합니다.
- Rule Name 창에 Web Rule 을 입력하고 OK 를 누릅니다.
같은 절차를 RealAudio Rule 에 대해서도 반복합니다.
규칙 속성과 기본값 바꾸기
새 규칙에는 관리자가 정해 둔 기본값이 들어 있습니다. 시스템은 Global Properties > QoS 에 정의된 기본 파라미터를 새 규칙에 자동으로 할당합니다. 이제 이 규칙들을 아래 표의 값으로 바꿉니다.
| Rule Name | Source | Destination | Service | Action |
|---|---|---|---|---|
| Web Rule | Any | Any | HTTP | Weight 35 |
| RealAudio Rule | Any | Any | RealAudio | Weight 5 |
| Default | Any | Any | Any | Weight 10 |
규칙의 속성을 바꾸는 절차는 다음과 같습니다.
- QoS 탭에서 Web Rule 의 Service 필드를 우클릭한 뒤 Add Objects 를 선택하고, 목록에서 HTTP 를 고릅니다.
- Action 필드를 더블클릭해 Rule Weight 속성을 35 로 바꿉니다(자세한 내용은 QoS 전역 속성 변경 설명 참고).
같은 절차를 RealAudio 규칙과 Default 규칙에도 반복합니다.
서비스로 트래픽 분류하기
보통 완성된 Rule Base에서는 DNS·ARP 같은 "배경(background)" 서비스를 일일이 규칙으로 정의하지 않 습니다. 이런 배경 서비스는 Default 규칙이 처리 합니다.
Rule Base의 구조는 창 왼쪽에 트리 형태 로 표시되며, 기본 규칙은 항상 맨 아래 에 있습니다(Rule Base 창에 관한 설명은 기본 정책 관리 참고).
연결은 자기에게 적용되는 규칙에 매겨진 가중치(우선순위)에 따라 대역폭 을 받습니다. 네 개의 연결이 동시에 활성일 때 어떻게 되는지 살펴봅니다. 대역폭 배분은 끊임없이 바뀐다 는 점에 유의하세요.
서비스 규칙 — 활성 연결 4개
| 연결 | 적용 규칙 | 대역폭 | 비고 |
|---|---|---|---|
| HTTP | Web Rule | 70% | 35 / 50 (전체 가중치 합) |
| RealAudio | RealAudio Rule | 10% | 5 / 50 |
| FTP | Default 공유 | 20% | 10 / 50 — 한 규칙이 모든 연결에 함께 적용 |
| TELNET | Default 공유 | 20% | 10 / 50 — 한 규칙이 모든 연결에 함께 적용 |
대역폭은 상대적 가중치에 따라 연결들 사이에 배분 됩니다. 연결이 열리고 닫힐 때마다 QoS는 정책에 따라 대역폭 배분을 다시 계산합니다. 예를 들어,
- HTTP·FTP·TELNET 연결이 모두 닫히면 남은 연결은 RealAudio뿐이므로, RealAudio가 대역폭 100% 를 받습니다.
- TELNET·FTP 연결이 닫히면, 풀린 대역폭을 HTTP와 RealAudio가 함께 나눠 받습니다.
서비스 규칙 — 활성 연결 2개
| 연결 | 적용 규칙 | 대역폭 | 비고 |
|---|---|---|---|
| HTTP | Web Rule | 87.5% | 35 / 40 (전체 가중치 합) |
| RealAudio | RealAudio Rule | 12.5% | 5 / 40 |
RealAudio는 HTTP에 비해 가중치가 매우 작지만, HTTP 트래픽이 아무리 무거워도 RealAudio가 대역폭을 굶지는 않 습니다. 실무에서는 작은 데이터를 주고받지만 사용자가 명령을 입력하는 TELNET 같은 대화형(interactive) 서비스에 상대적으로 높은 가중치 를 주고 싶을 때가 많습니다.
출발지로 트래픽 분류하기
QoS 정책 방침의 둘째 항목(Marketing이 Engineering보다 많은 대역폭)은 다음 규칙으로 구현합니다.
Marketing에 Engineering보다 많은 대역폭 배정
| Rule Name | Source | Destination | Service | Action |
|---|---|---|---|---|
| Marketing Rule | Marketing | Any | Any | Weight 30 |
| Engineering Rule | Engineering | Any | Any | Weight 20 |
| Default | Any | Any | Any | Weight 10 |
앞서 "새 규칙 만들기"·"규칙 속성과 기본값 바꾸기"에서 설명한 원리를 그대로 써서 SmartConsole에 새 규칙을 만들고 위 표의 값에 맞춰 바꿉니다. 이 규칙들의 효과는 다음 표와 같습니다.
| 연결 | 적용 규칙 | 대역폭 | 비고 |
|---|---|---|---|
| HTTP | Web Rule | 70% | 35 / 50 (전체 가중치 합) |
| RealAudio | RealAudio Rule | 10% | 5 / 50 |
| FTP | Default 공유 | 20% | 10 / 50 — 한 규칙이 모든 연결에 함께 적용 |
| TELNET | Default 공유 | 20% | 10 / 50 — 한 규칙이 모든 연결에 함께 적용 |
다만 다음 두 가지가 다릅니다.
- 가중치 값이 다르다 는 점
- 배분 기준이 서비스가 아니라 출발지(source) 라는 점
서비스와 출발지를 함께 쓰기
이제 모든 규칙을 하나의 Rule Base에 모으면 다음과 같습니다.
모든 규칙을 한데 모은 Rule Base
| Rule Name | Source | Destination | Service | Action |
|---|---|---|---|---|
| Web Rule | Any | Any | HTTP | Weight 35 |
| RealAudio Rule | Any | Any | RealAudio | Weight 5 |
| Marketing Rule | Marketing | Any | Any | Weight 30 |
| Engineering Rule | Engineering | Any | Any | Weight 20 |
| Default | Any | Any | Any | Weight 10 |
이 Rule Base에서는 대역폭 배분이 서브넷(출발지)과 서비스 양쪽 모두 를 기준으로 이루어집니다.
First Rule Match 원칙
위와 같은 Rule Base를 그대로 두면, 실제 운영 환경에서는 한 연결이 둘 이상의 규칙에 걸릴 수 있습니다. QoS는 First Rule Match(가장 먼저 매칭된 규칙) 원칙 으로 동작합니다 — 각 연결을 QoS 정책과 위에서부터 대조해, 처음 매칭된 규칙의 Action에 따라 대역폭 을 받습니다.
예를 들어 Marketing 사용자가 HTTP 연결 을 열면 그 연결은 Web Rule 과 Marketing Rule 양쪽 모두에 걸립니다. 하지만 Rule Base에서 Web Rule이 Marketing Rule보다 위 에 있으므로, 연결은 Web Rule에 매칭되어 Weight 35 를 받습니다.
HTTP 트래픽을 출발지별로 다시 구분 하고 싶다면, Web Rule 아래에 서브 규칙(sub-rule) 을 만들면 됩니다(아래 "서브 규칙" 참고).
보장(Guarantee)과 제한(Limit)
대역폭 배분은 가중치 말고 보장과 제한 으로도 정의할 수 있습니다. 보장·제한은 규칙 단위로도, 규칙 안의 개별 연결 단위로도 정의할 수 있습니다.
| Rule Name | Source | Destination | Service | Action |
|---|---|---|---|---|
| Web Rule | Any | Any | HTTP | Weight 35 |
| RealAudio Rule | Any | Any | RealAudio | Weight 5 |
| Marketing Rule | Marketing | Any | Any | Weight 30 |
| Engineering Rule | Engineering | Any | Any | Weight 20 |
| Default | Any | Any | Any | Weight 10 |
위 Rule Base의 Web Rule은 모든 HTTP 연결을 합쳐 가용 대역폭의 35% 를 배정합니다. 이 규칙에 매칭된 연결이 실제로 받는 대역폭은 다음에 따라 달라집니다.
- 전체 가용 대역폭
- 다른 규칙에 매칭되어 열려 있는 연결의 수
상대적 가중치 대신 보장(guarantee) 을 쓰면 대역폭을 절대값(초당 바이트 수, Bytes per second)으로 못 박 을 수 있습니다. 다음 표는 Web Rule에 20 KBps를 보장 한 예입니다.
보장 예시
| Rule Name | Source | Destination | Service | Action |
|---|---|---|---|---|
| Web Rule | Any | Any | HTTP | Guarantee 20 KBps, Weight 35 |
| RealAudio Rule | Any | Any | RealAudio | Weight 5 |
| Marketing Rule | Marketing | Any | Any | Weight 30 |
| Engineering Rule | Engineering | Any | Any | Weight 20 |
| Default | Any | Any | Any | Weight 10 |
Web Rule에 매칭된 연결은 총 20 KBps 를 받습니다. 그러고 남은 대역폭은 Web Rule을 포함한 모든 규칙에 각자의 가중치대로 다시 배분 됩니다. 보장·제한에 관한 더 자세한 내용은 보장·제한 예시와 대역폭 배분·서브 규칙 설명을 참고하세요.
서브 규칙(Sub-Rule)
서브 규칙 은 규칙 안에 중첩된 규칙 입니다. 예를 들어 Marketing에서 출발하는 HTTP 연결 에 더 많은 대역폭을 주는 서브 규칙을 만들 수 있습니다. 그러면 출발지가 Marketing인 연결이 다른 HTTP 트래픽보다 많은 대역폭을 받습니다. 아래 예에서는 marketing 서브 규칙과 default 서브 규칙이 Web Rule 아래에 들어갑니다.
서브 규칙 정의
| Rule Name | Source | Destination | Service | Action |
|---|---|---|---|---|
| Web Rule | Any | Any | Weight 20 | |
| — 서브 규칙 시작 — | ||||
| Marketing HTTP | Marketing | Any | Any | Weight 10 |
| Default | Any | Any | Any | Weight 1 |
| — 서브 규칙 끝 — |
대역폭은 먼저 Web Rule에 그 가중치(20)에 따라 배정됩니다. 그렇게 받은 대역폭이 다시 서브 규칙들 사이에 10:1 비율 로 나뉩니다. 즉 Web Rule 아래 연결들은 다음 가중치대로 대역폭을 받습니다.
- Marketing 부서에서 온 HTTP 트래픽에 10
- 그 밖의 모든 트래픽에 1
여기서 알아 둘 점이 둘 있습니다.
- Default 규칙이 두 개 존재합니다 — 하나는 Rule Base 전체의 Default, 다른 하나는 Web Rule 서브 규칙의 Default입니다.
- 서브 규칙의 Source·Destination·Service 필드는 반드시 부모 규칙의 "부분집합(sub-set)" 이어야 합니다.
서브 규칙을 만드는 절차는 다음과 같습니다.
- 서브 규칙을 넣을 규칙의 Name 필드를 우클릭합니다.
- Add Sub-Rule 을 선택합니다.
QoS 정책 설치
규칙을 다 짰으면 정책을 설치합니다. 절차는 다음과 같습니다.
- SmartDashboard에서 정책 규칙을 수정한 뒤 Update 를 클릭합니다.
- SmartConsole에서 Install Policy 를 클릭합니다.
- Policy 목록에서 설치할 정책을 선택합니다.
- Policy Targets 를 클릭해 이 정책을 받을 Security Gateway를 선택합니다.
- Install 을 클릭합니다.
설치가 성공하면 새 정책은 그것이 설치된 Security Gateway에서 적용·시행됩니다. 설치가 실패하면 오류 메시지를 다음 절차로 확인합니다.
- SmartConsole 왼쪽 아래의 Task Information 영역을 클릭합니다.
- Recent Tasks 영역에서 해당 오류의 Details 를 클릭합니다.
Install Policy Details 창에서 Status 열의 ^ 아이콘 을 클릭하면 오류 메시지가 보입니다. 모든 오류를 해결해야 정책을 정상적으로 설치 할 수 있습니다.