어떤 유형의 VPN 연결( IBM Cloud )이 VPC에 지원되나요?

IBM Cloud 는 다음 유형의 VPC용 VPN을 지원합니다:

• 사이트 간 VPN: 네트워크 간 연결에 사용됩니다.
• 클라이언트-사이트 간 VPN: 개별 사용자의 안전한 원격 액세스를 위해 사용됩니다.

VPC(사이트 간)용 IBM Cloud VPN 란 무엇인가요?

IBM Cloud VPN 는 IBM Cloud Virtual Private Cloud (VPC)와 온프레미스 환경과 같은 다른 사설 네트워크 간에 안전하게 암호화된 연결을 제공합니다. 인터넷을 통해 IPsec 터널을 사용하여 전송 중인 데이터를 보호합니다. 자세한 내용은 사이트 간 VPN 게이트웨이 및 VPC 제품 페이지(IBM Cloud VPN)를 참조하세요.

VPN for VPC, Transit Gateway, Direct Link 의 차이점은 무엇인가요?

다음 표는 VPN for VPC, Transit Gateway, Direct Link 의 차이점을 보여줍니다:

클라이언트-사이트 VPN보다 사이트-사이트 VPN을 사용해야 하는 이유는 무엇인가요?

사이트 간 VPN을 사용하여 IBM Cloud VPC 및 기타 사설 네트워크 간의 데이터 전송을 보호하여 하이브리드 클라우드 아키텍처 및 네트워크 간 통신을 지원합니다. 개별 사용자가 원격 위치에서 안전하게 암호화된 액세스가 필요한 경우 클라이언트-사이트 VPN을 사용하면 원격 근무 시나리오 또는 타사 계약업체에 이상적입니다.

IBM Cloud VPC 어떤 유형의 사이트 간 VPN을 지원하나요?

IBM Cloud VPC 는 다음 유형의 사이트 간 VPN을 지원합니다:

• 정책 기반 VPN: 정의된 IP 정책을 기반으로 트래픽을 라우팅하고 활성-대기 모드로 작동하며 정적 네트워크에 가장 적합합니다. 자세히 보기
• 경로 기반 VPN: 가상 터널 인터페이스와 동적 라우팅(BGP)을 사용하며 액티브-액티브 이중화를 지원하여 복잡하고 확장 가능한 아키텍처에 이상적입니다. 자세히 보기

일반적인 IBM Cloud 사이트 간 VPN 사용 사례는 무엇인가요?

IBM Cloud 사이트 간 VPN for VPC 하이브리드 클라우드 확장, 백업 연결, 지역 간 VPC 통신에 도움이 됩니다. 사이트 간 VPN 사용 사례를 참조하세요.

사이트 간 연결( VPN for VPC )을 백업 연결로 사용할 수 있나요?

예, VPN for VPC 는 일반적으로 Direct Link 의 백업으로 사용되거나 Transit Gateway 와 함께 보조 연결로 사용됩니다. 고가용성을 참조하세요.

IBM Cloud 사이트 간 VPN은 내 데이터를 어떻게 보호하나요?

VPN for VPC 고급 IPsec/IKEv2 암호화 알고리즘을 사용하여 전송 중인 데이터의 기밀성과 무결성을 보장합니다. 정책 협상에 대해 자세히 알아보세요.

VPN이 네트워크 속도에 영향을 주나요?

VPN 암호화는 최소한의 오버헤드를 추가합니다. IBM Cloud 는 안정적인 성능을 위해 VPN을 최적화하지만, 실제 속도는 네트워크 조건과 구성에 따라 달라집니다.

IBM Cloud VPN 연결 문제를 해결하려면 어떻게 해야 하나요?

IBM Cloud VPN 연결 문제를 해결하려면 VPN 대시보드 터널 상태를 확인하고, 경로를 확인하고, 액세스 및 방화벽 규칙을 검토하세요. 자세한 내용은 사이트 간 문제 해결을 참조하세요. IKE 및 IPsec 정책에서 협상, 제안 및 수신 알고리즘과 관련된 문제를 해결하려면 다음을 참조하십시오. IPsec 로그는 어떻게 확인하나요?

VPN 서비스 사용 불가에 대한 알림이 있나요?

VPN 서비스 사용 불가에 대해 알고 싶으시면 유지보수 이벤트에 대한 표준 알림 절차( IBM Cloud )를 참조하세요. IBM Cloud 상태 페이지를 참조하세요.

VPC에 사이트 간 VPN을 설정하는 시작점은 무엇인가요?

