Internet Explorer以来、様々なインターネット機能を採り込んで来たWindows。先頃発売されたWindwos XPでは、新たに「Windows Messenger」が標準装備となった。これは、従来の「MSN Messenger Service」と「Net Meeting」を合体したもので、メッセージやファイルのやり取り、音声・ビデオ通話、アプリケーションの共有、リモートアシスタンスといった盛り沢山の機能が、1つのインタフェースに統合されている。なかなか魅力的なツールではあるが、ルータを介してインターネットに接続している我が家では、この手のソフトは鬼門。何故かは後でお話しするが、たいていはうまく動かないので使用記にならないのだ。が、今回は「同じような環境のユーザも多いのでダメモト記事でいいから」という編集部からのたっての依頼で、この鬼門ソフトの使用記をお届けすることになった。

　結論から言えば、Windows Messenger自体はたいへん良くできたソフトである。先に挙げた諸機能は、決して目新しいものではないが、これらがコンシューマOSに標準で搭載され、実に簡単な手続きで利用できるという点は大いに評価したい。ただし、そのイージーな使い勝手とは裏腹に、環境面でクリアしておかなければならないことがある。

　全ての機能を何の障害も無く利用するためには、「高速な回線でなおかつグローバルIPを使って直接インターネットに接続できなければならない」のだ。CATVやADSLのおかげで、ブロードバンド化はかなり浸透しつつある。が、上り回線が実はISDN並みだったり、配布されるIPアドレスがプライベートアドレスだったりということが良くある。前者は、パフォーマンス上の問題なので我慢すれば良いのだが、後者の場合は致命的だ。

□関連記事
【Keyword】グローバル／プライベートIPアドレス
http://pc.watch.impress.co.jp/docs/article/20000406/key115.htm#IP
【Keyword】ローカルルータ
http://pc.watch.impress.co.jp/docs/article/20001207/key146.htm#local
【Keyword】ルータ、ブリッジ、ハブ
http://pc.watch.impress.co.jp/docs/article/20001019/key140.htm#bridge

●アドレス変換と相性の悪いWindows Messenger

　ルータは、異なるネットワーク間でコミュニケーションが行なえるように、パケットを配送する中継装置である。一般に使われている製品では、単にネットワーク間の中継を行なうだけでなく、一定のルールに基づいてパケットの配送を制限したり、一部の情報(IPアドレスやポート番号)を書き換えて配送する機能が組み込まれており、LANを外部からの不要なアクセスから守るファイアウォール機能や、プライベートアドレスしか持たないLAN内のマシンが、インターネットにアクセスできるようにする機能として広く使われている。たいへん便利な機能ではあるが、今回のWindows Messengerのように双方向の接続を要求するアプリケーションでは、色々な障害が発生してしまう。

　例えば、ブラウザで「/」というURLを指定すると、PC Watchのタイトルページを開くことができる。この時、舞台裏で最初にどんなことが行なわれるのかを簡単にお話ししよう。

　ブラウザは、まずプロバイダ内などに設置されているDNS(Domain Name System)サーバーに「www.watch.impress.co.jp」のIPアドレスを問い合わせ、「210.173.173.xx」というアドレスを取得する。これが、インターネット上に接続された複数のマシンの中から、PC WatchのWebサーバーを特定する住所である(※1)。次にブラウザは、このアドレスに対し、80番ポートへの接続要求を送る。ポート番号というのは、届け先のマシン上で動いている複数のソフトの中から、最終的な受け取り人を指定するための名前に相当するものだ(※2)。Webサービスを提供するHTTPサーバーは、通常80番ポートで接続待機することになっており、ブラウザは「http」プロトコルが指定されると、暗黙のうちに80番ポートに接続するように作られている(※3)。接続要求のパケットには、送り元のIPアドレスやポート番号も書かれており、接続を受け入れたサーバーは、この送り元に対してその旨を返答して来る。いうまでもないが、アドレスが違えば、接続要求のパケットは全く違う相手に配送されてしまう。また、80番ポートに待つ相手がいなければ接続は拒否されるし、全く別のソフトが待機していても、その後のコミュニケーションは成立しない。ポイントは「インターネット上で有効なアドレスと、相手が待機しているポート番号に接続しなければいけない」ということだ。

