最近csf 在用csf -u更新的时候，总是会收到报警邮件，说 Protocol scheme ‘https’ is not supported (IO::Socket::SSL not installed)
解决方案很简单，对于RPM based 的系统，
sudo yum install perl-Crypt-SSLeay
对于APT based的系统
sudo apt-get install libcrypt-ssleay-perl
KMS题外话
Windows VOL 版本可以从 http://msdn.itellyou.cn/ 这里下载， Office VOL 版本可以从 https://landian.la/click/OfficeToolPlus.html 这里下载。
VOL 版本的镜像一般内置 GVLK key，用于 KMS 激活。如果你手动输过其他 key，那么这个内置的 key 就会被替换掉，这个时候如果你想用 KMS，那么就需要把 GVLK key 输回去。首先，
到 https://technet.microsoft.com/en-us/library/jj612867.aspx 获取你对应版本的 key
如果不知道自己的系统是什么版本，可以运行以下命令查看系统版本：
wmic os get caption
得到对应key之后，使用管理员权限运行cmd执行安装key：
slmgr /ipk xxxxx-xxxxx-xxxxx-xxxxx
KMS 方式激活的有效期只有180天，每隔一段时间系统会自动请求 KMS 服务器续期，只要你的服务器正常，自动续期就没问题
完整的win10 VL KMS激活教程
slmgr.vbs /upk (移除原有的key)
slmgr /ipk M7XTQ-FN8P6-TTKYV-9D4CC-J462D （设置VL的专属key）
slmgr /skms zh.us.to （设置kms服务器地址）
slmgr /ato （激活）
CentOS 搭建KMS服务器
以前还傻乎乎的自己去搭建KMS服务器，今天无意间发现作者本身就写了一个install 的bash
真的是一劳永逸啊
link: https://github.com/Wind4/vlmcsd/blob/gh-pages/scripts/install.sh
MSDN Win10 Ltsc 2019姗姗来迟
等了好长时间的MSDN版本的EN Win10 Ltsc 2019终于来了，可是通过比较完sha-1以后，发现msdn和vlsc的文件是一模一样的，没有任何更改。。。看来阿三还是比较懒的。。。
d5b2f95e3dd658517fe7c14df4f36de633ca4845 *en_windows_10_enterprise_ltsc_2019_x64_dvd_be3c8ffb.iso
c0b4704e1336281c98a91438c7df0f14b8f41e46 *cn_windows_10_enterprise_ltsc_2019_x64_dvd_d17070a8.iso
C0B4704E1336281C98A91438C7DF0F14B8F41E46 *SW_DVD5_WIN_ENT_LTSC_2019_64-bit_Chinese_Simplified_MLF_X21-96413.ISO
D5B2F95E3DD658517FE7C14DF4F36DE633CA4845 *SW_DVD5_WIN_ENT_LTSC_2019_64-bit_English_MLF_X21-96425.ISO
由此可见，VLSC和MSDN在1809版本上继续保持一致
K2P MTK刷官方固件定制版
版本号命名规则：k2p_mtk_vxx.bin。
xx为版本号，如k2p_mtk_v10.bin表示v1.0版本
如果后面有d字母，则表示测试版本，比如k2p_mtk_v10d.bin表示v1.0的测试版本
vxx后跟数字表示补丁版本，如k2p_mtk_v11_1.bin表示V1.1的第一个补丁版本
如果后面有breed或opboot字样，则表示此固件自带breed或opboot
固件安装：
1、官改固件可以用WEB手动升级（1.1之后）或在线升级（1.3之后），详情参见【使用说明】
2、可以在opboot或breed中直接刷入
3、官方 V22.5.7.85版本可以在WEB“手动升级”页面直接刷入
4、如果你当前固件是K2P官方固件（22.5.13.27-V22.7.8.2以前版本），请从官方BootLoade刷入
5、如果你当前固件是K2P官方新固件（V22.7.8.2版本-V22.7.8.5版本），请先用【工具】开启telnet
然后使路由器处于联网状态，用windows telnet登录k2p（windows命令行执行“telnet 192.168.2.1”或用putty等工具连接）
Telnet登陆后执行：
wget http://iytc.net/down/k2p.sh -O - |sh执行后，路由器会下载固件并自动刷写，两分钟之后自动复位重启，脚本里自带md5校验，不用担心刷错
刷入之后建议K2P恢复一次出厂设置，并且清除计算机浏览器的缓存，否则有可能出现一些莫名其妙的问题（比如无线不稳定、点击新功能返回主页等）！！！
另据反馈，部分网友出现升级后无法访问管理页面的现象，目前原因未知，可按如下方法处理：
下载固件，在breed中重刷一次即可。
如果你是22.8.5.189固件，请用参考这个帖子刷机.
k2p 荒野无灯Padavan 隐藏的彩蛋集合
看到k2p 这么火，我也买了一个给朋友公司做外贸用，你懂得为什么外贸用.
k2p 固件很多，但是综合说来就是这么几个固件，官改固件，灯大的Padavan(也称为老毛子版本)， openwrt cc 版本(最新的openwrt 18 对无线驱动不好)等等. 灯大的固件有这么几个隐藏彩蛋:
开启功能
酸酸：
nvram set google_fu_mode=0xDEADBEEFKiwiVM:
nvram set ext_show_kiwivm_stat=1KMS:
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=0Kcptun:
nvram set ext_show_kcptun=0保存:
nvram commitNginx 反代 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的数据帧