简单陈述: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……..啊啊啊啊

网络模拟器神器之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的域名续费是不是也便宜就齐活了..