新規構築したネットワークが接続できない。自社ネットワークの問題か？顧客ネットワークの問題か？
先日、そんなネットワークトラブルの調査依頼を受ける機会がありました。なかなか興味深いケースでしたので皆さんにご紹介しようと思います。
皆さんの参考になれば幸いです。
戻り通信が届かない
通信要件は顧客拠点から自社ネットワーク内のサーバーへのTCP接続です。仮に65000/tcpへ接続するとしましょう。そしてネットワーク構成はとても単純です。
簡単に説明すると次のようなネットワークです。
顧客が通信テストを実施したところサーバーからの応答がないという連絡がありました。
原因究明のため自社のエンジニアAさんがサーバーでパケットキャプチャを実施したところ、顧客拠点からサーバーへの接続要求が届いていてサーバーもそれに応答している事が確認できました。
そこまで分かったのですが原因究明に至らず、わたしに調査依頼が来たというわけです。
調査開始
エンジニアAさんからネットワーク構成とルーターのコンフィグ、サーバーでのパケットキャプチャの結果を連携してもらい調査を開始しました。
パケットキャプチャの結果を調査する
エンジニアAさんから連携されたパケットキャプチャの結果を見てみます。長くて見辛いのでサッと目を通すだけで大丈夫です。
[root@server ~]# tcpdump -vv -nn port 65000
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
13:30:40.865646 IP (tos 0x0, ttl 62, id 48237, offset 0, flags [DF], proto TCP (6), length 60)
172.16.1.1.56192 > 172.16.3.1.65000: Flags [S], cksum 0xe561 (correct), seq 4211154411, win 29200, options [mss 1460,sackOK,TS val 9347462 ecr 0,nop,wscale 7], length 0
13:30:40.865675 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
172.16.3.1.65000 > 172.16.1.1.56192: Flags [S.], cksum 0x5c51 (incorrect -> 0xe164), seq 4050531875, ack 4211154412, win 28960, options [mss 1460,sackOK,TS val 11721879 ecr 9347462,nop,wscale 7], length 0
13:30:41.867065 IP (tos 0x0, ttl 62, id 48238, offset 0, flags [DF], proto TCP (6), length 60)
172.16.1.1.56192 > 172.16.3.1.65000: Flags [S], cksum 0xe177 (correct), seq 4211154411, win 29200, options [mss 1460,sackOK,TS val 9348464 ecr 0,nop,wscale 7], length 0
13:30:41.867100 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
172.16.3.1.65000 > 172.16.1.1.56192: Flags [S.], cksum 0x5c51 (incorrect -> 0x16f9), seq 4066179020, ack 4211154412, win 28960, options [mss 1460,sackOK,TS val 11722881 ecr 9348464,nop,wscale 7], length 0
13:30:43.871390 IP (tos 0x0, ttl 62, id 48239, offset 0, flags [DF], proto TCP (6), length 60)
172.16.1.1.56192 > 172.16.3.1.65000: Flags [S], cksum 0xd9a3 (correct), seq 4211154411, win 29200, options [mss 1460,sackOK,TS val 9350468 ecr 0,nop,wscale 7], length 0
13:30:43.871417 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
172.16.3.1.65000 > 172.16.1.1.56192: Flags [S.], cksum 0x5c51 (incorrect -> 0x26f3), seq 4097496652, ack 4211154412, win 28960, options [mss 1460,sackOK,TS val 11724885 ecr 9350468,nop,wscale 7], length 0
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel
[root@server ~]#キャプチャ結果を見ると確かに「172.16.1.1」から「172.16.3.1」へ接続要求が来ていて、「172.16.3.1」から「172.16.1.1」へ応答しています。
念のためTCP接続について説明すると、TCPは3ステップハンドシェイク（3ウェイハンドシェイク）という手順で接続を完了します。
今回のネットワークトラブルはSYN+ACKの応答パケットがどこかで失われており、そのためTCP接続が完了していません。
サーバーは正常に応答していますから自社のルーターか顧客側ネットワークのどこかで問題が発生しているはずです。
そこでわたしは自社のルーターにリモートログインして調査しました。
結果からいうと自社のルーターの設定には問題ありませんでした。ルーティングもACLも問題なし。
この時点で顧客側の問題である可能性が極めて高いのですが、確証がないと顧客に調査を依頼できないという悲しい立場だそうなので、わたしは作業を継続する亊にしました。
アプローチを変える
戻りパケットがどこかで失われている事は確実です。そこでサーバーから顧客ネットワークに対してtracerouteを実行してみました。
[root@server ~]# traceroute -n 172.16.1.1
traceroute to 172.16.1.1 (172.16.1.1), 30 hops max, 60 byte packets
1 172.16.3.254 0.182 ms 0.130 ms 0.141 ms
2 172.16.2.1 0.426 ms 0.430 ms 0.408 ms
3 172.16.2.1 0.397 ms !X 0.382 ms !X 0.363 ms !X
[root@server ~]#興味深い表示がありますね。
3 172.16.2.1 0.397 ms !X 0.382 ms !X 0.363 ms !X「!X」が表示されています。「!X」は通信が拒否されICMPエラーが返送された際に表示されるもので、ネットワーク機器のACLやLinuxのiptablesのようなものでrejectされた際によく見かけます。
今回は戻り通信が失われているのだからサーバー発信の通信テストなんて意味ないのでは？という意見がエンジニアBさんから出てきたのですが、そんな事はありません。
tracerouteによって次の3点が分かりました。
- サーバーから顧客ルーターまで到達できる
- 顧客ルーターでACLを設定している
- 顧客ルーターはACLに引っかかるとICMPエラーを返す設定になっている
勘の良い方であればピンときたかも知れません。
そうです。エンジニアAさんから連携されたパケットキャプチャの結果は不完全な可能性があります。
もう一度、自分の手でパケットキャプチャを実行してみましょう。
自分の手でパケットキャプチャを実行する
もうお気づきだと思いますが、もしも顧客ルーターのACLに引っかかって戻り通信が失われているのであれば、顧客ルーターからICMPエラーが送信されてくるはずです。
試してみましょう。
[root@server ~]# tcpdump -vv -nn port 65000 or icmp
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
13:31:31.801865 IP (tos 0x0, ttl 62, id 45994, offset 0, flags [DF], proto TCP (6), length 60)
172.16.1.1.56194 > 172.16.3.1.65000: Flags [S], cksum 0x385f (correct), seq 589224919, win 29200, options [mss 1460,sackOK,TS val 9398397 ecr 0,nop,wscale 7], length 0
13:31:31.801906 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
172.16.3.1.65000 > 172.16.1.1.56194: Flags [S.], cksum 0x5c51 (incorrect -> 0x2240), seq 3238834606, ack 589224920, win 28960, options [mss 1460,sackOK,TS val 11772815 ecr 9398397,nop,wscale 7], length 0
13:31:31.802217 IP (tos 0xc0, ttl 63, id 58700, offset 0, flags [none], proto ICMP (1), length 88)
172.16.2.1 > 172.16.3.1: ICMP host 172.16.1.1 unreachable – admin prohibited, length 68
IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto TCP (6), length 60)
172.16.3.1.65000 > 172.16.1.1.56194: Flags [S.], cksum 0x2240 (correct), seq 3238834606, ack 589224920, win 28960, options [mss 1460,sackOK,TS val 11772815 ecr 9398397,nop,wscale 7], length 0
13:31:32.804825 IP (tos 0x0, ttl 62, id 45995, offset 0, flags [DF], proto TCP (6), length 60)
172.16.1.1.56194 > 172.16.3.1.65000: Flags [S], cksum 0x3472 (correct), seq 589224919, win 29200, options [mss 1460,sackOK,TS val 9399402 ecr 0,nop,wscale 7], length 0
13:31:32.804852 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
172.16.3.1.65000 > 172.16.1.1.56194: Flags [S.], cksum 0x5c51 (incorrect -> 0xfa43), seq 3254505699, ack 589224920, win 28960, options [mss 1460,sackOK,TS val 11773818 ecr 9399402,nop,wscale 7], length 0
13:31:32.805095 IP (tos 0xc0, ttl 63, id 59440, offset 0, flags [none], proto ICMP (1), length 88)
172.16.2.1 > 172.16.3.1: ICMP host 172.16.1.1 unreachable – admin prohibited, length 68
IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto TCP (6), length 60)
172.16.3.1.65000 > 172.16.1.1.56194: Flags [S.], cksum 0xfa43 (correct), seq 3254505699, ack 589224920, win 28960, options [mss 1460,sackOK,TS val 11773818 ecr 9399402,nop,wscale 7], length 0
13:31:34.814041 IP (tos 0x0, ttl 62, id 45996, offset 0, flags [DF], proto TCP (6), length 60)
172.16.1.1.56194 > 172.16.3.1.65000: Flags [S], cksum 0x2c99 (correct), seq 589224919, win 29200, options [mss 1460,sackOK,TS val 9401411 ecr 0,nop,wscale 7], length 0
13:31:34.814074 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
172.16.3.1.65000 > 172.16.1.1.56194: Flags [S.], cksum 0x5c51 (incorrect -> 0xdf8b), seq 3285899785, ack 589224920, win 28960, options [mss 1460,sackOK,TS val 11775828 ecr 9401411,nop,wscale 7], length 0
13:31:34.814261 IP (tos 0xc0, ttl 63, id 61174, offset 0, flags [none], proto ICMP (1), length 88)
172.16.2.1 > 172.16.3.1: ICMP host 172.16.1.1 unreachable – admin prohibited, length 68
IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto TCP (6), length 60)
172.16.3.1.65000 > 172.16.1.1.56194: Flags [S.], cksum 0xdf8b (correct), seq 3285899785, ack 589224920, win 28960, options [mss 1460,sackOK,TS val 11775828 ecr 9401411,nop,wscale 7], length 0
^C
9 packets captured
9 packets received by filter
0 packets dropped by kernel
[root@server ~]#ビンゴ！顧客ルーターからICMPエラーが送信されています。見づらいので必要な個所だけ抜き出しましょう。
①接続要求送信
これは顧客側からサーバーへのTCP接続要求（SYN）の送信です。
IP (tos 0x0, ttl 62, id 45994, offset 0, flags [DF], proto TCP (6), length 60)
172.16.1.1.56194 > 172.16.3.1.65000: Flags [S], cksum 0x385f (correct), seq 589224919, win 29200, options [mss 1460,sackOK,TS val 9398397 ecr 0,nop,wscale 7], length 0②確認応答送信
これはサーバーからの確認応答（SYN+ACK）です。
IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
172.16.3.1.65000 > 172.16.1.1.56194: Flags [S.], cksum 0x5c51 (incorrect -> 0x2240), seq 3238834606, ack 589224920, win 28960, options [mss 1460,sackOK,TS val 11772815 ecr 9398397,nop,wscale 7], length 0③ICMPエラー
これが問題のICMPエラーです。
IP (tos 0xc0, ttl 63, id 58700, offset 0, flags [none], proto ICMP (1), length 88)
172.16.2.1 > 172.16.3.1: ICMP host 172.16.1.1 unreachable – admin prohibited, length 68
IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto TCP (6), length 60)
172.16.3.1.65000 > 172.16.1.1.56194: Flags [S.], cksum 0x2240 (correct), seq 3238834606, ack 589224920, win 28960, options [mss 1460,sackOK,TS val 11772815 ecr 9398397,nop,wscale 7], length 0説明のためマーキングしました。青色のアンダーラインを引いた個所は顧客側のルーターからサーバーに対してICMPエラーが送信された事を示しています。
次に赤色のアンダーラインを引いた個所は通信エラーとなったパケットです。②の通信と比較してください。同じですよね？つまり②の通信を顧客側のルーターがACLでrejectしてサーバーへICMPエラーを送信している事が分かります。
ICMPエラーとは
せっかくの機会ですから今回のICMPエラーについて簡単に解説します。
ICMPというとPingを連想する方が多いかと思いますが、ICMPは通信エラーの通知や情報を送信するために利用されるプロトコルです。
今回のICMPエラーはコード3、タイプ10です。具体的なパケット構造などは以下の記事をご覧ください。
このICMPエラーはエラーの元となったパケットを添付して返送してくれるという、とても気の利いたものです。これによって具体的にどの通信がエラーとなったのか分かります。
また、添付されているIPヘッダーのTTL値を見ると何ホップ先まで通信が届いているのか分かります。
IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto TCP (6), length 60)今回の例ではTTLは「62」でした。
あれ？と思った方がいらっしゃるかも知れません。
顧客ルーターへ到達した時点でTTLは63のはずですよね。であればTTLが63のパケットが添付されているはずです。
どうして63でなく62なのかというと、rejectされたのは顧客ルーターでルーティングされたときだからです。
つまり顧客側のルーターがTTLを63から62に減らしてルーティングする際にACLでrejectされたというわけです。
まとめ
今回の教訓として、TCP通信でトラブルが発生しているからといってパケットキャプチャの対象を絞り過ぎると原因に辿り着く事が難しくなる事が分かって頂けたかと思います。
パケットキャプチャする際は可能な限りすべての通信を記録するようにしましょう。
また、ICMPに関する知識も必要です。ICMPエラーはTCP/IPの基本中の基本です。ネットワークに携わる方であれば最低でも「マスタリングTCP/IP―入門編」を精読しておくと必ず役に立つはずです。
