VPC 네트워크 피어링 개요

Google Cloud VPC 네트워크 피어링은 동일한 프로젝트에 속하는지 또는 동일한 조직에 속하는지에 관계없이 두 개의 Virtual Private Cloud(VPC) 네트워크에서 내부 IP 주소 연결을 허용합니다.

VPC 네트워크 피어링을 사용하면 여러 VPC 네트워크의 워크로드가 내부적으로 통신할 수 있도록 VPC 네트워크를 연결할 수 있습니다. 트래픽은 Google 네트워크에 그대로 머무르며 공개 인터넷을 거치지 않습니다.

VPC 네트워크 피어링은 다음과 같은 환경에서 유용합니다.

  • Google Cloud의 SaaS(Software-as-a-Service) 생태계
  • 네트워크 관리 도메인이 여러 개인 조직

조직 내에 네트워크 관리 도메인이 여러 개 있는 경우 VPC 네트워크 피어링을 사용하면 내부 IP 주소를 사용하여 VPC 네트워크에서 서비스를 사용할 수 있습니다. 다른 조직에 서비스를 제공하는 경우 VPC 네트워크 피어링을 사용하면 해당 조직에 내부 IP 주소를 사용하여 해당 서비스를 사용할 수 있습니다. 조직 전체에 서비스를 제공하는 기능은 다른 기업에 서비스를 제공하려는 경우에 유용하며, 둘 이상의 조직을 소유하거나 제어하는 경우에도 유용합니다.

VPC 네트워크 피어링은 외부 IP 주소 또는 VPN을 사용하여 네트워크에 연결하는 방법에 비해 다음을 포함한 여러 가지 이점을 제공합니다.

  • 네트워크 지연 시간: 내부 주소만 사용하는 연결은 외부 주소를 사용하는 연결보다 지연 시간이 짧습니다.
  • 네트워크 보안: 서비스 소유자는 공개 인터넷에 서비스를 노출하여 그와 관련된 위험을 감수할 필요가 없습니다.
  • 네트워크 비용: Google Cloud는 트래픽이 같은 영역 내에 있더라도 외부 IP를 사용하여 통신하는 네트워크에 이그레스 대역폭 가격을 청구합니다. 그러나 피어링된 네트워크의 경우 내부 IP를 사용하여 통신하면 이러한 이그레스 비용을 절약할 수 있습니다. 일반 네트워크 가격은 여전히 모든 트래픽에 적용됩니다.

피어링 연결을 만드는 방법은 VPC 네트워크 피어링 사용을 참조하세요.

주요 속성

피어링된 VPC 네트워크의 주요 속성은 다음과 같습니다.

  • VPC 네트워크 피어링은 Compute Engine, GKEApp Engine 가변형 환경에서 작동합니다.
  • 피어링된 VPC 네트워크는 관리 측면에서 분리된 상태로 유지됩니다. 경로, 방화벽, VPN, 기타 트래픽 관리 도구는 각 VPC 네트워크에서 개별적으로 관리되고 적용됩니다.
  • 피어링 연결의 각 측은 독립적으로 설정됩니다. 피어링은 양측의 구성이 일치하는 경우에만 활성화됩니다. 어느 한쪽에서 언제든 피어링 연결을 삭제할 수 있습니다.
  • 연결할 VPC 네트워크가 만들어지기 전에 다른 VPC 네트워크에서 커스텀 경로 가져오기 및 내보내기 옵션과 피어링을 구성할 수 있습니다. 경로 교환이 양측이 구성된 후에 발생하는 경우에도 마찬가지입니다.
  • VPC 피어는 항상 비공개적으로 재사용되는 공개 IP 주소를 사용하지 않는 서브넷 경로를 교환합니다. 네트워크는 비공개적으로 재사용되는 공개 IP 주소를 수신하기 위해 이를 사용하는 서브넷 경로를 명시적으로 가져와야 합니다.
  • 피어링 구성이 가져오기 또는 내보내기를 수행하도록 구성되었는지 여부에 따라 커스텀 경로(정적 및 동적 경로)를 교환할 수 있습니다. 자세한 내용은 커스텀 경로 가져오기 및 내보내기를 참조하세요.
  • 서브넷 및 정적 경로는 전역 경로입니다. 동적 경로는 VPC 네트워크의 동적 라우팅 모드에 따라 리전으로 또는 전역으로 적용될 수 있습니다.
  • 하나의 VPC 네트워크에 여러 개의 VPC 네트워크를 피어링할 수 있지만 제한이 있습니다.
  • VPC 네트워크 피어링을 만들고 삭제하는 IAM 권한은 프로젝트 소유자, 프로젝트 편집자, 프로젝트 관리자 역할의 일부로 포함됩니다.
  • 피어링 트래픽(피어링된 네트워크 사이에 흐르는 트래픽)의 지연, 처리량, 가용성은 동일한 네트워크의 비공개 트래픽과 같습니다.
  • 피어링 트래픽에 대한 결제 정책은 동일한 네트워크의 비공개 트래픽에 대한 결제 정책과 동일합니다.
  • 조직 정책 관리자인 경우 조직 정책을 사용하여 조직의 VPC 네트워크와 피어링할 수 있는 VPC 네트워크를 제한할 수 있습니다. 특정 VPC 네트워크 또는 특정 폴더나 조직의 VPC 네트워크에 대한 피어링 연결을 거부할 수 있습니다. 이 제약조건은 새 피어링 구성에 적용되며 기존 연결에는 영향을 주지 않습니다. 새 정책이 새 연결을 거부하더라도 기존 피어링 연결은 계속 사용할 수 있습니다. 자세한 내용은 constraints/compute.restrictVpcPeering 제약조건을 참조하세요.

