목차/11. 자주 묻는 질문(FAQ)

11자주 묻는 질문(FAQ)FAQ

이 장은 Check Point QoS를 실제로 설계하고 운영하면서 가장 자주 부딪히는 질문 을 주제별로 묶어, 원문 FAQ에 실린 모든 문답·표·참고를 하나도 빼지 않고 풀어 둡니다. 짧게 끊어 답하기보다 "왜 그렇게 동작하는지"까지 설명하니, 개념을 더 깊이 보려면 중간중간 연결해 둔 본문 장으로 넘어가면 됩니다.

QoS 기본

Recommended와 Express 중 무엇을 써야 하나요?

세밀하게 다듬은 기능과 고급 QoS 기능이 필요하면 Recommended 정책 유형을, 기본 QoS만 있으면 충분하면 Express 정책 유형을 쓰면 됩니다. 즉 선택 기준은 "고급 기능을 얼마나 쓸 것인가"입니다.

두 모드 각각의 장점은 무엇인가요?

Recommended 는 고급 QoS 기능을 제공한다는 것이 장점입니다. Express 는 성능이 더 좋고, CPU와 메모리를 더 적게 쓴다는 것이 장점입니다. 그래서 단순한 QoS만 필요한 환경에서는 Express가 자원 면에서 유리합니다.

정책 유형을 나중에 바꿀 수 있나요?

Express에서 Recommended로는 바꿀 수 있지만, Recommended에서 Express로는 바꿀 수 없 습니다. 그래서 확신이 서지 않으면 Express로 시작 하기를 권장합니다. 이렇게 하면 나중에 고급 QoS 기능이 필요해졌을 때 Recommended로 올라갈 수 있어, 한 방향으로만 열려 있는 전환 제약에 걸리지 않습니다(자세히는 QoS 소개).

규칙에 줄 수 있는 가장 큰 가중치는 얼마인가요?

가중치는 어디까지나 상대값 입니다. 따라서 유일한 한계는 Global Properties 창의 QoS 항목에 정의된 Maximum weight of rule 파라미터뿐인데, 기본값은 1000이고 임의의 숫자로 바꿀 수 있습니다.

가중치에서 정말 중요한 것은 "최댓값이 얼마냐"가 아니라 초기 가중치를 크게 잡느냐 작게 잡느냐 입니다. 같은 비율이라도 출발점이 다르면, 나중에 규칙을 하나 더 추가했을 때 받는 영향이 크게 달라지기 때문입니다. 다음 예가 이 점을 잘 보여 줍니다.

정책	가중치 설정	HTTP가 받는 몫	설명
정책 1	HTTP=500, FTP=500	500/(500+500)	두 규칙에 동일한 가중치 → 동등 분배
정책 2	HTTP=2, FTP=2	2/(2+2)	두 규칙에 동일한 가중치 → 동등 분배
정책 1 + 세 번째 규칙	HTTP=500, FTP=500, SMTP=100	500/(500+500+100) = 500/1100	초기 가중치가 커서, 규칙을 더해도 HTTP 몫이 아주 조금만 줄어듦
정책 2 + 세 번째 규칙	HTTP=2, FTP=2, SMTP=100	2/(2+2+100) = 2/104	초기 가중치가 작아서, 규칙을 더하니 HTTP 몫이 크게 줄어듦

같은 의미로 정리하면, 정책 1과 정책 2 모두 처음에는 HTTP와 FTP가 대역폭을 똑같이 나눠 가집니다. 정책 1에서는 각각 500, 정책 2에서는 각각 2를 받지만 비율은 같으니까요. 그런데 두 정책에 똑같이 가중치 100짜리 SMTP 규칙을 추가하면 결과가 확 달라집니다. 정책 1은 초기 가중치가 워낙 커서 HTTP 몫이 거의 변하지 않지만, 정책 2는 초기 가중치가 작아서 HTTP 몫이 크게 줄어듭니다. 그래서 초기 가중치를 충분히 크게 잡아 두면 규칙을 더해도 기존 트래픽이 덜 흔들립 니다.

QoS를 외부 인터페이스에 둘까요, 내부 인터페이스에 둘까요?

