VPN for VPC 기능

IBM Cloud VPN for VPC 서비스에는 다음 기능이 포함되어 있습니다.

MD-5 및 SHA-1 인증 알고리즘, 2 및 5 DH 그룹, 3-DES 암호화 알고리즘은 2022년 9월 20일에 사용 중단되었으며 더 이상 콘솔에서 지원되지 않습니다.

• 인증 - IBM Cloud VPN for VPC는 1단계 피어 인증을 위해 사전 공유된 키를 지원합니다. 두 단계 모두에서 지원되는 인증 알고리즘은 SHA-256, SHA-384, SHA-512 입니다.

• 작동 중지 피어 발견 -IPsec 피어의 가용성을 발견하기 위한 구성 가능 메커니즘입니다.

• Diffie-Hellman(DH) - VPN 피어 간에 공유 비밀 키를 생성하기 위해 1단계에서 사용되는 키 교환 프로토콜입니다. 선택적으로 사용자는 PFS(Perfect Forward Secrecy)와 2단계 IPsec 협상을 DH 그룹을 사용할 수 있습니다. VPC용 IBM Cloud VPN DH 그룹 14-24 및 31을 지원합니다.

• 암호화- IBM Cloud VPN VPC의 경우 IKE 1단계와 2단계 모두에서 데이터 암호화를 위해 AES-128, AES-192, AES-256 을 지원합니다.

• 고가용성 - IBM Cloud VPN for VPC는 어플라이언스 수준 중복성을 제공하는 두 개의 VPN 디바이스로 구축되었습니다. 정책 기반 VPN은 멤버 간에 공유된 단일 VPN 게이트웨이 IP를 사용하여 활성 대기 모드에서 작동하는 반면, 라우트 기반 VPN은 두 개의 VPN 게이트웨이 IP가 있는 활성-활성 이중화를 제공합니다.

  정적 라우트 기반 VPN은 액티브-액티브 중복성 모드에서 배포됩니다. 두 개의 VPN 터널이 피어 VPN 게이트웨이와 연결됩니다. 그러나 IBM 게이트웨이는 항상 소형 공용 IP를 일차 송신 경로로 사용하여 터널을 사용합니다. 대형 공용 IP를 사용하는 터널은 이차 송신 경로입니다. 두 터널 모두 활성 상태인 경우 IBM VPC에서 온프레미스 네트워크로 가는 트래픽은 일차 송신 경로를 거칩니다. 일차 송신 경로가 비활성화되면 트래픽은 이차 송신 경로를 통과합니다. 온프레미스 VPN 게이트웨이는 선호되는 동일한 경로를 선택하려면 라우트 우선 순위를 사용해야 합니다.

• IKE(Internet Key Exchange) - IKE는 VPN 연결을 설정하는 데 사용되는 IPsec 프로토콜의 일부입니다. IKE 1단계에서, VPN 피어는 Dffie-Hellman(DH) 키 교환을 사용하여 안전하고 인증된 통신 채널을 생성합니다. IKE 2단계에서 피어는 1단계의 보안 채널을 사용하여 IPsec 터널을 위한 매개변수에 대해 협상합니다. IBM Cloud VPN for VPC는 IKEv1(기본 모드) 및 IKEv2를 모두 지원합니다. 지원되는 조합은 정책 협상 정보를 참조하십시오.

• IPsec - 디바이스 간에 보안 통신을 제공하는 프로토콜 스위트입니다. IBM Cloud VPN 는 터널 모드에서 ESP(보안 프로토콜) 패킷을 캡슐화하여 인증 및 전체 패킷 암호화를 제공하는 IPsec의 UDP 캡슐화를 사용합니다.

• 모드 - IBM Cloud VPN for VPC는 정적 라우트 기반 및 정책 기반 VPN 모드를 제공합니다. 정책 기반 VPN을 사용하면 협상된 CIDR 범위와 일치하는 트래픽이 VPN을 통과합니다. 정적 경로 기반 VPN의 경우에는 가상 터널 인터페이스가 작성되며 사용자 정의 경로를 통해 이러한 논리 인터페이스에 라우팅되는 모든 트래픽이 VPN을 통해 통과합니다. 두 VPN 옵션 모두 동일한 기능을 제공합니다.

