07VSX 구성하기Configuring VSX

새 VSX Gateway는 VSX Gateway Wizard로 만듭니다. 먼저 알아둘 제약은 기존 Security Gateway를 VSX Gateway로, 또는 그 반대로 변환할 수 없다는 것입니다. 마법사를 시작하려면 VSX Gateway를 관리할 Security Management Server나 Main Domain Management Server에 SmartConsole로 접속한 다음, 왼쪽 탐색 패널에서 Gateways & Servers를 누르고 위쪽에서 New > VSX > Gateway를 선택합니다. 그러면 General Properties 페이지로 마법사가 열리고, 다섯 단계를 거칩니다. 마법사를 마친 뒤에도 인터페이스를 추가·삭제하거나 기존 인터페이스에 VLAN을 붙이는 등 정의를 SmartConsole에서 바꿀 수 있습니다.

1단계 — General Properties (일반 속성)

이 페이지에서 다음 값을 정합니다.

2단계 — SIC 신뢰 설정 (Establishing SIC Trust)

VSX Gateway와 관리 서버는 신뢰(Trust)가 없으면 서로 통신할 수 없으므로, 둘 사이의 SIC 신뢰를 초기화합니다. VSX Gateway를 만들 때는 Gaia 최초 설정 마법사(First Time Configuration Wizard)에서 입력했던 것과 똑같은 활성화 키(Activation Key)를 입력하고 확인란까지 채운 뒤 Initialize를 누릅니다. 키가 맞으면 Trust State가 "Trust established"로 바뀝니다.

신뢰가 맺어지지 않으면 Check SIC Status를 눌러 실패 원인을 봅니다. 대개는 활성화 키 오류이거나 관리 서버-게이트웨이 간 연결 문제입니다. 해결 순서는 다음과 같습니다.

자세한 SIC 문제 해결은 R82 Security Management Administration Guide를 참고합니다.

Scalable Platform Security Group에서의 SIC 문제 해결

Security Group에서 SIC 리셋에는 3~5분 이 걸립니다. 만약 네트워크 연결 끊김 등으로 리셋이 중단되었다면, Expert 모드에서 g_all cp_conf sic state를 실행해 SIC 상태를 확인한 뒤 상태에 맞게 처리합니다.

그 밖의 SIC 문제는 Expert 모드에서 SIC 정리(cleanup)를 수행합니다.

asg_blade_config reset_sic -reboot_all <activation_key>

3단계 — 물리 인터페이스 정의 (Defining Physical Interfaces)

VSX Gateway Interfaces 창에는 현재 게이트웨이에 정의된 인터페이스가 보입니다. 어떤 인터페이스를 VLAN 트렁크로 쓸지 지정하려면 그 인터페이스에 대해 VLAN Trunk를 선택합니다.

4단계 — 가상 네트워크 장치 구성 (Virtual Network Device Configuration)

Custom Configuration 옵션을 골랐다면 이 창이 열리며, 여기서 게이트웨이와 인터페이스를 공유하는 가상 장치를 정의할 수 있습니다. 지금 정의하지 않으려면 Next로 넘어갑니다. 공유 인터페이스를 가진 가상 장치를 정의하려면 이렇게 합니다.

5단계 — VSX Gateway Management (게이트웨이 보호 정책)

이 창에서는 VSX Gateway 자신을 보호하는 정책 규칙을 정합니다. 이 정책은 새 게이트웨이에 자동으로 설치되며, 오직 VSX Gateway로 향하는 트래픽에만 적용됩니다. Virtual System이나 다른 가상 장치, 외부망·내부망으로 가는 트래픽은 이 정책의 영향을 받지 않습니다. 정책은 다음 서비스에 대한 사전 정의 규칙으로 구성됩니다.

각 규칙은 다음 두 가지를 설정합니다.

마법사 마치기

Next를 누른 뒤 Finish를 누르면 VSX Gateway 생성이 완료됩니다. 완료까지 몇 분 걸릴 수 있으며, 성공/실패 메시지가 표시됩니다. 실패했다면 View Report로 오류 메시지를 확인합니다(VSX 진단과 문제 해결 참고).

VSX Gateway는 Virtual System과 그 밖의 가상 네트워크 구성요소를 담는 컨테이너 역할을 하는 물리 장비입니다. 만든 뒤에는 객체를 더블클릭해 VSX Gateway Properties 창에서 토폴로지·여러 속성·고급 구성을 바꿉니다.

