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 kernelscope 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
問題は通常、LinuxではなくSIPpにあることを（ある程度）確認することができました。
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は効果がないことを意味します。