k-square's diary

IP 電話

最近ルータの調子が悪く Web サイトが表示できないことが、何度も続きました。
今まで報告しませんでしたが、最終的な原因はルータの
一つのポートが不調になったためのようです。
これが判明するまでかなりの時間を要しました。
さて、この原因の調査の段階で、
ルータ (RTX1000) のファームウェアをバージョンアップしました。
普段は 使いたい機能が増えた or 不具合解消のため にしかファームウェアのバージョンアップはしないので、
(時間があれば別ですが、トラブルを避ける上で動くものをわざわざいじらない方がいいのです)
「もしかしたら最新ファームウェアでは起こらないトラブルかもしれない」
という不確定情報でバージョンアップした今回は珍しいことといえるでしょう。

さて、このバージョンアップで Web サイトのダウンについては改善されなかったのですが、
それとは別に可能性が一つ広がりました。
それは VoIP の機能 です。
これを使うことで基本料金をきわめて低価格に固定電話を維持できます。
しかも機器は既に保有しているので、まさに私のための機能です。

元々 ISDN を維持していたのは二つの理由がありました。
一つは実家の PC を実家のルータと対向でダイヤルアップすることで、
メンテナンスしていたという理由と
もう一つは会社にダイヤルアップしているというのが理由です。

前者は既に実家を YahooBB にして
sshd と DDNS + DiCE と MSN Messenger と Real VNC を
併用することで、以前よりも手厚いサポートを通話料無料で、
かつ高速回線で行えるようになり、現在は必要なくなっています。
後者は転職に際して、この環境が必要なくなるので、
もはや ISDN を維持する必要がなくなるため、
電話回線の凍結を考えていましたが、
全ての登録書類にケータイの番号を記述するのはイヤなので、
どうしようかと迷っていたところなのでした。

そんなところに、VoIP の話。
ええ。えぇ。さっそく調べてみました。
プロバイダの VoIP オプション
対応機器
取り次ぎサービス

いいかも。
かなり現実味を帯びてきた VoIP です。
とりあえず既に機器は準備できていて、設定するだけですので、
ISDN を維持しつつテストをしてみます。
結果をお楽しみに〜。

あぁ、Yamaha はこの拡張性を実現してくれるから好きなんです。
サポートがステキ過ぎます。
今後も高くても Yamaha 買います！！(惚れ直したらしいです)

VoIP ( IP 電話 )

以前記述した IP 電話をはじめました。
構想から 2 ヶ月をへて、やっとの導入となりました。

元々は自分で持っている RTA54i を用いての IP 電話を導入しようと考えていましたが、
プロバイダの IP 電話オプションの設定時に、
設定内容をどうやら公開してくれない (自動設定される) ことがわかったので、
危険を冒さず、素直に VoIP アダプタのレンタルに申し込みました。

申し込んでから約 3 週間の期間を経て、本日 VoIP アダプタがとどきました。
早速取説とネットの情報を調べて、まずは VoIP アダプタのファームウェアを
最新にアップデートし、さらに最新版ファームウェアの自動チェックも設定しました。
VoIP アダプタがとどいたことで既存回線の ISDN の必要がなくなるので、
ISDN ルータ (RTA54i) を撤去し、ネットワークの設定変更を行いました。

ISDN ルータを撤去することで、ルーティングテーブルが変化する上、
さらにネットワーク機器の IP アドレス割り振りも変更したかったので、
RTX1000 (賢い IP ルータ) の DHCP の設定や DNS ルーティングの設定、
ネットワークルーティングの変更を行いました。
その上で、各ホストで DHCP での IP 再取得を行って、全ての作業が完了。
(RTX1000 以外の全てのネットワークアドレスは DHCP の静的配布で管理してます)

まぁ、書いてあることからわかるとおり、結構複雑です。
問題が起こらないように注意していたつもりでしたが、
一つ大きな失態を行いました。
RTX1000 の設定を変えている接続元ホストの IP アドレスの
DHCP 再取得を行ったときにそれが発現しました。

