CDO에서 가상 프라이빗 네트워크 관리

VPN(Virtual Private Network)은 인터넷과 같은 공용 네트워크를 통해 엔드포인트 간에 보안 터널을 설정합니다.

이 섹션은 ASA(Adaptive Security Appliance) 디바이스의 원격 액세스 및 사이트 투 사이트 VPN에 적용됩니다. 또한 ASA에서 VPN 연결을 배포하고 원격 액세스하는 데 사용되는 SSL 표준에 대해서도 설명합니다.

CDO에서는 다음과 같은 유형의 VPN 연결을 지원합니다.

사이트 간 가상 프라이빗 네트워크 소개

사이트간 VPN 터널은 다양한 위치에 있는 네트워크를 연결합니다. 관리형 디바이스 및 관리형 디바이스와 모든 관련 표준을 준수하는 다른 Cisco 또는 타사 피어 간에 Site-to-Site IPsec 연결을 만들 수 있습니다. 이러한 피어는 IPv4와 IPv6 주소를 사용하여 내부 주소와 외부 주소를 함께 포함할 수 있습니다 . Site-to-Site 터널은 IPsec(Internet Protocol Security) 프로토콜 제품군 및 인터넷 키 교환 버전 2(IKEv2)를 사용하여 구축됩니다. VPN 연결이 설정되면 로컬 게이트웨이의 뒤에 있는 호스트는 보안 VPN 터널을 통해 원격 게이트의 뒤에 있는 호스트와 연결할 수 있습니다.

VPN 토폴로지

새로운 사이트 간 VPN 토폴로지를 생성하려면 고유한 이름을 부여하거나 토폴로지 유형을 지정하거나 IPsec IKEv1 또는 IKEv2에 사용되는 IKE 버전 또는 둘 다 및 인증 방법을 선택해야 합니다. 구성된 후 토폴로지를 ASA에 구축합니다.

IPsec 및 IKE 프로토콜

CDO에서 사이트 간 VPN은 IKE 정책과 VPN 토폴로지에 할당된 IPsec 제안을 기반으로 구성됩니다. 정책 및 제안은 IPsec 터널에서 트래픽을 보호하는 데 사용되는 보안 프로토콜 및 알고리즘과 같은 사이트 간 VPN의 특성을 정의하는 파라미터 집합입니다. VPN 토폴로지에 할당할 수 있는 전체 구성 이미지를 정의하려면 몇 가지 정책 유형이 필요할 수 있습니다.

인증 VPN 터널

VPN 연결을 인증하려면 각 디바이스의 토폴로지에서 사전 공유 키를 구성합니다. 사전 공유 키를 사용하면 IKE 인증 단계에서 사용되는 보안 키를 두 피어 간에 공유할 수 있습니다.

VPN 암호화 도메인

VPN의 암호화 도메인은 경로 기반 또는 정책 기반 트래픽 선택기라는 두 가지 방법으로 정의할 수 있습니다.

  • 정책 기반: 암호화 도메인은 IPSec 터널에 들어오는 모든 트래픽을 허용하도록 설정됩니다. IPSec 로컬 및 원격 트래픽 선택기는 0.0.0.0으로 설정됩니다. 즉, IPSec 터널로 라우팅되는 모든 트래픽은 소스/대상 서브넷에 관계없이 암호화됩니다. ASA는 암호화 맵을 사용하는 정책 기반 VPN을 지원합니다.

  • 경로 기반: 암호화 도메인은 소스와 대상 모두에 대해 특정 IP 범위만 암호화하도록 설정됩니다. 이는 가상 IPsec 인터페이스를 생성하며, 해당 인터페이스에 들어오는 모든 트래픽은 암호화 및 암호 해독됩니다. ASA는 VTI(Virtual Tunnel Interface)를 사용하여 경로 기반 VPN을 지원합니다.

외부 디바이스 정보

비 시스코 또는 관리되지 않는 시스코 디바이스를 정적 또는 동적 IP 주소를 가진 "엑스트라넷" 장치로 VPN 토폴로지에 추가할 수 있습니다.

  • 비 시스코 디바이스: CDO를 사용하여 비 시스코 디바이스에 구성을 생성하거나 구축할 수 없습니다.

  • 관리되지 않는 시스코 디바이스: 회사 내 다른 조직에서 관리하는 네트워크의 스포크 또는 서비스 제공업체 또는 파트너 네트워크에 대한 연결과 같이 조직에서 관리하지 않는 시스코 디바이스입니다.

ASA 사이에 사이트 간 VPN 구성

CDO는 ASA(Adaptive Security Appliance) 디바이스에서 사이트 간 VPN 기능의 다음 측면을 지원합니다.

  • IPsec IKEv1 및 IKEv2 프로토콜이 모두 지원됩니다.

  • 인증을 위한 자동 또는 수동 사전 공유 키.

  • IPv4 및 IPv6. 내부와 외부의 모든 조합이 지원됩니다.

  • IPsec IKEv2 사이트 간 VPN 토폴로지는 보안 인증을 준수하기 위한 구성 설정을 제공합니다.

  • 정적 및 동적 인터페이스.

  • 엔드포인트로 작동하는 엑스트라넷 디바이스의 정적 또는 동적 IP 주소 지원.

동적 주소 지정 피어로 사이트 간 VPN 연결 구성

CDO를 사용하면 피어의 VPN 인터페이스 IP 주소 중 하나를 알 수 없거나 인터페이스가 DHCP 서버에서 주소를 가져올 때 피어 간에 사이트 간 VPN 연결을 생성할 수 있습니다. 사전 공유 키, IKE 설정 및 IPsec 구성이 다른 피어와 일치하는 모든 동적 피어는 사이트 간 VPN 연결을 설정할 수 있습니다.

피어 A와 B를 고려하십시오. 고정 피어는 VPN 인터페이스의 IP 주소가 고정되어 있는 디바이스이고 동적 피어는 VPN 인터페이스의 IP 주소를 알 수 없거나 임시 IP 주소가 있는 디바이스입니다.

다음 사용 사례에서는 동적으로 주소가 지정된 피어를 사용하여 안전한 사이트 간 VPN 연결을 설정하는 다양한 시나리오를 설명합니다.

  • A는 정적 피어이고 B는 동적 피어이거나 그 반대입니다.

  • A는 고정 피어이고 B는 DHCP 서버에서 확인된 IP 주소를 사용하거나 그 반대로 하는 동적 피어입니다.

  • A는 동적 피어이고, B는 고정 또는 동적 IP 주소를 사용하는 엑스트라넷 디바이스입니다.

  • A는 DHCP 서버에서 확인된 IP 주소를 사용하는 동적 피어이고, B는 고정 또는 동적 IP 주소를 사용하는 엑스트라넷 디바이스입니다.


참고


ASDM(Adaptive Security Device Manager)과 같은 로컬 관리자를 사용하여 인터페이스의 IP 주소를 변경하면 CDO에서 해당 피어의 Configuration Status(구성 상태)에 "Conflict Detected(충돌 탐지됨)"가 표시됩니다. 이 대역 외 변경 사항을 해결하면 다른 피어의 Configuration Status(구성 상태)가 "Not Synced(동기화되지 않음)" 상태로 변경됩니다. "Not Synced(동기화되지 않음)" 상태인 디바이스에 CDO 구성을 구축해야 합니다.


일반적으로 동적 피어는 연결을 시작하는 피어여야 합니다. 다른 피어는 동적 피어의 IP 주소를 알지 못하기 때문입니다. 원격 피어가 연결을 설정하려고 시도하면 다른 피어가 사전 공유 키, IKE 설정 및 IPsec 구성을 사용하여 연결을 검증합니다.

원격 피어에서 연결을 시작한 후에만 VPN 연결이 설정되므로 VPN 터널에서 트래픽을 허용하는 액세스 제어 규칙과 일치하는 모든 아웃바운드 트래픽은 연결이 설정될 때까지 중단됩니다. 이를 통해 데이터가 적절한 암호화 및 VPN 보호 없이 네트워크를 벗어나지 않게 합니다.


참고


다음 시나리오에서는 사이트 간 VPN 연결을 구성할 수 없습니다.

디바이스에 둘 이상의 동적 피어 연결이 있는 경우

  • 3개의 디바이스 A, B 및 C를 고려하십시오.

  • A(고정 피어)와 B(동적 피어) 간에 사이트 간 VPN 연결을 구성합니다.

  • 엑스트라넷 디바이스를 생성하여 A와 C(동적 피어) 간에 사이트 간 VPN 연결을 구성합니다. A의 고정 VPN 인터페이스 IP 주소를 엑스트라넷 디바이스에 할당하고 C와의 연결을 설정합니다.


ASA 사이트 간 VPN 지침 및 제한 사항

  • CDO는 S2S VPN에 대한 흥미로운 트래픽을 설계하기 위해 crypto-acl을 지원하지 않습니다. 이는 보호된 네트워크만 지원합니다.

  • IKE 포트 500/4500이 사용 중이거나 활성화된 일부 PAT 변환이 있을 때마다 사이트 간 VPN을 동일한 포트에서 구성할 수 없으므로 해당 포트에서 서비스를 시작하는 데 실패합니다.

  • 전송 모드는 지원되지 않으며 터널 모드만 지원됩니다. IPsec 터널 모드는 새 IP 패킷에서 페이로드가 되는 원래 IP 데이터그램 전체를 암호화합니다. 방화벽 뒤에 배치되어 있는 호스트와 주고받는 트래픽을 방화벽이 보호하는 경우 터널 모드를 사용합니다. 터널 모드는 인터넷 등의 신뢰할 수 없는 네트워크를 통해 연결하는 두 방화벽 또는 기타 보안 게이트웨이 간에 일반 IPSec이 구현되는 통상적인 방식입니다.

  • 이 릴리스에서는 하나 이상의 VPN 터널을 포함하는 PTP 토폴로지만 지원됩니다. Point-to-Point 구축에서는 두 엔드포인트 간에 VPN 터널을 설정합니다.

Virtual Tunnel Interface에 대한 지침

  • VTI는 IPsec 모드에서만 구성할 수 있습니다. ASA에서의 GRE 터널 종료는 지원되지 않습니다.

  • 터널 인터페이스를 사용하여 트래픽에 대한 동적 또는 정적 경로를 사용할 수 있습니다.

  • 기본 물리적 인터페이스에 따라 VTI에 대한 MTU가 자동으로 설정됩니다. 그러나 VTI가 활성화된 후 물리적 인터페이스 MTU를 변경하는 경우, 새 MTU 설정을 사용하려면 VTI를 비활성화했다가 다시 활성화해야 합니다.

  • 네트워크 주소 변환을 적용해야 할 경우, IKE 및 ESP 패킷이 UDP 헤더에서 캡슐화됩니다.

  • IKE 및 IPsec 보안 연계는 터널에서 데이터 트래픽에 관계없이 지속적으로 다시 입력됩니다. 이렇게 하면 VTI 터널은 항상 작동합니다.

  • 터널 그룹 이름은 피어가 IKEv1 또는 IKEv2 id로 전송하는 항목과 일치해야 합니다.

  • LAN-to-LAN 터널 그룹에서 IKEv1의 경우, 터널 인증 방법이 디지털 인증서 및/또는 적극적인 모드를 사용하도록 구성된 피어인 경우, IP 주소가 아닌 이름을 사용할 수 있습니다.

  • VTI 및 암호화 맵 구성은 동일한 물리적 인터페이스에서 공존할 수 있으며 암호화 맵에 구성된 피어 주소를 제공하며 VTI에 대한 터널 대상은 서로 다릅니다.

  • 기본적으로 VTI를 통과하는 모든 트래픽이 암호화됩니다.

  • 기본적으로 VTI 인터페이스의 보안 레벨은 0입니다.

  • 액세스 목록은 VTI를 통과하는 트래픽을 제어하기 위해 VTI 인터페이스에 적용될 수 있습니다.

  • VTI에서는 BGP만 지원됩니다.

  • ASA가 IOS IKEv2 VTI 클라이언트를 종료하는 경우, IOS에서 config-exchange 요청을 비활성화합니다. ASA는 IOS VTI 클라이언트에서 시작한 이 L2L 세션에 대한 mode-CFG 속성을 검색할 수 없기 때문입니다.

  • IPv6은 지원되지 않습니다.

