1台のサーバで、インターネットへの出口となるルータが複数あり、かつ、そのルータが別々のプロバイダへ繋がっていて、それぞれのルータで、内部の1台のサーバに NAT している場合、インターネット側からサーバへの TCP のコネクションが成立するには、何が必要ですか?


関連:http://q.hatena.ne.jp/1228386753

上記、質問のコメントでは、単にルータを並列に並べれば良いように書かれていますが、単純に考えれば、サーバは、送信先の IP アドレスとルーティングテーブルに従って、パケットを投げるルータを選択するだけで、クライアントの IP アドレスが含まれるネットワークアドレスがサーバのルーティングテーブルに無ければ、デフォルトゲートウェイに指定されたルータへ送られると思います。

サーバが Linux であれば iproute や iptables をごちょごちょすると出来そうな気がしますが、サーバ側に特別な仕組み無しに、確実に TCP のコネクションが成立する(クライアントが送った時の送信先 IP アドレスからパケットが返される)としたら、どんな仕組みによるものですか?

回答の条件
  • URL必須
  • 1人2回まで
  • 登録:2008/12/05 14:24:17
  • 終了:2008/12/11 21:20:34

回答(3件)

id:goodvn No.1

goodvn回答回数228ベストアンサー獲得回数182008/12/05 15:10:29

ポイント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 あたりを買えば,ご希望のネットワークが組めると思いますよ

http://netvolante.jp/products/rtx1200/

id:JULY

> 送った IP と異なる IP からパケットが返ってくるのは,

> TCP として成立していなくは無くて,正しい動作です。

TCP のハンドシェイク時に、SYN フラグつきのパケットを送って、違った IP アドレスから SYN/ACK のパケットを受け取ったら、SYN/ACK の送ってきた相手に対して ACK を返して、ハンドシェイクは成立してしまうんですか? それとも、SYN で送った相手に対して ACK を送る? SYN/ACK のパケットを受け取った時に、送信元のアドレスやポート番号を確認せず、ACK を送ってハンドシェイク成立するのかぁ...。う~ん、どこかにそのことが書いてあるサイトはないかなぁ...。

2008/12/05 15:35:29
id:aki1960 No.2

aki1960回答回数256ベストアンサー獲得回数82008/12/05 15:46:25

ポイント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にとってはローカルからのアクセスなんで、デフォルトゲートウエイではなくて、送信元のルータに直接返しますよね。

だから、コネクションとして成立するのでは?


http://www.asi.co.jp/techinfo/unix/nat.html

id:JULY

ん? 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 でつないだときは、ちゃんと、グローバルなアドレスで接続のログが残るけどなぁ...。

2008/12/05 16:00:18
id:aki1960 No.3

aki1960回答回数256ベストアンサー獲得回数82008/12/05 16:33:45

ポイント25pt

自宅のサーバに ssh でつないだときは、ちゃんと、グローバルなアドレスで接続のログが残る

ご自宅のサーバってNATで立ててます?

スタティックIPマスカレードじゃなく?


http://www.asi.co.jp/techinfo/unix/nat.html

id:JULY

「スタティックIPマスカレード」という用語が示されたページにある「静的IPマスカレード」ということであれば、「スタティックIPマスカレード」に該当します。(個人的にはポート・フォワーディングという用語の方がしっくりくるんだけど)

で、それで違いがあるんですか?

紹介いただいているページの先頭の方にある NAT の図でも、クライアント PC からみたサーバの IP アドレス(ルータの上にある PC の横に書書かれている終点のアドレス)は変化してませんよね。