MAC アドレスと IP アドレスの対応の記述を間違ったために、
IP アドレスが変わり、RTX1000 との通信が切断されました・・・(-_-;;
その結果、RTX1000 につなげられなくなり
(管理ユーザでログイン中はシリアル以外の接続が出来なくなります)
RTX1000 の設定を修正するまでの間、
RTX1000 の設定を変えている接続元ホストは普段と違う
IP アドレス (dynamic に IP がふられました) が配布され、
そして、そのホストというのは、Web サーバだったというオチ・・・。

管理ユーザのログインタイマがタイムアウトするまでの 1 時間、
Web サーバがのんびりと落ちてました m(_ _)m

というわけで、VoIP の導入にまつわる設定変更で、
「やっちゃったー」って感じはありますが、導入した IP 電話についてはかなりいいです。
まずは基本料金が安い (レンタルあわせて700円ぐらい)
さらに通話料金も安いし、遠距離も定額！！
さらにさらに、追加料金ナシでナンバーディスプレイ機能も有効になります。
電話番号が変わっても気にならない人は、とっても、お薦めです。
ぜひぜひ考慮してください☆

さぁ〜、今週中にでも NTT に ISDN の停止申請をださなきゃー！

Network

私はサーバエンジニアです (しかも Windows より)
ある程度上級のサーバエンジニアはみなネットワークのこともある程度わかるもので、
私もそれなりにはわかります。
でも、やっぱり専門職ではないので、冗長化の時の仕様とか、
ネットワーク機器の仕様とか、メーカ独自の拡張とか、自律制御系ネットワークとかは
ほとんどわかりません。

さて、今日からはじまった新しいプロジェクトは、
そのわからない部分満載のプロジェクトで、しかも私がリーダー扱い。
L3SW (C3550) の冗長化にロードバランサー (BIG-IP) の冗長化に
L2SW の冗長化 (+スパニングツリー) といった内容。
サーバ関連だったら、リーダーどころかリーダーから実働者まで
全て実施するのですが、今回は実働できるところの方が少ないぐらい。
実際に私が作業できるのは、DNS の設定ぐらい。。。

というわけで、マネジメントの方に徹していこうと思います。
かなり大変そうですが、結構やりがいがあります。
なんと言っても新たな技術を学びながらすすめられるのは、
本当に嬉しいことです。
最近新たな技術を手に入れていないだけに、
その気分は爽快に近いものがあります。

さて、その技術、ご存知の人も多いかもしれませんが、少しだけ書いてみますね。
まだ詳しくないので、とりあえず概要だけです。
この程度の情報ではネットワークの挙動がわからないので、
実際はもっともっと調べることになります。
(というか、今後調べていきます)

HSRP
http://ew.hitachi-system.co.jp/w/HSRP.html
http://www.nw-support.jp/hsrp.html
VRRP
http://ew.hitachi-system.co.jp/w/VRRP.html
冗長化などの設定時の注意事項 (自律ネットワーク系)
http://www.mpls.jp/2004/presentations/high_availability3.pdf

今日は疲れたけど、いい気分。
でもでも！！仕事人間にはなるつもりないからね〜。
転職に有利な材料を集めると思って (一時的に) 頑張ります☆

BIG-IP

最近は f5 の BIG-IP をいじってます。
といっても BIG-IP を知らない方も多いと思いますので簡単に説明すると、
「BIG-IP は高額なネットワークロードバランシング (負荷分散) 機器」
です。
購入に 150 万ほど。年間の保守費用はそれ以上かかります。
# 非 IT 業界の人は「保守＝修理＆アップデート費用」だと思ってください。
が、それだけにいろいろ機能があって便利です。

この BIG-IP をまるでおもちゃのようにいじり倒してるわけですが、
# ドキュメントにかかれていない実際の挙動や仕様を理解するためです。
# 別に遊んでるわけじゃないです・・・。
これって普通許されるのか、ということに思いをはせました。
転職前も hp の HP-UX ( 1 台で 1 億 ) とか
ファウンドリ の L4SW ( BIG-IP の廉価版) とかいじってたし、
そういうものに触れる運に恵まれているような気がします。

さて、いきなり話は変わって私のことですが
基本的にこだわり性だし、設定マニア (笑) なので、
このままいじり倒せば BIG-IP についてもいろんなことがわかるようになる予感がします。
で、そうなってしまうと、キャリア的には良いかもしれませんが (悪いかもしれません)
仕事が飛躍的に増えてしまうというワナが待ち受けていますので、
どうしようか悩みどころです。
これは運がいいのか悪いのか・・・。

結局のところ、運がいいのか悪いのか分かりませんが、
ほかの人が触れることができない機会を得られることに対しては、
好意的に解釈しましょう☆
未来のことは未来の私に任せましょう。
大きな流れには身を任せ、小さな流れをより良い方へと渡り歩きましょう♪

ってことで、明日も BIG-IP をいじってみます。
明日は明日の風が吹くぅ〜♪

SOCKS

SOCKS って皆さん知ってますか？
ネットワーク系アプリケーションの設定内容の中に出てくるので、
proxy の一種なのはご存知の人も多いと思います。
一般の proxy は接続先のプロトコル (サービス or ポート) を理解し、
その「プロトコルレベル」で中継するのに対し、
SOCKS は接続先のプロトコルについては処理を行わずに、
透過的に動作する proxy の一種。

わかりやすく考えるなら、ネットワークのゲートウェイと同じようなものです。
あるアプリケーションに SOCKS サーバを proxy として設定した場合、
そのアプリケーションを用いた通信はゲートウェイとして、
SOCKS サーバを利用します。
・・・っていうと、proxy と同じように思えますね・・・。
まぁ、利用するプロトコルにかかわらず利用できる proxy だと思えばオッケです。
( そのアプリケーションが SOCKS に対応している場合 )
# 最初からそういえばよかったです・・・。

さて、その SOCKS ですが、最近って VPN とかあるから流行らなくなってるんでしょうか？
昔は permeo が OS のドライバレベルで動作する、
SOCKS クライアントをプロダクトとして提供していたのですが、
現在は見当たりません。
すっごいつかいたいのにぃぃーー。

その名前は e-Border Driver (後に名前が Permeo Security Driver に代わったはず) で、
OS のドライバレベルで wrapper として動作するため、
OS のうえのアプリケーションの設定変更なく利用することができます。
しかも、複数の SOCKS サーバを設定できるため、
通常のゲートウェイに加えて、プロトコルレベルでゲートウェイを選択するような真似もできる、
ちょー便利なアプリケーションだったのにー。

昔は会社でもってたけど、たいして使ってなくて、
今、使いたいときにつかえないっていうのはどういうコトー！！？
やすいなら自分で買うんですけど金額は書いてないし・・・。
NEC の SocksCap では要件にたりないよぉー。
はぁ、、、どーしよ。

-- 追記 24:16 --
みつけましたー。
http://download.permeo.com/cgi-bin/eval
で、一体金額はいくらなんでしょぉ・・・？

-- 追記 2005/10/15 17:30 --
で、さらには e-Border Driver もみつけたので、
Permeo 製品の両方の動作試験を実施した結果、認証機能とかで変に拡張されてて、
一般的な SOCKS5 サーバのクライアントとしては正常には動作しないことが確認できました。
そして、改めて別のツールを探し回った結果、望ましいツールを見つけました。
しかも Free でかなりるんるん。ツール自体は以下のとおりです。

Hummingbird SOCKS Client
http://connectivity.hummingbird.com/products/nc/cpsecurity.html

動作確認もできましたよん♪

と・・・とうとうネットワークも？

なんども申し上げますが、わたしはサーバエンジニアです。
Linux / UNIX / Windows に関してはかなり頑張れる方だと自負してます。
が、 Network については微妙です。
もちろん、サーバ屋としてのネットワークについてはわかりますし、
大まかな概念はわかりますが、設定を行う際の仕様や問題点は知識が乏しいです。

が、なぜか、BIG-IP (ネットワーク負荷分散機器) を設定し、
今度は NetScreen (ファイアウォール) を設定することになりそうです。
後は CISCO 覚えたら、一人で何でもできるエンジニアになれちゃうじゃん。。。
キャリアアップとしてはいい気がしますが、
ただ単に便利屋になりそうな気がするのは気のせいかなぁ・・・(汗)

まぁ、ネットワーク機器は Windows などに比べて、
マニュアルにほとんどのことがかかれている上、コンフィグの例示もあるので、
取っ掛かりは大分良いのですが、
「その OS がそのハードウェアのためだけの OS 」というところが問題です。
一般の OS ( Network 機器の OS ではなく ) とちがって、
いたるところに制約があって、Appendix もあわせて確認しないとはまりそうな点がちらほら。。。
さらに、仕様まで正確に理解しないといけなそうな点もちらほら。。。

さらに、環境として 802.1Q (タグ vlan の標準) を使っているので、
上流＆下流の関係 Network 機器と設定をあわせないといけないのに、
設定を行う上で情報が足りなすぎ。
「こう設定して」
と言われたとおりに設定することはできなくはないのですが、
たぶんお客様の動作確認のときに問題が発生するのはミエミエなんですよね・・・・。
でも、まぁ、決まってしまったことなので、勉強するしかないですし、頑張ります☆

あ！！そういえば、私は Network を調べるときによくパケットキャプチャを行うんですが、
( tcpdump / snoop / ethreal とかです)
Network エンジニアの方が実行しているという話をあまり聞かないです。
Network エンジニアの方はどうやって調査とかをするのかおしえてくださいー。

DNS の詳細

法人向けプロバイダで労働してます。
そのプロバイダでさえ、DNS のことを厳密に理解している人は少なそうなので、
今回書いてみようかなーと思ってみました。

細かいことは自分で調べてもらうとして、
知ってないと調べられないことを書いてみましょう。
技術者の人が読めば「へー、そうだったのか！」と思うこと間違いなし。
# だといいなー(笑)
一般には語られないことを語ります。
書きやすいので、文書は断定形な感じで書きます。
なるべく理解しやすいように順番に書きますが、たまに前後しちゃうところはご愛嬌☆

1. DNS はツリー構造となっている。TLD といわれる .com や .net や .jp をまとめる
"." (ドット) 言われる最上位のドメインが存在することを理解すること。
通常は "." は略されているが、正しくは .com. .net. .jp. (最後に "." がつく) であると理解しておく。
よって、シングルツリー構造となっている。

2. DNS は分散システム。この分散は「委任」によって成り立っている。
シングルツリー構造であるため、ツリーの上位のものが下位に「委任」することで、
分散システムとなる。

3. DNS のプロトコルとして UDP を使うのはよく知られているが、
クエリーの回答に 512 byte を超える場合は TCP での回答となる。

4. UDP/TCP のプロトコルを理解していれば当然だが、
TCP での通信はコストが高く、頻繁に通信が必要となる DNS では好ましくない。
一般にはゾーン転送以外では TCP が使われないような、
ゾーン情報とするのが好ましい。(あまり語られないがこれは本当に重要)

5. ツリーの最上位はルートサーバといわれる 13 台のサーバで成り立っている。
この 13 台は今後増えることは (現状のプロトコル仕様では) まずない。
なぜなら、3. で語った DNS のプロトコルとして UDP で収まるのがこの台数だから。
14 台以上になると、TCP での通信となってしまう。

6. 13 台のサーバで成立っている、といわれているが、
本当に 13 台なわけではなく、実サーバとしては大量にある。
そのコア技術としては、エニイキャストがよく語られる。
また、語られないが、間違いなくネットワークロードバランシングも
用いられていることが想像される。

7. エニイキャストって何よ、という質問に回答するのは難しい。
(理解するためには実設定を想像できないとつらいから)
簡単にいうなら、一つの IP アドレスが複数のネットワークに存在する状態。
たとえば、違う会社で同じプライベートアドレスを利用していると思うけれど、
それをインターネットでやるということ。
これは specific に host ルーティングを書くことで実装されていると思われる。
(実設定は想像でしかないので念のため)

8. ネットワークロードバランシングは、BIG-IP (一番有名) などの
負荷分散機器を利用して、その機器に実 IP を割り当て、
その機器が複数のサーバにパケットを賢く転送するという技術。
まぁ、今はかなり有名なので、知らないなら調べてください。

9. というわけで、ルートサーバは 13 個のホスト名 (FQDN) と IP アドレスの組であって、
実サーバはいっぱい。(実際に何台あるかは誰もしらなそう。。。)
なので、なかなか落ちないので (落ちないようにみんな全力なので) とりあえず安心して、
委任されたドメイン名を各ネームサーバが答えれば、DNS という分散処理システムが出来上がる。
ちなみに委任は NS レコードによって行われる。
委任したサーバと委任されたサーバで NS レコードが違うのは「正しくない、好ましくない」状態。
だけど、動くので、そういう設定をたくさん見かける。

10. とはいえ、ドメイン名を持っている人は、「委任をしてもらった記憶ってないけど？」と
思う人もいると思うけれど、たとえばお名前 .com とかでドメインを取得すると、
「ネームサーバ」を設定するところがあって、それが「委任の依頼」にあたる。
(そんなことはかかれてないけれど、挙動としてはそういうこと)
というわけで、ルートドメインは ICANN (だったかな？) が管理してるので、
それが TLD を決め、TLD の下のドメインは TLD で委任されてる。
ということは、(ありえないけど) ICANN が私に .k-square. を委任したら、
その TLD を私が使えるようになるし「管理できるようになる (管理しないといけなくなる)」

11. TLD の委任の情報は whois で出てくるものと同値。
whois はドメインの情報を教えてくれるけれど、その中のネームサーバについては、
委任の状況を示したものなので、TLD からしたに降りてくるには dig / nslookup で
ルートドメインから降りてくるよりは whois 使ったほうが楽。

12. とはいえ、ルートドメインから TLD への委任は dig / nslookup で調べて頂戴。
(どこかに URL がありそうだけど面倒だから各自調べてください)

13. 9.〜11. をまとめるとドメインでの NS と whois に登録するネームサーバはあわせなさいってこと。

14. ところで、DNS サーバっていうのは二種類あって、コンテンツサーバとキャッシュサーバがある。
キャッシュサーバは
「プロバイダなどで指定される DNS サーバでがんばって名前を解決してくれるサーバ」
(再起解決をしてくれる)
コンテンツサーバは
「おもにキャッシュサーバに応答してくれるサーバで、名前解決はあまりがんばってくれずに、
自分の知っていることだけに答えるサーバ」(再起解決をしてくれない)

15. なんで二種類あるのかっていうと、結局負荷分散。
キャッシュサーバは名前解決を頑張るから、結構負荷が高い。
コンテンツサーバは知ってることだけを応えるから負荷が低い。
で、コンテンツサーバだけで、基本的には名前は調べていける。
だって、委任はコンテンツサーバで成立っているので、問題ない。
とはいえ、クライアント全員で一生懸命ルートドメイン→TLD→下位ドメイン→リソースレコード
って引いていくと面倒だし、トラフィックも増えてなんだかよろしくない。
ので、それらを解決するためにキャッシュサーバがあるわけ。
キャッシュサーバは名前どおり、DNS クライアントとコンテンツサーバをつなぐ DNS サーバ、
だと思うと正解で、クライアントが質問すると全て調べて応えてくれる優しい人。
普通のクライアントはキャッシュサーバの存在を前提にしてあるので、
キャッシュサーバ無いと普通の人は名前解決不能 (自分で反復解決できる人以外は死亡。。。)

16. で、実際はどうなの？っていうと、キャッシュサーバとコンテンツサーバは一緒のことも多い。
設定すればいいだけなので、コンテンツサーバはキャッシュサーバにもなるし、
キャッシュサーバもコンテンツサーバにできる。
(ドメイン持ってないとルートドメインしか応えないからいみないけど)
さすがにルートサーバとかは世界中から query されて負荷が高いから純粋なコンテンツサーバ。

17. キャッシュサーバとコンテンツサーバが理解できたところで、
コンテンツサーバは誰に対しても解答する必要があるけれど、
キャッシュサーバは自分の回答したいクライアントにだけ応えれば問題ないことが分かる。
(分からなかったら分かるまで 15. を読むこと)
なのでー、大手はキャッシュサーバは自分のネットワークからのみ回答して、
そのほかの IP アドレスからのクエリーは無視したりするように DNS サーバを構成してます。
逆にだれでも使えるキャッシュサーバは Open DNS といわれちゃって、
「なんだよ、大手のくせにたいしたことねーなー」とかに思われることもあります。
中小企業で外向きはコンテンツサーバ、内向きはキャッシュサーバとして構成した
DNS とか見かけると、感心しちゃったりします。( これは私(笑)がそう思うってだけですけど )

18. ところで、DNS と聞くとプライマリ・セカンダリって聞くけど？
っていうのは、これはまったく気にする必要なし。
勝手にプロバイダとかがそう記載しているだけで、何の区別もない！のが正解。
プロバイダとかの使い分けのポリシーで決まります。
なんというか、二口ガスコンロがあって強火が可能なものをプライマリ、
強火ができないものをセカンダリといってるようなもの。
どっちもコンロであるし機能は変わんないでしょ？
利用者からは master / slave とかわかんないし。
後述の master / slave とごっちゃに考えてる人も多いので、いまここで理解しましょう。
プライマリ / セカンダリを master / slave と考えるならそれはそういう誤用をしている人 / 場所なので、
(誤用でもないけど、厳密に理解するためにここではそう考えておいてください。)
それはそのままにして、えらそうに知識を振りかざさずに
「この人 / ここはそーいう使い方だ」と思えばおっけー。

19. じゃぁ、master / slave ってなにさー？
っていうのは DNS サーバソフトウェアの
「リソースレコードの設定をできるサーバかできないサーバかの違い」
です。
たとえば BIND なら、master 側でゾーンのリソースレコードを設定できますが、
slave 側では master の設定を継承するだけ。
ちなみに Windows のアクティブディレクトリとか使うと、
(設定によっては) マルチマスタなので、全 DNS (DC) が master サーバです。
ってことを考えると、プライマリとかセカンダリとクライアント側で言い分ける\n 意味のなさを理解してみたりします。

20. ぜんぜん話は変わるけれど、DNS プロトコルは port 53 の UDP / TCP を使います。
これは有名。
で、知ってない人は知っててほしいですが、UDP には「セッションとかいう概念はありません」
UDP 上で実装することは可能ですが、UDP にはないってことを知っておきましょう。
ってことは、DNS の帰りの UDP パケットとソース port 53 発の UDP パケットは区別つきません。
おおっとー。
というわけで、stateless (static) なパケットフィルタはソース port 53 の UDP パケットを通します。
(通さなかったら DNS 引けないので)
ので、これを利用したフィルタ回避方法が一時期 (いまも？) 流行ったので、
statefull (dynamic) なパケットフィルタでは、ソース port 53 の UDP パケットを破棄することがあります。
( drop / reject としてはおおむね drop が多いように見受けます)
ので、レスポンスタイムとか、ゾーン転送のソースポート設定によっては statefull パケットフィルタとかで
ガシガシとめられちゃうので、DNS サーバでのソースポート指定とかは、なるはやで消しちゃいましょう。
分かりづらい問題になりますよー。
(dig で -b 0.0.0.0#53 とか使ってのきりわけが必要になるので、多くの人がはまります)

21. 最後ですが、ドメイン名には "_" (アンダーバー) が使えません。
SRV レコードなどに使うので、DNS サーバとかで使えるようになってますが、
RFC 的には使えないことになってるので使わないようにしましょう。
Windows で DNS 立てるときは要注意です。

22. 言い忘れましたがリソースレコードとは A レコードとか NS レコードとか PTR とか CNAME とかです。