- PR -

回線冗長化について

«前のページへ 1|2
投稿者投稿内容
blunder
ベテラン
会議室デビュー日: 2003/09/11
投稿数: 65
投稿日時: 2008-01-17 19:17
私もまだちゃんと読んでないのですが、この辺なんかどうでしょうね？
picoさんのやりたいことに何だか近い気がします。
ルータ(Cisco)だけでできそうだし、何だか面白そうです。
やっぱりLinuxでやるよりはCiscoのほうが．．．．
内容は実は私もまだ理解できてないです（ごめんなさい）。

Small Site Multi-homing
http://www.nil.com/ipcorner/SmallSiteMultiHoming/
Redundant Small Site Multi-homing
http://www.nil.com/ipcorner/RedundantMultiHoming/

追記
サーバを公開するってことになると、これだけじゃ不足で、DNSも何か
工夫しなければならないのかもしれませんが、私もまだそこまで考えが
回っていません。
というかほとんど何も考えてませんが。
picoさんのほうで考えてみてください。


[ メッセージ編集済み 編集者: blunder 編集日時 2008-01-17 19:32 ]
pico
会議室デビュー日: 2008/01/12
投稿数: 7
投稿日時: 2008-01-17 20:14
BackDoor様、 blunder様

お返事ありがとうございます。

色々と考えたのですが、BackDoor様のおっしゃる通り、Linuxルータ２台にするよりも、アプライアンスのルータを１台購入してマルチホーミングとするのが一番安定して悩み事も少なくてみんな幸せかな、と思いました。


blunder様に示していただいたリンクは、LAN側にクライアントPCが存在する場合には良いのですが、LAN側に公開サーバがいる場合にはうまく動作しないのではと思いますが、いかがでしょうか。

外部のクライアントのIPがa.b.c.d
GW-AのWAN側IPが1.1.1.1
GW-AのLAN側IPが192.168.0.1
GW-BのWAN側IPが2.2.2.2
GW-BのLAN側IPが192.168.0.2
公開サーバのDNSサーバ上のアドレスが1.1.1.2, 2.2.2.3
公開サーバの実際の(LAN内の)アドレスが192.168.0.101

とすると、

STEP1 クライアント→GW-A：src=a.b.c.d dst=1.1.1.2
STEP2 GW-A→公開サーバ：src=a.b.c.d dst=192.168.0.101(★ここでGW-AがdstをNAT変換)
STEP3 公開サーバが応答を返す際：src=192.168.0.101 dst=a.b.c.d

となり、STEP3でGW-Aに行くべきかGW-Bに行くべきかがわからなくなると思います。GW-Bに行ってしまうと、

STEP4 GW-B→クライアント：src=2.2.2.2 dst=a.b.c.d

となってしまい、クライアント側のルータではじかれてしまうと思います。
これを解決するには、GW-AのLAN側のサブネットとGW-BのLAN側のサブネットを分けて、

GW-AのLAN側IPが192.168.0.1
GW-BのLAN側IPが192.168.1.1
公開サーバのNIC1のIPが192.168.0.101
公開サーバのNIC2のIPが192.168.1.101

とすれば、公開サーバのルーティングの設定で、クライアントからのパケットをどちらのNICが受け取ったかによって、正しいGWを選択して応答を返すということが可能になると思います。

あるいは、GW-A,GW-Bに特殊な機能があり、★の部分について

STEP2' GW-A→公開サーバ：src=192.168.0.1 dst=192.168.0.101

と、GW-AがdstについてNAT変換しつつsrcについてはNAPTを行えば、

STEP3' 公開サーバ→GW-A：src=192.168.0.101 dst=192.168.0.1
STEP4' GW-A→クライアント：src=1.1.1.2 dst=a.b.c.d

と、うまくいくかと思います。でも、こんなルータってあるのでしょうか・・・。
blunder
ベテラン
会議室デビュー日: 2003/09/11
投稿数: 65
投稿日時: 2008-01-18 11:16
引用:

色々と考えたのですが、BackDoor様のおっしゃる通り、Linuxルータ２台にするよりも、アプライアンスのルータを１台購入してマルチホーミングとするのが一番安定して悩み事も少なくてみんな幸せかな、と思いました。


はい。

引用:

blunder様に示していただいたリンクは、LAN側にクライアントPCが存在する場合には良いのですが、LAN側に公開サーバがいる場合にはうまく動作しないのではと思いますが、いかがでしょうか。


