Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dae work with adguardhome #31

Closed
BOBINIUNIU opened this issue Mar 12, 2023 · 48 comments
Closed

dae work with adguardhome #31

BOBINIUNIU opened this issue Mar 12, 2023 · 48 comments

Comments

@BOBINIUNIU
Copy link

BOBINIUNIU commented Mar 12, 2023

I am using adguardhome as upstream DNS but it is not working with dae, the domain traffic split not work. Could you please give me a sample config file. Many thanks!

Node is naiveproxy socks5
adguardhome:china website 223.5.5.5 upd dns,other site Google DoH dns

My current configuration file is below

global {
tproxy_port: 12345
log_level: info
#tcp_check_url: 'http://keep-alv.google.com/generate_204'
#udp_check_dns: 'dns.google:53'
#check_interval: 30s
#check_tolerance: 50ms
lan_interface: enp1s0
# wan_interface: enp1s0
allow_insecure: false
dial_mode: domain
}

node {
fast_node: 'socks5://127.0.0.1:10000'
cloud_node: 'socks5://127.0.0.1:10001'
}

dns {
upstream {
adguardhomedns: 'tcp+udp://127.0.0.1:53'
}
#routing {
#request {
#fallback: asis
#}
#response {
#upstream(localdns) -> accept
# !qname(geosite:cn) && ip(geoip:private) -> googledns
#fallback: accept
#}
#}
}

Node group (outbound).

group {
fast_group {
policy: fixed(0)
}

cloud_group {
policy: fixed(1)
}

}

routing {
### Preset rules.
pname(AdGuardHome) -> must_direct
# pname(NetworkManager, systemd-resolved) -> direct
dip(224.0.0.0/3, 'ff00::/8') -> direct
dip(geoip:private) -> direct

### Write your rules below.
dip(1.0.0.1) -> fast_group
dip(1.1.1.1) -> fast_group
domain(apple.com) -> direct
domain(apple.news) -> direct
dip(geoip:cn) -> direct
domain(geosite:cn) -> direct
fallback: fast_group

}

@mzz2017
Copy link
Contributor

mzz2017 commented Mar 13, 2023

  1. You should use upstream adguardhome as your DNS like this:
dns {
  # upstream ...

  routing {
    request {
      fallback: adguardhome
    }
  }
}
  1. You should set DNS server in DHCP setting as the IP of dae.

Notice that if your adguardhome is in the same machine of dae, please bind to WAN to make the adguardhome's https traffic to google go through proxy. In this case, pname(AdGuardHome) -> must_direct should be replaced with pname(AdGuardHome) && l4proto(udp) && port(53) -> must_direct

@BOBINIUNIU
Copy link
Author

  1. You should use upstream adguardhome as your DNS like this:
dns {
  # upstream ...

  routing {
    request {
      fallback: adguardhome
    }
  }
}
  1. You should set DNS server in DHCP setting as the IP of dae.

Notice that if your adguardhome is in the same machine of dae, please bind to WAN to make the adguardhome's https traffic to google go through proxy. In this case, pname(AdGuardHome) -> must_direct should be replaced with pname(AdGuardHome) && l4proto(udp) && port(53) -> must_direct

Thank you for your quick reply.
Yes, the adguardhome and dae are installed in the same system as transparent proxy.
I followed your instruction and added the DNS settings, but now all the websites can not open anymore. Browser shows dns error.
My settings are as follows

dns {
upstream {
adguardhomedns: 'tcp+udp://127.0.0.1:53'
}
routing {
request {
fallback: adguardhomedns
}
}
}

routing {
pname(AdGuardHome) && l4proto(udp) && dport(53) -> must_direct
pname(NetworkManager, systemd-resolved) -> direct
dip(224.0.0.0/3, 'ff00::/8') -> direct
dip(geoip:private) -> direct
dip(geoip:cn) -> direct
domain(geoisite:cn) -> direct
fallback: fast_group
}

