IPv6路由不可达时用ping怎么查：默认路由、邻居发现和防火墙检查

先界定故障范围：ping失败不一定等于IPv6路由不可达

服务器已经配置了IPv6地址，但访问外部IPv6目标失败，常见表现有三类：ping -6直接提示Network is unreachable，能发包但100%丢包，或者本机提示来自网关的Destination unreachable。这些现象都可能被归为“IPv6路由不可达”，但原因并不相同。

排查时不要只盯着一个公网IPv6地址。更稳妥的顺序是：先确认本机IPv6地址和默认路由，再用ping验证网关，随后验证外部IPv6目标，最后检查邻居发现和防火墙是否拦截ICMPv6。这个顺序适用于Linux服务器、虚拟机和大多数云主机环境；如果是Windows Server，命令不同，但判断逻辑一致。

从ping结果判断问题大致在哪一层

先准备一个已知可达的外部IPv6目标，例如公共DNS的IPv6地址。实际生产中建议同时准备两个目标，避免把对端禁ping误判成本机故障。

ping -6 -c 4 2606:4700:4700::1111
ping -6 -c 4 2001:4860:4860::8888

不同结果对应的排查方向不同：

需要注意：ping使用的是ICMPv6 Echo Request/Reply。外部目标不响应ping，并不能单独证明IPv6路由不可达。因此后续要结合ip -6 route、邻居表和防火墙一起判断。

检查IPv6地址与默认路由

先看网卡上是否存在有效的全局IPv6地址。以下命令以eth0为例，实际环境中请替换为真实网卡名，例如ens3、ens160、enp1s0等。

ip -6 addr show dev eth0

重点看三点：

• 是否有scope global的IPv6地址；
• 前缀长度是否符合分配信息，例如常见的/64；
• 地址状态是否正常，不能是tentative或dadfailed。

示例输出中，类似下面的地址才是可用于公网通信的IPv6地址：

inet6 2001:db8:10:20::10/64 scope global
   valid_lft forever preferred_lft forever

如果看到tentative，说明DAD重复地址检测尚未完成；如果看到dadfailed，说明地址冲突或链路上存在异常响应，需要先处理地址冲突，不能继续按路由故障排查。

接着检查IPv6路由表：

ip -6 route show

正常情况下，至少应看到本地前缀路由和默认路由。默认路由可能是全局地址网关，也可能是链路本地地址网关：

2001:db8:10:20::/64 dev eth0 proto kernel metric 256
default via fe80::1 dev eth0 proto ra metric 1024

或：

2001:db8:10:20::/64 dev eth0 proto kernel metric 256
default via 2001:db8:10:20::1 dev eth0 metric 100

如果没有default开头的IPv6路由，ping外部IPv6目标通常会直接报Network is unreachable。这时可以用route get确认系统会如何选择出口：

ip -6 route get 2606:4700:4700::1111

如果返回：

RTNETLINK answers: Network is unreachable

说明本机没有可用的IPv6默认路由。此时应根据服务器网络分配信息补充默认路由。

临时添加默认路由时要注意：如果网关是fe80::/10链路本地地址，必须指定出口网卡。

sudo ip -6 route add default via fe80::1 dev eth0

如果网关是全局IPv6地址，可按实际网关添加：

sudo ip -6 route add default via 2001:db8:10:20::1 dev eth0

这类命令只对当前运行状态生效，重启网络或服务器后可能丢失。确认无误后，再写入对应系统的持久化网络配置。以Ubuntu Netplan为例，以下仅为格式示例，地址和网关必须替换为实际分配值：

network:
  version: 2
  ethernets:
    eth0:
      addresses:
        - 2001:db8:10:20::10/64
      routes:
        - to: default
          via: fe80::1
          on-link: true

修改持久化配置前建议保留原文件备份，并确认有控制台或带外管理入口，避免网络配置错误导致远程断连。

用ping分段验证网关与外部IPv6目标

默认路由存在后，不要马上只ping公网目标。先ping网关。因为只要网关不可达，外部IPv6目标一定不稳定或不可达。

如果默认网关是链路本地地址，Linux下可以使用带接口作用域的写法：

ping -6 -c 4 fe80::1%eth0

也可以使用-I指定接口：

ping -6 -I eth0 -c 4 fe80::1

如果网关是全局IPv6地址：

ping -6 -c 4 2001:db8:10:20::1

根据结果分支处理：

• 网关ping不通：优先检查邻居发现、网卡/VLAN、网关地址是否写错、本机防火墙是否拦截ICMPv6。
• 网关ping通，外部IPv6不通：本机到网关的二层和邻居发现大概率正常，继续检查默认路由出口、上游路由策略、外部目标是否禁ping。
• 网关和外部IPv6都能ping通，但业务不通：问题可能不在IPv6路由本身，应继续检查DNS AAAA解析、应用监听地址、防火墙端口和服务日志。

为了避免系统自动选择错误源地址，可以指定源IPv6地址发起ping：

ping -6 -I 2001:db8:10:20::10 -c 4 2606:4700:4700::1111

同时查看路由选择结果：

ip -6 route get 2606:4700:4700::1111

正常输出中应包含出口网卡和源地址，例如：

2606:4700:4700::1111 from :: via fe80::1 dev eth0 src 2001:db8:10:20::10 metric 1024

这里的dev eth0和src 2001:db8:10:20::10非常关键。如果源地址不是预期地址，可能是服务器存在多个IPv6地址或多张网卡，导致回程路径不一致。

