search

zfl9 / ipt2socks

将 iptables/nftables 传入的透明代理流量转为 socks5 流量的实用工具
GNU Affero General Public License v3.0
411 stars 94 forks source link

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

Closed 18280181597 closed 3 months ago

18280181597 commented 3 months ago

使用ss-tproxy做代理执行脚本结合ipt2Socks做sockt5透明代理，ss_tproxy模式是gfwlist，其他配置基本保持默认配置。发送TCP报文时能够正确解析获取目标IP和端口，但是在发送UDP报文后，目标IP和端口都变成0，麻烦大佬帮忙看看是什么原因导致的。 ss-tproxy.conf配置如下：

## mode
#mode='global'  # 全局：{ignlist}走直连，其他走代理
mode='gfwlist' # 黑名单：{gfwlist}走代理，其他走直连 (回国模式也是这个，后面有详细说明)
#mode='chnroute' # 大陆白名单：{gfwlist}走代理，{ignlist,chnlist,chnroute}走直连，其他走代理

## ipv4/6
ipv4='true'     # 是否对ipv4启用'透明代理': true启用 false不启用
ipv6='false'    # 是否对ipv6启用'透明代理': true启用 false不启用

## tproxy
tproxy='true'  # true:  TPROXY(tcp)   + TPROXY(udp) ## 纯 tproxy 模式 ##
                # false: REDIRECT(tcp) + TPROXY(udp) ## redirect 模式  ##
                #
                # 具体取决于'本机代理进程'的透明代理传入'协议'
                #
                # ss/ssr/trojan 通常为 redirect 模式
                # v2ray 两者都支持，具体取决于 v2ray 配置
                # ipt2socks 默认为纯 tproxy 模式，也可切换为 redirect 模式
                # ss-libev 3.3.5+ 支持纯 tproxy 模式，参数为"-T"、"tcp_tproxy": true
                # trojan 原生不支持 udp 透明代理，但可以配合 ipt2socks 来实现
                # trojan-go 只使用纯 tproxy 模式，支持 tcp 和 udp
                #
                # 其他代理软件请自行甄别测试，配置错误将无法正常透明代理

## tcponly
tcponly='false' # true:仅代理TCP流量 | false:代理TCP和UDP流量
                # 取决与'代理套件'，有些代理/机场不支持UDP协议的代理
                # DNS查询默认走UDP，若代理不支持UDP，请将此选项设为true

## selfonly
selfonly='false' # true: 只代理ss-tproxy主机(本机)传出的流量
                 # false: 代理本机、内网机传出的流量(网关和dns指向ss-tproxy主机)
                 # 由于dns_remote必须走代理，且dns逻辑在本机进行，因此本机必须走代理
                 # 虽然可以只处理dns流量，其他流量不走代理，但感觉意义不大，还是简单点好

## proxy
#
# 本机代理进程相关，如透明代理端口，进程启动和停止命令(如果想自己控制进程启停，可以留空)
#
# ss-tproxy要求"代理进程"不参与ip分流，也不参与dns解析，专心让iptables过来的tcp/udp流量走代理即可
# 本机代理进程只会收到"纯ip"的tcp/udp流量，不会有dns相关的东西让你知晓，因为这些已被dns解析组件处理
# 因此ss-tproxy的设计原则是：各组件只负责自己的专业领域，无需知晓透明代理的全局面貌，做好自己的事就行
#
# 如果要切换代理/节点，请直接操作代理进程，而不是修改ss-tproxy.conf、重启ss-tproxy
# 因为这是一个重量级操作，除非tproxy模式、tcponly模式等涉及iptables规则的配置发生了更改
# 换句话说，ss-tproxy应该主要用于iptables管理，以及附带的dns方案，顺便帮你启动/关闭代理进程
#
proxy_procgroup='proxy'  # 本机代理进程的group(fsgid)，所有代理进程都需要以此身份运行，用于流量放行
                         # 不允许填root或0，脚本会自动帮你创建group(如果填的是name)，建议使用name
                         #
proxy_tcpport='60080'    # ss/ssr/v2ray/ipt2socks 等本机进程的 TCP 监听端口，该端口支持"透明代理"
proxy_udpport='60080'    # ss/ssr/v2ray/ipt2socks 等本机进程的 UDP 监听端口，该端口支持"透明代理"
                         # 代理进程只需监听"127.0.0.1"(v4环境)+"::1"(v6环境)，不需要监听"全0地址"
                         #
