VPN 모니터링 방법

IPsec 데이터 경로 검증이 필요한 이유는 무엇입니까?

경로 기반 VPN의 경우 포인트 투 포인트 모드에서 보안 터널(st0) 인터페이스의 상태는 일반적으로 VPN 터널의 상태를 기반으로 합니다. 디바이스가 IPsec 보안 연결(SA)을 설정한 후, Junos OS는 st0 인터페이스와 연결된 경로를 포워딩 테이블에 추가합니다. 네트워크에 VPN 터널 엔드포인트 사이에 전송 방화벽이 있는 경우 방화벽은 st0 인터페이스에서 활성 경로를 사용하는 IPsec 데이터 트래픽을 차단할 수 있습니다. 그 결과 트래픽 손실이 발생할 수 있습니다.

이러한 트래픽 손실을 방지하려면 IPsec 데이터 경로 검증을 사용하도록 설정해야 합니다. 이 기능을 활성화하면 Junos OS 디바이스가 데이터 경로를 확인할 때까지 st0 인터페이스를 불러오지 않습니다. 다음 옵션으로 데이터 경로 확인을 구성할 수 있습니다:

• 경로 기반 및 사이트 간 VPN 터널에 대한 문을 [set security ipsec vpn vpn-name vpn-monitor verify-path] 사용하여 구성할 수 있습니다.

• 피어 터널 엔드포인트 앞에 네트워크 주소 변환(NAT) 디바이스가 있는 경우 방화벽은 피어 터널 엔드포인트의 IP 주소를 네트워크 주소 변환(NAT) 디바이스의 IP 주소로 변환합니다. VPN 모니터 ICMP 요청이 피어 터널 엔드포인트에 도달하려면 네트워크 주소 변환(NAT) 디바이스 뒤에 있는 피어 터널 엔드포인트의 변환되지 않은 원래 IP 주소를 명시적으로 지정해야 합니다. 구성 문으로 [set security ipsec vpn vpn-name vpn-monitor verify-path destination-ip] 구성할 수 있습니다.

• st0 인터페이스가 불러오기 전에 IPsec 데이터 경로를 확인하는 데 사용되는 패킷의 크기를 구성할 수 있습니다. 구성 문을 사용합니다 [set security ipsec vpn vpn-name vpn-monitor verify-path packet-size] . 구성 가능한 패킷 크기는 64바이트에서 1350바이트까지입니다. 기본값은 64바이트입니다.

IPsec 데이터 경로 검증을 사용할 때 다음 사항을 고려하십시오.

• VPN 모니터링 작업을 위해 구성하는 소스 인터페이스 및 대상 IP 주소는 IPsec 데이터 경로 검증에 아무런 영향을 미치지 않습니다. IPsec datapath 검증에서 ICMP 요청의 소스는 로컬 터널 엔드포인트입니다.

• IPsec 데이터 경로 검증을 활성화하면 Junos OS는 st0 인터페이스가 가동된 후에만 VPN 모니터링을 자동으로 활성화합니다. IPsec datapath 검증을 활성화할 때 계층 수준에서 [edit security ipsec vpn vpn-name] 옵션을 구성 vpn-monitor optimized 하는 것이 좋습니다.

• IPsec datapath 확인 중에 섀시 클러스터 장애 조치가 발생하면 새로운 활성 노드가 다시 확인을 시작합니다. Junos OS는 검증이 성공할 때까지 st0 인터페이스를 활성화하지 않습니다.

• IPsec SA 키 재입력의 경우, Junos OS는 IPsec 데이터 경로 확인을 수행하지 않습니다. 이는 키 재입력에 대해 st0 인터페이스 상태가 변경되지 않기 때문입니다.

• Junos OS는 AutoVPN, ADVPN(Auto Discovery VPN) 및 여러 트래픽 선택기와 함께 사용되는 point-to-multipoint 모드에서 st0 인터페이스에 대한 IPsec 데이터 경로 확인을 지원하지 않습니다.

