関連：http://q.hatena.ne.jp/1228386753
上記、質問のコメントでは、単にルータを並列に並べれば良いように書かれていますが、単純に考えれば、サーバは、送信先の IP アドレスとルーティングテーブルに従って、パケットを投げるルータを選択するだけで、クライアントの IP アドレスが含まれるネットワークアドレスがサーバのルーティングテーブルに無ければ、デフォルトゲートウェイに指定されたルータへ送られると思います。
サーバが Linux であれば iproute や iptables をごちょごちょすると出来そうな気がしますが、サーバ側に特別な仕組み無しに、確実に TCP のコネクションが成立する（クライアントが送った時の送信先 IP アドレスからパケットが返される）としたら、どんな仕組みによるものですか？
No.1
228
18
100pt
まず，コメントに惑わされているのだと思いますが，ネットワークの仕組み的に言うと，送った IP と異なる IP からパケットが返ってくるのは，TCP として成立していなくは無くて，正しい動作です
しかし実際には，サーバに接続してくるユーザは，NAT などを使って The Internet に接続しており，この NAT の仕様としては，送った IP と異なる IP からのパケットを，ローカルネットワークに届ける術が無いので，パケットを破棄してしまうでしょう
NAT が入ると複雑なので，ちょっと整理してみます
まず，サーバは，複数の IP で Listen しているとします．ここでは，
・10.0.0.1
・10.0.1.2
・10.0.2.3
とします．10.0.0.1 がプライマリに割り振ったアドレスで，後はエイリアスとします
10.0.1.2 で httpd が Listen してたとします．ここに，どこかの IP (172.16.1.2 としましょうか) からコネクションの要求があり，accept したとします．この通信は，172.16.1.2 と 10.0.1.2 の間で成立しているので，ルーティングテーブルもデフォルトゲートウェイも関係ありません
10.0.2.3 で httpd が Listen してたとします．以下略．通信は，172.16.2.3 と 10.0.2.3 の間ですね
しかし，この httpd がプログラムを起動し(例えが wget)，どこか他のマシンへ接続しに行くとします．この場合，ソース IP としては，10.0.0.1 が使われ，特にルーティングが決められていなければ，デフォルトゲートウェイへ抜けていきます
FTP などのサービスは，始めのコネクションは ポート21 で受け付けますが，データの転送は異なるポートを開きます．NAT 環境で FTPサーバがうまく動かないのも，この辺りが原因なのですが，こういう動作を行うアプリケーションの場合，上記にあげた，異なるソースIP が使われ，異なるゲートウェイを通ってしまうために，うまく動かないだろうと思います(TCP 的におかしいのではなく，もっと上位レイヤーの話)
というのも，自宅サーバでは縁が無いでしょうが，普通のサーバというのは，マルチホームといわれるネットワークに接続されています．この辺は調べていただくとさらに詳しい情報が出ますが，複数の経路を持っているなんてことは当たり前なんです
でも，家庭用ネットワークは，シングルホームといって，接続先は一つである前提で作られています．仕様としては間違って無くても，想定外の利用方法のために，うまくいかなくなります
家庭用ルータでは難しいでしょうから，YAMAHA の RTX1200 あたりを買えば，ご希望のネットワークが組めると思いますよ
No.2
2568
25pt
元の質問コメントの、
サーバに届く IP パケットは、つなぎに来たクライアントの IP アドレスが送信元アドレスになっていて、宛先アドレスはサーバの IP アドレスになっているよね。ルータの IP アドレスは入っていないよね？。それとも、NAT 前のグローバルな IP アドレスがどこかに入っている？
の部分ですけど、NATだから、
Internet -+-- (201.11.192.10)ROUTER1(192.168.1.1) --+-- (192.168.1.10)Server
+-- (128.20.173.24)ROUTER1(192.168.1.2) --+
こんなカンジでは？(IPアドレスは適当ですけど。)
そうすると、Serverにとってはローカルからのアクセスなんで、デフォルトゲートウエイではなくて、送信元のルータに直接返しますよね。
だから、コネクションとして成立するのでは？
ん？ NAT って、内側に入ってくるときの、送信元の IP アドレスを変更する？
例に挙げてもらった IP アドレスに、クライアントの IP アドレスを仮に 123.123.123.123 だとして、201.11.192.10 にパケットを送ると、サーバが受け取るパケットは、
・送信元アドレス：192.168.1.1
・宛先アドレス： 192.168.1.10
になる、ってことですか？ とすると、サーバ側からはクライアントの 123.123.123.123 というアドレスは見えない、ということですよね。少なくとも TCP のレベルでは（上位プロトコルに載せている場合は除く）。
通常、NAT は内に入ってくるパケットは宛先アドレスを、外へ出て行くパケットは送信元アドレスを変換して、
外側で見たときの通信：123.123.123.123 - 201.11.192.10
内側で見たときの通信：123.123.123.123 - 192.168.1.10
とするものだと思っていたのですが...。
もし、クライアント側の IP アドレスも変換していたら、Web サーバのアクセスログには、全部 192.168.1.1 になりませんか？ 自宅のサーバに ssh でつないだときは、ちゃんと、グローバルなアドレスで接続のログが残るけどなぁ...。
No.3
2568
25pt
自宅のサーバに ssh でつないだときは、ちゃんと、グローバルなアドレスで接続のログが残る
ご自宅のサーバってNATで立ててます？
スタティックIPマスカレードじゃなく？
「スタティックIPマスカレード」という用語が示されたページにある「静的IPマスカレード」ということであれば、「スタティックIPマスカレード」に該当します。（個人的にはポート・フォワーディングという用語の方がしっくりくるんだけど）
で、それで違いがあるんですか？
紹介いただいているページの先頭の方にある NAT の図でも、クライアント PC からみたサーバの IP アドレス（ルータの上にある PC の横に書書かれている終点のアドレス）は変化してませんよね。
kn1967
2008/12/05 15:09:08
1
1
2
1
2
2
goodvn
JULY
潮澤 昴
standard_one
aki1960
tommax
> 送った IP と異なる IP からパケットが返ってくるのは，
> TCP として成立していなくは無くて，正しい動作です。
TCP のハンドシェイク時に、SYN フラグつきのパケットを送って、違った IP アドレスから SYN/ACK のパケットを受け取ったら、SYN/ACK の送ってきた相手に対して ACK を返して、ハンドシェイクは成立してしまうんですか？ それとも、SYN で送った相手に対して ACK を送る？ SYN/ACK のパケットを受け取った時に、送信元のアドレスやポート番号を確認せず、ACK を送ってハンドシェイク成立するのかぁ...。う～ん、どこかにそのことが書いてあるサイトはないかなぁ...。