08고급 기능·절차고급 기능·절차

왜 VMAC이 필요한가 — G-ARP의 한계

대부분의 스위치는 네트워크에 연결된 호스트 정보를 ARP Request·ARP Reply 로부터 배웁니다. ClusterXL은 이 동작에 기대어, 클러스터 인터페이스에서 연결된 네트워크로 Gratuitous ARP Request(G-ARP 갱신) 를 보냅니다. 그러면 스위치·호스트·라우터가 자기 ARP 테이블을 갱신해 Cluster Virtual IP(VIP)와 그에 대응하는 MAC 주소 를 학습합니다.

Check Point 클러스터에서 G-ARP가 어떻게 동작하는지 정리하면 이렇습니다.

문제는 스위치·호스트 쪽 에서 생깁니다.

Check Point의 해법 — VMAC 모드

이런 스위치를 다루려면, Cluster Member가 클러스터 인터페이스의 G-ARP 갱신에서 실제 MAC 대신 Virtual MAC(VMAC) 주소 를 쓰도록 구성하면 됩니다. 이러면 그런 "똑똑한" 스위치는 ARP 캐시를 갱신할 필요가 없습니다.

클러스터 객체에서 VMAC 모드를 켜면, 모든 Cluster Member가 자기 VIP에 대해 VMAC 주소를 출발지로 한 G-ARP 를 보냅니다. 각 멤버는 VIP마다 하나의 VMAC 을 만듭니다.

예를 들어 보겠습니다.

이렇게 하면 페일오버 때 NAT된 IP 주소에 대한 G-ARP 갱신이 불필요해져, 트래픽 단절 가능성이 줄어 듭니다.

Active/Pivot 멤버에서 나가는 트래픽의 출발지 주소는 이렇습니다.

네트워크의 호스트가 Cluster Member 쪽으로 보내는 트래픽의 주소는 이렇습니다.

VMAC 모드의 알려진 제약

  show cluster members interfaces virtual
  

  cphaprob -a if
  

VMAC 모드 켜기

VMAC 모드는 SmartConsole 에서 구성하며, 각 멤버의 명령줄에서도 제어할 수 있습니다.

SmartConsole에서 구성:

각 멤버 명령줄에서 구성(대안): 현재 커널 파라미터 값을 보려면 각 멤버에서 다음을 실행합니다.

fw ctl get int fwha_vmac_global_param_enabled

   fw ctl set int fwha_vmac_global_param_enabled 0
   

   fw ctl set int fwha_vmac_global_param_enabled 1
   

VMAC 값은 어떻게 만들어지나

VMAC은 총 48비트이며, 왼쪽부터 다음과 같이 구성됩니다.

VMAC 모니터링

     show cluster members interfaces virtual
     

     cphaprob -a if
     

Same VMAC과 Silent Standby

VMAC 모드는 Gratuitous ARP 패킷에만 적용되고, 멤버가 트래픽을 전달할 때는 여전히 실제 MAC을 씁니다. 그런데 일부 Layer 3 스위치는 도착하는 트래픽의 출발지 IP·출발지 MAC 으로부터 호스트를 학습합니다. 그런 "똑똑한" 스위치에서 IP-MAC 연결이 자주 바뀌면, 스위치는 그 IP를 "수상한(rogue)" 주소로 간주해 ARP 갱신을 막고 현재 연결을 동결시킬 수 있습니다.

이러면 트래픽 단절이 생깁니다. 멤버들이 같은 출발지 IP 에서 트래픽을 보내지만 출발지 MAC이 다르기 때문입니다(G-ARP에서는 VMAC, 일반 트래픽에서는 실제 MAC).

해법은 Same VMAC 입니다. 같은 서브넷에 속한 클러스터 인터페이스들이 실제 MAC 대신 동일한 VMAC 을 쓰게 하면, 스위치는 항상 같은 출발지 IP·같은 출발지 MAC에서 오는 트래픽을 봅니다.

예: Member_1의 eth1과 Member_2의 eth1이 똑같은 VMAC 을 갖습니다.

Same VMAC의 알려진 제약:

Same VMAC과 Silent Standby 켜기

각 멤버 명령줄에서 Expert mode로 들어간 뒤 다음을 진행합니다.

   fw ctl set -f int fwha_alter_vmac_param 1
   

   fw ctl set -f int fwha_silent_standby_mode 1
   

a. 설정 파일이 있는지 확인합니다.

   ls -l $FWDIR/conf/cpha_link_monitoring.conf
   

     cp -v $FWDIR/conf/cpha_link_monitoring.conf{,_BKP}
     

     touch $FWDIR/conf/cpha_link_monitoring.conf
     

b. 설정 파일에 값 all 만 넣습니다.

   echo all > $FWDIR/conf/cpha_link_monitoring.conf
   

Same VMAC과 Silent Standby 끄기: 각 멤버 Expert mode에서 다음을 실행하고, 마지막으로 SmartConsole에서 Use Virtual MAC 선택을 해제한 뒤 정책을 설치합니다.

fw ctl set -f int fwha_alter_vmac_param 0
fw ctl set -f int fwha_silent_standby_mode 0
echo '' > $FWDIR/conf/cpha_link_monitoring.conf

