07VSX 구성하기Configuring VSX

새 VSX Gateway는 VSX Gateway Wizard로 만듭니다. 먼저 알아둘 제약은 기존 Security Gateway를 VSX Gateway로, 또는 그 반대로 변환할 수 없다는 것입니다. SmartConsole에서 New > VSX > Gateway로 마법사를 시작하면 다섯 단계를 거칩니다.

1단계 General Properties에서는 VSX Gateway 이름(공백·특수문자 불가, 밑줄만 허용)과 관리 인터페이스 주소, 설치된 VSX 버전을 정합니다(IPv6를 주면 IPv4도 함께 줘야 합니다). 2단계 SIC 신뢰 설정에서는 Gaia 최초 설정 때 입력한 활성화 키를 똑같이 입력하고 Initialize를 누르는데, 키가 맞으면 Trust State가 "Trust established"로 바뀝니다. 신뢰가 안 맺어지면 Check SIC Status로 원인을 보는데, 대개 활성화 키 오류나 관리 서버-게이트웨이 간 연결 문제입니다.

3단계 물리 인터페이스 정의에서는 어느 인터페이스를 VLAN 트렁크로 쓸지 지정하고, 4단계 가상 네트워크 장치 구성에서는 게이트웨이와 인터페이스를 공유하는 가상 장치를 정의할 수 있습니다. 여기서 DMI냐 Non-DMI냐가 결정되는데, 이 설정은 마법사를 마친 뒤에는 바꿀 수 없습니다. 공유 가상 장치를 정의하지 않으면 기본적으로 DMI VSX Gateway가 만들어지며(Non-DMI는 폐기됨), 5단계 VSX Gateway Management에서는 게이트웨이 자신을 보호하는 정책 규칙을 정합니다. 이 정책은 오직 게이트웨이로 향하는 트래픽에만 적용되고 SNMP·SSH·ICMP(ping)·HTTPS 서비스에 대한 사전 정의 규칙으로 구성되는데, 기본적으로 모두 차단이라 예컨대 관리 서버에서 ping하려면 ICMP를 허용해야 합니다. 마법사를 마치면 완료까지 몇 분 걸릴 수 있습니다.

만든 뒤에는 객체를 더블클릭해 VSX Gateway Properties에서 토폴로지와 여러 속성을 바꿉니다. General Properties에서 SIC를 확인·재설정하고 이 게이트웨이에 설치할 Software Blade를 고릅니다. SIC를 리셋할 때는 게이트웨이 CLI에서 cpconfig로 SIC를 재초기화하고 Communication 창에서 Reset 후 다시 Initialize한 다음, <게이트웨이명>_VSX 정책을 설치하고 게이트웨이에서 cpstop;cpstart를 실행합니다.

Physical Interfaces 페이지에서 물리 인터페이스를 추가·제거하거나 VLAN 트렁크를 지정하고, Topology 페이지에서 인터페이스와 라우트를 정의합니다. 라우트를 추가할 때 Propagate route to adjacent Virtual Devices를 켜면 이웃 가상 장치에 경로를 알려 연결을 활성화하며, 토폴로지 자동 계산 옵션은 기본 켜짐이지만 동적 라우팅을 쓸 때는 끄는 것이 권장되고 Bridge 모드에서는 쓸 수 없습니다. VSX Gateway 객체를 삭제하면 그에 딸린 모든 Virtual System과 가상 장치가 관리 DB에서 함께 삭제됩니다. 장애에 대비한 백업·복원은 sk100395를 따릅니다.

Virtual System은 Virtual Systems Wizard로 만듭니다. 전형적인 VS는 외부망·DMZ·인터넷으로 가는 외부 인터페이스와, 보통 VLAN 트렁크로 내부망에 닿는 내부 인터페이스, 이렇게 두 개를 가집니다.

마법사의 General Properties에서 이름과 호스팅 VSX Gateway를 고르고 필요하면 Bridge Mode를 선택합니다. Network Configuration에서는 내·외부 인터페이스와 내부 인터페이스 뒤의 IP 토폴로지를 정의하는데, Main IP Address는 보통 외부 인터페이스에 배정되며 NAT나 VPN 연결에 쓰이는 VS 주소가 됩니다. 만든 뒤에는 Access Control 정책을 설치해야 합니다.

