Network Design

Active Directory ステップバイステップガイドと Active Directory ブランチオフィスガイド(TechNet)

YamaKen — Sat, 26 May 2007 19:45:00 GMT

今すぐに必要な状況ってことではないが、備忘録として。ブランチオフィスガイドは作業メニューを考えるときに参考になるかなぁ、と淡く期待。

Active Directory ステップバイステップガイド
http://www.microsoft.com/japan/technet/windowsserver/2003/technologies/directory/activedirectory/stepbystep/default.mspx

Active Directory ブランチオフィスガイド
http://www.microsoft.com/japan/technet/prodtechnol/windows2000serv/technologies/activedirectory/deploy/adguide/default.mspx

# ふと思い出したが、 Active Directory を十八番とする、エバンジェリストの高添さんが入院中とのこと。お大事に。

TechNet: 「試用版機械翻訳記事」

YamaKen — Sat, 06 Jan 2007 14:59:00 GMT

一ヶ月前より、 TechNet にて機械翻訳を用いたコンテンツの翻訳の提供の試みが開始されている。(米田さん、河端さんも紹介されていたんじゃないかと記憶。)

SMS 4.0 テクニカルライブラリ

このサービスは日本の TechNet チームの面々が手がけているものだが、フィードバックをぜひほしいとのこと。今後の展開を検討するときのネタとして、フィードバックをどんどんほしい様子。

TechNet試用版機械翻訳コンテンツに関するアンケート

どこの企業のサイトでも機械翻訳はまだ人力での翻訳のような精度のモノを出すことは出来ておらず、対象の業界を問わず、「コレ」ということが言えそうなセオリも確立していないので、そこまでの品質を望むのは恐らく、現実的にはムリ。

但し、次のような「機械翻訳を入れたらどんなメリットがある?」という捉え方で触れると、結構発見やアイデアがあるのではないか。

困ったときに検索してもキーワードが引っかからない現状 → 検索にヒットする母体数が圧倒的に増える
最新情報を、日本語を部分的によりどころにしつつ、追っかけることができる
読んでいて意味が通る部分はそのままとして、日本語訳として提示されたものが意味不明としても、オリジナルの英文で確認すれば済む。結果的に、ほしい情報に目を通すための所要時間を減らせる。

デメリットは次のようなものか。

単語レベルで訳語の選択が違う(専門用語、フレーズの訳出、文脈の判別) → 訳出の正確性を保証できない。読み手としては、意味を取れないことがわりとあるかも?
もともとの内容が難解であり、日本語をヒントにしようとしたが、意味を取れないので逆に混乱(各種 Technical Reference や新製品近辺でありそうかな…)

キーワードでヒットするものが増える限り、また、オリジナルを確認しやすくなる限り、歓迎したいかな。

メモ: MSDNS(2000/2003) → BIND9 on Windows とするときの注意

YamaKen — Wed, 15 Nov 2006 23:45:00 GMT

これまた取り留めないが... MSDNS で持っているゾーンを、 Windows 上に立てた BIND セカンダリで受け止めたり、 BIND 側をプライマリにするようなときに関連。

大まかには、次の文書(Windows 2000 のヘルプ) でいっていることを、ソースと目的地を変えて行うことになる。

http://www.microsoft.com/windows2000/ja/advanced/help/default.asp?url=/windows2000/ja/advanced/help/sag_DNS_imp_MigrationIssues.htm

この文書では BIND4 をソース、 MSDNS を目的地としているのだけど、それと逆の方向で、 MSDNS をソースで BIND9 を目的地としたいってこと。MSDNS からほかのプラットフォーム上の BIND やほかの DNS サーバの実装に換えるときも、構成の流れは殆ど変わらないだろうと考えている。

で、ゾーンファイルの移し方などはそっくりそのまんま。プライマリを MSDNS から BIND で置き換えるなら一度、 BIND をセカンダリとして立てて、既存プライマリと同期の上、ゾーンの種類を変えるのがラク。(named.conf 上の設定)

一度立ててしまえば、メンテナンスそのほかはほかのプラットフォーム上で動かす場合と変わらない(と思う。)

尚、上の文書は古い時代のもののため、ゾーンファイルは BIND4 のゾーンファイルを念頭に置いた構成になっている。現在は BIND9 上に置くゾーンファイルの名前のつけ方としては、 [zone name].zone としておくのが推奨されている。(named 起動時、 check-zone ツールに読み込ませるため。記憶が定かではないが、多分、マニュアルか Linux 版の man で見た。)

■ 大まかなポイント

サービス実行ユーザのユーザコンテキストと権限 → 制限ユーザ+サービス実行権限(ローカルポリシで決めてよい。レジストリ設定不要。)
conf の調達と載せるオプション決定、 rndc (リモート管理ツール)用の鍵の作成
ゾーンファイル、ルートヒントの調達

1. は少なくとも Windows 版の最新版のインストール時の動き。まぁ妥当でしょうかね。

オチたときも余計な権限持ってないコンテキストで動いていたならば、システム全体に与える影響も少ないから。(バッファオーバフローなどでオトされたときのことを想定)

2. 以降は後述。

■ 時間がかかる点: rndc.key, rndc.conf, named.conf の作成

ほかの OS 版と違って Windows 版は named.conf のサンプルついてないので、マニュアルを見ながらしこしこつくる。

rndc (BIND9 用のリモート管理ツール) 周りの扱いは UNIX/Linux 上で稼動させる場合との違いはない。

専用のコマンドをたたいて鍵(rndc.key)を作り、rndc.conf に入れる。この rndc.conf と named.conf で鍵が一致している必要アリ。 rndc.conf は rndc という管理ツールで。クライアントから提示する鍵と、管理ツールである rndc 及びサーバである named が持つ鍵が一致しなければ認証が通らず、管理を行うことが出来ないという仕掛け。 SSH を使える場合はコレを敢えてリモートから使わなくってもいいんじゃないかと思う。 rndc を直接通さないでもシェル動せれば、コマンドはたたけるから。

リモートから管理を行わぬ、ローカルのみで管理の場合でも、 rndc を用いて管理をするならば、鍵は作っておくこと。 rndc.conf と named.conf 両方で同じものを使う。

named.conf かき方の順序として、おーまかには

名前付き ACL を定義(→アクセスリストで使う。 IP レンジを毎度毎度、書いていられないでしょ。間違えたらイヤだし。)
全体動作のオプション(rndc で使う鍵や、 DDNS や DNSSEC など)
ログオプション(既定はイベントログの「アプリケーション」に吐く。syslog やテキストファイルに流すこともできるため、適宜チャネル、ログカテゴリ、ログレベルを決めて定義する。)
ビュー、ゾーンの定義(プライマリ、フォワーダ、スタブ、セカンダリか等)

を一個一個作っていく。或いは、面倒くさければ BIND を稼動しているほかのマシンから、 named.conf を持ってくる。

named-checkconf というツールで構文確認を実施出来るので、作り終わったらこのツールを使って、自分の書いた構成、内容に間違いがないことを確認のこと。forwarders 等にうっかり「名前つき ACL」を使わぬこと。名前つき ACL はココではなく、ビューやゾーンで IP レンジを基準にクライアントに許可する動作をキメる時に使う。丸ごとコピーする場合でも、 rndc の鍵のトコと名前つき ACL 及びゾーンのアクセス許可リストの構成は意識して見直すこと。

■ ゾーンファイル、ルートヒント

これも基本は、ほかの OS の上で動く BIND の場合と相違なく。BIND に乗っかってしまえば、あとは named-checkzone, dnslint などの道具で確認を行うこと。

ゾーンファイルを持ってくる方法としては、非 AD 統合の状態の Windows Server のオプションコンポーネントとしての DNS であれば、ゾーンファイルをそのままコピーして持ってくる。 AD 統合 DNS であれば dnscmd.exe で対象ゾーンをエクスポートする。

■ _msdcs.[domainnname] のゾーンを持ってくるときに注意すること

named.conf にて、そのゾーンのみ check-names を無効にする。そうじゃないと、 _gc あたりの記述を毎起動時に引っ掛けてしまう。複製は失敗する。

■ Windows DNS 側の設定(管理ツールからでも dnscmd.exe からでも。)

WINS 統合のゾーンのセカンダリを BIND で補う場合は WINS レコードをレプリケートしないこと。(設定あり)
→ レプリケートする設定だと、 WINS レコード(@WINS) が非 MSDNS のサーバに送信された際に、そのサーバが複製データを受け取らずに破棄するから。 (NT3.51 リソキの DNS Server 時代から引き続いている話。)
セカンダリゾーン: 通知先とも、既存のプライマリ or セカンダリと新規に立てたものとの間で、複製を許すこと。

