☰

使用 iproute2 的 ss 时，UDP 套接字处于 UNCONN 状态

tag-icon • tag-icon openvpn iproute udp
使用 iproute2 的 ss 时，UDP 套接字处于 UNCONN 状态

在运行 OpenVPN 客户端的计算机上编辑一些防火墙规则时，我试图像平常一样使用ss.

# ss -anup | grep openvpn
UNCONN6528   0    0.0.0.0:52012        0.0.0.0:*     users:(("openvpn",pid=333,fd=3))

结果是空的。

从配置中，我可以看到客户端必须通过 UDP 连接10.0.0.5:389。我在以下位置验证了这一点/proc：

# cat /proc/net/nf_conntrack | grep udp | grep 389
ipv4     2 udp      17 175 src=10.0.7.8 dst=10.0.0.5 sport=52012 dport=389 src=10.0.0.5 dst=10.0.7.8 sport=389 dport=52012 [ASSURED] mark=0 zone=0 use=2

curl ipinfo.io在进行出站连接并验证其正常工作并返回预期结果后，这两个命令都快速连续运行。

我尝试了与 netcat 的正常 UDP 连接（nc -l -u 12345在服务器和客户端上）以查看客户端上nc -u 10.0.0.5 12345的输出：ss

# ss -anup | grep nc
ESTAB      0      0      10.0.7.8:52051              10.0.0.5:12345               users:(("nc",pid=2002,fd=3))

为什么ssOpenVPN 的输出是UNCONNstate 而非预期ESTAB状态，就像简单的 netcat 情况一样？

环境：

# uname -a
Linux tank 4.16.3-1-ARCH #1 SMP PREEMPT Thu Apr 19 09:17:56 UTC 2018 x86_64 GNU/Linux

# pacman -Qo /usr/bin/ss
/usr/bin/ss is owned by iproute2 4.16.0-1

答案1

TL;DR：您可以在连接模式下使用 UDP 套接字，也可以保持未连接状态，这是一种实现选择，具体取决于简单性或可扩展性等其他因素。这不会改变线路上数据包的内容，也不会跟踪所做的任何选择。

netcat用途bind(2)到所选端口，仅使用一次recvfrom(2)可以选择MSG_PEEK甚至不使用数据，检索源，然后使用connect(2)到这个源将套接字的状态更改为ESTAB，现在可以继续简单的操作read(2)和write(2)来电。

其他应用程序（例如：socatUDP-RECVFROM:7777,fork -而不是socat UDP-LISTEN:7777 -，显然还有 openvpn）从来没有connect(2)到源，从而保持在 UNCONN 状态。他们只会使用recvfrom(2)并将使用发出数据sendto(2)。

这种使用差异的部分解释是recv(2)和send(2):

仅当套接字处于连接状态时才可以使用 send() 调用（以便知道预期的接收者）。 send() 和 write(2) 之间的唯一区别是标志的存在。使用零标志参数时，send() 相当于 write(2)。

相关内容