主页 / unix / 问题 / 439618
Accepted
aew9
Asked: 2018-04-24 17:17:44 +0800 CST

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

  • 772

在运行 OpenVPN 客户端的机器上编辑一些防火墙规则时，我试图确定它的远程端口，就像我通常做的那样，使用ss.

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

它空无一物。

从配置中，我可以看到客户端必须10.0.0.5:389通过 UDP 连接。我验证了这一点/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 的输出处于UNCONN状态而不是预期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
openvpn iproute

1 个回答

  1. Best Answer

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

    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)。

    • 2

相关问题