网络简记

[无线设备配置]

软路由安装使用简记

1. 动机

主路由性能难以支持clash分流等操作，clash分流时依赖CPU性能而不是硬件转发，故而存在性能瓶颈。实验证实，高性能软路由往往能支持100Mbps甚至更高速率的外网转发，这一点是普通路由器难以做到的。而对于普通的NAT转发，路由器的硬件加速较软路由有着“四两拨千斤”的效果。

器材：x86机器安装Docker，单网口也可实现软路由。

2. 注意事项

   • clash配置文件中，最好启用skip-verify并启用UDP，虽然这样不安全（中间人攻击），但是要考虑到学校内网是没有certification，IP连接的也占多数
   • 路由器在DHCP过程中会向客户机下发默认网关与IP等信息，在此过程中改变DHCP下发的网关即可对所有的客户端生效。
   • 若测试出现问题，先不要一味认为是软路由故障，网络问题多种多样，还有可能是订阅中的服务器出现连接故障，检测方法是使用4G/5G设备验证。

3. 收获

   软路由确实有效，但是仍旧需要良好的订阅作为支撑

   DHCP默认网关与路由器中路由表的默认网关不同，前者为下发给设备的默认网关，后者不是。对于本校（SNNU），若贸然更改默认网关（后者），会导致路由器掉线，原因是更改默认网关后路由器会重连，与外网无关。

   未解决的问题：

   • WLAN/Ethernet链路聚合失效，原因不明

     这里说的链路聚合，严格意义上说是负载均衡。手动指定WLAN与Ethernet网卡的跃点，可以实现两个网络连接叠加的效果。

   • 主路由的VPN连接失效，具体故障应该是DNS解析失败，IP访问外网正常（但无法接入Google）

     已解决，DHCP配置DNS时不必设为旁路由IP，无法接入Google是因为路由器自己充当了默认网关路由器下发给客户端的默认网关是服务端的IP地址，这是PPTP的特性决定的，后面的想法是对于服务端IP设定特别的网关

   原因分析：可能是下发的默认网关使二者失效，暂时的解决方法是在有需要时更换DHCP默认网关。

   下一步，在软路由上配置双网卡，真正将软路由作为路由器使用。

    

更新

• 软路由在稳定性上存在问题。若软路由死机，网络瞬间崩溃。

  • 为了解决此问题，首先要做的改变是将DHCP服务器下发的默认网关删除，不论软路由是否出现问题，至少应保证网络可用。

  • 解决此问题有两个思路，

    • 继续选择在路由器上使用代理软件，不过应进行优化，例如超频，选用ipset工具减少CPU压力，CPU压力主要来自庞杂的AES加密解密，可选用不加密的链接（此举不推荐，vps的ipv4地址已经被墙，目前使用ipv6地址苟活）。
    • 提升软路由的稳定性，换用kde或xfce桌面。

  • 解决策略：对路由器的CPU实现超频，由880MHz提升至1100MHz，使用SSR+进行代理工作。

  • 弊端：超频依赖CPU体质与主板供电情况，已经有一个路由器因超频损坏了USB3.0接口。另外，超频带来的性能提升不及软路由，连接速度在100Mbps左右，因此应考虑如何解决软路由的稳定性问题。

2024.3.17更新

• 软路由的稳定性问题已有突破口。

  • 据查，软路由的内存有问题，主要表现在随着使用时间增加，内存缓存增多，进行一些安装软件的操作时会出现段错误。为解决此问题，

    • 换内存。此方式不可取，因为电脑不是自己的，电脑归还后内存无用武之地。（2024.11更新，换了另外一个电脑的8GB内存条，目前工作稳定）
    • 换机器。可行，购置一1007U ，2+32的机器，80元。此机器为工控机性质，十分稳定，但不支持硬件AES。放置在宿舍当作软路由机器。
    • 让内存占用降低。关闭图形界面，关闭docker，清除不需要的软件与服务。

  • 尽量使用最少的资源实现功能。

    • 软路由需要配置docker形式的openwrt，不仅配置困难，且许多功能与宿主机重复，由于docker策略（macvlan），宿主机无法访问openwrt。另外，docker挂载硬盘后，宿主机再次挂载会提示设备忙，使得外界访问硬盘只能使用openwrt自带的工具。
    • 根据需求，宿主机只需完成数据包转发与代理即可，转发Linux自己即可完成，开启内核转发，iptables放行转发即可。代理则需要启用clash的tun模式，但需要root权限运行。
    • 数据包转发可以充分利用单个设备的网络连接，只需将设备网关指定为运行代理软件的机器ip即可，尤其适用于对接入设备有限制的代理提供商。