수정은 객체를 더블클릭해 합니다(이름만은 바꿀 수 없습니다). Topology 페이지에서 인터페이스를 추가할 때 Regular(물리), Leads to Virtual Router, Leads to Virtual Switch, Bridge 중에서 고르며, 이 인터페이스 설정을 바탕으로 VSX가 가상 장치와 게이트웨이로 가는 라우트를 자동 생성합니다. 클러스터 환경에서 특정 VS의 토폴로지를 바꾸면 그 VS에 정책을 설치해야 클러스터 토폴로지가 갱신된다는 점에 주의합니다. VPN을 켰다면 VPN Domain에서 그 VS 뒤의 어떤 호스트들이 VPN 터널로 통신할지 정하고, NAT > Advanced에서 그 VS에서 나오는 패킷에 Hide NAT이나 Static NAT을 설정합니다.

R81.10부터는 일반(L3) Virtual System에도 브리지 인터페이스를 추가할 수 있고, IP 없이 브리지 인터페이스만 가진 VS도 만들 수 있습니다. Topology에서 New > Bridge를 골라 두 종속 인터페이스(예: eth2, eth3)를 차례로 지정하면 됩니다. Bridge 모드의 동작 원리와 Multi Bridge는 Bridge 모드 장에서 자세히 다룹니다.

R82에서는 Virtual System마다 별도의 DNS 설정을 줄 수 있습니다. 게이트웨이 CLI(Gaia Clish, Scalable Platform은 gClish)에서 먼저 set dns mode per-vs로 기능을 켜고, set virtual-system <VSID>로 대상 VS 컨텍스트에 들어간 뒤 DNS 서버와 suffix를 설정합니다. 특정 도메인만 다른 DNS로 보내는 forwarding domain이나, VS를 DNS Relay로 동작시키는 listening-interface 설정도 같은 방식으로 추가합니다. DHCP 서버도 set virtual-system <VSID>로 컨텍스트를 바꾼 뒤 R82 Gaia Administration Guide의 DHCP 절차대로 설정합니다. 이처럼 CLI 작업은 늘 "지금 어느 VS 컨텍스트인가"가 중요한데, Expert 모드에서는 set virtual-system 대신 vsenv로 컨텍스트를 전환합니다.

set dns mode per-vs              # VS별 DNS 기능 켜기
set virtual-system 1             # 대상 VS 컨텍스트
set dns primary 192.168.10.21
set dns suffix mycompany.com
add dns proxy forwarding-domain anothercompany.com   # 특정 도메인만 다른 DNS
add dns proxy listening-interface wrp128             # DNS Relay로 동작
save config

Virtual Switch는 VS들과 내·외부 네트워크 사이에 L2 연결을 제공하며 물리 스위치처럼 포워딩 테이블을 유지합니다. Virtual Switch Wizard로 이름과 호스팅 게이트웨이를 정하고 연결할 인터페이스를 추가하면 만들어집니다.

Topology에서는 정의된 단일 인터페이스만 수정할 수 있고 Warp 인터페이스 설정은 바꿀 수 없습니다. 삭제할 때는 먼저 모든 인터페이스를 제거한 뒤 객체를 삭제합니다.

Virtual Router는 물리 라우터처럼 동작하며 여러 VS의 공유 회선이나 VS 간 라우팅에 씁니다(앞서 여러 번 언급한 대로 Maestro·Scalable Chassis에서는 지원되지 않습니다). 외부망·인터넷으로 향하면 외부 Virtual Router, 내부 보호망으로 향하면 내부 Virtual Router라 부르는데, 외부 Virtual Router는 여러 VS가 하나의 보안 물리 인터페이스를 공유해 인터넷으로 나가는 공용 게이트웨이 역할을 합니다.

Virtual Router Wizard로 이름·호스팅 게이트웨이를 정하고 인터페이스와 라우트(필요하면 기본 라우트)를 추가해 만들며, Topology의 Routes에서 Warp Link 라우트는 자동 생성되어 수정·삭제할 수 없고 그 외 라우트만 손댑니다. 만든 뒤에는 각 VS에 Virtual Router로 가는 인터페이스를 추가해 연결합니다.

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

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

덕분에 VLAN 없이 단일 물리 인터페이스만으로도 출발지에 따라 알맞은 VS로 트래픽을 보낼 수 있습니다. 설정은 Virtual Router 객체의 Topology 페이지에서 Advanced Routing 을 열어, 규칙마다 출발지 IP·넷마스크, 목적지 IP·넷마스크, next hop 게이트웨이를 지정하는 식입니다. 이 절차는 VSX Gateway든 VSX Cluster든 동일합니다.