检查邻居发现：IPv6没有ARP，NDP异常会导致网关不可达

IPv4常用ARP解析网关MAC地址，IPv6使用邻居发现协议NDP。NDP依赖ICMPv6，包括Neighbor Solicitation和Neighbor Advertisement。如果邻居发现被防火墙、交换网络或安全策略阻断，路由表看起来正常，ping仍然会失败。

查看邻居表：

ip -6 neigh show dev eth0

常见状态含义如下：

如果默认网关是fe80::1，邻居表中应能看到类似记录：

fe80::1 dev eth0 lladdr 00:11:22:33:44:55 router REACHABLE

如果一直是INCOMPLETE或FAILED，可重新触发一次邻居发现：

sudo ip -6 neigh flush dev eth0
ping -6 -I eth0 -c 2 fe80::1
ip -6 neigh show dev eth0

如果仍然无法解析，可以抓包确认本机是否发出了NDP请求，以及是否收到网关回应：

sudo tcpdump -ni eth0 'icmp6 and (icmp6[0] == 135 or icmp6[0] == 136)'

其中：

• 135是Neighbor Solicitation；
• 136是Neighbor Advertisement。

如果只看到本机持续发送135，没有收到136，通常说明网关无响应、二层隔离、VLAN不一致、上游安全策略限制，或本机/中间设备拦截了ICMPv6邻居发现报文。

防火墙检查：不要把ICMPv6当作可随意关闭的ping

IPv6环境中，ICMPv6不只是ping。邻居发现、路由通告、路径MTU发现都依赖ICMPv6。简单粗暴地丢弃所有ICMPv6，可能导致默认路由无法学习、网关MAC无法解析，或大包传输异常。

本机先检查当前防火墙规则。不同系统使用的工具不同，以下命令按实际环境选择。

使用nftables的系统：

sudo nft list ruleset | grep -nE 'icmpv6|ip6|drop|reject'

使用iptables/ip6tables的系统：

sudo ip6tables -S

使用firewalld的系统：

sudo firewall-cmd --state
sudo firewall-cmd --list-all

使用UFW的系统：

sudo ufw status verbose

重点确认是否存在以下风险规则：

• 默认策略为drop，但没有放行必要的ICMPv6；
• 显式拒绝ipv6-icmp或icmpv6；
• 只放行TCP/UDP端口，忽略了NDP和PMTU需要的ICMPv6；
• 安全组、ACL或上游防火墙禁止Echo Reply返回，导致外部ping测试失败。

至少应谨慎放行这些ICMPv6类型：destination-unreachable、packet-too-big、time-exceeded、parameter-problem、echo-request、echo-reply、nd-router-solicit、nd-router-advert、nd-neighbor-solicit、nd-neighbor-advert。其中packet-too-big对路径MTU发现很重要，不能因为“不需要ping”就一并阻断。

如果需要临时调整规则，先备份现有配置。以ip6tables为例：

sudo ip6tables-save > /root/ip6tables.$(date +%F-%H%M%S).bak

再在变更窗口内添加测试规则。示例仅用于临时验证，不建议不加审计地长期全量放行：

sudo ip6tables -I INPUT -p ipv6-icmp -j ACCEPT
sudo ip6tables -I OUTPUT -p ipv6-icmp -j ACCEPT

测试完成后，如果确认是规则导致，应改为符合安全策略的精细化放行，而不是长期保留过宽规则。若测试无改善，应回滚临时规则，避免扩大暴露面。

常见结果分支与处理方向

排查到这里，通常可以把问题收敛到几个明确分支。

如果服务器启用了IPv6转发，还要注意RA接收策略。在部分Linux环境中，开启转发后接口可能不再自动接受路由通告。可以查看：

sysctl net.ipv6.conf.all.forwarding
sysctl net.ipv6.conf.eth0.accept_ra

这类参数是否需要调整，取决于服务器角色。如果它只是普通主机，通常不应随意开启转发；如果它是路由器或网关，则应明确使用静态路由或按设计配置RA接收行为。

修复后用同一组命令验证，避免“偶然通一次”

修复完成后，不要只看一次ping成功。建议按固定顺序复测：

ip -6 addr show dev eth0
ip -6 route show
ip -6 route get 2606:4700:4700::1111
ip -6 neigh show dev eth0
ping -6 -c 4 fe80::1%eth0
ping -6 -c 4 2606:4700:4700::1111

如果网关不是链路本地地址，将fe80::1%eth0替换为实际IPv6网关。复测时重点观察：

• 默认路由是否仍然存在；
• route get选择的源地址是否正确；
• 网关邻居状态是否能进入REACHABLE或至少不再FAILED；
• 外部IPv6目标是否稳定响应；
• 防火墙规则重载或系统重启后配置是否仍然生效。

对于业务系统，还应使用业务协议做一次IPv6访问验证。例如Web服务可以检查监听地址和访问结果：

ss -lntp | grep ':80\|:443'
curl -6 -I --connect-timeout 5 https://example.com

临时添加过的路由、防火墙放行规则和调试参数，需要在确认原因后整理为正式配置；如果只是为了验证而添加，记得回滚。尤其是防火墙相关变更，不建议为了让ping通过而长期放开所有ICMPv6入站流量。更合适的做法是保留IPv6正常工作所需的ICMPv6类型，同时结合业务端口、来源地址和安全组策略收紧访问范围。