Some log message
Mar 13 20:35:53 debian dae[500]: level=info msg="localhost:10649 <-> 127.0.0.1:53" dialer=direct mac="7c:2b:e1:13:18:e6" network="udp4(DNS)" outbound=direct pid=482 pname=AdGuardHome policy=fixed qname=qq.com. qtype=65
Mar 13 20:35:53 debian dae[500]: level=info msg="localhost:58437 <-> 127.0.0.1:53" dialer=direct mac="7c:2b:e1:13:18:e6" network="udp4(DNS)" outbound=direct pid=482 pname=AdGuardHome policy=fixed qname=qq.com. qtype=65
Mar 13 20:35:53 debian dae[500]: level=info msg="localhost:17601 <-> 127.0.0.1:53" dialer=direct mac="7c:2b:e1:13:18:e6" network="udp4(DNS)" outbound=direct pid=482 pname=AdGuardHome policy=fixed qname=qq.com. qtype=65
Mar 13 20:35:53 debian dae[500]: level=info msg="localhost:7013 <-> 127.0.0.1:53" dialer=direct mac="7c:2b:e1:13:18:e6" network="udp4(DNS)" outbound=direct pid=482 pname=AdGuardHome policy=fixed qname=qq.com. qtype=65
Mar 13 20:36:02 debian dae[500]: level=warning msg="handleConn: handleTCP relay error: read tcp 127.0.0.1:8708->127.0.0.1:10000: read: connection reset by peer"
Mar 13 20:36:02 debian dae[500]: level=warning msg="handleConn: handleTCP relay error: read tcp 127.0.0.1:8702->127.0.0.1:10000: read: connection reset by peer"
Mar 13 20:36:02 debian dae[500]: level=warning msg="handleConn: handleTCP relay error: read tcp 127.0.0.1:8716->127.0.0.1:10000: read: connection reset by peer"
Mar 13 20:36:02 debian dae[500]: level=warning msg="handleConn: handleTCP relay error: read tcp 127.0.0.1:8720->127.0.0.1:10000: read: connection reset by peer"
Mar 13 20:36:02 debian dae[500]: level=warning msg="handleConn: handleTCP relay error: read tcp 127.0.0.1:8736->127.0.0.1:10000: read: connection reset by peer"
Mar 13 20:36:03 debian dae[500]: level=warning msg="handleConn: handleTCP relay error: read tcp 127.0.0.1:8746->127.0.0.1:10000: read: connection reset by peer"
Mar 13 20:36:03 debian dae[500]: level=info msg="localhost:14382 <-> 1.0.0.1:443" dialMode=ip dialer="fast_node" domain= mac="7c:2b:e1:13:18:e6" network=tcp4 outbound="fast_group" pid=482 pname=AdGuardHome policy=fixed
Mar 13 20:36:03 debian dae[500]: level=info msg="localhost:45134 <-> 127.0.0.1:53" dialer=direct mac="7c:2b:e1:13:18:e6" network="udp4(DNS)" outbound=direct pid=482 pname=AdGuardHome policy=fixed qname=myserver.top. qtype=TypeA
Mar 13 20:36:13 debian dae[500]: level=warning msg="handleConn: handleTCP relay error: read tcp 127.0.0.1:13198->127.0.0.1:10000: read: connection reset by peer"
Mar 13 20:36:24 debian dae[500]: level=info msg="localhost:50070 <-> 127.0.0.1:53" dialer=direct mac="7c:2b:e1:13:18:e6" network="udp4(DNS)" outbound=direct pid=482 pname=AdGuardHome policy=fixed qname=qq.com. qtype=TypeA
Mar 13 20:36:24 debian dae[500]: level=info msg="localhost:52362 <-> 127.0.0.1:53" dialer=direct mac="7c:2b:e1:13:18:e6" network="udp4(DNS)" outbound=direct pid=482 pname=AdGuardHome policy=fixed qname=qq.com. qtype=65
Mar 13 20:36:24 debian dae[500]: level=info msg="192.168.1.6:61897 <-> 127.0.0.1:53" dialer=direct mac="04:92:26:bd:fc:60" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qname=qq.com. qtype=TypeA
Mar 13 20:36:24 debian dae[500]: level=info msg="192.168.1.6:61897 <-> 127.0.0.1:53" dialer=direct mac="04:92:26:bd:fc:60" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qname=qq.com. qtype=TypeA
Mar 13 20:36:25 debian dae[500]: level=info msg="192.168.1.6:61897 <-> 127.0.0.1:53" dialer=direct mac="04:92:26:bd:fc:60" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qname=qq.com. qtype=TypeA
Mar 13 20:36:27 debian dae[500]: level=info msg="192.168.1.6:61897 <-> 127.0.0.1:53" dialer=direct mac="04:92:26:bd:fc:60" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qname=qq.com. qtype=TypeA
Mar 13 20:36:31 debian dae[500]: level=info msg="192.168.1.6:61897 <-> 127.0.0.1:53" dialer=direct mac="04:92:26:bd:fc:60" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qname=qq.com. qtype=TypeA

