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

[Bug] openwrt tun mixed stack unable to hijack dns #1258

Open
5 of 7 tasks
lux5am opened this issue May 12, 2024 · 4 comments
Open
5 of 7 tasks

[Bug] openwrt tun mixed stack unable to hijack dns #1258

lux5am opened this issue May 12, 2024 · 4 comments
Labels
bug Something isn't working

Comments

@lux5am
Copy link

lux5am commented May 12, 2024

Verify steps

  • I have read the documentation and understand the meaning of all configuration items I have written, avoiding a large number of seemingly useful options or default values.
  • I have not reviewed the documentation and resolve this issue.
  • I have not searched the Issue Tracker for the problem I am going to raise.
  • I have tested with the latest Alpha branch version, and the issue still persists.
  • I have provided server and client configuration files and processes that can reproduce the issue locally, rather than a desensitized complex client configuration file.
  • I have provided the simplest configuration that can reproduce the error I reported, rather than relying on remote servers, TUN, graphical client interfaces, or other closed-source software.
  • I have provided complete configuration files and logs, rather than providing only parts that I believe are useful due to confidence in my own intelligence.

Operating System

Linux

System Version

Openwrt 23.05.3

Mihomo Version

Mihomo Meta alpha-619f341 linux arm64 with go1.22.2 Sat May 11 16:12:32 UTC 2024
Use tags: with_gvisor

Configuration File

allow-lan: true
bind-address: "*"
mode: rule
log-level: warning
find-process-mode: 'off'
unified-delay: true
keep-alive-interval: 1800

external-controller: 0.0.0.0:9090
external-ui: ./ui

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: redir-host
  fake-ip-range: 198.18.0.1/16
  nameserver:
    # - 8.8.8.8
    - "https://94.140.14.14/dns-query"
  default-nameserver: 
    # - system
    - 8.8.8.8
  proxy-server-nameserver: 
    # - system
    # - 8.8.4.4
    - 1.1.1.1
proxies: []

proxy-groups:
  - name: 🌝Proxy
    type: select
    use:
      - myproxies

proxy-providers:
  myproxies:
    type: file
    path: ./proxy_provider/myproxies.yaml
    health-check:
      enable: true
      url: http://www.gstatic.com/generate_204
      interval: 1800

rules:
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,🌝Proxy

sniffer:   
  enable: true
  force-dns-mapping: false
  parse-pure-ip: true
  override-destination: false
  sniff: # TLS 和 QUIC 默认如果不配置 ports 默认嗅探 443
    QUIC:
      ports: [443]
    TLS:
      ports: [443, 8443, 5222-5228]
    # 默认嗅探 80
    HTTP: # 需要嗅探的端口
      ports: [80, 8080-8880]
  sniffing:
    - tls
    - http
  port-whitelist:
    - 80
    - 443

tun:
  enable: true
  mtu: 9000
  device: utun
  stack: mixed
  dns-hijack:
    - 0.0.0.0:53
  auto-route: true
  strict-route: false
  auto-detect-interface: true

Description

When using tun mixed stack local traffic didn't appear in connection log. It seems there's no local traffic routed to mihomo tun. Checked with curl https://ip.sb/ip it's indeed not enter mihomo.
Changed to system or gvisor there's no problem. It able to route local traffic normally.

I also tried sing-box. it has the same issue. I suspected it's something to do with sing library. I opened the issue few weeks ago in sing project it's immediately closed without reply as expected.

EDIT:
I checked again. It does route local traffic but the DNS request. So local service unable to resolve host.

Reproduction Steps

Enable tun with mixed stack.
Try to use internet within the router with ssh. Eg curl https://ip.sb/ip -A Mozilla
Observe

Logs

No response

@lux5am lux5am added the bug Something isn't working label May 12, 2024
@xishang0128
Copy link

xishang0128 commented May 14, 2024

image

image

It works fine on my device. I suggest checking if it's an issue with the local device/system.

@lux5am
Copy link
Author

lux5am commented May 15, 2024

