別環境にファイルサーバを据えたら認証で待たされる（遅くなった）。サーバが参照するdnsサーバを疑え

念願のclassB環境にネットワークを移行させたのは良いものの、結局トラブった。
classC環境（いわゆる192.168.x.x)からPC台数と管理の関係でclassBに移行したのだけれども、
何故か社内の特定ファイルサーバだけ、認証画面に行き着くまでかなりの時間（数十秒）待たされる。
認証してしまえば全く問題なく使えるのだけれども、統括部内だと全ての部署に配置されているファイルサーバに接続するため、
いちいち時間がかかってしようが無い。

結論から言うと、サーバ側の問題だったが、まあおつきあい下さい。
環境はcentos 5x~7xまでばらばらだが、centosとsambaで構成されたファイルサーバ群。クライアントは大半がwindows10。

まず疑ったのが、クライアントPCのルーティング。
「クラスC環境は全て取っ払った」ので、192.168とか吐いたら間違いなくそれの筈。
そこで、Wiresharkで通信ログを取るが、
全てDHCPで管理しているので、ルーティングをしくじっている気配は無い。
192.168とか吐いていればこれだと言えるが、吐いているのはサーバ群のみ。
*このときに気付いていれば良かったが、CからBへの移行の際、シームレスに移行するためにファイルサーバにはIPアドレスを２つ（BとC）持たせていたので、別に不自然だとは思わなかった。

次に、正常なサーバと異常なサーバを比較。
smb.confを比較したが、特に引っかかるところは無かった。
強いて言えば、netbios_nameがあったりなかったり程度。
iptablesではじいてしまっているのかと思って比較するも、関係なし。
ただ、
いつもはさっと引ける「iptables -L」が異常に重い。

google先生に

「iptables "-L" ローカルIPアドレス　遅い　表示」

で聞いてみると、どうやら名前を逆引き出来ないから、という結論に。
iptables -nLで逆引きしなければ良いよ、と教えて貰えるが、それはこの環境での答えとは違う。引いているのはローカルIPアドレスなのである。
ここら辺で、なんとなく名前の解決関係（DNS）がらみなのではと疑い出す。

ゲートウェイやDHCPはクラスB環境に移行していたので、最後にファイルサーバ群のネットワークの記述をクラスCのみにすることに。
ここで比較していると、一点だけ違う、奇妙なことに気がついた。
PEERDNS。
解説は
http://think-t.hatenablog.com/entry/20110113/p1
が詳しいのだけれども、あるなしの違いがあった。
正常に繋がる方は、PEERDNS=no、繋がらない方は記述自体が無い。
上記ページに従うと、resolv.confの記述内容を使うかどうかということ。
Centos5から使い続けていたので、NetworkManagerとは因縁がある。
もしNMを使っていれば関係ないのかもしれないが、
NMを使っていると、勝手にresolv.confを書き換えるので、意図的に停止させているのである。
なので、resolv.confの書き換えをしないと、設定は生きっぱなしになる。
resolv.confには、ばっちりclassCのDNSサーバアドレス。
しかも僕はご丁寧に（移行中だったからだけど）NICの設定ファイル（ifcfg-foobar）にも書いていた。

ということで、問題点は、
「存在しないDNSサーバにファイルサーバが問い合わせまくって、その問い合わせの答えが出ないから時間がかかりまくった」
ということでした。
解決法は
NICの設定ファイル（/etc/sysconfig/network-scripts/ifcfg-foobar)に正しいDNSサーバアドレスを書く
ことと、
resolv.confを見直し、ちゃんと正しいDNSサーバアドレスを認識しているかどうかを確認する
こと。

前者は、たとえばNICの設定ファイルがifcfg-eth1だった場合、

vi /etc/sysconfig/network-scripts/ifcfg-eth1

で、正しいDNSサーバのIPアドレスを指定する。たとえば

DNS=192.168.0.1

と記述してやる。
僕がはまったのは、サーバは番号を振ればいくらでも登録出来るので

DNS1=192.168.XXX.XXX
DNS2=172.16.YYY.YYY

のように登録して、DNS1は既に取り外していたこと。

後者も同じように、nameserver=でいくつでも登録出来るので、使う（使える）DNSサーバだけにする。

これで問題なくなった。

以下はgoogle先生に聞きまくったときに出てきた似たような事例。
残念ながら答えは出ていなかったが、恐らく問題は同じだろうと推察。
http://cgi.samba.gr.jp/mailman/archives/samba-jp/2013-July/003306.html
クライアント-サーバ間では全く問題ないログしか吐かないし、Wiresharkでも問題が認識出来ないのがミソ。

自分の関連過去エントリは
resilv.confとPEERDNSなど
http://roserogue.blogspot.jp/2011/10/cent-os6resolvconf.html

sambaがらみ
http://roserogue.blogspot.jp/2007/08/samba.html

名前の解決は出来るが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にすることで一応の解決を見た（これ消した方が良いのかしらん）が、
全く気付かなかった・・・。