自宅サーバーを運営しているのですが、現在、知り合いのサイトなどを含め40サイト程一つのサーバー上へ設定してあります。トラフィックが増加してきた為、プロバイダへの負荷分散対策として、複数のプロバイダと契約を行い20サイトづつ別々のプロバイダを通して提供したいと考えております。

あの～、「1本の光ケーブルで２セッション」だと、そもそも、回線帯域は元の B フレッツの太さで決まるんで、帯域の負荷分散にはならないと思うんだけど...。

まぁ、厳密には確かに、B フレッツの先の ISP での帯域もあるので、トータルの帯域が増える「可能性」はあるけど、少なくとも２倍にはならないと思います。

あと、ルータを２台おいても、サーバから見たときのデフォルトゲートウェイが片方になるので、サーバから出て行くパケットは、サーバに届いたパケットがどっちのルータを通ったかに関わらず、デフォルトゲートウェイに指定されたルータへ向かって投げられます。

ということは、クライアントから見ると、送ったパケットの宛先の IP アドレスと違う IP アドレスから戻りのパケットが届く可能性があることになるので、その場合、TCP のコネクションとしては成立しないことになります。

この人なに言ってるんだろうｗ

40サイトも運用しているのであれば、常時相当なトラフィックがあるんじゃないですか?
それであれば、NTT支局内でシェアしている他のユーザに迷惑がかかるので、ハイパーファミリーではなくて、ビジネスタイプに移行されてはいかがですか?
すべて非営利サイトであったとしても、常時100Mbpsを埋めるようなトラフィックを支局回線シェア型のハイパーファミリーでやられるのは、マナーというか、倫理的にと言うか、色々マズいと思いますが。

ハイパーファミリーでは迷惑がかかるのですね。
ビジネスタイプに切り替えようと思います。


-------------
あと、ルータを２台おいても、サーバから見たときのデフォルトゲートウェイが片方になるので、サーバから出て行くパケットは、サーバに届いたパケットがどっちのルータを通ったかに関わらず、デフォルトゲートウェイに指定されたルータへ向かって投げられます。

ということは、クライアントから見ると、送ったパケットの宛先の IP アドレスと違う IP アドレスから戻りのパケットが届く可能性があることになるので、その場合、TCP のコネクションとしては成立しないことになります。
-------------
TCPコネクションが成立しない事が問題だったのですが、それをルーター２台で解決できるのかと…。

＞TCPコネクションが成立しない事が問題だったのですが、それをルーター２台で解決できるのかと…。
解決しますよ。

TCPのコネクションとしては成立しないってのは
・HUBという部分を読み飛ばした雑なコメント
・ONUの先にプロバイダが直接存在しているという間違った思い込み
のどちらかが原因でしょう。
念のために説明しておくと、終端装置にHUBをつないで、HUBにルータを2台繋ぐということであって、ルータをカスケード接続するということではありません。
ていうか、それならHUBいらないですｗ

ん？

ONU - HUB - ルータ２台 - 1 台のサーバ

という構成ですよね？

で、２台のルータがそれぞれ、PPPoE で別々の ISP に繋がっている。サーバに対しては、ルータで NAT してポートフォワーディングしていて、インターネット側から見ると、ISP が割り当てた IP アドレスがルータの WAN 側に付いていて、例えば、

・ルータＡ：IP 11.22.33.44
・ルータＢ：IP 44.33.22.11

となっている。で、ルータの設定でそれぞれのグローバルアドレスはサーバの IP アドレスへ NAT で転送される。

違う？

もし、こういう構成であれば、サーバがインターネット側にパケットを投げるのは、デフォルトゲートウェイに指定したルータになって、デフォルトゲートウェイがルータＡの IP アドレスなら、サーバからインターネット側に出て行くパケットの送信元アドレスは常に、11.22.33.44 になる。

クライアント側が 44.33.22.11 に向かってパケットを投げても、サーバが投げるパケットは 11.22.33.44 から届くことになって、クライアントとしては「送ってもいない相手からパケットが届くなぁ」ということになって、コネクションが成立しない。11.22.33.44 へ向かってパケットを投げていればコネクションは成立する。

う～ん、全然違う構成なのかなぁ。

＞クライアント側が 44.33.22.11 に向かってパケットを投げても、サーバが投げるパケットは 11.22.33.44 から届くことになって

もう妄想はいいから、ネットワークの勉強しなおしなよｗ

PR-200NEって端末毎（IPアドレス毎）に接続先指定できないんだっけ？
（既に終了してしまっている質問だから確認せずに書いている）

仮に出来るのだとすればサーバ側の設定次第だと思うのだが・・・。
（サーバOSやサーバソフトの名称もバージョンも無いので何とも言えんけど・・・）

いやいや、妄想だというなら教えて。

まず、想定している構成はあってる？ 構成違っていたら、そもそもの前提が違っているんで。

で、構成があっているのなら、インターネットの向こう側にあるクライアントに対してパケットを投げるときに、サーバがどちらのルータへ向かって投げるのかを決める理屈を教えて。

ひょっとして、「戻りパケットは元のルータを経由する」と思ってます？ じゃぁ、どうやって元のルータを識別するの？ サーバに届く IP パケットは、つなぎに来たクライアントの IP アドレスが送信元アドレスになっていて、宛先アドレスはサーバの IP アドレスになっているよね。ルータの IP アドレスは入っていないよね？。それとも、NAT 前のグローバルな IP アドレスがどこかに入っている？

イーサフレームの MAC アドレスは確かに、通ってきたルータの内側の MAC アドレスが、送信元 MAC アドレスになっているけど、MAC アドレスが IP パケットのルーティングを決める条件に入っているの？

今、TCP ということで便宜的に「戻りのパケット」という言い方をしているけど、でも、ルーティングって、IP の話で、その中身が TCP でも UDP でも ICMP でも関係ないんじゃなかったけ？ それともルーティングを決めるときに「このパケットは TCP の 3 way ハンドシェイクの途中だからこっちへパケットを投げよう」ってするの？

それとも、サーバのデフォルトゲートウェイに両方のルータを設定するの？ 確かに、両方のルータをデフォルトゲートウェイを指定するのは可能だけど、常に両方に同じパケットが送られれば、TCP のコネクションが成立するけど、でも、少なくとも Windows だと、耐障害性のために設定できるようになっていた、送ろうと思ったルータが死んでいたら、もうひとつの方におくる、というものみたいだけど。

http://www.atmarkit.co.jp/fwin2k/win2ktips/262gateway/gateway.html

それとも、BGP や OSPF とかで、サーバがルーティングテーブルを更新する？

わざわざ「クライアント側が 44.33.22.11 に向かってパケットを投げても、サーバが投げるパケットは 11.22.33.44 から届くことになって」を引用して「妄想」と言っているというのことは、サーバは「クライアントからのパケットが届いたときのルータに向かってパケットを送信する」と言いたいんだと思うんだけど、だとすると、上記のような疑問があるんだけど...。

ネットワークの勉強するから教えてよ。

＞ネットワークの勉強するから教えてよ。

質問したいなら、こちらがおすすめですよ。
http://q.hatena.ne.jp/

質問したから答えてね。

http://q.hatena.ne.jp/1228454656

何に回答するかは私の自由ですが？
今回のコメントは意図的に質問者さんに益になる部分だけ意味のあるコメントをしています。
つまりJULYさんの間違った知識で質問者さんの手間を増やさないという点だけが重要です。