08VPN 토폴로지 — Domain-Based·Route-BasedVPN 토폴로지 — Domain-Based·Route-Based

개요 — VPN 도메인을 보고 길을 정한다

Domain-Based VPN 은 같은 커뮤니티 안의 Security Gateway 사이에서 VPN 트래픽이 어떻게 라우팅될지를 제어 합니다. 어떤 Security Gateway 뒤에 있는 호스트로 트래픽을 보내려면, 먼저 그 게이트웨이의 VPN 도메인을 정의 해야 합니다. 라우팅 구성은 SmartConsole 에서 하거나, 게이트웨이별 VPN 라우팅 설정 파일인 vpn_route.conf 에서 합니다.

대표적인 그림을 떠올려 보면 이해가 쉽습니다. Security Gateway "A" 뒤의 호스트가 Security Gateway "B" 뒤의 호스트에 접속하려 합니다. 그런데 기술적·정책적 이유로 A와 B가 직접 VPN 터널을 맺을 수 없 습니다. 이때 VPN Routing 을 쓰면, A와 B가 중간의 Security Gateway "C"를 거쳐 터널을 맺어 통신할 수 있습니다. 즉 A↔C 터널과 B↔C 터널이 있으면 C가 둘 사이를 중계합니다.

VPN Routing과 Access Control은 함께 간다

여기서 꼭 기억할 것 이 있습니다. VPN 라우팅 연결도 다른 연결과 똑같이 보안 정책(Access Control) 규칙의 통제를 받 습니다. VPN 라우팅을 아무리 정확히 구성했더라도, 그 연결을 허용하지 않는 정책 규칙이 있으면 연결은 차단 됩니다.

예를 들어 어떤 Security Gateway에 "내부 네트워크에서 외부로 나가는 모든 FTP 트래픽 금지"라는 규칙이 있다고 합시다. 피어 게이트웨이가 이 게이트웨이로 FTP 연결을 열면, 그 연결은 규칙에 걸려 차단 됩니다.

그래서 VPN 라우팅이 성공하려면, 중앙 게이트웨이에서 인바운드·아웃바운드 양방향 트래픽을 모두 한 규칙으로 덮 어야 합니다. 이 규칙을 만드는 방법은 바로 아래 SmartConsole 절차에서 설명합니다.

Domain-Based VPN에서 VPN 라우팅 구성하기

가장 흔한 VPN 라우팅 시나리오는 SmartConsole의 Star VPN Community 로 구성합니다. 더 세밀하게 제어하고 싶으면 Management Server에 있는 해당 vpn_route.conf 파일을 직접 편집할 수도 있습니다. 단, VPN 라우팅은 같은 VPN 커뮤니티에 속한 Security Gateway 사이에서만 구성할 수 있습니다.

SmartConsole에서 Star 커뮤니티로 구성하기

설정 파일 'vpn_route.conf'로 구성하기

더 세밀하게 제어하려면 Management Server에서 해당 vpn_route.conf 파일을 편집합니다. 이 파일은 네트워크 객체의 이름이 담긴 텍스트 파일 이며, 형식은 다음과 같습니다.

Destination    Next hop router interface    Install on

세 요소는 탭(tab)으로 구분 합니다.

간단한 예를 봅시다. 중앙(Hub) 게이트웨이 하나와 위성(spoke) 게이트웨이 둘로 구성되고, 모든 장비가 같은 Security Management Server로 관리되며 같은 VPN 커뮤니티에 속해 있습니다. 위성끼리는 Telnet과 FTP만 암호화해 Center를 거쳐 라우팅 한다고 합시다. Star VPN 커뮤니티로도 쉽게 할 수 있지만, vpn_route.conf로도 같은 결과를 만들 수 있습니다.

이 예에서 각 항목의 뜻은 이렇습니다.

파일 내용은 값을 공백으로 구분 해 이렇게 적습니다.

Spoke_B_VPN_DOM Hub_C Spoke_A
Spoke_A_VPN_DOM Hub_C Spoke_B

Management Server에서 'vpn_route.conf' 파일의 위치

vpn_route.conf 파일에는 Domain-Based Site to Site VPN의 구성 이 들어 있습니다. 다음을 지켜야 합니다.

  mdsenv <IP Address or Name of Domain Management Server>
  

대상 Security Gateway 버전에 따라 R82 Security Management Server와 Domain Management Server에서의 파일 위치는 다음과 같습니다.

'Accept VPN Traffic Rule' 구성하기

암호화된 트래픽을 모두 받아들이도록 커뮤니티 차원에서 설정하는 절차입니다. SmartConsole에서:

여러 Hub 구성하기 (Multiple Hubs)

