必要 - みる会図書館

1. UNIX MAGAZINE 2004年11月号

S S L 暗号化申し込みに必要なもの日本ジオトラストのクイック S S L プレミアム申し込みに必要なものサー・パ証明書発行中請書い第人 ( 現在も増加中 ! ) ラクしてトクした人の数→ クイック S S L プレミアム 0 サーバ証明書を 24 時間発行り面倒な公的書類不要 0 ご注文から導入まで全てオンラインで 0 98 % のプラウザで使用可能 0 個人の方でも導入可能上司に決済のお時間をいたたきます上司の印鑑をお借りくたさい法務局まての往復時間をお調へ下さい法務局まての往復交通費も申請して下さい法務局に行列する時間も計算にいれて下さい登記簿謄本申請書に記入漏れはありませんか登記簿謄本発行手続きの時間も必要てす印鑑証明申請書へこ記入下さい印鑑証明書発行手続きの時間もかかります印鑑証明書はなくさすにおもち下さい登録印鑑もお忘れなきようお願いします個人の方のお申し込みは、お受けしておりません 32 400 円 ~ ( 税込み ) 1 2 8 b i t S S L サーバ証明書年額もっとカンタンに取れればいいのに・シオトラストラクするあなたは、トルの臼し 6 s s L の設定に自信のない方、設定作業を行う時間のない方へ http://www.geotrust.co.jp/ もっと信じられるインターネットをる GeoTrust JAPAN くわしくはこちら〒 150-8512 東京都渋谷区桜丘町 26-1 セルリアンタワー 10 階 TEL: 03-5728-1551 ( 代表 )/FAX: 03-5728-1552 お問い合わせメールアドレス :info@geot 「 ust.co. jp 日本ジオトラスト株式会社

2. UNIX MAGAZINE 2004年11月号