Same VMAC 모니터링: 앞의 VMAC 모니터링처럼 show cluster members interfaces virtual(Clish) 또는 cphaprob -a if(Expert)로 VMAC을 확인하고, 호스트 ARP 테이블에 VMAC이 들어 있는지 점검합니다. Same VMAC으로 인해 클러스터 인터페이스에 실린 MAC 자체를 보려면 다음을 씁니다.

show interfaces all
show interface <물리 인터페이스 이름><SPACE><TAB>

Expert mode에서는 ifconfig 입니다.

클러스터에 VPN 구성하기

클러스터에 VPN을 구성하는 일은 단일 Security Gateway에 구성하는 것과 매우 비슷합니다. VPN의 모든 속성은 Cluster 객체 에 정의하고, 단 두 가지 속성만 각 Cluster Member 객체 에 정의합니다.

별도 Management Server가 관리하는 VPN 피어 클러스터 정의

VPN 피어가 다른 Management Server가 관리하는 Check Point Cluster라면, 또 다른 클러스터 객체를 만들지 마세요. 대신 이렇게 합니다.

Cluster Fold와 Cluster Hide

NAT(Network Address Translation)는 ClusterXL 동작 방식의 근본적인 한 부분입니다. 클러스터 자체가 두 가지 자동 NAT를 늘 수행합니다.

클러스터에 NAT 구성하기

클러스터에서도 단일 Security Gateway와 똑같이 NAT를 수행할 수 있습니다. 이 NAT는 위의 자동 Cluster Fold·Cluster Hide에 추가로 적용됩니다. NAT를 구성하려면 Cluster 객체 를 편집하고 Cluster Properties 창의 NAT 페이지를 씁니다. Cluster Member 객체의 NAT 탭은 건드리지 마세요.

Cluster Member에 NAT 구성하기

Cluster Member의 비-클러스터(non-cluster) 인터페이스 에 NAT를 수행할 수도 있습니다. 예를 들어 멤버의 비-클러스터 인터페이스가 또 다른 (비-클러스터) 내부 Security Gateway에 연결되어 있고, 그 인터페이스의 주소를 숨기고 싶을 때 유용합니다. 이러면 비-클러스터 인터페이스 뒤(또는 위)에서 출발해 내부 Security Gateway 반대편 호스트로 가는 패킷의 출발지 주소가 번역됩니다.

VLAN 스위치는 어느 VLAN에서 출발한 패킷에 어느 스위치 포트에서 왔는지를 나타내는 4바이트 헤더(태그) 를 붙입니다. 한 VLAN의 스위치 포트에서 다른 VLAN의 포트로는 패킷이 갈 수 없고, 예외는 모든 VLAN에 속하도록 정의된 "global" 포트뿐입니다. Cluster Member는 이 global 포트에 연결되며, 그러면 하나의 물리 포트가 여러 VLAN 포트(각각 멤버의 VLAN 태그 인터페이스에 대응) 로 논리적으로 나뉩니다.

인터페이스에 VLAN 태그를 정의할 때, 클러스터 IP 주소는 VLAN 인터페이스(태그된 인터페이스)에만 정의할 수 있습니다. VLAN을 가진 물리 인터페이스에 클러스터 IP를 두는 것은 지원되지 않으며, 그 물리 인터페이스는 Network Type을 Private 으로 정의해야 합니다.

ClusterXL(VSX 포함)은 동기화 네트워크(Delta Sync 정보를 나르는 CCP 패킷)를 가장 낮은 VLAN ID(VLAN 태그)에서만 지원합니다. 예를 들어 eth1에 ID 10·20·30 세 VLAN이 있으면 State Synchronization에는 eth1.10만 쓸 수 있습니다.

기본 인터페이스 감시는 이렇습니다.

기본 감시는 커널 파라미터로 바꿀 수 있습니다.

이 절차는 Cluster Member가 클러스터 인터페이스에서 CCP 패킷 대신 물리 링크만 감시 하도록 구성합니다.

절차:

Best Practice — 모드별 무중단 적용 순서:

Load Sharing Unicast 모드에서는 기본적으로 다음과 같이 멤버에 트래픽을 배분합니다.

기본 배분 비율을 바꾸려면 다음을 진행합니다.

Bonding(Link Aggregation) 용어

Bond 인터페이스(Link Aggregation)

Check Point 보안 장비는 여러 물리 인터페이스를 하나의 가상 인터페이스(bond 인터페이스)로 묶는 Link Aggregation을 지원합니다. bond 인터페이스는 여러 인터페이스가 부하를 나눠 장애 허용(fault tolerance)과 처리량 증가 를 줍니다. Check Point 장비는 동적 링크 결합을 위해 IEEE 802.3ad Link Aggregation Control Protocol(LACP) 를 지원합니다.

bond 인터페이스(bonding group, bond)는 Bond ID(예: bond1)로 식별되고 IP 주소가 할당됩니다. bond에 포함된 물리 인터페이스는 subordinate interface 라 하며 IP 주소가 없습니다. bond는 다음 두 동작 전략 중 하나를 씁니다.

Bond Load Sharing은 다음 모드 중 하나를 씁니다.