■ クライアントのネットワークインターフェース自動登録の動き(DDNS)

クライアントは次のように動く。参照先がどうあろうと SOA を持つサーバと通信して、レコード更新ができればよい。

Primary/Secondary DNS(NIC の設定。参照先にしている DNS ってこと。)を見る

↓

登録したいゾーンの SOA レコードを参照し、「書き込む相手」としての、そのゾーンのプライマリ DNS を参照する
(SOA すなわちそのゾーンのプライマリ役を負うノード以外からは通常、書き込みは行えないから。)

↓

SOA レコードにある DNS サーバに自動登録をリクエスト。

■ 立てる手間など

BIND を触りなれたひとなら、多分ものの数分～20分以内で、動く構成は作れるんじゃないでしょうかね。ゾーンの見せ方、ビューの定義、名前つき ACL の定義など、 named.conf を書く前の段階でデザインのセンスが要求されてくるかと思います。

■ そのほかコメント

MSDNS 管理を行うヒトはぜひ、 BIND にも触れて欲しい。そうすることで、 DNS サーバについて、より理解を深めることが出来るから。MCP 試験の 70-291 受験者もね。そこもひっくるめて、ネームサーバの動きを学習中のひとは、 BIND を動かせるようになったところでバッタ本を読了してみること。触る前には朧気にしか見えなかったところが、クリアにわかるようになってくる。そのための手っ取り早い足がかりとして、 Windows 版 BIND を触る、というのを推奨したい。

「インフラストラクチャの最適化」(TechNet)

YamaKen — Fri, 10 Nov 2006 22:06:00 GMT

TechNet では先般の東雲さんの紹介にもあったとおり、主にインフラ管理に従事する、 IT Pro といわれる技術者層のための各種技術情報の提供を行っています。

このコーナでは、業務改善、管理状態の改善を通じて「受身」から「予防対策で先手を打つ」「戦略的資産」への進化、のロードマップを示しています。

インフラストラクチャの最適化

ここで提供されている内容を大まかに纏めると、

概要(で、結局どういうこと?、を説明。)
モデルの説明
現状把握のための評価サービスほか
段階ごとの課題提示
- 第一段階: 安定化 (stabilized) ← 標準がないか徹底されていない状態。手動での管理オペレーション。ここでの命題は機能を集中化し、標準化に向かう礎とするというトコ。
- 第二段階: 標準化 (standarized) ← 標準とポリシを使っての管理は行っている状態。(但し事業に密接には結びついていない?)
- 第三段階: 効率化、合理化 (rationalized) ← 事業部門の「ベストなパートナ」として動く。常に予防的管理を徹底。
- 第四段階: ダイナミックなシステム(Dynamic) ← 自律システム化、自動化 (dynamic, active, proactive, self-managing) を進め、継続的な運用や、そのための各種オペレーションを「動的」に構成、実施する仕掛け
関連情報として、ライフサイクル全体を視野に入れた WSSRA (一年前の大西さんの記事を参照。設計以降どの段階で触れるにしてもかなり大事なので必見、の扱いです。) や、 MOF (オペレーション業務のフレームワーク) の提示

といったところでしょうか。少しだけ気をつけたいところは、第一段階～第二段階のインフラサービスの扱い。(特に、 DHCP)

こういうトコでの文書や MSU/MCP 等の教科書的には、確かに DHCP でネットワーク上のノードの構成を管理できればラクなのですけど、環境によっては、これをやろうとすると、 IP アドレス管理や物理的セキュリティの管理枠組みの変更なども相俟って、なかなか進まないというのが実際のところではないかと思います。

DHCP を使うとして、「利用登録をしていない持ち込みマシン等のネットワークへの接続の可否を制御する」には MAC アドレスフィルタを設定したりするなど、検疫ネットワークや、スイッチ等のネットワーク機器など、実際の投入先で関連する設備でも、整合の取れた対応が欲しい部分です。また、 DNS の扱い等、あんまり詳細に突っ込んだことを書いてないですね。こうした細かいことの濃淡は別として、総じて「何をすればよいか」の指針となる位置づけのドキュメントとしては、役割を果たしているかと思います。