Hub가 둘인 경우를 살펴봅시다. Hub "A"에는 spoke 둘("spoke_A1", "spoke_A2")이 붙어 있고, Hub "B"에는 spoke 하나("spoke_B")가 붙어 있습니다. Hub "A"는 Security Management Server "A"가, Hub "B"는 Security Management Server "B"가 관리합니다. 두 개의 Star VPN 커뮤니티(각각 Hub A·Hub B 중심)에서 다음을 원합니다.

커뮤니티 구성은 이렇습니다.

Security Management Server "A"에서의 구성

서버 "A"의 vpn_route.conf 파일은 다음과 같습니다.

여기서 spoke "A1"·"A2" 는 네트워크 그룹 객체 A_spokes 로 묶습니다. 알맞은 보안 정책 규칙은 다음과 같습니다.

Security Management Server "B"에서의 구성

서버 "B"의 vpn_route.conf 파일은 다음과 같습니다.

알맞은 보안 정책 규칙은 다음과 같습니다.

LSM 프로파일로 VPN 구성하기

두 개의 SmartLSM 프로파일 사이에 Star VPN Community를 구성할 수도 있습니다. 아래 절차는 SmartLSM Gateway Profile 과 SmartLSM Cluster Profile 을 묶는 예이지만, SmartLSM Cluster Profile 둘, 또는 SmartLSM Gateway Profile 둘 로 커뮤니티를 만들 수도 있습니다.

구성은 다음 네 곳에서 이루어집니다 — ①SmartConsole, ②Security Management Server의 CLI, ③SmartProvisioning GUI, ④Center Security Gateway의 CLI. 자세한 절차는 R82 SmartProvisioning Administration Guide 를 참고하세요.

개요 — 가상 인터페이스로 터널을 다룬다

Route-Based VPN 의 핵심 아이디어는, 피어 Security Gateway 사이에 VTI(VPN Tunnel Interface) 를 만드는 것이 마치 둘을 직접 케이블로 연결한 것과 같다 는 데 있습니다.

VTI 는 피어 게이트웨이의 VPN 도메인으로 들어가는 통로 역할을 하는 가상 인터페이스 입니다. 각 VTI는 하나의 게이트웨이로 가는 하나의 터널 에 연결되며, 터널 자체와 그 속성은 이전과 마찬가지로 두 게이트웨이를 잇는 VPN Community 가 정의합니다. 피어 게이트웨이에도 서로 대응하는 VTI 를 구성하면, 각 게이트웨이의 기본 IP 라우팅이 다른 인터페이스처럼 트래픽을 터널로 보냅니다.

피어 게이트웨이의 VPN 도메인으로 향하는 모든 트래픽은 연결된(associated) VTI를 거쳐 라우팅됩니다. 이 구조 덕분에 동적 라우팅 프로토콜이 VTI를 쓸 수 있게 됩니다. 게이트웨이에서 도는 동적 라우팅 데몬이 IPsec 터널 반대편 데몬과 라우팅 정보를 교환 하는데, 상대가 한 홉(single hop) 거리처럼 보입니다.

단, Route-Based VPN은 같은 VPN 커뮤니티 안의 Security Gateway 사이에서만 구현됩니다. 또한 배포하려면 Security Management Server의 Rule Base에 Directional Rule(방향 규칙) 을 구성해야 합니다(Directional VPN의 "Directional Enforcement within a Community" 참고).

VPN Tunnel Interface (VTI)

VTI 는 VPN 터널과 연관되어 원격 피어에 연결되는, Security Gateway의 가상 인터페이스 입니다. 각 Security Gateway에 VTI를 만들면, 그것이 원격 VPN 피어의 VTI와 짝을 이룹니다. 로컬 게이트웨이에서 VTI를 거쳐 라우팅된 트래픽은 암호화되어 짝이 되는 피어 게이트웨이로 전달됩니다.

예를 들어 다음과 같은 시나리오를 봅시다.

가상 인터페이스는 원격 피어에 직접 연결된 point-to-point 인터페이스처럼 동작합니다. 네트워크 호스트 사이 트래픽은 OS의 IP 라우팅으로 VPN 터널에 실립니다. 여전히 Security Gateway 객체와 VPN Community(그리고 Access Control 정책)는 필요해서 어떤 터널을 쓸 수 있는지 정의하지만, 각 피어의 VPN 암호화 도메인은 더 이상 필요하지 않 습니다. 암호화 여부는 트래픽이 가상 인터페이스를 거쳐 라우팅되느냐 에 달려 있고, 동적 라우팅 프로토콜(OSPF/BGP)이 있으면 라우팅이 동적으로 바뀝니다.

