标签: 草稿

蹭个热度–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……..啊啊啊啊

网络模拟器神器之EVE-NG on Hyper V

事实上在去年中的时候, 因为要做一些BGP的测试的时候就已经发现了EVE-NG这个东西…因为感觉总体要比GNS3来得好用并且强大就关注了下,不过因为那时候没有专门的虚拟机Host, 跑在本地的VMworkstation上感觉不是很舒服…所以就随便用了下就没仔细研究.

趁着春节期间自己的DIY Nas正式上线, 强大的E3 V5 CPU+远大于Gen8的内存, 我就毫不犹豫的把Hyper-V架了起来(为啥是Hyper-V而不是ESXi? 因为ESXi自己管硬盘太菜啊….直通到Node机再绕回来的方式我实在不喜欢…而且Windows Host本身可以解决很多日常用的东西足够了…VM Host只是副业而已).

然后…我发现EVE-NG的安装…是不建议用Hyper-V的….开发人员只有Bare跟VM的选项…好吧…我是不会为了这个去改成用ESXi的…所以我觉得先装了再说…不行就workstation呗.

事实上, 安装还真的有很多坑…我尝试先装Ubuntu的服务器再手动安装EVE-NG等几种方式都不尽人意….

但是…最终发现….直接把EVE-NG给的ISO直接选VM安装…是可以顺利跑完并且运行的…赞..

然后就是各种导入镜像啊基础测试什么的…这些在网上都有比较多的教程略过不谈..

在Hyper-V环境比如容易遇到的坑, 第一是Qemu的模拟….因为Qemu需要VT-X/AMD-V的CPU虚拟技术支撑…而Hyper-V的客户系统默认是不带这个的..

所以要用Powershell把CPU的虚拟技术转接到客户机上:

Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true

 

其次, 是桥接Cloud端口上,

这个东西闹腾了我很久…事实上至今我都怀疑是不是第一次我选错了安装的系统…但是以为后来重做了一遍可以用了就没法重现了..

这中间需要注意的是: 如果用VMware, 那么一切都是有标准解决方案跟技术支持的…而Hyper-V, 至少Helpdesk是爱莫能助的..我跟他们聊了一下他们也没撒办法.

所以我只能自己搞定..

一来是在走投无路的情况下重新装了一边, 我隐约记得我第一次用EVE-NG的ISO装的时候好像选了Bare, 结果是Cloud1各种不通…除了管理接口Pent0其他基本都用不了…

而重做后用了VM选项就没那么多问题….Cloud1的接口在第一时间就能从模拟的路由器上ping到了.

二来是Mac伪装…为了让桥接到模拟器里的网卡能跟外界通信, 还要给虚拟机开mac spoofing…

Get-VMNetworkAdapter -VMName <VMName> | Set-VMNetworkAdapter -MacAddressSpoofing On

否则就只能跟Interface一个IP通信了..

至此为止…模拟器基本测试就搞定.

 

然后EVE-NG能干啥呢….

一部分的GNS3的镜像可以直接用

IOL的镜像也可以支持

QEMU的一堆镜像可以用.

基本上来说, Cisco的大部分实验是没撒问题了.

我测试了一下用模拟的3层交换跟我的物理在用的路由器做OSPF路由…然后在模拟器里加了一台Win7的虚拟PC…达成的目标就是路由同步正常并且PC可以正常上网…

到此为止, 我觉得EVE-NG可能是暂时为止我用过最好的模拟器了…类似Packet Tracer的易用, 但是因为是用接近实机的img直接运行, 支持的功能又多得多…当然, 主要是因为我对GNS3没撒深入研究…所以GNS3的好处就没体会到…光感觉好麻烦了..

不过, 我还是觉得作为夸平台的模拟器来说, EVE-NG是真的好用啊…

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应该算是很不错的选择呢..

 

库存备用-Ubnt-EdgeOS-ERL3-编译

因为之前连接的某些地址已经404了…所以我决定把库存上传上来以备不时之需

chinadns

gfwlist2dnsmasq

shadowsocks-libev_2.2.4-1_mips.deb

这些暂时都是我在用的货…应该都好用吧….

细节决定成败啊~~EdgeRouter大破恢复中的一个细节坑了我2天..

EdgeRouter Lite 3(后面简称ERL3)在最近的一次系统升级后再起不能…

连上console去查看,发现是U盘内的系统引导不起来了,所以就一直在不停重启…

得,拆机器确认下内置U盘是不是还活着…U盘还能读…那就用恢复系统重新引导重做系统吧….

重做完了开始恢复所有配置, 因为备份的存在所以基础配置是没有悬念的….然而问题是….后台用Linux命令完成的Shadowsocks出问题了..

转发无法工作…

可以确认的是, 服务器是没有问题的..那么问题就只能在本地了..

本地的ss代理一共有4大部分组成:

  1. DNSMASQ +IPSet,组成本地的DNS解析功能以及翻墙需要功能的IP列表记录.
  2. ChinaDNS作为非国内IP的DNS解析工具
  3. Shadowsocks-Libev 作为透明代理
  4. iptables作为流量分离工具

其中1跟4其实都是系统已经自带的功能, 基本不太可能出问题, 唯一的区别是, 1是可以简单验证的, 而iptables我不知道怎么确定他把识别到了正确的组而把流量转发到需要的端口去了.

所以,故障排除顺序是

  1. 确认dns正常工作, dnsmasq没问题, chinadns也没问题, ipset正常记录IP一样很正常,所以1跟2没问题
  2. 确认ss工作正常. 启动-v的诊断模式, ss的log没有任何异常

然后我就没想法了…因为iptables我不知道怎么确认..

然后查了各种地方测试了不同版本的ss,不同的服务器,不同的iptables配置方式,不同的本地端口, 都无法解决问题…很尴尬啊..心态略崩溃…

不过在最后, 发现之前已经灭了的onlyOS博客又能看了…..所以爬了下评论…发现一个之前完全不知道的config.json的点..

因为之前其实调整过很多次config文件…主要就集中在本地端口跟本地的IP配置上….所以本着死马当作活马医的态度,再试了一下..nice啊..

 

所以问题的关键还在于…细节啊..

这个细节就是…本地的config.json..local_address是要用0.0.0.0的,不配置local_address或者配置127.0.0.1,都是没用的..

至少后面的telnet很明确验证了这个情况….唉…不过好歹救回来了…我现在要纠结的事情变成了….我要不要换个U盘给路由呢…有点抖啊…怕再出点什么幺蛾子…

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相关的文档以及配置案例, 对整个体系的理解有了一个新的认识.

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