インフラまわりのプロになりたい

---

Wake On LAN とは

前述しましたが Wake On LAN は 「PC を遠隔操作で起動させる技術」 で、WOL と略されます。

その仕組みはこんな感じです。

LAN に繋がっている電源が切れた状態の PC に対して、別の PC から “マジックパケット” と呼ばれるパケットを LAN 上に流します。 電源が切れた PC がこのマジックパケットを受信すると PC は独りでに電源を投入し、マシンが稼働状態になります。 マジックパケットを流すときは、大抵は WOL ツールなどを使うことが多いです。


たとえば、この仕組みを “知っている A さん” と “知らない B さん” の2人のエンジニアがいました。 彼らの部署は 1F ですが、急に 3F に配置された電源の落ちた PC をメンテナンスすることになりました。

このとき賢い A さんは、マジックパケットを 1F の PC から 3F の PC に向けて放出し、あとは優雅にスマホでもいじりながらリモートメンテナンスを開始します。 かっこいいですね。。

ところが B さんは WOL の存在を知らないため、電源を投入しに行くためだけに、わざわざ 1F から 3F へダッシュ する羽目になります。 こういうエンジニアは一見忙しそうですが、実は一番忙しくない存在だったりしますよね。 そう、僕のように…。 OTL



↑図1：走れフォレスト、みたいに走る羽目になる…。


ただし WOL を実現させるには、ハードウェアや OS などが WOL に対応していなければなりません。 全ての PC が対応しているとは限らないので、少々注意した方がいいかもしれませんね。

---

WOL テスト

さっそく WOL を試します。

WOL を使って起動させるマシンは dynabook T772/W5TF という WOL に対応したノート PC です。 OS は Windows 8.1 Pro (x64) が入っており、比較的新しめのマシンです。

WOL を実行する前準備として、BIOS 画面をから “Wake-up On LAN” といった設定を有効にします。
また、ネットワークアダプタの設定も必要です。 NIC プロパティの詳細設定を確認すると “Wake on Magic Packet” みたいな項目がありますので、そちらも有効にします。

これら WOL の項目名はベンダーや OS によって異なると思いますが、大抵はパッと見で判断できます。 もし該当する項目がない場合は、残念ながらそのマシンは WOL に対応していないことになります…。



■ Windows から MagicPacket を送信

Windows OS から MagicPacket を送信するときは、基本的には WOL のフリーソフトを使います。

僕が使っている WOL ツールは “Wake up On Lan tool” というフリーソフトですが、WOL ツールならどれでも大丈夫です。 Vector あたりから一番人気のツールを落とすのもよし、プログラミングができる方なら自分で作ってもよし。 MagicPacket が送信できるなら、どれを選んでも大丈夫です。

WOL ツールの使い方に関しては、ツールの readme などを読んで下さいまし（手抜きw）。



■ RTX1100 から MagicPacket を送信

ヤマハルータ RTX シリーズからも MagicPacket の送信ができます。

冒頭に書きましたプチ DMZ 領域に配置したノート PC は、この方法を使って WOL します。
RTX から WOL するには wol コマンド を使います。 本メモでは明記しない限り、この RTX から MagicPacket を送出して検証をしています。

↓wol コマンド

wol send eth0 "MAC-ADDRESS"

■ Linux から MagicPacket を送信

Linux (CentOS 6.3) から MagicPacket を送信するには “ether-wake” コマンドから実行します。
ether-wake のパッケージは “net-tools” のようです。 もしインストールされていなければ yum からインストールして下さい。

↓ether-wake コマンド

ether-wake -i eth0 "MAC-ADDRESS"

ちなみに Linux から MagicPacket を送信するときは ether-wake で問題ありませんが、Linux を WOL から起動 （Linux が MagicPacket を受信） するときは、“ethtool” というパッケージが必要です。 このパッケージを Linux にインストールして、[ ethtool -s eth0 wol g ] コマンドから MagicPacket を受け付ける必要がありました。

これ、すんげーハマりました。。。

