![使用 iproute2 的 ss 时,UDP 套接字处于 UNCONN 状态](https://linux22.com/image/132092/%E4%BD%BF%E7%94%A8%20iproute2%20%E7%9A%84%20ss%20%E6%97%B6%EF%BC%8CUDP%20%E5%A5%97%E6%8E%A5%E5%AD%97%E5%A4%84%E4%BA%8E%20UNCONN%20%E7%8A%B6%E6%80%81.png)
在运行 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))
为什么ss
OpenVPN 的输出是UNCONN
state 而非预期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)
。
仅当套接字处于连接状态时才可以使用 send() 调用(以便知道预期的接收者)。 send() 和 write(2) 之间的唯一区别是标志的存在。使用零标志参数时,send() 相当于 write(2)。