VPC에 사이트 간 VPN 설정을 시작하려면 VPN 게이트웨이를 만들어야 합니다. VPN 게이트웨이 만들기를 참조하세요.

IBM Cloud VPC 당 몇 개의 사이트 간 VPN 연결을 설정할 수 있나요?

사이트 간 VPN의 연결 수를 확인하려면 VPN 할당량을 참조하세요.

IBM Cloud 사이트 간 VPN for VPC 에 대한 가격 세부 정보는 어디에서 찾을 수 있나요?

IBM Cloud 사이트 간 VPN for VPC 에 대한 가격 세부 정보를 확인하려면 가격 탭을 참조하세요.

IBM Cloud VPN 에서 어떤 보안 모범 사례를 따라야 하나요?

강력한 암호화를 사용하고, 정기적으로 구성을 업데이트하며, 엄격한 액세스 제어를 적용하세요.

VPN 게이트웨이를 작성할 때 VPN 연결을 동시에 작성할 수 있습니까?

IBM Cloud 콘솔에서는 게이트웨이 및 연결을 동시에 작성할 수 있습니다. API 또는 CLI를 사용하는 경우 VPN 게이트웨이가 작성된 후 VPN 연결을 작성해야 합니다.

VPN이 연결된 VPN 게이트웨이를 삭제하는 경우 연결이 어떻게 됩니까?

VPN 게이트웨이와 함께 VPN 연결이 삭제됩니다.

VPN 게이트웨이 또는 VPN 연결을 삭제하는 경우 IKE 또는 IPsec 정책이 삭제됩니까?

아니요, IKE 및 IPsec 정책은 여러 연결에 적용될 수 있으므로 삭제되지 않습니다.

사이트 간 VPN 연결에서 IKE 및 IPsec에 대한 암호화 알고리즘은 어떻게 선택되나요?

IKE 또는 IPsec 정책에서 여러 알고리즘을 선택하는 경우 최종 선택은 알고리즘을 선택하는 쪽과 알고리즘이 평가되는 순서에 따라 달라집니다. 순서의 차이에 따라 협상 결과가 달라질 수 있습니다.

• IBM Cloud 에서 VPN 연결을 시작하면, 구성된 순서대로 알고리즘을 전송하고 피어가 최종 선택을 합니다. 예를 들어 IBM Cloud 에서 aes128, aes256 를 제안하고 피어에서 aes256, aes128 를 제안하는 경우 피어 구현에 따라 aes128 또는 aes256 중 하나를 선택할 수 있습니다.
• IBM Cloud 이 응답자인 경우 자체적으로 구성된 순서에 따라 첫 번째 매칭 알고리즘을 선택합니다. 예를 들어 IBM Cloud 가 aes128, aes256 로 구성되어 있고 상대방이 aes256, aes128 를 제안하면 aes128 가 선택됩니다.

일관된 알고리즘 선택을 보장하려면 동일한 IKE 및 IPsec 알고리즘을 구성하고 IBM Cloud VPN 게이트웨이와 피어 게이트웨이 모두에서 동일한 우선 순위를 유지하세요.

IPsec 로그는 어떻게 확인하나요?

협상, 제안 및 수신된 알고리즘에 대한 IPsec 로그를 보려면 다음 단계를 따르세요:

1. 먼저, VPN 인스턴스에 대한 로깅 인스턴스를 구성합니다. 자세한 내용은 IBM Cloud 로그 라우팅 서비스 구성하기를 참조하세요.
2. 로깅 인스턴스를 설정한 후에는 VPN에서 생성한 IPsec 로그 항목에 액세스하고 검토할 수 있습니다. 로그 형식 및 사용 가능한 필드에 대한 자세한 내용은 다음에 대한 로그 VPN for VPC 을 참조하세요.

모든 연결 디버깅의 경우, 피어에서 받은 제안에 IBM 측 IKE 및 IPsec 정책과 일치하는 알고리즘이 하나 이상 있는지 확인하세요. 피어와 IBM Cloud 구성 간에 일치하는 알고리즘이 없으면 연결이 설정되지 않습니다.

게이트웨이가 있는 서브넷을 삭제하려고 하는 경우 VPN 게이트웨이는 어떻게 됩니까?

VPN 게이트웨이를 포함한 가상 서버 인스턴스가 있는 경우 서브넷을 삭제할 수 없습니다.

기본 IKE 및 IPsec 정책이 존재합니까?

예. 정책 ID(IKE 또는 IPsec)를 참조하지 않고 VPN 연결을 작성하는 경우 자동 협상이 사용됩니다.

