Broadband Watch logo
バックナンバー
第76回:これさえあれば外出中も安心! 携帯電話で自宅の様子を確認できる「EZ de DIONモニター」
[2003/10/28]
第75回:無線LAN運用のカギはチャネルに有り 干渉を避けるための設定方法を探る
[2003/10/21]
第74回:これからの情報発信の本命になるか? blogの魅力を探る
[2003/10/14]
第73回:デュアルバンド対応&機能強化で巻き返しを図るアイ・オー・データ機器「WN-AG/BBR」
[2003/10/07]
第72回:低価格路線で変わるプロバイダーのあり方
[2003/09/30]
第71回:インターネット経由でのWakeup On LANに挑戦
[2003/09/16]
第70回:Yahoo! BB 26M+無線LANパックは実用的か?
[2003/09/09]
第69回:アッカ・ネットワークスの26Mbps ADSL開通! ~他のADSL事業者との違いが明確に~
[2003/09/02]
第68回:イー・アクセスのADSLプラスIIでAnnexC/Iの違いを比較
[2003/08/19]
第67回:WPAで無線LANはどう変わるのか? ~その2 実際にWPAの利用と問題点~
[2003/08/12]
第66回:WPAで無線LANはどう変わるのか? ~その1 WEPの弱点とWPAのしくみ~
[2003/08/05]
第65回:Yahoo! BB 26Mを再検証 ~約2Mbpsの速度向上を確認~
[2003/07/29]
第64回:Yahoo! BB 26M速攻レビュー
~ダブルスペクトラムの効果はいかに?~
[2003/07/22]
第63回:エレコム LD-WLS54AG/APが実現するデュアルバンド同時通信環境
[2003/07/15]
第62回:長い沈黙を破って登場した新Atermシリーズ ~AtermWR7600Hでトリプルワイヤレスは本格化するか?~
[2003/07/08]
第61回:ついにやってきた20Mbps超ADSL時代 ~24/26Mbps ADSLの全体像を考察する~
[2003/07/01]
第60回:アクセスポイント間通信でネット家電の無線化に挑戦
[2003/06/24]
第59回:リビングのテレビでお手軽Webブラウジング パナソニック「Tナビ」の実用度はいかに?
[2003/06/17]
第58回:モデル追加されたメルコ LinkStation 静音化対策&機能追加でリベンジなるか?
[2003/06/10]
第57回:ノートPCの無線LAN環境を考える すでに802.11gに対応した機種も……
[2003/06/03]
第56回:MPEG2やDivXも家庭用テレビで再生可能 「Play@TV」で快適なテレビ生活ができるか?
[2003/05/27]
第55回:PHSと無線LANの一発切替ツールが登場 b-mobileはモバイル通信の救世主となるか?
[2003/05/20]
第54回:待望の802.11a/gデュアルバンド対応無線LAN アイ・オー「WN-G54/BBR-S」の完成度はいかに?
[2003/05/13]
第53回:HDD&DVDビデオレコーダーをネットワーク対応に パナソニック ブロードバンドレシーバーを試す
[2003/05/06]
第52回:デスクトップPCもワイヤレス化したい!エレコム LD-WL5411/PCIを試す
[2003/04/22]
第51回:IP電話は普及するのか? VoIPサービスの現状と今後を考える
[2003/04/15]
第50回:IEEE 802.11gに登場した新たな選択肢 corega WLAP-54GT Setを試す
[2003/04/08]
第49回:こんなにも多機能になったプリントサーバー 使いやすく進化した2製品を試す
[2003/03/25]
第48回:汚名返上を目指すドラフト版IEEE 802.11g 新ファームウェアでメルコWBR-G54とLINKSYS WRT54Gを試す
[2003/03/18]
第47回:実力を発揮するのはこれから? ソニー ブロードバンドAVルータに隠された謎を解けるか
[2003/03/11]
第46回:ハードディスクもネットワークで増設する時代に メルコ LinkStation HD-80LANを試す
[2003/03/04]
第45回:ブロードバンドはどこを目指すのか? 混迷するADSL
[2003/02/25]
第44回:5,000円でも機能は十分? 低価格ルータ3機種を比較
[2003/02/18]
第43回:祝・FTTH2回線開通~BフレッツとUSEN BROAD-GATE 01を比較する
[2003/02/04]
第42回:リンクシスの意欲作~802.11g対応無線LANルータ Wireless-Gを試す
[2003/01/21]
第41回:新環境でADSL 3回線を比較
[2003/01/14]
第40回:どうする? どうなる? 引越に伴うADSLの移設
[2003/01/07]
第39回:12Mbps ADSLの最新の動向を事業者に聞く ~イー・アクセス編~
[2002/12/24]
第38回:フレッツ・ADSL モア開通 ~NTT東西の12Mbpsの実力はいかに?~
[2002/12/17]
第37回:12Mbps ADSLの最新の動向を事業者に聞く ~アッカ・ネットワークス編~
[2002/12/10]
第36回:大幅に進化したIEEE 802.11aチップセット アイコム SL-5000を試す
[2002/12/03]
第35回:待望の802.11a対応ワイヤレスLANコンバーター ソニー PCWA-DE50を試す
[2002/11/26]
第34回:常時接続環境でストリーム配信に挑戦 BROAD STREAM TSR-MS4をテスト
[2002/11/19]
第33回:アッカ・ネットワークスの12Mbps ADSL開通 オーバーラップの効果は如何に?
[2002/11/12]
第32回:低価格化が進むIEEE 802.11b対応無線LANルータ NECアクセステクニカ「WARPSTARΔ WB7000H」を試す
[2002/11/05]
第31回:インターネット経由でテレビが見たい! 「INFOCITY ドコデモTV」を試す
[2002/10/29]
第30回:第2世代チップで普及へ弾みを付けるIEEE 802.11a Atheros Communicationsインタビュー
[2002/10/22]
第29回:PPPoE 2セッション同時接続可能になったフレッツ・ADSLを検証
[2002/10/08]
第28回:ホットスポットをどこまで便利に使えるか? ソースネクストの「どこでも無線LAN」を試す
[2002/10/01]
第27回:フレッツ・ADSL モアで何が変わるのか? NTT東日本インタビュー
[2002/09/24]
第26回:単体製品へと回帰するIEEE 802.11b 小型アクセスポイント3機種を試す
[2002/09/17]
第25回:選択肢が増えてきた802.11a対応製品 NECのAterm WA7500Hを試す
[2002/09/10]
第24回:このままでいいのか? あまりに違うルータのパッケージ記載内容と実性能
[2002/09/03]
第23回:無線LANのセキュリティソフトは有効!? ソースネクストの「鉄壁 無線LAN」を試す
[2002/08/20]
第22回:Yahoo!BB 12M開通! 他のADSLへの影響はいかに
[2002/08/13]
第21回:FREESPOT始めました! メルコの導入キット「FS-01」を試す
[2002/08/06]
第20回:これからの無線LANはセキュリティ設定がカギ IEEE 802.11aに対応したアイコム「AP-120B」を試す
[2002/07/30]
第19回:NASの実力はいかに? アイ・オー・データの「HDA-i120G/LAN」を試す
[2002/07/23]
第18回:ADSL 12Mタイプの方式乱立で混迷の時代となるか?
[2002/07/16]
第17回:NETWORLD+INTEROP 2002 TOKYOレポート ようやく見えてきた次世代技術の使い道
[2002/07/09]
第16回:速度だけを強調したルーターはもう古い
[2002/06/25]
第15回:緊急警告!! 今すぐ無線LANのセキュリティを設定せよ
[2002/06/11]
第14回:2回線のADSLを同時接続しスピードアップに挑戦
[2002/05/28]
特別編:USENのHFC通信の詳細について聞く
[2002/05/23]
第13回:イー・アクセスの新ファームウェアを試す
[2002/05/14]
第12回:プレイステーション 2を無線LAN化
[2002/04/30]
特別編:アッカ・ネットワークスに聞く
[2002/04/24]
第11回:フレッツ・ADSLを8Mタイプに移行
[2002/04/16]
第10回:ルータとしての完成度はいまひとつ?!
[2002/04/02]
第9回:安定性向上に効果あり、FBM方式を試す
[2002/03/19]
特別編:アッカ・ネットワークス インタビュー
[2002/03/13]
第8回:アッカの8Mbps ADSLを導入
[2002/03/05]
第7回:UPnP対応ルータで半分だけ解決されるMessenger問題
[2002/02/19]
特別編補足版:近端漏話とカッド構造の密接な関係
[2002/02/15]
第6回:802.11a対応無線LANアクセスポイントを試す
[2002/02/05]
特別編:つながらない!? ADSL 8Mサービスの現状を探る
[2002/01/30]
第5回:ハッキリ言ってくだらないスループット論争
[2002/01/22]
第4回:エレコム LD-WBBR4のWindows Messenger対応ファームを試す
[2002/01/08]
第3回:Windows XPのブロードバンド度をチェック・3
[2001/12/18]
第2回:Windows XPのブロードバンド度をチェック・2
[2001/12/04]
第1回:Windows XPのブロードバンド度をチェック
[2001/11/15]