제한사항

VPC 네트워크와 피어링할 때 다음 제한사항을 고려하세요.

  • 피어링된 한 VPC 네트워크의 서브넷 CIDR 범위는 다른 피어링된 네트워크의 정적 경로와 겹칠 수 없습니다. 이 규칙은 서브넷 경로와 정적 경로 모두에 적용됩니다. Google Cloud는 다음과 같은 상황에서 중복을 검사하여 중복이 발생할 경우 오류를 생성합니다.
    • VPC 네트워크를 처음 구성할 때
    • 피어링된 VPC 네트워크에서 정적 경로를 만들 때
    • 피어링된 VPC 네트워크에서 새 서브넷을 만들 때
  • 동적 경로는 피어 네트워크의 서브넷 경로와 겹칠 수 있습니다. 동적 경로의 경우 피어 네트워크의 서브넷 경로와 겹치는 대상 범위는 자동으로 삭제되며, Google Cloud는 서브넷 경로를 사용합니다.
  • VPC 네트워크 피어링에서는 VPC 네트워크만 지원됩니다. 이전 네트워크에서는 피어링이 지원되지 않습니다.
  • 서브넷 경로 교환을 사용 중지하거나 교환할 서브넷 경로를 선택할 수 없습니다. 피어링이 설정되면 서브넷 IP 주소 내의 모든 리소스를 직접 피어링된 네트워크를 통해 액세스 가능합니다. VPC 네트워크 피어링은 피어링된 네트워크에서 액세스 가능한 서브넷 CIDR 범위를 필터링하기 위한 세분화된 경로 제어를 제공하지 않습니다. 필요한 경우 방화벽 규칙을 사용하여 트래픽을 필터링해야 합니다. 다음 엔드포인트 및 리소스 유형은 직접 피어링된 네트워크를 통해 액세스 가능합니다.
    • 모든 서브넷의 가상 머신(VM) 내부 IP
    • 모든 서브넷의 내부 부하 분산된 IP
  • 직접 피어링된 네트워크만 통신할 수 있습니다. 전환 피어링은 지원되지 않습니다. 즉, VPC 네트워크 N1이 N2 및 N3과 피어링되었지만 N2와 N3이 직접 연결되지 않은 경우 VPC 네트워크 N2는 VPC 네트워크 피어링을 통해 VPC 네트워크 N3과 통신할 수 없습니다.
  • 피어링된 네트워크의 태그 또는 서비스 계정을 다른 피어링된 네트워크에서 사용할 수 없습니다.
  • 피어링된 네트워크에서는 네트워크에 만들어진 Compute Engine 내부 DNS 이름에 액세스할 수 없습니다. 피어링된 네트워크에서 VM 인스턴스에 액세스하려면 IP 주소를 사용하세요.
  • 기본적으로 GKE를 사용한 VPC 네트워크 피어링은 IP 별칭과 함께 사용할 경우에 지원됩니다. IP 별칭을 사용하지 않는 경우 피어링된 네트워크에서 GKE 컨테이너에 액세스할 수 있도록 커스텀 경로를 내보낼 수 있습니다.