@mzz2017
Copy link
Contributor

mzz2017 commented Mar 13, 2023

The log shows your AdGuardHome is requesting 127.0.0.1:53(itself, I guess). This should not happen.

@BOBINIUNIU
Copy link
Author

BOBINIUNIU commented Mar 13, 2023

The log shows your AdGuardHome is requesting 127.0.0.1:53(itself, I guess). This should not happen.

Yes, dae seems to have intercepted the dns request, but local host and the PC that connected to the transparent gateway can't get the IP address.
The same configuration works fine on v2raya
Thank you for your great project.

A new error
Mar 13 21:26:32 debian dae[499]: level=warning msg="handlePkt: failed to read from: 127.0.0.1:53 (dialer: direct): read udp [::]:54994: i/o timeout"
Mar 13 21:26:32 debian dae[499]: level=warning msg="handlePkt: failed to read from: 127.0.0.1:53 (dialer: direct): read udp [::]:28874: i/o timeout"
Mar 13 21:26:32 debian dae[499]: level=warning msg="handleConn: handleTCP relay error: read tcp 127.0.0.1:17376->127.0.0.1:10000: read: connection reset by peer"

PS. the WAN port and the LAN port are both bound to enp1s0, is this the problem?

@mzz2017
Copy link
Contributor

mzz2017 commented Mar 13, 2023

You are right. I'll look into it. Maybe there is something wrong with dae's new code.

@BOBINIUNIU
Copy link
Author

You are right. I'll look into it. Maybe there is something wrong with dae's new code.

Please send me a message if you need test or log information. Thanks again and have a nice day.

@mzz2017
Copy link
Contributor

mzz2017 commented Mar 13, 2023

It should be fixed in 207c343. Thank you so much for your issue! Please test it again.

PS. the WAN port and the LAN port are both bound to enp1s0, is this the problem?

It doesn't matter. dae supports this.

@BOBINIUNIU
Copy link
Author

Thank you for fast update. The good news is the local host works! But the PC connected to the transparent gateway still does not work. no error message appear.

@mzz2017
Copy link
Contributor

mzz2017 commented Mar 13, 2023

I think you can configure your DHCP to use a public DNS (such as 8.8.8.8 and 223.5.5.5 but whatever it is); the requests will be intercepted by dae and forwarded to adguardhome. Because if you configure it as adguardhome_ip:53, the DNS traffic will be sent to adguardhome directly and not forwareded by dae.

@BOBINIUNIU
Copy link
Author

BOBINIUNIU commented Mar 13, 2023

I think you can configure your DHCP to use a public DNS (such as 8.8.8.8 and 223.5.5.5 but whatever it is); the requests will be intercepted by dae and forwarded to adguardhome. Because if you configure it as adguardhome_ip:53, the DNS traffic will be sent to adguardhome directly and not forwareded by dae.

