ThinkPad X40にD02NEドライバがインストールできない場合の対処。

Mobile Netowork ThinkPad X40 Windows

今年5月初旬辺りにlenovoサポートページ(だったかな？)からSystem Updateを使用しないよう指示が出ていたので、その途中の微妙なドライバやユーティリティの影響かもしれないのだが、、、

元々Linux Zaurusでも使えるということでD01NXIIを購入し、それをLinuxで使いたいがためにVMB5000ドライバをイジッてみたりしていたのだが、挫折し、D02NEに変更した。ところが、これがThinkPad X40のWindows XP Professionalにうまくドライバが組み込めない。
D02NE添付のCDでドライバとユーティリティをWindowsにセットアップするところまでは問題ない。ところが、ここでD02NEをThinkPad X40に差し込むと、本来であればハードウェアを認識し、ドライバが組み込まれ、動作し始めるはず、なのだが。何度やってもハードウェアがD02NEであることは認識するのだが、そのドライバの組み込み途中で処理が止まる。
デバイスマネージャでドライバの状況を見ると、ハードウェアは問題なく動作している、と表示されているが、ドライバは入っていないという、変な状況になっている。デバイスマネージャでドライバを更新してみようとかちょこちょこいじると、デバイスマネージャがハングし、プロセスを殺す羽目になる。
この状態でシャットダウンすると、かならずバッテリー関連のモジュールが終了せずに残った旨ダイアログが表示される。強制終了させると、その後のシャットダウンの延長でハング。どうしようもないので強制電源断。

繰り返しているうちに、ThinkPadのACPI電源制御周りとD02NEが相性？が悪いように思えてきた。ほぼ同じ頃、D02NEは数分間通信が途切れると、自動的に低消費電力モードになることをgoogleかなにかで発見。

ということで。

ThinkPadの省電力ドライバと省電力マネージャをアンインストールし、D02NEをセットアップしたところ、うまく行った。

仕方がないので、Windows XP素の電源管理を利用することにした。

SATAディスクをVMware物理ディスク/パーティションにすると、WindowsとLinuxのマルチブートでVMを共用できない。

Virtual Machine Windows Linux

VMware Workstation/Playerでは、ホストOSの物理ディスクやパーティションをゲスト仮想マシンのディスクとして利用できる。

この機能を利用して、Windows XPホストとLinuxホストのデュアルブート環境で物理ディスク/パーティションをゲストLinuxのディスクとして利用することで、仮想マシンを共用することを試みた。
これを、SATAディスクのマシンで試してみたところ、うまくいかなかった。

原因は、、、
LinuxのVMware Workstation/Playerのゲスト仮想マシン環境では、SATAディスクはSCSIディスクとして認識される。ところが、Windows XPホストにおいては、SATAディスクは仮想マシン上ではIDEディスクとして認識される。結果として、ゲスト仮想マシンであるLinuxには、Linuxホストの時はディスクがSCSI、つまり/dev/sdXXというデバイスに見えるが、Windowsホストの時はディスクがIDE、つまり/dev/hdXXというデバイスに見えてしまうのだ。このため、ゲスト仮想マシン内でディスクデバイス名が異なることになってしまい、うまく動かなかった。

試してはいないが、Windowsゲストなら、Windowsホスト、Linuxホストの場合共にSATA物理ディスクがVMware経由でIDEディスクとして見えるかもしれない。結果として、動作するかもしれない。
しかし、これは私が必要に迫られていなかったため、試しておらず、実際のところどうなるかはわからない。

Linux NFSサーバにOpenSolaris/Solaris10をNFSクライアントとして接続する方法(NFS v3)

Linux Solaris

NFSv4でのNFS運用は今のところ行っていないので、、、

LinuxのNFSサーバからエクスポートされたディレクトリをOpenSolaris/Solaris10 NFSクライアントでマウントしようとすると、マウントできない。原因詳細は不明だが、Linux NFSサーバとSolaris NFSクライアントでの、NFSバージョン確認処理がうまく動作しないらしい。