VPN에서 사용되는 암호화 및 해시 알고리즘

VPN 터널은 일반적으로 공용 네트워크(대개 인터넷)를 통과하므로 연결을 암호화하여 트래픽을 보호해야 합니다. IKE 정책 및 IPsec 제안을 사용하여 적용할 암호화 및 기타 보안 기술을 정의합니다.

디바이스 라이선스에서 강력한 암호화 적용이 허용되는 경우에는 광범위한 암호화 및 해시 알고리즘과 Diffie-Hellman 그룹 중에서 선택할 수 있습니다. 그러나 일반적으로는 터널에 적용하는 암호화가 강력할수록 시스템 성능은 더 나빠집니다. 따라서 효율성을 저하하지 않으면서 충분한 보호 기능을 제공하는 보안과 성능 간의 적절한 균형 지점을 찾아야 합니다.

Cisco는 선택할 수 있는 옵션에 대한 구체적인 지침을 제공하지는 않습니다. 대규모 기업이나 기타 조직 내에서 보안을 담당하는 경우 충족해야 하는 표준이 이미 정의되어 있을 수 있습니다. 그렇지 않은 경우, 선택할 수 있는 옵션에 대해 조사해야 합니다.

다음 주제에서는 사용 가능한 옵션에 대해 설명합니다.

사용할 암호화 알고리즘 결정

IKE 정책 또는 IPsec 제안에 사용할 암호화 알고리즘을 결정할 때는 VPN의 디바이스가 지원하는 알고리즘으로 선택이 제한됩니다.

IKEv2의 경우 여러 암호화 알고리즘을 구성할 수 있습니다. 시스템은 가장 안전한 항목부터 가장 안전하지 않은 항목 순으로 설정 순서를 지정하고 해당 순서를 사용하여 피어와 협상합니다. IKEv1의 경우 단일 옵션만 선택할 수 있습니다.

IPsec 제안의 경우 알고리즘은 인증, 암호화 및 재생 방지 서비스를 제공하는 ESP(Encapsulating Security Protocol)에서 사용됩니다. ESP는 IP 프로토콜 유형 50입니다. IKEv1 IPsec 제안에서 알고리즘 이름에는 ESP- 접두사가 붙습니다.

디바이스 라이선스에 따라 강력한 암호화를 사용할 수 있는 경우 다음 암호화 알고리즘 중에서 선택할 수 있습니다. 강력한 암호화를 사용할 수 없으면 DES만 선택할 수 있습니다.

  • AES-GCM - (IKEv2에만 해당됨) 기밀 유지 및 데이터 원본 인증 기능을 제공하는 블록 암호화 작동 모드인 AES-GCM(Advanced Encryption Standard in Galois/Counter Mode)은 AES보다 보안성이 뛰어납니다. AES-GCM은 세 가지 키 강도(128비트, 192비트 및 256비트 키)를 제공합니다. 키 길이가 길수록 보안성은 더 높지만 성능은 낮습니다. GCM은 NSA Suite B를 지원하는 데 필요한 AES의 모드입니다. NSA Suite B는 암호화 강도에 대한 연방 기준을 충족시키기 위해 디바이스가 지원해야 하는 암호화 알고리즘 세트입니다.

  • AES-GMAC - (IKEv2 IPsec 제안에만 해당됨) AES-GMAC(Advanced Encryption Standard Galois Message Authentication Code)는 데이터 원본 인증 기능만 제공하는 블록 암호화 작동 모드입니다. 이 모드는 데이터를 암호화하지 않고 데이터 인증을 허용하는 AES-GCM의 변형입니다. AES-GMAC는 세 가지 키 강도(128비트, 192비트 및 256비트 키)를 제공합니다.

  • AES - AES(Advanced Encryption Standard)는 DES보다 보안성이 뛰어나며 3DES보다 계산 효율성이 높은 대칭 암호화 알고리즘입니다. AES는 세 가지 키 강도(128비트, 192비트 및 256비트 키)를 제공합니다. 키 길이가 길수록 보안성은 더 높지만 성능은 낮습니다.

  • DES - 56비트 키를 사용하여 암호화를 수행하는 DES(Data Encryption Standard)는 대칭 보안 키 블록 알고리즘입니다. 라이선스 어카운트가 내보내기 제어에 대한 요건을 충족하지 않는 경우에는 이 옵션이 유일한 옵션입니다. 3DES보다 속도가 빠르며 시스템 리소스를 더 적게 사용하지만 보안성은 더 낮습니다. 강력한 데이터 기밀 유지 기능이 필요하지 않으며 시스템 리소스나 속도가 중요한 경우에는 DES를 선택하십시오.

  • 3DES - 56비트 키를 사용하여 암호화를 3회 수행하는 3DES(Triple DES)는 서로 다른 키를 사용하여 각 데이터 블록을 3회 처리하므로 DES보다 안전합니다. 그러나 시스템 리소스를 더 많이 사용하며 DES보다 속도가 느립니다.

  • NULL - null 암호화 알고리즘은 암호화를 수행하지 않는 인증 기능을 제공합니다. 이 알고리즘은 대개 테스트용으로만 사용됩니다.

사용할 해시 알고리즘 결정

IKE 정책에서 해시 알고리즘은 메시지 무결성을 보장하는 데 사용되는 메시지 다이제스트를 생성합니다. IKEv2에서 해시 알고리즘은 두 가지 옵션으로 구분됩니다. 그중 하나는 무결성 알고리즘 옵션이고 다른 하나는 PRF(Pseudo-Random Function: 의사 난수 함수) 옵션입니다.

IPsec 제안에서 해시 알고리즘은 인증을 위한 ESP(Encapsulating Security Protocol)에서 사용됩니다. IKEv2 IPsec 제안에서는 이러한 알고리즘을 무결성 해시라고 합니다. IKEv1 IPsec 제안에서는 알고리즘 이름에 ESP- 접두사가 붙으며 -HMAC(Hash Method Authentication Code) 접미사도 붙습니다.

IKEv2의 경우 여러 해시 알고리즘을 구성할 수 있습니다. 시스템은 가장 안전한 항목부터 가장 안전하지 않은 항목 순으로 설정 순서를 지정하고 해당 순서를 사용하여 피어와 협상합니다. IKEv1의 경우 단일 옵션만 선택할 수 있습니다.

다음 해시 알고리즘 중에서 선택할 수 있습니다.

  • SHA(Secure Hash Algorithm) - 표준 SHA(SHA-1)에서는 160비트 다이제스트를 생성합니다. SHA는 MD5보다 무차별 암호 대입 공격에 대한 방어력이 뛰어납니다. 그러나 MD5 보다 리소스를 더 많이 사용 합니다. 최고 보안 레벨이 필요한 구현의 경우 SHA 해시 알고리즘을 사용합니다.

  • IKEv2 컨피그레이션에는 다음과 같은 더욱 안전한 SHA-2 옵션을 사용할 수 있습니다. NSA Suite B 암호화 사양을 구현하려는 경우 이러한 옵션 중 하나를 선택합니다.

    • SHA-256 - 256비트 다이제스트를 생성하는 Secure Hash Algorithm SHA-2를 지정합니다.

    • SHA-384 - 384비트 다이제스트를 생성하는 Secure Hash Algorithm SHA-2를 지정합니다.

    • SHA-512 - 512비트 다이제스트를 생성하는 Secure Hash Algorithm SHA-2를 지정합니다.

  • MD5(Message Digest 5) - 128비트 다이제스트를 생성합니다. MD5는 SHA보다 전반적으로 성능이 우수하여 처리 시간이 짧지만 SHA보다 취약한 것으로 간주됩니다.

  • null 또는 None(NULL, ESP-NONE) - (IPsec 제안에만 해당됨) null 해시 알고리즘으로, 대개 테스트용으로만 사용됩니다. 그러나 AES-GCM/GMAC 옵션 중 하나를 암호화 알고리즘으로 선택하는 경우에는 null 무결성 알고리즘을 선택해야 합니다. null 이외의 옵션을 선택하더라도 이러한 암호화 표준에 대해서는 무결성 해시가 무시됩니다.

사용할 Diffie-Hellman 모듈러스 그룹 결정

다음 Diffie-Hellman 키 파생 알고리즘을 사용하여 IPsec 보안 연계(SA) 키를 생성할 수 있습니다. 각 그룹의 크기 모듈러스는 서로 다릅니다. 대형 모듈러스는 보안성은 더 높지만, 처리 시간이 더 오래 걸립니다. 두 피어에 일치하는 모듈러스 그룹이 있어야 합니다.

AES 암호화를 선택하는 경우 AES에 필요한 큰 키를 지원하려면 DH(Diffie-Hellman) 그룹 5 이상을 사용해야 합니다. IKEv1 정책에서는 아래에 나열된 그룹을 모두 지원하지는 않습니다.

NSA Suite B 암호화 사양을 구현하려면 IKEv2를 사용하고 ECDH(Elliptic Curve Diffie-Hellman) 옵션 19, 20, 21 중 하나를 선택합니다. 2048비트 모듈러스를 사용하는 엘립틱 커브 옵션과 그룹은 Logjam과 같은 공격에 노출될 가능성이 작습니다.

IKEv2의 경우에는 여러 그룹을 구성할 수 있습니다. 시스템은 가장 안전한 항목부터 가장 안전하지 않은 항목 순으로 설정 순서를 지정하고 해당 순서를 사용하여 피어와 협상합니다. IKEv1의 경우 단일 옵션만 선택할 수 있습니다.

  • 2 - Diffie-Hellman 그룹 2: 1024비트 MODP(모듈식 지수) 그룹. 이 옵션은 더 이상 좋은 보호 방법으로 간주되지 않습니다.

  • 5 - Diffie-Hellman 그룹 5: 1536비트 MODP 그룹. 전에는 이 옵션이 128비트 키에 대해 좋은 보호 방법으로 간주되었지만 이제는 더 이상 좋은 보호 방법으로 간주되지 않습니다.

  • 14 - Diffie-Hellman 그룹 14: 2048비트 MODP(모듈식 지수) 그룹. 192비트 키에 적합한 보호를 제공합니다.

  • 19 - Diffie-Hellman 그룹 19: NIST(국내 표준 및 기술) 256비트 ECP(elliptic curve modulo a prime) 그룹

  • 20 - Diffie-Hellman 그룹 20: NIST 384비트 ECP 그룹

  • 21 - Diffie-Hellman 그룹 21: NIST 521비트 ECP 그룹

  • 24 - Diffie-Hellman 그룹 24: 2048비트 MODP 그룹 및 256비트 소수 위수 하위 그룹. 이 옵션은 더 이상 권장되지 않습니다.

사용할 인증 방법 결정

