リセットパケットを投げたのは誰だ?は現場で活用できるの?

以前投稿した「リセットパケットを投げたのは誰だ?はなかなか評判が良いのですが、本当に現場で使えるの?って疑問に感じる人は少なからずいらっしゃるのではないかと思います。

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

遭遇した状況

クライアント端末から通信テストをすると「Pingは通る」「でもHulftが通らない(応答がない)」という事態が発生しました。

ぼくはFW担当でした。FWのログを見たところ、通信を許可しているので問題はない。Pingは通っているからルーティングの問題でもないでしょう。

Hulftの設定ミスかサーバー側の問題だろうと予想はしていたけれど、ぼくは担当ではないので待つのみ。結局、サーバー担当には原因が分からず1時間経過。

不審なICMPパケット

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

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

ぼく「サーバーで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時間後でした。

理由は、頑なにiptablesは動いていないと信じ込んでいたためです。どうせ1分で出来るのだからiptablesのチェックくらいして欲しいですね。

TTL云々はサーバーしか分からない人に言ってもなかなか伝わりません。というか無理ですね。

まとめ

パケットが到着している、していない、なんて言っているのはパケット解析なんかじゃないんですよ。

最初の、現場で活用できるの?って話ですが活用できます。でも理解させるのは相手がネットワークエンジニアでも期待しない方が良いかと思います。

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