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

[Feature Request] Connect to company network #565

Closed
marsjane opened this issue Jun 25, 2024 · 54 comments
Closed

[Feature Request] Connect to company network #565

marsjane opened this issue Jun 25, 2024 · 54 comments
Labels
help wanted Extra attention is needed

Comments

@marsjane
Copy link

marsjane commented Jun 25, 2024

Greetings

No response

Feature Request

Hi,thanks for this great work, I've been going through most of the documentation and plan to migrate to dae. However, I have several questions:

  1. I didn't find clear explanations about the config positions for dae in the doc. For arch, the config position seem to be /etc/dae ? Is it possible to put it under other place, like ~/.config/dae?
  2. if only under /etc/dae, which permission should it be? As I want to add several new files to use the separated configuration as shown in Config Examples #81 (comment)
    Is it necessary to do sudo chmod -R 0640 /etc/dae ? I just wonder is there any config file permission requirement for dae to run.
    Can you help clarify these?

Use Cases

other places for config files
separated configuration

Potential Benefits

clear understanding about config location and permission requirements

@dae-prow
Copy link
Contributor

dae-prow bot commented Jun 25, 2024

Thanks for opening this issue!

@mzz2017
Copy link
Contributor

mzz2017 commented Jun 25, 2024

  1. Anywhere is ok once you specify it in running arguments. dae requires root to run, thus ~/.config/dae (user config dir) seems not a good choice.
  2. 0600 is recommended due to security consideration, which is the same reason as .ssh/id_rsa

@marsjane
Copy link
Author

got it thanks! btw, some routing rules not effective can you help check?
here is the log:

[Jun 25 15:30:15] TRACE Received UDP(DNS) 192.168.50.237:36385 <-> 192.168.50.1:53: kkkkk.abcde. A
[Jun 25 15:30:15] TRACE Request to DNS upstream question=[{Name:kkkkk.abcde. Qtype:1 Qclass:1}] upstream=udp://dns.alidns.com:53
[Jun 25 15:30:15] TRACE Choose DNS path choose=udp+4 ipversions=[4 6] l4protos=[udp] upstream=udp://dns.alidns.com:53 use=223.5.5.5:53
[Jun 25 15:30:15] TRACE Accept question=[{Name:kkkkk.abcde. Qtype:1 Qclass:1}] upstream=udp://dns.alidns.com:53
[Jun 25 15:30:15]  INFO 192.168.50.237:36385 <-> 223.5.5.5:53 _qname=kkkkk.abcde. dialer=direct dscp=0 mac=48:21:0b:32:5f:4a network=udp4(DNS) outbound=direct pid=711 pname=tailscaled policy=fixed qtype=A
[Jun 25 15:30:15] TRACE Received UDP(DNS) 192.168.50.237:46950 <-> 192.168.50.1:53: kkkkk.abcde. AAAA
[Jun 25 15:30:15] TRACE Request to DNS upstream question=[{Name:kkkkk.abcde. Qtype:28 Qclass:1}] upstream=udp://dns.alidns.com:53
[Jun 25 15:30:15] TRACE Choose DNS path choose=udp+4 ipversions=[4 6] l4protos=[udp] upstream=udp://dns.alidns.com:53 use=223.5.5.5:53
[Jun 25 15:30:15] TRACE Accept question=[{Name:kkkkk.abcde. Qtype:28 Qclass:1}] upstream=udp://dns.alidns.com:53
[Jun 25 15:30:15]  INFO 192.168.50.237:46950 <-> 223.5.5.5:53 _qname=kkkkk.abcde. dialer=direct dscp=0 mac=48:21:0b:32:5f:4a network=udp4(DNS) outbound=direct pid=711 pname=tailscaled policy=fixed qtype=AAAA

I already add rule like:

domain(keyword:kkkkk) -> new_group

but it seems not working, from the log it seems still go to direct, I tried to replace kkkkk as github, it can go to new_group when opening github, so the rule seems not working due to the special website kkkkk.abcde ? can you see the reason from the log?

@marsjane
Copy link
Author

I even tried to put this rule at the top line of routing, still the same. For global settings I use the same as the example. so really confusing...

@mzz2017
Copy link
Contributor

mzz2017 commented Jun 25, 2024

@marsjane This is dns; its target is 223.5.5.5.
Write a rule in dns routing instead.

@marsjane
Copy link
Author

emm it is a website... I did some more tests, can you help check the results?
What I do is adding the rule domain(keyword:gitlab) -> MYPROXY, the MYPROXY group only have one node MYPROXY_http, then I test to open http://gitlab.company and https://gitlab.com, basically I think the rule should let both of them go to MYPROXY_http node, however, when I test this, the https://gitlab.com do work as expected with the log:

