Nanamiの电波发射塔
type: channel
link: https://blog.nanami.tech/
description: Nanamiの电波发射塔 | Nanami 个人技术博客站点 | 欢迎访问!
items: 家庭网络优化: 利用 FakeMesh + 802.11k/v/r 漫游做到全屋 WiFi 无死角覆盖
items: 整活向：使用 OSPFv3 + WireGuard 隧道让一个没有 IPv6 的网络环境也能使用 IPv6 上网
items: HomeLab 实战：使用 LACP 聚合双千兆网口，实现 2Gbps 网络带宽
items: 工程实践教程：基于 IX 前置与 OSPF 动态路由的 IEPL 专线网络搭建方案
items: 一个 EasyTier VPN 参数导致的 iBGP 全面崩溃 - BIRD iBGP 排坑记录
items: 当 Easytier 遇上 mwan3: 一次 VPN 回程路由被劫持的修复实录
items: 记录一则处理 systemd/journald 日志过多导致磁盘 I/O 爆炸及 systemd 处理缓慢的问题
items: 一篇文章搞定 PXE Server 网络启动, 从此装机抛弃物理存储设备 - iVentoy 部署
items: 图形化管理您的 frpc 集群 - Super-frpc 项目介绍
items: K3s 专题向研究 ep4: 部署 Rancher 集群管理平台

家庭网络优化: 利用 FakeMesh + 802.11k/v/r 漫游做到全屋 WiFi 无死角覆盖
type: item
date: 2026-07-27T14:06:00+00:00
description: 前言博主最近在思考如何优化自己的家庭网络环境时, 突然想到对家里的 WiFi 进行一个优化. 由于博主自己是一个人使用一台 AP 的, 所以对 WiFi 信号一直都觉得挺好的. 但是最近家里人和博主反映说家里的 WiFi 信号不是很好, 且走到某个房间里时就基本没信号了. 博主自己使用的是一台小米 AX3600, 但是家里其他人使用的却是一台很普通的 WiFi5 路由器. 所以博主打算给全屋 WiFi 进行一个更新.现状目前的 WiFi 环境是这样的: 博主自己使用 AX3600 拥有一个单独的 SSID, 发射功率和穿墙性能都还可以. 家里人使用的一台 ASUS WiFi5 路由器的功率和穿墙性能都不太行. 对于博主当前家里的这个户型来说很不友好.优化思路目前打算购置两台能刷 OpenWrt 软路由系统的硬路由, 然后配置 FakeMesh, 统一由主路由管理 SSID 和密码之类的配置. 然后两台路由器运行 802.11kvr (WiFi 漫游), 以此来实现自动分配信号更好的 AP. 在网上看了一圈, 发现小米 AX1800 刚好能满足这个需求, 且价格很便宜 (目前二手平台 40 左右就能买到), 所以买了两台 AX3600, 刷了 X-wrt, 准备来做这么一个配置. 当然博主自己使用的 AX3600 因为有特殊需求, 所以不参与这个网络的构建.注: 本文的方案适用于纯 OpenWrt 系列操作系统环境. 如果你想将你的 OpenWrt 路由器和其他硬路由 / AP 等设备进行 WiFi 漫游, 则可以参考 家庭网络更新 - 猫棒 + 802.11k/v/r 漫游 - Kagura iYoRoy开整1. 统一内网网段博主的规划是整个内网使用同一个网段, 因此所有路由器必须处于 AP 模式, 不再承担 DHCP Server 和 NAT 工作, 由主路由负责, 而不是 AP.启动 AP, 接入内网, 打开 WebUI.进入 Network -> Interface 页面, 找到并编辑 lan 接口. 将其 IPv4 地址设置为处于主网段但不与其他设备冲突的地址, 这里博主设置为 192.168.1.253. 然后将网关设置为主路由.切换到 DHCP Server 选项卡, 勾选 Ignore Interface 选项以完全禁用其 DHCP Server, 然后点击 Save 保存删除 wan 和 wan6 接口切换到 Devices 选项卡, 找到 br-lan 接口的 Configure 按钮并点击进行配置勾选所有物理接口和 AP 并单击保存如果你的情况和我一样, 这里列出的接口是 Switch VLAN 类型而不是 Ethernet Adapter, 可以通过这个方式来查找接口.切换到 Network -> Switch 页面从这里我们可以看出, LAN1, LAN2, LAN3 处于 VLAN 1 中, 模式为 Access, 由 CPU (eth0) 负责流量转发, WAN 处于 VLAN 2 中, 由 CPU (eth1) 负责流量转发. 所以上图中的 Switch VLAN: "eth0.1" 就是所有 LAN 口, Switch VLAN: "eth1.2" 就是 WAN 口.同时这种情况还可能导致下游设备没法拿到 IPv6 地址. 这里我们检查 eth0.1, eth1.2 的配置页面, 将 IPv6 Enabled 选项手动改为 enabled.做好所有配置后, 单击 Save&Apply 保存并应用.等待一段时间后, 尝试连接 WiFi, 查看 WiFi 属性可以看到这里已经成功拿到公网 IPv6 地址和 192.168.1.0/24 网段的 IPv4 地址.这样的配置在两台路由器上都需要进行2. 启用 FakeMeshFakeMesh 是 OpenWrt 提供的一个轻量级, 软件模拟的 Mesh 组网功能. 它能够做到在多台 AP 设备中进行统一的配置管理, 实现无缝漫游, 并且简化多路由网络管理.2.1 主路由配置进入 Mesh -> FakeMesh 页面, 勾选 Enable 启用功能在 Mesh ID 处创建当前 Mesh 会话的标识符. 这里建议不要填写英文字母, 下划线, 数字以外的特殊字符, 以免出现编码错误.在 Key 中创建当前 Mesh 会话的加密密钥在 Band 中选择 5G在 Role 处切换至 Controller (AC) 模式模式解释Wired AP 表示该设备为被控制有线 APAgent 表示该设备用于无线 Mesh 组网勾选 Sync Configuration 同步配置在 Band Steering Helper 中选择 usteerusteer: OpenWr…