Bonding HA·Load Sharing 모드 공통으로, 정의 가능한 bond 인터페이스 수는 플랫폼별 최대 인터페이스 수로 제한됩니다(R82 Release Notes 참고). 또한 하나의 bond에 물리 하위 인터페이스를 최대 8개 까지 구성할 수 있습니다.

클러스터에서 Bond High Availability 모드

미션 크리티컬 애플리케이션을 다루는 기업은 네트워크가 항상 가용 하기를 요구합니다. 클러스터링은 Security Gateway 수준의 이중화를 제공하지만, Bonding이 없으면 NIC나 게이트웨이 양쪽 스위치의 이중화는 오직 한 멤버에서 다른 멤버로의 페일오버 로만 가능합니다.

Simple Redundant Topology(단순 이중화)

Bonding 없이도 클러스터링만으로 이중화를 얻을 수 있습니다. 스위치나 멤버가 고장 나면 HA 클러스터가 시스템 이중화를 제공합니다. 예를 들어 동기화된 멤버 둘을 단순 이중화 구조로 배치할 수 있습니다.

GW1, 그 NIC, 또는 S1이 고장 나면 GW2가 유일한 Active 멤버가 되어 C2를 거쳐 S2에 연결됩니다. 다만 어느 한 구성요소(멤버·NIC·스위치)가 고장 나 페일오버하면 더 이상 이중화가 남지 않으며, 이후 또 한 번 Active 구성요소가 고장 나면 이 클러스터를 통한 트래픽이 완전히 멈춥니다.

Fully Meshed Redundancy(완전 메시 이중화)

Bonding HA 모드를 ClusterXL과 함께 쓰면, 완전 메시 구조 로 더 세밀한 이중화를 얻어 NIC와 스위치 모두에 독립적인 백업을 둘 수 있습니다 — 사실상 케이블까지 백업하는 셈입니다. 각 멤버는 외부 인터페이스 둘을 두어 각각 다른 스위치에 연결합니다.

멤버에서 외부 스위치로 가는 인터페이스 하나가 고장 나도 다른 인터페이스가 연결성을 이어 줍니다. Bonding이 NIC의 High Availability 를 제공하므로, 하나가 고장 나도 다른 하나가 그 자리를 대신합니다.

High Availability 모드에서의 Bond 페일오버

멤버에 구성된 Bond HA 모드에서 bond 내부 페일오버는 다음 두 경우에 일어납니다.

둘 중 어느 쪽이든, 상황에 따라 bond 내부 또는 멤버 사이에서 페일오버를 일으킵니다. 장애가 감지되면 로그가 기록됩니다 — SmartConsole에서 Management Server에 접속해 왼쪽 패널의 Logs & Events > Logs 에서 확인합니다.

High Availability 모드에서 Bond 인터페이스 구성

각 멤버에서 R82 Gaia Administration Guide 의 Network Management > Network Interfaces > Bond Interfaces (Link Aggregation) 절 지침을 따릅니다.

Bond 인터페이스가 제대로 동작하는지 확인

bond 인터페이스가 UP인지 확인합니다.

VLAN 페일오버 지원

Bonding HA 모드에서 ClusterXL은 VLAN ID의 연결 장애·통신 오류를 감시하고, 장애를 감지하면 페일오버를 시작합니다. VLAN 스위치 환경에서는 가장 낮은 ID의 VLAN 을 감시하며, 일정 간격으로 왕복 경로에 CCP 패킷을 보내 점검합니다. 가장 낮은 VLAN ID가 물리 연결 상태를 대표하므로 항상 감시되고, 연결 장애가 나면 페일오버가 일어납니다. 단 ClusterXL은 스위치 쪽 VLAN 구성 문제까지는 감지하지 못합니다.

Sync Redundancy(동기화 이중화)

여러 물리 동기화 인터페이스(1st·2nd·3rd sync)를 따로따로 동기화 이중화에 쓰는 것은 지원되지 않습니다. 동기화 이중화는 bond 인터페이스로 구현합니다.

요구사항·제약:

Sync High Availability용 bond 구성:

VRRP 클러스터에서 Bond High Availability 구성

R80.20 버전은 ClusterXL에서 동작하는 개선된 Active/Backup Bond 메커니즘(Enhanced Bond)을 도입했습니다. ClusterXL을 쓰면 Enhanced Bond는 기본으로 켜져 있고 추가 설정이 필요 없습니다. 그러나 구성을 ClusterXL에서 VRRP(MCVR & VRRP)로 바꾸거나 VRRP 클러스터를 처음부터 만들면 Enhanced Bond는 기본으로 꺼집니다. 반대로 VRRP에서 ClusterXL로 바꾸면 Enhanced Bond를 수동으로 켜야 합니다.

VRRP 클러스터에서 Enhanced Bond를 켜려면 각 VRRP 멤버에서 커널 파라미터 fwha_bond_enhanced_enable 값을 1로 설정합니다. 임시 또는 영구로 설정할 수 있습니다.

임시 설정(재부팅하면 원복):

영구 설정:

클러스터에서 Bond Load Sharing 모드

Bond Load Sharing 모드에서는 이렇게 동작합니다.

Load Sharing 모드에서의 Bond 페일오버

HA 모드와 마찬가지로, ① Active 인터페이스가 감시 인터페이스의 링크 상태 장애를 감지하거나, ② ClusterXL이 CCP 패킷 송수신 장애를 감지할 때 bond 내부 페일오버가 일어납니다. 장애가 감지되면 SmartConsole의 Logs & Events > Logs 에 로그가 기록됩니다.