[Jun 25 17:12:30] TRACE Accept question=[{Name:gitlab.com. Qtype:28 Qclass:1}] upstream=tcp+udp://dns.google.com:53
[Jun 25 17:12:30]  INFO 192.168.50.237:42194 <-> 8.8.8.8:53 _qname=gitlab.com. dialer=香港标准 IEPL 中继 1 dscp=0 mac=48:21:0b:32:5f:4a network=tcp4(DNS) outbound=HK pid=711 pname=tailscaled policy=min_moving_avg qtype=AAAA
[Jun 25 17:12:30] TRACE Update DNS record cache _qname=gitlab.com. ans=gitlab.com.(AAAA): 2606:4700:90:0:f22e:fbec:5bed:a9b9 rcode=0
[Jun 25 17:12:30] DEBUG UDP(DNS) 192.168.50.237:60518 <-> Cache: gitlab.com. AAAA
[Jun 25 17:12:30] DEBUG Rewrite dial target to domain from=172.65.251.78:443 to=gitlab.com:443
[Jun 25 17:12:30]  INFO 192.168.50.237:42566 <-> gitlab.com:443 dialer=MYPROXY_http dscp=0 ip=172.65.251.78:443 mac=48:21:0b:32:5f:4a network=tcp4 outbound=MYPROXY pid=0 pname=vivaldi-bin policy=fixed sniffed=gitlab.com
[Jun 25 17:12:30] TRACE Received UDP(DNS) 192.168.50.237:36159 <-> 192.168.50.1:53: gitlab.com. A
[Jun 25 17:12:30] DEBUG UDP(DNS) 192.168.50.237:36159 <-> Cache: gitlab.com. A
[Jun 25 17:12:30] TRACE Received UDP(DNS) 192.168.50.237:44712 <-> 192.168.50.1:53: gitlab.com. AAAA
[Jun 25 17:12:30] DEBUG UDP(DNS) 192.168.50.237:44712 <-> Cache: gitlab.com. AAAA
[Jun 25 17:12:30] DEBUG Rewrite dial target to domain from=172.65.251.78:443 to=gitlab.com:443
[Jun 25 17:12:30]  INFO 192.168.50.237:42568 <-> gitlab.com:443 dialer=MYPROXY_http dscp=0 ip=172.65.251.78:443 mac=48:21:0b:32:5f:4a network=tcp4 outbound=MYPROXY pid=0 pname=vivaldi-bin policy=fixed sniffed=gitlab.com
[Jun 25 17:12:30] DEBUG Rewrite dial target to domain from=172.65.251.78:443 to=gitlab.com:443
[Jun 25 17:12:30]  INFO 192.168.50.237:42582 <-> gitlab.com:443 dialer=MYPROXY_http dscp=0 ip=172.65.251.78:443 mac=48:21:0b:32:5f:4a network=tcp4 outbound=MYPROXY pid=0 pname=vivaldi-bin policy=fixed sniffed=gitlab.com

but for the http://gitlab.company, which is my company intranet, it seems just ignore this rule, log as follows:

[Jun 25 17:11:00] TRACE Accept question=[{Name:gitlab.company. Qtype:1 Qclass:1}] upstream=tcp+udp://dns.google.com:53
[Jun 25 17:11:00]  INFO 192.168.50.237:44861 <-> 8.8.8.8:53 _qname=gitlab.company. dialer=香港标准 IEPL 中继 1 dscp=0 mac=48:21:0b:32:5f:4a network=tcp4(DNS) outbound=HK pid=711 pname=tailscaled policy=min_moving_avg qtype=A
[Jun 25 17:11:00] TRACE Received UDP(DNS) 192.168.50.237:48329 <-> 192.168.50.1:53: gitlab.company. AAAA
[Jun 25 17:11:00] TRACE Request to DNS upstream question=[{Name:gitlab.company. Qtype:28 Qclass:1}] upstream=tcp+udp://dns.google.com:53
[Jun 25 17:11:00] TRACE Choose DNS path choose=tcp+4 ipversions=[4 6] l4protos=[udp tcp] upstream=tcp+udp://dns.google.com:53 use=8.8.8.8:53
[Jun 25 17:11:00] TRACE Received UDP(DNS) 192.168.50.237:43972 <-> 192.168.50.1:53: gzdata1.fc-smartserver.xyz. AAAA
[Jun 25 17:11:00] TRACE Received UDP(DNS) 192.168.50.237:42102 <-> 192.168.50.1:53: gzdata1.fc-smartserver.xyz. A
[Jun 25 17:11:00] DEBUG UDP(DNS) 192.168.50.237:43972 <-> Cache: gzdata1.fc-smartserver.xyz. AAAA
[Jun 25 17:11:00] DEBUG UDP(DNS) 192.168.50.237:42102 <-> Cache: gzdata1.fc-smartserver.xyz. A
[Jun 25 17:11:00] TRACE Accept question=[{Name:gitlab.company. Qtype:28 Qclass:1}] upstream=tcp+udp://dns.google.com:53
[Jun 25 17:11:00]  INFO 192.168.50.237:48329 <-> 8.8.8.8:53 _qname=gitlab.company. dialer=香港标准 IEPL 中继 1 dscp=0 mac=48:21:0b:32:5f:4a network=tcp4(DNS) outbound=HK pid=711 pname=tailscaled policy=min_moving_avg qtype=AAAA
[Jun 25 17:11:00] DEBUG 192.168.50.237:39502 <-> 104.194.8.134:9993 dialer=香港标准 IEPL 中继 1 dscp=0 ip=104.194.8.134:9993 mac=48:21:0b:32:5f:4a network=udp4 outbound=HK pid=871 pname=zerotier-one policy=min_moving_avg sniffed=

it ignore the rule then go to the fallback group which is my HK proxy

Could you help check which part is wrong here? Thank!

@mzz2017
Copy link
Contributor

mzz2017 commented Jun 25, 2024

This seems a known problem fixed in #542.
Try 0.7.0rc1 or main

@mzz2017 mzz2017 added help wanted Extra attention is needed and removed topic/feature labels Jun 25, 2024
@marsjane
Copy link
Author

Thanks, but I just checked my version is 0.7.0rc1, and I also tried the git version: dae version unstable-0.7.0rc1.r3.g3fd2826 go runtime go1.22.4 linux/amd64 it still the same error, I put my config here, can you kindly help check:

global {
    tproxy_port: 7888
    tproxy_port_protect: true
    pprof_port: 0
    so_mark_from_dae: 0
    log_level: debug
    disable_waiting_network: false
    enable_local_tcp_fast_redirect: false
    wan_interface: auto
    auto_config_kernel_parameter: true
    tcp_check_url: 'http://cp.cloudflare.com,1.1.1.1,2606:4700:4700::1111'
    tcp_check_http_method: HEAD
    udp_check_dns: 'dns.google.com:53,8.8.8.8,2001:4860:4860::8888'
    check_interval: 600s
    check_tolerance: 50ms
    dial_mode: domain
    allow_insecure: false
    sniffing_timeout: 100ms
    tls_implementation: tls
    utls_imitate: chrome_auto
}
subscription {
    tk: ''
}

node {
    CM_http: 'http://localhost:8843'
}

dns {
    upstream {
        alidns: 'udp://dns.alidns.com:53'
        googledns: 'tcp+udp://dns.google.com:53'
    }
    routing {
        request {
            qname(geosite:cn) -> alidns
            fallback: googledns
        }
    }
}

group {
    HK {
        filter: name(keyword:'香港标准')
        policy: min_moving_avg
    }
    CM {
       filter: name(CM_http)
       policy: fixed(0)
    }
}

