- - PR -
qmailで外部からのメールを受信できません。
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2003-03-12 15:48
お世話になります。いろいろ実験していろいろ調べてやっておるのですが、結果は以下のとおりです。
「外部」端末から #dig @219.x.x.2 mydomain.jp とやりましても応答はありません。。 #telnet 219.x.x.3 25 とやると応答できるようになりました。 応答できるようになった経緯はこうです。図の [ファイアーウォール]Redhat8.0 iptables ｜eth1:192.168.0.1 のマシンに適用しているiptables設定用のスクリプトを、windows上の秀丸でEUC（改行LF）で編集してのち、フロッピーでLinuxマシンに持っていって実行させておりました。 持っていった後の小さな変更はXwindow内でターミナルエミュレータで編集を行っておりました。 以前にもこの方法で移したスクリプトを正常に実行できなかったことが良くあり、ファイルを削除して全く同じ内容を書くと動いたりしておりました（パーミッションも全く同じです。）。 今回もどうもそのような感じです。なぜなら、もう一度同じ内容の別のスクリプトを作成して再適用すると、メールが、送信後数秒で受信できたからです。 しかしメールは送れたのに、外部からdigの反応がないのが不思議です。ファイアーウォール側で #tcpdump -i eth0:1 で待ち受けてみても外部からpingを通したときはしっかりモニタできるのに外部からdigしたときはモニタできたパケットは0件でした。つまり、tcpdumpの待ち受け状態から一切モニタの記録が表示されなかったのです。 なんとも不思議です。 また、5時間後や翌日に届いたメールのなぞは、どうも実験中に「おかし〜な〜・・・」といって、ファイアーウォールのFORWARDチェインを瞬間的に全てACCEPTにして実験したりしてましたので、その積み重ねでちょくちょく届いていたのではないかと推測しております。 依然、メールは届くがdigが通らないのは謎です。。 | ||||
|
投稿日時: 2003-03-12 16:22
お世話になります。
今、休憩して帰ってきてもう一度試すとまた駄目になっていました。 先ほどの発言から今までの間は休憩しかしておりませんので何も設定は変えておりません。 -------------------------------- #telnet 219.x.x.3 25 とやると応答できるようになりました。 -------------------------------- だったのですが、今はいっこうに応答がありませんし、もちろんメールも届いておりません。。 #tcpdump -i eth0:2 でtelnetをモニタしても何も表示されません。。 | ||||
|
投稿日時: 2003-03-12 16:33
こんにちは
# netstat -a | grep ":smtp" でどうなります？ smtp は「LISTEN」に成ってます？ それで、外から「telnet サーバ smtp」で「ESTABLISHED」になるでしょうか？ | ||||
|
投稿日時: 2003-03-12 17:14
お世話になっております。
メールサーバーで # netstat -a | grep ":smtp" をしたところ、LISTENになっております。 また、新たな現象が見えました。 外部端末（210.x.x.x）から、192.168.0.2 にpingを打ってみますと、replyが一件だけ帰ってきました。後はかえってきません、pingの結果は 23 packets transmitted, 1 recieved, 95% loss, time 22002ms となっておりました。 pingが一本しか帰って来ないというのはどういうことなのでしょうか。。 | ||||
|
投稿日時: 2003-03-13 13:38
症状も話もばらばらになってきましたので、とりあえず[ファイアーウォール]を別のハードで再セットアップしました。これでハードの疑いはないと思います。
ルータをインターネットから切り離して、ファイアーウォールを甘々にして純粋にnatでfowardingするだけにしました。 そして 219.x.x.14[動作確認端末]Redhat8.0 を下の位置に設置してテストしております。 --------------------------------- [インターネット] ｜ 一時切断 [ルータ]219.x.x.15 ｜ ＋---219.x.x.14[動作確認端末]Redhat8.0 ｜ ｜eth0 ／219.x.x.1 ｜eth0:1／219.x.x.2 → 192.168.0.2 へforward ｜eth0:2／219.x.x.3 → 192.168.0.3 へforward [ファイアーウォール]Redhat8.0 iptables ｜eth1:192.168.0.1 ｜ ＋---192.168.0.2[DNSサーバ]Redhat7.3 BIND9 ＋---192.168.0.3[メールサーバ]Redhat8.0 qmail＋tcpserver＋checkpassword ＋---・・・ ｜ ＋---192.168.0.100[win2000クライアント]OutlookExpress --------------------------------- こうした上で一旦話しを最初に戻しまして、もう一度動作の確認を順に行いました。 [動作確認端末]から #telnet 219.x.x.3 25 Trying 219.x.x.3... Connected to 219.x.x.3. Escape character is '^]'. 220 mxserver.mydomain.jp ESMTP メールサーバーへのSMTPは問題ないと思います。 [動作確認端末]から #dig mydomain.jp mx コネクション ダイムドアウト 上記2通りについてファイアーウォールでtcpdumpしましたが、SMTPはばっちりモニタできたのですが、dnsをモニタしてみると [動作確認端末側] #dig @219.x.x.2 mydomain.jp ・・・ ・・・ ;;connection timed out; no servers could be reached [ファイアーウォール] #tcpdump -i eth0:1 ・・・ 12:34:04.836260 219.x.x.2.32768 > 147.28.0.39.domain: 56567 [1au] A? BLACKHOLE-1.IANA.ORG. OPT UDPsize=2048 (49) (DF) 12:34:04.836409 219.x.x.2.32768 > 147.28.0.39.domain: 27760 [1au] A? BLACKHOLE-2.IANA.ORG. OPT UDPsize=2048 (49) (DF) 12:34:08.839330 219.x.x.2.32768 > 202.12.28.131.domain: 13880 [1au] A? BLACKHOLE-1.IANA.ORG. OPT UDPsize=2048 (49) (DF) 12:34:08.839490 219.x.x.2.32768 > 202.12.28.131.domain: 39708 [1au] A? BLACKHOLE-2.IANA.ORG. OPT UDPsize=2048 (49) (DF) 12:34:09.835652 arp who-has 219.x.x.15 tell 219.x.x.1 12:34:09.835918 arp reply 219.x.x.15 is-at xx:xx:xx:xx:xx:xx 12:34:09.837352 219.x.x.2.32776 > O□NのセカンダリDNSサーバー.domain: 12735+ PTR? 200.10.168.192.in-addr.arpa. (45) (DF) 12:34:12.294489 192.168.1.3.netbios-ns > 192.168.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 12:34:13.037572 192.168.1.3.netbios-ns > 192.168.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 12:34:13.788859 192.168.1.3.netbios-ns > 192.168.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 12:34:16.841676 219.x.x.2.32768 > 192.0.34.43.domain: 19854 [1au] A? BLACKHOLE-1.IANA.ORG. OPT UDPsize=2048 (49) (DF) 12:34:16.841829 219.x.x.2.32768 > 192.0.34.43.domain: 9927 [1au] A? BLACKHOLE-2.IANA.ORG. OPT UDPsize=2048 (49) (DF) 12:34:19.841583 219.x.x.2.32776 > O□NのセカンダリDNSサーバー.domain: 12735+ PTR? 200.10.168.192.in-addr.arpa. (45) (DF) 12:34:24.563906 192.168.1.3.netbios-ns > 192.168.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 12:34:24.845954 219.x.x.2.32768 > 193.0.0.193.domain: 12065 A? BLACKHOLE-1.IANA.ORG. (38) (DF) 12:34:24.846106 219.x.x.2.32768 > 193.0.0.193.domain: 6384 A? BLACKHOLE-2.IANA.ORG. (38) (DF) 12:34:25.308525 192.168.1.3.netbios-ns > 192.168.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 12:34:26.059793 192.168.1.3.netbios-ns > 192.168.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 12:34:32.848333 219.x.x.2.32768 > 203.37.255.97.domain: 35960 A? BLACKHOLE-1.IANA.ORG. (38) (DF) 12:34:32.848487 219.x.x.2.32768 > 203.37.255.97.domain: 50748 A? BLACKHOLE-2.IANA.ORG. (38) (DF) ・・・ ※実アドレス表示のIPは身に覚えのないアドレスです。 となっています。[動作確認端末]から #telnet 219.x.x.3 25 した結果はまったくモニタできていなくて、BLACKHOLE-何とか がたくさん表示されていて気味が悪いです。 最後に 192.168.0.2[DNSサーバ]Redhat7.3 でnetstatしてみると # netstat -a | grep "  omain"
tcp 0 0 192.168.0.2:domain *:* LISTEN tcp 0 0 dnsserver:domain *:* LISTEN udp 0 0 192.168.0.2:domain *:* udp 0 0 dnsserver:domain *:* となっていてudpをLISTENしていないようなのです。。 [ メッセージ編集済み 編集者: okumura 編集日時 2003-03-13 13:47 ] [ メッセージ編集済み 編集者: okumura 編集日時 2003-03-14 18:19 ] | ||||
|
投稿日時: 2003-03-14 18:11
こんにちは、ふじいです。
すみません。まちがってました。 53番、つまりDNSのやりとりは tcpdump -i eth0:1 |grep dns ではなく tcpdump -i eth0:1 |grep domain ですね。すみません。要は/etc/servicesの左の項をみてください。 -n をやると53を含むすべてのポートを拾ってしまうので、お勧めできないんですよ。 さて、本題ですが、 #tcpdump -i eth0:1 ・・・ 12:34:04.836260 219.x.x.2.32768 > 147.28.0.39.domain: 56567 [1au] A? BLACKHOLE-1.IANA.ORG. OPT UDPsize=2048 (49) (DF) 12:34:04.836409 219.x.x.2.32768 > 147.28.0.39.domain: 27760 [1au] A? BLACKHOLE-2.IANA.ORG. OPT UDPsize=2048 (49) (DF) 12:34:08.839330 219.x.x.2.32768 > 202.12.28.131.domain: 13880 [1au] A? BLACKHOLE-1.IANA.ORG. OPT UDPsize=2048 (49) (DF) 12:34:08.839490 219.x.x.2.32768 > 202.12.28.131.domain: 39708 [1au] A? BLACKHOLE-2.IANA.ORG. OPT UDPsize=2048 (49) (DF) これは、上位のDNSに問い合わせているけど、応答をiptablesが弾いているから、応答パケットがかえってこないっぽいです。 これが通過するチェインがあるか確認してください。 12:34:09.835652 arp who-has 219.x.x.15 tell 219.x.x.1 12:34:09.835918 arp reply 219.x.x.15 is-at xx.xx.xx.xx.xx.xx.xx? これはARPなので、しかも正しくMACアドレスとれてます。今度からはMACアドレスも伏せ字にしてください。 12:34:09.837352 219.x.x.2.32776 > O□NのセカンダリDNSサーバー.domain: 12735+ PTR? 200.10.168.192.in-addr.arpa. (45) (DF) 問い合わせてます。返事がなさそう・・・・。 12:34:12.294489 192.168.1.3.netbios-ns > 192.168.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 12:34:13.037572 192.168.1.3.netbios-ns > 192.168.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 12:34:13.788859 192.168.1.3.netbios-ns > 192.168.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 内部のWindowsマシンがnetBiosの名前解決をブロードキャストして聞いています。今回は関係なし。 以下、同様と思われます。 12:34:16.841676 219.x.x.2.32768 > 192.0.34.43.domain: 19854 [1au] A? BLACKHOLE-1.IANA.ORG. OPT UDPsize=2048 (49) (DF) 12:34:16.841829 219.x.x.2.32768 > 192.0.34.43.domain: 9927 [1au] A? BLACKHOLE-2.IANA.ORG. OPT UDPsize=2048 (49) (DF) 12:34:19.841583 219.x.x.2.32776 > O□NのセカンダリDNSサーバー.domain: 12735+ PTR? 200.10.168.192.in-addr.arpa. (45) (DF) 12:34:24.563906 192.168.1.3.netbios-ns > 192.168.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 12:34:24.845954 219.x.x.2.32768 > 193.0.0.193.domain: 12065 A? BLACKHOLE-1.IANA.ORG. (38) (DF) 12:34:24.846106 219.x.x.2.32768 > 193.0.0.193.domain: 6384 A? BLACKHOLE-2.IANA.ORG. (38) (DF) 12:34:25.308525 192.168.1.3.netbios-ns > 192.168.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 12:34:26.059793 192.168.1.3.netbios-ns > 192.168.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 12:34:32.848333 219.x.x.2.32768 > 203.37.255.97.domain: 35960 A? BLACKHOLE-1.IANA.ORG. (38) (DF) 12:34:32.848487 219.x.x.2.32768 > 203.37.255.97.domain: 50748 A? BLACKHOLE-2.IANA.ORG. (38) (DF) ・・・ つまり、UDPで、 src__sport____dist__dport *____*________自分__53 自分_53_______*_____* *____53_______自分__* 自分_*________*_____53 この辺の組み合わせを許可して、iptables -L -v してみて、使用していないチェインがあったら消してみてください。 僕はちょっと変な書き方してるので、このような書き方はしてないですが、DNSを通信ができてないっぽいです。確認してみてください。 [ メッセージ編集済み 編集者: ふじい 編集日時 2003-03-14 19:06 ] | ||||
|
投稿日時: 2003-03-14 18:38
お世話になります。ふじい様のレスは見ているだけで本当に勉強になります。ありがとうござます。
おっしゃる順序で問題を追っていくと解決できました。 原因は 219.x.x.14[動作確認端末] 自体にiptablesの設定を施しておりましたことを忘れていたことにありました。本当にお騒がせいたしました。しかしこれをきっかけにtcpdumpなど、色々調べる機会をいただきまして本当に勉強になりました。 別件ですが、 12:34:12.294489 192.168.1.3.netbios-ns > 192.168.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST に関してなんですが、うちのネットワークには 192.168.1.0/24 というネットワークはございませんし、192.168.1.3 もpingを打っても帰ってきませんし身に覚えがありません。。いったいどこからARPが飛んできているのでしょうか。。 ちなみに netbios-ns の 「ns」は何かのnetbios名でしょうか、一応別の192.168.10.0/24 のセグメントに ns というnetbios名のサーバーは確かに存在するのですが。。 | ||||
|
投稿日時: 2003-03-14 19:17
こんにちは、ふじいです。
基本的にtcpdumpでデバッグ時に使いそうなパターンは tcpdump -i ethx | grep sevice_name | grep -v いらない文字列 くらいで足りると思います。 僕は、わけがわからなくなったら、一度ルールをフラッシュして、 tcpdump -i ethx | grep sevice_name | grep -v いらない文字列 > ok.log ルールを有効にして tcpdump -i ethx | grep sevice_name | grep -v いらない文字列 > bad.log diff ok.log bad.log とかやってますね。
$ cat /etc/services | grep netbios netbios-ns 137/tcp # NETBIOS Name Service netbios-ns 137/udp netbios-dgm 138/tcp # NETBIOS Datagram Service netbios-dgm 138/udp netbios-ssn 139/tcp # NETBIOS session service netbios-ssn 139/udp とあるように、netbios-nsはsambaのnmbに対して、windowsクライアントが名前の解決をするためのプロトコルです。 思想の違いだと納得してますが、windowsクライアントはブロードキャストに問い合わせます。なので、windowsクライアントの数だけこのパケットを投げるので、ネットワーク管理者はnetbiosは大嫌いです。うるさいんですよ。（笑 つまりnmbはそれをひろって、名前を返すわけです。 で、なんで、192.168.1.0/24の問い合わせが来るのかというと、予想でしかないのですが、okumuraさんのルーターの上には正確にはインターネットではなく、プロバイダーのルーターがあります。その下にokumuraさんだけではなく、ほかのお客さんもぶらさがってるはず。 つまりコリジョンドメインにokumuraさん以外のマシンが何台かあって、その中のへぼい管理者が、ローカルな192.168.0.0/16のパケットを外側に出さないような設定をしていないから、漏れでていると推測されます。あくまでも推測ですが。 [ メッセージ編集済み 編集者: ふじい 編集日時 2003-03-14 19:24 ] | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。