라우팅 순서

Google Cloud가 피어링 그룹 내 네트워크 간의 경로 충돌을 해결하는 방법을 알아보려면 라우팅 순서를 신중하게 검토하세요.

커스텀 경로 가져오기 및 내보내기

비공개적으로 재사용되는 공개 IP 주소를 사용하지 않는 서브넷 경로는 항상 피어링된 네트워크 간에 교환됩니다. 또한 두 네트워크의 네트워크 관리자가 적절한 피어링 구성을 사용하는 경우 정적 및 동적 경로가 포함된 커스텀 경로와 비공개적으로 재사용된 공개 IP 주소를 사용하는 서브넷의 경로를 교환할 수 있습니다.

커스텀 경로를 가져올 때 VPC 네트워크는 피어 네트워크에서 경로를 수신할 수 있는데, 이는 해당 네트워크에서 커스텀 경로를 내보내는 경우에만 가능합니다. 이와 유사하게 커스텀 경로를 내보내는 경우 피어 네트워크는 해당 네트워크가 커스텀 경로를 가져오는 경우에만 커스텀 경로를 수신할 수 있습니다.

커스텀 경로를 가져오거나 내보낼 때 네트워크는 커스텀 경로를 다이렉트 피어와 교환합니다. 예를 들어 VPC 네트워크가 여러 네트워크와 피어링되는 경우 네트워크가 하나의 피어링된 네트워크에서 가져오는 경로가 피어링된 다른 네트워크에 내보내지지 않습니다.

피어링 구성을 만들거나 수정할 때 경로 가져오기, 경로 내보내기, 또는 둘 모두를 수행할 수 있습니다. 이와 유사하게 피어 네트워크 관리자는 경로가 교환되기 전에 피어링 구성을 설정해야 합니다. 이 프로세스를 통해 두 네트워크 관리자는 커스텀 경로가 교환되기 전에 커스텀 경로를 교환하는 데 명시적으로 동의합니다.

커스텀 경로 교환의 이점

커스텀 경로를 피어링된 VPC 네트워크와 공유하면 네트워크는 피어링된 네트워크에서 직접 경로를 학습할 수 있습니다. 예를 들어 피어링된 네트워크의 커스텀 경로가 업데이트되는 경우 VPC 네트워크는 사용자의 별도 조치 없이 업데이트된 커스텀 경로를 자동으로 학습하여 사용합니다.

커스텀 경로 교환은 다음 시나리오에서 도움이 될 수 있습니다.

  • VPC 기본 주소 지정 기능이 없는 GKE 클러스터가 있는 경우 컨테이너를 호스팅하는 VM 인스턴스에 트래픽을 보내는 여러 정적 경로가 있을 수 있습니다. 피어링된 네트워크에서 컨테이너에 액세스할 수 있도록 이러한 정적 경로를 내보낼 수 있습니다.
  • VPN 터널 또는 상호 연결이 있는 경우 피어 네트워크가 온프레미스 네트워크에 액세스할 수 있도록 커스텀 경로를 공유할 수 있습니다. 동적 경로의 경우 VPC 네트워크에서 Cloud Router 커스텀 경로 공지를 추가하여 피어링된 네트워크 서브넷을 온프레미스 네트워크에 전파해야 합니다.

고려사항

커스텀 경로 가져오기 또는 내보내기를 구성할 때 다음 특성에 유의하세요.

  • 피어링 시 Google Cloud는 다른 네트워크에 있는 서브넷 IP 범위와 겹치는 서브넷 IP 범위가 있는지 확인합니다. 겹치는 IP 범위가 있는 경우 피어링이 설정되지 않습니다. 이 중복 확인은 VPC 서브넷 범위 전용입니다. 정적 경로 및 동적 경로는 확인되지 않습니다. 피어링이 계속 진행되면 그대로 내보내집니다.
  • 정적 경로와 동적 경로 모두 내보내거나 가져옵니다. 한 가지 유형의 경로만 가져오거나 내보낼 수 없습니다.
  • 하나의 VPC 네트워크에서 가져온 커스텀 경로는 피어링된 다른 VPC 네트워크에 전환하여 내보낼 수 없습니다.
  • 다음 경로는 가져오기 및 내보내기에서 제외됩니다.
    • 태그가 지정된 경로는 피어 네트워크 간에 교환되지 않습니다. 태그가 지정된 경로는 네트워크 태그를 사용하여 특정 VM 인스턴스에 적용되는 커스텀 정적 경로입니다. 네트워크 태그는 해당 태그가 생성된 VPC 네트워크에서만 확인할 수 있습니다.
    • 기본 인터넷 게이트웨이로 다음 홉이 있는 정적 경로는 교환되지 않습니다. 예를 들어 기본 인터넷 게이트웨이의 다음 홉이 있는 기본 경로(0.0.0.0/0)는 피어 네트워크 간에 교환되지 않습니다.
  • 가져온 경로로 인해 트래픽 흐름이 의도하지 않게 변경될 수 있습니다(예: 라우팅 순서의 변경). 자세한 내용은 라우팅 순서를 참조하세요.
  • VPC 네트워크가 피어 네트워크에서 커스텀 경로를 가져올 때 목적지 범위를 있는 그대로 가져옵니다. 그러나 가져온 경로의 다음 홉이 피어링 연결의 이름으로 설정됩니다. 트래픽은 실제 다음 홉이 정의된 피어링된 네트워크로 라우팅됩니다.