QoS는 두 인터페이스 모두에서 동작 하지만, 외부 인터페이스에만 두는 것을 강력히 권장 합니다.

보장(Guarantee)과 가중치(Weight)는 무엇이 다른가요?

둘은 동작이 비슷합니다. 사전적 의미는 다르지만, 둘 다 매칭된 트래픽에 정해진 대역폭을 보장 한다는 점은 같습니다. 차이는 다음 두 가지입니다.

보장은 절대값 으로 표현됩니다(예: 20000bps). 가중치는 상대값 으로 표현됩니다(예: 100).
보장은 가중치보다 먼저 대역폭을 할당받 습니다.

예를 들어 1.5MB 회선에 다음 Rule Base가 있다고 합시다.

HTTP — Guarantee 1Mb
FTP — Weight 40
SMTP — Weight 10

이때 결과는 먼저 HTTP에 1MB를 할당 하고, 그다음 남은 0.5MB를 FTP 0.4MB·SMTP 0.1MB 로 나눕니다. 절대값으로 대역폭을 못 박거나 per-connection 보장을 줄 때는 보장을 쓰면 됩니다.

QoS는 Rule Base에서 어떤 Firewall 리소스를 지원하나요?

QoS는 자신의 리소스로 HTTP 트래픽을 검사 할 수 있습니다. 리소스는 URI for QoS 옵션으로 정의하며, 특정 URL이나 파일을 담을 수 있습니다. 예컨대 웹서핑을 http://www.restrict-access-to-this-site.com 사이트로 제한하고 싶다면, www.restrict-access-to-this-site.com 문자열(앞의 http://는 빼고)을 찾는 QoS URI 리소스 를 하나 추가한 뒤, 그 리소스를 QoS 규칙에 쓰면서 제한(limit)을 걸면 됩니다.

TCP 재전송 패킷은 어떻게 처리하나요?

재전송이 감지되면 QoS는 그 재전송 데이터가 이미 QoS 큐에 들어 있는지 확인 하고, 들어 있으면 해당 패킷을 떨굽 니다. QoS만의 이 독특한 기능 덕분에 WAN 링크의 최대 40%까지 잡아먹던 재전송을 없애 고, 중복 패킷을 저장하느라 쓰던 메모리도 아낄 수 있습니다.

보장은 대역폭을 낭비하지 않나요?

아닙니다. QoS는 정교한 큐잉 메커니즘을 씁니다. 애플리케이션은 필요한 만큼만 대역폭을 가져가 고, 쓰이지 않는 대역폭은 곧바로 다른 애플리케이션이 쓸 수 있게 풀립니다.

빌려준 대역폭을 되돌려받을 수 있는지 어떻게 아나요?

QoS에는 "빌려준 대역폭(loaned bandwidth)"이라는 개념 자체가 없 습니다. 보장 규칙이나 가중치 규칙이 쓰지 않는 대역폭은 즉시, 그것도 패킷 단위로 다른 연결들에 상대 우선순위에 따라 재분배됩니다. 여기서 기억해야 할 핵심은 Resolution(분배 단위의 세밀함) 입니다. QoS는 패킷 단위로 대역폭을 할당 하므로 한 번에 패킷 하나씩만 배분되고, 그래서 가장 정확한 스케줄링이 가능합니다.

다른 Check Point 제품과의 관계 — 지원과 관리

Multi-Domain Security Management 검사 체인에서 QoS는 어디에 위치하나요?

QoS는 두 구성 요소로 이루어집니다.

QoS Policy — 규칙 매칭을 담당합니다.
QoS Scheduling — 패킷 스케줄링을 담당합니다.

QoS가 Multi-Domain Security Management와 함께 동작하나요?

예. QoS의 가장 중요한 특징 중 하나가 바로 Multi-Domain Security Management와의 독특하고 정교한 통합 입니다. 통합 기능으로는 다음이 있습니다.

VPN 트래픽(터널 안쪽)의 정확한 분류
NAT된 트래픽의 분류
네트워크 객체와 토폴로지 공유(관리에 드는 시간과 수고를 줄여 줌)
고급 GUI를 갖췄지만 친숙한 모양새를 유지한 공통 SmartDashboard
DiffServ 지원과 함께, VPN 세계에 "Frame Relay보다 나은" QoS 제공
로그 검증

