search

zfl9 / chinadns-ng

chinadns 重构增强版，支持域名分流、ipset/nftset、UDP/TCP/DoT
GNU Affero General Public License v3.0
1.1k stars 184 forks source link

诚心求教：搞了几天，国内网ok，科学上网不通 #105

Closed wentijianihao closed 2 years ago

wentijianihao commented 2 years ago

ssrplus本身可正常科学上网，但搭配chinadns-ng后无法科学上网，国内网可以上。

具体设置如下： chinadns-ng端口6688 ssrplus 大陆白名单模式，DNS解析用自带的dns2tcp（应该是5335端口） 1、关闭turboACC的DNS缓存功能。 2、dnsmasq开启忽略解析文件，并转发到127.0.0.1#6688 3、chinadns-ng本地指向119.29.29.29，信任指向127.0.0.1#5335

而后，也尝试了启用dns-forward的5335端口取代SSRplus自带的。

反正折腾了几天，也刷了其他固件，都不行，技术小白快崩溃了。 诚心求教啊！！

zfl9 commented 2 years ago

dnsmasq:53@udp -> chinadns-ng:6688@udp -> dns2tcp/dns-forward:5335@udp -> 国外dns:53@tcp(这一步需要走代理)

zfl9 commented 2 years ago

估计是最后一步出问题了，国外dns你设置的是哪个上游？8.8.8.8:53@tcp？

zfl9 commented 2 years ago

不过没有日志的话，也很难定位问题。。。

wentijianihao commented 2 years ago

8.8.4.4:53@tcp，8.8.4.4也加入wan必翻名单了。不知日志在哪儿能看

zfl9 commented 2 years ago

需要 dnsmasq chinadns-ng dns2tcp 的日志

wentijianihao commented 2 years ago

有一点特别奇怪： 比如"google.com"在dnsmasq的server配置里 （ssrplus设置的） server=/google.com/127.0.0.1#5335

dnsmsq的server配置应该比 “转发“ 优先级更高吧，而127.0.0.1#5335在工作呢。 按理说，chinadns-ng配置成功与否，都不影响google.com的访问啊。

可实际情况是，google.com也访问不了。

zfl9 commented 2 years ago

靠猜没用，要看dnsmasq日志，才能知道转发到哪个上游去了，顺着这个请求链路，结合log才能定位问题

zfl9 commented 2 years ago

你可以 dig google.com @127.0.0.1 -p5335 +tcp 验证dns2tcp/dns-forward是否正常工作，解析出来的ip对不对，是不是走了代理

zfl9 commented 2 years ago

如果这一步测试失败，那么问题应该就是 dns2tcp/dns-forward 发出的tcp流量 没有走代理

wentijianihao commented 2 years ago 
root@OpenWrt:~# dig google.com @127.0.0.1 -p5335 +short
172.217.26.238
root@OpenWrt:~# dig google.com @127.0.0.1 -p5335 +tcp
;; Connection to 127.0.0.1#5335(127.0.0.1) for google.com failed: connection refused.
;; Connection to 127.0.0.1#5335(127.0.0.1) for google.com failed: connection refused.
;; Connection to 127.0.0.1#5335(127.0.0.1) for google.com failed: connection refused.

加上“+tcp” 被拒绝

zfl9 commented 2 years ago

sorry，我搞错了，不要+tcp

wentijianihao commented 2 years ago

dig google.com @127.0.0.1 -p5335 +short 172.217.26.238 结果地址是对的

zfl9 commented 2 years ago

那你就要看dnsmasq和chinadns-ng的日志了，可能是dnsmasq没有将查询请求转发给chinadns-ng，或者是chinadns-ng配置有问题。。。

zfl9 commented 2 years ago

dig @127.0.0.1 -p6688 google.com 看结果对不对，以及跟踪chinadns-ng的log

zfl9 commented 2 years ago

dig @127.0.0.1 -p53 google.com 看结果对不对，以及跟踪dnsmasq和chinadns-ng的log

zfl9 commented 2 years ago

然后就能大概定位到问题是出在哪一环了（dnsmasq还是chinadns-ng