여기엔 주의할 함정 이 하나 있습니다. GWb에서 시작된 연결이 VTI를 거쳐 GWc(또는 GWc 뒤의 서버)로 라우팅되고 implied rule로 허용되면, 그 연결은 VTI의 로컬 IP를 출발지 IP로 달고 평문으로 GWb를 떠 납니다. 만약 이 IP가 라우팅 불가능한 주소면 응답 패킷이 사라 집니다. 해결책은 다음과 같습니다.

이렇게 route-based VPN에서 해당 IP를 제외하더라도, Domain-Based VPN 정의를 써서 그 주소로 가는 다른 연결(implied rule을 타지 않는 연결)을 여전히 암호화할 수 있습니다.

VTI는 두 가지 방식으로 구성합니다.

동적 라우팅 프로토콜 사용하기

VTI를 쓰면 Security Gateway 사이에 동적 라우팅 프로토콜로 라우팅 정보를 교환 할 수 있습니다. Gaia가 지원하는 동적 라우팅 프로토콜은 다음과 같습니다.

클러스터 환경에서의 VTI

클러스터 환경에서 numbered VTI를 구성할 때는 다음을 고려해야 합니다.

Gaia 운영체제에서 VTI 구성하기

구체적인 VTI 구성 방법은 R82 Gaia Administration Guide 의 Network Management 장 > Network Interfaces > VPN Tunnel Interfaces 절을 참고하세요.

Route-Based VPN 활성화하기

한 게이트웨이를 Domain-Based VPN과 Route-Based VPN 모두로 구성하면, 기본적으로 Domain-Based VPN이 우선 합니다. Route-Based VPN을 우선하게 만들려면, 비어 있는 더미(dummy) 그룹을 만들어 VPN 도메인에 할당 해야 합니다.

Numbered VTI 구성 예제

다음은 numbered VTI 구성 예제입니다. 시나리오의 Security Gateway는 다음과 같습니다.

VTI는 다음을 잇습니다 — "Cluster GWa" 멤버들과 "GWb", "Cluster GWa" 멤버들과 "GWc", 그리고 "GWb"와 "GWc". IP 구성은 다음과 같습니다.

각 게이트웨이에서 VTI를 구성하는 절차는 모두 R82 Gaia Administration Guide 의 VPN Tunnel Interfaces 절을 참고하되, 설정할 값은 아래와 같습니다.

1. member_GWa1에 VTI 구성

a. GWb용 numbered VTI

b. GWc용 numbered VTI

2. member_GWa2에 VTI 구성

a. GWb용 — Peer GWb, Type Numbered, Local 10.0.1.12, Remote 10.0.0.2, ID는 1~99 정수(모든 멤버에서 동일).

b. GWc용 — Peer GWc, Type Numbered, Local 10.0.1.22, Remote 10.0.0.3, ID는 1~99 정수(모든 멤버에서 동일).

3. GWb에 VTI 구성

a. Cluster GWa용 — Peer ClusterGWa, Type Numbered, Local 10.0.0.2, Remote 10.0.1.10. 클러스터 멤버들에서 GWb용으로 구성한 것과 같은 ID 를 씁니다.

b. GWc용 — Peer GWc, Type Numbered, Local 10.0.0.2, Remote 10.0.0.3. 이 VTI는 GWb와 GWc에서 같은 ID 를 씁니다.

4. GWc에 VTI 구성

a. Cluster GWa용 — Peer ClusterGWa, Type Numbered, Local 10.0.0.3, Remote 10.0.1.20. 클러스터 멤버들에서 GWc용으로 구성한 것과 같은 ID 를 씁니다.

b. GWb용 — Peer GWb, Type Numbered, Local 10.0.0.3, Remote 10.0.0.2. 이 VTI는 GWc와 GWb에서 같은 ID 를 씁니다.

5. SmartConsole에서 Cluster 객체 구성

클러스터 멤버들에 VTI를 구성한 다음에는, SmartConsole의 클러스터 객체에서 이 VTI들의 Cluster Virtual IP 를 구성해야 합니다.

a. 왼쪽 탐색 패널에서 Gateways & Servers 를 클릭합니다. b. 클러스터 객체를 우클릭하고 Edit 를 선택합니다. c. 왼쪽 트리에서 Network Management 를 클릭합니다. d. Get Interfaces > Get Interfaces Without Topology 를 클릭합니다. VTI들이 Topology 열에 Point to point 로 나타납니다.

다음 조건이 모두 맞으면 인터페이스들은 같은 VTI의 멤버 입니다 — Peer, Remote IP address, Interface name. e. VTI에 Cluster Virtual IP를 구성합니다. - VTI 인터페이스를 선택하고 Edit 를 클릭합니다. - General 페이지에서 Virtual IP address 를 입력합니다. - OK 를 클릭합니다.

VTI에서 동적 라우팅 프로토콜 켜기 — 예제