General Properties

General Properties 페이지에서는 SIC 신뢰를 확인·재설정하고 이 게이트웨이에 설치할 Check Point 제품을 활성화합니다. 바꿀 수 있는 속성은 다음과 같습니다.

SIC 확인과 재설정

SIC 신뢰는 테스트·리셋할 수 있고, VSX Gateway의 Relative Distinguished Name도 볼 수 있습니다. SIC를 초기화하려면 객체를 더블클릭해 연 뒤 Communication을 누르고, Trusted Communication 창에서 활성화 키를 입력·확인한 다음 Initialize를 누릅니다(신뢰가 안 맺어지면 Test SIC Status로 원인을 봅니다).

SIC를 리셋할 때는 순서가 중요합니다.

cpstop;cpstart

Software Blade 선택

목록에서 이 VSX Gateway에 설치할 Check Point Software Blade를 고릅니다. 보이는 항목은 제품 버전과 라이선스 계약에 따라 달라집니다.

Physical Interfaces

Physical Interfaces 페이지에서는 물리 인터페이스를 추가·삭제하거나 VLAN 트렁크를 정의합니다. 추가하려면 Add를 눌러 인터페이스 이름을 입력하고, 삭제하려면 인터페이스를 선택해 Remove, VLAN 트렁크로 만들려면 해당 인터페이스의 VLAN Trunk를 선택합니다.

Topology — 인터페이스와 라우트

Topology 페이지에는 인터페이스와, 인터페이스·가상 장치 사이의 라우트 정의가 담깁니다.

인터페이스(Interfaces) 를 추가하려면 New를 누르고 Regular(새 물리 인터페이스)·Leads to Virtual Router·Leads to Virtual Switch 중 하나를 골라 Interface Properties 창에서 속성을 정합니다(아래 인터페이스 정의 다루기 참고). Actions > Copy to Clipboard로 인터페이스 표를 CSV로 복사할 수 있습니다.

라우트(Routes) 일부는 인터페이스 정의에 따라 자동 생성되며, 직접 추가·변경·삭제할 수도 있습니다.

토폴로지 자동 계산 (Topology Calculation)

Calculating topology automatically based on routing information 옵션을 켜면 VSX가 인터페이스·라우팅 정의를 바탕으로 네트워크 토폴로지를 자동 계산해 자동 링크나 연결 클라우드 객체를 만듭니다. 단 다음에 유의합니다.

VSX Gateway 삭제와 백업·복원

VSX Gateway 객체를 삭제하면 그에 딸린 모든 Virtual System과 가상 장치가 관리 DB에서 함께 삭제됩니다. 삭제하려면 Gateways & Servers 뷰나 Object Explorer 트리에서 객체를 우클릭해 Delete를 고른 뒤 Yes를 누릅니다. 한편 치명적 장애에 대비한 백업·복원은 sk100395(How to backup and restore VSX Gateway) 를 따릅니다.

Virtual System은 Virtual Systems Wizard로 만듭니다. 전형적인 VS는 외부망·DMZ·인터넷으로 가는 외부 인터페이스와, 보통 VLAN 트렁크로 내부망에 닿는 내부 인터페이스, 이렇게 두 개를 가집니다. VSX는 가상 장치 하나당 최대 128개, VSX Gateway·클러스터 하나당 총 4096개 의 인터페이스(VLAN과 Warp Link 포함)를 지원합니다.

만드는 절차

마법사의 General Properties에서는 이름(공백·특수문자 불가, 밑줄만 허용)과 호스팅 VSX Gateway/Cluster를 고르고, 필요하면 Bridge Mode를 선택합니다. Network Configuration에서는 내·외부 인터페이스와 내부 인터페이스 뒤의 IP 토폴로지를 정의합니다.

Next 후 Finish를 누르면 생성이 시작되며 몇 분 걸릴 수 있습니다(실패 시 View Report).

수정하기

수정은 관리 서버에 접속해 객체를 더블클릭한 뒤, 설정을 바꾸고 OK로 VSX 구성을 푸시하고 Access Control 정책을 설치하는 흐름입니다(이름만은 바꿀 수 없습니다).

NAT > Advanced

NAT > Advanced 페이지에서는 그 VS에서 나오는 패킷에 대한 NAT 규칙을 설정합니다.

일반(L3) Virtual System의 브리지 인터페이스

새 브리지 인터페이스는 다음처럼 추가합니다.

