VPC 네트워크 피어링

Google Cloud VPC 네트워크 피어링은 2개의 가상 프라이빗 클라우드(VPC) 네트워크를 연결하여 각 네트워크의 리소스가 서로 통신할 수 있게 해줍니다. 피어링된 VPC 네트워크는 동일한 프로젝트, 동일 조직의 다른 프로젝트, 다른 조직의 다른 프로젝트에 설정할 수 있습니다.

사양

VPC 네트워크 피어링을 사용하면 다음을 수행할 수 있습니다.

• VPC 네트워크 간에 software as a service(SaaS) 제품을 게시합니다.
• VPC 네트워크 피어링은 Compute Engine, GKE 및 App Engine 가변형 환경에서 작동합니다.
  • VPC 네트워크 피어링은 서브넷 경로를 교환하여 VPC 기반 GKE 클러스터를 지원합니다.
  • VPC 네트워크 피어링은 정적 경로를 교환하도록 구성된 경우 경로 기반 GKE 클러스터를 지원합니다.

연결

• VPC 네트워크 피어링은 레거시 네트워크가 아닌 VPC 네트워크 연결을 지원합니다.
• VPC 네트워크 피어링은 한 쌍의 VPC 네트워크 간에 내부 IPv4 및 IPv6 연결을 제공합니다. 피어링 트래픽(피어링된 네트워크 간에 흐르는 트래픽)은 동일한 VPC 네트워크 내의 트래픽과 동일한 지연 시간, 처리량 및 가용성을 가집니다.
  • VPC 네트워크 피어링은 전환 라우팅을 제공하지 않습니다. 예를 들어, VPC 네트워크 net-a와 net-b가 VPC 네트워크 피어링을 사용하여 연결되고 VPC 네트워크 net-a와 net-c도 VPC 네트워크 피어링을 사용하여 연결된 경우, VPC 네트워크 피어링은 net-b 및 net-c 간 연결을 제공하지 않습니다.
  • VPC 네트워크 피어링을 사용하여 두 개의 자동 모드 VPC 네트워크를 연결할 수 없습니다. 이는 피어링된 VPC 네트워크가 항상 비공개 내부 IPv4 주소를 사용하는 서브넷 경로를 교환하고 자동 모드 VPC 네트워크의 각 서브넷이 10.128.0.0/9 CIDR 블록에 맞는 서브넷 IP 주소 범위를 사용하기 때문입니다.
  • 커스텀 모드 VPC 네트워크에 10.128.0.0/9에 맞는 서브넷 IP 주소 범위가 없는 한 커스텀 모드 VPC 네트워크를 자동 모드 VPC 네트워크에 연결할 수 있습니다.
• VPC 네트워크 피어링에 의해 대상 외부 IPv6 주소에 대한 경로가 교환될 때, VPC 네트워크 피어링은 다음 리소스의 대상 외부 IPv6 주소 범위에 특정 외부 IPv6 연결을 제공합니다.
  • 듀얼 스택 가상 머신(VM) 인스턴스 네트워크 인터페이스
  • 외부 프로토콜 전달을 위한 전달 규칙
  • 외부 패스 스루 네트워크 부하 분산기용 전달 규칙
• VPC 네트워크 피어링은 IPv4 및 IPv6 연결을 둘 다 지원합니다. 이중 스택 서브넷을 포함하는 VPC 네트워크에서 VPC 네트워크 피어링을 구성할 수 있습니다.

관리

• 피어링된 VPC 네트워크는 관리 측면에서 분리된 상태로 유지됩니다. 경로만 피어링 구성에 따라 교환됩니다.
• 피어링 연결을 설정하려면 각 VPC 네트워크에 대한 네트워크 관리자가 다른 VPC 네트워크에 대해 피어링 연결을 만들어야 합니다. VPC 네트워크의 네트워크 관리자는 어느 한쪽이라도 피어링 연결을 해제할 수 있습니다.
• 피어링 연결의 각 측은 독립적으로 설정됩니다. 피어링은 양측의 구성이 일치하는 경우에만 활성화됩니다. 어느 한쪽에서 언제든 피어링 연결을 삭제할 수 있습니다.
• 피어링 연결을 만들어도 다른 VPC 네트워크에 대해 Identity and Access Management(IAM) 역할이 부여되지 않습니다. 예를 들어 하나의 네트워크에 대해 Compute 네트워크 관리자 역할 또는 Compute 보안 관리자 역할이 있어도 다른 네트워크에 대해서는 네트워크 관리자 또는 보안 관리자가 되지 않습니다.

IAM 권한

• VPC 네트워크 피어링을 만들고 삭제하는 IAM 권한은 Compute 네트워크 관리자 역할(roles/compute.networkAdmin)의 일부로 포함됩니다.
• 다음 권한이 포함된 경우 커스텀 역할을 사용할 수 있습니다.
  • compute.networks.addPeering
  • compute.networks.updatePeering
  • compute.networks.removePeering
  • compute.networks.listPeeringRoutes

네트워크 보안

