☰

Linux "iproute"는 TCP의 소스 주소를 변경하지만 UDP는 변경하지 않습니다.

tag-icon • tag-icon tcp route udp
Linux "iproute"는 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 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는 효과가 없음을 의미합니다.

관련 정보