　では、ルータのファイアウォール機能やインターネット上には存在しない筈のローカルアドレスでアクセスできるようにするアドレス変換機能は、どんなことをやっているのだろうか。

　最も基本的なファイアウォールの機能のひとつに「あらかじめ許可していない接続要求は通さない」という機能がある。Windows XPにも、この手のファイアウォール機能が搭載されており、これを有効にすると、ユーザーが明示的に許可しない限り、外部からのパケットは門前払いになってしまう。マシン上でHTTPサーバーが80番ポートで待機していても、80番ポートへの接続要求は受け付けないのである。これは「パケットフィルタリング」と呼ばれ、ファイアウォールを実現するためのひとつの方法に過ぎないが、Windows Messengerの動作に影響するものとして、まずはこのような機能があるということだけ覚えておいていただきたい。ちなみに、一般に市販されている低価格なルータのファイアウォール機能は、たいてい内部から外部への接続を制限しない形で出荷されているが、企業内に設置されているファイアウォールの場合には、内部から外部に対する接続も制限していることが多い。

　アドレス変換機能も、ファイアウォールを実現するひとつの手段であり、ローカルアドレスしか持たないマシンを、インターネットにアクセスできるようにする手段としても用いられている。

　アドレス変換機能を一般に「NAT(Network Address Translation)」、ポート番号の変換も行なう機能は「NAPT(Network Address Port Translation)」、「PAT(Port and Address Translation)」、「IPマスカレード」など色々な名前で呼ばれているが、とりあえずここでは両方を変換するタイプをNAPTと呼ぶことにし、この動作についてお話しする。これは、複数のローカルマシンを1つのIPアドレスでインターネットにアクセスできるようにする、もっとも一般的なタイプだ。

　接続要求のパケットには、送り元のIPアドレスやポート番号が含まれているとお話しした。ローカルアドレスで運用しているLAN上のマシンなら、送り元のアドレスは当然、そのマシンが持つローカルアドレスになる。LANで自由に利用できるローカルアドレスは、言い換えればインターネット上には存在しないアドレスであり、このようなパケットをもらっても、インターネット上のサーバーは返事の返しようがない。そこでNAPTルータは、パケットをそのまま右から左に配送するのではなく、自分が返事を受け取れるように細工をする。具体的には、ヘッダの送り元を自分自身の外部インタフェースに付けられたアドレスと都合の良いポート番号にして外部に配送し、受け取った返事の宛て先を、本当の送り元のアドレスとポート番号に戻してLAN内に配送。これで、内部から外部に接続するタイプのアプリケーションは、たいていうまく動作するようになる。

　ところが、LANの外側から内側のマシンに接続しようとすると、困ったことが起こる。LAN内から始まったセッションならば、ルータは内外両方の配送先を把握することができるのだが、突然外からルータ宛てに接続要求が来ても、それをどのマシンに送ればいいのかわからない。これは、セキュリティ上はとても都合の良い仕様だが、このために、相手からの接続が発生するアプリケーションは、ことごとく動作しなくなってしまう。Windows Messengerの機能がほとんど全滅なのも、このNAPTルータの仕様に起因する。

　ルータによっては、外部からの接続を受け入れられるように、あらかじめ特定のポートに対するパケットを特定のマシンに配送するように設定できる機能(ポートフォワーディング)や、配送先が確定できないパケットを全て特定のマシンに配送する機能(DMZ=DeMilitarized Zone)をサポートしている。が、Windows Messengerの場合には、これら機能では対処することができない。接続するためのアドレスやポート番号をメッセージでやりとりしているため、ルータの内側に置かれたマシンが、外部からの接続に使う本当のアドレスを相手に通知できないのである。

(※1) 「http://210.173.173.xx/pc/」と指定すれば、DNSの問い合わせ無しで接続することができるが、www.watch.impress.co.jpサーバーが、ずっと同じアドレスである保証はない。サーバーのアドレスが変わった時には、編集部は新しいアドレスでDNSサーバーを更新するので、「www.watch.impress.co.jp」でアクセスすれば更新されたアドレスで引き続き接続できるが、「210.173.173.xx」ではもはや接続できなくなってしまう。