整活向：使用 OSPFv3 + WireGuard 隧道让一个没有 IPv6 的网络环境也能使用 IPv6 上网
type: item
date: 2026-07-22T15:35:00+00:00
description: 前言博主大学的校园网环境中没有公网 IPv6 出口. 对于博主这种玩网络的人来说十分的不便. 但是博主在学校和在家的主路由都是 OpenWrt, 且之间有一条 VPN 骨干网可以互相通信. 于是乎博主想到了一个方法: 使用类似 Overlay Network 的方式, 通过 OSPFv3 将学校主路由的 IPv6 默认路由下一跳改为家里的主路由, 将家里的 IPv6 网络给校园网用.配置需求对端网关可以互相通信 (可通过 EasyTier, ZeroTier, TailScale 等 VPN)双方网关为软路由系统或可玩性较高的硬路由基础配置思路由于没有 IPv6 环境, 但是 OSPFv3 又需要使用 IPv6 来进行通信, 所以这里我们借助 WireGuard 来建立一条 6in4 通道. 然后使用 Bird v2 来运行 OSPFv3, 将家庭宽带的 ::/0 路由引入该 OSPF 会话, 从而达到校园网网关使用这条线路进行 IPv6 上网的目的.由于该文章编写于暑期阶段, 因此这里将使用 Debian 13 虚拟机作为校园网网关. 该虚拟机已经在内网接口关闭了 IPv6 功能, 因此无法直接通过内网连接公网 IPv6 业务.开整1. 安装并配置 Bird v2由于新版 OpenWrt 系统内置 WireGuard, 因此我们这里只需要另外安装 Bird 即可.进入 WebUI, 打开 System -> Software 页面, 搜索 Bird 并安装 bird2, bird2c安装完成后打开 SSH, 查询 Bird 安装状态root@X-wrt-Home:~# bird --version BIRD version 2.19.1移动配置文件位置并更改配置文件存储位置随着配置愈发复杂, 单个配置文件是无法满足我们的配置要求的. 所以这里我们使用 /etc/bird 来作为配置文件的存储文件夹.实际上, 除了 OpenWrt, 常规 Linux 安装 Bird 时都是采用 /etc/bird 作为配置文件目录mkdir /etc/bird mv /etc/bird.conf /etc/bird/bird.conf vim /etc/init.d/bird将其中的 BIRD_CONF 赋值为 /etc/bird/bird.conf更改完后保存并重启 Bird 进程/etc/init.d/bird restart2. 配置 WireGuard 接口OpenWrt 默认安装 WireGuard, 但没有默认的私钥和公钥, 所以这里我们自己生成进入 SSH, 生成公钥和私钥cd /etc/wireguard wg genkey | tee privatekey | wg pubkey > publickeyOpenWrt 原生支持在 WebUI 中配置和管理 WireGuard 接口, 所以我们这里直接在 WebUI 上进行配置.打开 WebUI, 切换至 Network -> Interfaces, 单击 Add new interface...在 Name 中输入该 WireGuard 接口的名称, 注意不要太长. 然后将 Protocol 切换至 WireGuard VPN在 Private Key 和 Public Key 中填入我们刚刚生成的密钥在 Listen Port 中填入可供 WireGuard 监听的空闲端口在 IP Addresses 中填入一个CIDR 格式的链路本地 IPv6 地址和一个符合 ULA 规范的 IPv6 地址我们这里因为接入的设备不多, 所以即使在考虑冗余的情况下, 给一个 /112 的网段也是绰绰有余了.示例配置切换至 Peers 页面, 点击 Add peer在 Description 中填入对端设备名称在 Public Key 中填入对端设备公钥在 Allowed IPs 中填入对端 WireGuard 内网 IPv6 地址和 ::/0在 Endpoint Host 中填入校园网网关的 VPN 内网地址在 Endpoint Port 中填入校园网网关的 WireGuard 监听地址因为我们还未配置校园网网关接口, 所以这里直接随便写一个端口即可.在 Persistent Keep Alive 中填入 25示例配置配置完成后保存提交相同的配置需要在校园网网关上也配置一遍双方都配置好后, 检查接口状态. 如果接口的 TX 和 RX 都有流量, 那就证明配置成功了. 此时可以进行测试.root@Debian:/etc/wireguard# ping fe80:1::1%tunnel_ipip6 PING fe80::1%tunnel_ipip6 (fe80:1::1%tunnel_ipip…

