Tor的Conjure网桥全面复活！

技术交流
, , , ,
1

Tor的Conjure网桥全面复活！
用“全面复活”这个词是因为之前已经复活，但这次是正式进入Stable版本，意味着Tor官方认为已经足够安全可以用在真正需要安全和匿名的危险环境。

注意这里说的全面复活是指技术原理层面，实际上能否成功翻墙需要你自己自行测试，别人那里没法翻墙不代表你的环境无法成功翻墙。
建议耐心等待，等待太长建议多次尝试，包括各种重启，刷新页面等。
用法：

2 个赞
2

试了下，用不了.

  1. conjure 桥基本找不到提供
  2. 如果启用前置代理，报错
    [WARN] Can’t use bridge at [scrubbed]: there is no configured transport called “conjure”.
    疑似无法使用前置代理

我不是很看好。不过还是点个赞，再等等看吧
.

3

尽量避免透露自己的网络环境信息，但根据gitlab.torproject.org上的公开信息，多尝试几次多等一会应该能连上，有些时候连不上好像是Bug？

如果真的怎么尝试都连不上可能是具体环境的原因，也要注意有可能是你尝试的时段Conjure和Tor方面本身的问题，这种情况是全球都连不上，就像复活之前。
Conjure本身的审查抵抗原理应该让它像Snowflake一样就算被干扰也很难被彻底封死。
如果你的环境不论怎么尝试都连不上，建议评估风险后决定是否向Tor报告Bug：
https://anonticket.torproject.org

新型网桥好像都不支持前置代理，好像Tor的框架好像需要PT（Pluggable Transport）特别设计才能支持前置代理。

4

你提供的conjure 桥的ip被封锁了，ping 不通，端口也不通，https://tcp.ping.pe/143.110.214.222:80 根本就没法测试协议是否可用

ip被封锁，基本上就不用试了，不可能连的上的

我也找不到别的conjure 桥，还是那个问题 conjure 桥太少了

我在国外的机子上连了下conjure 桥，确实是可用的

5

不完全正确，Conjure这种新型网桥都是对IP被封锁的情况有针对性设计，不可能低成本简单屏蔽单个IP就连不上，GFW要么技术上不可能屏蔽，要么屏蔽的成本极高。
新型网桥的IP和端口在中国不通不代表在中国无法使用，Snowflake是例子，Conjure同理，Webtunnel也是这样：

请严格按照bridge line进行尝试，不要检查IP和端口连通性就下结论。
如果尝试失败建议尝试调整fronts和stun参数，也注意这不是单纯的网桥方面更新复活，客户端也必须更新才能复活。

stunAddr := flag.String(“stun”, “stun.antisip.com:3478”, “STUN server address needed for IP retrieval, use with ampCacheURL specified”)

另外Conjure也确实提供直连方式连接，但那只是用来调试，所以墙外可以直连成功IP和端口也能连通。

6

是的，你是对的，今天又尝试了下，可以连通了。连接过程十分漫长，网络流量也很低

并不是，之前是先尝试失败了，才去检查IP和端口连通性的。这让我以为是封了ip导致无法连通下了错误的结论

不行，比如把
fronts=cdn.zk.mk,www.cdn77.com换成fronts=xijinping.com,pingjinxi.com 就连不上了，似乎还是要遵照服务端下发的配置

stun 的参数我找不到可以调整的地方

版本号 14.5.6

p
p1498×610 132 KB

墙外进行连接，没有问题，很迅速

7

是在说网速很慢还是传输数据量很低？ 我不清楚Conjure细节，但连接过程花费的时间较长不一定是因为网速慢，也可能是因为在协商内容什么的，所以连接过程花费很多时间但实际上并没有传输什么数据，只是在等待和协商。
连接成功后打开几个网页试试？也许体验不像连接过程那么慢？

fronts目前必须是解析到CDN77的IP，确实不是随便一个就行，具体我也没好办法只能自己多找几个域名试试运气好就能找到了。
但如果不在意特征异常的话，其实也不一定需要什么域名，自己随便弄个域名本地hosts文件解析到合适能用的CDN77的IP就行。
再次提醒没必要的话别这么干，这会降低Tor安全性和匿名性，而且一般确实不需要这么干，真的需要这么干的话建议报告给Tor让他们想办法。

16:24:52 <dcf1> right, or as shelikhoo says, find some way to internally pre-resolve the name (but that creates inconsistencies between the DNS layer and the TLS layer)

https://meetbot.debian.net/tor-meeting/2023/tor-meeting.2023-09-21-15.57.log.html#l-88
stun参数在文档里目前没说，但却是这次Conjure复活的关键，你看那段代码，其实就是bridge line里加上stun=stun服务器域名:stun服务器端口
stun域名可以参考Snowflake的ice参数，但注意格式有细微区别也不支持多域名，conjure的stun参数的内容开头不能加“stun:”。
Conjure错误示例： stun=stun:stun.antisip.com:3478
Conjure正确示例： stun=stun.antisip.com:3478

好奇墙外的迅速连接也是严格按照bridge line吗？ 那可能真的是具体环境干扰的事情了？或者Conjure对自由世界的请求有什么特殊的简单处理？

8

虽然我知道你很可能只是在开政治玩笑，但是你举的例子fronts=xijinping.com,pingjinxi.com会让尝试者承担不必要的风险。
可能有用的front domains：
最新：
https://bridges.torproject.org/moat/circumvention/map
https://bridges.torproject.org/moat/circumvention/builtin
曾经提到（也许仍然有用）：