wentijianihao commented 2 years ago 
root@OpenWrt:~# dig @127.0.0.1 -p 34567 google.com +short  （chinadns-ng端口34567，刚改了）
172.217.26.238
root@OpenWrt:~# dig @127.0.0.1 -p 53 google.com +short （dnsmsaq）
172.217.26.238

貌似都ok

zfl9 commented 2 years ago

那就是不是dns这边的问题了。curl看下能否访问这个ip curl -4sSk -H'Host: www.google.com' http://172.217.26.238 -v

zfl9 commented 2 years ago

可能的原因：

  1. 路由器上的 /etc/resolv.conf 没有指向 dnsmasq（即 127.0.0.1），会影响路由器自身的dns查询
  2. 路由器下的客户机 获取的dns不是路由器的ip，导致这些客户机的dns查询没有发给对应的dnsmasq
wentijianihao commented 2 years ago

那就是不是dns这边的问题了。curl看下能否访问这个ip curl -4sSk -H'Host: www.google.com' http://172.217.26.238 -v

能获取到!doctype html

zfl9 commented 2 years ago

那就看下原因2，确认下

wentijianihao commented 2 years ago

可能的原因：

  1. 路由器上的 /etc/resolv.conf 没有指向 dnsmasq（即 127.0.0.1），会影响路由器自身的dns查询
  2. 路由器下的客户机 获取的dns不是路由器的ip，导致这些客户机的dns查询没有发给对应的dnsmasq /etc/resolv.conf 的内容 search lan nameserver 127.0.0.1 nameserver ::1
zfl9 commented 2 years ago

客户机的dns和网关，是否指向路由器自身

wentijianihao commented 2 years ago

是的呢，dhcp自动下发的。不鼓捣的情况下，所有客户机都能透明科学上网呢。

zfl9 commented 2 years ago

经过前面的 dig 和 curl，确认路由器自身是能透明代理上网了。 所以只能猜测：1.路由器自身是否能透明代理来自客户机的dns和tcp/udp流量 2.客户机获取的网关和dns是否正确

wentijianihao commented 2 years ago

/usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.cfg01411c -k -x /var/run/dnsmasq/dnsmasq.cfg01411c.pid

/var/etc/dnsmasq.conf.cfg01411c：

# auto-generated config file from /etc/config/dhcp
conf-file=/etc/dnsmasq.conf
dhcp-authoritative
domain-needed
no-resolv
localise-queries
read-ethers
enable-ubus=dnsmasq
expand-hosts
bind-dynamic
local-service
min-ttl=3600
cache-size=8000
edns-packet-max=1232
domain=lan
local=/lan/
server=127.0.0.1#34567
addn-hosts=/tmp/hosts
dhcp-leasefile=/tmp/dhcp.leases
stop-dns-rebind
rebind-localhost-ok
dhcp-broadcast=tag:needs-broadcast
conf-dir=/tmp/dnsmasq.d
user=dnsmasq
group=dnsmasq

dhcp-ignore-names=tag:dhcp_bogus_hostname
conf-file=/usr/share/dnsmasq/dhcpbogushostname.conf

srv-host=_vlmcs._tcp,OpenWrt,1688,0,100

bogus-priv
conf-file=/usr/share/dnsmasq/rfc6761.conf
dhcp-range=set:lan,10.10.10.2,10.10.10.251,255.255.255.0,12h
no-dhcp-interface=pppoe-wan
zfl9 commented 2 years ago 
#192.168.1.1改为路由器自身LAN IP 试试？
dhcp-option=option:router,192.168.1.1
dhcp-option=option:dns-server,192.168.1.1
wentijianihao commented 2 years ago 
#192.168.1.1改为路由器自身LAN IP 试试？
dhcp-option=option:router,192.168.1.1
dhcp-option=option:dns-server,192.168.1.1

请问在哪儿添加

zfl9 commented 2 years ago

这个你需要看固件了，具体怎么配置，因固件而异，应该由web图形界面配置的。

其实你可以先手动在客户机，查看获取的网关和dns是否正确

wentijianihao commented 2 years ago

获取的网关和dns正确：