SmartView Monitor는 QoS의 일부인가요?

아닙니다. SmartView Monitor 는 QoS와 함께 번들로 제공되는 별도 제품 입니다.

QoS가 Load Sharing 구성을 지원하나요?

예. QoS는 모든 ClusterXL 구성을 지원 합니다. SYNC 메커니즘을 지원하므로 CPLS/CPHA나 서드파티 솔루션과도 함께 쓸 수 있습니다. OPSEC 파트너 솔루션에 대해서는 OPSEC 웹사이트를 참고하세요.

QoS가 NAT된 트래픽을 지원하나요?

QoS는 NAT 트래픽을 완전히 지원 합니다. 매칭, 스케줄링, 제한을 비롯한 모든 QoS 기능이 NAT된 트래픽에도 그대로 적용됩니다.

관리할 수 있는 QoS 게이트웨이의 최대 개수는?

QoS Security Gateway의 관리는 일반 Security Gateway와 동일 합니다. 따라서 최대 게이트웨이 개수도 일반적으로 관리할 수 있는 게이트웨이 최대 개수와 같습니다.

Security Management Server에도 QoS를 설치해야 하나요?

예. QoS Security Gateway를 관리하려면 Security Management Server에도 QoS를 설치 해야 합니다.

정책 만들기

LLQ(Low Latency Queuing)는 언제 써야 하나요?

LLQ 는 VoIP, 화상회의, 그 밖의 멀티미디어 애플리케이션 에 가장 잘 맞습니다. 구체적으로는 다음 조건을 가진 애플리케이션을 겨냥합니다.

적정 성능을 위해 최소 보장 대역폭이 필요 한 경우
낮은 지연(delay)과 낮은 지터(jitter)가 필요 한 경우

자세한 내용은 고급 QoS 정책 관리를 참고하세요.

QoS Rule Base는 "first match"인가요?

예. 모든 QoS 규칙은 "first match" 원칙 으로 매칭됩니다. 즉 하나의 연결에는 처음 맞는 규칙만 적용 되고, 그 뒤의 규칙은 보지 않습니다.

예를 들어 CEO 트래픽용 규칙과 HTTP 트래픽용 규칙이 있을 때, Rule Base에서 먼저 나오는 규칙 이 CEO의 모든 웹서핑에 적용됩니다. 그래서 순서가 결정적으로 중요합니다.

[올바른 Rule Base — CEO가 먼저 매칭됨]
1. SRC=CEO     => Guarantee = 128Kbps
2. Service=HTTP => Limit     = 64Kbps

[잘못된 Rule Base — CEO 트래픽이 제한에 걸림]
1. Service=HTTP => Limit     = 64Kbps
2. SRC=CEO     => Guarantee = 128Kbps

CEO에게 대역폭을 보장하고 싶다면 CEO 규칙을 HTTP 규칙보다 위에 둬야 합니다. 아래에 두면 CEO의 웹서핑이 먼저 HTTP 제한 규칙에 걸려 버립니다.

여러 게이트웨이를 쓸 때 Rule Base를 어떻게 정리하면 좋나요?

상황을 셋으로 나눠 생각하면 됩니다.

대역폭이 같고 정책도 같게 하고 싶다면, Install On 필드를 All 로 정의합니다.
대역폭은 다르지만 정책은 같게 하고 싶다면, 하나의 정책을 모든 게이트웨이에 설치할 수 있습니다. 이때는 절대값이 아니라 상대 대역폭을 배정하는 가중치(weight)를 쓰는 것이 최선 입니다. 가중치도 대역폭 할당을 보장한다는 점을 기억하세요.
대역폭도 다르고 정책도 다르게 하고 싶다면, 게이트웨이마다 서로 다른 서브 규칙(sub-rules) 을 쓰면 됩니다. 게이트웨이들에 공통으로 매칭되는 공통 규칙을 함께 쓸 수도 있습니다.

서브 규칙은 언제 써야 하나요?

객체 사이에 위계(hierarchy)가 있을 때 서브 규칙을 씁니다. 예컨대 R&D, Marketing, 운영처럼 조직 구조에 따라 대역폭을 나눠 관리하고 싶을 때가 대표적입니다.

