tavimori

@Fucter @ambition117 @MossFox

其实咱也只是想用于一些低带宽、低延时的场景的。专线一般都是这种应用场景。

@lcy630409 @huluhulu @huaseky

不是觉得他们技术不行，主要是考虑到不少游戏是基于 P2P 联机，所以并不能建立一个白名单把所有潜在游戏玩家的 IP 都包括进来吧？只要用类似的方式进行 P2P 连接，应该很难区分是否是游戏流量吧？

Wireguard 套传输层代理的确不是建议的做法。在这一问题上现在市面上没有广泛知晓的好的解决方案。

我不太了解 gost 对 UDP 转发的处理，但是任何在 UDP 转发层面做的数据缓冲、多个包合并、套到 TCP 上之类的做法，都会导致利用该 UDP 建立的 wireguard 虚拟网里的传输层协议速率控制算法无法正常工作，在很多情况下会大幅劣化网络质量。

总的来讲，个人理解上 Wireguard 下面不要套东西才能比较良好的工作，起码是不能套 TCP 的东西。

是不是客户端上的 Wireguard 在改路由表时只会自动排除 Wireguard 服务器 B ？

这个取决于你在客户端上对“Wireguard 服务器 B”这一 peer 的 AllowedIP 字段的设置和是否有其他路由规则。

如果是 IPv4 的话，一个简单的 debug 方式是将服务器这一 peer 的 AllowedIP 字段设置成只有他虚拟网的 IP 地址，并以/32 结尾，这样的话在一般的配置情况下，不会带起全局的路由（如果设置成 0.0.0.0/0 ，就会带起全局路由），只会带起到服务虚拟网单一 IP 地址的路由。

在这样建立连接后可以看下 ping 服务测的虚拟网 IP 通不通。

由于常见的加密代理都会对 UDP 包二次封装，并且不会对超过可封装长度的 UDP 包进行分片，所以相关的 UDP 应用要预先对包大小进行限制。

由于不清楚 GOST 协议的头开销，作为保险的解决方法，建议在客户端和服务端的 wireguard 配置上都增加如下配置：
```
MTU=1280
```
如果上述做法有效，可以进一步通过 GOST 协议的头开销对 MTU 进行精确的设定。

现在的互联网地址分配机制是 IANA 分给各个大洲 RIR ，然后可以分给国家级别的 NIR ，然后可以分配给地区级的 LIR ，然后在分配给具体的电信企业，或有独立网络需求的企业和个人。

有需求的企业和个人都可以申请分配公网 IP 。这个网上教程很多，基本上是一个行政流程，有自动化的平台，也有纯人工的渠道。比如欧洲 RIPE 的申请流程比较数字化一点，美洲的 ARIN 据说就比较古早，一般通过电子邮件申请。

从字面上看，似乎中国版 iPad 想要安装海外 esim 的话，只需要安装这一行为发生在境外就行，安装完后也可以漫游回境内使用。

之前用 Chrome 遇到过类似的问题，换个浏览器或者逐个禁用浏览器扩展排查一下就好了。
怀疑是某些插件在打开页面时进行了一些 blocking 操作。

可以使用支持多路径的四层代理协议来避免 TCP 乱序的问题。例如首先通过隧道组成两条并列的三层网络，然后传输层再使用 MPTCP 透明代理 TCP 流量。当然，如果没有需要单连接突破 100M 的需要的话，用 ECMP 之类的对不同连接进行负载均衡的方案就可以。