透過 Network Connectivity Center 傳播 Private Service Connect 連線
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
Private Service Connect 可讓消費者從虛擬私有雲 (VPC) 網路內部，以私密方式存取代管服務。同樣地，代管服務生產端也能在自己的獨立虛擬私有雲網路和專案中代管這些服務，並為消費者提供私人連線。Private Service Connect 連線不會在虛擬私有雲輪輻之間傳輸。透過 Network Connectivity Center 中樞傳播 Private Service Connect 服務後，同一個中樞內的其他輪輻虛擬私有雲即可透過路由表連上這些服務。
Network Connectivity Center Private Service Connect 連線傳播功能適用於下列用途：
您可以使用通用服務虛擬私有雲網路，建立多個 Private Service Connect 消費者端點。只要將單一通用服務虛擬私有雲網路新增至 Network Connectivity Center 中樞，虛擬私有雲網路中的所有 Private Service Connect 消費者端點，就能透過 Network Connectivity Center 中樞，以遞移方式供其他虛擬私有雲輪輻存取。有了這項連線功能，您就不必在每個虛擬私有雲網路中，個別管理每個 Private Service Connect 端點。
您可以從混合式輪輻可連上的內部部署網路，存取虛擬私有雲輪輻網路中的代管服務。
將虛擬私有雲輪輻連線至已啟用連線傳播功能的中樞時，Network Connectivity Center 會在該輪輻中，為附加至相同中樞的所有端點建立傳播連線，除非端點的子網路已排除在匯出範圍外。將虛擬私有雲網路新增至 Network Connectivity Center 中樞做為虛擬私有雲輪輻後，系統也會傳播新的 Private Service Connect 端點，除非端點的子網路已從匯出作業中排除。
如要設定啟用 Private Service Connect 傳播連線的中樞，中樞管理員必須建立中樞，並啟用 Private Service Connect 傳播功能，或使用 --export-psc 旗標更新傳播設定。接著，中樞管理員必須將虛擬私有雲網路新增為中樞的輪輻。輪輻擁有者可以使用 --exclude-export-ranges 和 --include-export-ranges 標記，從 Network Connectivity Center 路由中排除特定 Private Service Connect 分配的子網路，這樣其他虛擬私有雲網路就無法連線至指定的子網路，確保子網路僅供本機虛擬私有雲網路使用。
如要讓連線至混合式 Spoke 的內部部署網路使用傳播的 Private Service Connect 連線，請按照下列步驟操作：
Network Connectivity Center 中樞必須只有一個路由虛擬私有雲網路，其中包含所有混合式輪輻。
中樞的單一轉送虛擬私有雲網路也必須是虛擬私有雲輪輻。
如果中樞有多個路由虛擬私有雲網路，則這些網路都不能同時是虛擬私有雲輪輻。因此，如果中樞有兩個以上的路由虛擬私有雲網路，就無法將傳播的 Private Service Connect 連線提供給地端部署網路。
如要讓 Private Service Connect 傳播功能與混合式輪輻搭配運作，也必須將轉送虛擬私有雲網路新增為虛擬私有雲輪輻。
由於輪輻建立後，--exclude-export-ranges 篩選器就無法變更，因此建議您建立兩個子網路來代管 Private Service Connect 端點：一個子網路用於僅限虛擬私有雲網路的 Private Service Connect 端點，另一個則用於與中樞共用的 Private Service Connect 端點。將虛擬私有雲網路新增至中樞做為輪輻時，請將僅限虛擬私有雲網路的虛擬私有雲網路中，用於代管的子網路 IP 位址範圍新增至 --exclude-export-ranges 篩選器，確保該範圍不會與中樞共用。
使用私下使用的公用 IP 位址範圍的 Private Service Connect 端點，不會傳播至 Network Connectivity Center 中樞。
如果虛擬私有雲輪輻中的子網路已設定 Private NAT 來存取 Network Connectivity Center 中樞，系統會捨棄從子網路傳送至傳播 Private Service Connect 服務的流量。如果 Private NAT 閘道設定為 --nat-all-subnet-ip-ranges，則透過 Network Connectivity Center 傳播 Private Service Connect 的功能，不適用於這個輪輻 VPC 中的所有子網路。如要從這個虛擬私有雲端子網路的非重疊子網路運作，請使用 --nat-custom-subnet-ip-ranges 做為 Private NAT 閘道。請勿使用 NAT 將流量從不重疊的子網路，轉送至 Network Connectivity Center 中樞。
如果在短時間內建立、刪除及重新建立 Private Service Connect 端點，傳播狀態可能不準確。不過一段時間後，傳播狀態就會準確反映傳播連結的實際狀態。這項作業最多可能需要 15 分鐘才能完成。
建立或刪除 Spoke 後，Private Service Connect 連線傳播作業會以非同步方式進行。從中樞移除虛擬私有雲輪輻後，系統可能需要一段時間，才能更新傳播的 Private Service Connect 連線。Private Service Connect 傳播連線更新作業進行期間，即使虛擬私有雲輪輻已新增至新的中樞，虛擬私有雲網路中的 VM 流量仍可流向後端。為避免流量流向後端，請先刪除先前中樞網路中 VPC 網路的所有傳播狀態項目 (無論是來源輪輻或目標輪輻)，再將輪輻新增至其他中樞網路。
Private Service Connect 連線傳播狀態
您可以在 Network Connectivity Center 中樞內，透過 Network Connectivity Center 查看 Private Service Connect 連線傳播的狀態。您可以查看狀態摘要，或深入瞭解特定錯誤，查看錯誤詳細資料。
下表列出傳播狀態碼及其代表的意義。
程式碼
訊息
準備
傳播的 Private Service Connect 連線已就緒。
傳播
Private Service Connect 連線傳播作業尚未完成。這是暫時狀態。
錯誤：超過供應端傳播連線限制
無法傳播 Private Service Connect 連線，因為目標輪輻的專案或虛擬私有雲網路已超過供應商設定的傳播連線限制。如要解決這個問題，請參閱製作工具的說明文件，或與支援團隊聯絡。
錯誤：供應端網路位址轉譯 (NAT) IP 空間已用盡
無法傳播 Private Service Connect 連線，因為網路位址轉譯 (NAT) IP 子網路空間已用盡。這相當於 PSC 連線的
Needs attention狀態。詳情請參閱 Private Service Connect 說明文件中的「連線狀態」。
錯誤：超過供應端配額
無法傳播 Private Service Connect 連線，因為已超過供應商虛擬私有雲網路的 PSC_ILB_CONSUMER_FORWARDING_RULES_PER_PRODUCER_NETWORK 配額。
錯誤：超過用戶端配額
無法傳播 Private Service Connect 連線，因為已超過用戶虛擬私有雲網路的 PSC_PROPAGATED_CONNECTIONS_PER_VPC_NETWORK 配額。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-09-04 (世界標準時間)。"],[],[],null,["# Private Service Connect connection propagation through Network Connectivity Center\n\n[Private Service Connect](/vpc/docs/private-service-connect)\nlets *consumers* access *managed services* privately from\ninside their Virtual Private Cloud (VPC) network. Similarly, it lets managed service\n*producers* host these services in their own separate VPC\nnetworks and projects and offer a private connection to their consumers.\nPrivate Service Connect connections aren't transitive between\nVPC spokes. The\npropagation of Private Service Connect services through the\nNetwork Connectivity Center hub enables these services to be reachable by any other\nspoke VPC in the same hub through the route table.\n\nNetwork Connectivity Center also supports regional endpoint propagation. For more\ninformation about regional endpoints, see\n[About accessing regional endpoints through Private Service Connect endpoints](/vpc/docs/about-accessing-regional-google-apis-endpoints).\n\nThe Network Connectivity Center Private Service Connect connection\npropagation feature benefits the following use cases:\n\n- You can use a common services VPC network to create multiple\n Private Service Connect consumer endpoints. By adding a single\n common services VPC network to the Network Connectivity Center hub, all\n Private Service Connect consumer endpoints in the VPC\n network become transitively accessible to other VPC spokes\n through the Network Connectivity Center hub. This connectivity eliminates the need to\n individually manage each Private Service Connect endpoint in\n each VPC network.\n\n- You can access managed services in a VPC spoke network from\n on-premises networks that are reachable by hybrid spokes.\n\nWhen you connect a VPC spoke to a hub that has propagated\nconnections enabled, Network Connectivity Center creates propagated\nconnections in that spoke for any endpoints that are\nattached to the same hub, unless the endpoint's subnet is excluded from being\nexported. After a VPC network is added to a Network Connectivity Center\nhub as a VPC spoke, new Private Service Connect\nendpoints are also propagated, unless the endpoint's subnet is excluded from\nexport.\n\nTo set up a hub with a Private Service Connect propagated connection\nenabled, the hub administrator must [create a hub](/network-connectivity/docs/network-connectivity-center/how-to/vpc-configure-hub)\nwith Private Service Connect propagation or update the\npropagation setting by using the\n`--export-psc` flag. Then the hub administrator must\nadd the VPC networks as spokes to the hub. The spoke owner\ncan use the `--exclude-export-ranges` and `--include-export-ranges` flags to exclude specific\nPrivate Service Connect allocated subnets from the\nNetwork Connectivity Center routing so that specified subnets can't be reached from other\nVPC networks, thus keeping them private to the local\nVPC network.\n| **Note:** Connections are propagated asynchronously and could take up to 24 hours to propagate.\n\nFor information about Private Service Connect propagated\nconnections, see [About propagated connections](/vpc/docs/about-propagated-connections).\n\nFor information about the `--exclude-export-ranges` and\n`--include-export-ranges` flags, see [VPC connectivity with export filters](/network-connectivity/docs/network-connectivity-center/concepts/vpc-spokes-overview#vpc-connectivity-with-export-filters).\n\nFor detailed information about setting up a hub for a Private Service Connect\npropagated connection, see [Configure a hub](/network-connectivity/docs/network-connectivity-center/how-to/vpc-configure-hub).\n\nConnection propagation limit\n----------------------------\n\nFor details about propagated connection limits, see\n[Propagated connection limit](/vpc/docs/about-vpc-hosted-services#propagated-connection-limit).\n\nConsiderations\n--------------\n\nConsider the following before you enable a Private Service Connect\npropagated connection:\n\n- A Private Service Connect propagated connection works only with\n VPC spokes.\n\n- Private Service Connect IPv6 propagated connections across\n VPC spokes aren't supported.\n\n- If you need to make propagated Private Service Connect\n connections available to on-premises networks connected to hybrid spokes:\n\n - Your Network Connectivity Center hub must have only one [routing\n VPC\n network](/network-connectivity/docs/network-connectivity-center/concepts/dynamic-route-exchange-with-vpc-spokes#routing-vpc) that contains all of\n its hybrid spokes.\n\n - The hub's single routing VPC network must also be a\n VPC spoke.\n\n If a hub has two or more routing VPC networks, none of the\n routing VPC networks can also be VPC spokes.\n Consequently, hubs with two or more routing VPC networks can't\n make propagated Private Service Connect connections available\n to on-premises networks.\n- For Private Service Connect propagation to work with hybrid\n spokes, the routing VPC network must also be added as a\n VPC spoke.\n\n- Because the `--exclude-export-ranges` filter is not mutable for a spoke after\n the spoke is created, we recommend that you create two subnets to host\n Private Service Connect endpoints---one subnet for\n within-VPC-network-only Private Service Connect\n endpoints and the other for the Private Service Connect\n endpoints shared to the hub. When you add the VPC network to a\n hub as a spoke, add the IP address range of the subnet that hosts the\n within-VPC-network-only VPC network to the\n `--exclude-export-ranges` filter so that it is not shared with the hub.\n\n- Private Service Connect endpoints using privately used public\n IP address ranges aren't propagated to the Network Connectivity Center hub.\n\n- If a subnet in a VPC spoke is configured with Private NAT\n to access the Network Connectivity Center hub, the traffic from the subnet to the\n propagated Private Service Connect service is dropped.\n If the Private NAT gateway is configured with `--nat-all-subnet-ip-ranges`,\n then Private Service Connect propagation through\n Network Connectivity Center doesn't work for all subnets in this spoke\n VPC. To get it to work from non-overlapping subnets of this\n VPC spoke, use `--nat-custom-subnet-ip-ranges` for the\n Private NAT gateway. Don't use NAT to route traffic from\n non-overlapping subnets to the Network Connectivity Center hub.\n\n- The propagation status might be inaccurate if you\n create, delete, and re-create the Private Service Connect\n endpoint within a short timeframe. However, after some time,\n the propagation status becomes accurate and reflects the actual state of the\n propagated connection. This could take up to 15 minutes.\n\n- Private Service Connect connection propagation is asynchronous\n after spoke creation or deletion. When a VPC spoke is removed\n from a hub, it can take some time to update propagated\n Private Service Connect connections. While the\n Private Service Connect propagation connection update is\n in progress, traffic from the VM within the VPC network can flow to\n the backend, even after the VPC spoke is added to a new hub.\n To avoid traffic flow to the backend, before adding the spoke to another hub,\n make sure that all of the propagation status entries for the\n VPC network in the\n previous hub, whether as a source spoke or a target spoke, are deleted.\n\nPrivate Service Connect connection propagation status\n-----------------------------------------------------\n\nNetwork Connectivity Center lets you view the status of the\nPrivate Service Connect connection propagation within a\nNetwork Connectivity Center hub.\nYou can view a summary of statuses or drill down on specific\nerrors to view error details.\n\nThe following table lists the propagation status codes and what they mean.\n\nFor information about how to view Private Service Connect\nconnection propagation statuses, see\n[View the Private Service Connect connection propagation status](/network-connectivity/docs/network-connectivity-center/how-to/working-with-hubs-spokes#view-psc-propagation-status). For\nPrivate Service Connect connection propagation troubleshooting\ninformation, see [Troubleshoot Private Service Connect connection propagation errors](/network-connectivity/docs/network-connectivity-center/support/troubleshooting#troubleshoot-psc-propagation-errors).\n\nWhat's next\n-----------\n\n- To create hubs and spokes, see [Work with hubs and spokes](/network-connectivity/docs/network-connectivity-center/how-to/working-with-hubs-spokes).\n- To view a list of partners whose solutions are integrated with Network Connectivity Center, see [Network Connectivity Center partners](/network-connectivity/docs/network-connectivity-center/partners).\n- To find solutions for common issues, see [Troubleshooting](/network-connectivity/docs/network-connectivity-center/support/troubleshooting).\n- To get details about API and Google Cloud CLI commands, see [APIs and reference](/network-connectivity/docs/network-connectivity-center/apis)."]]
