목차/06. Link Selection

06Link SelectionLink Selection

게이트웨이에 외부 인터페이스나 ISP 회선이 여럿이면, VPN 트래픽을 어느 IP·인터페이스로 주고받을지, 그리고 어떤 경로가 가장 좋은지 를 누군가 정해 주어야 합니다. Link Selection 은 바로 들어오고 나가는 VPN 트래픽에 쓸 인터페이스와 최적 경로를 결정하는 메커니즘입니다. 이 손잡이로 관리자는 각 Security Gateway에서 VPN에 어떤 IP 주소를 쓸지 직접 고를 수 있습니다.

Link Selection은 VPN 트래픽을 통제하는 구성 옵션이 매우 많습니다. 대표적으로 다음과 같은 일을 할 수 있습니다.

Probing(탐침) 으로 링크의 가용성에 따라 어떤 링크를 쓸지 고릅니다.
VPN Load Sharing 으로 가용 링크 사이에 VPN 트래픽을 분산합니다.
Service Based Link Selection 으로 서비스별 대역폭 사용을 제어합니다.

Remote Access VPN 클라이언트용 설정은 Site-to-Site VPN 설정과 함께 또는 따로 구성할 수 있습니다.

R82의 두 가지 Link Selection 메커니즘

R82부터 Link Selection 메커니즘이 둘로 나뉩니다.

Enhanced Link Selection — R82에서 새로 추가된 기능입니다. 더 정교하고 유연하게 링크를 다룹니다.
Legacy Link Selection — 기존부터 있던 방식입니다. 새 Enhanced 방식과 구분하려고 이름 앞에 "Legacy(레거시)"가 붙었습니다.

환경에 맞게 둘 중 하나를 고르면 됩니다. 아래에서 각 방식을 차례로 자세히 설명합니다.

Enhanced Link Selection

Enhanced Link Selection이란

Enhanced Link Selection 은 VPN 연결에 외부 인터페이스를 여러 개 구성할 수 있게 함으로써 상호 운용성을 끌어올립니다. 핵심은, Check Point 고유의 VPN Link Selection 프로토콜인 RDP 에 의존하지 않고도 이중화(redundancy)와 Load Sharing을 제공 한다는 점입니다. 덕분에 서드파티·클라우드 기반의 Site-to-Site(S2S) IPsec 벤더와도 잘 맞물리며, 이전 구성에서 겪던 제약을 넘어섭니다.

어떻게 동작하나

여러 Site-to-Site VPN 연결이 맺어지면, Security Gateway는 각 연결이 정상 동작하는지 항상 감시 합니다. 기본(primary) 연결이 살아 있는 동안에는 그 연결을 씁니다. 만약 사용할 수 있는 기본 연결이 하나도 없으면, 구성해 둔 우선순위(priority)에 따라 백업(backup) 연결로 전환 합니다.

Link Selection의 세분화(granularity)

트래픽은 서로 다른 ISP를 통해 흐를 수 있고, 활성 상태인 각 인터페이스는 자기 상대 피어(peer)와 통신 합니다. 같은 게이트웨이에 달린 인터페이스끼리는 서로 통신하지 않습니다.

클라우드와의 ISP 이중화

Enhanced Link Selection은 클라우드·서드파티 벤더와의 통신에서도 이중화를 보장합니다.

주요 특징

VPN Link Redundancy — 서드파티·클라우드 벤더와의 통신에 이중화를 제공합니다.
Granular Link Selection — 게이트웨이 단위(per gateway) 또는 커뮤니티 단위(per community)로 링크 선택을 구성할 수 있습니다.
Enhanced VPN Link Reliability — 여러 링크를 처리하는 터널에서 발생하던 "out-of-window" 드롭 같은 취약점을 해소해 링크 신뢰성을 높입니다.
Infrastructure for SD-WAN — 현대 네트워킹에 필요한 기능을 제공하는 SD-WAN의 토대 역할을 합니다.

Enhanced Link Selection 구성하기

먼저 지원 범위를 짚어야 합니다. 이 VPN Interoperability(상호 운용성) 기능은 다음 환경을 지원하지 않습니다.

동적으로 IP가 할당되는(DAIP) Security Gateway
Quantum Spark Gateway
인터페이스당 IPv6 주소가 둘 이상인 구성
Large Scale VPN (LSV)
Remote Access VPN
ElasticXL
(Maestro·Scalable Chassis에서) IPv6 주소가 둘 이상 할당된 Security Group 인터페이스

아래 절차는 Site-to-Site VPN의 Star 또는 Meshed 커뮤니티 안에서 표준 터널(standard tunnel)을 사용해 Enhanced Link Selection을 구성하는 방법입니다. 목적은, 여러 Security Gateway 사이에 VPN 연결을 세우고 관리하여, 서로 다른 네트워크 인터페이스에 걸쳐 안전한 통신과 효율적인 트래픽 관리 를 보장하는 것입니다.

인터페이스를 어디서 지정할지 — 시나리오별 권장 구성

쓸 인터페이스는 여러 방식으로 지정할 수 있고, 현재 구성은 언제든 덮어쓸(override) 수 있습니다. 상황별 권장안을 표로 정리합니다.

시나리오	권장 구성
모든 VPN 커뮤니티에서 이 게이트웨이의 같은 인터페이스를 써야 한다	Security Gateway 객체 > IPsec VPN > Enhanced Link Selection 페이지 > Interfaces 섹션에서 필요한 인터페이스를 고른다. 이 게이트웨이를 VPN 커뮤니티에 추가하면, 구성해 둔 인터페이스가 자동으로 선택 된다.
대부분의 커뮤니티에서는 같은 인터페이스를, 일부 커뮤니티에서는 특정 인터페이스를 써야 한다	① 게이트웨이 객체의 Enhanced Link Selection > Interfaces 섹션에서 공통 인터페이스를 고른다(추가 시 자동 선택). ② 해당하는 일부 VPN 커뮤니티 객체 안에서, 게이트웨이의 기본 구성을 덮어써 필요한 인터페이스를 고른다.
커뮤니티마다 이 게이트웨이의 다른 인터페이스를 써야 한다	각 VPN 커뮤니티 객체 안에서, 게이트웨이의 기본 구성을 덮어써 필요한 인터페이스를 고른다.