VPC 네트워크 피어링 시나리오의 네트워킹 특징

다음 섹션에서는 VPC 네트워크 피어링이 특정 시나리오에서 어떻게 작동하는지 설명합니다.

피어링 시 서브넷 겹침

피어링 시 Google Cloud는 두 개의 VPC 네트워크 또는 피어링된 네트워크 간에 IP 범위가 겹치는 서브넷이 있는지 여부를 확인합니다. 겹치는 IP 범위가 있는 경우 피어링이 설정되지 않습니다. VM 인스턴스 간에 풀 메시 연결이 만들어지므로 피어링된 VPC 네트워크의 서브넷 IP 범위가 겹치면 안 됩니다. 겹치는 경우 라우팅 문제가 발생할 수 있기 때문입니다.

두 피어 간의 서브넷 IP 범위 겹침(확대하려면 클릭)
두 피어 간의 서브넷 IP 범위 겹침(확대하려면 클릭)

지정된 VPC 네트워크의 피어 간에 IP 범위가 겹치는 서브넷이 있는 경우 라우팅 충돌이 발생합니다. 예를 들어 VPC 네트워크 N1이 이미 VPC 네트워크 N2와 피어링되어 있는 상태에서 VPC 네트워크 N3이 N2와의 피어링을 시도하는 경우를 생각해 보겠습니다. N3에는 IP 범위가 네트워크 N1의 Subnet_1과 겹치는 서브넷 Subnet_5가 있으므로 이는 잘못된 피어링입니다.

3개의 피어와 서브넷 IP 범위가 겹침(확대하려면 클릭)
3개의 피어와 서브넷 IP 범위가 겹침(확대하려면 클릭)

서브넷을 만들거나 확장할 때 서브넷 겹침

VPC 서브넷이 만들어질 때 또는 서브넷 IP 범위가 확장될 때 Google Cloud는 새 서브넷 범위가 동일한 VPC 네트워크 또는 직접 피어링된 VPC 네트워크의 서브넷 IP 범위와 겹치지 않는지 확인합니다. 겹치는 경우 만들기 또는 확장 작업이 실패합니다. 예를 들어 다음 그림에서 네트워크 N2에 새 서브넷 subnet_3이 만들어질 때 IP 범위는 직접 피어링된 네트워크 N1에 정의된 IP 범위와 겹치면 안 됩니다.

서브넷 만들기 확인(확대하려면 클릭)
서브넷 만들기 확인(확대하려면 클릭)

또한 Google Cloud는 공통적으로 피어링된 네트워크가 있는 VPC 네트워크 간에 겹치는 서브넷 IP 범위가 허용되지 않았는지 확인합니다. 겹치는 경우 만들기 또는 확장 작업이 실패합니다. 예를 들어 다음 그림에서 N1은 N2와 이미 피어링되어 있으므로 네트워크 N3에 새 서브넷 subnet_5가 만들어질 때 IP 범위는 직접 피어링된 네트워크 N2 또는 네트워크 N1에 정의된 IP 범위와 겹치면 안 됩니다.

피어 3개에서 서브넷 만들기 확인(확대하려면 클릭)
피어 3개에서 서브넷 만들기 확인(확대하려면 클릭)

피어 네트워크에서 온프레미스 액세스