브리지 종속 인터페이스를 수정하려면 Topology의 Interfaces에서 해당 인터페이스를 골라 Edit합니다. 삭제하려면 먼저 게이트웨이 CLI에서 어떤 종속 인터페이스인지 확인하는 것이 좋습니다.

set virtual-system <VSID>
show bridging groups

그런 다음 SmartConsole의 Topology에서 첫 번째·두 번째 종속 인터페이스를 차례로 Delete하고, OK로 구성을 푸시한 뒤 정책을 설치합니다. Bridge 모드의 동작 원리와 Multi Bridge는 Bridge 모드 장에서 자세히 다룹니다.

Virtual System 삭제

Gateways & Servers 뷰나 Object Explorer에서 Virtual System 객체를 우클릭해 Delete, 그리고 Yes를 누르면 됩니다.

Gaia는 DNS로 호스트 이름을 IP 주소로 바꾸며, 이를 위해 기본(primary) DNS 서버가 필요하고 보조(secondary)·3차(tertiary) 서버도 둘 수 있습니다. 이름을 풀 때 먼저 primary에 묻고, 실패·시간 초과면 secondary, 그래도 안 되면 tertiary에 묻습니다. R81부터는 Virtual System마다 별도의 DNS 설정을 줄 수 있으며, 세 가지 방식이 있습니다.

기능 켜고 끄기

게이트웨이(각 클러스터 멤버) 명령줄에서 Gaia Clish(Scalable Platform은 gClish)에 로그인한 뒤, 아무 가상 장치 컨텍스트에서나 실행할 수 있습니다.

set dns mode {per-vs | default}   # per-vs로 켜기 / default로 끄기
show dns mode                     # 상태 확인
save config

모든 질의에 특정 DNS 서버 설정

set dns mode per-vs
set virtual-system <VSID>          # 대상 VS 컨텍스트
set dns
    primary   <IPv4 또는 IPv6 주소>
    secondary <IPv4 또는 IPv6 주소>
    tertiary  <IPv4 또는 IPv6 주소>
    suffix    <로컬 도메인 이름>
show dns
save config

삭제는 컨텍스트로 들어간 뒤 delete dns {primary | secondary | tertiary | suffix} 후 save config입니다.

set dns mode per-vs
set virtual-system 1
set dns primary 192.168.10.21
set dns secondary 192.168.10.22
set dns tertiary 192.168.10.23
set dns suffix mycompany.com
show dns
save config

특정 도메인에만 다른 DNS 서버 설정 (Forwarding Domain)

위처럼 기본 DNS를 설정한 뒤, Forwarding Domain Suffix와 그 도메인용 DNS 서버를 추가합니다.

add dns proxy forwarding-domain <Domain Suffix>
set dns proxy forwarding-domain <Domain Suffix>
    primary   <IPv4 또는 IPv6 주소>
    secondary <IPv4 또는 IPv6 주소>
    tertiary  <IPv4 또는 IPv6 주소>
show dns proxy forwarding-domains
show dns proxy forwarding-domain <Domain Suffix> primary
save config

삭제는 delete dns proxy forwarding-domain <Domain Suffix>(도메인 전체) 또는 그 뒤에 primary/secondary/tertiary를 붙여 개별 서버만 지웁니다.

set dns mode per-vs
set virtual-system 1
set dns primary 192.168.10.21
set dns secondary 192.168.10.22
set dns tertiary 192.168.10.23
set dns suffix mycompany.com
add dns proxy forwarding-domain anothercompany.com
set dns proxy forwarding-domain anothercompany.com primary 172.16.30.41
set dns proxy forwarding-domain anothercompany.com secondary 172.16.30.42
set dns proxy forwarding-domain anothercompany.com tertiary 172.16.30.43
save config

DNS Relay로 동작시키기

기본 DNS를 설정한 뒤, VS가 DNS 질의를 들을(listen) 인터페이스를 추가합니다.

add dns proxy listening-interface <Virtual System 인터페이스 이름>
show dns proxy listening-interfaces
save config

삭제는 delete dns proxy listening-interface <인터페이스 이름> 후 save config입니다.

set dns mode per-vs
set virtual-system 1
set dns primary 192.168.10.21
set dns suffix mycompany.com
add dns proxy listening-interface wrp128
show dns proxy listening-interfaces
save config

DNS CLI 파라미터

DHCP 서버

