Ubuntu 20.04/22.04本地网络连通但无法访问互联网的问题排查求助

我最近碰到个棘手的网络问题：一开始是Ubuntu 20.04出现状况，为了修复我升级到了22.04，但同一台机器的两个系统版本都有同样的问题，具体情况如下：

机器能正常连接本地局域网，访问路由器和其他设备都没问题，其他设备也能通过SSH远程访问这台机器。但不管用有线还是无线连接，都没法访问互联网——同一网络里的其他设备上网都完全正常。

我试过的测试手段：

• 加载网页失败
• ping公共DNS（1.1.1.1、8.8.8.8）也完全没响应
• 试过开启/关闭IPv4/IPv6的各种组合
• 重启过路由器
• 甚至等了很久，偶尔会突然连上几分钟，然后又断了
• 用U盘启动的「Try Ubuntu」模式完全正常，能SSH、上网、ping DNS，这说明应该是本机的配置出了问题

相关配置文件 #

/etc/netplan/01-netcfg.yaml（这是netplan目录里唯一的文件，最后一次执行sudo netplan apply用的就是它） #

network:
  version: 2
  renderer: NetworkManager

/etc/NetworkManager/NetworkManager.conf #

[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false

[device]
wifi.scan-rand-mac-address=no

/etc/resolv.conf（软链接指向/run/systemd/resolve/stub-resolv.conf），去掉注释后： #

nameserver 127.0.0.53
options edns0 trust-ad
search Home

/run/systemd/resolve/resolv.conf，去掉注释后： #

nameserver 192.168.0.1
nameserver 205.171.3.65
nameserver 192.168.0.1
# Too many DNS servers configured, the following entries may be ignored.
nameserver 205.171.3.65
search Home

/etc/NetworkManager/conf.d/10-globally-managed-devices.conf #

[keyfile]
unmanaged-devices=*,except:type:ethernet,except:type:wifi,except:type:wwan

命令输出 #

ip a输出： #

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp37s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 70:85:c2:a1:9e:2b brd ff:ff:ff:ff:ff:ff
3: wlp36s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 30:24:32:bd:75:0e brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.102/23 brd 192.168.1.255 scope global dynamic noprefixroute wlp36s0
       valid_lft 81712sec preferred_lft 81712sec

nmcli c show输出（wifi名称是:^)，之前一直没出过问题）： #

NAME                UUID                                  TYPE      DEVICE
:^)                 a48206d0-c23c-4634-b867-d743cec84e67  wifi      wlp36s0
Wired connection 1  1ee423fe-8374-3689-b786-f46ea5ef193f  ethernet  enp37s0

如果需要其他配置文件或命令输出，我随时可以补充，目前只想到这些。另外，如果有能从其他电脑传过去修复配置的工具，我也愿意试试。

EDIT 1：补充ip route和ip neigh输出 #

按@netbat的建议，补充以下命令输出：

ip route： #

default via 192.168.0.1 dev enp37s0 proto dhcp metric 100
default via 192.168.0.1 dev enp37s0 proto dhcp src 192.168.0.61 metric 100
default via 192.168.0.1 dev wlp36s0 proto dhcp metric 600
169.254.0.0/16 dev wlp36s0 scope link metric 1000
192.168.0.0/23 dev enp37s0 proto kernel scope link src 192.168.0.61
192.168.0.0/23 dev enp37s0 proto kernel scope link src 192.168.0.61 metric 100
192.168.0.0/23 dev wlp36s0 proto kernel scope link src 192.168.0.102 metric 600
192.168.0.1 dev enp37s0 proto dhcp scope link src 192.168.0.61 metric 100
205.171.3.65 via 192.168.0.1 dev enp37s0 proto dhcp src 192.168.0.61 metric 100

ip neigh： #

