ubuntu19.04でpingとnslookupができなくなり、DNSサーバーを変更するのにめちゃくちゃハマった話

## はじめに
ubuntu19.04 pc(xps13 9380)で`pingとdig/nslookupができなくなってしまいました。`
個人開発で使っているpcなので、右腕がごっそりもぎ取られた気分で辛かったです。。。

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">特定のwifiだけインターネットに繋がらない(ping digがtimeout)となってしまった我がpc <a href="https://t.co/DIsQxN3qa7">https://t.co/DIsQxN3qa7</a></p>&mdash; gkz (@gkzvoice) <a href="https://twitter.com/gkzvoice/status/1192230031709224963?ref_src=twsrc%5Etfw">November 6, 2019</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

- 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編）]
(https://blog.yyyak.com/post/network_check_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つの記事を参考におこなったので、ぜひ本記事と併せてご参照ください。


- [インターネットに繋がらないときの５つのコマンド（Linux編）]
(https://blog.yyyak.com/post/network_check_linux/)

- [Linux Mint(Ubuntu) で静的にDNSサーバを指定する方法]
(https://www.aintek.xyz/posts/linux-mint-dns-setting)

- [Ubuntu 18.04 の systemd-resolved で local DNS stub listener の利用をやめる]
(https://qiita.com/shora_kujira16/items/31d09b373809a5a44ae5)


## P.S. Twitterもやってるのでフォローしていただけると泣いて喜びます:)
[@gkzvoice](https://twitter.com/gkzvoice)


\#gkz