2008/12/05 16:52:07
  • id:kn1967
    相手のサーバ環境はおろか、ルータの機能すらも調べずに
    いきなりルータ2台なんて回答もいかがなものかとは思うけど
    (気にはなったからコメント書き込んだんだけどね・・・)
    回答は既にいるか付きで終了されているのだから
    質問者さんの環境には合致したんじゃないのかな?

    彼の人の言葉づかいは横から見ていても気分の良いものではないけれど
    「プロバイダへの負荷分散対策」が元になっている質問に対して
    「回線の太さ」って話は「方向違い」ですよね。
    (ビジネスタイプに替えようという提案はGoodですけど・・・)

    コネクションに関しては
    クライアントから出発してサーバに到達した時点で道が出来ている訳ですから
    サーバ側からの道作りは考える必要すら無く
    指定されたページの情報などを送り出すだけで済みます。
    このあたりで論点がズレてるって事だと思いますよ。
  • id:goodvn
    他人の事例ですが,
    http://flatray.com/linux/multihome/
    こんな感じで,家庭用ネットワーク,家庭用機器でうまくマルチホームを実現されている方もいますね
  • id:kn1967
    YAMAHAのNetvolanteシリーズが出た頃から意外と安価でマルチできましたよ。
    (家庭では当初ISDNでしたけど・・・)
  • id:JULY
    kn1967 さん、コメントありがとうございます。

    >「プロバイダへの負荷分散対策」が元になっている質問に対して
    >「回線の太さ」って話は「方向違い」ですよね。

    あっ、そうですね(^^;。

    てっきり、「帯域がいっぱいみたいだから、ISP を複数にすれば...」みたいな感じで「同一回線に複数プロバイダ」を考えたのかな、と思ってしまって。

    > コネクションに関しては
    > クライアントから出発してサーバに到達した時点で道が出来ている訳ですから

    goodvn さんの回答に対するコメントにも書いたんですが、クライアントから SYN パケットを送って、サーバから SYN/ACK のパケットが届くまでは良いんです。その時に、自分で SYN を送った IP アドレスと違うアドレスから SYN/ACK が届いたときに、ACK を送って TCP の 3way handshake が成立するか、という疑問があるんです。成立するとしたら、ACK の送り先は、自分が SYN を送った IP アドレスなのか、SYN/ACK を送ってきた相手なのか...。もし後者だとすれば、シーケンス番号を推定できれば、つなごうとした IP アドレスと違うアドレスに対して接続することになるので、それは無いかなぁ、とか。

    もし、SYN を送った相手と違う IP アドレスから SYN/ACK が送られてきても、TCP のハンドシェイクが成立するという資料が見つかれば、個人的には大発見なので、皆さんに感謝なのですが...。
  • id:fuk00346jp
    向こうの質問でNATの話を最初に出したのは誰?
    こっちの質問でSYN(同期)の話を最初に出したのは誰?
     
    ってわけで勝手に「要らない(成立しない)前提条件」が増やされてるわけです。
  • id:JULY
    goodvn さん、コメントありがとうございます。

    紹介してくれたページは Linux サーバで iproute2 を使った場合ですよね。私も iproute を使えば届いたルータに従って振り分けられるんだろうなぁ、となんとなく思っていました(iproute 自体は詳しくないんで、具体的な方法は全く分かりませんが)。なので、質問文に「iproute や iptables をごちょごちょすると出来そうな気が...」と書きました。

    全く方法が無い、とは思っていなくて、でも、単に2つルータを並べただけじゃ、無理じゃないかなぁ、と。

    業務用のルータであれば、ルータ1台の構成で iproute にやらせているようなことをさせれば出来ると思うのですが、元の質問にあったルータで出来るか、というと難しいかなぁ、と。NetVolante が出来るかどうか、といったところのような気がします。
  • id:JULY
    fuk00346jp さん、コメントありがとうございます。

    > 向こうの質問でNATの話を最初に出したのは誰?

    それは私です(^^;。

    なので、「この構成を前提として」という話をしています。全く別の構成なら、その構成を示して欲しかったんですが、断られてしまいました(^^;。

    ただ、もし、ルータ2台でそれぞれ別のプロバイダへ繋いで、かつ、NAT しないで1台のサーバ、となると、サーバの NIC を2つ使うか、1つの NIC に2つの IP アドレスを割り当てる必要があります。

    でも、それなら、ONU の下にぶら下げる HUB の下に直接サーバを置いて、サーバが PPPoE を2セッション張れば良いと思うのですが...。

    > こっちの質問でSYN(同期)の話を最初に出したのは誰?

    あの~、SYN って、TCP ハンドシェイクで使う SYN フラグの話ですが...

    http://www.infraexpert.com/info/5.1adsl.htm
  • id:kn1967
    もしかしてIPのルーティングと
    TCPのコネクションを同列に混同してませんか?

    IPによるルーティングが完了している(道が出来ている)からこそ
    TCPで接続できるかどうかという話に進めるのですけど・・・。
  • id:goodvn
    TCP の仕組みを調べて頂ければ疑問が解決すると思いますが,そもそも,なんで TCP がステートフルな通信を確保するために,ACK/SYN,ACK番号といった仕組みがあるかを考えれば,おのずと答えが分かると思います

    大学でも,情報系の学科だと,こういうところもきちんと教えてるはずなんですが,たぶん多くの人は聞き流してますよね(私も含め)

    この辺りは逆に IPv4 の弱点でもあるので,IPv6 では解決されていますが,結局,マルチホーム問題(IPv4に於ける問題とは違う)は IPv6 でも起こりうることになってしまい,今後も悩まされる事になりそうですね(IPv6 にはデフォルトゲートウェイが無いんです.なぜかは仕組みを調べれば分かります)

    蛇足ですが,NAT では WAN->LAN のパケットで,ソースIP の変換はしませんよ.この場合,ルータのローカル側インタフェイスと,サーバのインタフェイス間の接続は,MAC を使って特定されるので,ソースIP が変換されなかったとしても,通信相手とつながるルータは特定できます
  • id:standard_one
    可哀想になってきたのでヒントだけ。
    ルータと局舎は 無手順 でつながってるわけじゃないですよね。

    って、それ以上のヒントというか答えがてんこ盛り・・・
  • id:JULY
    kn1967 さんへ

    > IPによるルーティングが完了している(道が出来ている)からこそ
    > TCPで接続できるかどうかという話に進めるのですけど・・・。

    前のコメントに書きましたけど、IP のルーティングでパケットが届かない、とは思っていません。クライアントから送ったパケットに対してサーバ側からクライアントにパケットは届きます。それは、どっちのルータを通ったかに関わらず、IP パケットは届きます。

    私が疑問に思っているのは、TCP として接続するための 3way handshake が成立するか? ということです。3-way handshake の最初のパケットと、それに対する応答の2つ目のパケットが届くこと自体に疑問はありません。問題はその次の3つ目のパケットを送ってハンドシェイクが完結する際に、2つ目のパケットの送信元アドレスが、1つ目のパケットで送った相手の IP アドレス以外から届いたら、3つ目のパケットはどうなるのか? ということです。

    ひょっとして、3つ目のパケットってお飾りで、関係なしにその後の通信って成立しちゃうのかなぁ...
  • id:fuk00346jp
    http://q.hatena.ne.jp/1228386753
    ・20サイトづつ別々のプロバイダを通して提供(NICへ出る段階でどのプロバイダと通信するか確定されている。)
    ・ルーターはHUBとサーバーの間に挟まっているだけなのでどこと通信するかの選定には関与しない。
    こういう事でしょ?
    どこに通信確立しない要素があるんでしょう?
    違ってたらスンマセン^^;
  • id:kn1967
    >どっちのルータを通ったかに関わらず、IP パケットは届きます。

    TCP は IPパケットによって運ばれるのですから・・・
    IPパケットが届くと言う事は・・・。


    自分のコメントを見直してみると
    今回も含めて3回とも同じ事しか言ってない・・・。
  • id:JULY
    fuk00346jp さん、コメントありがとうございます。

    > どこに通信確立しない要素があるんでしょう?

    現在の(goodvn さんの回答を受けて)私の疑問は、

    ・TCP の接続時に行われる 3-way handshake において、2つ目の「SYN/ACK」パケットが、1つ目のパケットで送った相手の IP アドレスと違う IP アドレスから届いた場合に、3-way handshake が成立するか。

    という点です。

    「違う相手から SYN/ACK のパケットが届いたら、無視するだろう」と勝手に思っていたのですが、どうも違うみたいです。TCP コネクションハイジャック辺りをキーワードにして探してみると、確かに最初のシーケンス番号が推定できれば可能であることは書かれていて、その際に、相手の IP アドレスに関して合致している必要があるかどうかについて書かれていないので、現時点での感触では、goodvn さんの言うとおり、「SYN/ACK のパケットが届いたときの相手のアドレスは、3-way handshake の成立条件には含まれていない」のかなぁ、と。

    このことがずばり書いてあるところが見つかれば万々歳なんですが、まずは TCP の接続が成立しないのでは、という疑問に対しては解決できた気がしてきています。

    ただ、LAN 上にルータが2つあった場合、どっちのルータが選択されるか、という点は、ちょっと疑問があります。goodvn さんがコメントで紹介したような iproute を使えば、元の送信元の IP アドレスが、どっちのルータから届いたかを覚えていて、以降、その IP アドレスに対して、使われたルータへパケットを投げる、という動作になるのは分かるんですが、どんな OS でも、特別な設定をしなくても、そういう動作になるか...。もし、特別なことが必要が無いとしたら、goodvn さんが紹介してくれた人が iproute を使う必要はなくて、デフォルトゲートウェイに両方のルータの内側アドレスを書くだけで良いような気がします。

    なので、

    ・多分、つなぎに行ったときと違う IP アドレスからパケットが届いても、TCP の 3-way handshake は成立して、以降の通信は可能。
    ・でも、サーバ側で工夫しないと、片方のルータからしか出て行かない、ということにならないか?

    というのが今の気持ちです。
  • id:JULY
    kn1967 さんへ

    > 自分のコメントを見直してみると
    > 今回も含めて3回とも同じ事しか言ってない・・・。

    こちらこそ、3回も同じ事を書かせてしまって、申し訳ありません。

    fuk00346jp さんへのコメントにも書きましたが、ずっと、引っかかっていたのは、TCP のコネクションを開始するときの 3-way handshake のことでした。最初のパケットと違うところから返事のパケットがあったら、そのパケットは無視されて(もちろん IP パケットとしては受理されるけど、TCP の処理の段階で「こいつは違う」と判断されて)、送り主からの SYN/ACK パケットが届くの待つのでは、と思っていました。

    で、goodvn さんの回答から、私もちょっと調べてみたのですが、どうも、送った IP アドレスと違っていても良いらしい、という感じになっています。

    「パケットが届く」ことと、「TCP として接続状態が確立される」というのは別で、例えば、SYN パケットが届いたときに RST フラグを立てたパケットを送信してやれば、相手からみるとそのポートは閉じられている、という判断になり、以降、TCP の通信は行えません。

    私もこの 3-way handshake で誤解があったようなので、偉そうなことは言えませんが、TCP として通信が成立するには、IP パケットが届くだけでは不十分です。

    「TCP の通信が出来ている」 → IP のパケットは双方向で届いている」ことは言えますが「IP のパケットが双方向で届いている」→「TCP の通信が出来る」訳ではありません。

    あっ、ちょっと偉そうな感じになっちゃって、ごめんなさい。
  • id:aki1960
    >goodvnさん
    >蛇足ですが,NAT では WAN->LAN のパケットで,ソースIP の変換はしませんよ.

    私の書き方が足りませんでしたね。
    もちろん、ソースIPの変換もするように設定する前提です。
    CISCOっぽく言うと、
    SourceAddress inside local <-> SourceAddress outside global
    DestinationAddress inside local <-> DestinationAddress outside global
    を設定する。という意味です。

    >JULYさん
    >紹介いただいているページの先頭の方にある NAT の図でも、クライアント PC からみたサーバの IP アドレス(ルータの上にある PC の横に書書かれている終点のアドレス)は変化してませんよね。

    すみません、これも書き方が不親切でした。
    発IPがインターネット側なので、参考として書いたURLの図は、WAN側(インターネット側)が逆サイドになります。
    クライアントPCとして書いてあるものがインターネットからのアクセスで、サーバがローカル側として見てください。
  • id:JULY
    goodvn さんへ

    返事が遅くなってすみません。

    > なんで TCP がステートフルな通信を確保するために,
    > ACK/SYN,ACK番号といった仕組みがあるかを考えれば,

    ひとつは、パケットの順番や、欠落したパケットが無いかを判断するためですよね。あと、よそから勝手に送られてきたパケットじゃない、という判断のため...。3-way handshake の2つ目の SYN/ACK のパケットで ACK 番号が、自分が送ったシーケンス番号 + 1 の数字じゃなかったら、「このパケットが俺の送ったパケットに対する応答じゃないな」と。

    その時に、ACK 番号以外にも自分が送った IP アドレスを覚えていて、そこと違っていたら、同じように「俺の送ったパケットに対する応答じゃない」ということになると思い込んでいました。

    SYN/ACK の後の3つ目のパケットはおそらく、1つ目のパケットと同じ宛先に送ることになると思うのですが、もし、SYN/ACK を送ってきた IP アドレスに対して送るとなると、SYN/ACK のパケットをひたすら送っていれば、IP アドレスの偽装するら必要なしにコネクションハイジャックが出来ることになりますよね。

    > この辺りは逆に IPv4 の弱点でもあるので,IPv6 では解決されていますが,

    というのは、この辺のが IPv6 で改善された、ということなのかな? でも、「俺が送ったパケットに対する応答じゃない」と判断するのは TCP だから、IPv6 で TCP 自体にも変更があって、単に IPv6 の上に、これまでと同じ TCP が乗っかっている、という訳ではないのかな?


  • id:JULY
    aki1960 さんへ

    > すみません、これも書き方が不親切でした。
    > 発IPがインターネット側なので、参考として書いたURLの図は、
    > WAN側(インターネット側)が逆サイドになります。

    了解しました。

    コメントありがとうございました。
  • id:fuk00346jp
    >・TCP の接続時に行われる 3-way handshake において、2つ目の「SYN/ACK」パケットが、1つ目のパケットで送った相手の IP アドレスと違う IP アドレスから届いた場合に、3-way handshake が成立するか。
    「経路(ルーター)」が違っても「接続元(サーバーやらクライアント等のいわゆる「末端」)」は同じでしょうに。
     
    >・でも、サーバ側で工夫しないと、片方のルータからしか出て行かない、ということにならないか?
    そりゃそうでしょ。
  • id:JULY
    fuk00346jp へ

    >「経路(ルーター)」が違っても「接続元(サーバーやらクライアント等の
    > いわゆる「末端」)」は同じでしょうに。

    ん? 「末端の IP」が違っている場合を言っているつもりなんだけど。

    私が想定している構成ではルータで NAT しているので、サーバがどっちに投げたかによって、インターネット側のクライアントから見た「末端の IP」が結果的に違ってしまう。

    で、サーバが、「経由したルータに向かってパケットを送信する」という動作をすれば、クライアントが受け取るパケットは、送信した時の同じ IP アドレスから返って来て、なんの問題もありません。

    しかし、「経由したルータに向かってパケットを送信する」というのが、goodvn さんのコメントで紹介されているような、Linux で iproute を使って、といった工夫が無いと、単にデフォルトゲートウェイに両方のルータの内側 IP アドレスを指定した程度では、外向きのパケットは結局、片方のルータにしか送られない状況があるのでは、と思った次第です。

    だとすれば、クライアントがルータ A の持つ IP アドレスへ TCP の接続を始めようとして最初のパケットを送ったときに、ルータ B から2つ目のパケットが送られてくれば、クライアント側から見ると、「最初に送った時の IP アドレスと違う IP アドレスから応答パケットが届く」という状況が起きます。

    その状況が発生した際に、TCP の 3-way handshake は成立して、TCP のコネクションが確立できるのかどうか、というのが焦点になりました。

    >> ・でも、サーバ側で工夫しないと、片方のルータからしか
    >>  出て行かない、ということにならないか?
    > そりゃそうでしょ。

    その具体的な「工夫」を考えておく必要があると思います。

    iproute を使えば出来るのは、goodvn さんが示されているので問題ないと思いますが、私が思いつくのは、

    ・サーバ側に IP アドレスを2つ割り当てる。
    ・その2つの IP アドレスは別々のネットワークアドレスを持つ。
    ・その IP アドレスに対して、それぞれのルータで NAT の設定をする。

    といったことなんですが、ただ、デフォルトゲートウェイの扱いが微妙な気がします。

    複数のデフォルトゲートウェイが指定されている時に、送信しようとしている IP アドレスと同じネットワークアドレスを持つデフォルトゲートウェイへ必ず送信するか? というところに確信が持てません。

    同じネットワークアドレスを持つ IP アドレスをサーバに複数設定しても、どっちのルータへ送られるかは、OS での優先順位で選択されてしまうように思います。元の質問のコメントでも紹介した下記のページだと、少なくとも Windows に関してはそのように思われます。

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

    多分、ネットワークアドレスが違うように割り当てていれば、送信元アドレスと同じネットワークアドレスを持つルータが選択されると思うんだけど...。
  • id:kn1967
    >サーバがどっちに投げたか

    そうか・・・
    サーバは単に返事を返しているだけなんだけど
    「サーバが投げる」と理解しているから
    IPがどうのという話になってしまうのか・・・

    クライアントからルータAを通してサーバまでIPパケットが到達している時点で
    クライアント-ルータA-サーバという接続環境は調っているので
    わざわざルータBを通じて返答を返すような事はないと言えば解るかな?
  • id:standard_one
    構成が 構成が 言い続けてた理由はそれかな?
    質問して良かったですねぇJULYさん。
  • id:tommax
    standard_one さんへ

    自分からケンカを売るぐらいですから、その後の対応はひどさにも納得ですが、一言、意見させていただきます。
    はてなは、無知や勘違いを助ける場であって、からかったりする場ではないはずです。
    それはご理解されているようですが、知識をひけらかして楽しんでいるようにしか見えません。
    相手あってのサービスです。マナーは守ってください。以後、よろしくお願いします。
  • id:JULY
    kn1967 さんへ

    > わざわざルータBを通じて返答を返すような事はない

    つまり、たとえばクライアントの IP アドレスが 123.123.123.123 だったとして、このクライアントからのパケットがルータ A を経由してサーバが受け取ったことがあれば、以降、123.123.123.123 宛にパケットを送信する必要があるときには、自動的にルータ A を経由する、ということですよね?

    この事が書いてあるサイトでも書籍でも紹介してもらえませんか?

    その動作を実現するための方法をあれこれ考えたものを、ダイアリーに書いてみました。

    http://d.hatena.ne.jp/JULY/20081205

    kn1967 さんにとっては、特別なことをしなくても、届いたときに使われたルータが選択されるのが、当たり前なことかも知れませんが、私も 3-way ハンドシェイクで2つ目のパケットの送信元 IP アドレスと、1つ目のパケットの送信先の IP アドレスが違っていたら、TCP のコネクションは成立しないのが当たり前だと思っていました。

    私は 3-way handshake の成立条件に関して書かれたサイトを探しますので、kn1967 さんは、ルータの選択条件に関して、記述されているサイトを探して、お互いに発表しませんか?


  • id:standard_one
    tommaxさんへ
    質問者さんに嘘を教えると言う行為を肯定したら、はてな自体の意味も価値もなくしますよ。
    人間ですからミスは当然あるでしょうけど、自身の間違いを妄信的に押し付けるなんて論外の行為です。
    「言い方が気に入らない」という意味であれば、「相手の態度による」とお答えしておきます。私は太鼓持ちじゃないですしね。

    それと、こちらがケンカを売られたという認識です。
    まぁ第三者の方にはどうでもいいことだとは思いますが、せっかくなので聞いてください。
    >楽しんでいるようにしか見えません。
    とのことですが、別に私は楽しくありません。そう見えているなら誤解です。
    どう見えるかという観点での話しをされるのであれば、私にはどう見えているかも説明させていただきます。
    私にはここでのコメントの流れが「どうにかして自分の主張が正しかったと言える条件を探している」ように見えます。
    わざわざ私をこちらの質問に誘導しておきながら、自分の思った通りの展開(JULYさんの言っていることが正しいと証明される展開)にならなかったから、私へのレスができないのでは?とも考えています。
    まぁこの部分は予想ですけどね。
  • id:kn1967
    ダイアリーを見る(長いから斜め読み)とIPパケットの中身ばかりに注視していて
    ルータの果たす役割に関する部分がかなり抜けているので
    これが今回の迷走の真の原因かと思う。
    (回答3への返答を見ると、NATとIPマスカレードの違いも
    理解しておられなかったようなので、ほぼ間違いないと思う)

    今一度、書いてみる・・・。
    IPパケットに書かれているIPアドレスは変わる場合があるけれど
    クライアントとサーバそれぞれ固有に割り当てられているIPアドレスは変化しないのだし
    互いを結ぶ経路を形成するルータ達は接続先(転送先)を保有(保持)しているのだから
    一度到達すれば、接続に必要な情報は持続され、切断がリクエストされるまでの間は
    IPパケットのやりとりが出来る状態になっている(道が出来ている)
    TCPパケットはIPパケットの荷物として運ばれるものなのだから同じく
    やりとり出来る状態になっている。

    書いてみたけど、結局のところ、コメント1の
    >クライアントから出発してサーバに到達した時点で道が出来ている訳ですから
    >サーバ側からの道作りは考える必要すら無く
    >指定されたページの情報などを送り出すだけで済みます。
    と同じ事を書いているだけだから・・・理解していただけないかもしれないが・・・。
  • id:JULY
    kn1967 さんへ

    > 一度到達すれば、接続に必要な情報は持続され、切断がリクエストされるまでの間は
    > IPパケットのやりとりが出来る状態になっている(道が出来ている)

    「切断がリクエスト」ってどのレイアーの話ですか? IP パケットに「接続」と「切断」がある? まさか、ルータが PPPoE が登録した ISP へ接続をしていることを指しているわけないですよね。「接続を保持」とか書かれていますが、IP パケットに「接続」という状態がある? 「ルータの果たす役割に関する部分がかなり抜けている」という指摘がありますが、それと付け合わせると、PPPoE の話をしているような気が...。

    「道」という表現を使われていますが、これはおそらく、IP の下位のレイヤーの話ですよね。IP の下位のレイアーとしては、Ethernet もあれば、PPPoE もあれば、PPP やフレームリレーもある。「道ができている」というのは、これら下位レイアーが接続状態にある、ということを意味しているんですよね。Ehternet であればリンクアップすれば接続状態になるし、PPPoE や PPP であれば、さらにその下のレイアー(PPPoE であれば Ehternet で、PPP だったらアナログモデムのネゴシエーション完了だったり、ISDN 回線の接続完了だったり)が接続状態が確保されて、その後に、PPP としての情報交換をして、接続状態になりますよんね。もちろん、ルータから見てこれらの層が接続がされて初めて IP パケットが転送できるようになることは分かります。

    でも、今話題にしているのは、これらの下位のレイアーの接続状態は確保されている状態で、つまり、道は出来上がっていて、小包(IP パケット)を運ぶときにどの道を選択して、どの配送拠点を通過するか、という問題ですよね。

    ルータの内側にあるサーバから見てルータが複数ある場合、どっちのルータを使っても、宛先へパケットが届きますよね。つまり、道が既に2本用意さいれている。たとえば、サーバにルータ A だけがデフォルトゲートウェイが設定されていれば、サーバは常にルータ A を経路として選択しますよね。逆もしかり。でも、両方していたら、kn 1967 さんはどう思いますか? kn1967 さんのこれまでの話からすると、以前にパケットが届いた方のルータ、ということですよね。じゃぁ、その仕組みはどんなものだろう、と考えたのが、ダイアリーに書いた内容です。

    > 互いを結ぶ経路を形成するルータ達は接続先(転送先)を保有(保持)しているのだから
    > 一度到達すれば、接続に必要な情報は持続され、

    この意味するところがピント来ないのですが、たとえば、下記のサイトのルーティングに関する説明のどの部分に該当する部分ですか?

    http://www.atmarkit.co.jp/fwin2k/network/baswinlan009/baswinlan009_01.html

    「ルータ達は接続先(転送先)を保有(保持)」というのはルータが保持している「ルーティングテーブル」の事を意味していると思いますが「一度すれば、接続に必要な情報は持続され」というのは、ルータの話ですか? サーバの話ですか? 「接続に必要な情報」とは具体的に何を示していますか?

    今、私が問題にしているのは「サーバがどっちのルータを選択するか?」という点ですが、サーバがそれぞれのルータの PPPoE の接続状況がどうだ、とか、インタフェースをいくつ持っていて、どんなルーティングテーブルを持っていて、というのは分からないと思いますが、どう思いますか?サーバがどっちかのルータを選択して、ダイアリーで示したような「MAC アドレスがルータのアドレスで、IP アドレスが目的のアドレス」となっているパケットを送信すれば、あとは、ルータ側がそのルータの持っている情報の中で、適切と判断される方法で IP パケットを転送し、結果的に相手に IP パケットが届きますよね。小包の例で言えば、どの配送センターへ持って行くかを決めるに、運送会社の配送網がどうなっているかは知らなくても良いですよね。一番手近な配送センターに持って行く(別に、電話をかけて集荷をお願いしても良いけど(^^;)。

    どうも kn1967 さんの話を読むと、サーバが複数のルータのどちらかを選択する時に、ルータから接続状況やらなんやら、いろんな情報が渡されていて、それを見て、「うむ、今はこっちのルータを使うべきだ」と判断しているように思われるのですが、そういうことでしょうか?
  • id:kn1967
    >IP の下位のレイヤーの話ですよね。

    下位ではなくてIPの話。

    >サーバがどっちのルータを選択するか?

    サーバは単純に「来た方向に送り返すだけ」だから
    サーバがルータを選択したりしているわけではない。
    サーバから返されたものを2台のルータが受けて
    自分の担当なら、そちらに送ってくれる。
    ただ、これだけの事を何で難しく考えるのか・・・。

    具体的に説明されればされるほど混乱をきたしているようなので
    最初のコメントの時点から概要的な表現に絞って書き込んでるというのは
    理解してもらえていないようだけど、
    本当に、それぞれ具体的に知りたい、学びたいということであれば
    一度、頭をリセットしてTCP/IPの基礎から整理してみてください。
    失礼ながらNATとIPマスカレードの違いが解らないというほどの
    現状のスキルにあわせて、基礎の部分から説明するほどの
    時間は残念ながら割けません。

    あいつも匙を投げたかと思われるのは癪ですし、残念ですがこれにて失礼。
  • id:fuk00346jp
    風邪ひいて寝てました^^;
    >ん? 「末端の IP」が違っている場合を言っているつもりなんだけど。
    一つの接続の中ではありません。却下です。通信が成立しません。「末端の IP」が違えば同一と認識されません。
     
    id:goodvn さんが回答内で言っているのは別プログラムが起動応答しています。(同じプログラムでも良いんでしょうけど^^)
    接続は別物/新規です。
  • id:goodvn
    すみません.私は,うまく行かないパターンを親切に書いたつもりだったんですが,余計混乱させてしまったかもしれません(というわけで,FTP の例は忘れてください)

    どうも,id:JULY さんの質問などを見ていると,IP のパケットとか,単体の仕組みの話をかじっただけで,上下レイヤーで層が分かれていること,実運用の経験などはあまり無いのかな,という印象があります.もっと,全体を俯瞰した見方をしないと,疑問は解決されない気がします.あと,サイト,サイトと言われますが,自分の疑問に対しずばり答えの載ってるものを探す辺りは,(失礼かもしれないけど)ゆとりっぽさを感じます

    木を見て森を見ず,とも言われますが,もう少し,森を見てみませんか?

    日記も斜め読みしただけなんですが,書いてることが間違ってるというより,ここでの質問の想定と,シチュエーションがすりかわっちゃってますよね

    なぜか日記中では,ルータの内側からの通信が書かれています.このときは,当然,ルーティングテーブルが無ければ,デフォルトゲートウェイに抜けていきます.書かれている動作で問題ないと思います

    でも,ここでは,インターネット側からルータを経由してサーバが accept するシチュエーションでの話をしていますよね.arp に言及されていながら,なぜ arp について調べられないのか不思議なんですが,arpテーブルという仕組みが存在する意味を考えれば,おのずと答えはわかるかな,と思います

    つまり,ローカル -> インターネットの経路は,常にデフォルトゲートウェイのルータ経由で出て行く概念は間違って無いんです

    でも,インターネット -> ローカルへの経路は,入ってくるルータ経由で通信される,ということが,マルチホームでは当たり前なんですけど,なぜそれほど疑問に思われるのでしょうか?
  • id:JULY
    う~んと、誰のコメントから答えれば...

    とりあえず、ぱっと自分が一番理解しやすいところからで失礼します。

    goodvn さんへ(あっ、指名されたからといって逃げないで下さいね(^^;)

    > つまり,ローカル -> インターネットの経路は,常に
    > デフォルトゲートウェイのルータ経由で出て行く概念は間違って無いんです。

    今回の私が仮定している構成だと、「ローカル」側に「サーバ」があって、「サーバ」が「インターネット側のクライアント」に対してパケットを送信するときには、「サーバで指定されているデフォルトゲートウェイ」に指定されたルータに出て行く...。デフォルトゲートウェイが複数あるケースはこの際割愛しますが、ルータ A と ルータ B があって、ルータ A がデフォルトゲートウェイに指定されていたら、サーバからインターネットへ出て行く経路は常にルータ A になる、というのは間違っていないんですよね?

    > インターネット -> ローカルへの経路は,
    > 入ってくるルータ経由で通信される,ということが,
    > なぜそれほど疑問に思われるのでしょうか?

    ん? 私、なにか違ったことを書いていたかなぁ...。

    「インターネット→ローカルへの経路」、つまり、私の仮定した構成では、「クライアント→サーバ」というパケットの方向のことを指しているように思うんですけど、違いますか? 私はこの「クライアント→サーバ」の方向のパケットの経路に対して、言及したつもりはなかったのですが...。

    今回の構成は、goodvn さんのおっしゃる「ローカル」がサーバのある所で、「インターネット」がクライアントのある所のつもりなんですが...。もちろん、その誰かさんの「クライアント」が、実際には、インターネット側からみてブロードバンドルータの背後にあることもあると思いますが、そのことは、私が疑問に思っていることと無関係です。なので、クライアントがダイアルアップ接続していて、直接、グローバルな IP アドレスを割り当てられている状況を想定してみて下さい。

    で、私が疑問に思っているのは、例えば、私の 2008-12-06 10:04:15 付けの発言にあるように「サーバがクライアントへ送信する際に、どっちのルータを経由するか」です。goodvn さんの「ローカル -> インターネットの経路」の話です。

    で、goodvn さんは「常にデフォルトゲートウェイのルータ経由で出て行く」とおっしゃられていますよね。私もそう思っています。もし、そうしたくなければ goodvn さんが紹介してくれたページにあるように、Linux で iproute のようなものを使わない限り、単純にルーティングテーブルに従って送り先のルータは決まる。デフォルトゲートウェイしか定義されていなければ、当然、「常にデフォルトゲートウェイのルータ経由で出て行く」

    しかし、kn1967 さんの主張は、少なくとも私には、違っているように読めます。

    > クライアントからルータAを通してサーバまでIPパケットが
    > 到達している時点でクライアント-ルータA-サーバという
    > 接続環境は調っているので
    > わざわざルータBを通じて返答を返すような事はない

    と書かれています。この主張に従えば、先にクライアントからサーバ(つまり、「インターネット→ローカル」)のパケットがあれば、サーバからクライアント(つまり、「ローカル」→「インターネット」)のパケットは、先に通ってきたルータを経由することになります。つまり、サーバのデフォルトゲートウェイがルータ A を指定しても、クライアントからのパケットが ルータ B を経由して届けば、ルータ B を経由して返答を帰す(わざわざルータ A を通じて返答を返すような事はない)、ということになります。

    ただ、確かに私はこれまでのコメントの中で、「デフォルトゲートウェイが両方のルータに設定されている」という前提で書いていたので、その前提の場合にそういったことが起きる、というお話なのかもしれません。

    逆に、デフォルトゲートウェイが片方のルータにしか設定されていないとしたら、kn 1967 さんがおっしゃっているような、「届いたときのルータを経由する」、ということは起きるのでしょうか? goodvn さんの話だと「常にデフォルトゲートウェイのルータ」となると思うのですが...。

    > もっと,全体を俯瞰した見方をしないと,疑問は解決されない気がします.

    これは皆さんから指摘されているんで、言い訳できないのですが...。

    でも、私が細々とパケットの理屈で「こうなると思うけど」ということに対して、誰も否定してくれないも不思議なんです。

    「ばかやろう、IP パケットの転送はルーティングテーブルだけで決まるんじゃないぞ! ここを見てみろ! 俺の言っているのと同じことが書いてあるだろう!」というのが無いのが残念なんです。

    一応、私が前提としている構成(というか、思考の流れ)をhttp://d.hatena.ne.jp/JULY/20081208 に書いてみました。

    多分、私が思い描いている構成と、皆さんが思い描いている構成がずれているのが、議論がかみ合わない原因かなぁ、と。

    確かに私も余り細かくは構成に関して書いていないし、元の質問にも回答にも、詳しく書いていないので、いろんな「仮定」が入り込んでいるのは事実です。

    改めて元の質問の回答を読み直してみると「どちらのルータにぶらさげるかで、そのサーバが使うISPが決まります。」と書いてあるので、このことが、「サーバの NIC を2枚にして、それぞれのルータに接続する」ということを指すのであれば、私が想像(standard one さんに言わせると妄想(^^;)と構成が違うことになるので、皆さんが主張されていることは理解できるのですが...。

    「いや、お前の妄想の構成でもこうなるんだよ」という話であれば、やっぱり疑問は消えないのですが...。
  • id:standard_one
    考え方にせよ今後のことにせよ、皆さん親切に教えてくださってるんですから素直に耳を傾けられたらいかがですか?
    それが解決への最善策だと思いますよ。
  • id:JULY
    あっ、goodvn さん、ごめんなさい。
    私がミスリーディングしているかも知れないところを見つけたので書きます。

    > インターネット -> ローカルへの経路は,
    > 入ってくるルータ経由で通信される,ということが,
    > なぜそれほど疑問に思われるのでしょうか?

    これって、パケット単位の経路の話ではなくて、kn1967 さんと同様に、TCP のコネクションの方向の話だったでしょうか?

    なぜ「それほど疑問」に思っているかと、

    ・IP パケットの経路は上位のプロトコルには依存せず、単純にルーティングテーブルに従って決められる。

    と私は思っているからです。IP パケットの中身が TCP だろうが、UDP だろうが、ICMP だろうが、IP の小包をどこの配送センターに持っていくかは、ルーティングテーブルのみに従う、と。それは、パケットを転送する(ルーティングする)時も、自らが発信者となる(サーバがクライアントにパケットを送ろうとしているケース)場合でも、同じである。と。

    すると、この考えが間違いということですよね。ルーティングテーブル以外にも、前に受け取ったパケットがどこから届いたのか、とか、上位のプロトコルは TCP で、前にこの IP アドレスから届いたときには、このルータのを経由したから、ということが、サーバからパケットを送出する時の経路選択に影響する、ということで間違いありませんか?

    出来れば、goodvn さんや kn1967 さんに、そのことが書かれているサイトなり書籍を紹介していただければ、大変有り難いのですが、さすがにこれだけのコメントを頂いた上で「証拠を出せ」みたいなのはおこがましいので、自分で探してみます。もし、紹介していただければ(ずばりでなくてもかまいません。ここに書いているのは、こういう挙動を示唆しているよ、というのでも構いません)、ポイントで還元(といっても、大盤振る舞いできるわけじゃないですが(^^;)したいと思いますので、解答欄の方に書いていただけると有り難いです。
  • id:JULY
    見つけたかも...。

    http://linux-ip.net/html/routing-cache.html

    何せ英文なんで、ミスリーディングしている可能性もありますが、

    http://linux-ip.net/html/routing-selection.html

    の 4.5.2 節に「When determining the route by which to send a packet, the kernel always consults the routing cache first.」と書かれているので、ルーティングテーブルの前にルーティング・キャッシュをまず最初に確認し、無かったらルーティングテーブルを参照する、という流れだと。

    余談:
    そのルーティング・キャッシュの説明で「The routing cache is also known as the forwarding information base (FIB)」と書いているんだけど、FIB で日本語のページを探すと、FIP = 静的ルーティングテーブル、という説明が多いんだけど...。
  • id:goodvn
    たぶん,私の想定してる環境と,id:JULY さんが言われてる構成は同じだと思います

    私が書いたインターネットというのは,クライアント側,ローカルがサーバ側で問題ありません

    ただ,まさかなんですが,2台のルータの,LAN 側のセグメントが同じで,1つの IP で Listen する,なんて構成を想定されてはいませんよね?

    ここでの,私も含め,他の方の言っている構成では,2台のルータと,物理的に1つのインタフェイスという点は問題ないのですが,ルータA と ルータB の LAN 側のセグメント,インタフェイスには複数の IP アドレスが割り振られている,というところまでは問題ないでしょうか?

    インタフェイスの先にある,2台のルータのどちらへパケットを流すか,という問題は,ルーティングだけで決まりませんよね?

    % netstat -r

    あたりの結果を見ると分かりますが,gateway は IP アドレスだけではないですよね.論理的なインタフェイスも表示されると思います

    これで疑問は解決されましたか?

    私が言った,デフォルトゲートウェイに抜けていくのは,サーバから通信(パケットではない)した場合だけです.インターネットから通信されている場合は,デフォルトゲートウェイは関係ありません

    ご家庭でもテストできる,簡単な事例を考えてみました

    サーバ,BBルータ(ルータA)は普通の構成で,NAT を使って接続してるとします.当然,ルータAにふられた IP アドレスに接続すれば,NAT を経由してサーバが反応し,サーバと通信できると思います(ルータA の LAN セグメントを,172.16.0.0/24,サーバのローカル IP を,172.16.0.1 とします)

    ここに,別のルータ(ルータB)を用意して,WAN 側を,172.16.1.0/24 のセグメントにし,サーバのローカル IP を 172.16.1.1 にして接続してみてください(当然,ルータB は PPPoE などを使わず,固定IPです)

    このルータB の LAN 側セグメントを 172.16.2.0/24 として,ここに PC (172.16.2.2 とかにしますか) を接続してみてください.PC から,172.16.1.1 へ接続してみます.この時,サーバからのパケットは,デフォルトゲートウェイのルータA に行くわけでも無く,ちゃんとパケットが返ってきませんか?

    返ってくるパケットを見れば,172.16.1.1 がソース IP になってるはずです

    これでも疑問があるでしょうか?(逆に当たり前のこと過ぎて,サイトは思い当たりません.書籍であれば,当たり前のことなので,TCP/IP の初心者向けの本であっても,書いてあると思います)
  • id:goodvn
    訂正

    > ルータA と ルータB の LAN 側のセグメント,インタフェイスには複数の IP アドレスが...

    ルータA と ルータB の LAN 側のセグメントは異なり,インタフェイスには複数の IP アドレスが...

    (書いてて思ったけど,別に同じセグメントでも良い気はしてきた.たぶん,同じセグメントでも良いはず.IP が複数は必要)
  • id:JULY
    > ただ,まさかなんですが,2台のルータの,LAN 側のセグメントが同じで,
    > 1つの IP で Listen する,なんて構成を想定されてはいませんよね?

    そのまさかを想定していました(^^;。

    ということで、私が何で疑問を感じていたのか理解していただけましたでしょうか?

    私も複数の IP が設定されているケースなら大丈夫そうな気がする、というのは、私の 2008-12-05 19:05:05 付けのコメントでも書いています。

    > 書いてて思ったけど,別に同じセグメントでも良い気はしてきた.

    私もこの点にはちょっと自信が無くて、IP の送信元アドレスが決まれば、出力するインタフェースが決まるんで、元質問で standard_one さんが回答されているように、2つのルータのネットワークアドレスがかぶってても大丈夫のような気がします。

    ただ、UNIX 系 OS では、1つの NIC に複数の IP を割り当てれば、IP アドレスの分だけ NIC があるのと同じなので OK だと思うのですが、Windows 系の場合はどうなのか、という疑問はちょっと残ります。

    > IP が複数は必要

    私はずっと IP がひとつの時を話しているつもりで、それでも皆さんに「通ってきたルータで戻る」って言われて、じゃぁ、それを実装する立場になったら、どうやって実現するんだろう? と疑問に思っていたんです。そのことがうまく伝わっていなかったことに、もっと早く気がつけば良かったのですが...。皆さん、ごめんなさい、言葉足らずで。

    で、goodvn さんの指摘を受けて、「ルーティングテーブル以外要素」を探したら「ルーティング・キャッシュ」というものが見つかった。私が、ダイアリーで「もし、通ってきたルータを...」ということで書いた、「前にパケットが届いたときの履歴情報」が実在するということになったんで、なら、IP ひとつでも届いたときのルータが選択されるのかなぁ、と。先の私のコメントで紹介した英文に依れば、ルーティングテーブルの前に参照されるらしいし。

    個人的には「ルーティング・キャッシュ」の存在で、IP がひとつの状況下でも大丈夫そうな気がしている(実は、皆さんへのお礼の文も書きかけていた(^^;)のですが、goodvn さんはどう思われますか?
  • id:standard_one
    どう思われますかって・・・
    実験用の構成まで考えてもらって、色々な人にここまでフォローしてもらって、なんでそういう方向に進めようとするんですか?
    自分で実験するなり、新たにその質問立てるなりすればいいと思いますよ。
    少なくとも詭弁臭い論点のすり替えを繰り返し続けるよりは、よっぽどその方が健全です。
  • id:JULY
    最後の goodvn さんの意見を聞いてやめようと思ったのですが、さすがに、時間がだいぶ絶ちましたので、これでこの質問は終了します。

    最後まで、「私が疑問に思っている事」がうまく伝わらなかったのが残念ですが、とりあえず、

    ・サーバに IP が2つあれば大丈夫。
    ・サーバの IP が1つだったら、ルーティングキャッシュの機構でうまく行きそうだけど、今のところは微妙。

    というのが、私の現時点での結論です。

    あと、この質問に関して思うことを、ダイアリーに書きました。ここにコメントを書いてくださった皆さんには、読んでもらえないかもしれませんが...。

    皆さん、ありがとうございました。
  • id:kn1967
    多分、前回同様に文章が長そうなのでダイアリは読まないけど
    「サーバのIPは1つ、使用するポートは・・・」なども
    パターンに含んでみてちょ。
  • id:standard_one
    へぇ

    >・TCP の接続時に行われる 3-way handshake において、2つ目の「SYN/ACK」パケットが、1つ目のパケットで送った相手の IP アドレスと違う IP アドレスから届いた場合に、3-way handshake が成立するか。
     ↓
    >> ただ,まさかなんですが,2台のルータの,LAN 側のセグメントが同じで,
    >> 1つの IP で Listen する,なんて構成を想定されてはいませんよね?

    >そのまさかを想定していました(^^;。

この質問への反応(ブックマークコメント)

トラックバック

  • http://q.hatena.ne.jp/1228454656 に至った思考の経路 元の質問者の環境を下記のように仮定 (1) 物理的配線は ONU - ルータ - (* 1) - サーバ   *1) この位置に HUB が入っている可能性があるが、HUB の有
  • 家庭ネットワークでマルチホーム 緑茶は命の水 2008-12-16 09:47:41
    通常,一般家庭のインターネット接続は,ISP 1つの接続につながっています.これをシングルホームと言います TCP/IP では,他点との接続は複数持つことができ,パケットをどの経路で送る
「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません