何もする必要はありませんでした。。

xenの仮想サーバーでDom-U(ゲスト)をインターネット向けのサーバーとして利用することになりました。

Dom-0(ホスト)用のハードウェアにはインターフェイスがeth0, eth1の2つあり、そのうち、eth1を内部LAN向けのインターフェイスとして使っています。

Dom-Uもネットワークインターフェイスを2つ作り、eth1を内部LAN向け、eth0をインターネット向けとして、それぞれ、Dom-0のブリッジとつなげました。

VMware では、ホストOSのインターフェイスを停止させると、そのインターフェイスを使っているゲストOSのインターフェイスも使えなくなってしまいます。

そのため、xenでもDom-0のeth0インターフェイスはあげておく必要があると思いましたが、落とした状態でもDom-Uの外向けインターフェイスは利用可能でした。

こんな状態と思っていましたが

INTERNET
  --+------------------------------
    |
    |
    |  +-------------------------------+
    |  | +---------------------------+ |
    |  | |       Dom-U (ゲスト)      | |
    |  | | +--------+     +--------+ | |
    |  | | |  eth0  |     |  eth1  | | |
    |  | | +--------+     +---+----+ | |
    |  | +-----|--------------|------+ |
    |  |       |              |        |
    |  |   +---+----+     +---+----+   |
    |  |   | vifbr0 |     | vifbr1 |   |
    |  |   +---+----+     +---+----+   |
    |  |       |              |        |
    |  |   +---+----+     +---+----+   |
    +------+  eth0  |     |  eth1  +------+ < < eth0 が停止状態だとDom-Uも外にいけない
       |   +--------+     +--------+   |  |
       |        Dom-0 (ホスト)         |  |
       +-------------------------------+  |
                                          |
LAN/INTRANET                              |
  ----------------------------------------+---

そういうわけではなく、virtual interfaceで外と通信している

INTERNET
  --+------------------------------
    |
    |
    |  +-------------------------------+
    |  | +---------------------------+ |
    |  | |       Dom-U (ゲスト)      | |
    |  | | +--------+     +--------+ | |
    |  | | |  eth0  |     |  eth1  | | |
    |  | | +--------+     +---+----+ | |
    |  | +-----|--------------|------+ |
    |  |       |              |        |
    |  |   +---+----+     +---+----+   |
    +------+ vifbr0 |     | vifbr1 +------+
       |   +---+----+     +---+----+   |  |
       |       |              |        |  |
       |   +---+----+     +---+----+   |  |
       |   |  eth0  |     |  eth1  |   |  | < < eth0 が停止状態でもDom-Uには関係なし
       |   +--------+     +--------+   |  |
       |        Dom-0 (ホスト)         |  |
       +-------------------------------+  |
                                          |
LAN/INTRANET                              |
  ----------------------------------------+---

状態のようでした。

自分のPC (Wndows XP Pro)のVMware Server を1.0.7から2.0にしたら、vmware-hostd.exe がアプリケーションエラーとなってしまった。。

Googleで検索した、こんな方法や、サポートページを調べたが、解決しませんでした。

解決方法は、以下でした。

Documents and Settings/All Users/Application Data/VMware/VMware Server/vm-list

を見てみると、次のような感じ。

# This file is automatically generated. 
# Hand-editing this file is not recommended. 
config "C:\Virtual Machines\xxxxx-dev\Other Linux 2.6.x kernel.vmx"
config "C:\Virtual Machines\xxxxx-test\Other Linux 2.6.x kernel.vmx" < < これは削除したはず

前のバージョンで削除していたゲストOSのイメージがリストされていました。
この行を削除して、サービスから、VM Host Agent を再起動すると、うまくいきました。

とあるプロジェクトで、オープンソースのプロキシサーバ「pound」を使いました。

その中で、気になったことなどをメモしておきます。

設定は簡単

特にSSLの設定は非常に楽です。 設定ファイルの書き方も明快でわかりやすいのでメンテナンス上も良いです。

バックエンドのWebサーバーはクライアントIPアドレスが変わる

バックエンドではクライアントIPアドレスがプロキシサーバーのアドレスとなるため、バックエンドのウェブサーバー(今回はapache)でログのフォーマットを修正する必要がありました。 X-Forwarded-For にクライアントIPアドレスは渡されるため、Webサーバーではこの値をログするように変更しました。

ログの出力方法によってパフォーマンスに影響がある

Poundのログはdefaultでsyslogに出力することができます。ただ、この設定をするとパフォーマンスが目に見えて悪くなりました。 LogFacilityを – に設定するとログは標準出力なります。 1. ログ出力なし 2. 標準出力 3. syslogに出力 上記の3つの設定では3番の方法で極端にパフォーマンスの低下が見られました。

そのため、今回はPoundのログは標準出力にしました。

クライアントIPアドレスでのフィルタはできない

プロキシサーバーを使う前は、特定のIPアドレスに対してapacheでDenyの設定をしていましたが、この方法は使えなくなりました。 – iptables で設定 – アプリケーションで設定

と考えられましたが、今回はアプリケーションに実装する予定です。

設定ファイルのリロードはできない

設定ファイルを書き換えた場合、反映するためにはreload ではなく、 restartが必要となります。(reloadは無い) 今回のシステムでは瞬間的な停止は許容範囲のため、そのまま運用しています。

導入までの手間は非常に少なかったのですが、細かい設定ができないのでした。