HomeLab 实战：使用 LACP 聚合双千兆网口，实现 2Gbps 网络带宽
type: item
date: 2026-07-21T04:17:00+00:00
description: 前言博主的 HomeLab 网络环境是支持全链路 10 Gbps 的. 但是博主的 SubSerer 的单个端口却只有 1 Gbps. 由于该服务器负责的是业务流量转发, 其中包含网络代理. 在入户带宽 2000 Mbps 的情况下, 1 Gbps 的单口带宽就显得有些差强人意. 但好在这台服务器有两个这样的 1 Gbps 端口, 博主所使用的交换机也原生支持 LACP. 所以这篇文章就记录了博主尝试通过 LACP 对两个 1 Gbps 接口做链路聚合的过程.什么是链路聚合?简单来说, 链路聚合就是把两台设备之间的多条物理链路聚合在一起, 当做一条逻辑链路来使用. 通过这种技术, 我们不仅可以提升链路总带宽, 我们还可以增强业务 SLA, 随便坏其中任意一条链路都不影响业务可用性.什么是 LACP?LACP 是一种 基于 IEEE 802.3ad 标准的实现链路动态聚合与解聚合的协议. 通过这种协议, 我们可以很轻松的在终端和网络设备之间进行链路聚合, 且能够获得极高的稳定性. 但这种方法也有弊端: 只有终端和网络设备均支持 802.3ad 协议的情况下才可以使用, 这就造成了某些使用廉价 Layer 2 交换机或非网管交换机的用户群体无法使用该协议. 在本篇文章中, 我们只在双方都支持 LACP 的情况下进行配置.开整1. 配置交换机 LACP博主这里使用的是 D-Link 品牌的交换机, 直接使用 Web UI 进行配置. 虽然配置过程可能不同, 但 LACP 协议的基础原理都是通用的. 使用其他品牌交换机的读者也可以进行参考.启动交换机 Web UI, 进入 Link Arrangement 页面的 Port Trunking Settings 子页面.我们这里使用 40 和 48 号端口连接服务器, 所以这里勾选 40, 48 号端口.Group ID 填写的是该 LACP 会话的组 ID. 该参数的作用是标识不同的 LACP 会话, 从而达到一台交换机负责多个 LACP 连接的目的. 这里我们填写 1.Type 标识的是该 Trunk 端口的类型. 有两种可供选择, 分别为 Static 和 LACP, 这里我们选择 LACP.Master Port 标识的是该 LACP 会话的主要端口. 我们需要选择我们做聚合的其中一个端口, 这里我们选择 40 号端口.State 标识的是 LACP 会话的状态. 这里我们选择 Enabled.Trap 标识的是当前 LACP 会话是否开启 SNMP Trap 监听. 如果您的网络环境中存在 SNMP 网关服务器, 且进行了相关配置, 您可以选择 Enable.配置完成后我们单击 Add, 然后切换至 LACP Port Settings 子页面.在这里我们需要将 40 和 48 号端口的 Activity 配置为 Active, 即激活状态.配置完成后, 交换机侧的配置就彻底结束了.2. 配置服务器 LACP博主这里使用的是基于 Debian 13 的 Proxmox 9.2.3 系统.安装管理绑定的工具 ifenslavesudo apt update sudo apt install ifenslave加载指定内核模块, 让内核支持网卡绑定功能sudo modprobe bonding打开 /etc/network/interfaces 文件并按照指示编辑将你的物理网卡 (如 eth0, eth1) 设置为手动模式, 并指定它们属于哪个逻辑 bond 接口.auto eth0 iface eth0 inet manual bond-master bond0 auto eth1 iface eth1 inet manual bond-master bond0配置逻辑接口 bond0, 包括 bonding 的各项参数.auto bond0 iface bond0 inet manual bond-slaves eno1 eno2 bond-mode 802.3ad # 等价于 4 bond-miimon 100 bond-xmit-hash-policy layer3+4如果您使用的是常规 Linux 而非 Proxmox VE, 则这么配置auto bond0 iface bond0 inet static address 192.168.1.100 # 你的服务器IP netmask 255.255.255.0 # 你的网络子网掩码 gateway 192.168.1.1 # 你的网关地址 bond-slaves eth0 eth1 # 指定绑定的物理网卡 bond-mode 4 # 指定 bonding 模式 bond-miimon 100 # 链路检查间隔(毫秒) b…

