UDP报文经过代理后目标IP和端口都变成0 (上游socks5的udp实现不正确) about ipt2socks HOT 14 CLOSED

没明白你说的啥意思，信息不足。

from ipt2socks.

ss-tproxy v4.7.6，配置参考这个 README 的 trojan(socks5) 配置：https://github.com/zfl9/ss-tproxy#%E4%BB%A3%E7%90%86%E8%BD%AF%E4%BB%B6%E9%85%8D%E7%BD%AE

对于你描述的场景来说：

• trojan变为你司的socks5程序
• 以及socks5程序运行在其他局域网主机（这个也是测试过的，ipt2socks能够正确处理）

如果你按照这个配置进行测试发现还是不行，建议先检查下你的socks5服务器代码，或者可以对比测试，将这个socks5服务器换成一个开源的（比如v2ray，可以开一个socks5协议的inbound来模拟）。

from ipt2socks.

搭建内网透明代理，不用上互联网，用来代理专用软件发出的TCP和UDP数据报文。用的是ss-tproxy与ipt2socks在服务器上实现代理并转发，在另外一台PC上部署一个socket5代理服务器接收转发过来的TCP和UDP报文，现象是TCP可以正常链接访问，但是发送UDP协议报文的时候，在socket5代理服务器上获取到报文的的目标地址为：0.0.0.0、端口为：0，这时候socket5代理服务就无发建立代理链接发送报文，导致UDP报文代理失败。

from ipt2socks.

不可能吧，ipt2socks对接的上游socks5服务器是什么（ss/v2/trojan/native 还是其他？）

按理来说这个功能都测试过无数遍了，建议把 ipt2socks 的 verbose 日志打开，将你的测试过程贴出来，不然没法分析。

from ipt2socks.

我用的代理服务器是我们公司自己用java研发的一个socks5代理服务。以下是发送UDP报文的时候打印的日志。
2024-03-08 00:20:40 INF:[udp_tproxy_recvmsg_cb] recv from 192.168.6.12#36762, nrecv:19
2024-03-08 00:20:40 INF: [udp_tproxy_recvmsg_cb] try to connect to 192.168.6.219#1080 ...
2024-03-08 00:20:40 INF: [udp_socks5_connect_cb] connect to 192.168.6.219#1080 succeeded
2024-03-08 00:20:40 INF: [udp_socks5_send_authreq_cb] send to 192.168.6.219#1080, nsend:3
2024-03-08 00:20:40 INF: [udp_socks5_recv_authresp_cb] recv from 192.168.6.219#1080, nrecv:2
2024-03-08 00:20:40 INF: [udp_socks5_recv_authresp_cb] send to 192.168.6.219#1080, nsend:10
2024-03-08 00:20:40 ERR: [udp_socks5_recv_proxyresp_cb] recv from 192.168.6.219#1080: connection is closed
2024-03-08 00:20:40 INF: [udp_socks5_context_timeout_cb] context will be released, reason: manual

from ipt2socks.

应该是 socks5 服务器自己实现有问题，这里显示上游 socks5 服务器关闭了 tcp 连接（在 socks5 udp 握手过程中）。

from ipt2socks.

我想说的是，已经经过很久的测试，ipt2socks 可以与符合 RFC 规范的 socks5 服务器进行对接（TCP + UDP 代理）。

包括：shadowsocks 的 socks5 端口、v2ray 的 socks5 端口、trojan 的 socks5 端口、native 的 socks5 端口。

from ipt2socks.

我现在遇到的问题就是socks5服务器在握手阶段，接收到的UDP报文就没有目标IP和端口，全部都是0，导致握手失败，不知道是不是因为ss-tproxy配置不对还是还是其他原因导致的，如果可以的话麻烦你能否给我一个可用的ss-tproxy配置。

from ipt2socks.

好的，非常感谢，我先按照你提供的方式来试试。

from ipt2socks.

我之前也遇到这个问题， 解决方法是 ： socks5 不要 监听在 0.0.0.0，而是填具体的网卡 ip

from ipt2socks.

我之前也遇到这个问题， 解决方法是 ： socks5 不要 监听在 0.0.0.0，而是填具体的网卡 ip

引用某个大佬的说法: udp的socks5 server地址是socks5握手时socks5 server返回给socks5 client的。协议就是这样设计的

from ipt2socks.

回看了 ipt2socks 代码，我大概知道啥问题了，应该就是你的 socks5 服务器实现有误。