SmartConsole에서의 구성 절차

Star 또는 Meshed 커뮤니티 안에서 Enhanced Link Selection을 구성하려면, SmartConsole에서 다음 순서를 따릅니다.

1. VPN 커뮤니티를 만든다.

Star VPN Community 또는 Meshed VPN Community 객체를 생성합니다(자세한 절차는 "Getting Started with Site to Site VPN" 참고).

2. 필요한 Security Gateway를 커뮤니티에 추가한다.

Meshed 커뮤니티에서는 Gateways 페이지의 Participating Gateways 섹션에 게이트웨이를 추가합니다.
Star 커뮤니티에서는 Gateways 페이지의 Center Gateways 와 Satellite Gateways 섹션에 게이트웨이를 추가합니다.

게이트웨이를 커뮤니티에 추가하면, 기본적으로는 게이트웨이 객체에 설정된 인터페이스 구성을 그대로 사용합니다.

커뮤니티에서 다른 인터페이스를 고르려면

커뮤니티 단위로 다른 인터페이스를 쓰고 싶을 때는 다음과 같이 합니다.

Gateways 페이지의 해당 섹션에서 게이트웨이 객체를 선택합니다.
툴바의 연필 아이콘 을 클릭합니다. 그러면 "VPN configuration for <게이트웨이 이름> in <VPN 커뮤니티 이름> community" 창이 열립니다.
VPN Domain 섹션에서 적절한 옵션을 고릅니다. Override 를 골랐다면 해당하는 Network 또는 Network Group 객체를 선택합니다(피커 창에서 새 객체를 만들 수도 있습니다).
Interfaces 섹션에서 Override 를 선택합니다.
[+] 아이콘 을 클릭합니다.
필요한 인터페이스를 고르고 다음을 설정합니다.
1. External Interface 필드에서 사용할 인터페이스를 고릅니다.
2. (선택) Next Hop IP Address 필드에 다음 홉의 IP 주소를 적습니다. 비워 두면 운영체제 라우팅 테이블을 보고 게이트웨이가 자동으로 계산 합니다.
3. (선택) 이 인터페이스가 NAT 장치 뒤에 있다면, Static NAT IP Address 필드에 NAT 후 주소 를 적습니다.
4. Redundancy Mode 필드에서 모드를 고릅니다.
  - VPN Load Sharing 을 구성하려면 모든 인터페이스를 Active 로 둡니다.
  - VPN High Availability 를 구성하려면 하나만 Active, 나머지는 Backup 으로 둡니다.
5. Backup 을 골랐다면 Priority 필드에 우선순위를 설정합니다. 이 우선순위는 모든 Active 인터페이스가 다운으로 간주될 때(예: ISP 문제로 다음 홉에 닿지 못할 때) 어느 Backup 인터페이스를 쓸지 를 결정합니다.
6. OK 를 눌러 Interface Settings 창을 닫습니다.
인터페이스를 더 추가하려면 5~6단계를 반복합니다.
OK 를 눌러 VPN configuration 창을 닫습니다.
OK 를 눌러 VPN 커뮤니티 객체를 닫습니다.

3. 피어 게이트웨이를 구성한다.

이 VPN 커뮤니티의 다른 Security Gateway에 대해서도 같은 구성 과정을 반복합니다.

4. 인터페이스 가용성을 확인한다.

Security Gateway는 Dead Peer Detection (DPD) 으로 인터페이스 상태를 감시합니다.
터널의 Active 상태를 유지하도록, DPD 패킷이 제대로 송수신되는지 확인합니다.

Enhanced Link Selection은 터널 해소(resolution)를 위해 IKE 메시지를 통한 DPD 를 사용하며, 이 기능은 모든 게이트웨이 벤더가 지원합니다. DPD는 터널을 계속 살아 있게 유지하는 역할도 하지만, 그것이 주된 목적은 아닙니다 — 그 용도라면 영구 터널(permanent tunnel)을 늘 켜 둘 수 있기 때문입니다. DPD 활동을 포함한 IKE 세션은 ikeview 도구로 관찰할 수 있습니다.

5. 페일오버(failover)를 처리한다.

링크 장애가 나도 VPN 연결이 자동으로 백업 터널로 전환되어 살아남도록 합니다. 외부 인터페이스는 가급적 fw monitor 도구로 감시하고, 대안으로 tcpdump 도구로 링크 페일오버 중 ESP 데이터의 출처를 확인할 수 있습니다.

DPD 응답과 IPsec 터널 재협상을 관찰해 페일오버가 잘 되는지 검증합니다. 페일오버 중 실패한 Active 터널에서는 DPD 응답이 없어야 하며, 백업 피어 IP로 새 터널(IKE 세션)이 새로 맺어져야 합니다.

Legacy Link Selection

Legacy Link Selection이란

Legacy Link Selection 역시 들어오고 나가는 VPN 트래픽에 쓸 인터페이스와 최적 경로를 정하는 방식입니다. 이 방식으로 관리자는 각 Security Gateway에서 VPN에 어떤 IP 주소를 쓸지 고릅니다. Remote Access VPN 클라이언트용 설정은 Site-to-Site 설정과 함께 또는 따로 구성할 수 있습니다.

Legacy Link Selection 구성 절차

왼쪽 탐색 패널에서 Gateways & Servers 를 클릭합니다.
Security Gateway / Cluster 객체를 더블클릭합니다.
왼쪽 패널에서 IPsec VPN > Link Selection 을 클릭합니다.
Remote VPN 피어가 로컬 게이트웨이에 접속할 때 어떤 IP 주소를 쓰게 할지 를 정합니다. (아래 "IP Selection by Remote Peer" 참고)
나가는 경로 선택(Outgoing Route Selection) 을 구성합니다. (아래 참고)
추적(Tracking) 으로 해소 결정 알림 방식을 정합니다. (아래 참고)
OK 를 클릭합니다.
Access Control 정책을 설치(Install)합니다.

IP Selection by Remote Peer — 피어가 쓸 IP 정하기

