在彻底失去知情权之前再挣扎一把___花了一个周末把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者其实是完全一样的东西哦。
所以我们要做的就是:
- 安装v2ray
- 写v2ray的配置文件
- 运行
听上去跟把大象放进冰箱一样的简单呢。
一切的关键都在配置文件里,很清楚了吧。
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的配置的一些细节以及我踩的坑。希望能我自己下次别再踩一遍。
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应该算是很不错的选择呢..
细节决定成败啊~~EdgeRouter大破恢复中的一个细节坑了我2天..
EdgeRouter Lite 3(后面简称ERL3)在最近的一次系统升级后再起不能…
连上console去查看,发现是U盘内的系统引导不起来了,所以就一直在不停重启…
得,拆机器确认下内置U盘是不是还活着…U盘还能读…那就用恢复系统重新引导重做系统吧….
重做完了开始恢复所有配置, 因为备份的存在所以基础配置是没有悬念的….然而问题是….后台用Linux命令完成的Shadowsocks出问题了..
转发无法工作…
可以确认的是, 服务器是没有问题的..那么问题就只能在本地了..
本地的ss代理一共有4大部分组成:
- DNSMASQ +IPSet,组成本地的DNS解析功能以及翻墙需要功能的IP列表记录.
- ChinaDNS作为非国内IP的DNS解析工具
- Shadowsocks-Libev 作为透明代理
- iptables作为流量分离工具
其中1跟4其实都是系统已经自带的功能, 基本不太可能出问题, 唯一的区别是, 1是可以简单验证的, 而iptables我不知道怎么确定他把识别到了正确的组而把流量转发到需要的端口去了.
所以,故障排除顺序是
- 确认dns正常工作, dnsmasq没问题, chinadns也没问题, ipset正常记录IP一样很正常,所以1跟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还是挺好的…而且画图很方便…咔咔
婓迅的营销真心牛-免费路由背后的故事
首先介绍一下最近火的不行的婓迅的路由, 之前是K1, 现在已经是K2了…主要的变化是无线支持2.4G+5G并且支持802.11ac制式了.
那么为啥那么火呢?
先把他们的链接放出来, 这个是分销商的地址, 可以直接买到. 官方店完全没货要等后天上聚划算.
斐讯PSG1218千兆1200M无线路由器智能家用WIFI穿墙王双频路由K2
从技术角度上来说, 这个品牌跟东西本身其实并没有什么亮点, 甚至于因为LAN口WAN口都是百兆, 我个人认为有点脑残, 毕竟现在百兆宽带已经大规模铺开, LAN口WAN口不用千兆就意味着端口速度的损失, LAN口没千兆更加是导致内网共享的速度上不去.
然而这些对于非技术流玩家都是无所谓的…因为婓迅的运营的关键在于….免费!
一个免费就能把所有的技术缺陷都抹去…而能刷固件带来的大大的可玩性直接导致了这个路由的大规模爆炸! 反正不要钱嘛.
那么他们究竟干了什么呢?
其实很简单, 就是带上了一个需要推广的理财, 婓迅出产品, 理财出运营成本. 然后只要做一个免费的噱头, 加上一个常规的市场运作, 借助了免费的东风把销量一下子推上去.
顺带理财的数量也就跟着销量水涨船高. 就算100%的返款, 理财也能拿到每个月的无息现金流, 至少也是上千万.
那么婓迅能拿到什么?其实就是大规模的出货带来的去库存, 市场效应, 以及理财公司所付出的营销收益.
理财公司需要付出的就是市场推广成本, 其实这个东西他们本来就要做, 只是现在变成了直接付给婓迅而不是广告等其他渠道, 所以对他们来说反而更容易处理因为不用去谈营销方案等了.只要坐等收钱就行.
婓迅则要承担产品的成本跟市场营销的成本, 不过我个人觉得产品的成本会很低, 因为从产品本身来说其实没有亮点. 营销成本现在看来最大的应该就是天猫的推广了. 这个理论上跟他们本身的市场营销成本是一致的, 所以并不算额外支出.
所以, 只要理财公司的营销成本能覆盖掉婓迅的产品成本, 婓迅就能放心大胆的往外卖, 毕竟卖多少都有得赚.
理财公司则是只要坐等着钱进来然后在一段时间内维持一个相对稳定的现金池, 以沉淀资金去完成短期投资获取足够收益去覆盖营销成本.
用户端只要动动手然后押几个月钱就能轻松换到一台免费路由.
可以说, 这个真心是互联网共享经济的营销典范.
我们以后可以来大概介绍下K2的玩法, 不过再次之前最好先抢一台K2回家哦!
日本方向SoftLayer的路由已炸
今天因为发现速度有点慢…然后trace了一下从魔都去日本softlayer的状态, 喜闻乐见
从魔都去日本softlayer的路由先去太平洋对面走了一圈然后去SG旅游了一下才到日本…
这跟以前CN2直连的时代简直就完全不能比了.
所以近期在有意使用日本方向VPS的用户可以考虑暂时别用他们的东西了, 尤其是华东电信的用户.
魔都这边现在能享受直连的还是HK的部分线路以及韩国KT的线路.
有需要的可以考虑使用这2个地方的VPS.
翻墙之APN篇
继续我们的翻墙大业.
之前介绍的无论是路由智能翻墙还是客户端VPN, 基本上都是需要客户端软件支持的.
然而对于用户来说, 有没有一种是可以一次设置完就不用想只管用的解决方案呢?
伟大的劳动人民+奇葩的程序猿=无敌的存在, 所以答案是必须有!
我们有了一个叫APN接入方式.
这个APN是指Anon Proxy Network, 匿名代理网络, 而不是手机信号上的access point network.
实现方式如下:
对用户来说, 需要做的只是在你的wifi或者浏览器里面配置一个PAC文件的地址.
PAC是一个代理自动配置文件.功能就是根据域名或者IP来选择使用不同的代理服务器或者直连.
这样一来呢, 就可以直接在客户端完成路径的分流.
这样的模式对于服务器端要求略高, 需要墙内墙外各有一套, 通过服务器之间的通信来实现翻墙, 而用户因为只跟墙内的跳板服务器通信, 并且墙内代理可以开Cache或者使用感受会很好.
具体表现就是: 配置简单, 自动代理无需手动开关, 速度快.
不过这个模式的缺点也是很明确的:
1.由于使用的是代理模式, 所以实际上用户跟墙内服务器的通信是明文不加密的状态的, 这在私人服务器, 自建的VPS上的时候很少有感觉, 但是, 一旦被服务商大规模使用起来了, 那么流量的汇聚就很明显, 这也是APN的服务商几乎都不长久的根本原因.
2. 在移动平台上, PAC文件的配置是无法应用在蜂窝网络的, 只能在wifi下工作, 这就意味着, 当你在无wifi状态下, APN+PAC的模式就失效了, 用户需要准备另外一套方案来解决这个问题.
3. 由于一条通道必须有2台服务器, 所以成本必然相对高, 所以一般来说价格也会略贵一点.
由于这些原因, 市场上的APN供应商一直都处于不稳定的状态, 曲径熊猫都已经完蛋, 土行孙基本已经封闭, 轻云谢公屐也相对封闭, ZPN现在是邀请测试状态.
至于让用户自己起VPS做这个..我个人是不推荐的…因为与其要准备2套方案应对不同的网络环境, 不如直接来一套Shadowsocks解决问题更加实际.