VPC 네트워크 피어링을 사용하여 연결된 VPC 네트워크는 각 VPC 네트워크의 네트워크 관리자가 구성한 경로 교환 옵션을 기반으로 경로만 교환합니다.

VPC 네트워크 피어링은 VPC 방화벽 규칙 또는 방화벽 정책을 교환하지 않습니다.

VPC 방화벽 규칙의 경우:

• 네트워크 태그를 사용하여 대상이 정의된 방화벽 규칙은 방화벽 규칙의 VPC 네트워크에 있는 인스턴스로만 확인됩니다. 피어링된 VPC 네트워크의 보안 관리자가 동일한 네트워크 태그를 사용하여 피어링된 VPC 네트워크의 방화벽 규칙 대상을 정의할 수 있지만 피어링된 VPC 네트워크의 방화벽 규칙 대상에는 VPC 네트워크의 인스턴스가 포함되지 않습니다. 마찬가지로, 네트워크 태그를 사용하여 소스가 정의된 인그레스 방화벽 규칙은 방화벽 규칙의 VPC 네트워크에 있는 인스턴스로만 확인됩니다.

• 서비스 계정을 사용하여 대상이 정의된 방화벽 규칙은 방화벽 규칙의 VPC 네트워크에 있는 인스턴스로만 확인됩니다. IAM 권한에 따라 피어링된 VPC 네트워크의 보안 관리자는 동일한 서비스 계정을 사용하여 피어링된 VPC 네트워크의 방화벽 규칙 대상을 정의할 수 있지만 피어링된 VPC 네트워크의 방화벽 규칙 대상에는 VPC 네트워크의 인스턴스가 포함되지 않습니다. 마찬가지로 서비스 계정을 사용하여 소스가 정의된 인그레스 방화벽 규칙은 방화벽 규칙의 VPC 네트워크에 있는 인스턴스로만 확인됩니다.

네트워크 방화벽 정책의 규칙은 네트워크 태그와 다른 보안 태그를 사용하여 대상 및 소스를 식별할 수 있습니다.

• 네트워크 방화벽 정책에서 인그레스 또는 이그레스 규칙의 대상을 지정하는 경우 태그는 태그 범위가 지정된 VPC 네트워크의 대상만 식별할 수 있습니다.

• 네트워크 방화벽 정책에서 인그레스 규칙의 소스를 지정하는 경우 태그는 태그 범위가 지정된 VPC 네트워크와 태그 범위가 지정된 VPC 네트워크와 연결된 모든 피어링된 VPC 네트워크에서 소스를 식별할 수 있습니다. 자세한 내용은 방화벽 태그를 참조하세요.

모든 VPC 네트워크에는 묵시적인 방화벽 규칙이 포함됩니다. 묵시적 인그레스 거부 방화벽 규칙으로 인해 각 VPC 네트워크의 보안 관리자는 인그레스 허용 방화벽 규칙 또는 방화벽 정책의 규칙을 만들어야 합니다. 이러한 규칙의 소스는 피어링된 VPC 네트워크의 IP 주소 범위를 포함할 수 있습니다.

묵시적 이그레스 허용 방화벽 규칙으로 인해 네트워크에 이그레스 거부 규칙이 포함되지 않는 한 피어링된 VPC 네트워크의 대상에 대해 패킷을 허용하기 위해 이그레스 허용 방화벽 규칙이나 방화벽 정책의 규칙을 만들 필요가 없습니다.

DNS 지원

피어링된 VPC 네트워크의 리소스는 로컬 VPC 네트워크에서 만든 Compute Engine 내부 DNS 이름을 사용할 수 없습니다.

피어링된 VPC 네트워크는 로컬 VPC 네트워크에 대해서만 승인된 Cloud DNS 관리형 비공개 영역을 사용할 수 없습니다. 피어링된 VPC 네트워크의 리소스에 대해 DNS 이름을 사용할 수 있게 하려면 다음 기법 중 하나를 사용하세요.

• Cloud DNS 피어링 영역을 사용합니다.
• 모든 피어링된 VPC 네트워크에 대해 동일한 관리형 비공개 영역을 승인(표시)합니다.

내부 부하 분산기 지원

로컬 VPC 네트워크의 클라이언트는 피어 VPC 네트워크의 내부 부하 분산기에 액세스할 수 있습니다. 자세한 내용은 다음 부하 분산기 문서의 VPC 네트워크 피어링 사용 섹션을 참조하세요.

• 내부 패스 스루 네트워크 부하 분산기 및 연결된 네트워크
• 내부 프록시 네트워크 부하 분산기 및 연결된 네트워크
• 내부 애플리케이션 부하 분산기 및 연결된 네트워크

피어링된 네트워크는 내부 패스 스루 네트워크 부하 분산기를 다음 홉으로 사용하는 정적 경로를 교환할 수 있습니다. 자세한 내용은 경로 교환 옵션을 참조하세요.

피어링 그룹 및 할당량

