Linux-2.4.18にて、ip aliasで同一セグメントに所属する複数のIPアドレスを
マシン唯一のNICであるeth0に10個ぐらい指定します。ここで、
...中略...
name.sin_family=AF_INET;
name.sin_addr.s_addr=htonl(INADDR_ANY);
connect(socketfd,(struct sockaddr *)&name,sizeof(name))
のようなプログラムにてTCP通信をすると、
[Q1] パケットのソースアドレスは何になるかを容易に予測することは
可能でしょうか?
[Q2] このソースアドレスを決めている部分はOSのソースではどこになるので
しょうか?
(linux-src/net/ipv4/route.cの
ip_route_input_slow()内部かな?なんて勝手に思っている次第ですが
あってますでしょうか?)
In article <87y8ewi...@taito.co.jp>, takahide nojima <noj...@taito.co.jp> writes
> [Q1] パケットのソースアドレスは何になるかを容易に予測することは
> 可能でしょうか?
system 依存なんじゃないかなぁ。もちろん。
> Linux-2.4.18にて、ip aliasで同一セグメントに所属する複数のIPアドレスを
> マシン唯一のNICであるeth0に10個ぐらい指定します。ここで、
異なるネットワークアドレスでも同じネットワークアドレスでも、どっちも
ありえるんですよね。
> ...中略...
> name.sin_family=AF_INET;
> name.sin_addr.s_addr=htonl(INADDR_ANY);
> connect(socketfd,(struct sockaddr *)&name,sizeof(name))
> [Q2] このソースアドレスを決めている部分はOSのソースではどこになるので
> しょうか?
> (linux-src/net/ipv4/route.cの
> ip_route_input_slow()内部かな?なんて勝手に思っている次第ですが
> あってますでしょうか?)
このあたり駆け足で読んだような気もするんだけど、覚えがないです~
(と、わかりませんフォローをする...)
---
Shinji KONO @ Information Engineering, University of the Ryukyus
河野真治 @ 琉球大学工学部情報工学科
In article <3991096...@rananim.ie.u-ryukyu.ac.jp>
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> 河野真治 @ 琉球大学情報工学です。
> > [Q1] パケットのソースアドレスは何になるかを容易に予測することは
> > 可能でしょうか?
> system 依存なんじゃないかなぁ。もちろん。
そうだと思います。Solaris だと、負荷分散のように回していたと
思いました。今試せないけど。物理的にイーサネット・カードを2
枚指して、同じネットワークに接続しても、交互に使ったと思いま
すが、あれと同じノリが働くんじゃないかなあ。それで、受信側が
発狂してトラブルになると。
関係ないけど、FreeBSD の jail で、同じ IP アドレス指定して、
同じポート番号にサーバを2個上げたら、交互につながりました。
ソースアドレスとは関係ないけど。
\\ 新城 靖 (しんじょう やすし) \\
\\ 筑波大学 電子・情報 \\
フォローありがとうございます。
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> > [Q1] パケットのソースアドレスは何になるかを容易に予測することは
> > 可能でしょうか?
>
> system 依存なんじゃないかなぁ。もちろん。
なるほどです。以前猛烈に誤解をしていて、eth0に割り振られたアドレスかと
思い込んでました。やってみればわかるのですが、実際は違うようで...
> > name.sin_family=AF_INET;
> > name.sin_addr.s_addr=htonl(INADDR_ANY);
> > connect(socketfd,(struct sockaddr *)&name,sizeof(name))
> > [Q2] このソースアドレスを決めている部分はOSのソースではどこになるので
> > しょうか?
> > (linux-src/net/ipv4/route.cの
> > ip_route_input_slow()内部かな?なんて勝手に思っている次第ですが
> > あってますでしょうか?)
>
> このあたり駆け足で読んだような気もするんだけど、覚えがないです~
自分なりの動作の予想:
1) ifconfig eth0:x xxxx した時にIP アドレスを割り振ると同時に
xxxxの所属するセグメントへのroute add がeth0:xに対して行なわれる。
2) プログラムがパケットを出そうとすると、ipv4/route.c内部で、
ソースIPアドレスがルーティングテーブルを元に決定される。
3) 2)の時、同一セグメントに対する複数のルーティングテーブル
が見つかる。で、ルーティングテーブルを保管しているハッシュ
において一番最初に見つかったエントリから得られるインターフェースの
アドレスがソースIPアドレスとして利用される。
というわけで、ハッシュのエントリの一番最初を予測しなければならないので、
ソースIPアドレスの予測は難しいという自分の結論なのですが、あってますで
しょうか?
IP aliasの仕様ってどこかにあったりしますでしょうか?
y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes:
> 思いました。今試せないけど。物理的にイーサネット・カードを2
> 枚指して、同じネットワークに接続しても、交互に使ったと思いま
> すが、あれと同じノリが働くんじゃないかなあ。それで、受信側が
> 発狂してトラブルになると。
これは、知りませんでした。なるほどです。
なんとなくですが、もしかして、ip aliasって、listenポートの為に
利用しないと、後々トラブルに見舞われやすいと考えた方が良いのでしょうか?
dev_...@anet.ne.jp writes:
> > [Q1] パケットのソースアドレスは何になるかを容易に予測することは
> > 可能でしょうか?
> connect() する前に INADDR_ANY で bind() してみては如何でしょうか?
> その後、 getsockname() で取得する。(・・・って bind() は不要かな?)
自分の用途に適した解決法は、
・ソースアドレスもプログラム側で指定する
というのがあるので、最悪この手で逃げる予定ですが、
[1] プログラムの改造を伴う上に、
[2] TCP通信する際に、ソースアドレスもプログラム側で指定してるような
クライアントプログラムを自分は巷で見たことがない
という状況があるので、少々戸惑ってます。[2]をやってるようなオープンソースな
プログラムってありますでしょうか?
ip_route あたり指定していて、おそらく、そこに交互に割り当て
る仕組みが書いてあるってのがありそうな感じだと思います。bind/
connect 時ですね。TCPで通信しているコネクションでは固定にな
ると思います。
In article <87d5w4x...@taito.co.jp>, takahide nojima <noj...@taito.co.jp> writes
> nojimaです。
> > > [Q1] パケットのソースアドレスは何になるかを容易に予測することは
> > > 可能でしょうか?
やっぱり固定したいんだよね。セキュリティ的な理由で。繋げる側
が両方から来る前提で動いてくれないとだめです。Solaris の場合
でも、死ぬ相手側がいくつかありました。なので、固定したい気持
はわかります。
routing table でも逃げられるかも知れない。
> 自分の用途に適した解決法は、
> ・ソースアドレスもプログラム側で指定する
> というのがあるので、最悪この手で逃げる予定ですが、
> [1] プログラムの改造を伴う上に、
これは仕方ないですね。
> [2] TCP通信する際に、ソースアドレスもプログラム側で指定してるような
> クライアントプログラムを自分は巷で見たことがない
これはあります。
> という状況があるので、少々戸惑ってます。[2]をやってるようなオープンソースな
> プログラムってありますでしょうか?
想像ですけど、routed とか。(本当か?! SOCK_RAW かなぁ...)
router とかだけど interface を直接開けるなんてことが可能なんですけどね。
kernel に手を入れるってのもありだけど、「まず実験」じゃないでしょうか。
> [2] TCP通信する際に、ソースアドレスもプログラム側で指定してるような
> クライアントプログラムを自分は巷で見たことがない
bindするインターフェースを陽に指定できる「サーバ」プログラムならたくさ
んありますけどね。Sambaとかtcpserverとかdjbdnsとか。
前田敦司
At Mon, 17 Jan 2005 15:08:30 +0900,
Hiroaki Sengoku wrote:
> [2] 拙作 stone ではソースアドレスを指定することができます。で、いったん
> stone で受けて目的のプログラム (適当なポートで listen) へ転送するように
> すれば、[1] プログラムを改造しなくて済む、かもしれません。
思いっきり嘘を書いてしまった (_O_) ので、お詫びとして stone にソースアド
レスを指定する機能を追加しました。例えば
stone -I xxxx server:1234 1234 &
みたいな感じで実行して、localhost の 1234 番ポートに接続すれば、ソースア
ドレスを xxxx にしたうえで server:1234 へ接続してくれます。
# 「嘘から出たまこと」というべきか「必要は開発の母」というべきか...
なお、嘘を書いてしまった該当記事はキャンセルしました。現在の NetNews で
キャンセルがどれだけ機能しているのかは未知数ですけれど。
#8998. 仙石 浩明
http://www.gcd.org/sengoku/ Hiroaki Sengoku <sengoku at gcd.org>
P.S.
迷惑メール対策の実験のため、「おとり」アドレスを使用しております。
「おとり」アドレスへ送られたメールはそのまま捨てられるだけでなく、
「おとり」アドレスへメールを送ったサイトからのメールは (ホワイトリストに
追加されない限り) 受信が遅延することになりますのでご注意下さい。
In article <87d5w4x...@taito.co.jp>
takahide nojima <noj...@taito.co.jp> writes:
> 自分の用途に適した解決法は、
> ・ソースアドレスもプログラム側で指定する
> というのがあるので、最悪この手で逃げる予定ですが、
「逃げる」というか、普通の方法じゃないですか。
> [2] TCP通信する際に、ソースアドレスもプログラム側で指定してるような
> クライアントプログラムを自分は巷で見たことがない
> という状況があるので、少々戸惑ってます。[2]をやってるようなオープンソースな
> プログラムってありますでしょうか?
完全なクライアントとは言いにくいですが、ftp はそうしています。
通常モード(passiveではない)では、データ用のコネクションのた
め、IP アドレスとポート番号がサーバからコールバックしてもら
うために事前に必要になります。まあただコールバックされた瞬間
はクライアントではなくて、サーバともいいますけれど。
あと、BIND の named は、クライアントとして別の名前サーバに問
い合わせる時に、ソース・アドレスを指定できます。
query-source address xxxx port yyy;
ゾーン転送したい時には、クライアント側の IP アドレスは固定し
たいのでしょうが、もともとIP アドレスが1つしかないなら問題
にはななないので、address * と書くのでしょう。port 53 と書く
流儀も時々見ます。昔の BIND は、53 固定でだったようです。
> [1] プログラムの改造を伴う上に、
元のプログラムが想定していなかったことなので、しょうがないで
しょうね。ソースがあるなら、修正するのが筋でしょう。(ソース
なくても、動的リンクならライブラリなの中でこちょこちょすると
いうのはできます。)
フォローありがとうございます。
y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes:
> > 自分の用途に適した解決法は、
> > ・ソースアドレスもプログラム側で指定する
> > というのがあるので、最悪この手で逃げる予定ですが、
>
> 「逃げる」というか、普通の方法じゃないですか。
なるほどです。ソースアドレスも指定出来るようにするのが普通だったんですね。
知りませんでした。
> > [1] プログラムの改造を伴う上に、
>
> 元のプログラムが想定していなかったことなので、しょうがないで
> しょうね。ソースがあるなら、修正するのが筋でしょう。
ええ、仕様策定段階では全く想定してませんでした。しまった...
...デフォルト指定無しで、指示があれば指定可能という仕様がいいかな...
takahide nojima wrote:
> なるほどです。ソースアドレスも指定出来るようにするのが普通だったんですね。
> 知りませんでした。
そもそも、事前に(connectを行なう前に)、connect時に
決まるソケットのローカルなIPアドレスを知らなければ困るこ
とってあるんでしょうか?
あらかじめ(どのI/Fを使うか)決めておきたいというのならともかく。
--
齊藤明紀 saitoh at kankyo-u ac jp
In article <csm2d2$rjb$1...@caraway.media.kyoto-u.ac.jp>, SAITOH Akinori <sai...@kankyo-u.ac.jp.nospam> writes
> 鳥取環境大学の齊藤です
(お、そんなところに~)
> そもそも、事前に(connectを行なう前に)、connect時に
> 決まるソケットのローカルなIPアドレスを知らなければ困るこ
> とってあるんでしょうか?
自分だけならOkなんだけど、サーバが「IPアドレスを根拠に接続を
拒否する」ってことがあるんですよ。なので、「このIPアドレスか
ら出したい」ってのは、あります。
> あらかじめ(どのI/Fを使うか)決めておきたいというのならともかく。
これ、結構あるよね。なんだけど、Unix のAPIには、そういうものが
なくって... setsockopts か?
前から気づいてました~
> > そもそも、事前に(connectを行なう前に)、connect時に
> > 決まるソケットのローカルなIPアドレスを知らなければ困るこ
> > とってあるんでしょうか?
> 自分だけならOkなんだけど、サーバが「IPアドレスを根拠に接続を
> 拒否する」ってことがあるんですよ。なので、「このIPアドレスか
> ら出したい」ってのは、あります。
UDPだけど、私がずっとやっているプロダクトはそうです。まあ拒否じゃなく
て、ソースアドレスとパケットIDで管理するプロトコルなので(本とはポート
もだけど)アドレスをたくさん割り振りたい。
> > あらかじめ(どのI/Fを使うか)決めておきたいというのならともかく。
>
> これ、結構あるよね。なんだけど、Unix のAPIには、そういうものが
> なくって... setsockopts か?
でも、それってipの場合だと、最終的に出ていくインターフェースは
destinationのrouting tableで確定しちゃうからあんまり意味ないですよね。
まあ、ip以外だとインターフェースじか叩きは良くやりますが。
問題は各UNIXでやりかたが違うことだけど。
--
___ わしは、山吹色のかすてーらが大好きでのぅ
[[o o]] ふぉっふぉっふぉ
'J' 森下 お代官様 MaNMOS 英夫@ステラクラフト
PGP Finger = CD EA D5 A8 AD B2 FE 7D 02 74 87 52 7C B7 39 37
> でも、それってipの場合だと、最終的に出ていくインターフェースは
> destinationのrouting tableで確定しちゃうからあんまり意味ないですよね。
http://www.linux.or.jp/JM/html/LDP_man-pages/man2/sendto.2.html
の MSG_DONTROUTE では無理ですか?
FreeBSDのtelnetだと -s オプションで自側IPアドレスを指定できます.
# 下のマニュアルは5.2-RELEASEですが4-stableでもいけるはず.
http://www.jp.freebsd.org/cgi/mroff.cgi?subdir=man&lc=1&cmd=&man=telnet&dir=jpman-5.2.0%2Fman§=0
自分やtelnetの相手や間のルータのIPフィルタの都合とか、
サーバがtelnetを動かしているが持っているIPアドレスのうち、
一部しか経路を持っていない場合には使いたくなるオプションです.
takahide nojima <noj...@taito.co.jp> writes:
> [2] TCP通信する際に、ソースアドレスもプログラム側で指定してるような
> クライアントプログラムを自分は巷で見たことがない
>
> という状況があるので、少々戸惑ってます。[2]をやってるようなオープンソースな
> プログラムってありますでしょうか?
--
--
梅野 崇
「サーバがクライアントの一部のIPアドレスのみしか経路を知らない場合」
ですね。失礼しました.
UMENO Takashi <um...@rr.iij4u.or.jp> writes:
> サーバがtelnetを動かしているが持っているIPアドレスのうち、
> 一部しか経路を持っていない場合には使いたくなるオプションです.
> 自分やtelnetの相手や間のルータのIPフィルタの都合とか、
> サーバがtelnetを動かしているが持っているIPアドレスのうち、
> 一部しか経路を持っていない場合には使いたくなるオプションです.
TCP に限らず IP はすべてそうですよねえ。
先日、あるルータから隣のルータに ping して、
返事がなくておかしいと思ったら、
ソースアドレスが相手と違うネットワークになってて、
相手はそこへの経路を持っていなくて返事できなかったのです。
ちなみにそのルータの ping コマンドはソースアドレスを指定できませんでした。
> takahide nojima <noj...@taito.co.jp> writes:
>
> > [2] TCP通信する際に、ソースアドレスもプログラム側で指定してるような
> > クライアントプログラムを自分は巷で見たことがない
> >
> > という状況があるので、少々戸惑ってます。[2]をやってるようなオープンソースな
> > プログラムってありますでしょうか?
神田敏広
ca...@yyy.kgc.co.jp writes:
> UMENO Takashi <um...@rr.iij4u.or.jp> writes:
>
>> 自分やtelnetの相手や間のルータのIPフィルタの都合とか、
>> サーバがtelnetを動かしているが持っているIPアドレスのうち、
>> 一部しか経路を持っていない場合には使いたくなるオプションです.
>
> TCP に限らず IP はすべてそうですよねえ。
>
> 先日、あるルータから隣のルータに ping して、
> 返事がなくておかしいと思ったら、
> ソースアドレスが相手と違うネットワークになってて、
> 相手はそこへの経路を持っていなくて返事できなかったのです。
> ちなみにそのルータの ping コマンドはソースアドレスを指定できませんでした。
pingもソースアドレス指定できるとうれしいコマンドの一つですね。
あとはtracerouteあたりも欲しいきがしました。
ルータで動作する管理コマンドは特にソースアドレスを
指定できたほうがいいかなと思いました。
うめちゃんいつもお世話になってます。Reply含めてさんきゅーす。
UMENO Takashi <um...@rr.iij4u.or.jp> writes:
> FreeBSDのtelnetだと -s オプションで自側IPアドレスを指定できます.
> # 下のマニュアルは5.2-RELEASEですが4-stableでもいけるはず.
>
> http://www.jp.freebsd.org/cgi/mroff.cgi?subdir=man&lc=1&cmd=&man=telnet&dir=jpman-5.2.0%2Fman§=0
>
> 自分やtelnetの相手や間のルータのIPフィルタの都合とか、
> サーバがtelnetを動かしているが持っているIPアドレスのうち、
> 一部しか経路を持っていない場合には使いたくなるオプションです.
にゃるほど。知りませんでした。さすがFreeBSD。Debian woodyのman telnetには
ないオプションでした。ぬー、最近は自側IP定めることが出来るようにせんと
いかんぽいですなぁ。
UMENO Takashi <um...@unnumbered.net> writes:
> pingもソースアドレス指定できるとうれしいコマンドの一つですね。
> あとはtracerouteあたりも欲しいきがしました。
>
> ルータで動作する管理コマンドは特にソースアドレスを
> 指定できたほうがいいかなと思いました。
マニュアルを読む限り、FreeBSD の ping は -S で、
traceroute は -s でソースアドレスを指定できそうですね。
また、RH9 や NetBSD の ping は -I で traceroute は -s
でそれぞれ可能なようです。
# なお、http://www.freebsd.org/cgi/man.cgi で確認しただけで
# 実機は全く触ってません。あしからず。
--
NODA Takashi <tn...@mb.neweb.ne.jp>
NODA Takashi wrote:
> のだです。
> マニュアルを読む限り、FreeBSD の ping は -S で、
> traceroute は -s でソースアドレスを指定できそうですね。
ping のソースアドレス指定つきオプションははじめて知りました。
bingの存在を先に知っていたので思いつかなかったというのが本音。
> また、RH9 や NetBSD の ping は -I で traceroute は -s
> でそれぞれ可能なようです。
Microsoft Windows標準添付の tracert 以外はほとんど全部では?
と言いかけて、tracertコマンドのUsageを確認したらtracertに
出来ないのは -g で経由する gateway を指定することでした。
# ちなみに -s でソース指定することもできません、あしからず。
非標準添付のツールであれば
そんな制限なしのものもいろいろ選択できるでしょうから
標準ツールの柔軟性の差と優劣の差はこの場合結びつかないらしい。
--
mailto:shi...@dd.iij4u.or.jp 渋谷伸浩