• 遇到的问题：

  • 开启内核转发与tun设备后只能用socks代理连接，无法转发数据包。

    • 使用iptables -F命令清除后成功转发数据包。说明iptables阻碍转发。
    • iptables无法保存，重启后iptables恢复原样。网络上说使用service iptables save,对ubuntu来说明显是错的，没有这个服务。有的说使用iptables-save,明显也不对，运行了依然无法保存。有的说用iptables-persistant,依然如上。
    • 要明白iptables启动的原理，iptables启动后是空的，随后使用/etc/iptables.rules加载规则。目前使用iptables -F 对其无效。观察/etc/iptables.rules 的内容，可以看出forward链中有一条REJECT操作，删除后，重启即可生效。不建议全部删除iptables中的规则，否则会有意想不到的后果。后续需要将REJECT添加回iptables表，并使用

  • clash开机启动

    可以使用以下方法：Sitoi/SystemdClash: Clash 以 systemd 服务的方式开机自启 (github.com)

    需要提醒的是，不同用户运行应指定好配置文件，可用-f参数指定，建议最好将配置文件放入~/.config/clash目录下。例如，此服务以root权限运行，配置文件应放入/root/.config/clash中。

• 使用效果：

  代理可达满速

  工作稳定，内存占用<1GB，平时CPU占用在1%以下，系统负载为0.09（测速时），0.03（有连接时），0.00（无连接时），响应速度快。

2025-01更新

1. 硬件更新

   由于1007U的频率较低，目前已经更换为4核的CPU--Intel Pentium J3710。

   Intel Pentium J3710 是一款发布于 2016 年的低功耗处理器，基于 Braswell 架构。它采用 14 纳米工艺制造，拥有 4 个核心和 4 个线程。J3710 的基础频率为 1.6 GHz，最高睿频可达 2.64 GHz。

   这款处理器最大的特点是其极低的功耗，热设计功耗 (TDP) 仅为 6.5 瓦，根据在供电部分电流实测，其功耗大约在7W左右，与之相比，1007U需要12W左右的供电，且最大频率只有1.5GHz。这是更换的主要原因。

   不过，目前发现，即使J3710睿频更高，其单核性能不及1007U。分析原因后认为此应归因于IPC的问题。简要概括是：高频未必胜出。尽管 J3710 拥有高达 2.64 GHz 的睿频，但在部分单核性能测试中，它却可能落后于频率仅 1.5 GHz 的 1007U。

   J3710 采用的 Braswell 架构，其核心是 Airmont。Airmont 是 Silvermont 的 14nm 制程升级版，主要目标是提升能效比，而非绝对性能。在微架构设计上，Airmont 为了降低功耗，在流水线深度、乱序执行能力等方面做出了一定的妥协。

   相比之下，1007U 采用的 Ivy Bridge 架构，虽然发布时间较早，但在微架构设计上更注重单核性能。Ivy Bridge 继承并优化了 Sandy Bridge 的优秀设计，拥有更深的流水线、更强的乱序执行引擎以及更高效的缓存系统。这些设计上的优势，使得 Ivy Bridge 架构的 IPC 显著高于 Airmont。

   IPC 的差异，直接影响了处理器在每个时钟周期内能够执行的指令数量。即使 J3710 能够以更高的频率运行，但由于 Airmont 架构的 IPC 较低，其单核性能仍可能无法超越 1007U。

   这一对比也提醒我们，在评估处理器性能，尤其是跨架构比较时，不能仅凭频率高低做出判断。深入了解处理器的微架构设计，分析其 IPC 水平，才能更准确地评估其真实性能。