Cloud VPN 또는 Cloud Interconnect를 사용하여 온프레미스 네트워크를 VPC 네트워크에 안전하게 연결할 수 있습니다. 커스텀 경로를 내보내면 피어링된 VPC 네트워크를 온프레미스 네트워크에 연결할 수도 있습니다. 온프레미스 네트워크에서 VPC 네트워크로 향하는 트래픽이 VPN 터널로 향하도록 경로를 만들어야 합니다.

Cloud VPN은 정적 라우팅과 동적 라우팅을 모두 지원하지만 Cloud Interconnect는 동적 라우팅만 지원합니다. 동적 라우팅의 경우 Cloud Router를 사용하면 BGP(Border Gateway Protocol)를 사용하여 VPC 네트워크와 온프레미스 네트워크 간의 경로를 동적으로 업데이트합니다. Cloud Router는 해당 리전 내의 경로나 모든 VPC 네트워크 내 모든 리전에 대한 경로를 학습하거나 전파할 수 있습니다. 이 동작은 리전 또는 전역으로 설정할 수 있는 VPC 네트워크의 동적 라우팅 모드에 따라 달라집니다.

다음 사용 사례는 커스텀 경로를 가져오고 내보낸 후 피어링된 VPC 네트워크의 리소스에 액세스하는 방법을 보여줍니다. 각 예시는 서로 피어링된 두 네트워크(network-anetwork-b)를 보여줍니다. 위 예시에서 network-b에 대한 동적 라우팅 모드는 리전 기준이고, 다른 예시에서는 전역 기준입니다.

리전 동적 라우팅

리전 동적 라우팅을 사용하는 경우 Cloud Router와 동일한 리전의 리소스만 온프레미스 네트워크에 액세스할 수 있습니다. 이 제한사항은 피어링된 VPC 네트워크의 동적 라우팅 모드에 관계없이 Cloud Router의 VPC 네트워크와 피어링된 VPC 네트워크에 적용됩니다. 다음 예시에서 network-b는 VPN 터널(상호 연결도 가능)과 Cloud Router를 포함합니다. network-b의 동적 라우팅 모드는 리전으로 설정됩니다. 피어링된 네트워크에서 subnet-anetwork-b의 Cloud Router와 동일한 리전에 있습니다.

피어링 연결이 설정된 후 network-anetwork-b의 VPN 터널에 액세스할 수 있습니다. 이 액세스는 Cloud Router와 동일한 리전에 있는 서브넷으로 제한됩니다. 예를 들어 VM 인스턴스 vm-a는 Cloud Router와 동일한 리전에 있기 때문에 VPN 터널에 연결할 수 있습니다. 다른 리전의 VM 인스턴스는 터널에 액세스할 수 없습니다.

Cloud Router는 피어링된 VPC 네트워크의 경로를 학습하고 전파하지 않습니다. 결과적으로 Cloud Router에 10.8.1.0/24 범위를 BGP 세션의 온프레미스 네트워크에 전파하는 커스텀 경로 공지가 있어야 합니다.

다음 표에는 커스텀 경로를 가져오고 내보내는 경우 network-anetwork-b에 대한 경로가 요약되어 있습니다.

네트워크 목적지 다음 홉 원본
network-a 0.0.0.0/0 인터넷 게이트웨이 로컬
10.8.1.0/24 network-a 로컬
10.30.0.0/16 vm-a1 로컬
10.8.2.0/24 a에서 b로 피어링 피어
10.10.0.0/16
(동적 경로는 us-west1으로 제한됨)
a에서 b로 피어링 피어
network-b 0.0.0.0/0 인터넷 게이트웨이 로컬
10.8.2.0/24 network-b 로컬
10.10.0.0/16
(동적 경로는 us-west1으로 제한됨)
vpn-b 로컬
10.8.1.0/24 b에서 a로 피어링 피어
10.30.0.0/16 b에서 a로 피어링 피어

전역 동적 라우팅

network-b가 전역 동적 라우팅을 사용 설정하는 경우 모든 리전의 리소스가 온프레미스 네트워크에 액세스할 수 있습니다. 이는 피어링된 VPC 네트워크의 동적 라우팅 모드에 관계없이 Cloud Router의 VPC 네트워크와 피어링된 VPC 네트워크에 적용됩니다.

다음 예시에서 network-a의 리소스는 해당 리전에 상관없이 network-b에 있는 VPN 터널에 액세스할 수 있습니다. 예를 들어 VM 인스턴스 vm-a1vm-a2vm-a2가 VPN 터널과 다른 리전에 있더라도 온프레미스 네트워크에 연결할 수 있습니다.