まず、NFSv4は利用していないので、NFSv3を使用することにする。
Linux NFSサーバでは、/etc/exportsファイルに、

/export_dir solaris_client(rw,no_subtree_check)

のように記述する。そして、exportfs -aを実行する。設定変更後の反映時には、exportfs -raを実行する。

OpenSolaris NFSクライアントは、上記でエクスポートされたファイルを、NFSv3でマウントしてやればよい。
コマンドラインからだと、

OpenSolaris# mount -F nfs -o vers=3 linux_nfs_server:/export_dir /mount_point

また、デフォルトでNFSv3を使用するようにするには、/etc/default/nfsファイルでNFSクライアントのマウント要求バージョンでNFSv3以下にすればよい。以下の行はインストール直後はバージョンが4、かつ'#'でコメントアウトされているので、これを以下の記述に変更する。

NFS_CLIENT_VERSION=3

そして、svcadm enable nfs/clientすると、以下のように、versオプション指定なしでマウントできるようになる。既にnfs/clientが動作している時の設定反映はsvcadm restart nfs/clientで行える。

OpenSolaris# mount -F nfs linux_nfs_server:/export_dir /mount_point

Solaris10の場合は、上記設定だけではうまく行かない。LinuxのNFSサーバは、デフォルトではポート番号1024より小さなinternetポートから発したマウント要求しか受け付けない。ところが、Solaris10は、これより大きな値のポートからマウント要求を発行する、というのが原因のようだ。なので、Linux NFSサーバの/etc/exportsファイルにinsecureオプションを追加する。

/export_dir solaris10_client(rw,insecure,no_subtree_check)

Solaris10 NFSクライアントのマウント方法は、OpenSolarisと同様で良い。

なお、OpenSolarisとSolaris10の動作の違いを、Linuxならtcpdump/Solarisならsnoopで調べると、OpenSolarisはTCPプロトコルでNFSサーバにマウント要求を発行するが、Solaris10はUDPプロトコルで、ポートマッパを利用してマウント要求をする、ということがわかる。恐らく、このポートマッパ関連の動作の影響で、Solaris10は1024より大きなポートからマウント要求を発行していると思われる。

OpenSolaris、WindowsでBIOS時刻をGMTにする方法

Solaris Windows Linux

OpenSolarisとDebian5をデュアルブートにして、時刻に関する問題が発生。

googleで調べたところ、OpenSolarisは過去(MS-DOS時代)のデュアルブートにおける問題対処のため、デフォルトではBIOS時刻がlocaltimeになっていることがわかった。
また、これに関連して、サマータイムを導入している国などではサマータイムの切り替わる時に時刻がジャンプしてしまうという問題が発生していることもわかった。

Debian5は元々BIOSがGMTであることを期待しており、また、しばらく運用していると(詳細は調べていないがNTPなどで？)BIOS時刻を更新するらしく、この時にGMT時刻に変更してしまう。

いずれにせよ、BIOSはGMT時刻で運用した方が良さそうだ。

OpenSolarisでは、以下のようにすれば良い。
# rtc -c -z GMT
# ntpdate ntp.ring.gr.jp

WindowsはBIOSがlocaltimeでもサマータイム時刻で問題が発生しないよう修正されているようだが、マルチブートなどの時は以下のレジストリキーを作成、設定して再起動すれば良いらしい。
(こちらは必要に迫られていないため、試していない)
HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/TimeZoneInformation/RealTimeIsUniversal
(REG_DWORD = 1)

上記情報はOpenSolarisのバグデータベースからの引用。
http://bugs.opensolaris.org/view_bug.do?bug_id=6247281

OpenSolaris2009.06リリース

ThinkPad X61 OS Distribution Solaris

何気にさっき、OpenSolaris2008.11の仮想マシンをブートしてパッケージの更新してみたら。
異様に大量のパッケージが更新マネージャーに出てきた。