2. 软件更新

   之前一直使用Debian 12，某日因为供电问题导致系统盘的分区故障，修复故障时心血来潮想尝试飞牛OS。飞牛 OS 基于 Debian，且专注于 NAS 应用，这让我对其抱有很高的期望。然而，在实际使用过程中，我却遭遇了 USB 磁盘频繁掉盘的问题，这让我不得不深入探究其背后的原因。

   最初，我怀疑是硬件故障。毕竟，USB 连接的稳定性不如 SATA，可能是接口松动、供电不足，或者 USB 磁盘本身存在问题。我仔细检查了 USB 连接线，确认没有松动；更换了 USB 接口，排除了供电问题；又使用 CrystalDiskInfo 和 HD Tune Pro 等工具在 Windows 系统下对 USB 磁盘进行了全面的健康检查和读写测试，结果均显示磁盘状态良好。至此，硬件层面的疑点基本排除。

   既然硬件没有问题，那么问题必然出在软件层面。我开始将目光转向飞牛 OS 的系统配置和文件系统。飞牛 OS 默认使用 Btrfs 文件系统来管理存储空间。Btrfs 是一种先进的文件系统，具有快照、数据校验、CoW (Copy-on-Write) 等特性。CoW 机制确保了数据修改不会直接覆盖原有数据块，而是写入新的数据块，从而提高了数据安全性，但也对存储设备的 I/O 性能和稳定性提出了更高的要求。

   USB 连接，尤其是 USB 2.0 和早期的 USB 3.0，在数据传输速率和稳定性上，与 SATA 接口存在明显差距。USB 协议在错误处理和数据重传方面也不如 SATA 那么可靠。在 Btrfs 的 CoW 机制下，USB 连接的任何轻微波动，如瞬时断连或数据错误，都可能导致整个数据块写入失败，触发 Btrfs 的错误处理机制。严重情况下，这可能导致文件系统损坏，甚至需要格式化才能恢复。

   为了规避 Btrfs 可能带来的问题，我尝试将 USB 磁盘格式化为更通用的 exFAT 文件系统。然而，USB 掉盘现象依旧频繁发生，数据传输仍然极不稳定。这让我意识到，问题并非仅仅出在 Btrfs 上，而是更深层次的，很可能与飞牛 OS 的 USB 子系统有关。

   Linux 内核的 USB 子系统负责管理所有 USB 设备的连接、通信和电源管理。一个稳定、高效的 USB 子系统，必须能够正确识别各种 USB 设备、处理各种 USB 协议、精确控制 USB 设备的电源状态，并有效地处理 USB 传输过程中可能出现的各种错误。结合我在 Windows 系统下 USB 磁盘工作正常的对比测试，我推断飞牛 OS 的 USB 子系统可能存在缺陷，或者更直接地说，存在较多的 bug。这些 bug 可能体现在设备识别、电源管理、错误处理、兼容性等方面，导致 USB 磁盘在飞牛 OS 下无法稳定工作，具体表现为频繁掉盘。 也可能是Btrfs与不够稳定的USB子系统, 协同工作时放大了问题的影响.

   最终，由于飞牛 OS 在 USB 存储设备上的不稳定表现，我不得不放弃了它，转而使用 Ubuntu。在 Ubuntu下，通过简单的配置，同样的 USB 磁盘运行稳定，再也没有出现过掉盘或数据丢失的问题。这次经历也说明，NAS 系统的选择，不仅要看功能是否丰富，更要注重其底层组件的稳定性，尤其是文件系统和设备驱动的质量。

   此外，NAS的使用方式不同于直接使用Linux，它在数据安全和数据完整性方面有着诸多考量。NAS的另一个优点在于易用性（指类似群晖等成熟NAS），有着用户友好的GUI，而对于常年使用Linux CLI的用户，可能飞牛NAS不是一个成熟的选择。

3. 异地组网

   之前的异地组网选用的是zerotier，原因无他，只是因为可以在R3G上运行。后来无线设备更新为WiFi6，操作系统也变成了OpenWrt，可选的软件就更多了。近一段时间，身体状态由显著改善，最大的改变就是“有心气”，使得我可以耐着性子去阅读全英文的文献、网页。比如在Tailscale Docs的新发现改变了以往我对于异地组网的认识。

   在以前，我一直认为，异地组网离不开中继服务器，它就像是一个路由器一样，把在不同地方的设备连接起来，所有流量的转发都依赖于这个中继服务器。事实上，在早期人们组网也确实是这么做的。Tailscale使用的是去中心化的全新的组网策略，虽然仍需要中继服务器（DERP servers），但其主要作用是转发信令，而不是像传统 VPN 那样承担所有的数据流量转发。这极大地提高了网络的效率和可靠性。而 Tailscale 实现这一目标的关键技术之一，就是 WireGuard 协议，以及在此基础上构建的 subnet router 功能。

   Subnet Router：打通本地网络与 Tailscale 网络的桥梁

   在 Tailscale 网络中，每个设备都有一个唯一的 100.x.y.z 类型的 IP 地址（CGNAT 范围内）。这些设备之间可以直接通过 WireGuard 隧道进行点对点通信，无需经过中继服务器。但如果我想让 Tailscale 网络中的设备访问我本地网络（例如 192.168.1.0/24）中的其他设备，或者反过来，让本地网络中的设备访问 Tailscale 网络，就需要用到 subnet router。

   Subnet router，顾名思义，就是充当子网路由器的角色。你可以将 Tailscale 网络中的一台设备配置为 subnet router，它就像一个网关，连接了 Tailscale 网络和你指定的本地网络（或多个子网）。

   Subnet Router 的工作原理与优势：

   Subnet router 的工作原理并不复杂，但却非常巧妙。它会向 Tailscale 控制服务器宣告自己所代理的子网（例如 192.168.1.0/24）。控制服务器会将这些信息同步到 Tailscale 网络中的其他所有设备。当 Tailscale 网络中的设备 A 想要访问本地网络中的设备 B 时，设备 A 会根据控制服务器提供的信息，知道目标 IP 地址位于 subnet router 代理的子网内，于是，它会建立与 subnet router 的 WireGuard 隧道，并将数据包通过隧道发送给 subnet router。Subnet router 收到数据包后，会根据自己的路由表，将其转发给目标设备 B。响应数据包则以相反的路径返回。

   这种设计带来了几个显著的优势。首先，它是去中心化的。数据流量尽可能在设备之间直接传输，或者通过 subnet router 与本地网络设备之间直接传输。这与传统的 VPN 有着本质的区别。传统 VPN 通常采用客户端-服务器架构，所有流量都必须经过 VPN 服务器，这不仅增加了延迟，降低了带宽利用率，还存在单点故障的风险。而 Tailscale 的去中心化架构，即使中继服务器出现故障，只要设备之间或设备与 subnet router 之间可以建立直接的 WireGuard 隧道，通信就不会中断。

   其次，Subnet router 的配置非常简单。你无需像配置传统 VPN 那样，手动设置复杂的路由规则或进行 NAT 穿透。Tailscale 会自动处理路由宣告和数据转发，你只需要在 subnet router 上启用相应的功能，并指定要代理的子网即可。再次, 安全性也是一个重要优势。所有的数据传输都通过 WireGuard 隧道进行加密，保证了数据的机密性和完整性。

   最后, 灵活性. 你可以在 Tailscale 网络中配置多个 subnet router，分别代理不同的子网, 从而构建复杂的网络拓扑. 并且, 实现这一切都不需要你有公网IP, 只要 subnet router 所在的网络可以访问互联网即可。

   例如，若在假期需要访问学校的服务器，学校服务器没有给sudo权限无法安装Tailscale，只需要选择在内网在线的某一个运行Tailscale设备，配置以下内容：

   x
   1
   sudo tailscale up --advertise-routes=192.0.2.0/24,198.51.100.0/24
   

   其中的网段需要根据自己的实际情况加以配置。例如需要访问10.0.0.0/8子网的内容，只需替换以上的192.0.2.0/24,198.51.100.0/24即可。此外还需启动Linux系统的内核转发，具体就是/etc/sysctl.d的net.ipv4.ip_forward = 1应取消注释，具体操作已有很多教程，此文不再赘述。

   替换后还需要在tailscale的管理界面Approval后才能生效。除Linux外，其他设备均可自动加入子网路由，Linux设备需使用以下命令：

   xxxxxxxxxx
   1
   1
   sudo tailscale up --accept-routes
   

   另外Synology是不支持这么做的。我的Debian运行这个命令时却提示Synology不受支持。后来查看源码后发现我的Debian出现了/usr/syno目录，致使Tailscale安装时安装的是Synology版本的软件。但为何出现这个目录，原因仍旧未知。

   效果：访问速度可以达到200Mbps，使得远程查看流媒体成为现实。