テクノロジー紹介 from Y.E.Y. 湘南: djbdns

ラベル djbdns の投稿を表示しています。すべての投稿を表示

2010年7月22日木曜日

iptablesの処理か？！その結果

今回、100% iptables の仕業だとわかったところがもう一つあった。
一度、現状の iptables を全てクリアして SNAT (ip masquerade) のみを可動させるときちんとアクセス出来るじゃないか！こりゃおったまげた。なんで今まで気付かなかったのか。

取り敢えずフィルタを一つずつ探るしかなかった。最初はマジにフィルタの問題かと思ったが実際はフィルタとは違うところにあった。フィルタとより、初期化の問題だった。はじめはグループでコメントアウトさせていたが、どれも当てはまらなかったので仕方なくしらみ潰しした。そこで初期化だと判明。

旧： $IPTABLES -A INPUT -i $EXTIF -s 0.0.0.0/4 -j DROP
新： $IPTABLES -A INPUT -i $EXTIF -s 0.0.0.0 -j DROP

そう！「/4」が問題だった。でも HP.COM のアドレスって 15.x.x.x のクラスＡで/4でも大丈夫のはずと思っていたが、引っかかっていたんだ。あちゃ〜！色んな参考書通りに 0.0.0.0/4 にしろと書いてあったので、そのクラスは大丈夫かと信じていたがやはりアカン！全て疑ってかかれってヤツだ。良い教訓。でも解決した。

djbdns の DNS 問題じゃなかったｗ hp.com を正引き出来るようになった。バンザーイ！

2010年7月19日月曜日

やっぱりiptablesだな

あれからルータの設定を変えて、hp.comに内部ネットからアクセス出来るか試した。
やはりパケットが落ちる事が判明。DNSサーバをやはり疑った。

そして今、DNSサーバを今のdjbdnsのキャッシュサーバであるdnscacheのみにして、更にISPのDNSサーバをオフにして、ルータ直からのIPアドレスにしてhp.comにつないでみた。つながるんだよね。
っと言うことはDNSサーバの問題じゃないと判明。

iptablesの問題か。orz

iptablesの処理か？！

現状、私のこのマシンからアカマイでキャッシュされているサーバの一部がつながらない。
アカマイだけじゃないと判明した。これはＤＮＳを分散しているところだと先程判明した。
唯一繋がらないと分かっているのがHP.comと言うトンデモない状態だ。

しかし、私のルータにこのマシンを直接つないで、そっちのプライベートアドレスから外部へ出るとHP.comにつながるではないか！更に、私の実験室側で立てているルータの内部からはつながると言う不思議な現象が起きている。今までは外部と直接つながっているルータで試した事がなかったので気付かなかったが、実は問題なくつながるではないか！DNSサーバは同じのを利用している。

っと言うことは問題はiptablesの処理にあるのか！と判明。ルータ側のiptablesはサーバのdual home gatewayを介さないで通るからパケットがきちんと処理されていると言うことだ。っと言うことはiptablesの処理が悪いと言うことかｗ！DNSサーバの問題かとずっと思っていたら別のところだったとは。
しかし、不思議なことにdjbdnsのdnscacheを利用して、そのログを見ているとパケットは落とされているみたいだが、接続タイムアウトで落ちているとわかる。やはりiptablesの処理問題だったか。うぅ〜ん、根が深いところだ。

もしかしたらこれのおかげでBIND/namedのrecursive設定がきちんと動作していないのかも。でもまた内部ネットには反応が帰って来ているから不思議でありゃしない。やはり外部とのiptablesなんだろうな〜。

2010年7月13日火曜日

iptables内部の処理

懺悔モンだな

iptablesでSNATを利用している。