工程实践教程：基于 IX 前置与 OSPF 动态路由的 IEPL 专线网络搭建方案
type: item
date: 2026-07-19T15:39:00+00:00
description: 前言博主拥有自己的境外服务器, 用于完成自己的业务: Samba 文件备份恢复, 自建网站 CDN, DN42 路由等. 但在这之中, 某些 VPS 的线路并没有对国内有特殊优化, 这导致国内直连的体验非常的糟糕, 同时业务搭建的体验也非常的不好. 这使得博主打算通过购买 IEPL/IPLC 之类的专线业务来提升自己的业务使用体验. 这篇文章将会描述博主搭建专线业务网络的整个过程, 来给各位打算购买专线服务的做一个参考.配置需求可接入 IX 网络的国内前置服务器境外专线 VPS境外普通 VPS善于思考的大脑专有名词解释IEPL (International Ethernet Private Line) / IPLC (International Private Leased Circuit)国际以太网专线, 跨越国家或地区的端到端数字专有带宽连接的租用服务. 不同于普通线路的国际出口, IEPL 和 IPLC 通常拥有非常高的 SLA 保障, 可以做到无论网络是否处于高峰期, 都能够跑满线路的签约速率, 且丢包率通常极低, 甚至在日常业务的使用中可以忽略不记. 这两类线路的延迟也可以做到非常低, 在我们比较熟悉的沪日专线中, 延迟可以做到 ~30ms; 广港因为物理距离近, 延迟更是低到只有 ~3ms. 同时, 由于这两类线路的特殊性质, 其网络通常不受长城防火墙 (Great Fire Wall) 限制, 而是由监管更加严格的傲盾来进行流量监控. 因此, 要想在这样的线路上搭建梯子等违法业务, 是一件很困难的事.IEPL / IPLC 有两种接入方式, 一种为通过 IX 前置接入, 一种为直接接入. 前者无法直接被普通家用/商用宽带访问, 需要可以接入 IX 的云服务器作为跳板机使用. 后者则可以直接在任意网络环境中直接接入.IX (Internet Exchange Point)IX (Internet Exchange Point), 可以理解为一个大型的网络枢纽, 各大云厂商都接入其中, 彼此可以直接且高速地进行数据交换. 同时, 因为 IEPL/IPLC 线路的特殊性, 在国内通常不直接提供入口, 而是接入 IX, 仅由有资质的云厂商提供服务. 所以, 我们普通的家庭网络或者企业网络, 要想使用 IEPL/IPLC 提供的服务, 就必须需要 IX 前置来作为跳板机使用.法律声明本文仅作技术分享, 不教学任何违法违规的技术, 也请勿将本文中提到的技术用于违法违规业务的搭建与使用! 本文读者所造成的一切行为与本文, 本站以及博主无关!开整1. 购买 IX 前置目前, 国内可以接入 IX 的云厂商总共有以下这些阿里云 (Alibaba Cloud)腾讯云 (Tencent Cloud)华为云 (Huawei Cloud)火山引擎 (Volcano Engine)百度智能云 (Baidu Cloud)UCloud (UCloud)下面是它们的优势与劣势云厂商核心优势主要劣势 / 注意事项火山引擎延迟低流量费用高昂阿里云 / 腾讯云成本低, 常有高性价比套餐带宽可能受限, 存在稳定性风险, 且审查更为严格华为云 / 百度云 / UCloud作为备选方案, 可以覆盖更多场景信息相对较少, 具体性能和特定 IX 节点的兼容性需要自行验证数据仅供参考, 具体请以实际体验为准本篇文章选用阿里云的上海轻量服务器和 Debian 系统作为演示2. 搭建 WireGuard VPN 网络这一步的目的是为了让我们自己的设备和境外 VPS 建立直接连接, 使得我们可以直接访问到境外 VPS.2.1 安装 WireGuard我们需要安装 wireguard-tools 软件包, 使用这条指令安装apt install wireguard wireguard-tools -y使用这条指令确认 WireGuard 是否安装成功wg --version示例输出wireguard-tools v1.0.20210914 - https://git.zx2c4.com/wireguard-tools/安装完成后, 生成 WireGuard 密钥对cd /etc/wireguard wg genkey | tee privatekey | wg pubkey > publickey这样的操作需要在你的 IX 前置, 本地服务器, 境外 IEPL VPS 上都执行一遍2.2 规划 VPN 网络在本文的使用环境中, 博主需要建立一共包含多台设备的 WireGuard VPN 网络. 主要设备分别为 IX 前置, IEPL 服务器*, 个人内网网关, 此外还需要包含一些其他境外普通服务器. 所以这里我们直接给 /24 的一整个段.VPN 网络的地址段必须基于内网地…