IP Selection by Remote Peer 섹션에서, VPN 피어가 로컬 게이트웨이의 IP를 어떻게 알아내고 어떤 주소로 접속할지를 정합니다. 해당하는 옵션을 고릅니다.

Always use this IP Address (항상 이 IP를 사용)

VPN 피어가 게이트웨이 IP를 알아내려 할 때 늘 특정 IP를 쓰게 합니다. 이 옵션을 고른 뒤 아래 중 하나를 함께 선택합니다.

Main address — 객체의 General Properties 페이지에 설정된 게이트웨이/클러스터의 주 IP 주소로 터널을 만듭니다.
Selected address from topology table — 객체의 Network Management 페이지에 나타나는 인터페이스 IP 중 골라 둔 IP 로 터널을 만듭니다.
Statically NATed IP — 이 필드에 적은 IP로 터널을 만듭니다. 해당 인터페이스가 Static NAT 장치 뒤에 있을 때 씁니다. 이 IP는 객체의 Network Management 페이지에 나타나지 않아도 됩니다.

Calculate IP based on network topology (네트워크 토폴로지로 계산)

네트워크 토폴로지를 보고 계산한 IP 로 터널을 만듭니다. 객체 > Network Management 페이지 > 해당 인터페이스 > Topology 섹션의 설정이 올바른지 확인하세요.

Using DNS resolving (DNS 해석 사용)

이 게이트웨이가 동적 IP(DAIP) 라면 이 옵션을 고릅니다. DAIP 게이트웨이의 IP는 미리 알 수 없으므로, DAIP 게이트웨이로 향하는 터널은 DNS 해석으로만 시작 할 수 있습니다. DAIP가 아닌 게이트웨이에 이 옵션을 고른다면, Network Management 페이지에 IP를 설정해 두어야 합니다. DNS 해석이 없으면 DAIP 게이트웨이는 두 피어 사이의 첫 연결만 시작 할 수 있고, 그다음 연결은 DAIP 게이트웨이의 IP가 바뀌지 않은 동안 피어 쪽에서 시작할 수 있습니다. 이때 하위 옵션을 고릅니다.

Full hostname — 이 게이트웨이의 전체 FQDN을 적습니다. 사용되는 DNS 호스트네임은 <gateway_name>.<domain_name> 형식입니다. 예를 들어 객체 이름이 MyGw, 도메인이 example.com이면 FQDN은 MyGw.example.com이 됩니다.
Gateway's name and domain name (Global Properties 지정값) — 다음 두 가지를 조합합니다.
1. General Properties 페이지의 게이트웨이 객체 이름.
2. Global Properties > VPN > Advanced 페이지 > Link Selection settings 섹션 > Domain name of DNS resolving 필드에 설정한 도메인 이름.

Using probing. Link redundancy mode (탐침 사용, 링크 이중화 모드)

게이트웨이/클러스터에 VPN용 IP가 둘 이상이면, Link Selection은 Check Point 고유의 RDP 탐침(probing) 방식으로 어떤 링크를 쓸지 판단할 수 있습니다.

검사하고 싶지 않은 IP(예: 내부 IP)는 검사 목록에서 뺄 수 있습니다. 게이트웨이가 링크 가용성을 파악하고 나면, 아래 이중화 모드 중 하나에 따라 연결 단위로 링크를 선택 합니다.

a. 탐침 이중화 모드를 고릅니다.

High Availability — VPN 터널은 가장 먼저 응답한 IP 를(주 IP가 설정·활성 상태이면 그 주 IP를) 씁니다. 선택된 IP가 응답을 멈추면, 다른 응답 IP로 페일오버합니다. 주 IP가 설정돼 있으면, 주 IP가 다시 응답할 때까지 터널은 백업 IP에 머뭅니다.
Load Sharing — 암호화 트래픽을 모든 가용 VPN 링크에 분산 합니다. 암호화 대상이 된 새 연결은 라운드 로빈 방식으로 다음 가용 VPN 링크를 씁니다. 어떤 VPN 링크를 못 쓰게 되면, 그 링크의 모든 연결이 다른 가용 링크들로 재분배됩니다. 링크 가용성은 RDP 탐침으로 판단합니다.

b. 탐침 설정을 구성합니다.

Configure 를 클릭합니다.
해당하는 옵션을 고릅니다(자세한 내용은 Help 버튼 참고).
- Probe all addresses defined in the topology tab — 토폴로지에 정의된 모든 IP로 RDP 패킷을 보내 가용 링크를 찾습니다.
- Probe the following addresses — 탐침할 인터페이스 목록을 직접 구성합니다.
- Primary address — 다른 IP들보다 우선해야 할 인터페이스 IP를 고릅니다.
- Using ongoing probing — VPN용 IP가 여럿일 때, 세션이 시작되면 하나가 응답할 때까지 가능한 모든 목적지 IP에 RDP 패킷을 계속 보냅니다. 연결은 첫 응답 IP(또는 활성 주 IP)로 가며, 그 IP가 응답을 멈출 때까지 거기에 머뭅니다. RDP 탐침은 연결이 열릴 때 켜져 백그라운드 프로세스로 계속 동작합니다.
- Using one time probing — 세션이 시작되면 가능한 모든 목적지 IP에 경로 확인용 RDP 세션을 한 번만 보냅니다. 첫 응답 IP가 선택되고, 다음 정책 설치 때까지 유지됩니다.
OK 를 클릭합니다.

연결에 응답한 피어 게이트웨이는, 그 VPN 링크가 살아 있는 한 받은 경로 그대로 답신 트래픽을 보냅니다.

Outgoing Route Selection — 나가는 경로 선택

나가는(outbound) 트래픽에는 원격 피어로 연결할 때 어떤 경로를 쓸지 정하는 여러 방법이 있습니다.

a. 나가는 인터페이스를 정하는 방법을 고릅니다.