DHCP 서버도 게이트웨이(각 클러스터 멤버) 명령줄에서 Gaia Clish(Scalable Platform은 gClish)에 로그인한 뒤, set virtual-system <VS ID>로 대상 VS 컨텍스트에 들어가 설정합니다. 구체적 절차는 R82 Gaia Administration Guide > "Network Management" > "DHCP Server" > "Configuring a DHCP Server in Gaia Clish" 를 따릅니다. 이처럼 CLI 작업은 늘 "지금 어느 VS 컨텍스트인가"가 중요한데, Expert 모드에서는 set virtual-system 대신 vsenv로 컨텍스트를 전환합니다.

Virtual Switch

Virtual Switch는 VS들과 내·외부 네트워크 사이에 L2 연결을 제공하며, 물리 스위치처럼 알려진 네트워크와 도달 방향을 담은 포워딩 테이블을 유지합니다. 외부 통신용·내부 통신용 모두 정의할 수 있습니다.

만드는 방법은 관리 서버에 접속해 New > VSX > New Virtual Switch로 마법사를 연 뒤, 이름과 호스팅 VSX Gateway/Cluster를 정하고 Next, Interfaces 영역에서 Add로 연결할 인터페이스를 추가하고 Next > Finish입니다.

수정은 객체를 더블클릭해 합니다. General Properties에서는 주석과 아이콘 색만 바꿀 수 있고, Topology에서는 정의된 단일 인터페이스만 수정할 수 있으며 Warp 인터페이스 설정은 바꿀 수 없습니다. 인터페이스를 추가하려면 New를 눌러 목록에서 고르고 IP·넷마스크 등을 정합니다. 삭제할 때는 Topology에서 모든 인터페이스를 먼저 제거하고 OK한 뒤, 객체를 우클릭해 Delete > Yes, 마지막으로 세션을 Publish합니다.

Virtual Router

Virtual Router는 물리 라우터처럼 알려진 네트워크와 도달 방향을 담은 라우팅 테이블을 유지하며, 외부·내부 통신용 모두 정의할 수 있습니다(앞서 언급한 대로 Maestro·Scalable Chassis에서는 지원되지 않습니다). 외부망·DMZ·인터넷으로 향하면 외부 Virtual Router, 내부 보호망으로 향하면 내부 Virtual Router라 부르는데, 외부 Virtual Router는 여러 VS가 하나의 보안 물리 인터페이스를 공유해 인터넷으로 나가는 공용 게이트웨이 역할을 합니다.

이 시나리오에서 VSX는 Virtual System과 두 Virtual Router 사이에 Warp 인터페이스를 만들며, VS의 외부 인터페이스는 unnumbered(번호 없는) 인터페이스로 정의됩니다. 내부 Virtual Router는 보통 스위치를 거쳐 내부망으로 가는 인터페이스 하나와, 게이트웨이 안 다른 VS들로 가는 Warp Link들을 가집니다.

만드는 방법은 New > VSX > New Virtual Router로 마법사를 열어 이름·호스팅 게이트웨이를 정하고 Next, Interfaces 영역에서 Add로 인터페이스를, Routes 영역에서 Add로 라우트를(필요하면 Add Default Route로 기본 라우트도) 추가한 뒤 Next > Finish입니다. 인터페이스·라우트에서 Propagate route to adjacent Virtual Devices를 켜면 IP를 이웃 가상 장치에 광고해 연결을 활성화합니다. 만든 뒤에는 각 VS에 Virtual Router로 가는 인터페이스를 추가해 연결합니다.

수정은 객체를 더블클릭해 합니다. General Properties에서 Virtual Router IP·주석·색을 바꾸고, Topology에서는 인터페이스를 추가·수정·삭제하며 라우트를 다룹니다. 단 Warp Link 라우트는 자동 생성되어 수정·삭제할 수 없고, 그 외 라우트만 손댑니다. Advanced Routing에서는 아래의 출발지 기반 라우팅을 설정합니다. 삭제는 Virtual Switch와 마찬가지로 모든 인터페이스를 먼저 제거한 뒤 객체를 Delete하고 세션을 Publish**합니다.

출발지 기반 라우팅 (Source-Based Routing)

보통의 라우팅은 목적지 IP로 경로를 정하지만, 출발지 기반 라우팅은 출발지 IP(또는 출발지와 목적지의 조합)로 경로를 정하며, 일반 목적지 기반 규칙보다 우선 합니다.