文房具としての UNIX 図 2 ー舟勺な PXE ブートの様子カルのハードディスクに依存せずに起動する方法です。ハ PXE ブートするードディスクを使っていないので、いきなり電源を落とし DHCP 計算機サーバーても問題はありません。サーバー上にディスクレス・クラ ( 1 ) PC / AT 互換機の起動 - - ( 2 ) DHCP リクエストイアントをサポートする仕組みを作れば、クライアントをインストールする必要もありません。さらに、インストー ( 3 ) 設定情報ルの必要がないわけですから、追加のハードウェアさえ用意できれば、いつでもフロントエンドを増強することができます。こうして、、、自由なフロントエンド " プロジェクトは、・ディスクレス・プートで OS を起動し・コンテンツは NFS で共有するという方針で進めることに決定したのです。したとおり、 IPv4 アドレスやゲートウェイなど、ネットワディスクレスへの道ークへの接続に必要な情報を自動的に取得するための仕組前述したように、ディスクレス・プートとは、ネットワみです。一方、 TFTP (TriviaI FiIe Transfer protocol) ーク上のサーバーから必要なイメージを読み込み、それをは、ネットワーク経由でファイルを転送するための仕組みもとに起動する仕組みです。取得したイメージをハードデです 6 ファイル転送の方法としては FTP や HTTP が有名はすが、 TFTP は仕組みがた 0 ん単純化されて 0 、るイスクに書き出す必要もないので、ハードディスクをもたない引機でも OS を起動できます。もちろん、 OS も何ことか特徴で、ルータのファームウェア・アップデートや、もない状態から起動するため、ディスクレス・プートをおさまざまな機器の設定ファイルの読込みなどに利用されてこなうにはネットワーク・アダブタの対応が必須です。います。このディスクレス・プート、あまり馴染みがない仕組み計算機の電源を入れると、 BIOS のプートシーケンスのかもしれませんが、 UNIX の世界では昔から雹甬に利用さ設疋に従って起動の手続きが始まります。通常はハードデれていました。そして近年、 PXE という仕組みを備えたイスクやリムーバブル・メディア (CD-ROM やフロッピネットワーク・アダブタの登場により、 PC/AT 互換機でーディスクなど ) からプートするようになっていますが、も比較的容易に実現可能になりました 5 。 PXE (Preboot れらのメディアからのプートに失敗したり、設定でネット eXecution Environment) は lntel が策定したネットワワーク・プートがさきに指定されていると、 ( ネットワーーク・プートのための規格です。ちなみに、 N 十 I で TTS ク・アダブタに ) 順番がまわってきます。すると PXE プに利用したプレードサーバーには、 NetBSD 上で wm としートの出番です。て言哉される lntel PRO / 1000 MT が載っており、 PXE 1. PC/AT 互換機の電源を入れると、 BIOS による自己診プートに対応していました。断テスト (POST : Power On Self Test) などがおこ一般的な PXE ブートの手順なわれます。続いて、上記のようにプートシーケンスの設疋に従って起動できるメディアを探します。ネットワーヨ殳的な PXE プートの様子を図 2 に示します。ーク・プートの順番がまわってくると次に進みます。関係するのは PXE プートする計算機のほかに、 DHCP 2. PXE 対応のネットワーク・アダブタが DHCP でアドサーバーと TFTP サーバーです。 DHCP は前回も説明レスを取得しにいきます。この DHCP のリクエスト 5 PC/AT 互換機でネットワーク・プートを見するための仕組みは、 ether - には、、、 PXEClient" という文字列から始まる vendor- boot などをはじめとして、これまでさまざまなものがありました。しかし、ネットワーク・プートが -- 難りになり始めたのは、やはり PXE カ噎場してからのような気がします。 6 RFC1350 (http://www.ietf.org/rfc/rfc1350.txt) 連載 , 07 TFTP 山 Xd ( 4 ) TFTP リクエスト ( 5 ) 指定されたファイル ( 6 ) 取得したファイルの起動 97 UNIX MAGAZINE 2004. 11

3. UNIX MAGAZINE 2004年11月号

文房具としての図 8 ルート・ファイルシステム用のファイルをカーネルに埋め込む # mdsetimage —v netbsd /tmp/rootfs ・ img ←手順 1 で作ったカーネルのあるディレクトリで実行連載 07 copying image /tmp/rootfs. img intO netbsd mapped netbsd got symbols from netbsd done copying image exiting もあるのです。際には無理でした・。それに、大きくなったとしてもたかだか 64MB 10 いくつカカーネル・オプションで大きくすることができそうでしたが、実す。テムを供給するもう 1 つの方法としては、 NFS がありまさて、ハードディスクをもたない引機にファイルシスメモリティスクか NFS か ? ( 2 ) 予感、ですね。ろいろと必要でしよう。これこそ現場でトラブル大発生のす。また、システムファイル自体の容量を減らす工夫もいせいいつばいで、 Apache などを格納するのは厳しそうでないのです 10 。これではシステムファイルを入れるだけで埋め込めるファイルシステムの大きさは、 12MB ほどしかさらに致命的な問題があります。じつは、カーネル内に埋込み可能なファイルシステムが小さいたのです。なに面倒なんか・・・・」ということをお伝えする前末もあっこまで長々とメモリディスクの説明をしたのは、「こんになること間違いなしです。なりません。この手順の煩雑さは、現場でトラブルの原因順 ( もちろん、 newfs は必要ありません ) を踏まなければそして、取り出したイメージに対し、図 7 とほば同一の手には、 mdsetimage を -x オプション付きで実行します。カーネル内に埋め込まれたファイルシステムを取り出すけですから当然ですね ) 。てしまうのです ( メモリ上にあるファイルを書き換えるだ中の言 1 噂機のファイルを書き換えても、再起動すれば消えシステム上のファイルを変更しなければなりません。稼動ァイルを変更したくなったら、カーネル内にあるファイルメモリディスクを利用した方法では、システムの設疋フファイルの変更にひどく手間がかかる UN 工 X MAGAZINE 2004. 11 NetBSD をはじめとする多くの UNIX 系 OS では、 NFS でルート・ファイルシステムの供給を受けることができます。 NFS ですから、メモリディスクのときのようにファイルシステム容量の問題はありません。また、サーバー側からみると供給する部分はファイルシステムの一部なので、ファイルの謝奐えも簡単です。ちょうど ( ? ) TTS のコンテンツ部分は NFS で供給することにしていたため、ルート・ファイルシステムを含め、すべてを NFS で供給するのは簡単そうです ( 最初からそうしとけよ ! という声も聞こえてきそうですが ) 。ところが、何も考えずにすべて NFS にすればいいかというと、そうは問屋カ啣しません。複数のフロントエンドで共有してはいけないディレクトリがあるのです。それぞれのホストが同じファイルに対して書き込むようなものは、共有することができません。たとえば /var/log には、各ホストカ呆存するログファイルがありますし、 /var/run には、サービスを提供するプロセスの PID がされたファイルが保存されています。このようなディレクトリは、おもに / var 以下に集中しています 11 。ー引殳にこのようなディレクトリは、 NFS クライアントごとに異なるディレクトリを供給する設定をし、衝突を避けるような方法をとります。しかし、これを実現するためにはクライアントごとに異なる設定が必要になります。 TTS の場合は、運用中にフロントエンドが増加する可能性もあったので、これはあまり嬉しくありません。できれは、設定を変更することなく、フロントエンドを増減できるようにしたいものです。ところで、 /var に生成されるファイルは必要でしようか ? TTS におけるフロントエンドの場合、 /var に書き込まれるファイルで重要なものはログくらいです。そのログにしても、 syslog を利用すれは弛のサーバーで収集するこ 11 var は "variable ( 可変の ) " という未で、運用中に変更カ功日えられるファイルを集めたディレクトリです。 101

4. UNIX MAGAZINE 2004年11月号

文房具としての図 1 システムの概要連載 07 データベース用プライベート・セグメントはできません ( アドレスもプライベート・アドレスを利用しています ) 。なお、バックエンドからサーバー・セグメントに延びる線は、バックエンドのメンテナンス用です。のネットワークを通じて、外部のホストからデータベースにアクセスすることはできないようになっています。フロントエンドがいつばい図 1 からも分かるように、たくさんのフロントエンドが用意されています。フロントエンドの数カ寸曽えれば、ある程度までは負荷は軽減されます。それはいいのですが、数カえれば管理がたいへんになります。図 1 の構成は今年のものですが、 2003 年の N 十 I で運用したシステムも、これとほば同じような構成でした。 OS はすべて NetBSD で、フロントエンドは現地に入ってからインストールを始めました。 Web サーバーとして利用者からのリクエストをさばく必要があるため、 Apache などのアプリケーションもインストールしました。フロントエンドの構築に必要な作業はこれだけですが、昨年は 5 台のフロントエンドを用意したので、上記の作業を 5 回繰り返したわけです 2 。ふだん NetBSD で生活しているとインストール作業にも飽きていますし、黙々と 5 台ぶんのインストール作業をしていると、すべての構築が終ったころにはもう疲労困憊です。 2 dd でコピーすればいいやん、と思う方もいるかもしれませんが、プレードサーノ←を利用したので、手間はどちらも同じようなものでした。 HTTPS アクセスサーバー・セグメント L2 負荷分散負荷分散装置バックエンドフロントエンテータベースアクセス UNIX MAGAZINE 2004. 11 しかも、インストールが終ればそれでおしまいではありません。 web サーバーはすべて同じコンテンツをもたなければならないので、 TTS 自体のコードも 5 台のサーバーにインストールする必要があります。このコードはまさに開発途 - ヒで、現地での利用者からのリクエストに応じてどんどん改善されていきます。そしてもちろん、コードを書き換えるたびに 5 台のサーバーにコピーして回らなければなりません。 2003 年の N 十 I はこうして過ぎ、「もうコピーして回るのはいやや ! 来年はなんとしてでも楽するで。しかも、ちょっとぐっとくる方法でやるんや ! 」と固く心に誓ったのです。自由なフロントエンドその後、案の定そんな誓いなどあっさり忘れ去っていたのですが、今年の N 十 I の開催が近づくにつれ、コピーを繰り返す去年の自分の姿カ胡畄裏によみがえってきました。「あかんあかん、今年はなんとかせんと、また不自由なフロントエンドに縛られて、コピーだらけで疲労困憊の日々や」そこでます、何ができると楽なんだろうということをじっくり考えてみました。コンテンツのコピーはしたくない今年のシステムは心機一転、 PHP53 で一から書き直したものです。そのため、去年と同様、現地での変更や改善が頻繁に発生することが予想されました。去年のままだと、同じようにコンテンツのコピーが頻発してしまいます。また、あとで説明するように、会期中にフロントエンドカ寸曽減する可能性もあります。このような事態にも、うまくコンテンツの一貫性を保てるような方法が必要です。インストールの手間はできるだけ減らしたい現地に入ってからのインストール作業も大変です。とくに、プレードサーバーを利用するので、あらかじめハードディスクを用意していくことはできません。また、ハードディスクを取り出すのもすこし面倒ですから 4 、 dd してハードディスク・イメージをコピーするといった方法も避け 3 N 十 I の会期カ冬った時点で RC3 でした。 4 雹甬の PC でも面倒といえは面倒なので、手間は変わらないのかもしれませんが・・ 95

5. UNIX MAGAZINE 2004年11月号

特集図 22 青鉑勺な Tag VLAN 言窈列 ( 日立 GS4000 ) # show running—config vlan 100 untagged—port 0 / 0 ー 1 tagged—port 0 / 4 vlan 200 untagged-port 0 / 2 ー 4 tagged¯port 0 / 5 ただし、端末側からも以下に紹介するようなコマンドを実行すれは設定できます。検疫型ネットワークにおいて、端末側からの要求によってネットワーク接続を動的に変更する場合、このような Tag ID の設疋だけで対処できるのは単純で使いやすい仕組みだと思います。 BSD FreeBSD/NetBSD/OpenBSD いずれにおいても、 Tag VLAN は仮想インターフェイスとして実装されています。そのため、 Tag ID と対応する物理インターフェイスを適切に設定すれば、 Tag VLAN 接続を変更することができます ( 図 23 ) 。 Linux Linux でも、 Tag VLAN は仮想インターフェイスとして実装されています。図 24 に、 Tag VLAN 設疋ツール (vconfig) の実行例を示します。ただし、標準ではこのツールが導入されないディストリビューションもあります ( その場合には、 RPM などで別途インストールする必要があります ) 。 Windows lntel 系の Ethernet NIC 用の Tag VLAN 文寸応ドライバが、 lntel から配布されています 15 。このドライバを使えば、 TagVLAN を仮想的なインターフェイスとして利用できるようになります ( 図 25 ) 。なお、この Windows 実装では、 Tag VLAN を成疋した物理インターフェイスにおいて直接 (Tag VLAN を使わずに ) Ethernet フレームを入出力することができなくなります。 15 http://support.intel.co ・ jp/jp/support/network/ adapter/prol()()/index. htm 48 ボスト・ファイアウォールとネットワーク・セキュリティ Tag VLAN によるネットワーク分割の課題 Tag ID を端末側、スイッチ側のどちらで設定する場合にも、 Tag ID の端末やスイッチへの配布・更新方法カ題になります。とくに、この Tag ID の詐称につながるような攻撃への対応は重要です。 Tag VLAN によるネットワーク分割では、基本的にこの Tag ID にもとづいてアクセス制御などのセキュリティ処理がなされるため、 Tag ID の詐称はきわめて深刻なセキュリティ上の脅威となるからです。また、 RA (Router Advertisement) を用いて IPv6 アドレスを自動設定している場合、ネットワークを変更しても、旧い IPv6 プレフィックスの肩効期限が切れすに残ってしまうことがあります 16 この問題を解決するには、・ TagVLAN を収容するルータのリンクローカル・アドレスを Tag VLAN ごとに変える・ DHCP によるステートフルな自動設疋をおこない、管理者側で端末のアドレスを強制的に奪えるようにするといった対策を講じる必要があります。これらの問題についてはさまざまな答が考えられますが、どれが最善かは導入・運用コストと得られるセキュリティ・レベルとのトレードオフで決まるものであり、一概にどれがよいとは断言できません。というよりも、現状ではこうしたトレードオフの評価がもっとも重要な課題であるといったほうがよいでしよう。 DHCP DHCP (Dynamic Host Configuration Protocol) [ 12 ] は、ネットワークに接続された端末に対してネットワークに関する設定を自動的に配信、設定する目的でひろく使われているプロトコルです。 DHCP サーバーが設疋されているネットワーク・セグメントでは、 DHCP 機能を有効にした端末は特別な操作なしに、サーバーから配信された IP アドレスをはじめとする各種設定情報を自動的に設定します。これにより、ユーザーはネットワーク設定をとくに意識することなく、物理的にネットワーク・セグメントにつなぐだけで通信に必要な設定ができる仕組みにな 16 ネットワークの変更後、旧いデフォルトルータに到達可能なかぎり、旧い IPv6 プレフィックスは寿命に達するお 0 肖えません。 UNIX MAGAZ 工 NE 2004. 11

6. UNIX MAGAZINE 2004年11月号

特集ボスト・ファイアウォールとネットワーク・セキュリティ図 15 PANA と AAA プロトコルの組合せ PaC 認証メソッド EAP PANA 4 認証サーバー認証メソッド EAP AAA (RADIUS/ Diameter PAA EAP ( バススルー・オペレーション ) AAA (RADIUS/ PANA Diameter ( 注 ) 下位レイヤは省略図 16 PANA モテル PANA データバケット PAA PaC EP Secure Association P 「 0t0C0 ー SNMP または API アクセス制御 / ヾラメータ設定 (PAA → EP) PaC プレゼンス通知 ()P → PAA) インターネットることも可能です。この場合、 PAA は PaC と認証サーても PANA の認証手順を起動できるようになります。そバーとのあいだで EAP メッセージを中継しますにれを、の結果、ユーザーはアクセス・ネットワークを利用する前、、 EAP パススルー・オペレーション " といいます ) 。このに、そのネットワークで認証が必要かどうかを事前に知る場合、 PAA と認証サーバーとのあいだの EAP メッセー必要がなくなります。ジ車幻医には、 RADIUS [ 9 ] や Diameter [ 10 ] などの AAA PAA と EP は、同一の機器にも異なる機器にも実装でき (Authentication, Authorization and Accounting) プます。 PAA と EP が異なる機器に実装された場合、 PAA ロトコルを使用します ( 図 15 ) 。は SNMP を用いて EP と通信します。 PANA のメッセージ交換そのものには関与しませんが、 EP がデータバケットの号化 / 認証をともなうフィル PANA と密接な関連をもつ重要な機能要素として、データタリングをおこなう際 13 には、 PaC と EP のあいだでバケットのフィルタリングをおこなう EP (Enforcement Secure Association Protocol" と呼ばれる鍵交換プロ Point) があります [ 11 ] 。図 16 を参照しながら EP につトコルにもとづく通信がおこなわれます。 Secure Associ- いて説明します。 ation Protocol は、データバケットの暗号化 / 認証に必要 EP とは、 PANA を用いて認証された PaC について、ノヾな暗号鍵などのパラメータを設疋するためのプロトコルでケット単位のアクセス制御を実行する機能要素です。 EP す。暗号化 / 認証に IPsec を利用する場合には IKE (ln- の機能をもつ機器の代表的な例が、無線 LAN アクセスポ ternet Key Exchange) を、 IEEE802.1 li を利用するイントやアクセスルータです。 EP へのアクセス制御パラ場合は 802.11i の 4-way ハンドシェーク手順を、 Secure メータの設疋は、 PAA がおこないます。 Association Protocol として使います。 EP は、 PaC の存在を検出し、 PAA に通知する、、 PaC プレゼンス通知機能 " ももっています。これにより、 PaC 13 データバケットの暗引ヒ / 認証は、 PaC と EP のあいだでおこなわれまから PAA に対してだけでなく、 PAA から PaC に対しす。 44 UNIX MAGAZINE 2004. 11

7. UNIX MAGAZINE 2004年11月号

連載 / ネットワークとセキュリティ図 5 展開したファイルを、 veb サーバーのルート・ティレクトリに発力 $ su # cd # mv base/ /var/www/html/ # mv base/ /usr/local/www/data/ ← FreeBSD で ports から Apache をインストールした場合 ← Red Hat 系 Linux で Apache を RPM からインストールした場合 # mv base/ /usr/local/apache/htdocs ← ソースコードから Apache をインストールした場合ィ・イベントを分析できます。 BASE のもとになっているのは、 CERT Coordination Center の AirCERT プロジェクトで開発された ACID (AnaIysis Console for lntrusion Databases) で、現在のところ ACID と BASE にほとんど違いはありません。しかし、 ACID は 2003 年 1 月以降、まったくバージョンアップされていないため、今回はバージョンアップがおこなわれている BASE を紹介します。 BASE は PHP カ材家動する Web サーバー (Apache など ) で動作します。今回は、 Apache 1.3.31 、 PHP 4.3.8 、 ADODB 4.52 、 JPGraph 1.17-beta で動作を確認しました。なお、 Apache と PHP のインストールについては BASE のインストール省略します。トリにファイルが展開されてしまうので注意が必要です。ディレクトリを作成しない場合には、カレント・ディレクに作成し、そのディレクトリ内でアーカイプを展開します。ダウンロード後、 BASE を展開するディレクトリを新た原稿執筆時点での最新版は 0.9.7.1 です。アーカイプの・ http://sourceforge.net/projects/secureideas/ ロードします。ます、 BASE のアーカイプを SourceForge からダウン ADODB のインストールトリへ移動します ( 図 5 ) 。展開したファイルは、 Web サーバーのルート・ディレク $ tar xvzf . /base-0.9.7.1. tar $ cd base $ mkdir base UN 工 X MAGAZINE 2004. 11 のインターフェイスを提供します。 ADODB のソースコ OracIe といった各種のデータベースを利用する際に共通タベース抽象化ライプラリで、 MySQL や PostgreSQL 、用します。 ADODB は PHP 4.0.5 以降で動作するデー BASE は、データベースへのアクセスに ADODB を利ードは、・ http://adodb.sourceforge.net/ からダウンロードできます。 ADODB のインストール作業は、ダウンロードしたソースコードを展開し、ファイルを移動するだけで完了します。 $ tar xvzf ad0db452. tgz $ su # mv adodb/ /var/www/html/base/ これは Red Hat 系 Linux の場合です。他の環境の場合には、図 5 の例を参考に /var/www/html/base の部分を読み替えてください。 JPGraph のインストール JPGraph は BASE の動作には必須ではありませんが、これをインストールすることで侵入検知結果をグラフ化できます。なお、 JPGraph を利用するには、 GD ライプラリカ陏効化された PHP 4.3.0 以降が必要です。 JPGraph は、・ http://www.aditus.nu/jpgraph/jpdownload.php からアーカイプをダウンロードします。 JPGraph のインストール作業は、 ADODB と同様にダウンロードしたファイルを移動するだけで完了です。 $ tar xvzf jpgraph—l .17—beta. tar. gz $ su # mv jpgraph¯l. 17—beta/src/ , /var/www/html/base/jpgraph これも Red Hat 系 Linux の場合の例です。さきほどと同様、環境に応じて /var/www/html/base を読み替えてください。 BASE の言 BASE を利用するためには、セキュリティ・イベントの取得元となるデータベースなどの設定をおこなう必要があります。各項目の設定は、インストール先ディレクトリの 85

8. UNIX MAGAZINE 2004年11月号

表 1 アクセス手段とその不可肯域おも加最大 100Mbps 光ファイバー接続 FTTH 10Mbpsæ30Mbps 不呈度 CATV 接続 2Mbps—50Mbps 程度電話回線を利用した広帯士第妾続 xDSL 最大 11Mbps 802.11b による公衆アクセスホットスポット才第靃舌バケットサーピス 64Kbps 前後オペレータと使用通信方式によって利用可能な帯域カ畯わるて、 802.11b に準拠してさえいれば、海外製の機器では、ホットスポット・サービスが大きな利益を生むとは思も接続できる 1 。つまり、 802.11b 対応の機器を持ってえなし、。いるユーザーなら、誰でもホットスポットを使うことがたしかに、携帯電話ヨナービスと比較すれば、初期投資はできるのである、最近のラップトップ PC の多くには、はるかに少ないだろう。しかしながら、公衆電話と同じく、 802.11b 対応ネットワーク・アダブタカ肭蔵されている。ある程度以上の、、量 " がなければ便利なサービスと認めてしたがって、これらの PC のユーザーは、ホットスポッはもらえまい。ホットスポット・サービスが普及し始めたトの潜在的なユーザーということができる。とはいっても、たとえば、自宅の近くにホットスポットが・サービス提供範囲カ定されているある人は圧倒的に少ないはずだ。その未では、まだまだ基本的には、アクセスポイントから半径 40m 程度の範囲身近なサービスとはいえないであろう。にサービスを提供する。これまで、日本の無線系通イ言で量の問題はとりあえずおいておくとして、ホットスポッは、できるかぎり広く継ぎ目なくサービスを提供するこトの場合は、利用者がある程度の時間、滞留できるような空とを目標としていた。ところが、ホットスポット・サー間が必要になる。この点では、公衆電話の場合とは異なる。ビスは、提供或が地理的に限定されている。その他の公衆電話では、 ( たまには長電話をする人もいるだろう接続サービスと肩を並べたければ、必然的にアクセスポが ) たいていは短時間で会話カ鮗る。つまり、利用者が長時イントの数を増やさなければならないが、現状では数が間滞留できる場所に置く必要はないわけで、ほとんどどこ限られているようである。ビジネスの規模にしても、携に置いても大きな問題はない。ホットスポットはこれとは帯電話などの場合とくらべると、かなり規模が小さい印逆で、利用者が滞留できる場所に設置しなければ意味がな象を受ける。い。ホットスポットでインターネットを利用したい人は、固有のアプリケーションがないメールを受信して返事を書いたり、必要なファイルをダウホットスポット・サービスでなけれは利用できないアプンロードしたり、アップロードしたりすることが多いだろリケーションカ甘是供されていない。これは、携帯電話のう。それには、公衆電話よりも長い時間がかかる。したが市場展開とくらべると分かりやすい。携帯電話の場合、って、電源があり、机があり、利用者がゆっくり坐れるよどこでも電話を使いたいというニーズを満たすかたちでうな空間が必要になる。この点からみていくと、空港のラサービスが展開されてきた。これ 0 対し、ホットスポットは、サーカ甘是供され、 0 一 ; 所 0 = 行かなけれ 0 = 利ウンジや国際会議場のホール、コーヒーショップなどが適している。これら以外に、ホットスポットがうまく機能し用できない。そうなのはどんな場所だろうか。すぐに思い浮かぶのは駅携帯電話との対比でいえば、公衆電話をほっほっと設の待合室やファミリー・レストランなどだが、そのさきと置しているのと大きな違いはないように思う。どうも、なるとなかなか思いつかない。現在の PC の利用形態を考、、あなたの生活を一変させるサービス " という感じがしえると、屋外というのはかなり難しい。ないのである。米国では、一ヨ殳家庭へのプロードノヾンド接続の普及にはこういった背景を考えるならば、すくなくとも現時点でまだまだ時間がかかりそうなので、手軽にアクセスできるホットスポットの人気力皜まりつつあり、採算面で黒字化 1 802.11b オ剽鴟の規定を満たした国内の製品には、、 Wi ー F い材処 " と表記さしたところもあるようだ。しかし、日本ではプロードバンれている。連載 /UNIX Communication N0tes 62 UNIX MAGAZINE 2004. 11

9. UNIX MAGAZINE 2004年11月号

プログラミング・テクニック : 図 1 SRCS マクロに代入されているファイル群 clean—exit . c diag ・ c eval . c fix—options . c fromhost . c \ SRCS= hosts—access . c hosts—ctl . c misc . c myvsyslog ・ c options . c \ percent—m. c percent—x. c refuse . c て fC931. c shell—cmd. c \ socket . c t1i . c update . c workarounds . c libvars . c 宣言も付いていないので、これは外部変数の定義ということになります。ライプラリを構成するほかのファイルでは、この外部変数を利用してプログラムカ書かれています。しかし、変数自身の宣言はライプラリとしては利用しない別のファイルのなかでおこなわれているので、こで別に宣言しておく必要があるわけです。設定ファイルの読込み次に、設疋ファイルの言ムみについて考えてみましよう。設疋ファイルは人間カ毓みやすいように書かれており、かならずしも計算機にとって処理しやすい形式ではありません。そのため、通常は設疋ファイルの内容を読み込んで処理しやすい形式に変換したデータ構造として保持します。そして、設疋ファイルの内容が必要なときは、このデータ構造にアクセスして求める情報を取得します。通常のプログラムでは、このデータ構造をプログラムの起動時に作成しておき、以降はつねにデータ構造のほうを参照するのが普通です。そのため、プログラムの設疋ファイルを変更したときは、多くの場合、プログラムを再起動したり、設定ファイルの変更を通知する操作を実行するなど、特別な処理が必要になります。しかし、今回作成しているのはライプラリ・ファイルです。ライプラリ関数は、プログラムのどこから呼び出されるかが分からないため、設疋ファイルを読み込むタイミングをなんらかの方法で制御しなければなりません。ライプラリ関数のなかで設定ファイルを読み込む場合など、なんらかの初期設定が必要なときには、そのためのライプラリ関数を用意する方法があります。たとえば、ディレクトリ・エントリを読み出すライプラリ関数である read- dir は、利用する前に opendir ライプラリ関数を使って初期化しなければなりません。叩 endir 関数は初期化したデータを参照できるような値をハンドルとして返し、以降の readdir 関数の呼出しでは、このハンドルも引数として指定します。こうすることで、 readdir 関数の呼出しの際に UN 工 X MAGAZINE 2004.11 ハンドルを区別すれば、同時に複数のディレクトリを読み出す場合にも問題は生じません。この方法であれば、なんらかの後処理が必要になってもそのためのライプラリ関数を用意すれは解決できます。この方法の問題点は、ユーザーに前処理や後処理について意識させてしまうことです。ューザーの目的はメインの処理匪の例では readdir 関数 ) です。しかし、この関数を利用するには前処理ルーチン (opendir 関数 ) の呼出しが、処理を終了するには後処理ルーチン (closedir 関数 ) の呼出しが必要です。これを意識させない方法としては、プログラムのスタートアップ・ルーチンを変更して、前処理ルーチンをかならす乎び出すようにしたり、そのなかで atexit 関数を利用して後処理ルーチンを登録することも考えられます。ただし、処理対象となるハンドルが必要になったり、複数の処理対象のために複数回の処理が必要になるような場合には、簡単には対応できません。前処理や後処理の明示的な呼出しを避ける手段の 1 っとして、ライプラリ内で使う静的変数を用意する方法があります。この方法では、処理のルーチンの先頭で前処理をしているどうかを、あらかじめ用意した静的変数を使って調べ、していない場合にのみ処理をおこないます。 static int processed = 0 ; if (!processed) { 前処理 ( ) ; processed = 1 ; 本処理 ( ) ; このような処理をライプラリのインターフェイス関数に組み込んでおけば、ライプラリのユーザーが意識しなくても前処理を一度だけ実行することができます。このときの条件をネ礬隹にしたり、どの引数について前処理をしたのかを保持できるようにすれば、異なる複数の引数を用いた呼出しを区別しながら、前処理を必要な回数だけ実行することも可能になります。もう 1 つの手段は、前処理という考え方そのものをやめてしまう方法です。こまでの処理カ倒だったのは、前 89

10. UNIX MAGAZINE 2004年11月号

連載 192 ワークステーションのおと坂下秀図 1 ネットワーク構成 ( 1 ) SSL VPN 先日、勤務先で Juniper Networks の Netscreen Se- cure Access 3000 ( 以下、 SA3000 ) 1 を使う機会がありました。これは、いま流行りの SSL VPN を実現するための装置です。ます、 SSL VPN について簡単に説明してから、設疋や使ってみた感想を書くことにしましよう。 SSL VPN とは SSL VPN は、そういう名前の規格があるわけではなく、 SSL を用いて実現した VPN 製品全般を指す言葉です。これだけではよく分からないと思うので、もうすこし具体的に説明しましよう。ます、すべての製品で実現されているのは、、、 HTTPS で、インターネットから組織内の Web サーバーへのアクセス " という機能です。ここで重要図 2 ネットワーク構成 ( 2 ) なのは、糸騰設内の Web サーバーが HTTPS に対応していなくてもよいという点です。通常の HTTP でアクセスできる Web サーバーはそのままで、組織外からアクセスしたときには、 SSL VPN 装置が自動的に HTTPS に変換してくれるのです。ネットワーク構成としては図 1 のようになります。ネットワーク・インターフェイスが 2 つある SSL VPN 装置では、図 2 のような構成をとれるでしよう。一言でいえば HTTP/HTTPS 変換箱で、装置を設置して認証情報を設定し ( 装置によりますが、ローカルに認証情報を設定したり、 RADIUS や NIS 、 LDAP で組織内の認証サーバーを参照することもできます ) 、ネットワークを接続するだけです。単純ですが、たいへん便利です ( ただし、実装はけっこう大変です。たとえば、組織内の Web サーバーから送られてくる、 HTTP での URL 参照 (http:// ・・・・・ ) をすべて https に書き換える必要があり、 1 http://www.juniper ・ CO ・ jp/products/ssl/ この Secure Access 3000 は、マクニカネットワークスから借用したもそれなりの CPU パワーが必要です ) 。のです。定方法などの問合せについても、巡曲こ対応していただきました。 SSL VPN 装置で扱えるのは HTTP/HTTPS だ誌面を借りてお礼を申し上げます。インターネット HTTPS Web ブラウザから HTTPS でアクセス HTTPS ファイアウォー丿レ (HTTPS アクセスを SSL VPN 装置に転送 ) SSL VPNk 置 HTTP S HTTP 組織内の Web サーバー HTTPS インターネット Web ブラウザから HTTPS でアクセス HTTPS 外側のファイアウォール内側のファイアウォール SSL VPN 装置 HTTP 組織内の Web サーバー 139 UN 工 X MAGAZ 工 NE 2004. 11