更新しようとしたところ、パッケージ管理用のパッケージを先に更新せよとのダイアログが表示された。
これはもしや、と思い、sun.comのOpenSolarisページに行ってみたら、、、

OpenSolaris2009.06リリース！？

6月1日にリリースするとは。
今ダウンロード中だけど、遅い。。。isoファイルではなく、これまでOpenSolaris2008.11を使用してきた世界中のOpenSolarisが更新かけている？
6月1日にダウンロードしていた更新は、結果として、ダウンロード途中で停止してしまった。(;_;)
隣で別のマシンで行っていたisoファイルのダウンロードが終わってしまったので、そちらを新規インストールすることにした。

以下、OpenSolaris2009.06リリース時のSunのアナウンス「Sun Achieves Major Milestone with New Release of OpenSolaris; Incorporates Open Networking to Deliver Latest Features for Next Generation of Solaris」抜粋のOpenSolaris2009.06でのエンハンス機能の、怪しい日本語訳。。。

  • ネットワークエンハンス

以前からProjectとして開発されていた、ネットワーク高速化機能Crossbowが組み込まれた。ファーストステップ？である今回の機能としては、スケーラビリティのあるマルチコア/マルチスレッドなCPUが非常に速いNICと組み合わせて仮想化されるように設計されたらしい。高速な多数のCPUスレッドと高速NICを組み合わせると、高速で負荷にも強いネットワークができる、ようだ。

  • ストレージエンハンス

ZFSを含め、ストレージも(dozens ofだから、とりあえず)数十くらいのエンハンスがコネクティビティやプロトコルサポートに関して行われたそうだ。ZFSがフラッシュデバイス(恐らくIntel製などの高速SSDと思われる)を完全に統合化してサポートし、フラッシュデバイスの読み書きアクセラレーターとして設計することで、高いパフォーマンスのストレージを巨大なストレージプールとすることができるようになったそうだ。これによりZFSで自動管理されるプールは多くのワークロード(ストレージの負荷とか性能のことだろう)の領域でRAIDコントローラの小さいサイズのキャッシュを時代遅れにしてしまうとか。

CIFS(samba/Windows共有)を(従来からnfsがそうであったように)カーネルネイティブでサポートしたらしい。これにより性能も向上し、さらにWindows共有のセキュリティ、名前空間、アクセス権限などのセマンティクスをWindows、Linux、Solarisで透過的に使用でき、ファイル共有できるようになったそうだ。全体的なストレージ能力を完全に引き出すために、Sunは新しい、iSCSIとファイバーチャネルのブロックプロトコルへの非常にパフォーマンスの高いサポートをSolarisカーネルへ組み込むことを設計してきた。これにより、OpenSolarisの動作しているシステムは、あらゆる仮想ストレージトポロジーへクライアントとして、あるいはターゲットとして加わることが可能となった。

これらのストレージ機能はSolarisプラットフォームに組み込まれているので、Solarisコア機能(フォルト管理、ネットワーキング、マルチスレッドのスケール性、パフォーマンス、セキュリティ、リソース管理の能力)の優位性を完全に利用することができる、とのこと。なるほど。

  • 包括的な仮想化へのアプローチ

今回のアナウンスに伴いSunは、パフォーマンスとスケーラビリティを産業の新たな高さに引き上げるようなネットワーク、ストレージ、アプリケーションの抽象化に対する全体的で(Solarisに)組み込まれた仮想化のデザインを供給し続けてく。ネットワークストレージの仮想化の中にある優位性を構築することで、OpenSolaris OSの中に直接組み込まれた完全な仮想化プラットフォームをユーザに与えるために、OpenSolarisプラットフォームは、SunのCMTシステムとXenベースのハイパーバイザのためのSolarisコンテナや論理ドメイン(LDoms)の形での、キーとなるサーバ仮想化テクノロジーを提供する。世界中で広く使われてきた仮想化テクノロジーのうちの一つとして、Solarisコンテナは軽量で機敏でソフトウェアにより定義される境界を提供する。この境界は仮想化された、数百もの数が存在するエンタープライズクラスのワークロード(負荷、スループットなど？)の仮想サーバを一つのシステムに統合するのに使用することができている。

OpenSolarisはSunから出荷されているx86やSPARCシステムを含み、数千のシステムを完全にサポートしている。これは世界記録を出したシステムや、サービス、サポートのレベルを最も高いレベルに保った安定した、出荷されたシステムを含んでいる。2008年5月に最初にリリースされてからOpenSolarisは、その多用途性を明らかにデモンストレーションする24組の世界記録と産業的なベンチマークを出してきた。その傾向はOpenSolaris20009.06においても続いている。組み込まれた革新性と拡張の優位性によって、OpenSolaris2009.06は、砂金のLinuxリリースと比較し、メモリ管理において35%、整数演算において18%のより良いマルチスレッド管理を提供している。

  • OpenSolaris2009.06に対する新しいサポートサービス

Sunは年度毎のOpenSolarisサブスクリプションを含むよう、SunSpectrumサービスの製品ラインを拡張してきた。それは開発者へのサポートから、我々のグローバルなサポート - そして先を見越したオンラインや電話でのサポート、をデータセンターのスケールのグローバルエンタープライズレベルのアシストとして提供するようになった。SunSpectrumサポートは、技術(テクノロジー)と知識(knowledge)、プロセス、そして顧客を手助けするパートナーに素早く問題を解決し、彼らのシステム製品やオペレーティングシステムテクノロジーのあらゆるところで彼らの成功を最大限ならしめる、実績のある組み合わせを利用しそれぞれに分化したアプローチを提供する。


個人的な用途、の観点で見れば、サポートサービスはお金がかかるのでOpenSolarisを使う意味がなくなるのでおいておいて、純粋にOpenSolarisカーネルが性能向上したらしい、ということと、CIFS(samba)がカーネルに組み込まれたことで恐らく高速化され、またWindows共有との相性が良くなったようだ、ということくらいがメリットかと思われる。

お金持ちな方々には、高速なマルチコアCPUと高速NICカードを組み合わせてのネットワーク仮想化や、高速SSDやRAIDに関するストレージエンハンスもメリットになるかもしれない。。。