proxy_startcmd=''        # 用于启动"本机代理进程(组)"的 shell 命令行，该命令行不应该执行过长时间
proxy_stopcmd=''         # 用于关闭"本机代理进程(组)"的 shell 命令行，该命令行不应该执行过长时间
                         # 如果想自己接管"本机代理进程"的启动/停止，可以在startcmd/stopcmd上留空
                         #
                         # 如果命令行比较长，建议封装为函数，然后在startcmd/stopcmd中调用这些函数
                         # shell函数可以定义在ss-tproxy.conf的任何位置，比如ss-tproxy.conf的末尾
                         #
                         # startcmd 中可调用 set_proxy_group 给可执行文件设置所属 group、setgid 权限位
                         # 例如："set_proxy_group ss-redir"，此后启动的 ss-redir 进程将会自动切换 group
                         #
                         # 如果 startcmd/stopcmd 留空，则需要手动控制"本机代理进程"的启动和停止
                         # 此时可使用 ss-tproxy 的 set-proxy-group 命令给可执行文件设置所属 group、setgid 权限位
                         # 例如："sudo ss-tproxy set-proxy-group ipt2socks"，然后再启动 ipt2socks 等本机代理进程

## dns
dns_custom='false'                    # true:使用自定义dns方案(高级用户,见下面的说明) | false:使用内置dns方案
                                      # 使用自定义dns方案时，所有dns相关的配置被忽略，内置的域名分流规则也会失效
                                      # 需要自己实现域名解析/分流；udp代理未启用时，如果想走代理，请记得走tcp协议
                                      #
dns_procgroup='proxy_dns'             # dns进程的group(fsgid)，不能与proxy_procgroup相同，所有dns进程都需要以此身份运行
                                      # 不允许填root或0，脚本会自动帮你创建group(如果填的是name)，建议使用name而不是gid
                                      #
dns_mainport='60053'                  # dns请求的逻辑入口(udp监听端口)，脚本内部会将"所有"dns请求重定向至此udp端口
                                      # 监听地址必须能覆盖到"127.0.0.1"(v4环境)+"::1"(v6环境)，用于接收本机dns请求
                                      # 如果要代理内网，则监听地址还需覆盖到相关网卡，为了简单，建议监听通配地址(全0)
                                      #
                                      # 下面的这些 dns_* 配置，只在使用"内置dns方案"时有效
                                      #
                                      # 直连DNS和远程DNS，控制的是"内置dns组件"的上游dns服务器参数
                                      # white和black，控制的是"ipset白名单/黑名单"，即：直连还是代理
                                      # 放在这里是为了方便修改dns配置，不必修改ignlist.ext/gfwlist.ext
                                      #
                                      # white和black允许以下3类值，以dns_direct_white为例(其他同理)
                                      # - 'true'    # dns_direct的ip加入白名单，使其走直连
                                      # - 'false'   # dns_direct的ip不加入白名单，比如局域网ip
                                      # - '1.2.3.4' # 将1.2.3.4这个ip加入白名单，可填多个ip，空格隔开
                                      # > 注意，对于填写ip的情况，带6的选项请填ipv6地址，不带6的填ipv4地址
                                      #
dns_direct='223.5.5.5#53'             # 直连DNS(v4环境使用)，必须指定端口，可使用本地/内网服务器
dns_direct6='240C::6666#53'           # 直连DNS(v6环境使用)，必须指定端口，可使用本地/内网服务器
dns_direct_white='true'               # 将dns_direct的ip加入白名单(global/chnroute)，使其走直连
dns_direct6_white='true'              # 将dns_direct6的ip加入白名单(global/chnroute)，使其走直连
                                      #
dns_remote='8.8.8.8#53'               # 远程DNS(v4环境使用)，必须指定端口，可使用本地/内网服务器
dns_remote6='2001:4860:4860::8888#53' # 远程DNS(v6环境使用)，必须指定端口，可使用本地/内网服务器
dns_remote_black='true'               # 将dns_remote的ip加入黑名单(gfwlist/chnroute)，使其走代理
dns_remote6_black='true'              # 将dns_remote6的ip加入黑名单(gfwlist/chnroute)，使其走代理

## dnsmasq
# 使用自定义dns方案时，dnsmasq相关配置被忽略，dnsmasq不会启动
# 这里允许dnsmasq监听其他端口，是为了在它前面加入其他进程，优先处理dns
dnsmasq_bind_port=''                    # dnsmasq监听端口，留空表示端口同dns_mainport
dnsmasq_cache_size='4096'               # 最多缓存多少条，0表示禁用缓存，太大会影响性能
dnsmasq_cache_time_min='3600'           # 最短缓存多少秒，上限值为3600，0表示禁用此功能
dnsmasq_query_maxcnt='1024'             # dns查询最大并发数(dns-forward-max)，默认150
dnsmasq_log_enable='false'              # 记录详细日志，除非进行调试，否则不建议启用
dnsmasq_log_file='/var/log/dnsmasq.log' # 日志文件，如果不想保存日志可以改为 /dev/null
dnsmasq_conf_dir=()                     # `--conf-dir` 选项的参数，可以填多个，空格隔开
dnsmasq_conf_file=()                    # `--conf-file` 选项的参数，可以填多个，空格隔开
dnsmasq_conf_string=()                  # 自定义配置，一个数组元素就是一行配置，空格隔开

