11Wire Mode·Directional VPNWire Mode·Directional VPN

Wire Mode 개요

Wire Mode 는 기존 연결이 방화벽 적용을 우회해 성공적으로 페일오버(fail over)되도록 해 연결성을 개선 합니다. VPN 커뮤니티 안의 트래픽은 정의상 이미 사설이고 안전하므로, 많은 경우 VPN 연결에 대한 방화벽과 그 규칙은 불필요합니다. Wire Mode를 쓰면 내부 인터페이스와 커뮤니티를 "신뢰(trusted)"로 정의해 VPN 연결에 대해 방화벽을 우회 할 수 있습니다.

패킷이 Security Gateway에 도착하면 Security Gateway는 그 패킷에 대해 두 가지를 스스로 묻습니다.

두 질문에 모두 "예"이고, 두 Security Gateway가 속한 VPN 커뮤니티가 ="Wire Mode enabled"= 로 지정되어 있다면, stateful inspection이 적용되지 않고 신뢰 인터페이스 사이의 트래픽이 방화벽을 우회 합니다. stateful inspection이 일어나지 않으므로 버려지는(discarded) 패킷이 없 으며, 이때 VPN 연결은 전용 선(wire)을 따라 흐르는 다른 연결과 다를 바 없습니다 — 이것이 "Wire Mode"라는 이름의 뜻입니다. 또한 stateful inspection이 더 이상 일어나지 않으므로, 비(非)Wire Mode 구성에서는 state 검증을 통과하지 못하던 동적 라우팅 프로토콜(dynamic routing protocols) 을 이제 배포할 수 있습니다. 따라서 Wire Mode는 Route-Based VPN을 가능하게 합니다.

Wire Mode 시나리오

Wire Mode는 여러 인프라에서 연결성과 성능을 높이는 데 쓰입니다. 다음은 Wire Mode 적용으로 이득을 보는 시나리오들입니다.

MEP 구성에서의 Wire Mode

이 시나리오의 조건은 다음과 같습니다.

이 경우 M1이 다운되면 연결이 M2로 페일오버됩니다. Host 2를 떠난 패킷은 M1 뒤의 라우터에 의해 M2로 재지정되는데, M2가 백업 Security Gateway로 지정되어 있기 때문입니다. Wire Mode가 없다면 M2에서 stateful inspection이 적용되어 연결이 끊깁니다. 다른 Security Gateway를 통해 세션이 시작된 뒤 어떤 Security Gateway로 들어오는 패킷은 "out-of-state" 패킷으로 간주되기 때문입니다. 그러나 M2의 내부 인터페이스가 "신뢰"이고 커뮤니티에 Wire Mode가 켜져 있으므로, stateful inspection이 수행되지 않고 M2가 정보를 잃지 않고 연결을 성공적으로 이어 갑니다.

Route-Based VPN과 함께 쓰는 Wire Mode

이 시나리오의 조건은 다음과 같습니다.

위성 커뮤니티에서는 중앙 Security Gateway가 커뮤니티 안 위성 Security Gateway 사이의 트래픽을 라우팅하는 데 쓰입니다. 이 경우 위성 Security Gateway에서 온 트래픽은 Security Gateway C가 그저 재라우팅(reroute)할 뿐, C의 방화벽을 통과하지는 않 습니다. 따라서 C에서는 stateful inspection이 필요하지 않습니다. 커뮤니티와 C에 Wire Mode가 켜져 둘이 신뢰 상태이므로 stateful inspection이 우회됩니다. 단, Security Gateway A와 B에서는 stateful inspection이 그대로 수행 됩니다.

두 VPN 커뮤니티 사이의 Wire Mode

이 시나리오의 조건은 다음과 같습니다.

Wire Mode는 같은 커뮤니티 멤버가 아닌 두 Security Gateway 사이의 VPN 트래픽을 라우팅할 때 도 켤 수 있습니다. Security Gateway C는 두 커뮤니티 모두의 멤버이므로 두 커뮤니티를 모두 신뢰로 인식합니다. A 뒤의 Host 1이 B 뒤의 Host 2로 연결을 시작하면 C가 두 커뮤니티 사이의 트래픽을 라우팅하는 데 쓰이는데, 트래픽이 실제로 C로 들어가는 것은 아니므로 C에서 stateful inspection이 필요하지 않습니다. 단, Security Gateway A와 B에서는 stateful inspection이 그대로 수행됩니다.

