Al enviar paquetes desde una aplicación que se vincula a una dirección local, TCP utiliza una dirección de origen diferente a la de UDP. Por ejemplo, enlace a 10.10.0.51 (alias IP), la dirección src para UDP es 10.10.0.51 pero la dirección src para TCP es 10.10.0.2 (dirección IP principal de la máquina). Esto se observa mediante la captura de paquetes tcpdump.
La salida de "ip route show" incluye esta línea: "10.10.0.0/22 dev eth1 proto kernel alcance link src 10.10.0.2"
Mi pregunta: ¿por qué TCP usa la dirección de origen de la tabla de enrutamiento pero UDP usa la dirección de origen a la que se vincula la aplicación?
Esto está en 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
EDITAR: La aplicación en cuestión es 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
EDITAR 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))
Respuesta1
Pude confirmar (hasta cierto punto) que el problema está en SIPp y no en Linux en general.
He creado un ticket con SIPp:https://sourceforge.net/p/sipp/bugs/147/
Mi solución de problemas fue la siguiente:
En el lado del "servidor", abra netcat:
nc -v -l 10.10.0.55 5060
En "netcat abierto del lado del cliente:
nc -v -s 10.10.0.5 10.10.0.55 5060
Salida en el lado del "servidor":
Connection from 10.10.0.5 port 5060 [tcp/*] accepted
Salida en el lado del "cliente":
Connection to 10.10.0.55 5060 port [tcp/sip] succeeded!
Cuando no especifico una IP específica en el lado del "cliente":
nc -v 10.10.0.55 5060
Entonces la salida en el lado del "servidor" es:
Connection from 10.10.0.4 port 5060 [tcp/*] accepted
Esto significa que especificar una dirección IP específica funciona y es SIPp el que no funciona de esa manera cuando se usa el indicador -i.