k2p 荒野无灯Padavan 隐藏的彩蛋集合

看到k2p 这么火,我也买了一个给朋友公司做外贸用,你懂得为什么外贸用.

k2p 固件很多,但是综合说来就是这么几个固件,官改固件,灯大的Padavan(也称为老毛子版本), openwrt cc 版本(最新的openwrt 18 对无线驱动不好)等等. 灯大的固件有这么几个隐藏彩蛋:

开启功能

酸酸:

nvram set google_fu_mode=0xDEADBEEF

KiwiVM:

nvram set ext_show_kiwivm_stat=1

KMS:

nvram set ext_show_lse=1

闪讯:

nvram set ext_show_pppoesvr=1

电信云加速:

nvram set ext_show_c189_speedup=1

 

隐藏功能

ttyd:

nvram set ext_show_ttyd=0

Kcptun:

nvram set ext_show_kcptun=0

保存:

nvram commit

Nginx 反代 upstream sent too big header

今天突然几个站点打不开了,出现了502 错误,赶紧打开nginx error log, 发现了这个错误:

upstream sent too big header while reading response header from upstream, client: XX.XX.XX.XX

这个错误很明显,是nginx proxy buffer 不够了,解决的办法很简单,直接在http block 里面添加如下命令即可:

proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;

添加完毕重启即可解决上述问题.

同时这也说明了在监控中,不仅要检查nginx,mysql 的程序运行情况,也要检查http status, 只有200的情况是可以接受的

简单理解Linux路由表

很多网络问题都跟路由有关,那么首先必须学会看懂路由表,本文将讲述如何读懂路由及如何决策.

在命令行下输入route -n 或 netstat -rn,就可以打印本机的路由表,我的如下:

Destination Gateway Netmask Flags Metric Ref Use Iface
192.168.161.0 192.168.161.1 255.255.255.0 UG 0 0 0 em1
192.168.161.0 0.0.0.0 255.255.255.0 U 0 0 0 em1
192.168.61.0 0.0.0.0 255.255.255.0 U 0 0 0 em2
169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 em1
169.254.0.0 0.0.0.0 255.255.0.0 U 1003 0 0 em2
192.168.0.0 192.168.61.1 255.255.0.0 UG 0 0 0 em2
0.0.0.0 192.168.61.1 0.0.0.0 UG 0 0 0 em2
0.0.0.0 192.168.161.1 0.0.0.0 UG 0 0 0 em1

PS:我的电脑是双网卡,分别在192.168.61.0和192.168.161.0两个网段

————————————————–

1 字段解释

Destination 目的网段,最长匹配192.168.161.0 > 192.168.0.0 > 0.0.0.0,0可匹配任意数值
Gateway 所走网关,0.0.0.0表示无网关,即与本机IP同一网段,不需要经过网关(同一个局域网内2台主机通信不需要经过网关)
Genmask 掩码
Flags 标志,U – Up表示有效
G – Gateway表示连接路由,若无这个字段表示直连目的地址
H – Host表示目标是具体主机,而不是网段

2 路由匹配

路由表的作用就是指定下一级网关,那么根据路由表怎么确定下一级网关,这里就有一个匹配过程,匹配规则

*(1)优先级匹配(暂不讨论)

*(2)最长匹配

3 实例讲解

还是针对上面的路由表,为了方便表述,加上条目号字段

条目号 Destination Gateway Genmask Flags Metric Ref Use Iface
1 192.168.161.0 192.168.161.1 255.255.255.0 UG 0 0 0 em1
2 192.168.161.0 0.0.0.0 255.255.255.0 U 0 0 0 em1
3 192.168.61.0 0.0.0.0 255.255.255.0 U 0 0 0 em2
4 169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 em1
5 169.254.0.0 0.0.0.0 255.255.0.0 U 1003 0 0 em2
6 192.168.0.0 192.168.61.1 255.255.0.0 UG 0 0 0 em2
7 0.0.0.0 192.168.61.1 0.0.0.0 UG 0 0 0 em2
8 0.0.0.0 192.168.161.1 0.0.0.0 UG 0 0 0 em1

 

192.168.61.35 – 匹配条目3,即不需要经过网关
192.168.60.150 – 匹配条目6,需要经过网关192.168.60.1
www.baidu.com – 匹配条目7,这里需要说明下为何不匹配8?这是我实践的结果,后加的默认网关会在列表前面,即优先匹配。这个规则应该用于所有Destination一致的情况
192.168.161.113 – 匹配条目1,不是匹配条目2

Cisco中的PVID 和 Native Vlan

VLAN 1 是一个预设的 VLAN,所有 Cisco Switch 皆有 VLAN 1,而所有 port 亦预设放於 VLAN 1 之中。VLAN 1 之神圣在於它除了和其他 VLAN 一样可以传送 data 之外,还负责传送所谓 Control Plane Traffic,例如: VTP, CDP, PAgP 等。因此,基於保安考虑,VLAN 1 应避免给一般 HOST 使用,因为 HOST 利用 Packet Capture 软件可以轻易 Capture 到 Control Plane 的数据包.