socks5 的 udp 代理流程大概是这样的，我没记错的话：

1. ipt2socks 这边从 udp tproxy 端口接收到 raw_msg 后，会将 raw_msg 的 src_addr 作为 key，去一个缓存中查找是否有已建立的 socks5 udp 端口关联（后续简称 socks5 udpctx）

   • 若已存在，则将此 raw_msg 进行封包（增加 socks5 的 udp msg 头，将该 msg 的真正 dst_addr 编码进去）发送给关联的 socks5 udp 端口（X）。
   • 若不存在，则先与 socks5 服务器进行 TCP 握手、socks5 握手、socks5 请求（这个请求中的 DST.IP/PORT 无意义，通常都是设置为 0，这可能就是你说的解析到为 0 的现象），这个 socks5 请求就是 UDP Associate，通俗来说就是向 socks5 服务器申请两个新的 udp 端口（X 和 Y），X 用来和 socks5 客户端通信，传输的是 socks5_msg（socks_header + raw_msg，这个 header 主要信息就是 ip + port），Y 用来与“外部主机”（代理的目标）通信。传输的当然是 raw_msg。处理完此 socks5 请求后，socks5 服务器会返回一个响应消息，其中会有 X 的 ip+port 信息；然后 ipt2socks 将其与 raw_msg 的 src_addr 做关联，存到缓存中。然后走上一步逻辑，将 raw_msg 封包后（添加 dst_addr 信息），发送给 X。

2. socks5 服务器从 X 收到 socks5_msg 后，还原出 raw_msg，并且会从 header 中解析到真正的 dst_addr，然后用 Y 发送这个 raw_msg 到目标地址 dst_addr。注意，可能从 X 收到多个 socks5_msg，并且可以具有多个不同的 dst_addr。

3. socks5 服务器从 Y 收到 raw_msg 后，会将此消息进行封包（将 raw_msg 的 src_addr 编码到 header），然后将此 socks5_msg 用 X 发送给 socks5 客户端。

4. ipt2socks 从 X 收到 socks5_msg 后，从 header 解析出 msg 的来源地址（比如 8.8.8.8:53），然后创建一个 udp tproxy 套接字，并绑定到 8.8.8.8:53 地址（这里会有一些优化，比如缓存，避免重复创建），然后用这个 sock 发送给本地客户端（这个客户端的 addr 从 socks5 udpctx 可以得知）。这样这个客户端看来，就是从 8.8.8.8:53 收到 msg，实现了“透明”代理。

from ipt2socks.

我今天找了一个支持 UDP 的 socket5代理服务器，从日志现象来看是好像是可以获取到目标IP和端口的。但是有个问题是，从日志最后结果来看，在发送这个UDP包的时候好像是ipt2socks直接发送到目标设备上而没有发送到sock5代理服务器，但是由于目标设备和部署ip2socks的设备网络不通，导致发送超时。这种情况是iptables规则没有配置正确还是其他原因导致的呢？
2024-03-09 17:25:50 INF: [udp_tproxy_recvmsg_cb] recv from 192.168.9.150#1024, nrecv:18
2024-03-09 17:25:50 INF: [udp_tproxy_recvmsg_cb] try to connect to 192.168.6.219#1080 ...
2024-03-09 17:25:50 INF: [udp_socks5_connect_cb] connect to 192.168.6.219#1080 succeeded
2024-03-09 17:25:50 INF: [udp_socks5_send_authreq_cb] send to 192.168.6.219#1080, nsend:3
2024-03-09 17:26:23 INF: [udp_socks5_recv_authresp_cb] recv from 192.168.6.219#1080, nrecv:2
2024-03-09 17:26:23 INF: [udp_socks5_recv_authresp_cb] send to 192.168.6.219#1080, nsend:10
2024-03-09 17:28:57 INF: [udp_socks5_recv_proxyresp_cb] recv from 192.168.6.219#1080, nrecv:10
2024-03-09 17:28:57 INF: [udp_socks5_recv_proxyresp_cb] send to 192.168.2.41#5000, nsend:28
2024-03-09 17:29:57 INF: [udp_socks5_context_timeout_cb] context will be released, reason: timeout

from ipt2socks.

在发送这个UDP包的时候好像是ipt2socks直接发送到目标设备上而没有发送到sock5代理服务器，

不可能的，建议你仔细读一下我上面发的那段。

from ipt2socks.