定時帰る術-Linux ネットワークトラブルシューティング

ネットワークトラブルがよく発生すると思うけど、ネット上に、どうやって解決できるかの記事があんまりないので、川口のネットワークトラブルシューティングの考え方を整理してみた。

**トラブルシューティングの世界では、コマンドを覚えることより、考え方の方重要だと思って、細かいコマンドのオプションや使い方とかはここで略す。**



### 何も考えずに、とりあえずpingをやってみよう。
```
[root@test ~]# ping 192.168.56.1
PING 192.168.56.1 (192.168.56.1) 56(84) bytes of data.
64 bytes from 192.168.56.1: icmp_seq=1 ttl=128 time=0.546 ms
64 bytes from 192.168.56.1: icmp_seq=2 ttl=128 time=1.19 ms
64 bytes from 192.168.56.1: icmp_seq=3 ttl=128 time=2.04 ms
64 bytes from 192.168.56.1: icmp_seq=4 ttl=128 time=1.12 ms
```
### pingがとれず、同セグの場合、ip nでarpレコードがあるか確認しよう。
OSのFW設定によって、pingが拒否される場合も多い
pingがとれないけど、arpレコードが表示される場合もは、OSのFWに拒否されると考える
**対象機器のFW設定を確認してみよう**
```
[root@test ~]# ip n
192.168.56.100 dev enp0s8 lladdr 08:00:27:f5:8d:95 STALE
10.0.2.2 dev enp0s3 lladdr 52:54:00:12:35:02 REACHABLE
192.168.56.1 dev enp0s8 lladdr 0a:00:27:00:00:07 DELAY
```

### pingがとれないなら、tracepathでどこまでいけるのかをみてみよう。
内部NW機器までいける場合は、その対象機器にログインして、ルーティングテーブルを確認しよう。
```
[root@test ~]# tracepath -n 8.8.8.8
 1?: [LOCALHOST]                      pmtu 1500
 1:  no reply
 2:  no reply
 3:  no reply
```
### ルーティングの想定通りにいけない場合、自分自身のルーティングテーブルをみてみよう。
```
[root@test ~]# ip route
default via 192.168.56.1 dev enp0s8
1.1.1.254 dev enp0s3 proto static scope link metric 102
10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15 metric 102
192.168.56.0/24 dev enp0s8 proto kernel scope link src 192.168.56.102 metric 101
```
### スタティックルーティングテーブルが長く、目でみるのが面倒だと思う方は、ip route getでやってみよう
viaの後ろが対象IPへの行先
```
[root@test ~]# ip route get 8.8.8.8
8.8.8.8 via 192.168.56.1 dev enp0s8 src 192.168.56.102 uid 0
    cache
```
**PING(ICMP)はOSI参照モデルのネットワーク層のため、トランスポート層のことはしらいないので、サービスまでいけるのかpingで確認できない**
### nc(ncat)で確認しよう。
(nc、ncatは同じ)
```
[root@test ~]# which nc
/usr/bin/nc
[root@test ~]# ll /usr/bin/nc
lrwxrwxrwx. 1 root root 22  9月 26 16:46 /usr/bin/nc -> /etc/alternatives/nmap
[root@test ~]# ll /etc/alternatives/nmap
lrwxrwxrwx. 1 root root 13  9月 26 16:46 /etc/alternatives/nmap -> /usr/bin/ncat
[root@test ~]# ll /usr/bin/ncat
-rwxr-xr-x. 1 root root 470104  3月 28  2019 /usr/bin/ncat
```

### 川口的には-v をつけると結果も表示されるのが見やすいと思う
```
[root@test ~]# nc -z -v 192.168.56.1 22
Ncat: Version 7.70 ( https://nmap.org/ncat )
Ncat: Connection refused.
[root@test ~]# nc -z -v 192.168.56.1 3389
Ncat: Version 7.70 ( https://nmap.org/ncat )
Ncat: Connected to 192.168.56.1:3389.
Ncat: 0 bytes sent, 0 bytes received in 0.01 seconds.
```
### ncでConnection refused場合、対象機器のポートちゃんとあいている（LISTEN）かをみてみよう

**antupがネットワーク初かもしれない。antupが川口流であり、つけることで定時に帰られる。**
```
a：LISTENかどうか考えずに、とりあえず全部表示させる
n：ポート番号を番号のままで表示させる。
tu：TCP/UDPポートを表示させる。
p：プロセスも表示させる。（ここが重要）
（プロセスを表示することで、トラブルシューティングがやりやすくなる。↑に助けられたことが何回もある）
```
```
[root@test ~]# ss -antup
Netid           State            Recv-Q           Send-Q                       Local Address:Port                       Peer Address:Port           Process
tcp             LISTEN           0                128                                0.0.0.0:22                              0.0.0.0:*               users:(("sshd",pid=882,fd=4))
tcp             LISTEN           0                128                                   [::]:22                                 [::]:*               users:(("sshd",pid=882,fd=6))
```

### これで大体の問題が解決できる思うけど、もし解決できないなら、パケットキャプチャをやってみよう
・GW機器
ミラーリングポートを作って、作業端末でwireshareをみてみれば、いいだろう。
**ここで少し注意してもらうことがあって、↑のままでwireshareをみると、多分津波が来ると同じと思う。**
まずはフィルタを設定してから、ミラーリングポートにさすようにしよう。

・サーバ
tcpdumpでちゃんと送信したのか、受信され返していくかをみてみよう。

パケットキャプチャでもダメであれば、機器のファームウェアをアップデートしたり、ランケーブルをかえてみたりしてみばれと思う。
**（川口があの天下のシスコのファームウェアに引っかかって、定時に帰られないこともある
なので、全部ダメなら、ちゃんと自信を持って、ファームウェアをアップデートしてみようって提案できるようにしよう）**