필요한 최소 하위 인터페이스 수 구성

ClusterXL은 Load Sharing 모드의 bond에서 UP 상태로 남은 하위 인터페이스 수가 최소 필요 수보다 적으면 bond를 "down" 상태로 간주합니다. 기본적으로, 하위 인터페이스가 n개인 bond에서 UP을 유지해야 하는 최소 수는 n−1 입니다. 즉 하위 인터페이스가 하나만 더 고장 나(n−2개만 UP) bond가 둘보다 많은 하위 인터페이스를 갖고 있어도 ClusterXL은 bond를 "down"으로 봅니다. 더 적은 수로도 예상 트래픽을 처리할 수 있다면 최소 필요 수를 명시적으로 구성할 수 있습니다("Bond Load Sharing의 최소 필요 하위 인터페이스 수 구성" 절 참고).

Bond 인터페이스가 제대로 동작하는지 확인

Bond HA 때와 동일합니다 — 각 멤버 명령줄에서 show cluster members interfaces all(Clish) 또는 cphaprob -am if(Expert)로 클러스터 인터페이스를, show cluster bond {all | name <Bond 이름>}·show bonding groups(Clish) 또는 cphaprob show_bond <Bond 이름>(Expert)로 bond 인터페이스를 확인합니다.

Group of Bonds(Bond 그룹)

Group of Bonds 는 기존 Bond 인터페이스들을 묶은 논리 그룹으로, 추가 링크 이중화 를 제공합니다.

예시 토폴로지를 보겠습니다.

Group of Bonds가 없을 때의 사건 흐름:

이것은 바람직하지 않은 동작 입니다. GW-A는 SW-1뿐 아니라 SW-2에도 연결되어 있어, 이 토폴로지에서는 GW-A → GW-B로 페일오버할 실제 이유가 없기 때문입니다. 이를 해결하려고 멤버는 Bond-1과 Bond-2로 이루어진 Group of Bonds를 씁니다. 두 Bond가 모두 고장 났을 때만 Group of Bonds가 실패하고, 그때만 클러스터가 페일오버합니다.

Group of Bonds가 구성됐을 때의 사건 흐름:

새 Group of Bonds 만들기

a. 백업: cp -v $FWDIR/boot/modules/fwkern.conf{,_BKP}

b. 편집: vi $FWDIR/boot/modules/fwkern.conf

c. 파일 맨 아래에 다음 두 줄을 추가합니다(공백·주석 금지).

   fwha_group_of_bonds_str=<Group of Bonds 이름>:<이 그룹의 모든 Bond를 쉼표로 구분한 목록>
   fwha_arp_probe_method=1
   

예:

   fwha_arp_probe_method=1
   

d. 저장하고 편집기를 나갑니다. 5. 즉시(on-the-fly) 그룹을 추가하도록 fwha_group_of_bonds_str 값을 바꿉니다.

   fw ctl set str fwha_group_of_bonds_str '<Group of Bonds 이름>:<쉼표로 구분한 Bond 목록>'
   

예:

   fw ctl set str fwha_group_of_bonds_str 'GoB0:bond0,bond1;GoB1:bond2,bond3'
   

기존 Group of Bonds에 Bond 인터페이스 추가

   fw ctl set str fwha_group_of_bonds_str 'GoB0:bond0,bond1;GoB1:bond2,bond3,bond4'
   

기존 Group of Bonds에서 Bond 인터페이스 제거

추가 절차와 거의 같습니다. 멤버 명령줄에 접속 → (VSX라면 vsenv <VSID>) → Expert mode → fwkern.conf 백업·편집 후 fwha_group_of_bonds_str 값에서 해당 Bond를 빼고(예: fwha_group_of_bonds_str=GoB0:bond0,bond1;GoB1:bond2,bond3) 저장합니다. 그다음 현재 값을 복사(fw ctl get str ...)하고, 값을 비우고(fw ctl set str fwha_group_of_bonds_str ''), 비워졌는지 확인한 뒤, 다음으로 즉시 다시 설정합니다.

fw ctl set str fwha_group_of_bonds_str 'GoB0:bond0,bond1;GoB1:bond2,bond3'

마지막으로 값을 확인하고 SmartConsole에서 정책을 설치합니다. (작은따옴표 필수, 공백 금지)

Group of Bonds 삭제

   fwha_group_of_bonds_str=<Group of Bonds 이름>:<쉼표로 구분한 Bond 목록>
   fwha_arp_probe_method=1
   

저장하고 나갑니다. 5. 현재 값을 비웁니다: fw ctl set str fwha_group_of_bonds_str '' 6. 비워졌는지 확인합니다: fw ctl get str fwha_group_of_bonds_str 7. SmartConsole에서 Access Control Policy를 설치합니다.

Group of Bonds 모니터링과 로그

구성된 Group of Bonds를 보려면 cphaprob show_bond_groups 를 실행합니다("Bond 인터페이스 보기" 절 참고).

멤버는 관련 로그를 남깁니다.

Group of Bonds의 제약

Bond 인터페이스 성능 지침