$IPTABLES -t nat -A POSTROUTING -s 192.168.x.0/24 -o $EXTIF -j SNAT --to ww.xx.yy.zz
まず一つ目の問題はこの$EXTIFを$INTIFにしていた。(~_~;
色々といじっていて訳わからなくなったｗ

そうなんです。「-o」← Output だよ〜ここは外部へ出すI/Fを書くんだった。
そして外部のグローバルIPにSNATを振るんだった。orz
さて、もう一つの問題はDNSにある。
これは未だに解決していない。
だが逆引きは出来るようになり、友人へのメールも送る事ができた。

ルータをCoregaに変えたがファイヤーウォールを切る事が出来なく、認証が取れず、更にinboundパケットの細かいところを落とされてしまい、メールとSSHとかが使えなかったのでまたBuffaloに戻した。
実はヤマハのSRT-100を持っているのだが、使いづらいｗ

ちなみにdjbdnsの問題も未解決だ。
akamaiへキャッシュしているところにはつながらへん！

DNSとIPTABLES

この数日間、DNSとIPTABLESの設定でバトルしている。
マックミニサーバーだとどうしても逆引きがおかしい。
おかしいと言うのは語弊がある。
逆引きが引けない！オイオイ。
メールでは致命傷なんだな〜。

さてここでリナのサーバに戻すことにしたが、同様の現象。
更に今まで利用していたファイヤーウォールの設定だとプライベートアドレス内にパケットが転送されない。
これには理由は全くわからない。
そんな中、マックのサーバを二度も再インストールして、リナも別のHDDにUbuntuを入れてみた。
Ubuntuで毎回設定するのにsudo コマンドは面倒臭いったらありゃしない。
それに/etc/named.confがないじゃないか！rc.inet1.confでETH0/1/2にIPアドレスが振れない。
だって中身はRHL系がベースだから仕方ないんだけどね。
centOSにしようかと思ったけど、同じような問題もあるし、Bastilleとして動作がウザいからな。

昔のマシンを取り出して接続させてもダメだった。
先程iptablesが更に昔の設定で試したらパケットが内外に転送されるようになった！オイオイ。
まさか、SPIかよ？え？stateful packet inspectionの設定の場所が違うって？
他のマシン（サーバ）で動いているぞ。うぅ〜ん、わからん。

それにDNSだってnamedがきちんと逆引きしないんじゃん！
それに正引き（キャッシュサーバ）だってきちんと動作しないじゃん！(T_T)
っと言うことでakamaiとの対応がイマイチのdjbtoolsのdnscacheを二つ動かす (localhost用とプライベートIPの外部キャッシュサーバ用) 。

さて、ここまで二日間は掛かった。
発端はRRECへメールを送ろうとしたら弾かれた。そして別の米国の友人に送ろうとしたらまた弾かれた。
そこでマックが逆引きしていない事を発見。いくら設定しても昔の設定が反映されてしまう。
更に保存した内容が消える！オイオイ。
Time Machineで戻してもそこは戻らない。意味ね〜！

っと言うことでマックミニサーバは外して、これは内部用に使うことにした。
今からリナでCore2Duo E9300 CPUマシンに戻す作業をする。
そしてiptablesの検証だよ。トホホのブログｗ

2010年6月23日水曜日

DJBTOOLSのerrno.h

あれ？いつから #include <errno.h> になったんだ？
以前の変更は #include <error.h> だと思ったんだが。
それに /usr/local/daemontools/bin がない！
中身が /usr/local/bin に入っている。(>.<)
実際の中身は /command に入っているんだが。
これだと UCSPI-TCP と一緒だ。ウゥ〜ン、悩む。

2009年12月10日木曜日

djbdns dnscacheがakamaiのサーバからデータを

ず～～～～っと気になっていたことがあった。何故だか input/output error が表示される。

実は私のネットワークから（ここだけではなく、別のところも同様）でdjbdnsを使っているとakamaiからのキャッシュデータが拾えないと判明。

どうやら私だけではなかったので、よりよく調べてみた。

うちでは hp.com がダメです。中には ikea.comがつながらないとか、色々とありました。

っで、ついでにだから google public dnsを利用していみた。

これはキャッシュサーバだけど、外部に問い合わせを掛けるので以外と時間が掛かることが判明。

そんなこんなんでまた自前のキャッシュサーバに戻して、

苦肉の策で djbdns/env に FORWARDONLY を作成し、中身に"1"を書き込んで

> echo 1 > FORWARDONLY

そして root/server/@ ファイルに自分キャッシュサーバのipアドレスを入れた。

本来はここにルートサーバのアドレスが入るのだが（中身は dnsq ns . m.root-servers.net) -- ここの m は a から m のルートサーバどれでも良い -- この＠ファイルの中に自分のマシンのipアドレスとISPのセカンダリを入れて、OK。

