我在安装 20.04 时遇到了这个问题,为了解决这个问题,我升级到了 22.04。两个系统都表现出了相同的行为,我将在这里详细介绍。
该机器能够正常连接到我的本地网络。我可以毫无问题地访问网络内的其他设备,包括路由器。同样,我可以从网络中的其他机器ssh
毫无问题地访问该机器。当我尝试通过这台机器连接到互联网时,无论我使用的是有线还是无线连接,都无法正常工作。网络上的所有其他设备似乎都可以毫无问题地连接到互联网。
为了测试连接,我尝试加载网页并ping
登录各种名称服务器(1.1.1.1
和8.8.8.8
),但均未成功。我还尝试在有线和无线连接上启用/禁用 IPv4 和 IPv6 的每种组合,重置路由器,无限期等待,甚至使用从闪存驱动器运行的 Ubuntu 版本处于“尝试 ubuntu”模式。最后这两种策略是唯一取得进展的策略。
使用最后一种策略(通过 USB 设备访问 ubuntu)时,一切都运行正常。我可以 ssh 到网络上的其他设备、访问网页、ping 名称服务器等。这让我相信问题出在我的机器的某些配置上。
至于等待策略,一切似乎都会自行解决暂时地每隔几分钟就会出现一次。当我在另一台设备上输入这段文字时,有问题的机器突然加载了我让它指向的网页,几分钟后,它似乎又失去了连接。
作为背景,这里有一些相关的文件和输出:
/etc/netplan/01-netcfg.yaml
(中唯一的文件/etc/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
如果有其他文件或命令输出可以帮助诊断此问题,我很乐意发布它们,只是我不知道除了这些文件之外还要检查什么。或者,如果我可以从另一台计算机向机器发送一些实用程序,可以尝试修复配置,我很乐意尝试一下。
编辑:
根据@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
编辑2:
@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
使用已知地址,例如8.8.8.8
,但我发现当网络突然开始工作时(在浏览器中测试)我仍然无法ping
或tracepath
成功地连接到我家庭网络之外的 IP。
我的路由器上的 DHCP 服务器确实显示了我的以太网端口的 MAC 地址列表,该列表列出的 IP 地址与我的设备声称连接到的 IP 地址相同。
对于两个接口和两个默认问题,禁用 wifi 无线电后,我发现ip route
现在只显示以太网适配器的一个默认路由。
ip
查看网络运行/不运行时各种命令之间的差异,我能看到的主要差异是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,我使用额外的位来一目了然地区分网络上的智能设备。我的设备数量不足以真正保证整个额外位的合理性,但我喜欢 XX0.X 作为普通设备而 XX1.X 是我要关注的设备所带来的便利。我确实在路由器级别进行了配置,因此网络上的所有设备都正确遵守该设置。
编辑 3:尝试了下面建议的更改后,不幸的是,连接性并没有改善。它似乎停留在相同的不一致状态。我注意到,在多次重新启动和重新连接到网络后,其中一行从ip neigh
STALE 变为 REACHABLE,而连接开始工作的时间大致相同,反之亦然。具体来说,这一行:
fe80::86e8:92ff:fe8d:7f10 dev enp37s0 lladdr 84:e8:92:8d:7f:10 router STALE
除时间戳外,其他所有内容似乎都保持不变,无论我是否运行建议ip route
和ip addr
修改,情况都是如此
答案1
这看起来像是路由问题。请在此处附上命令响应列表:
ip route
ip neigh
第一个显示路由表条目,第二个显示本地网络中的邻居。
路由列表中可能缺少以下内容的一行(作者ip route
):
default via 192.168.0.1 dev wlp36s0 proto dhcp metric 100
这只是一个例子。您的机器必须具有路由器地址的信息,通过该地址可以从 LAN 通信到 Internet。这就是所谓的默认网关。
编辑1
您附加的其他列表显示出几个问题。
更深入的分析
请在此处附上您的接口设置。它们位于目录中的文件中/etc/NetworkManager/system-connections/
。可以使用以下命令列出摘要(必须使用空格键确认继续到下一个文件):
sudo more /etc/NetworkManager/system-connections/*
我认为您的网络存在错误,表现形式是两个相同的 IP 地址、MAC 地址、两个 DHCP 服务器或类似的东西发生冲突,表现为通信正常和不正常时的状态交替。
您应该重复执行这三个诊断命令,以在连接正常工作的状态下和不正常工作的状态下获得响应。
ip addr
ip route
ip neigh
通过比较结果并发现差异,我们可以继续寻找缺陷的原因。同时,在 Ubuntu 的另一个终端窗口中,您可以 ping 8.8.8.8 等,看看连接是否正常。
还请检查路由器上的 DHCP 服务器设置。只需检查是否有 Ubuntu 的 MAC 地址记录,以及最终是否有给定 Ubuntu MAC 的静态 IP 地址保留。可以使用 Ubuntu ip addr
PC 上的命令(搜索 link/ether 子句)找到 MAC 地址。
默认网关问题
您拥有的默认网关不止一个,而是三个。这是错误的。只有在特殊情况下才会使用不同的数字。
当同一网络有多条路由时,度量值最小的项优先。它是以太网。其度量值为 100。但看起来您的 enp37s0 以太网接口被 DHCP 服务器错误地设置了,它不应该有两个默认网关(路由)。
当您关闭 Wi-Fi 网络接口时,一个网关就会消失。
查看 DHCP 服务器和 Ubuntu 之间的 DHCP 通信的详细信息会很有趣。您可以使用 tcpdump 命令捕获数据包。详细信息将根据要求提供。
同时使用两个接口
我看到你的 Ubuntu PC 有两个接口同时连接到同一个网络 192.168.0.0/23:
- 以太网
enp37s0
- 无线上网
wlp36s0
这对于诊断问题来说根本不是一个好的情况。请只使用一个接口进行测试,直到问题解决为止。
问题:非典型网络掩码
为什么使用长度为 23 位的网络掩码,即 255.255.254.0,而不是通常的 24 位?这是有意还是无意的?我不认为您家里有 300 台计算机来使用大型网络。这完全取决于您,但必须在所有设备上设置相同的掩码。然后一切都会正常工作。差异会导致问题。
编辑2
请尝试配置Ubuntu PC的IP地址和默认路由手动。当设置工作正常时,我们开始分析 DHCP。不用担心,使用 CLI 手动设置的更改仅保留在 RAM 中,重新启动 PC 后所有更改都会消失。
更改前的状态、删除旧设置、更改后的状态
ip addr
ip route
sudo ip route del default via 192.168.0.1 dev enp37s0
sudo ip route del 192.168.0.0/23 dev enp37s0 proto kernel scope link src 192.168.0.61
sudo ip addr del 192.168.0.61/23 dev enp37s0
ip addr
ip route
验证旧路由和旧 IP 地址不存在。
新的设置,变更后的状态
sudo ip addr add 192.168.0.61/23 dev enp37s0 brd 192.168.1.255
sudo ip route add default via 192.168.0.1 dev enp37s0
ip add
ip route
ping -c 3 192.168.0.1
ping -c 3 1.1.1.1
新的设置有效吗?状态是否稳定,还是一段时间后与互联网的通信会再次中断?
编辑3
现在该分析网络数据包了。以下tcpdump
命令捕获解析所需的三种类型的通信:
- icmp
- ARP
- DHCP
诊断#1
处于互联网连接故障的状态。
如果 W-Fi 接口已打开,请将其关闭。在 Ubutnu PC 上打开两个终端窗口。
1号航站楼:
在主目录中创建一个子目录来记录捕获的数据包,然后开始捕获。bad.pcap
对于无法连接到 Internet 的状态,将创建一个文件。
mkdir ~/capture
sudo tcpdump -i enp37s0 "icmp or udp port 67 or udp port 68 or arp" -s 0 -w ~/capture/bad.pcap
2 号航站楼:
保存网络状态信息:
cd ~/capture
ip add >> bad.txt
ip rou >> bad.txt
ip nei >> bad.txt
验证连通性并将结果保存到同一个文件state1.txt
:
ping -c 3 192.168.0.1 | tee -a bad.txt
ping -c 3 1.1.1.1 | tee -a bad.txt
释放和更新PC的动态IP地址。
sudo dhclient -r enp37s0
sudo dhclient enp37s0
再次验证连通性:
ping -c 3 192.168.0.1 | tee -a bad.txt
ping -c 3 1.1.1.1 | tee -a bad.txt
返回第一个终端窗口。
1号航站楼:
tcpdump
使用停止命令Ctrl C
。
从您的计算机复制并保存bad.pcap
和文件。bad.txt
诊断#2
处于可以正常连接互联网的状态。
使用ip addr
找出以太网接口的名称,如果已改变,请在以下命令中更正。
1号航站楼:
good.pcap
在互联网连接正常的状态下创建一个文件,例如从 Live USB 闪存盘启动 Ubuntu 之后。
mkdir ~/capture
sudo tcpdump -i enp37s0 "icmp or udp port 67 or udp port 68 or arp" -s 0 -w ~/capture/good.pcap
2 号航站楼:
保存网络状态信息:
cd ~/capture
ip add >> good.txt
ip rou >> good.txt
ip nei >> good.txt
验证连通性并将结果保存到同一个文件good.txt
:
ping -c 3 192.168.0.1 | tee -a good.txt
ping -c 3 1.1.1.1 | tee -a good.txt
释放和更新PC的动态IP地址。
sudo dhclient -r enp37s0
sudo dhclient enp37s0
再次验证连通性:
ping -c 3 192.168.0.1 | tee -a good.txt
ping -c 3 1.1.1.1 | tee -a good.txt
返回第一个终端窗口。
1号航站楼:
tcpdump
使用停止命令Ctrl C
。
在关闭电脑之前,从计算机复制并保存good.pcap
和文件。good.txt
最后步骤
将所有 4 个文件保存为 ZIP 存档,以供详细分析。您可以.pcap
使用 Wireshark 应用程序打开和查看这些文件。不仅需要检查 L3 层,还需要检查 L2 层是否存在 MAC 地址差异。分析 ARP 和 DHCP 数据包可能会告诉我们一些信息。还需要注意各种 ICMP 消息,而不仅仅是回显请求和回显答复。
如果您不想公开提交您的诊断数据,请通过电子邮件发送给我。