ethtool パッケージをインストールしていない Linux マシンに MagicPacket を打ち込みながら 「なんで起動しないんだ!? 朝だぞ起きてくれ!!!」 と何度独り言をつぶやいたことか…。 OTL

↓ethtool コマンド （MagicPacket を受信）

ethtool -s eth0 wol g

↑図2：各 OS とルータが MagicPacket を送るとき

※上図では RTX1100 のコマンドに "-i" オプションが付いていますが、これは無視して下さいまし。。


以上のことを把握すれば WOL をご利用いただけると思います。


……さて、僕が知っているのはここまで。 。


次項からは 「MagicPacket のフォーマットや中身」 や 「なぜ MagicPacket を受信すると起動するのか」 などなど、もっと細部を追究したメモをしていこうと思います。

ついに WOL ルータ越えの謎が解明される……のかな？ o(・ω・?)o

---

ACPI

WOL を初めて知ったとき、無知な僕はこんな疑問を抱きました。

「電源が入っていないのだから、パケットを受け取っても認識しないんじゃ…？」

WOL はシャットダウンされた PC を遠隔地から起動させる仕組みですが、そもそも電源が入っていない PC なのに、どうして MagicPacket を受信できるのでしょうか。

普通に考えれば 「もしかしたらシャットダウンしていても NIC が通電しているのかな？」 と思うところですが、それでも漠然としていては納得がいかないので、まずはこちらを調査しました。


その結果、WOL は ACPI (Advanced Configuration and Power Interface) という規格が大きく関係していることが分かりました。

この ACPI はなんぞや……と言いますと、これは PC の電源管理の規格 でした。

一昔前の PC では、こういった電源管理を BIOS が担当していましたが、BIOS では細部にわたるまでの電源管理ができなかったようです。 そこでこの ACPI という規格を採用したことで OS レベルが電源管理を担当することになり、その結果 BIOS 以上に細かな電源管理が可能になったようです。

これは勝手なイメージですが、たとえば 「ディスプレイの電源を切る」 という設定が Windows にはありますが、これは OS が電源を管理していますので、おそらく ACPI が関係しているのでしょうね。 BIOS じゃそこまで細かな設定ができない気がします。



↑図3：OS が行う電源管理は ACPI 規格に則った技術を使っている



■ ACPI ステート （スリープステート）

そんな ACPI には “ACPI ステート” という 「スリープ状態の定義」 があります。

“スリープ” は誰もが経験したことがあると思います。 他にも “休止状態” や “スタンバイ” なども聞いたことがありますよね。 実はこれらの動作は ACPI ステートの 0～5 までの 計6段階 によって実現しています。

ちなみに僕は 超さびしがり屋 なので、寝るときはいつも 「Youtube 再生 ＋ 休止状態をタイマー」 で布団にダイヴしています。 これなら僕が寝るときには Youtube の動画が再生され、寝た後に PC が休止状態に入ってくれます。 休止状態には頭が上がらない生活でございますw


　↓ ACPI ステートの6段階
　S0 … OS の通常稼働
　S1 … スタンバイ
　S2 … サスペンド
　S3 … スリープ
　S4 … 休止状態
　S5 … ソフトオフ （シャットダウン）


・S0 … 通常稼働
これは OS が動いている普通の動作ですね。 僕でいう “Youtube 再生” がコレにあてはまりますw


・S1 … スタンバイ
稼働中の状態をそっくりそのまま停止させます。 CPU の動作は停止しますが、通電はしていますのでレジスタやキャッシュ情報が残ります。 また RAM にもデータが保持されますので、比較的スタンバイからの復帰が高速です。


・S2 … サスペンド
S1 と基本的には同じですが、CPU への通電が断ち切られるところが異なります。


・S3 … スリープ (Suspend to RAM)
稼働中の状態を全て RAM に退避させます。 CPU 内の情報も RAM に書き込まれ、それらの情報は復旧時に RAM から CPU へ書き戻すようです。 スリープ中はほぼ電力が断ち切られますが、RAM に限っては電気を送りつづけなければなりません。


・S4 … 休止状態 (Suspend to Disk / Hibernation)
稼働中の状態を全て HDD に退避させます。 HDD は RAM と違って電力を断ってもデータは消えませんので、休止状態中は S5 と同様、電源が切れています。 僕でいう、“休止状態＋タイマー” がコレｗ


・S5 … ソフトオフ （シャットダウン）
シャットダウン。 完全に OS を停止させたアノ状態。 ただし、「マザーボードには通電している」 ようです。



と、いうことは、、

ACPI 規格に準拠した OS やハードウェアであれば、シャットダウン (S5) しても 「わずかながら電力供給されている」 ということが分かりました。

なるほど、シャットダウンされていても NIC には通電している。 だから MagicPacket を受信できるのですね。

これはアレでしょうね、「テレビの電源をリモコンで消す」 みたいなものなのでしょうね。
リモコンを使ってテレビを消せば、たしかにテレビは電源オフになります。 けれどもテレビはリモコンからの電源を受け付けている状態ですので、わざわざテレビの電源ボタンを指で押さなくても大丈夫、といったイメージでしょうか。



↑図4：WOL の仕組みはテレビとリモコン？


今さらですが、WOL は ACPI ではなく ACPI 2.0 という規格に PC が対応していなければ使えませんが、現時点（2014年6月時点では ACPI 5.0 が最新のようなので、WOL を動かす際には ACPI を意識する必要はなさそうですね。

---

UDP

MagicPacket の情報収集をしていると、「MagicPacket は UDP パケットの 7 または 9 ポート に付加される」 といった内容が随所に見られました。

過去の本ブログでは TCP については少しばかりメモしてきましたが、UDP については全く触れていませんでした。 全く触れていないということは、言い換えれば ただ僕が知らないだけ でもあります。。

よってここでは MagicPacket を理解する前に、最低限レベル UDP の知識を蓄えておきます。


■コネクションレス型

UDP (User Datagram Protocol) は “コネクションレス型” という、TCP 特有のハンドシェイクが行われない通信を行うプロトコルです。 そのため通信を始めるときは 「通信を始めてもいいですか」 的なやりとりナシに、いきなりデータを送信します。

また TCP ではシーケンス番号をもとに送受信するデータの順番を守りますが、UDP にはそういったやり取りもないため、順番を一切守りません。 いわゆる 「送りっぱなし」 の通信ですね。

ゆえに信頼性という面では TCP に劣りますが、反面では TCP より 「遅延が少ない」 といった特徴を持っています。



↑図5：コネクション型とコネクションレス型


あと TCP パケットは Segment という呼び方をすることを過去のメモでも書きましたが、UDP パケットに関しては Datagram と呼ぶそうです。 ちなみに本メモでは通信データの総称を “パケット” と呼んでいますが、OSI 参照モデルを意識した場合は Segment, Packet, Frame と呼び方を変えています。 Datagram もこれに準拠しています。

そんな UDP Datagram のパケットフォーマットは、以下のとおりです。



↑図6：UDP Datagram フォーマット


こうやって見ると TCP Segment と比べてとてもシンプルな構造をしているのが分かりますね。

TCP フォーマットには存在するシーケンス番号や “確認応答番号” などが UDP フォーマットには存在しません。 また UDP にはフロー制御もありませんので、Window フィールドが存在しません。 このように UDP フォーマットはヘッダーサイズそのものが TCP と比べて少ないので、その分軽負荷な通信が可能となります。

さらに TCP ではデータサイズを自動調整（分割）しますが、UDP では調整を一切をしないようです。

UDP パケットを送信するとき、UDP ではアプリケーション層から流れてきたデータを受け取ると、それに UDP ヘッダを付加するだけの処理しか行わず、MTU 無視のままネットワーク層へ引き渡します。 この MTU 調整はネットワーク層で行われるようですが、UDP ではこういった処理も一切行いません。

UDP が軽いと呼ばれるゆえんは、こういうところにあったようです。



↑図7：TCP と比べると UDP はヘッダーフィールドが少ない



それではこのあたりで UDP のメモを終わります。

これくらいの理解があれば MagicPacket を十分に理解できると思います。 いずれ更に深いところまで UDP を調査することになるでしょうから、そのときはもっと信頼性のあるメモを書ければと思います。

---

MagicPacket

では、MagicPacket についてメモしていきます。

まず MagicPacket 送受信の流れですが、一般的に MagicPacket は “ブロードキャスト通信” で送られます。
ブロードキャスト通信とは、送信者と同じセグメントに属する 「全ての IP 機器」 に対して送信される通信です。 …あえて長ったらしく書いてしまいましたが、平たく言えば 「全員宛の通信」 でございます。。

このブロードキャスト通信によって送信されてきた MagicPacket を受け取ったノードは、それが自分宛であるか、そうでないかを判断します。 MagicPacket が自分宛でなければノードはそれを破棄し、もし自分宛であればそれがトリガーとなって PC が起動します。



↑図8：ブロードキャスト通信はパケットが自分宛じゃなくても受信する



■ MagicPacket (UDP Datagram)

では実際に MagicPacket の中身を Wireshark を使って確認します。
以下は RTX1100 から WOL コマンドを実行したことで生成された MagicPacket です。 MAC アドレスが 00:00:00:00:00:00 といった適当な数値になっていますが、気になさらないで下さいましw


↓ 実行コマンド

wol send lan1 00:00:00:00:00:00

↑図9：上から下へ階層が上がっていく


この MagicPacket には Transport Layer までのデータが詰まっていましたので、UDP Datagram の MagicPacket であることが分かりますね。 以下、気になったところのメモです。


Datalink Layer - Ethernet Frame

“Source: Yamaha_80:c5:ac” は MagicPacket を送信した RTX1100 の MAC アドレスで、“Destination: Broadcast (ff:ff:ff:ff:ff:ff)” はブロードキャスト通信を意味する宛先ですね。 この宛先のフレームは、同一セグメント内の全てのノードへ送信されます。

また Type フィールドには “Type: IP (0x0800)” が記述されていますが、これは 「プロトコル識別番号」 です。 後述しますが WOL のプロトコル識別番号は “0x0842” ですが、このフレームには 0x0800 がセットされていますので、これはデータグラムを使った MagicPacket のようですね。


Network Layer- Internet Protocol Packet

通常のユニキャスト通信でしたら、宛先アドレスに WOL 対象マシンの IP アドレスが指定されますが、今回はブロードキャスト通信なので、宛先アドレスには ”Destination: 192.168.0.255” が指定されます。 このブロードキャストは directed broadcast なので、192.168.0.0/24 に属する全てのノードが対象となります。

また Protocol フィールドには “Protocol: UDP (0x11)” という記述がありますので、このパケットは UDP 通信であることがわかりますね。


Transport Layer - UDP Datagram

送信元と宛先のポート番号に “discard (9)” が指定されています。 TCP/IP のポート番号には、1～1023 までの Well-known Port と それ以降の Ephemeral Port がありますので、この9番は Well-known Port ですね。 この9番ポートは主に 「テストやネットワーク測定」 に用いられることが多いようです。


そして本題の MagicPacket の実体となるデータ部ですが、この中身は 「FF:FF:FF:FF:FF:FF」 の1行と 「宛先 MAC アドレス×16回」 という、やや不気味ながらもシンプルな構造になっています。

ちなみに、このフォーマットの正式名称は “AMD Magic Packet Format” と呼ぶそうです。
なるほど、WOL は AMD の技術なんですねぇ。



↑図10：MagicPacket の中身


図10 のように MagicPacket のデータ部を展開すると、 前述した “Sync stream: FFFFFFFFFFFF” と “MAC: 00:00:00:00:00:00” が16行格納されたフォーマットが現れました。

これが MagicPacket の実体のようです。 先ほど 「シンプルな構造」 という表現を使いましたが、こうやってじっくり見ると他のフィールドに比べて本当にシンプルな構造をしていますよね。



■ MagicPacket (EtherType 0x0842)

次は EtherType 0x0842 の MagicPacket を作成します。
先ほどと同じく RTX1100 から MagicPacket を送信しますが、今回は少しばかりパラメータが異なります。


↓ 実行コマンド

wol send lan1 00:00:00:00:00:00 ethernet 2114

↑図11：EtherType 0x0842 の MagicPacket


WOL コマンドに “ethernet 2114” パラメータを付与することで、今度は 「Ethernet Frame の MagicPacket」 が生成されました。 図9 と比べてみても、パケットの構造が違うことが分かると思います。


Datalink Layer - Ethernet Frame

パラメータ [ ethernet 2114 ] の ethernet は、Ethernet Frame の EtherType フィールド を意味しています。 また WOL のプロトコル認識番号は 0ｘ0842 ですので、ここにはそれを10進数に直した数値の [ ethernet 2114 ] を指定しています。

ちなみに EtherType フィールドに 適当な数値 を指定しても MagicPacket は作られます。 試しに [ ethernet 1986 ] と指定してスリープ状態のマシンへ MagicPacket を送信したところ、特に問題なくマシンが起動してくれました。 適当な数値でも動作上は問題ないようです。

ただ Wireshark で [ ethernet 1986 ] パラメータの MagicPacket を確認したところ、Type フィールドが Unknown と表記されてしまいます （図12）。 また、既存の EtyerType 番号を指定 してもフォーマットが合わないのでフレームがエラーになります （図13）。 ここは無難に [ ethernet 2114 ] を指定するのが良さそうです。



↑図12： [ wol send lan1 00:00:00:00:00:00 ethernet 2054 ] で生成した MagicPacket



↑図13： [ wol send lan1 00:00:00:00:00:00 ethernet 1986 ] で生成した MagicPacket


以上が MagicPacket のメモでございました。

ちなみに WOL コマンドの EtherType パラメータを 1986 にした理由は、ただ 1986 が自分の生年だったからです。 スゲーどうでもいいお話ですね。。。OTL

---

ルータ越え

僕がはじめて WOL を触ったとき、悲しきかな 「ルータ越え」 ができませんでした。

その当時の僕はネットワークのド素人だったので （今もですが…）、WOL がルータ越えできない理由が漠然としてしか理解できませんでした。 どこかの技術サイトで目にした 「WOL はブロードキャストだからルータ越えできない」 という情報を、どこぞのテキストで覚えたような知識 で無理やり納得させて、その納得を記憶の奥底に眠らせました。

しかし今回、阿呆みたいに MagicPacket の中身を追究していったところ、（あれ？もしかして WOL って別セグメントも使えるんじゃね？） といった思考に変わっていき、徐々に希望の光が見えてきたじゃありませんか!!!

そんなわけで、以下は WOL のルータ越えメモを残していきますわよw (^ω^*)



■ MagicPacket のユニキャスト送信

本項の頭にも書きました 「MagicPacket がブロードキャスト送信される」 という解釈ですが、これは 半分正解・半分間違い のようです。 なんと MagicPacket によっては ユニキャスト通信 ができるようです。

前項にも書きましたが MagicPacket には 「EtherType 0x0842」 と 「UDP」 の2種類あります。

EtherType は後述しますが、UDP は4層なので構造的には IP アドレスの指定が可能です。 図9 の MagicPacket は RTX1100 から生成されたものですが、こちらには L3 と L4 のヘッダーフィールドが存在しますので、イメージ的にはそこに WOL 対象の PC の IP アドレスを入れてあげればいいのです。

RTX1100 では、以下のコマンドからそれが可能です。

↓ 実行コマンド

wol send lan1 00:00:00:00:00:00 192.168.1.1 udp 12345

↑図14：IP アドレスを指定した MagicPacket


上図には MAC アドレス、IP アドレス、ポート番号を各色四角で囲っていますが、見るからにこれは完全なユニキャストですよね。 この MagicPacket でしたら、経由するルータにルーティングを書いてあげるだけで WOL は成立するはずです。


試しに以下のような環境で試したところ、無事に WOL してくれました。

図15では、192.168.0.1 の PC から 192.168.1.1 の PC へ向けて MagicPacket を送信して WOL させています。 このとき 192.168.0.1 では Windows の WOL ツール (Wake up On Lan tool) を使って MagicPacket を生成し、宛先 IP アドレスには 「192.168.1.1/"32"」 を指定しました。

また PC 間には2台の RTX1100 を配置しています。 これらのルータにはインターフェースアドレスとルーティングのみ設定しています （ファイアウォールは前回ですが）。



↑図15：ユニキャスト送信だと MagicPacket はあっけなく通る


ユニキャスト送信に対応した WOL ツールであれば、ルータ越えはあっさりと行けそうですね。



■ MagicPacket のブロードキャスト送信

次に WOL 本来の通信方式となるブロードキャスト送信を試します。

環境は図15と同じものを使っていますが、今回はユニキャスト送信ではなくブロードキャスト送信です。 そのため宛先 IP アドレスには 「192.168.1.255/"24"」 を指定しています。 ここではブロードキャストアドレスを指定しましたが、/24 を指定しているからか、ホストアドレスを適当に指定しても大丈夫でした。


さっそく上記の情報を設定して MagicPacket を送信したところ……残念ながら届きませんでした。。


ブロードキャストの MagicPacket をルータに向けて送信していますので、本来でしたらルータを追究すべきですが、ここではその前に MagicPacket の中身を覗いてみます。 はじめは抵抗がありましたが、今や無くてはならない Wireshark から覗いたものが、以下の通りです。



↑図16：宛先 IP アドレスには 192.168.1.255 が指定される


WOL ツールからブロードキャスト送信すると、宛先 IP アドレスには 192.168.1.255 が指定されます。 これはブロードキャスト通信を意味しています。


「え、でもブロードキャストって 255.255.255.255 じゃないの？」


――と、メモしながら思ったワタクシ。

実はこのメモを書く前までは、ブロードキャストの概念は知っていました。 けれども白状しますと、ブロードキャスト通信には 2種類 があることを今まで知りませんでした。 ブロードキャスト通信に関しては別の機会に細かなメモを残しますが、ここでは簡単に2種類のブロードキャストをメモします。


　1．Limited Broadcast (255.255.255.255)
　2．Directed Broadcast (192.168.0.255)


Limited Broadcast

こちらは通信範囲が同一セグメント内 （ブロードキャストドメイン） に限られるブロードキャスト通信です。

「ブロードキャストストーム - 2013-12-02(18:02)」 のメモにも書きましたが、ブロードキャスト通信は同じネットワーク内に属する全てのノードに対して通信しますので、何かと便利ではありますがユニキャストに比べてネットワーク回線に負荷がかかってしまいます。

そんなブロードキャスト通信を別セグメントに転送させてしまうと、それこそブロードキャストストーム的な負荷がかかってしまう恐れがありますので、基本的にルータはブロードキャスト通信されたパケットを破棄します。 そのため、ブロードキャスト通信はルータを越えられないのです。

また limited broadcast では宛先 MAC アドレスに 「FF:FF:FF:FF:FF:FF」 が指定されます。 よって L2 で動作する EtherType 0x0842 の MagicPacket も基本的にはルータを越えられなさそうです。



↑図17：limited broadcast。 DHCP とかこんな感じ？



Directed Broadcast

これがもう一つのブロードキャスト通信となる 「Directed Broadcast」 です。

こちらはルータを越えられる少し特殊なブロードキャスト通信のようで、limited broadcast と違って宛先 IP アドレスには 「192.168.0.255」 といった具合に ホストアドレス部のみにビット1が立ちます。 図9 がまさに directed broadcast 通信されたパケットの解析画像ですが、こちらの各ヘッダー部を limited broadcast と比較すると、いくつかの違いに気づきました。

それはネットワーク層の 「送受信アドレス」 です。 limited broadcast では、「送信元アドレス：0.0.0.0 / 宛先アドレス：255.255.255.255」 が指定されましたが、directed broadcast では 「送信元アドレス：192.168.0.1 / 宛先アドレス：192.168.0.255」 が指定されています。

こうした指定をすることで自セグメントだけにとどまらず、ルータを経由して別セグメントへブロードキャスト送信することが可能になります。 別セグメントだけにブロードキャスト通信すると思っていましたが、ちゃっかり自セグメントにもブロードキャスト通信しているようですね。



↑図18：directed broadcast。 今のところ使い道がよく分からんけど、こういう動きだった


ただし directed broadcast をルータ越えさせるには、ルータに directed broadcast 転送機能が搭載していなければなりません。 RTX1100 にはその機能があるようなので、さっそく 「図15」 の環境のルータに対して [ wol relay ] コマンドを実行した上で 「192.168.1.255/"24"」 を宛先 IP アドレスに指定した MagicPacket を送信しました。


するとその結果、ついに WOL のブロードキャスト通信 ルータ越えに成功しました!!! （＾ω＾*）

↓図15 でいう右側のルータに設定した

ip lan1 wol relay broadcast

ついでにもう一つメモを。

RTX1100 では directed broadcast の転送に [ wol relay ] コマンドを使いましたが、[ ip filter ] コマンドからも directed broadcast の転送が可能のようです。 [ no ip lan1 wol relay ] コマンドを処理したあと、この転送許可を設定したことで WOL に成功したことを確認しました。

↓directed broadcast の転送許可

ip filter directed-broadcast off

これら [ wol relay ] コマンドと [ ip filter ] コマンドは、NAT と同じように 適用順位 がありました。
nat descriptor では 「NAT → ip filter」 といった適用の順番でしたが、こちらも同じように 「WOL → ip filter」 という順番になるようです。 MagicPacket のフィルタリングの方が先なんですね。



↑図19：directed broadcast フィルタリング適用の順番


ということは。。。


↓ こんなガッツリした ip filter を設定しても……

ip filter directed-broadcast 1 999 ip filter 1 pass 192.168.0.1/32 192.168.1.0/24 udp * 12345 ip filter 999 reject * * * * *

↓この一行を追加してしまうと……

ip lan1 wol relay broadcast

すべて台無し、ということですね。 わかります。



以上、WOL についてのメモでございましたw

ブロードキャストについてはいつかしっかり理解しなければなりませんので、これは別の機会にメモしていければと思います。 ひとまずは、お疲れさまでございましたw (*^ω^*)

---

最後に

今回、WOL のメモを残してきましたが、
一連を振り返ってみて 「一番大変だったこと」 を思い出してみます。


それは、WOL のルータ越え……ではなく、

MagicPacket の解析……でもなく、


実は 「ノート PC に CentOS をインストールしたこと」 でした。


何が苦労したかって、とにかくノート PC に CentOS が入らんかったのですよ。。

冒頭に書きました “ノート PC” のくだり。

ここだけ 太字 と 下線 にしたのは、
これのインストールが、とにかく大変だったからです。


　・CentOS 6 x64 → CPU が未対応とか
　・CentOS 6 x86 → インストーラー DVD が認識しない
　・Ubuntu 12.04 → インストーラー DVD が(ry
　・Ubuntu 10.04 → インストー(ry


最終的に “Minimal” という、

最小構成バージョンの CentOS がインストールできたので事なきを得ましたが…


終始　　ﾅｾﾞ｡゜（ﾟ´Д｀ﾟ)゜｡ﾊｲﾗﾅｲ?! 　←こんな状態でした


でも､どうしてここまでインストールに失敗したのか。

それはノート PC が やや古かった （WinXP 時代） からですが、
それ以上に、このノート PC は、職場の先輩 （ってか上司？） から譲り受けたものでした。


　僕 ｢勉強用に PC が欲しいのですが、破棄予定のマシンがあったら下さい！！」


という無茶振りに、快くノート PC を譲ってくれました。

僕の勉強スタイルは “ソロプレイ” が基本ですが、
こういった サポート （支え） を受けているからこそ、勉強が捗っています。

なにごとも、感謝を忘れてはいけませんねw