덕분에 VLAN 없이 단일 물리 인터페이스만으로도 출발지에 따라 알맞은 VS로 트래픽을 보낼 수 있습니다. 이 절차는 VSX Gateway든 VSX Cluster든 동일합니다. 설정은 Virtual Router 객체를 우클릭해 Edit한 뒤 Topology의 Advanced Routing을 열어, Add(또는 기존 규칙 선택 후 Edit)로 규칙마다 다음을 지정하고 OK합니다.

VSX에서 중요한 점은 VS0(게이트웨이)과 나머지 Virtual System의 설정 방법이 다르다는 것입니다. VS0은 CLI로, 개별 Virtual System은 SmartConsole로 인스턴스 수를 정합니다. VS의 인스턴스 수를 바꾸면 그 VS에 약간의 다운타임이 생깁니다.

VSX Gateway(VS0)에서 설정

VS0의 인스턴스 수는 cpconfig로 정하며, 서버·어플라이언스의 물리 코어 수를 넘을 수 없습니다. 게이트웨이(각 클러스터 멤버) 명령줄에서 다음을 합니다.

Scalable Platform Security Group(VS0)에서 설정

Security Group의 VS0은 gClish의 cpconfig나 Expert 모드의 g_all cp_conf corexl 로 설정합니다(후자는 R82 CLI Reference Guide의 "CoreXL Commands > cp_conf corexl" 참고). 절차는 Security Group 명령줄에서 Gaia gClish에 로그인(기본 셸이 Expert면 gclish)한 뒤 cpconfig를 실행하고 위와 같은 메뉴를 따릅니다. 이 경우에도 재부팅은 필요 없습니다.

개별 Virtual System에서 설정

개별 VS는 SmartConsole로 설정합니다. 64비트 Gaia에서는 VS 하나당 최대 32개 CoreXL Firewall 인스턴스를 줄 수 있고, 이 수는 게이트웨이의 물리 코어 수에 제한되지 않습니다. IPv6 인스턴스 수는 IPv4 이하여야 하고 0이어도 되며, 그 VS에 IPv6 주소가 설정된 경우에만 IPv6 인스턴스가 켜집니다.

설정 절차는 관리 서버에 접속해 VS 객체를 더블클릭하고, 왼쪽 트리에서 CoreXL을 골라 인스턴스 수를 선택한 뒤 OK하고 Access Control 정책을 설치하는 것입니다.

Virtual System과 Virtual Router는 OSPF·BGP 같은 동적 라우팅 프로토콜로 서로, 그리고 외부 라우터·기기와 경로를 주고받을 수 있습니다. VSX는 이를 위해 Gaia 라우팅 데몬(routed)을 쓰며, 각 가상 장치가 자기만의 동적 라우팅 인스턴스와 설정 파일을 가집니다. Warp Link도 일반 인터페이스와 같은 방식으로 설정하고, 클러스터라면 멤버마다 따로 설정할 수 있습니다.

설정은 게이트웨이(각 클러스터 멤버) 명령줄에서 Gaia Clish(Scalable Platform은 gClish)에 로그인한 뒤, set virtual-system <VSID>로 대상 장치 컨텍스트에 들어가 라우팅 데몬 명령을 실행하고 save config로 저장합니다. 구체적 구문은 R82 Gaia Advanced Routing Administration Guide를 참고합니다.

set virtual-system <VSID>    # 대상 가상 장치 컨텍스트
# (OSPF/BGP 등 라우팅 데몬 명령 — 구문은 Gaia Advanced Routing Guide)
save config

VSX Gateway·Virtual Router·Virtual Switch는 적어도 하나의 인터페이스 정의를 가지며, 보통 토폴로지를 설정할 때 함께 정의합니다. Warp 인터페이스는 가상 장치 정의에 따라 자동 생성되며 수정·삭제할 수 없습니다. 인터페이스를 추가할 때는 가상 장치 객체의 Topology에서 New로 Regular(물리)·Leads to Virtual Router·Leads to Virtual Switch 중 하나를 골라 Interface Properties 창에서 속성을 정하고, OK 후 Access Control 정책을 설치합니다. 기존 인터페이스를 바꾸려면 Interfaces 영역에서 인터페이스를 더블클릭해 수정하고, 삭제하려면 선택 후 Delete한 뒤 정책을 설치합니다.

General 탭 — 연결 속성

Virtual Router/Switch로 가는 인터페이스(Leads to)는 속성이 조금 다릅니다. Leads to에서 대상 Virtual Router/Switch를 고르고 그 인터페이스의 전용 VS IP 주소를 입력하는데, 넷마스크는 항상 IPv4 255.255.255.255, IPv6 /128로 고정됩니다. MTU의 허용 범위는 IPv6는 1280~16000, IPv4는 68~16000 입니다.

Topology 탭 — 인터페이스 토폴로지

인터페이스 유형에 따라 다음 속성을 바꿀 수 있습니다.

Anti-Spoofing (스푸핑 방지)

Anti-Spoofing 은 공격자가 높은 권한을 가진 신뢰된 출발지 IP를 위조("spoofing")해 보호망에 침투하는 것을 막습니다. 내부 인터페이스를 포함해 VSX Gateway·Virtual System에 설정하는 것이 중요하며, 토폴로지가 제대로 정의돼 있어야 켤 수 있습니다. 동적 라우팅을 쓴다면 "Calculate topology automatically based on routing information"를 끄고 VS 토폴로지를 직접 설정합니다. 켜려면 Interface Properties의 Topology 탭에서 Perform Anti-Spoofing based on interface topology를 고르고 추적(tracking) 옵션을 설정합니다.

Multicast Restrictions (멀티캐스트 제한)

IP 멀티캐스트 애플리케이션은 패킷 한 부를 만들어 수신을 원하는 컴퓨터 그룹에 주소를 매깁니다. 멀티캐스트 제한 은 특정 멀티캐스트 그룹(IP 주소 범위)으로 나가는 패킷을 차단하는 규칙으로, 물리·Warp 인터페이스 모두에 정의할 수 있습니다. 멀티캐스트 주소 범위는 다음과 같습니다.

켜는 절차는 Interface Properties의 Multicast Restrictions 탭에서 Drop multicast packets by the following conditions를 고른 뒤, 제한 유형(목록에 든 목적지를 차단 / 목록에 든 목적지만 빼고 모두 차단)을 정하고, Add > New > Multicast Address Range로 이름·유형(IP Address Range면 First·Last IP)을 설정합니다. 그런 다음 추적 옵션을 고르고 OK하며, 마지막으로 Access Control 정책에 그 멀티캐스트 그룹 트래픽을 허용하는 규칙을 추가합니다.

VSX도 일반 게이트웨이처럼 여러 인증 스킴을 씁니다. 인증 스킴은 사용자 이름·암호로 유효한 사용자를 식별하며, 일부는 로컬에 저장되고 일부는 외부 서버에 정보를 둡니다.

자세한 인증 방법 구성은 R82 Security Management Administration Guide의 "Configuring Authentication Methods for Users"를 참고합니다. MDS라면 해당 VS를 관리하는 Target Domain Management Server에서 인증 설정을 합니다.

RADIUS / TACACS 인증 구성

VS와 RADIUS·TACACS/TACACS+ 서버를 잇는 방식은 두 가지입니다.

Shared 구성 — 각 VS 객체에서 Other > Authentication으로 가 RADIUS 또는 TACACS와 Shared가 선택돼 있는지 확인하고 정책을 설치합니다(모든 VS에 반복). 클러스터라면 Hide NAT을 꺼야 합니다. 그 관리 서버(MDS라면 Target Domain Management Server)에서 적절한 table.def 파일을 편집해(sk98339), no_hide_services_ports 파라미터에 RADIUS(UDP 1645)나 TACACS/TACACS+(49) 포트가 들어 있게 합니다.

no_hide_services_ports = { <49, 6>, <49, 17>, <500, 17>, <259, 17>, <1701, 17>, <123, 17>, <1645, 17> };

Private 구성 — Active·Standby VS가 같은 암호화 키로 인증하며, HA에서는 각 멤버의 Active·Standby VS가 같은 VIP를 써야 합니다. VSX Gateway 객체에서 Other > Legacy Authentication으로 가 RADIUS/TACACS를 선택하고 정책을 설치합니다. 클러스터라면 Hide NAT을 켜고, table.def의 no_hide_services_ports에서 그 포트들(1645, 49)을 빼 둡니다.

no_hide_services_ports = { <500, 17>, <259, 17>, <1701, 17>, <123, 17> };

RSA SecurID 인증 구성

SecurID도 Shared와 Private이 있습니다.

큰 흐름은 세 부분입니다. (예: 클러스터에 멤버 3개, 멤버마다 VS 5개라면 — Shared는 멤버 수만큼 sdconf.rec 3개, Private은 VS 수만큼 5개를 생성)