一个 EasyTier VPN 参数导致的 iBGP 全面崩溃 - BIRD iBGP 排坑记录
type: item
date: 2026-05-28T11:43:00+00:00
description: 前言博主某天在查看自己 DN42 的 Looking Glass 时, 发现几个用于 ASN 内传输路由的 iBGP 协议全部处于 Connection closed 状态, 导致了 ASN 内部无法正常传输路由. 在检查了各项配置且尝试重启无果之后, 意识到这貌似并不是什么简单的问题, 遂尝试解决.网络状态各节点 BIRD: 正常iBGP 节点间通信: 正常iBGP Peer 协商: 不正常网络架构描述iBGP Peer 一共有五台设备, 一台设备处于境内, 与其他四台设备建立 Peer, 其他四台设备处于境外, 这四台设备之间互相不 Peer. 且每台设备都与若干 eBGP 节点进行了 Peer.已确认的部分iBGP 节点间 ASN 相同iBGP Peer 的 IP 地址配置无误节点间防火墙配置无误问题分析iBGP Peer 不成立通常可能是以下几个原因导致的Router ID 冲突Peer IP 地址不匹配TCP MD5 密码不匹配使用 LoopBack 建立连接时, BGP 多跳未配置监听地址与端口不匹配或配置错误某一方 BGP 会话未启动Hold Time 协商问题下面我们一个一个进行分析由于这些 iBGP Peer 的情况都大致相同, 且配置也大致相同. 因此每一步的验证仅取其中一对 Peer 进行查看Router ID 冲突对双方 Router ID 进行检查VM-Subroot@VM-Sub:/etc/bird/ibgp# birdc show status | grep "Router ID" Router ID is 172.23.66.97JPSB01root@JPSB01:~# birdc show status | grep "Router ID" Router ID is 45.xxx.xxx.xxx可以明显看出, 双方 Router ID 不同, 故不是此问题Peer IP 地址不匹配现在对双方在配置文件中的 Peer IP 进行检查VM-Subroot@VM-Sub:/etc/bird/ibgp# cat sb1-jp.conf protocol bgp 'ibgp_sb1-jp' from ibgpeers{ neighbor 10.0.64.103 as DN42_OWNAS; };JPSB01root@ACCK-JPSB01:/etc/bird/ibgp# cat homelab-subserver.conf protocol bgp 'ibgp_homelab-subserver' from ibgpeers{ neighbor 10.0.64.4 as DN42_OWNAS; };双方的 IP 地址均为 WireGuard VPN 内网中的 IP 地址, 因此互相连接时, 源 IP 地址肯定是 VPN 网络中的 IP 地址, 因此不是这个问题.TCP MD5 密码不匹配iBGP Peer 间未单独配置密码, 故不是该问题使用 LoopBack 建立连接时, BGP 多跳未配置iBGP 使用直连连接, 未使用 LoopBack 接口, 连接只有一跳, 故不是该问题监听地址与端口不匹配或配置错误监听地址和端口均为进行修改, 所有配置为 BIRD 默认, 故不存在该问题某一方 BGP 会话未启动双方 BGP 会话均启动, 故不是该问题深入排查现在, 所有可能的原因都排查完了, 但问题还未解决. 还剩怎么排查呢? 我们可以抓包查看具体通信报文是什么. 这里使用 tcpdump 对 179 端口进行监听, 并输出 pcap 文件tcpdump -i any port 179 -vvv -s0 -w bgp.pcap等待一段时间后, 使用 WireShark 打开该文件查看报文这就是具体抓到的数据包. 现在我们过滤所有 eBGP 报文, 仅查看需要检查的两个 iBGP Peer 之间的报文. 使用这个过滤器ip.addr == 10.0.64.4 && ip.addr == 10.0.64.103在这份数据包中我们可以看到, 10.0.64.4 多次尝试向 10.0.64.103 发送 OPEN 报文, 但最终会被 10.0.64.4 发送 RST 报文, 整个连接被重置, 最终导致 BIRD 报错 Connection closed.现在, 我们重新在 10.0.64.103 上进行抓包, 结果如下可以看到, 无论是 10.0.64.4 还是 10.0.64.60, 均只对对方的 TCP 报文进行了处理, 没有任何 BGP 层的处理. 这很奇怪, 如果问题出现在 BGP 层, 那么应该由其中一方发送 BGP Notification 报文来终止连接, 而不是 TCP Reset.鉴于这个问题是突…

