梦想博客

蹭个热度–V2ray的websocket+tls+webproxy+CDN的配置

继续上次topic,这次我来具体说下我在做v2ray的web+tls+cdn的配置的时候遇到的坑。

废话不说，先贴配置，看的明白的估计就不用看我废话了：

路由透明代理部分：

{
    "inbounds": [
    {
        "tag": "ipsetin",
		"port": 1188,
        "protocol": "dokodemo-door",
        "settings": {
        "network": "tcp,udp",
        "followRedirect": true
        }
    }
    ],
    "outbounds": [
    {
        "tag": "proxykcp",
        "protocol": "vmess",
        "settings": {
        "vnext": [
            {
                "address": "vps IP",
                "port": 64662,
                "users": [
                {
                    "id": "UUID",
                    "alterId": 64,
                    "security": "auto"
                }
                ]
            }
        ]
        },
        "streamSettings": {
            "network": "kcp",
            "kcpSettings": {
            "mtu": 1350,
            "tti": 50,
            "uplinkCapacity": 100,
            "downlinkCapacity": 100,
            "congestion": true,
            "readBufferSize": 2,
            "writeBufferSize": 2,
            "header": {
                "type": "srtp"
                      }
            }
        },
        "mux": {
            "enabled": true
        }
    },
	{
	"tag": "proxywstls",
	"protocol": "vmess",
        "settings": {
            "vnext": [
            {
                "address": "web domain",
                "port": 443,
                "users": [
                {
                    "id": "uuid",
                    "alterId": 64,
					"security": "aes-128-gcm"
                }
                ]
            }
            ]
        },
        "streamSettings": {
            "network": "ws",
            "security": "tls",
            "tlsSettings": {
                "allowInsecure": true,
                "serverName": null
            },
            "tcpSettings": null,
            "kcpSettings": null,
            "wsSettings": {
                "connectionReuse": true,
                "path": "path info",
                "headers": {
                    "Host": "web domain, maybe no need"
                }
			}
		}, 
	    "mux": {
            "enabled": true
	    }
	},
    {
        "tag": "direct",
        "protocol": "freedom",
        "settings": {},
        "streamSettings": {
        "sockopt": {
            "mark": 255
            }
        }
    },
    {
        "protocol": "dns",
        "tag": "dns-out"
    }
    ],
    "routing": {
        "domainStrategy": "IPOnDemand",
        "rules": [
        {
            "type": "field",
            "ip": [
                "geoip:private"
            ],
            "outboundTag": "direct"
        },
        {
            "type": "field",
                "inboundTag": [
                    "ipsetin"
                ],
            "balancerTag": "my-balance"
        }
        ],
        "balancers": [
        {
            "tag": "my-balance",
            "selector": [
               "proxykcp"
            ]
        }
        ]
    }
}
    

VPS服务器端：

