VPN > 설정 페이지에는 VPN 정책 구성을 위한 Dell SonicWALL 기능이 나와 있습니다. 이 페이지에서 사이트 간 VPN 정책과 GroupVPN 정책을 구성할 수 있습니다.
VPN(Virtual Private Network)은 공용 인터넷을 통해 둘 이상의 컴퓨터 또는 보호된 네트워크 간의 보안 연결 기능을 제공하고, 올바른 주체들이 정보를 주고받을 수 있도록 하는 인증 기능과 전송 중인 정보를 보거나 조작할 수 없도록 보호하는 보안 기능을 제공합니다.
IPsec(인터넷 프로토콜 보안) 및 SSL(Secure Socket Layer)이 발명되기 전에는 원격 컴퓨터 또는 네트워크 간의 보안 연결을 사용하려면 전용선이나 위성 링크가 필요했습니다. 이 방법은 유동적이지 않고 비용도 많이 들었습니다.
VPN은 인터넷을 통한 보안 터널을 설정함으로써 안정성과 보안 수준이 이전과 비슷한 연결 기능을 생성합니다. 이 터널은 물리적 연결이 아니여서 보다 유동적이기 때문에 언제든지 변경하여 노드를 추가, 변경하거나 완전히 제거할 수 있습니다. 또한 기존 인터넷 인프라를 사용하므로 비용도 훨씬 저렴합니다.
오늘날 널리 사용되는 주요 VPN의 유형은 다음의 두 가지입니다.
• IPsec VPN: IPsec은 네트워크 통신의 패킷 처리 레이어 보안에 필요한 프로토콜 집합입니다. IPsec의 장점은 개별 사용자 컴퓨터를 변경하지 않고도 보안 관련 작업을 처리할 수 있다는 것입니다. SonicOS에서는 IPsec VPN 만들기 및 관리 작업을 지원합니다.
• IPsec에서는 두 가지 보안 서비스, 즉 데이터 보낸 사람의 인증을 기본적으로 허용하는 AH(인증 헤더)와 보낸 사람 인증/데이터 암호화를 모두 지원하는 ESP(Encapsulating Security Payload) 중에서 선택할 수 있습니다. 이러한 각 서비스와 연관된 구체적인 정보는 IP 패킷 헤더 다음에 오는 헤더의 패킷에 삽입됩니다.
• SSL VPN: SSL(Secure Socket Layer)은 대개 HTTPS를 사용하는 인터넷의 메시지 전송 보안을 관리하는 프로토콜입니다. SSL은 인터넷의 HTTP(Hypertext Transfer Protocol) 및 TCP(전송 제어 프로토콜) 레이어 사이에 있는 프로그램 레이어를 사용합니다. 또한 RSA의 공용-개인 키 암호화 시스템을 사용하며, 디지털 인증서도 사용합니다. SSL VPN은 SSL을 사용하여 VPN 터널을 보호합니다.
• SSL VPN의 장점 중 하나는 대다수 웹 브라우저에서 SSL이 기본 제공된다는 것입니다. 따라서 특수한 VPN 클라이언트 소프트웨어나 하드웨어가 필요하지 않습니다.
Note Dell SonicWALL에서는 SonicOS를 실행하는 Dell SonicWALL 네트워크 보안 어플라이언스와 별도로 또는 함께 사용할 수 있는 SSL VPN 장치를 제공합니다. Dell SonicWALL SSL VPN 어플라이언스에 대한 자세한 내용은 다음 Dell SonicWALL 웹 사이트를 참조하십시오. http://www.SonicWALL.com/us/products/Secure_Remote_Access.html
IPsec VPN 트래픽은 다음의 두 단계로 보호됩니다.
• 인증: 첫 단계에서는 공용-개인 키 쌍의 공용 키 부분을 교환하여 트래픽을 보낸 사람과 받는 사람의 신뢰성을 설정합니다. 이 단계가 성공해야 VPN 터널을 설정할 수 있습니다.
• 암호화: AES, 3DES 등의 암호화 알고리즘을 사용하여 VPN 터널의 트래픽을 암호화합니다.
VPN의 각 노드에서 동일하게 입력해야 하는 수동 키를 사용하는 경우가 아니면, VPN 구성원을 인증하고 데이터를 암호화/암호 해독하기 위한 정보 교환에서는 IKE(Internet Key Exchange) 프로토콜을 사용하여 인증 정보(키)를 교환하고 VPN 터널을 설정합니다. SonicOS Enhanced는 IKE의 두 버전을 지원합니다.
• IKE 버전 1
• IKEv2
IKE 버전 1은 2단계 프로세스를 사용하여 VPN 터널을 보호합니다.
• 인증 단계인 IKE 단계 1에서는 터널 양쪽의 노드 또는 게이트웨이가 서로를 인증하고, 암호화/암호 해독 키를 교환하며, 보안 터널을 설정합니다.
• 협상 단계인 IKE 단계 2에서는 인증된 두 노드 또는 게이트웨이가 VPN을 통해 전달된 데이터에서 사용할 암호화/데이터 확인 방법을 협상(해시 기능 사용)하고, 터널의 SA(보안 연결) 수와 암호화/암호 해독 키를 재협상해야 할 때까지 소요되는 수명을 협상합니다.
IKE 단계 1
IKEv1에는 인증 정보를 교환하는 두 가지 모드, 즉 메인 모드와 적극적인 모드가 있습니다.
메인 모드: VPN을 시작하는 노드 또는 게이트웨이가 수신 쪽의 노드 또는 게이트웨이를 쿼리하고, 양쪽에서 인증 방법과 공개 키 및 ID 정보를 교환합니다. 이 모드에서는 대개 6개의 메시지를 교환해야 합니다. 메인 모드의 인증 메시지 순서는 다음과 같습니다.
1. 출발지에서 지원하는 암호화 알고리즘 목록을 보냅니다.
2. 목적지에서 지원되는 암호화 알고리즘 목록을 사용하여 회신합니다.
3. 출발지에서 해당하는 첫 번째 암호화 알고리즘용 공개 키(Diffie-Hellman 공개/개인 키 쌍의 일부분)를 보냅니다.
4. 목적지에서 같은 암호화 알고리즘용 공개 키를 사용하여 회신합니다.
5. 출발지에서 ID 정보(보통 인증서)를 보냅니다.
6. 목적지에서 ID 정보를 사용하여 회신합니다.
적극적인 모드: 이 모드에서는 인증 시 교환되는 메시지 수를 절반으로 줄이기 위해 사용할 암호화 알고리즘을 협상하지 않습니다. 출발지에서 특정 알고리즘을 제안하면 목적지가 해당 알고리즘의 지원 여부를 회신합니다.
1. 출발지에서 사용할 암호화 알고리즘을 제안한 후 해당 공개 키를 보냅니다.
2. 목적지에서 공개 키와 ID 증명을 사용하여 회신합니다.
3. 출발지에서 ID 증명을 보냅니다. 인증되면 SA 두 개(각 노드에서 반대쪽 노드로 연결되는 SA 각 하나씩)를 사용하여 VPN 터널을 설정합니다.
IKE 단계 2
IKE 단계 2에서는 두 주체가 사용할 보안 유형과 터널을 통과하는 트래픽에 사용할 암호화 방법(필요시), 키를 다시 입력해야 할 때까지 소요되는 터널 수명을 협상합니다.
개별 패킷에 대한 두 가지 보안 유형은 다음과 같습니다.
• ESP(Encryption Secured Payload) - 주체 간에 협상된 프로토콜을 사용하여 각 패킷의 데이터 부분을 암호화합니다.
• AH(인증 헤더) - 각 패킷의 헤더에 인증 정보를 포함하여 정보가 인증되었고 조작되지 않았음을 확인합니다. AH의 경우 데이터 암호화를 사용하지 않습니다.
SonicOS에서는 VPN을 통과하는 트래픽에 대해 다음의 암호화 방법을 지원합니다.
• DES
• 3DES
• AES-128
• AES-192
• AES-256
IKEv1에 대한 자세한 내용은 다음 웹 사이트에서 IKE를 맨 처음 정의하는 세 가지 사양인 RFC 2407, RFC 2408, RFC 2409를 통해 확인할 수 있습니다.
• http://www.faqs.org/rfcs/rfc2407.html
• http://www.faqs.org/rfcs/rfc2408.html
• http://www.faqs.org/rfcs/rfc2409.html
IKE 버전 2는 SA를 협상 및 설정하기 위한 새로운 프로토콜입니다. IKEv2는 보안 기능이 개선되고 아키텍처가 간소화되었으며 원격 사용자 지원 기능이 향상되었습니다. 또한 IKEv2에서는 다양한 인증 방법과 원격 액세스 시나리오를 사용할 수 있도록 IP 주소 할당 및 EAP가 지원됩니다. IKEv2를 사용하는 경우 IKEv1 메인 모드에 비해 SA 설정 시 필요한 메시지 교환 수가 크게 감소합니다. 또한 IKEv2는 IKEv1 어그레시브 모드보다 훨씬 안전하고 유동적입니다. 그러므로 키를 다시 입력하는 동안 나타나는 지연 현상이 줄어듭니다. IKEv2를 사용하면 VPN이 확장되어 여러 모드나 게이트웨이 간에 포함되는 터널 수가 계속 증가함에 따라 터널당 필요한 SA 수가 줄어들기 때문에 필요한 대역폭과 관리 오버헤드도 감소합니다.
IKEv2는 IKEv1과 호환되지 않습니다. IKEv2를 사용하는 경우 터널을 설정하려면 VPN의 모든 노드가 IKEv2를 사용해야 합니다.
IKEv2의 SA(하위 SA)는 VPN 터널의 수명 기간 동안 언제든지 독립적으로 작성, 수정하고 삭제할 수 있습니다.
IKEv2의 초기화 및 인증
IKEv2에서는 메시지 쌍(두 메시지/응답 쌍)을 교환하여 VPN 터널을 초기화합니다.
• 통신 초기화: 첫 번째 메시지 쌍(IKE_SA_INIT)은 암호화 알고리즘을 협상하고, nonce(메시기자 반복 생성되지 않도록 하기 위해 생성 후 전송되는 임의의 값)를 교환하며, 공개 키를 교환합니다.
– 출발지에서 지원되는 암호화 알고리즘, 공개 키 및 nonce 목록을 보냅니다.
– 목적지에서 선택한 암호화 알고리즘, 공개 키, nonce 및 인증 요청을 보냅니다.
• 인증: 두 번째 메시지 쌍(IKE_AUTH)은 이전 메시지를 인증하고, ID와 인증서를 교환하며, 첫 번째 CHILD_SA를 설정합니다. 이러한 메시지 중 일부는 IKE_SA_INIT 교환을 통해 설정된 키를 사용해 암호화되고 무결성이 보호되므로 ID가 도용되지 않으며 모든 메시지의 필드가 인증됩니다.
– 출발지에서 공유 암호, 인증서 등의 ID 증명과 하위 SA 설정 요청을 보냅니다.
– 목적지에서 일치하는 ID 증명을 보내고 하위 SA 협상을 완료합니다.
IKEv2에서 SA 협상
단일 요청/응답 쌍으로 구성되는 이 교환은 IKEv1에서 단계 2 교환으로 지칭되었습니다. 초기 교환이 완료되고 나면 SA의 두 주체 중 하나가 이 협상을 시작할 수 있습니다.
초기 교환 이후 모든 메시지는 IKE를 교환할 때 처음 두 메시지에서 협상된 암호화 알고리즘과 키를 사용하여 암호화 방식으로 보호됩니다.
양 끝점에서 CREATE_CHILD_SA 교환을 시작할 수 있으므로 이 섹션에 사용된 "출발지"라는 용어는 이 교환을 시작하는 끝점을 지칭합니다.
1. 출발지는 하위 SA 제안을 보내고, 데이터를 암호화하려는 경우 암호화 방법과 공개 키도 함께 보냅니다.
2. 목적지는 수락된 하위 SA 제안을 보내고, 암호화 정보가 포함된 경우 공개 키도 함께 보냅니다.
구성 페이로드
IKEv2 구성 페이로드(CP)를 사용하면 VPN 서버가 IP 주소를 원격 클라이언트에 동적으로 할당할 수 있습니다. 클라이언트와 서버는 클라이언트가 LAN에 직접 연결된 것처럼 DHCP 협상과 비슷한 정보를 교환합니다.
IKEv2가 IKE 단계 1 제안을 위한 교환 방법으로 선택되면 관리자는 IKEv2 IP 주소 풀의 IP 주소를 클라이언트에 할당하도록 선택할 수 있습니다.
IKEv2 구성 페이로드는 상대적으로 작은 규모의 배포를 위한 것입니다.
Windows 7 IKEv2 클라이언트
Dell SonicWALL 어플라이언스와 함께 사용할 때 Windows 7 IKEv2 클라이언트는 타사 인증서를 인증 방법으로 사용해야 합니다. 원격 액세스 서버에 설치된 인증서는 다음 값을 가져야 합니다.
• 일반 이름(CN): 이 필드는 원격 액세스 서버의 정규화된 DNS 이름 또는 IP 주소를 포함해야 합니다. 서버가 네트워크 주소 변환(NAT) 라우터 뒤에 있는 경우 인증서는 NAT 라우터 외부 연결의 정규화된 DNS 이름 또는 IP 주소를 포함해야 합니다(클라이언트 컴퓨터가 서버의 주소로 알고 있는 주소).
• EKU: 이 필드는 서버 인증을 포함해야 합니다. 둘 이상의 서버 인증 인증서가 있는 경우 추가로 IP 보안 KE 중간 EKU를 포함합니다. 한 인증서만 두 EKU 옵션을 포함해야 하며, 그렇지 않으면 IPsec은 사용할 인증서를 확인할 수 없으며 사용할 인증서를 선택하지 못할 수도 있습니다. 자세한 내용은 다음을 참조하십시오.
http://technet.microsoft.com/en-us/library/dd941612(WS.10).aspx
Note KEv2에 대한 자세한 내용은 다음 웹 사이트의 RFC 4306 사양에서 확인할 수 있습니다. http://www.ietf.org/rfc/rfc4306.txt