Linux の「ip route」は TCP の送信元アドレスを変更しますが、UDP は変更しません。

Linux の「ip route」は TCP の送信元アドレスを変更しますが、UDP は変更しません。

ローカル アドレスにバインドするアプリケーションからパケットを送信する場合、TCP は UDP とは異なる送信元アドレスを使用します。たとえば、10.10.0.51 (エイリアス IP) にバインドする場合、UDP の送信元アドレスは 10.10.0.51 ですが、TCP の送信元アドレスは 10.10.0.2 (マシンのプライマリ IP アドレス) です。これは、tcpdump パケット キャプチャを使用して確認できます。

「ip route show」の出力には次の行が含まれます: 「10.10.0.0/22 dev eth1 proto kernel scope link src 10.10.0.2」

質問:TCP はルーティング テーブルの送信元アドレスを使用するのに、UDP はアプリケーションがバインドする送信元アドレスを使用するのはなぜですか?

これは CentOS 6 上です。

[user@host ~]$ ip route show
10.10.0.0/22 dev eth1  proto kernel  scope link  src 10.10.0.2 
10.20.0.0/22 via 10.10.0.1 dev eth1 
10.145.192.0/18 dev eth0  proto kernel  scope link  src 10.145.194.226 
169.254.0.0/16 dev eth0  scope link  metric 1002 
169.254.0.0/16 dev eth1  scope link  metric 1003 
169.254.0.0/16 dev eth2  scope link  metric 1004 
default via 10.145.255.254 dev eth0 



[user@host ~]$ uname -a
Linux machinename 2.6.32-358.6.1.el6.x86_64 #1 SMP Tue Apr 23 19:29:00 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux



[user@host ~]$ ip address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:50:56:01:c3:96 brd ff:ff:ff:ff:ff:ff
    inet 10.145.194.226/18 brd 10.145.255.255 scope global eth0
    inet6 fe80::250:56ff:fe01:c396/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:50:56:01:c3:97 brd ff:ff:ff:ff:ff:ff
    inet 10.10.0.2/22 brd 10.10.3.255 scope global eth1
    inet 10.10.0.51/22 scope global secondary eth1:1
    inet 10.10.0.52/22 scope global secondary eth1:2
    inet 10.10.0.53/22 scope global secondary eth1:3
    inet 10.10.0.54/22 scope global secondary eth1:4
    inet 10.10.0.55/22 scope global secondary eth1:5
    inet6 2002::10:10:0:55/96 scope global 
       valid_lft forever preferred_lft forever
    inet6 2002::10:10:0:54/96 scope global 
       valid_lft forever preferred_lft forever
    inet6 2002::10:10:0:53/96 scope global 
       valid_lft forever preferred_lft forever
    inet6 2002::10:10:0:52/96 scope global 
       valid_lft forever preferred_lft forever
    inet6 2002::10:10:0:51/96 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::250:56ff:fe01:c397/64 scope link 
       valid_lft forever preferred_lft forever
4: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:50:56:01:c3:98 brd ff:ff:ff:ff:ff:ff
5: ip6tnl0: <NOARP> mtu 1460 qdisc noop 
    link/tunnel6 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 brd 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

編集: 問題のアプリケーションは SIPp です。

sipp -sn uac -i 10.10.0.51 -t tn -p 5060 -m 1 -r 1 10.10.0.1

sipp -sn uac -i 10.10.0.51 -t un -p 5060 -m 1 -r 1 10.10.0.1

編集2:

[user@host ~]$ ss -tplan | grep 5060
LISTEN     0      100              10.10.0.51:5060                     *:*      users:(("sipp",14837,3))
SYN-SENT   0      1                 10.10.0.2:50903            10.10.0.1:5060   users:(("sipp",14837,7))

[user@host ~]$ ss -uplan | grep 5060
UNCONN     0      0                10.10.0.51:5060                     *:*      users:(("sipp",14850,3))

答え1

この問題は SIPp に存在し、Linux 全般に存在しているわけではないことを (ある程度) 確認できました。

SIPp でチケットを作成しました:https://sourceforge.net/p/sipp/bugs/147/

私のトラブルシューティングは次のとおりです。

「サーバー」側で netcat を開きます:

nc -v -l 10.10.0.55 5060

「クライアント側でnetcatを開きます:

nc -v -s 10.10.0.5 10.10.0.55 5060

「サーバー」側の出力:

Connection from 10.10.0.5 port 5060 [tcp/*] accepted

「クライアント」側の出力:

Connection to 10.10.0.55 5060 port [tcp/sip] succeeded!

「クライアント」側で特定の IP を指定しない場合:

nc -v 10.10.0.55 5060

「サーバー」側の出力は次のようになります。

Connection from 10.10.0.4 port 5060 [tcp/*] accepted

つまり、特定の IP アドレスを指定すると機能し、-i フラグを使用する場合は SIPp ではそのように機能しません。

関連情報