GDC 中的每個機構都有各自獨立的虛擬網路。機構內的虛擬網路是固定 IP 空間，也就是說，機構內的所有工作負載都會直接連線至彼此的 IP 位址。使用專案網路政策，您可以控管機構中不同專案之間的工作負載存取權。
GDC 會在網路層級將每個機構與其他機構隔離。一個機構中的工作負載無法直接透過 IP 位址連線至另一個機構中的工作負載。
某機構有兩個不同的 IP 範圍：內部範圍和外部範圍。外部 IP 範圍可從機構外部連線，內部 IP 範圍則只能從機構內部連線。系統一律會從機構的內部範圍為工作負載指派 IP 位址，因此預設無法從機構外部存取工作負載。您必須使用「專案網路」一節所述的 Ingress 和 Egress 限制，明確啟用工作負載的輸入和輸出流量。
[[["容易理解","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-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."]]