连接特定的 DNS 后缀 . . . . . . . : lan 描述. . . . . . . . . . . . . . . : Intel(R) Wi-Fi 6 AX200 160MHz 物理地址. . . . . . . . . . . . . : 3C-9C-0F-8E-7E-7A DHCP 已启用 . . . . . . . . . . . : 是 自动配置已启用. . . . . . . . . . : 是 本地链接 IPv6 地址. . . . . . . . : fe80::a497:120:bd9e:2c62%12(首选) IPv4 地址 . . . . . . . . . . . . : 10.10.10.233(首选) 子网掩码 . . . . . . . . . . . . : 255.255.255.0 获得租约的时间 . . . . . . . . . : 2022年9月15日 18:13:17 租约过期的时间 . . . . . . . . . : 2022年9月16日 6:13:17 默认网关. . . . . . . . . . . . . : 10.10.10.1 DHCP 服务器 . . . . . . . . . . . : 10.10.10.1 DHCPv6 IAID . . . . . . . . . . . : 121412623 DHCPv6 客户端 DUID . . . . . . . : 00-01-00-01-25-FB-A9-B3-F4-39-09-76-94-72 DNS 服务器 . . . . . . . . . . . : 10.10.10.1 TCPIP 上的 NetBIOS . . . . . . . : 已启用

zfl9 commented 2 years ago

那和dns应该没关系了，代理方面的问题，可能。

wentijianihao commented 2 years ago

-t 127.0.0.1#5335 上游dns超时 没起作用，比如访问github.com时报err

root@OpenWrt:~# /usr/bin/chinadns-ng -b 127.0.0.1 -l 6688 -c 114.114.114.114,119.29.29.29 -t 127.0.0.1#5335 -g /etc/chinadns-ng/gfwlist.txt -m /etc/chinadns-ng/chinalist.txt -v /root/chinadns-ng.log

2022-09-16 10:36:22 INF: [main] local listen addr: 127.0.0.1#6688
2022-09-16 10:36:22 INF: [main] chinadns server#1: 114.114.114.114#53
2022-09-16 10:36:22 INF: [main] chinadns server#2: 119.29.29.29#53
2022-09-16 10:36:22 INF: [main] trustdns server#1: 127.0.0.1#5335
2022-09-16 10:36:22 INF: [main] ipset ip4 setname: chnroute
2022-09-16 10:36:22 INF: [main] ipset ip6 setname: chnroute6
2022-09-16 10:36:22 INF: [main] dns query timeout: 5 seconds
2022-09-16 10:36:22 INF: [main] gfwlist entries count: 5743
2022-09-16 10:36:22 INF: [main] chnlist entries count: 52438
2022-09-16 10:36:22 INF: [main] gfwlist have higher priority
2022-09-16 10:36:22 INF: [main] filter reply without ip addr
2022-09-16 10:36:22 INF: [main] cur judgment mode: fast mode
2022-09-16 10:36:22 INF: [main] print the verbose running log