Still not work, should I need change resolv.conf in local host? The current settings is 127.0.0.1 (adguardhome)

The public DNS configure in adguardhome is DoH https://1.1.1.1/dns-query

IP

@mzz2017
Copy link
Contributor

mzz2017 commented Mar 13, 2023

No. It should be OK. I committed a new patch ea568eb. Hope it can resolve it.

After this patch. I noticed that it is also feasible to set the IP of dae machine as DNS server in DHCP settings even if the port 53 is listened on by another program.

@BOBINIUNIU
Copy link
Author

Sorry, I have recompiled the latest version but no luck. No matter if I set DNS to adguardhome ip or public dns it doesn't work

Can you share your full configuration file?

the error message appears when I set the client DNS to 8.8.8.8
Mar 13 23:09:51 debian bash[461]: [0313/230951.860578:ERROR:ssl_client_socket_impl.cc(985)] handshake failed; returned -1, SSL error code 1, net_error -100
Mar 13 23:09:51 debian dae[482]: level=info msg="localhost:40588 <-> the server ip:443" dialMode=domain dialer="fast_node" domain=my.server.top mac="7c:2b:e1:13:18:e6" network=tcp4 outbound="fast_group" pid=461 pname=naive policy=fixed
Mar 13 23:09:51 debian dae[482]: level=warning msg="handleConn: handleTCP relay error: read tcp 127.0.0.1:30526->127.0.0.1:10000: read: connection reset by peer"
Mar 13 23:09:51 debian bash[461]: [0313/230951.876978:ERROR:ssl_client_socket_impl.cc(985)] handshake failed; returned -1, SSL error code 1, net_error -100

@mzz2017
Copy link
Contributor

mzz2017 commented Mar 13, 2023

OK.. But what is the naive process? I notice that the naive proxy is in the log. Are logs generated quickly now?

@BOBINIUNIU
Copy link
Author

I don't think it's a problem with naiveproxy. On the local host, the proxy works fine. But the client still can't get the IP address.

root@debian:~# wget qq.com
--2023-03-13 23:37:31-- http://qq.com/
Resolving qq.com (qq.com)... 123.151.137.18, 61.129.7.47, 183.3.226.35
Connecting to qq.com (qq.com)|123.151.137.18|:80... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: https://www.qq.com/ [following]
--2023-03-13 23:37:31-- https://www.qq.com/
Resolving www.qq.com (www.qq.com)... 121.14.77.221, 121.14.77.201
Connecting to www.qq.com (www.qq.com)|121.14.77.221|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html.10’

index.html.10 [ <=> ] 26.67K --.-KB/s in 0.02s

2023-03-13 23:37:31 (1.30 MB/s) - ‘index.html.10’ saved [27307]

root@debian:~# wget google.com
--2023-03-13 23:37:37-- http://google.com/
Resolving google.com (google.com)... 142.250.176.14
Connecting to google.com (google.com)|142.250.176.14|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://www.google.com/ [following]
--2023-03-13 23:37:37-- http://www.google.com/
Resolving www.google.com (www.google.com)... 142.250.188.228
Connecting to www.google.com (www.google.com)|142.250.188.228|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html.11’

index.html.11 [ <=> ] 15.73K --.-KB/s in 0.02s

2023-03-13 23:37:38 (772 KB/s) - ‘index.html.11’ saved [16103]

@mzz2017
Copy link
Contributor

mzz2017 commented Mar 13, 2023

OK. Do you have a linux machine? You can set log_level to trace in the dae configuration file, then:

  1. Use dig to test whether the dns is fine.
  2. Use curl 1.1.1.1 to test whether the request will be successful without dns.

I'm not sure whether you can do this on Windows with similar tools.

@BOBINIUNIU
Copy link
Author

OK. Do you have a linux machine? You can set log_level to trace in the dae configuration file, then:

  1. Use dig to test whether the dns is fine.
  2. Use curl 1.1.1.1 to test whether the request will be successful without dns.