Operating system routing table — 라우팅 테이블에서 메트릭이 가장 낮은(우선순위가 가장 높은) VPN 링크를 찾아 트래픽을 보냅니다.
Route based probing — 라우팅 테이블에서 메트릭이 가장 낮은 링크를 찾되, 보내기 전에 모든 라우팅 가능성을 검사해 그 링크가 활성인지 확인 합니다. 그런 다음 가장 잘 맞는(최장 prefix length) 활성 경로 중 메트릭이 가장 낮은(우선순위가 가장 높은) 것을 고릅니다. 외부 인터페이스가 둘 이상일 때 권장 됩니다. 만약 위 IP Selection by Remote Peer에서 Using probing + Load Sharing 을 골랐다면, 이 설정도 영향을 받아 나가는 암호화 트래픽을 모든 가용 VPN 링크에 라운드 로빈으로 분산 합니다.

Route Based Probing 예시

RDP 탐침을 켠 로컬 게이트웨이는 자신과 원격 피어 사이의 모든 가능한 경로 를 고려해, 가장 효율적인 경로를 정합니다.

이 시나리오에서 게이트웨이 "A"는 외부 인터페이스 둘(192.168.10.10, 192.168.20.10), 피어 "B"도 외부 인터페이스 둘(192.168.30.10, 192.168.40.10)을 가집니다.

게이트웨이 "A"의 라우팅 테이블:

Destination	Netmask	Next hop	Metric
192.168.40.10	255.255.255.0	192.168.10.20	1
192.168.40.10	255.255.255.0	192.168.20.20	2
192.168.30.10	255.255.255.0	192.168.10.20	3
192.168.30.10	255.255.255.0	192.168.20.20	4

게이트웨이 "B"의 라우팅 테이블:

Destination	Netmask	Next hop	Metric
192.168.20.10	255.255.255.0	192.168.40.20	1
192.168.20.10	255.255.255.0	192.168.30.20	2
192.168.10.10	255.255.255.0	192.168.40.20	3
192.168.10.10	255.255.255.0	192.168.30.20	4

게이트웨이 "A"의 나가는 경로가 모두 가용이라면, 192.168.10.10 → 192.168.40.10 경로가 메트릭이 가장 낮아(우선순위 최고) 선호 경로가 됩니다.

Route based probing에 관해 알아 둘 점이 몇 가지 있습니다.

IKE·RDP 세션의 응답 트래픽에는 같은 IP·같은 인터페이스 를 씁니다.
On Demand Links (ODL) 사용을 가능하게 합니다. ODL은 모든 주 링크가 실패할 때 작동하며, 우선순위가 더 높은 링크가 모두 못 쓰게 되면 스크립트로 ODL을 켤 수 있습니다(아래 "On Demand Links" 참고).
TCP 같은 일부 프로토콜은 링크 장애와 다음 해소 시도 사이에 타임아웃 날 수 있습니다. 관리자는 기본값을 줄일 수 있지만, 해소 빈도가 너무 높으면 게이트웨이에 부하 가 걸립니다. 이 구성은 MEP 메커니즘의 기본 해소 타임아웃도 함께 바꿉니다.
Layer 2 링크에서는 로컬 Layer 2 인터페이스 장치를 통해 피어의 암호화 도메인으로 가는 경로 가 있어야 합니다.
Route based probing은 resolver(해소기) 메커니즘으로 해소됩니다. 선택된 경로가 실패했는지 판단할 때, 이 메커니즘은 다음 두 파라미터 값의 합 을 사용합니다.

resolver_session_interval

원격 피어 상태(up/down)가 유효하게 유지되는 시간(초) 을 정합니다. 기본값: 30초

resolver_ttl

원격 피어를 다운으로 판단하기 전에 기다리는 시간(초) 을 정합니다. 기본값: 10

기본값을 바꾸려면 다음과 같이 합니다.

SmartConsole 왼쪽 위에서 Menu > Global properties 를 클릭합니다.
왼쪽 패널에서 Advanced 페이지 > Configure 를 클릭합니다.
왼쪽 패널에서 FireWall-1 을 펼치고 Resolver 를 클릭합니다.
필요한 값을 설정합니다.
OK 로 Advanced Configuration 창을 닫습니다.
OK 로 Global Properties 창을 닫습니다.
Access Control 정책을 설치합니다.

b. 원격이 시작한 터널에 답신할 때 나가는 인터페이스를 정하는 방법을 고릅니다.

Setup 을 클릭하고 해당 옵션을 고릅니다.

Use outgoing traffic configuration — Link Selection 페이지의 Outgoing Route Selection 섹션에서 고른 방법과 같은 방법 으로 인터페이스를 고릅니다.
Reply from the same interface — 트래픽이 도착한 그 인터페이스·다음 홉 IP 그대로 답신을 보냅니다. Route Based Probing 을 골랐다면 기본값이 이 옵션이 됩니다.

c. 게이트웨이가 시작하는 나가는 패킷에 쓸 출발지 IP를 고릅니다.

Source IP address settings 를 클릭하고 해당 옵션을 고릅니다.

Automatic (피어 IP 선택 방법에서 유도) — IP Selection by Remote Peer에서 고른 방법에 따라 출발지 IP를 정합니다.
- Main address 나 Selected address from topology table 를 골랐다면, 터널 시작 시 출발지 IP는 그 방법에서 설정한 IP 입니다.
- Calculate IP based on network topology, Statically NATed IP, Use DNS resolving, Use probing 중 하나를 골랐다면, 출발지 IP는 선택된 나가는 인터페이스의 IP 입니다.
Manual — 직접 지정합니다.
- Main IP address — General Properties 페이지에 설정된 객체의 주 IP를 씁니다.
- Selected address from topology table — 골라 둔 IP를 씁니다.
- IP address of chosen interface — 트래픽이 라우팅되는 그 인터페이스의 IP 를 씁니다.

Tracking — 해소 결정 알림 설정

게이트웨이가 원격 피어와 새로운 해소(resolving) 결정을 내릴 때마다 어떻게 알릴지 정합니다. Tracking 섹션의 Outgoing Link Tracking 필드에서 고릅니다.

