- PR -

内部からメール、DNSがうまく動きません。。。。

1
投稿者投稿内容
のり
ベテラン
会議室デビュー日: 2006/04/07
投稿数: 61
投稿日時: 2006-04-21 00:16
こんばんは!

以前Linuxルータを作成した際には皆様にお世話なりました。

その後、外部からのWebサーバへのアクセスや、
内部からのインターネットアクセスも問題なくできています。

しかし、内部からメールサーバへメールがとれない状態と、
Webサーバをバーチャルホストで使用しているため、内部からもドメインで
アクセスしたく、DNSをたてたのですが、うまく動きません。

メールサーバですが、アクセスして ~/Maildir/new を見たところ、
どんどんたまっているので、外部からはメールが来ていると思います。

DNSに関しましては、http://fedorasrv.com/bind-lan.shtml などを
参考にして、設定しているのですが、名前では全く引けません・・・。

以前のブロードバンドルータでは、特に意識せずできていたのですが、
恐らくルータ内部で色々動いていたからだと思います。

今回、Linuxルータを作成したから、このような事態になったとおもうですが、
私がやっていてはうまくいかず・・・・。

ご教授、ご指摘頂けましたら幸いですm(_ _)m。。。

ネットワーク環境と、
長くなりますが、現在ルータに使用しているスクリプトを掲載させて頂きます。
よろしくお願い致します。

*環境*
eth0 - PPPoE
eth1 - DMZ(サーバ公開) 192.168.10.1/24
eth2 - LAN(ローカル) 192.168.1.1/24

*スクリプト*

#!/bin/sh

IPTABLES="/sbin/iptables"

# ルールをクリア
$IPTABLES -F
$IPTABLES -t nat -F

###################################################
#
# INPUT:入ってくるパケット
# FORWARD:転送パケット
# OUTPUT:出て行くパケット
#
##################################################

# 原則破棄
$IPTABLES -P INPUT DROP

# 原則許可
$IPTABLES -P FORWARD ACCEPT
$IPTABLES -P OUTPUT ACCEPT

####################################################
#
# INPUT
#
####################################################

# SSHサーバへのアクセスを許可
$IPTABLES -A INPUT -p tcp --dport 22 -j ACCEPT

# WEBサーバへのアクセスを許可
$IPTABLES -A INPUT -p tcp --dport 80 -j ACCEPT

# SMTPサーバへのアクセスを許可
$IPTABLES -A INPUT -p tcp --dport 25 -j ACCEPT

# POPサーバへのアクセスを許可
$IPTABLES -A INPUT -p tcp --dport 110 -j ACCEPT

# SSLのアクセスを許可
$IPTABLES -A INPUT -p tcp --dport 443 -j ACCEPT

# 外部からDNSサーバへのアクセスを許可
$IPTABLES -A INPUT -p tcp --dport 53 -j ACCEPT
$IPTABLES -A INPUT -p udp --dport 53 -j ACCEPT

# 自端末からのアクセスを許可
$IPTABLES -A INPUT -i lo -j ACCEPT

# LAN内の他端末からのアクセスを許可
$IPTABLES -A INPUT -i eth0 -s 192.168.10.0/24 -j ACCEPT
$IPTABLES -A INPUT -i eth0 -s 192.168.1.0/24 -j ACCEPT

#接続が確立したパケットの応答は許可
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

####################################################################
#
# FORWARD
#
####################################################################

# 宛先ポート135,137?139,445のパケットを破棄
$IPTABLES -A FORWARD -p tcp --dport 135 -j DROP
$IPTABLES -A FORWARD -p udp --dport 135 -j DROP
#$IPTABLES -A FORWARD -p tcp --dport 137:139 -j DROP
$IPTABLES -A FORWARD -p udp --dport 137:139 -j DROP
$IPTABLES -A FORWARD -p tcp --dport 445 -j DROP
$IPTABLES -A FORWARD -p udp --dport 445 -j DROP

# パスMTU問題対策
$IPTABLES -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

##########################################################################
#
# LANから外に出て行くパケットの送信元IPを書き換える
#
##########################################################################

$IPTABLES -t nat -A POSTROUTING -o ppp0 -s 192.168.10.0/24 -j MASQUERADE
$IPTABLES -t nat -A POSTROUTING -o ppp0 -s 192.168.1.0/24 -j MASQUERADE

#######################################################################
#
# OUTPUT
# サーバ機で生成されたパケットに対するチェイン
#
#######################################################################

