简单陈述：V2ray WS+TLS+CDN的情况下借用CF的三方功能自定义DNS IP的调优

在通常情况下，我们为了自己翻墙的稳定性，在套用了WS+TLS+CDN（Cloudfare）以后，由于大概率使用的是cloudflare的CDN服务，而CF在免费服务情况下，给出的IP大部分时候并不是很友好。

所以，从某种角度上来说，如何我们可以自己控制CF的CDN接入IP，那么我们就可能在一定程度上优化我们自己去到墙外的速度。

这个做法其实在早先就有，我也是在最近才发现。

先陈述下WS+TLS+CDN的原理：

简单来说，就是我们本来的流量是直接去到墙外的服务器，现在因为使用了TLS+CDN的服务，所以我们就跟蹭了车一样，让自己的流量混进了CloudFlare的大量的分发流量里，走了CF一个中转，先到CF的服务器，再到我们自己的翻墙服务器。

所以就是：

原来：用户端—->服务器

现在：用户—->CloudFlare CDN—–>服务器

并且因为CF的支持，所有这路上的2段都可以完全使用TLS加密流量。所以我们就会有一个完整的端到端的加密流量出墙并且因为混在大量的CF流量中，相对来说特征也不显著。

但是CF的免费IP基本都是在美国那端，所以我们等于是我们的流量得先去美国转一圈。所以这个ping也好速度也好就不那么美好。

所以，我们想定制CF的DNS，自己控制给出的IP地址来保障我们可以尽可能得到比较好的IP.

CF本身在免费帐号下是不支持DNS定制的。

但是CF有一个partner 计划，可以支持我们把需要使用CF服务的域名托管到第三方的DNS服务商那边。

就比如我正在用的萌精灵，以及其他的一些国内国外的小型的DNS服务商。

在启用了这些3rd的DNS服务商以后，我们就可以定制你的DNS了。

然后就是理解的第二步。

我们可以在这些3rd的DNS托管下，再把域名的解析服务器丢到国内的比如DNSpod服务器上。

为啥要用DNSpod上呢？因为只有国内这些DNS解析，才会支持针对不同线路去给出不同的解析结果。

所以我们的域名解析的路径就变成了：

CF–>moe–>DNSpod。

中间一般都是用cname来报障各级服务之间的互相识别跟权属确认。

但是最终的域名A记录都是由DNSPod来管理。

这时候，我们可以自己去觉得自己的域名究竟用那个CF的IP

比如我现在的配置就是电信线路用1.0.0.0

联通线路用HK的104.x.x.x的IP

反正只要知道自己用哪个比较快就可以用哪个拉。

CF的IP有哪些。。这个问题就自己搜索吧。反正我给不出完全可靠的就不乱写了。

蹭个热度–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的故事了。

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

在彻底失去知情权之前再挣扎一把___花了一个周末把V2ray搞清楚了

为了保持自己那么一点点信息权力。

为了在彻底失去知情权之前再挣扎一把，这个周末，我花了2天，把现在当红的V2ray给折腾了一遍。

总的来说，v2ray在综合能力上确实要比ss或者ssr来得强大不少，毕竟本体就结合了多入口，多出口，DNS，路由选择，多种协议以及加密通信支持乃至于load balance.

但是同样的，功能的复杂以及自由度的提升，一样也造成了配置文件的复杂化，所以就没有那么即开即用化，友好程度明显降低。不过主要的难度还是集中在服务器端或者中转代理的配置上，用户端相对来说，在一些图形化client的帮助下，一般用户还是不难去掌握使用的。

我这次主要是为了让这v2ray能在我的ERL3上能顺利运转起来做透明路由（原先的SS花式断，基本废了。原因大家都理解），所以跟一般的客户端配置略有差异。不过能理解就行，毕竟逻辑跟原理是一样的。

