轻量级软路由 ESXi 和家庭影院方案的最佳实践

最近折腾软路由也有一阵子了，摸索出来一套适合自己的方案，关键词是两个，轻量级和最佳实践。

首先说轻量级，轻量级意味着不需要太强性能的设备，其次功耗要低否则电费也会吃不消，另外也不需要太大容量的硬盘。而最佳实践首先意味着可靠，也就是不管什么时候都得能连得上网，对于小白来说，折腾的时候家里网断了才尴尬，这就要求软路由方案要尽可能的减少对当前网络的侵入性，另外网络架构还要尽可能的简单，因为简单意味着可靠，要尽可能的减少内网的层级，多一层内网就多一层 NAT，这对于某些应用是不可接受的。

下面是拓扑图，可以看到对于普通的设备来说，一切都跟以前一样，而对于需要特殊功能的设备，只需要将网关和 DNS 改成软路由的即可。

太细节的东西我就不太想写了，下面放一些结论欢迎食用。

先上几个图来，这是我手上这款工控机，处理器是 3865u，搭配 8GB 内存 128GB SSD 和 500GB 的 HDD。无风扇设计，平时功耗大概 8W，第七代的 CPU，相当够用了。

软路由硬件配置怎么选

目前来看，可选的一般有 J1900 / 3865u / 3965u / 4415 / i3 / i5 / i7，基本上还是要大家想清楚自己的需求的，一般来说 3865/3965 绝对够了，如果不够，不是 CPU 的问题，而是你的问题。

对于局域网跑满千兆带宽的需求，普通路由器就够了，J1900 在探索国际互联网的过程中，没办法跑满千兆，所以这一款最先被放弃，当然了对于需求不高的人来说 J1900 也是足够。

接着说后面几款，3965 纸面数据性能比 3865 高 20%，实际上可以认为没什么用，因为 3865 足够你装虚拟机，跑满带宽，包括装一个 Linux 里面挂几个网站开几个服务，这个 CPU 也是够的，大多数 web app 都不是 CPU 密集型的程序。

那什么是 CPU 密集型的呢，音视频转码，对于音视频转码的需求来说，多强的 CPU 也照样不够用，都会觉得慢。如果真遇到了运算能力的瓶颈，有一万种优雅的方法绕过他，等下在流媒体服务器方案中详细说明。

当然了如果 3865u 和 3965u 差价在 100 以内，还是选 3965u，再贵就不建议了，因为付出了差价但是基本上用不到多出来的性能。

很多人会高估自己对 CPU 的要求，根据我个人经验来看，除非编译很大的程序，或者渲染视频，手上这台 MacBook 的 CPU 一般都在 10% 以内趴着，以及，关于阿里云的服务器，我惊奇的发现即使选了突发性能型号的 ECS，每天也只消耗了 5% 的计算配额。

内存建议 8GB 起步了，SSD 64G 是够的，128 也可以（可以装一个 windows 虚拟机），再高真的没必要。

网线取决于使用场景，如果只是作为跳线，1 米以内 5 类线也可以跑满千兆带宽，如果有的选建议还是圆形有十字骨的 6 类线，除非有特殊需求否则避免扁网线，尽管一米以内只要是根 RJ45 线就能跑满千兆。根据网友的测试，6 类线跑满 2.5G 带宽也没问题，所以对于普通家庭来说，质量好的 6 类线可以满足需求，当然了如果是装修布线，还是选光纤或者更高规格的线材吧。

ESXi 配置相关

ESXi 毫无悬念肯定选 6.7 版本，因为 7.0 对个人用户很不友好，比如驱动问题，比如磁盘占用，比如内存占用。

至于 PVE 和 ESXi 选哪个，这个问题大概相当于 MariaDB 和 MySQL 你选哪个，照着自己一贯的做法去选就行了。这是一个开源软件和商业软件社区版之间的选择，个人建议是如果商业软件并没有针对散户的重大缺陷，优先考虑商业软件。

如果遇到了 SSD 速度只有 30MB/s，一种可能是 ESXi 对这个牌子的 SSD 兼容有问题，另一方面也可能是 BIOS 设置的不对，在硬盘的选项中好好改改，改成正确的信息即可。

ESXi 需要配置的地方很少，我把他们分为如下几项：

• 静态 IP 的设置

这个可以在开机之后外接显示器，F2 修改静态 IP。

• 硬件直通

直通完毕切记相关虚拟机要预留所有内存，否则无法启动。

• SSL 证书

首先明确，ESXi 不支持 ECC 证书，擅自安装 ECC 证书之后会导致无法开启 web 管理界面，解决方案只有一个，那就是外接显示器打开 SSH，换一个 RSA 的证书，附一条重置证书的命令，会自动生成一个自签名的证书，可以解决上述 ECC 证书的问题。