当 Easytier 遇上 mwan3: 一次 VPN 回程路由被劫持的修复实录
type: item
date: 2026-05-27T02:48:00+00:00
description: 前言博主使用了 Easytier 在家, 学校, 境内外公网服务器之间通过 WireGuard 协议建立了一个三层 VPN 网络. 平日里在学校或出门在外都会通过这个 VPN 网络连接家里的设备, 访问家里搭建的业务. 在博主今天尝试在学校连接家里服务器上的 SMB 时, 发现全部连接失败, 故着手研究原因.网络拓扑架构在 HomeLab 中, 有三台设备代理了 192.168.1.0/24 网段, 即其他设备可以走这三个节点访问该网段. 且对于该网段的访问没有专门的 ACL 限制, 所有设备均可访问在校园节点中, 网关代理了 192.168.20.0/24 网段, 同样可以被所有设备访问链路状态相关节点状态: HomeLab (在线), Router-School (在线)链路通信状态校园节点在网关上与 192.168.1.0/24 段的设备通信正常, 但下游设备与该网段的通信时不正常HomeLab 中所有节点的网络通信状态与子网代理状态都是正常的疑点: 下游设备与 192.168.1.14/32 通信时正常, 但与该网段中其他所有设备通信都不正常. 表现为 ICMP Ping 无回包, 业务数据访问不通问题分析造成该故障最常见的原因可能有以下几点回程路由缺失反向路径过滤 (rp_filter) 导致回包被丢弃IP 转发未开启Easytier 的出口策略 / 策略路由冲突我们这边逐个来排查1. 回程路由缺失请求: 192.168.20.0/24 → 网关 → tun0 → VPN → 192.168.1.0/24回包: 192.168.1.0/24 → VPN → 网关 tun0 → ??? → 192.168.20.0/24网关自身访问时, 源地址通常是 tun0 的 IP (10.0.64.253), 这个地址天然在 VPN 路由域内, 对端可以直接回包.而下游设备访问时, 源地址保留为 192.168.20.x, 如果对端节点没有去往 192.168.20.0/24 的路由, 回包就会丢失或走默认路由被丢弃.这里检查校园网关的路由表root@X-wrt-School:~# ip rou default via 10.131.0.1 dev pppoe-wan proto static metric 40 default via 10.151.0.1 dev pppoe-xwan01 proto static metric 41 default via 10.141.0.1 dev pppoe-xwan02 proto static metric 42 default via 10.141.0.1 dev pppoe-xwan03 proto static metric 43 default via 10.151.0.1 dev pppoe-xwan04 proto static metric 44 10.0.64.0/24 dev tun0 proto kernel scope link src 10.0.64.253 10.0.64.0/24 dev tun0 proto static metric 65535 10.10.64.0/24 dev tun0 proto static metric 65535 10.131.0.1 dev pppoe-wan proto kernel scope link src 10.131.15.37 10.141.0.1 dev pppoe-xwan02 proto kernel scope link src 10.141.102.228 10.141.0.1 dev pppoe-xwan03 proto kernel scope link src 10.141.40.183 10.151.0.1 dev pppoe-xwan01 proto kernel scope link src 10.151.10.205 10.151.0.1 dev pppoe-xwan04 proto kernel scope link src 10.151.32.226 169.254.0.0/16 dev br-lan proto kernel scope link src 169.254.254.254 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 192.168.1.0/24 dev tun0 proto static metric 65535 192.168.3.0/24 dev tun0 proto static metric 65535 192.168.20.0/24 dev br-la…

记录一则处理 systemd/journald 日志过多导致磁盘 I/O 爆炸及 systemd 处理缓慢的问题
type: item
date: 2026-05-22T08:00:00+00:00
description: 前言博主在使用自己开发的 super-frpc 项目时, 注意到每次程序启动的时候, 磁盘 I/O 都会被占满. 一开始博主以为是被攻击, 后面使用 htop 查询发现, 占用量最大的进程分别为 systemctl status superfrpc_* 和 journalctl -u superfrpc_* -n 50 --no-pager. 这两者的相同点是都会读取最近日志. 因此引出了本篇文章所需要解决的问题.故障分析为什么 systemctl status 也会造成大量 I/O 开销首先, systemctl status * 并不会直接造成大量磁盘 I/O, 但是它会执行下面这些隐藏动作:查询 unit 状态读取最近日志 (journalctl)显示最近几十行 stdout / stderr解析 cgroup / PID / 状态信息也就是说, 实际上 systemctl status * 隐式执行了journalctl -u superfrpc_*.service -n 10为什么 journalctl 查询日志会造成大量 I/O 开销众所周知, 正常情况下查询 systemd 服务日志应当是一瞬间的事情. 但如果你的日志符合以下任意一条特征:该服务日志量巨大日志没有被 rotatejournal 文件非常大journal 已损坏日志开启了压缩日志存储在机械盘btrfs / zfs 上有校验/压缩那么, journald 就会疯狂读磁盘, 造成巨大 I/O 开销.super-frpc 本身出了什么问题主进程行为在 super-frpc 的执行框架中, 如果用户开启了 watchdog 监听, 那么当主进程启动时, 会一并拉起 watchdog 进程, 然后检测现在已经开启的所有隶属于 super-frpc 的 frpc 服务进程, 并将已经启动的服务进程托管至 watchdog 进行监听.watchdog 行为watchdog 在收到来自主进程的监听任务时, 会启动一个 runMonitor 的 goroutine. 在该函数中调用了一个 checkServiceLogs 的函数, 负责监听程序日志中的报错行为. 以下为修改前的 checkServiceLogs 函数代码func checkServiceLogs(serviceName string) (bool, error) { cmd := exec.Command("journalctl", "-u", serviceName, "-n", "50", "--no-pager") output, err := cmd.Output() if err != nil { return false, fmt.Errorf("failed to execute journalctl: %w", err) } logContent := string(output) errorKeywords := []string{"error", "fatal", "failed", "critical", "exception"} for _, keyword := range errorKeywords { if strings.Contains(strings.ToLower(logContent), keyword) { return false, nil } } return true, nil }可以看出, 这里调用了 journalctl 对服务进行了日志的查询. 而这样的查询任务会在每一个新服务被添加到监听列表时都会执行一遍, 且是持续监听. 这也就导致了磁盘 I/O 爆炸.故障排查查询整个 journald 日志所占据的磁盘空间nanami114@VM-Sub:~/PersonalFiles/super-frpc$ journalctl --disk-usage Archived and active journals take up 4.0G in the file system.可以看到, 光是日志就已经占据了 4.0G 的巨大空间, 这也就导致了 journald 读取日志时的大量磁盘开销. 同时也说明了本次博主所碰到的问题属于 服务日志量巨大故障修复临时删除不需要的日志nanami114@VM-Sub:~/PersonalFiles/super-frpc$ sudo journalctl --vacuum-size=500M # 将除最新的 500MB 日志以外的日志全部删除 Deleted archived journal /var/log/journal/e2bc53213dbb447bab4d9898e22776fa/system@cda8f901…