None — 로그도 경보도, 아무 알림도 보내지 않습니다.
Log — 로그를 생성합니다.
Popup Alert — SmartView Monitor GUI(열려 있을 때)에 팝업으로 뜨는 미리 정의된 경보를 생성합니다.
SNMP Trap Alert — SmartView Monitor GUI(열려 있을 때)에 나타나는 미리 정의된 SNMP Trap을 보냅니다.
User Defined Alert — SmartView Monitor GUI(열려 있을 때)에 팝업으로 뜨는 사용자 정의 경보를 생성합니다.

알아 둘 점이 있습니다.

None 이 아닌 다른 옵션을 고르면, 원격 피어와 새 해소 결정을 내릴 때마다 로그 를 보냅니다.
Using probing. Link redundancy mode 나 Route based probing 을 골랐다면, 모든 해소 변경마다 로그 를 보냅니다(예: 쓰던 VPN 링크가 못 쓰게 되어 새 링크를 고른 경우).

Legacy Link Selection 예시

Link Selection은 다양한 환경에서 쓰입니다. 여기서는 시나리오별로 어떻게 구성하면 좋은지 살펴봅니다.

외부 인터페이스가 하나인 게이트웨이

가장 단순한 시나리오로, 로컬 게이트웨이에 VPN용 외부 인터페이스가 하나뿐 입니다.

쓸 인터페이스가 하나뿐이므로, IP Selection by Remote Peer 섹션에서 아래 중 하나를 설정하고 정책을 설치합니다.

Main address 를 고릅니다.
Selected address from topology table 를 고르고 원하는 IP를 선택합니다.
게이트웨이 IP가 Static NAT 장치 뒤에 있으면 Statically NATed IP 를 고르고 NAT 후 IP를 적습니다.

서로 다른 상대가 쓰는 여러 IP를 가진 게이트웨이

이 시나리오에서는 로컬 게이트웨이가 서로 다른 두 인터페이스에서 점대점(point-to-point) 연결 을 맺고, 각 인터페이스를 다른 VPN 피어가 사용합니다. 한 인터페이스는 피어 "A"와의 VPN에, 다른 하나는 피어 "B"와의 VPN에 씁니다.

IP Selection by Remote Peer 섹션에서 다음을 설정합니다.

Using probing. Link redundancy mode 를 고릅니다.
High Availability 를 고릅니다.
Configure 를 클릭합니다.
Probe all addresses defined in the topology tab 을 고릅니다.
Using one time probing 을 고릅니다.
OK 를 클릭합니다.
Access Control 정책을 설치합니다.

각 피어가 쓸 IP가 하나뿐이므로, 탐침은 한 번만(one time) 하면 됩니다.

Static NAT 장치 뒤에 인터페이스가 있는 게이트웨이

이 시나리오에서는 로컬 게이트웨이에 VPN용 외부 인터페이스 둘(eth0, eth1)이 있고, eth0의 IP는 Static NAT 장치로 변환 됩니다.

IP Selection by Remote Peer 섹션에서 다음을 설정합니다.

Using probing. Link redundancy mode 를 고릅니다.
High Availability 를 고릅니다.
Configure 를 클릭합니다.
Probe all addresses defined in the topology tab 을 고릅니다. Static NAT된 IP를 탐침하려면 Probe the following addresses 를 고르고 Add 를 클릭한 뒤 NAT 후 IP를 적고 OK 를 누릅니다.
Using ongoing probing 을 고릅니다.
OK 를 클릭합니다.
Access Control 정책을 설치합니다.

VPN 피어 사이에 트래픽 분산하기

구성에 따라 로컬 게이트웨이와 피어 사이, 그리고 로컬 게이트웨이의 가용 VPN 링크 사이에 트래픽을 분산하는 방법이 여러 가지 있습니다.

양쪽 끝에 외부 인터페이스가 여럿인 VPN Load Sharing

로컬 게이트웨이와 피어 게이트웨이가 각각 외부 인터페이스 둘(eth0, eth1) 을 VPN에 쓰는 시나리오입니다.

양쪽 모두(로컬·각 피어) 의 IP Selection by Remote Peer 섹션에서 다음을 설정합니다.

Using probing. Link redundancy mode 를 고릅니다.
Load Sharing 을 고릅니다.
Configure 를 클릭합니다.
Probe all addresses defined in the topology tab 을 고릅니다. 특정 외부 인터페이스만 탐침하려면 Probe the following addresses 를 고르고 Add 로 해당 인터페이스 IP를 적은 뒤 OK 를 누릅니다.
Using ongoing probing 을 고릅니다.
OK 를 클릭합니다.
Access Control 정책을 설치합니다.

한 링크(예: eth0)가 다운되면 트래픽은 자동으로 다른 링크(예: eth1) 로 흐릅니다. 이 구성이 되려면 라우팅 테이블이 다음 사이에 패킷을 양방향으로 흐르게 해야 합니다.

로컬과 피어 게이트웨이의 eth0 인터페이스 사이
로컬과 피어 게이트웨이의 eth1 인터페이스 사이

한쪽 끝에만 외부 인터페이스가 여럿인 VPN Load Sharing

로컬 게이트웨이는 VPN용 외부 인터페이스 둘(eth0, eth1), 피어는 외부 인터페이스 하나 인 시나리오입니다.

로컬 게이트웨이에서 다음을 설정합니다.

IP Selection by Remote Peer 섹션에서: Using probing. Link redundancy mode → Load Sharing. 그 결과 피어는 나가는 VPN 트래픽을 로컬 게이트웨이의 eth0·eth1 사이에 분산 합니다.
Outgoing Route Selection 섹션에서 다음 중 하나를 고릅니다.
- Operating system routing table 를 고르면: 로컬 게이트웨이는 나가는 VPN 트래픽에 자기 인터페이스 하나만 씁니다. 라우팅 테이블 기준으로, 피어의 단일 IP에 닿는 메트릭이 가장 낮고 가장 잘 맞는 경로 하나 만 씁니다.
- Route based probing 을 고르면: 로컬 게이트웨이는 나가는 VPN 트래픽을 두 나가는 링크 모두에 분산 합니다.
OK 를 클릭합니다.
Access Control 정책을 설치합니다.

Service-Based Legacy Link Selection

구성 절차는 sk56384 를 참고하세요. 게이트웨이 객체와, Management Server의 $FWDIR/conf/vpn_service_based_routing.conf 파일에서 필요한 설정을 합니다.