다음과 같은 방법을 사용하여 Site-to-Site VPN 연결에서 피어를 인증할 수 있습니다.

사전 공유 키

사전 공유 키는 연결에서 각 피어에 컨피그레이션된 암호 키 문자열입니다. 이 키는 인증 단계 중에 IKE에서 사용합니다. IKEv1의 경우, 각 피어에서 동일한 사전 공유 키를 컨피그레이션해야 합니다. IKEv2의 경우, 각 피어에 고유 키를 컨피그레이션할 수 있습니다.

사전 공유 키는 인증서에 비해 확장성이 떨어집니다. 다수의 사이트 간 VPN 연결을 구성해야 하는 경우, 사전 공유 키 방법 대신 인증서 방법을 사용하십시오.

ASA 사이에 사이트 간 VPN 터널 생성

두 ASA 또는 엑스트라넷 디바이스를 사용하는 ASA 간에 사이트 간 VPN 터널을 생성하려면 다음 절차를 수행합니다.

프로시저

단계 1

탐색 창에서 VPN > Site-to-Site ASA/FDM (사이트 간 ASA/FDM )을 선택합니다.

단계 2

오른쪽 상단 모서리에 있는 파란색 더하기 를 클릭하고 ASA 레이블이 있는 Site-to-Site VPN(사이트 간 VPN)을 클릭합니다.

단계 3

Configuration Name(구성 이름) 필드에 생성한 사이트 간 VPN 구성의 이름을 입력합니다.

단계 4

정책 기반 또는 경로 기반 사이트 간 VPN을 생성하는 옵션 중 하나를 선택합니다.

단계 5

Peer Devices(피어 디바이스) 섹션에서 다음을 수행합니다.

  1. 피어 1: ASA 디바이스를 선택하고 Select(선택)를 클릭합니다.

  2. 피어 2: 다른 ASA 디바이스를 선택한 다음 Select(선택)를 클릭합니다.

    엑스트라넷: 피어 2에서 엑스트라넷 디바이스를 선택하려면 엑스트라넷 슬라이더를 클릭하여 활성화합니다.

    Static(고정)을 선택하고 IP 주소를 지정하거나, DHCP 할당 IP가 있는 엑스트라넷 디바이스의 경우 Dynamic(동적)을 선택합니다. IP Address(IP 주소)는 정적 인터페이스의 IP 주소 또는 동적 인터페이스의 DHCP Assigned(DHCP 할당됨)를 표시합니다.

  3. Next(다음)를 클릭합니다.

  4. 엔드포인트 디바이스에 대한 VPN 액세스 인터페이스를 선택합니다.

  5. (경로 기반 VPN에 적용 가능) LAN 서브넷을 제어하는 LAN 인터페이스를 선택합니다. 여러 인터페이스를 선택할 수 있습니다.

    선택한 LAN 인터페이스에 연결된 네트워크가 라우팅 정책 액세스 목록에 추가됩니다. 라우팅 정책 액세스 목록과 일치하는 트래픽은 VPN 터널에 의해 암호화/암호 해독됩니다.

  6. 참여하는 디바이스에 대해 Protected Networks(보호된 네트워크)를 추가하려면 Add Network(네트워크 추가)를 클릭합니다. 보호된 네트워크는 이 VPN 엔드포인트로 보호되는 네트워크를 정의합니다.

  7. (선택 사항이며 정책 기반에 적용 가능) 로컬 VPN 액세스 인터페이스의 NAT 정책에서 VPN 트래픽을 제외하려면 NAT Exempt(NAT 면제)를 선택합니다. 개별 피어에 대해 수동으로 구성해야 합니다. NAT 규칙을 로컬 네트워크에 적용하지 않으려는 경우 로컬 네트워크를 호스팅하는 인터페이스를 선택합니다. 이 옵션은 로컬 네트워크가 단일 라우팅 인터페이스(브리지 그룹 멤버 아님) 뒤에 있는 경우에만 작동합니다. 로컬 네트워크가 둘 이상의 라우팅 인터페이스 또는 하나 이상의 브리지 그룹 멤버 뒤에 있는 경우에는 NAT 제외 규칙을 수동으로 생성해야 합니다. 필요한 규칙을 수동으로 생성하는 방법에 대한 자세한 내용은 NAT에서 ASA 사이트 간 VPN 트래픽 제외를 참조하십시오.

  8. Next(다음)를 클릭합니다.

단계 6

(라우트 기반에 적용 가능) 이전 단계에서 피어 디바이스가 구성되면 터널 세부 정보에서 VTI 주소 필드가 자동으로 채워집니다. 필요한 경우 새 VTI로 사용할 IP 주소를 수동으로 입력할 수 있습니다.

단계 7

IKE Settings(IKE 설정) 섹션에서 IKE(Internet Key Exchange) 협상 중에 사용할 IKE 버전을 선택하고 프라이버시 구성을 지정합니다. IKE 정책에 대한 자세한 내용은 전역 IKE 정책 구성을 참조하십시오.

CDO는 사용자가 수행한 구성에 따라 IKE 설정을 제안합니다. 권장 IKE 구성 설정을 계속 사용하거나 새로 정의할 수 있습니다.

참고

 

IKE 정책은 디바이스에 전역적이며 연결된 모든 VPN 터널에 적용됩니다. 따라서 정책을 추가하거나 삭제하면 이 디바이스가 참여하는 모든 VPN 터널에 영향을 미칩니다.

  1. 적절하게 IKE 버전 중 하나 또는 둘 다를 선택합니다.

    기본적으로 IKEV 버전 2가 활성화되어 있습니다.

    참고

     

    경로 기반 VPN에는 두 IKE 버전을 모두 활성화할 수 없습니다.

  2. Add IKEv2 Policy(IKEv2 정책 추가)를 클릭하고 IKEv2 정책을 선택합니다.

    참고

     

    Create New IKEv2 Policy(새 IKEv2 정책 생성)를 클릭하여 새 IKEv2 정책을 생성합니다. 새 IKEv2 정책 생성에 대한 자세한 내용은 IKEv2 정책 구성을 참고하십시오. 기존 IKEv2 정책을 삭제하려면 선택한 정책 위에 마우스를 놓고 x 아이콘을 클릭합니다.

  3. 참여 디바이스에 대한 사전 공유 키를 입력합니다. 사전 공유 키는 연결에서 각 피어에 컨피그레이션된 암호 키 문자열입니다. IKE는 인증 단계 중에 이러한 키를 사용합니다.

    (IKEv2) 피어 1 사전 공유 키, 피어 2 사전 공유 키: IKEv2의 경우 각 피어에서 고유한 키를 구성할 수 있습니다. 사전 공유 키를 입력합니다. show(표시) 버튼을 클릭하고 피어에 대해 적절한 사전 공유를 입력할 수 있습니다. 키는 영숫자 1~127자가 될 수 있습니다. 다음 표에서는 두 피어에 대한 사전 공유 키의 용도에 대해 설명합니다.

    로컬 사전 공유 키

    원격 피어 사전 공유 키

    피어 1 피어 1 사전 공유 키 피어 2 사전 공유 키
    피어 2 피어 2 사전 공유 키 피어 1 사전 공유 키
  4. IKE Version 1(IKE 버전 1)을 클릭하여 활성화합니다.

  5. Add IKEv1 Policy(IKEv1 정책 추가)를 클릭하고 IKEv1 정책을 선택합니다. Create New IKEv1 Policy(새 IKEv1 정책 생성)를 클릭하여 새 IKEv1 정책을 생성합니다. 새 IKEv1 정책 생성에 대한 자세한 내용은 IKEv1 정책 구성을 참고하십시오. 기존 IKEv1 정책을 삭제하려면 선택한 정책 위에 마우스를 올리고 x 아이콘을 클릭합니다.

  6. (IKEv1) 사전 공유 키: IKEv1의 경우, 각 피어에서 동일한 사전 공유 키를 컨피그레이션해야 합니다. 키는 영숫자 1~127자가 될 수 있습니다. 이 시나리오에서 피어 1과 피어 2는 동일한 사전 공유 키를 사용하여 데이터를 암호화하고 해독합니다.

  7. Next(다음)를 클릭합니다.

단계 8

IPSec Settings(IPSec 설정) 섹션에서 CDO는 사용자가 수행한 구성을 기반으로 IKEv2 제안을 제안합니다. 권장 IKE 구성 설정을 계속 사용하거나 새로 정의할 수 있습니다. IPSec 설정에 대한 자세한 내용은 IPsec 제안 구성을 참고하십시오.

  1. + IKEv2 Proposals(+ IKEv2 제안)를 클릭하여 IPSec 구성을 선택합니다. IKE Settings(IKE 설정) 단계에서 선택한 항목에 따라 해당 IKEV 제안을 사용할 수 있습니다. 기존 IKEv2 제안을 삭제하려면 선택한 제안 위에 마우스를 올려 놓고 x 아이콘을 클릭합니다.

    참고

     

    Create New IKEv2 Proposals(새 IKEv2 제안 생성)를 클릭하여 새 IKEv2 제안을 생성합니다. 새 IKEv2 정책 생성에 대한 자세한 내용은 IKEv2에 대한 IPSec 제안 구성을 참고하십시오.

  2. Perfect Forward Secrecy용 Diffie-Hellman 그룹을 선택합니다. 자세한 내용은 VPN에서 사용되는 암호화 및 해시 알고리즘를 참조하십시오.

  3. Next(다음)를 클릭합니다.

단계 9

Finish(완료) 섹션에서 구성을 읽고 구성에 만족하는 경우에만 계속 진행하고 Submit(제출)을 클릭하십시오.


새로 구성된 사이트 간 VPN 터널을 표시하는 VPN Tunnels(VPN 터널) 페이지로 이동합니다. 변경 사항이 준비되며 수동으로 구축해야 합니다. VTI 터널을 통해 디바이스 간에 VTI 트래픽을 자동으로 라우팅하도록 라우팅 정책이 생성됩니다. 이 정책을 보려면 Inventory(인벤토리) 페이지에서 디바이스를 선택하고 Configuration(구성) > Diff(차이)를 선택하십시오.

새 터널과 연결된 디바이스에 사이트 간 VPN 구성을 구축하려면 구성 변경 사항 구축 섹션을 참조하십시오.

NAT에서 사이트 간 VPN 트래픽 제외

인터페이스에 사이트 간 VPN 연결이 정의되어 있고 해당 인터페이스에 대한 NAT 규칙도 있는 경우 NAT 규칙에서 VPN의 트래픽을 선택적으로 제외할 수 있습니다. VPN 연결의 원격 쪽에서 내부 주소를 처리할 수 있는 경우 이러한 VPN 트래픽을 제외할 수 있습니다.

VPN 연결을 생성할 때 NAT Exempt(NAT 제외) 옵션을 선택하여 규칙을 자동으로 생성할 수 있습니다. 그러나 브리지 그룹 멤버가 아닌 단일 라우팅 인터페이스를 통해 보호된 로컬 네트워크에 연결하는 경우에만 이 방법을 사용할 수 있습니다. 그렇지 않고 연결의 로컬 네트워크가 둘 이상의 라우팅 인터페이스 또는 하나 이상의 브리지 그룹 멤버에 있는 경우에는 NAT 제외 규칙을 수동으로 구성해야 합니다.