최적 성능을 위해 다음을 따릅니다.

a. bond 내 하위 인터페이스의 위치를 보려면 Expert mode에서 cat /proc/net/bonding/<Bond 인터페이스 이름> 을 실행합니다.

b. 출력의 인터페이스 순서를 적어 두고, 외부 bond와 그에 대응하는 내부 bond의 순서를 비교합니다. 두 bond에서 같은 위치 에 나타나는 하위 인터페이스가 짝(pair)이며, 이 짝을 한 CPU 코어가 처리하도록 설정합니다.

예시 구성 — 처리 코어 4개(core 0~3), bond 둘(bond0는 eth0·eth1·eth2, bond1는 eth3·eth4·eth5)이 있는 장비라면 코어 둘이 하위 인터페이스를 둘씩 처리해야 합니다. 최적 구성 예시는 다음과 같습니다.

자세히는 R82 Performance Tuning Administration Guide의 CoreXL > Configuring Affinity Settings, Affinity Settings for 16000 and 26000 Appliances 절을 참고하세요.

Bond 인터페이스 문제 해결

문제 해결 흐름:

a. 링크 상태를 "no"로 보고하는 하위 인터페이스를 찾습니다.

b. 케이블 연결과 기타 하드웨어를 점검합니다.

c. 이 하위 인터페이스가 연결된 스위치의 포트 구성을 점검합니다.

VSX Cluster Member에서는 bond 인터페이스에 다음 작업을 한 뒤 재부팅이 필요 합니다 — ① bond 모드 변경, ② 기존 bond에 하위 인터페이스 추가.

스위치에서의 연결 지연 — 일부 내부 bond 페일오버 동안 스위치에서 연결 지연이 생길 수 있습니다. 요즘 스위치의 여러 기능 때문에, 새로 연결된 인터페이스를 스위치가 처리하기 시작하기까지 거의 1분 이 걸리기도 합니다. 링크 장애 후 시작 시간을 줄이는 방법은 이렇습니다.

여러 동기화·ClusterXL 기능은 커널 파라미터 로 제어됩니다.

클러스터링·동기화 타이머 제어

부하가 높을 때 새 연결 차단

새 연결을 차단하는 이유는, 새 연결이 새 Delta Synchronization 트래픽의 주 원천 이기 때문입니다. 높은 속도로 새 트래픽이 계속 처리되면 Delta Synchronization이 위험해질 수 있습니다. 이때 클러스터 로그와 /var/log/messages 에 다음 오류가 남습니다.

State synchronization is in risk

멤버를 지나는 트래픽 양을 줄이면 Delta Synchronization 메커니즘을 보호할 수 있습니다(sk43896 참고). 다음 커널 파라미터로 동작을 제어합니다.

플래그 값 표는 이렇습니다.

기본값은 24 로, TCP_DATA_CONN_ALLOWED(8)와 UDP_DATA_CONN_ALLOWED(16)의 합입니다. 즉 부하 상태에서 기본적으로 TCP·UDP data 연결만 열 수 있습니다.

Non-Monitored 인터페이스 는 ClusterXL이 감시하지 않는 멤버 인터페이스입니다. 어떤 인터페이스가 오랫동안 다운되어 있는데도 멤버를 계속 Active로 유지하고 싶을 때 이렇게 정의합니다.

클러스터에 정책을 설치하면, 멤버들은 실제로 정책을 적용하기 전에 모두 같은 정책을 받았는지 확인하는 협상 과정 을 거칩니다. 이 협상에는 타임아웃이 있어, 한 멤버가 다른 멤버의 응답을 무한정 기다리지 않게 합니다(예: 정책 설치 중 다른 멤버가 다운될 때 유용).

규칙이 아주 많은 정책, 멤버가 둘보다 많은 클러스터, 느린 멤버 같은 상황에서는 정책 설치가 오래 걸려 이 타임아웃이 너무 일찍 만료 될 수 있습니다. 이때 커널 파라미터 fwha_policy_update_timeout_factor 로 타임아웃을 조정합니다. 기본값은 1이며 대부분의 구성에 충분합니다. 위 상황이라면 값을 2로 설정하면 됩니다.

TCP 연결을 여는 3-way 핸드셰이크에 대한 표준 강제는 단방향 stickiness 를 보장해 적절한 보안을 줍니다 — 즉 SYN-ACK이 항상 SYN 뒤에 오도록 보장합니다. 하지만 ACK이 항상 SYN-ACK 뒤에 오거나 첫 데이터 패킷이 ACK 뒤에 오는 것까지는 보장하지 않습니다. 모든 out-of-state 패킷을 거부 하는 더 엄격한 정책을 원한다면, 모든 TCP 연결 개시 패킷이 올바른 순서(SYN → SYN-ACK → ACK → 데이터)로 도착하도록 동기화 메커니즘을 구성할 수 있습니다.

강화된 강제 켜기:

TCP 3-way 핸드셰이크 동기화 모드:

클러스터 Virtual IP 주소를 멤버의 물리 IP와 다른 서브넷 에 둘 수 있습니다. 그러면 네트워크는 클러스터를 네트워크 라우터처럼 동작하는 하나의 Security Gateway 로 보며, 내부 구조나 멤버의 물리 IP를 알지 못합니다.