VPC 피어링 할당량은 피어링 그룹이라는 개념에 따라 달라집니다. 각 VPC 네트워크에는 자체 피어링 그룹이 포함되어 있습니다. 이 피어링 그룹은 자체 네트워크 그리고 VPC 네트워크 피어링을 사용하여 연결된 다른 모든 VPC 네트워크로 구성됩니다. 가장 간단한 시나리오에서 2개의 VPC 네트워크 net-a 및 net-b가 서로 피어링되어 있으면 2개의 피어링 그룹이 사용됩니다. 하나는 net-a 관점의 피어링 그룹이고 다른 하나는 net-b 관점의 피어링 그룹입니다.

VPC 네트워크 피어링 할당량에 대한 자세한 내용은 다음을 참조하세요.

• 네트워크별 할당량
• 피어링 그룹별 할당량의 유효 한도

제한사항

VPC 네트워크 피어링의 제한사항은 다음과 같습니다.

피어링된 VPC 네트워크 간 서브넷 IP 범위가 겹치면 안 됨

피어링된 VPC 네트워크에서 서브넷 IP 범위가 다른 서브넷 IP 범위와 정확하게 일치하거나 이를 포함하거나 속할 수 없습니다. 피어링 시 Google Cloud는 IP 범위가 겹치는 서브넷이 있는지 확인합니다. 있으면 피어링이 실패합니다. 이미 피어링된 네트워크의 경우 새 서브넷 경로를 만드는 작업을 수행하면 Google Cloud에는 고유한 대상 IP 주소 범위가 있는 새 서브넷 경로가 있어야 합니다.

새 서브넷을 만들기 전에 피어링 연결의 경로를 나열하여 새 서브넷 IPv4 주소 범위가 아직 사용되지 않았는지 확인할 수 있습니다.

이러한 제한사항과 Google Cloud의 해당 검사가 다음과 같은 시나리오에도 적용됩니다.

• VPC 네트워크 network-1은 두 번째 VPC 네트워크 network-2와 피어링됩니다.
• 또한 network-2는 세 번째 VPC 네트워크 network-3과 피어링됩니다.
• network-3은 network-1과 피어링되지 않습니다.

이 시나리오에서는 network-2에 대해 네트워크 관리자와 협의해야 합니다. network-2의 네트워크 관리자에게 VPC 네트워크의 피어링 경로를 나열하도록 요청합니다.

중복 검사에 대한 자세한 내용은 서브넷 및 피어링 서브넷 경로 상호작용을 참조하세요.

내부 DNS 이름이 피어링된 네트워크에서 확인되지 않음

피어링된 네트워크에서는 네트워크에 만들어진 Compute Engine 내부 DNS 이름에 액세스할 수 없습니다. 피어링된 네트워크의 VM 인스턴스에 연결하려면 VM의 IP 주소를 사용하세요.

태그와 서비스 계정은 피어링된 네트워크 간에 사용할 수 없음

방화벽 규칙에 있는 피어링된 네트워크의 VM과 관련된 태그 또는 서비스 계정을 다른 피어링된 네트워크에서 사용할 수 없습니다. 예를 들어 피어링된 네트워크의 인그레스 규칙이 태그를 기준으로 소스를 필터링하는 경우 피어링된 네트워크의 VN에 해당 태그가 있더라도 이 규칙은 피어가 아닌 네트워크 내에서 오는 VM 트래픽에만 적용됩니다. 이는 서비스 계정에서도 마찬가지입니다.

경로 교환 옵션

VPC 네트워크가 피어링된 VPC 네트워크와 로컬 경로를 공유할 때는 경로를 내보냅니다. 그런 후 피어링된 VPC 네트워크가 경로를 가져올 수 있습니다. 비공개로 사용된 공개 IPv4 주소를 사용하는 IPv4 서브넷을 제외하고 서브넷 경로가 항상 교환됩니다.

VPC 네트워크 피어링 구성을 사용하면 다음 항목을 제어할 수 있습니다.

• IPv6 경로가 교환되는지 여부
• 비공개로 사용된 공개 IPv4 주소를 사용하는 서브넷의 경로를 내보내거나 가져오는지 여부
• 정적 및 동적 경로를 내보내거나 가져오는지 여부

피어링을 설정하기 전에 또는 피어링 연결이 활성화된 동안에 구성을 업데이트할 수 있습니다.

VPC 네트워크 피어링은 다음을 제공하지 않습니다.

• 특정 서브넷 경로, 정적 경로, 동적 경로의 교환을 제어하기 위한 세분화된 방법
• 정책 기반 경로 교환 지원

서브넷 경로 교환 옵션

다음 표에서는 서브넷 경로에 대한 경로 교환 옵션에 대해 설명합니다.

