☰

建立有效的互联网连接需要什么（ubuntu 22.04 和 systemd）

tag-icon • tag-icon linux ubuntu networking networkmanager
建立有效的互联网连接需要什么（ubuntu 22.04 和 systemd）

我去过有一点麻烦在我的 ubuntu 22.04 盒子上。

这对理解互联网连接的工作原理提出了一些问题。据我了解，为了正常工作的互联网连接，我需要：

  1. 与充当网关的路由器的连接
  2. 路由器通过 DHCP 分配的 IP 地址
  3. DNS 名称服务器地址也由路由器通过 DHCP 提供

这是必要的，但似乎还不够。还需要什么？

在 systemd 下，NetworkManager “激活网络连接”。这至少涵盖了第 1-3 点。

我见过一种情况：

  • 连接已“激活”
  • 分配的IP地址正确
  • 分配的DNS服务器是正确的

但我无法与互联网通信（除非我使用恢复模式或同一 LAN 上的不同 PC）：

  • ping 超时
  • nslookup 超时
  • LAN 图标上覆盖有一个问号。

我已经习惯了这种“只是工作”，所以我需要问：

问：为了使网络真正工作，除了“激活网络连接”之外还需要做什么？

问 网络图标上的问号是什么意思？ （系统更新后不再出现）

问“激活网络连接”实际上是什么意思？

这是一个故意提出的一般性问题。对于特定的示例问题，请参阅我在第一行链接到的问题。

工作案例中的一个关键区别是以下行route：

default         _gateway        0.0.0.0         UG    100    0        0 enp0s31f6

请参阅下面的更多细节

下面可能是不相关的细节

对于 ping strace 显示：

socket()
connect()  - "8.8.8.8"
setsockopt()
newfsstatat()
ioctl(TCGETS)
ioctl(TIOCGWINSZ)
sendto() "8.8.8.8"
recvmsg()

并且 recvmsg() 失败并显示 EAGAIN，直到超时。因此，从某种意义上说，内核允许 connect() 调用成功，但连接似乎不允许数据流动。

但对于 nslookup strace 显示：

connect("127.0.0.53")

这不是正确的名称服务器。这可能相关。根据 ，似乎有东西在 127.0.0.53 上监听ss。

>tracepath -n -p 55 8.8.8.8.8
1?: [LOCALHOST]   pmtu 1500
1: no reply
...

并且它的recvmesg()再次超时（在重复EAGAIN之后）

具体问题的更多详细信息：

不工作的情况：

> route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.0.1     0.0.0.0         UG    100    0        0 enp0s31f6
link-local      0.0.0.0         255.255.0.0     U     1000   0        0 virbr0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.0.0     0.0.0.0         255.255.255.0   U     100    0        0 enp0s31f6
192.168.123.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0
> ip addr
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: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 70:4d:7b:64:62:35 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.17/24 brd 192.168.0.255 scope global dynamic noprefixroute enp0s31f6
       valid_lft 854001sec preferred_lft 854001sec
    inet6 fe80::ba46:11c7:b4d1:16b3/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: wlx503eaa945dc9: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 50:3e:aa:94:5d:c9 brd ff:ff:ff:ff:ff:ff
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:ed:8b:39 brd ff:ff:ff:ff:ff:ff
    inet 192.168.123.1/24 brd 192.168.123.255 scope global virbr0
       valid_lft forever preferred_lft forever
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:fe:8d:1b:aa brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever

# inxi -N
Network:
  Device-1: Intel Ethernet I219-V driver: e1000e
  Device-2: Realtek RTL8188EUS 802.11n Wireless Network Adapter type: USB driver: r8188eu

# netstat -i
Kernel Interface table
Iface      MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
docker0   1500        0      0      0 0             0      0      0      0 BMU
enp0s31f  1500    27075      0      0 0          1608      0      0      0 BMRU
lo       65536     5441      0      0 0          5441      0      0      0 LRU
virbr0    1500        0      0      0 0             0      0      0      0 BMU

# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 enp0s31f6
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 virbr0
172.17.0.0      0.0.0.0         255.255.0.0     U         0 0          0 docker0
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 enp0s31f6
192.168.123.0   0.0.0.0         255.255.255.0   U         0 0          0 virbr0

之后的工作案例：

  • 以恢复模式启动
  • 启用网络
  • 恢复正常启动

新输出：

$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 enp0s31f6
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 enp0s31f6
172.17.0.0      0.0.0.0         255.255.0.0     U         0 0          0 docker0
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 enp0s31f6
192.168.123.0   0.0.0.0         255.255.255.0   U         0 0          0 virbr0

$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    100    0        0 enp0s31f6
link-local      0.0.0.0         255.255.0.0     U     1000   0        0 enp0s31f6
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.0.0     0.0.0.0         255.255.255.0   U     100    0        0 enp0s31f6
192.168.123.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

$ netstat -i
Kernel Interface table
Iface      MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
docker0   1500        0      0      0 0             0      0      0      0 BMU
enp0s31f  1500    85232      0      1 0         46876      0      0      0 BMRU
lo       65536     4250      0      0 0          4250      0      0      0 LRU
virbr0    1500        0      0      0 0             0      0      0      0 BMU

$ inxi -N
Network:
  Device-1: Intel Ethernet I219-V driver: e1000e
  Device-2: Realtek RTL8188EUS 802.11n Wireless Network Adapter type: USB
    driver: r8188eu

$ ip addr
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: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 70:4d:7b:64:62:35 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.17/24 brd 192.168.0.255 scope global dynamic noprefixroute enp0s31f6
       valid_lft 862734sec preferred_lft 862734sec
    inet6 fe80::ba46:11c7:b4d1:16b3/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: wlx503eaa945dc9: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 50:3e:aa:94:5d:c9 brd ff:ff:ff:ff:ff:ff
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:ed:8b:39 brd ff:ff:ff:ff:ff:ff
    inet 192.168.123.1/24 brd 192.168.123.255 scope global virbr0
       valid_lft forever preferred_lft forever
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:05:f9:90:04 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever

答案1

即使路由器没有到您的互联网服务提供商的有效上游连接，您的路由器也可以提供您列出的所有三项功能。这样，即使路由器的互联网连接尚未正确配置，您也可以使用 Web 浏览器访问路由器的配置界面（假设有）。

因此，您应该尝试从路由器本身获取一些诊断信息：如果它有指示灯，它们的行为如何？如果您可以访问路由器的 Web 界面，其状态页面是否表明 Internet 端连接正常？

还有一种可能性是，路由器可能是“儿童防护”的，或者被限制为仅允许互联网连接到特定的客户端系统。例如，路由器中过于严格的防火墙规则可能会导致您的症状。

在现代操作系统上，“激活网络连接”通常包括测试：操作系统尝试连接某些操作系统供应商维护的云服务，以验证连接是否确实有效。如果没有，系统甚至不会尝试下载更新，并且通常会指示缺少互联网连接（例如，连接图标上带有问号）。

在 NetworkManager 中，这样的连接测试是可配置且可选的，但 Ubuntu 似乎默认启用它。

即使路由器没有到您的互联网服务提供商的有效上游连接，您的路由器也可以提供您列出的所有三项功能。这样，即使路由器的互联网连接尚未正确配置，您也可以使用 Web 浏览器访问路由器的配置界面（假设有）。

因此，您应该尝试从路由器本身获取一些诊断信息：如果它有指示灯，它们的行为如何？如果您可以访问路由器的 Web 界面，其状态页面是否表明 Internet 端连接正常？

还有一种可能性是，路由器可能是“儿童防护”的，或者被限制为仅允许互联网连接到特定的客户端系统。例如，路由器中过于严格的防火墙规则可能会导致您的症状。