동작 설명

Service-Based Legacy Link Selection 으로 관리자는 서비스(또는 서비스 그룹)를 특정 인터페이스에 배정 해, 나가는 VPN 라우팅 결정과 대역폭 사용을 제어합니다. 나가는 연결의 암호화 트래픽은 그 트래픽의 서비스에 따라 배정된 인터페이스로 라우팅됩니다.

피어로 가는 VPN 링크는 라우팅 테이블에서 유도하고, 링크 가용성은 RDP 탐침으로 검사합니다. 어떤 서비스에 배정된 인터페이스를 통과하는 모든 VPN 링크가 RDP 탐침에 응답을 멈추면, 다른 탐침 모드와 마찬가지로 VPN 링크 페일오버 가 일어납니다. 그 인터페이스의 링크가 복구되면 새 나가는 연결은 거기에 배정 되고, 기존 연결은 끝날 때까지 백업 링크에 유지됩니다.

특정 서비스의 트래픽이 페일오버하지 않도록 설정할 수도 있습니다. 이 경우, 그 서비스 트래픽은 배정된 인터페이스가 RDP 탐침에 응답을 멈춰도 오직 그 인터페이스로만 라우팅됩니다.

같은 서비스를 둘 이상의 인터페이스에 배정 하면, 그 서비스 트래픽은 배정된 인터페이스들 사이에 분산되며, 새 나가는 연결마다 라운드 로빈 으로 다음 가용 링크를 씁니다. 특정 인터페이스에 배정되지 않은 서비스의 모든 트래픽 은 나머지 인터페이스들 사이에 분산됩니다. 그 나머지 인터페이스의 VPN 링크가 모두 다운되면, 암호화 트래픽은 특정 서비스용으로 구성된 인터페이스들 사이에 분산됩니다.

이 환경의 설정 파일은 다음과 같습니다.

Security Gateway   Interface   Service   [dont_failover]
London_GW          eth1        http
London_GW          eth1        ftp
Paris_GW           eth1        http
Paris_GW           eth1        ftp

대안으로, SmartConsole에서 HTTP·FTP를 묶은 Services Group 을 만들 수 있습니다. 이 그룹을 http_ftp_grp 라 하면 설정 파일은 다음과 같습니다.

Security Gateway   Interface   Service        [dont_failover]
London_GW          eth1        http_ftp_grp
Paris_GW           eth1        http_ftp_grp

세 인터페이스를 모두 써서 트래픽을 분산하려면, 각 게이트웨이에서 다음을 설정합니다.

IP Selection by Remote Peer 섹션에서: Using probing. Link redundancy mode → Load Sharing.
Outgoing Route Selection 섹션에서: Route based probing 을 고릅니다.
OK 를 클릭합니다.
Access Control 정책을 설치합니다.

대역폭을 제어하려면 하나 이상의 링크를 특정 서비스 전용으로 둡니다. 이 시나리오에서는 양쪽의 eth0·eth1을 SIP 전용 으로 둡니다. SIP는 eth0·eth1 사이에 분산되고, 나머지 트래픽은 eth2로 갑니다. eth0이나 eth1의 링크가 RDP 탐침에 응답을 멈추면 SIP는 다른 SIP 인터페이스(각각 eth1 또는 eth0) 로 페일오버합니다. eth2의 링크가 응답을 멈추면 모든 트래픽은 eth0 또는 eth1로 갑니다.

로컬 게이트웨이 "London_GW"에서 다음을 설정합니다.

IP Selection by Remote Peer 섹션에서: Using probing. Link redundancy mode → Load Sharing.
Outgoing Route Selection 섹션에서: Route based probing 을 고릅니다.
OK 를 클릭합니다.
Access Control 정책을 설치합니다.

대역폭을 제어하려면 로컬 게이트웨이의 eth1을 HTTP·FTP 전용 으로 둡니다. 로컬 게이트웨이는 나가는 HTTP·FTP를 eth1로, 나머지는 eth0으로 보냅니다. 이 시나리오에서 HTTP·FTP는 페일오버하지 않아야 하므로, eth1의 링크가 RDP 탐침에 응답을 멈춰도 오직 eth1로만 보냅니다. 이는 $FWDIR/conf/vpn_service_based_routing.conf 파일에서 dont_failover 문자열로 지정합니다.

Security Gateway   Interface   Service   [dont_failover]
London_GW          eth1        http      dont_failover
London_GW          eth1        ftp       dont_failover

이 설정은 로컬 게이트웨이의 나가는 VPN 트래픽에만 적용되므로, 피어는 HTTP·FTP를 로컬 게이트웨이의 어느 인터페이스로든 보낼 수 있습니다. 피어의 나가는 VPN 트래픽은 로컬의 eth0·eth1 사이에 분산됩니다.

Trusted Links

동작 설명

Trusted Links(신뢰 링크) 기능은 어떤 인터페이스를 VPN 트래픽에 대해 "신뢰됨(trusted)" 으로 설정해, 그 링크로 보내는 트래픽을 암호화하지 않게 합니다.

인터페이스를 신뢰로 설정하면, 그 인터페이스로 라우팅되는 트래픽은 평문(clear-text) 으로 가고, 다른 인터페이스의 트래픽은 여전히 암호화됩니다. 신뢰 인터페이스는 로컬·피어 양쪽에 대칭(symmetrically) 으로 구성해야 합니다. 한쪽만 신뢰로 설정하면, 비신뢰 인터페이스가 받은 평문 트래픽은 피어 게이트웨이가 드롭 합니다.

특정 링크를 신뢰로 설정하고 탐침(probing)을 쓴다면, 탐침은 신뢰 링크를 포함한 모든 링크 를 두고 연결에 쓸 링크를 고릅니다. 탐침은 다음 기준으로 링크를 고릅니다.

구성된 이중화 모드 — IP Selection by Remote Peer에서 Using probing. Link redundancy mode 를 고르고 High Availability 또는 Load Sharing 을 선택합니다.
$FWDIR/conf/vpn_service_based_routing.conf 에 Service-Based Legacy Link Selection이 구성 되었는지 여부.