NAT 규칙에서 VPN 트래픽을 제외하려면 대상이 원격 네트워크일 때 로컬 트래픽에 대한 ID 수동 NAT 규칙을 생성합니다. 그런 다음 대상이 인터넷 등의 다른 항목일 때 트래픽에 NAT를 적용합니다. 로컬 네트워크의 인터페이스가 여러 개인 경우 각 인터페이스에 대해 규칙을 생성합니다. 또한 다음과 같은 제안 사항을 고려합니다.

  • 연결에 로컬 네트워크가 여러 개 있으면 네트워크를 정의하는 개체를 포함할 네트워크 개체 그룹을 생성합니다.

  • VPN에 IPv4 및 IPv6 네트워크를 둘 다 포함하는 경우 각 네트워크에 대해 별도의 ID NAT 규칙을 생성합니다.

볼더 사무실과 산호세 사무실을 연결하는 사이트 간 터널을 보여주는 다음 예를 살펴보십시오. 인터넷으로 이동할 트래픽(예: 볼더의 10.1.1.6에서 www.example.com으로)의 경우 인터넷 액세스를 위해 NAT에서 제공하는 공용 IP 주소가 필요합니다. 아래 예에서는 인터페이스 PAT(Port Address Translation) 규칙을 사용합니다. 그러나 VPN 터널을 지나갈 트래픽(예: 볼더의 10.1.1.6에서 산호세의 10.2.2.78로)에 대해서는 NAT를 수행하지 않으려고 합니다. 그렇게 하려면 ID NAT 규칙을 만들어 해당 트래픽을 제외해야 합니다. ID NAT는 주소를 동일한 주소로 변환합니다.

다음 예에서는 방화벽1(볼더)의 컨피그레이션에 대해 설명합니다. 이 예에서는 내부 인터페이스가 브리지 그룹이라고 가정하므로 각 멤버 인터페이스에 대해 규칙을 작성해야 합니다. 라우팅 내부 인터페이스가 하나이든 여러 개이든 프로세스는 동일합니다.


Note


이 예에서는 IPv4만 사용한다고 가정합니다. VPN에 IPv6 네트워크도 포함되어 있으면 IPv6용 병렬 규칙을 생성합니다. IPv6 인터페이스 PAT를 구현할 수는 없으므로 PAT에 사용할 고유 IPv6 주소가 포함된 호스트 개체를 생성해야 합니다.


Procedure

Step 1

여러 네트워크를 정의하기 위한 개체를 생성합니다.

  1. 왼쪽 창에서 개체를 클릭합니다.

  2. 파란색 더하기 버튼 을 클릭하여 개체를 생성합니다.

  3. ASA > Network(ASA 네트워크)를 클릭합니다.

  4. 볼더 내부 네트워크를 확인합니다.

  5. 개체 이름을 입력합니다(예: boulder-network).

  6. Create a network object(네트워크 개체 생성)를 선택합니다.

  7. Value(값) 섹션에서 다음을 수행합니다.

    • eq를 선택하고 단일 IP 주소 또는 CIDR 표기법으로 표시된 서브넷 주소를 입력합니다.

    • 범위를 선택하고 IP 주소 범위를 입력합니다. 예를 들어 네트워크 주소를 10.1.1.0/24로 입력합니다.

  8. Add(추가)를 클릭합니다.

  9. 파란색 더하기 버튼 을 클릭하여 개체를 생성합니다.

  10. 내부 산호세 네트워크를 정의합니다.

  11. 개체 이름(예: san-jose)을 입력합니다.

  12. Create a network object(네트워크 개체 생성)를 선택합니다.

  13. Value(값) 섹션에서 다음을 수행합니다.

    • eq를 선택하고 단일 IP 주소 또는 CIDR 표기법으로 표시된 서브넷 주소를 입력합니다.

    • 범위를 선택하고 IP 주소 범위를 입력합니다. 예를 들어 네트워크 주소를 10.1.1.0/24로 입력합니다.

  14. Add(추가)를 클릭합니다.

Step 2

방화벽1(볼더)에서 VPN을 통해 산호세로 이동할 때 볼더 네트워크용 수동 ID NAT를 구성합니다.

  1. 왼쪽 창에서 Inventory(재고 목록)를 클릭합니다.

  2. 필터를 사용하여 NAT 규칙을 생성할 디바이스를 찾습니다.

  3. 상세정보 패널의 Management(관리) 영역에서 NAT를 클릭합니다.

  4. > 2회 NAT를 클릭합니다.

    • 섹션 1에서 Static(정적)을 선택합니다. Continue(계속)를 클릭합니다.

    • 섹션 2에서 Source Interface(소스 인터페이스) = inside(내부)Destination Interface(대상 인터페이스) = outside(외부)를 선택합니다. Continue(계속)를 클릭합니다.

    • 섹션 3에서 Source Original Address(소스 원본 주소) = 'boulder-network' 및 Source Translated Address(소스 변환 주소) = 'boulder-network'를 선택합니다.

    • Use Destination(대상 사용)을 선택합니다.

    • Destination Original Address(대상 원본 주소) = 'sanjose-network' 및 Source Translated Address(소스 변환 주소) = 'sanjose-network'를 선택합니다. 참고: 대상 주소를 변환하지 않을 것이기 때문에 원본 주소 및 변환된 대상 주소에 대해 동일한 주소를 지정하여 대상 주소에 대한 ID NAT를 구성해야 합니다. 포트 필드는 모두 비워 둡니다. 이 규칙은 소스 및 대상 둘 다에 대해 ID NAT를 구성합니다.

    • Disable proxy ARP for Incoming packet(수신 패킷에 대해 프록시 ARP 비활성화)을 선택합니다.

    • Save(저장)를 클릭합니다.

    • 이 프로세스를 반복하여 각각의 기타 내부 인터페이스에 대해 동일 규칙을 생성합니다.

Step 3

방화벽1(볼더)에서 내부 볼더 네트워크에 대해 인터넷으로 이동할 때 수동 동적 인터페이스 PAT를 구성합니다. 참고: 모든 IPv4 트래픽에 적용되는 내부 인터페이스용 동적 인터페이스 PAT 규칙은 이미 있을 수 있습니다. 이러한 규칙은 초기 구성 중에 기본적으로 생성되기 때문입니다. 그러나 여기서는 완전한 설명을 위해 컨피그레이션을 제공합니다. 이러한 단계를 완료하기 전에 내부 인터페이스와 네트워크에 적용되는 규칙이 이미 있는지 확인하고 해당 규칙이 있으면 이 단계를 건너뜁니다.

  1. > 2회 NAT를 클릭합니다.

  2. 섹션 1에서 Dynamic(동적)을 선택합니다. Continue(계속)를 클릭합니다.

  3. 섹션 2에서 Source Interface(소스 인터페이스) = inside(내부)Destination Interface(대상 인터페이스) = outside(외부)를 선택합니다. Continue(계속)를 클릭합니다.

  4. 섹션 3에서 Source Original Address(소스 원본 주소) = 'boulder-network' 및 Source Translated Address(소스 변환 주소) = 'interface'를 선택합니다.

  5. Save(저장)를 클릭합니다.

  6. 이 프로세스를 반복하여 각각의 기타 내부 인터페이스에 대해 동일 규칙을 생성합니다.

Step 4

CDO에 구성 변경 사항을 구축합니다. 자세한 내용은 CDO GUI를 사용하여 구성 변경 사항 구축를 참고하십시오.

Step 5

방화벽2(산호세)도 관리하는 경우 해당 디바이스에 대해 비슷한 규칙을 구성할 수 있습니다.

  • 대상이 boulder-network일 때는 sanjose-network용 수동 ID NAT 규칙을 구성합니다. 방화벽2 내부 및 외부 네트워크용으로 새 인터페이스 개체를 생성합니다.

  • 대상이 "임의"일 때는 sanjose-network용 수동 동적 인터페이스 PAT 규칙을 생성합니다.


ASA와 멀티 클라우드 방어 게이트웨이 사이에 사이트 간 VPN 구성

모든 관련 표준을 준수하는 ASA와 멀티 클라우드 방어 게이트웨이 사이에 사이트 간 IPsec 연결을 생성할 수 있습니다. VPN 연결이 설정되면 방화벽 뒤에 있는 호스트는 보안 VPN 터널을 통해 게이트웨이 뒤에 있는 호스트에 연결할 수 있습니다.

멀티 클라우드 방어에서는 현재 AWS(Amazon Web Services), Azure, GCP(Google Cloud Platform) 및 Oracle OCI 클라우드 어카운트를 지원합니다.

ASA와 멀티 클라우드 방어 게이트웨이 사이에 사이트 간 VPN 터널 생성

다음 절차를 수행하여 CDO에 의해 관리되는 ASA 디바이스와 CDO 대시보드의 멀티 클라우드 방어 게이트웨이 사이에 VPN 터널을 생성합니다.

시작하기 전에

다음 사전 요건이 충족되는지 확인합니다.

프로시저

단계 1

왼쪽 창에서 VPN > 사이트 간 VPN(사이트 간 VPN)을 선택합니다.

단계 2

오른쪽 상단의 터널 생성() 버튼을 클릭하고 멀티 클라우드 방어 레이블을 가진 사이트 간 VPN을 클릭합니다.

단계 3

Configuration Name(구성 이름) 필드에 생성한 사이트 간 VPN 구성의 이름을 입력합니다.

단계 4

피어 디바이스 영역에서 다음 정보를 입력합니다.

  • 디바이스 1: 드롭다운 목록 에서 ASA 탭을 클릭하고 원하는 ASA 디바이스를 선택합니다.

  • 디바이스 2: 드롭다운 목록 에서 멀티 클라우드 방어 탭을 클릭하고 원하는 게이트웨이를 선택합니다.

  • VPN 액세스 인터페이스: 멀티 클라우드 방어에 연결하는 데 사용할 ASA 인터페이스를 선택합니다.

  • Public IP (선택 사항): 선택한 ASA의 외부 인터페이스에 매핑되는 네트워크 주소 변환(NAT)의 공용 IP 주소를 지정합니다.

  • 라우팅 : Add Networks(네트워크 추가)를 클릭하고 ASA에서 보호된 네트워크를 하나 이상 선택하여 선택한 네트워크 및 멀티 클라우드 방어 게이트웨이 사이에 사이트 간 터널을 생성합니다.

단계 5

Next(다음)를 클릭합니다.

단계 6

Tunnel Details(터널 상세정보) 영역에서 다음 정보를 제공합니다.

  • Virtual Tunnel Interface IP(가상 터널 인터페이스 IP): 피어에서 새 가상 터널 인터페이스의 주소를 지정합니다. CDO는 충돌이 발생하는 경우 변경할 수 있는 ASA에 대한 샘플 주소를 제공합니다. 이 디바이스에서 현재 사용되지 않는 미사용 IP 주소를 할당할 수 있습니다.

  • 자동 시스템 번호(피어 1): ASA 디바이스에 자동 시스템 번호가 구성되어 있지 않은 경우 CDO는 디바이스에 대해 자동 시스템 번호를 제안하며, 이 번호는 수정할 수 있습니다. 디바이스에 이미 자동 시스템 번호가 구성된 경우 현재 값이 표시되고 수정할 수 없습니다.

  • 자동 시스템 번호(피어 2): BGP 프로파일이 멀티 클라우드 방어 게이트웨이에 할당된 경우 프로파일과 연결된 자동 번호가 표시되며 이는 수정할 수 없습니다. 멀티 클라우드 방어 게이트웨이 추가를 참조하십시오.

단계 7

Next(다음)를 클릭합니다.

단계 8

