Kerosoft : Modus Operandi

この間から起こっていた0x3bの件がWindbgによってminidump検証したらkl1.sys（Kasperskyのファイアウォールフィルタドライバ）が原因であることが分かったため、KasperskyをやめてESETに移ってみた。
今のところ、システムは安定。うーん、x64のファイアウォールって難しいな。


さて、閑話休題。
今度はそのESET Smart Securityに変えた後、VMwareのブリッジモードでゲストOSが外にアクセスできないということになった。
その原因を追ってみる。

追記 2009/09/09

もっと手軽に設定できる箇所があったので、ESET Smart Security + VMware ブリッジモードのFW設定 part.2を参照。

まずは

このファイアウォールが原因なのか、それを突き止める。
とりあえず自分のPCはルーターの内部に居たので、少々ファイアウォールサービスを止めても影響ないかな、ということで、一旦全て停止。
すると、ゲストOSから外部に正常にアクセスできた。

ということは、ESETのファイアウォールが原因で間違いない。

ちなみに、DMZ状態のPCではしないように。外から筒抜けになってしまう。この場合の手順は次を参照。

試験用フィルタの作成

こういうときのために、次のようなルールを作成する。
ルール名は何でもよいが、とりあえず

• 制限緩めで通すこと。（特に外向きUDPだけ設定して、内向きUDPの設定をし忘れることが多い）
• ユーザー通知とログ記録を有効にすること

に注意すればよい。

DMZ環境の場合は、アクションを許可ではなく確認にすることをお忘れなく。
非常に大量の確認メッセージが出ることが予想できるが、ツーツーにするよりはマシかと。目当て以外の通信には根気強く拒否を押してください。

ちなみに、このルールはアプリケーションを指定しないので、アプリケーションツリー表示では見れません。
「ゾーンとルールの設定」ダイアログで、「詳細表示（すべてのルールを表示）に切り替え」をクリックすると出現します。

試験

次に、該当の通信アプリケーションを動作させます。
すると、右下にこんなポップアップが出ます。

それから、ログを見に行くと、先ほど追加した「試験用」ルールで通した通信が見れます。

原因究明

なるほど、ルーターの53番(DNS)からの内向きが通れないわけですか。
どうやら、VMwareの内側から名前問い合わせしたとき、外向きはvmware.exe辺りのルールで通過できるものの、返答のUDPパケットが遮断されている状態。アプリケーション名が空っぽですね。
まあ、ルーター圏内だし、信頼ゾーン区間のDNSのパケットは信じるということにして、次のようなルールを作ります。

これでゲストOSのWindows XPから名前が引けるようになり、無事ブラウズなど自由にできるようになった。

サーバーを立てている場合

私のように、VMware内部のゲストOSにサーバーを持たせていて、インターネット側からアクセスさせたいと考えている場合は、上記の設定だけではパケットが通らない。
どうやら、内向きの設定もアプリケーション名の指定なしで設定する必要があるみたい。

上記と同様の方法でどういうルールを作るか考えてみる。

ふむ、アプリケーションの設定なしで22番を開ければよさそうだ。

ついでに、UDP123番のNTPポートもブロックされていたようなので、ルール追加。
まあこれはVMware Toolsが自動同期してくれるから、どっちでもいいっちゃいいけど……。

これでブリッジモードでも安全に通信できるようになりましたとさ。