경로 유형	경로 내보내기 조건	경로 가져오기 조건
비공개 IPv4 주소 범위를 사용하는 IPv4 서브넷 경로(기본 및 보조 IPv4 서브넷 범위)	항상 내보내기 사용 중지할 수 없음	항상 가져오기 사용 중지할 수 없음
비공개로 사용된 공개 IPv4 주소 범위를 사용하는 IPv4 서브넷 경로(기본 및 보조 IPv4 서브넷 범위)	기본적으로 내보내기 --export-subnet-routes-with-public-ip 플래그를 사용하여 내보내기 제어	기본적으로 가져오지 않음 --import-subnet-routes-with-public-ip 플래그를 사용하여 가져오기 제어
내부 IPv6 서브넷 범위 (ipv6-access-type=INTERNAL)	기본적으로 내보내지 않음 --stack-type=IPV4_IPV6를 사용하여 내보내기 사용 설정	기본적으로 가져오지 않음 --stack-type=IPV4_IPV6를 설정하여 가져오기 사용 설정
외부 IPv6 서브넷 범위 (ipv6-access-type=EXTERNAL)	기본적으로 내보내지 않음 --stack-type=IPV4_IPV6를 사용하여 내보내기 사용 설정	기본적으로 가져오지 않음 --stack-type=IPV4_IPV6를 설정하여 가져오기 사용 설정

정적 경로 교환 옵션

다음 표에서는 정적 경로의 경로 교환 옵션에 대해 설명합니다.

경로 유형	경로 내보내기 조건	경로 가져오기 조건
네트워크 태그가 포함된 정적 경로(모든 다음 홉 유형)	내보낼 수 없음	가져올 수 없음
기본 인터넷 게이트웨이 다음 홉을 사용하는 정적 경로	내보낼 수 없음	가져올 수 없음
기본 인터넷 게이트웨이와 다른 다음 홉을 사용하고 네트워크 태그가 없는 IPv4 정적 경로	기본적으로 내보내지 않음 --export-custom-routes 플래그를 사용하여 내보내기 제어	기본적으로 가져오지 않음 --import-custom-routes 플래그를 사용하여 가져오기 제어
VM 인스턴스를 다음 홉으로 사용하고 네트워크 태그가 없는 IPv6 정적 경로	기본적으로 내보내지 않음 피어링의 스택 유형이 --stack-type=IPV4_IPV6로 설정되었을 때 --export-custom-routes 플래그를 사용하여 내보내기 제어	기본적으로 가져오지 않음 피어링의 스택 유형이 --stack-type=IPV4_IPV6로 설정되었을 때 --import-custom-routes 플래그를 사용하여 가져오기 제어

동적 경로 교환 옵션

다음 표에서는 동적 경로에 대한 경로 교환 옵션에 대해 설명합니다.

경로 유형	경로 내보내기 조건	경로 가져오기 조건
동적 IPv4 경로	기본적으로 내보내지 않음 --export-custom-routes 플래그를 사용하여 내보내기 제어	기본적으로 가져오지 않음 --import-custom-routes 플래그를 사용하여 가져오기 제어
동적 IPv6 경로	기본적으로 내보내지 않음 피어링의 스택 유형이 --stack-type=IPV4_IPV6로 설정되었을 때 --export-custom-routes 플래그를 사용하여 내보내기 제어	기본적으로 가져오지 않음 피어링의 스택 유형이 --stack-type=IPV4_IPV6로 설정되었을 때 --import-custom-routes 플래그를 사용하여 가져오기 제어

정적 경로 및 동적 경로 교환의 이점

하나의 VPC 네트워크가 정적 및 동적 경로를 내보내고 다른 VPC 네트워크가 이러한 경로를 가져올 때 가져오기 네트워크는 다음 홉이 피어 VPC 네트워크에 있는 가져온 각 정적 또는 동적 경로에 대한 다음 홉으로 직접 패킷을 전송할 수 있습니다.

로컬 VPC 네트워크의 네트워크 관리자는 --export-custom-routes 플래그를 사용하여 해당 네트워크의 정적 및 동적 경로의 내보내기를 제어합니다. 해당 피어링된 VPC 네트워크의 네트워크 관리자는 --import-custom-routes 플래그를 사용하여 이러한 정적 및 동적 경로의 가져오기를 제어합니다. 자세한 내용은 무시된 경로, 서브넷 및 피어링 서브넷 경로 상호작용, 서브넷 및 정적 경로 상호작용을 참조하세요.

피어링된 VPC 네트워크에서 정적 경로와 동적 경로를 가져오는 것은 다음과 같은 시나리오에서 유용할 수 있습니다.

• 피어링된 VPC 네트워크에 경로 기반 GKE 클러스터가 포함되어 있고 패킷을 해당 클러스터의 포드로 전송해야 할 경우. 포드 IP 주소가 피어링된 VPC 네트워크에 있는 정적 경로의 대상 범위로 구현됩니다.

