通信ができない際のトラブルシュート方法 Vol.02 / 開発者向けブログ・イベント

こんにちは、GMOインターネットグループ株式会社ネットワークソリューションチームの梅崎です

今回は主にサーバー管理者/アプリ開発者向けに
「ネットワークが繋がらない、通信ができない」となったときの
・クライアント/サーバー側で可能なトラブルシュート方法
・ネットワーク管理者へ調査依頼を出す際に我々が欲しい情報
をまとめてみました
今回はその通信に問題がある場合の被疑箇所の特定編です

通信に問題がある場合の被疑箇所の特定

前提として、クライアントとサーバーとの通信の場合
通信経路上におおよそ下記の機器があることが多いです

クライアント <==> クライアント側GW/FW <==> 経由するGW/FW <==> サーバー側GW/FW <==> サーバー

この章ではそれぞれどこのポイントで通信ができていないかの調査方法について記載しています
※ICMPが全区間にて許可されている前提の調査方法です
　特別セキュリティ要件が厳しくICMPもできない場合は、ネットワーク管理者へ直接調査依頼をした方が早いかもしれないです

全体的なL3(ルーティング)の調査

クライアントからサーバー、もしくはサーバーからクライアントへpingを打ってください

# pingコマンドで確認、「192.0.2.123」を実際のIPアドレスへ置き換えてください
ping 192.0.2.123

# 出力例
#
# 通信は問題ない場合
# PING 192.0.2.123 (192.0.2.123) 56(84) bytes of data.
# 64 bytes from 192.0.2.123: icmp_seq=1 ttl=64 time=0.340 ms
# 64 bytes from 192.0.2.123: icmp_seq=2 ttl=64 time=0.422 ms
# 64 bytes from 192.0.2.123: icmp_seq=3 ttl=64 time=0.418 ms
# 64 bytes from 192.0.2.123: icmp_seq=4 ttl=64 time=0.450 ms
# 64 bytes from 192.0.2.123: icmp_seq=5 ttl=64 time=0.382 ms
# ^C
# --- 192.0.2.123 ping statistics ---
# 5 packets transmitted, 5 received, 0% packet loss, time 3999ms
# rtt min/avg/max/mdev = 0.340/0.402/0.450/0.041 ms
#
#
# 通信が許可されていない場合
# PING 192.0.2.123 (192.0.2.123) 56(84) bytes of data.
# From 192.0.2.123 icmp_seq=1 Destination Port Unreachable
# From 192.0.2.123 icmp_seq=2 Destination Port Unreachable
# From 192.0.2.123 icmp_seq=3 Destination Port Unreachable
# ^C
# --- 192.0.2.123 ping statistics ---
# 3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 1999ms
#
#
# 応答がない場合(タイムアウトする場合)
# PING 192.0.2.123 (192.0.2.123) 56(84) bytes of data.
# ^C
# --- 192.0.2.123 ping statistics ---
# 9 packets transmitted, 0 received, 100% packet loss, time 8000ms

通信は問題ない場合、ルーティングは問題がなく、アクセス許可がされていない可能性が高いです
「アクセス拒否されている場合の被疑箇所の特定(作成中)」を参照してください

通信が許可されていない場合、ルーティングは問題がなく、アクセス許可がされていないです
「アクセス拒否されている場合の被疑箇所の特定(作成中)」を参照してください

応答がない場合(タイムアウトする場合)は次項に記載の内容を実施してください

クライアントとサーバーのL3(ルーティング)の調査

クライアントもしくはサーバーでルーティングの確認をしてください

# ルーティングテーブルの確認
ip route show

# 出力例
# default via 192.0.2.1 dev ens192 proto static metric 100 
# 192.0.2.0/24 dev ens192 proto kernel scope link src 192.0.2.123 metric 100

出力の見方

「宛先のIPセグメント(defaultはすべての宛先)」 via 「中継ネットワーク機器のIPアドレス, 所謂デフォルトゲートウェイ/デフォゲ」 dev 「サーバーのインターフェース名」 proto static metric 100

クライアントからサーバー(逆向きも同様)

* 通信用の行は存在するか、登録されているか
* デフォゲのIPアドレスは正しいか
* インターフェース名は正しいか

を確認してください

これがおかしい場合はサーバー/クライアントの設定を修正してください
これが問題ない場合は次項に記載の内容を実施してください