IKE 설정 영역 에서 CDO는 기본 사전 공유 키를 생성합니다. 이것은 피어에 구성된 암호 키 문자열입니다. IKE는 인증 단계 중에 이 키를 사용합니다. 피어 간에 터널을 설정할 때 서로를 확인하는 데 사용됩니다.

단계 9

Next(다음)를 클릭합니다.

단계 10

Finish(완료) 영역에서 구성을 검토하고 구성에 만족하는 경우에만 계속 진행합니다.

기본적으로 Deploy changes to ASA immediately(ASA에 즉시 변경 사항 구축) 확인란이 선택되어 Submit(제출)을 클릭한 후 ASA 디바이스에 즉시 구성을 구축합니다.

나중에 수동으로 설정을 검토하고 구축하려면 이 확인란의 선택을 취소합니다 .

단계 11

Submit(제출)를 클릭합니다.

구성은 멀티 클라우드 방어 게이트웨이로 푸시됩니다.


CDO의 VPN 페이지에는 피어 간에 생성된 사이트 간 터널이 표시됩니다. 멀티 클라우드 방어 게이트웨이 포털에서 해당 터널을 확인할 수 있습니다.

전역 IKE 정책 정보

IKE(Internet Key Exchange)는 IPsec 피어를 인증하고, IPsec 암호화 키를 협상 및 배포하고, IPsec SA(보안 연계)를 자동으로 설정하는 데 사용되는 키 관리 프로토콜입니다.

IKE 협상은 2단계로 구성됩니다. 1단계에서는 두 IKE 피어 간의 보안 연계를 협상합니다. 그러면 피어가 2단계에서 안전하게 통신할 수 있습니다. 2단계 협상 중에는 IKE가 IPsec 등의 기타 애플리케이션에 대해 SA를 설정합니다. 두 단계에서는 모두 연결을 협상할 때 제안을 사용합니다. IKE 제안은 두 피어가 상호 간의 IKE 협상을 보호하는 데 사용하는 알고리즘 집합입니다. IKE 협상에서는 두 피어가 먼저 공통(공유) IKE 정책을 합의합니다. 이 정책은 후속 IKE 협상을 보호하는 데 사용되는 보안 파라미터를 제시합니다.

IKE 정책 개체는 이러한 협상을 위한 IKE 제안을 정의합니다. 활성화하는 개체는 피어가 VPN 연결을 협상할 때 사용됩니다. 연결당 서로 다른 IKE 정책을 지정할 수는 없습니다. 각 개체의 상대 우선 순위에 따라 이러한 정책 중 먼저 사용을 시도할 정책이 결정되며, 숫자가 작을수록 우선 순위는 높습니다. 협상에서 장애가 발생하여 두 피어가 모두 지원할 수 있는 정책을 찾지 못하면 연결이 설정되지 않습니다.

글로벌 IKE 정책을 정의하려면 각 IKE 버전에 대해 활성화할 개체를 선택합니다. 사전 정의된 개체가 요건을 충족하지 않는 경우 새 정책을 생성하여 보안 정책을 적용합니다.

다음 절차에서는 개체 페이지를 통해 글로벌 정책을 구성하는 방법을 설명합니다. IKE 정책 설정에서 Edit(수정)을 클릭하여 VPN 연결을 수정할 때 정책을 활성화, 비활성화 및 생성할 수도 있습니다.

다음 항목에서는 각 버전에 대해 IKE 정책을 구성하는 방법에 대해 설명합니다.

IKEv1 정책 관리

IKEv1 정책 정보

IKE(Internet Key Exchange) 버전 1 정책 개체에는 VPN 연결을 정의할 때 IKEv1 정책에 필요한 파라미터가 포함되어 있습니다. IKE는 IPsec 기반 통신을 쉽게 관리할 수 있도록 하는 키 관리 프로토콜이며 IPsec 피어를 인증하고, IPsec 암호화 키를 협상 및 배포하고, IPsec SA(보안 연계)를 자동으로 설정하는 데 사용됩니다.

여러 가지 사전 정의된 IKEv1 정책이 있습니다. 필요에 맞는 정책이 있으면 State(상태) 토글을 클릭하여 활성화하면 됩니다. 새 정책을 생성하여 다른 보안 설정 조합을 구현할 수도 있습니다. 시스템 정의 개체는 수정하거나 삭제할 수 없습니다.

IKEv1 정책 생성

IKE(Internet Key Exchange) 버전 1 정책 개체에는 VPN 연결을 정의할 때 IKEv1 정책에 필요한 파라미터가 포함되어 있습니다. IKE는 IPsec 기반 통신을 쉽게 관리할 수 있도록 하는 키 관리 프로토콜이며 IPsec 피어를 인증하고, IPsec 암호화 키를 협상 및 배포하고, IPsec SA(보안 연계)를 자동으로 설정하는 데 사용됩니다.

여러 가지 사전 정의된 IKEv1 정책이 있습니다. 필요에 맞는 정책이 있으면 State(상태) 토글을 클릭하여 활성화하면 됩니다. 새 정책을 생성하여 다른 보안 설정 조합을 구현할 수도 있습니다. 시스템 정의 개체는 수정하거나 삭제할 수 없습니다.

다음 절차에서는 개체 페이지를 통해 개체를 직접 생성하고 편집할 수 있는 방법을 설명합니다. 개체 목록에 표시되는 Create New IKE Policy(새 IKE 정책 생성) 링크를 클릭하여 사이트 간 VPN 연결에서 IKE 설정을 편집하면서 IKEv1 정책을 생성할 수도 있습니다.

Procedure

Step 1

왼쪽 창에서 개체를 클릭합니다.

Step 2

다음 중 하나를 수행합니다.

  • 파란색 더하기 버튼을 클릭하고 FDM > IKEv1 Policy(IKEv1 정책)를 선택하여 새 IKEv1 정책을 생성합니다.

  • 개체 페이지에서 편집할 IKEv1 정책을 선택하고 오른쪽의 Actions(작업) 창에서 Edit(편집)를 클릭합니다.

Step 3

개체 이름을 최대 128자로 입력합니다.

Step 4

IKEv1 속성을 구성합니다.

  • Priority(우선순위)—IKE 정책의 상대 우선 순위는 1~65,535입니다. 우선 순위에 따라 일반 SA(보안 연계) 찾기를 시도할 때 두 협상 피어가 비교하는 IKE 정책의 순서가 결정됩니다. 원격 IPsec 피어는 최고 우선 순위 정책에서 선택한 파라미터를 지원하지 않는 경우 그 다음 우선 순위에 정의된 파라미터 사용을 시도합니다. 번호가 낮을수록 우선 순위가 높습니다.

  • Encryption(암호화) - 2단계 협상 보호를 위한 1단계 SA(보안 연계)를 설정하는 데 사용되는 암호화 알고리즘입니다. 옵션에 대한 설명은 사용할 암호화 알고리즘 결정을 참조하십시오.

  • Diffie-Hellman Group(Diffie-Hellman 그룹) - 공유 암호를 각 IPsec 피어에 전송하지 않고 두 IPsec 피어 간에 파생하는 데 사용할 Diffie Hellman 그룹입니다. 대형 모듈러스는 보안성은 더 높지만, 처리 시간이 더 오래 걸립니다. 두 피어의 모듈러스 그룹이 일치해야 합니다. 옵션에 대한 설명은 사용할 Diffie-Hellman 모듈러스 그룹 결정을 참조하십시오.

  • Lifetime(라이프타임)—SA(보안 연결)의 라이프타임(초)으로, 120~2147483647의 값이거나 비어 있습니다. 라이프타임이 초과되면 SA는 만료되며 두 피어 간에 SA를 재협상해야 합니다. 일반적으로 특정 지점까지는 라이프타임이 짧을수록 IKE 협상이 보다 안전합니다. 그러나 라이프타임이 길면 라이프타임이 짧은 경우에 비해 이후 IPsec 보안 연계를 더 빠르게 설정할 수 있습니다. 기본값은 86400입니다. 무제한 라이프타임을 지정하려면 아무 값도 입력하지 않고 필드를 비워 둡니다.

  • Authentication(인증) - 두 피어 간에 사용할 인증 방법입니다. 자세한 내용은 사용할 인증 방법 결정을 참조하십시오.

    • Preshared Key(사전 공유 키) - 각 디바이스에 정의된 사전 공유 키를 사용합니다. 이 키를 사용하면 보안 키를 두 피어 간에 공유할 수 있으며 인증 단계 수행 시 IKE에서 보안 키를 사용할 수 있습니다. 동일한 사전 공유 키를 사용하여 피어를 구성하지 않으면 IKE SA를 설정할 수 없습니다.

    • Certificate(인증서) - 서로 식별할 피어에 대해 디바이스 ID 인증서를 사용합니다. Certificate Authority에서 각 피어를 등록하여 이 인증서를 가져와야 합니다. 또한 각 피어에서 ID 인증서 서명에 사용되는 신뢰할 수 있는 CA 루트 및 중간 CA 인증서를 업로드해야 합니다. 피어는 동일한 또는 다른 CA에 등록할 수 있습니다. 어느 피어든 간에 SSC(자가서명 인증서)를 사용할 수 없습니다.

  • Hash(해시) - 메시지 무결성을 보장하는 데 사용되는 메시지 다이제스트를 생성하기 위한 해시 알고리즘입니다. 옵션에 대한 설명은 사용할 해시 알고리즘 결정을 참조하십시오.

Step 5

Add(추가)를 클릭합니다.


IKEv2 정책 관리

IKEv2 정책 정보

IKE(Internet Key Exchange) 버전 2 정책 개체에는 VPN 연결을 정의할 때 IKEv2 정책에 필요한 파라미터가 포함되어 있습니다. IKE는 IPsec 기반 통신을 쉽게 관리할 수 있도록 하는 키 관리 프로토콜이며 IPsec 피어를 인증하고, IPsec 암호화 키를 협상 및 배포하고, IPsec SA(보안 연계)를 자동으로 설정하는 데 사용됩니다.

여러 가지 사전 정의된 IKEv2 정책이 있습니다. 필요에 맞는 정책이 있으면 State(상태) 토글을 클릭하여 활성화하면 됩니다. 새 정책을 생성하여 다른 보안 설정 조합을 구현할 수도 있습니다. 시스템 정의 개체는 수정하거나 삭제할 수 없습니다.

IKEv2 정책 생성

IKE(Internet Key Exchange) 버전 2 정책 개체에는 VPN 연결을 정의할 때 IKEv2 정책에 필요한 파라미터가 포함되어 있습니다. IKE는 IPsec 기반 통신을 쉽게 관리할 수 있도록 하는 키 관리 프로토콜이며 IPsec 피어를 인증하고, IPsec 암호화 키를 협상 및 배포하고, IPsec SA(보안 연계)를 자동으로 설정하는 데 사용됩니다.

여러 가지 사전 정의된 IKEv2 정책이 있습니다. 필요에 맞는 정책이 있으면 State(상태) 토글을 클릭하여 활성화하면 됩니다. 새 정책을 생성하여 다른 보안 설정 조합을 구현할 수도 있습니다. 시스템 정의 개체는 수정하거나 삭제할 수 없습니다.

다음 절차에서는 개체 페이지를 통해 개체를 직접 생성하고 편집할 수 있는 방법을 설명합니다. 개체 목록에 표시되는 Create New IKEv2 Policy(새 IKEv2 정책 생성) 링크를 클릭하여 사이트 간 VPN 연결에서 IKE 설정을 편집하면서 IKEv2 정책을 생성할 수도 있습니다.

