[Feature Request] Connect to company network #565

marsjane · 2024-06-25T06:03:07Z

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:

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?
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

The text was updated successfully, but these errors were encountered:

dae-prow · 2024-06-25T06:03:12Z

Thanks for opening this issue!

mzz2017 · 2024-06-25T06:57:03Z

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.
0600 is recommended due to security consideration, which is the same reason as .ssh/id_rsa

marsjane · 2024-06-25T07:39:11Z

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 · 2024-06-25T08:00:11Z

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 · 2024-06-25T09:00:06Z

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

marsjane · 2024-06-25T09:23:05Z

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 · 2024-06-25T16:54:59Z

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

marsjane · 2024-06-26T02:00:48Z

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 · 2024-06-26T02:03:35Z

I'll look into it.

marsjane · 2024-06-26T02:05:05Z

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

KuGouGo · 2024-06-26T10:54:38Z

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

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

mzz2017 · 2024-06-26T11:09:57Z

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

marsjane · 2024-06-26T11:47:04Z

刚刚试了一下加了空格:

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 · 2024-06-26T11:52:05Z

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

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

mzz2017 · 2024-06-26T14:02:59Z

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

marsjane · 2024-06-26T14:31:04Z

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

  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 · 2024-06-26T14:33:23Z

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

marsjane · 2024-06-26T14:36:13Z

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

mzz2017 · 2024-06-26T14:40:38Z

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

mzz2017 · 2024-06-26T14:41:43Z

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

marsjane · 2024-06-26T14:51:21Z

这个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 · 2024-06-26T15:06:37Z

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

linglilongyi · 2024-06-27T01:43:15Z

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

marsjane · 2024-06-27T02:22:46Z

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

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

mzz2017 · 2024-06-27T06:08:50Z

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

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

marsjane · 2024-06-27T06:20:51Z

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

mzz2017 · 2024-06-27T09:48:45Z

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

mzz2017 · 2024-06-27T09:49:29Z

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

marsjane · 2024-06-27T10:22:23Z

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

mzz2017 · 2024-06-27T13:51:09Z

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

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

mzz2017 · 2024-06-27T13:52:02Z

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

marsjane · 2024-06-27T14:46:04Z

'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 · 2024-06-27T14:56:54Z

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

marsjane · 2024-06-27T15:11:58Z

我目前这么设置的对不：

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 · 2024-06-28T06:37:21Z

@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 · 2024-06-28T06:41:34Z

发一下比较全的配置？

marsjane · 2024-06-28T06:50:53Z

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 · 2024-06-28T07:05:19Z

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 · 2024-06-28T07:13:03Z

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

mzz2017 · 2024-06-28T09:35:06Z

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

marsjane · 2024-06-28T09:49:04Z

谢谢！

mzz2017 · 2024-06-28T10:38:10Z

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

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

marsjane · 2024-06-28T11:52:52Z

啊tcp可以了！多谢！！

IceCodeNew · 2024-06-28T13:28:31Z

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

marsjane · 2024-06-28T14:00:02Z

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

marsjane · 2024-07-02T01:24:55Z

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 · 2024-07-03T08:19:25Z

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

mzz2017 · 2024-07-03T16:28:44Z

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

marsjane · 2024-07-04T09:18:27Z

这个端口是一个别的机器上开出的一个服务，具体是什么我也不清楚，但是显示是一个内部域名的3128端口，我通过ssh连接，然后将这个端口映射到本地的8843端口
这些出问题的请求在浏览器上只是表现为全白，然后停住不动，我看了看网页的一些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.

这个域名是没问题的我可以访问，只是里面的一个操作<NewDeployment>好像会有bug，不过clash没问题，另外我去问了可能会用到的一些内部ip，我全加载routing里面了，但是好像也还是没有用。

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

marsjane added the topic/feature label Jun 25, 2024

mzz2017 added help wanted Extra attention is needed and removed topic/feature labels Jun 25, 2024

This comment was marked as outdated.

Sign in to view

marsjane closed this as completed Jun 27, 2024

mzz2017 reopened this Jun 28, 2024

mzz2017 changed the title ~~[Feature Request] About the config files location and permission instruction~~ [Feature Request] Connect to company network Jun 28, 2024

marsjane closed this as completed Jun 28, 2024

mzz2017 mentioned this issue Jun 28, 2024

[Proposal] 支持 DNS Upstream "fake" #567

Open

marsjane reopened this Jul 2, 2024

marsjane closed this as completed Jul 8, 2024

[Feature Request] Connect to company network #565

[Feature Request] Connect to company network #565

Comments

marsjane commented Jun 25, 2024 • edited Loading

Greetings

Feature Request

Use Cases

Potential Benefits

dae-prow bot commented Jun 25, 2024

mzz2017 commented Jun 25, 2024 • edited Loading

marsjane commented Jun 25, 2024

marsjane commented Jun 25, 2024

mzz2017 commented Jun 25, 2024

marsjane commented Jun 25, 2024

mzz2017 commented Jun 25, 2024

marsjane commented Jun 26, 2024

mzz2017 commented Jun 26, 2024

marsjane commented Jun 26, 2024

KuGouGo commented Jun 26, 2024

mzz2017 commented Jun 26, 2024

marsjane commented Jun 26, 2024 • edited Loading

marsjane commented Jun 26, 2024

mzz2017 commented Jun 26, 2024

marsjane commented Jun 26, 2024

mzz2017 commented Jun 26, 2024

marsjane commented Jun 26, 2024

mzz2017 commented Jun 26, 2024

mzz2017 commented Jun 26, 2024

marsjane commented Jun 26, 2024 • edited Loading

marsjane commented Jun 26, 2024

linglilongyi commented Jun 27, 2024

marsjane commented Jun 27, 2024

This comment was marked as outdated.

mzz2017 commented Jun 27, 2024 • edited Loading

marsjane commented Jun 27, 2024

mzz2017 commented Jun 27, 2024

mzz2017 commented Jun 27, 2024

marsjane commented Jun 27, 2024

mzz2017 commented Jun 27, 2024

mzz2017 commented Jun 27, 2024 • edited Loading

marsjane commented Jun 27, 2024

mzz2017 commented Jun 27, 2024

marsjane commented Jun 27, 2024

marsjane commented Jun 28, 2024

mzz2017 commented Jun 28, 2024

marsjane commented Jun 28, 2024

xmapst commented Jun 28, 2024

marsjane commented Jun 28, 2024

mzz2017 commented Jun 28, 2024

marsjane commented Jun 28, 2024

mzz2017 commented Jun 28, 2024 • edited Loading

marsjane commented Jun 28, 2024

IceCodeNew commented Jun 28, 2024

marsjane commented Jun 28, 2024

marsjane commented Jul 2, 2024

marsjane commented Jul 3, 2024

mzz2017 commented Jul 3, 2024

marsjane commented Jul 4, 2024

marsjane commented Jun 25, 2024 •

edited

Loading

mzz2017 commented Jun 25, 2024 •

edited

Loading

marsjane commented Jun 26, 2024 •

edited

Loading

marsjane commented Jun 26, 2024 •

edited

Loading

mzz2017 commented Jun 27, 2024 •

edited

Loading

mzz2017 commented Jun 27, 2024 •

edited

Loading

mzz2017 commented Jun 28, 2024 •

edited

Loading