• VPN 모니터링 및 IPsec 데이터 경로 확인은 IPv6 주소를 지원하지 않습니다. 따라서 IPv6 터널에는 IPsec 데이터 경로 검증을 사용할 수 없습니다.

IPsec 데이터 경로 검증은 어떻게 작동합니까?

IPsec datapath 검증을 구성할 때 다음 이벤트가 발생합니다.

1. 디바이스가 VPN 터널을 설정한 후 IPSec 데이터 경로를 확인하기 위해 피어 터널 엔드포인트에 ICMP 요청을 보냅니다. 피어 터널 엔드포인트는 VPN 모니터 ICMP 요청이 도달할 수 있어야 하며 ICMP 요청에 응답할 수 있어야 합니다. 데이터 경로 확인이 진행되는 동안 명령 출력의 show security ipsec security-association detail VPN 모니터링 필드에 문자 V가 표시됩니다.

2. Junos OS는 피어로부터 응답을 수신할 때만 st0 인터페이스를 활성화합니다. 명령 출력은 show interface st0.x datapath 검증 도중 및 이후에 st0 인터페이스 상태를 보여줍니다: 검증이 완료되기 전에는 Link-Layer-Down, 검증이 성공적으로 완료된 후에는 Up입니다.

3. 피어가 ICMP 응답을 보내지 않으면 디바이스는 구성된 VPN 모니터 임계값에 도달할 때까지 구성된 VPN 모니터 간격으로 다른 ICMP 요청을 보냅니다. 기본 VPN 모니터 간격은 10초이고 기본 VPN 모니터 임계값은 10배입니다. 검증에 성공하지 못하면 KMD_VPN_DOWN_ALARM_USER 시스템 로그 항목에 VPN 모니터링 verify-path 오류로 이유가 표시됩니다. 디바이스는 명령 출력의 터널 이벤트 아래에 오류를 기록합니다.show security ipsec security-association detail 명령은 show security ipsec tunnel-events-statistics 오류가 발생한 횟수를 표시합니다. [edit security ipsec] 계층 수준에서 구성 옵션을 사용하여 vpn-monitor-options VPN 모니터 간격 및 VPN 모니터 임계값을 구성할 수 있습니다.

4. 피어가 VPN 모니터 임계값에 도달한 후에도 ICMP 응답을 보내지 않으면 Junos OS는 VPN 터널을 중단하고 VPN 터널을 재협상합니다.

DPD는 어떻게 작동합니까?

IPsec 터널을 생성하는 동안 VPN 피어는 DPD(Dead Peer Detection) 방법을 사용할지 여부를 결정하기 위해 협상합니다. 피어가 DPD 방식을 사용하기로 동의하면 활성 트래픽이 없을 때 DPD 프로토콜은 피어에 주기적인 메시지를 보내고 응답을 기다립니다. 피어가 메시지에 응답하지 않으면 DPD 프로토콜은 피어를 더 이상 사용할 수 없다고 가정합니다. DPD의 동작은 IKEv1 및 IKEv2 프로토콜 모두에서 동일합니다. DPD 타이머는 IKE가 1단계 SA(보안 연결)를 설정하는 즉시 활성화됩니다.

방화벽은 DPD 프로토콜을 사용하여 IPsec VPN 연결의 활성을 감지합니다.

그림 1: DPD 프로토콜 의 메시지 교환

그림 1 은 IPsec VPN 터널에서 IKE 피어 간의 DPD 메시지 교환을 보여줍니다. 방화벽 디바이스가 DPD를 수행할 때 다음 이벤트가 발생합니다.

1. 방화벽 SRX-A는 지정된 DPD 간격까지 기다렸다가 피어 SRX-B로부터 트래픽을 수신했는지 확인합니다.

2. SRX-A가 지정된 DPD 간격 동안 SRX-B로부터 트래픽을 수신하지 않으면 암호화된 IKE(Internet Key Exchange) 1단계 알림 페이로드(R-U-THERE 메시지)를 SRX-B로 보냅니다.

3. SRX-A는 SRX-B로부터 DPD 승인(R-U-THERE-ACK 메시지)을 기다립니다.

   1. SRX-A가 이 간격 동안 SRX-B로부터 R-U-THERE-ACK 메시지를 수신하면 피어가 살아 있는 것으로 간주합니다. 그런 다음 SRX-A는 해당 터널에 대한 R-U-THERE 메시지 카운터를 재설정하고 새 간격을 시작합니다.

   2. SRX-A가 간격 동안 R-U-THERE-ACK 메시지를 수신하지 않으면 피어 SRX-B가 중단된 것으로 간주합니다. 그런 다음 SRX-A는 해당 피어에 대한 1단계 SA와 모든 2단계 SA를 제거합니다.

구성 가능한 DPD 매개 변수

구성해야 하는 DPD 매개 변수 목록은 다음과 같습니다.

• 모드 - 트래픽 활동에 따라 다음 모드 중 하나에서 DPD를 구성할 수 있습니다.

  • 최적화됨 - 최적화 모드에서 시작 디바이스가 피어에 발신 패킷을 전송할 때 구성된 간격 내에 피어로부터 들어오는 IKE 또는 IPsec 트래픽이 없으면 시작 디바이스는 R-U-THERE 메시지를 트리거합니다. DPD는 다른 모드를 구성하지 않는 한 이 기본 모드에서 작동합니다.

  • 프로브 유휴 터널 - 프로브 유휴 터널 모드에서 디바이스는 구성된 간격 내에 들어오거나 나가는 IKE(Internet Key Exchange) 또는 IPsec 트래픽이 없으면 R-U-THERE 메시지를 트리거합니다. 디바이스는 트래픽 활동이 있을 때까지 주기적으로 R-U-THERE 메시지를 피어에 보냅니다. 이 모드는 다운된 피어를 조기에 감지하여 활성 트래픽 플로우 중에 터널 가용성을 보장하는 데 도움이 됩니다.

    참고:

    이 시나리오에서 프로브 유휴 터널 모드를 구성할 때 동일한 IKE(Internet Key Exchange) SA에 대한 다른 터널의 트래픽에 관계없이 터널이 유휴 상태가 되면 디바이스는 R-U-THERE 메시지를 트리거합니다.

  • Always-send - always-send 모드에서 디바이스는 피어 간의 트래픽 활동에 관계없이 구성된 간격으로 R-U-THERE 메시지를 보냅니다. 항상 전송 모드 대신 프로브 유휴 터널 모드를 사용하는 것이 좋습니다.

• 간격 - 간격 매개 변수를 사용하여 디바이스가 R-U-THERE 메시지를 보내기 전에 피어의 트래픽을 기다리는 시간(초)을 지정합니다. 기본 간격은 10초입니다. R-U-THERE 메시지가 피어 디바이스로 전송되는 허용 간격 매개변수 범위는 2초에서 60초입니다. DPD 간격 매개 변수가 10초 미만으로 설정된 경우 최소 임계값 매개 변수를 3으로 설정하는 것이 좋습니다.

• 임계값 - 임계값 매개 변수를 사용하여 디바이스가 피어가 다운된 것으로 간주하기 전에 피어로부터 응답을 받지 않고 R-U-THERE 메시지를 보내는 최대 횟수를 지정합니다. 기본 전송 횟수는 5회이며 허용 범위는 1회에서 5회입니다.

DPD를 구성하기 전에 다음 사항을 참고하십시오.

• 활성 터널이 있는 기존 게이트웨이에 DPD 구성을 추가하면 디바이스는 1단계 또는 2단계 SA를 지우지 않고 R-U-THERE 메시지를 트리거하기 시작합니다.

• 활성 터널이 있는 기존 게이트웨이에서 DPD 구성을 삭제하면 디바이스는 터널에 대한 R-U-THERE 메시지 트리거를 중단합니다. 그러나 이것은 IKE 및 IPsec SA에는 영향을 미치지 않습니다.

• 모드, 간격 또는 임계값과 같은 DPD 구성 매개 변수를 수정할 때, IKE(Internet Key Exchange)는 1단계 또는 2단계 SA를 지우지 않고 DPD 작업을 업데이트합니다.