VSX에서 중요한 점은 VS0(게이트웨이)과 나머지 Virtual System의 설정 방법이 다르다는 것입니다. VS0은 CLI(cpconfig의 Configure Check Point CoreXL)로, 개별 Virtual System은 SmartConsole(객체 > CoreXL)로 인스턴스 수를 정합니다. Scalable Platform Security Group은 gClish의 cpconfig나 Expert 모드의 g_all cp_conf corexl로 설정합니다.

여기에는 반드시 알아야 할 비용이 있습니다. CoreXL 인스턴스 하나하나가 추가 메모리를 쓰므로, 인스턴스 5개짜리 VS는 별도 VS 5개와 비슷한 메모리를 먹습니다(VS별 CPU·메모리 사용량을 보는 방법은 VSX 성능 최적화 장 참고). 그래서 인스턴스 수는 그 VS의 예상 트래픽에 맞춰 정하고 물리 코어 수를 넘기지 않는 것이 권장됩니다. 또 IPv6 인스턴스 수는 IPv4 인스턴스 수를 넘을 수 없고, VS의 인스턴스 수를 바꾸면 그 VS에 약간의 다운타임이 생깁니다. 한편 VS0에 CoreXL을 켜는 것은 권장되지 않는데, VS0의 주 역할이 게이트웨이 관리라 인스턴스 하나로 충분하고 메모리 부담만 늘기 때문입니다. VS0의 CoreXL 변경은 재부팅이 필요 없지만, 상위 버전으로 업그레이드한 뒤에는 VS0 컨텍스트에서 fw ctl affinity -vsx_factory_defaults로 어피니티를 기본값으로 되돌리고 재부팅하는 것이 좋습니다.

Virtual System과 Virtual Router는 OSPF·BGP 같은 동적 라우팅 프로토콜로 서로, 그리고 외부 라우터와 경로를 주고받을 수 있습니다. VSX는 이를 위해 Gaia 라우팅 데몬(routed)을 쓰며, 각 가상 장치가 자기만의 동적 라우팅 인스턴스와 설정 파일을 가집니다. 설정은 게이트웨이 CLI(Gaia Clish, Scalable Platform은 gClish)에서 set virtual-system <VSID>로 대상 장치 컨텍스트에 들어간 뒤 라우팅 데몬 명령을 실행하고 save config로 저장합니다. 단 정적 라우트는 반드시 SmartConsole의 객체에서만 설정해야 하고, 클러스터라면 모든 멤버를 동일하게 맞춰야 합니다.

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 중 하나를 고릅니다. General 탭에서 물리 인터페이스·VLAN 태그·IP·넷마스크·MTU(기본 1500)를 정하고, Virtual Router/Switch로 가는 인터페이스는 넷마스크가 항상 IPv4 255.255.255.255(IPv6 /128) 로 고정됩니다. 여기서도 Propagate route 옵션으로 이웃 장치에 경로를 알릴 수 있습니다.

인터페이스에는 보안 설정도 붙습니다. Anti-Spoofing(스푸핑 방지) 은 신뢰된 출발지 IP를 위조해 들어오는 공격을 막는 것으로, 토폴로지가 제대로 정의돼 있으면 인터페이스의 Topology 탭에서 "Perform Anti-Spoofing based on interface topology"로 켭니다(동적 라우팅을 쓴다면 토폴로지 자동 계산을 끄고 수동으로 정의해야 합니다). 멀티캐스트 제한 은 특정 멀티캐스트 그룹(IPv4 224.0.0.0~239.255.255.255 등)으로 나가는 패킷을 차단하는 규칙으로, 인터페이스의 Multicast Restrictions 탭에서 허용/차단 목록을 정의합니다.

VSX도 일반 게이트웨이처럼 여러 인증 스킴을 씁니다. Check Point 비밀번호와 OS 비밀번호는 로컬에 저장되고, RADIUS·TACACS는 외부 서버에 인증을 맡기며, SecurID는 토큰이 만드는 일회용 비밀번호를 RSA Authentication Manager로 검증합니다.