クライアントとサーバーのL2の調査

デフォゲとの疎通が可能かを確認してください

# pingコマンドで確認、「192.0.2.1」を実際のIPアドレスへ置き換えてください
ping 192.0.2.1

まず、デフォゲのIPアドレスが正しいことを再確認してください
デフォゲとの疎通が問題ない場合は、「クライアントとサーバーの間のルーティング確認」を参照してください
デフォゲとの疎通に問題がある場合は次のコマンドで調査をしてください

# L2(VLAN等)が繋がっているかの確認
# ARPテーブルの確認
ip neigh show

# 出力例
# 192.0.2.200 dev ens192  FAILED
# 192.0.2.10 dev ens192 lladdr 00:53:00:00:00:00 STALE
# 192.0.2.15 dev ens192 lladdr 00:53:00:aa:aa:aa STALE
# 192.0.2.16 dev ens192 lladdr 00:53:00:12:34:56 STALE

FAILED以外の行として同一IPセグメントのサーバーのIP/MAC Addressが一つも表示されない場合はサーバーとネットワーク機器でIP帯 or VLAN番号が一致していない可能性が高いです

次のコマンドでサーバー側のインターフェースを情報を取得してください

# インターフェースのIPアドレスとMACアドレスなどを表示
ip address show

# 出力例
#(略)
#2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
#    link/ether 00:53:00:00:00:00 brd ff:ff:ff:ff:ff:ff
#    inet 192.0.2.10/24 brd 192.0.2.255 scope global noprefixroute dynamic eth0
#(略)

出力の見方

例の1行目が
2: 「インターフェース名」: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 「MTUサイズ」 qdisc mq state 「UP/DOWN、インターフェース上がっているか落ちているか」 group 「この辺は気にしなくてOK」
例の2行目が
    link/ether 「MACアドレス」 brd ff:ff:ff:ff:ff:ff
例の3行目が
    inet 「IPアドレス」 brd 「ブロードキャストアドレス」 scope 「この辺は気にしなくてOK」

下記の情報とともにネットワーク管理者へ「ip neigh showで同一IPセグメントのサーバー(ARPエントリー)が見えず、デフォゲとのping疎通もできない」という旨の調査依頼をしてください

必須
・問題となっているクライアントとサーバー名、位置情報等
・問題となっているクライアントとサーバーを接続しているスイッチ名とスイッチのインターフェース番号
・問題となっているクライアントとサーバーのIPアドレス
　「192.0.2.123/24」や「192.0.2.123 255.255.255.0」等
・デフォゲとして指定しているIPアドレス
　「192.0.2.1」等
・デフォゲの設定をしているサーバーのインターフェースのIPアドレスとMACアドレス
・ここまでで調査したコマンドと結果すべて

利用していれば必須
・問題となっているクライアントとサーバーのVLAN番号

あれば
・画面のスクショやログのコピー ※秘匿情報以外は加工せず生情報の方がベスト
・事象を確認した時間帯
　最低限、一時間単位で正確なものがありがたいです

既存のサーバーのIP/MAC Addressが表示されてる場合は
上記の情報とともにネットワーク管理者へ「ip neigh showで同一IPセグメントのサーバー(ARPエントリー)が見えるがデフォゲとのping疎通ができない」という旨の調査依頼をしてください

クライアントとサーバーの間のルーティング確認

宛先からのping応答がないがデフォゲからのping応答はある場合は

どの経路を通って通信しているかの情報を取得してください

# tracerouteコマンドで確認、「192.0.2.1」を実際のIPアドレスへ置き換えてください
# (少し時間がかかります)
traceroute -n 192.0.2.1

下記の情報とともにネットワーク管理者へ「サーバーからのping応答がないがデフォゲからのping応答はある」という旨の情報とともに調査依頼をしてください

必須
・問題となっているクライアントとサーバーのIPアドレス
　「192.0.2.123/24」や「192.0.2.123 255.255.255.0」等
・クライアントとサーバーがお互いにどの経路を通って通信しているかの情報
・ここまでで調査したコマンドと結果すべて

あれば
・画面のスクショやログのコピー ※秘匿情報以外は加工せず生情報の方がベスト
・事象を確認した時間帯
　最低限、一時間単位で正確なものがありがたいです