## chinadns
# 使用自定义dns方案时，chinadns相关配置被忽略，chinadns-ng不会启动
chinadns_for_gfwlist='true'              # 用于mode=gfwlist，提升域名匹配性能
chinadns_bind_port='65353'               # 监听端口，若 65353 被占用，请注意更改
chinadns_chnlist_first='false'           # 优先加载 chnlist 域名 (默认优先 gfwlist)
chinadns_extra_options=''                # 其他附加的命令行选项(已有的选项就别再填了)
chinadns_verbose='false'                 # 记录详细日志，除非进行调试，否则不建议启用
chinadns_logfile='/var/log/chinadns.log' # 日志文件，如果不想保存日志可以改为 /dev/null

## dns2tcp
# 使用自定义dns方案时，dns2tcp相关配置被忽略，dns2tcp不会启动
# 如果udp代理效果一般，建议启用dns2tcp，个人测试tcp查询快于udp，可能是isp/gfw对udp进行了qos
# 这里提供禁用选项，主要是为了方便使用其他dns工具替代dns2tcp，比如dnsproxy，走doh，也是tcp协议
dns2tcp_enable='auto'                   # auto:tcponly时启用 | true:总是启用 | false:禁用
dns2tcp_bind_port='65454'               # 监听端口，若 65454 被占用，请注意更改
dns2tcp_extra_options=''                # 其他附加的命令行选项(已有的选项就别再填了)
dns2tcp_verbose='false'                 # 记录详细日志，除非进行调试，否则不建议启用
dns2tcp_logfile='/var/log/dns2tcp.log'  # 日志文件，如果不想保存日志可以改为 /dev/null

## ipts
ipts_if_lo='lo'                     # 环回接口的名称，在标准发行版中，通常为 lo，如果不是请修改
ipts_rt_tab='233'                   # iproute2 路由表名或表 ID，除非产生冲突，否则不建议改动该选项
ipts_rt_mark='0x2333'               # iproute2 策略路由的防火墙标记，除非产生冲突，否则不建议改动该选项
ipts_set_snat='false'               # 设置 ipv4 MASQUERADE(SNAT) 规则，selfonly=false 时有效，详见 README
ipts_set_snat6='false'              # 设置 ipv6 MASQUERADE(SNAT) 规则，selfonly=false 时有效，详见 README
ipts_reddns_onstop='223.5.5.5#53'   # stop后重定向内网主机发来的dns至指定dns，selfonly=false 时有效，详见 README
ipts_reddns6_onstop='240C::6666#53' # stop后重定向内网主机发来的dns至指定dns，selfonly=false 时有效，详见 README
ipts_proxy_dst_port=''              # 要代理哪些端口，留空表示全部，多个逗号隔开，冒号表示范围(含边界)，详见 README
ipts_drop_quic='tcponly'            # 丢弃发往"黑名单"的QUIC: 留空:不丢弃 | tcponly:tcponly时丢弃 | always:总是丢弃

## opts
opts_ss_netstat='auto'      # auto/ss/netstat，用哪个端口检测工具: auto(自动选择,优先考虑ss) | ss | netstat

## url
# 用于更新gfwlist.txt，格式：`域名后缀`或`server=/域名后缀/dns_ip`(dnsmasq格式，只关心`域名后缀`字段)
url_gfwlist='https://raw.githubusercontent.com/pexcn/daily/gh-pages/gfwlist/gfwlist.txt'
# 用于更新chnlist.txt，格式：`域名后缀`或`server=/域名后缀/dns_ip`(dnsmasq格式，只关心`域名后缀`字段)
url_chnlist='https://raw.githubusercontent.com/felixonmars/dnsmasq-china-list/master/accelerated-domains.china.conf'
# 用于更新chnroute*.txt，目前只支持APNIC格式，如果想使用其他ip库，建议在当前文件重写ss-tproxy的相关函数
url_chnroute='https://ftp.apnic.net/stats/apnic/delegated-apnic-latest'