2022-09-16 10:37:10 INF: [handle_local_packet] query [sk3.cshan.win] from 127.0.0.1#37146 (0)
2022-09-16 10:37:10 INF: [handle_local_packet] query [sk3.cshan.win] from 127.0.0.1#43996 (1)
2022-09-16 10:37:10 INF: [handle_remote_packet] reply [sk3.cshan.win] from 114.114.114.114#53 (1), result: filter
2022-09-16 10:37:10 INF: [handle_remote_packet] reply [sk3.cshan.win] from 119.29.29.29#53 (1), result: filter
2022-09-16 10:37:10 INF: [handle_remote_packet] reply [sk3.cshan.win] from 114.114.114.114#53 (0), result: filter
2022-09-16 10:37:10 INF: [handle_remote_packet] reply [sk3.cshan.win] from 119.29.29.29#53 (0), result: filter
2022-09-16 10:37:10 INF: [handle_local_packet] query [t.pthome.net] from 127.0.0.1#34634 (2)
2022-09-16 10:37:10 INF: [handle_local_packet] query [t.pthome.net] from 127.0.0.1#38914 (3)
2022-09-16 10:37:10 INF: [handle_remote_packet] reply [t.pthome.net] from 119.29.29.29#53 (3), result: filter
2022-09-16 10:37:10 INF: [handle_remote_packet] reply [t.pthome.net] from 119.29.29.29#53 (2), result: filter
2022-09-16 10:37:10 INF: [handle_remote_packet] reply [t.pthome.net] from 114.114.114.114#53 (2), result: filter
2022-09-16 10:37:10 INF: [handle_remote_packet] reply [t.pthome.net] from 114.114.114.114#53 (3), result: filter
2022-09-16 10:37:11 INF: [handle_local_packet] query [api.miwifi.com] from 127.0.0.1#42203 (4)
2022-09-16 10:37:11 INF: [handle_local_packet] query [api.miwifi.com] from 127.0.0.1#36661 (5)
2022-09-16 10:37:11 INF: [handle_remote_packet] reply [api.miwifi.com] from 119.29.29.29#53 (4), result: accept
2022-09-16 10:37:11 INF: [handle_remote_packet] reply [api.miwifi.com] from 119.29.29.29#53 (5), result: accept
2022-09-16 10:37:11 INF: [handle_remote_packet] reply [api.miwifi.com] from 114.114.114.114#53 (4), result: ignore
2022-09-16 10:37:11 INF: [handle_remote_packet] reply [api.miwifi.com] from 114.114.114.114#53 (5), result: ignore
2022-09-16 10:37:11 INF: [handle_local_packet] query [www.baidu.com] from 127.0.0.1#47055 (6)
2022-09-16 10:37:11 INF: [handle_local_packet] query [www.baidu.com] from 127.0.0.1#46882 (7)
2022-09-16 10:37:11 INF: [handle_remote_packet] reply [www.baidu.com] from 119.29.29.29#53 (7), result: accept
2022-09-16 10:37:11 INF: [handle_remote_packet] reply [www.baidu.com] from 119.29.29.29#53 (6), result: accept
2022-09-16 10:37:11 INF: [handle_remote_packet] reply [www.baidu.com] from 114.114.114.114#53 (6), result: ignore
2022-09-16 10:37:11 INF: [handle_remote_packet] reply [www.baidu.com] from 114.114.114.114#53 (7), result: ignore
2022-09-16 10:37:11 INF: [handle_local_packet] query [www.taobao.com] from 127.0.0.1#49112 (8)
2022-09-16 10:37:11 INF: [handle_local_packet] query [www.taobao.com] from 127.0.0.1#37262 (9)
2022-09-16 10:37:11 INF: [handle_remote_packet] reply [www.taobao.com] from 119.29.29.29#53 (8), result: accept
2022-09-16 10:37:11 INF: [handle_remote_packet] reply [www.taobao.com] from 119.29.29.29#53 (9), result: accept
2022-09-16 10:37:11 INF: [handle_remote_packet] reply [www.taobao.com] from 114.114.114.114#53 (8), result: ignore
2022-09-16 10:37:11 INF: [handle_remote_packet] reply [www.taobao.com] from 114.114.114.114#53 (9), result: ignore
2022-09-16 10:37:11 INF: [handle_local_packet] query [config.pinyin.sogou.com] from 127.0.0.1#46913 (10)
2022-09-16 10:37:11 INF: [handle_remote_packet] reply [config.pinyin.sogou.com] from 119.29.29.29#53 (10), result: accept
2022-09-16 10:37:11 INF: [handle_remote_packet] reply [config.pinyin.sogou.com] from 114.114.114.114#53 (10), result: ignore
2022-09-16 10:37:15 INF: [handle_local_packet] query [t.pthome.net] from 127.0.0.1#38914 (11)
2022-09-16 10:37:15 INF: [handle_remote_packet] reply [t.pthome.net] from 119.29.29.29#53 (11), result: filter
2022-09-16 10:37:15 INF: [handle_remote_packet] reply [t.pthome.net] from 114.114.114.114#53 (11), result: filter
2022-09-16 10:37:15 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 0
2022-09-16 10:37:15 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 1
2022-09-16 10:37:15 INF: [handle_local_packet] query [sk3.cshan.win] from 127.0.0.1#43996 (12)
2022-09-16 10:37:15 INF: [handle_local_packet] query [sk3.cshan.win] from 127.0.0.1#37146 (13)
2022-09-16 10:37:15 INF: [handle_remote_packet] reply [sk3.cshan.win] from 119.29.29.29#53 (13), result: filter
2022-09-16 10:37:15 INF: [handle_remote_packet] reply [sk3.cshan.win] from 119.29.29.29#53 (12), result: filter
2022-09-16 10:37:15 INF: [handle_remote_packet] reply [sk3.cshan.win] from 114.114.114.114#53 (12), result: filter
2022-09-16 10:37:15 INF: [handle_remote_packet] reply [sk3.cshan.win] from 114.114.114.114#53 (13), result: filter
2022-09-16 10:37:15 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 2
2022-09-16 10:37:15 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 3
2022-09-16 10:37:15 INF: [handle_local_packet] query [t.pthome.net] from 127.0.0.1#34634 (14)
2022-09-16 10:37:15 INF: [handle_remote_packet] reply [t.pthome.net] from 119.29.29.29#53 (14), result: filter
2022-09-16 10:37:15 INF: [handle_remote_packet] reply [t.pthome.net] from 114.114.114.114#53 (14), result: filter
2022-09-16 10:37:20 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 11
2022-09-16 10:37:20 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 12
2022-09-16 10:37:20 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 13
2022-09-16 10:37:20 INF: [handle_local_packet] query [sk3.cshan.win] from 127.0.0.1#43996 (15)
2022-09-16 10:37:20 INF: [handle_local_packet] query [sk3.cshan.win] from 127.0.0.1#37146 (16)
2022-09-16 10:37:20 INF: [handle_remote_packet] reply [sk3.cshan.win] from 119.29.29.29#53 (15), result: filter
2022-09-16 10:37:20 INF: [handle_remote_packet] reply [sk3.cshan.win] from 119.29.29.29#53 (16), result: filter
2022-09-16 10:37:20 INF: [handle_remote_packet] reply [sk3.cshan.win] from 114.114.114.114#53 (15), result: filter
2022-09-16 10:37:20 INF: [handle_remote_packet] reply [sk3.cshan.win] from 114.114.114.114#53 (16), result: filter
2022-09-16 10:37:20 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 14
2022-09-16 10:37:20 INF: [handle_local_packet] query [t.pthome.net] from 127.0.0.1#34634 (17)
2022-09-16 10:37:20 INF: [handle_local_packet] query [t.pthome.net] from 127.0.0.1#38914 (18)
2022-09-16 10:37:20 INF: [handle_remote_packet] reply [t.pthome.net] from 119.29.29.29#53 (17), result: filter
2022-09-16 10:37:20 INF: [handle_remote_packet] reply [t.pthome.net] from 119.29.29.29#53 (18), result: filter
2022-09-16 10:37:20 INF: [handle_remote_packet] reply [t.pthome.net] from 114.114.114.114#53 (17), result: filter
2022-09-16 10:37:20 INF: [handle_remote_packet] reply [t.pthome.net] from 114.114.114.114#53 (18), result: filter
2022-09-16 10:37:22 INF: [handle_local_packet] query [t.pthome.net] from 127.0.0.1#38914 (19)
2022-09-16 10:37:22 INF: [handle_remote_packet] reply [t.pthome.net] from 119.29.29.29#53 (19), result: filter
2022-09-16 10:37:22 INF: [handle_remote_packet] reply [t.pthome.net] from 114.114.114.114#53 (19), result: filter
2022-09-16 10:37:24 INF: [handle_local_packet] query [t.pthome.net] from 127.0.0.1#34634 (20)
2022-09-16 10:37:24 INF: [handle_remote_packet] reply [t.pthome.net] from 119.29.29.29#53 (20), result: filter
2022-09-16 10:37:24 INF: [handle_remote_packet] reply [t.pthome.net] from 114.114.114.114#53 (20), result: filter
2022-09-16 10:37:25 INF: [handle_local_packet] query [t.pthome.net] from 127.0.0.1#38914 (21)
2022-09-16 10:37:25 INF: [handle_remote_packet] reply [t.pthome.net] from 119.29.29.29#53 (21), result: filter
2022-09-16 10:37:25 INF: [handle_remote_packet] reply [t.pthome.net] from 114.114.114.114#53 (21), result: filter
2022-09-16 10:37:25 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 15
2022-09-16 10:37:25 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 16
2022-09-16 10:37:25 INF: [handle_local_packet] query [sk3.cshan.win] from 127.0.0.1#43996 (22)
2022-09-16 10:37:25 INF: [handle_local_packet] query [sk3.cshan.win] from 127.0.0.1#37146 (23)
2022-09-16 10:37:25 INF: [handle_remote_packet] reply [sk3.cshan.win] from 119.29.29.29#53 (23), result: filter
2022-09-16 10:37:25 INF: [handle_remote_packet] reply [sk3.cshan.win] from 119.29.29.29#53 (22), result: filter
2022-09-16 10:37:25 INF: [handle_remote_packet] reply [sk3.cshan.win] from 114.114.114.114#53 (22), result: filter
2022-09-16 10:37:25 INF: [handle_remote_packet] reply [sk3.cshan.win] from 114.114.114.114#53 (23), result: filter
2022-09-16 10:37:25 INF: [handle_local_packet] query [t.pthome.net] from 127.0.0.1#34634 (24)
2022-09-16 10:37:25 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 17
2022-09-16 10:37:25 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 18
2022-09-16 10:37:25 INF: [handle_remote_packet] reply [t.pthome.net] from 119.29.29.29#53 (24), result: filter
2022-09-16 10:37:25 INF: [handle_remote_packet] reply [t.pthome.net] from 114.114.114.114#53 (24), result: filter
2022-09-16 10:37:27 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 19
2022-09-16 10:37:29 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 20
2022-09-16 10:37:30 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 21
2022-09-16 10:37:30 INF: [handle_local_packet] query [t.pthome.net] from 127.0.0.1#34634 (25)
2022-09-16 10:37:30 INF: [handle_remote_packet] reply [t.pthome.net] from 119.29.29.29#53 (25), result: filter
2022-09-16 10:37:30 INF: [handle_remote_packet] reply [t.pthome.net] from 114.114.114.114#53 (25), result: filter
2022-09-16 10:37:30 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 22
2022-09-16 10:37:30 ERR: [handle_timeout_event] upstream dns server reply timeout, unique msgid: 23
zfl9 commented 2 years ago