在现代操作系统上，“激活网络连接”通常包括测试：操作系统尝试连接某些操作系统供应商维护的云服务，以验证连接是否确实有效。如果没有，系统甚至不会尝试下载更新，并且通常会指示缺少互联网连接（例如，连接图标上带有问号）。

在 NetworkManager 中，这样的连接测试是可配置且可选的，但 Ubuntu 似乎默认启用它。

套接字（）连接（） - “8.8.8.8”setsockopt（）newfsstatat（）ioctl（TCGETS）ioctl（TIOCGWINSZ）sendto（）“8.8.8.8”recvmsg（）

所以如果connect()并且sendto()显然成功，那么据内核所知，ping 数据包曾是送出。

根据man 2 recvmsg，EAGAIN 错误意味着：

EAGAIN 或 EWOULBlock

套接字被标记为非阻塞并且接收操作将阻塞，或者已设置接收超时并且在接收数据之前超时已过期。 POSIX.1 允许在这种情况下返回任一错误，并且不要求这些常量具有相同的值，因此可移植应用程序应检查这两种可能性。

换句话说，没有收到答复。如果没有随附的 ICMP 错误数据包描述原因，则系统无法提供进一步的解释。一般来说，这意味着某些故障或配置的限制（例如防火墙规则）导致您的传出 ping 数据包或传入 ping 响应在您的路由器处或在其上游的某个点被丢弃。

在这种情况下，一种可能的测试是traceroute。由于防火墙在现代网络中无处不在，因此我发现专门使用基于 TCP 或 UDP 的跟踪路由非常有用，定向到我期望工作的特定端口。所以在这种情况下：

sudo traceroute -n -T -p 53 8.8.8.8

尝试基于 TCP 的跟踪路由到 Google 知名 DNS 服务器的端口 53。由于 DNS 协议同时使用 TCP 和 UDP，并且 TCP 端口为跟踪路由提供了更强大的响应，因此这应该能够告诉您在停止接收返回响应之前传出数据包可以到达多远。

如果您在带有数据包传输时间的输出中看到的最后一个 IP 地址traceroute是您的路由器的 IP 地址，则表明问题出在您的路由器中或在它与 ISP 的路由器之间。

如果您在路由器的 IP 地址之后看到任何其他 IP 地址，则问题出在 ISP 设备内的某处（更有可能）或 ISP 与其他组织之间的互联网主干连接中（可能性较小，因为这些通常是多重冗余的）。在这两种情况下，您都无法自行修复：您能做的最好的事情就是向您的 ISP 报告问题并等待他们修复它或在中断处重新路由流量。

但对于 nslookup strace 显示：

连接（“127.0.0.53”）

这不是正确的服务器名称。这可能相关。

您没有阅读链接问题的答案吗？您的系统正在使用systemd-resolved.大多数应用程序使用glibc的主机名解析API，并且hosts: ...resolve...您中的关键字/etc/nsswitch.conf指示它直接进行通信systemd-resolved。为了一些旧的应用程序和特定于 DNS 的工具（如 ）nslookup，在 127.0.0.53 的端口 53（即 的替代 IP 地址）中systemd-resolved维护向后兼容性/etc/resolv.conf和 DNS 解析器代理localhost。您应该运行resolvectl以查看系统的实际 DNS 设置，并忽略旧的/etc/resolv.conf.

但一次有一个问题：由于您显然甚至无法通过 IP ping 8.8.8.8，因此您必须解决 IP 连接问题，然后才能开始担心 DNS 解析。

一件可能让您感到沮丧的新事情是，出于隐私原因，最新的操作系统默认情况下可能会在每次启动时随机化您的 MAC 地址。如果您的路由器已配置了系统的特定 IP 预留或其他特定于主机的设置，则此类随机化可能会给工作带来麻烦。

您的 NetworkManager 设置应包含禁用 MAC 地址随机化的选项。在恢复模式下可能会跳过随机化，因为这可能会使用简化的过程来启动网络。

相关内容