tailscale 自带 exit node 功能, 就是可以把流量全部路由到某个节点, 正好也可以顺便组网

大概看了一下原理, 大概跟很久以前一个叫 twister 的去中心化播客差不多
个人感觉类似的东西要解决存储问题才能大规模使用, 毕竟不能指望用户用爱发电

@Pichai 我看 xda 上说好像是自从一加被合并以后, 就不再提供后续型号的救砖工具了, 所以没有开发者愿意尝试

我看了一圈，到现在 8gen1 以后的 soc 的机型几乎没有第三方 rom ，有没有 android 开发者说一下为什么? 是因为没有救砖工具吗?

开源协议的存在价值之一就是让项目可以被更多的人使用，这里的使用自然也包括了二次开发，所以如果你在遵守协议的情况下对代码进行修改，分发，是完全合理合法的，因为这就是作者选择这种开源协议的本意

@eecker 没戏

如果你是指域名的话, m-talk.google.com 还有它的备用域名是没有被墙的, 但是它解析得到的 ip 有一部分是被墙的, 你可以上 github 上找一下或者自己试一下哪些 ip 可以直连, 然后改 hosts 把解析固定下来就行了, 比如说 142.250.111.188

广播 syn 可太秀了,真是脑溢血才能想出的方案,干脆内网直接用组播地址算了

我是真的不理解,与其搞这个,运营商搞个端口映射不是简单地多?

@icegaze 求个链接，哪里可以买到这么便宜的盒子

你如果用梯子, 很可能就是走的 apple 服务器中转, 那么断线也是很正常的, 毕竟 apple 的服务器都在国外.
但是如果是 p2p 的话, 就很稳, 不过 p2p 对打洞条件有要求

@lanlandezei 程序里有自动创建 iptables 规则的，你可以在 nat 表里找到
还有，interval 不用设置太高，半个小时更新一次都没问题，毕竟用的公共服务器

@lanlandezei 有需要可以自行编译

https://github.com/Alozxy/trav

@q197 更进一步研究抓包发现，在 TCP 协议下，无论是连接 peers 还是连接 tracker ，使用的本地端口都是 socket 随机指定的，而不是设置里的监听端口，在这种情况下 nat 外的端口也是不固定的，所以两个 peers 自动打洞成功的概率可以忽略不计。
但是作为对比，UDP 协议下，无论是μtp 还是 udp tracker ，使用的本地端口都是设置里的监听端口，这种情况下才有可能实现上一楼中说的情况，但是这要求必须是μtp + udp tracker ，实际使用中 udp tracker 其实是很少的。
但是如果下载的不是私有种子，那么就和之前说的一样，可以使用 DHT 或者 PEX 协议接受μtp 入站连接，[BEP_0055]( https://www.bittorrent.org/beps/bep_0055.html)也规定了一部分打洞扩展。
以上实验皆基于 qbittorrent

@q197 其实即便 tacker 记录的是 external port ，两个 nat1 的 peers 也很难连上，主要就是因为 nat 的映射时间太短，而 tracker 汇报的间隔很长，所以只有两个 peers 同时在 nat 映射打开的时候连接对方才行，这个概率真的很随缘。不过如果真是这种情况，只需要一个 peer 主动一直打开映射就一定能被其他 peer 连上，可以说能简化很多。