티스토리 뷰
Cloud VPN
목차:
1. Cloud VPN
2. Cloud interconnecting and Peering
3. Sharng VPC Networks
1. Cloud VPN
- Cloud VPN은 IPsec VPN 터널을 통해 온프레미스 네트워크를 GCP VPC 네트워크에 안전하게 연결합니다. 두 네트워크 사이를 이동하는 트래픽은 하나의 VPN 게이트웨이로 암호화된 다음 다른 VPN 게이트웨이에서 해독됩니다. 이렇게 하면 공용 인터넷을 통해 이동하는 데이터가 보호되므로 Cloud VPN은 소량의 데이터 연결에 유용합니다.
- 관리형 서비스인 Cloud VPN은 99.9 % 서비스 가용성의 SLA를 제공하고 사이트 간 VPN, 정적 및 동적 경로, IKEv1 및 IKEv2 암호를 지원합니다. Cloud VPN은 클라이언트 컴퓨터가 클라이언트 VPN 소프트웨어를 사용하여 VPN에 'dial in'해야 하는 사용 사례를 지원하지 않습니다. 또한 동적 경로는 Cloud Router로 구성되며 이에 대해 나중에 간략히 설명합니다.
VPN topology
- Cloud VPN의 예를 살펴보겠습니다. 이 다이어그램은 VPC와 온 프레미스 네트워크 간의 간단한 VPN 연결을 보여줍니다. VPC 네트워크에는 us-east1 및 us-west1에 서브넷이 있으며 각 지역에는 GCP 리소스가 있습니다. 이러한 리소스는 네트워크 내의 라우팅이 자동으로 구성되기 때문에 내부 IP 주소를 사용하여 통신할 수 있습니다 (방화벽 규칙이 통신을 허용한다고 가정합니다).
- 이제 온 프레미스 네트워크 및 해당 리소스에 연결하려면 Cloud VPN 게이트웨이, 온 프레미스 VPN 게이트웨이, VPN 터널 2 개를 구성해야 합니다. Cloud VPN 게이트웨이는 지역 외부 IP 주소를 사용하는 지역 리소스입니다.
- 온-프레미스 VPN 게이트웨이는 데이터 센터의 물리적 장치이거나 다른 클라우드 게이트웨이의 물리적 또는 소프트웨어 기반 VPN 제품에도 외부 IP 주소가 있습니다.
- 그런 다음 VPN 터널은 VPN 게이트웨이를 연결하고 암호화된 트래픽이 통과하는 가상 매체 역할을 합니다. 두 VPN 게이트웨이 사이에 연결을 생성하려면 두 VPN 터널을 설정해야만 합니다. 각 터널은 게이트웨이 관점에서 연결을 정의하며 터널이 쌍으로만 설정된 경우에 트래픽이 통과할 수 있습니다.
- Cloud VPN을 사용할 때 기억해야 할 한 가지는 온 프레미스 VPN 게이트웨이의 최대 전송 단위 또는 MTU가 1460 바이트를 초과할 수 없습니다. 패킷의 암호화 및 캡슐화 때문에 생기는 제한 사항입니다.
1.3 Dynamic routing with Cloud Router
- 앞서 Cloud VPN이 정적 및 동적 경로를 모두 지원한다고 언급했습니다. 동적 경로를 사용하려면 Cloud Router를 구성해야 합니다. Cloud Router는 BGP (Border Gateway Protocol)를 사용하여 Cloud VPN 터널의 경로를 관리할 수 있습니다. 이 라우팅 방법을 사용하면 터널 구성을 변경하지 않고도 경로를 업데이트하고 교환할 수 있습니다.
- 예를 들어 위 다이어그램은 VPC 네트워크에서 Test와 Prod라는 두 개의 서로 다른 지역 서브넷을 보여줍니다. 온 프레미스 네트워크에는 29 개의 서브넷이 있으며 두 네트워크는 Cloud VPN 터널을 통해 연결됩니다. 이제 새 서브넷 추가를 어떻게 처리할까요? 예를 들어 데이터 센터에서 증가하는 트래픽을 처리하기 위해 GCP 네트워크에 새로운 '스테이징'서브넷과 새로운 온 프레미스 10.0.30.0/24 서브넷을 추가하려면 어떻게 해야 할까요?
- 네트워크 구성 변경 사항을 자동으로 전파하기 위해 VPN 터널은 Cloud Router를 사용하여 VPC와 BGP를 지원해야 하는 온 프레미스 VPN 게이트웨이 간에 BGP 세션을 설정합니다. 그런 다음 새 서브넷이 네트워크 간에 원활하게 보급됩니다. 즉, 새 서브넷의 인스턴스가 트래픽을 즉시 보내고 받을 수 있습니다.
- BGP를 설정하려면 VPN 터널의 각 끝에 추가 IP 주소를 할당해야 합니다. 이 두 IP 주소는 IP 주소 범위 169.254.0.0/16에 속하는 링크 로컬 IP 주소 여야 합니다. 이러한 주소는 두 네트워크의 IP 주소 공간의 일부가 아니며 BGP 세션을 설정하는 데 독점적으로 사용됩니다.
2. Cloud interconnecting and Peering
- 인프라를 Google 네트워크에 연결하는 데 사용할 수 있는 다양한 Cloud Interconnect 및 피어링 서비스가 있습니다. 이러한 서비스는 dedicated 연결 대 shared 연결과 레이어 2 대 레이어 3 연결로 나눌 수 있습니다. 서비스는 직접 피어링, 이동 통신사 피어링(Carrier Peering), 전용 상호 연결 및 파트너 상호 연결입니다.
- Dedicated 연결은 Google 네트워크에 대한 직접 연결을 제공하지만 shared 연결은 파트너를 통해 Google 네트워크에 대한 연결을 제공합니다. 레이어 2 연결은 GCP 환경으로 직접 파이프 되는 VLAN을 사용하여 RFC 1918 주소 공간의 내부 IP 주소에 대한 연결을 제공합니다. 레이어 3 연결은 공개 IP 주소를 사용하여 G Suite 서비스, YouTube, Google Cloud API에 대한 액세스를 제공합니다.
- 이제 앞서 설명한 것처럼 Google은 Cloud VPN이라는 자체 가상 사설망 서비스도 제공합니다. 이 서비스는 공용 인터넷을 사용하지만 트래픽이 암호화되어 내부 IP 주소에 대한 액세스를 제공합니다. 이것이 바로 Cloud VPN이 다이렉트 피어링 및 이동 통신사 피어링(Carrier Peering)에 유용한 추가 기능인 이유입니다.
Dedicated Interconnect
- Dedicated Interconnect는 온 프레미스 네트워크와 Google 네트워크 간의 직접적인 물리적 연결을 제공합니다. 이를 통해 네트워크 간에 많은 양의 데이터를 전송할 수 있으므로 공용 인터넷을 통해 추가 대역폭을 구입하는 것보다 비용 효율적일 수 있습니다.
- Dedicated Interconnect를 사용하려면이 다이어그램에 표시된 대로 Google 네트워크와 공용 코로케이션 시설에서 자체 라우터 간의 교차 연결을 프로비저닝 해야 합니다. 네트워크 간에 경로를 교환하려면 Cloud Router와 온 프레미스 라우터 간의 상호 연결을 통해 BGP 세션을 구성합니다. 이렇게 하면 온 프레미스 네트워크의 사용자 트래픽이 VPC 네트워크의 GCP 리소스에 도달할 수 있으며 그 반대의 경우도 마찬가지입니다.
- Dedicated Interconnect는 99.9 % 또는 99.99 % 가동 시간 SLA를 제공하도록 구성할 수 있습니다. 이러한 SLA를 달성하는 방법에 대한 자세한 내용은 Dedicated Interconnect 문서를 참조하세요.
- Dedicated Interconnect를 사용하려면 네트워크가 지원되는 코로케이션 시설에서 Google 네트워크를 물리적으로 만나야 합니다. 이 맵은 전용 연결을 생성할 수 있는 위치를 보여줍니다. 아직은 한국은 없나 봐요.
- 지도를 보고 자신과 가까운 거리에 없을 때, Partner Interconnect를 고려해야 합니다.
Partner Interconnect
- Partner Interconnect은 지원되는 서비스 제공 업체를 통해 온 프레미스 네트워크와 VPC 네트워크 간의 연결을 제공합니다. 이는 데이터 센터가 Dedicated Interconnect 코로케이션 시설에 도달할 수 없는 물리적 위치에 있거나 데이터가 Dedicated Interconnect를 보증하지 않는 경우에 유용합니다.
- Partner Interconnect를 사용하려면 지원되는 서비스 제공 업체와 협력하여 VPC와 온 프레미스 네트워크를 연결합니다.
- 이러한 서비스 제공 업체에는 고객이 사용할 수 있도록 Google 네트워크에 대한 기존 물리적 연결이 있습니다. 서비스 제공 업체와 연결을 설정한 후, 서비스 제공 업체에 Partner Interconnect 연결을 요청할 수 있습니다. 그런 다음 Cloud Router와 온프레미스 라우터 간에 BGP 세션을 설정하여 서비스 제공 업체의 네트워크를 통해 네트워크 간에 트래픽을 전달하기 시작합니다.
- Partner Interconnect는 Google과 서비스 제공 업체 간에 99.9 % 또는 99.99 % 가동 시간 SLA를 제공하도록 구성할 수 있습니다. 이러한 SLA를 달성하는 방법에 대한 자세한 내용은 Partner Interconnect 문서를 참조하세요.
- 방금 논의한 상호 연결 옵션을 비교해 보겠습니다. 이러한 모든 옵션은 온 프레미스 네트워크와 VPC 네트워크의 리소스 간에 내부 IP 주소 액세스를 제공합니다. 주요 차이점은 연결 용량과 서비스 사용을 위한 요구 사항입니다.
- Cloud VPN이 제공하는 IPsec VPN 터널의 용량은 터널 당 1.5 ~ 3 Gbps이며 온프레미스 네트워크에 VPN 기기가 필요합니다. 1.5 Gbps 용량은 공용 인터넷을 통과하는 트래픽에 적용되고 3 Gbps 용량은 직접 피어링 링크를 통과하는 트래픽에 적용됩니다. 이 용량을 확장하려면 여러 터널을 구성할 수 있습니다.
- Dedicated Interconnect는 링크 당 10 Gbps의 용량을 제공하며 Google에서 지원하는 코 로케이션 시설에 연결되어 있어야 합니다. 최대 8 개의 링크를 사용하여 10 Gbps의 배수를 달성할 수 있지만 10 Gbps가 최소 용량입니다. 이 녹화 시점에는 최대 2 개의 링크로 링크 당 100 Gbps를 제공하는 베타 기능이 있습니다. 베타 기능은 SLA 또는 지원 중단 정책이 적용되지 않으며 이전 버전과 호환되지 않는 변경 사항이 적용될 수 있습니다.
- Partner Interconnect의 용량은 연결 당 50 Mbps ~ 10 Gbps이며 요구 사항은 서비스 제공 업체에 따라 다릅니다.
- 추천드리는 것은 VPN 터널로 시작하는 것입니다. GCP에 대한 엔터프라이즈 급 연결이 필요한 경우 코 로케이션 시설과의 근접성 및 용량 요구 사항에 따라 Dedicated Interconnect 또는 Partner Interconnect로 전환하세요.
Direct Peering
- 다이렉트 피어링 및 이동 통신사 피어링인 클라우드 피어링 서비스에 대해 이야기해 보겠습니다. 이러한 서비스는 Google 및 Google Cloud 속성에 액세스해야 할 때 유용합니다.
- Google을 사용하면 비즈니스 네트워크와 Google 네트워크 간에 다이렉트 피어링 연결을 설정할 수 있습니다. 이 연결을 사용하면 Google의 광범위한 에지 네트워크 위치 중 하나에서 네트워크와 Google 간에 인터넷 트래픽을 교환할 수 있습니다.
- Google과의 직접 피어링은 Google과 피어링 엔티티 간에 BGP 경로를 교환하여 수행됩니다. 다이렉트 피어링 연결이 설정되면 이를 사용하여 Google Cloud Platform 제품의 전체 제품군을 포함하여 Google의 모든 서비스에 연결할 수 있습니다. Dedicated Interconnect와 달리 다이렉트 피어링에는 SLA가 없습니다.
- GCP의 엣지 접속 지점 (PoP)은 Google 네트워크가 피어링을 통해 나머지 인터넷에 연결되는 곳입니다. PoP는 90 개 이상의 인터넷 거래소와 전 세계 100 개 이상의 상호 연결 시설에 있습니다. 이러한 교환 지점 및 시설에 대한 자세한 내용은 Google의 PeeringDB 항목을 참조하는 것이 좋습니다.
Carrier Peering
- Google 공용 인프라에 대한 액세스가 필요하고 Google의 피어링 요구 사항을 충족할 수 없는 경우 이동 통신사 피어링 파트너를 통해 연결할 수 있습니다. 서비스 제공 업체와 직접 협력하여 필요한 연결을 얻고 파트너의 요구 사항을 이해해야 합니다.
- Direct Peering과 마찬가지로 Carrier Peering에는 SLA가 없습니다.
- 방금 논의한 피어링 옵션을 비교해 보겠습니다. 이러한 모든 옵션은 Google의 모든 서비스에 대한 공개 IP 주소 액세스를 제공합니다. 주요 차이점은 서비스 사용을 위한 용량과 요구 사항입니다.
- 다이렉트 피어링은 링크 당 10 Gbps의 용량을 가지며 GCP Edge PoP에 연결되어 있어야 합니다.
- 이동 통신사 피어링의 용량과 요구 사항은 함께 일하는 서비스 제공 업체에 따라 다릅니다.
- 다양한 연결 서비스에 대해 모두 논의했으므로 이제 하이브리드 연결 요구 사항에 가장 적합한 서비스를 결정하도록 도와 드리겠습니다. 이 강의는 인프라를 GCP에 연결하는 5 가지 방법을 소개하는 것으로 시작했습니다. 이러한 서비스를 Dedicated 연결과 Shared 연결 및 레이어 2와 레이어 3 연결로 분할했습니다.
- 이러한 서비스를 구성하는 또 다른 방법은 상호 연결 서비스 및 피어링 서비스입니다. 상호 연결 서비스는 SLA를 통해 VPC의 RFC1918 IP 주소에 대한 직접 액세스를 제공합니다. 반면 피어링 서비스는 SLA 없이 Google 공용 IP 주소에 대한 액세스 만 제공합니다.
- 흐름도를 사용하여 요구 사항에 맞는 올바른 서비스를 선택할 수 있습니다. 인프라를 클라우드로 확장하려는 가정하에 이 다이어그램을 위에서부터 살펴보겠습니다. G Suite 서비스, YouTube 또는 Google Cloud API를 위해 네트워크를 확장해야 하는지 자문해보세요. 그렇다면 피어링 서비스 중 하나를 선택하세요. Google의 다이렉트 피어링 요구 사항을 충족할 수 있는 경우 다이렉트 피어링을 선택하세요. 그렇지 않으면 Carrier Peering을 선택합니다.
- G Suite 서비스 또는 Google Cloud API를 위해 네트워크를 확장할 필요는 없지만 네트워크 범위를 GCP로 확장하려는 경우 상호 연결 서비스 중 하나를 선택하는 것이 좋습니다. 코로케이션 시설 중 하나에서 Google을 만날 수 없는 경우 Cloud VPN 또는 Partner Interconnect를 선택하세요. 이 선택은 연결 목적과 함께 대역폭 및 암호화 요구 사항에 따라 달라집니다. 특히 적절한 대역폭이 필요하고 짧은 시간 동안 연결을 사용하고 암호화된 채널이 필요한 경우 Cloud VPN을 선택합니다. 그렇지 않으면 Partner Interconnect를 선택합니다.
- 코로케이션 시설 중 하나에서 Google을 만날 수 있다면 Dedicated Interconnect로 이동할 수 있습니다. 그러나 민감한 트래픽에 대한 자체 암호화 메커니즘을 제공할 수 없거나 10 Gbps 연결이 너무 크다고 생각하거나 여러 클라우드에 액세스 하려는 경우 대신 Cloud VPN 또는 Partner Interconnect를 고려하는 것이 좋습니다.
3. sharing VPC networks
- Shared VPC를 사용하면 organization에서 여러 프로젝트의 리소스를 공통 VPC 네트워크에 연결할 수 있습니다. 이를 통해 리소스는 해당 네트워크의 내부 IP를 사용하여 안전하고 효율적으로 서로 통신할 수 있습니다. 즉, 같은 organization에서 접근할 수 있는 네트워크입니다.
- 예를 들어 위 다이어그램에는 웹 응용 프로그램 서버의 프로젝트에 속하는 네트워크가 하나 있습니다. 이 네트워크는 3 개의 다른 프로젝트, 즉 추천 서비스와 공유됩니다. 개인화 서비스 및 분석 서비스. 이러한 각 서비스 프로젝트에는 웹 애플리케이션 서버와 동일한 네트워크에 있는 인스턴스가 있으며 내부 IP 주소를 사용하여 해당 서버에 대한 개인 통신을 허용합니다. 웹 응용 프로그램 서버는 서버의 외부 IP 주소를 사용하여 클라이언트 및 온 프레미스와 통신합니다. 반대로 백엔드 서비스는 내부 IP 주소를 사용하여 통신하기 때문에 외부 적으로 연결할 수 없습니다.
- Shared VPC를 사용하는 경우 프로젝트를 호스트 프로젝트로 지정하고 하나 이상의 다른 서비스 프로젝트를 여기에 연결합니다. 이 경우 웹 응용 프로그램 서버의 프로젝트는 호스트 프로젝트이고 다른 세 개의 프로젝트는 서비스 프로젝트입니다. 전체 VPC 네트워크를 Shared VPC 네트워크라고 합니다.
- 반대로 VPC network peering은 두 VPC 네트워크가 동일한 프로젝트에 속하든 동일한 조직에 속하든 관계없이 두 VPC 네트워크에서 비공개 RFC 1918 연결을 허용합니다. 이제 각 VPC 네트워크에는 네트워크 간에 허용 또는 거부되는 트래픽을 정의하는 방화벽 규칙이 있습니다.
- 예를 들어, 이 다이어그램에는 소비자와 생산자를 각각 나타내는 두 개의 조직이 있습니다. 각 조직에는 자체 조직 노드, VPC 네트워크, VM 인스턴스, 네트워크 관리자, 인스턴스 관리자가 있습니다. VPC 네트워크 피어링이 성공적으로 설정되려면 생산자 네트워크 관리자는 생산자 네트워크를 소비자 네트워크와 피어링 해야 하고 소비자 네트워크 관리자는 소비자 네트워크를 생산자 네트워크와 피어링 해야 합니다. 두 피어링 연결이 모두 생성되면 VPC 네트워크 피어링 세션이 활성 상태가 되고 경로가 교환됩니다. 이를 통해 가상 머신 인스턴스는 내부 IP 주소를 사용하여 비공개로 통신할 수 있습니다.
- VPC 네트워크 피어링은 각 VPC 네트워크가 별도의 관리자 그룹의 제어를 받고 자체 전역 방화벽 및 라우팅 테이블을 유지하기 때문에 다중 프로젝트 네트워킹에 대한 분산 또는 분산 접근 방식입니다. 기존에 이러한 프로젝트는 VPC 네트워크 간의 비공개 통신을 용이하게 하기 위해 외부 IP 주소 또는 VPN을 고려했습니다. 그러나 VPC 네트워크 피어링은 외부 IP 주소 또는 VPN을 사용할 때 나타나는 네트워크 지연 시간, 보안, 비용 문제를 일으키지 않습니다.
- 이제 shared VPC 및 VPC 네트워크 피어링에 대해 이야기했으므로 이 두 구성을 비교하여 주어진 상황에 적합한 구성을 결정하는 데 도움을 드리겠습니다. 다른 organizations의 VPC 네트워크 간에 비공개 통신을 구성하려면 VPC 네트워크 피어링을 사용해야 합니다. Shared VPC는 동일한 organizations 내에서만 작동합니다. 비슷하게 동일한 프로젝트의 VPC 네트워크 간에 비공개 통신을 구성하려면 VPC 네트워크 피어링을 사용해야 합니다. 이것은 네트워크가 동일한 프로젝트에 있어야 한다는 것을 의미하지는 않지만 그럴 수 있습니다. 공유 VPC는 프로젝트 간에만 작동합니다.
- 두 구성의 가장 큰 차이점은 네트워크 관리 모델입니다. Shared VPC는 보안 및 네트워크 정책이 지정된 단일 VPC 네트워크에서 발생하기 때문에 다중 프로젝트 네트워킹에 대한 중앙 집중식 접근 방식입니다. 반대로 VPC network peering은 분산된 접근 방식입니다. 각 VPC 네트워크는 별도의 관리자 그룹의 제어를 받을 수 있고 자체 전역 방화벽 및 라우팅 테이블을 유지하기 때문입니다.
이 모듈에서는 인프라를 GCP에 연결하는 5 가지 방법인 Dedicated Interconnect, Partner Interconnect, Cloud VPN, Direct Peering, Carrier Peering을 살펴보았습니다. 또한 여러 서비스 중에서 선택하는 방법에 대한 지침도 제공했습니다. 하나의 서비스를 사용하기 시작하고 요구 사항이 변경되거나 새로운 코로케이션 시설이 열리면 다른 서비스로 전환할 수 있습니다. 또한 GCP 프로젝트에서 VPC 네트워크를 공유하기 위한 두 가지 구성 인 shared VPC 및 VPC 네트워크 피어링에 대한 간략한 개요를 제공했습니다.