(※2) URLでポートを明示的に指定する場合には、ホスト名に続けて「:ポート番号」と記述する。本編の例を明示的に指定すると「http://www.watch.impress.co.jp:80/pc/」となる。

(※3) 実際のプロトコルは階層化されており、HTTPプロトコルは下位のTCPを、TCPは下位のIPを、IPは下位のEthernetなどのプロトコルを使用してパケットを送っている。送信元や宛て先のポート番号はTCPのヘッダ情報に、IPアドレスはIPのヘッダ情報に書き込まれ、それぞれの階層に必要な相手を識別している。ちなみに下位のEthernetパケットの場合には、ネットワークカードなどが持つMACアドレスが使われる。この例にあるような、インターネット上のサーバーに接続する場合には、いわゆる「デフォルトゲートウェイ」と呼ばれるルータのMACアドレスがこの階層の宛て先……すなわち、最初に直接パケットを渡す相手になる。

□関連記事
【Keyword】DNS
http://pc.watch.impress.co.jp/docs/article/971105/key5.htm#dns
【Keyword】NAT
http://pc.watch.impress.co.jp/docs/article/971105/key5.htm#nat
【Keyword】マルチNAT
http://pc.watch.impress.co.jp/docs/article/20010802/key176.htm#STATEFUL
【Keyword】DMZ
http://pc.watch.impress.co.jp/docs/article/20010201/key151.htm#DMZ

●アドレス変換がWindows Messengerに及ぼす影響

　では、NAPTルータやWindows XP内蔵のファイヤーウォールが、Windows Messengerの各機能にどのような影響を及ぼすのか見てみよう。

＜メッセージ送信＞

　メッセージのやりとりは、常にMessenger用のサーバーを介して行なわれる。Messengerサーバーへの接続は、HTTPサーバーと同じようにユーザー側から接続を開始し、以後そのコネクションを使って双方向の通信を行なうスタイルである。接続するサーバーのポートは1863番(TCP)なので、このポートに対する内部から外部の接続が制限されていない限り、双方がルータの内側にいる場合でも、メッセージをやりとりすることができる。ちなみに、他の機能はいずれも、このコネクションをベースに必要な手続きを開始するため、メッセージのやりとりが成立しないと、Windows Messengerの全機能が停止する。

　メッセージ送信自体には、特に大きな障害はないが、NAPTルータの中には、パケットのやりとりが停止していると、かなり早い時間で自動的に接続を解除してしまうものがある。オンラインで待機していたつもりが、いつのまにかオフラインになっているということが起こるので注意したい。

＜ファイル送信＞

　ファイル転送は、送信側が特定のポートで接続して来るのを待機し、受信側から送信側のマシンに接続するスタイルを採る。送信側のポートは、同時に転送するファイル数に応じて、6891～6900(TCP)を使用する。したがって、常に1個ずつしか送らないのであれば(操作上は1ファイルずつしか送れないが、送信中にさらに別のファイル転送を開始することができ、最大10個まで並行して送ることができる)、6891だけ接続を受け付ける状態になっていればよい。

XP内蔵のファイアウォール(チェックされているのは自動的に開かれたポート)

　Windows Messengerは、XP内蔵のファイアウォールに対しては、必要なポートに接続できるように自動的にコンフィギュレーションを行なう(ログインしているユーザーに管理者権限が必要)ようになっている。実際、他の機能に関しては、特別な設定無しで利用できるのだが、ファイル転送だけは、必要なポートを自動設定してくれないので、ファイアウォール機能を有効にしている場合には、あらかじめ使用するポートをセットしておく必要がある。

　ファイアウォールがNAPTルータの場合には、このようなオンデマンドのコンフィギュレーションに対応する機種がないため、今のところはユーザーが設定しなければならない。さらに、送信側がNAPTルータの内側にいる場合には、接続できないアドレスを通知してしまうためうまく接続できなくなってしまう。ただし、双方が同じNAPTルータの内側にいる場合は別。通知されたアドレスは、LAN上で有効なアドレスなので、ファイル転送は問題無く行なえる。