第71回:インターネット経由でのWakeup On LANに挑戦


 FTTHやADSLなどの常時接続回線を利用すれば、外出先から自宅へのリモートアクセス環境を構築することもさほど難しくない。しかし、このときに問題になりがちなのが、自宅側のパソコンの電源管理だ。リモートアクセス環境を利用するには、自宅側のパソコンの電源がONになっていることがひとつの条件となる。今回は、この問題を解決すべく、WAN側からのWakeup On LAN(WOL)に挑戦してみた。


インターネット接続だけではもったいない

 FTTHやADSLなどの常時接続環境を利用して、自宅へのリモートアクセス環境を整えてみたい……。そう考えたことはないだろうか? リモートアクセス環境を整えておけば、会社から自宅、外出先から自宅といったように、遠隔地から自宅のパソコンにアクセスして情報を自由に取り出すことが容易に可能となる。せっかく、高速かつ、常時接続が可能な回線が自宅にあるのだから、これを家からインターネット接続だけに利用するのは、実にもったいない話だ。

 もちろん、これまではリモートアクセス環境を構築するために、難しい設定が必要だったり、サーバーなどの機器を用意しなければならないという問題があった。しかし、Windows XPのリモートデスクトップを使ったり、VPNサーバー機能を搭載したルータ(オムロン MR104FHやヤマハ RT57iなど)を利用することで、以前に比べて容易に環境が整えられるようになってきた。公衆無線LANアクセスポイントのVPN対応など、アクセスする側の環境も整いつつある。

 このような環境を整えれば、FTTHやADSLなどのブロードバンド環境をインターネット接続インフラとしてだけでなく、自宅とさまざまな地点を結ぶネットワークとしても利用可能となるだろう。


