はじめに
ubuntu19.04 pc(xps13 9380)でpingとdig/nslookupができなくなってしまいました。
個人開発で使っているpcなので、右腕がごっそりもぎ取られた気分で辛かったです。。。
特定のwifiだけインターネットに繋がらない(ping digがtimeout)となってしまった我がpc https://t.co/DIsQxN3qa7
— gkz (@gkzvoice) November 6, 2019
- pingが通らない
gkz@localhost ~$ ping www.google.com
ping: www.google.com: Temporary failure in name resolution
- nslookupもダメ
gkz@localhost ~$ nslookup wwww.google.com
Server: 127.0.0.53
Address: 127.0.0.53#53
** server can't find wwww.google.com: SERVFAIL
gkz@localhost ~$ nslookup wwww.google.co.jp 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53
** server can't find wwww.google.co.jp: NXDOMAIN
結論からいうと後述する以下の2つの対処と再起動をすれば、よかったようですが、シンボリックリンクの張替えをしていなかったためにめちゃくちゃハマりました汗。
- /etc/systemd/resolved.confを編集
- シンボリックリンクを張替え
無事私用以外のwifiでも接続できるようになったので、ログを記事に残しておこうと思います。
環境/バージョン情報
- Ubuntu19.04 (Disco Dingo)(ローカル)
お話すること
- 対処方法(DNSサーバを指定)
- /etc/systemd/resolved.confを編集
- シンボリックリンクを張替え
- 確認したこと
- ネットワークの設定を確認
- pingが自分自身に通るか
- ルーティングテーブルの確認 - IPアドレスとMACアドレスを対応づけているARPテーブルの確認
- 確認すればもっと早く解決できたかもしれないこと
- /etc/resolv.confにシンボリックリンクが貼られているか
- 53番ポートが空いているか確認すること
対処方法(DNSサーバを指定)
/etc/systemd/resolved.confに追記
今回はGoogle Public DNSを採用した。
$ tail /etc/systemd/resolved.conf
[Resolve]
#DNS=
#FallbackDNS=
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#DNSOverTLS=no
#Cache=yes
#DNSStubListener=yes
#ReadEtcHosts=yes
#DNS=192.168.1.1
DNS=8.8.8.8 8.8.4.4 ## 追記
シンボリックリンクを張替え
次のコマンドを叩いてシンボリックリンクが貼られていることが分かった場合、張り替える必要があります。
gkz@localhost ~ $ cd /etc
gkz@localhost $ ls -la /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Jul 21 13:34 resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
/run/systemd/resolve/stub-resolv.confから/run/systemd/resolve/resolv.confに張り替えます。
この2つのファイルについては、確認すればもっと早く解決できたかもしれないということで後述します。
gkz@localhost /etc $ sudo ln -sf ../run/systemd/resolve/resolv.conf resolv.conf
gkz@localhost /etc $ ls -la resolv.conf
lrwxrwxrwx 1 root root 34 Nov 17 15:19 resolv.conf -> ../run/systemd/resolve/resolv.conf
以上の2点を行った後、再起動をすればよいのですが、そのときのログを残していなかったので該当コマンドだけ貼っておきます。
たいして考えず、リブートもさせていたかもしれません。
$ systemctl restart systemd-resolved
$ sudo reboot
ご参考までにsystemd-reslovedのステータスを。
gkz@localhost ~$ systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor
Active: active (running) since Mon 2019-12-02 12:49:28 JST; 7min ago
Docs: man:systemd-resolved.service(8)
https://www.freedesktop.org/wiki/Software/systemd/resolved
https://www.freedesktop.org/wiki/Software/systemd/writing-network-con
https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-cl
Main PID: 778 (systemd-resolve)
Status: "Processing requests..."
Tasks: 1 (limit: 4915)
Memory: 6.2M
CGroup: /system.slice/systemd-resolved.service
└─778 /lib/systemd/systemd-resolved
Dec 02 12:49:27 XPS13-9380 systemd[1]: Starting Network Name Resolution...
Dec 02 12:49:28 XPS13-9380 systemd-resolved[778]: Positive Trust Anchors:
Dec 02 12:49:28 XPS13-9380 systemd-resolved[778]: . IN DS 19036 8 2 49aac11d7b6f
Dec 02 12:49:28 XPS13-9380 systemd-resolved[778]: . IN DS 20326 8 2 e06d44b80b8f
Dec 02 12:49:28 XPS13-9380 systemd-resolved[778]: Negative trust anchors: 10.in-
Dec 02 12:49:28 XPS13-9380 systemd-resolved[778]: Using system hostname 'XPS13-9
Dec 02 12:49:28 XPS13-9380 systemd[1]: Started Network Name Resolution.
調査したこと
ネットワークの設定を確認
gkz@localhost ~$ ip a | head
1: lo: <LOOPBACK,UP,LOWER_UP> xxxxxxxx
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: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether xxxxxxxxxxxxxx brd xxxxxxxxxxxxxx
### ※1
inet 192.168.xxx.xxx/24 brd 192.168.0.255 scope global dynamic noprefixroute wlp2s0
valid_lft xxxxxxxxxx preferred_lft xxxxxxxxx
inet6 xxxxxxxxxxxxxxxxxxxxxx scope link noprefixroute
valid_lft forever preferred_lft forever
※1 下記の記事によれば、IPアドレスは正しく割り振られているようです。
正しいIPアドレス
普通は、以下のようになっているはずです。192.168.(0~255).(1~254)
172.(16~31).(0~255).(1~254)
10.(0~255).(0~255).(1~254)特殊な場合ですが、もしIPアドレスを取得しているならその値が設定されている必要があります。
参考
インターネットに繋がらないときの５つのコマンド（Linux編）
pingが自分自身に通るか
gkz@localhost ~$ ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.077 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.093 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.085 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.080 ms
^C
--- 127.0.0.1 ping statistics ---
### ※2
4 packets transmitted, 4 received, 0% packet loss, time 33ms
rtt min/avg/max/mdev = 0.077/0.083/0.093/0.012 ms
※2 自分自身に対してはpingが打てているので、内部的には問題なさそうです。
ルーティングテーブルの確認
gkz@localhost ~$ ip route show | head
default via 192.168.0.1 dev wlp2s0 proto dhcp metric 600
この行のゲートウェイにルータのアドレスが設定されているようなのでここも問題ないです。
IPアドレスとMACアドレスを対応づけているARPテーブルの確認
gkz@localhost ~$ ip n | grep 192.168
192.168.0.1 dev wlp2s0 lladdr xxxxxxxxxxxx STALE
左記のip route showで確認できたdefaultのipの行がREACHABLEではないです。
なお、「REACHABLE」はARPによりアドレス解決された直後、 「STALE」は解決してから一定時間経過した状態を示します。
(あと、「PERMANENT」は永久保存、「FAILED」は解決に失敗、です。)
gkz@localhost ~$ sudo systemctl status network-manager | grep Active
Active: active (running) since Thu 2019-11-07 23:39:15 JST; 5min ago
確認すればもっと早く解決できたかもしれないこと
/etc/resolv.confにシンボリックリンクが貼られているか
53番ポートが空いているか確認すること
類似ケースの原因として53番ポートが空いていなかった点が挙げられています。
つながらなかったときのポートの空き確認をしていないのでなんともいえないですが、またトラブったらポートの空きをチェックしてみようと思います。
local DNS stub listener を利用することにはさまざまな利点がありますが、この機能をオフにしたい場合もあります。私の場合は DNS コンテンツサーバを起動しようとしたときに local DNS stub listener が53番ポートを先に利用してしまっていたことで起動できなくなるという問題が起こりました。
参考までに正常にインターネットに接続できる現時点でのポート。
みたかんじ変わらず、ローカルに向いているように思えるので、シンボリックリンクはどういう働きをしたのか不明です汗。
gkz@localhost ~$ sudo netstat -ltupn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 192.168.122.1:53 0.0.0.0:* LISTEN 1208/dnsmasq
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 765/systemd-resolve
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 894/cupsd
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 1002/postgres
tcp6 0 0 :::80 :::* LISTEN 2011/docker-proxy
tcp6 0 0 ::1:631 :::* LISTEN 894/cupsd
udp 0 0 0.0.0.0:56440 0.0.0.0:* 885/avahi-daemon: r
udp 0 0 192.168.122.1:53 0.0.0.0:* 1208/dnsmasq
udp 0 0 127.0.0.53:53 0.0.0.0:* 765/systemd-resolve
udp 0 0 0.0.0.0:67 0.0.0.0:* 1208/dnsmasq
udp 0 0 0.0.0.0:68 0.0.0.0:* 1508/dhclient
udp 0 0 0.0.0.0:631 0.0.0.0:* 945/cups-browsed
udp 0 0 224.0.0.251:5353 0.0.0.0:* 2616/chrome --type=
udp 0 0 224.0.0.251:5353 0.0.0.0:* 2578/chrome
udp 0 0 224.0.0.251:5353 0.0.0.0:* 2578/chrome
udp 0 0 0.0.0.0:5353 0.0.0.0:* 885/avahi-daemon: r
udp6 0 0 :::59495 :::* 885/avahi-daemon: r
udp6 0 0 :::5353 :::* 885/avahi-daemon: r
参考
今回のトラブルシュートは、以下の3つの記事を参考におこなったので、ぜひ本記事と併せてご参照ください。
P.S. Twitterもやってるのでフォローしていただけると泣いて喜びます:)
#gkz