Wire Mode의 특별 고려사항

Wire Mode 구성하기

Wire Mode는 두 곳에서 구성합니다.

VPN 커뮤니티에서 Wire Mode 켜기

특정 Security Gateway에서 Wire Mode 켜기

Directional VPN 개요

Security Policy Rule Base의 VPN 열에 VPN 커뮤니티를 선택하면, 출발지·목적지 IP 주소가 커뮤니티 안의 어느 Security Gateway든 될 수 있습니다. 다시 말해 트래픽이 양방향(bidirectional)이라, 어느 Security Gateway든 연결의 출발지가 될 수도 목적지가 될 수도 있습니다. 그런데 관리자가 회사 보안 정책에 맞춰 트래픽을 한 방향으로만 강제 하고 싶거나, VPN 커뮤니티에 포함되지 않은 Security Gateway를 오가는 암호화 트래픽을 허용 하려면 어떻게 해야 할까요? 이런 강제를 가능하게 하려고 VPN은 Directional VPN 을 제공합니다.

Directional VPN은 출발지 주소가 어디여야 하고, 목적지 주소가 어디여야 하는지를 명시 합니다. 이렇게 하면 다음 두 곳에서 강제가 이루어질 수 있습니다.

커뮤니티 안에서의 방향 강제

아래 예시는 MyIntranet 이라는 단순한 Mesh VPN 커뮤니티를 보여 줍니다. "MyIntranet Mesh" 안의 VPN 트래픽은 양방향이라, 어느 Security Gateway(또는 그 VPN 도메인 뒤의 호스트)든 연결의 출발지나 목적지가 될 수 있습니다.

매치 조건은 여러 복합(compound) 객체로 표현되며, 다음 방향으로 트래픽을 강제합니다.

방향에 구성할 수 있는 객체들

다음 표는 방향에 구성할 수 있는 모든 객체를 보여 주며, Directional VPN을 위해 새로 만들어진 세 객체(External_clear, Internal_clear, Any Traffic)도 포함합니다.

한 규칙에 구성할 수 있는 VPN 방향의 개수에는 제한이 없습니다. 다만 방향 강제가 많아지면 표준 양방향 조건으로 대체하는 것을 고려 하는 편이 좋습니다.

커뮤니티 사이의 방향 강제

VPN Directional Enforcement는 두 VPN 커뮤니티 사이 에서도 이루어질 수 있습니다. 이 경우 한 Security Gateway를 두 커뮤니티 모두의 멤버이자 둘 사이의 강제 지점(enforcement point) 으로 구성해야 합니다. 두 커뮤니티의 다른 모든 피어 Security Gateway는, (Management Server에 구성된) 해당 vpn_route.conf 파일에 강제 지점 Security Gateway로 가는 라우트 항목을 가지고 있어야 합니다.

강제 지점 Security Gateway로 가는 라우트 항목을 추가하려면, (강제 지점 Security Gateway를 제외한) 커뮤니티 내 각 Security Gateway의 관리 모듈에서, (Management Server에 구성된) 해당 vpn_route.conf 파일에 다음 항목을 추가합니다.

항목에 쓰이는 변수는 다음과 같습니다.

아래 예시에서 Washington 은 Mesh 커뮤니티, London 은 VPN Star입니다.

강제 지점 Security Gateway에 대해 Access Control Policy Rule Base에 다음 Directional VPN 규칙을 구성해야 합니다.

이 규칙은 강제 지점 Security Gateway를 통과해 Washington과 London 커뮤니티 사이를 오가는 모든 VPN 트래픽에 적용됩니다. Washington Mesh의 출발지에서 연결이 열리고 목적지가 London Star에 있으면 연결이 허용되며, 그렇지 않으면 거부됩니다.

한 VPN 커뮤니티 안에서 Directional VPN 구성하기

여러 VPN 커뮤니티 사이에서 Directional VPN 구성하기