谷歌云分销商 谷歌云VM网络故障排查

网络故障排查第一步：确认基础配置

检查实例网络接口设置

别以为实例启动了就万事大吉，有时候网络接口可能没分配到IP，或者IP被错误配置。这时候得用gcloud命令看看networkInterfaces里的配置，如果显示'NO_IP'，那可就尴尬了，得赶紧重配或者申请新IP。

gcloud compute instances describe my-instance --zone=us-central1-a --format="json"

或者更简单，直接用gcloud compute instances list看看实例的外网IP是否显示，如果为空，说明没配置外部IP或者配置错误。我见过有人把实例的网络接口设成“没有外部IP”，结果还抱怨为什么上不了网，这就像给手机开了飞行模式还打电话——难怪接不通！

VPC网络配置检查

VPC网络就像小区的主干道，如果主干道修错了，整个小区的交通都会乱。检查VPC的子网CIDR范围是否合理，是否有重叠。比如，子网掩码是/24，但实际IP分配超过254个，那肯定不行。另外，子网所在的区域是否和实例所在的区域一致，有时候选错区域导致网络不通。

还有，VPC的网络配置是否和实例的网络配置匹配。比如，实例的子网设置是否正确，是否属于某个VPC。有时候创建实例时选错了VPC，导致和其他实例完全隔离，这就像把你家的门钥匙给了隔壁小区的邻居——门都找不到！

防火墙规则与安全组排查

入站/出站规则验证

防火墙规则就像小区保安，但有时候保安会“懒癌发作”——该放行的不放行，不该拦的拦住了。检查防火墙规则时，别只盯着“允许”，还要看“来源”和“目标”是否匹配。比如：

gcloud compute firewall-rules describe my-rule --format="json"

假设你的VM需要对外提供HTTP服务，但发现外网无法访问。先用gcloud compute firewall-rules list查看项目级防火墙规则，找到允许TCP 80端口的规则。这时候要检查sourceRanges是否包含你访问的IP段，比如0.0.0.0/0。如果sourceRanges只写了192.168.1.0/24，那外面的人当然进不来，这时候需要修改规则或者添加新规则。

另一个常见坑是“出站规则”。很多人以为入站规则开了就行，但出站规则默认允许所有，不过如果你设置了自定义出站规则，可能不小心把出站流量拦了。比如用gcloud compute firewall-rules describe rules-name查看出站规则是否放行了所有流量，或者至少放行了你需要的端口和目标。曾经有个客户，配置了出站规则只允许443端口，结果他想用80端口更新代码，发现死活连不上，结果排查了两小时才发现是出站规则的问题，笑死。

安全组策略冲突检查

安全组策略有时候会“打架”。比如，你给实例打了一个标签，然后创建了基于标签的防火墙规则，但可能其他规则也应用了这个标签，导致规则冲突。检查所有应用到该实例的防火墙规则，看是否有相互冲突的规则。例如，一个规则允许所有IP访问80端口，但另一个规则又拒绝所有访问，这时候拒绝规则优先级更高，导致访问被阻断。

记得用gcloud compute firewall-rules list --filter="labels.your-label"查看相关规则。有时候，规则的优先级设置错误，比如优先级高的规则是拒绝，而优先级低的是允许，结果优先级高的先生效，导致问题。记住，防火墙规则的优先级数字越小，优先级越高，这点一定要注意，不然会被自己的规则“坑死”。

路由与网关问题

默认路由配置

默认路由就像导航里的“最短路径”，如果配置错了，数据包可能绕道去火星。检查VPC的路由表，确保有默认路由（0.0.0.0/0）指向正确的网关。默认网关通常是“default-internet-gateway”，如果缺失了这条路由，实例就无法访问外网。

gcloud compute routes list --filter="destRange=0.0.0.0/0"

曾经有个项目，配置了自定义路由，但不小心把默认路由覆盖了，结果所有外网访问都断了。当时我一看路由表，发现0.0.0.0/0的下一跳是某个虚拟路由器，但那个路由器根本没配置，数据包直接被丢弃。这种错误就像把快递地址写成“宇宙中心”，结果包裹永远到不了——因为没有快递员送过去！

