GDC 中的每个组织都有自己的隔离虚拟网络。组织内的虚拟网络是一个扁平的 IP 空间，这意味着组织中的所有工作负载都具有直接的 IP 地址连接。借助项目网络政策，您可以控制组织中不同项目内工作负载之间的访问权限。
GDC 在网络级将每个组织与其他所有组织隔离开来。一个组织中的工作负载无法直接通过 IP 地址连接到另一个组织中的工作负载。
组织有两个不同的 IP 范围：内部范围和外部范围。外部 IP 范围可从组织外部访问，而内部 IP 范围只能从组织内部访问。系统始终会从组织的内部范围为工作负载分配 IP 地址，这意味着默认情况下无法从组织外部访问这些工作负载。您必须使用项目联网部分中所述的入站流量和出站流量限制条件，明确为工作负载启用入站流量和出站流量。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-09-05。"],[[["\u003cp\u003eGoogle Distributed Cloud (GDC) air-gapped uses a virtual networking layer to manage connectivity, firewalls, service discovery, load balancing, and observability between virtual machines and pods within a GDC organization.\u003c/p\u003e\n"],["\u003cp\u003eGDC organizations each have their own isolated virtual network with a flat IP space, allowing direct IP address connectivity between workloads within the same organization, but isolating them from other organizations.\u003c/p\u003e\n"],["\u003cp\u003eProjects within a GDC organization offer network segmentation, with default network policies preventing communication between workloads in different projects, unless configured otherwise using Project Network Policies.\u003c/p\u003e\n"],["\u003cp\u003eWorkloads within a GDC organization are assigned internal IP addresses and are not accessible from outside the organization by default; you must explicitly enable inbound and outbound traffic via ingress and egress constraints.\u003c/p\u003e\n"],["\u003cp\u003eNetwork policies in GDC use an additive, allow-based model, enforcing Layer-3 and Layer-4 traffic flows to manage security, and only the client initiating a connection experiences a timeout when a policy denies a flow.\u003c/p\u003e\n"]]],[],null,["# Networking overview\n\nThe virtual networking layer on\nGoogle Distributed Cloud (GDC) air-gapped governs connectivity, firewalls, service\ndiscovery, load balancing, and observability between virtual machines and\npods running in a GDC organization.\n\nGDC networking model\n--------------------\n\nGDC contains two levels of multi-tenancy concepts: organizations and projects. Projects exist within organizations, and you deploy all virtualized and containerized workloads into one particular project within an organization.\n\n### Organization networking\n\nEach organization in GDC has its own isolated virtual network. The virtual network within the organization is a flat IP space, which means all workloads in the organization have direct IP address connectivity to one another. Using [project network policies](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/configure-pnp), you can control access between workloads in different projects in the organization.\n\nGDC isolates each organization at the network level from all other organizations. Workloads in one organization don't have direct IP address connectivity to workloads in another organization.\n\nAn organization has two different IP ranges: an internal range and an external range. The external IP range is reachable from outside the organization, and the internal IP range is only accessible from within the organization. Workloads are always assigned an IP address from the internal range of the organization, which means they are not accessible from outside the organization by default. You must explicitly enable inbound and outbound traffic for workloads using the ingress and egress constraints described in the [Project networking](#project-networking) section.\n\n### Project networking\n\nYou deploy all virtual machines (VM) and containerized workloads into a [project](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/project-management). Projects provide a network segmentation boundary within the organization.\n\nWorkloads within a project can communicate directly with one another. However, the default network policy prevents communication between workloads in different projects. [Project network policies](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/configure-pnp) (`ProjectNetworkPolicy`) let you configure which projects in the organization can communicate with one another. If the project network policy allows, then workloads in the organization can reach each other at the L3 network layer using their respective IP addresses. You must explicitly enable [ingress](#ingress) and [egress](#egress) constraints to and from the organization for each workload that requires inbound or outbound traffic.\n\nConfigure load balancers\n------------------------\n\nLoad balancers distribute traffic across your application's backend workloads, ensuring stability and availability. Create external and internal load balancers for pod and VM workloads. GDC provides three methods for configuring load balancers. For more information, see [Manage load balancers](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/expose-services).\n\n#### Ingress constraints\n\nThe mechanism used to expose workloads outside the organization differs depending on whether the workload is based on VMs or containers.\n\nYou expose VM-based workloads outside of the organization using the VM external access capability. You enable this capability for each VM. Each VM gets its own IP address from the external range of the organization.\n\nOn the other hand, you expose containerized workloads outside the organization using the external load balancer feature. You can create an external load balancer, and GDC assigns an external IP address. Then, traffic can be load-balanced across a set of backend pod workloads.\n\n#### Egress constraints\n\nYou must explicitly enable outbound traffic for each project and workload to communicate outside the organization. Enabling outbound traffic changes the IP from workloads to an external IP using Network Address Translation (NAT) when connecting outside the organization. For more information about allowing outbound traffic, see [Manage outbound traffic from an organization](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/manage-egress).\n\nNetwork policy enforcement model\n--------------------------------\n\nThe security posture for workloads within an organization is the union of default and\nuser-created [project network policies](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/configure-pnp).\n\nPolicy enforcement is based on Layer-3 and Layer-4 traffic flows. A flow describes a 5-tuple connection as follows:\n\n- Source IP address\n- Destination IP address\n- Source port\n- Destination port\n- Protocol, such as `TCP` or `UDP`\n\nNetwork policies perform outbound traffic enforcement on traffic at the\nnode that hosts the source workload and inbound traffic enforcement when the\ntraffic arrives at the node that hosts the destination workload. Therefore, to\nestablish a connection, you must allow the policy to leave the source for the\ndestination and arrive at the destination from the source.\n\nReply traffic, such as the SYN-ACK (synchronize-acknowledge) segment replying to an SYN segment, is not\nsubject to enforcement. Therefore, reply traffic is always allowed if the\ninitiating traffic is allowed. For this reason, you only observe connection timeouts due to\npolicy enforcement from the client initiating the\nconnection. Denied traffic is either discarded during the outbound data transfer from the source\nnode or the inbound data transfer at the destination node. The receiving workload never observes the connection.\n\nEnforcement is based on allow-based policy rules that are additive. The\nresulting enforcement for a workload is an \"any match\" for the traffic flow\nagainst the union of all policies applied to that workload. When multiple\npolicies are present, the rules applied to each workload are additively combined,\nallowing traffic if it matches at least one of the rules. You don't have\ndeny rules, only allow rules.\n\nWhen a network policy denies a flow, you don't receive a response packet and observe a connection timeout.\nFor this reason, any refused or reset protocol-level connections\nor HTTP errors are not a direct result of networking enforcement.\n\nFor more information about Kubernetes network policies, see\n\u003chttps://kubernetes.io/docs/concepts/services-networking/network-policies/#the-two-sorts-of-pod-isolation\u003e."]]