• 즉시 터널을 설정하는 옵션을 지정하지 않고 DPD 및 VPN 모니터링으로 IKE(Internet Key Exchange) 게이트웨이를 구성하는 경우 IKE(Internet Key Exchange)는 1단계 협상을 시작하지 않습니다. DPD를 구성할 때, 1edit security ipsec vpn vpn-name 단계 및 2단계 SA를 사용할 수 없을 때 st0 인터페이스를 삭제하도록 [] 계층 수준에서 옵션을 구성 establish-tunnels immediately 해야 합니다. 옵션은 vpn(보안) establish-tunnels 을 참조하십시오.

• 여러 피어 IP 주소 및 DPD로 IKE 게이트웨이를 구성했지만 첫 번째 피어 IP 주소로 1단계 SA를 설정하지 못하면 IKE는 다음 피어 IP 주소로 설정을 시도합니다. DPD는 IKE가 1단계 SA를 설정한 후에만 활성화됩니다. dead-peer-detection을 참조하십시오.

• 여러 피어 및 DPD로 IKE 게이트웨이를 구성했지만 현재 피어의 IP 주소로 연결이 실패하는 경우 IKE는 1단계 및 2단계 SA를 지우고 DPD는 다음 피어 IP 주소로 페일오버를 수행합니다. 게이트웨이(보안 IKE)를 참조하십시오.

• 동시 협상 때문에 둘 이상의 1단계 또는 2단계 SA가 동일한 피어에 존재할 수 있습니다. 이 경우 DPD는 모든 1단계 SA에 R-U-THERE 메시지를 보냅니다. 게이트웨이가 구성된 연속 횟수 동안 DPD 응답을 수신하지 못하면 1단계 SA 및 연결된 2단계 SA를 지웁니다(IKEv2만 해당).

IKE(Internet Key Exchange) 피어가 활성 상태라면 기본 VPN이 작동 중임을 의미합니까?

VPN 터널 모니터링은 어떻게 작동합니까?

VPN 모니터링은 ICMP 패킷의 ICMP(Internet Control Message Protocol) 에코 요청(또는 ping)과 터널 ID와 같은 서명 데이터를 사용하여 VPN 터널이 작동 중인지 여부를 확인합니다.

VPN 모니터링을 활성화하면 디바이스는 VPN 터널을 통해 피어 게이트웨이 또는 터널의 다른 쪽 끝에 있는 지정된 대상으로 ICMP 에코 요청을 보냅니다. 디바이스는 기본적으로 최대 10회 연속으로 10초 간격으로 요청을 보냅니다. 디바이스가 10회 연속 ping 후에도 응답을 받지 못하면 VPN이 다운된 것으로 간주하고 IPsec 보안 연결을 지웁니다.

다음 운영 모드를 사용하여 VPN 터널을 모니터링합니다.

• Always-send 모드 - 이 모드에서는 디바이스가 터널의 트래픽과 관계없이 구성된 간격마다 한 번씩 VPN 모니터링 패킷을 보냅니다. VPN 모니터링을 활성화한 후, 지정하지 않으면 Junos OS는 항상 전송 모드를 기본 모드로 사용합니다.

• 최적화 모드 - 이 모드에서는 디바이스가 구성된 간격마다 한 번씩 VPN 모니터링 패킷을 전송하고 간격 동안 터널을 통해 들어오는 트래픽이 없는 경우에만 전송합니다. VPN 터널을 통해 들어오는 트래픽이 있는 경우 디바이스는 터널을 활성 상태로 간주하고 피어에 ping 전송을 중지합니다. 최적화 모드를 사용하여 디바이스의 리소스를 절약할 수 있습니다. 이 모드에서는 디바이스가 피어 활성을 판별해야 할 때만 ping을 보내기 때문입니다. 핑을 보내면 비용이 많이 드는 백업 링크가 활성화될 수도 있습니다.

  최적화 모드를 명시적으로 구성하지 않으면 디바이스는 기본 always-send 모드에서 작동합니다.