Total Pageviews

Saturday, 29 January 2022

利用udp2raw,使得被isp进行qos限速的wireguard起死复生

服务端配置

在VPS,下载服务端:

wget https://github.com/wangyu-/udp2raw/releases/download/20200818.0/udp2raw_binaries.tar.gz

tar xvf udp2raw_binaries.tar.gz

解压出来的东西,除了udp2raw_amd64之外,所有其它解压出来的东西都可删除。

./udp2raw_amd64 -s -l 0.0.0.0:4096 -r 127.0.0.1:51820 -a -k mypassword --raw-mode faketcp &

(可用systemd把此命令运行为service)

此命令中的51820为服务器上的wireguard所监听的端口。


客户端配置(客户端机器为mac)

在mac上,安装pcap:
brew install libpcap

mkdir ~/udp2raw_mp_binaries

cd ~/udp2raw_mp_binaries

wget https://github.com/wangyu-/udp2raw-multiplatform/releases/download/20210111.0/udp2raw_mp_binaries.tar.gz

tar xvf udp2raw_mp_binaries.tar.gz

sudo ./udp2raw_mp_mac -c -l 0.0.0.0:3333  -r vps-public-ip:4096 -k mypassword --raw-mode easy-faketcp  (不要关闭此窗口)


然后,编辑mac上的wireguard 的配置文件:
nano /etc/wireguard/wg2.conf

cat /etc/wireguard/wg2.conf

[Interface]

PrivateKey = 你的PrivateKey的值

Address = 17.0.0.2/24

DNS = 8.8.8.8

MTU = 1200


[Peer]

PublicKey = 你的PublicKey的值

Endpoint = 0.0.0.0:3333

AllowedIPs = 0.0.0.0/0

PersistentKeepalive = 25


其中,Endpoint的值要改为0.0.0.0:3333


然后运行wireguard:

sudo wg-quick up wg2


至此,即可用 wireguard翻墙。


https://github.com/wangyu-/udp2raw-multiplatform/wiki/%E5%BF%AB%E9%80%9F%E5%85%A5%E9%97%A8


https://github.com/wangyu-/udp2raw-multiplatform/wiki/%E4%B8%AD%E6%96%87%E6%96%87%E7%AB%A0


注意1:必须先运行udp2raw,后运行wireguard。顺序不可颠倒。

注意2MTU的值要设置得低一点,比如1200,不要设为1300或1400.

这在https://github.com/wangyu-/udp2raw-tunnel/blob/master/doc/README.zh-cn.md里面有说明:MTU设置(重要)

不论你用udp2raw来加速kcptun还是vpn(基于udp流量的vpn, 比如wireguard vpn),为了稳定使用,都需要设置合理的MTU(在kcptun/vpn的配置文件里设置,而不是在udp2raw里),建议把MTU设置成1200。client和server端都要设置。(设置为同一个值)“
-----------------------------------

related post: 

https://briteming.blogspot.com/2018/11/macwireguard.html

https://briteming.blogspot.com/2017/10/udp2raw-tunnel_23.html

-----------------------------------------------


Wireguard-anti-QOS

介绍

Wireguard走UDP协议,部分运营商会对UDP进行限速QOS处理使连接速度不理想或出现丢包情况。若串联udp2raw可将UDP流量伪装成TCP流量避免被运营商QOS。本项目脚本会在服务器搭建Wireguard和udp2raw服务,同时本地使用Tunsafe连接Wireguard时会自动运行大陆IP分流脚本和udp2raw程序。

本项目脚本根据Atrandys一键脚本修改,请支持原作者,项目地址:https://github.com/yobabyshark/wireguard

使用方法