值得一提的是,VLAN 1 预设也是 Trunk Link 上的一个 Native VLAN,Natvie VLAN 的意思是 Switch 把这个 VLAN 的 Packet 送上 Trunk Link 时,是不会放入 VLAN Tag 的,这就有点玩野了,刚刚不是说我们要把在 Packet 放一个 VLAN ID 好让其他 Switch 可以分辨吗? 怎麽现在又有个 Native VLAN 不用 VLAN ID? 细心想想,道理很简单,如果所有 2-4096 的 VLAN 都有 VLAN ID,只要 Trunk Link 两边的 Switch 都协议没有 VLAN ID 的 Packet 就是 VLAN 1,那麽 VLAN 1 就算没有 VLAN ID 也可以被区别出来。道理就像大家在不同颜色的数字球上写上数字,红色写 2,黄色写 3,蓝色写 4,那麽没有颜色的透明就写 1 吧

所以当 VLAN 1 的 Packet 通过 Trunk Link,用 Packet Capture 软件 Capture 也不会看到 VLAN ID 1,只会看见一个没有 VLAN ID 的封包 (即没有 Tag)。Native VLAN 的 ID 是可以设定的。

另外需要注意的是Trunk Link 两边的interface的native vlan 必须相同,否则会造成native vlan mismatch的问题

vlan 于 trunk 打标签的过程

交换机内部的对vlan tag的处理有以下几种情况:(按照数据包的转发方向)

1、从Access端口进入,然后从Access端口发出;则进入是带上vlan tag,发出时去掉vlan tag;

2、从Access端口进入,然后从Trunk端口发出;则进入时带上vlan tag,发出时保留vlan tag;

3、从Trunk端口进入,然后从Trunk端口发出;则vlan tag无变化,进来什么样出去还是什么样;

4、从Trunk端口进入,然后从Access端口发出;则进入时无变化,出去时去掉vlan tag;

其实很简单,从access口出来的都是不带tag的,从trunk口出来,都是带tag的

trunk的作用是可以让多个vlan通过,原理是对不同的vlan打上不同的标签以区分不同的vlan的数据帧

KMS 基本命令

家里的Win 2016 Server datacenter KMS 激活马上就要到期了,这才想起来KMS 的命令早就忘的一干二净…哎。。。这里做个记录,以后也好查找

KMS 只适用于VL 版本,不适用于旗舰版

一般来说,只要确保的下载的是VL批量版本并且没有手动安装过任何key, 你只需要使用管理员权限运行cmd执行一句命令就足够:

slmgr /skms you.ip.address.or.domain

然后去计算机属性或者控制面板其他的什么的地方点一下激活就好了。

更多

monit 在 centos 7 和debian 8, debian 9下的使用

在老的centos 6 和 debian 7 中,monit 是通过对 pid 的监控来判断程序是否die 或者有问题的, 但是在 centos 7 和 debian 8 和debian 9下,只要service 不是以forking 的形式启动,systemd 就不会让service 创建 pid file,即使你在service 的配置文件中创建了 PidFile 的命令,这个命令是会被忽略的

因为在由systemd 控制的linux 系统中,monit 无法通过pid 的形式来监控程序,在这里我们就需要用到monit 的的match 命令,比如说nginx 来可以match ‘nginx’, 来完成对nginx 的监控

Unix 守护进程

守护进程是在后台运行不受终端控制的进程(如输入、输出等),一般的网络服务都是以守护进程的方式运行。守护进程脱离终端的主要原因有两点:(1)用来启动守护进程的终端在启动守护进程之后,需要执行其他任务。(2)(如其他用户登录该终端后,以前的守护进程的错误信息不应出现)由终端上的一些键所产生的信号(如中断信号),不应对以前从该终端上启动的任何守护进程造成影响。要注意守护进程与后台运行程序(即加&启动的程序)的区别。

更多

service在centos6,debian7 和centos7,debian8 的不同

我是一个很老套的人,一直在坚持使用centos 6 和 debian 7,但是无奈很多软件已经取消了对centos 6 和debian 8 的支持,现在只能加班加点开始适应debian 8 和 centos 7.

在centos 6 和debian 7中,脚本一直使用的是/etc/init.d/xxx, 在系统升级到Centos 7 和 Debian 8后,虽然以前的启动脚本仍然可以使用,但是在centos 7 和 debian8中, 系统的service 已经由sysvinit 转向了systemd,进而也有了很多的变化

CentOS 7 集成了 RHEL 7 的新特性,systemd的使用也大幅提高了系统服务的运行效率,同时也变的简单而易用了许多.

Unit 的文件位置,一般主要有三个目录:

/lib/systemd/system
/run/systemd/system
/etc/systemd/system

这三个目录的配置文件优先级一次从低到高,如果同意选项三个地方都配置了,优先级高的会覆盖优先级低的. 

对于第三方或者自己定义的service 来说,我们一般放在/etc/systemd/service下面。

更多

一晃就是一年

真的是时间飞逝,一晃就是一年.

上一篇更新还是在去年的8月18号,在过去的一年时间里,发生了很多事情,其中最大的好事就是大胖儿子出生了,给整个家庭带来了不少欢声笑语.

压力更大,我也需要更加努力了