もう～～～～～～～！なんでだ～！と叫ぶのですが。

djbdnsは万能ではないことは確か。でもBINDを使うよりマシと思っている。

どの道、キャッシュサーバだから外部とはあまり関係ないけど今夜はもう少し枕を高くして寝られるかな。

2009年11月11日水曜日

MacMini Server DNSクエリーが遅い！

DNSサーバとして利用しているマックミニサーバ、遅い！

やはりGUIが負荷を拡大している。なんとか脳死状態のリナを復活させなければ。

DNSのキャッシュサーバの反応が遅くておかげでこっちの思考パターンにズレが生じる。

遅い理由はきちんとセカンダリーを登録していないのと（これは問題あるな～）、ネット上、データが無駄な流れを起している。スッキリさせないと。

2009年11月10日火曜日

リナHDDトラブル、さぁ次の手は－その１

二日間徹夜してやっと直ったと言うより手段を変えた

5日にDNSサーバのハードディスクがコケた出した。

正直、コンテンツは全く入っていない分散したサーバだったので、あとは各々のURLを別のサーバに飛ばしていたので大したことは無かったが、そろそろ寿命もありパワーもないのと更に分散していたのをまた１台に戻そうと考えていた矢先だった。早急に直す場合はコケたHDDを別のに入れて復帰させる手段があったが、今回は大幅な改造を試みた代償がデカ過ぎた。

今回用意したマシンはCore2Duo 2.53GHz 2GBマシンでHDD５００GBｘ２の自作マシンだった。まずはファイヤーウォールを作るのにDual Home Gatewayと呼ばれるNIC数枚挿しで作るやり方だ。

iptablesは別のマシンでドつぼに填ったので予めきちんと対応させていた。

しかしここからが地獄の徹夜二日間だった。

単体でルータのみを直結させるとDNSキャッシュサーバはきちんと動作し、再帰的な問い合わせに応じてくれている。私はコンテンツサーバにはBIND、しかしキャッシュサーバにはdjbdnsのdnscacheを内部と外部で利用している。tinydnsを使わない理由は簡単。情報がなさ過ぎて、以前もトラブルに遭遇したからだ。これは置いといて、さて途中で途切れる！

ルータはきちんと繋がっている。故に外部へもアクセス出来る。サーバからは問題なく。しかしファイヤーウォールを超えたところで全てがアウトだ。DNSがきちんと繋がらないじゃないか。正確にはdnscache情報がどこかで切られている。ブラウザでは表示されるのだが、ホームページ内容が全く転送されない。

不思議なことに、NICを変えても何をしても同様。しかし物理的なルータのポートからは応じている。ルータを数珠つなぎをすると全てダメになる。サブネットから別のサブネットに回したらだ。

原因は不明でずっとカーネルをチェックしていたが、負けた。

このつづきはまた別の時に。

2009年7月8日水曜日

DNSを設定

サーバを入れ替えてます。
OSのバージョンアップと他の/etcの中身や特殊な設定。
ドえらい作業です。
ホントに神経磨り減ります。ドメインを移管しています。
あぁ～、忙しいのに色々と試すことがあって憂鬱になります。
でも負けずにやらないと仕事にならない。

2009年7月7日火曜日

DJBDNSに脆弱性が発見されていたとは

大したことじゃないけど、$1000の報奨金が支払われたのでしょうね。
http://www.theregister.co.uk/2009/02/28/djbdns_cache_poisoning_vulns/

驚いたね。
あまり騒がれなかったのは、dnscacheに対する汚染（これは重要）だけど、不特定多数に提供していた場合に限ったことで、内部の人しか影響ないと言うことなのでSecuniaのレベル２って出ていました。
http://secunia.com/advisories/33855/ ホンマかいな？
http://www.your.org/dnscache/djbdns.pdf
まだ読んでいないけど。

でもパッチも出ている。
基本的に少し修正すればよいだけ。詳しくは下を見て欲しい。
http://article.gmane.org/gmane.network.djbdns/13864

登録: 投稿 (Atom)