Propagação da conexão do Private Service Connect pelo Network Connectivity Center
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
O Private Service Connect
permite que os consumidores acessem serviços gerenciados de maneira particular
de dentro da rede de nuvem privada virtual (VPC). Da mesma forma, ele permite que os produtores de serviços gerenciados hospedem esses serviços em redes e projetos VPC separados e ofereçam uma conexão privada aos consumidores.
As conexões do Private Service Connect não são transitivas
das VPCs com peering. A propagação dos serviços do Private Service Connect pelo hub do Network Connectivity Center permite que esses serviços sejam acessados por qualquer outra VPC spoke no mesmo hub.
O recurso de propagação de conexão do Private Service Connect
do Network Connectivity Center beneficia o seguinte caso de uso:
É possível usar uma rede VPC de serviços comuns para criar vários
endpoints do consumidor do Private Service Connect. Ao adicionar uma única
rede VPC de serviços comuns ao hub do Network Connectivity Center, todos
os endpoints do consumidor do Private Service Connect na rede VPC
se tornam transitivamente acessíveis a outros spokes de VPC
pelo hub do Network Connectivity Center do Google. Essa conectividade elimina a necessidade de
gerenciar individualmente cada endpoint do Private Service Connect em
cada rede VPC.
Quando você conecta um spoke VPC a um hub com conexões propagadas ativadas, o Network Connectivity Center cria conexões propagadas nesse spoke para qualquer endpoint anexado ao mesmo hub, a menos que a sub-rede do endpoint seja excluída da exportação. Depois que uma rede VPC é adicionada a um hub do Network Connectivity Center como um spoke VPC, os novos endpoints do Private Service Connect também são propagados, a menos que a sub-rede do endpoint seja excluída da exportação.
Para configurar um hub com uma conexão propagada do Private Service Connect ativada, o administrador do hub precisa criar um hub com propagação do Private Service Connect ou atualizar a configuração de propagação usando o --export-psc. Em seguida, o administrador do hub precisa
adicionar as redes VPC como spokes ao hub. O administrador do hub também pode usar a flag --exclude-export-ranges para excluir sub-redes alocadas específicas do Private Service Connect do roteamento do Network Connectivity Center para que as sub-redes especificadas não possam ser acessadas por outras redes VPC, mantendo a privacidade delas
à rede VPC local.
Considere o seguinte antes de ativar uma conexão propagada do Private Service Connect:
Uma conexão propagada do Private Service Connect só
funciona com spokes de VPC.
A VPC de destino de um spoke híbrido
não pode ser um spoke VPC.
A propagação da conexão do Private Service Connect
pode ser atrasada e a notificação orientada a eventos pode ser assíncrona. Ou seja, a notificação de entrega
pode acontecer algum tempo após a conexão propagada.
Como o filtro --exclude-export-ranges não é mutável para um spoke depois
que ele é criado, recomendamos criar duas sub-redes para hospedar
endpoints do Private Service Connect: uma sub-rede
para dentro da rede VPC apenas do Private Service Connect e a outra para os endpoints do Private Service Connect compartilhados com o hub. Ao adicionar a rede VPC a um hub como um spoke, inclua o intervalo de endereços IP da sub-rede que hospeda a rede VPC apenas dentro da rede VPC ao filtro --exclude-export-ranges para que para que ele não seja compartilhado com o hub.
O número total de endpoints do Private Service Connect em
todos os spokes no hub não pode ser maior que 1.000. Não será estabelecida uma propagação
acima desse limite.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-04 UTC."],[],[],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)."]]
