06연결 동기화(State Synchronization)연결 동기화(State Synchronization)

게이트웨이가 인식하는 모든 IP 기반 서비스(TCP·UDP 포함)가 동기화 됩니다. 다만 모드에 따라 동기화의 의무가 다릅니다.

Synchronization Network 는 연결 정보와 Security Gateway 상태를 멤버 사이에 옮기는 통로 입니다. 여기에는 조직에서 가장 민감한 보안 정책 정보가 흐르 므로, 악의적 위협과 실수에 의한 위협 양쪽 모두로부터 반드시 보호해야 합니다. 권장하는 보호 전략은 세 가지입니다.

State Synchronization은 두 가지 모드 로 동작합니다 — Full Sync 와 Delta Sync 입니다.

Full Sync — 전체를 한 번에

Full Sync 는 한 멤버에서 다른 멤버로 모든 Security Gateway 커널 테이블 정보를 옮깁 니다. 상태 정보를 처음 옮길 때, 즉 멤버가 클러스터에 새로 합류할 때 사용합니다. 어떤 멤버가 down되었다가 다시 올라오면, 활성(Active) 동료 멤버와 Full Sync를 수행합니다. 모든 멤버가 동기화를 마친 뒤에는, Full Sync보다 빠른 Delta Sync로 변경분만 주고받습니다.

Full Sync는 다음 순서로 동작합니다.

Delta Sync — 변경분만

Delta Sync 는 멤버 사이에 커널 테이블의 변경분만 옮깁 니다. 모든 멤버가 Full Sync를 마친 뒤, 연결 상태 정보의 변화 를 주고받는 데 씁니다. 이 Delta Sync는 Security Gateway 커널이 UDP 8116 포트 로 처리합니다.

State Synchronization 트래픽은 전체 Cluster Control Protocol(CCP) 트래픽의 약 90% 를 차지합니다. 멤버들은 UDP 데이터 헤더의 opcode 를 보고 State Synchronization 패킷을 나머지 CCP 트래픽과 구분합니다.

모든 연결을 동기화할 필요는 없습니다. HTTP 같은 일부 TCP 서비스는 연결 지속 시간이 아주 짧 습니다. 이런 연결은 동기화해 봐야 의미가 없습니다 — 동기화된 연결마다 멤버 자원을 쓰는데, 정작 페일오버가 일어날 즈음엔 이미 연결이 끝나 있을 가능성이 높기 때문입니다.

수명이 짧은 서비스에는 Delayed Notifications 기능을 씁니다. 이 기능은 멤버에게 연결을 알리는 것을 미뤄, 연결이 시작된 지 X초 뒤에도 여전히 살아 있을 때만 동기화 합니다. Delayed Notifications는 모든 멤버에 SecureXL이 켜져 있어야 동작합니다(기본값으로 켜져 있습니다).

설정 절차는 다음과 같습니다.

연결 동기화에는 성능 비용 이 따릅니다. 클러스터를 지나는 모든 연결을 반드시 동기화해야 하는 것은 아닙니다.

다음 조건이 모두 참이라면 어떤 서비스를 동기화하지 않기로 선택할 만합니다.

동기화되는 서비스 정의와 동기화되지 않는 서비스 정의를 따로 두고 Rule Base에서 선택적으로 쓸 수 있습니다. 자세한 내용은 R82 Security Management Administration Guide를 참고하세요.

클러스터에서 서비스를 동기화하지 않도록 설정하는 절차는 다음과 같습니다.

고착 연결이란

어떤 연결이 양방향 모두 단 하나의 멤버에 의해 처리되면 그 연결을 sticky(고착) 하다고 합니다. High Availability 모드가 여기에 해당합니다 — 모든 연결이 같은 멤버를 거쳐 라우팅되므로 모두 고착됩니다. Load Sharing 모드에서도 VPN 피어·Static NAT 규칙·SIP 트래픽이 없으면 고착됩니다.

하지만 Load Sharing 모드에서는 특정 멤버에서 시작한 연결이 양방향 모두 같은 멤버에서 계속 처리되도록 보장해야 하는 경우 가 있습니다. 그럴 때는 SmartConsole의 클러스터 객체에서 Sticky Decision Function 을 켜서 특정 연결을 고착시킬 수 있습니다.