127.0.0.1#5335 根本都没有响应dns查询请求。去看dns2tcp/dns-forward的日志，看为什么没返回。

wentijianihao commented 2 years ago 
oot@OpenWrt:~# /var/etc/ssrplus/bin/dns2tcp -L 127.0.0.1#5335 -R 8.8.8.8#53 v
2022-09-16 12:22:11 INF: [main] udp listen addr: 127.0.0.1#5335
2022-09-16 12:22:11 INF: [main] tcp remote addr: 8.8.8.8#53

2022-09-16 12:24:11 ERR: [tcp_recvmsg_cb] recv from 8.8.8.8#53: connection is closed
2022-09-16 12:24:11 ERR: [tcp_recvmsg_cb] recv from 8.8.8.8#53: connection is closed
2022-09-16 12:24:11 ERR: [tcp_recvmsg_cb] recv from 8.8.8.8#53: connection is closed
2022-09-16 12:24:11 ERR: [tcp_recvmsg_cb] recv from 8.8.8.8#53: connection is closed
wentijianihao commented 2 years ago

感觉跟ssrplus和turboacc的逻辑有关。

各种配置测试，有的情况下 dns2tcp -R 8.8.8.8#53 v 正常，不报错，也能科学上网。

wentijianihao commented 2 years ago