• 온프레미스 네트워크와 피어링된 VPC 네트워크 간의 연결을 제공해야 하는 경우. 로컬 VPC 네트워크에 온프레미스 네트워크에 연결되는 다음 홉 Cloud VPN 터널, Cloud Interconnect 연결(VLAN) 또는 라우터 어플라이언스가 있는 동적 경로가 포함되어 있다고 가정합니다. 피어링된 VPC 네트워크에서 온프레미스 네트워크까지의 경로를 제공하려면 로컬 VPC 네트워크의 네트워크 관리자가 커스텀 경로 내보내기를 사용 설정하고 피어링된 VPC 네트워크의 네트워크 관리자는 커스텀 경로 가져오기를 사용 설정합니다. 온프레미스 네트워크에서 피어링된 VPC 네트워크까지의 경로를 제공하려면 로컬 VPC 네트워크의 네트워크 관리자는 온프레미스 네트워크에 연결하는 Cloud VPN 터널, Cloud Interconnect 연결(VLAN) 또는 라우터 어플라이언스의 BGP 세션을 관리하는 Cloud Router에서 Cloud Router 커스텀 공지 모드를 구성해야 합니다. 이러한 커스텀 공지 경로의 콘텐츠에는 피어링된 VPC 네트워크의 서브넷 IP 주소 범위가 포함되어야 합니다.

중요: Cloud Router는 기본 공지 모드를 사용할 때 수신된 피어링 서브넷 경로를 공지하지 않습니다. 피어링 서브넷 경로 또는 피어링 서브넷 경로의 집계 범위를 공지하려면 커스텀 공지 모드를 사용 설정하고 커스텀 공지 경로에 피어링된 VPC 네트워크의 서브넷 IP 주소 범위가 포함되어 있는지 확인해야 합니다.

무시된 경로

VPC 네트워크가 경로를 가져오는 경우에도 다음과 같은 상황에서는 가져온 경로를 무시할 수 있습니다.

• 로컬 VPC 네트워크에 대상이 동일하거나 보다 구체적인(더 긴 서브넷 마스크) 경로가 있으면 로컬 VPC 네트워크에 항상 로컬 경로가 사용됩니다.

• 로컬 VPC 네트워크에 패킷 대상에 대해 가장 세부적인 경로가 포함되지 않지만 둘 이상의 피어링된 VPC 네트워크에 패킷에 대해 동일하고 가장 구체적인 대상이 포함되어 있으면 Google Cloud가 내부 알고리즘에 따라 피어링된 VPC 네트워크 중 하나로부터 다음 홉을 선택합니다. 이러한 선택은 경로 우선순위가 고려되기 전에 수행되며, 사용자가 동작을 구성할 수 없습니다. 피어링된 VPC 네트워크를 추가하거나 삭제하면 라우팅 순서가 의도치 않게 변경될 수 있으므로, 권장사항에 따라 이 구성을 방지하는 것이 좋습니다.

앞에서 설명한 상황들에 대한 자세한 내용은 라우팅 순서를 참조하세요.

이중 스택 피어링의 경우 IPv6 경로를 가져오는 로컬 VPC 네트워크에 이중 스택 서브넷이 없으면 피어링된 VPC 네트워크에서 수신하는 IPv6 경로 중 어느 것도 사용할 수 없습니다. 또한 constraints/compute.disableAllIpv6 조직 정책 제약조건이 설정된 경우 네트워크 관리자가 이중 스택 서브넷을 만들지 못할 수 있습니다.

서브넷 및 피어링 서브넷 경로 상호작용

피어링된 VPC 네트워크의 IPv4 서브넷 경로는 중복될 수 없습니다.

• 피어링 시에는 동일한 IPv4 서브넷 경로가 금지됩니다. 예를 들어 2개의 피어링된 VPC 네트워크는 해당 대상이 100.64.0.0/10인 IPv4 서브넷 경로를 둘 다 포함할 수 없습니다.
• 피어링 시에는 서브넷 경로가 피어링 서브넷 경로 내에 포함되지 않도록 금지됩니다. 예를 들어 로컬 VPC 네트워크에 해당 대상이 100.64.0.0/24인 서브넷 경로가 있으면 피어링된 VPC 네트워크 중 어느 것도 해당 대상이 100.64.0.0/10인 서브넷 경로를 가질 수 없습니다.

Google Cloud는 다음과 같은 경우에 IPv4 서브넷 경로에 대해 앞의 조건을 적용합니다.

• VPC 네트워크 피어링을 사용하여 VPC 네트워크를 처음 연결하는 경우
• 네트워크를 피어링하는 동안
• 피어링 구성을 변경하는 경우(예를 들어 비공개로 사용된 공개 IP 주소로 서브넷 IPv4 경로 가져오기를 사용 설정하는 경우)

네트워크를 피어링할 때 다음 작업으로 인해 중복이 발생하면 Google Cloud에서 오류가 반환됩니다.

• 새 서브넷 추가

• 서브넷 보조 IPv4 주소 범위 추가

• 서브넷 기본 IPv4 주소 범위 확장

IPv6 서브넷 경로(내부 및 외부 모두)는 고유하게 정의됩니다. 2개의 VPC 네트워크가 동일한 내부 또는 외부 IPv6 서브넷 범위를 사용할 수 없습니다. 예를 들어 한 VPC 네트워크에서 fc:1000:1000:1000::/64를 IPv6 서브넷 범위로 사용하면 VPC 네트워크가 VPC 네트워크 피어링을 사용하여 연결되었는지 여부와 관계없이 Google Cloud에 있는 다른 VPC 네트워크가 fc:1000:1000:1000::/64를 사용할 수 없습니다.