最大の問題はパソコンの電源投入

 ただし、リモートアクセス環境を構築するには、ひとつ大きな問題がある。以前に本コラムでも紹介したように、リモートデスクトップ環境ルータでのVPN接続環境の構築は、それほど難しくはない。必要なソフトウェアや機材をそろえて、適切に設定すれば誰にでも構築は可能だ。

 しかしながら、リモートデスクトップにしろ、VPN接続にしろ、自宅側のパソコンの電源がONになっていないと利用できないという問題がある。自宅側のパソコンの電源がOFFになっていると、リモートデスクトップは接続自体ができないうえ、VPN接続は接続が完了してもパソコンの資源を参照することができない。これでは、いくら環境の構築が手軽だとしても、実際の利用には躊躇してしまうだろう。

 では、常にパソコンの電源をONにしておくのか? これは非効率的だろう。夏の電力不足を無事に乗り切ったとは言え、いつ使うかがわからないパソコンの電源を常にONにしておくわけにはいかない。もちろん、電気料金も気になるところだ。やはり理想としては、リモートアクセスで接続したときだけパソコンの電源をONにできるようにしたいところだろう。

 そこで、今回はWakeup On LAN(以下WOL)を利用して、この問題の解決を試みてみた。WOLとは、ネットワーク経由でパソコンの電源をコントロールできる機能のことだ。MagicPacketと呼ばれる特定のデータをネットワーク経由でパソコンに送信することで、パソコンの電源をONにすることができる。この機能を利用すれば、リモートアクセスしたときだけ、パソコンの電源をONにすることができるはずだ。


まずは自宅LANでWOLをテスト

 WOLを利用するには、WOLに対応したNIC(LANインターフェイス)とMagicPacketを送信するためのソフトウェアが必要になる。比較的新しいパソコンに搭載されているNICであれば、ほとんどの場合WOLを利用できるが、中にはBIOSのバージョンアップや設定の変更などが必要なことがあるので、マニュアルやメーカーのサポート情報などを事前に確認しておくといいだろう。

 一方、MagicPacketを送信するためのソフトウェアは、オンラインソフトなどもいくつか存在するが、今回はAMDが同社のNIC向けに提供している「PCnet Magic Packet Utility」を利用した。他のソフトウェアを利用してもかまわないが、場合によってはルータ越えに対応していない場合もあるので、あらかじめ機能をよく確認しておきたい。

AMDのPCnet Magic Packet Utility。送信先アドレスやMACアドレスを毎回手動入力しなければならないのが面倒だが、ルータ経由などでも確実にWOLが利用できる

 これらの準備ができたら、まずはLAN上でWOLのテストをしてみると良いだろう。ターゲットとなるパソコンの電源をOFF、またはスタンバイにしておき、この状態でLAN上の他のパソコンにインストールしたMagicPacket用ソフトウェアを起動。起動したいパソコンのIPアドレス(もしくはブロードキャストアドレス)とNICのMACアドレスを指定して、MagicPacketを送信する。これで電源がONになれば、ひとまず準備は完了だ。

 なお、今回、筆者のパソコンはスタンバイからの復帰しかできなかった。電源OFFからの起動にはパソコンによって条件や制約があるため、今回はスタンバイからの復帰という前提で話を進めていく。


WAN側からのWOLには工夫が必要

 さて、LAN上でのテストがうまくいったら、これをインターネットを経由したWANに拡張すればいい。ただし、ここで問題になるのがルータの存在だ。WOLでは、MagicPacketがターゲットのパソコンに届くことで電源がONになるのだが、ルータが存在することにより、通常の方法ではMagicPacketは届かない。

 そこで、ルータのポートフォワードを利用してみることにした。前述した「PCnet Magic Packet Utility」の場合、利用するプロトコルはUDPで、ポートは2304だ。つまり、ルータ側にこのパケットが届いたときに、LAN上のパソコンのIPアドレスにフォワードするように設定し、外出先のクライアントからルータのグローバルIP宛にMagicPacketを送信すればいいわけだ(ルータによってはフィルタリングの設定も必要)。

NECアクセステクニカのAtermシリーズの設定画面。ルータによってはフィルタリングの設定変更も必要。2304ポート宛のUDPパケットを通過させる必要がある
ARPキャッシュの問題を避けるため、MagicPacketをブロードキャストアドレス宛にポートフォワードする。これで、WAN経由でもWOLが利用できる

 この方法は、一見、うまくいったように見える。実際、自宅側のパソコンをスタンバイにしてから数十分の間であれば、何の問題もなくWOLが成功する。しかし、一定の時間が空くと、途端にスタンバイから復旧させることができなくなってしまう。いろいろ調べてみると、どうやらルータのARPキャッシュが関係しているようだ。ルータはLAN上のパソコンのMACアドレスとIPアドレスの対応をARPキャッシュとして一定時間保持しているが(どれくらい保持するかはルータによる)、これがクリアされてしまうと、転送先のパソコンのMACアドレスが不明となり、きちんとMagicPacketが届かない。これによって、一定時間しかWOLが機能しないと考えられる。

 このため、今度はポートフォワードの設定を変更し、転送先をパソコンのIPアドレスではなく、LAN側のブロードキャストアドレス(192.168.0.255など、末尾が255のアドレス)にしてみた。ブロードキャストアドレスであれば、LAN全体にMagicPacketがブロードキャストされるため、ARPキャッシュがクリアされたとしてもターゲットのパソコンにMagicPacketを届けることができる。すると、今度は問題なくLAN上のパソコンをスタンバイから復帰させることができた。同様にリモートデスクトップのポート(3389)などもポートフォワードしておくように設定しておけば、これでWOLしてから、リモートデスクトップで接続するというリモートアクセス環境を整えることができるだろう。

ポートフォワードを利用したWAN側からのWOLの利用イメージ。クライアントからルータ宛に送ったMagicPacketは、ルータのポートフォワードによってLAN側にブロードキャストされる

 ただし、ルータによっては、アドレスが間違っている判断され設定が拒否されるためか、ブロードキャストアドレス宛のポートフォワードが設定できないように制限されていたり、後述するようにLAN側へのブロードキャストが破棄される設定になっている場合もある。今回テストに利用したNECアクセステクニカ製のルータ(WR7600H、およびイー・アクセスやアッカでレンタルされるADSLモデム)では、問題なく設定できたが、他の製品の場合は設定できないこともあるので注意が必要だろう。


やはりVPNで使いたい

 このように、ブロードキャストアドレス宛にポートフォワードを設定することで、WAN側からのWOLは可能になった。しかし、ポートフォワードの場合、ポートが常に空いているため、セキュリティ上の問題がどうしても避けられない。リモートデスクトップで利用するのであれば、そのポートも開けておかなければならない。このため、個人的にはVPNで接続する方法をおすすめしたい。

 VPN環境でWOLを利用する場合、前述したポートフォワードの設定は不要だ。VPN接続した次点で、外出先のクライアントにもLAN側と同じプライベートIPアドレスが割り当てられるため、この状態からMagicPacketを送信してやればいいことになる。前述した方法と同様、ARPキャッシュの問題を避けるために、LAN側のブロードキャストアドレスにMagicPacketを送信すればWOLが可能になるはずだ。

 しかし、実際にやってみるとこれがうまくいかない。今回、VPN接続のテストには、YAMAHAのRT57iを利用したのだが、このルータはSmarfアタック対策のために、WAN側からLAN側へのダイレクトブロードキャストが禁止されている。つまり、外出先のクライアントからブロードキャストアドレス宛にMacigPacketを送信しても、それがすべてフィルタによってリジェクトされてしまうのだ。

YAMAHA RT57iの設定画面。MagicPacketをLAN側にブロードキャストするためには、LAN側へのダイレクトブロードキャストを許可しておく必要がある

 このため、VPNでWOLを利用する場合は、あらかじめルータ側でダイレクトブロードキャストを許可しておく必要がある。ヤマハのルータの場合にはTELNET、もしくはルータの設定画面で「ip filter directed-broadcast off」というコマンドを実行する。これで、ダイレクトブロードキャストが許可され、VPNで接続したクライアントからのMagicPacketがLAN上にブロードキャストされるようになる。Smarfアタックに対して対抗できなくなる可能性があるが、ルータ側ではPPTPが利用するポートしか空いていないので、安全性という面では、前述した方法よりは高いだろう。

VPN環境でのWOL利用イメージ。VPNで接続した後、LAN側のブロードキャストアドレス宛に直接MagicPacketを送信する

よりスマートでセキュアな方法が望まれる

 このように、今回はWAN側からWOLを利用する2種類の方法を紹介したが、どちらも設定が面倒であるうえ、若干セキュリティが甘くなってしまう問題を残す結果となった。リモートアクセス環境がより普及するようになるためには、このような問題が解決され、よりスマートな方法が提供されなければならないだろう。

 過去、ISDNルータが多用されていた時代には、PHSからのダイヤルアップサーバー機能が提供されており、中にはルータからMagicPacketを送信できる製品も存在した。回線が常時接続になり、リモートアクセス環境が使いやすい環境になったのに、このような製品があまり登場しないのは非常に残念だ。SOHOというか、家庭で仕事をする立場の人間からすると、非常に欲しい機能のひとつなのだが……。今後、単にインターネット接続だけを提供するルータではなく、このような付加価値を持ったルータが登場することを望みたいところだ。

(2003/09/16 清水理史)


□関連記事:第2回:Windows XPのブロードバンド度をチェック・2
http://bb.watch.impress.co.jp/column/shimizu/2001/12/04/

清水理史
 製品レビューなど幅広く執筆しているが、実際に大手企業でネットワーク管理者をしていたこともあり、Windowsのネットワーク全般が得意ジャンル。最新刊「できるADSL eAccess版 無線LAN対応」ほか多数の著書がある。
Broadband Watch ホームページ
Copyright (c) 2003 Impress Corporation All rights reserved.