신뢰 링크가 연결에 선택되면 트래픽은 암호화되지 않고, 비신뢰 링크가 선택되면 암호화됩니다.

알아 둘 제약이 있습니다.

MEP 구성 에서는, 신뢰 링크가 피어가 MEP 게이트웨이로 시작한 연결 에만 지원됩니다. MEP 게이트웨이가 시작해 신뢰 인터페이스로 라우팅된 비암호화 VPN 연결은 피어가 드롭 할 수 있습니다.
Traditional VPN 모드에서는 지원되지 않습니다. 이 모드에서는 신뢰 링크 설정이 무시되고 VPN 트래픽은 항상 암호화됩니다.
신뢰 링크는 R71 이상 Security Gateway에서 지원됩니다.

Trusted Links 구성하기

신뢰 링크는 Database Tool (GuiDBEdit Tool) 로 구성합니다.

Management Server에 연결된 모든 SmartConsole 창을 닫습니다.
Database Tool (GuiDBEdit Tool)로 Management Server에 연결합니다.
왼쪽 위 창에서 Network objects > network_objects 로 갑니다.
오른쪽 위 창에서 편집할 Security Gateway / Cluster 객체를 클릭합니다.
아래 창에서 인터페이스 집합(interfaces set) 안에 있는, 신뢰로 설정할 인터페이스를 찾습니다. 인터페이스 이름은 officialname 속성에 나타납니다.
그 신뢰 인터페이스 집합 안에서 vpn_trusted 속성 값을 true 로 바꿉니다(기본값: false).
신뢰 인터페이스를 피어에도 대칭으로 구성합니다. 한쪽만 설정하면 비신뢰 인터페이스가 받은 평문 트래픽을 피어가 드롭합니다.
변경을 저장합니다(File 메뉴 > Save All).
SmartConsole로 Management Server에 연결합니다.
SmartConsole에서 해당 게이트웨이/클러스터 객체에 Access Control 정책을 설치합니다.

Trusted Links 시나리오

로컬·피어 게이트웨이가 각각 외부 인터페이스 둘(eth0, eth1)을 VPN에 쓰고, 양쪽의 eth1을 신뢰 인터페이스 로 설정한 시나리오입니다. 따라서 로컬의 eth1에서 보낸 트래픽은 암호화되지 않은 채 피어의 eth1에 받아들여지고, 그 반대도 마찬가지입니다.

IP Selection by Remote Peer에서 Using probing. Link redundancy mode → High Availability → Configure → Primary IP address 로 신뢰 링크의 IP를 고르면, 신뢰 링크가 VPN 트래픽에 쓰입니다. 신뢰 링크가 RDP 탐침에 응답을 멈추면 eth0 링크가 쓰이고, 그 트래픽은 암호화 됩니다.
IP Selection by Remote Peer에서 Using probing. Link redundancy mode → Load Sharing 을 고르면, VPN 트래픽이 가용 링크 사이에 분산됩니다. eth0으로 라우팅된 연결은 암호화, 신뢰 링크로 라우팅된 연결은 비암호화 됩니다.

SIP는 두 eth1 사이의 신뢰 링크로 라우팅되어 암호화되지 않습니다. 신뢰 링크가 RDP 탐침에 응답을 멈추면 SIP는 eth0으로 라우팅되어 암호화 됩니다. SIP가 아닌 나머지 트래픽은 eth0 링크로 암호화되어 갑니다. 다만 eth0이 RDP 탐침에 응답을 멈추면 모든 트래픽은 신뢰 링크로 가며 암호화되지 않습니다.

On Demand Links (ODL)

동작 설명

Route based probing 은 On Demand Link (ODL) 사용을 가능하게 합니다. ODL은 모든 주 링크가 실패할 때 작동합니다. 장애가 감지되면 사용자 정의 스크립트 로 ODL을 켜고 라우팅 정보를 바꿉니다. ODL로 간주되려면, 그 메트릭이 구성된 최소값보다 커야 합니다.

이 시나리오에서 게이트웨이는 인터넷 연결용 외부 링크가 둘 — 하나는 ISP, 다른 하나는 ISDN 다이얼업이고, ISDN 다이얼업이 ODL 로 구성됩니다. Route based probing 메커니즘은 ODL이 아닌 링크를 모두 탐침해 메트릭이 가장 낮은 활성 링크 를 고릅니다(여기서는 ISP 링크). 우선순위가 더 높은 모든 링크가 못 쓰게 되면 스크립트로 ODL을 켜고, 링크가 다시 가용해지면 종료 스크립트가 자동으로 실행 되어 연결은 ISP 링크로 돌아갑니다.

On Demand Links 구성하기

ODL은 Outgoing Route Selection 에서 Route based probing 을 골랐을 때만 활성화할 수 있습니다. ODL 명령은 Database Tool (GuiDBEdit Tool) 로 구성합니다.

Security Gateway 객체의 속성	설명
`use_on_demand_links`	ODL을 활성화합니다. 기본값은 `false` 이며, `true` 로 바꿉니다.
`on_demand_metric_min`	ODL의 최소 메트릭 레벨을 정합니다. 이 값은 구성된 최소 메트릭과 같거나 커야 합니다.
`on_demand_initial_script`	ODL 스크립트의 이름입니다. ODL이 아닌 모든 경로가 응답을 멈출 때 실행됩니다. 스크립트는 게이트웨이의 `$FWDIR/conf/` 디렉터리에 둡니다.
`on_demand_shutdown_script`	실패했던 링크가 다시 가용해질 때 실행됩니다. 스크립트는 게이트웨이의 `$FWDIR/conf/` 디렉터리에 둡니다.

GuiDBEdit Tool을 쓰지 않으려면, use_on_demand_links 와 on_demand_metric_min 설정은 SmartConsole에서도 구성할 수 있습니다.

Menu > Global properties 를 클릭합니다.
왼쪽 패널에서 Advanced 페이지 > Configure 버튼을 클릭합니다.
VPN Advanced Properties 를 펼치고 Link Selection 을 클릭합니다.
use_on_demand_links 를 선택해 ODL을 활성화합니다.
on_demand_metric_min 필드에 ODL의 최소 메트릭 레벨을 설정합니다.
OK 로 Advanced Configuration 창을 닫습니다.
OK 로 Global Properties 창을 닫습니다.
Access Control 정책을 설치합니다.