# 宛先ポート135,137?139,445のパケットを破棄
$IPTABLES -A OUTPUT -o ppp0 -p tcp --dport 135 -j DROP
$IPTABLES -A OUTPUT -o ppp0 -p udp --dport 135 -j DROP
$IPTABLES -A OUTPUT -o ppp0 -p tcp --dport 137:139 -j DROP
$IPTABLES -A OUTPUT -o ppp0 -p udp --dport 137:139 -j DROP
$IPTABLES -A OUTPUT -o ppp0 -p tcp --dport 445 -j DROP
$IPTABLES -A OUTPUT -o ppp0 -p udp --dport 445 -j DROP

#######################################################################
#
# 静的NAT
#
########################################################################

$IPTABLES -t nat -A PREROUTING -i ppp0 -p tcp --dport 22 -j DNAT --to 192.168.10.10
$IPTABLES -t nat -A PREROUTING -i ppp0 -p tcp --dport 80 -j DNAT --to 192.168.10.100
$IPTABLES -t nat -A PREROUTING -i ppp0 -p tcp --dport 25 -j DNAT --to 192.168.10.110
$IPTABLES -t nat -A PREROUTING -i ppp0 -p tcp --dport 110 -j DNAT --to 192.168.10.110
$IPTABLES -t nat -A PREROUTING -i ppp0 -p tcp --dport 443 -j DNAT --to 192.168.10.50
$IPTABLES -t nat -A PREROUTING -i ppp0 -p tcp --dport 53 -j DNAT --to 192.168.10.130
$IPTABLES -t nat -A PREROUTING -i ppp0 -p udp --dport 53 -j DNAT --to 192.168.10.130


$IPTABLES -t nat -A PREROUTING -i eth1 -p tcp --dport 110 -j DNAT --to 192.168.10.110



kaz
ぬし
会議室デビュー日: 2003/11/06
投稿数: 5403
投稿日時: 2006-04-21 07:39
引用:

のりさんの書き込み (2006-04-21 00:16) より:

しかし、内部からメールサーバへメールがとれない状態と、
Webサーバをバーチャルホストで使用しているため、内部からもドメインで
アクセスしたく、DNSをたてたのですが、うまく動きません。


まず環境をちゃんと記載するようにしないと,会話が成り立たないと思います.
DNS server はどこにあるのですか?
内部と DMZ の server の通信時に NAT させる必要があるのでしょうか?
引用:

メールサーバですが、アクセスして ~/Maildir/new を見たところ、
どんどんたまっているので、外部からはメールが来ていると思います。


pop3 で NAT をしているところは正常なのですか?
「メールが取れない」なる表現が全く意味を成していないんですが,
通信できないのですか?
それとも通信できて拒否されているのですか?
では SMTP で送出はできるんでしょうか?
引用:

DNSに関しましては、http://fedorasrv.com/bind-lan.shtml などを
参考にして、設定しているのですが、名前では全く引けません・・・。


どう定義して NG なんですか?
外部に対しては正常に DNS が機能している?
でも内部には機能していないとして,内部向けの定義を別に書いているのか,
NAT を使って「内部も外部も同じ」ようにしているのですか?

重要な部分の説明が欠落しているので,何が起きているかわかりません.
のり
ベテラン
会議室デビュー日: 2006/04/07
投稿数: 61
投稿日時: 2006-04-21 10:34
kazさんいつもありがとうございます。

引用:

まず環境をちゃんと記載するようにしないと,会話が成り立たないと思います.



申し訳ありません。。

引用:

DNS server はどこにあるのですか?


今はうまくいかなかったので、プロバイダ指定のDNSサーバへ直接向けています。

引用:

内部と DMZ の server の通信時に NAT させる必要があるのでしょうか?


$IPTABLES -t nat -A PREROUTING -i ppp0 -p tcp --dport 53 -j DNAT --to 192.168.10.130
$IPTABLES -t nat -A PREROUTING -i ppp0 -p udp --dport 53 -j DNAT --to 192.168.10.130
の文ですよね!?
確かに外部に公開しない限りこれは必要ないのかなと思っていました。
すぐに外します!

引用:

pop3 で NAT をしているところは正常なのですか?
「メールが取れない」なる表現が全く意味を成していないんですが,
通信できないのですか?
それとも通信できて拒否されているのですか?
では SMTP で送出はできるんでしょうか?



POP3でのNATですが、一度、
$IPTABLES -t nat -A PREROUTING -i ppp0 -p tcp --dport 110 -j DNAT --to 192.168.10.110
の設定を外してみて、やってみましたが、同じ現象でした。

現象ですが、"POPサーバが応答しません"というものでした。

SMTP送出ですが、違うメールアドレスに送信したところ、
こちらは正常にすることができました。

引用:

どう定義して NG なんですか?
外部に対しては正常に DNS が機能している?
でも内部には機能していないとして,内部向けの定義を別に書いているのか,
NAT を使って「内部も外部も同じ」ようにしているのですか?



