스포크 관리 개요

이 페이지에서는 Virtual Private Cloud(VPC) 스포크 관리자의 관점에서 개요를 제공합니다.

Network Connectivity Center 허브와 VPC 스포크가 동일한 프로젝트에 있으면 VPC 스포크 관리자는 해당 프로젝트에 대해 다음과 같은 Identity and Access Management(IAM) 바인딩이 모두 있어야 합니다.

Network Connectivity Center 허브와 VPC 스포크가 서로 다른 프로젝트에 있는 경우 IAM 정책에 다음 바인딩이 있어야 합니다.

커스텀 역할에 앞서 나열된 사전 정의된 역할과 동일한 권한이 포함되어 있는 한 커스텀 역할을 사용할 수도 있습니다.

VPC 네트워크와 Network Connectivity Center 허브가 서로 다른 프로젝트에 있는 경우 VPC 스포크 관리자가 스포크 제안서를 만들어 VPC 네트워크가 허브에 참여하도록 요청해야 합니다. 허브 관리자가 제안서를 검토합니다. 허브 관리자가 제안을 수락하면 VPC 네트워크가 허브에 연결됩니다. 허브 관리자는 스포크 제안을 거부할 수도 있습니다. 스포크 관리자는 언제든지 VPC 스포크 제안서의 상태를 확인할 수 있습니다.

자세한 내용은 다음 섹션을 참조하세요.

서브넷 경로 고유성

VPC 네트워크 피어링과 마찬가지로 Google Cloud는 Network Connectivity Center 허브에 연결된 VPC 스포크 간의 서브넷 IP 주소 범위 충돌을 금지합니다. 다음 중 하나가 true인 경우 서브넷 IP 주소 범위가 다른 서브넷 IP 주소 범위와 충돌합니다.

  • 한 VPC 네트워크의 서브넷 IP 주소 범위가 다른 VPC 네트워크의 서브넷 IP 주소 범위와 정확하게 일치합니다.
  • 한 VPC 네트워크의 서브넷 IP 주소 범위가 다른 VPC 네트워크의 서브넷 IP 주소 범위에 포함됩니다.
  • 한 VPC 네트워크의 서브넷 IP 주소 범위가 다른 VPC 네트워크의 서브넷 IP 주소 범위를 포함합니다.

VPC 스포크는 충돌하는 서브넷 IP 주소 범위를 동일한 Network Connectivity Center 허브로 내보낼 수 없습니다. Google Cloud CLI에서 exclude-export-ranges 플래그를 사용하거나 API에서 excludeExportRanges 필드를 사용하여 Network Connectivity Center 허브로의 VPC 스포크가 서브넷 IP 주소 범위를 공유하지 않도록 할 수 있습니다. 예를 들어 동일한 Network Connectivity Center 허브에 연결하려는 VPC 네트워크가 두 개 있다고 가정해 보겠습니다.

  • 첫 번째 VPC 네트워크에는 기본 내부 IPv4 주소 범위가 100.64.0.0/16인 서브넷이 있으므로 100.64.0.0/16의 서브넷 경로가 생성됩니다.
  • 두 번째 VPC 네트워크에는 보조 내부 IPv4 주소 범위가 100.64.0.0/24인 서브넷이 있으므로 100.64.0.0/24의 서브넷 경로가 생성됩니다.

100.64.0.0/24가 100.64.0.0/16 내에 포함되므로 두 서브넷 경로의 서브넷 IP 주소 범위가 충돌합니다. 충돌을 해결하지 않는 한 두 네트워크를 모두 동일한 Network Connectivity Center 허브에 대한 VPC 스포크로 연결할 수 없습니다. 다음 전략 중 하나를 사용하여 충돌을 해결할 수 있습니다.

  • 첫 번째 VPC 네트워크를 허브에 연결할 때 100.64.0.0/16 IP 주소 범위를 제외하거나 두 번째 VPC 네트워크를 허브에 연결할 때 100.64.0.0/24 IP 주소 범위를 제외하는 방법입니다.
  • 각 VPC 네트워크를 연결할 때 100.64.0.0/16 또는 전체 RFC 6598 공간인 100.64.0.0/10을 제외합니다.

VPC 네트워크 피어링 서브넷 경로와의 상호작용

피어링 서브넷 경로는 VPC 네트워크 피어링을 사용하여 연결된 VPC 네트워크 간에 교환되는 경로입니다. Network Connectivity Center 허브에 연결된 VPC 스포크 간에 피어링 서브넷 경로가 교환되지는 않지만 피어링 서브넷 경로는 고려해야 합니다. 각 VPC 스포크의 관점에서 모든 로컬 서브넷 경로, 가져온 피어링 서브넷 경로, 가져온 Network Connectivity Center 서브넷 경로는 충돌할 수 없습니다.

이 개념을 설명하려면 다음 구성을 고려해 보세요.

  • VPC 네트워크 net-a는 Network Connectivity Center 허브에 연결된 VPC 스포크입니다.
  • VPC 네트워크 net-b는 동일한 Network Connectivity Center 허브에 연결된 VPC 스포크입니다.
  • VPC 네트워크 net-b와 net-c가 VPC 네트워크 피어링을 사용하여 서로 연결되어 있습니다.

100.64.0.0/24의 로컬 서브넷 IP 주소 범위가 net-c에 있다고 가정해 보겠습니다. 이렇게 하면 net-c에 로컬 서브넷 경로 생성되고 net-b에 피어링 서브넷 경로가 생성됩니다. 100.64.0.0/24 IP 주소 범위의 피어링 서브넷 경로는 Network Connectivity Center 허브로 내보내지지 않지만, 이 경로가 net-b에 있으면 net-b는 대상이 100.64.0.0/24와 정확히 일치하거나 100.64.0.0/24 안에 속하거나 100.64.0.0/24를 포함하는 Network Connectivity Center 경로를 가져올 수 없습니다. 따라서 충돌하는 범위를 내보내지 않도록 net-a를 구성하지 않는 한 100.64.0.0/24, 100.64.0.0/25, 100.64.0.0/16에 대한 어떤 로컬 서브넷 경로도 net-a에 존재할 수 없습니다.

서브넷 경로를 보여주는 경로 테이블

Google Cloud에서는 VPC 스포크에서 가져온 Network Connectivity Center 서브넷 경로를 두 경로 테이블에 표시합니다.

Google Cloud는 다음 조건 중 하나가 충족되면 각 VPC 스포크의 VPC 네트워크 경로 테이블과 Network Connectivity Center 허브 경로 테이블을 자동으로 업데이트합니다.

VPC 네트워크 경로 테이블에서 다른 VPC 스포크에서 가져온 각 경로는 다음 홉이 Network Connectivity Center 허브인 Network Connectivity Center 서브넷 경로로 표시됩니다. 이러한 Network Connectivity Center 서브넷 경로의 이름은 ncc-subnet-route- 접두사로 시작합니다. 가져온 Network Connectivity Center 서브넷 경로의 실제 다음 홉을 보려면 Network Connectivity Center 허브 경로 테이블을 열람하거나, 서브넷 경로를 Network Connectivity Center 허브로 내보내는 VPC 스포크의 VPC 네트워크 경로 테이블을 열람할 수 있습니다.

VPC 경로에 대한 자세한 내용은 VPC 문서의 경로를 참고하세요.

다음 단계