dnsmasq dns转发关闭，或者转发到turboacc dns缓存 都正常出国。 一旦dnsmasq转发到本机其他tcp协议的dns（经测试该服务本身正常运行），就无法出国，此时该服务日志显示无法链接到8.8.8.8（已加入wan强制走代理）。不知是哪个环节出问题了？ 始终没有“”tcp_recvmsg_cb“ root@OpenWrt:/etc/init.d# /var/etc/ssrplus/bin/dns2tcp -L 127.0.0.1#5335 -R 8.8.8.8#53 -v

2022-09-17 13:33:04 INF: [main] udp listen addr: 127.0.0.1#5335 2022-09-17 13:33:04 INF: [main] tcp remote addr: 8.8.8.8#53 2022-09-17 13:33:04 INF: [main] verbose mode, affect performance

2022-09-17 13:33:06 INF: [udp_recvmsg_cb] recv from 127.0.0.1#45781, nrecv:31 2022-09-17 13:33:06 INF: [udp_recvmsg_cb] try to connect to 8.8.8.8#53 2022-09-17 13:33:06 INF: [tcp_connect_cb] connect to 8.8.8.8#53 succeed 2022-09-17 13:33:06 INF: [tcp_sendmsg_cb] send to 8.8.8.8#53, nsend:33 2022-09-17 13:33:11 INF: [udp_recvmsg_cb] recv from 127.0.0.1#45781, nrecv:36 2022-09-17 13:33:11 INF: [udp_recvmsg_cb] try to connect to 8.8.8.8#53 2022-09-17 13:33:11 INF: [tcp_connect_cb] connect to 8.8.8.8#53 succeed 2022-09-17 13:33:11 INF: [tcp_sendmsg_cb] send to 8.8.8.8#53, nsend:38 2022-09-17 13:33:11 INF: [udp_recvmsg_cb] recv from 127.0.0.1#45781, nrecv:31 2022-09-17 13:33:11 INF: [udp_recvmsg_cb] try to connect to 8.8.8.8#53 2022-09-17 13:33:11 INF: [tcp_connect_cb] connect to 8.8.8.8#53 succeed 2022-09-17 13:33:11 INF: [tcp_sendmsg_cb] send to 8.8.8.8#53, nsend:33 2022-09-17 13:33:16 INF: [udp_recvmsg_cb] recv from 127.0.0.1#45781, nrecv:31 2022-09-17 13:33:16 INF: [udp_recvmsg_cb] try to connect to 8.8.8.8#53 2022-09-17 13:33:16 INF: [tcp_connect_cb] connect to 8.8.8.8#53 succeed 2022-09-17 13:33:16 INF: [tcp_sendmsg_cb] send to 8.8.8.8#53, nsend:33 2022-09-17 13:33:18 INF: [udp_recvmsg_cb] recv from 127.0.0.1#45781, nrecv:27 2022-09-17 13:33:18 INF: [udp_recvmsg_cb] try to connect to 8.8.8.8#53 2022-09-17 13:33:18 INF: [tcp_connect_cb] connect to 8.8.8.8#53 succeed 2022-09-17 13:33:18 INF: [tcp_sendmsg_cb] send to 8.8.8.8#53, nsend:29 2022-09-17 13:33:21 INF: [udp_recvmsg_cb] recv from 127.0.0.1#45781, nrecv:31 2022-09-17 13:33:21 INF: [udp_recvmsg_cb] try to connect to 8.8.8.8#53 2022-09-17 13:33:21 INF: [tcp_connect_cb] connect to 8.8.8.8#53 succeed 2022-09-17 13:33:21 INF: [tcp_sendmsg_cb] send to 8.8.8.8#53, nsend:33`

zfl9 commented 2 years ago

说明本机(路由器)tcp代理有问题，8.8.8.8没走代理 或 代理链路有问题

wentijianihao commented 2 years ago

破案了！这几天折腾的！！ 不通的原因：科学服务器地址用的是域名而不是ip导致的。 由于该ip指向墙外，chinadns-ng的国内NS解析一看是墙外IP，就等8.8.8.8的解析结果，这时巧了，连通墙外服务器又等着解析服务ip。你等我，我等你，死循环了。 解决办法：把自建或机场服务器域名写入 dnsmasq server文件，在“高级设置-额外的 SERVERS 文件”。