다른 서브넷을 쓰는 장점:

멤버에서 내부·외부 네트워크로 나가는 트래픽은 클러스터 VIP와 클러스터 MAC 뒤에 숨겨집니다. 클러스터 인터페이스에 할당되는 클러스터 MAC은 이렇습니다.

다른 서브넷을 쓰면 몇 가지 제약이 따릅니다("다른 서브넷의 클러스터 주소 제약" 절 참고).

다른 서브넷 클러스터 IP 구성 예시

이 예시에서 클러스터는 네트워크 172.16.6.0/24(Side "A", 외부)와 172.16.4.0/24(Side "B", 내부)를 분리합니다.

1) 멤버에서 인터페이스와 정적 경로 구성 — 각 멤버에서 인터페이스와 다음 정적 경로를 구성합니다.

Gaia Clish 예시(Member_1, eth0 IP는 이미 구성됨):

set static-route 172.16.6.0/24 nexthop gateway logical eth0 on
set static-route 172.16.6.0/24 scopelocal on
set interface eth1 ipv4-address 192.168.2.1 mask-length 24
set interface eth1 state on
set static-route 172.16.4.0/24 nexthop gateway logical eth1 on
set static-route 172.16.4.0/24 scopelocal on
set interface eth2 ipv4-address 192.168.3.1 mask-length 24
set interface eth2 state on
save config

Member_2(주소만 다름):

set static-route 172.16.6.0/24 nexthop gateway logical eth0 on
set static-route 172.16.6.0/24 scopelocal on
set interface eth1 ipv4-address 192.168.2.2 mask-length 24
set interface eth1 state on
set static-route 172.16.4.0/24 nexthop gateway logical eth1 on
set static-route 172.16.4.0/24 scopelocal on
set interface eth2 ipv4-address 192.168.3.2 mask-length 24
set interface eth2 state on
save config

2) SmartConsole에서 클러스터 객체 열기 — Management Server에 접속 → Gateways & Servers → 클러스터 객체 열기 → Network Management.

3) 외부 클러스터 인터페이스 eth0 구성 — eth0을 선택해 Edit.

4) 내부 클러스터 인터페이스 eth1 구성 — eth0과 같은 방식으로 합니다.

5) Sync 인터페이스 eth2 구성 — eth2를 선택해 Edit.

6) 정책 설치 — SmartConsole 세션을 Publish하고, 클러스터 객체에 Access Control Policy를 설치합니다.

7) Side "A" 호스트의 기본 게이트웨이 — 모두 172.16.6.100/24.

8) Side "B" 호스트의 기본 게이트웨이 — 모두 172.16.4.100/24.

다른 서브넷 클러스터 주소의 제약

이 기능은 아직 ClusterXL의 모든 기능을 지원하지 못하며, 일부는 추가 구성이 필요하고 일부는 지원되지 않습니다.

멤버 사이 연결 — 멤버가 보내는 ARP Request가 클러스터 IP·MAC 뒤에 숨겨지므로, 한 멤버가 다른 멤버에 보낸 요청을 목적지 컴퓨터가 무시할 수 있습니다. 멤버끼리 통신하게 하려면 각 멤버에 다른 모든 멤버의 MAC을 담은 정적 ARP 를 구성해야 합니다. 멤버 사이 IP 패킷은 변형되지 않으므로 라우팅 테이블은 바꿀 필요가 없습니다.

"반쯤 지원하는(semi-supporting)" 하드웨어에서의 Load Sharing Multicast — 모든 네트워크 하드웨어가 multicast MAC을 다루지는 못하지만, 어떤 라우터는 그런 패킷을 통과시키면서도 multicast MAC이 든 ARP Reply는 처리하지 못합니다. 이런 라우터에서는 클러스터 MAC을 라우터 내부 테이블에 정적 ARP 항목 으로 구성해 통신하게 할 수 있습니다. 다른 서브넷을 쓸 때는, 이런 라우터가 multicast 출발지 MAC이 든 ARP Request에 응답하지 않으므로, 각 멤버에 라우터 MAC을 담은 정적 ARP 항목 을 구성해야 합니다. multicast MAC을 완전히 지원하는 라우터에서는 이 특수 절차가 필요 없습니다.

수동 Proxy ARP — Static NAT를 쓸 때, 클러스터는 뒤에 숨은 호스트를 자동으로 인식해 그들을 대신해 클러스터 MAC으로 ARP Reply를 보낼 수 있습니다(Automatic Proxy ARP). 하지만 VMAC 모드나 다른 서브넷을 쓰면 이 메커니즘이 동작하지 않으므로 proxy ARP를 수동으로 구성 해야 합니다. SmartConsole에서 Menu > Global properties > NAT Network Address Translation 으로 가서 Automatic ARP Configuration 을 끄고, $FWDIR/conf/local.arp 파일을 만듭니다(sk30197 참고).

클러스터 네트워크에서 멤버에 접속하기 — 고유 IP는 임의로 고를 수 있어, 그 주소가 클러스터 IP의 서브넷에서 접근 가능하다는 보장이 없습니다. 멤버의 고유 IP로 접근하려면, 접속하는 멤버에서 클러스터 IP를 고유 IP 서브넷의 기본 게이트웨이 로 하는 경로를 구성해야 합니다.

