Ubuntu 18.04サーバーの1つに問題があります。
最近の停電以降、ネットワークの外部から接続できなくなりました。
現在、ネットワーク上の他のサーバーから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
私のルーター(192.168.1.1)でpingを実行すると動作しますが、実際には非常に遅く断続的に中断されます。
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回の試みのうちの1回)、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
そのサーバーのresolv.confにネームサーバー8.8.8.8を追加してみましたが、違いはありませんでした。
編集する
奇妙なことに、外部DNSサーバーにも遅いですが、pingは可能です。たとえば、
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
最終的にルーターをリスンし、問題を解決しました。これは私がリモートでできることではありません。とても奇妙な問題です。ルータを強制的に再起動することは不要なように見えましたが、その時点では避けられませんでした。