I'm not sure whether you can do this on Windows with similar tools.

I will creat a VM to test tomorrow.
It's time to rest. Stay healthy :-)
Thank you for your hard work.

@mzz2017
Copy link
Contributor

mzz2017 commented Mar 13, 2023

Thanks for your help. Good night.

@BOBINIUNIU
Copy link
Author

BOBINIUNIU commented Mar 14, 2023

dig and curl output
root@test:~# dig qq.com

; <<>> DiG 9.16.37-Debian <<>> qq.com
;; global options: +cmd
;; connection timed out; no servers could be reached

root@test:~# dig google.com

; <<>> DiG 9.16.37-Debian <<>> google.com
;; global options: +cmd
;; connection timed out; no servers could be reached

root@test:~# curl -f qq.com
curl: (6) Could not resolve host: qq.com

DAE Log
Mar 14 09:50:22 debian dae[463]: level=trace msg="Request to DNS upstream" question=[{qq.com. TypeA ClassINET}] upstream="tcp+udp://127.0.0.1:53"
Mar 14 09:50:22 debian dae[463]: level=trace msg="Choose DNS path" ipversions=[4] l4protos=[udp tcp] upstream="tcp+udp://127.0.0.1:53"
Mar 14 09:50:22 debian dae[463]: level=trace msg="Update DNS record cache" addition=".(TypeOPT): dnsmessage.OPTResource{Options: []dnsmessage.Option{}}" ans="qq.com.(TypeA): 123.151.137.18; qq.com.(TypeA): 61.129.7.47; qq.com.(TypeA): 183.3.226.35" auth= qname=qq.com. rcode=RCodeSuccess
Mar 14 09:50:22 debian dae[463]: level=trace msg=Accept question=[{qq.com. TypeA ClassINET}] upstream="tcp+udp://127.0.0.1:53"
Mar 14 09:50:22 debian dae[463]: level=info msg="192.168.1.12:43311 <-> 127.0.0.1:53" dialer=direct mac="26:0e:1b:34:f6:6d" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qname=qq.com. qtype=TypeA
Mar 14 09:50:27 debian dae[463]: level=trace msg="UDP(DNS) 192.168.1.12:43311 <-> Cache: qq.com. TypeA"
Mar 14 09:50:32 debian dae[463]: level=trace msg="UDP(DNS) 192.168.1.12:43311 <-> Cache: qq.com. TypeA"
Mar 14 09:51:27 debian dae[463]: level=trace msg="Request to DNS upstream" question=[{google.com. TypeA ClassINET}] upstream="tcp+udp://127.0.0.1:53"
Mar 14 09:51:27 debian dae[463]: level=trace msg="Choose DNS path" ipversions=[4] l4protos=[udp tcp] upstream="tcp+udp://127.0.0.1:53"
Mar 14 09:51:27 debian dae[463]: level=info msg="localhost:46598 <-> 1.0.0.1:443" dialMode=ip dialer="fast_node" domain= mac="7c:2b:e1:13:18:e6" network=tcp4 outbound="fast_group" pid=445 pname=AdGuardHome policy=fixed
Mar 14 09:51:28 debian dae[463]: level=trace msg="Update DNS record cache" addition=".(TypeOPT): dnsmessage.OPTResource{Options: []dnsmessage.Option{}}" ans="google.com.(TypeA): 172.217.14.78" auth= qname=google.com. rcode=RCodeSuccess
Mar 14 09:51:28 debian dae[463]: level=trace msg=Accept question=[{google.com. TypeA ClassINET}] upstream="tcp+udp://127.0.0.1:53"
Mar 14 09:51:28 debian dae[463]: level=info msg="192.168.1.12:44100 <-> 127.0.0.1:53" dialer=direct mac="26:0e:1b:34:f6:6d" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qname=google.com. qtype=TypeA
Mar 14 09:51:32 debian dae[463]: level=trace msg="UDP(DNS) 192.168.1.12:44100 <-> Cache: google.com. TypeA"
Mar 14 09:51:37 debian dae[463]: level=trace msg="UDP(DNS) 192.168.1.12:44100 <-> Cache: google.com. TypeA"