和訳に時間がかかってしまって、インストールの法が先に終わってしまったのだが、
実際にインストールしてみて気付いたことをいくつか。

  • Linuxでもリリースアップすると同じだが、背景やgdmのテーマが微妙に変わった。
  • OpenSolarisのLive CDで、grub起動時のメニュー選択によるコンソール起動が可能になった。レスキュー用CDとしては使い易くなった。
  • Firefoxが3.1β3になり、pre-3.5みたいな感じのものが使えるようになった。ただ、これはまだあまり使い込んでいないので、3.0.10との違いがあまりわからない。タブの右側に追加タブを生成するためのアイコンができて、Internet Explorer7?/8やChromeみたいな形でタブを開くことができるようになった。逆に、拡張モジュールで使えなくなったものも結構あった。とりあえずNo ScriptとAdblock Plus、WOT、Download Statusbarなどの、個人的に良く使用していたモジュールは対応済みだったので助かった。また、[BS]キーでページを戻さないようにするaddonが使えなくなったが、そもそも[BS]キーでページが戻ってしまう動作がなくなったので問題ない。
  • シャットダウンが、かなり速くなった、ような、気が、する、、、が、OpenSolaris2008.11まではVMware仮想マシンとしてしか動作させたことがないので、実際どのくらい速くなったのかは謎。
  • ThinkPad X61(CPU: Core2Duo T7300 2GHz, MEM: 2GB)に(Debian5 lennyとのデュアルブートで)インストールした感じでは、Debianに比べ起動が遅いが、起動してしまえば、個人的には速度的に不満はない。VMwareでは音が鳴らなかったが、実機にインストールすると、ちゃんと音が鳴っていた。これは2009.06に限った話ではないかもしれないが、、、(^-^;;;
  • 先にDebian GNU/Linux 5を論理パーティションにインストールしている状態でインストールしたところ、これを認識せず、あせった。。。googleしたところ、OpenSolarisのgrubのmenu.lstに論理パーティション指定でDebian5のエントリを追加したところ、普通に認識した。良かった。。。怖くて試していないが、LinuxのgrubがZFSを認識するとは思えないので、基本的にはMBRがおかしくなったらOpenSolaris Live CDで起動してLinuxのエントリもメニューにあることを確認後、OpenSolarisにてinstallgrubを実行する必要があると思われる。
  • OpenSolaris動作システムをSunに登録すると追加リポジトリが使えるとのことで、登録してみた。途中でエラーが発生しダイアログが表示されたが、登録状況を確認したところ、なぜかちゃんとThinkPad X61の型番などが登録されていた。
  • 追加リポジトリの登録はセキュリティキーや証明書をOpenSolarisに組み込む必要があり、結構面倒くさかった。
  • 追加リポジトリの登録が済み、パッケージマネージャで中を覗いたところ、ATOKがあった！これは嬉しい。早速インストールした。
  • DHCPクライアントとしてのOpenSolarisホスト名をDHCPサーバに認識させるには、Solarisと同じく？/etc/default/dhcpagentと/etc/hostname.e1000g0を編集すればよかった。
  • Solaris10のノリでサービスの動作/停止管理はsvcadmコマンドを使用していたのだが、OpenSolarisでは、[システム]→[システム管理]→[サービスの管理]のGUIでできることがわかった。。。
  • 「ファイバーチャネルストレージなんて高価なモン、持ってないからサービス止めちゃえー」って停止させたら、マルチユーザーで起動しなくなってあせった。依存関係があった。。。

他にもなにかあったかも知れないが、とりあえず触ってみて、まだ忘れていないことは上記くらいかと思う。

VMware NAT接続仮想マシンをLinuxホスト、またはWindowsホストでは一つのNAT接続仮想LinuxマシンでDNSサーバを運用しようとすると、VMwareホストからDNSを引くことができない。

Virtual Machine Windows Linux

まず、当初の私の目論見は、VMware Workstation/Player/Serverが提供しているNAT用のDHCPサービスを停止させ、Windowsホストなら専用の仮想マシンを一台作成、Linuxホストならホスト自身でNAT内でDynamic DNSサービスを実行させ、NAT内の相互マシンどうし、またはVMwareホストからNAT内の仮想マシンへDNSを利用して、hostsファイルを利用せずにホスト名によってアクセスしたい、ということであった。これが実現できれば、VMwareホストからアクセスしたいマシンを必ず静的アドレスで作成し、そのアドレスをホストOSのhostsファイルに記述する、という面倒から解放されると考えたのだ。ところが、残念ながら実際には、このようなことは不可能であることがわかった。

VMware Workstation/Player、またVMware Serverも同様の考え方になると思われるが、VMware NATサービスは、VMware NATネットワークxxx.xxx.xxx.2のアドレスにルータとDNS Proxyが存在する。NAT内の仮想マシンは、これを利用してとホスト外部のネットワークにアクセスする。このDNS Proxyは、(VMwareの実装はわからないが、少なくとも論理的には)VMwareホストOSのネームサービスを利用しているはずである。

そして、私の目論見のように、VMware NATに接続されている仮想マシンのDNSサービスを、VMwareホストがWindowsならばNAT上の仮想マシン、またLinuxホストの場合はホスト自身もDNSサーバとして動作させることができるので、いずれかの方法でセットアップしたとする。そして、VMwareホストOSから、このDNSサーバを参照しようとすると、、、

ホストOSはNAT用のDNSサーバを参照しにいく。そして、そのDNSサーバは、(NAT内のマシンをVMwareホスト外ネットワークにアクセスさせることために、)xxx.xxx.xxx.2なアドレスのVMware NAT DNS Proxyを参照しにいく。このDNS ProxyはホストOSのネームサービス、つまり今回のケースではホストOSのDNSを参照しにいく。ところが！ホストOSはNAT内の仮想マシンのためのDNSサーバを再び参照しにいき、DNS参照のループが発生してしまうようなのである。

論理的にも納得のいく話だが、実際試したところ、やはりうまく行かなかった。

NAT内の仮想マシンがDNS Proxyを通してVMwareホスト外のネットワークにアクセスする構造となっている以上、私の目論見はうまくいかないはずだ。。。

NAT内のマシンからVMwareホスト外部ネットワークへのアクセスのためのDNS参照とNAT内のDNS参照を分離して、NAT内マシンが外部ネットワークへアクセスする時にはホストのDNSのみを利用するが、NAT内マシンどうし、また、VMwareホストからこのDNSサーバを参照した時には、DNS Proxyへの参照(xxx.xxx.xxx.2の参照)を行わず、NAT内のDynamicDNS/DHCPによるDNS情報のみを参照するような工夫ができれば、私の期待することが可能となるのだが。。。

DynamicDNS/DHCPサーバを、NAT内完全ローカルで動作するようにセットアップし、NAT内のマシンは全て、第一優先DNSサーバとしてはこのサーバを参照、次にDNS Proxyアドレスをサーバとして参照すればよいのかもしれないが、これはこれで、NAT内の仮想マシンのセットアップで、せっかくDynamicDNS/DHCPサーバが配布してくれているDNSサーバアドレスがあるのに、おそらくはそれを利用せず手作業でDNSサーバを指定し、加えてその次の優先度でDNS Proxyサーバも参照するよう、全てのDynamicDNS/DHCP管理マシンをセットアップしなければならず、少々おっくうだ。。。

残念。

LinuxホストでVMware Workstation/Playerを動かすときのfirewall(iptables)について

Virtual Machine OS Distribution Linux

Linuxホスト環境で、VMware Workstation 6.5.2/Player 2.5.2を使用している時のfirewallはどう設定すべきか、実際に試してみた。iptablesの設定はホストで行い、基本的にはNAT環境のゲストがガードできるかどうか。なお、私は主にDebian(現在はDebian5 lenny)を使用しているので、設定ファイルの配置はDebian5ディストリビューションに依存している。

Linuxのiptablesには、自ホストへの入力/出力を制御するINPUT/OUTPUTチェイン、複数のネットワークインタフェース間のルーティングに関するパケットフィルタリングを制御するFORWARDチェインがある。

VMware Workstation/PlayerのゲストOSには、仮想NIC(ネットワークインターフェイス)ドライバとして、vmnetX(一般的にvmnet1はホストとゲストのみを接続、vmnet8はNATとして、これに接続した仮想マシンは全て同一のNATネットワーク内に属することになる)がある。また、ホストOSが動作している物理的なマシンと同じネットワークに、別のマシンとして接続されているように見えるブリッジ接続がある。

しかし、ゲストOSは(ドライバは存在するけれども)基本的にホストLinux OSのプロセスとして動作している。なので、恐らくホストオンリー、NATとして使用されるvmnetX(通常はvmnet1とvmnet8)はiptablesから見るとINPUT/OUTPUTチェインで制御でき、FORWARDチェインはDROPさせたままにしておいても良いと考えられる。また、実際VMwareは、Linuxホスト上で動作している時に、一般的にルーティングのために必要な設定/proc/sys/net/ipv4/ip_forwardは0のまま動作している。

ただし、VMwareゲストとの接続NICである(NAT接続の)vmnet8は、iptablesのINPUT/OUTPUTチェインをDROPしていいかどうか試して見たところ、DROPするとアクセスできなくなった。恐らく、ルーティング(FORWARDチェイン)に関する機能はVMwareが不要としているが、vmnetXの先のゲストとホストとの通信でのINPUT/OUTPUTチェインは仮想マシンをホストマシンとは"別のマシン"と意識する仕組みになっているのだろう。

これらのことを確認するためにiptablesを設定してみた。予想通り、FORWARDチェインのパケットは全て破棄(DROP)に設定しても、VMwareゲストは外部ネットワークと通信することが可能だった。また、ブリッジ接続の場合にはどうかも確認してみたが、やはりFORWARDチェインはDROPさせたままで外部ネットワークと通信することができた。

私はiptablesについてはほとんど初心者であるため、パケットフィルタリングにIPアドレスを指定する必然性が理解できなかった。また、使用しているVMwareホストのLinuxマシンがDynamic DNS(DNSとDHCPが連携して、ホスト名をDHSPサーバに渡すと、LAN上の他のマシンからはDNSネームが見える)クライアントであり、またVMwareゲストも基本的にはNAT接続かつVMwareのDHCPは使用せずdnsmasqを利用してDynamic DNSクライアントとして動作させる運用であるため、IPアドレス指定のパケットフィルタリングは行っていない。

さて、iptablesでのファイヤーウォール設定であるが、以下のようなポリシーで行った。

  • VMwareホストから外部に出たパケットに関連するパケット以外は、外部からのパケットは全てDROP。
  • VMwareゲストは全てNAT接続で構成しているので、vmnet8(ついでにvmnetX全て)で接続されているゲストとの相互パケットは全てACCEPT。

非常にシンプルであるが、以下のような設定スクリプトになった。スクリプト名はfirewall-startとした。外部との接続はeth0、VMwareゲストとの相互通信はvmnetXで行うとしている。

#!/bin/sh

# iptablesポリシーの初期化
# 基本的には、全てのチェインのパケットを通過させない。
# 以降の設定ルールにマッチした場合は、そちらが優先となる。

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

# このスクリプト実行前のiptables設定をクリア
# (現在このスクリプトではユーザ定義チェイン、パケットカウンタ、バイトカウンタは
# 使用していないが、他のスクリプトの考慮と、今後使用する可能性を考え、消去している。)

iptables -F # iptables内蔵チェイン内容を全て消去
iptables -X # ユーザ定義されていたチェイン内容を全て消去
iptables -Z # 全チェインのパケットカウンタ、バイトカウンタを全て消去

# loopbackインタフェース(このホスト内部での相互通信)の設定(全て許可)

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# vmnetで接続された仮想マシンとVMwareホストとの相互通信設定(全て許可)
# (vmnet+はiptablesの仕様でvmnet[0-9]全て、というような意味を表す)

iptables -A INPUT -i vmnet+ -j ACCEPT
iptables -A OUTPUT -o vmnet+ -j ACCEPT

# このVMwareホストと外部(eth0インタフェース)との通信設定
# (外部へのアクセスは全て許可、そのアクセスに関する外部からのアクセスは許可)

iptables -A OUTPUT -o eth0 -j ACCEPT
iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

Debian5での設定として、ネットワーク初期化前にこのスクリプトを実行するため、firewall-startを/etc/network/if-pre-up.dに配置した。

また、停止スクリプトとして、大したことはしていないが、以下のfirewall-stopを作成。コメントはfirewall-startと同様なので省略。

#!/bin/sh

iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

iptables -F
iptables -X
iptables -Z

このスクリプトfirewall-stopを/etc/network/if-post-down.dに配置した。

このスクリプトにより、取り合えず単純な外部からのアクセスは完全に破棄(DROP)するので、通常使用には問題ないと思っている。

ただし、このVMwareホスト自身と、VMware内部の仮想マシンからのパケット流出を考慮するには、もう少し(firewall-startの最後から一つ前の行)の処理を検討する必要があると思われる。