続・○○パケットを投げたのは誰だ?

以前投稿した「リセットパケットを投げたのは誰だ?はリセットパケットに主眼を置いているため、うまく活用できない人もいるのではないか?と思っていた矢先、ネットワーク構築作業で似たような状況にまたまた遭遇して、いい加減頭に来たので改めて書きます。

スポンサーリンク
スポンサーリンク

状況

クライアント端末から通信テストをすると「Pingは通る」「でもHulftが通らない(応答がない)」。FWを経由しているのでFWのログを見ると、ログ上では当該通信を許可しているので問題はない。Pingは通っているからルーティングの問題はないですね。Hulftの設定ミスかサーバー側の問題だろうと予想はしていたけれど、ぼくは担当ではないので待つのみ。結局、サーバー担当には原因が分からず1時間経過。

不審なICMPパケット

余りにヒマなのでクライアント端末の前でバタバタしている人の肩越しに画面を覗くとtcpdumpを動かしているじゃないですか。で、Pingの送受信に混じって表示されていたのがコレ。

ICMP host xxx.xxx.xxx.xxx unreachable – admin prohibited

これiptablesでrejectされた時の応答ですよね…どうしてみんな無視しているの?

ぼく「サーバーでiptables動かしていませんか?原因はたぶんiptablesですよ」
サーバー担当「いえ、iptablesは動いていないはずです」

「はず」って何だよ?確認しろよ〜と思いつつ、tcpdumpを停止させて「-v」オプションを付けて再実行。「-v」オプションを付けるとIPヘッダのTTLを表示してくれます。

万が一、途中の中継機器が悪さしていればPing応答時のTTLとICMP(unreachable)のTTLは異なるはずです。TTLが一致すればサーバーのiptablesで決まりです。

PingとHulft通信の再実施をお願いすると、予想通りPing応答時とICMP(unreachable)のTTLが一致。明らかにサーバーでiptablesが動いていて、Hulft通信をrejectしています。

説得は楽じゃない

ぼくはこれで解決したと思っていたのですが、結局サーバー担当がiptablesの確認をしたのは、その1時間後でした。理由はぼくが言っている意味、TTLが一致するという事がどういう事なのかまったく理解できていないのと、頑なにiptablesは動いていないと信じ込んでいたためです。もうちょっと身軽に、どうせ1分で出来るのだからiptablesのチェックくらいして欲しいですね。

こういうケースは、対顧客の場合もあるでしょうから、あまり難しい言葉は使わずに上手く説明できるようにするのが、ぼくの今後の課題です。

まとめ

最終的にはiptablesに加えてHulftの設定も間違っていたというオチで、さすがにズッコケて笑ってしまいました。

ぼくがお伝えしたいのは、送信元が中継器なのか?そうではないのか?の判断材料にTTLは使えるよ、という事です。リセットパケットやICMPだけじゃなくて、すべてのパケットについてです。

ただtcpdumpを実行してパケットが到着しているとか、していない、なんて言っているのはパケット解析なんかじゃないんです。

スポンサーリンク
スポンサーリンク
スポンサーリンク

フォローする