私も土、日に読む予定で、まだ斜め読みしただけですが、リンク先の記事はそうかも
しれません。
それをヒントにしてサーバ公開の話はその「応用」で考えればいいのかなと思っています。
ただpicoさんの目的はサーバ公開なので、ちょっと的外れだったかもしれませんね。
失礼しました。

引用:

STEP1 クライアント→GW-A：src=a.b.c.d dst=1.1.1.2
STEP2 GW-A→公開サーバ：src=a.b.c.d dst=192.168.0.101(★ここでGW-AがdstをNAT変換)
STEP3 公開サーバが応答を返す際：src=192.168.0.101 dst=a.b.c.d

となり、STEP3でGW-Aに行くべきかGW-Bに行くべきかがわからなくなると思います。GW-Bに行ってしまうと、


「わからない」といえばたしかに「わからない」ですね。
もしVRRPを使っているなら、戻りパケットは単純にVRRPマスターに行くだけでしょうね。
で、そうなるとリターンパスが違いますから、たしかに戻り時のアドレストランスレーション
は失敗するでしょうね。
おっしゃる通りです。

引用:

GW-AのLAN側IPが192.168.0.1
GW-BのLAN側IPが192.168.1.1
公開サーバのNIC1のIPが192.168.0.101
公開サーバのNIC2のIPが192.168.1.101

とすれば、公開サーバのルーティングの設定で、クライアントからのパケットをどちらのNICが受け取ったかによって、正しいGWを選択して応答を返すということが可能になると思います。


私もそのイメージに近いですね。
それで合っていると思います。
ただ私の考えは、かならずしもデフォルトルートやVRRPには頼らないで、必要に応じて
RIPやOSPFを使うというものなので、その辺が微妙に違うかもしれません。
デフォルトルートやVRRPだけで本当に全部できるのかは．．．．
ちょっと苦しいかも、という感じです。

引用:

あるいは、GW-A,GW-Bに特殊な機能があり、★の部分について

STEP2' GW-A→公開サーバ：src=192.168.0.1 dst=192.168.0.101

と、GW-AがdstについてNAT変換しつつsrcについてはNAPTを行えば、

STEP3' 公開サーバ→GW-A：src=192.168.0.101 dst=192.168.0.1
STEP4' GW-A→クライアント：src=1.1.1.2 dst=a.b.c.d

と、うまくいくかと思います。でも、こんなルータってあるのでしょうか・・・。


素晴らしいです。まさにそうすればいいと思います。
上のルーティングと下のこのNATを組み合わせるというイメージです。
私はそれくらいは「できる」ものと思ってましたが、実際はどうなんでしょうね。
要検証かも．．．．

でも結論的には、専用アプライアンスを使うというので、いいと思います。
ルータでやると、意外と複雑になるかもしれません。たぶん専用アプライアンスを使う
のが「現実解」なのだと思います。無理して複雑な構成を組む必要はないと思います。

では。
たらお
大ベテラン
会議室デビュー日: 2006/12/25
投稿数: 206
お住まい・勤務地: 東京・永代通り
投稿日時: 2008-01-23 23:12
構成2のパターンなら、マルチホーミングも可能かと。

まずVRIDを3つ用意して、WAN側に2つ、LAN側に1つ付与します。
インタフェースグルーピングは、取り合えずなしで考えます。
以下のような構成になると思います。

コード:
 (ISP-A)   (ISP-B)
   |          |
   |          |
 [Hub1]-----[Hub2]
   |          |
   |VR1       |VR2
[Router1]==[Router2]
   |    VR3   :Standby
   |          :
 [Hub3]-----[Hub4]公開セグメント
  ||||       ||||
  ||||       ||||
  ||||       ||||

配線は、タスキ掛けなし、Router間のリンクは、L3リンクです。
これなら、STPで頭を捻ることもありません。

ただ、異なるISPへの認証と返り経路のバランシングをを考えると、頭が痛いですね。
SSG-140では、PPPoEで振り出されたIPをスタンバイ側が引き継ぎます。
こんな構成です。

 (ISP-A)     (ISP-B)
   |            |
   |            |
 [Hub1]-------[Hub2]
   |            :
   |            :Standby
[SSG140-1]==[SSG140-2]
   |     VR1    :Standby
   |            :
 [Hub3]-------[Hub4]公開セグメント
  ||||         ||||
  ||||         ||||
  ||||         ||||

この場合は、VRIDは1つだけ、NSRP(VRRP)によるインタフェースグルーピングです。
考え方がシンプルになり、設計もらくそうです。
それでも、返り経路のバランシングに悩みそうです。


_________________
＿福田太郎＿
«前のページへ 1|2

スキルアップ／キャリアアップ（JOB@IT）