今回は検証環境のネットワーク周りについて書きたいと思います。

検証時にやってはいけないこと

検証をする時には自由にサーバーを立てたりするわけですが以下のようなことをすると非常に大変なことになってしまいます。

- IPアドレスをバッティングさせてしまう

きちんと通信できませんし、場合によってはもともと正しくそのIPアドレスを使っていた本来のホストが通信できなくなってしまうようなことにもなります。それが重要なサービスを行っているサーバーだったりすると……。

- DHCPサーバーを本番ネットワークで立ててしまう

検証用ネットワーク…のつもりで構成してあると、起動して間違ったDHCPサーバーからIPアドレスを受け取ってしまったホストがすべてきちんと通信できなくなります。私の所属する会社でも昔は新人が配属された直後に毎年のようにこの事故が起きてました…。

- ホスト名、ドメイン名をバッティングさせてしまう

Windowsネットワークではホスト名やドメイン名は重複できません。特に同一セグメント内ではブロードキャストしてますので、ホスト名が重複しているというエラーが表示されちゃいます。同一セグメント内で同じドメイン名、特に同じBETBIOSドメイン名なんて作ってしまうとまともに動かなくなると思います。マニアックなところでは、ドメイン名と同じホスト名が存在してたりするとドメインに参加しているホストのすべてが起動するたびにホスト名の重複のエラーが表示されたりします。この時ホスト名同士が重複しているわけではないので原因を探すのにちょっと時間がかかったりします。

このようなことがありますので、検証用のネットワークはきちんと本番のネットワークから独立させようという話が出てきます。もちろん独立させるべきです。ただ、単純に独立させてしまうと今度は以下のような場面で不便です。

- Microsoft Updateを実行したいけどできない。
- 検証環境にファイルを持ち込んだり持ち出したりしたいけどできない。USBメモリ、UBS HDDは使用禁止だし…。
- 自分のPCからリモート接続できたら便利なのにできない…。

このようなことがあるので、検証環境を本番環境から安全に分離しつつ利便性を損なわない構成にしたくなります。

もっとも、セキュリティを最重視するのであればネットワークは完全に切り離されるべきですし不便であるべきです。部屋も別、携帯等の持ち込みも禁止……、というような環境もあります。私はそこまですると非効率すぎて逆に事故が増えるのではと思いますが…。

具体的な方法

いくつか具体的な対象方法を挙げてみます。

- 検証環境と本番環境の両方に接続するホストを作り、そのホスト上で必要なProxyを動作させる。ファイルの中継場所にする。
- 検証環境と本番環境の間にFWやNATを設け、必要な通信のみ行えるようにする。
- 検証環境からインターネットにアクセスする回線を別途設ける。

どれかひとつだけやればいいというわけでもなく、並行してやっても良いです。他にも色々なやり方があるとも思います。

また、検証環境が仮想環境上にある場合などはネットワーク的には完全に切り離しつつコンソールにアクセスすることが基本機能でできますね。最近はもうこういう環境の方が多いかもしれませんね。ただ、Hyper-Vのコンソールなどはコピペすらまともにできず酷いもんですが…。

よく使うソフト

私がよくつかうソフトを一応紹介しておきます。実はあまりよく調べて選んでいるわけではないのですが便利に使わせてもらっています。

DeleGate Home Page (www.delegate.org)

Hyper-Vの物理ホストあたりにはProxyとしてDeleGateを仕込んでおくことが多いです。

 

BlackJumboDog ちょっとした検証の時にGUIでちょちょいっと設定して動かせちゃうので重宝します。Proxy以外にも色々なサーバーになれてしかもデバッグ表示が優れているので検証用途には重宝しています。