- ベストアンサー
複数LANポートにネット設定する方法とは？
- 社内のイントラネット環境で、新設したネットワークにDBサーバを接続するためにはどのような設定が必要でしょうか？
- サーバにLANポート２つを使い、新規ネットと従来ネットを設定し、どちらでもDB接続可能な状態にしたいです。設定方法を教えてください。
- サーバのネットワークを２つ設定することは、ネットワークの仕様上問題ないでしょうか？
- OrcaEater
- お礼率100% (16/16)
- その他（ITシステム運用・管理）
- 回答数3
- ありがとう数3
- みんなの回答 （3）
- 専門家の回答
質問者が選んだベストアンサー
＞(1)上記のような構成で、サーバのネットワークを２つ設定する事は、ネットワークの仕様上問題ないのでしょうか？ ネットワーク設定自体は出来ますが、構成上ルーティングに問題が出ると思います。 （サーバから見た宛先が同一ネットワークであるため） ＞(2)ネット仕様上問題なければ、これを実現する設定を教えて頂けませんでしょうか？ DBサーバであれば特殊な通信ではないと思いますので、 サーバは新しいIPアドレス体系で設定し、ルータで旧IPアドレスが新IPアドレスになるように静的NATによるIPアドレスの変換を行うほうが現実的ではないかと思います。 ただこの場合ルータがもう一台必要になります。 具体的な設定は、ルータの一方を従来ネット（図の黒い線）、もう一方を新規ネット（図の赤い線）につないで、従来のサーバIPアドレス＝新規のサーバIPアドレスでNATします。 お望みの回答にならないかもしれずに申し訳ありませんが、私が思いつくのはこんなところです。
その他の回答 (2)
- maesen
- ベストアンサー率81% (646/790)
route addのinterfaceはどのように設定しましたか？ ＞1-1)クライアント→サーバの従来IPにecho要求する ＞ ・クライアントから図中の黒い線を経由してサーバに到達。 ＞ src:クライアントのIP。dst:サーバの従来IP ＞ ・サーバからは図中の赤い線の経由してecho応答。 ＞ src:サーバの新規IP。dst:クライアントのIP。 これを見ると新規IPのインターフェースがプライマリなのでルーティングテーブルのインターフェースが新規IP側になっているだけのような気もします。 ICMPはコネクションレスなのでこれでもいいのですが、TCPはコネクション内のサーバ→クライアントの通信で（上記の下側の通信）送信元が新規IPになってしまったら通信が出来ません。 実際の通信はTCPが大半だと思いますのでTCPにて検証を行う必要もあります。 ＞このecho応答を返せないという動きが「ルーティングに問題が出る」るということになるのでしょうか？ サーバ側の必要条件として、受信したインターフェース（＝IPアドレス）から送信するということが条件になると思います。 これが担保出来ないとTCPが通信出来ないと思うのです。 ちょっとLinuxの動きはわかりませんが、ルーティングの設定ではこの必要条件を見たすことが出来ないのではないかと思い「ルーティングに問題が出る」と思いますと書いたわけです。 実際に検証したわけではないのでうまくいく可能性も無いとはいえませんが。 ＞ただルータをもう一台購入するのは現状では厳しいので、もうちょっと色々検討します。 新規で買わなくてもそれほど長期間ではないと思いますのでうまいこと調達できないでしょうか。 クライアント数やトラフィック量がわかりませんが、それほど高性能である必要もないと考えます。（移行期間中多少遅くても我慢してもらう） ヤフオクでRTX1000やIX2015なんかが2000～3000円で入手出来ると思うのでこれらもねらい目だったりするかも（ヤフオクだめだろうな～） 勝手なことを言って申し訳ないです。
お礼
TCP通信について現象を調査しました。 参照されている方の後学のためにも結果を記したいと思います。 ＜前提＞ windows server 2008おいて、ルートテーブルに一部追加をした結果、２つのインタフェース(1)192.168.10.10(以下IF1と呼称)、(2)192.168.1.10(以下IF2と呼称)のそれぞれにecho要求したらそれぞれecho応答が来るようになった。 しかし、ICMPはコネクションレスのプロトコルであるため、たまたま正常に動作しているように見えただけかもしれない。 そこで、コネクションが必須なTCPプロトコルでの動作を検証する。 サーバのルートテーブル設定は以下のようになっている。 ※ネット構成 192.168.10.0/24は新規のサーバルーム用ネット 192.168.1.0/24は従来のサーバルーム用ネット(老朽化後日撤廃予定) 192.168.3.0/24はサーバに接続するクライアントが属するネット >netstat -rn IPv4 ルート テーブル =========================================================== アクティブ ルート: ネットワーク宛先 ネットマスク ゲートウェイ インターフェイス メトリック 0.0.0.0 0.0.0.0 192.168.10.1 192.168.10.10 266 192.168.3.0 255.255.255.0 192.168.1.1 192.168.1.10 11 ※ 192.168.1.0 255.255.255.0 リンク上 192.168.1.10 266 192.168.1.10 255.255.255.255 リンク上 192.168.1.10 266 192.168.1.255 255.255.255.255 リンク上 192.168.1.10 266 192.168.10.0 255.255.255.0 リンク上 192.168.10.10 266 192.168.10.10 255.255.255.255 リンク上 192.168.10.10 266 192.168.10.255 255.255.255.255 リンク上 192.168.10.10 266 (以下無関係なので省略) =========================================================== 固定ルート: ネットワーク アドレス ネットマスク ゲートウェイ アドレス メトリック 0.0.0.0 0.0.0.0 192.168.10.10 既定 =========================================================== ※アクティブルートの2行目の※をつけた行が追加した設定。メトリックは指定しなかったら自動で11がついた。 ＜方法＞ route addによってゲートウェイをデフォルト以外に設定された192.168.3.0/24のPC 192.168.3.254(以下クライアントPCと呼称)から、サーバの持つIF1,IF2のそれぞれを通してサーバ内の共有フォルダを参照し、かつファイル作成できるか検証。 なおIF2から通じるレピータハブを経由してパケットをキャプチャする。キャプチャの条件としては[クライアントPCのIP or サーバIF1のIP or サーバIF2のIP」を指定。 ＜調査＞ (1)クライアントPCよりエクスプローラにて\\［IF2のIPを直接入力］にてを共有フォルダを参照。 するとIF2からのパケットキャプチャ上で３ウェイハンドシェイクを確認できた。 共有フォルダも開けて、ファイル作成も問題なし。 つまりpingと異なりIF1を使った通信はしていない事が確認できた。 (2)マイクロソフトのファイル共有セションを閉じるためにサーバ側では強制的にセション切断（管理ツールより）。クライアントPCにおいてもセションが残らないようPCを再起動。 (3)クライアントPCよりエクスプローラにて\\［IF1のIPを直接入力］にてを共有フォルダを参照。 IF1側はパケットキャプチャ出来る環境がないが、IF2側のキャプチャには一切反応がないためIF1のみを用いて通信していると考えられる。 共有フォルダも開けて、ファイル作成も問題なし。 ＜結論＞ Windows Server 2008においては、私の希望通りの動きをするものと考えられる。 しかしルートテーブル設定において、クライアントPCへの通信はすべてIF2を使うように指示しているはずなのに、ケースバイケースで送信IFを変えるというのは腑に落ちない。Microsoftのバグでなければよいのだが・・。 こんな感じです。また、linuxについては対応方法が皆目見当つかない状態が続いていますので、本質問はこれでcloseにして、カテゴリlinuxで同様の質問をあげようと思います。 長々とありがとうございました。
補足
>route addのinterfaceはどのように設定しましたか？ route add [クライアントのいるネットワーク] mask [255.255.255.0=クライアントのいるネットワークのマスク] [従来のIFのゲートウェイ] IF [従来のIFのIPアドレス］ と設定しました。 目的に沿った設定ではない事はわかっていますが、検証の一環としてこんなことをやったらどうなるか試したらpingはうまくいったので、ここからなにか策が見つからないかと検証している段階です。 >実際の通信はTCPが大半だと思いますのでTCPにて検証を行う必要もあります。 その通りですね。これは検証します。結果は後日お礼のほうに記載したいと思います。 >新規で買わなくてもそれほど長期間ではないと思いますのでうまいこと調達できないでしょうか。 ネットを切断できる期間も限られていますので、設置したら外すタイミングは1年後とかになってしまうのです（；＿；）。 しかし、今後も同様なサーバが現れるでしょうから、NATについては今回はあきらめますが、来年度予算とかには盛り込んで信頼できるもの（即日保守サポートしてもらえるような）を準備しようと思います。 NATを紹介してもらえてありがたく思っております。
- beefisdead
- ベストアンサー率63% (92/145)
二つのインターフェイスにそれぞれ別のアドレスを付けるのはごくごく普通のことです。 どうぞ引き続き設定なさってください。
お礼
質問（１）については問題ないということですね。 ありがとうございました。
補足
設定方法についてですが、ゲートウェイアドレスを二つつけてはいけないのですよね。 それを回避するためにroute addコマンドで、クライアントの存在するネットからの通信では従来IPをゲートウェイとするように設定したら、たまたまwindows server 2008では正常動作しました。 でもとRedHut Enterprise Linuxでは動作が違っていて希望通りの動きをしてくれません。 どのように設定するのが正しいのでしょうか・・。
お礼
回答ありがとうございます。 複数ポートを使いたいということではないので、目的に対して広い視点からの回答をいただけてありがたいです。 ただルータをもう一台購入するのは現状では厳しいので、もうちょっと色々検討します。
補足
間にNATを持たせるのは非常にシンプルな対応で好ましいです。採用したいところですが・・残念ながら予算がありません。 ルーティングについては確かに一般的ではない動きをしますね。キャプチャして確認しました。 1)なぜかうまく動作しているWindows Server 2008の場合。 （いずれもroute addで追加したIP体系のクライアントとの通信の検証です) 1-1)クライアント→サーバの従来IPにecho要求する ・クライアントから図中の黒い線を経由してサーバに到達。 src:クライアントのIP。dst:サーバの従来IP ・サーバからは図中の赤い線の経由してecho応答。 src:サーバの新規IP。dst:クライアントのIP。 1-2)クライアント→サーバの新規IPにecho要求する。 ・クライアントから図中の赤い線を経由してサーバに到達。 src:クライアントのIP。dst:サーバの新規IP ・サーバからは図中の赤い線を経由してecho応答。 src:サーバの新規IP。dst:クライアントのIP。 ※この動作自体route addした動きとは違う(echo応答のsrcは従来IPになるように設定したつもり)のですが、結果的には通信できています。サーバが自動でIPフォワーディングしてくれているのかな？ 2)希望通りの動作をしないLinuxの場合。 2-1)クライアント→サーバの従来IPにecho要求する ・クライアントから図中の黒い線を経由してサーバに到達。 src:クライアントのIP。dst:サーバの従来IP ・サーバからは図中の黒い線を経由してecho応答。 src:サーバの従来IP。dst:クライアントのIP。 2-2)クライアント→サーバの新規IPにecho要求する。 2-2-1）echoの応答がない。 ・echo要求はクライアントから図中の赤い線を経由してサーバに到達。 src:クライアントのIP。dst:サーバの新規IP ・サーバからはまったくecho応答が出されていない。 2-2-2)echo応答がある。 ・echo要求はクライアントから図中の赤い線を経由してサーバに到達。 src:クライアントのIP。dst:サーバの新規IP ・サーバからは図中の黒い線を経由してecho応答。 src:サーバの従来IP。dst:クライアントのIP。 ※2-2-1)と2-2-2)の違い なぜか、いったん従来IPにpingを通してから5～10分位の間だけ2-2-2)の状態になる。 ※route addの設定としては2-2-2)の動作のように黒い線を経由する動作は正常と思われる。しかし、通常はecho応答を返せない。 このecho応答を返せないという動きが「ルーティングに問題が出る」るということになるのでしょうか？