routing {
    domain(keyword:gitlab) -> CM
    pname(NetworkManager) -> direct

    dip(224.0.0.0/3, 'ff00::/8') -> direct

    dip(geoip:private) -> direct

    domain(keyword:company) -> CM

    l4proto(udp) && dport(443) -> block
    dip(geoip:cn) -> direct
    domain(geosite:cn) -> direct
    domain(geosite:category-ads) -> block
    fallback: HK
}

so key is why the domain(keyword:company) -> CM not working. FYI these intranet is sth like http://*.company

@mzz2017
Copy link
Contributor

mzz2017 commented Jun 26, 2024

I'll look into it.

@marsjane
Copy link
Author

Thanks, because seems the domain(keyword:gitlab) -> CM also not working if it is http://gitlab.company

@KuGouGo
Copy link

KuGouGo commented Jun 26, 2024

Thanks, because seems the domain(keyword:gitlab) -> CM also not working if it is http://gitlab.company

试试加个空格 domain(keyword: company) -> CM

@mzz2017
Copy link
Contributor

mzz2017 commented Jun 26, 2024

这个看起来是 sniffed 为空,所以 routing 没有生效

@marsjane
Copy link
Author

marsjane commented Jun 26, 2024

刚刚试了一下加了空格:

routing {
    ### Preset rules.

    # Network managers in localhost should be direct to avoid false negative network connectivity check when binding to
    # WAN.
    domain(keyword: company) -> CM
    domain(keyword: gitlab) -> CM
......

但是好像还是不行,我用curl -I 测试了一下,log更干净一些,发现了一些问题,这是完整的相关log对比:

# for gitlab.com
[Jun 26 19:32:00] TRACE Received UDP(DNS) 192.168.50.237:60363 <-> 192.168.50.1:53: gitlab.com. A
[Jun 26 19:32:00] TRACE Request to DNS upstream question=[{Name:gitlab.com. Qtype:1 Qclass:1}] upstream=tcp+udp://dns.google.com:53
[Jun 26 19:32:00] TRACE Choose DNS path choose=tcp+4 ipversions=[4 6] l4protos=[udp tcp] upstream=tcp+udp://dns.google.com:53 use=8.8.8.8:53
[Jun 26 19:32:00] TRACE Received UDP(DNS) 192.168.50.237:43772 <-> 192.168.50.1:53: gzdata1.fc-smartserver.xyz. AAAA
[Jun 26 19:32:00] TRACE Received UDP(DNS) 192.168.50.237:55744 <-> 192.168.50.1:53: gzdata1.fc-smartserver.xyz. A
[Jun 26 19:32:00] DEBUG UDP(DNS) 192.168.50.237:43772 <-> Cache: gzdata1.fc-smartserver.xyz. AAAA
[Jun 26 19:32:00] DEBUG UDP(DNS) 192.168.50.237:55744 <-> Cache: gzdata1.fc-smartserver.xyz. A
[Jun 26 19:32:00] TRACE Accept question=[{Name:gitlab.com. Qtype:1 Qclass:1}] upstream=tcp+udp://dns.google.com:53
[Jun 26 19:32:00]  INFO 192.168.50.237:60363 <-> 8.8.8.8:53 _qname=gitlab.com. dialer=香港标准 IEPL 中继 5 dscp=0 mac=48:21:0b:32:5f:4a network=tcp4(DNS) outbound=HK pid=711 pname=tailscaled policy=min_moving_avg qtype=A

[Jun 26 19:32:00] TRACE Update DNS record cache _qname=gitlab.com. ans=gitlab.com.(A): 172.65.251.78 rcode=0
[Jun 26 19:32:00] TRACE Received UDP(DNS) 192.168.50.237:60777 <-> 192.168.50.1:53: gitlab.com. AAAA
[Jun 26 19:32:00] TRACE Request to DNS upstream question=[{Name:gitlab.com. Qtype:28 Qclass:1}] upstream=tcp+udp://dns.google.com:53
[Jun 26 19:32:00] TRACE Choose DNS path choose=tcp+4 ipversions=[4 6] l4protos=[udp tcp] upstream=tcp+udp://dns.google.com:53 use=8.8.8.8:53
[Jun 26 19:32:00] TRACE Received UDP(DNS) 192.168.50.237:34868 <-> 192.168.50.1:53: gzdata1.fc-smartserver.xyz. AAAA
[Jun 26 19:32:00] TRACE Received UDP(DNS) 192.168.50.237:34452 <-> 192.168.50.1:53: gzdata1.fc-smartserver.xyz. A
[Jun 26 19:32:00] DEBUG UDP(DNS) 192.168.50.237:34868 <-> Cache: gzdata1.fc-smartserver.xyz. AAAA
[Jun 26 19:32:00] DEBUG UDP(DNS) 192.168.50.237:34452 <-> Cache: gzdata1.fc-smartserver.xyz. A
[Jun 26 19:32:00] TRACE Accept question=[{Name:gitlab.com. Qtype:1 Qclass:1}] upstream=tcp+udp://dns.google.com:53
[Jun 26 19:32:00]  INFO 192.168.50.237:60363 <-> 8.8.8.8:53 _qname=gitlab.com. dialer=香港标准 IEPL 中继 5 dscp=0 mac=48:21:0b:32:5f:4a network=tcp4(DNS) outbound=HK pid=711 pname=tailscaled policy=min_moving_avg qtype=A
[Jun 26 19:32:00] TRACE Update DNS record cache _qname=gitlab.com. ans=gitlab.com.(A): 172.65.251.78 rcode=0
[Jun 26 19:32:00] TRACE Received UDP(DNS) 192.168.50.237:60777 <-> 192.168.50.1:53: gitlab.com. AAAA
[Jun 26 19:32:00] TRACE Request to DNS upstream question=[{Name:gitlab.com. Qtype:28 Qclass:1}] upstream=tcp+udp://dns.google.com:53
[Jun 26 19:32:00] TRACE Choose DNS path choose=tcp+4 ipversions=[4 6] l4protos=[udp tcp] upstream=tcp+udp://dns.google.com:53 use=8.8.8.8:53
[Jun 26 19:32:00] TRACE Received UDP(DNS) 192.168.50.237:34868 <-> 192.168.50.1:53: gzdata1.fc-smartserver.xyz. AAAA
[Jun 26 19:32:00] TRACE Received UDP(DNS) 192.168.50.237:34452 <-> 192.168.50.1:53: gzdata1.fc-smartserver.xyz. A
[Jun 26 19:32:00] DEBUG UDP(DNS) 192.168.50.237:34868 <-> Cache: gzdata1.fc-smartserver.xyz. AAAA
[Jun 26 19:32:00] DEBUG UDP(DNS) 192.168.50.237:34452 <-> Cache: gzdata1.fc-smartserver.xyz. A
[Jun 26 19:32:00] TRACE Accept question=[{Name:gitlab.com. Qtype:28 Qclass:1}] upstream=tcp+udp://dns.google.com:53
[Jun 26 19:32:00]  INFO 192.168.50.237:60777 <-> 8.8.8.8:53 _qname=gitlab.com. dialer=香港标准 IEPL 中继 5 dscp=0 mac=48:21:0b:32:5f:4a network=tcp4(DNS) outbound=HK pid=711 pname=tailscaled policy=min_moving_avg qtype=AAAA
[Jun 26 19:32:00] TRACE Update DNS record cache _qname=gitlab.com. ans=gitlab.com.(AAAA): 2606:4700:90:0:f22e:fbec:5bed:a9b9 rcode=0
[Jun 26 19:32:00] DEBUG Rewrite dial target to domain from=172.65.251.78:80 to=gitlab.com:80
[Jun 26 19:32:00]  INFO 192.168.50.237:42338 <-> gitlab.com:80 dialer=CM_http dscp=0 ip=172.65.251.78:80 mac=48:21:0b:32:5f:4a network=tcp4 outbound=CM pid=0 pname=curl policy=fixed sniffed=gitlab.com


# for gitlab.company
[Jun 26 19:33:08] TRACE Received UDP(DNS) 192.168.50.237:45882 <-> 192.168.50.1:53: gitlab.company. A
[Jun 26 19:33:08] TRACE Request to DNS upstream question=[{Name:gitlab.company. Qtype:1 Qclass:1}] upstream=tcp+udp://dns.google.com:53
[Jun 26 19:33:08] TRACE Choose DNS path choose=tcp+4 ipversions=[4 6] l4protos=[udp tcp] upstream=tcp+udp://dns.google.com:53 use=8.8.8.8:53
[Jun 26 19:33:08] TRACE Received UDP(DNS) 192.168.50.237:60972 <-> 192.168.50.1:53: gzdata1.fc-smartserver.xyz. A
[Jun 26 19:33:08] TRACE Received UDP(DNS) 192.168.50.237:57314 <-> 192.168.50.1:53: gzdata1.fc-smartserver.xyz. AAAA
[Jun 26 19:33:08] DEBUG UDP(DNS) 192.168.50.237:60972 <-> Cache: gzdata1.fc-smartserver.xyz. A
[Jun 26 19:33:08] DEBUG UDP(DNS) 192.168.50.237:57314 <-> Cache: gzdata1.fc-smartserver.xyz. AAAA
[Jun 26 19:33:08] TRACE Accept question=[{Name:gitlab.company. Qtype:1 Qclass:1}] upstream=tcp+udp://dns.google.com:53
[Jun 26 19:33:08]  INFO 192.168.50.237:45882 <-> 8.8.8.8:53 _qname=gitlab.company. dialer=香港标准 IEPL 中继 5 dscp=0 mac=48:21:0b:32:5f:4a network=tcp4(DNS) outbound=HK pid=711 pname=tailscaled policy=min_moving_avg qtype=A

[Jun 26 19:33:08] TRACE Received UDP(DNS) 192.168.50.237:52284 <-> 192.168.50.1:53: gitlab.company. AAAA
[Jun 26 19:33:08] TRACE Request to DNS upstream question=[{Name:gitlab.company. Qtype:28 Qclass:1}] upstream=tcp+udp://dns.google.com:53
[Jun 26 19:33:08] TRACE Choose DNS path choose=tcp+4 ipversions=[4 6] l4protos=[udp tcp] upstream=tcp+udp://dns.google.com:53 use=8.8.8.8:53
[Jun 26 19:33:08] TRACE Received UDP(DNS) 192.168.50.237:55406 <-> 192.168.50.1:53: gzdata1.fc-smartserver.xyz. AAAA
[Jun 26 19:33:08] TRACE Received UDP(DNS) 192.168.50.237:54051 <-> 192.168.50.1:53: gzdata1.fc-smartserver.xyz. A
[Jun 26 19:33:08] DEBUG UDP(DNS) 192.168.50.237:55406 <-> Cache: gzdata1.fc-smartserver.xyz. AAAA
[Jun 26 19:33:08] DEBUG UDP(DNS) 192.168.50.237:54051 <-> Cache: gzdata1.fc-smartserver.xyz. A
[Jun 26 19:33:08] TRACE Accept question=[{Name:gitlab.company. Qtype:28 Qclass:1}] upstream=tcp+udp://dns.google.com:53
[Jun 26 19:33:08]  INFO 192.168.50.237:52284 <-> 8.8.8.8:53 _qname=gitlab.company. dialer=香港标准 IEPL 中继 5 dscp=0 mac=48:21:0b:32:5f:4a network=tcp4(DNS) outbound=HK pid=711 pname=tailscaled policy=min_moving_avg qtype=AAAA

对 gitlab.com, 有三行很不一样:

[Jun 26 19:32:00] TRACE Update DNS record cache _qname=gitlab.com. ans=gitlab.com.(A): 172.65.251.78 rcode=0
[Jun 26 19:32:00] TRACE Update DNS record cache _qname=gitlab.com. ans=gitlab.com.(A): 172.65.251.78 rcode=0
[Jun 26 19:32:00] TRACE Update DNS record cache _qname=gitlab.com. ans=gitlab.com.(AAAA): 2606:4700:90:0:f22e:fbec:5bed:a9b9 rcode=0
[Jun 26 19:32:00] DEBUG Rewrite dial target to domain from=172.65.251.78:80 to=gitlab.com:80

这之后就成功应用到了那个CM了:

[Jun 26 19:32:00]  INFO 192.168.50.237:42338 <-> gitlab.com:80 dialer=CM_http dscp=0 ip=172.65.251.78:80 mac=48:21:0b:32:5f:4a network=tcp4 outbound=CM pid=0 pname=curl policy=fixed sniffed=gitlab.com

但是 gitlab.company,没有 TRACE Update相关的 log, 能看出来什么问题么?

@marsjane
Copy link
Author

这个看起来是 sniffed 为空,所以 routing 没有生效

哦哦哦那这个应该怎么弄啊?

@mzz2017
Copy link
Contributor

mzz2017 commented Jun 26, 2024

看起来并没有“Update DNS record cache _qname=gitlab.company” 相关的字样,猜测这个域名应该交给一个内网 dns 才能解析出结果,你可以添加一个可以解析该域名的 dns upstream,对这个域名转发到该 dns 进行查询

@marsjane
Copy link
Author

感觉是这样了!以前在别的工具里面我用的这个是没问题的:

  default-nameserver:
    - 223.5.5.5
  nameserver:
    - tls://8.8.4.4
    - tls://1.1.1.1
  nameserver-policy:
    "geosite:cn,private":
      - https://doh.pub/dns-query
      - https://dns.alidns.com/dns-query

这个不知道怎么转换过来呢 我看tls和https似乎都还不支持?我试了一下用tcp+udp://223.5.5.5:53,然后加了个条件,确实走了这个DNS,但是好像也没解析出来:

[Jun 26 22:26:45]  INFO 192.168.50.237:42647 <-> 223.5.5.5:53 _qname=gitlab.company. dialer=direct dscp=0 mac=48:21:0b:32:5f:4a network=udp4(DNS) outbound=direct pid=711 pname=tailscaled policy=fixed qtype=A
[Jun 26 22:26:45] TRACE Received UDP(DNS) 192.168.50.237:42466 <-> 192.168.50.1:53: gitlab.company. AAAA
[Jun 26 22:26:45] TRACE Request to DNS upstream question=[{Name:gitlab.company. Qtype:28 Qclass:1}] upstream=tcp+udp://223.5.5.5:53
[Jun 26 22:26:45] TRACE Choose DNS path choose=udp+4 ipversions=[4] l4protos=[udp tcp] upstream=tcp+udp://223.5.5.5:53 use=223.5.5.5:53
[Jun 26 22:26:45] TRACE Accept question=[{Name:gitlab.company. Qtype:28 Qclass:1}] upstream=tcp+udp://223.5.5.5:53
[Jun 26 22:26:45]  INFO 192.168.50.237:42466 <-> 223.5.5.5:53 _qname=gitlab.company. dialer=direct dscp=0 mac=48:21:0b:32:5f:4a network=udp4(DNS) outbound=direct pid=711 pname=tailscaled policy=fixed qtype=AAAA
TRAC[0042] sniffUdp                                      error="sniffing error: not applicable" from="192.168.50.237:39502" to="50.7.252.138:9993"

这方面我着实不太懂,有没有什么建议的dns upstream呀?

@mzz2017
Copy link
Contributor

mzz2017 commented Jun 26, 2024

@marsjane dns routing 里用 qname(suffix:gitlab.company)->asis

@marsjane
Copy link
Author

asis需要定义么?我目前加的是ali: 'tcp+udp://223.5.5.5:53' qname(keyword:company) -> ali

@mzz2017
Copy link
Contributor

mzz2017 commented Jun 26, 2024

@marsjane 不用定义。asis就是请求的时候用什么就用什么,上述就是去用 192.168.50.1:53,你可以验证 dig gitlab.company @192.168.50.1 看看有没有结果

@mzz2017
Copy link
Contributor

mzz2017 commented Jun 26, 2024

@marsjane 在 dae 关闭的情况下 dig 测试

@marsjane
Copy link
Author

marsjane commented Jun 26, 2024

这个dig确实没问题,我按照你说的试了,确实它走的是192.168.50.1:53,但是好像依旧没有结果==

[Jun 26 22:47:19] TRACE Received UDP(DNS) 192.168.50.237:33241 <-> 192.168.50.1:53: gitlab.company.
[Jun 26 22:47:19] TRACE Request to DNS upstream question=[{Name:gitlab.company. Qtype:1 Qclass:1}] upstream=asis
[Jun 26 22:47:19] TRACE Choose DNS path choose=udp+4 ipversions=[4] l4protos=[udp] upstream=udp://192.168.50.1:53 use=192.168.50.1:53
[Jun 26 22:47:19] TRACE Accept question=[{Name:gitlab.company. Qtype:1 Qclass:1}] upstream=asis
[Jun 26 22:47:19]  INFO 192.168.50.237:33241 <-> 192.168.50.1:53 _qname=gitlab.company. dialer=direct dscp=0 mac=48:21:0b:32:5f:4a network=udp4(DNS) outbound=direct pid=711 pname=tailscaled policy=fixed qtype=A
[Jun 26 22:47:19] TRACE Received UDP(DNS) 192.168.50.237:52313 <-> 192.168.50.1:53: gitlab.company. AAAA
[Jun 26 22:47:19] TRACE Request to DNS upstream question=[{Name:gitlab.company. Qtype:28 Qclass:1}] upstream=asis
[Jun 26 22:47:19] TRACE Choose DNS path choose=udp+4 ipversions=[4] l4protos=[udp] upstream=udp://192.168.50.1:53 use=192.168.50.1:53
[Jun 26 22:47:19] TRACE Accept question=[{Name:gitlab.company. Qtype:28 Qclass:1}] upstream=asis
[Jun 26 22:47:19]  INFO 192.168.50.237:52313 <-> 192.168.50.1:53 _qname=gitlab.company. dialer=direct dscp=0 mac=48:21:0b:32:5f:4a network=udp4(DNS) outbound=direct pid=711 pname=tailscaled policy=fixed qtype=AAAA
[Jun 26 22:47:19] TRACE Update DNS record cache _qname=gitlab.company. ans= rcode=0

为啥dig可以这里又不可以了呢

@marsjane
Copy link
Author

好像是update DNS record cache有了但是还是没有Rewrite dial target to domain,反正我curl -I 的命令显示的是curl: (6) Could not resolve host: gitlab.company

@linglilongyi
Copy link
Contributor

这个update DNS record cache里面没有answer,所以问题应该在192.168.50.1上?

@marsjane
Copy link
Author

这个update DNS record cache里面没有answer,所以问题应该在192.168.50.1上?

那还有什么方式可以不用这个192.168.50.1么?为啥我上面提到的别的软件的那种设置是可以的?不知道那个是通过什么dns完成的

@linglilongyi

This comment was marked as outdated.

@mzz2017
Copy link
Contributor

mzz2017 commented Jun 27, 2024

我收到了你的邮件,看起来手动 dig 也是没有 a/aaaa 记录的,http 代理可以是因为直接发送了域名到远端。
在 fakeip 的场景下这个问题可能会被规避,这可能是你的 clash 可以使用的原因。
现在首先要解决你无法解析域名的问题,这大概率是因为你的域名在内网域名服务器上,你可以如下操作:

  1. 到 company 的节点机上查看公司 dns ip 并将其设为 dae 的一个 upstream
  2. 将 qname(keyword: company) -> 该 upstream
  3. 将 dip(这个 dns ip) -> company 节点
  4. 将 domain(keyword: company) -> company 节点

@marsjane
Copy link
Author

好的,多谢两位,我试一下!话说如何看公司dns ip啊,我去内部机器上看了/etc/resolv.conf,里面是nameserver 127.0.0.53

@mzz2017
Copy link
Contributor

mzz2017 commented Jun 27, 2024

@marsjane 直接 tcpdump -i any dst port 53 -n 然后新开个终端 nslookup 看看目标地址是多少(有可能有缓存,等缓存结束之后再测)

@mzz2017
Copy link
Contributor

mzz2017 commented Jun 27, 2024

@marsjane 另一个方法是 lsof -i:53 看看监听 53 的进程是谁,找到对应的配置文件看看上游 dns 是多少

@marsjane
Copy link
Author

tcpdump我似乎没有权限执行 我不是管理员,那个lsod -i :53我跑了一下 啥输出也没有,感觉不知道是不是也是权限不足所以看不到

@mzz2017
Copy link
Contributor

mzz2017 commented Jun 27, 2024

@marsjane 1. 问问公司 dns 服务器是多少

  1. 自己电脑或者笔记本连上公司内网之后看看是多少
  2. 无非就是 systemd-networkd / NetworkManager / dnsmasq,挨个找找

@mzz2017
Copy link
Contributor

mzz2017 commented Jun 27, 2024

@marsjane 哦对了,127.0.0.53也没关系,可以直接当成 upstream
xxxx: 'udp://127.0.0.53:53'

@marsjane
Copy link
Author

'udp://127.0.0.53:53', 以及nmcli device show | grep IP4.DNS输出的,还有for ns in $(dig +short NS gitlab.company); do dig +short A $ns; done输出出来的我全试了一遍,都不行==感觉可能我这个场景也比较奇怪吧,也许比较难搞

@mzz2017
Copy link
Contributor

mzz2017 commented Jun 27, 2024

@marsjane 你要按照上面我说的那几个步骤,不能单加个 upstream。
使用 127.0.0.53 并要通过代理转发才行,为了避免这个直连,所以路由里这个 dip 规则要很靠前

@marsjane
Copy link
Author

我目前这么设置的对不:

cm: 'udp://127.0.0.53:53'
qname(keyword:company) -> cm


# 放在了第一行
dip(127.0.0.53) -> CM
domain(keyword: company) -> CM

然后它的报错是:

[Jun 27 23:10:06] TRACE Choose DNS path choose=udp+4 ipversions=[4] l4protos=[udp] upstream=udp://127.0.0.53:53 use=127.0.0.53:53
[Jun 27 23:10:06]  WARN handlePkt: failed to dial '127.0.0.53:53': unknown network unsupported tunnel type

不过我也确实没看到127.0.0.53走我这个CM节点的log,好像dip(127.0.0.53) -> CM也确实没有生效?

@marsjane
Copy link
Author

@mzz2017 所以为啥dip(127.0.0.53) -> CM这个没有生效呢?我感觉你说的方法确实合理 就是不知道为啥127.0.0.53的时候没有调用过去, 感觉这个报错failed to dial '127.0.0.53:53': unknown network unsupported tunnel type就是这个原因吧?

@mzz2017 mzz2017 reopened this Jun 28, 2024
@mzz2017
Copy link
Contributor

mzz2017 commented Jun 28, 2024

发一下比较全的配置?

@marsjane
Copy link
Author

global {
    tproxy_port: 7888
    tproxy_port_protect: true
    pprof_port: 0
    so_mark_from_dae: 0
    log_level: trace
    disable_waiting_network: false
    enable_local_tcp_fast_redirect: false
    wan_interface: auto
    auto_config_kernel_parameter: true
    tcp_check_url: 'http://cp.cloudflare.com,1.1.1.1,2606:4700:4700::1111'
    tcp_check_http_method: HEAD
    udp_check_dns: 'dns.google.com:53,8.8.8.8,2001:4860:4860::8888'
    check_interval: 600s
    check_tolerance: 50ms
    dial_mode: domain
    allow_insecure: false
    sniffing_timeout: 100ms
    tls_implementation: tls
    utls_imitate: chrome_auto
}
# Subscriptions defined here will be resolved as nodes and merged as a part of the global node pool.
# Support to give the subscription a tag, and filter nodes from a given subscription in the group section.
subscription {
    # Add your subscription links here.
    aa: ''
}

# Nodes defined here will be merged as a part of the global node pool.
node {
    CM_http: 'http://127.0.0.1:8843'
}

# See https://github.com/daeuniverse/dae/blob/main/docs/en/configuration/dns.md for full examples.
dns {
    upstream {
        cm: 'udp://127.0.0.53:53'
        alidns: 'udp://dns.alidns.com:53'
        googledns: 'tcp+udp://dns.google.com:53'
    }
    routing {
        # According to the request of dns query, decide to use which DNS upstream.
        # Match rules from top to bottom.
        request {
            # Lookup China mainland domains using alidns, otherwise googledns.
            qname(keyword:company) -> cm
            qname(geosite:cn) -> alidns
            # fallback is also called default.
            fallback: googledns
        }
    }
}

# Node group (outbound).
group {
    HK {
        # No filter. Use all nodes.

        # Randomly select a node from the group for every connection.
        #policy: random

        # Select the first node from the group for every connection.
        #policy: fixed(0)

        # Select the node with min last latency from the group for every connection.
        #policy: min

        # Select the node with min moving average of latencies from the group for every connection.
        filter: name(keyword:'香港标准')
        policy: min_moving_avg
    }
    CM {
       filter: name(CM_http)
       policy: fixed(0)
    }
}

# See https://github.com/daeuniverse/dae/blob/main/docs/en/configuration/routing.md for full examples.
routing {
    ### Preset rules.

    # Network managers in localhost should be direct to avoid false negative network connectivity check when binding to
    # WAN.
    dip(127.0.0.53) -> CM
    domain(keyword: company) -> CM
    domain(keyword: gitlab) -> CM
    pname(NetworkManager) -> direct

    # Put it in the front to prevent broadcast, multicast and other packets that should be sent to the LAN from being
    # forwarded by the proxy.
    # "dip" means destination IP.
    dip(224.0.0.0/3, 'ff00::/8') -> direct

    # This line allows you to access private addresses directly instead of via your proxy. If you really want to access
    # private addresses in your proxy host network, modify the below line.
    dip(geoip:private) -> direct

    ### Write your rules below.

    # Disable h3 because it usually consumes too much cpu/mem resources.
    l4proto(udp) && dport(443) -> block
    dip(geoip:cn) -> direct
    domain(geosite:cn) -> direct
    domain(geosite:category-ads) -> block

    fallback: HK
}

@xmapst
Copy link

xmapst commented Jun 28, 2024

global {
    tproxy_port: 7888
    tproxy_port_protect: true
    pprof_port: 0
    so_mark_from_dae: 0
    log_level: trace
    disable_waiting_network: false
    enable_local_tcp_fast_redirect: false
    wan_interface: auto
    auto_config_kernel_parameter: true
    tcp_check_url: 'http://cp.cloudflare.com,1.1.1.1,2606:4700:4700::1111'
    tcp_check_http_method: HEAD
    udp_check_dns: 'dns.google.com:53,8.8.8.8,2001:4860:4860::8888'
    check_interval: 600s
    check_tolerance: 50ms
    dial_mode: domain
    allow_insecure: false
    sniffing_timeout: 100ms
    tls_implementation: tls
    utls_imitate: chrome_auto
}
# Subscriptions defined here will be resolved as nodes and merged as a part of the global node pool.
# Support to give the subscription a tag, and filter nodes from a given subscription in the group section.
subscription {
    # Add your subscription links here.
    aa: ''
}

# Nodes defined here will be merged as a part of the global node pool.
node {
    CM_http: 'http://127.0.0.1:8843'
}

# See https://github.com/daeuniverse/dae/blob/main/docs/en/configuration/dns.md for full examples.
dns {
    upstream {
        cm: 'udp://127.0.0.53:53'
        alidns: 'udp://dns.alidns.com:53'
        googledns: 'tcp+udp://dns.google.com:53'
    }
    routing {
        # According to the request of dns query, decide to use which DNS upstream.
        # Match rules from top to bottom.
        request {
            # Lookup China mainland domains using alidns, otherwise googledns.
            qname(keyword:company) -> cm
            qname(geosite:cn) -> alidns
            # fallback is also called default.
            fallback: googledns
        }
    }
}

# Node group (outbound).
group {
    HK {
        # No filter. Use all nodes.

        # Randomly select a node from the group for every connection.
        #policy: random

        # Select the first node from the group for every connection.
        #policy: fixed(0)

        # Select the node with min last latency from the group for every connection.
        #policy: min

        # Select the node with min moving average of latencies from the group for every connection.
        filter: name(keyword:'香港标准')
        policy: min_moving_avg
    }
    CM {
       filter: name(CM_http)
       policy: fixed(0)
    }
}

# See https://github.com/daeuniverse/dae/blob/main/docs/en/configuration/routing.md for full examples.
routing {
    ### Preset rules.

    # Network managers in localhost should be direct to avoid false negative network connectivity check when binding to
    # WAN.
    dip(127.0.0.53) -> CM
    domain(keyword: company) -> CM
    domain(keyword: gitlab) -> CM
    pname(NetworkManager) -> direct

    # Put it in the front to prevent broadcast, multicast and other packets that should be sent to the LAN from being
    # forwarded by the proxy.
    # "dip" means destination IP.
    dip(224.0.0.0/3, 'ff00::/8') -> direct

    # This line allows you to access private addresses directly instead of via your proxy. If you really want to access
    # private addresses in your proxy host network, modify the below line.
    dip(geoip:private) -> direct

    ### Write your rules below.

    # Disable h3 because it usually consumes too much cpu/mem resources.
    l4proto(udp) && dport(443) -> block
    dip(geoip:cn) -> direct
    domain(geosite:cn) -> direct
    domain(geosite:category-ads) -> block

    fallback: HK
}

pname(NetworkManager) -> direct 改成 pname(NetworkManager,systemd-resolved) -> direct 试试

因为127.0.0.53:53是systemd-resolved

@marsjane
Copy link
Author

啊试了一下,还是一样的报错WARN handlePkt: failed to dial '127.0.0.53:53': unknown network unsupported tunnel type

@mzz2017
Copy link
Contributor

mzz2017 commented Jun 28, 2024

@marsjane 感觉没什么问题,我得抽空复现一下

@marsjane
Copy link
Author

谢谢!

@mzz2017
Copy link
Contributor

mzz2017 commented Jun 28, 2024

@marsjane 你的 node 是 http 的,不支持 udp,有两个解决方案:

  1. 使用 socks5
  2. 不确定上游 dns 是否支持 tcp,upstream 可以改为 tcp://127.0.0.53:53 试试

@mzz2017 mzz2017 changed the title [Feature Request] About the config files location and permission instruction [Feature Request] Connect to company network Jun 28, 2024
@marsjane
Copy link
Author

啊tcp可以了!多谢!!

@IceCodeNew
Copy link

好巧,我也是遇到了节点为 https proxy 时,dns 设置 udp 会报错的情况,没想到刚过来搜 issue 就找到解决方案了哈哈

@marsjane
Copy link
Author

那属实缘分,感谢 @mzz2017 和其他几位不厌其烦帮忙debug!期待一下 #567

@marsjane
Copy link
Author

marsjane commented Jul 2, 2024

hi @mzz2017 , 这个办法确实我可以上内部网站了 但是似乎还是会遇到一些问题 就是一些操作的话发送回网站好像会有问题,不知道这个log是什么意思,大概就是我在网站上进行一个提交 就会卡住,也不太清楚是卡在哪里了

dae[21115]: level=warning msg="handleConn: handleTCP relay error: read tcp 127.0.0.1:58886->127.0.0.1:8843: i/o timeout: readfrom tcp 127.0.0.1:58886->127.0.0.1:8843: unexpected EOF"

@marsjane marsjane reopened this Jul 2, 2024
@marsjane
Copy link
Author

marsjane commented Jul 3, 2024

现在发现一些诸如上传文件之类的操作也一样是报上面这个错,正常的浏览都没问题

@mzz2017
Copy link
Contributor

mzz2017 commented Jul 3, 2024

  1. 你的8843是什么服务开出来的?那边的相关日志是什么?
  2. 对应的请求在浏览器中的错误码是多少?
  3. 对应的请求域名是多少,在 dae 里有对应配置吗?

@marsjane
Copy link
Author

marsjane commented Jul 4, 2024

  1. 这个端口是一个别的机器上开出的一个服务,具体是什么我也不清楚,但是显示是一个内部域名的3128端口,我通过ssh连接,然后将这个端口映射到本地的8843端口
  2. 这些出问题的请求在浏览器上只是表现为全白,然后停住不动,我看了看网页的一些log显示如下:
Error: Network Error
    at createError (main-894722d4a4b691b673db.cc3f71b27a89.js:84752:16)
    at XMLHttpRequest.handleError (main-894722d4a4b691b673db.cc3f71b27a89.js:84605:15)

Uncaught TypeError: Cannot read properties of undefined (reading 'data')
    at main-894722d4a4b691b673db.cc3f71b27a89.js:229841:39
    at invokePassiveEffectCreate (main-894722d4a4b691b673db.cc3f71b27a89.js:28036:21)
    at HTMLUnknownElement.callCallback (main-894722d4a4b691b673db.cc3f71b27a89.js:8494:15)
    at Object.invokeGuardedCallbackDev (main-894722d4a4b691b673db.cc3f71b27a89.js:8543:17)
    at invokeGuardedCallback (main-894722d4a4b691b673db.cc3f71b27a89.js:8605:32)
    at flushPassiveEffectsImpl (main-894722d4a4b691b673db.cc3f71b27a89.js:28123:10)
    at unstable_runWithPriority (main-894722d4a4b691b673db.cc3f71b27a89.js:4364:13)
    at runWithPriority$1 (main-894722d4a4b691b673db.cc3f71b27a89.js:15825:11)
    at flushPassiveEffects (main-894722d4a4b691b673db.cc3f71b27a89.js:27996:15)
    at performSyncWorkOnRoot (main-894722d4a4b691b673db.cc3f71b27a89.js:26818:4)


The above error occurred in the <NewDeployment> component:

    at NewDeployment (http://deploy.company:7999/static/main-894722d4a4b691b673db.cc3f71b27a89.js:229748:36)
    at Route (http://deploy.company:7999/static/main-894722d4a4b691b673db.cc3f71b27a89.js:67101:6)
    at Switch (http://deploy.company:7999/static/main-894722d4a4b691b673db.cc3f71b27a89.js:68299:6)
    at div
    at Container (http://deploy.company:7999/static/main-894722d4a4b691b673db.cc3f71b27a89.js:69409:26)
    at main
    at div
    at div
    at DefaultLayout (http://deploy.company:7999/static/main-894722d4a4b691b673db.cc3f71b27a89.js:68929:6)
    at ComposedComponent (http://deploy.company:7999/static/main-894722d4a4b691b673db.cc3f71b27a89.js:290627:8)
    at Route (http://deploy.company:7999/static/main-894722d4a4b691b673db.cc3f71b27a89.js:67101:6)
    at C (http://deploy.company:7999/static/main-894722d4a4b691b673db.cc3f71b27a89.js:68438:38)
    at Connect (http://deploy.company:7999/static/main-894722d4a4b691b673db.cc3f71b27a89.js:32574:10)
    at Route (http://deploy.company:7999/static/main-894722d4a4b691b673db.cc3f71b27a89.js:67101:6)
    at Switch (http://deploy.company:7999/static/main-894722d4a4b691b673db.cc3f71b27a89.js:68299:6)
    at Router (http://deploy.company:7999/static/main-894722d4a4b691b673db.cc3f71b27a89.js:66575:6)
    at BrowserRouter (http://deploy.company:7999/static/main-894722d4a4b691b673db.cc3f71b27a89.js:65221:6)
    at App (http://deploy.company:7999/static/main-894722d4a4b691b673db.cc3f71b27a89.js:65071:6)
    at Provider (http://deploy.company:7999/static/main-894722d4a4b691b673db.cc3f71b27a89.js:31283:8)

Consider adding an error boundary to your tree to customize error handling behavior.
Visit https://reactjs.org/link/error-boundaries to learn more about error boundaries.
  1. 这个域名是没问题的我可以访问,只是里面的一个操作<NewDeployment>好像会有bug,不过clash没问题,另外我去问了可能会用到的一些内部ip,我全加载routing里面了,但是好像也还是没有用。

emm这个看不到服务端的日志要是无法debug的话那也没事,我现在暂时先用其他软件代替着用吧,感觉确实是特殊需求

@marsjane marsjane closed this as completed Jul 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

6 participants