Part 1 — sdconf.rec 생성 — RSA Authentication Manager에서 적절한 MIP(Shared는 각 멤버의 MIP, Private은 각 VS의 MIP)로 sdconf.rec를 만듭니다.

Part 2 — VS별 인증 설정 — 각 VS 객체에서 Other > Legacy Authentication으로 가 SecurID와 Shared(또는 Private)를 고르고 정책을 설치합니다. 그런 다음 각 VS에 MIP를 담은 sdopts.rec 파일을 만듭니다. 게이트웨이(각 클러스터 멤버) Expert 모드에서 vsenv로 컨텍스트를 옮기며(Scalable Platform은 g_all vsenv) 작업하는데, Shared는 VS0에서 /var/ace/sdopts.rec를 만들어 CLIENT_IP=<게이트웨이/멤버 인터페이스 IP>를 넣고 각 VS의 $FWDIR/conf/로 복사하며, Private은 각 VS 컨텍스트에서 $FWDIR/conf/sdopts.rec를 만들어 CLIENT_IP=<VS 인터페이스 IP>를 넣습니다.

# (예: 특정 VS 컨텍스트에서)
vsenv <VSID>
touch $FWDIR/conf/sdopts.rec
vi $FWDIR/conf/sdopts.rec          # CLIENT_IP=<...> 한 줄 추가
# Scalable Platform이면 모든 멤버로 복사:
asg_cp2blades $FWDIR/conf/sdopts.rec

이어서 sdconf.rec를 적절한 위치로 복사합니다 — VS0용은 /var/ace/에, 다른 VS용은 임시 디렉터리(예: /var/tmp/)에 둔 뒤 vsenv <VSID>로 컨텍스트를 옮겨 $FWDIR/conf/로 복사합니다(Scalable Platform은 asg_cp2blades로 모든 멤버에 뿌린 뒤 g_all 접두로 복사).

클러스터라면 UDP 5500 포트의 Hide NAT 처리를 서버 기대값에 맞춥니다. 관리 서버 Expert 모드에서 table.def를 편집해, 서버가 각 멤버(또는 각 VS)로부터의 연결을 기대하면 <5500, 17>을 포함시키고, 클러스터/VS의 VIP로부터의 연결을 기대하면 <5500, 17>을 빼 둔 뒤 정책을 설치합니다(table.def 경로는 sk·관리 가이드의 "Location of 'table.def' Files" 참고).

# 멤버/VS에서 직접 오는 연결을 기대할 때
no_hide_services_ports = { <500, 17>, <259, 17>, <1701, 17>, <123, 17>, <5500, 17> };
# VIP에서 오는 연결을 기대할 때
no_hide_services_ports = { <500, 17>, <259, 17>, <1701, 17>, <123, 17> };

Part 3 — 노드 시크릿 배포 — VSX Gateway/멤버가 SecurID 서버에 처음 인증할 때 서버가 노드 시크릿 파일 securid를 보내 줍니다. 이를 모든 VS로 복사해야 합니다. SecurID 사용자 계정으로 게이트웨이에 인증해 securid를 받은 뒤, find /var/ace/ -name securid -type f로 찾고, (Scalable Platform이면 asg_cp2blades /var/ace/securid로 모든 멤버에 복사한 뒤) vsenv <VSID>로 각 VS 컨텍스트에 들어가 cp -v /var/ace/securid $FWDIR/conf/로 복사합니다. 클러스터라면 각 멤버에서 그 멤버에 Active인 VS를 찾아 이 과정을 수행하고, Active VS가 없으면 해당 멤버로 페일오버한 뒤 진행합니다.

SmartConsole의 Logs & Events에서 모든 게이트웨이·VSX Gateway·가상 장치의 상태를 볼 수 있는데, 가상 장치의 전체(Overall) 상태는 그 Software Blade들 중 가장 심각한 상태로 결정됩니다. 예컨대 다른 Blade가 다 OK라도 SmartEvent Blade가 Problem이면 전체가 Problem입니다.

단일 VSX Gateway에서

관리 서버에 접속해 VS 객체를 열고 NAT > Advanced에서 다음을 합니다.

VSX Cluster에서 — VS 자신의 트래픽 Hide NAT

클러스터에는 특수한 경우가 있습니다. VS 자신이 만들어 내는 트래픽(예: Anti-Bot 시그니처 업데이트)을 Hide NAT 해 외부 자원에 접속하게 하는 경우입니다. 각 클러스터 멤버 Expert 모드에서 작업합니다.

VSX에서도 Application Control·URL Filtering·Threat Prevention 같은 상위 보안 Blade를 VS별로 켤 수 있습니다(sk106496, sk79700). 기본 동작과 정책 구성은 물리 게이트웨이와 같지만, 공통 전제가 있습니다. VS0(VSX Gateway/클러스터 멤버)의 라우팅·DNS·프록시 설정이 올바라야 하고, VSX Gateway/클러스터와 VS가 인터넷에 연결될 수 있어야 합니다. VS는 업데이트를 VS0를 통해 받습니다.

Application Control / URL Filtering

이 두 Blade는 VSX Gateway/클러스터 객체 자체에는 켜지 말아야 합니다. 켜는 것은 개별 VS입니다.

Threat Prevention (Anti-Bot, Anti-Virus, IPS)

이들은 VS0가 모든 VS의 계약 검증을 담당하므로, VSX Gateway/클러스터 객체와 해당 VS 양쪽 모두에 켜고 구성해야 합니다. VS0가 인터넷 연결에 실패하면 각 VS는 자기 프록시 설정으로 직접 업데이트를 받습니다.

Threat Emulation

필요하면 프록시를 설정한 뒤, 각 VS 객체의 Custom Threat Prevention 탭에서 SandBlast Threat Emulation을 고릅니다. First Time Activation 마법사에서 Emulation Location을 정하고 Threat Extraction 활성화 설정을 거쳐 Finish, Blade를 설정하고 OK합니다. 그런 다음 각 VS의 Threat Prevention 정책을 구성·설치합니다(필요하면 Access Control 정책도).

Threat Extraction

필요하면 프록시를 설정한 뒤, 각 VS 객체의 Threat Prevention 탭에서 SandBlast Threat Extraction을 고르고 OK합니다. Threat Extraction을 켜면 HTTP·HTTPS 웹 트래픽 지원이 자동으로 켜지며, 이메일 첨부도 검사하려면 게이트웨이를 MTA(Mail Transfer Agent)로 구성합니다(R82 Threat Prevention Administration Guide의 "Mail Transfer Agent"). VS0와 각 VS의 정책을 구성한 뒤, 기본 VSX 정책 <...>_VSX 를 VSX Gateway/클러스터에 설치하고, Threat Prevention 정책을 VS0와 각 VS에 설치합니다.

이처럼 각 VS가 독립 정책을 갖는다는 VSX의 원리 덕분에, 테넌트나 부서마다 서로 다른 위협 방어 정책을 줄 수 있습니다.

Check Point 소프트웨어는 라이선스 키로 활성화됩니다. 소프트웨어 미디어 팩 뒷면의 인증서 키(certificate key)를 Check Point User Center에 등록하면, 평가·구매하는 제품용 라이선스 키가 생성됩니다(구매는 리셀러에게 문의).

VSX 라이선스 — 각 VSX Gateway·VSX Cluster 멤버는 자기 IP에 묶인 별도 라이선스가 필요하며, 이 라이선스는 정해진 수의 Virtual System을 포함합니다. VSX 라이선스는 Security Gateway 라이선스(컨테이너와 Software Blade)에 더해 적용됩니다. 게이트웨이가 허용하는 VS 수는 vsx stat의 "Number of Virtual Systems allowed by license" 값으로 확인하며, 0보다 커야 정책 설치가 됩니다. 라이선스가 없거나 유효하지 않으면 VSX 생성 마법사에서 정책 설치 오류가 나므로, 관리 서버에서 cplic check로 확인하고 각 게이트웨이·멤버마다 유효한 VSX 라이선스를 설치합니다. NGSM 라이선스 카운팅 방식은 sk119075를 참고합니다.

라이선스 업그레이드 — R82로 업그레이드하기 전에 소프트웨어 업그레이드와 메이저 릴리스를 포함하는 유효한 지원 계약 이 User Center 계정에 등록돼 있어야 합니다. 관리 서버는 계약 파일을 저장했다가 업그레이드 때 게이트웨이로 내려보내며, 이 파일이 현재 라이선싱 표준 준수를 보장합니다.

평가 기간(Trial Period) — 제품을 처음 설치하면 15일간 완전 기능 평가 기간 이 주어집니다. 기간이 끝나면 영구 라이선스를 구매·설치해야 하며, 평가 기간 동안에는 최대 25개의 Virtual System 을 구성할 수 있습니다.