wireguard 最佳套壳优化姿势? - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Evovil
0.01D
V2EX    宽带症候群

wireguard 最佳套壳优化姿势?

  •  
  •   Evovil 2023-12-13 22:45:38 +08:00 via iPhone 10982 次点击
    这是一个创建于 668 天前的主题,其中的信息可能已经有所发展或是发生改变。

    计划从抢外把 wg 流量传回国内,什么情况是最佳姿势?

    1. 使用机场线路: 大部分机场 udp 支持不佳而且就算有也会有 qos (可能),走 tcp 的话 fake-tcp 类( udp2raw ,phantun )无法使用正常 ss 类 tcp tunnel 。 硬转 tcp 走 tcp 隧道会有 tcp over tcp (拥塞异常等)性能问题,也会有 head of line block 等性能问题,私认为不是最佳实践

    2. 买个 9939/cn2gie/iplc 的 vps 跳板(可以推荐下不 眼花缭乱)。这些线路 udp 会有优化吗?

    3. 用 quic 类走直连- 似乎出墙除非精品网,cn2 等也是变态 qos

    4. 换 openvpn ? 似乎性能有点差

    22 条回复    2023-12-15 13:30:35 +08:00
    szzys
        1
    szzys  
       2023-12-13 22:47:44 +08:00 via Android
    三大流氓出海必被 qos ,只是看程度而已
    ericFork
        2
    ericFork  
       2023-12-13 23:43:13 +08:00
    2. 未必有,甚至经常会额外加上更严的 UDP QoS
    4. 直接排除,现阶段没有任何用它的必要
    mantouboji
        3
    mantouboji  
       2023-12-13 23:47:31 +08:00
    就普通的 wireguard 配置,不要加任何包装。写好脚本,每隔一段时间(比如三个小时),更换一个随机端口。
    etnperlong
        4
    etnperlong  
       2023-12-14 00:13:24 +08:00
    我现在有一台腾讯云国内,一台某墙外 VPS ,是这样组网的
    在墙外 VPS 搭了 Hysteria2 服务器,开端口跳跃,墙内使用 Hyteria2 动态端口连接
    然后将 WireGuard 端口转发,腾讯云的 WireGuard 指向本地映射的端口,用 Hysteria2 抗封锁+隐藏特征
    运行了一年多没有问题(之前用 hy1 现在改成 hy2 )
    cnbatch
        5
    cnbatch  
       2023-12-14 03:35:01 +08:00
    那就看你想套哪种壳。

    自带流控、丢包重传的壳,选择很多。比如楼上提到的 Hysteria ,适合大流量传输;还有经典的 v2ray 和 xray-core ,走 UDP over TCP ;也可以用 KCPTube ,只不过这主要是为了抗丢包+低延迟的,大流量未必合适。

    不带流控的壳,单纯只是在外面套一层包装箱,可以用经典的 UDPSpeeder ;以及 udp2raw ,伪装成 TCP ;或者 UDPHop ,定时端口跳跃。
    wangyucn
        6
    wangyucn  
       2023-12-14 07:03:06 +08:00
    你都提到 tcp over tcp 了不知道为啥还会考虑 4 ,4 一样有 tcp over tcp 。

    >走 tcp 的话 fake-tcp 类( udp2raw ,phantun )无法使用正常 ss 类 tcp tunnel

    为什么 4 个选项里没有:不使用机场路线,自己 vps 跑 faketcp
    wangyucn
        7
    wangyucn  
       2023-12-14 07:10:18 +08:00
    >自带流控、丢包重传的壳,选择很多。比如楼上提到的 Hysteria ,适合大流量传输;还有经典的 v2ray 和 xray-core ,走 UDP over TCP ;也可以用 KCPTube ,只不过这主要是为了抗丢包+低延迟的,大流量未必合适。

    Hysteria 是 udp over Quic; v2ray 和 xray-core 是 udp over tcp; KCPTube 看描述应该是 udp over kcp

    如果在 wireguard 里跑了 TCP, 就分别是 tcp over quic; tcp over tcp; tcp over kcp 。

    还是有双重拥塞控制、head of line blocking 的问题。 只不过 over quic 和 over kcp 比 over 原生 kcp 在双重拥塞控制上好一点。 head of line blocking 完全无法避免。
    Evovil
        8
    Evovil  
    OP
       2023-12-14 09:13:41 +08:00 via iPhone
    @wangyucn #6 感谢大神,听上去最佳时间似乎是:
    找个 cn2gie/9939/iplc 的跳板,然后用 udp2raw faketcp/auth-none/cipe-none 用来避免 isp 的 qos

    如果直连 faketcp 普通 ip 走 chinanet 即使是 tcp 还有通常无差别暴力丢包,和 tcp qos
    Evovil
        9
    Evovil  
    OP
       2023-12-14 09:25:53 +08:00 via iPhone
    套壳大概总结:
    1. 选个稳定线路,通过 faketcp 避免 udp qos
    2. 选个不稳定线路通过 udp over quic 等自带拥协议的用激进流控策略获得低延迟+大流量稳定性。
    wangyucn
        10
    wangyucn  
       2023-12-14 09:43:10 +08:00   1
    >选个不稳定线路通过 udp over quic 等自带拥协议的用激进流控策略获得低延迟+大流量稳定性。

    在 wireguard 下面增加一个可靠传输层,只会增加延迟,不会降低。

    不太理解在有 udp qos 的情况下,udp over quic 或者 udp over kcp 解决了啥问题。 quic 和 kcp 底层还是 udp ,不管加了什么激进的流控策略,底层还是 udp 。

    如果你说的 udp qos 只是简单的丢包,说不定有一些意想不到的效果。 如果你说的 udp qos 是断流或者有速率限制,那么你在上层做什么激进的策略也解决不了。
    Evovil
        11
    Evovil  
    OP
       2023-12-14 09:56:23 +08:00 via iPhone
    @wangyucn 不知道理解对不对
    按照出口带宽的现象推测:普通 ip 标准出口的带宽资源是有限的,除了 vip 线路其他共享一个带宽池,在超售带宽的前提下选择性丢包。 hy2 这类的拥塞协议应该是通过多倍发包策略获得更多机会也别再大流量下有更好的表现

    udp qos 或者掐断应该是面向墙内一些 isp 自己的策略,推测是防止 udp 反射之类的 ddos 流量
    wangyucn
        12
    wangyucn  
       2023-12-14 10:32:37 +08:00   2
    据我了解,hy2 是魔改 quic ,手动控制拥塞控制,不能多倍发包。检测到丢包了再重传的不算多倍发包。

    有多倍发包的是 net-speeder 这种纯多倍发包,或者是 kcptun-go udpspeeder 这种支持 fec 的。

    > 按照出口带宽的现象推测:普通 ip 标准出口的带宽资源是有限的,除了 vip 线路其他共享一个带宽池,在超售带宽的前提下选择性丢包。hy2 这类的拥塞协议应该是通过多倍发包策略获得更多机会也别再大流量下有更好的表现
    > udp qos 或者掐断应该是面向墙内一些 isp 自己的策略,推测是防止 udp 反射之类的 ddos 流量

    所以你是想说,只考虑简单丢包的情况,不考虑别的情况。 那 wireguard over hy2 可能有一些意想不到的效果,也可能没有, 我不确定。

    udp 简单丢包:
    1. 如果上层只代理 tcp 。 那不如只用 hy2 ,不用 wireguard 。没有 tcp over tcp 的问题,底层 udp 有丢包,重传一下也就解决了;因为有激进的拥塞策略,速度可以保证,就是延迟会高。
    2. 上层只代理 tcp ,对延迟还有要求。 那就用打开了 fec 的 kcptun ,延迟有改善,其他同 1
    3. 上层要代理 udp ,这种情况才需要上 wireguard 。 先尝试用 faketcp ,看转成 tcp 丢包能不能降低,如果能问题解决。 如果不能,那就用 udpspeeder 加 fec 。 如果真的只是“简单”丢包,一般 fec 都可以解决;解决不了的话,很可能你的线路就不是简单丢包(参考下面)。

    udp 非简单丢包(比如流量大了被掐断;再比如发得越多丢得越多):
    1. 上层只代理 tcp 。 那不如你试试 bbr 锐速这种,直接不走 udp 。
    2. 上层要代理 udp 。 你试试转成 faketcp, 看问题能不能解决。 如果不能,那基本上没什么好办法了。 可以试一些非常规方案,比如不停换端口,但是别抱太大希望。 如果再解决不了,建议放弃这个线路。
    mason961125
        13
    mason961125  
       2023-12-14 11:24:56 +08:00
    2 就可以了,买个专线 NAT 直接端口转发 wg 即可。
    FredWang
        14
    FredWang  
       2023-12-14 12:10:15 +08:00
    @etnperlong 直接用 hysteria2 不行么,省去 wireguard
    cnbatch
        15
    cnbatch  
       2023-12-14 12:28:25 +08:00
    @wangyucn 哈哈,果然只要提到两个 UDP 工具的任意一个就能引出来,第三次验证成功

    以后遇到类似问题都可以这么干了,吸引 wangyu 过来帮忙出解决方案
    onedayonecode
        16
    onedayonecode  
       2023-12-14 18:33:30 +08:00
    @mantouboji 那客户端的 IP 也需要跟着改吧
    mantouboji
        17
       2023-12-14 19:25:52 +08:00
    @onedayonecode IP 不需要,但是端口可以跟着变。反正 wg 命令可以随时修改任何参数 on-the-fly
    etnperlong
        18
    etnperlong  
       2023-12-14 20:50:35 +08:00
    @FredWang 我有一些业务需要保持 NAT 畅通,所以用 wireguard 组网
    fan88
        19
    fan88  
       2023-12-15 04:19:16 +08:00
    跟博主有同样的需求。

    聊一下我现在做的情况

    方案 1:使用机场。结论:可以用,非常依赖机场稳定性,且速率一般不会太高。

    测了两家,还算能用的:库洛米和奶昔。这两家之前一段时间稳定性不错,但是最近,东部入口更改为了移动,电信/联通过去就会有丢包和跳 ping ,只能说能用,算不上非常稳,UDP 速率最大为 90Mbps 。

    方案 2:9929 、CN2-GIA 就不考虑了,过墙的东西还是少用,早晚翻车。所以我选的是 IPLC NAT 。结论:稳定性尚可,但绝对没有想象中的那么好,至少一般意义上的预算(一年几十万买线路的当我没说),买不到特别好的。

    用了两家:咕咕云和 CloudIPLC 。CloudIPLC 好点,但是还是会出现丢包、跳 ping 的情况,尤其高峰期,每分钟要丢这么一两个或者跳那么一两个包( 100 毫秒一次 ping ),最大速率根据你买的套餐来,一般不超过 100Mbps 。

    方案 3:CN2 出墙直连。
    手上有线路,但是没去试,最主要的原因是 CN2 去很多地方还是绕路,延迟有点高。


    博主如果有方法了希望可以多交流~
    fan88
        20
    fan88  
       2023-12-15 04:21:58 +08:00
    正价买 IPLC 线路(运营商的国际 SD-WAN )怎么也得 100~300/Mbps/月,咱们这点预算,机场和 IPLC NAT 转发目前看来是比较好的选择。
    Evovil
        21
    Evovil  
    OP
       2023-12-15 07:33:43 +08:00 via iPhone
    @fan88
    完全通过稳定可靠的物理线路,花费几乎是数万每月,除了商用基本没可能。
    完全通过技术,不花钱靠着各种神仙技巧在千军万马过独木桥中从普通出口获得优势,这也行不通,获得的几乎是暴力 qos ,而且也不安全。

    其实最完美的方案 @wangyucn 大神在 #12 已经给出来了:
    1. 选一条尚可的线路:比如 iplc nat ,通过 udp2raw 套上 faketcp ,抵抗 isp 的 qos ,然后再套上 udpspeeder 通过 fec 基本可以抵消高峰时间跳 ping 丢包,高峰期的简单 qos 同时在高峰期共享带宽不足抢带宽上获得优势,基本就已经达到了完美的效果,非常平衡,而且可以根据线路优化参数获得更好的延迟/带宽/流量消耗。

    我之前的方案是:某影机场 vip5+proxy-chain 落地机,兼顾安全性和链路性能,但是代价是延迟高,稳定性也不能保障,即使是很贵的机场也总有不稳定的情况
    wangyucn
        22
    wangyucn  
       2023-12-15 13:30:35 +08:00   2
    称不上完美。套壳 wireguard 实在没多少选择,这个帖子里提到的软件,除了 faketcp 类和 fec 类的,其他东西本来就不是设计用来 tunnel wireguard 的。

    用 wireguard+ faketcp +fec 看似一套方案解决 tcp 和 udp 。 但是就 tcp 来说,这套方案没有魔改的拥塞控制, tcp 速度很可能比不上有魔改拥塞控制的方案。 但是 tcp 延迟相比大部分其他方案有优点,对打游戏什么的有帮助。

    如果倾向 tcp 速度的话,不如 udp 走 faketcp+fec ,tcp 走别的(BBR, kcptun ,hy2)。

    大概就像这个的图里面的: https://github.com/wangyu-/UDPspeeder/wiki/UDPspeeder---kcptun-finalspeed---%24%24-%E5%90%8C%E6%97%B6%E5%8A%A0%E9%80%9Ftcp%E5%92%8Cudp%E6%B5%81%E9%87%8F

    另外,如果你想要 VPN 一样的接口的话,可以在 ss 基础上加个 socks2tun (或者类似的东西),把 socks5“转成” VPN. (不支持 icmp)
    关于     帮助文档     自助推广系统     博客     API     FAQ     Solana     2747 人在线   最高记录 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 29ms UTC 08:32 PVG 16:32 LAX 01:32 JFK 04:32
    Do have faith in what you're doing.
    ubao snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86