[[["容易理解","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,["# Test connectivity within VPC networks\n\nA common use case for Connectivity Tests is testing between two\nCompute Engine virtual machine (VM) instances in the same or peered\nVirtual Private Cloud (VPC) networks.\n\nFor this type of test, Connectivity Tests evaluates reachability\nby using both configuration analysis and live data plane analysis. To analyze the\nconfiguration, Connectivity Tests identifies and evaluates a trace\npath.\nTrace diagrams on this page use the symbols described in the following legend.\n\nThe following diagram shows the typical trace path between two VM instances. The\n`Match routes` object can represent routes that direct traffic in a single\nVPC network or between two peered VPC networks.\n\n\n[](/static/network-intelligence-center/docs/connectivity-tests/images/source-vm-2-dest-vm-trace.svg) Source VM to destination VM trace (click to enlarge).\n\n\u003cbr /\u003e\n\nThe following steps describe the checkpoints that correspond to each point in\nthe trace diagram. The check might fail at any check point. The query results\nshow the reason for each failure. For a complete list of test states and\nmessages, see\n[Configuration analysis states](/network-intelligence-center/docs/connectivity-tests/concepts/state-tables#test-states).\n\n1. Connectivity Tests verifies that the source VM can send egress\n packets with the specified source IP address, or can otherwise default to the\n spoof check process.\n\n2. Connectivity Tests performs a spoof check when a simulated packet to or from\n a VM instance uses an IP address not owned by that instance. IP addresses owned\n by a VM include all VM internal IP addresses and secondary IP addresses.\n\n If the address is an address that appears to originate from external traffic, also called a\n foreign address, then the IP address fails the spoof check.\n3. To determine whether trace packets can be sent from\n the source, Connectivity Tests verifies the appropriate\n egress firewall rules. As part of this process, Connectivity Tests\n begins by evaluating any hierarchical firewall policy rules that exist.\n For details about how hierarchical firewall policy rules and VPC\n firewall rules affect connectivity, see\n [Hierarchical firewall policy examples](/firewall/docs/firewall-policies-examples).\n\n4. Connectivity Tests finds (matches) a route for the destination\n IP address, according to the [routing order](/vpc/docs/routes#routeselection).\n If no other routes are available to the destination VM instance,\n Connectivity Tests uses the default static route with the next\n hop as the internet gateway. All VPC networks use this\n default route unless you have removed it.\n\n5. Connectivity Tests verifies that the network's ingress firewall\n rules allow the packet to arrive at the destination VM. Again,\n Connectivity Tests begins by evaluating any hierarchical firewall\n policy rules that exist.\n\n6. If needed, Connectivity Tests runs\n a spoof check on the packet that arrives at the second VM.\n\n7. Connectivity Tests verifies that the destination VM can receive\n a packet with the specified destination IP address. If this address is a\n foreign IP address, the destination VM must have IP forwarding\n enabled. A foreign IP address is an address that does not belong to the VM.\n\nThe following screenshot from the Google Cloud console shows the results of a\nVM-to-VM test.\n\nThe configuration analysis shows a result of **Packet could be delivered** .\nIn the API response, this label corresponds to a\n[final state of `Deliver`](/network-intelligence-center/docs/connectivity-tests/concepts/state-tables#deliver-state).\n\nThis result shows that the configuration analysis has validated network\nconnectivity for every Google Cloud resource in the path from the source\nVM to the destination VM. In this case, the route included two\nVPC firewall rules: an implied VPC firewall\nrule (named `default`) and one that was created for this VPC\nnetwork.\n\nAlso, Connectivity Tests dynamically verified that the destination VM\nis reachable by using active probing. The **Last packet transmission result**\nfield shows the details of this result.\n\n\n[](/static/network-intelligence-center/docs/connectivity-tests/images/vm-2-vm-ui-cards.png) Google Cloud console screenshot for VM-to-VM trace (click to enlarge)\n\n\u003cbr /\u003e\n\nYou can expand each of the cards in the trace path to view more detail.\n\nThe following example shows an expanded card for an ingress firewall rule.\nThis card includes information about the VPC network, the\nconfigured action for the firewall rule (allow), and the rule priority.\n\n\n[](/static/network-intelligence-center/docs/connectivity-tests/images/vm-2-vm-firewall-card.png) Ingress firewall rule card expanded (click to enlarge)\n\n\u003cbr /\u003e\n\nWhen a trace contains a VPC network route with the next hop\nas a peered VPC network, the start of the trace is not a VM\ninstance, but a VPC network. This type of trace validates\nfirewall rules and routes at the network level because the IP address\nthat you test comes from a network range instead of a VM instance.\n\nPeered networks can exist in the same or in different projects. The following\ntrace example shows peered networks in different projects.\n\n\n[](/static/network-intelligence-center/docs/connectivity-tests/images/trace-path-vpc-peering-different-accessible-project.svg) VM-to-VM trace through an accessible peered VPC network in a different project (click to enlarge)\n\n\u003cbr /\u003e\n\nTest failures for VPC networks\n------------------------------\n\nThe following table lists common failures for tests within VPC\nnetworks.\n\n| **Note:** The Google Cloud console result **Packet could be dropped** is represented in the API response as a [final state of `Drop`](/network-intelligence-center/docs/connectivity-tests/concepts/state-tables#drop-state).\n\nThe following screenshot illustrates a trace that failed because connectivity\nwas blocked by an ingress hierarchical firewall policy rule.\n\n\n[](/static/network-intelligence-center/docs/connectivity-tests/images/vm-2-vm-with-policy.png) Google Cloud console screenshot for a trace that's blocked by a hierarchical firewall policy rule (click to enlarge)\n\n\u003cbr /\u003e\n\nTest failures for Shared VPC networks\n-------------------------------------\n\nIn Shared VPC networks, not having permissions to the host\nproject or the service project can cause the test failures listed in the\nfollowing table.\n\nTest failures for VPC Network Peering networks\n----------------------------------------------\n\nWith VPC Network Peering, not having permission to the `peered`\nnetwork's Google Cloud project from the `primary` network can cause\nthe test result listed in the following table.\n\nThe following trace path shows forward state for peered VPC networks.\n\n\n[](/static/network-intelligence-center/docs/connectivity-tests/images/trace-path-vpc-peering-different-inaccessible-project.svg) VM-to-VM trace through an inaccessible peered VPC network in a different project (click to enlarge)\n\n\u003cbr /\u003e\n\nWhat's next\n-----------\n\n- [Common test scenarios](/network-intelligence-center/docs/connectivity-tests/concepts/common-use-cases)\n- [Learn about Connectivity Tests](/network-intelligence-center/docs/connectivity-tests/concepts/overview)\n- [Troubleshoot Connectivity Tests](/network-intelligence-center/docs/connectivity-tests/support/troubleshooting)"]]