[Bug Report] HTTPS PROXY 无法正常工作
IceCodeNew opened this issue · comments
Checks
- I have searched the existing issues
- I have read the documentation
- Is it your first time sumbitting an issue
Current Behavior
Jun 28 22:45:27 vm-ubuntu daed[7315]: time="Jun 28 22:45:27" level=debug msg="Connectivity Check Failed" err="unknown network unsupported tunnel type" network="udp4(DNS)" node=tt
Jun 28 22:45:27 vm-ubuntu daed[7315]: time="Jun 28 22:45:27" level=debug msg="Connectivity Check Failed" err="unknown network unsupported tunnel type" network="udp6(DNS)" node=tt
Jun 28 22:45:27 vm-ubuntu daed[7315]: time="Jun 28 22:45:27" level=debug msg="Connectivity Check Failed" err="Head "http://cp.cloudflare.com": h2ConnsPool.GetClientConn: unknown tls implementati
on: " network=tcp4 node=tt
Jun 28 22:45:27 vm-ubuntu daed[7315]: time="Jun 28 22:45:27" level=debug msg="Connectivity Check Failed" err="h2ConnsPool.GetClientConn: unknown tls implementation: " network="tcp4(DNS)" node=tt
Jun 28 22:45:27 vm-ubuntu daed[7315]: time="Jun 28 22:45:27" level=debug msg="Connectivity Check Failed" err="h2ConnsPool.GetClientConn: unknown tls implementation: " network="tcp6(DNS)" node=tt
Jun 28 22:45:27 vm-ubuntu daed[7315]: time="Jun 28 22:45:27" level=debug msg="Connectivity Check Failed" err="Head "http://cp.cloudflare.com": h2ConnsPool.GetClientConn: unknown tls implementati
on: " network=tcp6 node=tt
Expected Behavior
在其他代理软件上验证了节点是可以链接的,期望的行为是 https proxy 节点可以通过 dae 的健康检查
Steps to Reproduce
tt 是 https proxy 节点添加到 dae 时起的识别名称,节点链接如下:
https://user:abcd1234-1b34-4c2a-1234-1234abcd7890@101.6.6.6:8443?sni=dns.tuna.tsinghua.edu.cn#🇭🇰 HK-4
要复现该问题,请
- 将以上节点添加到 dae 中
- 调整 dae 的日志级别到 trace 级别
- 观察 tt 节点的健康检查结果
- 执行
curl --proxytunnel --proxy-user 'user:abcd1234-1b34-4c2a-1234-1234abcd7890' --proxy 'https://dns.tuna.tsinghua.edu.cn:8443/' --resolve 'dns.tuna.tsinghua.edu.cn:8443:101.6.6.6' -vvv -- ipinfo.io
,确认以上节点链接虽然经过脱敏,但其实是可以正确建立 https 连接的。日志中如果看到对 "http://cp.cloudflare.com" 返回 40x 错误,说明当前 bug 已经解决
Environment
- Dae version (use
dae --version
):
daed version v0.6.0
dae version v0.6.0
go runtime go1.22.3 linux/amd64
Copyright (c) 2022-2024 @daeuniverse
License GNU AGPLv3 <https://github.com/daeuniverse/dae/blob/main/LICENSE>
- OS (e.g
cat /etc/os-release
):
PRETTY_NAME="Ubuntu 22.04.4 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.4 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy
- Kernel (e.g.
uname -a
):
Linux vm-ubuntu 5.15.0-113-generic #123-Ubuntu SMP Mon Jun 10 08:16:17 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
- Others:
Anything else?
根据错误日志定位到代码
https://github.com/daeuniverse/outbound/blob/152a72fc0e782fc8b519b592317cfde673b71ea6/transport/tls/tls.go#L121
说明建立代理连接中途 s.tlsImplentation
被置空了,但是翻了下 https proxy 的处理逻辑,感觉没有明显的问题。
出问题的环境上用的是 daed,没有找到导出完整配置的办法。因为虚拟机有命令审计,不方便用 delve 构建一个 debug 版的 daed 下断点,所以先把目前发现的信息整理一下提问
需要注意 HTTPS PROXY 节点使用了 443 以外的端口
Thanks for opening this issue!
配置
{
"id": "Y3Vyc29yMQ",
"name": "global",
"selected": true,
"global": {
"logLevel": "trace",
"tproxyPort": 12345,
"allowInsecure": false,
"checkInterval": "30s",
"checkTolerance": "50ms",
"lanInterface": [
"eth0"
],
"wanInterface": [
"auto"
],
"udpCheckDns": [
"dns.google.com:53",
"8.8.8.8",
"2001:4860:4860::8888"
],
"tcpCheckUrl": [
"http://cp.cloudflare.com",
"1.1.1.1",
"2606:4700:4700::1111"
],
"dialMode": "domain++",
"tcpCheckHttpMethod": "HEAD",
"disableWaitingNetwork": true,
"autoConfigKernelParameter": true,
"sniffingTimeout": "100ms",
"tlsImplementation": "tls",
"utlsImitate": "chrome_auto",
"tproxyPortProtect": true,
"soMarkFromDae": 415
}
}
DNS
upstream {
alidns: 'tcp://223.5.5.5:53'
control-d: 'tcp://76.76.2.0:53'
}
routing {
request {
qname(geosite:cn) -> alidns
fallback: control-d
}
}
路由
pname(NetworkManager, systemd-resolved, dnsmasq) -> must_direct
# 对应上面的 https proxy 节点 server
domain(suffix: www.baidu.com) -> must_direct
domain(geosite:cn) -> direct
l4proto(udp) && dport(123) -> must_direct
l4proto(udp) && dport(443) -> block
dip(geoip:private) -> direct
dip(geoip:cn) -> direct
fallback: proxy
节点
https://user:abcd1234-1b34-4c2a-1234-1234abcd7890@101.6.6.6:8443?sni=dns.tuna.tsinghua.edu.cn#🇭🇰 HK-4
试一下:#569
测试过了,没问题了~