VPN 게이트웨이 프로비저닝 중에 서브넷을 선택해야 하는 이유가 무엇입니까?

게이트웨이는 연결을 설정하기 위해 VPC 서브넷 내에 배포되므로 IBM Cloud 에서 VPN 게이트웨이를 프로비저닝할 때 서브넷을 선택해야 합니다. 라우팅 기반 VPN은 모든 영역에서 연결을 지원할 수 있지만, 게이트웨이 자체는 고가용성과 자동 유지보수를 제공하기 위해 선택한 서브넷에서 4개의 사용 가능한 사설 IP 주소가 필요합니다. 서브넷 접두사 길이가 28보다 짧거나 같은 크기 16 전용 서브넷을 VPN 게이트웨이에 사용하는 것이 가장 좋습니다.

VPN 게이트웨이를 배치하기 위해 사용된 서브넷에서 ACL을 사용하는 경우 어떻게 해야 합니까?

관리 트래픽 및 VPN 터널 트래픽을 허용하기 위해 다음과 같은 ACL 규칙이 설정되어 있는지 확인하십시오. 자세한 내용은 VPN과 함께 사용할 네트워크 ACL 구성하기를 참조하세요.

온프레미스 사설 네트워크와 통신G해야 하는 서브넷에서 ACL을 사용하는 경우 어떻게 해야 합니까?

ACL 규칙이 VPC 및 온프레미스 사설 네트워크에 있는 가상 서버 인스턴스 간의 트래픽을 허용하도록 설정되어 있는지 확인하십시오. 자세한 내용은 VPN과 함께 사용하기 위한 ACL 구성을 참조하세요.

VPN for VPC에서 고가용성 구성을 지원합니까?

예, VPN for VPC 정책 기반 VPN의 경우 액티브-대기 구성에서 고가용성을 지원하고 정적 라우팅 기반 VPN의 경우 액티브-액티브 구성을 지원합니다.

SSL VPN을 지원하는 플랜이 존재합니까?

아니오, IPsec 사이트-투-사이트만 지원됩니다.

사이트-투-사이트 VPNaaS의 처리량에 한도가 있습니까?

예, 처리량은 VPN 모드, 트래픽 분산, 암호화 설정, 컴퓨팅 용량, 네트워크 상태, 피어 기기 용량 등 다양한 요인에 따라 달라집니다. 최적의 조건에서 트래픽 분산 옵션을 활성화한 상태에서 액티브-액티브 모드로 배포된 경로 기반 VPN은 두 터널에서 최대 ~2Gbps의 총 처리량을 지원할 수 있습니다( IBM 내부 벤치마크 테스트 기준, 사용자 환경에서 보장되는 제한이 아님). VPN 처리량에 대한 자세한 내용은 사이트 간 VPN 처리량 및 성능 향상을 참조하세요.

VPNaaS에서 PSK(Pre-Shared Key) 및 인증서 기반 IKE 인증이 지원됩니까?

PSK 인증만 지원됩니다.

VPN for VPC를 IBM Cloud 클래식 인프라용 VPN 게이트웨이로 사용할 수 있습니까?

예. 기존 네트워크를 VPC에 연결하는 권장 방법은 IBM Cloud Transit Gateway. 클래식 인프라에 대한 액세스 설정하기를 참조하세요.

사이트 간 VPN 간 재키 충돌이란 무엇인가요?

리키 충돌은 두 VPN 피어가 동시에 리키를 시작하려고 시도할 때 발생하며, 이로 인해 협상 충돌, 터널 불안정 또는 연결 끊김이 발생할 수 있습니다. 이 문제는 양쪽이 일치하는 키 수명을 사용해야 하고 프로토콜에 충돌 처리 메커니즘이 부족하여 신뢰할 수 없기 때문에 IKEv1 에서 흔히 관찰됩니다. IKEv1 도 오래되었으므로 가급적 사용하지 않는 것이 좋습니다. 하지만 IKEv2 에서는 비대칭 키 수명을 지원하여 동시 키 재키 시도를 원활하게 처리할 수 있습니다. IKEv1을 사용하는 경우 키 재입력 충돌이 발생하면 IKE/IPsec SA(Security Association)가 삭제됩니다. IKE/IPsec SA를 다시 작성하려면 연결 관리 상태를 down으로 설정한 후 다시 up으로 설정해야 합니다. 리키 충돌을 최소화하고 안정적인 성능을 유지하려면 IKEv2 을 사용하세요.