Check Point의 Cluster Correction Layer(CCL) 가 Check Point 클러스터에서 비대칭 연결을 처리합니다.

타사 피어와 Load Sharing의 VPN 터널

Check Point는 타사 게이트웨이가 Check Point Security Gateway와 피어를 맺을 수 있게 해 상호 운용성 을 제공합니다. 그런데 특수한 문제가 하나 있습니다. 일부 타사 피어(예: Microsoft L2TP, Cisco 게이트웨이)가 Load Sharing 모드의 ClusterXL과 VPN 터널을 맺으려 할 때 입니다. 이 VPN 피어들은 SA(Security Association)를 저장하는 능력이 제한 적이라, 한 멤버에서 시작한 VPN 세션이 Load Sharing 때문에 돌아오는 길에 다른 멤버를 거치면 그 세션을 알아보지 못하고 드롭 합니다.

이 그림의 구성 요소는 다음과 같습니다.

이 시나리오에서는 —

타사 피어는 SA 집합을 하나밖에 저장하지 못 하므로 여러 멤버와 VPN 터널을 협상할 수 없고, 그래서 멤버가 라우팅 트랜잭션을 완료하지 못합니다.

SA 집합을 하나만 저장할 수 있는 일부 타사 피어·게이트웨이에서는 연결을 고착(sticky)시켜 이 문제를 해결합니다. CCL 이 같은 타사 게이트웨이가 시작한 모든 VPN 세션을 단 하나의 멤버가 처리 하도록 보장합니다.

Hub and Spoke VPN 배포의 타사 게이트웨이

Load Sharing 모드에서 CCL이 제공하는 연결 고착성이 필요한 또 다른 경우는, 일부 타사 게이트웨이를 Hub and Spoke 배포에 통합 할 때입니다. SA 집합을 하나밖에 저장하지 못하므로, 타사 게이트웨이는 SA 중복을 피하려면 VPN 터널을 단 하나의 멤버에 유지 해야 합니다.

이 예시 배포의 구성 요소는 다음과 같습니다.

이 예시 배포에서는 —

Spoke A와 B는 항상 같은 멤버를 거쳐 통신하도록 설정해야 합니다. CCL 이 이 문제의 절반을 풀어 줍니다 — 어느 타사 게이트웨이가 시작했든 그 게이트웨이의 모든 VPN 세션을 단 하나의 멤버가 처리하게 만듭니다.

Hub and Spoke 배포에서 타사 게이트웨이 설정하기

Hub and Spoke VPN 배포에서 타사 게이트웨이를 Spoke로 설정하려면, Management Server 에서 다음을 수행합니다.

   all@{member1,member2} vpn_sticky_gws = {<10.10.10.1;1>,
   <20.20.20.1;1>};
   

이 구성의 요소는 다음과 같습니다.

   all@{member1,member2} vpn_sticky_gws = {<10.10.10.1;1>,
   <20.20.20.1;1>, <30.30.30.1;1>};
   

Tunnel Group Identifier ;1 은 그대로이며, 이는 나열된 피어들이 항상 같은 멤버를 거쳐 연결 됨을 뜻합니다.

이 절차는 해당 연결에 대해 Load Sharing을 끕 니다. 만약 여러 타사 게이트웨이 집합을 서로 연결 하려는 것이라면, 게이트웨이 쌍을 특정 멤버와 함께 동작하도록 설정해 일종의 Load Sharing을 구현할 수 있습니다. 예를 들어 또 다른 두 Spoke(C와 D) 사이의 연결을 만들려면, 그 IP 주소를 줄에 추가하고 Tunnel Group Identifier를 ;1 대신 ;2 로 바꿉니다. 그러면 줄은 다음과 같습니다.

all@{member1,member2} vpn_sticky_gws = {<10.10.10.1;1>,
<20.20.20.1;1>, <192.168.15.5;2>, <192.168.1.4;2>,};

이제 피어 식별자가 두 개(;1 과 ;2) 입니다. Spoke A와 B는 한 멤버를 거쳐, Spoke C와 D는 다른 멤버를 거쳐 연결됩니다.

단 하나의 멤버가 그 연결의 모든 패킷을 처리하면 sticky 하다고 합니다. 비고착(non-sticky) 연결 에서는 연결의 응답 패킷이 원래 요청 패킷과 다른 멤버를 거쳐 돌아 옵니다.

클러스터 동기화 메커니즘은 이런 비고착 연결을 올바르게 다룰 줄 압니다. 비고착 연결에서는 멤버가 out-of-state 패킷 을 받을 수 있는데, 이는 보안 위험이라 방화벽이 보통은 드롭하는 패킷입니다.

Load Sharing 구성에서는 모든 멤버가 활성입니다. Static NAT 와 암호화 연결에서는 출발지·목적지 IP 주소가 바뀝니다. 그래서 Load Sharing 클러스터를 지나는 Static NAT·암호화 연결은 비고착일 수 있습니다. Hide NAT 에서도 비고착이 생길 수 있으나, ClusterXL에는 이를 고착으로 만드는 메커니즘이 있습니다.

High Availability 구성에서는 모든 패킷이 활성 멤버에 도달하므로 모든 연결이 고착 됩니다. 연결을 맺는 도중에 페일오버가 일어나면 그 연결은 잃지만, 동기화는 나중에 수행 할 수 있습니다.

다른 멤버들이 비고착 연결을 모르면 그 패킷은 out-of-state가 되어 보안상 드롭됩니다. 하지만 동기화 메커니즘이 다른 멤버에게 그 연결을 알려 줍니다. 그 덕분에 유효하지만 비고착인 연결에서 out-of-state 패킷을 막아, 이런 비고착 연결도 허용됩니다.

비고착 연결은 관리자가 비대칭 라우팅(asymmetric routing)을 설정 했을 때도 생깁니다 — 응답 패킷이 원래 패킷과 다른 Security Gateway를 거쳐 돌아오는 경우입니다.

비고착 연결 예시 — TCP 3-Way Handshake

모든 TCP 연결을 시작하는 3-way handshake 가 흔히 비고착(흔히 비대칭 라우팅이라고도 함) 연결로 이어 집니다. 다음 그림이 예시 시나리오를 보여 줍니다.

이 그림의 구성 요소는 다음과 같습니다.

클라이언트가 서버에 SYN 패킷을 보내 연결을 시작합니다. SYN은 멤버 A를 지나지만, SYN-ACK 응답은 멤버 B를 거쳐 돌아 옵니다. 응답 패킷이 원래 패킷과 다른 게이트웨이를 거쳐 돌아오므로 비고착 연결입니다.

동기화 네트워크가 멤버 B에 알립니다. 서버가 보낸 SYN-ACK 패킷이 도달하기 전에 멤버 B가 갱신되면 연결이 정상 처리됩니다. 그러나 동기화가 지연되어 SYN 플래그가 갱신되기 전에 SYN-ACK 패킷이 멤버 B에 먼저 도착 하면, 게이트웨이는 그 SYN-ACK를 out-of-state로 취급해 연결을 드롭합니다.

이 문제를 해결하려면 enhanced 3-Way TCP Handshake enforcement 를 설정할 수 있습니다("Enhanced 3-Way TCP Handshake Enforcement" 참고).

비고착 연결의 동기화

동기화 메커니즘은 유효하지만 비고착인 연결에서 out-of-state 패킷을 막습니다. 이 방식은 모든 TCP 데이터 연결을 시작하는 3-way handshake로 가장 잘 설명됩니다. 3-way handshake는 다음 순서로 진행됩니다.

out-of-state 패킷을 막기 위해, 다음과 같은 순서(이른바 "Flush and Ack")가 일어납니다.

조직에 따라 멤버를 서로 멀리 떨어진 지리적 위치에 두어야 하는 경우가 있습니다. 대표적인 예가 재해 복구용으로 위치를 멀리 떨어뜨린 복제 데이터센터 입니다. 이런 구성에서는 동기화 네트워크에 크로스 케이블을 쓰는 것이 사실상 불가능합니다.

동기화 네트워크를 원격지에 걸쳐 펼칠 수 있으며, 이렇게 하면 지리적으로 분산된 클러스터를 더 쉽게 배포할 수 있습니다. 다만 이 기능에는 두 가지 제약 이 있습니다.

지리적으로 분산된 클러스터는 명령줄 인터페이스로 모니터링·트러블슈팅 할 수 있습니다.

멤버를 동기화할 때는 다음 제약이 적용됩니다.