首先值得高兴的是，ERL3在升级到2.0.x版本的固件后，后台的Debian内核也升级到了9.x…所以，习惯于用shadowscoks-libev 版本的同学，可以直接用APT安装了。并且，v2ray的官方go.sh安装脚本可以无障碍的直接在CLI下运行，完全不需要担心兼容性问题。

VPS端就不阐述一起必然需要的准备了，相信大部分DIY的留学生应该还是很熟悉这套操作的。

简单的来说，vps服务器端跟本地透明代理端，运行的东西完全一样。v2ray的官方文档也写的很清楚，v2ray本身并没有服务器端跟客户端的区别。所以除了配置文件的不同，2者其实是完全一样的东西哦。

所以我们要做的就是：

  1. 安装v2ray
  2. 写v2ray的配置文件
  3. 运行

听上去跟把大象放进冰箱一样的简单呢。

一切的关键都在配置文件里，很清楚了吧。

v2ray使用的是非常常见的JSON格式的配置文件。粗略的项目如下：

{
  "log": {},
  "api": {},
  "dns": {},
  "stats": {},
  "routing": {},
  "policy": {},
  "reverse": {},
  "inbounds": [],
  "outbounds": [],
  "transport": {}
}

简单的说就是这些模块的组合就能让v2ray工作起来。

其中我们一定需要理解的是，inbound, outbound以及routing。log最好能明白因为排错会很方便。 dns看需要，我个人更喜欢用gfw+ipset的分流，并且用ubound做DNS over Tls的解析。。所以dns我完成没涉及。但是据说很不错。至少看着能解决投毒的问题，所以也是值得研究的。

至于具体的inbound, outbound有哪些参数啥的，我个人推荐直接查下官方文档然后找几个配置example理解一下。应该还是不难理解的。

然后我们从逻辑上大概理解下v2ray是怎么工作的。

从本质上来说，v2ray，跟ss和ssr他们没有根本的区别。都是一样的代理转发工具。虽然v2ray更大更强更威猛，但是说到底他还是个二道贩子。主要的功能就是为了把从inbound进来的东西从outbound转发出去。就这么简单。

到了这里，有一点就很清晰了，就是client端的outbound的配置，需要跟server端inbound的配置相对应，这样双方才能平等交流互信互惠，一切都遵循和平共处五项原则。

我们来看个配置文件的实例，抄自白话版v2ray教程：

