系统重启后网络问题 - Ubuntu 18.04 Server

系统重启后网络问题 - Ubuntu 18.04 Server

我的一台 Ubuntu 18.04 服务器出现问题。

最近断电后,我无法再从网络外部连接到它。

我目前正在通过网络中的另一台服务器(可以访问互联网)通过 SSH 连接到它。

ping google.com
ping: google.com: Temporary failure in name resolution

 ping -c4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3050ms



cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 127.0.0.1
nameserver 192.168.1.1

Ping 我的路由器 (192.168.1.1) 可以工作,但实际上速度很慢,并且间歇性挂起:

 ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=1.81 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=1.67 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=1.85 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=3.80 ms

而且,有时(可能每 10 次尝试中就有一次)对 google.com 的 ping 操作会返回以下内容:

ping google.com
PING google.com (172.217.169.78) 56(84) bytes of data.
64 bytes from lhr48s09-in-f14.1e100.net (172.217.169.78): icmp_seq=1 ttl=55 time=24.6 ms
64 bytes from lhr48s09-in-f14.1e100.net (172.217.169.78): icmp_seq=2 ttl=55 time=19.2 ms
64 bytes from lhr48s09-in-f14.1e100.net (172.217.169.78): icmp_seq=3 ttl=55 time=14.8 ms
64 bytes from lhr48s09-in-f14.1e100.net (172.217.169.78): icmp_seq=4 ttl=55 time=25.7 ms
64 bytes from lhr48s09-in-f14.1e100.net (172.217.169.78): icmp_seq=5 ttl=55 time=57.0 ms
64 bytes from lhr48s09-in-f14.1e100.net (172.217.169.78): icmp_seq=6 ttl=55 time=21.9 ms
64 bytes from lhr48s09-in-f14.1e100.net (172.217.169.78): icmp_seq=7 ttl=55 time=16.6 ms

我已经禁用了解析:

 systemctl status systemd-resolved.service
● systemd-resolved.service - Network Name Resolution
   Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:systemd-resolved.service(8)
           https://www.freedesktop.org/wiki/Software/systemd/resolved
           https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
           https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients

并且,根据另一个论坛的一些建议,添加了一个条目以/etc/NetworkManager/conf.d/no-systemd-resolved.conf 确保网络管理员忽略 resolvd。

上次系统重新启动时(大约 3 周前),系统已恢复,完全没有与网络相关的问题。那时服务器没有更新。

如果我查看网络上另一台 Linux 机器(在本例中为 Rasberry Pi)的配置,我可以看到它已成功使用 resolvd:

pi@colin:~ $ cat /etc/resolv.conf
# Generated by resolvconf
nameserver 192.168.1.1
nameserver 8.8.8.8
nameserver fd51:42f8:caae:d92e::1

我尝试将名称服务器 8.8.8.8 添加到有问题的服务器的 resolv.conf 中,但这没有什么区别。

编辑

奇怪的是,我可以 ping 通外部 DNS 服务器,尽管速度很慢。例如:

PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=7 ttl=58 time=15.1 ms
64 bytes from 1.1.1.1: icmp_seq=98 ttl=58 time=18.2 ms
64 bytes from 1.1.1.1: icmp_seq=99 ttl=58 time=15.6 ms
64 bytes from 1.1.1.1: icmp_seq=100 ttl=58 time=12.4 ms
64 bytes from 1.1.1.1: icmp_seq=101 ttl=58 time=9.09 ms
64 bytes from 1.1.1.1: icmp_seq=102 ttl=58 time=22.3 ms
...
<approx 40 second pause>
...
64 bytes from 1.1.1.1: icmp_seq=103 ttl=58 time=16.5 ms
64 bytes from 1.1.1.1: icmp_seq=104 ttl=58 time=24.9 ms
64 bytes from 1.1.1.1: icmp_seq=105 ttl=58 time=12.3 ms
64 bytes from 1.1.1.1: icmp_seq=144 ttl=58 time=13.9 ms
64 bytes from 1.1.1.1: icmp_seq=145 ttl=58 time=28.4 ms
...
<approx 10 second pause>
...
64 bytes from 1.1.1.1: icmp_seq=146 ttl=58 time=8.77 ms
64 bytes from 1.1.1.1: icmp_seq=147 ttl=58 time=9.13 ms
64 bytes from 1.1.1.1: icmp_seq=148 ttl=58 time=22.3 ms
64 bytes from 1.1.1.1: icmp_seq=149 ttl=58 time=25.4 ms
...
<approx 20 second pause>
...
64 bytes from 1.1.1.1: icmp_seq=190 ttl=58 time=9.26 ms
64 bytes from 1.1.1.1: icmp_seq=191 ttl=58 time=15.9 ms
64 bytes from 1.1.1.1: icmp_seq=192 ttl=58 time=12.7 ms
64 bytes from 1.1.1.1: icmp_seq=235 ttl=58 time=14.8 ms
64 bytes from 1.1.1.1: icmp_seq=236 ttl=58 time=19.7 ms

ping 响应时间似乎不一致。

答案1

我最终弹跳了路由器并解决了问题。这不是我可以远程完成的事情。非常奇怪的问题,路由器的硬重启似乎没有必要,但在那时是不可避免的。

相关内容