自分のかかわり方、意識の向き先は第一段階、第二段階がわりと多いのかと、改めて認識しました。(但し、コードをこしらえるときは第四段階も特に意識していますが。)

Cisco: News@Cisco Podcast "Strategic Market"

YamaKen — Fri, 15 Sep 2006 00:03:00 GMT

モトネタはどのカンファレンスだったかな。技術者向けカンファレンスのようだが。Cisco の「仮想化技術」はなにをどうあつかうことを指しているのかちょっと、イメージできていない。自分にとっては新しいこと、を入手できるので楽しいのだけれど、三度に一度は、概念からはじめて触れるものがあるのがちょっとキツい。

帰宅途中の電車で聴き、頭に残っている限りではあるが、この Podcast のうち、昨日入手した "Strategic Market" というプレゼンテーションの配信(MP3音声ファイル)で Jayshree Ullal 氏 (Datacenter Group 担当のシニアバイスプレジデント) が語った要点は

Consolidation (いわゆる、サーバなどの統合であったり、サーバのブレード化、各機能ごとのファーム化の近辺の話題。)
Security
Virtualization (one to many & many to one というあたりと、「ネットワークの仮想化」)

の三点。どれをとっても、サーバ周りを考えるときに避けて通れない課題。Consolidation(⇒各コンポーネントを「緊密に繋ぐ」),Security はまぁ予見できるとして、 Virtualization にも意欲を見せているのは、やや意外だった。 VMWare のような、サーバの仮想化だけではなく、ネットワークの仮想化、が提示されていた。(但し技術詳細は失念; VMWare, ZEN, MS Virtual Server などとは少し違うアプローチがメインディッシュ。)

ということで、理解が甘いのでまた後で確認してみよう。 37 分あるので、ちょっとゆっくり集中できるときにでも。

モトネタになった Podcast の入手元はコレね↓

News@Cisco

Windows 技術全般: ITPro が知っておくべき設計開発領域の内容

YamaKen — Mon, 04 Sep 2006 12:30:00 GMT

今回の TechED に触発され、というところもあるが、次のような内容は早期にマスタしておくべきことだろうと考えている。趣味、興味の方向性から、VBScript によるコーディングと、製品全体の設計、アーキテクチャに偏っているのは認めるけど。
# マジに仕事に活かしたいなら、これにプラスして、実装手順等と実務での落とし込みをもっと掘り下げなきゃだよなぁ...

■ IIS7 (現状は Pod/Webcasts とか、過去の PDC やTechED のセッションとか。)

新機能
改廃される機能
これらに関する操作
ASP.NET (2.0 or higher) ← 各種設定が関連するため。アプリケーションを「書かない」としても「何のために」(目的)、「何を」(対象)操作するのか、その内容は何か、を把握すべき。

■ Windows OS (MS サイトに現状でも色々ある。 MCP 試験で言えば、ネットワーク関連機能については歴史的経緯と 2000 での実装概要は 70-216/218 を、 2003 での使い方、設計の仕方については 70-291/293/297 を参照。 Windows Server Hacks にはコマンドや、主要なサービスに関する Tips が一部掲載)

Active Directory (Windows Server と切っても切り離せないだろう)
→ 試験でいけば営業知識レベルなら MCA、技術概要なら 70-217/219/294 を。言うまでもなく TechNet 等にさまざまな情報あり。 US の Podcasts/Webcasts も Active Directory Inside Out シリーズなど、一本一時間～二時間程度のセッションの詰め合わせあり)
NAP (検疫ネットワーク) ← 今の時点で実装していないなら、LongHorn での実装に注目すべき。このほか、検疫の現状の実装(各社)を見ておくのもよし。
パケットフィルタ
グループポリシ(ローカルでも、ポリシの多段構成が可能になるため)
各種ネットワーク設定を手動で実施し、確認する方法
同じくネットワーク設定の自動化可能部分と実施方法 (OS 標準コマンドと、VBScript)
WinRM (Windows Server 2003 R2 以降; MS サイトのほかは、オライリーの Windows Server クックブック付録に記載あり)
→ SSL を経由したコマンドライン操作及び、ハードウェア筐体のログ(これまでは SNMP を通じ、メーカ別に専用の管理アプリケーションを経由しなければ見えなかった部分)を操作できる
IPSec (概要と、操作方法、利用方法) ← OS バージョンごとにコマンドライン操作の方法が違うので注意。 MCP 試験でも出題される。(特に 2003 トラックのネットワーク関連科目)
RADIUS (本来の用途と Windows Server での利用の意味、目的とソレに付随する拡張。LongHorn は現状のニーズと密接したトコに注目して、実装を行っているため、機能概要と利用方法の現状をまずは理解すること。)
WMI (とりあえず、使う言語は VBScript でよい)
QoS
IPv6 はじめとしたプロトコルスタックの実装
シェル (Windows PowerShell 及びレガシなバッチファイル)