其实 ESXi 的 openssl 版本是支持 ECDSA 算法的，并且曲线里面也包含了 secp384r1 曲线，奈何就是网页不能配置 ECC 证书。

/sbin/generate-certificates

网上很多暴力教程，要我说都是瞎 jb 写，官方的建议是 key 文件不要碰它（400 权限），那么方法就来了，用这个 key 生成一个 CSR，只编辑证书文件就行了。

// 重启管理网络生效 SSL 证书
/etc/init.d/hostd restart
/etc/init.d/vpxa restart

• 交换机设置

默认交换机的设置里面，建议设置一个混杂模式，方便少插一根网线，缺点是会依赖 OpenWrt 的启动，因为 OpenWrt 要做这个口的桥接。

ESXi 直通相关

NAS 数据盘直通不用说了，关于网卡直通，路由器性能一般要么是过剩，要么是不够，不够的时候肯定用直通，但是过剩的时候，选虚拟网卡也没太多损耗，纯虚拟的兼容性更好一些。实际可以根据网卡兼容程度和自己强迫症程度来选。

经过实测，我的软路由固态盘和机械硬盘同属一个 SATA 控制器，直接直通硬盘会导致很严重的后果，如果谁遇到相同问题，建议重装，修复起来过于麻烦。

再就是 ESXi 自带的 RDM 直通，实测效果跟 PCIe 直通性能差距几乎没有，唯一的区别就是不能读取 SMART 信息，硬盘插到别的系统里照样可以读取文件。

关于显卡直通，本来想直通一个核显给 Debian 系统，做流媒体的硬解码，后来发现 ESXi 不认 HD610 这个核显，遂作罢，硬解的问题稍后再说。

OpenWrt 和 ROS 的选择

普通用户真的没什么必要上 ROS，带来的体验会边际递减，OpenWrt 选一个稳定的发行版本即可。OpenWrt 的官方固件功能有限，可选的有 koolshare 和 Lean 的 LEDE，前者 700M 功能更强后者 100M 更稳定但是需要自己编译。

OpenWrt 的设置

基本上国内用户的需求就是探索广阔世界了，这部分因为个人不需要就不再介绍。

关于去广告，直接上结论，koolproxy 一是不再维护了，再就是他需要 Root CA，综合所有考量还是用 adbyby 比较好。另外，adbyby 自带的规则太少了，建议订阅 https://github.com/privacy-protection-tools/anti-AD ，选 dnsmasq 规则，因为 dnsmasq 是从域名解析入手来屏蔽这些广告，跟其他几种（hosts, easylist）比起来，效果差不多，但是效率高。

去广告整个机制其实很麻烦，如果在浏览器上，插件可以根据 HTML 内容过滤标签，所以是最精准的，缺点就是必须 Chrome，连 Safari 都不行，而且只能在浏览器上实现。从路由器上如果想实现相同功能，现在很多网站都用 HTTPS，必须信任自己的 root 证书，解密流量然后过滤，是一个很脏的做法。综合所有考虑，我的核心诉求其实是禁止追踪，尤其是 mmstat 这个混蛋流氓，只要能屏蔽 mmstat 就很幸福了。

关于网易云解锁灰色歌曲的功能，如果不放心还是建议自己签一个 Root CA 证书，避免日后的麻烦。另外还有一个小技巧，作者的方案里面，网页版的就会废掉，因为打开网页不会加载 CSS 和部分 JS。解决方案就是在签发证书的时候，除去作者推荐的 DNS:music.163.com,DNS:*.music.163.com 两个域名，再加上两个，签发这四个域名的证书 DNS:music.163.com,DNS:*.music.163.com,DNS:*.126.net,DNS:*.music.126.net 。

私人网盘的方案选择

个人建议 NextCloud，虽然这也是个残废，但是开源方案真的没有更好的了，NextCloud 最大的缺陷在于磁盘 IO 的控制不到位，在线播放视频本来应该网络传输多少读多少磁盘，根据 HTTP header 头里面的 Range 决定读取多少文件内容，但是 NextCloud 会读取整个文件，经常服务器的负载会从 0.02 飙升到 50+，经过排查发现是 IO 导致的。我在 GitHub 提过好几个 issue，但是官方解释说这个问题在目前的代码框架下很难解决。

• Extremely high IO usage when deal with large files #22334
• Solved: Video playback cause a high load average (51.75), website gets stuck #22276
• Huge download: File gets completely read even after download is cancelled #8161

并且，NextCloud 在 WebDAV 协议下同步多个小文件的时候也存在 IO 的问题，总的来说，NextCloud 玩玩可以，当个网盘替代品可以，别使劲操，否则代价就是网站卡死，半个小时后见，除非手动重启 php 进程。

