컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

VPC 네트워크 피어링

Google Cloud VPC 네트워크 피어링은 2개의 Virtual Private Cloud(VPC) 네트워크를 연결하여 각 네트워크의 리소스가 서로 통신할 수 있게 해줍니다.

  • 모든 서브넷은 내부 IPv4 주소를 사용하여 통신할 수 있습니다.
  • 이중 스택 서브넷은 또한 내부 또는 외부 IPv6 주소를 사용하여 통신할 수 있습니다.

피어링된 VPC 네트워크는 동일한 프로젝트, 동일 조직의 다른 프로젝트, 다른 조직의 다른 프로젝트에 설정할 수 있습니다.

VPC 네트워크 피어링은 다음과 같은 이점을 제공합니다.

VPC 네트워크 피어링의 이점

VPC 네트워크 피어링은 다음과 같은 이점이 있습니다.

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

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

사양

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

일반 사양:

  • VPC 네트워크 피어링은 Compute Engine, GKE 및 App Engine 가변형 환경에서 작동합니다.
    • 기본적으로 GKE를 사용한 VPC 네트워크 피어링은 IP 별칭과 함께 사용할 경우에 지원됩니다. IP 별칭을 사용하지 않는 경우 피어링된 네트워크에서 GKE 컨테이너에 액세스할 수 있도록 커스텀 경로를 내보낼 수 있습니다.
  • VPC 네트워크 피어링에서는 VPC 네트워크만 지원됩니다. 이전 네트워크에서는 피어링이 지원되지 않습니다.
  • VPC 네트워크 피어링은 IPv4 및 IPv6 연결을 둘 다 지원합니다. 이중 스택 서브넷을 포함하는 VPC 네트워크에서 VPC 네트워크 피어링을 구성할 수 있습니다. 그러나 IPv6의 경우 동적 경로만 교환됩니다.
  • 하나의 VPC 네트워크에 여러 개의 VPC 네트워크를 피어링할 수 있지만 제한이 있습니다.

관리 분리:

  • 피어링된 VPC 네트워크는 관리 측면에서 분리된 상태로 유지됩니다. 경로, 방화벽, VPN, 기타 트래픽 관리 도구는 각 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 피어는 항상 서브넷 경로를 내보냅니다.
  • 서브넷에 비공개 IP 주소가 사용될 경우 VPC 피어가 항상 서브넷 경로를 가져옵니다. 서브넷이 비공개로 사용되는 공개 IP 주소를 사용하는 경우 피어링된 네트워크는 비공개로 사용되는 공개 IP 서브넷 경로를 명시적으로 가져와 다른 네트워크에서 수신해야 합니다. 비공개 IP 주소 및 비공개로 사용되는 공개 IP 주소에 대한 자세한 내용은 유효한 범위를 참조하세요.
  • 서브넷 경로 교환을 사용 중지하거나 교환할 서브넷 경로를 선택할 수 없습니다. 피어링이 설정되면 서브넷 IP 주소 내의 모든 리소스를 직접 피어링된 네트워크를 통해 액세스 가능합니다. VPC 네트워크 피어링은 피어링된 네트워크에서 액세스 가능한 서브넷 CIDR 범위를 필터링하기 위한 세분화된 경로 제어를 제공하지 않습니다. 필요한 경우 방화벽 규칙을 사용하여 트래픽을 필터링해야 합니다. 다음 엔드포인트 및 리소스 유형은 직접 피어링된 네트워크를 통해 액세스 가능합니다.
    • 모든 서브넷의 가상 머신(VM) 내부 IP
    • 모든 서브넷의 내부 부하 분산된 IP
  • 피어링 구성이 가져오기 또는 내보내기를 수행하도록 구성되었는지 여부에 따라 커스텀 경로(정적 및 동적 경로)를 교환할 수 있습니다. 자세한 내용은 커스텀 경로 가져오기 및 내보내기를 참조하세요.
  • 서브넷 및 정적 경로는 전역 경로입니다. 동적 경로는 VPC 네트워크의 동적 라우팅 모드에 따라 리전으로 또는 전역으로 적용될 수 있습니다.
  • 피어링된 한 VPC 네트워크의 서브넷 CIDR 범위는 다른 피어링된 네트워크의 정적 경로와 겹칠 수 없습니다. 이 규칙은 서브넷 경로와 정적 경로 모두에 적용됩니다. Google Cloud는 다음과 같은 상황에서 중복을 검사하여 중복이 발생할 경우 오류를 생성합니다.
    • VPC 네트워크를 처음 구성할 때
    • 피어링된 VPC 네트워크에서 정적 경로를 만들 때
    • 피어링된 VPC 네트워크에서 새 서브넷을 만들 때
  • 동적 경로는 피어 네트워크의 서브넷 경로와 겹칠 수 있습니다. 동적 경로의 경우 피어 네트워크의 서브넷 경로와 겹치는 대상 범위는 자동으로 삭제되며, Google Cloud는 서브넷 경로를 사용합니다.

제한사항:

  • 직접 피어링된 네트워크만 통신할 수 있습니다. 전환 피어링은 지원되지 않습니다. 즉, VPC 네트워크 N1이 N2 및 N3과 피어링되었지만 N2와 N3이 직접 연결되지 않은 경우 VPC 네트워크 N2는 VPC 네트워크 피어링을 통해 VPC 네트워크 N3과 통신할 수 없습니다.
  • VPC 방화벽 규칙은 피어링된 네트워크에서 네트워크 태그 또는 서비스 계정을 사용할 수 없습니다. 자세한 내용은 네트워크 보안을 참조하세요.
  • 피어링된 네트워크에서는 네트워크에 만들어진 Compute Engine 내부 DNS 이름에 액세스할 수 없습니다. 피어링된 네트워크에서 VM 인스턴스에 액세스하려면 IP 주소를 사용하세요.
  • 정책 기반 경로는 피어링을 통해 교환되지 않습니다.

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

네트워크 보안

VPC 네트워크 피어링은 VPC 방화벽 규칙 또는 계층식 방화벽 정책을 교환하지 않습니다. 하나의 VPC 네트워크에 있는 VPC 방화벽 규칙은 다른 VPC 네트워크의 네트워크 태그 또는 서비스 계정을 사용하여 대상 또는 소스를 지정할 수 없습니다. 하지만 두 네트워크 모두에서 동일한 대상 네트워크 태그를 사용할 수 있습니다.

모든 VPC 네트워크에는 묵시적인 방화벽 규칙이 포함됩니다. 묵시적인 인그레스 거부 방화벽 규칙으로 인해 로컬 VPC 네트워크의 보안 관리자가 적절한 인그레스 허용 방화벽 규칙 또는 계층식 방화벽 정책을 만들어야 합니다. 이러한 규칙 또는 정책은 피어링된 VPC 네트워크에서 필요한 소스 IP 주소 범위의 패킷을 허용합니다.

묵시적인 이그레스 허용 방화벽 규칙으로 인해 피어링된 VPC 네트워크의 대상에 대해 패킷을 허용하기 위해 이그레스 허용 방화벽 규칙 또는 계층식 방화벽 정책을 만들 필요가 없습니다. 그러나 로컬 VPC 네트워크 보안 관리자가 명시적 이그레스 거부 규칙을 만들었으면 이그레스 허용 규칙 또는 정책을 만들어야 합니다.

DNS 지원

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

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

내부 부하 분산기 지원

로컬 VPC 네트워크의 클라이언트는 피어 VPC 네트워크의 내부 TCP/UDP 부하 분산기에 액세스할 수 있습니다. 자세한 내용은 내부 TCP/UDP 부하 분산기에 VPC 네트워크 피어링 사용을 참조하세요. 피어링된 네트워크는 내부 TCP/UDP 부하 분산기를 다음 홉을 사용하여 커스텀 정적 경로를 교환할 수 있습니다. 자세한 내용은 경로 교환 옵션을 참조하세요.

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

VPC 네트워크 피어링 한도

VPC 네트워크 피어링 한도에 따라 다음 항목이 제어됩니다.

  • 피어링 그룹에 존재할 수 있는 가상 머신(VM) 인스턴스 또는 내부 전달 규칙과 같은 리소스 수
  • 지정된 VPC 네트워크가 연결할 수 있는 네트워크 수

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

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

경로 교환 옵션

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

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

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

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

서브넷 경로 교환 옵션

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

경로 유형 경로 내보내기 조건 경로 가져오기 조건
비공개 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를 설정하여 가져오기 사용 설정

커스텀 정적 경로 교환 옵션

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

경로 유형 경로 내보내기 조건 경로 가져오기 조건
네트워크 태그가 포함된 커스텀 정적 경로(모든 다음 홉 유형) 내보낼 수 없음 가져올 수 없음
기본 인터넷 게이트웨이 다음 홉을 사용하는 커스텀 정적 경로 내보낼 수 없음 가져올 수 없음
내부 TCP/UDP 부하 분산기의 비공개 IPv4 주소를 다음 홉으로 사용하고 네트워크 태그가 없는 커스텀 IPv4 정적 경로 항상 내보내기(예: 서브넷 IPv4 경로)

사용 중지할 수 없음 		항상 가져오기(예: 서브넷 IPv4 경로)

사용 중지할 수 없음
내부 TCP/UDP 부하 분산기의 전달 규칙 이름을 다음 홉으로 사용하고 네트워크 태그가 없는 커스텀 IPv4 정적 경로 기본적으로 내보내지 않음

--export-custom-routes 플래그를 사용하여 내보내기 제어 		기본적으로 가져오지 않음

--import-custom-routes 플래그를 사용하여 가져오기 제어
다른 다음 홉 유형을 사용하고 네트워크 태그가 없는 커스텀 IPv4 정적 경로 기본적으로 내보내지 않음

--export-custom-routes 플래그를 사용하여 내보내기 제어 		기본적으로 가져오지 않음