서브넷 및 정적 경로 상호작용

Google Cloud를 사용하려면 서브넷 경로 및 피어링 서브넷 경로에 가장 구체적인 대상 IPv4 또는 IPv6 범위가 포함되어야 합니다. VPC 네트워크 내에서 로컬 정적 경로는 로컬 서브넷 경로와 정확하게 일치하거나 이를 포함하는 경로를 가질 수 없습니다. 이 시나리오에 대한 자세한 설명은 정적 경로와 상호작용을 참조하세요.

이 개념은 다음 두 규칙에 따라 VPC 네트워크 피어링으로 확장됩니다.

• 로컬 정적 경로는 피어링 서브넷 경로와 정확하게 일치하거나 여기에 포함되는 대상을 가질 수 없습니다. 로컬 정적 경로가 존재할 경우 Google Cloud가 다음을 적용합니다.

  • 피어링 구성으로 인해 충돌하는 서브넷 경로를 가져오는 경우 로컬 정적 경로의 대상과 정확하게 일치하거나 이를 포함하는 서브넷 경로가 이미 있는 VPC 네트워크에 대해 새로운 피어링 연결을 설정할 수 없습니다. 예를 들면 다음과 같습니다.

    • 대상이 10.0.0.0/24인 로컬 정적 경로가 존재할 경우 대상이 10.0.0.0/24와 정확하게 일치하거나 10.0.0.0/24를 포함하는(예: 10.0.0.0/8) IPv4 서브넷 경로가 포함된 VPC 네트워크에 대해 새 피어링 연결을 설정할 수 없습니다.

    • 의도한 피어링 스택 유형이 IPV4_IPV6인 경우 2001:0db8:0a0b:0c0d::/96 대상 위치를 포함하는 로컬 정적 경로가 있으면 VPC 네트워크에 대해 새 피어링 대상이 정확하게 일치하거나 2001:0db8:0a0b:0c0d::/96을 포함하는 IPv6 서브넷 경로로 연결을 설정할 수 없습니다. 이 상황에서 가능한 유일한 서브넷 IPv6 주소 범위는 2001:0db8:0a0b:0c0d::/64이며, 이는 Google Cloud의 서브넷 IPv6 주소 범위가 64비트 서브넷 마스크 길이를 사용해야 하기 때문입니다.

  • 업데이트된 피어링 구성으로 인해 충돌하는 서브넷 경로를 가져오는 경우 기존 피어링 연결을 업데이트할 수 없습니다. 예를 들면 다음과 같습니다.

    • VPC 네트워크 2개가 이미 피어링되어 있지만 비공개로 사용되는 공개 IPv4 주소 범위를 사용하여 IPv4 서브넷 경로를 내보내고 가져오지 않는다고 가정해 보겠습니다. 11.0.0.0/24 대상의 로컬 정적 경로가 첫 번째 VPC 네트워크에 있고 대상 11.0.0.0/8가 있는 서브넷 경로가 피어링된 VPC 네트워크에 있습니다. 피어링된 VPC 네트워크가 비공개로 사용되는 공개 IPv4 주소를 사용하여 서브넷 경로를 내보내도록 하는 동시에 첫 번째 VPC 네트워크를 비공개로 사용되는 공개 IPv4 주소를 사용하여 서브넷 경로를 가져오도록 구성할 수 없습니다.

    • 두 VPC 네트워크가 이미 피어링되었고 피어링 스택 유형이 IPv4 뿐이라고 가정해 보겠습니다. 2001:0db8:0a0b:0c0d::/96 대상의 로컬 정적 경로가 첫 번째 VPC 네트워크에 있고 대상 2001:0db8:0a0b:0c0d::/64가 있는 IPv6 서브넷 경로가 피어링된 VPC 네트워크에 있습니다. 피어링 스택 유형은 IPV4_IPV6로 변경할 수 없습니다.

  • 반대로 VPC 네트워크가 이미 VPC 네트워크 피어링을 사용하여 연결된 경우 다음 작업을 수행할 수 없습니다.

    • 대상이 가져온 피어링 서브넷 경로와 정확하게 일치하거나 이를 포함하는 새 로컬 정적 경로를 만듭니다.

    • 해당 범위가 기존 로컬 정적 경로와 정확하게 일치하거나 이를 포함하는 경우 피어링된 VPC 네트워크에서 새 서브넷 주소 범위를 만듭니다.