또한 Cloud Router에는 10.8.1.0/2410.9.1.0/24 범위를 BGP 세션의 온프레미스 네트워크에 알리는 커스텀 경로 공지가 포함되어 있어야 합니다.

다음 표에는 커스텀 경로를 가져오고 내보내는 경우 network-anetwork-b에 대한 경로가 요약되어 있습니다.

네트워크 목적지 다음 홉 원본
network-a 0.0.0.0/0 인터넷 게이트웨이 로컬
10.8.1.0/24 network-a 로컬
10.9.1.0/24 network-a 로컬
10.30.0.0/16 vm-a1 로컬
10.8.2.0/24 a에서 b로 피어링 피어
10.10.0.0/16
(전역 동적 경로)
a에서 b로 피어링 피어
network-b 0.0.0.0/0 인터넷 게이트웨이 로컬
10.8.2.0/24 network-b 로컬
10.10.0.0/16
(전역 동적 경로)
vpn-b 로컬
10.8.1.0/24 b에서 a로 피어링 피어
10.9.1.0/24 b에서 a로 피어링 피어
10.30.0.0/16 b에서 a로 피어링 피어

전송 네트워크인 VPC 네트워크

VPC 네트워크와 온프레미스 네트워크 사이에 VPN 터널 또는 상호 연결과 같은 단일 온프레미스 연결이 있다고 가정해 보겠습니다. 다른 모든 VPC 네트워크에 대한 내부 연결을 다시 만들 필요가 없도록 이 연결을 다른 VPC 네트워크와 공유하려고 합니다.

다른 네트워크가 온프레미스 연결을 사용할 수 있도록 다른 VPC 네트워크가 사용자의 VPC 네트워크(전송 네트워크라고도 함)와 피어링하도록 설정할 수 있습니다. 피어링된 모든 네트워크는 온프레미스 연결을 활용할 수 있지만 전송 네트워크를 통해 다른 피어로 트래픽을 라우팅할 수는 없습니다.

다음 예시에는 세 개의 VPC 네트워크가 있습니다. network-bnetwork-anetwork-c와 피어링됩니다. 모든 네트워크는 커스텀 경로를 내보내고 가져옵니다. network-b는 VPN 터널이 위치하는 전송 네트워크의 역할을 합니다.

  • network-b에는 트래픽을 연결된 온프레미스 네트워크에 라우팅하는 관련 정적 VPN 경로가 있습니다. 정적 경로를 내보낸 후 피어링된 VPC 네트워크에서 가져옵니다. 동적 라우팅에 Cloud Router를 사용하는 경우 피어 네트워크의 서브넷 IP 주소를 공지해야 합니다. Cloud Router는 VPC 네트워크 피어링의 경로를 자동으로 공지하지 않습니다.

  • 온프레미스 네트워크의 호스트는 각 VPC 네트워크의 호스트에 트래픽을 보내고 받을 수 있습니다. 트래픽이 VPC 네트워크를 대상으로 전송되는 경우 온프레미스 네트워크에는 VPN 게이트웨이의 다음 홉이 있는 경로가 포함되어 있어야 합니다.

  • network-c의 호스트는 network-b 및 온프레미스 네트워크의 호스트에 액세스할 수 있지만 network-a의 호스트에는 액세스할 수 없습니다. 이와 유사하게 network-a의 호스트는 network-b 및 온프레미스 네트워크에 액세스할 수 있지만 network-c에는 액세스할 수 없습니다. 이는 피어링 경로가 전환 경로가 아니기 때문입니다.

내부 TCP/UDP 부하 분산

다음 조건이 충족되는 경우 피어 네트워크의 VM 인스턴스는 VPC 네트워크에서 내부 TCP/UDP 부하 분산기의 내부 IP 주소에 액세스할 수 있습니다.

  • VM은 내부 TCP/UDP 부하 분산기와 같은 리전에 위치합니다.
  • 부하 분산기의 백엔드 VM에 적용되는 인그레스 방화벽 규칙은 피어 네트워크의 소스에서 발생하는 트래픽을 허용합니다. 이러한 인그레스 방화벽 규칙은 부하 분산기를 포함하는 VPC 네트워크에서 만들어야 합니다.

자세한 내용은 VPC 네트워크 피어링 사용을 참조하세요.

