05QoS 기본 아키텍처Basic QoS Architecture
QoS의 내부 구조와 흐름 제어는 방화벽과 거의 똑같 습니다. 이 장은 QoS가 어떤 컴포넌트로 이뤄지고, QoS Blade와 엔진·데몬이 각각 무슨 일을 하며, 패킷이 어떤 경로로 처리되고, 분산·Client-Server 구성은 어떻게 배치되며, 방화벽·VPN과 어떻게 맞물리는지를 빠짐없이 정리합니다.
세 컴포넌트
QoS는 방화벽처럼 세 컴포넌트 로 나뉩니다.
- SmartConsole
- Security Management Server
- Gateway
이들은 한 장비에 다 올릴 수도 있고, 여러 장비에 나눠 배치(distributed) 할 수도 있습니다.
역할 분담은 이렇습니다. 대역폭 정책은 SmartConsole에서 구성 하고, Security Management Server에서 그 정책을 검증해 QoS 게이트웨이에 설치 합니다. 실제 트래픽을 다루는 QoS Security Gateway는 다음 두 가지를 씁니다.
- 방화벽의 체이닝(chaining) 메커니즘 으로 패킷을 받고·처리하고·내보냅니다.
- 자체(proprietary) 분류·규칙 매칭 인프라 로 패킷을 검사합니다.
로그 정보는 방화벽 커널 API 로 만들어집니다.
QoS Blade
QoS Blade 의 본래 임무는 두 가지입니다.
- 네트워크 접점(network access points)에서 QoS 정책을 집행 합니다.
- 들어오고 나가는(inbound·outbound) 트래픽의 흐름을 통제 합니다.
이 블레이드는 두 컴포넌트로 이뤄집니다 — QoS 커널 드라이버 와 QoS 데몬 입니다.
QoS Engine
QoS Engine 은 QoS 동작의 심장 이자 Firewall-1 과 SecureXL 의 일부입니다. QoS 엔진 안에서 IP 패킷을 검사하고, 큐에 넣고, 스케줄링하고, 내보내는 일이 일어나며, 바로 이 과정이 QoS의 트래픽 통제를 가능하게 합니다.
QoS Daemon (fgd50)
QoS 데몬(fgd50) 은 사용자 모드(user mode) 프로세스로, 두 가지 일을 합니다.
- 커널을 위해 DNS를 해석 합니다(Rule Base 매칭에 쓰입니다).
- Cluster Load Sharing 구성에서는 클러스터 상태 변화를 커널에 알 립니다. 예를 들어 클러스터 멤버 하나가 다운되면, 데몬이 게이트웨이들의 상대 부하를 다시 계산 해 커널을 갱신합니다.
QoS SmartConsole과 SmartDashboard
정책을 짜는 도구는 둘로 나뉩니다.
- QoS SmartConsole — SmartConsole과 SmartDashboard로 QoS 정책의 ="대역폭 규칙(bandwidth rules)"== 을 만듭니다. 활성 QoS Security Gateway와 그 정책에 대한 정보는 SmartConsole의 Logs & Events 기능으로 봅니다.
- QoS SmartDashboard — SmartConsole로 QoS 정책을 만들고 바꾸며, 실제 규칙과 거기 딸린 네트워크 객체·서비스 작업은 SmartDashboard 에서 합니다.
QoS 정책의 규칙들은 QoS Rule Base 에 나타납니다.
QoS 구성 — 분산 배치
Security Management Server와 QoS Security Gateway는 한 장비에 둘 수도, 두 장비에 나눠 둘 수도 있습니다. 따로 두는 구성을 분산(distributed) 이라 부릅니다.
① 내부 네트워크(본사) ② QoS를 켠 Security Gateway ③ Security Management Server ④ SmartConsole ⑤ 인터넷 ⑥ QoS를 켠 Security Gateway(지점) ⑦ 내부 네트워크(지점)
이 예는 분산 구성으로, 하나의 Security Management Server(Security Management Server와 SmartConsole로 구성)가 네 대의 QoS 게이트웨이를 제어 하고, 그 네 대의 게이트웨이가 세 개의 QoS 회선(line)에서 대역폭 배분을 관리 합니다.
한 Security Management Server가 여러 QoS 게이트웨이를 제어·모니터링 할 수 있습니다. 각 QoS Security Gateway는 Security Management Server와 독립적으로 동작 하며, QoS 게이트웨이는 인터넷 게이트웨이뿐 아니라 부서 간(interdepartmental) 게이트웨이에서도 동작할 수 있습니다.
Client-Server 구조
SmartConsole과 Security Management Server도 같은 장비에 둘 수도, 두 장비에 나눌 수도 있습니다. 나누면 SmartConsole이 Security Management Server를 제어하는 Client/Server 모델 이 됩니다.
① 내부 네트워크(본사) ② Security Management Server ③ SmartConsole ④ QoS를 켠 Security Gateway ⑤ 인터넷
이 그림에서는 Security Management Server의 기능이 두 워크스테이션(Tower 와 Bridge)으로 나뉩니다. 데이터베이스를 가진 Security Management Server는 Tower에, SmartConsole은 Bridge에 있습니다. Bridge에서 작업하는 사용자가 Tower에 있는 QoS 정책·데이터베이스를 유지하고, London 의 QoS Security Gateway가 QoS 회선에 정책을 집행합니다.
Security Management Server 시작과 권한
Security Management Server는 cpstart 명령으로 시작하며, 클라이언트 장비에서 SmartConsole을 쓰려면 이 서버가 떠 있어야 합니다.
SmartConsole이 서버를 관리하려면 SmartConsole에 로그인한 관리자와 SmartConsole이 실행되는 컴퓨터가 모두 Security Management Server 접근 권한 을 받아야 합니다. 이때 cpconfig 를 써서 다음을 합니다.
- SmartConsole을 Security Management Server에 접근할 수 있는 GUI client 로 추가합니다.
- Security Management Server의 관리자(administrators) 를 정의합니다.
동시 세션
여러 관리자가 동시에 각자 다른 세션에서 QoS 정책을 작업 할 수 있습니다. 다만 잠금(locking) 메커니즘이 같은 객체를 둘이 동시에 건드리지 못하게 막습니다. 세션 작업을 마치고 Publish 를 누르면 변경 내용이 다른 세션·관리자에게 공개됩니다.
방화벽·VPN과의 상호작용
Interoperability
QoS와 방화벽은 많은 핵심 기술 컴포넌트를 공유 합니다. 같은 사용자 정의 네트워크 객체를 양쪽에서 쓸 수 있고, 보안 정책과 대역폭 관리 정책을 통합하면 정책 정의와 시스템 구성이 쉬워집니다. 효율적 트래픽 검사와 향상된 성능을 위해 두 블레이드가 상태 테이블(state table) 정보를 함께 씁니다. 덕분에 QoS 블레이드와 방화벽 블레이드를 통해 암호화 트래픽과 NAT된 트래픽에도 대역폭 배분 규칙 을 정의할 수 있습니다.
Security Management Server
QoS는 Security Management Server를 사용하며, 방화벽과 객체 데이터베이스(네트워크 객체·서비스·리소스)를 공유 합니다. 다만 객체 중에는 제품별 고유 속성 도 있습니다. 예를 들어 방화벽에는 QoS와 무관한 암호화 속성이 있고, QoS 네트워크 인터페이스에는 방화벽과 무관한 속도(speed) 속성이 있습니다.