새 Cluster Member를 클러스터 객체에 추가

1) 새 Cluster Member 설치 — 추가할 새 멤버를 설치합니다(R82 Installation and Upgrade Guide의 클러스터 설치 장에서 "Install the Cluster Members" 단계만 따름).

2) 새 Cluster Member 구성 — 새 멤버에서:

3) SmartConsole에서 클러스터 객체 구성:

4) 클러스터 상태 점검 — 각 멤버(기존·신규)에서 명령줄에 접속해 로그인한 뒤, 모든 멤버가 서로를 감지하고 상태에 합의하는지 확인합니다.

서로 감지하지 못하거나 상태에 합의하지 못하면 클러스터링을 재시작합니다 — 각 멤버 명령줄에서 로그인 후 다음을 실행합니다.

cphastart

재시작 뒤 다시 show cluster state(Clish) 또는 cphaprob [-vs <VSID>] state(Expert)로 상태 합의를 확인합니다.

기존 Security Gateway를 멤버로 추가

1) 기존 Security Gateway 구성 — 인터페이스 IP·정적 경로를 토폴로지에 맞게 구성하고, 명령줄에서 cpconfig 를 실행해 Enable cluster membership for this gateway 를 선택(y)한 뒤 재부팅합니다.

2) SmartConsole에서 클러스터 객체 구성:

  If you add <Name_of_Security_Gateway_object> to the
  cluster, it will be converted to a cluster member. Some
  settings will be lost.
  The following settings will still remain:
  -SIC
  -VPN
  -NAT (except for IP Pools)
  In order to revert the conversion, session must be
  discarded.
  Are you sure you want to continue?
  

3) 클러스터 상태 점검 — 새 멤버 추가 때와 동일합니다. 각 멤버에서 상태 합의를 확인하고, 필요하면 cphastop / cphastart 로 클러스터링을 재시작한 뒤 다시 확인합니다.

1) SmartConsole에서 클러스터 객체 구성:

2) 클러스터링 재시작·상태 점검 — 남은 각 멤버에서 cphastop / cphastart 로 클러스터링을 재시작하고, show cluster state(Clish) 또는 cphaprob [-vs <VSID>] state(Expert)로 상태 합의를 확인합니다.

3) 제거된 멤버 구성 — 제거한 Security Gateway에서 명령줄에 접속해 cpconfig 를 실행한 뒤:

4) 제거된 게이트웨이와 SIC 수립 — 제거한 게이트웨이를 계속 쓰려면 SIC를 다시 맺습니다 — Management Server에 접속해 새 Security Gateway 객체를 만들고(New > Gateway 등), 화면 지시에 따라 앞서 cpconfig에서 입력한 것과 같은 Activation Key 를 입력한 뒤 OK, 세션 Publish, Access Control·Threat Prevention 정책을 설치합니다.

ISP Redundancy 는 멤버를 여러 ISP 링크 로 인터넷에 연결합니다. ISP 링크를 감시해 그때그때 가장 좋은 링크 를 고릅니다.

아래 표의 IP는 예시일 뿐입니다.

ISP Redundancy 모드

ISP Redundancy 모드는 내부 클라이언트에서 인터넷으로 나가는 연결 의 동작을 결정합니다.

나가는 연결(Outgoing)

들어오는 연결(Incoming)

외부 사용자가 들어오는 연결을 맺게 하려면 관리자가 이렇게 합니다.

서버가 서로 다른 서비스(예: HTTP, FTP)를 다루면, 공개 서버 전부에 라우팅 가능한 IP만 쓰도록 NAT를 쓸 수 있습니다. 외부 클라이언트는 할당된 IP 중 하나를 쓰며, 연결하려면 서버의 DNS 이름을 올바른 IP로 해석할 수 있어야 합니다.

웹 서버 www.example.com에 ISP마다 IP가 할당됩니다 — ISP A에서 192.168.1.2, ISP B에서 172.16.2.2. ISP A 링크가 죽으면 192.168.1.2를 쓸 수 없으므로, 클라이언트는 www.example.com을 172.16.2.2로 해석할 수 있어야 합니다. 들어오는 연결은 이 순서로 맺어집니다.

클러스터에 ISP Redundancy 구성하기

ISP 데이터(링크 속도, next hop IP)를 준비합니다. Network Management 에 Topology가 "External"인 인터페이스가 둘 이상 있으면 자동, 하나뿐 이면 수동으로 구성합니다.

자동 구성: Other > ISP Redundancy → Set initial configuration 클릭(ISP 링크가 자동 추가됨) → Primary/Backup 모드라면 Primary 인터페이스가 목록 맨 앞에 오도록 오른쪽 화살표로 순서를 맞춤 → OK.