• 피어링 정적 경로는 로컬 서브넷 경로와 정확하게 일치하거나 이를 포함하는 대상을 가질 수 없습니다. 로컬 서브넷 경로가 있으면 Google Cloud에서 다음 항목이 금지됩니다.

  • 피어링 구성으로 인해 피어에서 정적 경로를 가져오는 경우 로컬 VPC 네트워크에서 서브넷 경로의 대상과 정확하게 일치하거나 이를 포함하는 정적 경로가 이미 포함된 VPC 네트워크에 대해 새로운 피어링 연결을 설정할 수 없습니다. 예를 들면 다음과 같습니다.

    • 10.0.0.0/8의 로컬 서브넷 경로가 있는 경우 해당 대상이 10.0.0.0/8과 정확하게 일치하거나 10.0.0.0/8에 포함되는(예: 10.0.0.0/24) 정적 경로를 사용하여 VPC 네트워크에 피어링 연결을 설정할 수 없습니다.

    • 의도한 피어링 스택 유형이 IPV4_IPV6인 경우 2001:0db8:0a0b:0c0d::/64의 로컬 서브넷 경로가 있으면 VPC 네트워크에 대해 대상이 2001:0db8:0a0b:0c0d::/64와 정확하게 일치하거나 2001:0db8:0a0b:0c0d::/64를 포함하는 정적 경로(예: 2001:0db8:0a0b:0c0d::/96)로 피어링 연결을 설정할 수 없습니다.

  • 업데이트된 피어링 구성으로 인해 충돌하는 정적 경로를 가져오는 경우 기존 피어링 연결을 업데이트할 수 없습니다.

  • 반대로 VPC 네트워크가 이미 VPC 네트워크 피어링을 사용하여 연결된 경우 다음 작업을 수행할 수 없습니다.

    • 대상이 가져온 피어링 정적 경로와 정확하게 일치하거나 이를 포함하는 새 로컬 서브넷 경로를 만듭니다.
    • 해당 대상이 기존 로컬 서브넷 경로와 정확하게 일치하거나 이를 포함하는 피어링된 VPC 네트워크에 새 정적 경로를 만듭니다.

동적 라우팅 모드의 영향

VPC 네트워크의 동적 라우팅 모드에 따라 해당 네트워크의 Cloud Router에서 학습된 프리픽스가 로컬 동적 경로로 적용되는 리전이 결정됩니다. 이 동작에 대한 자세한 내용은 동적 라우팅 모드의 영향을 참조하세요.

이 개념은 VPC 네트워크 피어링으로 확장됩니다. 동적 경로의 프리픽스를 학습한 Cloud Router가 포함된 내보내는 VPC 네트워크의 동적 라우팅 모드에 따라 피어 네트워크에서 피어링 동적 경로를 프로그래밍할 수 있는 리전이 결정됩니다.

• 내보내는 VPC 네트워크의 동적 라우팅 모드가 리전별이면 프리픽스를 학습한 Cloud Router와 동일한 리전에서만 네트워크가 동적 경로를 내보냅니다.

• 내보내는 VPC 네트워크의 동적 라우팅 모드가 전역적이면 네트워크가 모든 리전의 동적 경로를 내보냅니다.

두 경우 모두 가져오는 VPC 네트워크의 동적 라우팅 모드는 관련이 없습니다.

이 동작을 보여주는 예시는 온프레미스 연결을 사용하는 로컬 VPC 네트워크 및 피어 VPC 네트워크를 참조하세요.

서브넷 및 동적 경로 상호작용

로컬 및 피어링 서브넷 경로와 동적 경로 사이의 충돌은 동적 경로와의 상호작용에 설명된 대로 해결됩니다.

VPC 네트워크 피어링 예시

다음 예시에서는 두 가지 일반적인 VPC 네트워크 피어링 시나리오를 보여줍니다.

온프레미스 연결을 사용하는 로컬 VPC 네트워크 및 피어 VPC 네트워크

이 예시에서는 다음과 같이 네트워크 피어링을 설정합니다.

• network-a는 network-b로 피어링되고 network-b는 network-a로 피어링됩니다.
• network-a에는 각각 별도의 리전에 있는 두 개의 서브넷이 포함됩니다. network-b에는 단일 서브넷이 포함됩니다.
• network-b는 동적 라우팅을 사용해서 Cloud VPN 터널을 통해 온프레미스 네트워크에 연결됩니다. (터널을 Cloud Interconnect VLAN 연결로 바꿔도 동일한 원칙이 적용됩니다.)
• network-b의 피어링 연결은 --export-custom-routes 플래그로 구성되고 network-a의 피어링 연결은 --import-custom-routes 플래그로 구성됩니다.

전역 동적 라우팅을 사용하는 온프레미스 네트워크에 액세스할 수 있는 피어링된 네트워크(확대하려면 클릭)

온프레미스에서 network-a 및 network-b의 서브넷까지의 연결을 제공하려면 network-b의 Cloud Router에서 커스텀 공지 모드를 사용하도록 구성해야 합니다. 예를 들어 Cloud Router는 network-b의 서브넷 범위와 network-a의 서브넷 범위를 포함하는 custom-prefix-1 커스텀 프리픽스만 공지합니다.

us-west1의 Cloud Router는 온프레미스 라우터에서 on-premises-prefix를 학습합니다. on-premises-prefix은 서브넷 및 피어링 서브넷 경로보다 포괄적이므로 충돌을 일으키지 않습니다. 즉, on-premises-prefix은 서브넷 또는 피어링 서브넷 경로와 정확하게 일치하거나 내부에 포함되지 않습니다.

다음 표에는 앞의 예시에 명시된 네트워크 구성이 요약되어 있습니다.