대역폭을 가장 많이 잡아먹는 애플리케이션은 어떻게 보나요?

명령줄에서 다음 명령을 실행하면 됩니다(CLI 참조).

rtmtopsvc

용량 산정(Capacity Planning)

QoS의 메모리 요구량은 얼마인가요?

QoS를 돌리려면 (Multi-Domain Security Management에 필요한 메모리와 별개로) 다음만큼의 여유 메모리가 필요합니다.

연결 수	Management	Gateway (또는 Management+Gateway)
5,000	0 MB	32.5 MB
10,000	0 MB	39 MB
25,000	0 MB	57 MB
50,000	0 MB	91 MB
100,000	0 MB	156 MB

이 표에는 다음 점을 함께 알아 두면 좋습니다.

위 수치에는 SmartView Monitor와 UserAuthority가 포함 되어 있습니다.
연결 수는 Firewall 연결 테이블 기준으로 셉니다.
연결 테이블의 기본 크기는 25,000 입니다.
평균적으로 연결 하나당 약 1300바이트 가 듭니다.

QoS를 돌리려면 어떤 하드웨어가 필요한지 어떻게 판단하나요?

하드웨어 플랫폼과 벤더 선택에는 지원, 가격, 어플라이언스, 보유 지식 등 여러 측면이 얽혀 있고, 구매자마다 고려 사항이 다릅니다. 다만 성능만 놓고 보면 QoS 성능의 주된 요인은 CPU 성능 입니다. 메모리는 발자국이 작고 값도 싸기 때문에, 보통은 메모리가 병목이 되지 않 습니다.

QoS 성능은 어떻게 튜닝하나요?

성능을 다듬는 팁은 다음과 같습니다.

사용 가능한 최신 QoS 버전으로 업그레이드 합니다.
대부분의 경우 게이트웨이의 외부 인터페이스에만 QoS를 설치하면 됩니다.
inbound 트래픽에 제한을 쓰는 경우가 아니라면, outbound 방향에만 설치 해도 기능과 개선 효과의 대부분을 얻을 수 있습니다.
자주 매칭되는 규칙을 Rule Base 위쪽으로 올립니다. 어떤 규칙이 얼마나 많이 쓰이는지는 SmartView Monitor로 분석할 수 있습니다.
"per connection limits"를 "per rule limits"로 바꿉니다.
"per connection guarantees"를 "per rule guarantees"로 바꿉니다.

QoS가 지원하는 최대 대역폭은?

10Gbps 입니다.

설치 / 하위 호환 / 라이선스 / 버전

QoS의 다음 기능 팩은 언제 나오나요?

QoS의 기능 팩과 릴리스는 보통 Multi-Domain Security Management 기능 팩이 출시되는 시점에 함께 나옵니다.

어떻게 하나요?(How do I?)

메일 서버 성능을 보장하려면?

메일 트래픽에 매칭되는 규칙을 하나 추가 하면 됩니다. 메일 서버의 출발지/목적지로 매칭하거나, 메일 프로토콜(SMTP, POP3, Exchange)로 매칭하면 됩니다. 이 규칙에 원하는 우선순위에 맞는 가중치나 보장을 정의합니다.

VoIP의 통화 품질을 보장하려면?

QoS는 VoIP에 맞춘 메커니즘인 LLQ(Low Latency Queuing) 를 씁니다. 이 메커니즘은 VoIP처럼 일정 비트레이트(constant bit rate)를 쓰는 애플리케이션에서 지연을 최소로 하도록 다듬어져 있습니다.

받아들이는 연결 수를 제한하려면 LLQ에 per-connection 보장 을 함께 씁니다. 음성 트래픽은 통화마다 대역폭을 보장 해 주고 싶을 테니, 보통은 대역폭이 충분하지 않으면 추가 통화를 받지 않는 입장 정책(admission policy) 을 두게 됩니다.

ERP 애플리케이션 성능을 보장하려면?