{
	"inbounds": 
	[
	{
      "port": 1443,
      "protocol": "vmess",
      "settings": {
        "clients": [
          {
            "id": "uuid",
            "alterId": 64
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "wsSettings": {
        "path": "path info"
        }
      }
    },
	{
		"port": 64662,
		"protocol": "vmess",
		"settings": 
		{
			"clients": 
			[
				{
				"id": "uuid",
				"level": 1,
				"alterId": 64
				}
			],
		"detour": 
			{ //绕行配置，即指示客户端使用 dynamicPort 的配置通信
			"to": "dynamicPort"   
			}
		},
		"streamSettings": 
		{
            "network": "kcp",
            "kcpSettings": 
			{
                "mtu": 1350,
                "tti": 50,
                "uplinkCapacity": 100,
                "downlinkCapacity": 100,
                "congestion": true,
                "readBufferSize": 2,
                "writeBufferSize": 2,
                "header": 
				{
                    "type": "srtp"
                }
            }
        },
		"sniffing": 
		{
			"enabled": true,
			"destOverride": 
			[
				"http",
				"tls"
			]
		}
    },
	{
		"protocol": "vmess",
		"port": "63000-65000", 
		"tag": "dynamicPort", 
		"settings": 
		{
			"default": 
			{
				"alterId": 64
			}
		},
		"allocate": 
		{            
			"strategy": "random",
			"concurrency": 2,     
			"refresh": 3
		}
    }
	],
	"outbounds": 
	[
	{
		"protocol": "freedom",
		"settings": {}
	},
	{
		"protocol": "blackhole",
		"settings": {},
		"tag": "blocked"
	}
	],
	"routing": 
	{
		"rules": 
		[
		{	
			"type": "field",
			"ip": ["geoip:private"],
			"outboundTag": "blocked"
		}
		]
	}	
}

希望不是很太影响阅读，毕竟我的Blog似乎对代码支持不是很好。毕竟我实在不是个会写代码的人。

首先来说服务器端。

这里实际上是3个大的部分，1个inbound的，KCP+动态端口配置， 一个是inbound的websocket入口配置。然后剩下就是直接freedom的outbound的配置。

事实上并不复杂, websocket入口在v2ray的服务器端，其实就是把network的类型改成ws, 并且把path配置写上对应的参数，v2ray服务器端其实就完事了。并没什么特殊。

然后我们来看透明代理端，我的配置里是1个inbound+2个outbound+load balance，其实一般只用一个，但是我为了自己方便，所以把个outbound都留着，这样我只要用一个load balance参数就可以直接切换了。

这中间呢，inbound使用的是v2ray官方推荐的dokodemo-door协议，基本也不用研究照抄就是了。

而跟websocket相关的其实只有第二个outbound配置，就是把目标设定为域名地址，然后再steam里配置了ws跟tls的那些。记得path的参数要能匹配的起来。以及端口一般用443去访问服务器端的webproxy.

然后就是重头戏了，我们怎么来处理我们的tls并且伪装成一个合法的https网页。

首先，到现在为止，我们的配置都是为了让我们自己这边的client端直接去访问我们在海外的VPS。所以，理论上，如果我们不管tls啥的，那么2端的端口号匹配的情况下，其实是就能直接通信的，我配置上KCP其实就是这样工作的。

但是，你们这样的思想很危险啊胸带。。。

因为实践证明，GFW是无所不能的，DPI下几乎完全无所遁形，各种特征指认都给你安排的明明白白，不是封端口就是封IP.

所以，从某种角度来说，我们需要tls封装来隐藏自己流量的特指。而tls最常见的情况就是https端口的网页。

所以，最容易实现的，就是在海外vps上再搭建一个简单的webproxy，把我们的流量伪装到https的网页流量用tls加密然而再由proxy转发到服务器端的v2ray。

所以这中间我们需要一个可以实现https的代理。

v2ray的手册上推荐的是Nginx, Apache和caddy.

我选了caddy,因为够简单，不用我自己管理域名。

不过如果你的域名还想加载cloudflare的cdn,那么谨慎选择，中间有个坑，带我详细说来。

caddy的安装配置不复杂，配置文件如下：

domain.name
{
  log /var/log/caddy/caddy.log

  tls   {
        dns cloudflare
        }
  proxy / https://website.com
  proxy /v2ray/web localhost:1443 {
        websocket
        header_upstream -Origin
  }
}

我选caddy是因为caddy会自动向letsencrypt 申请证书维护证书，所以省去了我去管这个东西的事情。

但是，因为我的域名用的是我blog的这个网站。所以我早就在cloudflare上有证书了。所以我是起了个二级域名挂在caddy上，想着让caddy自己去管吧。我在cloudflare上写个cname直接指向我vps的DNS名字就完事了（以为封IP端口的问题，我改用DNS名字而不是IP地址了这样我就可以随便改IP了）。然后caddy就各种申请证书出错。

然后一顿搜索以后，发现问题是可能因为已经有证书？所以要用caddy的一个cloudflare dns插件来引导caddy直接去cloudflare拉证书。

然而还是不行，懵了。

后来github上搜索到有人说用cloud dns插件的话，cname是不行的，要用A记录。似乎跟我一样，试试看，改了cloudflare的DNS记录。舒服了。

caddy可以起来了。

所以，要用caddy的，要么来个新的域名直接上。要么就做好可能处问题的准备。

你们会看到我的caddy的配置是有2条proxy的。

直接访问“/”根目录的会直接转发到你现在看的这个blog。这样就不会出现一直有巨大流量到这个IP但是却是个404页面的尴尬逻辑了。

然而下面，写了更加具体的“/wspath”的path参数的这条，才会把流量导入到local host的一个特殊端口，而这个端口就是vps上v2ray ws用的inbound端的端口号。

记住不要用443在这里，虽然我们的client端写的是443，因为我们从client端出来的目标是web proxy，而caddy一起来就会占用443跟80..所以从proxy到v2ray的端口需要用另外的，反正一般是同一台服务器所以可以随意别跟其他的重复就可以。我一开始没注意这个都用443然后就把自己坑了。唉..

到这里了，我们为tls准备的从客户端到服务器端的链路就基本打通了：

PC—路由器—路由器v2ray透明代理—vps web代理—vps v2ray—目标网站

这样的情况下，我们从本地到远端VPS的流量会被TLS包裹所以内容被加密了。

但是，GFW不care你加密啊。。。他可以直接把你IP封了啊。。。然后你号就没了。。。没了。。。没了。。。

所以，我们还是不够安全。

但是，既然从路由到vps这段我们走的是网页流量。。所以理论上，我们是可以使用CDN加速的。而CDN一加速，DNS记录上给出的IP就不是我们VPS真正的IP而是CDN服务的edge server IP. 那我们实际的VPS岂不是美滋滋？

所以，在前面的都可用的条件下，我们可以把我们的域名找个CDN加速服务弄上，然后确认下证书tls没问题以后。我们就可以通过CDN加速来隐藏我们真实的IP来保护我们的VPS服务器。

这就是使用V2ray完整的Websocket+tls+webproxy+CDN的故事了。

好吧，我写东西一般都比较乱所以要是看不明白….可以先看看官方文档啥的。就这样拉.