이 페이지의 내용
IPsec VPN용 IKE(Internet Key Exchange)
IPsec VPN용 IKEv2와 Junos OS에서의 구성에 대해 알아보십시오.
IKEv2(Internet Key Exchange version 2)는 IPsec 기반 터널링 프로토콜입니다. IKEv2는 피어 VPN 디바이스 간에 보안 VPN 통신 채널을 제공하고 보호된 방식으로 IPsec SA(Security Association)에 대한 협상 및 인증을 정의합니다.
기능 탐색기를 사용하여 특정 기능에 대한 플랫폼 및 릴리스 지원을 확인하십시오.
플랫폼과 관련된 참고 사항은 플랫폼별 IKEv2 응답자 전용 동작 섹션을 검토합니다.
IKE(Internet Key Exchange) 및 IPsec 패킷 처리
IKE(Internet Key Exchange)는 IPsec에 대한 터널 관리를 제공하고 최종 엔터티를 인증합니다. IKE는 네트워크 디바이스 간에 IPsec 터널을 생성하기 위해 DH(Diffie-Hellman) 키 교환을 수행합니다. IKE에서 생성된 IPsec 터널은 IP 레이어의 네트워크 디바이스 간의 사용자 트래픽을 암호화, 복호화 및 인증하는 데 사용됩니다.
IKE(Internet Key Exchange) 패킷 처리
일반 텍스트 패킷이 터널링이 필요한 주니퍼 네트웍스 디바이스에 도착하고 해당 터널에 대한 활성 2단계 SA가 존재하지 않으면 Junos OS는 IKE 협상을 시작하고 패킷을 삭제합니다. IP 패킷 헤더의 소스 및 대상 주소는 각각 로컬 및 원격 IKE 게이트웨이의 주소입니다. IP 패킷 페이로드에는 ISAKMP(IKE) 패킷을 캡슐화하는 UDP 세그먼트가 있습니다. IKE(Internet Key Exchange) 패킷의 형식은 1단계와 2단계에서 동일합니다. 그림 1을 참조하십시오.
한편, 소스 호스트는 손실된 패킷을 다시 전송했습니다. 일반적으로 두 번째 패킷이 도착할 때쯤이면 IKE 협상이 완료되고 Junos OS는 패킷과 세션의 모든 후속 패킷을 포워딩하기 전에 IPsec을 통해 보호합니다.
다음 페이로드 필드에는 다음 페이로드 유형 중 하나를 나타내는 숫자가 포함되어 있습니다.
-
0002 - SA 협상 페이로드에는 1단계 또는 2단계 SA에 대한 정의가 포함되어 있습니다.
-
0004 - 제안 페이로드는 1단계 또는 2단계 제안일 수 있습니다.
-
0008 - 변환 페이로드는 SA 페이로드에 캡슐화되는 제안 페이로드에 캡슐화됩니다.
-
0010 - 키 교환(KE) 페이로드에는 DH 공용 값과 같은 키 교환을 수행하는 데 필요한 정보가 포함되어 있습니다.
-
0020 - 식별(IDx) 페이로드.
-
1단계에서 IDii는 개시자 ID를 나타내고, IDir은 응답자 ID를 나타냅니다.
-
2단계에서 IDui는 사용자 개시자를 나타내고 IDur는 사용자 응답자를 나타냅니다.
ID는 FQDN, U-FQDN, IP 주소 및 ASN.1_DN와 같은 IKE ID 유형입니다.
-
-
0040 - 인증서(CERT) 페이로드.
-
0080 - 인증서 요청(CERT_REQ) 페이로드.
-
0100 - 해시(HASH) 페이로드는 특정 해시 함수의 다이제스트 출력을 포함합니다.
-
0200 - 서명(SIG) 페이로드에 디지털 서명이 포함되어 있습니다.
-
0400 - Nonce(Nx) 페이로드에는 교환에 필요한 일부 의사 랜덤 정보가 포함되어 있습니다.)
-
0800 - 페이로드에 알림.
-
1000 - ISAKMP 페이로드 삭제.
-
2000 - 공급업체 ID(VID) 페이로드는 1단계 협상의 모든 곳에 포함될 수 있습니다. Junos OS는 이를 사용하여 NAT-T에 대한 지원을 표시합니다.
각 ISAKMP 페이로드는 그림 2와 같이 동일한 일반 헤더로 시작합니다.
함께 연결된 여러 ISAKMP 페이로드가 있을 수 있으며, 각 후속 페이로드 유형은 다음 헤더 필드의 값으로 표시됩니다. 의 0000 값은 마지막 ISAKMP 페이로드를 나타냅니다. 예를 보려면 그림 3 을 참조하십시오.
가 있는 ISAKMP 헤더
IPsec 패킷 처리
IKE(Internet Key Exchange) 협상이 완료되고 두 IKE(Internet Key Exchange) 게이트웨이가 1단계 및 2단계 SA를 설정한 후에는 모든 후속 패킷이 터널을 사용하여 전달됩니다. 2단계 SA가 터널 모드에서 ESP(Encapsulating 보안 프로토콜)를 지정하는 경우, 패킷은 그림 4와 같이 표시됩니다. 디바이스는 시작 호스트가 보내는 원본 패킷에 두 개의 추가 헤더를 추가합니다.
그림 4에서 볼 수 있듯이, 시작 호스트가 구성하는 패킷에는 페이로드, TCP 헤더 및 내부 IP 헤더(IP1)가 포함됩니다.
의 IPsec 패킷 - ESP
Junos OS가 추가하는 라우터 IP 헤더(IP2)에는 대상 IP 주소인 원격 게이트웨이의 IP 주소와 소스 IP 주소인 로컬 라우터의 IP 주소가 포함되어 있습니다. 또한 Junos OS는 외부 및 내부 IP 헤더 사이에 ESP 헤더를 추가합니다. ESP 헤더에는 원격 피어가 패킷을 수신할 때 패킷을 올바르게 처리할 수 있도록 하는 정보가 포함되어 있습니다. 그림 5를 참조하십시오.
다음 헤더 필드는 페이로드 필드의 데이터 유형을 나타냅니다. 터널 모드에서 이 값은 4로 IP 패킷이 페이로드 내에 포함되어 있음을 나타냅니다. 그림 6을 참조하십시오.
Junos OS의 IKE(Internet Key Exchange) 소개
IKE(Internet Key Exchange)는 인터넷과 같은 보안되지 않은 매체를 통해 암호화 및 인증을 위한 키를 안전하게 교환할 수 있는 방법을 제공합니다. IKE(Internet Key Exchange)를 사용하면 한 쌍의 보안 게이트웨이가 다음을 수행할 수 있습니다. 보안 게이트웨이가 터널 및 키 정보를 교환할 수 있는 보안 터널을 동적으로 설정합니다. 터널 속성 협상 및 키 관리를 포함하여 사용자 수준 터널 또는 터널 SA를 설정합니다. 이러한 터널은 동일한 보안 채널 위에서 새로 고쳐지고 종료될 수도 있습니다. IKE(Internet Key Exchange)는 Diffie-Hellman 메서드를 사용하며 IPsec에서 선택 사항입니다(공유 키는 엔드포인트에서 수동으로 입력할 수 있음).
IKEv2는 다음을 지원합니다.
-
경로 기반 VPN.
-
사이트 간 VPN.
-
데드 피어 감지.
-
섀시 클러스터.
-
사전 공유 키 인증.
-
인증서 기반 인증.
-
하위 SA. IKEv2 하위 SA는 IKEv1에서 2단계 SA로 알려져 있습니다. IKEv2에서 하위 SA는 기본 IKE SA 없이는 존재할 수 없습니다.
-
AutoVPN.
-
동적 엔드포인트 VPN.
-
EAP는 IKEv2를 사용하는 원격 액세스에 대해 지원됩니다.
-
트래픽 선택기.
IKEv2는 다음 기능을 지원하지 않습니다.
-
정책 기반 VPN.
-
VPN 모니터링.
-
IPComp(IP 페이로드 압축 프로토콜).
Junos OS에서 IKEv2 구성
VPN 피어가 IKEv1 또는 IKEv2로 구성되어 있습니다. 피어가 IKEv2로 구성된 경우 원격 피어가 IKEv1 협상을 시작하면 피어가 IKEv1로 다시 이동할 수 없습니다. 기본적으로 주니퍼 네트웍스 보안 디바이스는 IKEv1 피어입니다.
[edit security ike gateway gw-name ] 계층 수준의 구성 문을 사용하여 version v2-only IKEv2를 구성합니다.
IKE 버전은 및 CLI 운영 명령의 출력에 표시됩니다 show security ike security-associations show security ipsec security-associations .
주니퍼 네트웍스 디바이스는 2단계 협상에 대해 최대 4개의 제안을 지원하므로, 허용할 터널 매개 변수 범위를 얼마나 제한할지 정의할 수 있습니다. Junos OS는 사전 정의된 표준의 호환 가능한 기본 2단계 제안 세트를 제공합니다. 또한 사용자 정의 2단계 제안을 정의할 수 있습니다.
IKEv2 구성 페이로드 이해
구성 페이로드는 응답기에서 이니시에이터로 프로비저닝 정보를 전파하기 위해 제공되는 IKEv2(Internet Key Exchange version 2) 옵션입니다. IKEv2 구성 페이로드는 경로 기반 VPN에서만 지원됩니다.
RFC 5996, IKEv2(Internet Key Exchange Protocol Version 2)는 응답자가 이니시에이터에 반환할 수 있는 15가지 구성 속성을 정의합니다. 표 1 은 방화벽에서 지원되는 IKEv2 구성 속성을 설명합니다.
|
속성 유형 |
값 |
설명 |
길이 |
|---|---|---|---|
|
INTERNAL_IP4_ADDRESS |
1 |
내부 네트워크의 주소를 지정합니다. 여러 내부 주소를 요청할 수 있습니다. 응답자는 요청한 주소 수까지 보낼 수 있습니다. |
0 또는 4 옥텟 |
|
INTERNAL_IP4_NETMASK |
2 |
내부 네트워크의 넷마스크 값을 지정합니다. 요청 및 응답 메시지에는 하나의 넷마스크 값(예: 255.255.255.0)만 허용되며 INTERNAL_IP4_ADDRESS 속성에만 사용해야 합니다. |
0 또는 4 옥텟 |
|
INTERNAL_IP4_DNS |
3 |
네트워크 내의 DNS 서버 주소를 지정합니다. 여러 DNS 서버를 요청할 수 있습니다. 응답자는 0개 이상의 DNS 서버 속성으로 응답할 수 있습니다. |
0 또는 4 옥텟 |
|
INTERNAL_IP4_NBNS |
4 |
네트워크 내에서 NBNS(NetBIOS 이름 서버)의 주소를 지정합니다(예: WINS 서버). 여러 NBNS 서버를 요청할 수 있습니다. 응답자는 0개 이상의 NBNS 서버 속성으로 응답할 수 있습니다. |
0 또는 4 옥텟 |
|
INTERNAL_IP6_ADDRESS |
8 |
내부 네트워크의 주소를 지정합니다. 여러 내부 주소를 요청할 수 있습니다. 응답자는 요청한 주소 수까지 보낼 수 있습니다. |
0 또는 17 옥텟 |
|
INTERNAL_IP6_DNS |
10 |
네트워크 내의 DNS 서버 주소를 지정합니다. 여러 DNS 서버를 요청할 수 있습니다. 응답자는 0개 이상의 DNS 서버 속성으로 응답할 수 있습니다. |
0 또는 16 옥텟 |
IKE(Internet Key Exchange) 응답자가 개시자에게 프로비저닝 정보를 제공하려면 RADIUS 서버와 같은 지정된 소스에서 정보를 획득해야 합니다. 프로비저닝 정보는 RADIUS 서버를 통해 DHCP 서버에서 반환할 수도 있습니다. RADIUS 서버에서 사용자 정보에 인증 비밀번호를 포함해서는 안 됩니다. RADIUS 서버 프로필은 [edit security ike gateway gateway-name ] 계층 수준의 구성을 사용하여 aaa access-profile profile-name IKE 게이트웨이에 바인딩됩니다.
Junos OS는 IKEv2 구성 페이로드를 개선하여 다음 기능을 지원합니다.
-
IPv4 및 IPv6 로컬 주소 풀을 지원합니다. 고정 IP 주소를 피어에 할당할 수도 있습니다.
IKE(Internet Key Exchange)를 설정하는 동안 개시자는 응답자로부터 IPv4 주소, IPv6 주소, DNS 주소 또는 WINS 주소를 요청합니다. 응답자는 개시자를 성공적으로 인증한 후 로컬 주소 풀 또는 RADIUS 서버를 통해 IP 주소를 할당합니다. 구성에 따라 이 IP 주소는 피어가 연결할 때마다 동적으로 할당되거나 고정 IP 주소로 할당됩니다. RADIUS 서버가 프레임 풀로 응답하는 경우 Junos OS는 해당 로컬 풀의 구성에 따라 IP 주소 또는 정보를 할당합니다. 로컬 주소 풀과 RADIUS 서버를 모두 구성하는 경우, RADIUS 서버에서 할당한 IP 주소가 로컬 풀보다 우선합니다. 로컬 IP 주소 풀을 구성하고 RADIUS 서버가 IP 주소를 반환하지 않은 경우 로컬 풀은 요청에 IP 주소를 할당합니다.
-
에 도입된
authentication-order추가 옵션none. 인증 순서(액세스 프로필)를 참조하십시오. -
RADIUS 계정 시작 및 중지 메시지는 터널 또는 RADIUS 서버에 대한 피어의 상태를 알려줍니다. 이러한 메시지는 DHCP 서버와 같은 하위 시스템에 대한 추적 또는 알림 목적으로 사용될 수 있습니다.
RADIUS 서버가 어카운팅 시작 또는 중지 메시지를 지원하는지 확인합니다. 또한 방화벽과 RADIUS 서버 모두에 이러한 메시지를 추적할 수 있는 적절한 설정이 있는지 확인하십시오.
-
IPv6 지원이 도입되면서 구성 페이로드를 사용하는 이중 스택 터널이 가능해졌습니다. 로그인 프로세스 중에 IKE(Internet Key Exchange)는 IPv4 및 IPv6 주소 모두에 대해 요청합니다. AAA는 요청된 모든 주소가 성공적으로 할당된 경우에만 로그인을 허용합니다. IKE(Internet Key Exchange)는 요청된 IP가 할당되지 않으면 협상을 종료합니다.
경로 기반 VPN에서 보안 터널(st0) 인터페이스는 포인트-투-멀티포인트 또는 포인트-투-포인트 모드에서 작동합니다. IKEv2 구성 페이로드를 통한 주소 할당은 이제 포인트 투 멀티포인트 또는 포인트 투 포인트 모드에서 지원됩니다. 포인트 투 멀티포인트 인터페이스의 경우, 인터페이스에 번호가 매겨져야 하며 구성 페이로드 INTERNAL_IP4_ADDRESS 속성 유형의 주소는 연결된 포인트 투 멀티포인트 인터페이스의 서브네트워크 범위 내에 있어야 합니다.
IKE(Internet Key Exchange) 게이트웨이 구성에 대한 IKEv2 구성 페이로드 요청에 대한 공통 비밀번호를 구성할 수 있습니다. 1자에서 128자 사이의 공통 패스워드를 사용하면 관리자가 공통 패스워드를 정의할 수 있습니다. 이 암호는 방화벽이 IKEv2 구성 페이로드를 사용하여 원격 IPsec 피어를 대신하여 IP 주소를 요청할 때 방화벽과 RADIUS 서버 간에 사용됩니다. RADIUS 서버는 구성 페이로드 요청을 위해 방화벽에 IP 정보를 제공하기 전에 자격 증명을 일치시킵니다. [edit security ike gateway gateway-name aaa access-profile access-profile-name] 계층 수준에서 구성 문을 사용하여 config-payload-password configured-password 공통 암호를 구성할 수 있습니다.
방화벽과 RADIUS 서버 모두 동일한 비밀번호를 구성해야 하며 RADIUS 서버는 PAP(Password Authentication Protocol)를 인증 프로토콜로 사용하도록 인증해야 합니다. 이것이 없으면 터널 설정이 성공할 수 없습니다.
그림 7 은 IKEv2 구성 페이로드의 일반적인 워크플로우를 보여줍니다.
IKEv2 구성 페이로드 기능은 point-to-multipoint 보안 터널(st0) 인터페이스와 point-to-point 인터페이스 모두에서 지원됩니다. 포인트-투-멀티포인트 인터페이스에는 번호가 지정되어야 하며, 구성 페이로드에 제공된 주소는 연결된 포인트-투-멀티포인트 인터페이스의 서브네트워크 범위 내에 있어야 합니다.
Pico 셀 프로비저닝 이해
IKEv2 구성 페이로드를 사용하여 방화벽과 같은 IKE 응답자에서 셀룰러 네트워크의 LTE 피코 셀 기지국과 같은 여러 개시자로 프로비저닝 정보를 전파할 수 있습니다. 피코 셀은 방화벽에 연결할 수 있는 표준 구성으로 공장에서 출하되지만, 피코 셀 프로비저닝 정보는 보호된 네트워크 내에 있는 하나 이상의 프로비저닝 서버에 저장됩니다. 피코 셀은 프로비저닝 서버와 보안 연결을 구축한 후 전체 프로비저닝 정보를 수신합니다.
피코 셀을 부트스트랩 및 프로비저닝하고 서비스에 도입하는 데 필요한 워크플로우는 다음과 같은 네 가지 단계를 포함합니다.
-
초기 주소 획득 - 피코 셀은 다음 정보와 함께 공장에서 배송됩니다.
-
방화벽에 대한 보안 게이트웨이 터널에 대한 구성
-
제조업체에서 발행한 디지털 인증서
-
보호된 네트워크 내에 있는 프로비저닝 서버의 FQDN(정규화된 도메인 이름)
피코 셀이 부팅되고 DHCP 서버에서 IKE 협상에 사용할 주소를 획득합니다. 그런 다음 이 주소를 사용하여 방화벽의 보안 게이트웨이에 터널이 구축됩니다. OAM(Operation, Administration, and Management) 트래픽 주소도 DHCP 서버에서 보호된 네트워크에서 사용하기 위해 할당됩니다.
-
-
피코 셀 프로비저닝 - 할당된 OAM 트래픽 주소를 사용하여 피코 셀은 보호된 네트워크 내의 서버에 프로비저닝 정보(일반적으로 운영자 인증서, 라이선스, 소프트웨어 및 구성 정보)를 요청합니다.
-
재부팅 - 피코 셀이 재부팅되고 획득한 프로비저닝 정보를 사용하여 서비스 프로바이더의 네트워크 및 운영 모델에 맞게 만듭니다.
-
서비스 프로비저닝 - 피코 셀이 서비스를 시작할 때 FQDN과 함께 고유 이름(DN) 및 주체 대체 이름 값이 포함된 단일 인증서를 사용하여 방화벽의 보안 게이트웨이에 대한 두 개의 터널(하나는 OAM 트래픽용, 다른 하나는 3GPP(Third-Generation Partnership Project) 데이터 트래픽용)을 구축합니다.
또한보십시오
IKE(Internet Key Exchange) 제안
IKE(Internet Key Exchange) 구성은 피어 보안 게이트웨이와의 보안 IKE 연결을 설정하는 데 사용되는 알고리즘과 키를 정의합니다. 하나 이상의 IKE(Internet Key Exchange) 제안을 구성할 수 있습니다. 각 제안은 IKE 호스트와 피어 간의 IKE 연결을 보호하기 위한 IKE 속성 목록입니다.
IKE(Internet Key Exchange) 제안을 구성하려면 문을 포함 proposal 하고 [edit security ike ] 계층 수준에서 이름을 지정합니다.
IKE(Internet Key Exchange) 정책
IKE(Internet Key Exchange) 정책은 IKE 협상 중에 사용할 보안 매개 변수(IKE 제안)의 조합을 정의합니다. 피어 주소와 해당 연결에 필요한 제안을 정의합니다. 사용되는 인증 방법에 따라 지정된 피어 또는 로컬 인증서에 대한 사전 공유 키(PSK)를 정의합니다. IKE(Internet Key Exchange) 협상 중에 IKE(Internet Key Exchange)는 두 피어에서 동일한 IKE 정책을 찾습니다. 협상을 시작하는 피어는 모든 정책을 원격 피어에 전송하고 원격 피어는 일치하는 정책을 찾으려고 시도합니다. 두 피어의 두 정책 모두에 동일한 구성 속성을 포함하는 제안이 있을 때 일치가 이루어집니다. 수명이 동일하지 않은 경우, 두 정책(호스트와 피어로부터) 사이의 더 짧은 수명이 사용됩니다. 구성된 PSK는 피어와도 일치해야 합니다.
먼저 하나 이상의 IKE 제안을 구성합니다. 그런 다음 이러한 제안을 IKE(Internet Key Exchange) 정책과 연결합니다.
IKE(Internet Key Exchange) 정책을 구성하려면 문을 포함 policy 하고 [edit security ike] 계층 수준에서 정책 이름을 지정합니다.
키 재생성 및 재인증
개요
IKEv2에서는 키 재생성과 재인증이 별개의 프로세스입니다. 키 재생성은 IKE SA(보안 연결)에 대한 새 키를 설정하고 메시지 ID 카운터를 재설정하지만 피어를 재인증하지는 않습니다. 재인증은 VPN 피어가 인증 자격 증명에 대한 액세스 권한을 유지하는지 확인합니다. 재인증은 IKE SA 및 하위 SA에 대한 새 키를 설정합니다. 보류 중인 IKE SA 또는 하위 SA의 키 재생성은 더 이상 필요하지 않습니다. 새 IKE 및 하위 SA가 생성되면 이전 IKE 및 하위 SA가 삭제됩니다.
IKEv2 재인증은 기본적으로 비활성화되어 있습니다. 재인증 빈도 값을 1에서 100 사이로 구성하여 재인증을 사용하도록 설정합니다. 재인증 빈도는 재인증이 발생하기 전에 발생하는 IKE 키 재생성 횟수입니다. 예를 들어, 구성된 재인증 빈도가 1인 경우 IKE 키 재생성이 있을 때마다 재인증이 발생합니다. 구성된 재인증 빈도가 2이면 다른 모든 IKE 키 재생성에서 재인증이 발생합니다. 구성된 재인증 빈도가 3이면 세 번째 IKE 키 재생성 시마다 재인증이 발생합니다.
[edit security ike policy policy-name] 계층 수준에서 문을 사용하여 reauth-frequency 재인증 빈도를 구성합니다. 재인증 빈도를 0(기본값)으로 설정하면 재인증이 비활성화됩니다. 재인증 빈도는 피어에 의해 협상되지 않으며 각 피어는 고유한 재인증 빈도 값을 가질 수 있습니다.
지원되는 기능
IKEv2 재인증은 다음과 같은 기능으로 지원됩니다.
-
IKEv2 개시자 또는 응답자
-
DPD(Dead Peer Detection)
-
가상 라우터의 가상 라우터 및 보안 터널(st0) 인터페이스
-
네트워크 주소 변환 통과(NAT-T)
-
액티브-액티브 및 액티브-패시브 모드의 섀시 클러스터
-
ISSU(In-Service Software Upgrade)
-
ISHU(In-Service Hardware Upgrade) 절차를 사용한 새로운 SPU(Services Processing Unit)의 업그레이드 또는 삽입
제한 사항
IKEv2 재인증을 사용할 때 다음과 같은 주의 사항을 참고하십시오.
-
NAT-T를 사용하면 이전 IKE SA와 다른 포트로 새 IKE SA를 생성할 수 있습니다. 이 시나리오에서는 이전 IKE(Internet Key Exchange) SA가 삭제되지 않을 수 있습니다.
-
NAT-T 시나리오에서는 네트워크 주소 변환(NAT) 디바이스 뒤에 있는 개시자가 재인증 후 응답자가 될 수 있습니다. 네트워크 주소 변환(NAT) 세션이 만료되면 네트워크 주소 변환(NAT) 디바이스는 다른 포트에 도착할 수 있는 새 IKE 패킷을 폐기할 수 있습니다. NAT 세션을 활성 상태로 유지하려면 NAT-T keepalive 또는 DPD를 활성화해야 합니다. AutoVPN의 경우, 스포크에 구성된 재인증 빈도는 허브에 구성된 재인증 빈도보다 작게 하는 것이 좋습니다.
-
재인증 빈도에 따라, 원래 IKE(Internet Key Exchange) SA의 개시자 또는 응답자에 의해 새로운 IKE(Internet Key Exchange) SA가 시작될 수 있습니다. EAP(Extensible Authentication Protocol) 인증 및 구성 페이로드를 사용하려면 원래 IKE SA와 동일한 당사자가 IKE SA를 시작해야 하므로 EAP 인증 또는 구성 페이로드로 재인증이 지원되지 않습니다.
IKE(Internet Key Exchange) 인증(인증서 기반 인증)
인증서 인증을 위한 다단계 계층
인증서 기반 인증은 IKE 협상 중 방화벽에서 지원되는 인증 방법입니다. 대규모 네트워크에서 여러 CA(인증 기관)가 해당 종단 디바이스에 EE(End Entity) 인증서를 발급할 수 있습니다. 개별 위치, 부서 또는 조직에 대해 별도의 CA를 갖는 것이 일반적입니다.
인증서 기반 인증에 단일 수준 계층을 사용하는 경우 네트워크의 모든 EE 인증서는 동일한 CA에 의해 서명되어야 합니다. 모든 방화벽 디바이스에는 피어 인증서 유효성 검사를 위해 등록된 동일한 CA 인증서가 있어야 합니다. IKE(Internet Key Exchange) 협상 중에 전송된 인증서 페이로드에는 EE 인증서만 포함됩니다.
또는 IKE 협상 중에 전송된 인증서 페이로드에는 EE 및 CA 인증서 체인이 포함될 수 있습니다. 인증서 체인 은 피어의 EE 인증서를 검증하는 데 필요한 인증서 목록입니다. 인증서 체인에는 EE 인증서와 로컬 피어에 없는 모든 CA 인증서가 포함됩니다.
네트워크 관리자는 IKE 협상에 참여하는 모든 피어가 해당 인증서 체인에 하나 이상의 공통된 신뢰할 수 있는 CA를 보유하도록 해야 합니다. 신뢰할 수 있는 공통 CA는 루트 CA일 필요가 없습니다. EE에 대한 인증서와 체인의 최상위 CA를 포함하여 체인의 인증서 수는 10개를 초과할 수 없습니다.
구성된 IKE(Internet Key Exchange) 피어의 유효성 검사는 지정된 CA 서버 또는 CA 서버 그룹으로 수행할 수 있습니다. 인증서 체인을 사용하면 루트 CA가 IKE(Internet Key Exchange) 정책에 구성된 신뢰할 수 있는 CA 그룹 또는 CA 서버와 일치해야 합니다.
그림 8에 표시된 CA 계층 예에서 루트-CA는 네트워크의 모든 디바이스에 대해 공통적으로 신뢰할 수 있는 CA입니다. Root-CA는 각각 Eng-CA 및 Sales-CA로 식별되는 엔지니어링 및 영업 CA에 CA 인증서를 발급합니다. Eng-CA는 개발 및 품질 보증 CA에 CA 인증서를 발급하며, 각각 Dev-CA 및 Qa-CA로 식별됩니다. Host-A는 Dev-CA로부터 EE 인증서를 받고 Host-B는 Sales-CA로부터 EE 인증서를 받습니다.
각 종단 디바이스는 해당 계층에 CA 인증서와 함께 로드되어야 합니다. Host-A에는 Root-CA, Eng-CA 및 Dev-CA 인증서가 있어야 합니다. Sales-CA 및 Qa-CA 인증서는 필요하지 않습니다. Host-B에는 Root-CA 및 Sales-CA 인증서가 있어야 합니다. 인증서는 디바이스에 수동으로 로드하거나 SCEP(Simple Certificate Enrollment Process)를 사용하여 등록할 수 있습니다.
각 종단 디바이스는 인증서 체인의 각 CA에 대한 CA 프로필로 구성되어야 합니다. 다음 출력은 Host-A에서 구성된 CA 프로필을 보여줍니다.
admin@host-A# show security
pki {
ca-profile Root-CA {
ca-identity Root-CA;
enrollment {
url “www.example.net/scep/Root/”;
}
}
ca-profile Eng-CA {
ca-identity Eng-CA;
enrollment {
url “www.example.net/scep/Eng/”;
}
}
ca-profile Dev-CA {
ca-identity Dev-CA;
enrollment {
url “www.example.net/scep/Dev/”;
}
}
}
다음 출력은 Host-B에 구성된 CA 프로필을 보여줍니다.
admin@host-B# show security
pki {
ca-profile Root-CA {
ca-identity Root-CA;
enrollment {
url “www.example.net/scep/Root/”;
}
}
ca-profile Sales-CA {
ca-identity Sales-CA;
enrollment {
url “www.example.net/scep/Sales/”;
}
}
}
또한보십시오
IKEv2의 서명 인증
IKEv2의 서명 인증 방법과 Junos OS에서의 작동 방식에 대해 알아보려면 이 주제를 읽어보십시오.
IKEv2(Internet Key Exchange version 2) 프로토콜은 공개 키 암호화를 사용하는 서명 기반 인증을 지원합니다. IKEv2에서 서명 기반 인증은 서명 알고리즘당 하나의 인증 방법을 지원합니다. 예를 들어, IKE 피어는 RSA, DSA(Digital Signature Algorithm) 및 ECDSA(Elliptic Curve DSA)와 같은 각 디지털 서명에 대해 별도의 인증 방법을 사용합니다. 각 해시 알고리즘은 인증을 위해 하나의 서명에 연결됩니다. IKEv2 제안 구성에서 인증 방법을 지정하면 디바이스는 해당 방법을 사용하여 IKEv2 메시지의 소스를 인증합니다. IKE(Internet Key Exchange) 피어는 어떤 해시 알고리즘이 서명과 연관되어 있는지 알기 어렵습니다. 이 프로세스는 새로운 알고리즘이 도입될 때마다 더욱 번거로워집니다. IKEv2에 대한 자세한 내용은 Internet Key Exchange 를 참조하십시오.
RFC 7427을 기반으로 하는 디지털 서명 인증 방법으로 이러한 문제를 해결할 수 있습니다. 이 방법은 IKE(Internet Key Exchange) 피어가 지원되는 서명 알고리즘을 사용하고 서명 해시 알고리즘을 협상할 수 있으므로 서명 기반 인증 방법에 비해 더 일반적입니다. IKEv2의 서명 인증에 대해 자세히 읽어보십시오.
IKEv2에서 서명 인증 구현
Junos OS는 알고리즘별로 서명 기반 인증 지원할 뿐만 아니라 RFC 7427에 설명된 디지털 서명 인증 방법도 지원합니다. 이 메서드에서 IKEv2 인증 페이로드는 공개 키 유형뿐만 아니라 디바이스가 서명을 생성하는 데 사용하는 해시 알고리즘도 나타냅니다. 디바이스는 SIGNATURE_HASH_ALGORITHM 알림을 사용하여 피어에 RFC 7427 지원에 대해 알리고 지원되는 해시 알고리즘 목록을 제공합니다.
이 기능을 사용하려면 디바이스에서 디지털 서명 인증 방법을 구성해야 합니다. 디지털 서명 인증 방법에 대한 자세한 내용은 제안(보안 IKE)을 참조하십시오 . 구성 옵션을 signature-hash-algorithm 사용하여 수신된 각 서명 해시 알고리즘과 계층 순서대로 일치해야 하는 특정 서명 해시 알고리즘을 정의할 수 있습니다. 서명 해시 알고리즘을 지정하지 않으면 디바이스는 지원되는 모든 해시 알고리즘의 기본 목록에서 수신된 서명 해시 알고리즘과 일치합니다. 서명 해시 알고리즘(보안 IKE)을 참조하십시오 .
Junos OS에서 인증 방법은 IKEv2 메시지 플로우에 정의된 다음 단계를 포함합니다. 자세한 내용은 RFC 7296, IKEv2(Internet Key Exchange Protocol Version 2) 를 참조하십시오.
-
두 IKE(Internet Key Exchange) 피어 모두 처음에 지원되는 해시 알고리즘 목록을 서로에게 알려줍니다. 디바이스가 IKE_SA_INIT 메시지의 SIGNATURE_HASH_ALGORITHM 페이로드를 피어 디바이스로 전송하고 응답을 수신합니다. 그런 다음 피어는 서명 해시 알고리즘을 협상합니다.
-
IKE_AUTH 메시지에서 피어는 디지털 서명 인증 방법을 교환합니다.
디바이스는 다음 시나리오 중 하나에서 기본 인증서 인증 방법을 사용합니다.
-
응답자는 RFC 7427을 지원하지 않습니다.
-
개시자는 수신된 해시 알고리즘을 지원하지 않습니다.
이점
-
유연성 - 기존 및 새로운 디지털 서명을 포함합니다.
-
사용 편의성 - 기존 PKI(Public Key Infrastructure)에 통합됩니다.
-
강력한 솔루션 - 서명 기반 인증 방법에 비해 더 나은 ID 검증을 수행하여 IKE 피어의 전반적인 보안 및 신뢰성을 개선합니다.
또한보십시오
디도스(DDoS) 공격으로부터 IKE(Internet Key Exchange) 보호
서비스 거부(DoS)는 안전하지 않은 IPsec VPN 네트워크에서 가장 흔하면서도 심각한 공격 중 하나입니다. DoS 공격은 네트워크 인프라에 많은 기반을 두지 않아도 되므로 네트워크를 빠르고 쉽게 장악할 수 있는 방법을 제공합니다. 사이버 공격자는 네트워크를 장악하기 위해 이 방법을 선택합니다.
DoS 공격에서는 어떤 일이 발생합니까?
공격자는 너무 많은 트래픽으로 네트워크를 플러딩하고 점진적으로 충돌시키려고 시도하여 네트워크 리소스를 고갈시키고 메모리 및 CPU와 같은 디바이스 리소스를 추가로 제어합니다. 공격자가 여러 개의 오케스트레이션된 시스템을 사용하여 제어를 시도하고 단일 대상을 동시에 공격하는 경우를 디도스(DDoS) 공격이라고 합니다.
IKE(Internet Key Exchange) 구현의 디도스(DDoS) 취약점
원격 피어(개시자)가 SA_INIT 메시지를 보내면 로컬 피어(응답자)가 회신하고 메시지 구조에 대한 메모리를 할당합니다. IKE_AUTH 메시지의 도움으로 인증이 발생할 때까지 세션을 반개방형 IKE 세션 이라고 합니다. 피어가 IKE 보안 연결(SA)을 설정하면 세션은 완전히 열린 IKE 세션이 됩니다.
IKEv2 디도스(DDoS) 취약성을 이해하기 위해 공격자가 IKE SA에 대한 쉬운 공격 벡터를 만들 수 있는 몇 가지 방법을 살펴보겠습니다.
-
공격자가 반쯤 열린 IKE(Internet Key Exchange) 보안 연결 구조를 생성할 수 있는 IKE_AUTH 메시지 없이 많은 수의 SA_INIT 메시지를 보냅니다. 이 공격으로 인해 디바이스가 리소스를 사용하고 메모리가 부족해집니다.
-
개시자 및 응답자에서 각각 올바른 SPI_i와 SPI_r을 사용하여 다수의 정크 IKE_AUTH 패킷을 보냅니다. 패킷을 복호화하는 동안 디바이스의 메모리가 부족합니다.
-
SA_INIT 패킷을 지속적으로 전송합니다. 암호화된 패킷에 대한 키를 생성하는 동안 디바이스의 메모리가 부족합니다.
-
전체 개방형 IKE(Internet Key Exchange) 세션 동안 초당 많은 수의 키 재입력 요청을 보냅니다.
-
고유한 메시지 ID(ID)를 사용하여 많은 수의 메시지를 보냅니다. 디바이스는 들어오는 모든 IKE 메시지를 대기열에 넣고 메모리가 부족합니다.
IKE(Internet Key Exchange) 구현을 보호하는 방법
주니퍼는 IKEv1 및 IKEv2 프로토콜 모두에 대해 디도스(DDoS) 공격을 완화하고 모니터링할 수 있는 강력한 인프라를 제공합니다. 방화벽이 IPsec VPN 서비스에 대한 iked 프로세스( junos-ike 패키지)를 실행할 때 IKE 구현에 대한 공격으로부터 보호할 수 있습니다.
IKEv2에 대한 디도스(DDoS) 공격에 대한 자세한 내용은 RFC 8019, 분산 서비스 거부 공격으로부터 IKEv2(Internet Key Exchange Protocol Version 2) 구현 보호를 참조하십시오. 방화벽이 iked 프로세스를 사용하여 IPsec VPN 서비스를 실행할 때 IKEv1에 대해 유사한 보호를 제공합니다. RFC에서 제공하는 클라이언트 퍼즐 메커니즘은 지원하지 않습니다.
디도스(DDoS) 공격으로부터 보호
IKE(Internet Key Exchange) 보안 연결 생성 프로세스 중에 디도스(DDoS) 공격에 대해 여러 방어 메커니즘을 사용할 수 있습니다. 이러한 메커니즘에는 반개방형 IKE(Internet Key Exchange) SA에 대한 속도 제한 및 보존 기간 구성과 키 재입력 요청에 대한 수신 환율의 추가적인 관리가 포함됩니다. IKE(Internet Key Exchange) SA에 대한 디도스(DDoS) 공격으로부터 보호하기 위해 다음과 같은 조치를 제공합니다.
- 반개방형 IKE(Internet Key Exchange) SA에 대한 보호 조치:
-
응답자는 특정 기간 동안 반개방형 IKE(Internet Key Exchange) SA의 구성을 허용하지 않습니다. 응답자가 시간 초과 기간에 도달할 때까지 SA를 구성하지 않도록 이 제한을 설정할 수 있습니다. 자세한 내용은 옵션
timeout에 대한 세션(보안 IKE)을 참조하십시오. -
응답자에서 허용되는 최대 절반 개방형 IKE(Internet Key Exchange) SA에 대한 제한을 설정할 수 있습니다. 하프 오픈 IKE(Internet Key Exchange) SA의 총 수가 최대 수에 도달하면 응답자는 IKEv1 및 IKEv2 SA 모두에 대한 새 연결을 거부합니다. 자세한 내용은 세션(보안 IKE)의 옵션을 참조하십시오
max-count. -
응답자는 반개방형 IKE(Internet Key Exchange) SA에 대한 세션 수에 임계값을 적용합니다. 하프 오픈 IKE(Internet Key Exchange) SA의 총 수가 임계값에 도달하면
-
IKEv2 SA의 경우 응답자는 모든 새 연결에 대해 쿠키 메커니즘을 호출합니다.
-
IKEv1 SA의 경우 응답자는 새 연결을 거부합니다.
자세한 내용은 세션(보안 IKE)의 및
send-cookiereduce-timeout옵션을 참조하십시오thresholds. -
-
응답자는 중복 세션을 삭제할 수 있습니다. 자세한 내용은 세션(보안 IKE)의 옵션을 참조하십시오
discard-duplicate. -
인증 실패 및 시작 실패 단계에 대한 백오프 타임아웃을 설정할 수 있습니다. 자세한 내용은 옵션에 대한 세션
init-phase-failure(보안 IKE)을 참조하십시오 .backoff-timeoutsauth-phase-failure
-
-
완전 개방형 IKE(Internet Key Exchange) SA의 경우:
-
최대 수신 키 재입력 요청 속도를 구성하여 확장된 시나리오에서 요청을 제한할 수 있습니다. 자세한 내용은 세션(보안 IKE)의 옵션을 참조하십시오
incoming-exchange-max-rates.
-
-
응답자는 피어 IKE(Internet Key Exchange) ID를 기반으로 피어로부터 들어오는 IKE 세션을 차단할 수 있습니다. 자세한 내용은 차단 목록(보안 IKE)을 참조하십시오 .
-
동적 게이트웨이의 경우 옵션을 사용하여
connections-limitIKE(Internet Key Exchange) 게이트웨이 구성 수준에서 연결 수에 대한 제한을 설정할 수 있습니다. 자세한 내용은 게이트웨이(보안 IKE)를 참조하십시오 .
이러한 옵션을 구성하는 방법에 대한 자세한 내용은 IKE(Internet Key Exchange) 디도스(DDoS) 공격에 대한 보호 구성을 참조하십시오.
당사는 다음을 지원하지 않습니다.
-
kmd 프로세스 기반 IPsec VPN 서비스를 통한 디도스(DDoS) 방어.
-
이러한 인코딩 유형을 지원하지 않으므로 해시 및 URL 인증서 인코딩 공격으로부터 보호합니다.
디도스(DDoS) 공격을 모니터링하는 방법
디도스(DDoS) 공격을 모니터링하기 위해 다음과 같은 메커니즘을 제공합니다.
-
이 명령을 사용하여
show security ike security-associations모든 성숙 및 미성숙 IKE 보안 연결을 나열합니다. 자세한 내용은 show security ike security-associations를 참조하십시오. -
이 명령을 사용하여
show security ike statsIPsec VPN 터널의 글로벌 IKE 통계(예: 진행 중, 설정됨, 만료된 통계)를 표시합니다. 자세한 내용은 show security ike stats를 참조하십시오. -
이 명령을 사용하여
show security ike active-peer원격 피어와의 성공적인 IKE 협상에 대한 세부 정보를 표시합니다. 자세한 내용은 show security ike active-peer를 참조하십시오. -
이 명령을 사용하여
show security ike peers in-progress반쯤 열린 IKE(Internet Key Exchange) SA를 포함하여 진행 중인 IKE(Internet Key Exchange) SA의 세부 정보를 표시합니다. 자세한 내용은 show security ike peers를 참조하십시오. 이 명령을 사용하여 차단된 피어, 실패한 피어, 백오프 피어의 세부 정보도 볼 수 있습니다. -
이 명령을 사용하여
clear security ike peers백오프, 차단, 실패 또는 진행 중인 IKE 피어를 지웁니다. 자세한 내용은 보안 IKE(Internet Key Exchange) 피어 삭제를 참조하십시오. -
추가 통신에서 차단해야 하는 피어와의 기존 IKE 보안 연결을 삭제하려면 이
clear security ike security-associations명령을 사용합니다. 자세한 내용은 clear security ike security-associations를 참조하십시오. -
iked 시스템 로그(syslog) 메시지 IKE_GATEWAY_PEER_BLOCKED, IKE_GATEWAY_PEER_BACKOFF 및 IKE_GATEWAY_PEER_FAILED 는 각각 원격 피어와의 차단, 백오프 및 실패한 IKE 협상에 대한 세부 정보를 제공합니다.
-
보안을 강화하기 위해 Junos OS는 필터링, 세션 수, 속도 제한과 같은 패킷 기반 시스템 공격으로부터 사용자를 보호하는 서비스를 제공합니다. 자세한 내용은 [
edit security screen ids-option screen-name] 계층 수준에서 show firewall 명령 및 ids-option 문을 참조하십시오.
IKE(Internet Key Exchange) 디도스(DDoS) 공격에 대한 보호 구성
IKE 프로토콜에서 디도스(DDoS) 공격에 대한 보호를 구성하는 방법을 이해하려면 이 섹션을 참조하십시오.
선제조건
IKE(Internet Key Exchange) 디도스(DDoS) 공격에 대한 보호를 구성하기 전에 다음 전제 조건을 충족하는지 확인하십시오.
-
iked 프로세스를 사용하여 IPsec VPN 서비스를 실행할 수 있도록 패키지를 지원하는
junos-ike방화벽입니다. -
로컬 엔드포인트(응답자) 역할을 하는 방화벽은 원격 IKE 피어(개시자)에 연결할 수 있습니다.
-
IKE(Internet Key Exchange) 차단 목록을 연결할 수 있는 IKE 정책입니다.
IKE(Internet Key Exchange) 디도스(DDoS) 공격에 대한 보호를 구성하는 데는 다음 작업이 필요합니다.
-
들어오는 절반의 개방형 IKE(Internet Key Exchange) SA를 관리합니다.
-
들어오는 완전 개방형 IKE(Internet Key Exchange) SA를 관리합니다.
-
다양한 피어에서 들어오는 IKE 세션을 차단하고 차단 목록 중 하나를 IKE 피어와 연결하려면 여러 차단 방법을 구성합니다.
이러한 작업을 구성하려면 다음 작업을 참조하십시오.
- 절반 개방형 IKE(Internet Key Exchange) SA에 대한 IKE(Internet Key Exchange) 세션 구성
- 완전 개방형 IKE(Internet Key Exchange) SA를 위한 IKE(Internet Key Exchange) 세션 구성
- IKE(Internet Key Exchange) 세션 차단 목록 구성
절반 개방형 IKE(Internet Key Exchange) SA에 대한 IKE(Internet Key Exchange) 세션 구성
개요
위에서 설명한 모든 전제 조건을 충족하는지 확인합니다.
이 섹션에서는 절반 개방형 IKE(Internet Key Exchange) SA에 대한 시간 제한, 최대 개수 및 임계값을 구성하는 방법을 알아봅니다. 구성 변경 사항은 새 세션에 적용되는 반면, 기존 세션은 이전에 명시적으로 구성하지 않은 경우 기본값을 계속 사용합니다. [edit security ike session half-open] 계층 수준에서 이러한 구성의 범위는 피어 수준이 아닌 글로벌 수준에서 적용됩니다.
구성
-
옵션을
timeout seconds사용하여 응답자 수명 매개 변수를 설정하려면 다음을 수행합니다.[edit] user@host# set security ike session half-open timeout 150
이 기간 동안 응답자는 시간 초과 기간에 도달할 때까지 반쯤 열린 IKE(Internet Key Exchange) SA의 구성을 허용하지 않습니다. 개시자는 응답자의 구성과 관계없이 60초의 시간 초과 기간을 계속 가질 수 있습니다.
-
옵션을
max-count value사용하여 응답자 최대 카운트 매개 변수를 설정하려면 다음을 수행합니다.[edit] user@host# set security ike session half-open max-count 1000
이 옵션은 응답자에서 절반 열린 IKE(Internet Key Exchange) 세션의 최대 수를 설정합니다. 지정하지 않으면 기본값은 300입니다. 구성은
max-count모든 임계값을 비활성화합니다. 이러한 경우 임계값을 명시적으로 구성하여 적용해야 합니다. -
응답자의 세션 수가 제한에 도달할 때 옵션을
threshold사용하여 다양한 유형의 작업을 지정합니다.-
다음을 사용하여 쿠키 작업을 적용하기 위해 반쯤 열린 IKE(Internet Key Exchange) 세션의 최소 수를 설정하려면 다음을 사용합니다.
send-cookie count[edit] user@host# set security ike session half-open threshold send-cookie 500
이는 응답자가 원격 피어에게 초기 응답에서 피어로 다시 전송된 쿠키로 세션 시작을 재시도하도록 요청하는 임계값 제한을 지정합니다. 여기서 절반 열린 IKE 세션 수 제한이 500에 도달하면 iked 프로세스는 새 IKE 세션에 대한 쿠키 메커니즘을 사용합니다.
-
옵션을 사용하여 시간 제한 감소 작업을 적용하기 위해 절반 개방 IKE(Internet Key Exchange) 세션의 최소 수를 설정하려면 다음을 사용합니다.
reduced-timeout count timeout seconds[edit] user@host# set security ike session half-open threshold reduce-timeout 600 timeout 100
이는 iked 프로세스가 새로운 절반 개방형 IKE SA의 수명을 줄이는 제한을 지정합니다. 절반 개방형 응답자 IKE(Internet Key Exchange) 세션 수가 임계값 아래로 감소하면 절반 개방형 응답자 IKE(Internet Key Exchange) 세션은 기본 시간 제한 값을 다시 사용합니다.
-
-
개시자에게 응답을 다시 보내지 않고 중복된 절반 개방형 IKE 세션을 폐기하기 위한 옵션을
discard-duplicate설정하려면 다음을 수행합니다.[edit] user@host# set security ike session half-open discard-duplicate
협상이 진행되는 동안 IKE(Internet Key Exchange) SA가 없는 다른 개시자 쿠키를 사용하여 동일한 피어에서 오는 중복 세션 시작 요청(SA_INIT)의 경우, 응답자는 패킷을 폐기합니다.
-
옵션을 사용하여
backoff-timeouts백오프 시간 제한을 설정할 수 있습니다.이렇게 하면 세션 시작 실패 시 원격 피어가 물러날 수 있는 시간이 확보되어 해당 기간 동안 동일한 피어가 새 세션을 시작할 수 없게 됩니다. 백오프 시간 초과 후 피어는 새 세션을 시작할 수 있습니다. 세션 시작은 초기화 단계와 인증 단계의 두 단계에서 실패할 수 있습니다.
-
옵션을 사용하여 IKE_AUTH 단계 중에 오류가 발생할 때 백오프 시간 제한을 설정하려면 다음을 사용합니다.
backoff-timeouts auth-phase-failure value[edit] user@host# set security ike session half-open backoff-timeouts auth-phase-failure 150
구성 시
auth-phase-failure차단 목록에 있는 모든 원격 피어는 대상 차단 목록 규칙에 대한 작업으로 백오프를 구성하지 않은 경우에도 백오프됩니다. 백오프에 대한 시간 초과는 에 구성된 시간입니다.auth-phase-failure이 예에서 디바이스는 150초 후에 새 세션을 시작합니다. 특정 규칙에 대한 이 백오프 시간 제한을 덮어쓰려면,backoffrule[edit security ike blocklists blocklist1 rule rule-name then backoff timeout-value] hierarchy level. -
옵션을 사용하여
backoff-timeouts init-phase-failure valueSA_INIT 단계 중에 오류가 발생할 때 백오프 시간 제한을 설정하려면 :[edit] user@host# set security ike session half-open backoff-timeouts init-phase-failure 160
이 예에서 디바이스는 160초 후에 새 세션을 시작합니다.
-
완전 개방형 IKE(Internet Key Exchange) SA를 위한 IKE(Internet Key Exchange) 세션 구성
개요
위에서 설명한 모든 전제 조건을 충족하는지 확인합니다.
이 섹션에서는 [edit security ike session full-open] 계층 수준의 옵션을 incoming-exchange-max-rates 사용하여 전체 개방형 IKE(Internet Key Exchange) SA에 대한 다양한 수신 요청 속도를 구성하는 방법을 살펴봅니다.
구성
IKE(Internet Key Exchange) SA를 설정한 후 원격 피어가 시작한 다양한 교환에 대한 최대 속도를 설정하는 옵션을 구성 incoming-exchange-max-rates 합니다. 세 가지 유형의 환율, 즉 IKE 키 재생성, IPsec 재생성 및 keepalive(데드 피어 감지라고도 함)를 구성할 수 있습니다.
-
다음을 사용하여 수신 피어 시작 IKE 키 재입력 최대 속도를 설정하려면 다음을 사용합니다.
incoming-exchange-max-rates ike-rekey value[edit] user@host# set security ike session full-open incoming-exchange-max-rates ike-rekey 200/60
이 옵션은 IKE(Internet Key Exchange) SA가 이미 존재하는 기존 피어와 함께 피어별로 IKEv2 키 재생성에 적용할 수 있습니다.
-
다음을 사용하여 수신 피어 시작 IPsec SA 키 재입력 최대 속도를 설정하려면 다음을 사용합니다.
incoming-exchange-max-rates ipsec-rekey value[edit] user@host# set security ike session full-open incoming-exchange-max-rates ipsec-rekey 100/60
이 제한은 터널별로 적용됩니다.
-
다음을 사용하여 수신 피어 시작 keepalive 최대 속도를 설정하려면 다음을 사용합니다.
incoming-exchange-max-rates keepalive value[edit] user@host# set security ike session full-open incoming-exchange-max-rates keepalive 60/60
이 제한은 피어별로 적용됩니다.
IKE(Internet Key Exchange) 세션 차단 목록 구성
개요
위에서 설명한 모든 전제 조건을 충족하는지 확인합니다.
피어 IKE(Internet Key Exchange) ID를 기반으로 피어로부터 들어오는 IKE 세션을 차단하려면 하나 이상의 차단 목록을 구성해야 합니다. 각 차단 목록에는 하나 이상의 규칙이 포함되어 있습니다. 각 규칙에는 일치 기준과 작업이 있습니다.
차단 목록을 구성할 때 다음 기준을 고려하십시오.
-
차단 목록 규칙은 협상 중인 새 IKE SA에 적용되며 기존 IKE SA에는 영향을 미치지 않습니다. 피어 인증 단계에서 디바이스는 차단 목록 규칙을 적용합니다.
-
규칙의 적용 순서는 이러한 규칙이 나열되는 순서에 따라 다릅니다.
-
역할(개시자 또는 응답자), ID 유형(IPv4 또는 IPv6 주소, 호스트 이름, 고유 이름, 이메일 ID 또는 키 ID) 및 IKE ID와 일치하는 정규식인 ID 패턴을 기반으로 일치 기준을 구성합니다.
-
ID 유형으로 각 규칙을 구성할 수 있습니다. 이를 통해 동일한 차단 목록 내에서 다른 규칙에 대해 다른 IKE ID를 구성할 수 있습니다.
-
피어 연결을 삭제하거나 거부하는 작업을 구성합니다. 일치에 따라 디바이스가 작업을 적용합니다. 선택적으로 이러한 작업으로 백오프 타이머를 설정할 수 있습니다.
-
IKE(Internet Key Exchange) 게이트웨이와 연결된 IKE(Internet Key Exchange) 정책의 차단 목록을 참조하십시오.
-
각 IKE(Internet Key Exchange) 게이트웨이는 한 가지 유형의 원격 IKE ID 유형만 지원합니다. 차단 목록을 게이트웨이에 연결하고 다른 IKE ID를 포함하는 규칙으로 구성하는 경우 게이트웨이는 IKE ID 유형이 IKE 게이트웨이에 대해 구성된 것과 동일한 규칙만 적용하고 일치시킵니다.
-
IKE(Internet Key Exchange) 게이트웨이에 연결된 차단 목록이 있는 터널 설정 속도 메트릭은 차단 목록에 구성된 규칙 수를 기반으로 합니다.
이 섹션에서는 차단 목록을 구성하고 차단 목록을 IKE(Internet Key Exchange) 정책에 연결하는 방법을 살펴봅니다.
구성
-
여러 규칙이 포함된 차단 목록을 만들려면:
-
차단 목록을 만듭니다.
[edit] user@host# set security ike blocklists blocklist1 description block_from_remote
-
하나 이상의 규칙을 만듭니다.
[edit] user@host# set security ike blocklists blocklist1 rule rule1 description rule_1 user@host# set security ike blocklists blocklist1 rule rule2 description rule_2
이러한 차단 목록과 해당 규칙을 여러 개 만들 수 있습니다.
-
-
일치 기준을 구성하고 작업을 지정하려면:
-
차단 목록에서 blocklist1에 rule1 대한 일치 기준을 구성합니다.
[edit] user@host# set security ike blocklists blocklist1 rule rule1 match role initiator user@host# set security ike blocklists blocklist1 rule rule1 match id-type hostname user@host# set security ike blocklists blocklist1 rule rule1 match id-pattern "peer.*\.example\.net" user@host# set security ike blocklists blocklist1 rule rule2 match role initiator user@host# set security ike blocklists blocklist1 rule rule2 match id-type user-at-hostname user@host# set security ike blocklists blocklist1 rule rule2 match id-pattern "hr.example.com"
IKE ID 그룹 또는 부분 IKE ID를 사용하여 차단 목록을 구성하려면 접미사 또는 접두사와 함께 을 사용합니다
id-pattern value. 예를 들어, hr.example.com, finance.example.com, admin.example.com 를 일치시켜야 하는 경우 *.example.com 값을 사용할 수 있습니다. 규칙 rule1에서 디바이스는 패턴 peer.*\.example\.net과 일치하는 호스트 이름을 찾습니다. 다음은 peer.example.net, peer.1.example.net 및 peer.uplink.example.net 몇 가지 잠재적 일치 항목입니다. 규칙 rule2에서 디바이스는 패턴 hr.example.com과 일치하는 이메일 주소를 찾습니다. 마찬가지로, 다른id-type또는id-pattern를 기반으로 다른 규칙에 대한 다른 일치 기준을 구성할 수 있습니다. 이러한 패턴은 표준 정규 표현식을 사용합니다. -
일치 항목을 위한 작업을 지정합니다.
[edit] user@host# set security ike blocklists blocklist1 rule rule1 then reject user@host# set security ike blocklists blocklist1 rule rule1 then backoff 60 user@host# set security ike blocklists blocklist1 rule rule2 then discard user@host# set security ike blocklists blocklist1 rule rule2 then backoff 100
-
-
차단 목록을 IKE(Internet Key Exchange) 피어와 연결하려면
-
IKE(Internet Key Exchange) 정책 ike_policy1에서 차단 목록을 blocklist1 구성합니다.
[edit] user@host# set security ike policy ike_policy1 blocklist blocklist1
-
예: 피어 인증서 체인 검증을 위한 디바이스 구성
이 예는 IKE 협상 중에 피어 디바이스의 유효성을 검사하는 데 사용되는 인증서 체인에 대한 디바이스를 구성하는 방법을 보여줍니다.
요구 사항
시작하기 전에 로컬 인증서에 대한 요청을 제출할 때 인증 기관(CA)의 주소와 필요한 정보(예: 챌린지 암호)를 확보하십시오.
개요
이 예에서는 인증서 체인에 대한 로컬 디바이스를 구성하고, CA 및 로컬 인증서를 등록하고, 등록된 인증서의 유효성을 확인하고, 피어 디바이스의 해지 상태를 확인하는 방법을 보여줍니다.
토폴로지
이 예는 그림 9와 같이 Host-A의 구성 및 운영 명령을 보여줍니다. Host-A가 Sales-CA에서 CRL을 다운로드하고 Host-B 인증서의 해지 상태를 확인할 수 있도록 Host-A에 동적 CA 프로필이 자동으로 생성됩니다.
이 예에서 Host-A에 대해 1단계 및 2단계 협상을 위한 IPsec VPN 구성이 표시됩니다. 피어 디바이스(Host-B)는 1단계 및 2단계 옵션이 성공적으로 협상되고 보안 연결(SA)이 설정되도록 올바르게 구성되어야 합니다. VPN용 피어 디바이스 구성의 예는 사이트 간 VPN에 대한 원격 IKE ID 구성을 참조하십시오.
구성
인증서 체인을 위한 디바이스를 구성하려면 다음을 수행합니다.
CA 프로필 구성
CLI 빠른 구성
이 예를 빠르게 구성하려면, 아래 명령을 복사하여 텍스트 파일로 붙여 넣은 다음 모든 라인브레이크를 제거하고, 네트워크 구성을 일치하는 데 필요한 세부 사항을 변경하고, 계층 수준에서 [edit] 명령을 복사하여 CLI에 붙여 넣은 다음, 구성 모드에서 들어갑니다 commit .
set security pki ca-profile Root-CA ca-identity CA-Root set security pki ca-profile Root-CA enrollment url http://198.51.100.230:8080/scep/Root/ set security pki ca-profile Root-CA revocation-check crl set security pki ca-profile Eng-CA ca-identity Eng-CA set security pki ca-profile Eng-CA enrollment url http://198.51.100.230:8080/scep/Eng/ set security pki ca-profile Eng-CA revocation-check crl set security pki ca-profile Dev-CA ca-identity Dev-CA set security pki ca-profile Dev-CA enrollment url http://198.51.100.230:8080/scep/Dev/ set security pki ca-profile Dev-CA revocation-check crl
단계별 절차
다음 예에서는 구성 계층에서 다양한 수준을 탐색해야 합니다. 이를 수행하는 방법에 대한 지침은 CLI 사용자 가이드의 구성 모드에서 CLI 편집기 사용을 참조하십시오.
CA 프로필을 구성하려면 다음을 수행합니다.
-
Root-CA에 대한 CA 프로필을 생성합니다.
[edit security pki] user@host# set ca-profile Root-CA ca-identity CA-Root user@host# set ca-profile Root-CA enrollment url http://198.51.100.230:8080/scep/Root/ user@host# set ca-profile Root-CA revocation-check crl
-
Eng-CA에 대한 CA 프로필을 생성합니다.
[edit security pki] user@host# set ca-profile Eng-CA ca-identity Eng-CA user@host# set ca-profile Eng-CA enrollment url http://198.51.100.230:8080/scep/Eng/ user@host# set ca-profile Eng-CA revocation-check crl
-
Dev-CA에 대한 CA 프로필을 만듭니다.
[edit security pki] user@host# set ca-profile Dev-CA ca-identity Dev-CA user@host# set ca-profile Dev-CA enrollment url http://198.51.100.230:8080/scep/Dev/ user@host# set ca-profile Dev-CA revocation-check crl
결과
구성 모드에서 명령을 입력하여 구성을 확인합니다. show security pki 출력에 의도한 구성이 표시되지 않으면 이 예의 구성 지침을 반복하여 수정합니다.
[edit]
user@host# show security pki
ca-profile Root-CA {
ca-identity Root-CA;
enrollment {
url "http:/;/198.51.100.230:8080/scep/Root/";
}
revocation-check {
crl ;
}
}
ca-profile Eng-CA {
ca-identity Eng-CA;
enrollment {
url "http:/;/198.51.100.230:8080/scep/Eng/";
}
revocation-check {
crl ;
}
}
ca-profile Dev-CA {
ca-identity Dev-CA;
enrollment {
url "http:/;/198.51.100.230:8080/scep/Dev/";
}
revocation-check {
crl ;
}
}
디바이스 구성이 완료되면 구성 모드에서 들어갑니다 commit .
인증서 등록
단계별 절차
인증서를 등록하려면 다음을 수행합니다.
-
CA 인증서를 등록합니다.
user@host> request security pki ca-certificate enroll ca-profile Root-CA
user@host> request security pki ca-certificate enroll ca-profile Eng-CA
user@host> request security pki ca-certificate enroll ca-profile Dev-CA
프롬프트에 입력 yes 하여 CA 인증서를 로드합니다.
-
CA 인증서가 디바이스에 등록되어 있는지 확인합니다.
user@host> show security pki ca-certificate ca-profile Root-CA Certificate identifier: Root-CA Issued to: Root-CA, Issued by: C = us, O = example, CN = Root-CA Validity: Not before: 08-14-2012 22:19 Not after: 08-13-2017 22:19 Public key algorithm: rsaEncryption(2048 bits)user@host> show security pki ca-certificate ca-profile Eng-CA Certificate identifier: Eng-CA Issued to: Eng-CA, Issued by: C = us, O = example, CN = Root-CA Validity: Not before: 08-15-2012 01:02 Not after: 08-13-2017 22:19 Public key algorithm: rsaEncryption(2048 bits)user@host> show security pki ca-certificate ca-profile Dev-CA Certificate identifier: Dev-CA Issued to: Dev-CA, Issued by: C = us, O = example, CN = Eng-CA Validity: Not before: 08-15-2012 17:41 Not after: 08-13-2017 22:19 Public key algorithm: rsaEncryption(2048 bits) -
등록된 CA 인증서의 유효성을 확인합니다.
user@host> request security pki ca-certificate verify ca-profile Root-CA CA certificate Root-CA verified successfully
user@host> request security pki ca-certificate verify ca-profile Eng-CA CA certificate Eng-CA verified successfully
user@host> request security pki ca-certificate verify ca-profile Dev-CA CA certificate Dev-CA verified successfully
-
키 쌍을 생성합니다.
user@host> request security pki generate-key-pair certificate-id Host-A type rsa size 1024
-
로컬 인증서를 등록합니다.
user@host> request security pki local-certificate enroll certificate-id Host-A ca-profile Dev-CA challenge-password example domain-name host-a.example.net email host-a@example.net subject DC=example,CN=Host-A, OU=DEV,O=PKI,L=Sunnyvale,ST=CA,C=US
-
로컬 인증서가 디바이스에 등록되어 있는지 확인합니다.
user@host> show security pki local-certificate Issued to: Host-A, Issued by: C = us, O = example, CN = Dev-CA Validity: Not before: 09-17-2012 22:22 Not after: 08-13-2017 22:19 Public key algorithm: rsaEncryption(1024 bits) -
등록된 로컬 인증서의 유효성을 확인합니다.
user@host> request security pki local-certificate verify certificate-id Host-A Local certificate Host-A verification success
-
구성된 CA 프로필에 대한 CRL 다운로드를 확인합니다.
user@host> show security pki crl CA profile: Root-CA CRL version: V00000001 CRL issuer: C = us, O = example, CN = Root-CA Effective date: 09- 9-2012 13:08 Next update: 09-21-2012 02:55 CA profile: Eng-CA CRL version: V00000001 CRL issuer: C = us, O = example, CN = Eng-CA Effective date: 08-22-2012 17:46 Next update: 10-24-2015 03:33 CA profile: Dev-CA CRL version: V00000001 CRL issuer: C = us, O = example, CN = Dev-CA Effective date: 09-14-2012 21:15 Next update: 09-26-2012 11:02
IPsec VPN 옵션 구성
CLI 빠른 구성
이 예를 빠르게 구성하려면, 아래 명령을 복사하여 텍스트 파일로 붙여 넣은 다음 모든 라인브레이크를 제거하고, 네트워크 구성을 일치하는 데 필요한 세부 사항을 변경하고, 계층 수준에서 [edit] 명령을 복사하여 CLI에 붙여 넣은 다음, 구성 모드에서 들어갑니다 commit .
set security ike proposal ike_cert_prop_01 authentication-method rsa-signatures set security ike proposal ike_cert_prop_01 dh-group group5 set security ike proposal ike_cert_prop_01 authentication-algorithm sha1 set security ike proposal ike_cert_prop_01 encryption-algorithm aes-256-cbc set security ike policy ike_cert_pol_01 mode main set security ike policy ike_cert_pol_01 proposals ike_cert_prop_01 set security ike policy ike_cert_pol_01 certificate local-certificate Host-A set security ike gateway ike_cert_gw_01 ike-policy ike_cert_pol_01 set security ike gateway ike_cert_gw_01 address 192.0.2.51 set security ike gateway ike_cert_gw_01 external-interface ge-0/0/1.0 set security ike gateway ike_cert_gw_01 local-identity 192.0.2.31 set security ipsec proposal ipsec_prop_01 protocol esp set security ipsec proposal ipsec_prop_01 authentication-algorithm hmac-sha1-96 set security ipsec proposal ipsec_prop_01 encryption-algorithm 3des-cbc set security ipsec proposal ipsec_prop_01 lifetime-seconds 300 set security ipsec policy ipsec_pol_01 proposals ipsec_prop_01 set security ipsec vpn ipsec_cert_vpn_01 bind-interface st0.1 set security ipsec vpn ipsec_cert_vpn_01 ike gateway ike_cert_gw_01 set security ipsec vpn ipsec_cert_vpn_01 ike ipsec-policy ipsec_pol_01
단계별 절차
다음 예에서는 구성 계층에서 다양한 수준을 탐색해야 합니다. 이를 수행하는 방법에 대한 지침은 CLI 사용자 가이드의 구성 모드에서 CLI 편집기 사용을 참조하십시오.
IPsec VPN 옵션 구성:
-
1단계 옵션을 구성합니다.
[edit security ike proposal ike_cert_prop_01] user@host# set authentication-method rsa-signatures user@host# set dh-group group5 user@host# set authentication-algorithm sha1 user@host# set encryption-algorithm aes-256-cbc [edit security ike policy ike_cert_pol_01] user@host# set mode main user@host# set proposals ike_cert_prop_01 user@host# set certificate local-certificate Host-A [edit security ike gateway ike_cert_gw_01] user@host# set ike-policy ike_cert_pol_01 user@host# set address 192.0.2.51 user@host# set external-interface ge-0/0/1.0 user@host# set local-identity 192.0.2.31
-
2단계 옵션을 구성합니다.
[edit security ipsec proposal ipsec_prop_01] user@host# set protocol esp user@host# set authentication-algorithm hmac-sha1-96 user@host# set encryption-algorithm 3des-cbc user@host# set lifetime-seconds 300 [edit security ipsec policy ipsec_pol_01] user@host# set proposals ipsec_prop_01 [edit security ipsec vpn ipsec_cert_vpn_01] user@host# set bind-interface st0.1 user@host# set ike gateway ike_cert_gw_01 user@host# set ike ipsec-policy ipsec_pol_01
결과
구성 모드에서 and show security ipsec 명령을 입력 show security ike 하여 구성을 확인합니다. 출력에 의도한 구성이 표시되지 않으면 이 예의 구성 지침을 반복하여 수정합니다.
[edit]
user@host# show security ike
proposal ike_cert_prop_01 {
authentication-method rsa-signatures;
dh-group group5;
authentication-algorithm sha1;
encryption-algorithm aes-256-cbc;
}
policy ike_cert_pol_01 {
mode main;
proposals ike_cert_prop_01;
certificate {
local-certificate Host-A;
}
}
gateway ike_cert_gw_01 {
ike-policy ike_cert_pol_01;
address 192.0.2.51;
external-interface ge-0/0/1.0;
}
[edit]
user@host# show security ipsec
proposal ipsec_prop_01 {
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm 3des-cbc;
lifetime-seconds 300;
}
policy ipsec_pol_01 {
proposals ipsec_prop_01;
}
vpn ipsec_cert_vpn_01 {
bind-interface st0.1;
ike {
gateway ike_cert_gw_01;
ipsec-policy ipsec_pol_01;
}
}
디바이스 구성이 완료되면 구성 모드에서 들어갑니다 commit .
검증
피어 디바이스 간의 IKE 협상 중에 인증서 유효성 검사가 성공하면 IKE 및 IPsec 보안 연결(SA)이 모두 설정됩니다.
인증서가 유효한 경우 IKE(Internet Key Exchange) SA가 작동 중입니다. 인증서가 해지되면 IKE SA가 다운되고 IPSEC SA가 형성되며, 피어 디바이스에서 해지 검사가 구성된 경우에만 인증서가 해지됩니다
IKE(Internet Key Exchange) 1단계 상태 확인
목적
IKE(Internet Key Exchange) 1단계 상태를 확인합니다.
작업
운영 모드에서 명령을 입력합니다 show security ike security-associations .
user@host> show security ike security-associations
Index State Initiator cookie Responder cookie Mode Remote Address
2090205 DOWN 285feacb50824495 59fca3f72b64da10 Main 192.0.2.51
IPsec 2단계 상태 확인
목적
IPsec 2단계 상태를 확인합니다.
작업
운영 모드에서 명령을 입력합니다 show security ipsec security-associations .
user@host> show security ipsec security-associations
Total active tunnels: 1
ID Algorithm SPI Life:sec/kb Mon vsys Port Gateway
<131073 ESP:3des/sha1 a4756de9 207/ unlim - root 500 192.0.2.51
>131073 ESP:3des/sha1 353bacd3 207/ unlim - root 500 192.0.2.51
해지된 인증서에 대한 IKE 및 IPsec SA 실패
해지된 인증서 확인
문제
피어 디바이스 간의 IKE 협상 중에 인증서 유효성 검사가 실패하면 피어의 인증서가 해지되지 않았는지 확인합니다. 동적 CA 프로필을 사용하면 로컬 디바이스가 피어의 CA에서 CRL을 다운로드하고 피어 인증서의 해지 상태를 확인할 수 있습니다. 동적 CA 프로필을 revocation-check crl 사용하려면 상위 CA 프로필에서 옵션을 구성해야 합니다.
해결책
피어 인증서의 해지 상태를 확인하려면
-
운영 모드에서 명령을 입력하여 피어 디바이스의 CRL을 표시할 동적 CA 프로필을 식별합니다 show security pki crl .
user@host> show security pki crl CA profile: Root-CA CRL version: V00000001 CRL issuer: C = us, O = example, CN = Root-CA Effective date: 09- 9-2012 13:08 Next update: 09-21-2012 02:55 CA profile: Eng-CA CRL version: V00000001 CRL issuer: C = us, O = example, CN = Eng-CA Effective date: 08-22-2012 17:46 Next update: 10-24-2015 03:33 CA profile: Dev-CA CRL version: V00000001 CRL issuer: C = us, O = example, CN = Dev-CA Effective date: 09-14-2012 21:15 Next update: 09-26-2012 11:02 CA profile: dynamic-001 CRL version: V00000001 CRL issuer: C = us, O = example, CN = Sales-CA Effective date: 09-14-2012 21:15 Next update: 09-26-2012 11:02CA 프로필
dynamic-001은 Host-A에서 자동으로 생성되므로 Host-A는 Host-B의 CA(Sales-CA)에서 CRL을 다운로드하고 피어 인증서의 해지 상태를 확인할 수 있습니다. -
운영 모드에서 명령을 입력 show security pki crl ca-profile dynamic-001 detail 하여 동적 CA 프로필에 대한 CRL 정보를 표시합니다.
엔터 버튼
user@host> show security pki crl ca-profile dynamic-001 detail CA profile: dynamic-001 CRL version: V00000001 CRL issuer: C = us, O = example, CN = Sub11 Effective date: 09-19-2012 17:29 Next update: 09-20-2012 01:49 Revocation List: Serial number Revocation date 10647C84 09-19-2012 17:29 UTCHost-B의 인증서(일련 번호 10647084)가 해지되었습니다.
IKEv2 단편화
메시지 단편화
RFC 7383, Internet Key Exchange 프로토콜 버전 2(IKEv2) 메시지 단편화에 설명된 바와 같이 IKEv2 메시지 단편화를 사용하면 IP 단편이 차단되고 피어가 SA(IPsec Security Association)를 설정할 수 없는 환경에서 IKEv2가 작동할 수 있습니다. IKEv2 단편화는 큰 IKEv2 메시지를 일련의 작은 메시지로 분할하여 IP 수준에서 단편화가 발생하지 않도록 합니다. 단편화는 원본 메시지가 암호화되고 인증되기 전에 수행되므로 각 조각이 별도로 암호화되고 인증됩니다. 수신기에서 조각은 수집, 확인, 해독 및 원본 메시지로 병합됩니다.
IKEv2 단편화이 발생하려면 두 VPN 피어 모두 IKE_SA_INIT 교환에 IKEV2_FRAGMENTATION_SUPPORTED 알림 페이로드를 포함하여 단편화 지원을 나타내 야 합니다 . 두 피어 모두 단편화 지원을 나타내는 경우, IKEv2 단편화의 사용 여부를 결정하는 것은 메시지 교환 개시자의 몫입니다.
방화벽에서는 IKEv2 메시지당 최대 32개의 조각이 허용됩니다. 송수신할 IKEv2 메시지 조각의 수가 32를 초과하면 조각이 삭제되고 터널이 설정되지 않습니다. 개별 메시지 조각의 재전송은 지원되지 않습니다
구성
방화벽에서 IKEv2 단편화는 기본적으로 IPv4 및 IPv6 메시지에 대해 사용하도록 설정됩니다. IKEv2 단편화를 비활성화하려면 [edit security ike gateway gateway-name fragmentation] 계층 수준에서 문을 사용합니다disable. 또한 이 size 문을 사용하여 메시지가 단편화되는 패킷의 크기를 구성할 수 있으며, 패킷 크기는 500바이트에서 1300바이트 사이입니다. 구성되지 않은 경우size, 기본 패킷 크기는 IPv4 트래픽의 경우 576바이트, IPv6 트래픽의 경우 1280바이트입니다. 구성된 패킷 크기보다 큰 IKEv2 패킷은 단편화됩니다.
IKEv2 단편화가 비활성화 또는 활성화되거나 패킷 조각 크기가 변경되면 IKE 게이트웨이에서 호스팅되는 VPN 터널이 중단되고 IKE 및 IPsec SA가 재협상됩니다.
주의 사항
다음 기능은 IKEv2 단편화에서 지원되지 않습니다.
-
경로 MTU 검색.
-
SNMP입니다.
또한보십시오
로컬 인증서를 사용하는 IKE(Internet Key Exchange) 정책
IKE 협상 중 인증에 로컬 인증서를 사용하는 IKE 정책에 대해 알아보려면 이 주제를 읽어보십시오.
- IKE의 로컬 인증서
- 로컬 인증서 선택 기준
- 여러 로컬 인증서
- 인증서 선택에서 IKE ID의 역할
- IKE의 로컬 인증서 캐싱
- 로컬 인증서의 추가 또는 삭제
- 여러 로컬 인증서로 IKE(Internet Key Exchange) 정책 구성
IKE의 로컬 인증서
IKE(Internet Key Exchange)는 인증서 기반 인증을 지원하여 VPN 피어 간에 신뢰를 안전하게 구축합니다. 이 인증 방법에서 두 피어는 IKE 협상 중에 디지털 인증서를 사용하여 서로의 ID를 확인합니다.
IKE(Internet Key Exchange) 인증 단계에서 원격 피어(개시자)는 로컬 디바이스(응답자)에 인증서 요청 페이로드를 보냅니다. 이에 대한 응답으로 로컬 디바이스는 로컬 인증서가 포함된 인증서 페이로드를 보냅니다. 개시자는 수신된 인증서를 사용하여 인증서 체인을 확인하고 발급 CA(인증 기관)와의 신뢰 관계를 확인하여 응답자의 ID의 유효성을 검사합니다. 이 검증을 통해 응답자가 IKE 협상에 참여할 수 있는 권한이 있는지 확인합니다.
로컬 인증서 선택 기준
로컬 인증서는 IKE(Internet Key Exchange) 협상 중에 응답자가 ID를 증명하기 위해 개시자에게 제시하는 인증서입니다. VPN 피어는 인증서 요청에 CA 식별자를 포함하여 신뢰하는 CA를 나타냅니다. iked 프로세스는 처음 8개의 식별자만 고려하고 추가 식별자는 무시합니다. 로컬 디바이스는 피어의 인증서 요청 페이로드에 포함된 CA 식별자를 검사하고 다음 표에 나열된 기준에 따라 로컬 인증서를 선택합니다.
| IKE(Internet Key Exchange) 버전 | 인증 선택 기준 |
|---|---|
| IKEv2 | 인증서 요청 페이로드에 제공된 CA 해시를 기반으로 로컬 인증서를 선택합니다. |
| IKEv1 | 인증서 요청 페이로드에 제공된 CA 주체 고유 이름(DN)을 기반으로 로컬 인증서를 선택합니다. |
| IKE(Internet Key Exchange) 폴백 동작 | 일치하는 항목이 없을 경우 로컬 인증서 목록에 로드된 첫 번째 인증서를 선택합니다. |
여러 로컬 인증서
디바이스는 단일 또는 여러 로컬 인증서를 지원하는지 여부에 따라 로컬 인증서를 선택하고 관리합니다.
디바이스가 단일 로컬 인증서만 지원하는 경우:
-
각각의 새로운 로컬 인증서 구성은 기존 인증서를 대체합니다.
-
게이트웨이는 여러 원격 피어에 서비스를 제공하는 경우에도 단일 인증서를 사용합니다. 일부 피어에는 게이트웨이가 피어의 요청에 따라 일치하는 로컬 인증서를 제공하지 않을 수 있으므로 게이트웨이 인증서의 유효성을 검사하는 데 필요한 CA 인증서가 없을 수 있습니다.
디바이스가 iked 프로세스로 여러 로컬 인증서를 지원하는 경우:
-
IKE(Internet Key Exchange) 정책에서 여러 로컬 인증서를 구성할 수 있습니다.
-
구성된 각 로컬 인증서는 기존 목록을 대체하는 대신 기존 목록에 추가됩니다. 인증서는 만료되거나 명시적으로 제거될 때까지 계속 사용할 수 있습니다.
-
디바이스는 나열된 순서대로 로컬 인증서를 평가합니다. 디바이스는 체인(신뢰할 수 있는 루트 CA에 구축됨)이 피어 CA 식별자 중 하나와 일치하는 첫 번째 인증서를 선택합니다. 인증서 요청의 CA 식별자와 일치하는 구성된 인증서가 없는 경우 iked 프로세스는 신뢰할 수 있는 루트 CA에 체인을 구축할 수 있는 로컬 인증서를 선택합니다. 이 프로세스는 인증서를 순차적으로 평가하고 피어에 보낼 유효한 체인이 있는 첫 번째 인증서를 선택합니다.
인증서 선택에서 IKE ID의 역할
-
로컬 IKE ID는 IKE ID 유형이 [
edit security ike gateway name remote-identity distinguished-name] 계층 수준에서 DN인 경우를 제외하고는 IKE 인증서 선택에 영향을 주지 않습니다.- IKE ID가 DN인 경우, IKE는 PKI 조회를 수행하여 나열된 순서를 평가하지 않고 DN과 일치하는 인증서를 검색합니다.
- 검색 후 IKE(Internet Key Exchange)는 나중에 사용할 수 있도록 인증서를 캐시합니다.
로컬 IKE ID가 선택한 로컬 인증서와 일치하지 않으면 피어 디바이스에서 IKE 핸드셰이크가 실패할 수 있습니다.
IKE의 로컬 인증서 캐싱
로컬 인증서를 선택한 후 IKE(Internet Key Exchange)는 인증서를 캐시하여 향후 PKI 조회를 최소화합니다. IKE에 캐시된 경우:
-
iked 프로세스는 수신 CA 식별자와 일치하는 한 후속 연결에 캐시된 인증서를 사용합니다.
-
캐시된 인증서가 들어오는 CA 식별자와 일치하지 않으면 iked 프로세스는 새 인증서를 선택하고 구성된 로컬 인증서 목록에서 인증서 체인을 다시 빌드합니다.
-
인증서 순서는 인증서 선택에 영향을 주지 않습니다.
-
인증서의 순서를 변경하더라도(예: 첫 번째 인증서를 다른 위치로 이동) 새 PKI 조회가 트리거되거나 기존 IPsec 연결이 삭제되지 않습니다.
-
IKE(Internet Key Exchange)는 필요한 선택 기준을 충족하는 한 캐시된 인증서를 계속 사용합니다.
-
로컬 인증서가 디바이스에서 삭제되면 해당 캐시된 인증서도 지워집니다.
-
iked 프로세스를 다시 시작하면 인증서 캐시가 지워집니다.
로컬 인증서의 추가 또는 삭제
-
인증서를 추가해도 기존 SA(보안 연결)는 삭제되지 않습니다.
-
인증서 목록에서 인증서를 삭제하면 해당 IKE 정책을 사용하는 모든 IKE SA가 삭제됩니다.
-
PKI에서 로컬 인증서 또는 CA 인증서를 삭제해도 IKE에서 커밋 오류가 발생하거나 기존 IPsec 연결이 삭제되지 않습니다.
여러 로컬 인증서로 IKE(Internet Key Exchange) 정책 구성
여러 로컬 인증서를 구성하려면 다음 단계를 수행합니다.
-
CA 프로필을 구성하고 CA 인증서를 로드합니다. 인증 기관을 참조하십시오.
-
디바이스에 기존 로컬 인증서를 로드하거나 CA 인증서가 이전에 로드된 CA에서 로컬 인증서를 등록합니다. 디지털 인증서를 참조하십시오.
IKE(Internet Key Exchange) 정책의 각 로컬 인증서에 대해 이 단계를 반복합니다.
-
로컬 인증서를 IKE(Internet Key Exchange) 정책과 연결합니다. 다음 명령 중 하나를 사용합니다.
set security ike policy IKE-POL certificate local-certificate [cert1 cert2 cert3]
또는
[edit] set security ike policy IKE-POL certificate local-certificate cert1 set security ike policy IKE-POL certificate local-certificate cert2 set security ike policy IKE-POL certificate local-certificate cert3
IKE(Internet Key Exchange) 정책, IKE(Internet Key Exchange) 제안, IKE(Internet Key Exchange) 게이트웨이를 구성한 다음 종단 간 IPsec VPN 터널 설정을 위한 IPsec 정책 및 제안을 구성합니다.
IKE(Internet Key Exchange) 정책에 구성된 인증서 목록에서 어떤 로컬 인증서를 선택할지 결정하려면 IKE 추적 로그를 검토하십시오. 로그에는 인증서 주체 DN이 표시됩니다.
또한보십시오
신뢰할 수 있는 CA가 있는 IKE(Internet Key Exchange) 정책
이 예는 신뢰할 수 있는 CA 서버를 피어의 IKE(Internet Key Exchange) 정책에 바인딩하는 방법을 보여줍니다.
시작하기 전에 피어의 IKE(Internet Key Exchange) 정책과 연결하려는 모든 신뢰할 수 있는 CA 목록이 있어야 합니다.
IKE(Internet Key Exchange) 정책을 단일 신뢰할 수 있는 CA 프로필 또는 신뢰할 수 있는 CA 그룹에 연결할 수 있습니다. 보안 연결을 설정하기 위해 IKE 게이트웨이는 IKE 정책을 사용하여 인증서를 검증하는 동안 구성된 CA 그룹(ca-profiles)으로 자신을 제한합니다. 신뢰할 수 있는 CA 또는 신뢰할 수 있는 CA 그룹 이외의 원본에서 발급한 인증서는 유효성이 검사되지 않습니다. IKE(Internet Key Exchange) 정책에서 인증서 유효성 검사 요청이 오는 경우 IKE(Internet Key Exchange) 정책의 연결된 CA 프로필이 인증서의 유효성을 검사합니다. IKE(Internet Key Exchange) 정책이 CA와 연결되지 않은 경우, 기본적으로 인증서는 구성된 CA 프로필 중 하나에 의해 검증됩니다.
이 예에서는 라는 CA root-ca 프로필이 생성되고 프로필에 a root-ca-identity 가 연결됩니다.
신뢰할 수 있는 CA 그룹에 추가하려는 CA 프로필을 최대 20개까지 구성할 수 있습니다. 신뢰할 수 있는 CA 그룹에서 20개 이상의 CA 프로필을 구성하는 경우 구성을 커밋할 수 없습니다.
디바이스에 구성된 CA 프로필 및 신뢰할 수 있는 CA 그룹을 보려면 명령을 실행합니다 show security pki .
user@host# show security ike
proposal ike_prop {
authentication-method rsa-signatures;
dh-group group2;
authentication-algorithm sha-256;
encryption-algorithm aes-256-cbc;
}
policy ike_policy {
proposals ike_prop;
certificate {
local-certificate SPOKE;
trusted-ca ca-profile root-ca;
}
}
이 명령은 show security ike 명명된 ike_policy IKE 정책 및 IKE 정책과 연결된 인증서 아래에 CA 프로필 그룹을 표시합니다.
또한보십시오
신뢰할 수 있는 CA 그룹의 IKE(Internet Key Exchange) 정책
인증서 기반 인증에 신뢰할 수 있는 CA 그룹을 사용하도록 IKE 정책을 구성하는 방법에 대해 알아보려면 이 주제를 읽어보십시오.
IKE의 신뢰할 수 있는 CA 그룹 개요
신뢰할 수 있는 인증 기관(CA) 그룹은 하나 이상의 CA 프로필을 번들로 묶고 IKE 협상 중에 피어 인증서의 유효성을 검사하기 위한 단일 트러스트 앵커 역할을 합니다. 디바이스에는 여러 CA 인증서가 포함될 수 있습니다. 구성된 CA 인증서의 하위 집합인 신뢰할 수 있는 CA 그룹을 사용하도록 IKE(Internet Key Exchange)를 구성할 수 있습니다. IKEv2 또는 IKEv1에 대한 인증서 기반 인증 중에 디바이스는 루트까지 피어의 인증서 체인을 확인합니다. IKE(Internet Key Exchange) 정책이 신뢰할 수 있는 CA 그룹을 사용하면 디바이스는 그룹에 포함된 모든 CA 프로필에 대해 피어의 인증서를 검증합니다.
신뢰할 수 있는 CA 그룹은 여러 CA를 사용하는 환경에서 또는 한 CA에서 다른 CA로 마이그레이션할 때 인증서 관리를 단순화합니다. 언제든지 CA 그룹을 업데이트하여 CA 프로필을 추가하거나 제거할 수 있습니다.
VPN 피어가 연결을 시작하면 디바이스는 IKE(Internet Key Exchange) 정책에 구성된 신뢰할 수 있는 CA 그룹을 사용하여 피어의 인증서를 검증합니다.
-
인증서가 신뢰할 수 있는 그룹의 CA에 의해 서명되면 인증이 성공하고 연결이 허용됩니다.
-
인증서가 신뢰할 수 있는 그룹의 CA에 의해 서명되지 않으면 인증이 실패하고 IPsec 터널이 설정되지 않습니다.
따라서 신뢰할 수 있는 CA 그룹은 디바이스가 인증된 CA에서 발급한 인증서만 수락하도록 하여 안전한 VPN 인증을 유지하면서 인증서 관리를 단순화합니다.
신뢰할 수 있는 CA 그룹으로 IKE(Internet Key Exchange) 정책 구성
신뢰할 수 있는 CA 그룹으로 IKE(Internet Key Exchange) 정책을 구성하기 전에 다음을 확인하십시오.
-
신뢰할 수 있는 모든 CA 목록이 있습니다.
-
IKE(Internet Key Exchange) 정책은 인증서 기반 인증을 사용합니다.
-
디바이스에서 PKI 및 IKE(Internet Key Exchange) 설정을 구성할 수 있습니다.
신뢰할 수 있는 CA 그룹으로 IKE(Internet Key Exchange) 정책을 구성하고 확인하려면 다음을 수행합니다.
-
CA 프로필을 만들고 인증서를 로드합니다. 각 CA 프로필은 하나의 CA를 나타냅니다. CA 프로필 구성을 참조하십시오.
[edit] user@host# set security pki ca-profile CORP-CA ca-identity CORP-CA user@host# set security pki ca-profile BRANCH1-CA ca-identity BRANCH1-CA user@host# set security pki ca-profile BRANCH2-CA ca-identity BRANCH2-CA
각 CA 프로필은 피어 인증서의 유효성을 검사할 수 있는 신뢰할 수 있는 CA를 나타냅니다.
user@host> request security pki ca-certificate load ca-profile CORP-CA filename corp-ca.crt user@host> request security pki ca-certificate load ca-profile BRANCH1-CA filename branch1-ca.crt user@host> request security pki ca-certificate load ca-profile BRANCH2-CA filename branch2-ca.crt
CA 인증서를 해당 CA 프로필에 로드합니다. 로드된 각 CA 인증서를 통해 디바이스는 해당 CA에서 발급한 피어 인증서의 유효성을 검사할 수 있습니다.
-
신뢰할 수 있는 CA 그룹을 만듭니다. CA 프로필을 신뢰할 수 있는 CA 그룹으로 그룹화합니다. 신뢰할 수 있는 CA 그룹의 CA 프로필 순서는 인증서 유효성 검사에 영향을 주지 않습니다. 신뢰할 수 있는 CA 그룹 구성을 참조하십시오.
[edit] user@host# set security pki trusted-ca-group VPN-TRUSTED-CA-GROUP ca-profiles [CORP-CA BRANCH1-CA BRANCH2-CA]
디바이스는 IKE(Internet Key Exchange) 인증 중에 피어 인증서를 검증하기 위해 인증 그룹을 사용합니다.
-
인증서 기반 인증을 사용하도록 IKE(Internet Key Exchange) 정책을 구성하고 신뢰할 수 있는 CA 그룹을 정책과 연결합니다.
[edit] user@host# set security ike policy IKE-POL mode main user@host# set security ike policy IKE-POL certificate trusted-ca trusted-ca-group VPN-TRUSTED-CA-GROUP
-
신뢰할 수 있는 CA 그룹이 올바르게 구성되었는지 확인합니다.
[edit] user@host# show security pki ca-profile-group VPN-TRUSTED-CA-GROUP { ca-profile CORP-CA; ca-profile BRANCH1-CA; ca-profile BRANCH2-CA; }[edit] user@host# show security ike policy IKE-POL { certificate { trusted-ca-profile-group VPN-TRUSTED-CA-GROUP; } }신뢰할 수 있는 CA 그룹이 IKE 정책과 연결되어 있는지 확인합니다.
구성이 완료된 후:
-
디바이스는 인증서를 사용하여 VPN 피어를 인증합니다.
-
디바이스는 신뢰할 수 있는 CA 그룹의 모든 CA에서 발급한 인증서를 신뢰합니다.
-
CA 그룹에서 피어 인증서의 유효성을 검사하면 들어오는 VPN 연결이 성공합니다.
IKE에서 Establish-Tunnel Responder-only 구성
이 주제는 IKE(Internet Key Exchange)에서 establish-tunnels responder-only를 구성하는 방법을 보여줍니다. 원격 피어에서 터널을 시작하고 모든 터널을 통해 트래픽을 보냅니다. IKE(Internet Key Exchange)가 활성화되는 시기를 지정합니다.
방화벽에서 옵션은 establish-tunnels 계층 수준에서 [edit security ipsec vpn vpn-name] 및 responder-only-no-rekey 값을 지원합니다responder-only.
이러한 옵션은 사이트 간 VPN에서만 지원됩니다. 이러한 옵션은 자동 VPN에서 지원되지 않습니다.
responder-only 및 responder-only-no-rekey 옵션은 디바이스에서 VPN 터널을 설정하지 않으므로 원격 피어에서 VPN 터널이 시작됩니다. 구성할 때 responder-only설정된 터널은 구성된 IKE 및 IPsec 수명 값을 기반으로 IKE와 IPsec 모두의 키를 다시 생성합니다. 구성할 때 responder-only-no-rekey설정된 터널은 디바이스에서 키 재생성을 하지 않고 원격 피어에 의존하여 키 재생성을 시작합니다. 원격 피어가 키 재생성을 시작하지 않으면 하드 수명이 만료된 후 터널 해제가 발생합니다.
시작하기 전에:
-
자동 키 IKE(Internet Key Exchange) IPsec 터널을 설정하는 방법을 이해합니다. IPsec 개요를 읽어보십시오.
IKE(Internet Key Exchange)에서 establish-터널 응답자 전용을 구성하려면 다음을 수행합니다.
플랫폼별 IKEv2 응답자 전용 동작
기능 탐색기를 사용하여 특정 기능에 대한 플랫폼 및 릴리스 지원을 확인하십시오.
다음 표를 사용하여 플랫폼의 플랫폼별 동작을 검토하십시오.
| 플랫폼 | 차이 |
|---|---|
| SRX 시리즈 |
|
변경 내역 표
기능 지원은 사용 중인 플랫폼과 릴리스에 따라 결정됩니다. 기능 탐색기를 사용하여 플랫폼에서 기능이 지원되는지 확인합니다.
[edit security ipsec vpn vpn-name] 옵션에 establish-tunnels 대한 responder-only 지원 및 responder-only-no-rekey 값은 Junos OS 릴리스 19.1R1의 SRX5000 라인에 도입되었습니다.