@mzz2017
Copy link
Contributor

mzz2017 commented Mar 14, 2023

what about curl 1.1.1.1

@mzz2017
Copy link
Contributor

mzz2017 commented Mar 14, 2023

I think it may be a NIC problem. Try to listen AdGuardHome on a non-53 port.

Don't fotget to modify corresponding upstream settings in dae config.

@BOBINIUNIU
Copy link
Author

what about curl 1.1.1.1

root@test:~# curl 1.1.1.1

<title>301 Moved Permanently</title>

301 Moved Permanently


cloudflare

@BOBINIUNIU
Copy link
Author

I think it may be a NIC problem. Try to listen AdGuardHome on a non-53 port.

Don't fotget to modify corresponding upstream settings in dae config.

Modified the adguardhome port but still the same result

dns {
upstream {
adguardhomedns: 'tcp+udp://127.0.0.1:54'
}
routing {
request {
fallback: adguardhomedns
}
}
}
routing {
pname(AdGuardHome) && l4proto(udp) && dport(54) -> must_direct
pname(NetworkManager, systemd-resolved) -> direct

@mzz2017
Copy link
Contributor

mzz2017 commented Mar 14, 2023

So weird. I have the same configuration but cannot reproduce.

@mzz2017
Copy link
Contributor

mzz2017 commented Mar 14, 2023

What if you do not use adguardhome? Will it perform fine?

@mzz2017
Copy link
Contributor

mzz2017 commented Mar 14, 2023

Will adguardhome work (test it on port 53) when dae is stopped?

@BOBINIUNIU
Copy link
Author

What if you do not use adguardhome? Will it perform fine?

I have changed dns settings in dae and client to 1.1.1.1, same result. If remove the dns section in ade, it works.

dns {
upstream {
adguardhomedns: 'udp://1.1.1.1:53'
}
routing {
request {
fallback: adguardhomedns
}
}
}

nameserver 1.1.1.1

@BOBINIUNIU
Copy link
Author

Will adguardhome work (test it on port 53) when dae is stopped?

Yes, adguardhome works fine. The problem only occurs after added dns section to dae

@mzz2017
Copy link
Contributor

mzz2017 commented Mar 14, 2023

Ok... Good change... So if you change fallback:adgaurdhome to fallback:asis, will it remain failure?

@BOBINIUNIU
Copy link
Author

Ok... Good change... So if you change fallback:adgaurdhome to fallback:asis, will it remain failure?

changed dns to 1.1.1.1 and fallback to asis, I got these errors

Mar 14 11:50:23 debian dae[481]: level=trace msg="Request to DNS upstream" question=[{qq.com. TypeA ClassINET}] upstream=asis
Mar 14 11:50:23 debian dae[481]: level=trace msg="Choose DNS path" ipversions=[4] l4protos=[udp] upstream="udp://1.1.1.1:53"
Mar 14 11:50:23 debian dae[481]: level=trace msg="Request to DNS upstream" question=[{qq.com. TypeAAAA ClassINET}] upstream=asis
Mar 14 11:50:23 debian dae[481]: level=trace msg="Choose DNS path" ipversions=[4] l4protos=[udp] upstream="udp://1.1.1.1:53"
Mar 14 11:50:23 debian dae[481]: level=warning msg="handlePkt: failed to dial '1.1.1.1:53': proxy: SOCKS5 proxy at 127.0.0.1:10000 failed to connect: command not supported by socks5 server: UDPAssociate"
Mar 14 11:50:23 debian dae[481]: level=warning msg="handlePkt: failed to dial '1.1.1.1:53': proxy: SOCKS5 proxy at 127.0.0.1:10000 failed to connect: command not supported by socks5 server: UDPAssociate"
Mar 14 11:50:28 debian dae[481]: level=trace msg="Request to DNS upstream" question=[{qq.com. TypeA ClassINET}] upstream=asis
Mar 14 11:50:28 debian dae[481]: level=trace msg="Choose DNS path" ipversions=[4] l4protos=[udp] upstream="udp://1.1.1.1:53"
Mar 14 11:50:28 debian dae[481]: level=trace msg="Request to DNS upstream" question=[{qq.com. TypeAAAA ClassINET}] upstream=asis
Mar 14 11:50:28 debian dae[481]: level=trace msg="Choose DNS path" ipversions=[4] l4protos=[udp] upstream="udp://1.1.1.1:53"
Mar 14 11:50:28 debian dae[481]: level=warning msg="handlePkt: failed to dial '1.1.1.1:53': proxy: SOCKS5 proxy at 127.0.0.1:10000 failed to connect: command not supported by socks5 server: UDPAssociate"
Mar 14 11:50:28 debian dae[481]: level=warning msg="handlePkt: failed to dial '1.1.1.1:53': proxy: SOCKS5 proxy at 127.0.0.1:10000 failed to connect: command not supported by socks5 server: UDPAssociate"

@mzz2017
Copy link
Contributor

mzz2017 commented Mar 14, 2023

Please change your dns to 223.5.5.5 and try again.

@BOBINIUNIU
Copy link
Author

Please change your dns to 223.5.5.5 and try again.

Changed dns on both client and dae but no luck.

Mar 14 11:58:26 debian dae[483]: level=trace msg="Request to DNS upstream" question=[{qq.com. TypeA ClassINET}] upstream=asis
Mar 14 11:58:26 debian dae[483]: level=trace msg="Choose DNS path" ipversions=[4] l4protos=[udp] upstream="udp://223.5.5.5:53"
Mar 14 11:58:26 debian dae[483]: level=trace msg="Request to DNS upstream" question=[{qq.com. TypeAAAA ClassINET}] upstream=asis
Mar 14 11:58:26 debian dae[483]: level=trace msg="Choose DNS path" ipversions=[4] l4protos=[udp] upstream="udp://223.5.5.5:53"
Mar 14 11:58:26 debian dae[483]: level=trace msg="Update DNS record cache" addition=".(TypeOPT): dnsmessage.OPTResource{Options: []dnsmessage.Option{}}" ans="qq.com.(TypeA): 61.129.7.47; qq.com.(TypeA): 183.3.226.35; qq.com.(TypeA): 123.151.137.18" auth= qname=qq.com. rcode=RCodeSuccess
Mar 14 11:58:26 debian dae[483]: level=trace msg=Accept question=[{qq.com. TypeA ClassINET}] upstream=asis
Mar 14 11:58:26 debian dae[483]: level=info msg="192.168.1.12:58889 <-> 223.5.5.5:53" dialer=direct mac="26:0e:1b:34:f6:6d" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qname=qq.com. qtype=TypeA
Mar 14 11:58:26 debian dae[483]: level=trace msg=Accept question=[{qq.com. TypeAAAA ClassINET}] upstream=asis
Mar 14 11:58:26 debian dae[483]: level=info msg="192.168.1.12:58889 <-> 223.5.5.5:53" dialer=direct mac="26:0e:1b:34:f6:6d" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qname=qq.com. qtype=TypeAAAA
Mar 14 11:58:31 debian dae[483]: level=trace msg="UDP(DNS) 192.168.1.12:58889 <-> Cache: qq.com. TypeA"
Mar 14 11:58:31 debian dae[483]: level=trace msg="Request to DNS upstream" question=[{qq.com. TypeAAAA ClassINET}] upstream=asis
Mar 14 11:58:31 debian dae[483]: level=trace msg="Choose DNS path" ipversions=[4] l4protos=[udp] upstream="udp://223.5.5.5:53"
Mar 14 11:58:32 debian dae[483]: level=trace msg=Accept question=[{qq.com. TypeAAAA ClassINET}] upstream=asis
Mar 14 11:58:32 debian dae[483]: level=info msg="192.168.1.12:58889 <-> 223.5.5.5:53" dialer=direct mac="26:0e:1b:34:f6:6d" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qname=qq.com. qtype=TypeAAAA

here is the full config file
config.dae.txt

@mzz2017
Copy link
Contributor

mzz2017 commented Mar 14, 2023

There is a weird point. If your proxy does not support UDP, why after removing DNS section it can forward traffic to 1.1.1.1:53 successfully?

@mzz2017
Copy link
Contributor

mzz2017 commented Mar 14, 2023

I see. You mean that DNS server uses adguardhome in this case.

@mzz2017
Copy link
Contributor

mzz2017 commented Mar 14, 2023

I think dae should act like a normal dns server when port 53 is not in use. Can you reach me on telegram? @mzz2017

@BOBINIUNIU
Copy link
Author

I think dae should act like a normal dns server when port 53 is not in use. Can you reach me on telegram? @mzz2017

Sorry, my telegram account is currently unavailable

If the dns setting is added to dae, does that mean dae will listening on port 53? Maybe I should stop the adguradhome service and try again

@mzz2017
Copy link
Contributor

mzz2017 commented Mar 14, 2023

Dae will not actually listen on port 53. It uses a magic method to simulate. Use sudo netstat -ulpen or sudo lsof -i:53 to make sure 53 is not be listened on.

@BOBINIUNIU
Copy link
Author

I have disabled Adguardhome then changed dae dns and client dns to 223.5.5.5, it works now!

@mzz2017
Copy link
Contributor

mzz2017 commented Mar 14, 2023

Generally, it works fine regardless of whether other programs listen on 53. However, it will fail when you have some other program listen on port 53 and your NIC does not support to disable checksum verification in the production environment.

If you encounter this problem, the solution is to not occupy port 53. You should change your adguardhome listening port.

@BOBINIUNIU
Copy link
Author

Disable NIC checksum verification, do you mean this command?
ethtool --offload tx off

@mzz2017
Copy link
Contributor

mzz2017 commented Mar 14, 2023

Disable NIC checksum verification, do you mean this command? ethtool --offload tx off

No, it has nothing with offload. Do not disable it.

@BOBINIUNIU
Copy link
Author

Maybe I should give up using adguardhome if dae also supports the dns caching feature

@mzz2017
Copy link
Contributor

mzz2017 commented Mar 14, 2023

Maybe I should give up using adguardhome if dae also supports the dns caching feature

Yes. You can do this. Now dae only supports tcp/udp. DoH, DoT, DoQ are in TODO list. And if you still want to use adguardhome, I think trying changing the listening port is a good method.

Anyway, thanks for help with debugging.

@BOBINIUNIU
Copy link
Author

Can I using Doh in dae like this 1111dns: 'https://1.0.0.1/dns-query:443'

@mzz2017
Copy link
Contributor

mzz2017 commented Mar 14, 2023

Not yet. dae does not support DoH yet.

@mzz2017
Copy link
Contributor

mzz2017 commented Mar 14, 2023

Of course, this feature is important, and I think it should be supported in the first half of this year.

@BOBINIUNIU
Copy link
Author

Of course, this feature is important, and I think it should be supported in the first half of this year.

I will continue testing in the evening. Thank you very much for your patience!
dae is indeed faster than v2raya, hope it support Doh soon. good job!

@mzz2017
Copy link
Contributor

mzz2017 commented Mar 14, 2023

Thank you! Have a good day!

@mzz2017
Copy link
Contributor

mzz2017 commented Mar 14, 2023

I'll close this issue as completed. If you have other problems. Please open another issue.

@mzz2017 mzz2017 closed this as completed Mar 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants