2009/01/17(Sat)ESET Smart Security + VMware ブリッジモードのFW設定
2009/01/17 17:15
今のところ、システムは安定。うーん、x64のファイアウォールって難しいな。
さて、閑話休題。
今度はそのESET Smart Securityに変えた後、VMwareのブリッジモードでゲストOSが外にアクセスできないということになった。
その原因を追ってみる。
追記
もっと手軽に設定できる箇所があったので、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が自動同期してくれるから、どっちでもいいっちゃいいけど……。
これでブリッジモードでも安全に通信できるようになりましたとさ。