It works fine on my device. I suggest checking if it's an issue with the local device/system.

What to check?
I tried openclash it works but it use manual route and some services don't get routed like local dns and other net service.

ip a | grep utun
8: utun: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UNKNOWN group default qlen 500
    inet 198.18.0.1/30 brd 198.18.0.3 scope global utun

EDIT:
I checked again. Apparently it does routed the traffic but failed to hijack DNS request.
Openclash actually replace dnsmasq forward DNS to mihomo :7874 so it works. But curl seems to not use dnsmasq (127.0.0.1:53). So it failed.
dig with random DNS server also always timed out. With system/gvisor dig is fine.

~# curl -vv google.com
* Could not resolve host: google.com
* Closing connection
curl: (6) Could not resolve host: google.com

~# curl -vv google.com --interface utun
* Host google.com:80 was resolved.
* IPv6: (none)
* IPv4: 172.253.118.102, 172.253.118.100, 172.253.118.139, 172.253.118.101, 172.253.118.113, 172.253.118.138
*   Trying 172.253.118.102:80...
* socket successfully bound to interface 'utun'
* Connected to google.com (172.253.118.102) port 80
> GET / HTTP/1.1
> Host: google.com
> User-Agent: curl/8.7.1
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 302 Found
< Location: http://www.google.com/sorry/index?continue=http://google.com/&q=EgRoHJqWGJ-zkLIGIinItgvMhX6eUMNNkBxIvu0DGEWQCCysuUzXEOIh05okgGz6L9y5635oEDIBcloBQw
< Date: Wed, 15 May 2024 02:10:39 GMT
< Pragma: no-cache
< Expires: Fri, 01 Jan 1990 00:00:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate
< Content-Type: text/html; charset=UTF-8
< Server: HTTP server (unknown)
< Content-Length: 347
< X-XSS-Protection: 0
<
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>302 Moved</TITLE></HEAD><BODY>
<H1>302 Moved</H1>
The document has moved
<A HREF="http://www.google.com/sorry/index?continue=http://google.com/&amp;q=EgRoHJqWGJ-zkLIGIinItgvMhX6eUMNNkBxIvu0DGEWQCCysuUzXEOIh05okgGz6L9y5635oEDIBcloBQw">here</A>.
</BODY></HTML>
* Connection #0 to host google.com left intact

@lux5am lux5am changed the title [Bug] openwrt tun mixed stack unable to route local traffic. [Bug] openwrt tun mixed stack unable to hijack dns May 15, 2024
@xishang0128
Copy link

@lux5am Check the resolv.conf file to ensure it does not contain private addresses, as private addresses cannot be hijacked.

@lux5am
Copy link
Author

lux5am commented May 15, 2024

@xishang0128
I always checked ignore resolv file in DHCP setting tho since it's connected to my isp router/modem and provide DHCP with its own DNS (192.168.0.1) so indeed it can't be hijacked.

Screenshot_20240515-161952_Termux

I tried with kdig @8.8.8.8 or any random server it also timeout. But sometimes it works. Which is strange.

Screenshot_20240515-164250_Termux

Switched to gvisor everything is fine.
Screenshot_20240515-164319_Termux

The same with system. The problem only when using mixed stack.

Turned off mihomo also no problem. My ISP actually hijack all DNS request at UDP:53 for censorship. So I use mihomo with fallback to doh.

So plain UDP with non censored domain should be fast. When using doh it should also responded in less than 1sec. So timeout should not be there.

It seems mihomo do hijack the DNS request but failed to response DNS request properly or something in between when using mixed stack.

I remember the problem occured only a few months ago. So I switched to gvisor. I reported to sing-box project since it's more appropriate to report sing problem in there, and it's closed immedietly without explanation as usual.
I suspected there's some changes in sing-tun or related library that mihomo uses. Since sing-box also suffer the same issue.

I enabled debug log and there's nothing about DNS in the log when using mixed stack. Switched to gvisor it immediately flooded with DNS hijack log.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants