- A+
FakeTLS,是将MTProto流被包装在标准HTTPS(第一条隧道协商消息)中,在该HTTPS中传输域(伪造)。在协商了MTProto协议-不使用Fake-TLS之后,流量便开始使用具有随机长度(dd-密钥)的常规MTProto协议。
之前配置过MTP的中转教程,数据通过KCP封装,经过UDP传输,会相对比本文的方式稳定可靠。
如需参考:通过KCP中转实现MTP代理(UDP) | Telegram实现稳定代理
本文是通过官方前不久更新出的fake tls功能实现的数据伪装,比原本的mtp协议更稳定。
事实上MTP官方程序原本就有两种代理方式一种是,无混淆;另外一种是增加随机字串,以防止数据包被ISP检测。
目前用到的就是第三种实现伪装tls传输数据,如果你还使用的旧版本的MTP代理,是没有这个功能的,建议重新编译后使用。
安装教程
On Debian/Ubuntu
1 |
[crayon-65c45c7809e93630834821 inline="true" class="language-bash"]apt install git curl build-essential libssl-dev zlib1g-dev |
[/crayon]
On CentOS/RHEL:
1 2 |
[crayon-65c45c7809e98818509452 inline="true" class="language-bash"]yum install openssl-devel zlib-devel yum groupinstall "Development Tools" |
[/crayon]
Clone the repo:
1 2 |
[crayon-65c45c7809e9b224789227 inline="true" class="language-bash"]git clone https://github.com/TelegramMessenger/MTProxy cd MTProxy |
[/crayon]
进行编译
执行make进行编译,生成的二进制文件在 objs/bin/mtproto-proxy
1 |
[crayon-65c45c7809ea2046597394 inline="true" ]make && cd objs/bin |
[/crayon]
如果你编译失败,可以执行make clean清理缓存,重新进行编译步骤。
运行使用
获取Telegram通信密匙
1 |
[crayon-65c45c7809ea5115033695 inline="true" class="language-bash"]curl -s https://core.telegram.org/getProxySecret -o proxy-secret |
[/crayon]
获取当前Telegram代理配置(官方建议每天更新此文件)
1 |
[crayon-65c45c7809ea9209536960 inline="true" class="language-bash"]curl -s https://core.telegram.org/getProxyConfig -o proxy-multi.conf |
[/crayon]
生成代理密匙
如果你没有安装head可以复制我以下所生成的,修改个别字符即可。
1 2 |
[crayon-65c45c7809ead434579554 inline="true" class="language-bash"][root@eller MTProxy]# head -c 16 /dev/urandom | xxd -ps 271082e5da56c2877f215c225eb93ffe |
[/crayon]
启动MTP服务端
1 |
[crayon-65c45c7809eb1098949554 inline="true" class="language-bash"]./mtproto-proxy -u nobody -p 8888 -H 443 -S 271082e5da56c2877f215c225eb93ffe --aes-pwd proxy-secret proxy-multi.conf -M 1 |
[/crayon]
启动成功后,客户连接配置:
端口:443,密匙:271082e5da56c2877f215c225eb93ffe
配置TLS
此时你根据上述命令默认运行的是不带有tls功能的。
在通过 ./mtproto-proxy --help 指令查看到指定tls传输的说明
1 2 |
[crayon-65c45c7809eb7215506234 inline="true" ]--domain/-D <arg> adds allowed domain for TLS-transport mode, disables other transports; can be specified more than once( 為TLS傳輸模式添加允許的域,禁用其他傳輸;可以多次指定) |
[/crayon]
此时,修改启动命令:
1 |
[crayon-65c45c7809ebb316995800 inline="true" class="language-bash"]./mtproto-proxy -u nobody -p 8888 -H 443-S 271082e5da56c2877f215c225eb93ffe --aes-pwd proxy-secret proxy-multi.conf -M 1 -D "www.google.com" |
[/crayon]
MTP的默认文档中没有说明客户端如何连接,我在issue中找到了客户端连接方式:
即其他参数不变,secret修改为如下字符串
ee+secret+domain的十六进制
可以通过python3生成
1 2 |
[crayon-65c45c7809ebf154042221 inline="true" class="language-bash"]>>> print ("ee"+"271082e5da56c2877f215c225eb93ffe"+"www.google.com".encode().hex()) ee271082e5da56c2877f215c225eb93ffe7777772e676f6f676c652e636f6d |
[/crayon]
注意:这个secret只是客户端这样拼接填写,服务端还是保持原始的密匙,即本文的:271082e5da56c2877f215c225eb93ffe
此时通过发现客户端还是无法连接通。
经过不断的反复尝试,发现Windows的TG可以连通,移动设备却不能使用。(如果你也有该现象,尝试更换代理域名、关闭本地代理工具)
尝试更改google域名为centos的,经过测试发现可以连通。猜测可能因为我本地google代理的问题,也可能是因为其他的的原因,目前没有测试,建议更改为无ban白名单的域名。
且最好是支持TLS1.3!也不是说不是tls1.3就不能用,只是因为mtp的协议伪装是按照tls1.3设计的,这样看起来会更友好一些。当然,我并没有在文档中找到相关的东西,代码也没有去研读,这些全是在issue里面所了解到的。
1 |
[crayon-65c45c7809ec3987664528 inline="true" ]./mtproto-proxy -u nobody -p 8888 -H 443-S 271082e5da56c2877f215c225eb93ffe --aes-pwd proxy-secret proxy-multi.conf -M 1 --domain www.centos.org |
[/crayon]
客户端连接信息:
IP:xx.xx.xx.xx (有人建议通过域名解析到IP,客户端填写域名,能有效避免ISP审查,该方式也没有大量测试,无法得出具体结果...)
secret:ee271082e5da56c2877f215c225eb93ffe7777772e63656e746f732e6f7267
port:443
供参考:Telegram为MTProto代理使用3种类型的密钥:
- 常规密钥(由DPI轻松确定)
- 前两个字母-dd-随机消息长度(DPI只能通过连接协商的第一个数据包来确定协议-然后看起来像普通的https / TLS) 密匙: dd+secret
- 前两个字母-ee-伪TLS +随机消息长度(DPI无法确定协议,第一个消息以及所有后续消息看起来像HTTPS / TLS)
密匙填写:
第一种是无混淆的即客户端密匙原模原样填写,无需变化。
第二种是有随机填充的,客户端需要在原始的密匙开头加上,如: dd+secret
第三种就是fake tls混淆,客户端需要再原始的密匙开头加上ee,还需要在密匙后面拼接域名的十六进制形式,如: ee+secret+domain_in_hex
在线转换十六进制:https://www.rapidtables.com/convert/number/ascii-hex-bin-dec-converter.html
写入常驻后台运行
1 2 3 4 5 6 |
[crayon-65c45c7809ecd824710243 inline="true" class="language-bash"]cat > /home/MTProxy/objs/bin/run.sh <<EOF #!/bin/bash cd "$(dirname "$0")" ./mtproto-proxy -u nobody -p 8888 -H 2083 -S 271082e5da56c2877f215c225eb93ffe --aes-pwd proxy-secret proxy-multi.conf -M 1-6 --domain www.centos.org >/dev/null 2>&1 & EOF chmod +x /home/MTProxy/objs/bin/run.sh |
[/crayon]
写入开机启动
编辑 /etc/rc.local 加入启动脚本
1 |
[crayon-65c45c7809ed1324835951 inline="true" class="language-bash"]/home/MTProxy/objs/bin/run.sh |
[/crayon]
开机启动无效,大多数原因是启动脚本没有执行权限,可赋值启动脚本权限进行修复。
1 2 |
[crayon-65c45c7809ed5186822136 inline="true" class="language-bash"]chmod +x /etc/rc.local chmod +x /etc/rc.d/rc.local |
[/crayon]
关于调试
在我调试时遇到很多问题,例如你设置的代理域名,执行时提示失败,也并不能代表你不能用。如:
1 2 3 |
[crayon-65c45c7809ed9011535932 inline="true" class="language-bash"][18121][2020-01-06 18:44:53.583586 local] Not found TLS 1.3 support on domain www.centos.org [18121][2020-01-06 18:44:53.584159 local] Failed to update response data about www.centos.org, so default response settings wiil be used [18121][2020-01-06 18:44:53.584188 local] It is recommended to not use workers with TLS-transport[18121][2020-01-06 18:44:53.584269 local] creating 1 workers |
[/crayon]
反倒是,在我刚开始测试时,得不出任何结论时,这个失败的域名反倒可以连通,浏览器访问也是成功的。
其实这只是MTP尝试获取该域名的证书相关信息时,为客户端交换信息做的准备工作。获取不到的就取预设的默认值,也是可以工作的。
这是正常能获取到的信息:
1 2 |
[crayon-65c45c7809edd891224045 inline="true" class="language-bash"][17763][2020-01-06 18:35:57.923782 local] Successfully checked domain eller.tech in 0.112 seconds: is_reversed_extension_order = 0, server_hello_encrypted_size = 1864, use_random_encrypted_size = 1 [17763][2020-01-06 18:35:57.923839 local] It is recommended to not use workers with TLS-transport[17763][2020-01-06 18:35:57.923934 local] creating 1 workers |
[/crayon]
另外你也可以通过浏览器访问
https://ip:port 进行测试查看证书是否正确,以及是否重定向成功。
关于安全性
如果采用了tls,对于网路运营商而言,他并不能看到具体传输的数据内容,只可以分析出你的数据包是HTTPS。能获取的信息只有服务器IP地址、以及域名证书。
由于获取到的信息有限,你可以借此将你的服务器实现更深度的隐匿。
例如你使用谷歌云的服务器,代理域名设置为google.com。
使用亚马逊(aws)服务器,代理域名设置到aws.amazon.com。
使用DO的服务器,代理域名设置到digitalocean.com。
这样一来,你的IP地址、证书一致,对于其他人而言这就是一个正常的网站,无论是从正常访问还是探测的角度都很难识别出这是MTP代理服务器。