bash <(curl -L -s https://raw.githubusercontent.com/lmc999/Wireguard-anti-QOS/master/wg-anti-qos.sh)

用Winscp等软件登入VPS,下载目录/etc/wireguard/中的client.conf到Tunsafe配置文件目录

下载Tunsafe用批处理文件文件: https://github.com/lmc999/Wireguard-anti-QOS/archive/master.zip

解压缩文件,并将文件夹内的所有文件解压到 D:\software\TunSafe\bat

本教程Tunsafe默认安装路径 D:\software\TunSafe,如果你的安装路径不一样请注意修改clien.conf中的批处理程序的路径.同时建议安装路径不要有空格。

用记事本打开start.bat,修改44.55.66.77为你Wireguard服务器ip

开启Tunsafe的Pre/Post命令功能。在"Option"选择"Allow Pre/Post Commands"

TunSafe选中client.conf, connect即可自动分流和串联udp2raw


from  https://github.com/lmc999/Wireguard-anti-QOS

-----


WireguardForGame

介绍

Wireguard走UDP协议,部分运营商会对UDP进行限速QOS处理使连接速度不理想或出现丢包情况。若串联udp2raw可将UDP流量伪装成TCP流量避免被运营商QOS。另外同时再串联udpspeeder多倍发包可降低游戏丢包率。本项目脚本会在服务器搭建Wireguard、udp2raw、udpspeeder服务,同时本地使用Tunsafe连接Wireguard时会自动运行大陆IP分流脚本,udp2raw和udpspeeder程序。

本项目脚本根据Atrandys一键脚本修改,请支持原作者,项目地址:https://github.com/atrandys/wireguard

事前准备

电脑需安装好winpcap或npcap,下载地址请自行百度。

目前脚本支持centos7+, debian8+, ubuntu16+

使用方法

bash <(curl -L -s https://raw.githubusercontent.com/lmc999/WireguardForGame/master/wg-for-game.sh)

用Winscp等软件登入VPS,下载目录/etc/wireguard/中的client.conf到Tunsafe配置文件目录

下载Tunsafe用批处理文件文件master.zip

解压缩文件,并将文件夹内的所有文件解压到 D:\software\TunSafe\bat

本教程Tunsafe默认安装路径 D:\software\TunSafe,如果你的安装路径不一样请注意修改clien.conf中的批处理程序的路径.同时建议安装路径不要有空格。

用记事本打开start.bat,修改44.55.66.77为你Wireguard服务器ip

开启Tunsafe的Pre/Post命令功能。在"Option"选择"Allow Pre/Post Commands"

TunSafe选中client.conf, connect即可自动分流和串联udp2raw + udpspeeder

Wireguard配合游戏规则使用

本项目搭建成功后默认是大陆白名单模式,可以直接进行游戏。

但同时Wireguard的Windows客户端Tunsafe支持添加路由规则,指定具体路由走wireguard代理,原理与SSTAP的游戏规则相同。使用方法是往Tunsafe配置文件中的AllowIPs参数添加游戏路由表。这里以PUBG亚服规则为例子,请参考sample.conf

目前已有成熟的游戏规则项目,项目原本为SSTAP服务,但其实只需将该项目中的对应游戏规则添加到Wireguard中照样可正常使用。

项目传送门:https://github.com/FQrabbit/SSTap-Rule


from https://github.com/lmc999/WireguardForGame

---------------


RouterOS下,基于macvlan pppoe拨号的wireguard mtu问题

最近发现 git clone github 上面稍微大一点的库的时候就会在下载到几百兆的时候报错断开。我一直以为是从 udp2raw 切换到 hysteria 才导致的线路不稳定。但是报错断开的同时观察 ping 数据,一直处于非常稳定的状态。最近这一次碰到的时候突然联想到了 mtu 。觉得可能和它有关系。就尝试调整了一下。

git clone 大致的报错如下:

remote: Enumerating objects: 222542, done.
remote: Counting objects: 100% (11400/11400), done.
remote: Compressing objects: 100% (466/466), done.
error: RPC failed; curl 92 HTTP/2 stream 5 was not closed cleanly: CANCEL (err 8)
error: 6407 bytes of body are still expected
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output

网络结构:


之前用的是 udp2raw + udpspeeder,来包裹 wireguard 协议。udpspeeder 好像会重新对包进行组装。所以没有遇到网络问题。
但由于 routeros 中的 container 没有 iptables 的权限。没有办法运行 udp2raw,所以换成了 hysteria 对 wireguard 协议进行包裹。运行了一段时间之后感觉稳定性也还不错。延迟似乎还更低了一些。从 github 拉一些不太大的库也没有碰到问题。

这次怀疑 mtu 问题也只是猜测而已。尝试过设置两边的 wg0 接口 mtu 值为 1480, 1460, 1420, 1280 都没有解决问题。错误的设置甚至会导致 git clone 操作卡死不动,直到 timeout。

最后测试下来发现下面的设置是有效的:

  • 设置 macvlan mtu 为 1480
  • pppoe 拨号后会自动设置 mtu 为 1472 (1480-8)
  • 保持 routeros wg0 mtu 为默认的 1420
  • server 端 wg0 保持为 1500

其它

中间加入了一层 macvlan 是因为给 pppoe 做单线多拨。
很早之前也遇到过 mtu 导致的网络问题,但通常都是在访问 http 服务的时候出现的,而且大部分网站都会遇到访问问题。这次的情况好像只有 github 出现问题。并且只是在 git clone 的时候出现问题。通过浏览器访问、下载都是正常的。其实这次出现问题我也没有发现设置上明显的错误。最后虽然解决了,但也只是通过猜测解决的。暂时先记录一下。继续观察看看。


2024-03-29 更新:

最近又出现了 github 不能 clone 仓库的问题了。应该还是 mtu 导致的问题。最后找到了解决方案。通过下面的命令设置 server 的 pmtu

iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

并且设置:

  • 还原 routeros 中 macvlan mtu 为 1500
  • 设置 server 端 wg0 接口 mtu 为默认的 1420

----------------------------------------------------------------------

ShadowsocksR+UDPSpeeder+Udp2raw+KCP 实现网游加速

 之所以选用 ShadowsocksR,而不是 V2ray,是因为 V2ray 的 UDP 协议是 UDP over TCP,就是讲 UDP 数据包转换成 TCP 再进行传送,主要的问题是在 Nat Full Cone 表现上极为不好,无法穿透内网,也就无法实现多人联机。

在我测试的结果来看,给我的感觉是 UDP 数据包通过远端传送出去之后,并没有接到其他服务器响应回来的数据包,也没把数据包带回来,导致只会有去无返的数据包。

当然 udp 测试是通过的,因为数据包可以正常发出。又有其他人说是是因为多路数据包回应时,v2ray 只能记住前一个的数据包的源地址,导致后面的错误返回属于无效包。

这是 V2 实现 NAT 穿透的技术讨论页,有兴趣可以自行关注:https://github.com/v2ray/v2ray-core/issues/1429#issuecomment-549667805

虽然 V2ray 在实际使用过程中 TCP 性能要比 SSR 要好很多,但是无法达成我们今天这个场景,所以我们还是选择 SSR。

本文的内容主要讲网游加速器的原理和实际遇到的问题以及解决具体问题。

TG 技术扯谈群组:https://t.me/EllerCN
一步到位教程

不想看细节的可以看这个一步到位教程,很简单。需要了解过程的查看下文。

注:将你的 SSR 端口配置为 8388
下载通用(服务端/客户端):

mkdir /home/udp2raw-tunnel
cd /home/udp2raw-tunnel
wget https://github.com/wangyu-/udp2raw-tunnel/releases/download/20190716.test.0/udp2raw_binaries.tar.gz
tar -xzf udp2raw_binaries.tar.gz

mkdir /home/speederv2
cd /home/speederv2
wget https://github.com/wangyu-/UDPspeeder/releases/download/20190121.0/speederv2_binaries.tar.gz
tar -xzf speederv2_binaries.tar.gz


mkdir /home/kcptun
cd /home/kcptun
wget https://github.com/xtaci/kcptun/releases/download/v20191127/kcptun-linux-amd64-20191127.tar.gz
tar -zxf kcptun-linux-amd64-*.tar.gz

服务端运行脚本:

若服务端端口无冲突的情况下,该脚本不必修改可直接使用。

local_proxy为代理加速的端口,如 SSR 的监听端口 8388,也可以是其他你需要加速的端口。

cat >/home/jiasu_run.sh <<\EOF
#!/bin/bash
echo "KCP/SpeederV2/Udp2raw 一键启动脚本[服务端]"
cd `dirname $0`

publish_ip="0.0.0.0" #服务端 IP 地址
publish_kcp=29900 #KCP 对外端口
publish_udp2raw=6002 #UDP2RAW 监听端口

local_proxy=8388 #加速的代理端口,如 SSR 的 8388
local_speederv2=6001 #speederv2 本地服务端口

param=$1
if [ ! -d "./pid" ];then
  mkdir ./pid
fi

pid_kcptun=./pid/kcptun_$0.pid
pid_speederv2=./pid/speederv2_$0.pid
pid_udp2raw=./pid/udp2raw_$0.pid

function pid_exists(){
  local exists=`ps aux | awk '{print $2}'| grep -w $1`
  if [[ ! $exists ]]
  then
    return 0;
  else
    return 1;
  fi
}

function pid_status(){
  if [[ -f $1 ]];then
    pid_exists `cat $1`
    if [[ $? == 1 ]];then
      echo -e "\t $2: \033[32m 运行中\033[0m"
    else
      echo -e "\t $2: \033[31m 已停止\033[0m"
    fi
  else
    echo -e "\t $2: \033[31m 已停止\033[0m"
  fi
}


function stop(){
  local pid=`cat $1`
  kill -9 $pid
  pid_exists $pid
  if [[ $pid == 1 ]]
  then
    echo "停止任务失败"
  fi
}

function start(){
  ./kcptun/server_linux_amd64 -l $publish_ip:$publish_kcp -t 127.0.0.1:$local_proxy -key "eller" -mtu 1400 -sndwnd 2048 -rcvwnd 2048 -mode fast2 >/dev/null 2>&1 &
  pid=$!
  echo $pid >$pid_kcptun
  sleep 2
  pid_exists $pid
  if [ $? == 1 ];then
    echo -e "KCP \033[32m 启动成功\033[0m,对接端口:$publish_ip:$publish_kcp"
    #echo "KCP 启动成功,对接端口:$remote_ip:$remote_kcp"
  else
    echo -e "KCP \033[33m 启动失败\033[0m"
  fi

  ./speederv2/speederv2_amd64 -s -l127.0.0.1:$local_speederv2 -r127.0.0.1:$local_proxy -k "eller" -f20:40 --timeout 1 >/dev/null 2>&1 &
  pid=$!
  echo $pid >$pid_speederv2
  sleep 2
  pid_exists $pid
  if [ $? == 1 ];then
    echo -e "SpeedV2 \033[32m 启动成功\033[0m"
  else
    echo -e "SpeedV2 \033[33m 启动失败\033[0m"
  fi

  ./udp2raw-tunnel/udp2raw_amd64 -s -l$publish_ip:$publish_udp2raw -r 127.0.0.1:$local_speederv2 -a -k "eller" --raw-mode faketcp >/dev/null 2>&1 &
  pid=$!
  echo $pid >$pid_udp2raw
  sleep 2
  pid_exists $pid
  if [ $? == 1 ];then
    echo -e "UDP2RAW \033[32m 启动成功\033[0m"
  else
    echo -e "UDP2RAW \033[33m 启动失败\033[0m"
  fi
}

function stop_proces(){
  stop $pid_kcptun
  stop $pid_speederv2
  stop $pid_udp2raw
}

if [[ "start" == $param ]];then
  echo "即将:启动脚本";
  start
elif  [[ "stop" == $param ]];then
  echo "即将:停止脚本";
  stop_proces;
elif  [[ "restart" == $param ]];then
  stop_proces
  start
else
  echo "当前配置(如不正确,请编辑脚本进行修改):"
  echo -e "\t 服务端 IP:$publish_ip"
  echo -e "\t 服务端 KCP 端口: $publish_kcp"
  echo -e "\t 服务端 UDP2RAW 端口: $publish_udp2raw"
  echo -e "\t 本地加速端口: $local_proxy"
  echo -e "\t 本地 udp2raw 端口:$local_speederv2"
  echo "服务状态:"

  pid_status $pid_kcptun "KCP"
  pid_status $pid_speederv2 "speederv2"
  pid_status $pid_udp2raw "udp2raw"

  echo "使用方式:  "
  echo -e "\t 运行服务:bash $0 start "
  echo -e "\t 停止服务:bash $0 stop "
  echo -e "\t 重启服务:bash $0 restart "
fi
EOF

客户端运行脚本:

这里的客户端一般为中继服务器,你也可以通过虚拟机来创建此服务,windows 端连接这个"中继"服务器 IP,即代理加速的端口即可,如:8388

注意修改脚本中的 “55.66.77.88”为自己的服务器 IP

cat >/home/jiasu_run.sh <<\EOF
#!/bin/bash
echo "KCP/SpeederV2/Udp2raw 一键启动脚本[客户端]"
cd `dirname $0`

remote_ip="55.66.77.88" #远端 IP 地址
remote_kcp=29900 #远端 KCP 端口
remote_udp2raw=6002 #远端 UDP2RAW 端口

local_publish=8388 #本地公开端口,建议和服务端 SSR 一致便于理解
local_udp2raw=7004 #udp2raw 本地服务端口

param=$1
if [ ! -d "./pid" ];then
  mkdir ./pid
fi

pid_kcptun=./pid/kcptun_$0.pid
pid_speederv2=./pid/speederv2_$0.pid
pid_udp2raw=./pid/udp2raw_$0.pid

function pid_exists(){
  local exists=`ps aux | awk '{print $2}'| grep -w $1`
  if [[ ! $exists ]]
  then
    return 0;
  else
    return 1;
  fi
}

function pid_status(){
  if [[ -f $1 ]];then
    pid_exists `cat $1`
    if [[ $? == 1 ]];then
      echo -e "\t $2: \033[32m 运行中\033[0m"
    else
      echo -e "\t $2: \033[31m 已停止\033[0m"
    fi
  else
    echo -e "\t $2: \033[31m 已停止\033[0m"
  fi
}


function stop(){
  local pid=`cat $1`
  kill -9 $pid
  pid_exists $pid
  if [[ $pid == 1 ]]
  then
    echo "停止任务失败"
  fi
}

function start(){
  ./kcptun/client_linux_amd64 -l :$local_publish -r $remote_ip:$remote_kcp -key eller -mtu 1400 -sndwnd 256 -rcvwnd 2048 -mode fast2 -conn 4 > /dev/null 2>&1 &
  pid=$!
  echo $pid >$pid_kcptun
  sleep 2
  pid_exists $pid
  if [ $? == 1 ];then
    echo -e "KCP \033[32m 启动成功\033[0m,对接端口:$remote_ip:$remote_kcp"
    #echo "KCP 启动成功,对接端口:$remote_ip:$remote_kcp"
  else
    echo -e "KCP \033[33m 启动失败\033[0m"
  fi

  ./speederv2/speederv2_amd64 -c -l0.0.0.0:$local_publish -r127.0.0.1:$local_udp2raw -f20:40 -k "eller" --mode 0 > /dev/null 2>&1 &
  pid=$!
  echo $pid >$pid_speederv2
  sleep 2
  pid_exists $pid
  if [ $? == 1 ];then
    echo -e "SpeedV2 \033[32m 启动成功\033[0m"
  else
    echo -e "SpeedV2 \033[33m 启动失败\033[0m"
  fi

  ./udp2raw-tunnel/udp2raw_amd64 -c -l127.0.0.1:$local_udp2raw  -r$remote_ip:$remote_udp2raw -k "eller" --raw-mode faketcp >/dev/null 2>&1 &
  pid=$!
  echo $pid >$pid_udp2raw
  sleep 2
  pid_exists $pid
  if [ $? == 1 ];then
    echo -e "UDP2RAW \033[32m 启动成功\033[0m"
  else
    echo -e "UDP2RAW \033[33m 启动失败\033[0m"
  fi
}

function stop_proces(){
  stop $pid_kcptun
  stop $pid_speederv2
  stop $pid_udp2raw
}

if [[ "start" == $param ]];then
  echo "即将:启动脚本";
  start
elif  [[ "stop" == $param ]];then
  echo "即将:停止脚本";
  stop_proces;
elif  [[ "restart" == $param ]];then
  stop_proces
  start
else
  echo "当前配置(如不正确,请编辑脚本进行修改):"
  echo -e "\t 远端 IP:$remote_ip"
  echo -e "\t 远端 KCP 端口: $remote_kcp"
  echo -e "\t 远端 UDP2RAW 端口: $remote_udp2raw"
  echo -e "\t 本地发布端口: $local_publish"
  echo -e "\t 本地 udp2raw 端口:$local_udp2raw"
  echo "服务状态:"

  pid_status $pid_kcptun "KCP"
  pid_status $pid_speederv2 "speederv2"
  pid_status $pid_udp2raw "udp2raw"

  echo "使用方式:  "
  echo -e "\t 运行服务:bash $0 start "
  echo -e "\t 停止服务:bash $0 stop "
  echo -e "\t 重启服务:bash $0 restart "
fi
EOF

运行

服务端/客户端

chmod  x /home/jiasu_run.sh

# 启动
bash /home/jiasu_run.sh start
# 停止
bash /home/jiasu_run.sh stop
# 重启
bash /home/jiasu_run.sh restart

使用截图:



防火墙:

开放脚本中的:6002、29900 端口。
SSTap 连通性测试:

成功运行之后就可以通过,中继服务器 IP:端口 来连接自己加速后的服务。

加速后的 UDP 服务,能有效减少丢包的情况。

网游加速器

一般网游加速器核心是将用户与游戏服务器的距离拉短,或经过稳定的中继服务器,优化路由提高连接稳定性。

即在选择服务器线路上,最好针对你所玩的游戏来选择合适的服务器。

以 GTAV 游戏举例,可以通过抓包获取到游戏的服务器地址。

conductor-prod.ros.rockstargames.com
patches.rockstargames.com
prod.cloud.rockstargames.com
prod.cs.ros.rockstargames.com
prod.p01sjc.pod.rockstargames.com
prod.p02sjc.pod.rockstargames.com
prod.ros.rockstargames.com

prod.ros.rockstargames.com
prod.telemetry.ros.rockstargames.com
prod.anticheat.ros.rockstargames.com
prod.badsport.ros.rockstargames.com
prod.modders.ros.rockstargames.com
prod.bans.ros.rockstargames.com
prod.report.ros.rockstargames.com
prod.reports.ros.rockstargames.com
prod.modder.ros.rockstargames.com

经过测试,无论你在世界何地,连接 GTAV 的服务器都需要连接 telemetry 服务器,我们通过全球 ping 获取这个服务器的 IP 地址。

推荐使用站长工具:

http://ping.chinaz.com/prod.telemetry.ros.rockstargames.com

发现服务器目的地都在西雅图或者波特兰两地,而这两地的实际位置也是很相近。

整理拿到服务器的 IP 地址列表

34.210.149.250
35.215.105.43
34.210.149.250
34.209.49.245
34.215.105.43

还有一个很重要的服务器,我们也进行全球 ping 尝试。

http://ping.chinaz.com/prod.ros.rockstargames.com

我们测出只有一个 IP 地址,也就是 GTAV 中最慢的 192.81.241.100

查看本地到该 IP 的路由跃点

可见,延迟有 273 以上,是非常高了(因为服务器禁 ping,所以只参考最后一个可见跃点 IP 的延迟)

其实,我在此之前,测试尾号 100 的 IP 地址时,服务器所在地也是在西雅图/波特兰两地的,所以本教程依然以波特兰/西雅图为目的地说明。

所以我们需要解决的问题就是跳过中间这些默认的路由节点,直连到游戏服务器。那么可以采用西雅图或者波特兰的服务器,尽量保障本地到服务器之间是直连。

如果本地到波特兰是 160ms 的延迟,波特兰同市机房到 GTAV 服务器延迟为 10ms。大致可以理解,延迟从 274ms 降到了 170ms。

如果你选用亚马逊的服务器,且你有亚马逊内网专线的话,那么你可以得到更好的体验,毕竟可以看到最终路由到了亚马逊的机房中。

参照上文,我们可以选用洛杉矶/圣何塞的服务器,即广州-洛杉矶的服务器延迟 洛杉矶-西雅图的延迟。

在实际使用中我们还会遇到各种各样的网络拥堵情况,比如丢包严重,线路 QOS,出口干扰等。

为了解决这些外界干扰情况,我们将使用一些其他工具将所需的数据包封装起来进行传输,从而减少外界对链接传输的干扰。
ShadowsocksR

SSR 的配置教程有很多,本文不再多说,可以自行搜寻。
服务器信息

文中远端服务器 IP:10.10.10.10

SSR 端口:8388
KCP

kcp 是一款 TCP 双端网络加速神器,可以有效将极差的网络环境改善,从而提升网络畅通率和链接速度。

该工具大致是开放一个端口将数据通过封装,经过 UDP 传输到达目的地,回路也是反向 UDP 回应。

具体参见开源项目:

https://github.com/xtaci/kcptun

由于是双端加速,我们需要在客户端和服务器分别部署,对于客户端还是推荐中转服务器,省去游戏机的繁琐配置。

KCP 二进制文件:

https://github.com/xtaci/kcptun/releases

KCP 安装方式服务器和客户端一样,区别于配置和启动方式不同,故下载安装如下:

mkdir /home/kcptun
cd /home/kcptun
wget https://github.com/xtaci/kcptun/releases/download/v20191127/kcptun-linux-amd64-20191127.tar.gz
tar -zxf kcptun-linux-amd64-*.tar.gz

服务器端:

cd /home/kcptun

cat > run.sh <<EOF
./server_linux_amd64 -l :29900 -t 127.0.0.1:8388 -key eller -mtu 1400 -sndwnd 2048 -rcvwnd 2048 -mode fast2 > kcptun.log 2>&1 &
EOF

cat > stop.sh <<EOF
PID=`ps -ef | grep server_linux_amd64 | grep -v grep | awk '{print $2}'`
if [[ "" !=  "$PID" ]]; then
  echo "killing $PID"
  kill -9 $PID
fi
EOF

KCP 监听 29900 端口,并将数据转发给 8388 端口,eller 是密匙需要和客户端一致,mode 是加速模式,其他参数参见 KCP 官方介绍。

响应速度:

fast3 > [fast2] > fast > normal > default

有效载荷比:

default > normal > fast > [fast2] > fast3

中间 mode 参数比较均衡,总之就是越快越浪费带宽,推荐模式 fast2。

其他参数,请使用 ./server_linux_amd64 -h 查看,更深层次的参数调整需要理解 KCP 协议,并通过“隐藏参数”调整。

下面是作者给的配置样例,适用大部分 ADSL 接入(非对称上下行)的参数(实验环境电信 100M ADSL)。其它带宽请按比例调整,比如 50M ADSL,把 CLIENT 的 -sndwnd -rcvwnd 减掉一半,SERVER 不变。

客户端:

cd /home/kcptun

cat > run.sh <<EOF
./client_linux_amd64 -l :12948 -r 10.10.10.10:29900 -key eller -mtu 1400 -sndwnd 256 -rcvwnd 2048 -mode fast2 -conn 4
EOF

cat > stop.sh <<EOF
PID=`ps -ef | grep client_linux_amd64 | grep -v grep | awk '{print $2}'`
if [[ "" !=  "$PID" ]]; then
  echo "killing $PID"
  kill -9 $PID
fi
EOF

其中 10.10.10.10 位服务器 IP 地址,需要将其更换掉。
启动

sh ./run.sh

停止

sh ./stop.sh

UDPSpeeder

UDPSpeeder 是一款加速 UDP 流量的工具,上面那个 KCP 虽然是 UDP 传输但也只能传输 TCP 流量,所以我们需要这款工具将 UDP 流量也一并加速。

具体参见开源项目:

https://github.com/wangyu-/UDPspeeder

二进制文件下载:

https://github.com/wangyu-/UDPspeeder/releases

在安装部署方面,服务端和客户端也基本一致,只需要区别于启动参数即可。

mkdir /home/speederv2
cd /home/speederv2
wget https://github.com/wangyu-/UDPspeeder/releases/download/20190121.0/speederv2_binaries.tar.gz
tar -xzf speederv2_binaries.tar.gz

服务端:

cd /home/speederv2
cat > run.sh <<EOF
./speederv2_amd64 -s -l0.0.0.0:6001 -r127.0.0.1:8388 -k "passwd" -f2:4 --timeout 1 >error.txt 2>&1 &
EOF

其中的 passwd 可自行更改,需要保持客户端一致。

客户端:

cd /home/speederv2
cat > run.sh <<EOF
speederv2_amd64 -c -l0.0.0.0:7001 -r10.10.10.10:6001 -k "passwd"  -f2:4 --timeout 1 >error.txt 2>&1 &
EOF

设监听本地 7001 端口作为 UDP 数据入口,本地连接远端服务器(10.10.10.10)的 6001 端口(speederv2 端口)进行传送数据。
启动

sh ./run.sh

Udp2raw

Udp2raw 是一款将 UDP 流量伪装工具,本身并没有加速功能,但在复杂的网络环境中,经过将 UDP 流量伪装改善成 TCP 流量(实际还是 UDP 传输)可以达到更稳定的传输。

具体参见开源项目:

https://github.com/wangyu-/udp2raw-tunnel

二进制文件下载:

https://github.com/wangyu-/udp2raw-tunnel/releases

通过上文,我们在成功配置了 UDPSpeeder 和 KCP 的基础上,我们再加上 Udp2raw,将 UDPSpeeder 的流量混淆成 TCP 流量。

也可以一并将 KCP 也混淆了,但我不太推荐再混淆一层。因为本身 KCP 的速度就已经比较快了,再包一层会导致性能下降,网络也得不到好的提升,除非确实 UDP QOS 严重,可以尝试将 KCP 一并混淆。

mkdir /home/udp2raw-tunnel
cd /home/udp2raw-tunnel
wget https://github.com/wangyu-/udp2raw-tunnel/releases/download/20190716.test.0/udp2raw_binaries.tar.gz
tar -xzf udp2raw_binaries.tar.gz

服务端:

cd /home/udp2raw-tunnel
cat > run.sh <<EOF
./udp2raw_amd64 -s -l0.0.0.0:6002 -r 127.0.0.1:6001  -a -k "passwd" --raw-mode faketcp >error.txt 2>&1 &
EOF

需要说明下,在服务器端,6001 端口为 speederv2 的监听端口,而 speederv2 连接的是 SSR 的 8388 端口。

如果要混淆 KCP,那么可以使用这个配置:

cd /home/udp2raw-tunnel
cat > run.sh <<EOF
./udp2raw_amd64 -s -l0.0.0.0:6002 -r 127.0.0.1:6001  -a -k "passwd" --raw-mode faketcp >error.txt 2>&1 &
./udp2raw_amd64 -s -l0.0.0.0:6003 -r 127.0.0.1:29900  -a -k "passwd" --raw-mode faketcp >error.txt 2>&1 &
EOF

对外端口:6002 为混淆过的 Speederv2 端口,6003 为混淆过的 KCP 端口。

客户端:

cd /home/udp2raw-tunnel
cat > run.sh <<EOF
./udp2raw_amd64 -l127.0.0.1:70002 -r10.10.10.10:6002 -k "passwd" --raw-mode faketcp >error.txt 2>&1 &
EOF

如果需要混淆 KCP:

cd /home/udp2raw-tunnel
cat > run.sh <<EOF
./udp2raw_amd64 -l127.0.0.1:70002 -r10.10.10.10:6002 -k "passwd" --raw-mode faketcp >error.txt 2>&1 &
./udp2raw_amd64 -l127.0.0.1:70003 -r10.10.10.10:6003 -k "passwd" --raw-mode faketcp >error.txt 2>&1 &
EOF

本地 127 的 7002 端口对接远端的 6002 端口(udp2raw 转 Speederv2),7003 端口对接远端的 6003 端口(udp2raw 转 KCP)。

如果我们使用了 udp2raw,客户端对应的 speederv2 和 kcp 连接地址需要更改为 udp2raw 混淆后的服务器端口,修改如下:

speederv2

cd /home/speederv2
cat > run.sh <<EOF
speederv2_amd64 -c -l0.0.0.0:8388 -r127.0.0.1:7002 -k "passwd"  -f2:4 --timeout 1 >error.txt 2>&1 &
EOF

kcp

cd /home/kcptun
cat > run.sh <<EOF
./client_linux_amd64 -l :8388 -r 1127.0.0.1:7003 -key eller -mtu 1400 -sndwnd 256 -rcvwnd 2048 -mode fast2 -conn 4 >error.txt 2>&1 &
EOF

简单说明下,最后这里修改了前面的配置,修改后的目的是:

将 speederv2 的监听 8388 的 UDP 数据,将其传送给本地 7002 端口(udp2raw 入口),而远端 7002 端口连接的是远端 6002 端口(udp2raw),远端 6002 端口再转发到 6001(speeder),6001 再转发给 8388 端口给 SSR。

将 kcp 的监听 8388 的 TCP 数据,将其传送给本地 7003 端口(udp2raw 入口),而远端 7003 端口连接的是远端 6003 端口(udp2raw),远端 6003 端口再转发到 29900(kcp),29900 再转发给 8388 端口给 SSR。

因为 KCP 和 speederv2 是分别监听 TCP 和 UDP 协议,所以不会端口冲突。

listen udp [local:8388]  =udp=> [local:7002] =udp fake tcp=> [remote:7002] =udp=> [remote:6002] =udp=> [remote:8388] SSR

listen tcp[local:8388]  =udp=> [local:7003] =udp fake tcp=> [remote:6003] =udp=> [remote:29900] =tcp=> [remote:8388] SSR

此时连接客户端的 8388 端口就相当于连接服务器的 8388 端口,期间还经过了一系列的转换。

最终可以用 SSR 连接 127.0.0.1:8388,如果文中提到的客户端为中转服务器,可省去在 windows 上配置的麻烦过程,以上的 speederv2、udp2raw、kcp 均支持 windows。

服务器端 SSR 端口:8388

服务器端 KCP 原生端口:29900

服务器端 KCP 混淆端口:6003

服务器端 Speederv2 原生端口:6001

服务器端 Speederv2 混淆端口:6002
启动

客户端/服务端均适用

/home/kcptun/run.sh
/home/speederv2/run.sh
/home/udp2raw-tunnel/run.sh

停止

客户端/服务端均适用

pkill -9 client_linux_amd64
pkill -9 speederv2_amd64
pkill -9 udp2raw_amd64

客户端

针对于 windows 上的加速器客户端,推荐采用 SSTAP。因 SSTAP 已经不再维护更新,更推荐 Netch。

SSTAP:

https://www.sockscap64.com/changelog-of-sstap/

Netch:

https://github.com/NetchX/Netch/releases


参考链接:
https://home4love.com/3154.html




No comments:

Post a Comment