はじめに
ネットワークに問題が発生したときのトラブルシューティングについて、順番にコマンドで確認することで原因を特定できるようにまとめてみました。
どんな問題もこれで特定できるわけではないと思いますが、どこらへんに原因があるかはある程度目処が付けられると思います。
切り分け手順
以下の順番で自身のネットワークインターフェースの確認から対向側のサーバへの疎通を確認していきます。自身に近い方から疎通確認していくイメージになります。
- ネットワークインターフェースの確認
- デフォルトゲートウェイの確認と疎通
- DNSでの名前解決
- インターネット上のサーバへのpingとtraceroute
- 対向サーバへのpingとtraceroute
- ポートを指定して疎通確認
想定している構成
今回想定しているのは下記のような構成です。自身のサーバはCentOSを想定しています。
ネットワークインターフェースの確認
まずは自身のサーバのネットワークインターフェースを確認します。ここで想定していなかった状態であれば自身のサーバのネットワークインターフェースの設定を見直します。
イメージとしては下記の部分になります。
下記のコマンドで確認できます。
ifconfigip addr show例えば以下のような結果だと、2つのイーサネットインターフェース（eth0とeth1）が有効になっていることがわかります。
$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.2.15 netmask 255.255.255.0 broadcast 10.0.2.255
inet6 fe80::5054:ff:fe4d:77d3 prefixlen 64 scopeid 0x20<link>
ether 52:54:00:4d:77:d3 txqueuelen 1000 (Ethernet)
RX packets 201225 bytes 287635311 (274.3 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 40521 bytes 2669360 (2.5 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.1 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::a00:27ff:fe30:42f2 prefixlen 64 scopeid 0x20<link>
ether 08:00:27:30:42:f2 txqueuelen 1000 (Ethernet)
RX packets 24 bytes 4244 (4.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 21 bytes 2786 (2.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0また、グローバルIPアドレスについては、下記で確認できます。
curl https://ifconfig.ioデフォルトゲートウェイの確認と疎通
次にデフォルトゲートウェイの確認と疎通を試します。ここで想定していない結果であればデフォルトゲートウェイまでの設定等を見直します。
イメージとしては下記の部分になります。
デフォルトゲートウェイは下記のコマンドで確認します。
route -nGenmaskが0.0.0.0となっている行がデフォルトゲートウェイになります。
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.2.2 0.0.0.0 UG 100 0 0 eth0
10.0.2.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 101 0 0 eth1デフォルトゲートウェイの設定が想定通りであれば、デフォルトゲートウェイまでの疎通が可能かを確認します。
ping -c 5 デフォルトゲートウェイのIPアドレス疎通ができれば以下のようになります。
$ ping -c 5 10.0.2.2
PING 10.0.2.2 (10.0.2.2) 56(84) bytes of data.
64 bytes from 10.0.2.2: icmp_seq=1 ttl=64 time=0.131 ms
64 bytes from 10.0.2.2: icmp_seq=2 ttl=64 time=0.304 ms
64 bytes from 10.0.2.2: icmp_seq=3 ttl=64 time=0.264 ms
64 bytes from 10.0.2.2: icmp_seq=4 ttl=64 time=0.148 ms
64 bytes from 10.0.2.2: icmp_seq=5 ttl=64 time=0.191 ms
--- 10.0.2.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4003ms
rtt min/avg/max/mdev = 0.131/0.207/0.304/0.068 msDNSでの名前解決
次にDNSでの名前解決がされているかを確認します。ここで想定していない結果であればDNS周りの設定等を見直します。
イメージとしては下記の部分になります。
名前解決は下記のコマンドで確認します。
nslookup ドメイン名dig ドメイン名名前解決ができれば対応するIPアドレスが取得できます。
$ nslookup google.com
Server: 10.0.2.3
Address: 10.0.2.3#53
Non-authoritative answer:
Name: google.com
Address: 172.217.26.14
Name: google.com
Address: 2404:6800:4004:822::200eインターネット上のサーバへのpingとtraceroute
次に対向サーバとは別のインターネット上のサーバへアクセスできるか確認します。ここで想定していない結果であればインターネットに出る通信の設定（FW等）を見直します。
イメージとしては下記の部分になります。
インターネット上のサーバへの疎通を確認する場合はGoogleのDNS（8.8.8.8）を利用するのがいいと思います。
$ ping -c 5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=63 time=11.8 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=63 time=5.39 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=63 time=11.7 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=63 time=5.82 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=63 time=11.2 ms
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4009ms
rtt min/avg/max/mdev = 5.396/9.217/11.868/2.954 mspingが届かない場合はtracerouteでどこまで届いているかを確認します。
アスタリスク「*」が表示されているのは、ルータのICMPによる問い合わせを拒否している場合かタイムアウトの場合になります。必ずしもタイムアウトではないので、最終的に宛先に届けば問題ありません。
$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 gateway (10.0.2.2) 0.221 ms 0.170 ms 0.149 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 dns.google (8.8.8.8) 14.568 ms 11.407 ms 14.479 ms対向サーバへのpingとtraceroute
先程と同様に対向サーバへのpingとtracerouteを確認します。ここで想定していない結果であれば対向サーバ側の設定（FW等）や対向サーバ向けの通信設定（IPアドレスで制限していないか等）を見直します。
イメージとしては下記の部分になります。
確認するコマンドは下記の通りです。
ping 対向サーバのIPアドレスtraceroute 対向サーバのIPアドレスポートを指定して通信
最後にポートを指定して疎通できるかを確認します。ここで想定していない結果であれば特定のポートに対しての疎通周りの設定（特定のポートへの疎通を拒否しているFWがあるか等）を見直します。
イメージとしては下記の部分になります。
下記のコマンドでポート指定で疎通確認ができます。
nc -vz 対向サーバのIPアドレス ポートcurl -l 対向サーバのIPアドレス:ポートそれでも解決しない場合は
大体のことはこれまでの確認である程度の目処がたつと思いますが、それでも解決しない場合は以下のことを試してみるのがいいと思います。
- 対向サーバ側のログを確認
- FWのログを確認
- パケットキャプチャ
