标签: 路由器

在彻底失去知情权之前再挣扎一把___花了一个周末把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是真的好用啊…

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回家哦!

 

 

自动翻墙配置EdgeOS篇续

上一篇我们说明了使用纯VPN连接的方式来做自动翻墙.

因为VPN的方式就必然需要另外一头也有相同协议的服务器端, 这就意味着要么自己在VPS上建自己的VPN服务器,

比如我常说的搬瓦工, 一来是便宜, 二来是因为搬瓦工几乎把所有VPN需要用到的服务跟端口都给开了, 所以软件安装相对容易多了.

要么去买一些商用的VPN服务,比如:

VyprVPN, 在最基础的套餐jin仅支持PPTP, 但是在后续的pro套餐里可以支持几乎所有参见的的协议.

不过现在我们还有别的选择, 那就是shadowsocks.

这是一个开源的加密Socket5代理协议, 跟VPN相比最大的区别就是他的客户端相对轻量化, 所以大部分的路由器系统都可以运行在后台.

所以在路由器平台上相当流行, 也进而导致了同样使用shadowsocks协议的服务供应商的大量出现.

所以如果不愿意自己建VPS的服务端, 也可以直接去买相关的服务.

关于Shadowsocks的服务器端怎么安装就不在这里说了, 因为不同的服务器不同的系统差别比较大.

在EdgeOS这端, 我们需要在Debian的系统里安装2个工具, 一个是Shadowsock, 一个是ChinaDNS.

ERL3用的版本可以在这里找到:http://www.onlyos.com/archives/shadowsocks-libev-chinadns.html

因为是Linux端, 需要的话可以用Wget或者PSCP从Windwos拷贝过来.

Deb使用dpkg安装, ChinaDNS则是解压以后直接chmod +x赋权以后就能直接用了.

基本思路如下:

Shadowsocks负责流量的转发…ss-redir启动以后可以绑定在127.0.0.1的某个端口上, 等待路由协议把需要翻墙的包转发到这个端口上然后发送到服务器端

ChinaDNS负责作为本地的DNS服务器解析域名, 因为ChinaDNS本身带有-m的压缩指针模式, 同时支持使用433等非标准的域名端口, 所以可以成功绕开GFW去国外域名服务器拿到正确的IP.

并且支持非污染的IP从国内DNS拿IP, 被污染的出国拿, 所以最大程度上绕开了域名污染,并且避免了CDN, 位置服务等带来的不遍.

IPset负责标记GFWlist内的域名进入相关的组.

IPtables 负责将符合要求的对应的组的流量转发到Shadowsocks

这中间, 还需要一个本地Dnsmasq的支持, 不过这里的Dnsmasq主要的是直接去访问127.0.0.1:(ChinaDNS的端口), 作为一个转发跟缓存的存在, 因为Ipset需要Dnsmasq的解析记录去存入group

因为主要是Debian下的DNS操作, 所以具体操作我就不详细写了.

ss的配置主要是config.json的这个文件, 以及ss-tunnel的问题.

因为ss一开始并不支持UDP协议, 所以在DNS解析的时候, UDP包没有地方去, 所以ChianDNS使用8.8.8.8:53作为墙外的DNS, 那么我们可能需要ss-tunnel作为UDP转发通道.

一旦涉及到UDP流量, 那么请考虑所使用的SS版本因为只有C语音版本是支持UDP的, python版本无法使用UDP转发所以服务器端装什么也要考虑到.

当然我们也可以让ChinaDNS启用压缩指针模式.

在这些都准备好的情况下, 我们只需要一条iptabels的命令:

iptables -t nat -A PREROUTING -p tcp -m set –match-set group-name dst -j REDIRECT –to-port 1188(ss-local-port)

就可以把ipset对应的翻墙组的流量都扔到ss上然后出国拉.

我个人使用的方式是结合了几种方式的:

  1. 我用PPTP的VPN作为DNS解析的通道, 因为对速度要求低而且不需要考虑SS服务器端是否支持UDP
  2. SS作为流量的转发主力, 主要是因为如果要更换服务器信息我只要改下配置文件或者新建配置文件就可以, 不需要考虑路由等问题
  3. IPv6隧道备用, 作为第三路径保证前2个都出问题的情况下我去google和inbox都不会出问题.

ERL3是一台非常强大非常好用的路由, 然而因为图形界面的简陋, 命令行的相对晦涩, 导致了使用的人比较少, 相关资料也远不如ROS来的丰富.

然而因为后台Linux系统的开放, 甚至于可以直接在上面apt-get, 就跟一个树莓派一样, 所以对于Linux比较熟悉的用户甚至于可以直接在上面创建编译环境生成需要的工具.

并且他的存储其实是一个U盘…如果觉得原厂的容量不够了, 可以直接拆机换一个16G的上去…屌炸天有木有.

有兴趣的朋友去买一个来玩玩呗.

Ubiquiti Networks Edgerouter Lite 3Port Router (ERLITE-3)

Ubiquiti EdgeRouter X Advanced Gigabit Ethernet Routers ER-X 256MB Storage 5 Gigabit RJ45 ports

注意ER-X跟ERL的硬件平台不同所以软件包并不通道.