{
  "inbounds": [
    {
      "port": 16823, // 服务器监听端口
      "protocol": "vmess",    // 主传入协议
      "settings": {
        "clients": [
          {
            "id": "b831381d-6324-4d53-ad4f-8cda48b30811",  // 用户 ID，客户端与服务器必须相同
            "alterId": 64
          }
        ]
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",  // 主传出协议
      "settings": {}
    }
  ]
}

这里其实就2个模块，一个inbound用来解决输入，一个outbound用来解决输出。至于中间的vmess, 这个是v2ray私有的通信协议，但是应该已经可识别特征，因为我在tcp模式下不管加不加伪装都被灭过不止一次端口。剩下的端口啊， id啥的。。都是一个作用。就是匹配握手。

所以把大的部分拆开了，还是不难去理解的。

那么v2ray就那么简单？显然不是啊。

为啥它牛呢，因为你现在看到的只是前面的部分，后面经过简单计算推导的结果还没出来啊。

因为v2ray的特征是模块化，并且本身就已经携带了如vmess, mKCP, shadowsocks, Mux，并且支持websocket, HTTPS, HTTP/2等多种协议，所以其本身的自由度非常巨大。即使不考虑商用多用户多服务器等大规模管理，我们依然面对了非常巨大的选择空间，从协议上，是选择shadowsocks还是vess. 通信的标准上使用tcp还是mKCP, KCP用静态还是动态端口。websocket是否需要加tls等等一系列的可供选择的配置。

一般而言，我们常见的是直接从客户端转发到海外VPS端的方式，这样是最直接最容易实现的，只要vps配置完，自己设备上有个v2ray能用的client端，GUI填一些简单参数就很容易搞定。

然而其次，就是我折腾了2天的网关/路由器透明代理。这种方式，对大多数用户其实跟第一种差不多，因为现在梅林啊，老毛子，LEDE等各种固件都集成了各种插件，这些插件用起来也不用自己写配置文件，GUI填下就好了。

我只是因为穷，买不起那些好用的，才只能手工自己写，踩了无数坑之后才搞定了。所以说，有钱就是可以为所欲为啊，哈哈哈。

v2ray还有一种链式代理的工作方式，是类似多重代理的方式。很玄妙。暂时我还没用到所以没有深入研究。

这样可能产生的配置组合就很多。现在比较常见的配置组合是，mKCP动态端口直连；websocket+tls+webproxy;以及号称最牛的组合：websocket+tls+webproxy+CDN的组合。

鉴于太长不适合阅读，我会在下一篇介绍下websocket+tls+webproxy+CDN的配置的一些细节以及我踩的坑。希望能我自己下次别再踩一遍。

记在ERL-3存储再次大破以后

  1. 台电的U盘是真的次，1年9个月以后读写错误，系统大灭。
  2. mkeosing这个Github上的脚本非常赞….最大的好处是，你可以定制给EdgeOS划分的数据分区的大小，可以根据自己U盘大小来而不是原先系统指定的2G. 而且简单易用，比进内置的引导系统再用工具直接重做来得更加容易直接。 https://github.com/sowbug/mkeosimg
  3. 狗东的服务不错。新买的U盘是迅速送到了。同时挂掉的台电U盘因为还在保，JD提供了售后服务。给了2个选择，原价的7折退钱或者换个同品牌的一样容量的。毫无悬念的退了钱，舒服。
  4. ERL-3，或者说EdgeOS在越来越多的人的研究跟贡献下正在越来越好用。比如之前IPTV我能找到的资料并不多。现在基本上就可以找到很多可以参考的。随便找找就发现了ER-4做的单线VLAN直通到交换口解决IPTV AB面验证的配置了。我又可以省下2个交换的口了。
  5. 最新的EdgeOS的是基于Debian 9的。有能力升级的同志们都可以升级下。因为在9的repo里。。某个奇妙的梯子是可以直接APT 安装的。不需要去研究啥交叉编译拉。
  6. 细节决定命运啊，我从默认目标下cp出来的config.json没有local IP的配置。。导致我个傻X一晚上没想明白为啥流量过不去。结果跟上次在服务器端一样，那次是没配服务器地址，这次是没有local ip的选项导致绑定问题。
  7. 上海电信至今不给IPv6….虽然不是啥必须的但是我想玩呀。
  8. VLAN 51这个IPTV传说的组播VLAN。。。究竟有没有用啊，很玄学啊。今天搞了一天这个，最终是关了Cisco 3750的IGMP Snooping解决的。不过vlan51…我现在是根本没加进去啊在路由上。那这个组播的VID需要只在光猫上存在就行？
  9. 我想买ER-4……..啊啊啊啊

Supervisor on EdgeOS是真的好用啊~~

因为要在ERL3上挂SS跟ChinaDNS…所以在后台进程是有Linux管理的ChinaDNS以及ss-redir…

但是不知为啥…ChinaDNS跟ss-redir, 尤其是chinaDNS,会莫名就总结.

后来一段时间用Crontab的定时任务把ChinaDNS跟ss-redir定时重启.

不过总觉得这管理方式很土.

最近换了Supervisor…感觉各种好…很稳, 自定义配置文件,有log 记录..甚至于还能做web查询.完美…

ERL-3现在用的系统没有systemd, 以后估计也未必有..所以暂时来说, Supervisor应该算是很不错的选择呢..

 

Cisco packet tracer 模拟BGP的一点感受

最近因为工作关系, 需要做一些混合着3层交换, 路由, MPLS-VPN, IPSec Tunnel等环境的模拟.

因为我用GNS3实在无法完美模拟出3层交换机…所以退而求其次用了CPT, 因为最近发现更新到了7.0版本,而且CPT一直比较容易用,是我这种菜G比较喜欢的.

首先至少能用BGP了, 这个据说是5.x开始的进步算是弥补了以前连用都不能用的尴尬.

不过只能支持E-BGP不能用I-BGP这点我挺意外的…本质上没那么大差别啊..居然不支持…

然后发现手工汇率network的情况下只能配置静态到Null 0再用network宣告, 没有aggregate-address 命令.

三层路由可以直接起BGP, 如果在GNS3上只能用路由器加交换卡来模拟….虽然差不多应该不过我怕有东西不一样啊

IPSec Tunnel也比较容易就实现了…不过总觉得Cloud这个设备不太好用….最终是配了帧中继来模拟公网IP互联的….其实我想偷懒直接配公网IP互联的..

防火墙型号只有ASA-5505….因为公网互联用了FR的关系所以我没用这个架VPN…而且因为型号略旧了…跟新的那些ASA系统差别有点大…所以就算了.

 

总的来说,易用性一直都是CPT不灭的优势….不过相比GNS3对于设备的精确模拟来说, CPT的模拟确实有点out of date.

不过对于环境要求没有那么高只要随手能用的情况下, CPT还是挺好的…而且画图很方便…咔咔

 

 

黑五是个好东西!

黑五期间各种优惠~~域名主机也不例外~~

刚刚把Blog从siteground搬家到了Hawk..因为siteground续费比买的时候几乎翻倍价格.

反过来看,Hawk的价格是2年200多,续费价格一样..简直白送,对于纯粹堆个人blog来说太便宜了..

挂了新加坡的DC,发现速度完全不行….查了下路由

中国–美国–日本–新加坡…

半个地球绕了个来回….

开Ticket换DC,搬到了HK, 路由其实类似….我真的觉得Softlayer该死CN2该死啊….

不过至少响应比较正常了….先不管了,挂上Cloudflare用上了再说吧…

等下去看下namecheap的域名续费是不是也便宜就齐活了..

 

记折腾4K IPTV的周末给自己带来的新知识

上个月家里宽带升级了200M, 顺带看到可以免费享受一路4K的IPTV.

其实一直都知道电信的宽带可以免费申请IPTV, 但是一直都没弄, 主要原因是一直都没找到合适的办法去只用一根网线来解决我上网出口跟IPTV的问题..曾经看到一些方案但是都觉得不合适或者说不够理想, 而在几周前,在Chiphell毒坛看到了一个近乎完美的解决方案https://www.chiphell.com/thread-1421026-1-1.html, 这样一来4K的IPTV自然就可以顺理成章的入住了.

申请过程很简单, 直接找电信客服提供信息就可以安排安装了, 连个合同都没其实, 但是却要求1年的锁定期…电信也是可以…

在电信安排安装之前的一周里, 我先对自己内网做了一个简单的调整来保证新的IPTV实现方案的基础.

简单描述一下原来的网络结构:

电信光猫—-ERL3路由(PPPoE拨号+DHCP+DNS+SS…)—HP 2910al交换机—终端

基本上结构无论是逻辑还是单一方向的, 物理接线也是光猫出来的线直接进入路由器再从路由器进交换机.

在调整完以后:

电信光猫—HP交换机(WAN VLAN+IPTV VLAN)—ERL3—HP交换机(LAN VLAN)—终端

盗用一下Chiphell上作者的解释图:

qq20151223-12x

从物理连接上就变得复杂了, 光猫出来的线路先进交换机, 脱标以后的WAN数据进如路由器, 打标的IPTV 组播数据会直接通过VLAN trunk去跟IPTV做交互.

所以整个方案的核心就在于:

  1. 需要交换机使用Trunk线路来同时承载上网数据跟IPTV数据
  2. 在交换机中将2类数据分离开来并且送到需要去的地方
  3. 路由器的DHCP能为IPTV提供需要的配置参数.

所以折腾的点就变成了:

  1. 交换机的VLAN配置
  2. 路由器的DHCP Option

事实上交换机的VLAN配置并没有什么大的挑战, 因为我自己之前的环境内本身就是多VLAN的, 所以无论是设备的支持与否以及能做到什么程度都很清楚.

所以其实只是在交换机上多加了4条VLAN:

  • VLAN for WAN, 专门的2个口用作光猫LAN口跟路由WAN的连接, 目的就是让光猫到交换机的线路变成Trunk状态可以同时承载多VLAN的数据.然后从另外一个出口把脱标的上网数据送给路由器做拨号. 而打标的IPTV组播会从trunk线中的其他VLAN回去到光猫. 这个就实现了我们需要实现的关键功能第一跟第二个核心点
  • VLAN for IPTV, 这个是我专门给IPTV开的一个VLAN, 实际是可以不用的, 可以使用之前已经存在的LAN VLAN来代替. 不过考虑到IPTV需要特殊的DHCP option 参数, 所以我特地开了一个独立的VLAN出来接IPTV, IPTV的公网接口就是从这个VLAN出来再从路由的接口出去的.
  • VLAN 85 跟 VLAN 51, 这两个是IPTV专网使用的组播VLAN, 用来承载电视数据, IPTV会通过这个VLAN直接跟光猫通信跳过路由器. 所以实现第二核心点的重点就是VLAN的划分

到这步为止, IPTV需要的在交换机上的准备就完成了.

剩下的事情就是DHCP的问题了…

因为没用过以前的IPTV所以我不确定是什么情况, 据说比较新的版本是只要能上网就能用了.

而新的4K IPTV是需要所谓的跨越AB面认证的, 从我的认识上来说, 就是先要拿到Internet的access, 再通过VLAN 85拿到专网的IP.

公网access的IP简单, 常规DHCP的配置就行. VLAN85的配置, 根据众多前辈抓包对比以及查阅《中国电信家庭网关总体技术要求》说得到的信息来说，就是需要在第一步的公网IP的DHCP过程中，携带上Option 125的信息,

dhcp

option 125中的信息会告诉Client VLAN85的存在.

具体请参考这里:http://koolshare.cn/thread-43568-1-1.html

所以我就需要给IPTV VLAN的DHCP server必须要可以发送Option 125出去.

然后重点就来了.

我本来天真的以为只要配置上了DHCP Option 125, 那么Client来申请的时候option会被附加上, 然而事实证明我还是太弱鸡了.

不过既然这么想了, 肯定先要把option 125这个配置能正常生成了才行.

所以我去爬了一下Ubnt的国内外论坛, 了解了自定义DHCP option的配置方式, 相对来说还是比较容易实现的.

set service dhcp-server global-parameters “option option-125 code 125 = string;”

set service dhcp-server shared-network-name VLAN_50 subnet 192.168.5.0/24 subnet-parameters “option option-125 00:00:00:00:14:02:06:48:47:57:2d:43:54:0a:02:20:00:0b:02:00:55:0d:02:00:2e;”

2条命令就能在ERL3里面自定义出来一个option 125来..不得不说Ubnt的货实在是自由度高到没边啊…

然后我就用Windows上DHCP test去做测试了..

这是个很小的带抓包功能的测试工具, 基本功能就是检测网卡通信中的DHCP包并且抓取下来, 以及模拟一块新的网卡去discover DHCP.

DHCPtest出来的结果很令人振奋呢, 可以直接看到Option 125在offer包里呢!

所以我就很放心的去等IPTV的安装了…

然而事实证明一帆风顺总是小概率事件, IPTV在完成安装以后直接就跳了认证失败, 网络信息显示公网正常专网拿不到IP地址.

这时候我就觉得这怎么可能..

回头再用DHCTest测试, 明明是有的啊…这时候我都怀疑是不是Option 125给的raw data是否会错了…不过考虑到以及被很多人实现过额, 所以code出错的概率其实很小.

所以, 这时候只能启用交换机的镜像端口去抓IPTV说产生的DHCP包, 结果令我诧异的是根本没有Option 125的数据被附加上去.

这时候我才意识到, 前辈们使用DHCP-option-Force的参数给Dnsmasq来添加Option 125的意义, 就是为了强制把option 125推送除去啊…

然而我不想换Dnsmasq啊, 因为ERL3的web页面管理使用dhcpd来实现的, 很清楚很好用啊…

这时候我已经再想要不要把raspiberry给翻出来专门给IPTV作为DHCP sever来服务了, 因为手头能尝试的办法跟能查询到资料已经大多过了一遍了, 对于EdgeOS的系统上如何实现强制option完全没有涉及.

不过天无绝人之路, 在再次搜索查看信息的时候, 注意到了Linux 的DHCP Man Page里对于Option 55的描述是如下的:

“option dhcp-parameter-request-list uint16 [, uint16… ];This option, when sent by the client, specifies which options the client wishes the server to return. Normally, in the ISC DHCP client, this is done using the request statement. If this option is not specified by the client, the DHCP server will normally return every option that is valid in scope and that fits into the reply. When this option is specified on the server, the server returns the specified options. This can be used to force a client to take options that it hasn’t requested, and it can also be used to tailor the response of the DHCP server for clients that may need a more limited set of options than those the server would normally return.”

也就说, 只要能给服务器定义出这样一个option, 服务器就会自动根据配置的option list强制给client发送option 信息, 这不就是我要的嘛.

然后赶紧去查Ubnt怎么配置类似的参数, 还真给找到一个:

于是就有个如下的2个配置:

set service dhcp-server global-parameters “option option-55 code 55 = array of unsigned integer 16;”

set service dhcp-server shared-network-name VLAN_50 subnet 192.168.5.0/24 subnet-parameters “option option-55 3,6,58,59,125;”

第一行是定义一个option 125的参数名字, option code以及数据类型

第二行是在对应的子网下, 定义出需要强制发送的Option List.

这里需要注意的是, 在有了55以后, 很多以前被认为理所应当会被DHCP server发送的option就不发了, 比如option 3的网关信息, Option 6的DNS server 信息等等.. 所以无法偷懒只写一个125.

然后就是享受HD IPTV的时间了…

总的来说, 整个过程因为前人的大量实践, 所以并不是特别曲折, 只是因为设备本身的配置以及功能区别的问题, 所以给了我一个去深入理解DHCP以及Option的契机, 在几天时间内大量的翻阅跟DHCP option相关的文档以及配置案例, 对整个体系的理解有了一个新的认识.

所以说, 在实践出真知啊!! 人生不折腾还有什么意义呢?

限制滴滴们的背后

今天, 因为网约车新政而导致的滴滴相关的讨论大量出现在了各个热门的社区以及各种圈子内…滴滴涨价的说法也甚嚣尘上..

从各地的政策上,统一口径的就是收紧对于网约车平台的监管, 增大对于车辆的准入限制以及司机资格的限制.

魔都跟帝都就更绝一点..直接导入了户籍制度作为撒手锏.

我们不能否认滴滴快递们为出行市场做出的贡献…至少让很多人有了方便快捷的出行方式.

滴滴们的出现让我们能方便的叫到需要的车辆,比以前傻等要容易的多,也不需要给出租公司付电调费用.

红包和补贴的存在又大幅度拉低了费用, 提供经济上巨大的利益.

然而同样的,滴滴的出现, 直接导致了曾经作为魔都一大招牌的出租车已经完全沦陷..各种拒载挑客等在魔都原本几乎不会出现的情况在有了滴滴等打车软件以后层出不穷, 最大的问题就是司机不愿意拉小单,以前要是不拉就要在马路上转.现在完全可以在手机上等着, 所以近距离的出行反而变得麻烦了.我想很多人都有在风雨天叫车不加价根本没车接单的尴尬情况把.

其次就是, 现在已经没有黑车这个概念了…以前交警还要费力整治的黑车已经通过滴滴等完全洗白…变成了专车快车顺风车, 所以黑车已经成为历史…然而这些曾经被认为是不安全隐患的黑车是消失了还是变好了?都不是…只是他们套上滴滴们的合法外套, 不再需要在地铁站单纯的等待…而是可以用手机直接解决客源问题了而已. 所以说, 一个软件就解决了曾经整个社会都谈之色变的安全问题了?

我曾经认为滴滴们的崛起会是倒逼出租车改革的一大动力, 然而在滴滴完成了事实垄断, 价格逐渐太高以后, 我觉得滴滴本身反而变成了需要改革的对象, 因为本身共享经济特性所提供的价格优势不再, 服务水平不会比传统出租更高,而安全监管水平差的多的网约车, 凭什么跟每个月交着份子钱的出租车在一个价格水平上?

如果说滴滴大幅度的解决了市场需要的运力问题, 那我可以说, 黑车也解决了这个问题, 而且还便宜…请问2者有什么本质的区别吗?

那么我们回到这次的限制政策上, 大部分的政策的情况就是要造成滴滴网约车必须要提供差异化服务, 车子要好要新,服务要好.

这也就意味着,把大量廉价的黑车级别的车辆运力淘汰出市场. 至少我是觉得如果真是为了安全舒适考虑的话没什么不好的.

至于户籍限制, 除了魔都帝都应该都没太大意义….至于2个超级城市, 我想住这里的都能理解这个户籍背后给人带来的种种标签意义.

我并不认为增加司机的户籍限制是个合理的行为, 不过如果说要为了限制比亚迪秦这种可以直接拿沪牌的车, 那么剩下的招数也着实不多了, 我估计真要说要求房产证什么的做证据那抵制的声音可能比现在说歧视的声音来得更大吧.

从另外一个角度去想, 很多原本靠着滴滴过日子的司机师傅, 可能因为这样的变故, 直接就回老家了. 我不得不想着, 这应该也是政府人口导流的一个措施吧..毕竟魔都跟帝都都是指定了人口限制计划的地方, 基本上不会再考虑外来人口的舒适度了, 这已经是既定方针, 既然这样, 出台这种政策也就没撒大惊小怪的了.

至于滴滴一直在呼吁的运力大幅度下降的情况, 我预期一定时期内确实会存在, 不过只要需求在, 市场在, 那么必然会有解决的办法…以前的黑车后来的滴滴, 哪个是原本就有的东西?

或许为了吸引新的司机队伍, 滴滴就不得不加大补贴的力度了呢?

至于提价…我相信会消费者始终都会用自己的脚来投票的…如果滴滴不想要这块市场, 那么我觉得别人会很乐意看到的,比如摩拜单车也许哪天就变成摩拜租车了…

当然受伤最深的应该就是现在的专职滴滴司机了….如果直接被扫地出门的话, 他们这些近年来完全依靠滴滴生存的人可能直接就没有了立足的根本了.

不得不说, 无论是滴滴还是快递公司们, 他们间接的解决了大量的剩余劳动力, 也解决了中国这个巨大市场的最终末梢的流通环节.

所以, 怎么解决这些人的出路, 可能会是一个不大不小的课题….希望, 能有个妥善的办法吧…

整个事情的背后, 尤其是滴滴的回应, 给人的感觉更像是拿着消费者跟司机们去跟政府讨价还价…多少有点给人一种垄断要挟的感觉.

我不清楚政府制定政策的人是站在什么角度去权衡的, 但是, 从我的角度去考虑, 保护坐车人的安全是第一位的, 其次才是司机跟消费者的经济利益.

所以滴滴只谈经济问题, 不谈监管问题多少有点避实就虚.

而政府政策的收紧, 我看不清楚目的跟动机是什么, 所以多少有点矫枉过正的感觉, 所以引起的反弹确实有点大..

只能希望市场本身能给出一个相对合理的解读然后做成适当的反应, 去解决这个长期困扰各大城市的民生问题了.

BYOD?CYOD?究竟为了什么?

最近在看RemoteAPP的东西，串到了VDI上，然后想应用场景。无非就是BYOD啊，远程办公啊等等。

然后回头再想一个用户端的问题，我为什么要BYOD呢？对我有什么好处啊？

我猜很多用户的心理的自己用的东西用着顺手，程序员等IT类用户尤其。另外一部分是因为便携，希望随手拿起一个PAD就能查需要的东西，公司的高管可能会更倾向于这个。

那么问题来了，这些其实都不构成真正的所谓的用户需求， 只是用户习惯的问题。

从本质上来说，东西用得不顺手的问题，最根本的原因还是公司的deceive catalog问题。

如果给我选，在公司能提供给我自己一样型号甚至更好的新硬件的情况下，我随便怎么样也不会想着把自己的设备带进来。

那么公司的catalog为什么不够大呢？因为要标准化啊，可是现在连BYOD都能用了，这个标准化不就名存实亡了？

然后另外一个优势是成本优势，然而这要求纯粹的BYOD的，公司完全不提供员工硬件的情况下才能实现，这几乎是不可能的。就算真有员工有这样的意向，一般情况也会要求相应的现金补偿，毕竟是要用自己的硬件来干活了。

所以现在有另外一个说法，叫CYOD，Choose your own Device.

基本上就是把BYOD的思路变成了公司采购，最大化公司的catalog满足用户的需求。

从设备端来说这样其实就解决了用户的问题。

那么反过来从管理端来说，为了满足BYOD/CYOD等多样性设备接入企业网络，IT这边又要做些什么呢？

最首要的就是安全管理。

BYOD的设备是用户自己的设备，CYOD的设备很多是非标准windows客户端，想用传统的AD管理收回用户的管理员权限基本没戏。还有大量的移动端等设备，如果为了安全等考虑，则必须全部都用MDM管理起来。

这样的管理方式的思路其实还是基于传统集中化管理的方式，区别只是以前使用AD来管所有的桌面端，现在是用MDM或者类似的工具来管理几乎所有的移动端设备。

那么为了完成这样的一个集中管理，IT不得不去搭建管理平台，MDM，Landesk，或者SCCM等等类似的。

无论采用何种方式，最终的结果仍然是IT要去尽力集中管理所有的接入设备，最好能做到完全的接入控制，从用户端来控制企业内部网络的安全。

做的再多一点的，直接就上整套VDI系统，把桌面系统跟用户设备直接隔离。这样可以无视用户端的系统平台并且尽可能的将办公环境的网络跟数据中心网络的数据交换做隔离。

但是这一切的一切，其实都是要另外的投入的，无论是硬件还是技术人员的投入。

那么BYOD或者CYOD这些方案的最终目标究竟是什么呢?能带给企业什么样的竞争力呢?

至少我很疑惑。

从经济角度，为了接入安全加大的投入可能会抵消轻量化客户端带来的收益。

从管理角度，无法标准化的客户端急剧增大管理的难度。

从安全角度，因为大量的无权限管控的客户端的存在，从客观上增大了网络被攻入的原因。

所以，我个人对于BYOD带来的收益表示怀疑。

相对来所， CYOD由于仍然属于公司的资产，所以至少在强管控上是可以轻松达成的。相对纯粹的BYOD, CYOD或者混合的CYOD/BYOD可能才是更加合适的情况。