2013年11月14日木曜日

port53番ポートが兎に角開かない(iptablesでは開放しているのに、外から見ると閉じている)

CentosにBINDを突っ込んで設定していたところ、どうしても53番ポートが開かない。
というか、サーバ的には53番は開放しているのだけれども、外から見た場合、closedに見えるという切ない状況。
iptablesとしては、53番開放済み。
nmapをわざわざインストールして見ても、53番は開いている。
dig @192.168.XXX.XXX google.com(XはサーバのIP) も通る。
でも外からwindowsで見た場合、
nslookup google.com 192.168.XXX.XXX
はタイムアウトするし、windowsからnmapでサーバを見ても、port 53はclosed。
困りに困ってまたまたgoogle先生にお伺いを立て続けたところ、

http://q.hatena.ne.jp/1296524427

が出てきた。
named.conf に
listen-on port 53 { 127.0.0.1; };
という行がありませんか? つまり、localhost のインタフェースでしか Listent していない状態です。
この行を外せば、全てのインタフェースで Listen するようになります。
間違いない。
これのせいだ。ということで、
vi /etc/named.conf


// listen-on port 53 { 127.0.0.1; };
という風にコメントアウト。
無事外からも見えるようになりましたとさ。

ただ、ポートがふさがっているということになると、やはり疑うのはfirewall。
iptablesの内容を何度もさらった。

iptables -A INPUT -p udp -s $internal_ip --dport 53 -j ACCEPT
iptables -A OUTPUT -p udp -d $internal_ip --sport 53 -j ACCEPT
iptables -A INPUT -p tcp -m state --state NEW -s $internal_ip --dport 53 -j ACCEPT

で大丈夫なんだろうけど、もっと良い書き方有ったら教えてください。

また、named.confにforwardの設定をしているのだけれど、
Nov 14 21:50:40 servername named[1876]: error (no valid DS) resolving 'XXX.XXX.168.192.in-addr.arpa/PTR/IN': 8.8.4.4#53
Nov 14 21:50:40 servername named[1876]: error (no valid RRSIG) resolving '168.192.in-addr.arpa/DS/IN': 8.8.4.4#53
Nov 14 21:50:40 servername named[1876]: error (no valid RRSIG) resolving '168.192.in-addr.arpa/DS/IN': 8.8.8.8#53
 みたいなログをmessagesに吐き出されてげんなり。
8.8.8.8と8.8.4.4と192.168.XXX.XXX
をforward先として設定しているのだけれども、全部エラー。しかもgoogle先生教えてくれない。

追記
と思ったら出てきた。
http://jsapachehtml.hatenablog.com/entry/2014/01/13/113229

ということで、DNSSECの問題らしい。が、それはそれで気持ち悪いなあ・・・。
named.confを書き換える。

vi /etc/named.conf

dnssec-enable no;
dnssec-validation no;
//dnssec-lookaside auto;
chrootしている場合はファイルの場所が違うので注意。

2013年11月13日水曜日

名前の解決は出来るがpingが通らない

久しぶりにやらかした。


NICが2つあるマザーでゲートウェイを組もうとしていた。
DNSリゾルバを組み込もうとしたところで躓く。
何故かpingが通らない。
そして名前も引けない。
ここでの解法は簡単な物だった。
namedを設定する直前に、squidプロキシの設定やらがちがちの禁止事項を盛り込んだiptablesのシェルスクリプトファイルを読み込んだからである。
そこまでは良かった。
そしてそこからが大変だった。
取り敢えず物理的環境を実運用スタイルにと思い、

インターネット

ルータ(192.168.69.1)

eth0(192.168.69.2)

ゲートウェイサーバ本体

eth1(192.168.96.1)

ハブ

設定用ノートPC(192.168.96.2)

という構成にしたところ、
素の状態で、何故かgoogle.comにpingが通らない。
何をしても通らない。
iptablesを落とし、selinuxを落としても直らない。
 だがdigするとgoogle.comの名前は引ける。
ルータ(192.168.69.1)にもpingが通る。
でもdigで引けたgoogleにpingが通らない。
ルータにノートを直づけすると、勿論gogle。comは通る。

名前は解決できているので、少なくともサーバはルータには繋がっている。
ルータはgoogle.comに繋がっている。
 でもサーバからgoogleにpingが通らない。
ある意味「半分繋がっている」、という不思議な状態。
経路の問題というのは分かるのだけれども、tcpdumpを眺めても特になく。

嫌な感じがして、わざわざgnome環境をサーバに入れてみたところ、
サーバ上のfirefoxでもgoogle.comに繋がらない。
意味が分からない・・・。

やはりそこはgoogle先生にということでお伺いを立て続けると、

http://okwave.jp/qa/q7244798.html

が。

外部、というのが202.xxx.xxx.xxx/28や192.168.xxx.xxx/24以外のネットワークだとしたら当然そうなります
デフォルトルートが2つ設定されていますが、実際に有効になるのは片方だけなので

ネットワークのあて先がわからないときの最終的なパケットの投げ先がデフォルトゲートウェイなので、そんなものが2つあっても片方にしか投げられないのが原因
片方のデフォルトゲートウェイを残し、もう片方のNICに対しては必要な分のスタティックルーティングを設定すべきです

まるっきり状況が同じ。

要は、eth0とeth1に、別のゲートウェイを指定していたためにこうなってしまったのである。

実はeth1は、元から有る環境に接続するため(ぶら下がるために)IPアドレスは、
192.168.96.1ではなく、192.168.96.20だった。なので、eth1にはGATEWAY=192.168.96.1が設定されていた。

上記のような環境にするために、eth0にGATEWAY=192.168.69.1を設定したにもかかわらず、
eth1のGATEWAYが優先され、本来GATEWAYとして通らなければならない192.168.69.1は無視されたと。

要は、一番初っ端のネットワーク設定をしくじっていたということである。
eth1のGATEWAY記述を192.168.69.1にすることで一応の解決を見た(これ消した方が良いのかしらん)が、
全く気付かなかった・・・。

EchoLife HG8045jの初期ユーザ名とパスワード

EchoLife HG8045jの初期ユーザ名とパスワードは
admin
admin

HUAWEI製品・・・。