네트워크 이름	네트워킹 구성요소	IPv4 범위	IPv6 범위	리전
network-a	subnet-a	10.0.0.0/24	fc:1000:1000:1000::/64	us-west1
network-a	subnet-b	10.0.1.0/24	fc:1000:1000:1001::/64	europe-north 1
network-b	subnet-c	10.0.2.0/23	fc:1000:1000:1002::/64	us-west1
network-b	Cloud Router	10.0.0.0/22	fc:1000:1000:1000::/64	us-west1
온프레미스 네트워크	온프레미스 라우터	10.0.0.0/8	fc:1000:1000:1000::/56	해당 사항 없음

network-a의 동적 라우팅 모드에 관계없이 다음 라우팅 특성이 적용됩니다.

• network-b의 동적 라우팅 모드가 전역적이면 network-b에서 Cloud Router로 학습된 On-premises prefix가 network-b의 모든 리전에 동적 경로로 추가되고 그리고 network-a의 모든 리전에 피어링 동적 경로로 추가됩니다. 방화벽 규칙이 올바르게 구성된 경우 vm-a1 ,vm-a2 및 vm-b가 IPv4 주소 10.5.6.7(또는 IPv6 주소 fc:1000:1000:10a0:29b::)로 온프레미스 리소스와 통신할 수 있습니다.

• network-b의 동적 라우팅 모드가 리전별로 변경된 경우에는 network-b에서 Cloud Router로 학습된 On-premises prefix가 network-b의 us-west1 리전에 동적 경로만으로 추가되고 network-a의 us-west1 리전에 피어링 동적 경로만으로 추가됩니다. 방화벽 규칙이 올바르게 구성되었으면 Cloud Router와 동일한 리전의 유일한 VM이므로 vm-a1 및 vm-b만 IPv4 주소 10.5.6.7(또는 IPv6 주소 fc:1000:1000:10a0:29b::)을 사용하여 온프레미스 리소스와 통신할 수 있습니다.

피어링이 여러 개 있는 전송 네트워크

network-b가 온프레미스 네트워크에 연결되어 있고 다른 두 네트워크 network-a 및 network-c의 전송 네트워크로 작동하는 시나리오가 있다고 가정해 보세요. 이러한 네트워크 모두의 VM에서 내부 IP 주소만 사용하여 network-b 및 연결된 온프레미스 네트워크에 액세스할 수 있게 하려면 다음 구성이 필요합니다.

• network-a는 network-b로 피어링되고 network-b는 network-a로 피어링됩니다.
• network-c는 network-b로 피어링되고 network-b는 network-c로 피어링됩니다.
• network-b는 동적 라우팅을 사용해서 Cloud VPN 터널을 통해 온프레미스 네트워크에 연결됩니다. 터널을 Cloud Interconnect VLAN 연결로 바꿔도 동일한 원칙이 적용됩니다.
  • 온프레미스에서 network-a, network-b, network-c의 서브넷까지의 연결을 제공하려면 network-b의 Cloud Router에서 커스텀 공지 모드를 사용하도록 구성합니다. 예를 들어 Cloud Router는 network-a 및 network-c의 서브넷 경로를 포함하는 커스텀 프리픽스와 함께 network-b의 서브넷 경로를 공지합니다.
  • 서브넷 및 동적 경로 상호작용에 따라 network-b의 Cloud Router는 온프레미스 프리픽스를 학습하고 network-b에 동적 경로를 만듭니다.
• network-b에서 network-a로, network-b에서 network-c로의 피어링 연결은 --export-custom-routes 플래그로 구성됩니다. network-a에서 network-b로, network-c에서 network-b로의 피어링 연결은 --import-custom-routes 플래그로 구성됩니다.
  • 서브넷 및 동적 경로 상호작용에 따라 network-b의 Cloud Router는 또한 network-a 및 network-c에서 피어링 동적 경로를 만듭니다.

VPC 전송 네트워크(확대하려면 클릭)

방화벽이 올바르게 구성되었으면 다음 연결 시나리오가 가능합니다.

• network-a의 VM 인스턴스가 network-b 및 온프레미스 시스템의 다른 VM에 연결할 수 있습니다.
• network-c의 VM 인스턴스가 network-b 및 온프레미스 시스템의 다른 VM에 연결할 수 있습니다.
• network-b의 VM 인스턴스는 온프레미스 네트워크의 시스템뿐만 아니라 network-a 및 network-c의 다른 VM에도 연결할 수 있습니다.

VPC 네트워크 피어링은 전환되지 않으므로 VPC 네트워크 피어링을 사용하여 network-a 및 network-c 네트워크도 연결하지 않는 한 network-a 및 network-c의 VM 인스턴스가 서로 통신할 수 없습니다.

가격 책정

VPC 네트워크 피어링에는 일반 네트워크 가격 책정이 적용됩니다.

다음 단계

• VPC 네트워크 피어링을 설정하고 문제를 해결하려면 VPC 네트워크 피어링 설정 및 관리를 참조하세요.