一篇文章搞定 PXE Server 网络启动, 从此装机抛弃物理存储设备 - iVentoy 部署
type: item
date: 2026-05-20T06:17:00+00:00
description: 前言在做网络运维的过程中, 常常会碰到需要给各种物理机或虚拟机安装系统的情况. 以往装系统都是通过 U 盘等物理存储介质进行安装. 这种安装方式不仅效率低, 还可能因为 U 盘速率不达标而导致安装过程缓慢. 本篇文章将会给大家介绍一种效率极高且速率极快的系统安装方式 - PXE 网络启动. 使用 PXE Server 安装系统不仅可以做到几百台设备同时安装, 还可以做到通过一个通道, 自由安装不同种类, 不同平台的操作系统.需要注意的是, PXE 技术不仅可以用于安装系统, 还可以托管操作系统, 使下游设备做到无盘启动. 本文只介绍前者的解决方案.配置需求一台网络接口 1Gbps 及以上, 硬盘速率足够的物理机/虚拟机支持配置 TFTP Server 的硬/软路由本篇文章使用基于 OpenWrt 的 X-wrt 作为演示开整安装 iVentoy在待配置为 PXE Server 的设备上安装 Debian/Ubuntu 操作系统 (略).在官方发布页 中根据设备架构下载 iVentoy 的软件包截至本文编写时, 官方最新版本为 1.0.30. 如果是 x86_64 设备, 需要下载的文件为 https://github.com/ventoy/PXE/releases/download/v1.0.30/iventoy-1.0.30-linux-x86_64-free.tar.gz解压下载的软件包tar -xzvf https://github.com/ventoy/PXE/releases/download/v1.0.30/iventoy-1.0.30-linux-x86_64-free.tar.gz启动 iVentoycd iventoy-1.0.30 chmod +x ./iventoy.sh ./iventoy.sh start脚本运行后, 默认运行在 26000 端口上. 以下是输出示例iventoy start SUCCESS PID=2040 Please open your browser and visit http://127.0.0.1:26000 or http://x.x.x.x:26000 (x.x.x.x is any valid IP address)使用浏览器输入 http://<Server IP>:26000, 即可进入 iVentoy 的配置页面.在主页中按照您的需求进行配置Select Server IP - 选择服务器 IP. 这里列出的是当前服务器的 IP 地址NIC Name - 服务器网卡名称.Subnet Mask - 子网掩码.Gateway - 网关.IP Pool (begin) - PXE Boot IP 地址池起始. 注意: 免费版的 iVentoy 一次性支持 20 个客户端同时启动, 故此处设置 20 个 IP 即可IP Pool (end) - PXE Boot IP 地址池末尾.DNS Server - DNS 服务器地址. 置空即可进入 Configuration 页面, 按照需求对 iVentoy 的启动方式进行配置DHCP Server Mode - DHCP 服务器模式. 这里推荐保持不变Boot Background Mode - 启动时背景模式. 这里推荐选择 GUI, 即图形化用户界面Boot Menu Resolution - 启动菜单分辨率. 可以不用设置太高, 合适即可EFI Boot File - EFI 引导文件. 按需选择, 如果没有特殊要求, 保持默认即可System Boot Password - 系统引导密码. 选择 PXE 引导时是否需要输入密码, 如不需要置空即可System Default Image - 系统默认映像. 选择 iVentoy 默认引导的系统映像, 如无特殊需求置空即可Page Default Language - 页面默认语言.导入 ISO 映像在软件包解压后的目录中有一个 iso 文件夹, 将您的所有 ISO 映像文件放入该文件夹即可.注: 您也可以使用 NFS/SMB 将存有映像文件的网络目录挂载到 iso 目录, 当然使用硬链接也是可以的配置 TFTP Server本文使用基于 OpenWrt 的 X-Wrt 进行演示进入设备 WebUI, 依次选择 Network (网络) --> DHCP --> dnsmasq --> PXE/TFTP勾选 Enable TFTP Server (启用 TFTP 服务器)在下方的 Special PXE boot options for Dnsmasq. 表格中点击 Add (添加) 按钮在对话框中填入您的相关配置.Filename - 引导文件文件名. 填入 i…