RADIUS·TACACS 설정에는 두 가지 방식이 있습니다. Shared(공유, 기본값) 는 모든 VS가 VSX Gateway를 통해 인증 서버에 연결하고, Private(개별) 은 각 VS가 자기 클러스터 IP를 출발지로 직접 연결합니다. SmartConsole에서 VS 객체의 Other > Authentication(개별은 Legacy Authentication)에서 방식을 고른 뒤 정책을 설치하는데, 클러스터에서는 Hide NAT 설정이 핵심입니다. Shared는 Hide NAT을 꺼야 하고, table.def의 no_hide_services_ports에 RADIUS(UDP 1645)나 TACACS(49) 포트를 넣어 줍니다(sk98339). Private은 반대로 Hide NAT을 켜고 그 포트들을 빼 둡니다. MDS라면 이 설정을 해당 VS를 관리하는 Target Domain Management Server에서 해야 합니다.

RSA SecurID도 Shared와 Private이 있습니다. Shared는 멤버 단위로 sdconf.rec(암호화 키)와 securid(노드 시크릿) 파일을 쓰고, Private은 VS마다 고유한 sdconf.rec와 securid를 씁니다. 큰 흐름은 RSA Authentication Manager에서 해당 MIP(Member IP)로 sdconf.rec를 생성해 각 VS 컨텍스트의 $FWDIR/conf/에 복사하고, SmartConsole에서 VS 객체에 SecurID를 선택해 정책을 설치한 뒤, 최초 인증 때 서버가 보내 준 노드 시크릿 파일 securid를 모든 VS 컨텍스트로 복사하는 것입니다. 클러스터에서는 UDP 5500 포트의 Hide NAT 처리(no_hide_services_ports)를 서버 기대값에 맞춰 설정합니다.

SmartConsole의 Logs & Events에서 모든 게이트웨이·가상 장치의 상태를 볼 수 있는데, 가상 장치의 전체 상태는 그 Software Blade들 중 가장 심각한 상태로 결정됩니다. 예컨대 다른 Blade가 다 OK라도 하나가 Problem이면 전체가 Problem입니다. 상태는 정상인 OK, 사소한 문제가 있지만 동작하는 Attention, Blade 오작동이나 미설치를 뜻하는 Problem, 데이터를 기다리는 Waiting, 도달 불가인 Disconnected, 그리고 SIC가 안 맺어진 Untrusted 로 나뉩니다.

단일 게이트웨이에서는 VS 객체의 NAT > Advanced에서 Add Automatic Address Translation을 켜고 Hide(게이트웨이 뒤로 숨기기 또는 라우팅 가능한 가상 IP 뒤로 숨기기)나 Static(사설↔공인 1:1 변환) 을 고른 뒤 정책을 설치하면 됩니다.

클러스터에서는 한 가지 특수한 경우가 있습니다. VS 자신이 만들어 내는 트래픽(예: Anti-Bot 시그니처 업데이트)을 Hide NAT 하려면, 먼저 그 VS 컨텍스트에서 fw getifs로 Funny IP(클러스터 내부 통신망에 속한 IP) 를 알아낸 다음, SmartConsole에서 Funny IP를 가진 Node Host와 NATed IP를 가진 Node Host 객체를 만들고, NAT 정책에 그 VS 트래픽을 NATed IP 뒤로 숨기는 규칙을 추가해 정책을 설치합니다.

VSX에서도 Application Control·URL Filtering·Threat Prevention 같은 상위 보안 Blade를 VS별로 켤 수 있습니다(sk106496, sk79700). 기본 동작과 정책 구성은 물리 게이트웨이와 같지만, 두 가지 전제가 중요합니다. 하나는 VS0(VSX Gateway/클러스터 멤버)의 라우팅·DNS·프록시 설정이 올바라야 한다는 것이고, 다른 하나는 이 Blade들을 VSX Gateway나 클러스터 객체 자체에는 켜지 말아야 한다는 것입니다. 켜는 것은 어디까지나 개별 Virtual System입니다. 각 VS가 독립 정책을 갖는다는 VSX의 원리 덕분에, 테넌트나 부서마다 서로 다른 위협 방어 정책을 줄 수 있습니다.

마지막은 라이선스입니다. VSX는 게이트웨이가 허용하는 Virtual System 수가 라이선스로 카운팅되며, 이를 vsx stat의 "Number of Virtual Systems allowed by license" 값으로 확인할 수 있습니다(0보다 커야 정책 설치가 됩니다). 라이선스가 없거나 유효하지 않으면 VSX 생성 마법사에서 정책 설치 오류가 나므로, 관리 서버에서 cplic check로 필요한 라이선스를 확인하고 각 VSX Gateway·클러스터 멤버마다 유효한 VSX 라이선스를 설치해야 합니다. VSX/VSNext의 NGSM 라이선스 카운팅 방식은 sk119075를 참고합니다.