다음 예제는 VTI에서 OSPF 동적 라우팅 프로토콜을 켜는 방법을 보여 줍니다. 단일 멤버용과 클러스터 멤버용의 network 명령이 같지 않 다는 점에 유의하세요. VTI와 고급 라우팅 명령은 R82 Gaia Administration Guide 와 R82 Gaia Advanced Routing Administration Guide 를 참고합니다. Cisco GRE 장비와 피어링할 때는 point-to-point GRE 터널이 필요 합니다.

member_GWa1에서의 OSPF 구성 — vpnt1은 member_GWa1과 GWb 사이, vpnt2는 member_GWa1과 GWc 사이의 VTI입니다.

member_GWa1:0> set ospf area 0.0.0.0 on
member_GWa1:0> set router-id 170.170.1.10
member_GWa1:0> set ospf interface vpnt1 area 0.0.0.0 on
member_GWa1:0> set ospf interface vpnt2 area 0.0.0.0 on
member_GWa1:0> set route-redistribution to ospf2 from kernel all-ipv4-routes on
member_GWa1:0> save config
member_GWa1:0> show configuration ospf

member_GWa2에서의 OSPF 구성 — vpnt1은 member_GWa2와 GWb 사이, vpnt2는 member_GWa2와 GWc 사이의 VTI입니다.

member_GWa2:0> set ospf area 0.0.0.0 on
member_GWa2:0> set router-id 170.170.1.10
member_GWa2:0> set ospf interface vpnt1 area 0.0.0.0 on
member_GWa2:0> set ospf interface vpnt2 area 0.0.0.0 on
member_GWa2:0> set route-redistribution to ospf2 from kernel all-ipv4-routes on
member_GWa2:0> save config
member_GWa2:0> show configuration ospf

GWb에서의 OSPF 구성 — vpnt1은 GWb와 Cluster GWa 사이, vpnt3은 GWb와 GWc 사이의 VTI입니다.

GWb:0> set ospf area 0.0.0.0 on
GWb:0> set router-id 180.180.1.1
GWb:0> set ospf interface vpnt1 area 0.0.0.0 on
GWb:0> set ospf interface vpnt3 area 0.0.0.0 on
GWb:0> set route-redistribution to ospf2 from kernel all-ipv4-routes on
GWb:0> save config
GWb:0> show configuration ospf

GWc에서의 OSPF 구성 — vpnt2는 GWc와 Cluster GWa 사이, vpnt3은 GWc와 GWb 사이의 VTI입니다.

GWc:0> set ospf area 0.0.0.0 on
GWc:0> set router-id 190.190.1.1
GWc:0> set ospf interface vpnt2 area 0.0.0.0 on
GWc:0> set ospf interface vpnt3 area 0.0.0.0 on
GWc:0> set route-redistribution to ospf2 from kernel all-ipv4-routes on
GWc:0> save config
GWc:0> show configuration ospf

SmartConsole에서 VTI에 Anti-Spoofing 구성하기

VPN 터널로 멀티캐스트 패킷 라우팅하기

멀티캐스트(Multicast) 는 하나의 메시지를 선택된 수신자 그룹에게 보내는 방식입니다. IP 멀티캐스팅 애플리케이션은 각 데이터그램(IP 패킷)을 한 부만 만들어 받기를 원하는 컴퓨터 그룹에 주소를 지정 합니다. 즉 단일 수신자(unicast 주소)가 아니라 수신자 그룹(multicast 주소)에게 데이터그램을 보내 고, 네트워크가 그것을 받아야 하는 네트워크에만 전달합니다. 이 기능에는 PIM 이 필요합니다. 멀티캐스팅 일반은 R82 Security Management Administration Guide 의 Access Control Policy 생성 장 > Multicast Access Control 절을 참고하세요.

멀티캐스트 트래픽은 VTI(같은 물리 인터페이스에 연관된 가상 인터페이스)로 구성된 VPN 터널을 통해 암호화·전달 될 수 있습니다. 보내는 쪽·받는 쪽의 모든 참여 게이트웨이가 VPN 터널마다 가상 인터페이스를 가져야 하고, 모든 참여 게이트웨이에서 멀티캐스트 라우팅 프로토콜이 켜져 있어야 합니다.

랑데부 포인트(rendezvous point) 역할을 하는 게이트웨이에서 멀티캐스트 서비스를 켜려면, 그 게이트웨이의 보안 정책에 규칙을 추가해 특정 멀티캐스트 서비스만 평문으로 받아들이고, 나머지 서비스는 커뮤니티를 통해서만 받게 합니다. 참여하는 모든 게이트웨이에 멀티캐스트 프로토콜·서비스를 허용하는 대응 규칙 을 만들어야 합니다. 예를 들면 다음과 같습니다.