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
내 라우터(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번 시도 중 한 번) 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
결국 라우터를 수신 거부하고 문제가 해결되었습니다. 이건 내가 원격으로 할 수 있는 일이 아니다. 아주 이상한 문제입니다. 라우터를 강제로 재부팅하는 것은 불필요한 것처럼 보였지만 그 시점에서는 피할 수 없었습니다.