■ Exchange Server 2007 (製品サイト、 TechED、US の Podcast/Webcast)

Exchange 自身のアーキテクチャの変化と、「言い方」「摘要部分」の変化した機能の把握
新機能と、アーキテクチャのうちどの領域で「まったく新たに追加になった」のか
改廃する機能
Active Directory との関連
Exchange 2000/2003 からの移行手順
Exchange 自身に直接実装の障害回復及びパフォーマンス改善の概要
64bit への移行で間接的に利用できるパフォーマンス改善の概要
Windows PowerShell でどのようにコードを書くのか
→ GUI 操作と密接に関連しており、主要な操作については、管理ツール内で「 CLI を使うとどんなコードになるか」を画面表示する機能あり

■ コーディング関連

要件定義、仕様策定、目的の明記 (業務経験、という以外は未調査)
→ ここがハッキリしないと、とりあえずの納品は影響がない場合もあるかもしれないが、リプレイスするときに労力を割かなければいけないので効率的ではない。)
実現方法の部品化 ← ベターな実装に、部分ごとでも切り替えを行いやすくするように。
実行結果のレポート化 (何をどう操作して、どのような結果を得ているのか。中間段階と最終処理。)
→ Windows Server Hacks 及び Windows Server クックブック(オライリー)

■ 要件定義前後～設計

製品別のトコ → MS サイト及び、関連する MCP 試験(AD なら 297、 Exchange なら 285)
一般的 → 業務経験以外何か在るか? (未調査)
注記: ハードウェア調達に先立ってのスペック見積もりやパフォーマンス指標は公開部分で不十分な場合あり
コミュニケーションスキル(一般的なのかな? 未調査)
→ 打ち合わせして、案を出して、揉んで、 Fix しても尚、やりたいことと実装の乖離や、意図のズレってあるもんだし。

...一般的に利用可能なリソースのうち、これらを重点的に押さえられれば、 LongHorn 時代に備えることは出来るのじゃないかな。先のことなど誰にも判りはしないだろうけど。

雑記というかメモ: ファイアウォールのおき場所区分

YamaKen — Wed, 05 Jul 2006 01:09:00 GMT

どう転んでも営業知識の範疇になるわけだが。職人として時代に追いついてないことに、またひとつ気づいた次第 orz

ファイアウォールといっても、パケットフィルタを主眼とするもの、通信状態 (session state) をみるもの、アプリケーションレイヤまでみるもの、ホストベースのもの(通信ベースではなくアプリケーション側の動きに注目しているもの)と、やること、できることが違う。 OS で持ってる機能も含めて考えると、次のような区分で置き場を考えることが出来るだろうか。

最外周(境界; 捌く通信量如何にもよるが、通信を route することが主眼)～DMZ : パケットフィルタ型～stateful filtering
例: ルータ、多くの layer3 スイッチ、Symantec,Nokia などのハコモノ、ISA Server、 [Windows OS] IPSec, RRAS, TCP/IP filtering, [Open Source] IPTables, IPChains 他
内部(1) バックボーン: stateful filtering ～アプリケーション型
例: Symantec,Nokia などのハコモノ、 ISA Server, IPS 統合型各種ソリューション(ここ数年追っかけきれてないけど Sygate はじめとして幾つかのものがあるのは認知している...)
内部(2) サービス: アプリケーション型&ホスト型
例:
ISA Server、そのほか IPS 統合型各種ソリューション→ アプリケーション型
Windows Firewall、各サーバアプリケーションに特化したアプリケーション(専門向け)ファイアウォール(AppShield ほか)
内部: クライアント: ホスト型
例:
IPS 統合型各種ソリューション→ アプリケーション型
Windows Firewall、ZoneAlarm、の他、アンチウイルス、アンチスパイウェアなど。