　この辺は他の機能も同様で、表では「同一ネットワーク内」「異なるネットワーク」として分類しているが、要は、受け取ったアドレスで相手に接続できる環境であれば、通信は成立する。

＜音声・ビデオ通話＞

　音声・ビデオ通話は、SIP(Session Initiation Protocol)と呼ばれるリアルタイム通信の制御を行なうプロトコルを使って双方が打ち合わせを行ない、最終的にはRTP(Real Time transport Protocol)というリアルタイム転送用のプロトコルを使って、音声に2ポート、ビデオに2ポートのUDPストリームを確立する。使用するポートは、動的に割り当てられるため特定することはできない(XPのファイアウォールは自動的に制御される)。また、一方がNAPTルータの内側にいる場合には、無効なアドレスを通知してしまうため、SIPの段階で接続に失敗してしまう。

＜アプリケーション共有＞

アプリケーションの共有(デスクトップを共有したところ)

　この機能は、特定のアプリケーションやデスクトップ全体を相手のディスプレイに表示したり、操作できるようにするもので、次のリモートアシスタンスやXP Professionalがサポートするリモートデスクトップと同じ技術(以前のターミナルサービス)がベースになっている。アプリケーション共有では、最終的に1503(TCP)ポートを使用するが、音声・ビデオ通話と同様、前処理にSIPを使用しているため、一方がNAPTルータの内側にいる場合には、SIPのプロセスで接続に失敗してしまう。

＜リモートアシスタンス＞

　この機能は、別のユーザーに支援を受けるためのもので、Windows Messengerとは独立した単体の機能としても提供されている。単体で利用する場合には、アシストしてもらう相手をメールで招待し、ポート3389(TCP)に接続してもらうが、Windows Messengerで招待した場合には、3000(TCP)番台のポートを使って双方から接続し合い、適当なところに落ちつくようだ。一方の要求が通れば接続できるルーズな仕様(というかソフトの性格上なんとか接続しようと頑張ってくれている)なので、どちらか一方がグローバルアドレスであれば接続できる。ただし、リモートアシスタンス内の音声通話はSIPを使用するので、Windows Messengerの音声・ビデオ通話と同様の制約がある。

●Windows Messengerが望む理想のルータ

UPnPに対応したIntelのレジデンシャルゲートウェイの試作機。UPnP対応の意向を表明している数少ないモデル。IntelはCPUなどの部品を売ることを目的としており、最終的な製品化は他社に委ねる

　かなり相性の悪いルータとWindows Messengerだが、ルータにいわせれば、これはWindows MessengerがNATに非対応だからということになるだろう。一方のWindows Messengerにいわせると、原因はルータがUPnP(Universal Plug and Play)非対応だからということになる。

　UPnPは、ネットワーク上でUSBのようなデバイスの認識とコンフィギュレーションを自動的に行なう機能を提供する。先のXP内蔵ファイアウォール機能や、今回は試していないが、XPをルータにしてしまうインターネット接続共有の場合には、このUPnPに対応しており、必要に応じてルータの外側のアドレスやポートのマッピング状態を取得したり、ポートのマッピングを変更したりといったことが行なえる。

　ルータの内側に置かれたマシンが、ルータの外側のアドレスを知ることができ、なおかつ、接続用にルータのポートを開いて自分の方に向けさせることが動的に行なえれば、今回の障害は全てクリアできる。従来なら、このようなアプリケーションがルータ越しに通信できるように、個々のアプリケーションに合わせたアプリケーションレベルのゲートウェイ機能を実装しなければならなかったが、UPnPなら、あまたある対戦ゲームやストリーミング、P2Pツールなどに臨機応変に対応できる。

　個人的にはあまり使いたくない存在だが、セキュリティ云々よりもイージーで便利なことが優先されるホームユースでは、このような万能な機能が必要なのかもしれない。ただし、現状ではUPnP対応の製品は、まだ市販されていない。

□参考文献
Windows XP の Windows Messenger : ファイアウォールとネットワーク アドレス変換での動作
http://www.microsoft.com/japan/windowsxp/pro/techinfo/deployment/natfw/default.asp

(2001年11月20日)

[Text by 鈴木直美]