Procedure

Step 1

왼쪽 창에서 개체를 클릭합니다.

Step 2

다음 중 하나를 수행합니다.

  • 파란색 더하기 버튼을 클릭하고 FTD > IKEv2 Policy(IKEv2 정책)를 선택하여 새 IKEv2 정책을 생성합니다.

  • 개체 페이지에서 편집할 IKEv2 정책을 선택하고 오른쪽의 Actions(작업) 창에서 Edit(편집)를 클릭합니다.

Step 3

개체 이름을 최대 128자로 입력합니다.

Step 4

IKEv2 속성을 구성합니다.

  • Priority(우선순위)—IKE 정책의 상대 우선 순위는 1~65,535입니다. 우선 순위에 따라 일반 SA(보안 연계) 찾기를 시도할 때 두 협상 피어가 비교하는 IKE 정책의 순서가 결정됩니다. 원격 IPsec 피어는 최고 우선 순위 정책에서 선택한 파라미터를 지원하지 않는 경우 그 다음 우선 순위에 정의된 파라미터 사용을 시도합니다. 번호가 낮을수록 우선 순위가 높습니다.

  • State(상태) - IKE 정책이 활성화되어 있는지 여부입니다. 토글을 클릭하여 상태를 변경합니다. IKE 협상 중에는 활성화된 정책만 사용됩니다.

  • Encryption(암호화) - 2단계 협상 보호를 위한 1단계 SA(보안 연계)를 설정하는 데 사용되는 암호화 알고리즘입니다. 허용하려는 모든 알고리즘을 선택합니다. 단, 같은 정책에 혼합 모드(AES-GCM) 및 일반 모드 옵션을 둘 다 포함할 수는 없습니다. 일반 모드에서는 무결성 해시를 선택해야 하는 반면 혼합 모드에서는 개별 무결성 해시 선택이 금지됩니다. 시스템은 일치하는 항목이 합의될 때까지 가장 강력한 알고리즘에서 가장 취약한 알고리즘 순서대로 피어와 협상을 합니다. 옵션에 대한 설명은 사용할 암호화 알고리즘 결정을 참조하십시오.

  • Diffie-Hellman Group(Diffie-Hellman 그룹) - 공유 암호를 각 IPsec 피어에 전송하지 않고 두 IPsec 피어 간에 파생하는 데 사용할 Diffie Hellman 그룹입니다. 대형 모듈러스는 보안성은 더 높지만, 처리 시간이 더 오래 걸립니다. 두 피어의 모듈러스 그룹이 일치해야 합니다. 허용하려는 모든 알고리즘을 선택합니다. 시스템은 일치하는 항목이 합의될 때까지 가장 강력한 그룹에서 가장 취약한 그룹 순서대로 피어와 협상을 합니다. 옵션에 대한 설명은 사용할 Diffie-Hellman 모듈러스 그룹 결정을 참조하십시오.

  • Integrity Hash(무결성 해시) - 메시지 무결성을 보장하는 데 사용되는 메시지 다이제스트를 생성하기 위한 해시 알고리즘의 무결성 부분입니다. 허용하려는 모든 알고리즘을 선택합니다. 시스템은 일치하는 항목이 합의될 때까지 가장 강력한 알고리즘에서 가장 취약한 알고리즘 순서대로 피어와 협상을 합니다. AES-GCM 암호화 옵션에서는 무결성 해시가 사용되지 않습니다. 옵션에 대한 설명은 사용할 해시 알고리즘 결정을 참조하십시오.

  • PRF(Pseudo-Random Function) 해시 - 해시 알고리즘의 PRF(Pseudo Random Function) 부분으로, IKEv2 터널 암호화에 필요한 키 요소 및 해싱 작업을 파생시키기 위해 알고리즘으로 사용됩니다. IKEv1에서는 무결성 및 PRF 알고리즘이 구분되지 않지만 IKEv2에서는 이러한 요소에 대해 서로 다른 알고리즘을 지정할 수 있습니다. 허용하려는 모든 알고리즘을 선택합니다. 시스템은 일치하는 항목이 합의될 때까지 가장 강력한 알고리즘에서 가장 취약한 알고리즘 순서대로 피어와 협상을 합니다. 옵션에 대한 설명은 사용할 해시 알고리즘 결정을 참조하십시오.

  • Lifetime(라이프타임)—SA(보안 연결)의 라이프타임(초)으로, 120~2147483647의 값이거나 비어 있습니다. 라이프타임이 초과되면 SA는 만료되며 두 피어 간에 SA를 재협상해야 합니다. 일반적으로 특정 지점까지는 라이프타임이 짧을수록 IKE 협상이 보다 안전합니다. 그러나 라이프타임이 길면 라이프타임이 짧은 경우에 비해 이후 IPsec 보안 연계를 더 빠르게 설정할 수 있습니다. 기본값은 86400입니다. 무제한 라이프타임을 지정하려면 아무 값도 입력하지 않고 필드를 비워 둡니다.

Step 5

Add(추가)를 클릭합니다.


IPsec 제안 정보

IPsec는 가장 안전하게 VPN 설정을 하는 방법 중 하나입니다. IPsec는 IP 패킷 레벨에서 데이터 암호화 기능을 제공하는 강력한 표준 기반 솔루션입니다. IPsec를 사용하는 경우 데이터는 터널을 통해 공용 네트워크를 사용하여 전송됩니다. 터널은 두 피어 간의 안전한 논리적 통신 경로입니다. IPsec 터널로 진입하는 트래픽은 보안 프로토콜 및 알고리즘이 조합된 변환 집합에 의해 보호됩니다. IPsec 보안 연계(SA) 협상 중에 피어는 두 피어에서 동일한 변환 집합을 검색합니다.

IKE 버전(IKEv1 또는 IKEv2)에 따라 각기 다른 IPsec 제안 개체가 있습니다.

  • IKEv1 IPsec 제안을 생성할 때는 IPsec가 동작하는 모드를 선택하고 필요한 암호화 및 인증 유형을 정의합니다. 알고리즘에 대해서는 단일 옵션을 선택할 수 있습니다. VPN에서 여러 조합을 지원하려면 여러 IKEv1 IPsec 제안 개체를 생성하여 선택합니다.

  • IKEv2 IPsec 제안을 생성할 때는 VPN에서 허용되는 모든 암호화 및 해시 알고리즘을 선택할 수 있습니다. 시스템은 가장 안전한 항목부터 가장 안전하지 않은 항목 순으로 설정 순서를 지정하고 일치하는 항목을 찾을 때까지 피어와 협상합니다. 이를 통해 IKEv1과 마찬가지로 허용된 각 조합을 개별적으로 전송하는 대신 모든 허용된 조합을 전달하는 단일 제안서를 보낼 수 있습니다.

IKEv1 및 IKEv2 IPsec 제안에는 모두 ESP(Encapsulating Security Protocol)가 사용됩니다. ESP는 인증, 암호화 및 재생 방지 서비스를 제공합니다. ESP는 IP 프로토콜 유형 50입니다.


Note


IPsec 터널에서는 암호화 및 인증을 모두 사용하는 것이 좋습니다.


다음 항목에서는 각 IKE 버전에 대해 IPsec 제안을 구성하는 방법을 설명합니다.

IKEv1 IPsec 제안 개체 관리

IPsec 제안 개체는 IKE 2단계 협상 중에 사용되는 IPsec 제안을 구성합니다. IPsec 제안은 IPsec 터널에서 트래픽을 보호하는 보안 프로토콜 및 알고리즘 조합을 정의합니다. IKEv1과 IKEv2용으로 별도의 개체가 있습니다. 현재 CDO는 IKEv1 IPsec 제안 개체를 지원합니다.

IKEv1 및 IKEv2 IPsec 제안에는 모두 ESP(Encapsulating Security Protocol)가 사용됩니다. ESP는 인증, 암호화 및 재생 방지 서비스를 제공합니다. ESP는 IP 프로토콜 유형 50입니다.


Note


IPsec 터널에서는 암호화 및 인증을 모두 사용하는 것이 좋습니다.


IKEv1 IPsec 제안 개체 생성

IPsec 제안 개체는 IKE 2단계 협상 중에 사용되는 IPsec 제안을 구성합니다. IPsec 제안은 IPsec 터널에서 트래픽을 보호하는 보안 프로토콜 및 알고리즘 조합을 정의합니다. IKEv1과 IKEv2용으로 별도의 개체가 있습니다. 현재 CDO는 IKEv1 IPsec 제안 개체를 지원합니다.

IKEv1 및 IKEv2 IPsec 제안에는 모두 ESP(Encapsulating Security Protocol)가 사용됩니다. ESP는 인증, 암호화 및 재생 방지 서비스를 제공합니다. ESP는 IP 프로토콜 유형 50입니다.


Note


IPsec 터널에서는 암호화 및 인증을 모두 사용하는 것이 좋습니다.


여러 가지 사전 정의된 IKEv1 IPsec 제안이 있습니다. 새 제안을 생성하여 다른 보안 설정 조합을 구현할 수도 있습니다. 시스템 정의 개체는 수정하거나 삭제할 수 없습니다.

다음 절차에서는 개체 페이지를 통해 개체를 직접 생성하고 편집할 수 있는 방법을 설명합니다. 개체 목록에 표시되는 Create New IKEv1 Proposal(새 IKEv1 제안 생성) 링크를 클릭하여 사이트 간 VPN 연결에서 IKEv1 IPsec 설정을 편집하면서 IKEv1 IPsec 제안 개체를 생성할 수도 있습니다.

Procedure

Step 1

왼쪽 창에서 개체를 클릭합니다.

Step 2

다음 중 하나를 수행합니다.

  • 파란색 플러스 버튼 을 클릭하고 FDM > IKEv1 IPsec Proposal(IKEv1 IPsec 제안)을 선택하여 새 개체를 생성합니다.

  • 개체 페이지에서 편집할 IPsec 제안을 선택하고 오른쪽의 작업 창에서 Edit(편집)를 클릭합니다.

Step 3

새 개체의 개체 이름을 입력합니다.

Step 4

IKEv1 IPsec 제안 개체가 작동하는 모드를 선택합니다.

  • 터널 모드에서는 전체 IP 패킷이 캡슐화됩니다. IPSec 헤더는 원본 IP 헤더와 새 IP 헤더 사이에 추가됩니다. 이는 기본값입니다. 방화벽 뒤에 배치되어 있는 호스트와 주고받는 트래픽을 방화벽이 보호하는 경우 터널 모드를 사용합니다. 터널 모드는 인터넷 등의 신뢰할 수 없는 네트워크를 통해 연결하는 두 방화벽 또는 기타 보안 게이트웨이 간에 일반 IPsec이 구현되는 통상적인 방식입니다.

  • 전송 모드에서는 IP 패킷의 상위 레이어 프로토콜만 캡슐화됩니다. IPSec 헤더는 TCP 등의 상위 계층 프로토콜 헤더와 IP 헤더 사이에 삽입됩니다. 전송 모드에서는 소스 호스트와 대상 호스트가 모두 IPsec를 지원해야 합니다. 터널의 대상 피어가 IP 패킷의 최종 대상인 경우에만 전송 모드를 사용할 수 있습니다. 전송 모드는 대개 GRE, L2TP, DLSW 등의 레이어 2 또는 레이어 3 터널링 프로토콜을 보호할 때만 사용됩니다.

Step 5