정책 기반 VPN에서 VPC측에서 온프레미스 측으로 모든 트래픽을 전송하는 방법은 무엇입니까?

VPC 측에서 온프레미스 측으로 모든 트래픽을 보내려면 연결을 만들 때 피어 CIDR을 0.0.0.0/0 으로 설정하세요.

연결이 성공적으로 생성되면 VPN 서비스는 <VPN gateway private IP> 경로를 통해 CIDR 0.0.0.0/0 을 VPC의 기본 라우팅 테이블에 추가합니다. 그러나 이 새 라우트로 인해 서로 통신할 수 없는 다른 서브넷의 가상 서버 및 온프레미스 VPN 게이트웨이와 통신하지 않는 VPN 게이트웨이와 같은 라우팅 문제가 발생할 수 있습니다.

라우팅 문제를 해결하려면 VPN 게이트웨이 또는 가상 서버 인스턴스가 통신하지 않는 이유를 참조하세요.

정적 라우팅과 동적 라우팅 기반 VPN 연결 유형의 차이점은 무엇인가요?

정적 라우팅 연결은 경로 광고에 BGP를 사용하지 않으며 Transit Gateway 또는 온프레미스 네트워크로의 경로를 광고할 수 없습니다. 이 연결의 경우 모든 경로를 수동으로 생성하고 관리해야 하지만, 동적 연결의 경우 초기 프로비저닝 및 연결 후에는 수동 구성이 필요하지 않습니다.

경로 기반 VPN 게이트웨이를 만들 때 동적 라우팅이 지원되나요?

예, 동적 VPN 연결은 경로 기반 VPN 게이트웨이에서 지원됩니다. 경로 기반 VPN을 만들려면 VPN 게이트웨이 만들기를 참조하고 연결 유형으로 동적을 선택합니다.

동적 라우팅 연결이 작동하려면 Transit Gateway 을 첨부해야 하나요?

예, 동적 라우팅 연결이 제대로 작동하려면 Transit Gateway 을 첨부해야 합니다. Transit Gateway 이 없으면 IPsec 연결이 설정되어 있어도 VPN 게이트웨이와 온프레미스 네트워크 간의 통신이 작동하지 않습니다.

동적 경로 기반 연결을 위해 Transit Gateway 주소가 필요한 이유는 무엇인가요?

Transit Gateway 은 네트워크 내의 모든 연결에 대한 중앙 허브 역할을 하므로 동적 라우팅에 필수적입니다. Transit Gateway 은 VPN 연결을 포함한 모든 스포크의 라우팅을 관리합니다. Transit Gateway 허브가 없으면 스포크는 허브( Transit Gateway )에 의존하여 트래픽을 원활하게 라우팅하기 때문에 서로 통신할 수 없습니다.

동적 경로 기반 VPN 연결에서 VPN을 여러 트랜짓 게이트웨이에 연결할 수 있나요?

아니요, 각 VPN 게이트웨이는 하나의 Transit Gateway 에만 연결할 수 있습니다.

동적 라우팅을 위해 기존 Transit Gateway 을 경로 기반 VPN에 연결할 수 있나요?

예, 동적 라우팅을 위해 기존 Transit Gateway 주소를 경로 기반 VPN에 연결할 수 있습니다. Transit Gateway 을 새로 만들 필요는 없습니다.

ASN이란 무엇이며 동적 라우팅에 왜 필요한가요?

ASN(자율 시스템 번호)은 BGP(보더 게이트웨이 프로토콜)에서 자율 시스템(AS)을 나타내기 위해 사용되는 고유 식별자입니다. 이는 IPsec 연결에서 공인 IP 주소와 유사하게 작동하며 네트워크 내에서 장치를 식별하는 주요 속성 역할을 합니다. 네트워크 내의 각 장치는 특정 ASN에 할당되며, 유효한 ASN이 없으면 VPN 게이트웨이가 네트워크의 다른 장치와 BGP 세션을 성공적으로 설정할 수 없습니다.

광고된 CIDR의 용도는 무엇인가요?

광고된 CIDR은 VPN에서 연결할 수 있고 온프레미스 네트워크에 광고되는 정적 IP 주소 범위입니다. 이러한 CIDR은 Secrets Manager 엔드포인트 또는 Cloud Object Storage 엔드포인트와 같이 Transit Gateway 에 직접 연결할 수 없는 비공개 엔드포인트에 유용합니다. IBM VPN 에서 온프레미스 네트워크에 이러한 CIDR을 광고하면 온프레미스 환경 내의 모든 리소스가 이러한 엔드포인트에 연결할 수 있습니다.