自定义路由表分析

自定义路由表有时会带来意想不到的问题。比如，你设置了从某个子网到另一个子网的特定路由，但可能因为子网配置错误，导致流量走错了路径。检查所有自定义路由的destRange和nextHop，确保它们指向正确的下一跳。

例如，如果你在VPC中设置了多个子网，想让子网A的流量通过某个NAT网关访问外网，但NAT网关的IP配置错误，或者路由指向了错误的网关，就会导致网络不通。这时候需要用gcloud compute routes describe route-name详细查看路由配置，或者用gcloud compute networks vpc-flow-logs describe查看流量日志，确认流量是否按预期路径转发。

DNS与域名解析故障

DNS服务器配置检查

DNS问题往往让人抓狂。比如，ping域名解析失败，但直接ping IP却能通。这时候需要检查实例的DNS配置。在Linux系统中，检查/etc/resolv.conf文件，确认DNS服务器是否正确。谷歌云实例通常会从Metadata中获取DNS服务器，比如169.254.169.254，但有时可能被覆盖。

cat /etc/resolv.conf

如果DNS服务器地址不正确，或者无法解析，可以尝试手动修改DNS服务器为8.8.8.8（Google DNS）或114.114.114.114（国内常用DNS），看是否能解决问题。不过要注意，如果实例是自动获取DNS，可能需要修改Metadata中的DNS配置，或者重启实例。

解析问题定位

用nslookup或dig命令测试域名解析。比如：

nslookup example.com

如果返回“server can't find example.com: NXDOMAIN”，说明DNS服务器没有该记录，或者服务器本身有问题。这时候可以更换DNS服务器测试，或者检查域名注册商的DNS设置是否正确。曾经有个案例，客户把域名DNS服务器改成了错误的地址，导致全球都解析不了，结果还以为是云平台的问题，折腾了好久才找到源头。

常用工具实战排查

gcloud命令行工具使用

除了前面提到的命令，gcloud还有很多实用工具。比如，查看VPC的详细信息：

gcloud compute networks describe my-network

或者查看子网的详细信息：

gcloud compute networks subnets describe my-subnet --region=us-central1

谷歌云分销商 这些命令能帮你快速获取网络配置信息，避免手动翻找控制台的繁琐。记住，命令行工具是运维的“瑞士军刀”，熟练掌握能大幅提升效率。

ping与traceroute实战

最基础的网络测试工具，但往往被忽视。用ping测试到目标IP的连通性：

ping 8.8.8.8

如果ping不通，可能是网络不通或者防火墙禁了ICMP。这时候可以用traceroute查看数据包路径：

traceroute 8.8.8.8

如果traceroute在某个节点突然断了，说明问题出在那个节点。比如，如果在GCE的网关处断开，可能是VPC路由问题；如果在公网节点断开，可能是外部网络问题。曾经有个案例，traceroute显示在某个路由器处超时，但实际是云服务商的设备问题，联系支持后快速解决。

网络抓包分析

对于复杂问题，网络抓包是终极手段。用tcpdump捕获网络流量：

tcpdump -i eth0 -w capture.pcap

谷歌云分销商 然后用Wireshark分析。比如，如果SSH连接不上，可以抓包看是否收到SYN包，是否有RST响应，从而判断是防火墙拦截还是服务端问题。不过抓包需要一定技术，新手可能觉得复杂，但熟练后能快速定位问题根源。记得抓包时注意权限，使用sudo。

总结：排查思路与经验

网络故障排查就像破案，需要有条理、有耐心。先确认基础配置，再检查防火墙、路由、DNS，最后用工具验证。记住以下几点：

• 先确认实例是否正常运行，网络接口配置是否正确
• 防火墙规则是否允许所需流量，注意入站和出站规则
• 路由表是否正确，尤其是默认路由
• DNS配置是否正确，解析是否正常
• 善用gcloud命令、ping、traceroute、tcpdump等工具

遇到问题时，不要慌，一步步排查，往往问题就出在最简单的地方。就像老话说的，“细节决定成败”，网络故障排查也不例外。下次再遇到网络问题，记住这些步骤，你也能成为云上网络问题的终结者！