DNSに関してですが、また長くなりますが、下記が
named.confになります。

//
// named.conf for Red Hat caching-nameserver
//

options {
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;

# 追加ここから #

# このDNSサーバを使用する範囲
allow-query{
127.0.0.1;
192.168.1.0/24;
192.168.10.0/24;
};

# このDNSサーバをキャッシュサーバとして使用する範囲
allow-recursion{
127.0.0.1;
192.168.1.0/24;
192.168.10.0/24;
};

# このDNSサーバのゾーンデータの転送先の範囲
allow-transfer{
127.0.0.1;
192.168.1.0/24;
192.168.10.0/24;
};

#
forwarders{
プロバイダのDNSサーバ(プライマリ);
プロバイダのDNSサーバ(セカンダリ);
};

# 追加ここまで #

};

//
// a caching only nameserver config
//
controls {
inet 127.0.0.1 allow { localhost; } keys { rndckey; };
};

# 追加ここから #

# /var/log/messagesに「lame server resolving …」というログを出力しないようにする
logging {
category lame-servers { null; };
};

# 追加ここまで #


zone "." IN {
type hint;
file "named.ca";
};

zone "localdomain" IN {
type master;
file "localdomain.zone";
allow-update { none; };
};

zone "localhost" IN {
type master;
file "localhost.zone";
allow-update { none; };
};

zone "0.0.127.in-addr.arpa" IN {
type master;
file "named.local";
allow-update { none; };
};

zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {
type master;
file "named.ip6.local";
allow-update { none; };
};

zone "255.in-addr.arpa" IN {
type master;
file "named.broadcast";
allow-update { none; };
};

zone "0.in-addr.arpa" IN {
type master;
file "named.zero";
allow-update { none; };
};

# 正引きZONEデータ追加ここから #

zone "n-n-s.net" IN
{
type master;
file "n-n-s.net.zone";
allow-update { none; };
};

zone "masudaclub.com" IN
{
type master;
file "masudaclub.com.zone";
allow-update { none; };
};

zone "in-serverside.net" IN
{
type master;
file "in-serverside.net.zone";
allow-update { none; };
};

zone "naracity.net" IN
{
type master;
file "naracity.net.zone";
allow-update { none; };
};

# ここまで #

# 逆引きZONEデータ追加ここから #

zone "10.168.192.in-addr.arpa" IN
{
type master;
file "10.168.192.in-addr.arpa.zone";
allow-update { none; };
};

# 追加ここまで #

include "/etc/rndc.key";

以上で、

例えば、masudaclub.netのzoneファイルは下記になります。

$TTL 86400
@ IN SOA masudaclub.com. root.masudaclub.com.
(
2006041101 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ; Minimum
)
IN NS masudaclub.com.
IN MX 10 masudaclub.com.
@ IN A 192.168.10.130
www IN A 192.168.10.100
mail IN A 192.168.10.110


逆引きファイルは、

