继续上次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的故事了。
好吧，我写东西一般都比较乱所以要是看不明白….可以先看看官方文档啥的。就这样拉.