而这种问题几乎是无解的，总不能无限的增加磁盘速度，而且重点在于，磁盘是被完全不必要的读写给占满的，根本没发挥出应有的价值，比如打开一个视频再关闭，NextCloud 仍然会坚持读完这个文件，如果打开多个大文件再关闭，那服务器的负载会高到爆满，直到网站卡死。

这里有一个投机取巧的方案：数据盘单独挂载，比如挂载到机械硬盘，而 NextCloud 源代码，php 程序放在 SSD 里面，这样即使机械盘的 IO 占满，也不至于网站卡死。为什么网站会卡死呢，因为 php 是一门脚本语言，运行时要从磁盘读取的，当然也可以打开 opcache，但是总归治标不治本。

为什么不建议用黑群晖呢，看个人需求，绝大部分人只是需要一个比百度网盘好用的网盘而已，黑群晖毕竟是黑的，而且在虚拟机里，玩玩就行，不要当真。

流媒体服务器

流媒体服务器是花了我最长时间的模块，最开始用 NextCloud，奈何 IO 问题会导致硬盘速度占满，虽然后来经过调整也勉强能用，但是没办法我有强迫症，不该他读盘的时候就是不能纵容他读盘。所以首选就是 Nginx 映射一个静态服务器到视频目录，不得不说 Nginx 真牛逼，几乎做到没有 IO 开销，响应极快，然而好景不长很快就遇到问题了，有的视频是 mkv 容器的，里面虽然视频流是 H264，奈何音频不是 aac，交给浏览器是没办法解码的。于是乎我在网上看到个骚操作，让 Nginx 识别 mkv 格式，本来以为自己要成了，结果发现视频是可以播放，但是没声音。所以这个方案基本上不可行，除非你打算给每个视频做转码。

接着就发现了一个神器，Emby。Emby 有一个很神奇的功能，假设一个视频是 H264 编码音频是 DTS 编码，Emby 可以做到只转码音频，达到在线推流的效果。所以这里我想回应一下上面的观点，为什么 3865/3965 CPU 性能足够，并且再高几乎没什么用，因为如果只是给音频解码，3865/3965 足够了，网上漫天飞的 H264 资源，真遇到 CPU 瓶颈，不是 CPU 的问题而是你的问题。

不得不说 Emby 帮用户解决了很多问题，漂亮的布局，metadata 搜刮，字幕下载等等，必须说一句 Emby 真香！

ESXi 下直通核显给 emby 比较麻烦，有些核显确实不能被识别，瞎搞容易搞崩系统然后就麻烦了，为了一劳永逸，直接关闭用户 transcoding 功能就行了，只允许 audio transcoding，因为网上的资源基本上都是 H264 编码，所以使用起来没问题。关了之后，副作用是用户没法看其他编码的视频，但是一般种子都会写清楚是否 H264 编码，所以可以认为这样做不存在问题。

Emby 是一款免费的软件，部分高级功能需要会员才行，119 美元买断，具体高级功能自己看官网去 https://emby.media/premiere.html 。当然了也是有办法绕过验证，实现方法就是跟上面网易云解锁灰色歌曲差不多，自己签一个证书，并且劫持 DNS 到对应的服务器，在对应的验证 URL 返回硬编码的 json 即可。

对了有一个小技巧，如果遇到激活不成功，或许是因为 Emby server 端代码里面写死了一个 root 证书列表，需要编辑这个列表加入自己的 root 证书。

AP 关闭 DHCP 之后，怎么进入后台管理？

Singtel 的宽带有一个 HG8244H 光猫还有一个 AC1900 的路由器，两个的访问地址都是 192.168.1.254，由于路由器关闭了 DHCP，所以默认会连到光猫的管理后台。如果想设置路由器，把光猫拔下来，使用自己的子网，即可实现路由器管理。

另外光猫上面也有一些小技巧，背后标签贴的账户 root 密码 admin 只是一个普通用户，不能改变光猫的工作模式，实际的控制账户密码是其他的，谷歌可以找得到。

服务器怎么备份

这个其实是因人而异，但是原则很简单，自己产生的数据必须备份，网上可以下载到的尽量不备份，对于我个人来讲，最重要的目录有这么几个：

• etc 存放各种软件精心调整过的配置
• home 目录以及所有命令行历史，但是不包括 .npm .composer .cache 这些
• 数据库
• 网站的配置文件

我的做法是写一个备份脚本，每天打包这四处文件，加起来大概 3MB，并且同时删除当前天减去三这一天的备份，也就是说永远只保留三天的备份。至于备份是传到网盘，还是 OSS，还是其他储存介质，这个因人而异。

同时我也会保证至少一个月一次的全盘备份，把虚拟机关机，直接拷贝出来所有文件放在移动硬盘里，这么下来基本上就不会有任何问题。

总的来说，每套方案一定会适合某个群体，上面这套相对更适合轻量一点需求的用户，在保证了高可用性的同时也提供了丰富的可玩性。