• PFS(Perfect Forward Secrecy) - PFS는 IPsec 재협상 중에 DH 생성 키가 다시 사용되지 않는지 확인합니다. 키가 손상된 경우, 보호된 보안 연관 수명 동안 전송 중인 데이터만 액세스할 수 있습니다.

VPN 게이트웨이 시작하기

VPN을 작성하기 전에 먼저 VPN 및 기타 리소스에 대해 VPC 및 하나 이상의 서브넷을 작성해야 합니다.

필수는 아니지만 VPN 게이트웨이에 대해 최소 16개의 IP(접두부 28 이하)의 서브넷을 전용화하는 것이 좋습니다. VPN 서브넷 내에 추가 리소스를 프로비저닝하기로 결정한 경우, VPN 게이트웨이에서 사용할 복구 및 유지보수 태스크에 항상 네 개 이상의 IP를 사용할 수 있는지 확인하십시오. VPN 게이트웨이에 필요한 4개의 IP뿐만 아니라, 서브넷에 최대 5개의 IP가 내부 네트워크용으로 예약되어 있으므로 서브넷이 충분히 큰지 확인하십시오.

VPN 게이트웨이를 작성하려면 다음 일반 단계를 따르십시오.

1. VPN 트래픽이 통과할 네트워크 ACL이 설정되어 있는지 확인하세요.

2. 피어 디바이스가 NAT 순회를 지원하며 이 순회가 피어 디바이스에서 사용 가능한지 확인하십시오. 자세한 정보는 VPN 게이트웨이 제한사항을 참조하십시오.

3. 계획 고려사항을 검토하고 VPN 게이트웨이를 작성하십시오.

4. VPN 연결을 작성하십시오.

   IBM Cloud VPN for VPC는 VPC당 구역마다 하나의 라우트 기반 VPN만을 지원합니다.

5. 정적, 라우트 기반 VPN의 경우, 정적 라우팅에 대한 라우팅 테이블을 작성하거나 선택한 다음, VPN 연결 유형을 사용하여 라우트를 작성하십시오.

6. VPN 터널을 통해 온프레미스 네트워크에 연결하십시오.

7. 피어 네트워크에 있는 디바이스로 터널을 통해 ping 또는 데이터 트래픽을 전송하여 VPN 연결을 사용할 수 있는지 확인하십시오.

아키텍처

이 다이어그램에서는 다중 온프레미스 네트워크가 있는 예제 VPN 설정을 설명합니다. VPN은 사용자의 VPC 내의 서브넷에 구성되지만, 구역 내의 모든 서브넷에 있는 인스턴스에서 공유할 수 있습니다. 또한, IKE 및 IPsec 정책을 하나 이상의 VPN 연결에서 사용할 수 있습니다.

정책 협상 정보

두 가지 IKE 협상 단계 모두에서 IPsec 피어는 각각 지원하도록 구성된 보안 매개변수의 제안을 교환하고 구성 세트에 동의해야 합니다. 사용자 정의 IKE 및 IPsec 정책은 IBM Cloud VPN for VPC 사용자가 이 협상 중에 사용되는 이러한 보안 매개변수를 구성하도록 허용합니다.

IKE 및 IPsec 정책을 사용하여 VPN 연결을 구성하는 작업은 선택사항입니다. 정책이 선택되지 않은 경우 기본 제안사항은 _자동 협상_으로 알려진 프로세스를 통해 자동으로 선택됩니다.

이 협상 프로세스에 포함된 기본 보안 매개변수는 다음과 같습니다.

• IKE 단계
• 암호화 알고리즘
• 인증 알고리즘
• Diffie-Hellman 그룹(암호화 키 교환 프로토콜)

IBM Cloud 자동 협상에서는 IKEv2를 사용하기 때문에 온프레미스 디바이스에서도 IKEv2를 사용해야 합니다. 온프레미스 디바이스에서 IKEv2를 지원하지 않을 경우 사용자 정의 IKE 정책을 사용하십시오.

VPN for VPC 유스 케이스

유스 케이스 1: 하나 이상의 피어 네트워크와 연관된 동일한 유형의 단일 원격 피어 디바이스에 대한 VPN 연결

라우트기반 및 정책 기반 VPN 모두 사용자가 하나 이상의 네트워크와 연결된 단일 원격 피어 디바이스에 연결할 수 있도록 허용합니다.