수동 구성: Other > ISP Redundancy → ISP Links 영역에서 Add → General 탭에서 링크 이름 입력(이 이름은 ISP Redundancy 명령에 쓰임) → 이 ISP 링크의 Interface 선택 → Next Hop IP Address 구성(External 인터페이스가 둘 이상이면 비워 두고 Get from routing table, 하나뿐이면 링크마다 다른 next hop 라우터 지정) → Load Sharing 모드라면 Weight 입력(링크가 둘이면 각 50, 셋이면 각 33, 넷이면 각 25 … 합이 항상 100이 되도록. 더 빠른 링크는 값을 올리고 나머지는 내림) → Advanced 탭에서 링크 동작 확인용 모니터링 호스트를 Selected hosts 에 추가 → OK. 8. 클러스터를 DNS 서버로 구성 합니다. 클러스터(또는 그 뒤의 DNS 서버)가 DNS 질의에 응답해 DMZ·내부 서버 IP를 해석해야 합니다. 각 ISP에서 공개 IP를 얻고, 없으면 도메인을 등록해 인터넷에서 DNS 서버에 접근 가능하게 합니다.

DNS 서버 켜기: Other > ISP Redundancy → Enable DNS Proxy 선택 → Configure → DMZ·웹 서버 추가(각 서버에 ISP마다 공개 IP 설정) → DNS TTL 에 초 단위 입력(인터넷 DNS 서버가 이 시간보다 오래 데이터를 캐시하지 못함) → OK → Static NAT로 공개 IP를 실제 서버 IP로 번역 → 다음 Access Control 규칙을 정의합니다.

도메인 등록·IP 받기: 각 ISP에 도메인을 등록하고, ISP에 DNS 서버의 구성된 IP를 알려 줍니다. DMZ의 각 서버에 ISP마다 공개 IP를 받고, SmartConsole의 Menu > Global properties > NAT - Network Address Translation 에서 Manual NAT rules 영역의 Translate destination on client side 를 선택한 뒤 OK. 9. ISP Redundancy용 Access Control Policy 구성 — 정책은 ISP 링크를 통한 연결을 허용하고, 나가는 연결을 시작하는 네트워크 객체에 Automatic Hide NAT 가 적용되어야 합니다. 내부 네트워크 객체 속성에서 NAT > Add Automatic Address Translation Rules → Hide behind the gateway 선택 → OK. 공개 접근 서버(웹·DNS·DMZ)용 규칙도 정의합니다.

ISP Redundancy와 VPN

ISP Redundancy를 켜면 VPN 암호화 연결이 ISP 링크 장애에서도 살아남습니다. ISP Redundancy 페이지의 설정이 IPsec VPN > Link Selection 페이지 설정보다 우선합니다.

Check Point 피어와의 VPN용 ISP Redundancy 구성:

타사 피어와의 VPN용 ISP Redundancy 구성 — VPN 피어가 Check Point 게이트웨이가 아니면 VPN이 실패하거나, 타사 장비가 죽은 ISP 링크로 계속 암호화 트래픽을 보낼 수 있습니다.

CLI에서 ISP Redundancy 제어

ISP 링크 상태 강제 — fw isp_link 명령으로 링크 상태를 Up/Down으로 강제합니다. 설치·배포 테스트나, 게이트웨이가 링크 상태를 잘못 인식할 때(링크가 죽었는데 up으로 봄) 실제 상태를 인식시키는 데 씁니다.

  fw isp_link <SmartConsole의 ISP 링크 이름> {up | down}
  

  fw isp_link <Cluster Member 객체 이름> <SmartConsole의 ISP 링크 이름> {up | down}
  

자세히는 R82 CLI Reference Guide의 fw > fw isp_link 절을 보세요.

ISP Redundancy 스크립트 — 멤버가 시작하거나 ISP 링크 상태가 바뀌면 멤버에서 $FWDIR/bin/cpisp_update 스크립트가 실행됩니다. 이 스크립트는 멤버의 기본 경로(default route)를 바꿉니다.

ClusterXL은 Gaia OS의 일부로서 동적 라우팅(Unicast·Multicast) 프로토콜을 지원합니다. 네트워크 인프라가 클러스터된 게이트웨이를 하나의 논리 entity 로 보므로, 멤버 장애가 인프라에 투명하게 처리되어 연쇄 효과(ripple effect) 를 일으키지 않습니다.

Router IP Address — 모든 멤버가 클러스터 Virtual IP 를 Router IP로 씁니다.

Routing Table Synchronization — 라우팅 정보는 FIB(Forwarding Information Base) Manager 프로세스로 멤버 사이에 동기화됩니다. 페일오버 때 트래픽 중단을 막기 위함이며 Load Sharing·HA 모드에 쓰입니다. FIB Manager는 라우팅 정보를 책임지며 "FIB" 라는 Critical Device로 등록됩니다. 라우팅 데이터베이스가 동기화에서 벗어나면 이 Critical Device가 상태를 "problem"으로 보고하고, 그 결과 FIB Manager가 다시 동기화될 때까지 멤버가 "DOWN" 상태가 됩니다.

Wait for Clustering — 동적 라우팅 프로토콜이나 DHCP Relay가 클러스터에 구성되면, Wait for Clustering 옵션을:

자세히는 sk92322를 보세요.

Failure Recovery — ClusterXL의 동적 라우팅은 페일오버 때 연쇄 효과를 피하려고, 라우터가 유지보수 모드를 빠져나갔다 고 이웃 라우터에 알립니다. 그러면 이웃 라우터는 다른 라우터에 알리지 않고 클러스터와의 관계를 다시 맺습니다. 이 restart 프로토콜은 주요 네트워킹 벤더가 널리 채택했습니다. Check Point 동적 라우팅과 호환되는 RFC·draft는 이렇습니다.