$TTL
@ IN SOA n-n-s.net. root.n-n-s.net.(
2006041101 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS n-n-s.net.
IN A 255.255.255.0

100 IN PTR n-n-s.net.
100 IN PTR masudaclub.com.
100 IN PTR in-serverside.net.
100 IN PTR naracity.net.
100 IN PTR m-printing.com.

WebサーバのIPが末尾100で、Mailサーバが110、DNSが130になります。

またまた長くなりましたが、よろしくお願い致します。

情報不足でしたら、指摘下さい。
kaz
ぬし
会議室デビュー日: 2003/11/06
投稿数: 5403
投稿日時: 2006-04-21 11:25
引用:

のりさんの書き込み (2006-04-21 10:34) より:

引用:

DNS server はどこにあるのですか?


今はうまくいかなかったので、プロバイダ指定のDNSサーバへ直接向けています。


つまり,その DNS server には「外部向けの内容」だけが記述されているんですよね?
内部向けに local な IP address で解決できる内容は記述されていませんよね?
それを「client が直接見ている」のですか?
記述を見ると
・DNS server はある
・でもその DNS server は見ずに外部の DNS server で名前解決している
ように読めますが,ドウなのでしょう?
引用:

現象ですが、"POPサーバが応答しません"というものでした。

SMTP送出ですが、違うメールアドレスに送信したところ、
こちらは正常にすることができました。


それで,その pop3 server は名前解決が出来なくて,
SMTP server としては名前解決ができると?
それとも MUA 側では IP address で「メールサーバ」を指定していますか?
実際に pop3 daemon が起動していることは確認済みですね?
引用:

引用:

どう定義して NG なんですか?
外部に対しては正常に DNS が機能している?
でも内部には機能していないとして,内部向けの定義を別に書いているのか,
NAT を使って「内部も外部も同じ」ようにしているのですか?


DNSに関してですが、また長くなりますが、下記が
named.confになります。


内容から「内部向けの情報だけ」が記述されていると認識しています.
ですが,
引用:

IN NS masudaclub.com.


ここはどの host でしょうか?
cache server としてだけ機能するなら,
自分で zone を管理する必要は無いでしょう.
自分で zone を管理するなら masudaclub.com の IP address が解釈できて,
さらにその masudaclub.com に名前解決の要求を
受け取ってもらえないとダメだと思います.
その辺の理屈は理解されていますか?
※どうしても構成が「正しくない」と思うのです.
のり
ベテラン
会議室デビュー日: 2006/04/07
投稿数: 61
投稿日時: 2006-04-21 12:13
kaz様ありがとうございます。

引用:

それを「client が直接見ている」のですか?
記述を見ると
・DNS server はある
・でもその DNS server は見ずに外部の DNS server で名前解決している
ように読めますが,ドウなのでしょう?



またまた言葉足らずですいません。

依然試みた際は、クライアントのDNSサーバIPは
きちんと内部用のDNSサーバを向けていて、
内部からのドメイン解決ができませんでした。

それが失敗したので、現在クライアントは
プロバイダのDNSサーバを指定しています。

引用:

それで,その pop3 server は名前解決が出来なくて,
SMTP server としては名前解決ができると?
それとも MUA 側では IP address で「メールサーバ」を指定していますか?
実際に pop3 daemon が起動していることは確認済みですね?



現在恐らく内部DNSを使用しては解決できないので、
メール受信・送信テストをしたメーラーの設定は、
メールサーバのIPを直接指定して行いました。

その際、送信はできて受信はできないという状態です。

サービスですが、"dovecot"が起動していることを確認しております。

引用:

内容から「内部向けの情報だけ」が記述されていると認識しています.
ですが,


認識頂いている通りでございます。

引用:

ここはどの host でしょうか?
cache server としてだけ機能するなら,
自分で zone を管理する必要は無いでしょう.
自分で zone を管理するなら masudaclub.com の IP address が解釈できて,
さらにその masudaclub.com に名前解決の要求を
受け取ってもらえないとダメだと思います.
その辺の理屈は理解されていますか?
※どうしても構成が「正しくない」と思うのです.



指摘して頂きましたホストは内部のWebサーバのバーチャルホストの一部です。

その辺り理解できていないことになりますね。。

内部解決の為のDNSの構成がまずおかしいということですね。。。

なるほどです。
DNSを今指摘して頂いたものを踏まえまして、調べていきたいと思います!
kaz
ぬし
会議室デビュー日: 2003/11/06
投稿数: 5403
投稿日時: 2006-04-21 13:03
まずハッキリさせなければならないのは,
名前解決の仕組みがどのような流れになっているか?でしょう.
引用:

のりさんの書き込み (2006-04-21 12:13) より:

依然試みた際は、クライアントのDNSサーバIPは
きちんと内部用のDNSサーバを向けていて、
内部からのドメイン解決ができませんでした。

それが失敗したので、現在クライアントは
プロバイダのDNSサーバを指定しています。


ですので,内部にある DNS server はまったくなんの役割を果たしていませんよね?
現段階で名前解決の service を提供しているのは ISP の DNS server ですので,
内部向けの名前解決は事実上出来ません.
よって,名前解決できるはずは無いんです.
引用:

現在恐らく内部DNSを使用しては解決できないので、
メール受信・送信テストをしたメーラーの設定は、
メールサーバのIPを直接指定して行いました。

その際、送信はできて受信はできないという状態です。

サービスですが、"dovecot"が起動していることを確認しております。


ということなので,名前解決はこの局面では全く考慮する必要は無いです.
なぜなら client は名前解決をしないで SMTP/pop3 server と通信しているので.
dovecot は正常に起動しているなら,設定の問題では?
その pop3 server 上で telnet などで 110/tcp に接続して,
その dovecot はちゃんと喋ってくれますか?
client から pop3 で接続した際,pop3 server 側の log は確認されていますか?
※接続を拒否したとか,そういった log は?

dmz にある DNS server は誰も参照していないのですよね?
であれば,ややこしいから今の段階では停止してしまったほうがよろしいのでは?
有害では有りませんが,話がややこしくなるので.
ちゃんと動くようになった暁にそれぞれの server/client から
参照すれば良いと思います.

以上,ご参考までに.
のり
ベテラン
会議室デビュー日: 2006/04/07
投稿数: 61
投稿日時: 2006-04-21 17:50
ありがとうございます。

とりあえず、ご指摘の通り、メールとDNSを別にして切り分け
てやっていこうと思います。

また、進捗などありましたら追記させて頂きます。
1

スキルアップ/キャリアアップ(JOB@IT)