ネットワークトラブルがよく発生すると思うけど、ネット上に、どうやって解決できるかの記事があんまりないので、川口のネットワークトラブルシューティングの考え方を整理してみた。
トラブルシューティングの世界では、コマンドを覚えることより、考え方の方重要だと思って、細かいコマンドのオプションや使い方とかはここで略す。
何も考えずに、とりあえず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でちゃんと送信したのか、受信され返していくかをみてみよう。
パケットキャプチャでもダメであれば、機器のファームウェアをアップデートしたり、ランケーブルをかえてみたりしてみばれと思う。
（川口があの天下のシスコのファームウェアに引っかかって、定時に帰られないこともある
なので、全部ダメなら、ちゃんと自信を持って、ファームウェアをアップデートしてみようって提案できるようにしよう）