インターネットのどっかのサーバから社内LANのDMZ領域にある
外向きDNSサーバに向かって、何やらtcpで接続中断してるよ。
ってエラーログを頻繁に吐いてる(´・ω・｀)
と、そのDNSサーバの/var/log/messagesのerror文を監視してるスクリプトから報告があったので、
一応調べてみる事に。
このサーバではbindではDNS固有のログを記録せず、全部/var/log/messagesに吐くように設定して
あるので、 （どういう意図か知らんけど。普通そうなの？笑）
cat /var/log/messages | grep named | grep 当該時間
とかで、エラー吐いた時間あたりのログを見てみる。
すると、
月 日 時:分:秒 [サーバ名] named[pid]: dispatch: error: dispatch XxXXXXXXXX: shutting down due to TCP receive error: connection reset
なんじゃこりゃ(´・ω・｀)
色々調べてみたり、ベンダーに聞いてみたりしたんだけど、
『TCPの接続に失敗したから、中断したよん。』ぐらいの事しかわからない。
ベンダー曰く、ネットワークにしろ相手側のサーバにしろ、考えられる原因が多岐に渡り、
切り分けは難しいだろうとの事。 まぁそうだろうね・・・
もちろん、自分のトコのDNSサーバの設定に不備が無い事が前提で。
いやいや、そこが一番不安なんだけどさｗｗｗｗｗ
とまぁそんな事を上司に報告したら、
『とりあえず再発なければ様子見でいいけど、接続してきてる相手先だけは特定しておこう』
ってんで、当該DNSサーバのNICの53番ポートへの接続に対してtcpdumpを仕掛けておく事に。
# tcpdump dst port 53 -w [filename] &
（53番のプロトコル（DNS）使ってる通信をfilenameに記録してね。あと動かしっ放しにするからバックグラウンドでね。）
んー、こんなんでいいかにゃーと思ってしばらく放置。
一時間後。
とりあえず仕掛けたtcpdumpが正常にfileに記録されてるかなーと様子を見に行ったら、
ファイルがあるものの、容量が0バイト・・・
アルェー？(´・３・)
しょうがないからmanページを見て試行錯誤。
どうも、tcpdumpは
『オプションでインターフェースを指定しなかった場合、
有効設定になっているインターフェイスのうち、
一番最初のインターフェイスのみdumpを取得する』
っていう仕様になっているらしい。
ほほー
どれどれ。。。
# ifconfig -a
eth 0 がなんたら
eth 1 がかんたら
bond 0 がどうたらこうたら
・・・このサーバはNIC2枚でbondingしており、2つの物理IPアドレスを、
バーチャルIP1つでまとめてあるようです。
ふんふん
つまり、インターフェイスを指定してないから、どうやらeth0のdumpを取ろうとしちゃってたみたいだ。
bondingしてるって事は、このサーバ宛ての通信はバーチャルIPに向かって来てるわけだから、、、
tcpdump dst port 53 -i bond0 -w [filename] &
（bond0のインターフェースの、53番ポートに向かってくるTCPの通信を取得してfilenameに書き込んでね。
このプロセスはバックグラウンドでやってね）
としたら、おお、ちゃんと取れてる！！(*´Д｀*)
晴れてtcpdumpを仕掛ける事に成功したわけですが、
数日間に渡ってあんなに頻繁に吐いてたエラーが
tcpdumpを仕掛けた途端にピタリと起こらなくなり、
結局、相手先のサーバを突き止める事は出来ませんでした
ってオチなんですけどね(´∀｀)ｱﾊﾊﾝ
へぇーと思ったらポチっとお願いします（ ´∀｀）つ →
