为什么ipt2socks需要udp 443的端口监听呢？
xtccc opened this issue · comments
Jan 31 17:25:16 archwork ipt2socks[464762]: 2024-01-31 17:25:16 INF: [main] server address: 127.0.0.1#1080
Jan 31 17:25:16 archwork ipt2socks[464762]: 2024-01-31 17:25:16 INF: [main] listen address: 127.0.0.1#60080
Jan 31 17:25:16 archwork ipt2socks[464762]: 2024-01-31 17:25:16 INF: [main] listen address: ::1#60080
Jan 31 17:25:16 archwork ipt2socks[464762]: 2024-01-31 17:25:16 INF: [main] udp cache maximum size: 256
Jan 31 17:25:16 archwork ipt2socks[464762]: 2024-01-31 17:25:16 INF: [main] udp socket idle timeout: 60
Jan 31 17:25:16 archwork ipt2socks[464762]: 2024-01-31 17:25:16 INF: [main] number of worker threads: 1
Jan 31 17:25:16 archwork ipt2socks[464762]: 2024-01-31 17:25:16 INF: [main] enable tcp transparent proxy
Jan 31 17:25:16 archwork ipt2socks[464762]: 2024-01-31 17:25:16 INF: [main] enable udp transparent proxy
Jan 31 17:25:31 archwork ipt2socks[464762]: 2024-01-31 17:25:31 ERR: [udp_socks5_recv_udpmessage_cb] bind tproxy reply address: Address already in use
Jan 31 17:25:31 archwork ipt2socks[464762]: 2024-01-31 17:25:31 ERR: [udp_socks5_recv_udpmessage_cb] bind tproxy reply address: Address already in use
Jan 31 17:25:31 archwork ipt2socks[464762]: 2024-01-31 17:25:31 ERR: [udp_socks5_recv_udpmessage_cb] bind tproxy reply address: Address already in use
Jan 31 17:25:31 archwork ipt2socks[464762]: 2024-01-31 17:25:31 ERR: [udp_socks5_recv_udpmessage_cb] bind tproxy reply address: Address already in use
Jan 31 17:25:31 archwork ipt2socks[464762]: 2024-01-31 17:25:31 ERR: [udp_socks5_recv_udpmessage_cb] bind tproxy reply address: Address already in use
Jan 31 17:25:32 archwork ipt2socks[464762]: 2024-01-31 17:25:32 ERR: [udp_socks5_recv_udpmessage_cb] bind tproxy reply address: Address already in use
Jan 31 17:25:33 archwork ipt2socks[464762]: 2024-01-31 17:25:33 ERR: [udp_socks5_recv_udpmessage_cb] bind tproxy reply address: Address already in use
Jan 31 17:26:21 archwork ipt2socks[464762]: 2024-01-31 17:26:21 ERR: [udp_socks5_recv_udpmessage_cb] bind tproxy reply address: Address already in use
Jan 31 17:26:21 archwork ipt2socks[464762]: 2024-01-31 17:26:21 ERR: [udp_socks5_recv_udpmessage_cb] bind tproxy reply address: Address already in use
Jan 31 17:26:21 archwork ipt2socks[464762]: 2024-01-31 17:26:21 ERR: [udp_socks5_recv_udpmessage_cb] bind tproxy reply address: Address already in use
Jan 31 17:26:22 archwork ipt2socks[464762]: 2024-01-31 17:26:22 ERR: [udp_socks5_recv_udpmessage_cb] bind tproxy reply address: Address already in use
Jan 31 17:26:22 archwork ipt2socks[464762]: 2024-01-31 17:26:22 ERR: [udp_socks5_recv_udpmessage_cb] bind tproxy reply address: Address already in use
Jan 31 17:26:22 archwork ipt2socks[464762]: 2024-01-31 17:26:22 ERR: [udp_socks5_recv_udpmessage_cb] bind tproxy reply address: Address already in use
我发现它占用的是公网ip？
udp UNCONN 0 0 142.250.189.234:443 0.0.0.0:* users:(("ipt2socks",pid=464762,fd=138))
udp UNCONN 0 0 172.217.12.106:443 0.0.0.0:* users:(("ipt2socks",pid=464762,fd=133))
udp UNCONN 0 0 142.250.191.68:443 0.0.0.0:* users:(("ipt2socks",pid=464762,fd=68))
udp UNCONN 0 0 127.0.0.1:60080 0.0.0.0:* users:(("ipt2socks",pid=464762,fd=6))
udp UNCONN 0 0 [::1]:60080 [::]:* users:(("ipt2socks",pid=464762,fd=7))
tcp LISTEN 0 4096 127.0.0.1:60080 0.0.0.0:* users:(("ipt2socks",pid=464762,fd=4))
tcp LISTEN 0 4096 [::1]:60080 [::]:* users:(("ipt2socks",pid=4647
2024-01-31 17:52:45 INF: [udp_tproxy_recvmsg_cb] recv from 192.168.56.1#52033, nrecv:1250
2024-01-31 17:52:45 INF: [udp_tproxy_recvmsg_cb] try to connect to 127.0.0.1#1080 ...
2024-01-31 17:52:45 INF: [udp_socks5_connect_cb] connect to 127.0.0.1#1080 succeeded
2024-01-31 17:52:45 INF: [udp_socks5_send_authreq_cb] send to 127.0.0.1#1080, nsend:3
2024-01-31 17:52:45 INF: [udp_tproxy_recvmsg_cb] recv from 192.168.56.1#52033, nrecv:78
2024-01-31 17:52:45 INF: [udp_tproxy_recvmsg_cb] tunnel is not ready, discard this msg
2024-01-31 17:52:45 INF: [udp_socks5_recv_authresp_cb] recv from 127.0.0.1#1080, nrecv:2
2024-01-31 17:52:45 INF: [udp_socks5_recv_authresp_cb] send to 127.0.0.1#1080, nsend:10
2024-01-31 17:52:45 INF: [udp_socks5_recv_proxyresp_cb] recv from 127.0.0.1#1080, nrecv:10
2024-01-31 17:52:45 INF: [udp_socks5_recv_proxyresp_cb] send to 142.250.191.68#443, nsend:1260
2024-01-31 17:52:45 INF: [udp_socks5_recv_udpmessage_cb] recv from 142.250.191.68#443, nrecv:1260
2024-01-31 17:52:45 INF: [udp_socks5_recv_udpmessage_cb] send to 192.168.56.1#52033, nsend:1250
2024-01-31 17:52:45 INF: [udp_socks5_recv_udpmessage_cb] recv from 142.250.191.68#443, nrecv:810
2024-01-31 17:52:45 INF: [udp_socks5_recv_udpmessage_cb] send to 192.168.56.1#52033, nsend:800
2024-01-31 17:52:45 INF: [udp_socks5_recv_udpmessage_cb] recv from 142.250.191.68#443, nrecv:174
2024-01-31 17:52:45 INF: [udp_socks5_recv_udpmessage_cb] send to 192.168.56.1#52033, nsend:164
2024-01-31 17:52:45 INF: [udp_tproxy_recvmsg_cb] recv from 192.168.56.1#52033, nrecv:1250
2024-01-31 17:52:45 INF: [udp_tproxy_recvmsg_cb] send to 142.250.191.68#443, nsend:1260
2024-01-31 17:52:45 INF: [udp_tproxy_recvmsg_cb] recv from 192.168.56.1#52033, nrecv:73
2024-01-31 17:52:45 INF: [udp_tproxy_recvmsg_cb] send to 142.250.191.68#443, nsend:83
2024-01-31 17:52:45 INF: [udp_tproxy_recvmsg_cb] recv from 192.168.56.1#52033, nrecv:31
2024-01-31 17:52:45 INF: [udp_tproxy_recvmsg_cb] send to 142.250.191.68#443, nsend:41
2024-01-31 17:52:45 INF: [udp_tproxy_recvmsg_cb] recv from 192.168.56.1#52033, nrecv:32
2024-01-31 17:52:45 INF: [udp_tproxy_recvmsg_cb] send to 142.250.191.68#443, nsend:42
2024-01-31 17:52:46 INF: [udp_socks5_recv_udpmessage_cb] recv from 142.250.191.68#443, nrecv:128
2024-01-31 17:52:46 INF: [udp_socks5_recv_udpmessage_cb] send to 192.168.56.1#52033, nsend:118
2024-01-31 17:52:46 INF: [udp_tproxy_recvmsg_cb] recv from 192.168.56.1#52033, nrecv:32
2024-01-31 17:52:46 INF: [udp_tproxy_recvmsg_cb] send to 142.250.191.68#443, nsend:42
2024-01-31 17:52:46 INF: [udp_tproxy_recvmsg_cb] recv from 192.168.56.1#52033, nrecv:70
2024-01-31 17:52:46 INF: [udp_tproxy_recvmsg_cb] send to 142.250.191.68#443, nsend:80
2024-01-31 17:52:46 INF: [udp_socks5_context_timeout_cb] context will be released, reason: timeout
2024-01-31 17:52:46 INF: [udp_socks5_recv_udpmessage_cb] recv from 142.250.191.68#443, nrecv:35
2024-01-31 17:52:46 INF: [udp_socks5_recv_udpmessage_cb] send to 192.168.56.1#52033, nsend:25
2024-01-31 17:52:46 INF: [tcp_tproxy_accept_cb] source socket address: 192.168.56.1#50725
2024-01-31 17:52:46 INF: [tcp_tproxy_accept_cb] target socket address: 35.223.238.178#443
2024-01-31 17:52:46 INF: [tcp_tproxy_accept_cb] try to connect to 127.0.0.1#1080 ...
2024-01-31 17:52:46 INF: [tcp_socks5_connect_cb] connect to 127.0.0.1#1080 succeeded
2024-01-31 17:52:46 INF: [tcp_socks5_send_authreq_cb] send to 127.0.0.1#1080, nsend:3
2024-01-31 17:52:46 INF: [tcp_socks5_recv_authresp_cb] recv from 127.0.0.1#1080, nrecv:2
2024-01-31 17:52:46 INF: [tcp_socks5_recv_authresp_cb] send to 127.0.0.1#1080, nsend:10
2024-01-31 17:52:46 INF: [tcp_socks5_recv_proxyresp_cb] recv from 127.0.0.1#1080, nrecv:10
2024-01-31 17:52:46 INF: [tcp_socks5_recv_proxyresp_cb] tunnel is ready, start forwarding ...
2024-01-31 17:52:47 INF: [tcp_stream_payload_forward_cb] recv FIN from socks5 stream, release ctx
是的，这就是tproxy的核心原理，让ipt2socks假装是目标服务器（如8.8.8.8），通过这个tproxy socket向客户端发送响应数据时，因为src-address与真实的“目标服务器”相同，从而达到“欺骗”客户端的目的。
我发现它占用的是公网ip？
准确来说，bind的地址是 之前通过 ipt2socks 访问过 的目标 udp 服务器的 ip。
我发现它占用的是公网ip？
准确来说，bind的地址是 之前通过 ipt2socks 访问过 的目标 udp 服务器的 ip。
懂了，
我是在机器上装caddy ，caddy默认监听:443 ,发现 启动失败 ， 才发现这个现象
这个端口已占用的报错，可以通过 SO_REUSEADDR 选项解决（ipt2socks 本身是默认设置了该选项，只要占用目标端口的进程也给socket设置该选项就 OK）。
ipt2socks 监听了 udp 443, 因为你访问了那个 443, 那个ip看起来像是你访问了 youtube 并且用了 quic 协议, 并且因为这条 ip route add local default dev lo table 100 路由的原因.
如果caddy支持 so_reuseaddr 和 so_reuseport, 不会启动失败. 另外你可以关闭 caddy 的 udp ,只用 h1 h2 协议... protocols h1 h2
ipt2socks 监听了 udp 443, 因为你访问了那个 443, 那个ip看起来像是你访问了 youtube 并且用了
quic协议, 并且因为这条ip route add local default dev lo table 100路由的原因.如果caddy支持 so_reuseaddr 和 so_reuseport, 不会启动失败. 另外你可以关闭 caddy 的 udp ,只用 h1 h2 协议...
protocols h1 h2
好的， 没事 我通过让caddy监听指定ip解决问题， 反正听作者说的原理 ipt2socks不会监听内网ip