Legacy Link Selection과 ISP Redundancy

ISP Redundancy 는 단일 또는 클러스터 게이트웨이가 여러 ISP 연결을 통해 인터넷에 붙도록 해, 안정적인 인터넷 연결을 제공합니다. 두 가지 동작 모드가 있습니다.

Load Sharing mode — 두 ISP에 모두 붙어, 지정한 가중치(weight)에 따라 나가는 연결의 부하를 ISP들 사이에 나눕니다. 새 연결은 무작위로 한 링크에 배정되고, 어떤 링크가 실패하면 새 나가는 연결은 모두 활성 링크로 갑니다. 이로써 WAN 대역폭을 늘리면서 연결 보호도 제공합니다. 단, ISP 링크 가중치는 게이트웨이 트래픽에만 지원됩니다.
Primary/Backup mode — 주(primary) 링크의 ISP로 붙다가, 주 ISP 링크가 실패하면 백업 ISP로 전환합니다. 주 링크가 복구되면 새 나가는 연결은 거기에 배정되고, 기존 연결은 끝날 때까지 백업 링크에 유지됩니다.

Legacy Link Selection과 ISP Redundancy 구성

Link Selection과 ISP Redundancy는 게이트웨이 객체의 Other > ISP Redundancy 페이지에서 구성합니다.

ISP Redundancy 창의 설정은 기본적으로 Link Selection 페이지에 적용되며, 기존 구성을 덮어씁니다. 다음 설정이 그대로 넘어옵니다.

ISP Redundancy가 구성되면 Link Selection 페이지의 기본 설정은 Use ongoing probing 이 됩니다. 다만 Link Selection은 ISP Redundancy 창에 구성된 ISP만 탐침합니다. 이로써 게이트웨이 인터페이스 하나의 연결이 끊겨도 VPN 터널의 연결 페일오버 가 가능합니다.
ISP Redundancy 모드가 Load Sharing 이면, Link Selection 페이지의 탐침 이중화 모드도 Load Sharing 이 됩니다.
ISP Redundancy 모드가 Primary/Backup 이면, Link Selection 페이지의 탐침 이중화 모드는 High Availability 가 됩니다.
- ISP Redundancy의 주 ISP 링크가 Link Selection 탐침의 Primary Address 로 설정됩니다. Primary Address는 IP Selection by Remote Peer > Use Probing > Configure(설정이 ISP Redundancy에서 유도되었으면 View)에서 확인합니다.

ISP Redundancy 설정이 Link Selection에 영향을 주지 않게 하려면, ISP Redundancy 페이지에서 Apply settings to VPN traffic 체크박스를 해제 하고 Link Selection 페이지에서 필요한 VPN 설정을 직접 합니다. 이는 평문 트래픽과 VPN 트래픽을 다르게 라우팅 하고 싶을 때 유용합니다(예: 평문은 Load Sharing, VPN은 High Availability를 쓰거나, 평문과 VPN에 다른 주 ISP를 쓰고 싶을 때).

Topology > ISP Redundancy 창에서 ISP Links·Redundancy mode 같은 설정을 구성합니다. 이 설정은 기본적으로 VPN 트래픽에 적용되고, 유도된 Link Selection 설정은 IPsec VPN > Link Selection 창에서 볼 수 있습니다.

다음 시나리오는 ISP Redundancy 페이지에서 Apply settings to VPN traffic 를 해제 하고, Link Selection과 ISP Redundancy에 서로 다른 설정을 둔 경우입니다.

이 시나리오에서 게이트웨이 "A", "B", "C"는 각각 ISP 링크로 구성된 인터페이스 둘을 가지며, 게이트웨이 "A"에 ISP Redundancy가 구성 됩니다. "A"는 ISP 1로 "B"에, ISP 2로 "C"에 연결해야 하고, 한쪽 ISP 링크가 못 쓰게 되면 다른 ISP를 씁니다. 이를 위해 게이트웨이 "A"의 관리자는 다음을 해야 합니다.

ISP Redundancy 창에서 Apply settings to VPN traffic 박스를 해제합니다.
Link Selection 창에서 Outgoing Route Selection 을 Route based probing 으로 다시 구성합니다.
라우팅 테이블을 구성해, 피어 "B"에는 ISP 1, 피어 "C"에는 ISP 2가 가장 높은 우선순위가 되게 합니다.

Legacy Link Selection과 비-Check Point 장치

동작 설명

일부 Link Selection 기능에 쓰이는 RDP 탐침 은 Check Point 고유이며 Check Point 개체끼리만 동작합니다. 비-Check Point 장치에서는 지원되지 않습니다.

비-Check Point 게이트웨이에서는 RDP 탐침이 동작하지 않으므로, Check Point 게이트웨이가 비-Check Point 게이트웨이로 VPN 트래픽을 보낼 때 다음 결과가 적용됩니다.

IP Selection by Remote Peer 섹션의 Use probing. Link redundancy mode 옵션으로는 비-Check Point 장치의 IP를 판단할 수 없습니다. 이 섹션의 다른 방법을 쓰세요.
다음 설정 조합은 비-Check Point 게이트웨이와 동작하지 않습니다.
1. Outgoing Route Selection에서 Route based probing + Load Sharing 을 골랐고,
2. Service-Based Legacy Link Selection을 구성한 경우.

로컬 게이트웨이에 Load Sharing 이나 Service-Based Legacy Link Selection 이 켜져 있어도 피어가 비-Check Point 장치라면, 로컬 게이트웨이는 비-Check Point 장치로 링크 하나만 씁니다 — 가장 잘 맞는(최장 prefix length) 링크 중 메트릭이 가장 낮은 것입니다. - 비-Check Point 장치로 가는 VPN 트래픽에 Route based probing 을 골랐다면, 로컬 게이트웨이는 항상 가장 잘 맞는(최장 prefix length) 링크 중 메트릭이 가장 낮은 링크를 씁니다.