[Bug] DNS udp requests are shown in log but not resolved

pmartini commented 1 year ago

Verify steps

[X] Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.
[X] I have searched on the issue tracker for a related issue.

Version

2.4.1

What OS are you seeing the problem on?

Linux

Description

Hello DNS queries are shown in tun2socks log, however dns requests are not resolved at all, neither curl domainname.com (curl: (6) Could not resolve host: ) or nslookup or any other, no response received. If use use raw ip address for http/https queries instead of domain name, everything works fine. To fix this I had to add a route to 8.8.8.8 and 1.1.1.1 server through default enp0s3 interface to prevent routing via tun0, but it leads to dns leaks in browser which is not good. Is there a way to make dns requests work via tun2socks tunnel ? Forcing DNS vis TCP helps on local machine however other machines in 10.10.10.0 network can't be forced to use DNS over TCP.

CLI or Config

ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:a7:fe:3a brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global enp0s3
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fea7:fe3a/64 scope link 
       valid_lft forever preferred_lft forever
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:ee:c8:e1 brd ff:ff:ff:ff:ff:ff
    inet 10.10.10.1/24 brd 10.10.10.255 scope global enp0s8
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:feee:c8e1/64 scope link 
       valid_lft forever preferred_lft forever
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 500
    link/none 
    inet 198.18.0.1/15 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::bebc:13c2:a2ee:3a19/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

ip route

default via 198.18.0.1 dev tun0 metric 1 
default via 10.0.2.2 dev enp0s3 metric 10 
10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15 
10.10.10.0/24 dev enp0s8 proto kernel scope link src 10.10.10.1 
{{shadowsocksServerIp}} via 10.0.2.2 dev enp0s3 
198.18.0.0/15 dev tun0 proto kernel scope link src 198.18.0.1

Logs

INFO[0098] [UDP] 198.18.0.1:53561 <-> 8.8.8.8:53        
INFO[0099] [UDP] 198.18.0.1:53561 <-> 1.1.1.1:53        
INFO[0106] [UDP] 198.18.0.1:57242 <-> 8.8.8.8:53        
INFO[0107] [UDP] 198.18.0.1:57242 <-> 1.1.1.1:53        
INFO[0146] [UDP] 198.18.0.1:55278 <-> 8.8.8.8:53        
INFO[0147] [UDP] 198.18.0.1:55278 <-> 1.1.1.1:53        
INFO[0203] [UDP] 198.18.0.1:60976 <-> 8.8.8.8:53        
INFO[0204] [UDP] 198.18.0.1:60976 <-> 1.1.1.1:53        
INFO[0250] [UDP] 198.18.0.1:50277 <-> 8.8.8.8:53        
INFO[0251] [UDP] 198.18.0.1:50277 <-> 1.1.1.1:53        
INFO[0281] [UDP] 198.18.0.1:47553 <-> 1.1.1.1:53        
INFO[0286] [UDP] 198.18.0.1:45350 <-> 8.8.8.8:53        
INFO[0289] [UDP] 198.18.0.1:50625 <-> 8.8.4.4:53        
INFO[0302] [UDP] 198.18.0.1:55232 <-> 8.8.8.8:53        
INFO[0303] [UDP] 198.18.0.1:55232 <-> 1.1.1.1:53

How to Reproduce

Download prebuild linux-amd64 binary version 2.4.1 and use on Debian 11 amd64, same if build from source code No response

xjasonlyu commented 1 year ago

Thanks for your feedback! I would like to ask if your proxy server correctly supports the UDP relay. If not, you should try to use one.

However, if you just wanna DNS over tcp or whatsoever, you can install a DoH server locally. That will do all the magic.

Ador-able commented 1 year ago

我貌似遇到了同样的问题。 ddc6492eee1c22174aa7dd9464e4c2c bd4f4aa9c3c21e085ddc20786e10b9d ping域名，日志正常显示，但是无法解析 effd43227410d5718275f7f1a840671 直接curl ip，是可以正常走代理的。

我是部署在docker desktop for window上的。代理是V2rayN,已经开启udp

我不太懂这些，怎么做才能正常dns解析呢？非常感谢

Ador-able commented 1 year ago

我写了一个脚本发送udp请求，通过代理去解析域名。在v2rayN中是能看到代理udp的相关日志的。

但是tun2socks发送的udp在v2rayN中看不到。好难，搞不懂。

Ador-able commented 1 year ago

设置了以下内容，可以正常访问网页了。 ip rule add to 8.8.8.8 lookup main ip rule add to 192.168.65.7 lookup main

但是容器内走udp的服务都无法正常代理。

执行 / # echo "hello" | nc -u -w1 192.168.1.100 1234 可以看到日志输出 2023-03-24 19:57:11 time="2023-03-24T11:57:11Z" level=info msg="[UDP] 198.18.0.1:54598 <-> 192.168.1.100:1234" 2023-03-24 19:57:28 time="2023-03-24T11:57:28Z" level=info msg="[UDP] 198.18.0.1:58025 <-> 192.168.1.100:1234"

但是v2rayN中看不到任何信息。正常情况下应该能看到 2023/03/24 19:58:57 [Info] [3137682001] proxy/socks: client UDP connection from udp:127.0.0.1:65099 2023/03/24 19:58:57 [Debug] [3137682001] proxy/socks: send packet to udp:192.168.1.100:1234 with 32 bytes

xjasonlyu commented 1 year ago

@Ador-able It's probably your v2ray side's issue. When using UDP behind NAT, you should be careful to configure the right UDP binding address for your socks server.

Ador-able commented 1 year ago

@xjasonlyu 我使用python PySocks库写了一个测试脚本，其中通过代理发送udp流量，在tun2socks容器内部执行的。使用同样的代理地址，脚本发送的udp流量能被正确代理。经过tun2socks的udp流量 v2ray接收不到

xjasonlyu commented 1 year ago

v2ray 有个UDP设置的，你应该是那里没设置对。

Ador-able commented 1 year ago

是可以正常代理udp流量的

Ador-able commented 1 year ago

@xjasonlyu 确实是nat后的原因，socks5.go的123行，返回的代理 IP 地址是127.0.0.1，导致udp发错了。是否可以将127.0.0.1这种地址也走一下net.ResolveUDPAddr

xjasonlyu commented 1 year ago

这是不符合Socks5 UDP规范的，不应该更改tun2socks的代码，而应该是配置v2ray UDP的时候将监听地址绑定正确。

github-actions[bot] commented 1 year ago

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days

xjasonlyu / tun2socks