## 回国模式
#
# 在国外访问大陆网站时，可能会出现ip区域限制等问题，导致无法正常使用大陆网络服务
# 此时可以使用"回国模式"，通过代理回到国内，摆脱ip区域限制等问题，原理与翻墙类似
#
# ss-tproxy支持回国模式，要切换到回国模式，请执行以下步骤：
#
# - 使用 gfwlist 分流模式，即 mode='gfwlist'
# - 互换 dns_direct* 和 dns_remote* 的配置内容
# - url_gfwlist 改为大陆域名列表的url，如 url_chnlist
# - 注释 gfwlist.ext 中的 Telegram 地址段 (这是给国内用的)
# - 执行 ss-tproxy update-gfwlist (将gfwlist.txt换成大陆域名)
#
# 以上步骤只需执行一次，之后就是正常使用 ss-tproxy start/stop 了

###################### 钩子函数 ######################

# 此函数在"启动逻辑之前"执行
pre_start() {
    # do something
    return
}

# 此函数在"启动逻辑之后"执行
post_start() {
    # do something
    return
}

# 此函数在"停止逻辑之前"执行
pre_stop() {
    # do something
    return
}

# 此函数在"停止逻辑之后"执行
post_stop() {
    # do something
    return
}

# 额外状态，如curl测试代理是否ok
extra_status() {
    # do something
    return
}

# 此函数在start的最后一步执行，获取运行时状态(如进程pid)，保存到文件
extra_pid() {
    # 格式同shell变量赋值，注意变量命名，防止冲突/覆盖
    # pid文件是一个shell脚本，下次执行时会source加载它
    # echo "pid_foo=$pid_foo"
    # echo "pid_bar=$pid_bar"
    return
}

###################### 自定义dns方案 ######################

# 自定义dns方案时，你需要自己实现"域名分流"(ignlist/chnlist/gfwlist)
# 并且将相关域名解析出来的ip加入ipset黑/白名单，以便与iptables规则联动
# 黑名单: sstp_black、sstp_black6 | 白名单: sstp_white、sstp_white6

# 以下接口不要求全部实现，你可以根据需要自由组织代码，保证逻辑正确即可
# 如果不知道怎么实现，可以参考ss-tproxy脚本中有关dns的源码，依葫芦画瓢

# 初始化，脚本加载时调用
custom_dns_init() {
    # do something
    return
}

# 要加入白名单的ip，启动dns之前调用
custom_dns_whiteip() {
    # 格式同 ignlist.ext，一行一个
    # echo "-223.5.5.5"
    # echo "~240C::6666"
    return
}

# 要加入黑名单的ip，启动dns之前调用
custom_dns_blackip() {
    # 格式同 gfwlist.ext，一行一个
    # echo "-8.8.8.8"
    # echo "~2001:4860:4860::8888"
    return
}

# 启动dns进程，请务必以dns_procgroup身份运行
custom_dns_start() {
    # do something
    return
}

# 关闭dns进程，stop时调用
custom_dns_stop() {
    # do something
    return
}

# 打印运行状态，status时调用
custom_dns_status() {
    # do something
    return
}

# 清空dns缓存，flush-dnscache时调用
custom_dns_flush() {
    # do something
    return
}

# 此函数在start的最后一步执行，获取运行时状态，同extra_pid
custom_dns_pid() {
    # 格式同shell变量赋值，注意变量命名，防止冲突/覆盖
    # pid文件是一个shell脚本，下次执行时会source加载它
    # echo "pid_foo=$pid_foo"
    # echo "pid_bar=$pid_bar"
    return
}

# 除了上述钩子函数，你还可以定义其他shell函数和变量
# 你也可以在当前文件使用ss-tproxy中已定义的函数和变量
#
# 若定义的函数与ss-tproxy中的同名，则本文件定义的函数覆盖原函数
# 使用自定义dns方案时，此特性可帮助你快速与原脚本融合(见脚本源码)
#
# ss-tproxy.conf是一个shell脚本，可以使用source来加载其他shell脚本
# ss-tproxy.conf被执行时，可以访问ss-tproxy传来的命令行参数(位置参数)
zfl9 commented 3 months ago

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

18280181597 commented 3 months ago

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

zfl9 commented 3 months ago

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

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

18280181597 commented 3 months ago

我用的代理服务器是我们公司自己用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

zfl9 commented 3 months ago

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

zfl9 commented 3 months ago

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

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

18280181597 commented 3 months ago

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

zfl9 commented 3 months ago

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

对于你描述的场景来说：

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

18280181597 commented 3 months ago

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

cattyhouse commented 3 months ago

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

cattyhouse commented 3 months ago

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

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

zfl9 commented 3 months ago

回看了 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，实现了“透明”代理。

18280181597 commented 3 months ago

我今天找了一个支持 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

zfl9 commented 3 months ago

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

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