이 유스 케이스는 정책 기반 VPN과 라우트 기반 VPN 사이의 연결에는 적용되지 않습니다. 자세한 정보는 알려진 제한사항의 내용을 참조하십시오.

유스 케이스 2: 다중 원격 피어 디바이스에 대한 VPN 연결

정책 기반 및 라우트 기반 VPN을 둘 다 사용하면 사용자가 다중 VPN 연결을 사용하여 다른 VPC/환경과 연관된 여러 원격 피어 디바이스에 연결할 수 있습니다.

사용 사례 3: FQDN을 이용한 VPN 고급 구성

다음 유스 케이스는 IBM Cloud 에 하나의 VPC가 있고 온프레미스 사이트를 단일 VPN 게이트웨이와 연결하려는 고객을 보여줍니다. 온프레미스 사이트 VPN 게이트웨이는 NAT 디바이스 뒤에 있으며 공용 IP 주소가 없습니다. 온프레미스 VPN 게이트웨이의 로컬 IKE ID는 소유하는 사설 IP 주소입니다. 하나의 FQDN이 NAT 디바이스의 공용 IP 주소와 연관됩니다.

사용 사례 4: 라우팅 기반 VPN을 위한 트래픽 분산

경로 기반 VPN은 백엔드에 2개의 터널이 활성화되어 있습니다. 두 VPN 터널이 모두 가동 중일 때는 터널을 통해 VPN 트래픽을 라우팅하는 데 하나의 터널만 사용됩니다.

VPN은 작은 공인 IP가 있는 터널을 기본 송신 경로로 사용합니다. 기본 송신 경로가 비활성화되면 트래픽은 보조 경로를 통해 흐릅니다. 하나의 터널만 사용하여 트래픽을 라우팅하는 이유는 비대칭 라우팅 문제를 피하기 위해서입니다. 다음 다이어그램은 기본 구성을 보여줍니다. 목적지 10.1.0.0/24 경로를 생성하고 다음 홉이 VPN 연결인 경우, tunnel 1 tunnel 2 모두 켜져 있으면 경로 생성을 위해 VPN 어플라이언스의 개인 IP 10.254.0.2 반환됩니다.

가상 네트워크 인터페이스의 프로토콜 상태 필터링은 비대칭 라우팅 문제를 해결할 수 있는 옵션을 제공합니다. 자세한 내용은 프로토콜 상태 필터링 모드를 참조하세요.

이제 경로 기반 VPN에 대한 연결을 만들 때 VPC 경로의 다음 홉이 VPN 연결인 경우 VPN 게이트웨이 연결의 Up 터널 간에 트래픽을 분배하도록 설정할 수 있습니다. 이 액티브/액티브 이중화 모드를 사용하려면 만들기 또는 vPN 게이트웨이에 연결 추가 때 '트래픽 분산' 기능을 활성화해야 합니다.

다음 다이어그램에서 볼 수 있듯이 트래픽 이그레스는 2개의 터널로 동적으로 라우팅됩니다. 터널이 Up 경우, 개인 IP 주소 10.254.0.2 10.254.0.3 반환되고 VPC 네트워크 서비스가 2개의 경로를 생성합니다. 이러한 경로의 우선 순위가 동일하기 때문에 트래픽은 tunnel 1 tunnel 2 동적으로 흐릅니다.

이 기능을 사용하려면 온프레미스 디바이스가 비대칭 라우팅을 지원하여 네트워크 성능을 높여야 합니다. 또한, 모든 온프레미스 VPN 게이트웨이가 이 사용 사례를 지원하는 것은 아니라는 점에 유의하세요. 예를 들어, VPN 트래픽 송신과 수신이 다른 터널을 통해 이루어지는 경우, 온프레미스 VPN 장치 또는 방화벽에 의해 트래픽이 차단될 수 있습니다.

관련 링크

다음 링크는 IBM Cloud VPN for VPC에 대한 추가 정보를 제공합니다.

• VPN CLI 참조
• VPN API 참조
• VPN Terraform 참조
• VPC 인프라 서비스에 대한 IAM 액세스 관리
• Activity Tracker 이벤트
• VPN 게이트웨이에 대한 FAQ
• VPN 게이트웨이 문제점 해결
• VPN 게이트웨이 할당량