이 페이지에서
IPsec VPN을 위한 IKE(Internet Key Exchange)
IKEv2(Internet Key Exchange version 2)는 피어 VPN 디바이스 간에 보안 VPN 통신 채널을 제공하고 IPsec SA(보안 연결)에 대한 협상 및 인증을 보호된 방식으로 정의하는 IPsec 기반 터널링 프로토콜입니다.
IKE(Internet Key Exchange) 및 IPsec 패킷 처리
IKE(Internet Key Exchange)는 IPsec에 대한 터널 관리를 제공하고 최종 엔터티를 인증합니다. IKE는 네트워크 디바이스 간 IPsec 터널을 생성하기 위한 Diffie-Hellman(DH) 키 교환을 수행합니다. 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을 사용하여 보호합니다.
Next Payload 필드에는 다음 페이로드 유형 중 하나를 나타내는 숫자가 포함되어 있습니다.
-
0002 - SA 협상 페이로드에 1단계 또는 2단계 SA에 대한 정의가 포함되어 있습니다.
-
0004 - 제안 페이로드는 1단계 또는 2단계 제안일 수 있습니다.
-
0008 - 변환 페이로드가 SA 페이로드에 캡슐화되는 제안 페이로드에 캡슐화됩니다.
-
0010—KE(Key Exchange) 페이로드에는 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 - VID(Vendor ID) 페이로드는 1단계 협상의 어느 곳에나 포함될 수 있습니다. Junos OS는 NAT-T에 대한 지원을 표시하기 위해 이를 사용합니다.
각 ISAKMP 페이로드는 에 표시된 그림 2것과 동일한 일반 헤더로 시작합니다.
여러 ISAKMP 페이로드가 함께 연결될 수 있으며, 각 후속 페이로드 유형은 다음 헤더 필드의 값으로 표시됩니다. 값 0000 은 마지막 ISAKMP 페이로드를 나타냅니다. 예를 보려면 을(를) 참조하십시오 그림 3 .
IPsec 패킷 처리
IKE 협상이 완료되고 두 개의 IKE 게이트웨이가 1단계 및 2단계 보안 연결(SA)을 설정한 후, 모든 후속 패킷은 터널을 사용하여 전달됩니다. 2단계 SA가 터널 모드에서 ESP(Encapsulating Security Protocol)를 지정하는 경우 패킷은 에 그림 4표시된 것과 같습니다. 디바이스는 시작 호스트가 보내는 원래 패킷에 두 개의 추가 헤더를 추가합니다.
에서 그림 4볼 수 있듯이 시작 호스트가 구성하는 패킷에는 페이로드, TCP 헤더 및 내부 IP 헤더(IP1)가 포함됩니다.
Junos OS가 추가하는 라우터 IP 헤더(IP2)에는 대상 IP 주소로 원격 게이트웨이의 IP 주소를, 소스 IP 주소로 로컬 라우터의 IP 주소가 포함되어 있습니다. 또한 Junos OS는 외부 및 내부 IP 헤더 사이에 ESP 헤더를 추가합니다. ESP 헤더에는 원격 피어가 패킷을 수신할 때 패킷을 적절하게 처리할 수 있도록 하는 정보가 포함되어 있습니다. 이 내용은 에 나와 있습니다 그림 5.
다음 헤더 필드는 페이로드 필드의 데이터 유형을 나타냅니다. 터널 모드에서 이 값은 4로, IP 패킷이 페이로드 내에 포함되어 있음을 나타냅니다. 그림 6을(를) 참조하세요.
Junos OS의 IKE(Internet Key Exchange) 소개
IKE는 인터넷과 같은 보안되지 않은 매체를 통해 암호화 및 인증을 위한 키를 안전하게 교환할 수 있는 방법을 제공합니다. IKE(Internet Key Exchange)는 한 쌍의 보안 게이트웨이가 다음을 수행할 수 있도록 지원합니다. 보안 게이트웨이가 터널 및 키 정보를 교환할 수 있는 보안 터널을 동적으로 설정합니다. 터널 속성 협상 및 키 관리를 포함하여 사용자 수준 터널 또는 SA를 설정합니다. 이러한 터널은 동일한 보안 채널 위에서 새로 고침 및 종료할 수도 있습니다. IKE는 Diffie-Hellman 메서드를 사용하며 IPsec에서 선택 사항입니다(공유 키는 엔드포인트에서 수동으로 입력할 수 있음).
IKEv2는 다음에 대한 지원을 포함합니다.
경로 기반 VPN.
사이트 간 VPN.
Dead Peer Detection(데드 피어 탐지).
섀시 클러스터.
사전 공유 키 인증.
인증서 기반 인증.
하위 SA. IKEv2 하위 SA는 IKEv1에서 2단계 SA로 알려져 있습니다. IKEv2에서 하위 SA는 기본 IKE SA 없이 존재할 수 없습니다.
오토VPN.
동적 엔드포인트 VPN.
EAP는 IKEv2를 사용한 원격 액세스에 대해 지원됩니다.
트래픽 선택기.
IKEv2는 다음 기능을 지원하지 않습니다.
정책 기반 VPN.
VPN 모니터링
IP 페이로드 압축 프로토콜(IPComp).
Junos OS에서 IKEv2 구성
VPN 피어가 IKEv1 또는 IKEv2 중 하나로 구성되어 있습니다. 피어가 IKEv2로 구성된 경우 해당 원격 피어가 IKEv1 협상을 시작하면 피어가 IKEv1로 다시 이동할 수 없습니다. 기본적으로 주니퍼 네트웍스 보안 디바이스는 IKEv1 피어입니다.
version v2-only[edit security ike gateway gw-name] 계층 수준의 구성 문을 사용하여 IKEv2를 구성합니다.
IKE(Internet Key Exchange) 버전은 및 show security ipsec security-associations CLI 운영 명령의 출력에 show security ike security-associations 표시됩니다.
주니퍼 네트웍스 디바이스는 2단계 협상에 대해 최대 4개의 제안을 지원하므로 허용할 터널 매개 변수의 범위를 얼마나 제한할지 정의할 수 있습니다. Junos OS는 사정 정의된 표준의 호환 가능한 기본 2단계 제안 세트를 제공합니다. 또한 사용자 정의 2단계 제안을 정의할 수 있습니다.
IKEv2 구성 페이로드 이해
구성 페이로드는 응답기에서 이니시에이터로 프로비저닝 정보를 전파하기 위해 제공되는 IKEv2(Internet Key Exchange 버전 2) 옵션입니다. IKEv2 구성 페이로드는 루트 기반 VPN에서만 지원됩니다.
RFC 5996, IKEv2(Internet Key Exchange Protocol Version 2)는 응답자가 이니시에이터에 반환할 수 있는 15가지 구성 속성을 정의합니다. 표 1 은(는) SRX 시리즈 방화벽에서 지원되는 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 |
네트워크 내에서 WINS 서버와 같은 NBNS(NetBIOS 이름 서버)의 주소를 지정합니다. 여러 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(Internet Key Exchange) 게이트웨이에 바인딩됩니다.
Junos OS 릴리스 20.3R1부터 iked 프로세스를 실행하는 SPC3 및 vSRX 가상 방화벽SRX5000 라인에서 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추가 옵션. authentication-order(액세스 프로파일)를 참조하십시오. -
RADIUS 계정 시작 및 중지 메시지는 RADIUS 서버에 대한 터널 또는 피어의 상태를 알려줍니다. 이러한 메시지는 추적 목적이나 DHCP 서버와 같은 하위 시스템에 대한 알림에 사용할 수 있습니다.
RADIUS 서버가 어카운팅 시작 또는 중지 메시지를 지원하는지 확인합니다. 또한 SRX 시리즈 방화벽과 RADIUS 서버 모두에 이러한 메시지를 추적할 수 있는 적절한 설정이 있는지 확인합니다.
-
IPv6 지원을 도입하여 구성 페이로드를 사용하여 이중 스택 터널을 사용할 수 있습니다. 로그인 프로세스 중에 IKE는 IPv4 및 IPv6 주소를 모두 요청합니다. AAA는 요청된 모든 주소가 성공적으로 할당된 경우에만 로그인을 허용합니다. IKE는 요청된 IP가 할당되지 않은 경우 협상을 종료합니다.
경로 기반 VPN에서 보안 터널(st0) 인터페이스는 point-to-multipoint 또는 point-to-point 모드로 작동합니다. IKEv2 구성 페이로드를 통한 주소 할당은 이제 point-to-multipoint 또는 point-to-point 모드에서 지원됩니다. point-to-multipoint 인터페이스의 경우, 인터페이스에 번호를 매겨야 하며 구성 페이로드 INTERNAL_IP4_ADDRESS 속성 유형의 주소는 연결된 point-to-multipoint 인터페이스의 서브네트워크 범위 내에 있어야 합니다.
Junos OS 릴리스 20.1R1부터 IKE(Internet Key Exchange) 게이트웨이 구성의 IKEv2 구성 페이로드 요청에 대한 공통 암호를 구성할 수 있습니다. 1자에서 128자 사이의 공통 비밀번호를 사용하면 관리자가 공통 비밀번호를 정의할 수 있습니다. 이 암호는 SRX 시리즈 방화벽이 IKEv2 구성 페이로드를 사용하여 원격 IPsec 피어를 대신하여 IP 주소를 요청할 때 SRX 시리즈 방화벽과 RADIUS 서버 간에 사용됩니다. RADIUS 서버는 구성 페이로드 요청을 위해 SRX 시리즈 방화벽에 IP 정보를 제공하기 전에 자격 증명을 일치시킵니다. [edit security ike gateway gateway-name aaa access-profile access-profile-name] 계층 수준에서 구성 문을 사용하여 config-payload-password configured-password 공통 암호를 구성할 수 있습니다.
SRX 시리즈 방화벽과 RADIUS 서버 모두 동일한 비밀번호를 구성해야 하며, 인증 프로토콜로 PAP(Password Authentication Protocol)를 사용하도록 RADIUS 서버를 구성해야 합니다. 이렇게 하지 않으면 터널 설정이 성공하지 못합니다.
그림 7 은(는) IKEv2 구성 페이로드에 대한 일반적인 워크플로우를 보여줍니다.
IKEv2 구성 페이로드 기능은 포인트-투-멀티포인트 보안 터널(st0) 인터페이스와 포인트-투-포인트 인터페이스 모두에서 지원됩니다. 포인트-투-멀티포인트 인터페이스에는 번호가 매겨져야 하며, 구성 페이로드에 제공된 주소는 연결된 포인트-투-멀티포인트 인터페이스의 서브네트워크 범위 내에 있어야 합니다.
Junos OS 릴리스 20.1R1부터 SRX5000 라인 의 포인트 투 포인트 인터페이스와 iked를 실행하는 vSRX 가상 방화벽을 통해 IKEv2 구성 페이로드 기능을 지원합니다.
Pico 셀 프로비저닝 이해
IKEv2 구성 페이로드는 SRX 시리즈 방화벽과 같은 IKE 응답기에서 셀룰러 네트워크의 LTE 피코 셀 기지국과 같은 여러 이니시에이터로 프로비저닝 정보를 전파하는 데 사용할 수 있습니다. 피코 셀은 SRX 시리즈 방화벽에 연결할 수 있는 표준 구성으로 출고되지만, 피코 셀 프로비저닝 정보는 보호된 네트워크 내의 하나 이상의 프로비저닝 서버에 저장됩니다. 피코 셀은 프로비저닝 서버와의 보안 연결을 설정한 후 전체 프로비저닝 정보를 받습니다.
피코 셀을 부트스트랩 및 프로비저닝하고 서비스에 도입하는 데 필요한 워크플로우에는 다음과 같은 네 가지 단계가 포함됩니다.
-
초기 주소 획득 - pico 셀은 다음 정보와 함께 공장에서 배송됩니다.
-
SRX 시리즈 방화벽에 대한 보안 게이트웨이 터널 구성
-
제조업체에서 발급한 디지털 인증서
-
보호된 네트워크 내에 있는 프로비저닝 서버의 FQDN(정규화된 도메인 이름)
피코 셀이 부팅되고 DHCP 서버에서 IKE 협상에 사용할 주소를 획득합니다 . 그런 다음 이 주소를 사용하여 SRX 시리즈 방화벽의 보안 게이트웨이에 터널이 구축됩니다. OAM(Operation, Administration, and Management) 트래픽에 대한 주소도 DHCP 서버에 의해 할당되어 보호된 네트워크에서 사용할 수 있습니다.
-
피코 셀 프로비저닝 - 할당된 OAM 트래픽 주소를 사용하여 피코 셀은 보호된 네트워크 내의 서버에서 프로비저닝 정보(일반적으로 운영자 인증서, 라이센스, 소프트웨어 및 구성 정보)를 요청합니다.
재부팅 - 피코 셀이 재부팅되고 획득한 프로비저닝 정보를 사용하여 서비스 프로바이더의 네트워크 및 운영 모델에 맞게 만듭니다.
-
서비스 프로비저닝 - 피코 셀이 서비스에 들어가면 FQDN과 함께 고유 이름(DN) 및 주체 대체 이름 값이 포함된 단일 인증서를 사용하여 SRX 시리즈 방화벽의 보안 게이트웨이에 대한 터널 2개를 구축합니다. 하나는 OAM 트래픽용이고 다른 하나는 3GPP(Third-Generation Partnership Project) 데이터 트래픽용입니다.
참조
IKE(Internet Key Exchange) 제안
IKE 구성은 피어 보안 게이트웨이와의 보안 IKE 연결을 설정하는 데 사용되는 알고리즘과 키를 정의합니다. 하나 이상의 IKE(Internet Key Exchange) 제안을 구성할 수 있습니다. 각 제안은 IKE(Internet Key Exchange) 호스트와 피어 간의 IKE(Internet Key Exchange) 연결을 보호하기 위한 IKE 속성 목록입니다.
IKE(Internet Key Exchange) 제안을 구성하려면 문을 포함하고 proposal [edit security ike ] 계층 수준에서 이름을 지정합니다.
IKE(Internet Key Exchange) 정책
IKE 정책은 IKE 협상 중에 사용할 보안 매개 변수(IKE 제안)의 조합을 정의합니다. 피어 주소와 해당 연결에 필요한 제안을 정의합니다. 사용되는 인증 방법에 따라 지정된 피어 또는 로컬 인증서에 대한 사전 공유 키를 정의합니다. IKE 협상 중에 IKE는 두 피어에서 동일한 IKE 정책을 찾습니다. 협상을 시작한 피어는 모든 정책을 원격 피어에 전송하고 원격 피어는 일치하는 항목을 찾으려고 시도합니다. 두 피어의 두 정책에 동일한 구성 속성이 포함된 제안이 있으면 일치가 이루어집니다. 수명이 동일하지 않으면 두 정책(호스트와 피어) 간의 더 짧은 수명이 사용됩니다. 구성된 사전 공유 키도 피어와 일치해야 합니다.
먼저 하나 이상의 IKE(Internet Key Exchange) 제안을 구성합니다. 그런 다음 이러한 제안을 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)
SRX5400, SRX5600 및 SRX5800 디바이스를 위한 액티브-액티브 및 액티브-패시브 모드의 섀시 클러스터
SRX5400, SRX5600 및 SRX5800 디바이스의 ISSU(In-Service Software Upgrade)
ISHU(In-Service Hardware Upgrade) 절차를 사용하여 새 SPU(Services Processing Unit)의 업그레이드 또는 삽입
제한
IKEv2 재인증을 사용할 때 다음 사항에 유의하십시오.
NAT-T를 사용하면 이전 IKE(Internet Key Exchange) SA와 다른 포트로 새 IKE(Internet Key Exchange) 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(확장할 수 있는 인증 프로토콜) 인증 및 구성 페이로드를 사용하려면 원래 IKE SA와 동일한 당사자가 IKE SA를 시작해야 하므로 EAP 인증 또는 구성 페이로드에서는 재인증이 지원되지 않습니다.
IKE(Internet Key Exchange) 인증(인증서 기반 인증)
인증서 인증을 위한 Multilevel Hierarchy
인증서 기반 인증은 IKE 협상 중에 SRX 시리즈 방화벽에서 지원되는 인증 방법입니다. 대규모 네트워크에서는 여러 CA(인증 기관)가 각각의 최종 디바이스에 EE(End Entity) 인증서를 발급할 수 있습니다. 개별 위치, 부서 또는 조직에 대해 별도의 CA를 갖는 것이 일반적입니다.
인증서 기반 인증을 위한 단일 수준 계층을 사용하는 경우 네트워크의 모든 EE 인증서는 동일한 CA에서 서명해야 합니다. 모든 방화벽 디바이스에는 피어 인증서 유효성 검사를 위해 등록된 것과 동일한 CA 인증서가 있어야 합니다. IKE 협상 중에 전송된 인증서 페이로드에는 EE 인증서만 포함됩니다.
또는 IKE 협상 중에 전송된 인증서 페이로드에 EE 및 CA 인증서 체인이 포함될 수 있습니다. 인증서 체인은 피어의 EE 인증서를 검증하는 데 필요한 인증서 목록입니다. 인증서 체인에는 EE 인증서 및 로컬 피어에 없는 모든 CA 인증서가 포함됩니다.
네트워크 관리자는 IKE 협상에 참여하는 모든 피어가 각각의 인증서 체인에 하나 이상의 신뢰할 수 있는 공통 CA를 가지고 있는지 확인해야 합니다. 신뢰할 수 있는 공통 CA가 루트 CA일 필요는 없습니다. EE에 대한 인증서와 체인의 최상위 CA를 포함하여 체인의 인증서 수는 10개를 초과할 수 없습니다.
Junos OS 릴리스 18.1R1부터 지정된 CA 서버 또는 CA 서버 그룹을 사용하여 구성된 IKE 피어의 검증을 수행할 수 있습니다. 인증서 체인을 사용하면 루트 CA가 IKE(Internet Key Exchange) 정책에 구성된 신뢰할 수 있는 CA 그룹 또는 CA 서버와 일치해야 합니다
에 그림 8표시된 CA 계층 예시에서 Root-CA는 네트워크의 모든 디바이스에 대한 공통의 신뢰할 수 있는 CA입니다. Root-CA는 각각 Eng-CA 및 Sales-CA로 식별되는 엔지니어링 및 영업 CA에 CA 인증서를 발급합니다. Eng-CA는 각각 Dev-CA 및 Qa-CA로 식별되는 개발 및 품질 보증 CA에 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(단순 인증서 등록 프로세스)를 사용하여 등록할 수 있습니다.
각 최종 디바이스는 인증서 체인의 각 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/”;
}
}
}참조
디도스(DDoS) 공격으로부터 IKE 보호
DoS(Denial of service)는 안전하지 않은 IPsec VPN 네트워크에서 가장 흔하지만 심각한 공격 중 하나입니다. DoS 공격은 네트워크 인프라에서 많은 발판을 마련할 필요가 없기 때문에 네트워크를 장악할 수 있는 빠르고 쉬운 방법을 제공합니다. CYber공격자는 네트워크를 제어하기 위해 이 방법을 선택합니다.
DoS 공격은 어떻게 되나요?
공격자는 너무 많은 트래픽으로 네트워크를 플러딩하고 점진적으로 충돌시켜 네트워크 리소스를 고갈시키고 메모리 및 CPU와 같은 디바이스 리소스를 추가로 제어하려고 합니다. 공격자가 여러 오케스트레이션된 시스템을 사용하여 제어하려고 시도하고 단일 대상을 동기적으로 공격하는 것을 DDoS(Distributed DoS) 공격이라고 합니다.
IKE 구현의 디도스(DDoS) 공격 취약성
원격 피어(개시자)가 SA_INIT 메시지를 전송하면 로컬 피어(응답자)가 응답하고 메시지 구조에 대한 메모리를 할당합니다. IKE_AUTH 메시지의 도움으로 인증이 수행될 때까지 세션을 반쯤 열린 IKE 세션이라고 합니다. 피어가 IKE(Internet Key Exchange) 보안 연결(SA)을 설정하면 세션은 완전히 열린 IKE(Internet Key Exchange) 세션이 됩니다 .
IKEv2 DDoS 취약점을 이해하기 위해 공격자가 IKE SA에 대한 쉬운 공격 벡터를 만들 수 있는 몇 가지 방법을 살펴보겠습니다.
-
공격자가 반쯤 열린 IKE 보안 연결 구조를 만들 수 있는 대량의SA_INIT 메시지(IKE_AUTH 메시지 없이)를 보냅니다. 이 공격 으로 인해 디바이스가 리소스를 활용하고 메모리가 부족해집니다.
-
개시자와 응답자에 각각 올바른 SPI_i와 SPI_r 있는 많은 수의 정크 IKE_AUTH 패킷을 보냅니다. 패킷의 암호를 해독하는 동안 디바이스의 메모리가 부족합니다.
-
SA_INIT 패킷을 지속적으로 전송합니다. 암호화된 패킷에 대한 키를 생성하려고 시도하는 동안 디바이스의 메모리가 부족합니다.
-
완전히 열려 있는 IKE(Internet Key Exchange) 세션 중에 초당 많은 수의 키 재입력 요청을 보냅니다.
-
고유한 메시지 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 SA의 구성을 허용하지 않습니다. 응답자가 타임아웃 기간에 도달할 때까지 SA를 구성하지 않도록 이 제한을 설정할 수 있습니다. 자세한 내용은 옵션을
timeout참조하십시오 session (Security IKE) . -
응답자에 대해 허용되는 최대 절반 개방 IKE(Half-Open IKE) SA에 대한 제한을 설정할 수 있습니다. 반쯤 열린 IKE SA의 총 수가 최대 수에 도달하면응답자는 IKEv1 및 IKEv2 SA 모두에 대한 새 연결을 거부합니다. 자세한 내용은 의session (Security IKE) 옵션을 참조하십시오.
max-count -
응답자는 반개방 IKE(Internet Key Exchange) SA의 세션 수에 임계값을 적용합니다. 반쯤 열린 IKE(Internet Key Exchange) SA의 총 수가 임계값 에 도달하면다음을 수행합니다.
-
IKEv2 SA의 경우 응답자는 모든 새 연결에 대해 쿠키 메커니즘을 호출합니다.
-
IKEv1 SA의 경우 응답자는 새 연결을 거부합니다.
자세한 내용은 의 , 및 옵션을 참조하십시오
thresholds.reduce-timeoutsend-cookiesession (Security IKE) -
-
응답자는 중복 세션을 삭제할 수 있습니다. 자세한 내용은 의 session (Security IKE)옵션을 참조하십시오.
discard-duplicate -
인증 실패 및 시작 실패 단계에 대한 백오프 시간 제한을 설정할 수 있습니다. 자세한 내용은 옵션
backoff-timeouts및init-phase-failureauth-phase-failure을 참조하십시오session (Security IKE).
-
-
완전히 열려 있는 IKE(Internet Key Exchange) SA의 경우:
-
최대 수신 키 재입력 요청 속도를 구성하여 확장된 시나리오에서 요청을 제한할 수 있습니다. 자세한 내용은 의 옵션을 참조하십시오
incoming-exchange-max-rates.session (Security IKE)
-
-
응답자는 피어 IKE(Internet Key Exchange) ID를 기반으로 피어로부터 들어오는 IKE 세션을 차단할 수 있습니다. 자세한 내용은 을 참조하십시오blocklists (Security IKE).
-
동적 게이트웨이의 경우 옵션을
connections-limit사용하여 IKE(Internet Key Exchange) 게이트웨이 구성 수준에서 연결 수에 대한 제한을 설정할 수 있습니다. 자세한 내용은 게이트웨이(보안 IKE)를 참조하십시오.
이러한 옵션을 구성하는 방법에 대한 자세한 내용은 IKE(Internet Key Exchange) DDoS 공격에 대한 보호 구성을 참조하십시오.
다음을 지원하지 않습니다.
-
kmd 프로세스 기반의 IPsec VPN 서비스를 통한 디도스(DDoS) 공격 방어.
-
이러한 인코딩 유형을 지원하지 않으므로 해시 및 URL 인증서 인코딩 공격으로부터 보호합니다.
디도스(DDoS) 공격 모니터링 방법
디도스(DDoS) 공격을 모니터링하기 위해 다음과 같은 메커니즘을 제공합니다.
-
show security ike security-associations명령을 사용하여 모든 성숙 및 성숙되지 않은 IKE 보안 연결을나열합니다. 자세한 내용은 보안 ike 보안 연관 표시를 참조하세요. -
show security ike stats명령을 사용하여 진행 중, 설정, 만료 통계와 같은 IPsec VPN 터널의 글로벌 IKE 통계를 표시합니다. 자세한 내용은 보안 ike 통계 표시를 참조하세요. -
show security ike active-peer명령을 사용하여 원격 피어와의 성공적인 IKE(Internet Key Exchange) 협상에 대한 세부 정보를 표시합니다. 자세한 내용은 보안 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(Internet Key Exchange) 피어를 지웁니다. 자세한 내용은 을 참조하십시오 clear security ike peers. -
추가 통신을 차단해야 하는 피어와의 기존 IKE 보안 연결을 삭제하려면 명령을 사용합니다
clear security ike security-associations. 자세한 내용은 보안 ike 보안 연결 지우기를 참조하세요. -
iked system log(syslog) 메시지 IKE_GATEWAY_PEER_BLOCKED, IKE_GATEWAY_PEER_BACKOFF 및 IKE_GATEWAY_PEER_FAILED은 원격 피어와의 차단, 백오프 및 실패한 IKE 협상에 대한 세부 정보를 각각 제공합니다.
-
추가 보안을 위해 Junos OS는 필터링, 세션 수 및 속도 제한과 같은 패킷 기반 시스템 공격으로부터 보호하기 위한 서비스를 사용자에게 제공합니다. 자세한 내용은 [] 계층 수준에서 show firewall 명령 및 ids-option 문을
edit security screen ids-option screen-name참조하십시오.
IKE(Internet Key Exchange) 디도스(DDoS) 공격에 대한 보호 구성
SUMMARY IKE(Internet Key Exchange) 프로토콜에 대한 디도스(DDoS) 공격에 대한 보호를 구성하는 방법을 이해하려면 이 섹션을 참조하십시오.
전제 조건
IKE(Internet Key Exchange) 디도스(DDoS) 공격에 대한 보호를 구성하기 전에 다음 전제 조건을 충족하는지 확인하십시오.
-
SRX 시리즈 방화벽은 iked 프로세스를 사용하여 IPsec VPN 서비스를 실행하기 위한 패키지를 지원합니다
junos-ike. -
로컬 엔드포인트(응답자) 역할을 하는 SRX 시리즈 방화벽은 원격 IKE 피어(개시자)에 연결할 수 있습니다.
-
IKE 차단 목록을 연결할 수 있는 IKE 정책.
IKE(Internet Key Exchange) DDoS 공격에 대한 보호를 구성하기 위한 작업은 다음과 같습니다.
-
들어오는 절반 개방형 IKE SA를 관리합니다.
-
들어오는 완전 개방형 IKE(Internet Key Exchange) SA를 관리합니다.
-
다양한 피어에서 들어오는 IKE 세션을 차단하고 차단 목록 중 하나를 IKE 피어와 연결하려면 여러 차단 방법을 구성합니다.
이러한 작업을 구성하려면 다음 작업을 참조하십시오.
- 절반이 열린 IKE(Internet Key Exchange) SA에 대한 IKE 세션 구성
- 완전히 열려 있는 IKE(Internet Key Exchange) SA에 대한 IKE 세션 구성
- IKE(Internet Key Exchange) 세션 차단 목록 구성
절반이 열린 IKE(Internet Key Exchange) SA에 대한 IKE 세션 구성
개요
위에서 설명한 모든 필수 구성 요소를 충족하는지 확인합니다.
이 섹션에서는 절반이 열려 있는 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 세션 수를 설정합니다. 지정하지 않으면 기본값은 300입니다. 구성은 모든 임계값을
max-count비활성화합니다. 이러한 경우, 이를 적용하기 위해 임계값을 명시적으로 구성해야 합니다. -
응답자의 세션 수가 제한에 도달할 때 옵션을
threshold사용하여 다양한 유형의 작업을 지정합니다.-
옵션을
send-cookie count사용하여 쿠키 작업을 적용하기 위해 열린 IKE 세션의 절반 미만 수를 설정하려면:[edit] user@host# set security ike session half-open threshold send-cookie 500
이는 응답자가 초기 응답에서 피어로 다시 전송된 쿠키를 사용하여 세션 시작을 재시도하도록 원격 피어에 요청하는 임계값 제한을 지정합니다. 여기서 절반이 열린 IKE 세션 수 제한이 500에 도달하면 iked 프로세스는 새 IKE 세션에 대한 쿠키 메커니즘을 사용합니다.
-
옵션을
reduced-timeout count timeout seconds사용하여 시간 초과 작업을 줄이기 위해 절반 열린 IKE 세션의 최소 수를 설정하려면 다음을 수행합니다.[edit] user@host# set security ike session half-open threshold reduce-timeout 600 timeout 100
이는 iked 프로세스가 새로운 절반 개방 IKE SA의 수명을 줄이는 한계를 지정합니다. 반쯤 열린 응답자 IKE 세션 수가 임계값 아래로 감소하면 반쯤 열린 응답자 IKE 세션은 기본 시간 제한 값을 다시 사용합니다.
-
-
이니시에이터에 응답을 다시 보내지 않고 중복된 절반 열린 IKE 세션을 삭제하기 위해 옵션을
discard-duplicate설정하려면 다음을 수행합니다.[edit] user@host# set security ike session half-open discard-duplicate
협상이 진행되는 동안 IKE(Internet Key Exchange) SA가 없는 다른 개시자 쿠키를 사용하여 동일한 피어에서 오는 중복 세션 시작 요청(SA_INIT)의 경우 응답자는 패킷을 삭제합니다.
-
옵션을 사용하여 백오프 시간 제한을 설정할 수 있습니다
backoff-timeouts.이렇게 하면 세션 시작 실패 시 원격 피어가 물러날 수 있는 시간이 주어지며, 동일한 피어가 해당 기간 동안 새 세션을 시작할 수 없습니다. 백오프 시간 초과 후 피어는 새 세션을 시작할 수 있습니다. 세션 시작은 초기화 단계와 인증 단계의 두 단계에서 실패할 수 있습니다.
-
옵션을
backoff-timeouts auth-phase-failure value사용하여 IKE_AUTH 단계에서 오류가 발생할 때 백오프 시간 제한을 설정하려면 다음을 수행합니다.[edit] user@host# set security ike session half-open backoff-timeouts auth-phase-failure 150
을 구성할
auth-phase-failure때 차단 목록에 있는 모든 원격 피어는 대상 차단 목록 규칙에 대한 작업으로 백오프를 구성하지 않더라도 백오프됩니다. 백오프에 대한 시간 제한은 에 대해auth-phase-failure구성된 시간입니다. 이 예에서 디바이스는 150초 후에 새 세션을 시작합니다. 특정 규칙에 대한 이 백오프 시간 제한을 덮어쓰려면backoff[ruleedit security ike blocklists blocklist1 rule rule-name then backoff timeout-value] hierarchy level. -
옵션을
backoff-timeouts init-phase-failure value사용하여 SA_INIT 단계에서 오류가 발생할 때 백오프 시간 제한을 설정하려면 다음을 수행합니다.[edit] user@host# set security ike session half-open backoff-timeouts init-phase-failure 160
이 예에서 디바이스는 160초 후에 새 세션을 시작합니다.
-
옵션을
timeout seconds사용하여 응답자 수명 매개 변수를 설정하려면:[edit] user@host# set security ike session half-open timeout 150
이 기간 동안 응답자는 타임아웃 기간에 도달할 때까지 절반이 열린 IKE(Internet Key Exchange) SA의 구성을 허용하지 않습니다. 개시자는 응답자의 구성과 관계없이 60초의 시간 초과 기간을 계속 가질 수 있습니다.
-
완전히 열려 있는 IKE(Internet Key Exchange) SA에 대한 IKE 세션 구성
개요
위에서 설명한 모든 필수 구성 요소를 충족하는지 확인합니다.
이 섹션에서는 [edit security ike session full-open] 계층 수준의 옵션을 incoming-exchange-max-rates 사용하여 전체 개방형 IKE(Internet Key Exchange) SA에 대해 다양한 수신 요청 속도를 구성하는 방법을 알아봅니다.
구성
incoming-exchange-max-rates 옵션을 구성하여 IKE(Internet Key Exchange) SA를 설정한 후 원격 피어에 의해 개시되는 다양한 교환에 대한 최대 속도를 설정합니다. 세 가지 유형의 환율, 즉 IKE(Internet Key Rekey), IPsec 키 재생성(IPsec rekey) 및 keepalive(Dead Peer Detection이라고도 함)를 구성할 수 있습니다.
-
옵션을
incoming-exchange-max-rates ike-rekey value사용하여 수신 피어 시작 IKE 키 재입력 최대 속도를 설정하려면 다음을 수행합니다.[edit] user@host# set security ike session full-open incoming-exchange-max-rates ike-rekey 200/60
이 옵션은 IKE SA가 이미 있는 기존 피어를 사용하여 피어별로 IKEv2 키 재생성에 적용할 수 있습니다.
-
옵션을
incoming-exchange-max-rates ipsec-rekey value사용하여 수신 피어 시작 IPsec SA 키 재입력 최대 속도를 설정하려면 다음을 수행합니다.[edit] user@host# set security ike session full-open incoming-exchange-max-rates ipsec-rekey 100/60
이 제한은 터널별로 적용됩니다.
-
옵션을
incoming-exchange-max-rates keepalive value사용하여 수신 피어 시작 keepalive 최대 속도를 설정하려면:[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(Internet Key Exchange) 세션을 차단하려면 하나 이상의 차단 목록을 구성해야 합니다. 각 차단 목록에는 하나 이상의 규칙이 포함되어 있습니다. 각 규칙에는 일치 기준과 작업이 있습니다.
차단 목록을 구성할 때 다음 기준을 고려하십시오.
-
차단 목록 규칙은 협상 중인 새 IKE SA에 적용되며 기존 IKE SA에는 영향을 주지 않습니다. 피어 인증 단계에서 디바이스는 차단 목록 규칙을 적용합니다.
-
규칙의 적용 순서는 이러한 규칙이 나열되는 순서에 따라 달라집니다.
-
역할(개시자 또는 응답자), ID 유형(IPv4 또는 IPv6 주소, 호스트 이름, 고유 이름, 이메일 ID 또는 키 ID) 및 IKE(Internet Key Exchange) ID와 일치하는 정규식인 ID 패턴을 기반으로 일치 기준을 구성합니다.
-
ID 유형으로 각 규칙을 구성할 수 있습니다. 이를 통해 동일한 차단 목록 내에서 다른 규칙에 대해 다른 IKE ID를 구성할 수 있습니다.
-
피어 연결을 폐기하거나 거부하는 작업을 구성합니다. 일치 항목에 따라 디바이스는 작업을 적용합니다. 선택적으로 이러한 작업으로 백오프 타이머를 설정할 수 있습니다.
-
IKE(Internet Key Exchange) 게이트웨이와 연결된 IKE(Internet Key Exchange) 정책의 차단 목록을 참조하십시오.
-
각 IKE(Internet Key Exchange) 게이트웨이 는 한 가지 유형의 원격 IKE(Internet Key Exchange) ID 유형만 지원합니다. 차단 목록을 게이트웨이에 연결하고 다른 IKE ID를 포함하는 규칙으로 구성하는 경우 게이트웨이는 IKE ID 유형이 IKE 게이트웨이에 대해 구성된 것과 동일한 규칙만 적용되고 일치합니다.
-
IKE(Internet Key Exchange) 게이트웨이에 연결된 차단 목록이 있는 터널 설정 속도 메트릭은 차단 목록에 구성된 규칙 수를 기반으로 합니다.
이 섹션에서는 차단 목록을 구성하고 차단 목록을 IKE 정책에 연결하는 방법을 알아봅니다.
구성
-
여러 규칙이 있는 차단 목록을 생성하려면 다음을 수행합니다.
-
차단 목록을 만듭니다.
[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(Internet Key Exchange) 협상 중에 피어 디바이스를 검증하는 데 사용되는 인증서 체인에 대한 디바이스를 구성하는 방법을 보여줍니다.
요구 사항
시작하기 전에 인증 기관(CA)의 주소와 로컬 인증서에 대한 요청을 제출할 때 필요한 정보(예: 인증 확인 비밀번호)를 확인하십시오.
개요
이 예는 인증서 체인에 대한 로컬 디바이스를 구성하고, CA 및 로컬 인증서를 등록하고, 등록된 인증서의 유효성을 확인하고, 피어 디바이스의 해지 상태를 확인하는 방법을 보여줍니다.
토폴로지
이 예에서는 에 표시된 그림 9대로 Host-A의 구성 및 운영 명령을 보여 줍니다. Host-A가 Sales-CA에서 CRL을 다운로드하고 Host-B 인증서의 해지 상태를 확인할 수 있도록 Host-A에 동적 CA 프로필이 자동으로 생성됩니다.
1단계 및 2단계 협상을 위한 IPsec VPN 구성은 이 예에서 Host-A에 대해 표시됩니다. 피어 디바이스(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
결과
구성 모드에서 show security ike 및 show security ipsec 명령을 입력하여 구성을 확인합니다. 출력이 의도된 구성을 표시하지 않으면, 이 예의 구성 지침을 반복하여 수정합니다.
[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(Security Association)가 모두 설정됩니다.
인증서가 유효하면 IKE(Internet Key Exchange) SA가 작동 중입니다. 인증서가 해지되면 IKE SA가 DOWN이고 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 프로필에서 옵션을 구성해야 합니다.
솔루션
피어 인증서의 해지 상태를 확인하려면 다음을 수행합니다.
운영 모드에서 명령을 입력하여 show security pki crl 피어 디바이스에 대한 CRL을 표시할 동적 CA 프로필을 식별합니다.
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 UTC호스트-B의 인증서(일련 번호 10647084)가 해지되었습니다.
IKEv2 단편화
메시지 조각화
RFC 7383, IKEv2(Internet Key Exchange Protocol Version 2) 메시지 단편화에 설명된 바와 같이 IKEv2 메시지 단편화를 사용하면 IP 조각이 차단되고 피어가 SA(IPsec Security Association)를 설정할 수 없는 환경에서 IKEv2가 작동할 수 있습니다. IKEv2 단편화는 큰 IKEv2 메시지를 일련의 작은 메시지로 분할하여 IP 수준에서 단편화가 발생하지 않도록 합니다. 단편화는 원래 메시지가 암호화되고 인증되기 전에 수행되므로 각 조각이 별도로 암호화되고 인증됩니다. 수신기에서 조각은 수집, 확인, 해독 및 원본 메시지로 병합됩니다.
IKEv2 단편화가 발생하려면 두 VPN 피어 모두 IKE_SA_INIT 교환에 IKEV2_FRAGMENTATION_SUPPORTED 알림 페이로드를 포함하여 단편화 지원을 나타내 야 합니다 . 두 피어가 모두 단편화 지원을 나타내는 경우 IKEv2 단편화가 사용되는지 여부를 결정하는 것은 메시지 교환의 개시자에게 달려 있습니다.
SRX 시리즈 방화벽에서는 IKEv2 메시지당 최대 32개의 프래그먼트가 허용됩니다. 보내거나 받을 IKEv2 메시지 조각의 수가 32개를 초과하면 조각이 삭제되고 터널이 설정되지 않습니다. 개별 메시지 조각의 재전송은 지원되지 않습니다
구성
SRX 시리즈 방화벽에서 IPv4 및 IPv6 메시지에 대해 IKEv2 단편화가 기본적으로 활성화됩니다. 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입니다.
참조
신뢰할 수 있는 CA의 IKE(Internet Key Exchange) 정책
이 예에서는 신뢰할 수 있는 CA 서버를 피어의 IKE 정책에 바인딩하는 방법을 보여 줍니다.
시작하기 전에 피어의 IKE 정책과 연결할 모든 신뢰할 수 있는 CA 목록이 있어야 합니다.
IKE(Internet Key Exchange) 정책을 신뢰할 수 있는 단일 CA 프로필 또는 신뢰할 수 있는 CA 그룹에 연결할 수 있습니다. 보안 연결 설정을 위해 IKE 게이트웨이는 IKE 정책을 사용하여 인증서의 유효성을 검증하는 동안 구성된 CA 그룹(ca-profiles)으로 자신을 제한합니다. 신뢰할 수 있는 CA 또는 신뢰할 수 있는 CA 그룹 이외의 소스에서 발행한 인증서의 유효성이 검사되지 않습니다. IKE 정책에서 인증서 유효성 검사 요청이 있는 경우 IKE 정책의 연결된 CA 프로필이 인증서의 유효성을 검사합니다. IKE 정책이 CA와 연결되어 있지 않은 경우 기본적으로 구성된 CA 프로필 중 하나에 의해 인증서의 유효성이 검사됩니다.
이 예에서는 라는 root-ca CA 프로필이 생성되고 이(가 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 ike_policy (Internet Key Exchange) 정책 아래에 CA 프로필 그룹을 표시하고 IKE(Internet Key Exchange) 정책과 연결된 인증서를 표시합니다.
참조
IKE에서 Establish-Tunnel Responder-only 구성
이 주제는 IKE(Internet Key Exchange)에서 establish-tunnels responder-only를 구성하는 방법을 보여줍니다. 원격 피어에서 터널을 시작하고 모든 터널을 통해 트래픽을 보냅니다. IKE(Internet Key Exchange)가 활성화되는 시기를 지정합니다.
Junos OS 릴리스 19.1R1부터 SRX5000 라인에서 establish tunnels 옵션은 계층 수준에서 및 responder-only-no-rekey 값을 [edit security ipsec vpn vpn-name] 지원합니다responder-only.
responder-only 및 responder-only-no-rekey 옵션은 이(가) 설치된 경우에만 SPC3 카드가 있는 SRX5000 라인에서 junos-ike-package 지원됩니다. 이러한 옵션은 사이트 간 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에서 establish-tunnel responder-only 구성하기:
변경 내역 표
기능 지원은 사용 중인 플랫폼과 릴리스에 따라 결정됩니다. Feature Explorer 를 사용하여 플랫폼에서 기능이 지원되는지 확인하세요.