(廉価ハードウェア、及びソフトウェアベースの)ファイアウォールに関しては次の領域との統合もキーポイントの一端か。別売りオプションじゃなくて統合。
比較の対象としてはハードウェアベース(SonicWALL 及び WatchGuard を主に。)の小規模版を念頭においている。

アンチウイルス等、関連領域との統合
アプリケーションレイヤへの対応
コンテンツフィルタ
VPN
4 つ以上の複数のネットワークセグメント
検疫ネットワーク (そろそろ実装は出揃ってきたか?)

ISA が特に強いってコトでウリにしてるのはこの辺だが、ほかのファイアウォール製品も 4. や 5. を除いて似たような機能を出してきている。(この辺は必ずしも競合と捉える必要はなく、組み合わせでフォローできる場合もある。)

IPS 統合型のプロダクト(Cisco のとか、Sygate のとか。)もあったりするので、もっと勉強しないと。＜自分

Tool: Ethereal now has a new home!

YamaKen — Sun, 11 Jun 2006 17:22:00 GMT

Ethereal の名前が WireShark と変わり、ホームサイトが変更になった。 http://www.wireshark.org/

これはオリジナルの作者、 Gerald Comb 氏が NSI から CACE Technologies (WinPcaP 等の開発をやってますね。)へ移籍するのに伴ってのこと。 (Ethereal は NSI が版権を持っているから。)

ということで、リンクを変更する必要があればお早めに。＜ALL

尚、中身は大幅には変わってない様子なので、書籍にあるような機能、或いはもっとフツーに、基本的な使い方は今のところ影響はないと思います。

Macintosh (Mac OS 10.2.x-10.3.2) から Active Directory にアクセスさせるときは ".local" ドメインサフィックスは不向き?(KB836413)

YamaKen — Sat, 08 Apr 2006 01:54:00 GMT

Syngress の How To Cheat At Managing Windows Small Business Server 2003 を通読していて目にしたトピック。
Mac OS X には Bonjour (以前 otsune さんにご紹介いただいた Rendezvous から名前が変わった。)という、名前解決を行うコンポーネントが ".local" のドメインサフィックスを用いることから、仮に Active Directory で .local を使う形でドメインを構成していると、Mac OS X 10.2.x 以降 10.3.2 迄を実行する Macintosh からは Active Directory 内の資源にはアクセスできなくなる。 KB 836413 ではこのことに触れている。例によって機械翻訳がちょっとアレなので原文を示す。

836413 You receive an "unexpected error occurred" error message when you try to access resources on a Windows-based network from your Macintosh computer
http://support.microsoft.com/kb/836413/en-us

対処方法は KB の中にあるとおり、Apple の技術文書107800にある対処を行う。10.3.3-10.3.9 迄はターミナルからコマンドを入力、 10.4 以降は GUI から設定の変更を実施する。

そういえば、このケースとは直接関連ないが、以前大西さんが紹介されていた WSSRA の一連の文書のうち、ネームサーバ関連の文書でも .local のドメインサフィックスは推奨されてはいなかったと記憶している。因みにWSSRA の文書、ヘルプ及び Self-Paced Training Kit はじめ Microsoft Press の書籍の範囲では、推奨プランとされているのは次の二つ。

ルートドメインの下に Active Directory 用サブドメインを配置
最も推奨されているっぽい。確かに、名前空間分けておけば妙な混乱は起こりにくい。
念のため、コレは Active Directory 固有のアプローチではない。BIND を使っていたりしても用途別にサブドメインを分けるというのはよくある話。
ルートドメインをそのまま使う。
とはいえ、外に公開するゾーンと中に公開するゾーンで「同じ名前のドメイン」且つ格納するデータを違えたゾーンを二つ維持する必要があるので混乱を生じたり、ゾーンファイルの中身が煩雑になりがち。こちらも、実際にはよくある構成ではある。

DNS&BINDの後半の構築例なども参考にしつつ、名前空間は綿密に構成したいものだ。

メモ: Windows Server 2003 SP1 のグループポリシと IAS を利用した WPA の実装関連資料

YamaKen — Sat, 01 Apr 2006 16:39:00 GMT

とはいえ、家庭用の安物だと WPA を実装した無線アクセスポイントってムリのような気がする。

PEAP およびパスワードでワイヤレス LAN のセキュリティを保護する http://www.microsoft.com/japan/technet/security/topics/cryptographyetc/peap_b.mspx