방화벽 규칙

VPC 네트워크 피어링을 사용하여 네트워크를 연결하면 방화벽 규칙이 네트워크 간에 교환되지 않습니다. 피어 네트워크의 VM 인스턴스에서 발생하는 인그레스 트래픽을 허용하려면 인그레스 허용 방화벽 규칙을 만들어야 합니다. 기본적으로 VM에 대한 인그레스 트래픽은 묵시적 거부 인그레스 규칙에 의해 차단됩니다.

VM으로 액세스를 제한하여 VPC 네트워크의 다른 VM만 액세스할 수 있도록 하려면 인그레스 허용 방화벽 규칙의 소스가 피어 네트워크가 아닌 VPC 네트워크의 VM만 식별해야 합니다. 예를 들어 VPC 네트워크의 서브넷에 대해서만 소스 IP 범위를 지정할 수 있습니다.

내부 TCP/UDP 부하 분산기로 액세스를 제한하려면 부하 분산기의 백엔드 VM에 적용되는 인그레스 방화벽 규칙을 만드세요.

방화벽

방화벽 규칙은 피어링된 네트워크로 가져올 수 없습니다. 각 네트워크에서 개별적으로 방화벽 규칙을 구성하여 허용하거나 차단할 피어링된 네트워크의 트래픽을 제어할 수 있습니다.

내 VPC 네트워크와 다른 VPC 네트워크 사이에서 피어링하는 경우 특정 VM 인스턴스 또는 내부 부하 분산 엔드포인트로 가는 트래픽을 차단해야 할 수 있습니다. 피어링에서 특정 VM 인스턴스 또는 내부 부하 분산기를 제외하는 방법은 없으므로 방화벽 규칙을 사용해야 합니다. 특정 VM 인스턴스 또는 내부 부하 분산기와의 통신을 허용하지 않으려면 통신을 차단하려는 네트워크에 인그레스 방화벽 규칙을 설치할 수 있습니다.

  • VM 인스턴스: 이 경우 특정 소스 IP의 트래픽만 허용하는 인그레스 방화벽을 설치할 수 있습니다. 이러한 소스 IP는 VPC 네트워크의 서브넷 CIDR에 매핑이 가능합니다. 이는 피어링된 VPC 네트워크에서 오는 모든 트래픽을 차단합니다.
VPC 네트워크 피어링과 방화벽(확대하려면 클릭)
VPC 네트워크 피어링과 방화벽(확대하려면 클릭)
  • 내부 부하 분산기: 이 경우 내부 부하 분산기가 있는 VPC 네트워크에 인그레스 방화벽 규칙을 설치할 수 있습니다. 이러한 소스 IP는 네트워크의 서브넷 CIDR 전체 또는 일부에 매핑이 가능합니다. 인그레스 방화벽 규칙이 피어링된 네트워크의 모든 서브넷 CIDR 범위에 적용되는 경우 그 네트워크의 인스턴스는 내부 부하 분산기 백엔드 VM에 도달할 수 없습니다.

공유 VPC

VPC 네트워크 피어링에서는 공유 VPC와의 피어링이 허용됩니다. 공유 VPC 호스트 프로젝트는 다른 프로젝트에서 네트워크 중 하나를 사용하도록 허용하는 프로젝트입니다. 다음 다이어그램에서는 이 설정을 보여줍니다.

네트워크 피어링을 사용한 공유 VPC(확대하려면 클릭)
네트워크 피어링을 사용한 공유 VPC(확대하려면 클릭)

네트워크 SVPC는 호스트 프로젝트 P1의 공유 VPC 네트워크에 있습니다. 서비스 프로젝트 P3 및 P4는 네트워크 SVPC에 VM 인스턴스를 연결할 수 있습니다. 네트워크 SVPC는 네트워크 A와 피어링됩니다. 결과는 다음과 같습니다. 결과는 다음과 같습니다.

  • 네트워크 SVPC를 사용하는 공유 VPC 서비스 프로젝트의 VM 인스턴스(VM3과 VM4)는 네트워크 A에 연결된 모든 엔드포인트에 비공개 내부 IP로 연결됩니다.
  • 네트워크 A에 연결된 VM 인스턴스는 해당 엔드포인트가 호스트 프로젝트에 있든 서비스 프로젝트에 있든 관계없이 네트워크 SVPC에 연결된 모든 엔드포인트에 비공개 내부 IP로 연결됩니다.