이 제안에 대한 ESP Encryption(ESP 암호화)(Encapsulating Security Protocol) 알고리즘을 선택합니다. 자세한 내용은 사용할 암호화 알고리즘 결정을 참조하십시요.

Step 6

인증에 사용할 ESP Hash(ESP 해시) 또는 무결성 알고리즘을 선택합니다. 자세한 내용은 사용할 해시 알고리즘 결정을 참조하십시오.

Step 7

Add(추가)를 클릭합니다.


IKEv2 IPsec 제안 개체 관리

IPsec 제안 개체는 IKE 2단계 협상 중에 사용되는 IPsec 제안을 구성합니다. IPsec 제안은 IPsec 터널에서 트래픽을 보호하는 보안 프로토콜 및 알고리즘 조합을 정의합니다.

IKEv2 IPsec 제안을 생성할 때는 VPN에서 허용되는 모든 암호화 및 해시 알고리즘을 선택할 수 있습니다. 시스템은 가장 안전한 항목부터 가장 안전하지 않은 항목 순으로 설정 순서를 지정하고 일치하는 항목을 찾을 때까지 피어와 협상합니다. 이를 통해 IKEv1과 마찬가지로 허용된 각 조합을 개별적으로 전송하는 대신 모든 허용된 조합을 전달하는 단일 제안서를 보낼 수 있습니다.

IKEv2 IPsec 제안 개체 생성 또는 편집

여러 가지 사전 정의된 IKEv2 IPsec 제안이 있습니다. 새 제안을 생성하여 다른 보안 설정 조합을 구현할 수도 있습니다. 시스템 정의 개체는 수정하거나 삭제할 수 없습니다.

다음 절차에서는 개체 페이지를 통해 개체를 직접 생성하고 편집할 수 있는 방법을 설명합니다. 개체 목록에 표시되는 Create New IPsec Proposal(새 IPsec 제안 생성) 링크를 클릭하여 VPN 연결에서 IKEv2 IPsec 설정을 편집하면서 IKEv2 IPsec 제안 개체를 생성할 수도 있습니다.

Procedure

Step 1

왼쪽 창에서 개체를 클릭합니다.

Step 2

다음 중 하나를 수행합니다.

  • 파란색 플러스 버튼 을 클릭하고 FDM > IKEv2 IPsec Proposal(IKEv2 IPsec 제안)을 선택하여 새 개체를 생성합니다.

  • 개체 페이지에서 편집할 IPsec 제안을 선택하고 오른쪽의 작업 창에서 Edit(편집)를 클릭합니다.

Step 3

새 개체의 개체 이름을 입력합니다.

Step 4

IKE2 IPsec 제안 개체 구성:

  • Encryption(암호화) - 이 제안에 대한 ESP(Encapsulating Security Protocol) 암호화 알고리즘입니다. 허용하려는 모든 알고리즘을 선택합니다. 시스템은 일치하는 항목이 합의될 때까지 가장 강력한 알고리즘에서 가장 취약한 알고리즘 순서대로 피어와 협상을 합니다. 옵션에 대한 설명은 사용할 암호화 알고리즘 결정을 참조하십시오.

  • Integrity Hash(무결성 해시) - 인증에 사용할 해시 또는 무결성 알고리즘입니다. 허용하려는 모든 알고리즘을 선택합니다. 시스템은 일치하는 항목이 합의될 때까지 가장 강력한 알고리즘에서 가장 취약한 알고리즘 순서대로 피어와 협상을 합니다. 옵션에 대한 설명은 사용할 해시 알고리즘 결정을 참조하십시오.

Step 5

Add(추가)를 클릭합니다.


ASA 사이트 간 가상 프라이빗 네트워크 모니터링

CDO를 사용하면 온보딩된 ASA 디바이스에서 이미 존재하는 사이트 간 VPN 구성을 모니터링할 수 있습니다. 사이트 간 구성을 수정하거나 삭제할 수 없습니다.

사이트 투 사이트 VPN 터널 연결 확인

Check Connectivity(연결 확인) 버튼을 사용하여 터널에 대한 실시간 연결 확인을 트리거하여 터널이 현재 활성 상태인지 유휴 상태인지를 식별합니다. 온디맨드 연결 확인 버튼을 클릭하지 않으면 온보딩된 모든 디바이스에서 사용 가능한 모든 터널의 확인이 1시간에 한 번 수행됩니다.


Note


  • CDOASA에서 이 연결성 검사 명령을 실행하여 터널이 활성 상태인지 유휴 상태인지를 확인합니다.
    show vpn-sessiondb l2l sort ipaddress
  • 모델 ASA 디바이스 터널은 항상 유휴로 표시됩니다.


VPN 페이지에서 터널 연결을 확인하려면 다음을 수행합니다.

Procedure

Step 1

왼쪽 창에서 VPN > ASA/FDM 사이트 간 VPN(ASA/FDM 사이트 간 VPN)를 클릭합니다.

Step 2

사이트 투 사이트 VPN 터널에 대한 터널 목록을 검색 및 필터링하고 선택합니다.

Step 3

오른쪽의 작업 창에서 Check Connectivity(연결 확인)를 클릭합니다.


사이트 간 VPN 대시보드

CDO에서는 테넌트에서 생성된 사이트 간 VPN 연결에 대한 통합 정보를 제공합니다.

왼쪽 창에서 Dashboard(대시보드)를 클릭합니다. 사이트 간 VPN은 다음 위젯의 정보를 제공합니다.

  • Sessions and Insights(세션 및 인사이트): 활성 VPN 터널 및 유휴 VPN 터널을 나타내는 막대 그래프를 적절한 색상으로 표시합니다.

  • Issues(문제): 문제로 탐지된 총 터널 수를 표시합니다.

  • Pending Deploy(구축 보류): 보류 중인 구축이 있는 총 터널 수를 표시합니다.

원형 차트 또는 위젯의 링크를 클릭하면 선택한 값에 따라 필터가 적용된 사이트 간 VPN 목록 페이지가 표시됩니다. 예를 들어 VPN 터널 상태 위젯에서 Active VPN Tunnels(활성 VPN 터널)을 클릭하면 활성 상태 필터가 적용된 사이트 간 VPN 목록 페이지로 이동하며 활성 터널만 표시됩니다.

VPN 문제 식별

CDOASA에서 VPN 문제를 식별할 수 있습니다. (이 기능은 아직 AWS VPC 사이트 투 사이트 VPN 터널에 사용할 수 없습니다.) 이 문서에서는 다음을 설명합니다.

누락된 피어가 있는 VPN 터널 찾기

"Missing IP Peer" 상태는 FDM 관리 디바이스보다 ASA 디바이스에서 발생할 가능성이 높습니다.

Procedure

Step 1

왼쪽 창에서 VPN > ASA/FDM Site-to-Site VPN(ASA/FDM 사이트 간 VPN)를 클릭하여 VPN 페이지를 엽니다.

Step 2

Table View(테이블 보기)를 선택합니다.

Step 3

필터 아이콘 을 클릭하여 필터 패널을 엽니다.

Step 4

감지된 문제를 확인합니다.

Step 5

문제 를 보고하는 각 디바이스를 선택하고 오른쪽의 Peers(피어) 창을 확인합니다. 하나의 피어 이름이 나열됩니다. CDO는 다른 피어 이름을 "[Missing peer IP.]"로 보고합니다.


암호화 키 문제가 있는 VPN 피어 찾기

이 접근 방식을 사용하여 다음과 같은 암호화 키 문제가 있는 VPN 피어를 찾습니다.

  • IKEv1 또는 IKEv2 키가 잘못되었거나 누락되었거나 일치하지 않습니다.

  • 사용되지 않거나 낮은 암호화 터널

Procedure

Step 1

왼쪽 창에서 VPN > ASA/FDM Site-to-Site VPN(ASA/FDM 사이트 간 VPN)를 클릭하여 VPN 페이지를 엽니다.

Step 2

Table View(테이블 보기)를 선택합니다.

Step 3

필터 아이콘 을 클릭하여 필터 패널을 엽니다.

Step 4

문제 를 보고하는 각 디바이스를 선택하고 오른쪽의 Peers(피어) 창을 확인합니다. 피어 정보에는 두 피어가 모두 표시됩니다.

Step 5

디바이스 중 하나에 대해 View Peers(피어 보기)를 클릭합니다.

Step 6

Diagram View(다이어그램 보기)에서 문제를 보고하는 디바이스를 두 번 클릭합니다.

Step 7

하단의 Tunnel Details(터널 세부 정보) 창에서 Key Exchange(키 교환)를 클릭합니다. 두 디바이스를 모두 보고 해당 지점에서 주요 문제를 진단할 수 있습니다.


터널에 대해 정의된 불완전하거나 잘못 구성된 액세스 목록 찾기

"불완전하거나 잘못 구성된 액세스 목록" 상태는 ASA 디바이스에서만 발생할 수 있습니다.

Procedure

Step 1

왼쪽 창에서 VPN > ASA/FDM Site-to-Site VPN(ASA/FDM 사이트 간 VPN)를 클릭하여 VPN 페이지를 엽니다.

Step 2

Table View(테이블 보기)를 선택합니다.

Step 3

필터 아이콘 을 클릭하여 필터 패널을 엽니다.

Step 4

문제 를 보고하는 각 디바이스를 선택하고 오른쪽의 Peers(피어) 창을 확인합니다. 피어 정보에는 두 피어가 모두 표시됩니다.

Step 5

디바이스 중 하나에 대해 View Peers(피어 보기)를 클릭합니다.

Step 6

Diagram View(다이어그램 보기)에서 문제를 보고하는 디바이스를 두 번 클릭합니다.

Step 7

하단의 Tunnel Details(터널 세부 정보) 패널에서 Tunnel Details(터널 세부 정보)를 클릭합니다. "Network Policy: Incomplete(네트워크 정책: 완료되지 않음)" 메시지가 표시됩니다.


터널 구성에서 문제 찾기

터널 구성 오류는 다음 시나리오에서 발생할 수 있습니다.

  • 사이트 투 사이트 VPN 인터페이스의 IP 주소가 변경되면 "피어 IP 주소 값이 변경되었습니다."

  • VPN 터널의 IKE 값이 다른 VPN 터널과 일치하지 않으면 "IKE 값 불일치" 메시지가 나타납니다.

Procedure

Step 1

왼쪽 창에서 VPN > ASA/FDM 사이트 간 VPN(ASA/FDM 사이트 간 VPN)를 클릭하여 VPN 페이지를 엽니다.

Step 2

Table View(테이블 보기)를 선택합니다.

Step 3

필터 아이콘 을 클릭하여 필터 패널을 엽니다.

Step 4

터널 문제에서 탐지된 문제를 클릭하여 오류를 보고하는 VPN 구성을 봅니다. 구성 보고 문제 를 볼 수 있습니다.

Step 5

VPN 구성 보고 문제를 선택합니다.

Step 6

오른쪽의 피어 창에 문제가 있는 피어에 대한 아이콘이 나타납니다. 아이콘 위로 마우스를 가져가면 문제와 해결 방법을 볼 수 있습니다.

다음 단계: 터널 구성 문제 해결.


터널 구성 문제 해결

이 절차는 다음과 같은 터널 구성 문제를 해결하려고 시도합니다.

  • 사이트 투 사이트 VPN 인터페이스의 IP 주소가 변경되면 "피어 IP 주소 값이 변경되었습니다."

  • VPN 터널의 IKE 값이 다른 VPN 터널과 일치하지 않으면 "IKE 값 불일치" 메시지가 나타납니다.