동적 경로 기반 VPN 연결을 생성할 때 경로를 구성해야 하나요?

아니요, 동적 경로 기반 VPN 연결을 생성할 때 수동으로 경로를 구성할 필요가 없습니다. Transit Gateway 에 연결된 모든 스포크는 자동으로 온프레미스 네트워크에 연결됩니다.

동적 경로 기반 연결을 위해 VPN for VPC 은 VPN 피어당 몇 개의 경로를 지원하나요?

각 IBM VPN 게이트웨이는 동적 라우팅 설정에서 각 VPN 피어에 대해 최대 120개의 경로를 지원합니다. 이 제한을 초과하면 해당 피어에 대한 BGP 세션이 자동으로 종료됩니다. 세션을 복원하려면 온프레미스 피어 네트워크에서 알린 경로 수를 120개 이하로 줄인 다음 IBM Cloud 에서 연결을 토글하여 BGP 세션을 다시 설정해야 합니다. 또한 VPN 어플라이언스가 여러 피어 조합을 통해 120개 이상의 경로를 수신하는 경우, 어플라이언스는 처음 120개 경로만 전송 게이트웨이로 전달합니다. 예를 들어, 두 개의 피어가 각각 70개의 경로를 VPN 어플라이언스로 전송하는 경우, 처음 120개의 경로만 전송 게이트웨이로 전파됩니다. 120개 이상의 경로가 필요한 경우, VPN 어플라이언스를 다른 온프레미스 장치에 연결할 수 있습니다. 하지만 이 구성은 다른 온프레미스 장치에 연결된 경우 VPN 어플라이언스의 고가용성 또는 재해 복구를 보장하지 않는다는 점에 유의하세요.

데이터 플레인 VPN 어플라이언스의 분기별 ASV 스캔이 완료되었습니까?

ASV(Approved Scanning Vendor) 분기별 스캔은 PCI(Payment Card Industry) 보안 표준 위원회의 요구사항입니다. VPN 데이터 플레인 어플라이언스의 ASV 스캔은 전적으로 고객 책임입니다. 이 스캔이 고객 워크로드 기능 및 성능에 부정적인 영향을 줄 수 있으므로 데이터 플레인 어플라이언스를 스캔하는 데 ASV를 사용하지 않습니다.

VPC용 VPN 게이트웨이를 사용하는 경우 어떤 메트릭이 청구되나요?

다음 메트릭이 매월 VPN 게이트웨이 비용 청구를 위해 수집됩니다.

• VPN 게이트웨이 인스턴스 시간: VPN 게이트웨이 인스턴스가 작동되어 실행되는 시간입니다.
• VPN 연결 시간: 각 VPN 연결이 VPN 게이트웨이에 설정되어 유지되는 시간입니다.
• 플로팅 IP: VPN 게이트웨이 인스턴스에서 사용하는 활성 플로팅 IP 주소 수입니다.

VPN 게이트웨이를 사용하는 경우, VPC 데이터 요금으로 청구되는 모든 아웃바운드 공용 인터넷 트래픽에 대해서도 요금이 부과됩니다.

라우팅 기반 VPN 게이트웨이를 통해 트래픽이 라우팅되지 않는 경우는 언제인가요?

VPN 연결을 다음 홉으로 사용하여 VPC 경로를 구성한 경우 다음과 같은 조건으로 인해 트래픽이 예상대로 라우팅되지 않을 수 있습니다:

• VPC 인스턴스와 연결된 보안 그룹은 트래픽을 허용하지 않습니다. 또한 인스턴스의 서브넷 또는 VPN 게이트웨이와 연결된 네트워크 ACL이 트래픽을 차단합니다. 보안 그룹과 ACL이 의도한 트래픽을 허용하는지 확인하세요. 자세한 내용은 VPN과 함께 사용할 네트워크 ACL 구성하기를 참조하세요.
• 트래픽의 소스 IP가 VPN 경로가 포함된 라우팅 테이블과 연결된 서브넷에 속하지 않는 경우, VPN 게이트웨이가 트래픽을 삭제합니다. 예를 들어 서브넷 A에만 연결되고 다음 홉이 VPN 연결인 경로가 포함된 VPC 라우팅 테이블을 생각해 보세요. 트래픽이 VPN 게이트웨이에 도달하지만 서브넷 A 또는 해당 라우팅 테이블에 연결된 다른 서브넷 외부의 IP 주소에서 시작된 경우, 게이트웨이가 트래픽을 전달하지 않습니다.