ERP 트래픽에 매칭되는 규칙을 하나 추가 하면 됩니다. ERP 서버의 출발지/목적지로 매칭하거나, 애플리케이션 프로토콜(SAP, BAAN, ORACLE)로 매칭합니다. 이 규칙에 원하는 우선순위에 맞는 가중치나 보장을 정의합니다. 만약 쓰는 ERP 애플리케이션이 미리 정의된 서비스가 아니라면, 직접 수동으로 추가 하거나 위의 출발지/목적지 매칭 방법을 쓰면 됩니다.

ERP를 HTTP 위에서 쓰고 있다면, "인트라넷 애플리케이션에 대역폭을 어떻게 주나요?" 항목을 함께 확인하세요.

QoS로 DoS(서비스 거부) 공격을 막을 수 있나요?

QoS는 DoS 전용 방어 도구는 아닙니다. 다만 QoS를 그런 공격의 탐지·모니터링·예방에 활용 할 수 있는 상황은 많습니다. SmartView Monitor와 QoS를 함께 쓰면 탐지와 모니터링을 할 수 있고, 예방은 다음 방식으로 할 수 있습니다.

DoS 공격에 흔히 동원되는 애플리케이션(예: ICMP, 수상한 URL)을 제한(limit) 합니다.
중요한 트래픽(예: ERP, MAIL, VoIP)에 보장(guarantee) 을 줍니다.

일반적인 문제(General Issues)

애플리케이션을 차단하는 것보다 대역폭을 제한하는 것이 왜 더 나은가요?

"업무와 무관한" 애플리케이션을 완전히 차단하면, 사용자가 차단을 우회할 방법을 찾게 만들 수 있습니다. 반면 대역폭에 우선순위를 두면, 핵심 업무 프로세스를 해치지 않으면서도 사용자가 활동을 이어 가게 할 수 있습니다.

인터넷 회선이 P2P 파일 다운로드에 쓰이는 대학을 떠올려 보세요. 이런 서비스를 완전히 막으면 학생들이 우회로를 찾게 되고, 이는 법적 문제로까지 번질 수 있습니다. QoS는 더 똑똑한 해법을 제공합니다.

그런 애플리케이션에 배정되는 대역폭을 제한 합니다 — 학생들이 알든 모르든 가능합니다.
낮 시간에는 대역폭을 제한하고, 밤에는 더 많이 주는 식으로 시간대별로 조절합니다.
중요한 사용자(교수, MIS)에게는 보장을 주고, 학생들은 남는 대역폭을 쓰게 합니다.

장비에 기술적 장애가 생기면 어떻게 하나요?

알려진 문제와 제약에 대해 웹에서 최신 릴리스 노트를 확인 하고, 추가 지원이 필요하면 벤더에 연락하세요.

보장/제한을 설정했는데 SmartView Monitor에서 깨져 보입니다.

아주 낮은 트래픽 제한(예: 초당 1000바이트)을 높은 빈도(2초마다 갱신)로 들여다보면, QoS가 패킷을 쪼개지 않기 때문에 마치 제한이 깨진 것처럼 보일 수 있습니다. SmartView Monitor의 샘플링 주기를 낮추면(8초마다 갱신) 제한이 제대로 지켜지고 있음을 확인할 수 있습니다.

QoS를 LAN 환경에 배치할 수 있나요?

예. 다만 우선순위를 주려는 네트워크 트래픽을 받쳐 줄 위치에 하드웨어를 배치해야 합니다. QoS는 네트워크 트래픽의 혼잡 지점(congestion point)에 배치할 때 가장 효과가 좋습니다.

정의한 대역폭이 실제 물리 대역폭보다 작으면 어떻게 되나요?

QoS는 Interface Properties 창에 정의된 만큼만 대역폭을 할당 합니다. 인터페이스의 물리 대역폭이 아무리 커도, 정의값을 넘는 대역폭은 할당하지 않습니다.

정의한 링크 대역폭이 실제 물리 대역폭보다 크면 어떻게 되나요?

QoS가 물리 대역폭이 허용하는 양보다 더 많이 보내려고 시도 하게 됩니다. 이렇게 되면 다음 홉(next hop)에서 무작위 트래픽 드롭 이 발생해, 중요한 패킷을 잃을 수 있습니다. 그래서 QoS 관리에서 강조했듯, 정의 전송률을 실제 용량에 맞추는 것이 중요합니다.