192.168.0.5 dev enp37s0 lladdr f0:18:98:85:f8:7f STALE
192.168.0.50 dev wlp36s0 lladdr f0:2f:4b:08:df:11 STALE
192.168.0.1 dev wlp36s0 lladdr 84:e8:92:8d:7f:10 REACHABLE
192.168.0.202 dev enp37s0 lladdr 34:7e:5c:f7:6c:f6 STALE
192.168.0.47 dev wlp36s0 lladdr e0:d4:64:e1:0a:0a STALE
192.168.0.50 dev enp37s0 lladdr f0:2f:4b:08:df:11 DELAY
192.168.0.200 dev wlp36s0 lladdr 58:ef:68:e9:02:a5 STALE
192.168.0.1 dev enp37s0 lladdr 84:e8:92:8d:7f:10 REACHABLE
192.168.0.38 dev wlp36s0 lladdr b8:e8:56:42:b1:80 STALE
192.168.0.55 dev wlp36s0 lladdr f4:d4:88:6a:99:f2 STALE
192.168.0.5 dev wlp36s0 lladdr f0:18:98:85:f8:7f STALE
192.168.0.202 dev wlp36s0 lladdr 34:7e:5c:f7:6c:f6 STALE
192.168.0.38 dev enp37s0 lladdr b8:e8:56:42:b1:80 REACHABLE
192.168.0.55 dev enp37s0 lladdr f4:d4:88:6a:99:f2 STALE
192.168.0.200 dev enp37s0 lladdr 58:ef:68:e9:02:a5 STALE
fe80::18a5:1285:aa20:5c0c dev enp37s0 lladdr 1c:b3:c9:35:ad:97 router STALE
fe80::86e8:92ff:fe8d:7f10 dev enp37s0 lladdr 84:e8:92:8d:7f:10 router REACHABLE

EDIT 2：补充NetworkManager连接配置，以及工作/非工作状态对比 #

感谢@netbat帮忙分析！下面是/etc/NetworkManager/system-connections/里的文件：

:^).nmconnection（密码已隐去）： #

[connection]
id=:^)
uuid=a48206d0-c23c-4634-b867-d743cec84e67
type=wifi
interface-name=wlp36s0
timestamp=1673334649

[wifi]
mode=infrastructure
ssid=:^)

[wifi-security]
key-mgmt=wpa-psk
psk=******

[ipv4]
method=auto

[ipv6]
addr-gen-mode=stable-privacy
method=auto

[proxy]

Wired connection 1.nmconnection： #

[connection]
id=Wired connection 1
uuid=1ee423fe-8374-3689-b786-f46ea5ef193f
type=ethernet
autoconnect-priority=-999
interface-name=enp37s0
timestamp=1673410242

[ethernet]

[ipv4]
method=auto

[ipv6]
addr-gen-mode=stable-privacy
method=auto

[proxy]

我现在先禁用了wifi，专注排查有线连接。另外补充个细节：即使网络突然恢复（浏览器能打开网页），我还是没法ping或者tracepath外网IP。路由器的DHCP列表里，有线网卡的MAC地址对应的IP和本机显示的一致。

禁用wifi后，ip route里只剩有线的默认路由了。对比网络工作和不工作时的命令输出，主要差异在：

ip addr里的有线网卡条目：

• 工作状态：

  inet 192.168.0.61/23 brd 192.168.1.255 scope global dynamic enp37s0
  

• 非工作状态：

  inet 192.168.0.61/23 metric 100 brd 192.168.1.255 scope global dynamic enp37s0
  

ip route：

• 工作状态：

  default via 192.168.0.1 dev enp37s0 proto dhcp metric 100
  192.168.0.0/23 dev enp37s0 proto kernel scope link src 192.168.0.61
  192.168.0.0/23 dev enp37s0 proto kernel scope link src 192.168.0.61 metric 100
  192.168.0.1 dev enp37s0 proto dhcp scope link src 192.168.0.61 metric 100
  205.171.3.65 via 192.168.0.1 dev enp37s0 proto dhcp src 192.168.0.61 metric 100
  

• 非工作状态：

  default via 192.168.0.1 dev enp37s0 proto dhcp src 192.168.0.61 metric 100
  192.168.0.0/23 dev enp37s0 proto kernel scope link src 192.168.0.61 metric 100
  192.168.0.1 dev enp37s0 proto dhcp scope link src 192.168.0.61 metric 100
  205.171.3.65 via 192.168.0.1 dev enp37s0 proto dhcp src 192.168.0.61 metric 100
  

关于子网掩码是/23而不是常见的/24，这是我在路由器上特意配置的，用来区分普通设备和智能设备（192.168.0.X是普通设备，192.168.1.X是需要关注的设备），网络里所有设备都能正常识别这个配置，应该不是问题根源。

EDIT 3：尝试建议修改后的情况 #

按照大家的建议修改后，网络状况还是没改善，依然时好时坏。我多次重启和重新连接后发现，ip neigh里有一行状态会随着网络连通性变化：

• 网络正常时：fe80::86e8:92ff:fe8d:7f10 dev enp37s0 lladdr 84:e8:92:8d:7f:10 router REACHABLE
• 网络断开时：这行会变成STALE

其他条目除了时间戳外都没变化，而且不管我手动执行ip route和ip addr的修改命令，这个现象依然存在。

备注：内容来源于stack exchange，提问作者Lucas Burns