--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 네트워크에서 커스텀 경로 가져오기는 다음과 같은 시나리오에서 유용할 수 있습니다.

  • 피어링된 VPC 네트워크에 경로 기반 GKE 클러스터가 포함되어 있고 해당 클러스터의 포드로 패킷을 전송해야 할 경우: 포드 IP 주소가 피어링된 VPC 네트워크에 있는 커스텀 정적 경로에 대한 대상 범위로 구현됩니다.
  • 피어링된 VPC 네트워크에 온프레미스 리소스에 대한 경로가 포함되어 있고 로컬 VPC 네트워크의 리소스에 액세스해야 하는 경우: 또한 온프레미스 네트워크에서 로컬 VPC 네트워크의 서브넷 IP 주소 범위에 대해 경로를 만들어야 합니다. 이러한 추가 요구사항을 달성하기 위해서는 피어링된 VPC 네트워크에서 Cloud Router 커스텀 경로 공지를 사용할 수 있습니다.

중요: Cloud Router는 기본 공지 모드를 사용할 때 피어링 서브넷 경로를 공지하지 않습니다. 따라서 피어링 서브넷 경로를 공지하기 위해(또는 피어링 서브넷 경로의 범위를 수집하기 위해) 커스텀 경로 공지를 사용해야 합니다.

무시된 경로

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에서 오류가 반환됩니다.

IPv6 서브넷 경로(내부 및 외부 모두)는 고유하게 정의됩니다. 2개의 VPC 네트워크가 동일한 내부 또는 외부 IPv6 서브넷 범위를 사용할 수 없습니다.

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

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) 서브넷 경로가 포함된 VPC 네트워크에 대해 새 피어링 연결을 설정할 수 없습니다.

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

      예를 들어 대상이 11.0.0.0/24인 로컬 정적 경로가 존재하고 대상이 11.0.0.0/8인 서브넷 경로가 피어링된 VPC 네트워크에 존재할 경우 비공개로 사용된 공개 IPv4 주소를 사용하여 서브넷 경로를 내보내도록 피어링된 VPC 네트워크를 구성할 수 없으며, 비공개로 사용된 공개 IPv4 주소를 사용하여 서브넷 경로를 가져오도록 로컬 VPC 네트워크를 구성할 수 없습니다.

    • 반대로 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 네트워크에 피어링 연결을 설정할 수 없습니다.

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

    • 반대로 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에는 기본 IPv4 주소 범위가 us-west1의 10.0.0.0/24인 서브넷이 포함됩니다.
    • network-a에는 기본 IPv4 주소 범위가 europe-north1의 10.0.1.0/24인 서브넷이 포함됩니다.
    • network-b에는 기본 IPv4 주소 범위가 us-west1의 10.0.2.0/23인 서브넷이 포함됩니다.
  • network-b는 동적 라우팅을 사용해서 Cloud VPN 터널을 통해 온프레미스 네트워크에 연결됩니다. (터널을 Cloud Interconnect VLAN 연결로 바꿔도 동일한 원칙이 적용됩니다.)
    • 온프레미스에서 network-a 및 network-b의 서브넷으로 연결을 제공하려면 커스텀 경로 공지를 사용하도록 network-b의 Cloud Router를 구성해야 합니다. 예를 들어 Cloud Router는 network-b의 10.0.2.0/23 서브넷 범위와 network-a의 10.0.0.0/24 및 10.0.1.0/24 서브넷 범위를 포함하는 10.0.0.0/22 커스텀 프리픽스만 공지합니다.
    • us-west1의 Cloud Router는 온프레미스 라우터에서 10.0.0.0/8 프리픽스를 학습합니다. 10.0.0.0/8은 서브넷 및 피어링 서브넷 경로보다 포괄적이므로 충돌을 일으키지 않습니다. 즉, 10.0.0.0/8은 서브넷 또는 피어링 서브넷 경로와 정확하게 일치하거나 내부에 포함되지 않습니다.
  • network-b의 피어링 연결은 해당 커스텀 경로를 내보내도록 구성되고, network-a의 피어링 연결은 커스텀 경로를 가져오도록 구성됩니다.

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

  • network-b의 동적 라우팅 모드가 전역적이면 network-b에서 Cloud Router로 학습된 온프레미스 프리픽스(10.0.0.0/8)가 network-b의 모든 리전에 동적 경로로 추가되고 그리고 network-a의 모든 리전에 피어링 동적 경로로 추가됩니다. 방화벽 규칙이 올바르게 구성되었으면 vm-a1, vm-a2, vm-b가 IP 주소 10.5.6.7을 사용하여 온프레미스 리소스와 통신할 수 있습니다.

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

전송 네트워크

다음 예시에서 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로의 피어링 연결은 커스텀 경로를 내보내도록 구성되었습니다. network-a에서 network-b로 그리고 network-c에서 network-b로의 피어링 연결은 커스텀 경로를 가져오도록 구성되었습니다.

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

  • 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 인스턴스가 서로 통신할 수 없습니다.

다음 단계