자세한 내용은 터널 구성에서 문제 찾기를 참조하십시오.

프로시저

단계 1

왼쪽 창에서 Inventory(재고 목록)를 클릭합니다.

단계 2

Devices(디바이스) 탭을 클릭합니다.

단계 3

적절한 디바이스 유형 탭을 클릭하고 문제를 보고하는 VPN 구성과 연결된 디바이스를 선택합니다.

단계 4

디바이스 변경 사항을 수락합니다.

단계 5

왼쪽 창에서, VPN > ASA/FDM 사이트 간 VPN(사이트 간 VPN)을 클릭하여 VPN 페이지를 엽니다.

단계 6

이 문제를 보고하는 VPN 구성을 선택합니다.

단계 7

Actions(작업)창에서 Edit(편집) 아이콘을 클릭합니다.

단계 8

4단계에서 Finish(마침) 버튼을 클릭할 때까지 각 단계에서 Next(다음)를 클릭합니다.

단계 9

모든 디바이스에 대한 구성 변경 사항 미리보기 및 구축.


사이트 간 VPN 터널 검색 및 필터링

필터 사이드바 를 검색 필드와 함께 사용하여 VPN 터널 다이어그램에 표시된 VPN 터널 검색에 집중할 수 있습니다.

Procedure

Step 1

왼쪽 창에서 VPN > ASA/FDM 사이트 간 VPN를 클릭하여 VPN 페이지를 엽니다.

Step 2

필터 아이콘 을 클릭하여 필터 창을 엽니다.

Step 3

다음 필터를 사용하여 검색을 구체화합니다.

  • Filter by Device(디바이스별 필터링) - Filter by Device(디바이스별 필터링)를 클릭하고 디바이스 유형 탭을 선택한 후 필터링을 통해 찾으려는 디바이스를 선택합니다.

  • Tunnel Issues(터널 문제) - 터널의 양쪽에 문제가 있음을 탐지했는지 여부입니다. 디바이스에 문제가 있는 몇 가지 예로는 연결된 인터페이스 또는 피어 IP 주소 또는 액세스 목록 누락, IKEv1 제안 불일치 등이 있습니다(AWS VPC VPN 터널에서는 터널 문제 탐지를 아직 사용할 수 없음).

  • Devices/Services(디바이스/서비스) -디바이스 유형을 기준으로 필터링합니다.

  • Status(상태) – 터널 상태는 활성 또는 유휴 상태일 수 있습니다.

    • Active(활성) - 네트워크 패킷이 VPN 터널을 통과하는 열린 세션이 있거나 성공적인 세션이 설정되었고 아직 시간 초과되지 않았습니다. Active(활성)는 터널이 활성 상태이고 관련성이 있음을 나타내는 데 도움이 될 수 있습니다.

    • 유휴 - CDO는 이 터널에 대해 열려 있는 세션을 검색할 수 없습니다. 터널이 사용 중이 아니거나 이 터널에 문제가 있을 수 있습니다.

  • Onboarded(온보딩됨) - CDO에서 디바이스를 관리하거나 CDO에서 관리하지 않을 수 있습니다(관리되지 않음).

    • Managed(관리됨) - CDO가 관리하는 디바이스별로 필터링합니다.

    • Unmanaged(관리되지 않음) - CDO가 관리하지 않는 디바이스로 필터링합니다.

  • Device Types(디바이스 유형) - 터널의 한쪽이 라이브(연결된 디바이스) 디바이스인지 아니면 모델 디바이스인지 여부입니다.

Step 4

검색 창에 디바이스 이름 또는 IP 주소를 입력하여 필터링된 결과를 검색할 수도 있습니다. 검색은 대/소문자를 구분하지 않습니다.


관리되지 않는 사이트 간 VPN 피어 온보딩

CDO는 피어 중 하나가 온보딩될 때 사이트 간 VPN 터널을 검색 합니다. 두 번째 피어가 CDO에서 관리되지 않는 경우 VPN 터널 목록을 필터링하여 관리되지 않는 디바이스를 찾아 온보딩할 수 있습니다.

Procedure

Step 1

왼쪽 창에서 VPN > ASA/FDM Site-to-Site VPN(ASA/FDM 사이트 간 VPN)를 클릭하여 VPN 페이지를 엽니다.

Step 2

Table View(테이블 보기)를 선택합니다.

Step 3

를 클릭하여 필터 패널을 엽니다.

Step 4

Unmanaged(관리되지 않음)를 선택합니다.

Step 5

결과의 테이블에서 터널을 선택합니다.

Step 6

오른쪽의 Peers(피어) 창에서 Onboard Device(온보드 디바이스)를 클릭하고 화면의 지침을 따릅니다.


사이트 투 사이트 VPN 터널의 IKE 개체 세부 정보 보기

선택한 터널의 피어/디바이스에 구성된 IKE 개체의 세부 정보를 볼 수 있습니다. 이러한 세부 정보는 IKE 정책 개체의 우선 순위에 따라 계층 구조의 트리 구조로 나타납니다.


Note


엑스트라넷 디바이스는 IKE 개체 세부 정보를 표시하지 않습니다.


Procedure

Step 1

왼쪽 창에서 VPN > ASA/FDM Site-to-Site VPN(ASA/FDM 사이트 간 VPN)를 클릭하여 VPN 페이지를 엽니다.

Step 2

VPN Tunnels(VPN 터널) 페이지에서 피어를 연결하는 VPN 터널의 이름을 클릭합니다.

Step 3

오른쪽의 Relationships(관계) 아래에 세부 정보를 보려는 개체를 확장합니다.


사이트 간 VPN 터널 정보 보기

사이트 간 VPN 테이블 보기는 CDO에 온보딩된 모든 디바이스에서 사용 가능한 모든 사이트 간 VPN 터널의 전체 목록입니다. 터널은 이 목록에 한 번만 존재합니다. 테이블에 나열된 터널을 클릭하면 추가 조사를 위해 터널의 피어로 직접 이동할 수 있는 옵션이 오른쪽 사이드바에 제공됩니다.

CDO가 터널의 양쪽을 모두 관리하지 않는 경우 Onboard Device(디바이스 온보딩)를 클릭하여 언매니지드 피어의 온보드 기본 온보딩 페이지를 열 수 있습니다. CDO가 터널의 양쪽을 모두 관리하는 경우 Peer 2(피어 2) 열에 매니지드 디바이스의 이름이 포함됩니다. 그러나 AWS VPC의 경우 Peer 2 열에 VPN 게이트웨이의 IP 주소가 포함됩니다.

테이블 보기에서 사이트 간 VPN 연결을 보려면 다음을 수행합니다.

Procedure

Step 1

왼쪽 창에서 VPN > ASA/FDM Site-to-Site VPN(ASA/FDM 사이트 간 VPN)를 클릭하여 VPN 페이지를 엽니다.

Step 2

Table view(테이블 보기) 버튼을 클릭합니다.

Step 3

Search and Filter Site-to-Site VPN Tunnels(사이트 간 VPN 터널 검색 및 필터링)를 사용하여 특정 터널을 찾거나 전역 보기 그래픽을 확대하여 원하는 VPN 게이트웨이 및 해당 피어를 찾습니다.


사이트 투 사이트 VPN 전역 보기
Procedure

Step 1

왼쪽 창에서 다음을 클릭합니다. VPN > ASA/FDM 사이트 간 VPN(사이트 간 VPN).

Step 2

Global view(전역 보기) 버튼을 클릭합니다.

Step 3

Search and Filter Site-to-Site VPN Tunnels(사이트 간 VPN 터널 검색 및 필터링)를 사용하여 특정 터널을 찾거나 전역 보기 그래픽을 확대하여 원하는 VPN 게이트웨이 및 해당 피어를 찾습니다.

Step 4

전역 보기에 표시된 피어 중 하나를 선택합니다.

Step 5

View Details(세부사항 보기)를 클릭합니다.

Step 6

VPN 터널의 다른 쪽 끝을 클릭하면 CDO에 해당 연결에 대한 Tunnel Details(터널 세부 정보), NAT Information(NAT 정보) 및 Key Exchange(키 교환) 정보가 표시됩니다.

  • Tunnel Details(터널 세부 정보) - 터널에 대한 이름 및 연결 정보를 표시합니다. Refresh(새로 고침) 아이콘을 클릭하면 터널에 대한 연결 정보가 업데이트됩니다.

  • Tunnel Details specific to AWS connections(AWS 연결 관련 터널 세부 정보) -AWS 사이트 투 사이트 연결에 대한 터널 세부 정보는 다른 연결과 약간 다릅니다. AWS VPC에서 VPN 게이트웨이로의 각 연결에 대해 AWS는 2개의 VPN 터널을 생성합니다. 이는 고가용성을 위한 것입니다.

    • 터널의 이름은 VPN 게이트웨이가 연결된 VPC의 이름을 나타냅니다. 터널에 이름이 지정된 IP 주소는 VPN 게이트웨이가 VPC로 인식하는 IP 주소입니다.

    • CDO 연결 상태가 active(활성)로 표시되면 AWS 터널 상태가 Up(가동 중)입니다. CDO 연결 상태가 inactive(비활성)인 경우 AWS 터널 상태는 Down(중단)입니다.

  • NAT Information(NAT 정보) - 사용 중인 NAT 규칙의 유형, 원래 및 변환된 패킷 정보를 표시하고, 해당 터널에 대한 NAT 규칙을 볼 수 있는 NAT 테이블에 대한 링크를 제공합니다. (AWS VPC 사이트 투 사이트 VPN에는 아직 사용할 수 없습니다.)

  • Key Exchange(키 교환) - 터널 및 키 교환 문제에서 사용 중인 암호화 키를 표시합니다. (AWS VPC 사이트 투 사이트 VPN에는 아직 사용할 수 없습니다.)


사이트 간 VPN 터널 창

Tunnels(터널) 창에는 특정 VPN 게이트웨이와 연결된 모든 터널의 목록이 표시됩니다. VPN 게이트웨이와 AWS VPC 간의 사이트 간 VPN 연결의 경우, tunnels(터널) 창에는 VPN 게이트웨이에서 VPC로의 모든 터널이 표시됩니다. VPN 게이트웨이와 AWS VPC 간의 각 사이트 간 VPN 연결에는 2개의 터널이 있으므로 다른 디바이스에 대해 일반적으로 표시되는 터널 수가 두 배입니다.

VPN 게이트웨이 세부 정보

VPN 게이트웨이에 연결된 피어의 수 및 VPN 게이트웨이의 IP 주소를 표시합니다. 이는 VPN Tunnels(VPN 터널) 페이지에만 표시됩니다.

피어 보기

사이트 간 VPN 피어 쌍을 선택하면 Peers(피어) 창에 쌍의 두 디바이스가 나열되며 디바이스 중 하나에 대해 View Peers(피어 보기)를 클릭할 수 있습니다. View Peers(피어 보기)를 클릭하면 디바이스가 연결된 다른 사이트 간 피어가 표시됩니다. 이는 Table(테이블) 보기 및 Global(전역) 보기에 표시됩니다.

CDO 사이트 간 VPN 터널 삭제

Procedure


Step 1

탐색 창에서 VPN > 사이트 간 VPN(사이트 간 VPN)을 선택합니다.

Step 2

삭제할 원하는 사이트 투 사이트 VPN 터널을 선택합니다.

Step 3

오른쪽의 Actions(작업) 창에서 Delete(삭제)를 클릭합니다.


선택한 사이트 투 사이트 VPN 터널이 삭제됩니다.