두 개의 공유 VPC 네트워크 간에 VPC 네트워크 피어링을 설정할 수 있습니다.

VM 인스턴스당 다중 네트워크 인터페이스

VM 인스턴스에는 VPC 네트워크당 하나씩 다중 네트워크 인터페이스가 있을 수 있습니다. 이러한 인스턴스의 경우 Google Cloud는 목적지 기반 IP 경로를 할당하며 각 인터페이스는 현재 있는 서브넷에서 경로를 가져옵니다. 또한 Google Cloud는 기본 네트워크 인터페이스에 대한 기본 경로를 제공합니다. 목적지 기반 라우팅을 사용하면 목적지가 인스턴스의 서브넷이 아닌 모든 트래픽은 기본 네트워크 인터페이스에서 이그레스됩니다. 자세한 내용은 다중 네트워크 인터페이스의 DHCP 동작을 참조하세요.

다중 네트워크 인터페이스가 있는 VM 인스턴스가 포함된 피어 네트워크가 있는 경우 기본 목적지 기반 라우팅 정책을 소스 기반 라우팅 정책으로 변경해야 할 수 있습니다. 자세한 내용은 정책 라우팅 구성을 참조하세요.

다음 시나리오는 VM 인스턴스에 소스 기반 라우팅 정책이 필요하거나 필요하지 않을 수 있는 경우를 보여줍니다.

라우팅 정책이 필요한 경우

다음 예시에서 vm1vm1vm2와 통신할 수 있도록 소스 기반 라우팅 정책을 요구합니다. 라우팅 정책이 없는 경우 트래픽 목적지가 nic1이 있는 subnet-b가 아니라면 모든 트래픽이 vm1-nic0~network-a로 이그레스됩니다. 즉, VM 인스턴스가 항상 기본 인터페이스에서 트래픽을 전송하기 때문에 목적지가 network-cvm1의 트래픽이 중단되거나 잘못된 목적지로 전송됩니다.

라우팅 정책 요구사항은 서브넷 IP 범위에 따라 다릅니다.

다음 예시에서 vm1의 기본 네트워크 인터페이스는 다른 네트워크와 피어링된 네트워크에 있습니다. vm1에 정책 라우팅을 구성할 필요가 없습니다.

다음 예시에서 vm1-nic1vm2-nic0는 중복된 서브넷에 있습니다. 피어링이 설정되면 Google Cloud는 피어 사이에서만 IP 범위가 겹치는지 확인하고 인스턴스에 네트워크 인터페이스가 포함된 다른 네트워크는 확인하지 않습니다. vm1vm2 사이의 통신을 보장하기 위해 vm1-nic0에서 소스 기반 라우팅 정책을 추가해야 합니다.

인터페이스 간 피어링

다음 예시에서는 다중 네트워크 인스턴스가 있는 VM 인스턴스를 보여줍니다. 각 인스턴스는 서로 피어링된 네트워크에 있습니다. 이 경우 vm1는 소스 기반 라우팅 정책이 필요하지 않습니다. VM 인스턴스에서 각 서브넷으로 나가는 트래픽은 해당 네트워크 인터페이스를 사용합니다.

vm1에서 vm2-nic1의 IP 주소로 트래픽을 보내는 경우 트래픽은 nic1으로 이동하지만 nic0에서 이그레스됩니다. 마찬가지로 vm3에서 vm2-nic0의 IP 주소로 트래픽을 보내는 경우 트래픽은 nic0으로 이동하지만 nic1에서 이그레스됩니다.

서브넷 보조 범위

서브넷에는 단일 기본 IP 주소 범위와 선택적으로 하나 이상의 보조 IP 주소 범위가 있습니다. 각 서브넷 IP 주소 범위에 대해 Google Cloud는 서브넷 경로를 만듭니다. VPC 네트워크 피어링을 사용할 때 Google Cloud는 항상 피어링 된 두 네트워크 간에 비공개적으로 재사용되는 공개 IP 주소를 사용하지 않는 서브넷 경로를 교환합니다. 각 네트워크의 방화벽 규칙이 통신을 허용하면 한 네트워크의 VM 인스턴스가 피어링된 네트워크의 인스턴스와 통신할 수 있습니다.

피어링 관계를 설정할 때 Google Cloud는 피어링된 네트워크의 다른 범위와 서브넷의 기본 및 보조 범위가 겹치지 않는지 확인합니다.

다음 단계