图形化管理您的 frpc 集群 - Super-frpc 项目介绍
type: item
date: 2026-05-13T05:28:00+00:00
description: Super-frpc让 frp 客户端集群管理变得可视化, 自动化, 可靠化.项目简介将您的所有 frp 客户端实例置于一个 WebUI 中进行管理. 集中化, 标准化, 自动化. 增强您的 frp 链路鲁棒性, 让您的 frp 实例管理更方便, 更快捷该项目目前处于预发布阶段, 可能会遇到各种不确定的 Bug 和有待完善的功能. 还请各路大佬高抬贵手, 有能力的帮忙完善项目项目特色集中管理: 使用一个后端服务, 一个 WebUI, 就可以一次性对所有 frp 实例进行管理跨平台: 同时支持 Windows, GNU/Linux 平台 (GNU/Linux 平台目前支持 systemd, initd)基于角色的访问控制: 系统内置三种用户角色 (visitor, admin, superuser), 每个角色权限明确, 使得您可以安排您信任的人共同维护您的 frp 客户端集群轻松部署: 整个项目使用二进制方式部署, 方便快捷, 部署难度低操作简单: Web 面板内各个功能模块分区明确, 操作简单易上手自动化运维: 内置 Watchdog 程序, 可以对您的 frp 客户端实例进行监控. 一旦检测到程序报错, 会先自行尝试恢复, 如无法恢复, 可以通过您自行设定的通知渠道来通知您技术栈开发语言: Go, Vue3后端模块: BurntSushi/toml, gorilla/websocket, modernc.org/sqlite数据库: SQLite支持平台GNU/Linux (systemd, initd)Windows 10 or Up其中, 主程序的测试已在 Linux 中完成, 但 watchdog 在目前的版本中只支持 systemd 管理器的 Linux 平台项目地址Gitea截图部署Linux 平台在 后端发布页面 中下载最新发行版的二进制程序, 并将其放入新建文件夹中给予可执行权限chmod +x super-frpc在相同目录中新建 watchdog 文件夹mkdir watchdog在 Watchdog 发布页 中下载最新发行版的二进制程序, 并将其放入 watchdog 文件夹中赋予可执行权限chmod +x watchdog_systemd退回上一级, 并以 root 用户执行主程序如果程序执行没有报错, 则证明正常运行. 程序会默认监听 7000 端口, 可以通过该端口进入内嵌的 WebUI进入 frp 官方发布页 下载最新 frp 二进制文件发行压缩包解压到 super-frpc 目录tar -xzvf frp_0.69.0_darwin_amd64.tar.gz赋予 frpc 可执行权限chmod +x frp_0.69.0_darwin_amd64/frpc进入程序 WebUI, 按照初始化提示进入设置页面, 填入 frpc 二进制文件的绝对路径, 并按照要求和需求完成剩余设置后应用并重启如果一切正常, 那么您已经成功部署了!在初次进入程序时, 程序会要求您进行初始化设置.

K3s 专题向研究 ep4: 部署 Rancher 集群管理平台
type: item
date: 2026-04-20T04:18:00+00:00
description: 前言随着业务量的上涨与集群节点的增加, 我们使用 kubectl 命令行工具进行运维会逐渐变得困难, 并且也无法实时监测到每个节点的实时状态. 这时, 一套好用的图形化监控与运维工具就成为了我们的刚需. 这篇文章将会详细描述 Kubernets 图形化运维工具 Rancher 的搭建与配置过程本文章同样适用于 K8s配置需求可运行的 K3s/K8s Master 节点与至少一个 Worker 节点开整安装 HelmHelm 是一个为 Kubernets 开发的包管理器, 它简化了应用的部署与管理. 它使用 Helm charts, 这是一个定义了 Kubernets 资源分配的 YAML 文件, 为自动化的安装, 升级, 管理 Kubernets 集群应用程序而生.个人翻译, 有错见谅, 原文如下:Helm is a package manager for Kubernetes that simplifies the deployment and management of applications. It uses Helm charts, which are collections of YAML files that define Kubernetes resources, to automate the process of installing, upgrading, and managing applications in a Kubernetes cluster.安装 Helm 软件源与 GPG Keysudo apt-get install curl gpg apt-transport-https --yes curl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null echo "deb [signed-by=/usr/share/keyrings/helm.gpg] https://packages.buildkite.com/helm-linux/helm-debian/any/ any main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list更新软件源并安装 Helm可能需要科学上网sudo apt update sudo apt install helm安装 cert-manager可以在 这里 看到 Rancher 的支持平台与配置需求添加 Rancher 软件源helm repo add rancher-latest https://releases.rancher.com/server-charts/latest在 Kubernets 中创建 Rancher 的 namespacekubectl create namespace cattle-system添加 cert-manager 清单文件kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/<VERSION>/cert-manager.crds.yamlVERSION Github 上的版本 Tag, 需要您自己填写添加 jetstack 软件源helm repo add jetstack https://charts.jetstack.io更新软件源helm repo update安装 cert-managerhelm install cert-manager jetstack/cert-manager \ --namespace cert-manager \ --create-namespace注: 如果您在安装过程中碰到报错 Error: INSTALLATION FAILED: Kubernetes cluster unreachable: Get "http://localhost:8080/version": dial tcp [::1]:8080: connect: connection refused, 则您需要按照如下步骤进行配置Q. 为什么会报错?A. helm v3 版本不再需要 Tiller, 而是直接访问 ApiServer 来与 k8s 交互，通过环境变量 KUBECONFIG 来读取存有 ApiServre 的地址与 token 的配置文件地址, 默认地址为 ~/.kube/config *转自 CSDN修改 /etc/…