Nanamiの电波发射塔

校园网 VLAN 接入 AP 与自动认证

Fri, 09 Oct 2026 07:16:00 GMT

前言

博主的学校宿舍楼在大一的暑假进行了一次翻修, 开学回来后虽然设施是翻新了, 但是居然把墙上的网络面板给弄坏了! 这让博主这种十分依赖有线低延迟和链路聚合的用户十分气愤. 学校的 AP 不仅性能弱, 延迟高. 且每次连接都需要重新在 Captive Protocol 中进行认证, 十分不方便. 一开始得到的回复是十月中旬之前会全部弄好, 但现在已经将近十月中旬了, 也没见有人来施工. 在思考的过程中, 博主将目标转向了每个寝室都会安装的 AP, 思考能不能在这块做些什么. 于是乎就有了今天这篇文章.

环境介绍与研究目标

AP 是通过每层楼的 PoE 汇聚交换机接入的, 每个寝室都有. 正常的连接方式是下游 STA 设备通过 WiFi 接入, 然后登录学校的 Captive Protocol 进行认证上网. 博主这里打算将接入 AP 的这条网线接入自己的 OpenWrt 路由器, 实现有线上网.

观前须知

注意: 本文为纯整活向文章, 这种上网方式既不合适也不推荐. 不单单是因为麻烦, 还有可能会因为私自修改学校网络设备被校方追责. 看个乐呵就行, 不要照做! 如不听劝, 那后果自负!

开整

1. 探明网络架构

将网线直接接入路由器, 发现 DHCP 能拿到地址

路由器接入 AP 网线后通过 DHCP 获取地址

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1492 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:e0:4c:d0:1f:f7 brd ff:ff:ff:ff:ff:ff
    inet 172.17.255.165/18 brd 172.17.255.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::2e0:4cff:fed0:1ff7/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever

正常来说下游 STA 访问外部网站会被直接 302 到门户网站, 这里博主在电脑上尝试后发现并不能. 这里博主使用了一台手机连接学校的 WiFi, 拿到了门户网站的地址, 随后在路由器侧测试 DNS. 发现 DNS 是能通的.

root@X-wrt-School:~# nslookup *.edu.cn
Server:         127.0.0.1
Address:        127.0.0.1:53

Non-authoritative answer:
Name:   *.edu.cn
Address: 211.*.*.*

Non-authoritative answer:

尝试直接 ping 门户网站服务器, 发现无法通信

root@X-wrt-School:~# ping 211.*.*.*
PING 211.*.*.* (211.*.*.*): 56 data bytes
^C
--- 211.*.*.* ping statistics ---
6 packets transmitted, 0 packets received, 100% packet loss

2. 分析路由策略

观察后发现, 路由器侧拿到的 DHCP 地址为 172.0.0.0/8 段, 但是 STA 侧如果连接 WiFi, 拿到的地址就是 10.0.0.0/8 段, 这与路由器拿到的地址不一致. STA 使用这个地址段的 IP 可以直接访问到门户网站, 而路由器却不行. 因此可以推测: 下游设备到门户服务器中的路由有防火墙, 且可能仅对 10.0.0.0/8 地址段开放. 既然 STA 连接 WiFi 能拿到 10.0.0.0/8 的地址, 那么路由器肯定也是能通过某些方法拿到这段地址的. 这里最有可能的方式便是 VLAN. 使用 Wireshark 对路由器进行抓包, 发现三条 VLAN. 分析后发现其对应的网段如下

VLAN ID	Network
`602`	`10.130.0.0/16`
`604`	`10.140.0.0/16`
`606`	`10.150.0.0/16`

使用 STA 连接 AP 发射的三条 WLAN, 发现网段与 ISP 的对应关系如下

VLAN ID	Network	ISP
`602`	`10.130.0.0/16`	CTNET
`604`	`10.140.0.0/16`	CMCC
`606`	`10.150.0.0/16`	CUNIQ

知道了这些信息, 我们就可以着手开始在路由器侧进行配置了.

3. 接口配置

打开 LuCi WebUI, 转到 Network -> Interfaces -> Devices, 点击 Add device configuration... 添加接口配置
Device type 选择 VLAN (802.1q), 填入对应 VLAN ID 和接口名称.

注意: 这里有多少个用户就需要创建多少个 VLAN 端口, 否则因为接口参数不变, 不管创建多少个 DHCP 拿到的永远都是同一个地址. 如果需要在一个接口上创建多个 VlanIf, 则需要将第 >=2 个 VlanIf 接口的 MAC 地址做更改. 值与接口本身不同即可.
创建 VLAN 802.1q 设备并填写 VLAN ID

接口全部创建完成后单击保存并应用.
全部配置
转到 Interfaces 选项卡, 点击 Add new interface... 添加新接口
协议选择 DHCP Client, 名称按需填写, 接口则选择刚刚创建的 VlanIf 接口
转到 Advanced Settings, 将 Use default gateway 取消勾选

注意: 这一步非常重要, 如果不取消勾选, 系统将会在路由表内自动创建一条到达该接口网关的默认路由. 这个操作会影响当前路由器的正常上网! 出于隐私考虑, 也推荐将 General Settings 中的 Hostname to send when requesting DHCP 选项改为 Do not send a hostname.

全部创建完成后, 单击保存并应用. 如果全部可以正常获取地址, 则该部分配置完成.
创建 DHCP Client 接口并取消默认网关

注意: 在某些 aarch64 机型上, SoC 可能会限制同一个 VID 只能创建一个 VlanIf 设备. 如果您使用 VlanIf 创建 DHCP Client 时, 出现报错 DEVICE_CLAIM_FAILED, 则可能是这个原因. 这种情况下最合适的做法是: 基于该接口创建一个 VlanIf 接口, 然后多用户使用 Mac VLAN 接入.

4. 尝试登录网络

在之前的分析中, 我们获得了 Captive Protocol 认证门户的 IP 地址, 所以我们这里随便找一个 MAC VlanIf 接口作为出口, 写一条到认证门户的路由即可测试.

ip r add 211.*.*.*/32 via 10.150.0.1 dev lan1.cuniq-***

路由写进去后使用下游设备登录门户网站

校园网 Captive Portal 登录页面

发现成功登录. 输入正确的校园网账号密码后可以正常登录.

校园网认证成功页面

至此, Captive Protocol 门户的验证也完成了.

5. 持久化

注销刚刚登录的校园网账号, 打开 BurpSuit 进行抓包. 分析后发现登录过程如下:

获取客户端 IP — 从门户页面的 CONFIG 嵌入信息中提取 ip 字
获取 Challenge Token — GET /cgi-bin/get_challenge?username=<账号@域名>&ip=<IP>&callback=cb, 返回 64 字节 hex token (有效期 60 秒)
HMAC-MD5 — hmd5 = HMAC-MD5 (key=密码, msg=token), 逆向自 all.min.js 中 md5 v2.10.0 库的 A(n,t,r) 函数, 双参数时实际调用的是 HMAC
用户信息加密 — 将的 JSON 用 XXTEA (delta=0x9E3779B9) 以 token 为密钥加密, 再用自定义 Base64 字母表 LVoJPiCN2R8G90yg+hmFHuacZ1OWMnrsSTXkYpUq/3dlbfKwv6xztjI7DeBE45QA 编码, 前缀 {SRBX1}
校验和 + 登录 — chksum = SHA1(token+username + token+hmd5 + token+acid + token+ip + token+n + token+type + token+info), 然后 GET /cgi-bin/srun_portal 发起 JSONP 登录

根据逆向结果, 我们可以写一份登录脚本

USERNAME=""
PASSWORD=""
DOMAIN=""
INTERFACE=""
GATEWAY=""
CPURL=""

# Set IP route to captive protocol server
ip route add 211.*.*.* via $GATEWAY dev $INTERFACE
echo "Route added, sleep 5s..."
sleep 5

set -euo pipefail

# Get AC_ID from captive protocol url
AUTH_HOST="$(printf '%s\n' "$CPURL" | sed -nE 's#^https?://([^/]+)/.*#\1#p')"
ACID="$(printf '%s\n' "$CPURL" | sed -nE 's/.*ac_id=([0-9]+).*/\1/p')"
[ -z "$ACID" ] && ACID="1"

echo "=== Srun Portal Login ==="
echo "Captive Protocol Server: $AUTH_HOST"
echo "ac_id:      $ACID"
echo "Username:     ${USERNAME}${DOMAIN}"
echo ""

python3 - "$AUTH_HOST" "$ACID" "$USERNAME" "$PASSWORD" "$DOMAIN" << 'PYTHON_SCRIPT'
import sys, json, hmac, hashlib, base64, re, urllib.request, urllib.parse, time

auth_host, ac_id, username_raw, password, domain = sys.argv[1:6]
username = username_raw + domain
base_url = f"http://{auth_host}"

# ---- HTTP GET with retry ----
def http_get(url, timeout=15, retries=5):
    last_err = None
    for attempt in range(1, retries + 1):
        try:
            req = urllib.request.Request(url, headers={'User-Agent': 'Mozilla/5.0'})
            with urllib.request.urlopen(req, timeout=timeout) as resp:
                return resp.read().decode('utf-8')
        except Exception as e:
            last_err = e
            wait = attempt * 3
            print(f"  [retry {attempt}/{retries}] {e} — waiting {wait}s...", file=sys.stderr)
            time.sleep(wait)
    raise last_err

def parse_jsonp(body):
    m = re.search(r'\((\{.*\})\)', body, re.S)
    return json.loads(m.group(1)) if m else json.loads(body)

# ---- XXTEA Enc ----
def xxtea_encrypt(text, key):
    if text == '':
        return ''
    def str_to_ints(s, append_len):
        c = len(s)
        v = []
        for i in range(0, c, 4):
            n = (ord(s[i]) if i < c else 0)
            n |= (ord(s[i+1]) if i+1 < c else 0) << 8
            n |= (ord(s[i+2]) if i+2 < c else 0) << 16
            n |= (ord(s[i+3]) if i+3 < c else 0) << 24
            v.append(n & 0xFFFFFFFF)
        if append_len:
            v.append(c)
        return v

    def ints_to_str(v):
        chars = []
        for val in v:
            chars.append(chr(val & 0xff))
            chars.append(chr((val >> 8) & 0xff))
            chars.append(chr((val >> 16) & 0xff))
            chars.append(chr((val >> 24) & 0xff))
        return ''.join(chars)

    v = str_to_ints(text, True)
    k = str_to_ints(key, False)
    if len(k) < 4:
        k.extend([0] * (4 - len(k)))
    n = len(v) - 1
    z, y = v[n], v[0]
    DELTA = 0x9E3779B9
    M = 0xFFFFFFFF
    q = 6 + 52 // (n + 1)
    d = 0
    while q > 0:
        d = (d + DELTA) & M
        e = (d >> 2) & 3
        for p in range(n):
            y = v[p + 1]
            m = ((z >> 5) ^ (y << 2)) & M
            m = (m + (((y >> 3) ^ ((z << 4) & M)) ^ (d ^ y))) & M
            m = (m + (k[(p & 3) ^ e] ^ z)) & M
            z = v[p] = (v[p] + m) & M
        p = n
        y = v[0]
        m = ((z >> 5) ^ (y << 2)) & M
        m = (m + (((y >> 3) ^ ((z << 4) & M)) ^ (d ^ y))) & M
        m = (m + (k[(p & 3) ^ e] ^ z)) & M
        z = v[n] = (v[n] + m) & M
        q -= 1
    return ints_to_str(v)

# ---- Custom Base64 ----
CUSTOM = 'LVoJPiCN2R8G90yg+hmFHuacZ1OWMnrsSTXkYpUq/3dlbfKwv6xztjI7DeBE45QA'
STD    = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/'
def custom_b64(data_bytes):
    std_b64 = base64.b64encode(data_bytes).decode('ascii')
    return std_b64.translate(str.maketrans(STD, CUSTOM))

# ---- Step 0: Get Client IP ----
try:
    page = http_get(f"{base_url}/srun_portal_pc?ac_id={ac_id}&theme=pro")
    m = re.search(r'ip\s*:\s*"([^"]+)"', page)
    client_ip = m.group(1) if m else ''
except Exception as e:
    print(f"[!] Failed to get client IP: {e}", file=sys.stderr)
    sys.exit(1)
if not client_ip:
    print("[!] Could not parse client IP from portal page", file=sys.stderr)
    sys.exit(1)
print(f"Client IP: {client_ip}")

# ---- Step 1: Get Challenge Token ----
cb = f"srun{int(time.time()*1000)}"
params = urllib.parse.urlencode({'username': username, 'ip': client_ip, 'callback': cb})
resp = parse_jsonp(http_get(f"{base_url}/cgi-bin/get_challenge?{params}"))
if resp.get('error') != 'ok':
    print(f"[!] Failed to get challenge token: {resp}", file=sys.stderr)
    sys.exit(1)
token = resp['challenge']
print(f"Token:       {token[:16]}...")

# ---- Step 2: HMAC-MD5(key=password, msg=token) ----
hmd5 = hmac.new(password.encode('utf-8'), token.encode('utf-8'), hashlib.md5).hexdigest()

# ---- Step 3: Encrypted user info (XXTEA + Custom Base64) ----
info_json = json.dumps({
    'username': username,
    'password': password,
    'ip': client_ip,
    'acid': ac_id,
    'enc_ver': 'srun_bx1'
}, separators=(',', ':'))
encrypted = xxtea_encrypt(info_json, token).encode('latin-1')
info = '{SRBX1}' + custom_b64(encrypted)

# ---- Step 4: Calculate chksum = SHA1(token + ...) ----
n_val, type_val = 200, 1
chk = (token + username + token + hmd5 + token + ac_id +
       token + client_ip + token + str(n_val) +
       token + str(type_val) + token + info)
chksum = hashlib.sha1(chk.encode('utf-8')).hexdigest()

# ---- Step 5: Post Login Request ----
login_params = urllib.parse.urlencode({
    'action': 'login',
    'username': username,
    'password': '{MD5}' + hmd5,
    'os': 'Linux',
    'name': 'Linux',
    'double_stack': '0',
    'chksum': chksum,
    'info': info,
    'ac_id': ac_id,
    'ip': client_ip,
    'n': str(n_val),
    'type': str(type_val),
    'callback': cb
})
result = parse_jsonp(http_get(f"{base_url}/cgi-bin/srun_portal?{login_params}"))

err = result.get('error', '')
suc = result.get('suc_msg', '')

if err == 'ok' and suc == 'login_ok':
    print(f"\n[OK] Login successfully!")
    print(f"  User: {result.get('username', username)}")
    print(f"  IP:   {result.get('client_ip', client_ip)}")
    msg = result.get('ploy_msg', '')
    if msg:
        print(f"  Message: {msg}")
elif err == 'ok' and 'already_online' in suc:
    print(f"\n[OK] This IP is already online")
elif 'already_online' in err:
    print(f"\n[OK] This IP is already online")
else:
    print(f"\n[FAIL] Failed to login: {result.get('error_msg', err)}", file=sys.stderr)
    sys.exit(1)
PYTHON_SCRIPT

# Remove IP route
ip route del 211.*.*.* via $GATEWAY dev $INTERFACE

填写好参数后执行脚本

Route added, sleep 5s...
=== Srun Portal Login ===
Captive Protocol Server: 211.*.*.*
ac_id:      2
Username:     ***

Client IP: 10.150.196.77
Token:       ***...

[OK] Login successfully!
  User: ***
  IP:   10.150.196.77
  Message: E0000: Login is successful.

可以看到, 已经登录成功了. 接下来只需要写一份 init.d 脚本, 让 initd 在每次启动时执行一遍脚本登录就可以了. 这份脚本可以复制多份, 以对应不同的用户登录.

如果你的学校用的也是 SRun (深渊) 软件, 或许这份脚本也可以帮到你.

创建 initd 脚本

vim /etc/init.d/srun_login
chmod +x /etc/init.d/srun_login

将以下内容填入脚本

#!/bin/sh /etc/rc.common

USE_PROCD=1
START=95
STOP=15

start_service() {
    procd_open_instance
    procd_set_param command /root/srun_login/srun_login.sh
    procd_set_param respawn ${respawn_threshold:-3600} ${respawn_timeout:-5} ${respawn_retry:-5}
    procd_set_param stdout 1
    procd_set_param stderr 1
    procd_close_instance
}

stop_service() {
}

启用开机启动并启动脚本

/etc/init.d/srun_login enable
/etc/init.d/srun_login start

6. 链路聚合

博主之前已经写过一篇利用 mwan3 做链路聚合的文章. 具体可以查看这里. 本篇文章就不再赘述.

至此, 所有配置均已完成.

总结

本人非专业人士, 如有错误或疏漏请指出. 感谢阅读!

盛科 CTC7132 逆向: 解锁 SFP+ 2.5G

Wed, 07 Oct 2026 13:51:00 GMT

前言

博主前段时间购入了一台基于 Centec CTC7132 平台的企业级交换机. 其拥有 48 个 2.5Gbe 电口, 4 个 SFP+ 光口和两个 40G QSFP 光口. 同时, 博主也购入了两条 2.5Gbe 的 SFP GPON 猫棒. 使用这类猫棒的一个硬性要求就是端口速率强制锁死在 2.5Gbe / 1Gbe, 否则无法使用. 当博主在其 WebUI 上尝试更改速率时, 出现了要求我使用 group-speed 命令更改的报错. 但使用 CLI 发现 group-speed 并没有可以将接口调制成 2.5Gbe 的命令, 遂深入研究.

CTC7132 平台

CTC7132（TsingMa）芯片是盛科面向云时代，边缘计算技术演进需求推出的第六代核心交换芯片。芯片集成 ARM 双核 A53 处理器，支持 QSGMII 和 USXGMII 等端口形态，提供从 100M 到 100G 的全速率端口能力。芯片创新集成 X-Engine™，包含了 OAM/BFD Engine，Telemetry Engine，Security Engine 和 Wireless Engine 等。提供线速的增强特性能力和更高的集成度，更好服务于边缘的多业务接入场景，满足网络未知，业务需求不断融合的网络发展趋势。

OAM/BFD Engine 提供高精度，多条目的 OAM 和 BFD 会话，并集成了 RFC2544 和 TWAMP 能力，提供 IP RAN 的接入解决方案。
Telemetry Engine 提供的 NetFlow 功能，基于会话提供业务统计，丢包统计，提供最小和最大的时延抖动分析，为业务和流量优化提供数据支撑。
Wireless Engine 提供线速的 CAPWAP 加解封装以及分片重组能力，支撑 1G/2.5G/5G 多速率融合，有效支撑有线无线的融合。

作为盛科第六代芯片，CTC7132 继承了丰富的特性，包括 L2、L3、MPLS、VXLAN、MPLS SR 和 OAM/APS 等特性，亮点特性包括可视化特性、可编程特性、安全和流量控制特性、高精度时钟特性。 CTC7132 提供 100M/1G/2.5G/5G/10G/25G/40G/50G/100G 的端口速率。其 SerDes 设计满足多个端口协议：SGMII/QSGMII/USXGMII/XFI/SFI/XAUI/CAUI4/10G-KR/40G-KR4/100G-KR4/25G-KR/50G-KR2。

引用自 https://www.centec.com/silicon/Ethernet-Switch-Silicon/CTC7132

综上所述, 芯片侧是支持 2.5Gbe 速率的配置的.

研究目标

既然判断大概率不是 CPU 侧的限制, 那么研究方向主要集中在软件, 例如底层 SDK, 上层 CLI. 除此之外, 我们还需要探究为什么厂商要强制将四个 SFP+ 端口绑定在一个组内统一调整速率, 以及为什么不能调整 2.5Gbe 速率.

观前提示

阅读本文需要您具备一定的 Linux 基础知识, Linux 编程基础, 逆向基础, 计算机网络知识基础等. 如果您没有这些知识, 可能会阅读困难. 可以尝试借助 AI 来辅助理解.

开整

1. 固件分析

使用 binwalk 解包固件, 获取完整的 rootfs. 经过分析后可以得到以下信息

项	值
内核版本	`4.9.62-tsingma` (厂商自定义 `LOCALVERSION`)
架构	AArch64 (ARM64), SMP
编译工具	Linaro GCC 6.3.1 (2017.02)
构建时间	2024-11-18 CST
平台	Centec (盛科), `CLDK v20.01`

我们的核心目的是将端口速率更改至 2.5Gbe, 所以我们需要使得 group-speed 命令支持 2.5Gbe 速率的下发. 因此首要入手点是 group-speed 命令. 全盘搜索该字符串, 查找哪些二进制里包含这个字符串.

nanami114@NanamiWork-PC:~/firmware/moondon_webImage_v3.0.17.20250718/_uImage_v3.0.15.7.bin.extracted/_53E8E4.extracted/cpio-root$ grep -rl --binary-files=text "group-speed" usr/ lib/ sbin/ bin/
usr/sbin/imi
usr/sbin/nsm
usr/bin/imish
lib/libimish.so

在博主之前的分析中已经得出 imish 和 imi 均为用户态 OEM Shell, 只具备下发命令参数的功能, 不具备底层 SDK 实现. 因此, 这里我们需要检查的就是 usr/sbin/nsm.

2. 分析 `nsm`

2.1 `group-speed` 分析

在 IDA Pro 中对其进行静态逆向. 查找所有包含 group-speed 的函数

IDA Pro 中搜索 group-speed 字符串的交叉引用

经过分析和查找, 发现在 00b9a090 处的 group-speed 指向了一个 sub_536744 函数, 对其进行分析.

sub_536744 函数中 group-speed 的调用关系

完整的 sub_536744 伪代码如下

__int64 __fastcall sub_536744(__int64 a1, __int64 a2, const char **a3)
{
  unsigned __int8 v6; // [xsp+33h] [xbp+33h] BYREF
  int v7; // [xsp+34h] [xbp+34h] BYREF
  int v8; // [xsp+38h] [xbp+38h]
  char v9; // [xsp+3Fh] [xbp+3Fh]
  __int64 v10; // [xsp+40h] [xbp+40h]
  unsigned __int8 v11; // [xsp+4Fh] [xbp+4Fh]

  v10 = *(_QWORD *)(a1 + 64);
  v9 = 0;
  v11 = 0;
  v8 = 0;
  if ( *(_WORD *)(v10 + 302) != 2 )
  {
    (*(void (__fastcall **)(_QWORD, const char *))(a1 + 16))(
      *(_QWORD *)(a1 + 24),
      "%% Can only set speed on physical interface\n");
    return 1;
  }
  v8 = sub_50EB5C(v10, &v6, &v7);
  if ( v8 )
  {
    (*(void (__fastcall **)(_QWORD, const char *))(a1 + 16))(*(_QWORD *)(a1 + 24), "%% Get port group id fail \n");
    return 1;
  }
  if ( !v6 )
  {
    (*(void (**)(_QWORD, const char *, ...))(a1 + 16))(
      *(_QWORD *)(a1 + 24),
      "%% Unsupported CLI in present interface. Please refer to CLI \"speed %s\"\n",
      *a3);
    return 1;
  }
  if ( (((unsigned __int8)byte_B9B4E8 >> 7) & 1) != 0 )
  {
    if ( (unsigned int)sub_50F1B0(*(unsigned int *)(v10 + 80)) )
    {
      byte_B9B4E8 = 1;
    }
    else if ( (unsigned int)sub_50F184(*(unsigned int *)(v10 + 80)) )
    {
      byte_B9B4E8 = 2;
    }
    else if ( (unsigned int)sub_50F100(*(unsigned int *)(v10 + 80)) )
    {
      byte_B9B4E8 = 3;
    }
  }
  sub_49ABCC(v10);
  sub_49AC88(v10);
  sub_49ACFC(v10);
  v9 = (1 << (v6 - 1)) & byte_CAB190;
  if ( !strncmp(*a3, "1000", 4u) )
  {
    if ( v7 && (v7 & 2) == 0 )
      return sub_52C79C(a1, 4294967051LL);
    if ( (unsigned int)sub_50F1B0(*(unsigned int *)(v10 + 80)) && v9 )
    {
      (*(void (__fastcall **)(_QWORD, const char *))(a1 + 16))(
        *(_QWORD *)(a1 + 24),
        "speed has already been 1G, no need to config \n");
      return 20;
    }
    v11 = 1;
  }
  else if ( !strncmp(*a3, "10G", 3u) )
  {
    if ( v7 && (v7 & 4) == 0 )
      return sub_52C79C(a1, 4294967051LL);
    if ( (unsigned int)sub_50F184(*(unsigned int *)(v10 + 80)) && v9 )
    {
      (*(void (__fastcall **)(_QWORD, const char *))(a1 + 16))(
        *(_QWORD *)(a1 + 24),
        "speed has already been 10G, no need to config \n");
      return 20;
    }
    v11 = 2;
  }
  else if ( !strncmp(*a3, "25G", 3u) )
  {
    if ( v7 && (v7 & 0x80) == 0 )
      return sub_52C79C(a1, 4294967051LL);
    if ( (unsigned int)sub_50F100(*(unsigned int *)(v10 + 80)) && v9 )
    {
      (*(void (__fastcall **)(_QWORD, const char *))(a1 + 16))(
        *(_QWORD *)(a1 + 24),
        "speed has already been 25G, no need to config \n");
      return 20;
    }
    v11 = 3;
  }
  else if ( !strncmp(*a3, "default", 7u) )
  {
    if ( ((unsigned int)sub_50F1B0(*(unsigned int *)(v10 + 80)) && byte_B9B4E8 == 1
       || (unsigned int)sub_50F184(*(unsigned int *)(v10 + 80)) && byte_B9B4E8 == 2
       || (unsigned int)sub_50F100(*(unsigned int *)(v10 + 80)) && byte_B9B4E8 == 3)
      && v9 )
    {
      (*(void (__fastcall **)(_QWORD, const char *))(a1 + 16))(
        *(_QWORD *)(a1 + 24),
        "speed has already been default value, no need to config \n");
      return 20;
    }
    v11 = byte_B9B4E8;
  }
  v8 = sub_510E9C(v10, v11, v6);
  if ( v8 )
  {
    (*(void (__fastcall **)(_QWORD, const char *))(a1 + 16))(*(_QWORD *)(a1 + 24), "%% Set speed failed!\n");
    return 1;
  }
  else
  {
    if ( !strncmp(*a3, "default", 7u) || v11 == (unsigned __int8)byte_B9B4E8 )
    {
      byte_CAB191 &= ~(unsigned __int8)(1 << (v6 - 1));
    }
    else
    {
      byte_CAB191 |= 1 << (v6 - 1);
      dword_CAB194 &= ~(15 << (4 * (v6 - 1)));
      dword_CAB194 |= v11 << (4 * (v6 - 1));
    }
    byte_CAB190 |= 1 << (v6 - 1);
    return 0;
  }
}

可以明显看出, 这个函数就是 group-speed 的处理函数. 因此我们标记其为 0x536744. 在该函数中, 有几处明显和速率有关的 strncmp

strncmp(*a3, "1000", 4u)
strncmp(*a3, "10G", 3u)
strncmp(*a3, "25G", 3u)
strncmp(*a3, "default", 7u)

其中 1000, 10G, 25G, default 恰好对应了 group-speed 的四种速率状态

Switch(config-if)# group-speed ?
  1000     Switch speed of all interface in group to 1G
  10G      Switch speed of all interface in group to 10G
  25G      Switch speed of all interface in group to 25G
  default  Switch speed of all interface in group to default value

同时我们还可以看出, 所有用户输入处理完成后, 被统一交付给了一个 sub_510E9C 函数进行处理, 然后将返回值交给 v8 参数, 作为命令执行的结果. 因此我们这里定位到 sub_510E9C 进行研究

__int64 __fastcall sub_510E9C(__int64 a1, unsigned __int8 a2, unsigned __int8 a3)
{
  if ( !a1 )
    return 4294967287LL;
  if ( *(_WORD *)(a1 + 302) != 2 )
    return 4294967284LL;
  if ( (unsigned int)sub_4FC03C(a1, a2, a3) )
    return 0xFFFFFFFFLL;
  return 0;
}

该函数指向了 sub_4FC03C, 继续分析

__int64 __fastcall sub_4FC03C(__int64 a1, unsigned __int8 a2, unsigned __int8 a3)
{
  if ( *(_WORD *)(a1 + 302) == 2 )
    return (unsigned int)sub_9C0DC4(*(unsigned int *)(a1 + 24), a2, a3);
  else
    return 128;
}

该函数指向了 sub_9C0DC4, 继续分析

__int64 __fastcall sub_9C0DC4(int a1, char a2, char a3)
{
  int v4; // [xsp+28h] [xbp+28h] BYREF
  char v5; // [xsp+2Ch] [xbp+2Ch]
  char v6; // [xsp+2Dh] [xbp+2Dh]

  v4 = a1;
  v5 = a2;
  v6 = a3;
  return sub_9B4D70(929, &v4, 8, 0, 0, 0, 0);
}

该函数指向了 sub_9B4D70, 继续分析

__int64 __fastcall sub_9B4D70(
        unsigned int a1,
        const void *a2,
        size_t a3,
        __int64 a4,
        __int64 a5,
        __int64 a6,
        __int64 a7)
{
  int v8; // w0
  _DWORD s[5]; // [xsp+58h] [xbp+58h] BYREF
  int v14; // [xsp+6Ch] [xbp+6Ch]
  __int64 v15; // [xsp+70h] [xbp+70h]
  void *dest; // [xsp+78h] [xbp+78h]

  dest = 0;
  v15 = 0;
  v14 = 0;
  memset(s, 0, 0x10u);
  if ( dword_E51FE0 )
  {
    if ( a1 <= 0x479 )
    {
      if ( !a3 || a2 )
      {
        if ( sock_shal >= 0 )
        {
          if ( qword_E4FF98 )
          {
            log_sys(158, 1, "hal socket not connect, send msg(%d) fail", a1);
            return 0xFFFFFFFFLL;
          }
          else if ( a3 <= 0xFF4 )
          {
            if ( qword_E51FF0 && *(unsigned __int16 *)(qword_E51FF0 + 16) + a3 + 12 > 0x1000 )
              sub_9B4B60();
            v8 = dword_E4FF84++;
            s[2] = v8;
            s[1] = a3 + 12;
            s[0] = a1;
            v15 = sub_9B3F1C(&sock_shal, a3 + 12);
            if ( v15 )
            {
              dest = (void *)(v15 + 18 + *(unsigned __int16 *)(v15 + 16));
              memcpy(dest, s, 0xCu);
              *(_WORD *)(v15 + 16) += 12;
              dest = (char *)dest + 12;
              memcpy(dest, a2, a3);
              *(_WORD *)(v15 + 16) += a3;
              if ( !dword_E51FA4 || a7 )
              {
                while ( qword_E51FE8 )
                {
                  v14 = sub_9B4B60();
                  if ( v14 == -2 )
                    pal_delay(1000);
                }
              }
              return 0;
            }
            else
            {
              log_sys(158, 1, "hal talk: no memory");
              return 0xFFFFFFFFLL;
            }
          }
          else
          {
            log_sys(158, 1, "hal talk: req_len is too longer");
            return 0xFFFFFFFFLL;
          }
        }
        else
        {
          return 0xFFFFFFFFLL;
        }
      }
      else
      {
        log_sys(158, 3, "req == NULL, but req_len != 0");
        return 0xFFFFFFFFLL;
      }
    }
    else
    {
      log_sys(158, 3, "Msg type error, 0x%x", a1);
      return 0;
    }
  }
  else
  {
    log_sys(158, 1, "hal socket not init");
    return 0xFFFFFFFFLL;
  }
}

不难看出, 函数 sub_9B4D70 就是用户 CLI 与板层 HAL 通讯的函数. 纵观整个 group-speed 实现, 我们不难发现, 该命令根本没有 2.5Gbe 速率的分支, 从底层也根本没实现 2.5Gbe 速率的下发. 因此 group-speed 对于我们的目的而言已经没有研究的价值了. 现在的方向应该是检查在什么情况下 speed 命令才会拒绝下发命令, 转而要求使用 group-speed.

2.2 `speed` 分析

查找所有包含 speed 的函数

IDA Pro 中搜索 speed 相关函数的交叉引用

在 sub_534568 函数中发现了关于配置速率报错的字符串输出, 我们这里重点分析该函数

__int64 __fastcall sub_534568(__int64 a1, __int64 a2, const char **a3)
{
  void (*v4)(__int64, const char *, ...); // x19
  __int64 v5; // x20
  const char *v6; // x0
  void (*v7)(__int64, const char *, ...); // x19
  __int64 v8; // x20
  const char *v9; // x21
  const char *v10; // x0
  char dest[2]; // [xsp+50h] [xbp+50h] BYREF
  __int64 v14; // [xsp+52h] [xbp+52h]
  char v15; // [xsp+5Bh] [xbp+5Bh] BYREF
  unsigned int v16; // [xsp+5Ch] [xbp+5Ch]
  __int64 v17; // [xsp+60h] [xbp+60h]
  __int64 v18; // [xsp+68h] [xbp+68h]
  int v19; // [xsp+74h] [xbp+74h]
  __int64 v20; // [xsp+78h] [xbp+78h]
  unsigned int v21; // [xsp+84h] [xbp+84h]
  char v22; // [xsp+8Bh] [xbp+8Bh]
  unsigned int v23; // [xsp+8Ch] [xbp+8Ch]

  v23 = 0;
  v20 = *(_QWORD *)(a1 + 64);
  v22 = 1;
  v21 = 0;
  if ( *(_WORD *)(v20 + 302) == 2 )
  {
    v15 = 0;
    v19 = 0;
    v19 = sub_50EB5C(v20, &v15, 0);
    if ( !v19 )
    {
      if ( v15 )
      {
        *(_WORD *)dest = 0;
        v14 = 0;
        strcpy(dest, *a3);
        (*(void (**)(_QWORD, const char *, ...))(a1 + 16))(
          *(_QWORD *)(a1 + 24),
          "%% Unsupported CLI in present interface. Please refer to CLI \"group-speed %s\"\n",
          *a3);
        return 1;
      }
    }
  }
  if ( *(int *)(v20 + 76) < 0 && !*(_DWORD *)(v20 + 84) )
  {
    (*(void (__fastcall **)(_QWORD, const char *))(a1 + 16))(
      *(_QWORD *)(a1 + 24),
      "%% Can not set speed with interface media type auto select\n");
    return 1;
  }
  v18 = *(_QWORD *)(v20 + 448);
  if ( v18 && *(_BYTE *)(v18 + 125) && *(_BYTE *)(v18 + 96) != 1 )
  {
    (*(void (__fastcall **)(_QWORD, const char *))(a1 + 16))(
      *(_QWORD *)(a1 + 24),
      "%% Cannot configure aggregator member\n");
    return 1;
  }
  v17 = *(_QWORD *)(v20 + 448);
  if ( v17 && *(_BYTE *)(v17 + 125) && *(_BYTE *)(v17 + 96) != 2 )
  {
    (*(void (__fastcall **)(_QWORD, const char *))(a1 + 16))(*(_QWORD *)(a1 + 24), "%% Cannot configure aggregator\n");
    return 1;
  }
  if ( *(_WORD *)(v20 + 302) != 2 && *(_WORD *)(v20 + 302) != 9 )
  {
    v4 = *(void (**)(__int64, const char *, ...))(a1 + 16);
    v5 = *(_QWORD *)(a1 + 24);
    v6 = (const char *)sub_49EB94(*(unsigned __int16 *)(v20 + 302));
    v4(v5, "%% Can't set speed on %s interface\n", v6);
    return 1;
  }
  if ( !strncmp(*a3, "400G", 4u) )
  {
    v23 = 12;
  }
  else if ( !strncmp(*a3, "200G", 4u) )
  {
    v23 = 11;
  }
  else if ( !strncmp(*a3, "100G", 4u) )
  {
    v23 = 6;
  }
  else if ( !strncmp(*a3, "40G", 3u) )
  {
    v23 = 5;
  }
  else if ( !strncmp(*a3, "50G", 3u) )
  {
    v23 = 10;
  }
  else if ( !strncmp(*a3, "25G", 3u) )
  {
    v23 = 9;
  }
  else if ( !strncmp(*a3, "10G", 3u) )
  {
    v23 = 4;
  }
  else if ( !strncmp(*a3, "5G", 2u) )
  {
    v23 = 8;
  }
  else if ( !strncmp(*a3, "2G5", 3u) )
  {
    v23 = 7;
  }
  else if ( !strncmp(*a3, "1000", 4u) )
  {
    v23 = 3;
  }
  else if ( !strncmp(*a3, "100", 3u) )
  {
    v23 = 2;
  }
  else if ( !strncmp(*a3, "10", 2u) )
  {
    v23 = 1;
  }
  else
  {
    if ( strncmp(*a3, "auto", 4u) )
    {
      (*(void (**)(_QWORD, const char *, ...))(a1 + 16))(*(_QWORD *)(a1 + 24), "%% Invalid speed : %s\n", *a3);
      return 1;
    }
    v23 = 0;
  }
  if ( v23 && *(_DWORD *)(v20 + 268) && *(_DWORD *)(v20 + 820) == 1 )
  {
    (*(void (__fastcall **)(_QWORD, const char *))(a1 + 16))(
      *(_QWORD *)(a1 + 24),
      "%% Please disable eee function first\n");
    return 1;
  }
  else
  {
    if ( *(_WORD *)(v20 + 302) != 2
      || !(unsigned int)sub_50F024(*(unsigned int *)(v20 + 80))
      && !(unsigned int)sub_50F050(*(unsigned int *)(v20 + 80))
      && !(unsigned int)sub_50F07C(*(unsigned int *)(v20 + 80))
      && !(unsigned int)sub_50F100(*(unsigned int *)(v20 + 80))
      && !(unsigned int)sub_50F0D4(*(unsigned int *)(v20 + 80))
      && !(unsigned int)sub_50F0A8(*(unsigned int *)(v20 + 80))
      && !(unsigned int)sub_50F184(*(unsigned int *)(v20 + 80)) )
    {
      v22 = 0;
    }
    if ( v22 && (*(_WORD *)(v20 + 836) & 0x80) == 0 )
    {
      if ( v23 && v23 != 12 && v23 != 11 && v23 != 6 && v23 != 10 && v23 != 9 && v23 != 4 && v23 != 5 )
        v21 = 20;
      if ( (*(_WORD *)(v20 + 836) & 0x3F) == 2 )
      {
        if ( v23 == 12 )
          v21 = 20;
        if ( v23 == 11 )
          v21 = 20;
        if ( v23 == 6 )
          v21 = 20;
        if ( v23 == 10 )
          v21 = 20;
      }
      if ( (*(_WORD *)(v20 + 836) & 0x3F) == 1 )
      {
        if ( v23 == 12 )
          v21 = 20;
        if ( v23 == 11 )
          v21 = 20;
        if ( v23 == 6
          && (unsigned int)sub_50F0D4(*(unsigned int *)(v20 + 80))
          && (unsigned int)sub_50F07C(*(unsigned int *)(v20 + 80)) )
        {
          v21 = 20;
        }
        if ( v23 == 10
          && (unsigned int)sub_50F0D4(*(unsigned int *)(v20 + 80))
          && (unsigned int)sub_50F100(*(unsigned int *)(v20 + 80)) )
        {
          v21 = 20;
        }
        if ( v23 == 5 || v23 == 4 )
          v21 = 20;
      }
      if ( (*(_WORD *)(v20 + 836) & 0x3F) == 4 || (*(_WORD *)(v20 + 836) & 0x3F) == 8 )
      {
        if ( v23 == 5 || v23 == 9 || v23 == 4 )
          v21 = 20;
        if ( v23 == 10 )
        {
          if ( (unsigned int)sub_50F0D4(*(unsigned int *)(v20 + 80))
            && (unsigned int)sub_50F07C(*(unsigned int *)(v20 + 80)) )
          {
            v21 = 20;
          }
          if ( (unsigned int)sub_50F0D4(*(unsigned int *)(v20 + 80))
            && !(unsigned int)sub_50F100(*(unsigned int *)(v20 + 80))
            && !(unsigned int)sub_50F07C(*(unsigned int *)(v20 + 80)) )
          {
            v21 = 20;
          }
        }
        if ( v23 == 6 )
        {
          if ( (unsigned int)sub_50F07C(*(unsigned int *)(v20 + 80))
            && (unsigned int)sub_50F050(*(unsigned int *)(v20 + 80)) )
          {
            v21 = 20;
          }
          if ( (unsigned int)sub_50F0A8(*(unsigned int *)(v20 + 80))
            && (unsigned int)sub_50F07C(*(unsigned int *)(v20 + 80))
            && !(unsigned int)sub_50F050(*(unsigned int *)(v20 + 80)) )
          {
            v21 = 20;
          }
        }
      }
      if ( (*(_WORD *)(v20 + 836) & 0x3F) == 0 )
      {
        if ( v23 == 11 || v23 == 12 )
          v21 = 20;
        if ( v23 == 6
          && (unsigned int)sub_50F0D4(*(unsigned int *)(v20 + 80))
          && (unsigned int)sub_50F07C(*(unsigned int *)(v20 + 80)) )
        {
          v21 = 20;
        }
        if ( v23 == 10
          && (unsigned int)sub_50F0D4(*(unsigned int *)(v20 + 80))
          && (unsigned int)sub_50F100(*(unsigned int *)(v20 + 80)) )
        {
          v21 = 20;
        }
      }
    }
    if ( v23 == 8 && (*(_BYTE *)(v20 + 249) || *(_BYTE *)(v20 + 248)) )
    {
      (*(void (__fastcall **)(_QWORD, const char *))(a1 + 16))(
        *(_QWORD *)(a1 + 24),
        "%% Please disable flowcontrol send and receive function first\n");
      return 1;
    }
    else
    {
      v16 = sub_510A48(*(unsigned int *)(*(_QWORD *)(a1 + 136) + 16LL), v20, v23);
      if ( !v16 )
        *(_BYTE *)(v20 + 401) |= 4u;
      if ( (unsigned int)sub_52C79C(a1, v16) )
      {
        return 1;
      }
      else
      {
        v7 = *(void (**)(__int64, const char *, ...))(a1 + 16);
        v8 = *(_QWORD *)(a1 + 24);
        v9 = (const char *)sub_49FF90(*(unsigned __int16 *)(v20 + 836));
        v10 = (const char *)sub_49ED5C(*(unsigned int *)(v20 + 68));
        v7(
          v8,
          "%% Warning: FEC %s can be configured but not in effect on %s port\n"
          "%% Please use show interface cmd to confirm FEC status details\n",
          v9,
          v10);
        return v21;
      }
    }
  }
}

可以看出, 该函数中包含了 speed 命令的多个速率模式 (auto, 10, 100, 1000, 10G, 40G, 100G), 以及关键用户侧报错 %% Unsupported CLI in present interface. Please refer to CLI \"group-speed %s\"\n. 定位到报错位置具体分析代码.

  if ( *(_WORD *)(v20 + 302) == 2 )
  {
    v15 = 0;
    v19 = 0;
    v19 = sub_50EB5C(v20, &v15, 0);
    if ( !v19 )
    {
      if ( v15 )
      {
        *(_WORD *)dest = 0;
        v14 = 0;
        strcpy(dest, *a3);
        (*(void (**)(_QWORD, const char *, ...))(a1 + 16))(
          *(_QWORD *)(a1 + 24),
          "%% Unsupported CLI in present interface. Please refer to CLI \"group-speed %s\"\n",
          *a3);
        return 1;
      }
    }
  }

从代码中我们可以看出, 只有当 sub_50EB5C 返回非零值时, 才会触发相应检测. 这里我们查看其汇编继续分析

.text:00000000005367AC
.text:00000000005367AC loc_5367AC                              ; CODE XREF: sub_536744+38↑j
.text:00000000005367AC                 ADD             X1, X29, #0x50+var_1C
.text:00000000005367B0                 ADD             X0, X29, #0x50+var_1D
.text:00000000005367B4                 MOV             X2, X1
.text:00000000005367B8                 MOV             X1, X0
.text:00000000005367BC                 LDR             X0, [X29,#0x50+var_10]
.text:00000000005367C0                 BL              sub_50EB5C
.text:00000000005367C4                 STR             W0, [X29,#0x50+var_18]
.text:00000000005367C8                 LDR             W0, [X29,#0x50+var_18]
.text:00000000005367CC                 CMP             W0, #0
.text:00000000005367D0                 B.EQ            loc_536800
.text:00000000005367D4                 LDR             X0, [X29,#0x50+var_28]
.text:00000000005367D8                 LDR             X2, [X0,#0x10]
.text:00000000005367DC                 LDR             X0, [X29,#0x50+var_28]
.text:00000000005367E0                 LDR             X3, [X0,#0x18]
.text:00000000005367E4                 ADRL            X0, aGetPortGroupId ; "%% Get port group id fail \n"
.text:00000000005367EC                 MOV             X1, X0
.text:00000000005367F0                 MOV             X0, X3
.text:00000000005367F4                 BLR             X2
.text:00000000005367F8                 MOV             W0, #1
.text:00000000005367FC                 B               loc_536DCC

这里我们可以看到, 该函数执行后调用了 sub_50EB5C, 然后读取其返回值, 当其返回值为 0 时, 继续执行 loc_536800 处代码, 当其返回值非 0 时, 输出 %% Get port group id fail \n. 因此这里我们可以判断, sub_50EB5C 的语义正为用户态的 get port group id. 所以这里得出的结论是: 当 speed 检测到 group-id 非 0 时触发告警, 并让用户使用 group-speed 指定速率.

3. 研究判断逻辑

既然我们现在已经知道 speed 命令检测的是 group-id, 那么我们就从这里下手. 现在我们就来研究怎么样让 speed 命令绕过 group-id 的检测, 直接向板卡下发命令. 在上面的分析中我们可以得知, sub_536744 函数是 group-speed 命令的处理函数. 我们现在要找的是 speed, 所以肯定还有别的函数是包含 Unsupported CLI in present interface 报错的. 经过全局搜索后, 发现除了 sub_536744 以外, 只有 sub_534568 是包含这个报错的.

speed 命令对 group-id 的检测逻辑

因此我们这里分析该函数.

if ( *(_WORD *)(v20 + 302) == 2 )
  {
    v15 = 0;
    v19 = 0;
    v19 = sub_50EB5C(v20, &v15, 0);
    if ( !v19 )
    {
      if ( v15 )
      {
        *(_WORD *)dest = 0;
        v14 = 0;
        strcpy(dest, *a3);
        (*(void (**)(_QWORD, const char *, ...))(a1 + 16))(
          *(_QWORD *)(a1 + 24),
          "%% Unsupported CLI in present interface. Please refer to CLI \"group-speed %s\"\n",
          *a3);
        return 1;
      }
    }
  }

从该函数中得知, 当 v15 非 0 时, 会触发报错. 而修改 v15 的函数为 sub_50EB5C, 也就是上面所说的 get port group id. 所以我们这里直接查看汇编, 看看哪个地址调用了该函数.

.text:00000000005345AC                 B.NE            loc_534644
.text:00000000005345B0                 STRB            WZR, [X29,#0x90+var_35]
.text:00000000005345B4                 STR             WZR, [X29,#0x90+var_1C]
.text:00000000005345B8                 ADD             X0, X29, #0x90+var_35
.text:00000000005345BC                 MOV             X2, #0
.text:00000000005345C0                 MOV             X1, X0
.text:00000000005345C4                 LDR             X0, [X29,#0x90+var_18]
.text:00000000005345C8                 BL              sub_50EB5C
.text:00000000005345CC                 STR             W0, [X29,#0x90+var_1C]
.text:00000000005345D0                 LDR             W0, [X29,#0x90+var_1C]
.text:00000000005345D4                 CMP             W0, #0
.text:00000000005345D8                 B.NE            loc_534644
.text:00000000005345DC                 LDRB            W0, [X29,#0x90+var_35]
.text:00000000005345E0                 CMP             W0, #0
.text:00000000005345E4                 B.EQ            loc_534644
.text:00000000005345E8                 ADRL            X0, word_AAD088
.text:00000000005345F0                 LDRH            W0, [X0]
.text:00000000005345F4                 STRH            W0, [X29,#0x90+dest]
.text:00000000005345F8                 STUR            XZR, [X29,#0x90+var_3E]
.text:00000000005345FC                 LDR             X0, [X29,#0x90+var_58]
.text:0000000000534600                 LDR             X1, [X0] ; src
.text:0000000000534604                 ADD             X0, X29, #0x90+dest ; dest
.text:0000000000534608                 BL              .strcpy
.text:000000000053460C                 LDR             X0, [X29,#0x90+var_48]
.text:0000000000534610                 LDR             X3, [X0,#0x10]
.text:0000000000534614                 LDR             X0, [X29,#0x90+var_48]
.text:0000000000534618                 LDR             X4, [X0,#0x18]
.text:000000000053461C                 LDR             X0, [X29,#0x90+var_58]
.text:0000000000534620                 LDR             X1, [X0]
.text:0000000000534624                 ADRL            X0, aUnsupportedCli ; "%% Unsupported CLI in present interface"...
.text:000000000053462C                 MOV             X2, X1
.text:0000000000534630                 MOV             X1, X0
.text:0000000000534634                 MOV             X0, X4
.text:0000000000534638                 BLR             X3
.text:000000000053463C                 MOV             W0, #1
.text:0000000000534640                 B               loc_53504C

从汇编码中可以看到, 在 0x5345C8 位置调用了该函数. 查看上下文, 可以发现:

.text:00000000005345C4 LDR X0, [X29,#0x90+var_18] 为 ifentry
sub_50EB5C 获取 group-id
.text:00000000005345CC STR W0, [X29,#0x90+var_1C] 保存返回值
.text:00000000005345D8 B.NE loc_534644 取失败, 当作无组接口继续
.text:00000000005345DC LDRB W0, [X29,#0x90+var_35] 取上文获取的返回值
.text:00000000005345E4 B.EQ loc_534644 group==0, 跳至正常 speed 设置速率.

现在已经分析的很明确了: 0x5345E4 就是判断 group-id 为 0 则正常下发速率的命令. 到了这一步我们就可以做一个尝试: 将这一块的 B.EQ 改为 B, 即无论如何都走正常速率下发流程.

4. 第一次 Patch

知道了手段, 那么我们就尝试写一份内存 Patch 脚本, 然后在设备上运行.

注: 该设备的 Linux Root Shell 已被博主破解, 目前已和厂商反馈并申请相关 CVE-ID. 在厂商明确修复完成并下放补丁前不做技术细节公开.

已知设备上有 Python 2.7 环境, 所以我们这里用 Python 写内存补丁.

GPATCH = 0x5345e4
wr(ABIL, struct.pack('<I', cur | 0x20))      # 给能力位图补 0x20
wr(GPATCH, binascii.unhexlify('18000014'))   # b.eq -> b

应用内存补丁后, 尝试使用 speed 命令进行修改. 虽然没有报错使用 group-speed, 但是出现了新的报错: % Can not set speed with interface media type auto select.

5. 定位首次 Patch 报错点

在 0x534674 处发现该报错的字符串

.text:0000000000534674                 ADRL            X0, aCanNotSetSpeed ; "%% Can not set speed with interface med"...

查看具体汇编码

.text:0000000000534644 loc_534644                              ; CODE XREF: sub_534568+44↑j
.text:0000000000534644                                         ; sub_534568+70↑j ...
.text:0000000000534644                 LDR             X0, [X29,#0x90+var_18]
.text:0000000000534648                 LDR             W0, [X0,#0x4C]
.text:000000000053464C                 CMP             W0, #0
.text:0000000000534650                 B.GE            loc_534690
.text:0000000000534654                 LDR             X0, [X29,#0x90+var_18]
.text:0000000000534658                 LDR             W0, [X0,#0x54]
.text:000000000053465C                 CMP             W0, #0
.text:0000000000534660                 B.NE            loc_534690
.text:0000000000534664                 LDR             X0, [X29,#0x90+var_48]
.text:0000000000534668                 LDR             X2, [X0,#0x10]
.text:000000000053466C                 LDR             X0, [X29,#0x90+var_48]
.text:0000000000534670                 LDR             X3, [X0,#0x18]
.text:0000000000534674                 ADRL            X0, aCanNotSetSpeed ; "%% Can not set speed with interface med"...
.text:000000000053467C                 MOV             X1, X0
.text:0000000000534680                 MOV             X0, X3
.text:0000000000534684                 BLR             X2
.text:0000000000534688                 MOV             W0, #1
.text:000000000053468C                 B               loc_53504C

这里可以看到, 该报错的执行条件是 [ifentry+0x4c] < 0 && [ifentry+0x54] == 0. 读取各口字段发现厂商做了如下处理

端口	`[+0x4c]`	`[+0x54]`	结果
电口 / QSFP	正数	0	通过
SFP+ 51~54	负数	0	报错

也就是说当 media-type 为电口 / QSFP 时, 可以通过检查. 厂商 CLI 中有直接修改 media-type 的相关命令, 所以这里尝试直接在 CLI 中修改. 修改完成后再次使用 speed 命令下发指令, 随即被设备接受.

6. 第一次踩坑

应用速率后, 接入设备查看连接. 发现等了好一会并没有成功协商 2.5Gbe 速率. 再次下发指令发现出现新的报错: % Unsupport port speed ability. 查看设备日志发现, 手动更改的 media-type 被守卫进程 hsrvd 从 HAL 层重新拉回了 0x04. 因此这里得出了一个结论: 数据补丁不可靠, 必须直接改代码.

7. 尝试更改代码

经过上面的步骤, 博主发现: 能力限制的真正源头在 HAL 层, nsm 只是通讯中间件. 经过一番查找, 发现类型门校验在 0x50f920 处. 查看附近汇编码

.text:000000000050F750                 ADD             X0, X29, #0x30+var_10
.text:000000000050F754                 MOV             X1, X0
.text:000000000050F758                 LDR             X0, [X29,#0x30+var_18]
.text:000000000050F75C                 BL              sub_50EAAC
.text:000000000050F760                 LDR             W0, [X29,#0x30+var_10]
.text:000000000050F764                 AND             W0, W0, #0x1FFF
.text:000000000050F768                 STR             W0, [X29,#0x30+var_4]
.text:000000000050F76C                 LDR             W0, [X29,#0x30+var_8]
.text:000000000050F770                 AND             W0, W0, #0xFFFFFF
.text:000000000050F774                 STR             W0, [X29,#0x30+var_C]
...
.text:000000000050F910 loc_50F910                              ; CODE XREF: sub_50F728+1D4↑j
.text:000000000050F910                 LDR             W0, [X29,#0x30+var_1C]
.text:000000000050F914                 CMP             W0, #7
.text:000000000050F918                 B.NE            loc_50F92C
.text:000000000050F91C                 LDR             W0, [X29,#0x30+var_C]
.text:000000000050F920                 AND             W0, W0, #0x20 ; ' '
.text:000000000050F924                 CMP             W0, #0
.text:000000000050F928                 B.NE            loc_50F970

逐一解读逻辑:

.text:000000000050F758 LDR X0, [X29,#0x30+var_18] - ifentry
.text:000000000050F75C BL sub_50EAAC - 计算端口类型
.text:000000000050F768 STR W0, [X29,#0x30+var_4] - *type
.text:000000000050F76C LDR W0, [X29,#0x30+var_8] - ifentry + 0x50
.text:000000000050F774 STR W0, [X29,#0x30+var_C] - ability = 能力位图

接着查找能力位图

.text:000000000050E3BC                 AND             W0, W0, #0x1FFF
.text:000000000050E3C0                 CMP             W0, #0x63 ; switch 100 cases
.text:000000000050E3C4                 B.HI            def_50E3DC ; jumptable 000000000050E3DC default case, case 54
.text:000000000050E3C8                 ADRL            X1, jpt_50E3DC
.text:000000000050E3D0                 LDR             W0, [X1,W0,UXTW#2]
.text:000000000050E3D4                 ADR             X1, loc_50E3E0 ; jumptable 000000000050E3DC case 0
.text:000000000050E3D8                 ADD             X0, X1, W0,SXTW#2
.text:000000000050E3DC                 BR              X0      ; switch jump

50e3fc: ... 50e404: bl strncmp        ; 与 0xaa3d48 = 'agg'   (len 3) → 返回 20
50e430: ... bl strncmp                ; 与 0xaa3d50 = 'vlan'  (len 4) → 返回 21
50e45c: ... bl strncmp                ; 与 0xaa3d58 = 'tunnel'(len 6) → 返回 22
50e488: ... bl strncmp                ; 与 0xaa3d60 = 'loopback'(len 8) → 返回 23
50e4b4: ... bl strncmp                ; 与 0xaa3d70 = 'seth'  → 返回 ...

即 type 是按接口名(agg/vlan/tunnel*/loopback*/seth*/eth*……)分出来的类别码. 最终解出来的能力位图如下

分支	允许的速率码	说明
type==1	{0,1,2,3}	`[if+0x10c]!=0` 时禁 3(1G),返回 -246
type==3	{0,1,2}
type==45	{0,2,3,7,8}	`[if+0x10c]!=0` 时禁 3/7/8;再查能力位
type==43 (0x2b)	{0,2,3,4,7,8}	`[if+0x10c]!=0` 时禁 3/7/8/4;再查能力位
其余	5/6/4/3/2/10/9/7/11/12 ……	按大速率集查能力位

因此速率码对照表即为: 0=auto 1=10M 2=100M 3=1G 4=10G 5=40G 6=100G 7=2.5G 8=5G 9=25G 10=50G 11=200G 12=400G 所以这里我们需要给校验码打补丁:

地址	原值	新值
nsm VA `0x50f728`	`fd 7b bd a9` (`stp x29,x30,[sp,#-48]!`)	`00 00 80 52 c0 03 5f d6` (`mov w0,#0; ret`)

8. 第二次 Patch

使用 Python 编写补丁

import sys, binascii
pid = int(sys.argv[1]); act = sys.argv[2]
BK = '/tmp/mpatch_bk.txt'
# (label, nsm VA, original bytes hex, new bytes hex)  -- lengths may be 4 or 8 bytes
EDITS = [
    # 0x50f728 = port-speed ability validator: "stp x29,x30,[sp,#-48]!" -> "mov w0,#0; ret"
    ('valid_entry', 0x50f728, 'fd7bbda9', '00008052c0035fd6'),
]

def rd(off, n):
    f = open('/proc/%d/mem' % pid, 'rb'); f.seek(off); return f.read(n)

def wr(off, data):
    f = open('/proc/%d/mem' % pid, 'r+b'); f.seek(off); f.write(data); f.flush()

def hx(b):
    return binascii.hexlify(b)

if act == 'read':
    for (lab, a, o, n) in EDITS:
        print("%-14s @0x%x  now=%s" % (lab, a, hx(rd(a, len(o) // 2))))
    sys.exit(0)

if act == 'patch':
    lines = []
    for (lab, a, o, n) in EDITS:
        cur = hx(rd(a, len(o) // 2))
        lines.append("%s %x %s" % (lab, a, cur))
        if cur == o:
            wr(a, binascii.unhexlify(n))
        else:
            print("WARN %s current=%s expected=%s" % (lab, cur, o))
    open(BK, 'w').write("\n".join(lines) + "\n")
    for (lab, a, o, n) in EDITS:
        print("%-14s @0x%x -> %s" % (lab, a, hx(rd(a, len(o) // 2))))

if act == 'restore':
    for line in open(BK):
            wr(a, binascii.unhexlify(n))
        else:
            print("WARN %s current=%s expected=%s" % (lab, cur, o))
    open(BK, 'w').write("\n".join(lines) + "\n")
    for (lab, a, o, n) in EDITS:
        print("%-14s @0x%x -> %s" % (lab, a, hx(rd(a, len(o) // 2))))

if act == 'restore':
    for line in open(BK):
        lab, a, cur = line.split()
        wr(int(a, 16), binascii.unhexlify(cur))
        print("restored %s @%s -> %s" % (lab, a, hx(rd(int(a, 16), len(cur) // 2))))

在设备上应用补丁. 然后再次 speed 下发速率.

Switch(config-if)# speed 2G5

Switch# show running-config interface eth-0-51
interface eth-0-51
 speed 2G5

Switch# show interface eth-0-51
  Interface current state: UP
  Bandwidth 2500000 kbits
  Speed - 2.5Gb/s , Duplex - Full

可以看到, 此时端口速率已经成功的应用为 2.5Gbe. 且测试后接入设备也没有重置速率. 至此, Patch 完成.

端口速率成功设置为 2.5Gbe

9. 持久化

该交换机的 rootfs 文件系统为 ramfs, 所以没法做持久化. 但是 flash 挂载为 ext4. 因此我们可以写个 patch 脚本在设备上, 如果设备重启就手动应用一遍脚本. 交换机这种设备只要不是设备断电, 几乎不会重启. 所以这种方法暂且也是可行的. 之后或许会研究真正持久化的做法. 这里把完整补丁内容贴出来

#!/usr/bin/python2.7
# -*- coding: utf-8 -*-
import os
import sys
import glob
import time

TARGET = '/usr/sbin/nsm'                     # 目标进程
WAIT_SECS = 30                               # 等待 nsm 上线的秒数

# (标签, 运行时地址 == 文件内 VA（nsm 为非 PIE）, 原始字节, 补丁字节)
# 注意：字节串均为小端（ARM64 指令在内存中的实际字节序）
EDITS = [
    ('group_check      ', 0x5345e4, '00030054',         '18000014'),
    ('ability_validator', 0x50f728, 'fd7bbda9fd030091', '00008052c0035fd6'),
]

PATCHDIR = os.path.dirname(os.path.abspath(__file__))
BACKUP = os.path.join(PATCHDIR, 'patch-sfp+.bak')


def find_pid():
    """按 /proc/<pid>/exe 指向找到 nsm 的 pid（不依赖 pidof 是否可用）。"""
    for p in glob.glob('/proc/[0-9]*/exe'):
        try:
            if os.readlink(p) == TARGET:
                return int(p.split('/')[2])
        except OSError:
            pass
    return None


def wait_pid():
    for _ in range(WAIT_SECS):
        pid = find_pid()
        if pid is not None:
            return pid
        time.sleep(1)
    return None


def hx(b):
    return ''.join('%02x' % ord(c) for c in b)


def mem_rd(fd, off, n):
    os.lseek(fd, off, os.SEEK_SET)
    return os.read(fd, n)


def mem_wr(fd, off, data):
    os.lseek(fd, off, os.SEEK_SET)
    return os.write(fd, data)


def do_status(fd):
    rc = 0
    for (lab, addr, orig, patched) in EDITS:
        n = len(orig) // 2
        cur = hx(mem_rd(fd, addr, n))
        if cur == patched:
            state = 'PATCHED'
        elif cur == orig:
            state = 'original'
        else:
            state = 'UNKNOWN'
            rc = 2
        print("  %s @0x%06x = %-20s [%s]" % (lab, addr, cur, state))
    return rc


def do_restore(fd):
    if not os.path.exists(BACKUP):
        print("ERROR: 找不到备份 %s，无法还原" % BACKUP)
        return 1
    for line in open(BACKUP):
        lab, addr, orig = line.split()
        mem_wr(fd, int(addr, 16), orig.decode('hex'))
        print("  restored %s @0x%s -> %s" % (lab, addr, hx(mem_rd(fd, int(addr, 16), len(orig) // 2))))
    return 0


def do_patch(fd):
    rc = 0
    bk = []
    for (lab, addr, orig, patched) in EDITS:
        n = len(orig) // 2
        cur = hx(mem_rd(fd, addr, n))
        bk.append("%s %x %s\n" % (lab.strip(), addr, orig))   # 备份一律记原始字节
        if cur == patched:
            print("  SKIP  %s @0x%06x 已经打过补丁" % (lab, addr))
        elif cur == orig:
            mem_wr(fd, addr, patched.decode('hex'))
            print("  PATCH %s @0x%06x  %s -> %s" % (lab, addr, cur, hx(mem_rd(fd, addr, n))))
        else:
            print("  WARN  %s @0x%06x 未知内容 %s（期望 %s），已跳过" % (lab, addr, cur, orig))
            rc = 2
    try:
        f = open(BACKUP, 'w')
        f.writelines(bk)
        f.close()
        print("  备份已写入 %s" % BACKUP)
    except IOError, e:
        print("  WARN 备份写入失败: %s" % e)
    return rc


def main():
    mode = 'patch'
    if '--restore' in sys.argv:
        mode = 'restore'
    elif '--status' in sys.argv:
        mode = 'status'

    print("=== patch-sfp+.py  mode=%s ===" % mode)
    pid = wait_pid()
    if pid is None:
        print("ERROR: 等待 %ds 仍未找到 nsm 进程 (%s)" % (WAIT_SECS, TARGET))
        return 1
    print("  nsm pid = %d" % pid)

    fd = os.open('/proc/%d/mem' % pid, os.O_RDWR)
    try:
        if mode == 'status':
            rc = do_status(fd)
        elif mode == 'restore':
            rc = do_restore(fd)
        else:
            rc = do_patch(fd)
    finally:
        os.close(fd)

    if rc == 0:
        print("=== DONE ===")
    else:
        print("=== DONE (rc=%d，请检查上面的 WARN) ===" % rc)
    return rc


if __name__ == '__main__':
    sys.exit(main())

10. 关于开头的问题

10.1 为什么厂商要将这四个端口绑定到一个组内?

芯片侧存在 PLL 域 (CMU) 的概念 (sys_tsingma_datapath_12g_is_pll_equal、sys_tsingma_datapath_28g_is_pll_equal、_sys_tsingma_datapath_12g_load_cmu_val), 按速率分 12G 域 (≤12.5G，容纳 1G/2.5G/10G) 与 28G 域 (25G/50G). 但是博主手上的这台设备端口规格为 SFP+, 并非 SFP28. 因此也就不支持 25G/50G 速率, 也就不会出现 28G 时钟速率的情况. 厂家将其绑定为一个组归根结底还是避免速率调整导致的设备故障, 这种做法也可以理解. 但由于固件过于公版, 并没有针对每个设备做十分细致的调整, 也就导致了这台设备非必要的功能缺失.

10.2 为什么 `group-speed` 没有设计 2.5Gbe 速率的下发实现?

关于这个疑问, 其实分析完之后也没法做出一个很准确的回答. 但分析过程中也确实从侧面获取到了一些厂家可能的意图.

产品定位: SFP+ 是上联口, 而 2.5G 是接入侧的定位整机是 48×2.5G 电口 + 4×10G + 2×40G:

2.5Gbe 是接入侧的能力, 由 48 个电口的 PHY 提供;
SFP+ 是上联 / 级联用途, 目标速率是 1G/10G. 在这种分工下, 让上联口跑 2.5Gbe 不是产品设计里的应用场景, 厂商自然不会把它做进上联专用的 group-speed.

2.5Gbe 在 SFP+ 上不是标准速率 SFP+ MSA 定义的是 1G / 10G. 2.5G 跑 SFP+ 属于非标准用法, 能用它的模块很少. 厂商为上联口提供非标准速率意味着: 额外的模块兼容性验证、DDM/CDR 行为的未知风险、以及售后支持成本.
代码结构原因
vs 特化逻辑这是最直接的工程解释:

每端口 speed 是全产品线共用的代码路径, 它的 token 表要覆盖所有 SKU 的所有口类型 (10M……400G), 所以 2G5 天然在里面;
group-speed 是针对 上联端口组 特化的逻辑, 厂家只枚举了该场景真正要用的速率 (default|1000|10G|25G).

厂家其实是有意关掉, 不是漏做这是最有力的一条: speed-mode (1-10G | 2G5-10G | 1-25G | 10-25G) 这个命令已经把 2G5-10G 写好了, 包括写 EEPROM/sysenv, 重启生效, show speed-mode 全套. 但本板没有任何端口带上启用所需的标志, 导致该命令直接回 Do not support speed mode config! 也就是说: 能力是现成的, 开关是故意焊死的. 这不太像是忘了做, 而是更像做了但按板型分产品或是客户配置关闭.很可能是按订单 / SKU 分级的产品策略 (要 2.5G 就得买对应型号).

总结

本分并非专业人士, 如有错误或疏漏请指出! 感谢您的阅读.

自建 Debian 13 镜像源: ftpsync + Nginx

Sun, 20 Sep 2026 04:45:00 GMT

前言

在某些企业中, 由于私有服务器有不联公网的要求, 但同时也需要更新相关软件包, 这时就需要自建软件镜像源. 而在某些 HomeLab 玩家中, 为了追求极致的速度和极低的延迟, 也会选择自建相关镜像源. 这篇文章将会记录博主自建 Debian 镜像源的全过程, 为有需要的人提供一些帮助.

示例环境

root@Mirror:~# neowofetch
       _,met$$$$$gg.             root@Mirror 
    ,g$$$$$$$$$$$$$$$P.          ----------- 
  ,g$$P"        """Y$$.".        OS: Debian GNU/Linux 13.6 (trixie) x86_64 
 ,$$P'              `$$$.        Host: KVM/QEMU (Standard PC (i440FX + PIIX, 1996) pc-i440fx-11.0) 
',$$P       ,ggs.     `$$b:      Kernel: 6.12.74+deb13+1-amd64 
`d$$'     ,$P"'   .    $$$       Uptime: 6 mins 
 $$P      d$'     ,    $$P       Packages: 450 (dpkg) 
 $$:      $$.   -    ,d$$'       Shell: bash 5.2.37 
 $$;      Y$b._   _,d$P'         Terminal: /dev/pts/0 
 Y$$.    `.`"Y$$$$P"'            CPU: Intel Xeon E5-2696 v4 (8) @ 2.1GHz 
 `$$b      "-.__                 Memory: 0.32 GiB / 1.92 GiB (16%) 
  `Y$$                           Network: Unknown 
   `Y$$.                         BIOS: SeaBIOS 0.0 (04/01/2014) 
     `$$b.
       `Y$$b.                                            
          `"Y$b._                                        
              `"""

注意

搭建软件镜像源需要非常多的磁盘存储, 在操作之前请确认你有足够多的空间去存放软件源. Debian 相关软件源大小可以从这里获取

开整

1. 前置工作

用于进行软件源同步的工具有非常多, 具体功能与特色可以参考下表

工具	核心特点	适用场景
`apt-mirror`	简单易用, 配置直观, 适合快速搭建完整镜像.	希望快速上手, 对功能要求不复杂的个人或小型内网环境.
`apt-mirror2`	`apt-mirror` 的现代重写版, 使用 `Python`/`asyncio`, 性能功耗, 支持数据完整性检查和 GPG 签名校验, 能保证镜像完整不损坏.	追求更好性能和可靠性, 希望避免同步过程中产生损坏镜像的用户.
`debmirror`	功能强大且灵活, 支持按架构, 发行版, 组件进行精细化同步. 支持 HTTP/HTTPS/FTP/rsync 多种传输方式.	需要精细控制同步内容, 或者网络环境需要特定协议的场景.
`aptly`	企业级仓库管理工具. 除了镜像, 还支持快照, 合并, 发布等高级功能, 适合需要版本控制和 CI/CD 集成的环境.	企业级应用, 需要对仓库进行复杂管理和版本控制的场景.
`reprepro`	轻量级的仓库构建和管理工具, 可以从本地 `.deb` 文件池构建仓库, 也支持镜像功能, 配置灵活.	希望从本地软件包构建仓库, 或者需要进行更细粒度镜像配置的场景.
`rsync`	最基础的同步工具, 直接镜像整个目录, 增量同步效率高.	对同步要求内容不高, 仅需简单, 完整地复制整个仓库目录的场景.

这里我们使用 ftpsync 作为同步工具.

首先我们需要安装 ftpsync 同步镜像源, Web 服务器 (nginx / apache) 确保能够被 HTTP 访问

apt update
apt install ftpsync nginx -y

创建一个专门用于同步镜像的用户, 这是官方推荐的安全做法

adduser mirror

创建存储目录并配置权限, 用于存放所有镜像文件

mkdir path/to/mirrir
chown mirror:mirror path/to/mirror

2. 配置同步

创建配置文件

mkdir /etc/ftpsync
vim /etc/ftpsync/ftpsync.conf

填入以下参数

########################################################################
# ftpsync.conf - Debian 13 (trixie) amd64 + arm64 镜像配置
########################################################################

# ---- 基础信息 ----
# 镜像主机名，用于生成 trace 文件
MIRRORNAME=$(hostname -f)

# 镜像存放的目标目录（必须为空或仅含 pool 数据）
TO="/srv/mirrors/debian"

# 日志与邮件（日志目录需提前创建）
LOGDIR="/home/mirror/log"
MAILTO=""          # 留空则不发送邮件，改为查看日志

# 是否为叶子节点（不向下游推送）
HUB=false

# ---- 上游连接 ----
# 选择一个支持 rsync 的上游镜像
# 国内推荐使用阿里云/腾讯云镜像，但需确认其提供 rsync 服务
# 这里以官方 ftp.debian.org 为例，实际请替换为你的上游
RSYNC_HOST="ftp.debian.org"
RSYNC_PATH="debian"

# ---- 架构过滤 ----
# 只同步 amd64 和 arm64，source 包含在内以便后续需要
ARCH_INCLUDE="amd64 arm64 source"

# ---- 发行版过滤 ----
# 只同步 trixie（Debian 13）及其相关组件
# DIST_INCLUDE 是 ftpsync 支持的过滤选项
DIST_INCLUDE="trixie trixie-updates trixie-backports"

# ---- 日志详细程度 ----
# 开启 FULLLOGS 才能看到 rsync 的详细传输进度
FULLLOGS=true

# ---- 安全删除限制 ----
# 防止误删，设置最大删除数量
MAX_DELETE=1000

# ---- rsync 额外选项 ----
# --info=progress2 用于显示整体进度（配合 FULLLOGS 使用）
RSYNC_EXTRA="--info=progress2"

如果想设置同步多个镜像, 则需要在相同目录下按照 ftpsync-<mirrorName>.conf 创建配置文件

执行同步命令测试配置

ftpsync sync:all

如果执行后没有立即报错, 正常开始同步, 则证明配置文件无误. 此时可以 ^C 然后继续进行后续配置

3. 配置 Web 服务器

创建 Nginx 配置文件

vim /etc/nginx/site-avaliable/mirrors

填入以下内容

server {
    listen 80;
    listen [::]:80;

    server_name <your_domain>;

    root path/to/mirror;

    autoindex on;
    autoindex_exact_size on;
    autoindex_localtime on;

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

    charset utf-8;

    keepalive_timeout 65;

    access_log /var/log/nginx/mirrors.access.log;
    error_log /var/log/nginx/mirrors.error.log;

    location ~* /(dists|pool)/.*(InRelease|Release|Release.gpg|Packages|Sources)(\.gz|\.xz|\.bz2)?$ {
        expires 1h;
        add_header Cache-Control "public";
    }

    location ~ /\. {
        deny all;
        access_log off;
        log_not_found off;
    }
}

server_name 服务器名称. 填入您的域名即可 root 网站根目录. 填写镜像同步目录即可如果你的 URL 中包含 debian, 则需要添加以下内容
  location /debian/ {
      alias path/to/mirror;
      autoindex on;
  }

将配置文件链接到 sites-enabled 目录以启用

ln -s /etc/nginx/sites-available/mirror-debian /etc/nginx/sites-enabled/

测试配置

nginx -t

如果输出没有报错, 则正常. 4. 重新加载 Nginx, 使其生效

systemctl reload nginx

配置相关权限, 使得 www-data 也对镜像目录有可读可执行权限

chmod -R a+rX /mnt/Mirror/mirrors/debian

4. 创建定时任务

安装 crontab, flock

apt install cron flock

mkdir /var/run/ftpsync
chown mirror:mirror /var/run/ftpsync
crontab -u mirror -e

添加行 0 3 * * * flock -xn /var/run/ftpsync/ftpsync-debian.lock ftpsync sync:all

含义为每天凌晨三点自动运行同步如果想设置为每隔 n 小时同步一次, 则可以添加 0 */n * * * flock -xn /var/run/ftpsync/ftpsync-debian.lock ftpsync sync:all

保存并退出

5. 进行首次同步

运行 ftpsync sync:all 进行首次同步

注: 单次全量同步时间较长, 建议使用 screen 等类似工具创建虚拟显示器

等待同步完成后, 即可在客户机替换软件源

6. 测试

替换客户机软件源, 使用 apt update && apt upgrade 进行测试.

root@test:~# apt update && apt upgrade
Get:1 http://mirrors.vm.homelab/debian-security trixie-security InRelease [43.4 kB]
Hit:2 http://mirrors.vm.homelab/debian trixie InRelease
Hit:3 http://mirrors.vm.homelab/debian trixie-updates InRelease
Fetched 43.4 kB in 0s (134 kB/s)
All packages are up to date.    
Summary:                        
  Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0

如果没有报错且速度很快, 那就表明没有问题. 如果有条件的话, 还可以在内网 DNS Server 做单独配置, 给予一个内网可用的专有域名. 至此, 镜像源的搭建就结束了.

结语

本人非专业人士, 如有错误请指出! 感谢您的阅读.

自建私有 VoIP: FreePBX 电话系统

Thu, 13 Aug 2026 10:39:00 GMT

前言

在这个技术日益高速发展的时代, 科技单位对我们的监控也变得越来越变本加厉. 信息安全成为了所有人都应该注重的因素. 电话是我们所有人日常生活中都需要使用的功能. 众所周知, 普通电话是可以很轻易地被运营商监听监控的, 所以在谈论一些要事时, 不适宜用普通电话进行交谈. 为了使自己的电话隐私得到更严密的保护, 本篇文章将会记录博主搭建私有 VoIP 电话系统的全过程, 供有需要的读者进行参考.

什么是 VoIP?

VoIP (Voice over IP), 是一种语音通话协议. 它将实时音频流封装到 IP 协议中, 通过互联网基础设施进行传输. 我们可以对其数据包进行一定程度的加密, 从而达到保护隐私的目的.

搭建规划

博主建立了一张可以在家中, 学校中和一些朋友的网络中互相通信的 VPN 网络. 这套 VoIP 系统需要承载 VPN 内电话流量, 但同时不可以被外网访问. 因此防火墙需要指定在 VPN 内网网段和刚才提到的这些网络的内网网段.

配置需求

可以安装 Debian 12 的服务器 / KVM (客户机至少需要 2G RAM, 20G 硬盘)
VPN 网络 (可选)

免责声明

本篇文章仅作技术交流, 请勿使用相关技术进行违规违法行为. 博主已尽到相关警告义务, 所有由读者造成的相关后果与本文, 博主, 本站均无关!

开整

1. 安装 `FreePBX`

Q. 什么是 FreePBX? A. FreePBX 是一套开源免费的, 基于 Asterisk 平台的 IP 电话系统管理工具. 具有用户友好的 WebUI 页面. 同时是全球部署最广泛的开源商业通信系统之一, 拥有数百万活跃安装量. 其拥有庞大的开发者群体和社区, 提供丰富的文档支持. 同时功能可根据需求进行模块化定制和扩展, 十分方便.

1.1 使用 ISO 映像安装

前往 FreePBX 下载页下载最新版的 FreePBX 安装映像
启动映像, 选择第一项直接安装. 选择后会让你花 30s 的时间阅读一份帮助文档, 随后就可以进入安装页面. 整个安装过程是全自动的, 并不需要手动操作什么, 等待安装完成即可.

1.2 手动安装

使用这种方法需要你当前的操作系统为 Debian 12 (bookworm). 如果你和我一样使用 Proxmox VE 作为宿主系统, 那么我这里推荐使用 Debian 12 Cloud Init 映像作为安装映像

使用该指令执行安装脚本

wget https://github.com/FreePBX/sng_freepbx_debian_install/raw/master/sng_freepbx_debian_install.sh -O /tmp/sng_freepbx_debian_install.sh && bash /tmp/sng_freepbx_debian_install.sh

执行后, 该脚本会自动安装所有所需要的软件包, 整个过程大约需要半小时, 耐心等待即可.

可能需要科学上网

2. 配置 FreePBX

2.1 初始化

安装完成后, 直接访问服务器 IP 地址, 端口为默认 80 端口, 打开 WebUI.
按照要求填写管理员用户名, 密码, 邮箱地址等, 然后完成设置.
进入 WebUI 后登录, 会自动跳转到服务器初始化设置页面. 单击 Active 激活服务器.
这里会让你创建 Portal Account (门户账户), 输入邮箱后服务器会自动检查可用性.
在这之后按照 WebUI 指示完成全部配置即可.

2.2 基础配置

2.2.1 防火墙

进入 Connectivity -> Firewall 页面, 设置防火墙
选择 Interfaces 选项卡, 进入接口设置. 这里会列举出你的服务器上当前可用的所有网络接口. 然后在 Default Zone 中配置默认区域.

Default Zone	名称	简介	安全性
`Internet`	互联网	允许网络上的所有 SIP 客户端接入, 黑名单除外	最低
`Local`	本地	仅允许本地受信任的通讯接入	高
`Other`	其他	仅允许其他类型通讯接入	高
`Reject`	拒绝	拒绝所有通讯接入	最高
`Trusted`	受信任	仅允许受信任的通讯接入	高

这里按需选择接口防火墙配置. 在本文的场景中, 选择 Local 即可. 配置完成后, 单击右下角 Update Interfaces 即可更新防火墙配置

来到 Networks 选项卡, 配置受信任的网段. 服务器会自动将本地网段和你用于访问 WebUI 的设备地址加入受信任域, 这里我们可以手动添加. 输入的 IP 地址段须符合 CIDR 规则 (例如 192.168.1.0/24, 10.0.0.0/8 等) 输入完成后单击右下角的 Save 即可

2.2.2 SIP 中继

如果你需要将你的系统接入外部 SIP 系统, 来访问其他全球 VoIP 服务器, 则需要配置中继. 在本文的需求中是不需要的. 但这里为了使得教程更加通用, 还是介绍一下如何配置.

首先向一个 SIP 服务提供商 (如 VoIP.ms, Twilio 等) 购买服务
进入 Connectivity -> Trunks 点击 Add Trunk
根据 SIP 提供商给出的相关信息, 选择相应的类型, 填入数据后保存即可

2.2.3 创建分机 (添加用户)

进入 Connectivity -> Extensions 点击 Quick Create Extension 快速添加分机, 按照指示填写参数

参数名称	含义	详解
`Type`	分机类型	这里直接选择 `chan_pjsip` 即可. 这是 FreePBX 目前推荐且默认的现代 SIP 协议栈, 兼容性更好且支持 IPv6 和更强的加密
`Extension Number`	分机号码	系统内外呼时的号码
`Display Name`	显示名称	该分机来电时显示的名称
`Outbound Caller ID`	外呼主叫号码	拨打外线电话 (其他 SIP 中继号码) 时, 对方看到的来电号码
`Email Address`	电子邮件	该分机关联的邮箱

参考配置
FreePBX 分机配置参考

填写完单击下一步, 然后继续按照要求填写

参数名称	含义	详解
`Enable Find Me/Follow Me`	启用 “查找我”/“跟踪我”	多终端联动功能. 当有人拨打你的号码时, 系统可以同时或依次呼叫你的其他分机
`ParkingLot`	驻留区域	通话驻留是指可以将你正在进行的通话暂存到系统的某个编号, 然后去另一部分机上取回继续通话
`Create User Manager User`	创建用户管理用户	是否在 FreePBX 的用户控制面板中创建一个 Web 登录账号
`User Manager Groups`	用户管理分组	给这个用户分配的权限组
`Enable Voicemail`	启用语音信箱	当无人接听或忙线时, 可以给你留言
`Voicemail PIN`	语音信箱密码	用电话拨号盘接听语音留言时, 需要输入 PIN 码

参考配置
FreePBX 语音信箱参考配置

配置完成后单击 Finish. 然后单击用户右侧的编辑按钮, 进入编辑页面
找到用户密码, 将鼠标指针移至编辑框内就会显示密码, 复制并记录. 如需修改也可以现在修改.
全部配置完成后, 返回用户列表页面, 单击右上方红色 Apply Config 按钮提交配置.

3. 配置客户端

SIP 分机拨号客户端有很多种, 这里我们使用 ZoiPer 作为演示. 安卓端可以直接在 Play 商店中下载, 桌面端请移步官网.

打开软件, 在 Username @ PBX/VoIP provider 一栏中, 按照 分机号 @ IP 地址 的格式填写

例如 10001@192.168.1.24

密码填写刚才记录的用户密码, 然后点击 Login 登录.
接下来两个页面都直接下一步即可, 随后会进入一个测试连接可用性的页面. 博主的环境中测试 SIP UDP 是可用的.

注意: 如果你正在使用 HTTP Proxy 或透明代理, 可能会无法使用! 请暂时关闭您的代理

进入主页面后, 就可以直接尝试拨打电话了.

至此, 服务端和客户端的基础配置就完成了. FreePBX 的功能十分强大, 十分推荐自行去挖掘一下其他有用的功能. 本文只做基础配置讲解, 暂且不提其他配置. 如果后面有机会, 还会再出一篇进阶配置的文章.

后记

本人并非专业人员, 如有错误会疏漏请直接指出, 感谢您的阅读!

OrangePi 3B 编译 UEFI 固件

Sun, 09 Aug 2026 14:15:00 GMT

前言

就在前几天 (2026-08-05), Proxmox VE 官方宣布了对 Arm64 平台的支持. 这使得我想起了实验室学长们送我的那块 OrangePi 3B 开发板, 索性尝试使用这块开发板来启动 Proxmox VE 原生的 iso 映像文件. 由于 Proxmox VE 官方提供的映像文件是需要使用 efi 启动的, 查了一圈发现没有专门给 OrangePi 3B 编译的 UEFI 固件, 索性自己尝试编译

本文操作环境

       _,met$$$$$gg.             nanami114@VM-Main 
    ,g$$$$$$$$$$$$$$$P.          ----------------- 
  ,g$$P"        """Y$$.".        OS: Debian GNU/Linux 13.4 (trixie) x86_64 
 ,$$P'              `$$$.        Host: KVM/QEMU (Standard PC (i440FX + PIIX, 1996) pc-i440fx-11.0) 
',$$P       ,ggs.     `$$b:      Kernel: 6.12.74+deb13+1-amd64 
`d$$'     ,$P"'   .    $$$       Uptime: 29 days, 3 hours, 15 mins 
 $$P      d$'     ,    $$P       Packages: 3 (npm), 1526 (dpkg) 
 $$:      $$.   -    ,d$$'       Shell: bash 5.2.37 
 $$;      Y$b._   _,d$P'         Resolution: 1280x800 
 Y$$.    `.`"Y$$$$P"'            Terminal: /dev/pts/1 
 `$$b      "-.__                 CPU: Intel Xeon E5-2696 v4 (44) @ 2.1GHz 
  `Y$$                           GPU: Vendor 1234 Device 1111 
   `Y$$.                         Memory: 20.74 GiB / 31.33 GiB (66%) 
     `$$b.                       Network: Unknown 
       `Y$$b.                    BIOS: SeaBIOS 0.0 (04/01/2014) 
          `"Y$b._
              `"""

开整

1. 编译 UEFI

1.1 准备材料

在 GitHub 中有一个叫做 quartz64_uefi 的项目专门给 RK356X 的平台适配了 UEFI, 所以我们可以从这里入手. 首先 clone 该仓库

git clone https://github.com/jaredmcneill/quartz64_uefi

查看项目结构, 发现项目中已经包含了专门为 Orange Pi 3B 的 platform, device tree, drivers 等, 并且 build.sh 中也有适用于 OrangePi 3B 的构建流程. 所以这里可以尝试直接构建
quartz64_uefi 项目中的 OrangePi 3B 平台目录结构

for board in ${RKUEFIBOARDS}; do
        case ${board} in
        QUARTZ64)
                build_uefi Pine64 Quartz64
                build_fit Quartz64 rk3566-quartz64-a
                ;;
        SOQUARTZ)
                build_uefi Pine64 SOQuartz
                build_fit SOQuartz rk3566-soquartz-cm4
                ;;
        ROC-RK3566-PC)
                build_uefi Firefly ROC-RK3566-PC
                build_fit ROC-RK3566-PC rk3566-roc-pc
                ;;
        ROC-RK3568-PC)
                build_uefi Firefly ROC-RK3568-PC
                build_fit ROC-RK3568-PC rk3568-firefly-roc-pc
                ;;
# OrangePi 3B Here...
        ORANGEPI3B)
                build_uefi OrangePi OrangePi3B
                build_fit OrangePi3B rk3566-orangepi-3b
                ;;
        PINETAB2)
                build_uefi Pine64 PineTab2
                build_fit PineTab2 rk3566-pinetab2
                ;;
        ZERO-3W)
                build_uefi Radxa Zero-3W
                build_fit Zero-3W rk3566-radxa-zero-3w
                ;;
        ODROID-M1S)
                build_uefi HardKernel Odroid-M1S
                build_fit Odroid-M1S rk3566-hardkernel-odroid-m1s
                ;;
        *)
                echo "Unknown board ${board}"
                exit 1
                ;;
        esac
done

1.2 检查环境

检查 Git 子模块状态

git submodule status

如果你当前所处的目录属主与当前执行的用户不一致, 则 Git 会报错 dubious ownership, 此时执行这条指令添加信任

git config --global --add safe.directory path/to/quartz64_uefi

检查编译工具链由于博主这里是在 amd64 架构的设备上去编译 arm64 的固件, 故这里需要配置交叉编译工具链. 我们从官方 CI 配置文件中提取依赖清单并安装

cat .github/workflows/build.yml

从这份配置文件中我们可以得到官方构建所需要的所有依赖, 分别为 gcc-aarch64-linux-gnu iasl device-tree-compiler python3-pyelftools uuid-dev. 这里我们直接安装

sudo apt-get update
sudo apt-get install -y --no-install-recommends gcc-aarch64-linux-gnu iasl device-tree-compiler python3-pyelftools uuid-dev

检查 edk2-rockchip 目录性质

git -C ed2k-rockchip rev-parse HEAD
ls edk2-rockchip/.git
git ls-files | grep edk2-rockchip

执行完后我们可以发现, 项目里 edk2-rockchip/ 和 edk2-rockchip-non-osi/rkbin/ 是 platform 代码和 Rockchip 官方 vendor 组件 (DDR 初始化固件, BL31, OP-TEE, boot_merger/ddrbin_tool 工具). 我们需要确认它们是 submodule 还是直接打进 git 的:

.git 文件不存在, 同时 git ls-files 显示 234 个文件被直接跟踪. 因此得出它们是 vendored 进主仓库的, 我们只需要克隆主仓库就齐了.
只有 edk2 是真正的 submodule, 因此只有 edk2 需要单独初始化.

1.3 初始化编译环境

这里我们更新并初始化所有 submodule

git submodule update --init --recursive

--rescursive 的作用是连带嵌套 submodule 一起克隆 edk2 自己还有 cmocka/googletest/subhook 等测试框架子模块

edk2 是一个 200MB+ 的大仓库, 这里更新需要拥有一个稳定的网络环境.

1.4 尝试编译

使用 make 工具启动构建

make BOARDS=ORANGEPI3B uefi

这里通常只需要等待几分钟, 如果编译时间过长请检查之前的动作有没有问题

编译完成后, 使用 make 编译一个可烧录进 SD 卡的映像文件

make BOARDS=ORANGEPI3B sdcard

这里需要提前安装 parted, 否则会报错

编译完成后我们会得到一份 ORANGEPI3B_EFI.img 文件, 这份文件可以直接烧录进 SD 卡尝试启动.

2. 启动 UEFI

2.1 烧录

使用 Win32DiskImager 将 ORANGEPI3B_EFI.img 烧录至 SD 卡即可.

2.2 启动

重启之后会看到 Orange Pi 的 Logo, 还有 tianocore 项目的文字. 如果没有插入任何启动设备, 则会自动进入 BIOS.

OrangePi 3B 启动后进入 UEFI 设置界面

据了解, 在以前的版本中, 只有 USB3.0 处于可用状态. 但这里博主编译的版本, 四个 USB-A 接口都处于可用状态.

2.3 烧录系统

这里可以使用 UltraISO 之类的软件, 将可启动映像烧录至 U 盘等存储介质中, 然后直接上电启动, UEFI 会自动引导到您的安装介质.

使用镜像工具将 UEFI 固件烧录到 SD 卡

至此, 整个 UEFI 编译及烧录过程就结束了.

结语

本人并非专业人士, 如有错误或疏漏请指出, 谢谢!

附件

ORANGEPI3B_EFI.zip

FakeMesh + 802.11kvr 全屋 WiFi 漫游

Mon, 27 Jul 2026 14:06:00 GMT

前言

博主最近在思考如何优化自己的家庭网络环境时, 突然想到对家里的 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. 然后将网关设置为主路由.
设置 AP 的 lan 接口 IPv4 地址与网关
切换到 DHCP Server 选项卡, 勾选 Ignore Interface 选项以完全禁用其 DHCP Server, 然后点击 Save 保存
在 AP 上忽略 DHCP Server
删除 wan 和 wan6 接口
切换到 Devices 选项卡, 找到 br-lan 接口的 Configure 按钮并点击进行配置
勾选所有物理接口和 AP 并单击保存
将物理接口与 AP 绑定到 br-lan

如果你的情况和我一样, 这里列出的接口是 Switch VLAN 类型而不是 Ethernet Adapter, 可以通过这个方式来查找接口.

切换到 Network -> Switch 页面
OpenWrt Switch 页面中的 VLAN 划分
从这里我们可以看出, 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 属性
连接 WiFi 后获取到公网 IPv6 与内网 IPv4
可以看到这里已经成功拿到公网 IPv6 地址和 192.168.1.0/24 网段的 IPv4 地址.

这样的配置在两台路由器上都需要进行

2. 启用 FakeMesh

FakeMesh 是 OpenWrt 提供的一个轻量级, 软件模拟的 Mesh 组网功能. 它能够做到在多台 AP 设备中进行统一的配置管理, 实现无缝漫游, 并且简化多路由网络管理.

2.1 主路由配置

进入 Mesh -> FakeMesh 页面, 勾选 Enable 启用功能
在 Mesh ID 处创建当前 Mesh 会话的标识符. 这里建议不要填写英文字母, 下划线, 数字以外的特殊字符, 以免出现编码错误.
在 Key 中创建当前 Mesh 会话的加密密钥
在 Band 中选择 5G
在 Role 处切换至 Controller (AC) 模式

模式解释

Wired AP 表示该设备为被控制有线 AP

Agent 表示该设备用于无线 Mesh 组网

勾选 Sync Configuration 同步配置
在 Band Steering Helper 中选择 usteer

usteer: OpenWrt 官方的轻量级漫游辅助工具, 简单稳定

DAWN: 一个功能更强大的第三方漫游辅助工具, 算法更复杂. 这里考虑到路由器的性能, 不做选择.

None: 关闭漫游辅助功能

关于 Controller Access IP: 这个地址是 FakeMesh 控制器设置的一个固定 IP, 方便你在局域网内访问它的 WebUI. 通常情况下不需要修改, 保持默认值 10.10.10.1 即可. 这个 IP 是 FakeMesh 在内部网络中用于服务发现的, 不会和你的主路由 LAN 口 IP 产生冲突. 平时管理主路由还是使用 LAN 口的 IP 去管理. 当然, 如果你的网络环境中 10.10.10.1 这个地址存在冲突, 那你当然可以换掉它. 但请记住在 AP 中配置时也要填写相应的 IP. 关于 Disable Fronthaul: 该功能用于开关当前节点的 SSID 广播功能. 如果你不希望当前节点发射 SSID 信号, 则可以勾选它. 在博主的配置场景中, 主路由不具备 WiFi 信号发射功能, 所以这里可以勾选

主路由 FakeMesh 控制器配置

配置完成后点击 Save&Apply. 应用成功后, 下方的 Wireless Management 板块会出现一个 WiFi SSID. 这里我们点击编辑
在弹出的对话框中配置你想要的 SSID, 加密方式, 频段和密码. 填写完成后再次点击保存并应用.

到这里为止, 主路由 FakeMesh 的配置就结束了

2.2 AP 配置

进入 Mesh -> FakeMesh 页面, 勾选 Enable 启用功能
在下面的信息中填入你刚才在主路由中配置的信息, 并将 Role 切换为 Wired AP (Ethernet backhaul) 模式
信息填写完成后单击保存并应用. 届时, AP 设备原有的 IP 地址将会失效, 此时需要进入主路由的 Mesh -> Usteer 页面查看
Usteer 页面显示已上线的 AP

可以看到这里有一台 AP 已经上线. 我们使用页面中所给的 192.168.1.182 访问 AP 的后台

登录后台, 切换到 Network -> Interface 页面
点击 meshx0 接口的编辑按钮, 将其从 DHCP Client 切换到 Static Address 协议
输入你之前设定的 IP 地址信息, 然后点击保存并提交. 之后使用你设置的新 IP 访问 AP 后台.
切换到 Network -> Wireless 查看 WiFi 发射信息. 如果看到刚才在主路由上配置的 SSID 有正确发送, 则证明配置成功.
AP 侧 Wireless 页面确认 SSID 已下发

如果你配置完成后, AP 侧已经同步了相关配置信息, 但是就是没有发送 WiFi 信号. 别急, 这不是你的问题. 经过分析, 这是由于主路由 FakeMesh 控制器的 wifim 配置中缺少 band 选项. 在 AP 侧, 生成 WiFi 信号的主要逻辑在 agent_sync_config 函数中:

  while uci get fakemeshac.@wifim[$J] &>/dev/null; do
          ssid=$(uci get fakemeshac.@wifim[$J].ssid)
          encryption=$(uci get fakemeshac.@wifim[$J].encryption)
          key=$(uci get fakemeshac.@wifim[$J].key)
          bands=$(uci get fakemeshac.@wifim[$J].band)    # ← 关键！
          enabled=$(uci get fakemeshac.@wifim[$J].enabled || echo 1)

          [ "$bands" = "2g5g" ] && bands="2g 5g"

          [ "$enabled" = "1" ] && {
              for band in $bands; do                      # ← band 为空则循环不执行！
                  for wbandstr in $(uci show wireless | grep .band=\'${band}\'$); do
                      radio=$(echo $wbandstr | cut -d\. -f2)
                      uci set wireless.wifinet$K=wifi-iface
                      uci set wireless.wifinet$K.device="${radio}"
                      # ... 设置 SSID、加密、802.11r/k/v 等
                      K=$((K+1))
                  done
              done
          }
          J=$((J+1))
      done

控制器的 wifim 配置没有 band 选项, 导致 AP 同步配置后无法匹配任何 radio, 客户端 WiFi 接口从未被创建. 初步判断这可能是 OpenWrt 系统的 Bug. 现在来进行修复

登录主路由 SSH, 执行以下指令

uci set fakemesh.@wifim[0].band="2g5g"
uci commit fakemesh

uci delete fakemesh.default.wifim_md5
uci commit fakemesh
/etc/init.d/fakemesh restart

等待 20s 左右, 让 FakeMesh 完成同步. 届时你就应该能看到 WiFi 信号正确创建.

至此, AP 侧配置完成.

相应的配置在两台 AP 上都需要执行.

3. 测试

在两台 AP 上都配置完成后, 再次打开主路由的 Network -> Usteer 页面. 应当能看到两台 AP 接入

Usteer 页面显示两台 AP 接入

此时打开手机的 WiFi 页面检查, 理应能看到 4 个 AP 接入点. (双 2.5G, 双 5G)

手机 WiFi 列表显示 4 个 AP 接入点

连接上网络后, 四处走动观察首选 AP 连接状况变化

AP 1
漫游测试中 AP1 的连接记录
AP 2
漫游测试中 AP2 的连接记录
可以看到, AP 确实有在按照信号强度切换.

最后使用 Speedtest 对网络速率进行测试

Speedtest 测速结果约 700Mbps

博主家里是 2000Mbps 宽带, 路由器的接口速率为 1Gbps, 这里局限于路由器性能, 跑到 700Mbps 属正常水平, 故测试正常!

至此, 配置全部结束

后记

本人非专业人士, 如有错误或疏漏请直接指出! 感谢您的阅读!

OSPFv3 + WireGuard 借用 IPv6 出口

Wed, 22 Jul 2026 15:35:00 GMT

前言

博主大学的校园网环境中没有公网 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
OpenWrt 软件包页面安装 BIRD
安装完成后打开 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 restart

2. 配置 WireGuard 接口

OpenWrt 默认安装 WireGuard, 但没有默认的私钥和公钥, 所以这里我们自己生成

进入 SSH, 生成公钥和私钥

cd /etc/wireguard
wg genkey | tee privatekey | wg pubkey > publickey

OpenWrt 原生支持在 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 的网段也是绰绰有余了. 示例配置
WireGuard 接口示例配置

切换至 Peers 页面, 点击 Add peer
在 Description 中填入对端设备名称
在 Public Key 中填入对端设备公钥
在 Allowed IPs 中填入对端 WireGuard 内网 IPv6 地址和 ::/0
在 Endpoint Host 中填入校园网网关的 VPN 内网地址
在 Endpoint Port 中填入校园网网关的 WireGuard 监听地址

因为我们还未配置校园网网关接口, 所以这里直接随便写一个端口即可.

在 Persistent Keep Alive 中填入 25

示例配置
WireGuard Peer 示例配置

配置完成后保存提交

相同的配置需要在校园网网关上也配置一遍

双方都配置好后, 检查接口状态. 如果接口的 TX 和 RX 都有流量, 那就证明配置成功了. 此时可以进行测试.

root@Debian:/etc/wireguard# ping fe80:1::1%tunnel_ipip6
PING fe80::1%tunnel_ipip6 (fe80:1::1%tunnel_ipip6) 56 data bytes
64 bytes from fe80:1::1%tunnel_ipip6: icmp_seq=1 ttl=64 time=0.812 ms
64 bytes from fe80:1::1%tunnel_ipip6: icmp_seq=2 ttl=64 time=0.614 ms
64 bytes from fe80:1::1%tunnel_ipip6: icmp_seq=3 ttl=64 time=0.750 ms
64 bytes from fe80:1::1%tunnel_ipip6: icmp_seq=4 ttl=64 time=1.25 ms
^C
--- fe80:1::1%tunnel_ipip6 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3052ms
rtt min/avg/max/mdev = 0.614/0.857/1.254/0.239 ms

可以看到连接是没有问题的, 至此 WireGuard 侧配置完成.

3. 配置 OSPF

在这两台设备上创建 bird.conf

vim /etc/bird/bird.conf

按照该模板填写

log syslog all;

define ROUTER_ID                = <ROUTER_ID>

protocol device {
    scan time 10;
};

protocol direct {
    ipv4;
    ipv6;
};

include "kernel.conf";
include "ospf.conf";

ROUTER_ID 当前路由器的 Router ID. 需要双方不同且唯一. 值形式与 IPv4 类似, 均为 xxx.xxx.xxx.xxx. 这里可以直接填写本机的内网 IPv4 地址.

分别创建 kernel.conf

protocol kernel kernel_v4{  
    ipv4 {
        import none;
        export filter {
            if source = RTS_STATIC then reject;
            accept;
        };
    };
}

protocol kernel kernel_v6 {
    ipv6 {
        import none;
        export filter {
            if source = RTS_STATIC then reject;
            accept;
        };
    };
}

该配置文件旨在让 BIRD 将动态路由协议 (如 BGP, OSPF) 学习到的路由写入系统内核, 但拒绝将自己配置文件中写死的静态路由写入内核.

分别创建 ospf.conf
校园网网关

protocol ospf v3 ospf_4to6 {
    router id ROUTER_ID;
    ipv6 {
        import all;
        export none;
    };
    include "/etc/bird/ospf/0.conf";
}

该配置文件旨在让 BIRD 从该 OSPF 会话中引入所有学习到的路由, 但不导出任何路由到该 OSPF 会话中.

家庭网关

filter export_default {
    if net ~ [ ::/0 ] then {
        accept;
    } else {
        reject;
    }
}

protocol ospf v3 ospf_4to6_test {
    router id ROUTER_ID;
    ipv6 {
        import none;
        export filter export_default;
    };
    include "/etc/bird/ospf/0.conf";
}

该配置文件旨在让 BIRD 将 ::/0 的默认路由导入 OSPF 中, 但不导出任何学习到的路由到系统内核中.

分别创建 OSPF 会话配置文件
校园网网关

mkdir ospf
vim ospf/0.conf

plain - 配置文件 bash area 0.0.0.0 { interface "tunnel_ipip6" { type ptmp; ttl security tx only; neighbors { fd00:1::1; }; }; };

家庭网关

mkdir ospf
vim ospf/0.conf

plain - 配置文件 bash area 0.0.0.0 { interface "tunnel_ipip6" { type ptmp; ttl security tx only; neighbors { fd00:1::2; }; }; };

Q. 为什么使用 ULA 地址建立连接却还需要 Link-Local 地址? A. 因为 OSPFv3 邻居发现依赖链路本地地址 (Link-Local）, 协议报文以 Link-Local 为源/目的进行邻接建立; 全局或 ULA 地址可以用于配置, 管理或路由条目. 但不能替代接口上的 Link-Local 地址参与邻接建立, 但是公网会话却需要使用符合 ULA 规范的地址. 因此虽然 OSPF 配置文件中使用 ULA 地址, 但实际连接时 BIRD 会检查该接口是否拥有 Link-Local 地址. 如果没有, OSPF 连接则会失败.

分别应用配置

birdc c

检查会话状态

birdc s p

如果 OSPF 已经处于 Running 状态, 则配置完成

root@Debian:/etc/bird# birdc s p
BIRD 2.19.1 ready.
Name       Proto      Table      State  Since         Info
device1    Device     ---        up     14:40:45.408  
direct1    Direct     ---        up     14:40:45.408  
kernel_v4  Kernel     master4    up     14:40:45.408  
kernel_v6  Kernel     master6    up     14:40:45.408  
ospf_4to6  OSPF       master6    up     14:46:00.698  Running

3. 配置防火墙

到达这一步, 我们已经拥有了 IPv6 默认路由, ULA 地址, Link-Local 地址. 但我们仍然无法上网. 为什么呢? 这是因为在家庭网关侧我们需要启用 nat6 才可以让本地数据包正确的发往公网, 同时公网返回的数据包也可以正确的到达本地设备. 因为 OpenWrt 可以使用 WebUI 配置, 所以这里我们全程使用 WebUI.

打开 Network -> Firewall 页面, 在下方的 Zones 区域点击 wan 区域的编辑按钮
在 Advanced Setting 中勾选 IPv6 Masquerading, 然后保存提交
在 wan 区域启用 IPv6 Masquerading
点击左下角 Add 按钮, 命名为 WireGuard, 将所有规则都选择 accept, Covered networks 选择之前创建的 WireGuard 接口, Allowed forwared to destination zones 和 Allowed forwared to source zones 全部勾选. 之后同样切换到 Advanced Settings 中打开 IPv6 Masquerading, 保存提交
新建 WireGuard 防火墙区域
切换到 NAT Rules 选项卡, 点击 Add 按钮新建规则
规则名称命名为 nat6_ipip6Tunnel, Restrict to address family 选择 IPv6 Only. Outbound Zone 选择 WireGuard. Source address 填入 fd00:1::/112 (即为刚才填写的 ULA 地址段), Action 选择 MASQUERADE, 保存提交.
新建 IPv6 NAT 规则 nat6_ipip6Tunnel

至此, 防火墙配置完成

4. 验证

到了这里, 我们已经完成了所有配置. 现在我们来验证校园网网关是否可以 IPv6 上网.

IPv6 地址查询

root@Debian:/etc/bird# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether bc:24:11:41:d0:1c brd ff:ff:ff:ff:ff:ff
    altname enp0s18
    altname enxbc241141d01c
    inet 192.168.1.21/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,UP,LOWER_UP> mtu 1360 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none 
    inet 10.0.64.21/24 brd 10.0.64.255 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::617b:570b:ef5a:a679/64 scope link stable-privacy proto kernel_ll 
       valid_lft forever preferred_lft forever
5: tunnel_ipip6: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet6 fd00:1::2/112 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80:1::2/112 scope link 
       valid_lft forever preferred_lft forever

可以看到这里 eth0 接口是没有公网 IPv6 地址的

连通性测试

root@Debian:/etc/bird# ping www.baidu.com -6
PING www.baidu.com (2409:8c20:6:123c:0:ff:b0f6:b2d) 56 data bytes
64 bytes from 2409:8c20:6:123c:0:ff:b0f6:b2d: icmp_seq=1 ttl=52 time=14.3 ms
64 bytes from 2409:8c20:6:123c:0:ff:b0f6:b2d: icmp_seq=2 ttl=52 time=13.8 ms
64 bytes from 2409:8c20:6:123c:0:ff:b0f6:b2d: icmp_seq=3 ttl=52 time=13.7 ms
64 bytes from 2409:8c20:6:123c:0:ff:b0f6:b2d: icmp_seq=4 ttl=52 time=14.0 ms
64 bytes from 2409:8c20:6:123c:0:ff:b0f6:b2d: icmp_seq=5 ttl=52 time=14.0 ms
^C
--- www.baidu.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 13.671/13.957/14.308/0.208 ms

可以看到这里成功访问了百度的 IPv6 地址, 连通性正常!

网络路径查询

root@Debian:/etc/bird# traceroute www.baidu.com -6
traceroute to www.baidu.com (2409:8c20:6:123c:0:ff:b0f6:b2d), 30 hops max, 80 byte packets
 1  _gateway (fd00:1::1)  0.873 ms  0.856 ms  0.825 ms
 2  ah-ipv6 (2409:***)  2.385 ms  2.360 ms  2.312 ms
 3  * ah-ipv6 (2409:***)  3.636 ms *
 4  2409:*** (2409:***)  5.922 ms * *
 5  2409:*** (2409:***)  12.053 ms *  12.465 ms
 6  2409:*** (2409:***)  14.650 ms * *
 7  2409:*** (2409:***)  10.908 ms 2409:*** (2409:***)  10.122 ms 2409:*** (2409:***)  8.499 ms
 ...

可以看到, 这里的第一跳就是我们刚才通过 OSPF 配置的 Peer! 至此, 配置全部结束!

后记

本文为整活性质想法, 如果你真的有类似需求, 你或许应该寻找更加体面的方法. 本人非专业人员, 如有错误或疏漏欢迎指出! 感谢阅读.

LACP 聚合双千兆网口实现 2Gbps

Tue, 21 Jul 2026 04:17:00 GMT

前言

博主的 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 品牌的交换机, 直接使用 WebUI 进行配置. 虽然配置过程可能不同, 但 LACP 协议的基础原理都是通用的. 使用其他品牌交换机的读者也可以进行参考.

启动交换机 WebUI, 进入 Link Arrangement 页面的 Port Trunking Settings 子页面.
D-Link 交换机 Port Trunking 设置页面

我们这里使用 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, 即激活状态.
D-Link 交换机 LACP 端口设置页面
配置完成后, 交换机侧的配置就彻底结束了.

2. 配置服务器 LACP

博主这里使用的是基于 Debian 13 的 Proxmox 9.2.3 系统.

安装管理绑定的工具 ifenslave

sudo 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                 # 链路检查间隔(毫秒)
    bond-xmit-hash-policy layer3+4  # 负载均衡的哈希策略
关于 bond-mode

模式名称效果与说明适用场景
mode=4 802.3ad (LACP) 专业级链路聚合, 能够叠加速率并提供负载均衡和容错. 需要交换机也支持 LACP. 服务器与交换机均支持的理想生产环境
mode=0 balance-rr (轮询) 简单负载均衡, 能叠加速率, 不依赖交换机. 但可能导致数据包乱序. 希望无需调整交换机就能获得较好性能的场景. 理论上无需 LACP, 但通常仍建议交换机支持静态聚合, 否则兼容性有限
mode=6 balance-alb (自适应) 无需交换机支持, 即可实现发送和接收的负载均衡, 理论上能叠加速率希望无需调整交换机就能获得较好性能的场景
mode=1 active-backup (主备) 仅提供冗余, 不叠加带宽. 同一时间只有一个网卡工作. 只希望提高网络 SLA, 不追求提升速率

模式	名称	效果与说明	适用场景
`mode=4`	`802.3ad (LACP)`	专业级链路聚合, 能够叠加速率并提供负载均衡和容错. 需要交换机也支持 LACP.	服务器与交换机均支持的理想生产环境
`mode=0`	`balance-rr` (轮询)	简单负载均衡, 能叠加速率, 不依赖交换机. 但可能导致数据包乱序.	希望无需调整交换机就能获得较好性能的场景. 理论上无需 LACP, 但通常仍建议交换机支持静态聚合, 否则兼容性有限
`mode=6`	`balance-alb` (自适应)	无需交换机支持, 即可实现发送和接收的负载均衡, 理论上能叠加速率	希望无需调整交换机就能获得较好性能的场景
`mode=1`	`active-backup` (主备)	仅提供冗余, 不叠加带宽. 同一时间只有一个网卡工作.	只希望提高网络 SLA, 不追求提升速率

配置 vmbr0 网卡

如果您配置的是普通 Linux 而非 Proxmox VE, 则可以不用配置这一步

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.100/24   # 服务器 IP 地址
    gateway 192.168.1.1        # 服务器网关
    bridge-ports bond0         # 关键：网桥连接至 bond0
    bridge-stp off
    bridge-fd 0

完整配置示例

# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage parts of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT read its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual
    bond-master bond0

auto eno2
iface eno2 inet manual
    bond-master bond0

auto bond0
iface bond0 inet manual
    bond-slaves eno1 eno2
    bond-mode 802.3ad
    bond-miimon 100
    bond-xmit-hash-policy layer3+4

auto vmbr0
iface vmbr0 inet static
        address 192.168.1.5/24
        gateway 192.168.1.1
        bridge-ports bond0
        bridge-stp off
        bridge-fd 0

配置完成后, 对网络进行热重载

ifreload -a

如果您正在配置普通 Linux, 则使用该指令
systemctl restart networking

重载完成后, 检查 WebUI 上的配置. 如果没问题, 则配置完成

3. 测试

因为 LACP 是基于流量哈希计算的链路聚合, 所以在单线程下, 带宽仍然是单条链路的带宽. 因此我们这里使用多线程的 iperf3 进行测试

iperf3 -c 192.168.1.5 -P 2

iperf3 双线程测速达到 2Gbps

这里可以看到, 总带宽已经达到 2 Gbps 的标准. 由此可以得出, LACP 聚合的配置已经成功!

如果您使用的是企业交换机, 不要忘了保存配置

后记

本人非专业人员, 如有错误或疏漏请指出! 感谢您的阅读!

IX 前置 + OSPF: IEPL 专线组网搭建

Sun, 19 Jul 2026 15:39:00 GMT

前言

博主拥有自己的境外服务器, 用于完成自己的业务: 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 网络的地址段必须基于内网地址, 且不应与系统路由表冲突. 这里我们给与 10.0.1.0/24 这一段的地址. 由于博主在建立这条 WireGuard VPN 网络前, 还早已建立了一条 EasyTier 骨干网. 所以这里 IP 地址的最后 8 bit 也按照 EasyTier 骨干网段的地址给. 因此, IEPL 的地址就是 10.0.1.106, IX 前置的地址为 10.0.1.1, 个人内网网关的地址为 10.0.1.254. 设计完成后, 正式开始建立 Peer.

2.3 建立 WireGuard Peer

2.3.1 建立专线 Peer

因为 IX 类型 IEPL / IPLC 的特殊性, 这里我们需要现在专线机器上创建 WireGuard 服务端, 来让 IX 前置作为客户端接入

在专线设备上建立 WireGuard 接口

cd /etc/wireguard
vim infra-ixpeer.conf

infra-ixpeer 作为 WireGuard 接口名称, 您可以自行定义, 但注意不要太长.

在配置文件中按照这个模板进行创建

[Interface]
Address = <ipAddr>
ListenPort = <port>
PrivateKey = <privKey>
MTU = 1420

[Peer]
PublicKey = <ix_pubKey>
AllowedIPs = <vpn_net_CIDR>
PersistentKeepalive = 25

ipAddr 专线服务器 VPN 内网地址

port 专线服务器监听端口. 注意: 专线服务器的 IX 入口通常是 NAT 类型, 且只有 ~1000 个端口可以直接连接. 这里的监听端口一定要在这 ~1000 个可以直接连接的端口中选用

privKey 专线服务器 WireGuard 私钥

ix_pubKey IX 前置的 WireGuard 公钥

vpn_net_CIDR CIDR 格式的整个 VPN 内网地址段

示例配置
[Interface]
Address = 10.0.1.106/32
ListenPort = 16601
PrivateKey = ***
MTU = 1420

[Peer]
PublicKey = ***
AllowedIPs = 10.0.1.0/24
PersistentKeepalive = 25

配置开机自动启动并启动端口

systemctl enable --now wg-quick@infra-ixpeer

创建完成后可以输入 wg 来查看接口是否生效

root@NB-JPIEPL01:/etc/wireguard# wg
interface: infra-aliyun
  public key: (hidden)
  private key: (hidden)
  listening port: 16601

peer: (hidden)
  endpoint: 172.16.1.2:51132
  allowed ips: 10.0.1.0/24
  latest handshake: 57 seconds ago
  transfer: 430.17 KiB received, 119.27 KiB sent
  persistent keepalive: every 25 seconds

如果可以正常显示接口, 则证明已经生效. 至此, 专线服务器部分配置完成.

2.3.2 建立个人网关 Peer

我们自己的服务器也需要和 IX 前置进行 Peer. 但由于处于家庭宽带/普通企业宽带中的设备通常处于 NAT 环境, 因此这里作为客户端建立单向 WireGuard 连接

在个人服务器上创建 WireGuard 端口

cd /etc/wireguard
vim infra-ixpeer.conf

在配置文件中按照这个模板进行创建

[Interface]
PrivateKey = <privKey>
Address = <ipAddr>
MTU = 1420

[Peer]
PublicKey = <ix_pubKey>
Endpoint = <ix_endpoint>
AllowedIPs = <allowedIPs>
PersistentKeepalive = 25

privKey 当前服务器 WireGuard 私钥

ipAddr 当前服务器 VPN 内网地址

ix_pubKey IX 前置 WireGuard 公钥

ix_endpoint IX 前置 WireGuard 监听地址

allowedIPs 允许通过 WireGuard 接入的 IP 地址段

示例配置
[Interface]
PrivateKey = ***
Address = 10.0.1.254/32
MTU = 1420

[Peer]
PublicKey = ***
Endpoint = 10.0.64.1:51132
AllowedIPs = 10.10.64.0/24, 10.0.1.0/24
PersistentKeepalive = 25

配置开机自动启动并启动端口

systemctl enable --now wg-quick@infra-ixpeer

创建完成后可以输入 wg 来查看接口是否生效

root@X-wrt-Home:/etc/wireguard# wg
interface: jp_iepl01
  public key: (hidden)
  private key: (hidden)
  listening port: 46997

peer: (hidden)
  endpoint: 8.***.***.***:51132
  allowed ips: 10.10.64.0/24, 10.0.1.0/24
  latest handshake: 1 minute, 14 seconds ago
  transfer: 402.16 KiB received, 149.66 KiB sent
  persistent keepalive: every 25 seconds

至此, 个人网关 Peer 就配置完成了.

2.3.3 建立 IX Peer

我们的目的是要让 IX 前置作为一跳 (hop) 去为我们自己的机器提供路由, 所以这里我们使用 IX 前置作为控制平面, 来与其他设备建立 Peer.

在 IX 前置中创建 WireGuard 接口

cd /etc/wireguard
vim infra-ixpeer.conf

在配置文件中按照这个模板进行创建

[Interface]
PrivateKey = <privKey>
Address = <ipAddr>/32
ListenPort = <port>
MTU = 1420
PostUp = iptables -I FORWARD -i %i -j ACCEPT
PostUp = iptables -I FORWARD -o %i -j ACCEPT
PostDown = iptables -D FORWARD -i %i -j ACCEPT 2>/dev/null || true
PostDown = iptables -D FORWARD -o %i -j ACCEPT 2>/dev/null || true

[Peer]
PublicKey = <iepl_pubKey>
Endpoint = <iepl_endpoint>
AllowedIPs = <iepl_allowedIPs>
PersistentKeepalive = 25

[Peer]
PublicKey = <pubKey>
AllowedIPs = <allowedIPs>
PersistentKeepalive = 25

privkey 本机 WireGuard 私钥

ipAddr 本机 WireGuard 私有地址

port 本机 WireGuard 流量监听地址

iepl_pubkey IEPL 服务器 WireGuard 公钥

iepl_endpoint IEPL 服务器的 WireGuard 监听地址

iepl_allowedIPs 本机所允许的专线服务器输入 IP 地址段. 如果您只想和 IEPL 服务器做通信, 则填入专线服务器的 WireGuard 私有地址即可, 如果想让专线服务器作为路由设备, 则需要填写对应的网段. 所有 IP 地址都应符合 CIDR 格式. 本文对应的情况为后者.

pubkey 您的个人境内私有服务器/网关设备 WireGuard 公钥

allowedIPs 您的个人境内私有服务器/网关设备 WireGuard 地址

示例配置
[Interface]
PrivateKey = ***
Address = 10.0.1.1/32
ListenPort = 51132
MTU = 1420
PostUp = iptables -I FORWARD -i %i -j ACCEPT
PostUp = iptables -I FORWARD -o %i -j ACCEPT
PostDown = iptables -D FORWARD -i %i -j ACCEPT 2>/dev/null || true
PostDown = iptables -D FORWARD -o %i -j ACCEPT 2>/dev/null || true

[Peer]
PublicKey = ***
Endpoint = 114.***.***.***:16601
AllowedIPs = 10.10.64.0/24, 192.168.0.0/16, 10.0.1.106/32
PersistentKeepalive = 25

[Peer]
PublicKey = ***
AllowedIPs = 10.0.1.254/32
PersistentKeepalive = 25

配置开机自动启动并启动端口

systemctl enable --now wg-quick@infra-ixpeer

创建完成后可以输入 wg 来查看接口是否生效

root@Aliyun-SH:/etc/wireguard# wg
interface: bridge_iepl
  public key: (hidden)
  private key: (hidden)
  listening port: 51132

peer: (hidden)
  endpoint: 114.***.***.***:16601
  allowed ips: 10.10.64.0/24, 192.168.0.0/16, 10.0.1.106/32
  latest handshake: 18 seconds ago
  transfer: 120.07 KiB received, 433.36 KiB sent
  persistent keepalive: every 25 seconds

peer: (hidden)
  endpoint: 112.***.***.***:40849
  allowed ips: 10.0.1.254/32
  latest handshake: 35 seconds ago
  transfer: 151.40 KiB received, 402.07 KiB sent
  persistent keepalive: every 25 seconds

如果两个接口的 transfer 字段中 received 前有流量, 则证明通信正常. 此时可以通过 ping 命令验证通信

root@Aliyun-SH:/etc/wireguard# ping 10.0.1.106
PING 10.0.1.106 (10.0.1.106) 56(84) bytes of data.
64 bytes from 10.0.1.106: icmp_seq=1 ttl=64 time=4.53 ms
64 bytes from 10.0.1.106: icmp_seq=2 ttl=64 time=4.19 ms  
64 bytes from 10.0.1.106: icmp_seq=3 ttl=64 time=4.22 ms
64 bytes from 10.0.1.106: icmp_seq=4 ttl=64 time=4.30 ms
^C
--- 10.0.1.106 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 4.190/4.309/4.527/0.131 ms

root@Aliyun-SH:/etc/wireguard# ping 10.0.1.4
PING 10.0.1.4 (10.0.1.4) 56(84) bytes of data.
64 bytes from 10.0.1.4: icmp_seq=1 ttl=64 time=17.5 ms
64 bytes from 10.0.1.4: icmp_seq=2 ttl=64 time=17.3 ms
64 bytes from 10.0.1.4: icmp_seq=3 ttl=64 time=17.6 ms
64 bytes from 10.0.1.4: icmp_seq=4 ttl=64 time=17.4 ms
^C
--- 10.0.1.4 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 17.339/17.471/17.647/0.120 ms

可以看到, 两个 Peer 已经成功建立并正常通信. 因为博主这里是建立在网关上的, 所以可以直接使用下级设备尝试与专线服务器进行通信

两个 WireGuard Peer 建立后的 ping 测试结果

一切正常!

2.3.4 建立境外服务器间 WireGuard Peer

为了使境外服务器之间能够联通, 且不受系统路由表干扰, 这里我们需要将每个境外服务器都加入到当前的 WireGuard 网络中.

在境外其他普通服务器上创建接口

cd /etc/wireguard
vim intra-iepl.conf

按照该模板创建配置

[Interface]
PrivateKey = <privKey>
Address = <ipAddr>
ListenPort = <port>
MTU = 1450

[Peer]
PublicKey = <pubKey_iepl>
AllowedIPs = <wgNet/CIDR>, <domesticNet/CIDR>
PersistentKeepalive = 25

privKey 当前设备的 WireGuard 私钥

ipAddr 当前设备的 WireGuard 内网地址

port 当前设备的 WireGuard 监听端口

pubKey_iepl 专线服务器的 WireGuard 公钥

wgNet/CIDR CIDR 格式的 WireGuard 网段

domesticNet/CIDR CIDR 格式的境内代理网段

示例配置
[Interface]
PrivateKey = ...
Address = 10.0.1.103
ListenPort = 51132
MTU = 1450

[Peer]
PublicKey = ...
AllowedIPs = 10.0.1.0/24, 192.168.1.0/24
PersistentKeepalive = 25

启动该端口

systemctl enable --now wg-quick@intra-iepl

如果没有报错则启动完成

在专线服务器的 intra-ixpeers.conf 中添加配置

[Peer]
PublicKey = <pubKey_global>
Endpoint = <ipAddr_global>:<port>
AllowedIPs = <ipAddr_wg>/32
PersistentKeepalive = 25

pubKey_global 先前配置的境外服务器的 WireGuard 公钥

ipAddr_global 先前配置的境外服务器的公网 IP 地址, 可以是域名

port 先前配置的境外服务器的 WireGuard 监听地址

ipAddr_wg 先前配置的境外服务器的 WireGuard 内网地址

示例配置
[Peer]
PublicKey = ...
Endpoint = v4.sb1.jp.nanami.tech:51132
AllowedIPs = 10.0.1.103/32
PersistentKeepalive = 25

重启接口

systemctl restart wg-quick@intra-ixpeers

重启后检查连通性

root@NB-JPIEPL01:/etc/wireguard# ping 10.0.1.103
PING 10.0.1.103 (10.0.1.103) 56(84) bytes of data.
64 bytes from 10.0.1.103: icmp_seq=1 ttl=64 time=29.0 ms
64 bytes from 10.0.1.103: icmp_seq=2 ttl=64 time=28.8 ms
64 bytes from 10.0.1.103: icmp_seq=3 ttl=64 time=28.9 ms
64 bytes from 10.0.1.103: icmp_seq=4 ttl=64 time=28.8 ms
64 bytes from 10.0.1.103: icmp_seq=5 ttl=64 time=29.1 ms
^C
--- 10.0.1.103 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4007ms
rtt min/avg/max/mdev = 28.780/28.904/29.060/0.098 ms

至此, 设备连接完成.

注意: 这样的操作在添加的每一台设备添加时都需要执行.

3. 建立 OSPF Peer

3.1 安装 BIRD

既然我们的目的是将专线服务器作为中转来连接我们境外的其他服务器, 那么我们就需要将这台专线服务器配置成一台路由器, 来帮我们转发业务流量. 这里我们使用 BIRD v2 来将其配置为路由器.

您需要在您的私人服务器/网关和专线服务器上安装 BIRD

使用这几条指令安装最新版本 BIRD v2

sudo apt update && sudo apt -y install apt-transport-https ca-certificates wget lsb-release
sudo wget -O /usr/share/keyrings/cznic-labs-pkg.gpg https://pkg.labs.nic.cz/gpg

echo "deb [signed-by=/usr/share/keyrings/cznic-labs-pkg.gpg] https://pkg.labs.nic.cz/bird2 $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/cznic-labs-bird2.list

sudo apt update && sudo apt install bird2 -y

指令转载至 DN42 探究日记 - Ep.2 通过 OSPF 搭建内部网络并启用 iBGP - iYoRoy Blog

输入这条指令验证安装

bird --version

示例输出

root@NB-JPIEPL01:/etc/bird# bird --version
BIRD version 2.19.1

如果没有报错, 则安装结束

3.2 配置专线服务器

备份核心配置文件并创建新配置

cd /etc/bird
mv bird.conf bird.conf.bak
vim bird.conf

按照如下示例创建配置

log syslog all;

define ROUTER_ID                = <routerID>;
define INTRA_OWNAS              = <ownAS>;
define INTRA_OWNIP              = <ownIP>;
define INTRA_OWNNET             = <ownNet/CIDR>;
define INTRA_OWNSET             = [ <ownSet/CIDR+> ];

protocol device {
    scan time 10;
};

protocol direct {
    ipv4;
    ipv6;
};

include "kernel.conf";
include "ospf.conf";

routerID 该服务器运行在所有协议中的 Router ID

ownAS 该服务器的 AS Number. 因为此处我们配置的是内网而非 IANA/DN42, 所以我们这里需要填写私有 ASN. 私有 ASN 的范围是 64512-65534, 在这里取用即可.

ownIP 该服务器在您想代理的网段中的 IP. 在本文的环境中, 我们填写这台服务器在境外 VPN 骨干网的 IP 地址.

ownNet/CIDR 您所填写的 IP 地址的整个网段. 在本文的环境中, 我们填写整个境外 VPN 骨干网的 IP 地址段.

ownSet/CIDR+ 您所想引入的所有网段. 这里需要填写您未来会引入的所有地址段信息.

在 BIRD 配置文件中, define 用于声明全局变量, 故这里的 INTRA_OWNAS, INTRA_OWNIP 等字段均为全局变量, 在其他的配置文件中均可调用 bird.conf 为 BIRD 主要配置文件, BIRD 启动时只会读取这里的配置信息. include 则用于在该文件中引入其他配置文件. 因此 kernel.conf, ospf.conf 均为引入的文件.

示例配置
log syslog all;

define ROUTER_ID                = 10.10.64.106;
define INTRA_OWNAS              = 65534;
define INTRA_OWNIP              = 10.10.64.106;
define INTRA_OWNNET             = 10.10.64.0/24;
define INTRA_OWNSET             = [ 192.168.1.0/24+, 192.168.20.0/24+, 10.0.64.0/24+, 10.10.64.0/24+ ];

protocol device {
    scan time 10;
};

protocol direct {
    ipv4;
    ipv6;
};

include "defs.conf";
include "ospf.conf";

保存后, 在相同目录下创建 defs.conf, 写入如下内容

function is_intra_net4() {
  return net ~ INTRA_OWNSET;
}

保存后, 在相同目录下创建 ospf.conf, 写入如下内容

protocol ospf v2 ospf_intra {
    router id ROUTER_ID;
    ipv4 {
        import where is_intra_net4();
        export filter {
                if source = RTS_DEVICE && net ~ <ipAddr/CIDR> then accept;
                reject;
        };
    };

    include "/etc/bird/ospf/*";
};

ipAddr/CIDR 境内私人服务器/网关所代理的网段

创建 OSPF 配置文件夹和 Area 0 的配置文件

mkdir ospf
vim ospf/0.conf

按照以下模板写入配置

area 0.0.0.0 {
    interface "intra-ixpeers" {
        type ptmp;
        ttl security tx only;
        neighbors {
            <ipAddr_domestic>;
        };
    };
}

ipAddr_domestic 境内私人服务器/网关的 WireGuard 地址

应用配置

birdc c

如果得到如下输出, 则应用成功

BIRD 2.19.1 ready.
Reading configuration from /etc/bird/bird.conf
Reconfiguration in progress

此时查看具体协议状态

birdc s p

得到如下输出

BIRD 2.19.1 ready.
Name       Proto      Table      State  Since         Info
device1    Device     ---        up     2026-07-07    
direct1    Direct     ---        up     2026-07-07    
kernel_v4  Kernel     master4    up     2026-07-07    
kernel_v6  Kernel     master6    up     2026-07-07    
ospf_intra OSPF       master4    up     2026-07-16    Alone

可以看到此时 OSPF 的状态为 Alone, 这是因为目前只有这一台设备在运行 OSPF, 还没有其他 Peer. 所以下一步我们来配置境内服务器/网关的 OSPF.

3.3 配置境内服务器/网关

备份核心配置文件并创建新配置

cd /etc/bird
mv bird.conf bird.conf.bak
vim bird.conf

按照如下示例创建配置

log syslog all;

define ROUTER_ID                = <routerID>;
define INTRA_OWNAS              = <ownAS>;
define INTRA_OWNIP              = <ownIP>;
define INTRA_OWNNET             = <ownNet/CIDR>;
define INTRA_OWNSET             = [ <ownSet/CIDR+> ];

protocol device {
    scan time 10;
};

protocol direct {
    ipv4;
    ipv6;
};

include "kernel.conf";
include "ospf.conf";

示例配置

log syslog all;

define ROUTER_ID                = 10.0.64.254;
define INTRA_OWNAS              = 65534;
define INTRA_OWNIP              = 192.168.1.1;
define INTRA_OWNNET             = 192.168.1.0/24;
define INTRA_OWNSET             = [ 192.168.1.0/24+, 192.168.20.0/24+, 10.0.64.0/24+, 10.10.64.0/24+ ];

protocol device {
    scan time 10;
};

protocol direct {
    ipv4;
    ipv6;
};

include "kernel.conf";
include "defs.conf";
include "ospf.conf";

保存后, 在相同目录下创建 defs.conf, 写入如下内容

function is_intra_net4() {
  return net ~ INTRA_OWNSET;
}

保存后, 在相同目录下创建 ospf.conf, 写入如下内容

protocol ospf v2 ospf_intra {
    router id ROUTER_ID;
    ipv4 {
        import where is_intra_net4();
        export filter {
                if source = RTS_DEVICE && net ~ <ipAddr/CIDR> then accept;
                reject;
        };
    };

    include "/etc/bird/ospf/*";
};

ipAddr/CIDR 境内私人服务器/网关所代理的网段

创建 OSPF 配置文件夹和 Area 0 的配置文件

mkdir ospf
vim ospf/0.conf

按照以下模板写入配置

area 0.0.0.0 {
    interface "intra-ixpeers" {
        type ptmp;
        ttl security tx only;
        neighbors {
            <ipAddr_domestic>;
        };
    };
}

ipAddr_domestic 境内私人服务器/网关的 WireGuard 地址

应用配置

birdc c

如果得到如下输出, 则应用成功

BIRD 2.19.1 ready.
Reading configuration from /etc/bird/bird.conf
Reconfiguration in progress

此时查看具体协议状态

birdc s p

得到如下输出

BIRD 2.19.1 ready.
Name       Proto      Table      State  Since         Info
device1    Device     ---        up     2026-07-07    
direct1    Direct     ---        up     2026-07-07    
kernel_v4  Kernel     master4    up     2026-07-07    
kernel_v6  Kernel     master6    up     2026-07-07    
ospf_intra OSPF       master4    up     2026-07-16    Running

可以看到, 此时 OSPF 协议状态为 Running, 则表明成功与境外专线服务器建立 Peer. 此时双方的配置均已完成.

4. 测试

在境外专线服务器对境内设备进行联通测试

root@NB-JPIEPL01:~# ping 192.168.1.4
PING 192.168.1.4 (192.168.1.4) 56(84) bytes of data.
64 bytes from 192.168.1.4: icmp_seq=1 ttl=62 time=24.5 ms
64 bytes from 192.168.1.4: icmp_seq=2 ttl=62 time=24.1 ms
64 bytes from 192.168.1.4: icmp_seq=3 ttl=62 time=24.4 ms
64 bytes from 192.168.1.4: icmp_seq=4 ttl=62 time=24.4 ms
64 bytes from 192.168.1.4: icmp_seq=5 ttl=62 time=24.7 ms
^C
--- 192.168.1.4 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 24.087/24.400/24.713/0.199 ms

在境内服务器对境外设备进行联通测试

root@X-wrt-Home:/etc/wireguard# ping 10.0.1.103
PING 10.0.1.103 (10.0.1.103): 56 data bytes
64 bytes from 10.0.1.103: seq=0 ttl=62 time=53.015 ms
64 bytes from 10.0.1.103: seq=1 ttl=62 time=53.352 ms
64 bytes from 10.0.1.103: seq=2 ttl=62 time=53.052 ms
64 bytes from 10.0.1.103: seq=3 ttl=62 time=53.209 ms

--- 10.0.1.103 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 53.015/53.157/53.352 ms

可以看到, 两边都成功联通并稳定. 至此, 配置全部结束

后记

本人非专业人员, 如有疏漏或错误请指出! 感谢您的阅读!

EasyTier 参数导致 iBGP 崩溃排查

Thu, 28 May 2026 11:43:00 GMT

前言

博主某天在查看自己 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-Sub

root@VM-Sub:/etc/bird/ibgp# birdc show status | grep "Router ID"
Router ID is 172.23.66.97

JPSB01

root@JPSB01:~# birdc show status | grep "Router ID"
Router ID is 45.xxx.xxx.xxx

可以明显看出, 双方 Router ID 不同, 故不是此问题

Peer IP 地址不匹配

现在对双方在配置文件中的 Peer IP 进行检查

VM-Sub

root@VM-Sub:/etc/bird/ibgp# cat sb1-jp.conf 
protocol bgp 'ibgp_sb1-jp' from ibgpeers{
    neighbor 10.0.64.103 as DN42_OWNAS;
};

JPSB01

root@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 打开该文件查看报文

Wireshark 中抓取的 BGP 179 端口报文

这就是具体抓到的数据包. 现在我们过滤所有 eBGP 报文, 仅查看需要检查的两个 iBGP Peer 之间的报文. 使用这个过滤器

ip.addr == 10.0.64.4 && ip.addr == 10.0.64.103

过滤两个 iBGP Peer 之间的报文

在这份数据包中我们可以看到, 10.0.64.4 多次尝试向 10.0.64.103 发送 OPEN 报文, 但最终会被 10.0.64.4 发送 RST 报文, 整个连接被重置, 最终导致 BIRD 报错 Connection closed.

现在, 我们重新在 10.0.64.103 上进行抓包, 结果如下

在 10.0.64.103 上抓取到的 TCP 重置报文

可以看到, 无论是 10.0.64.4 还是 10.0.64.60, 均只对对方的 TCP 报文进行了处理, 没有任何 BGP 层的处理. 这很奇怪, 如果问题出现在 BGP 层, 那么应该由其中一方发送 BGP Notification 报文来终止连接, 而不是 TCP Reset.

鉴于这个问题是突然出现的, 所以我们来审视一下问题出现的前后, 我都对网络做了什么改动. 回想了一下, 在这期间我对网络做的唯一改动就是 将 EasyTier VPN 的部署从 直接在 systemd 服务中将具体配置参数输入给 EasyTier 二进制程序 改为了 通过将具体配置写进配置文件再送给 EasyTier 处理. 在配置文件中, 我多加上了这么几条参数

[flags]
enable_kcp_proxy = true
enable_quic_proxy = true
latency_first = true
private_mode = true

我们逐个检查这些 flag 会实现什么功能

enable_kcp_proxy 启用 KCP 代理. 将 TCP 连接使用 KCP 协议进行代理

该功能虽然会改变 TCP 流量的传输方式, 但不改变原始 TCP 报文, 所以不会造成影响.

enable_quic_proxy 启用 QUIC 代理. 将 TCP 连接使用 QUIC 协议进行代理

该功能虽然会改变 TCP 流量的传输方式, 但不改变原始 TCP 报文, 所以不会造成影响.

latency_first 延迟优先. 无视 TTL 跳数, 始终优先使用延迟最短的路径转发流量

该功能虽然达到了最小延迟的目的, 但可能会增加 TTL 跳数. 从上面的配置文件可以看出, 配置里并没有单独配置 max-hop, 这可能造成连接失败.

我们来测试一下双方互通的跳数

10.0.64.4

traceroute to 10.0.64.60 (10.0.64.60), 30 hops max, 60 byte packets
 1  10.0.64.60 (10.0.64.60)  14.478 ms  14.476 ms  14.463 ms

10.0.64.60

traceroute to 10.0.64.4 (10.0.64.4), 30 hops max, 60 byte packets
 1  10.0.64.4 (10.0.64.4)  13.845 ms  14.444 ms  14.378 ms

这里可以看到, 两台机器虽然均开启了 latency_first, 但双方的跳数仍为 1, 不会造成 iBGP 故障. 但保险起见, 我们还是把这项功能关掉.

private_mode 隐私模式. 不允许任何非相同网络的节点使用该节点建立连接或转发流量

顾名思义, 这项功能是为了防止外部未知设备在未经允许的情况下借助这个节点进行 VPN 网络搭建或流量转发, 但在我查询 AI 后, 它告诉我

Root cause: EasyTier's private_mode with KCP/QUIC proxy rewrites the source IP of incoming BGP connections to
  10.0.64.60 (this machine's own tunnel IP). BIRD rejects these because it only knows about neighbor
  10.0.64.4. The same issue likely affects 10.0.64.4 in reverse, so both directions fail.

底层原因: EasyTier 的 private_mode 通过 KCP/QUIC 代理时会 重写连入 BGP 连接的源 IP 地址 到 10.0.64.60 (这台机器的私有隧道 IP). BIRD 拒绝了这些连接, 因为它只知道邻居的地址 10.0.64.4. 相同的问题也影响了 10.0.64.4, 故两边均失败了.

EasyTier 改写 BGP 连接源 IP 的示意

由此我们可以得知, 当某一方的 BGP 连接传入时, EasyTier 会先将 IP 数据包中的 源 IP 地址 改为本机隧道地址, 然后再被 BIRD 接收.

为了验证是不是为这个问题, 我们在 10.0.64.60 中查看 BIRD 的日志

root@SchoolNode-Main:/home/nanami114/PersonalFiles/easytier/configs# journalctl -xeu bird
Jun 04 17:50:58 SchoolNode-Main bird[2383741]: BGP: Unexpected connect from unknown address 10.0.64.60 (port 39138)
Jun 04 17:51:03 SchoolNode-Main bird[2383741]: BGP: Unexpected connect from unknown address 10.0.64.60 (port 56654)
Jun 04 17:51:07 SchoolNode-Main bird[2383741]: BGP: Unexpected connect from unknown address 10.0.64.60 (port 56670)
Jun 04 17:51:11 SchoolNode-Main bird[2383741]: BGP: Unexpected connect from unknown address 10.0.64.60 (port 56676)
Jun 04 17:51:15 SchoolNode-Main bird[2383741]: BGP: Unexpected connect from unknown address 10.0.64.60 (port 44306)
Jun 04 17:51:19 SchoolNode-Main bird[2383741]: BGP: Unexpected connect from unknown address 10.0.64.60 (port 44320)
Jun 04 17:51:23 SchoolNode-Main bird[2383741]: BGP: Unexpected connect from unknown address 10.0.64.60 (port 38916)
Jun 04 17:51:27 SchoolNode-Main bird[2383741]: BGP: Unexpected connect from unknown address 10.0.64.60 (port 38924)
Jun 04 17:51:31 SchoolNode-Main bird[2383741]: BGP: Unexpected connect from unknown address 10.0.64.60 (port 38930)
Jun 04 17:51:35 SchoolNode-Main bird[2383741]: BGP: Unexpected connect from unknown address 10.0.64.60 (port 37640)
Jun 04 17:51:40 SchoolNode-Main bird[2383741]: BGP: Unexpected connect from unknown address 10.0.64.60 (port 37656)
Jun 04 17:51:44 SchoolNode-Main bird[2383741]: BGP: Unexpected connect from unknown address 10.0.64.60 (port 48124)
Jun 04 17:51:49 SchoolNode-Main bird[2383741]: BGP: Unexpected connect from unknown address 10.0.64.60 (port 48128)
Jun 04 17:51:53 SchoolNode-Main bird[2383741]: BGP: Unexpected connect from unknown address 10.0.64.60 (port 55374)
Jun 04 17:51:58 SchoolNode-Main bird[2383741]: BGP: Unexpected connect from unknown address 10.0.64.60 (port 55388)
Jun 04 17:52:02 SchoolNode-Main bird[2383741]: BGP: Unexpected connect from unknown address 10.0.64.60 (port 39252)
Jun 04 17:52:07 SchoolNode-Main bird[2383741]: BGP: Unexpected connect from unknown address 10.0.64.60 (port 39266)
Jun 04 17:52:11 SchoolNode-Main bird[2383741]: BGP: Unexpected connect from unknown address 10.0.64.60 (port 39270)
Jun 04 17:52:15 SchoolNode-Main bird[2383741]: BGP: Unexpected connect from unknown address 10.0.64.60 (port 33950)
Jun 04 17:52:20 SchoolNode-Main bird[2383741]: BGP: Unexpected connect from unknown address 10.0.64.60 (port 33964)
Jun 04 17:52:24 SchoolNode-Main bird[2383741]: BGP: Unexpected connect from unknown address 10.0.64.60 (port 59404)
...

可以从日志中看到, BIRD 对 10.0.64.60 传入的连接进行了大量的报错, 由此我们得知, 问题就出在这里!

现在我们将这项功能关掉, 然后再次查看连接状态

root@SchoolNode-Main:/home/nanami114/PersonalFiles/easytier/configs# birdc s p
BIRD 2.18.1 ready.
Name       Proto      Table      State  Since         Info
device1    Device     ---        up     17:15:38.915  
kernel_v4  Kernel     master4    up     17:15:38.915  
kernel_v6  Kernel     master6    up     17:15:38.915  
dn42_static_v4 Static     master4    up     17:15:38.915  
dn42_static_v6 Static     master6    up     17:15:38.915  
dn42_rpki_akix RPKI       ---        up     17:15:39.962  Established
ospf_dn42  OSPF       master4    up     17:15:38.915  Alone
ospf_dn42_v6 OSPF       master6    up     17:15:38.915  Alone
ibgp_homelab-subserver BGP        ---        up     17:54:48.504  Established

可以看到, 此时 iBGP 已经处于了 Established 状态. 至此, 问题全部解决.

结语

本人非专业网络运维, 如有错误或疏漏还请指出! 如果觉得文章不错, 还请分享给有需要的人, 感谢!

EasyTier 与 mwan3: VPN 回程路由修复

Wed, 27 May 2026 02:48:00 GMT

前言

博主使用了 EasyTier 在家, 学校, 境内外公网服务器之间通过 WireGuard 协议建立了一个三层 VPN 网络. 平日里在学校或出门在外都会通过这个 VPN 网络连接家里的设备, 访问家里搭建的业务. 在博主今天尝试在学校连接家里服务器上的 SMB 时, 发现全部连接失败, 故着手研究原因.

网络拓扑架构

Topology

在 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-lan proto kernel scope link src 192.168.20.1 
192.168.20.0/24 dev br-lan proto bird scope link metric 32 
192.168.100.0/24 dev tun0 proto static metric 65535

可以看到, 192.168.1.0/24 正常从 tun0 出口

然后检查 HomeLab 节点中设备的路由表

nanami114@NanamiWork-Server:~$ ip rou
default via 192.168.1.1 dev vmbr0 proto kernel onlink 
10.0.64.0/24 dev tun0 proto static metric 65535 
10.10.64.0/24 dev tun0 proto static metric 65535 
192.168.1.0/24 dev vmbr0 proto kernel scope link src 192.168.1.8 
192.168.3.0/24 dev tun0 proto static metric 65535 
192.168.20.0/24 dev tun0 proto static metric 65535 
192.168.100.0/24 dev tun0 proto static metric 65535

可以看到这里也是正常的, 因此该原因被排除

2. 反向路径过滤 `(rp_filter)` 导致回包被丢弃

这里直接检查校园网关的 rp_filter 策略

root@X-wrt-School:~# sysctl net.ipv4.conf.all.rp_filter
net.ipv4.conf.all.rp_filter = 0
root@X-wrt-School:~# sysctl net.ipv4.conf.tun0.rp_filter
net.ipv4.conf.tun0.rp_filter = 0
root@X-wrt-School:~# sysctl net.ipv4.conf.br-lan.rp_filter
net.ipv4.conf.br-lan.rp_filter = 0

可以看到, 所有相关网络接口的 rp_filter 均为 0, 证明这里没有问题, 故排除该原因

3. IP 转发未开启

首先网关本身使用的系统为 OpenWrt, 该系统为专业的软路由系统, 因此可以直接排除该原因. 但为了严谨, 这里还是检查一下

root@X-wrt-School:~# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

4. EasyTier 的出口策略 / 策略路由冲突

在第一项检查中我们可以看到, 路由表中存在多个 pppoe-wan, 说明这是一个多拨的网络环境. 因此可能造成下游流量在转发时被路由策略规则劫持, 导致回包走到了错误的物理接口, 而非回到 tun0.

root@X-wrt-School:~# ip rule show
0:      from all lookup local
1001:   from all iif pppoe-wan lookup 1
1002:   from all iif pppoe-xwan01 lookup 2
1003:   from all iif pppoe-xwan02 lookup 3
1004:   from all iif pppoe-xwan03 lookup 4
1005:   from all iif pppoe-xwan04 lookup 5
2001:   from all fwmark 0x100/0x3f00 lookup 1
2002:   from all fwmark 0x200/0x3f00 lookup 2
2003:   from all fwmark 0x300/0x3f00 lookup 3
2004:   from all fwmark 0x400/0x3f00 lookup 4
2005:   from all fwmark 0x500/0x3f00 lookup 5
2061:   from all fwmark 0x3d00/0x3f00 blackhole
2062:   from all fwmark 0x3e00/0x3f00 unreachable
32766:  from all lookup main
32767:  from all lookup default

通过这条输出, 我们可以注意到:

下游设备 192.168.20.x → 网关 → 匹配 main 路由表走 tun0 → VPN → 192.168.1.y (正常发出)
回包到达网关 tun0 后, 内核会进行路由查找. 此时, 如果回包被打上了某个 fwmark (例如 0x100), 就会命中规则 2001: from all fwmark 0x100/0x3f00 lookup 1, 从而使用路由表 1 进行转发.

这里我们查看路由表 1 的具体路由信息

root@X-wrt-School:~# ip route show table 1
default via 10.131.0.1 dev pppoe-wan metric 40 
10.0.64.0/24 dev tun0 proto kernel scope link src 10.0.64.253 metric 256 
10.0.64.0/24 dev tun0 proto static scope link metric 65535 
10.10.64.0/24 dev tun0 proto static scope link 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 metric 3 
10.141.0.1 dev pppoe-xwan03 proto kernel scope link src 10.141.40.183 metric 4 
10.151.0.1 dev pppoe-xwan01 proto kernel scope link src 10.151.10.205 metric 2 
10.151.0.1 dev pppoe-xwan04 proto kernel scope link src 10.151.32.226 metric 5 
169.254.0.0/16 dev br-lan proto kernel scope link src 169.254.254.254 metric 256 
192.168.1.0/24 dev tun0 proto static scope link metric 65535 
192.168.3.0/24 dev tun0 proto static scope link metric 65535 
192.168.20.0/24 dev br-lan proto bird scope link metric 32 
192.168.20.0/24 dev br-lan proto kernel scope link src 192.168.20.1 metric 256 
192.168.100.0/24 dev tun0 proto static scope link metric 65535

从输出的路由表信息来看, 已经存在去往 192.168.20.0/24 的正确路由, 这说明单纯的回程缺失已经被排除. 但下游设备无法通信, 此时问题大概率出现在连接跟踪表记 (conntrack) 与防火墙过滤的联合作用上.

首先我们查看 OpenWrt 的防火墙配置

OpenWrt 防火墙中 EasyTier 接口的出入站配置

可以看到, EasyTier 接口的出入配置都是正确且有效的, 那么接下来我们对问题进行深入分析与排查

深入分析

`mwan3` 的标记机制

mwan3 会在 mangle 表的 PREROUTING 和 OUTPUT 中挂载 mwan3_hook. 核心逻辑如下

CONNMARK restore: 恢复连接上保存的标记 (fwmark).
如果恢复后标记为 0, 则根据入接口 (mwan3_ifaces_in) 或策略 (mwan3_rules) 打上新标记, 最后 CONNMARK save, 将标记保存到连接跟踪里.
此后所有属于该连接的包都会自动被还原相同标记, 并通过 ip rule 的 fwmark 匹配, 强制走对应的路由表 (如 table 1~5).

当前链路存在的问题

当 192.168.20.x 首次访问 192.168.1.x 时

出站 (br-lan → 网关 → tun0): 该包在 PREROUTING 或 OUTPUT 链被 mwan3 打上某个标记 (例如 0x100), 并 CONNMARK save 保存.
回包 (tun0 → 网关 → 应回到 br-lan): 回包进入 PREROUTING → mwan3_hook → CONNMARK restore 直接将标记恢复为 0x100. 由于标记非零, 后续 mwan3_ifaces_in 等链都被跳过 (它们要求 mark match 0x0/0x3f00). 回包带着 0x100 进入路由查找, 命中 ip rule 中的 2001: from all fwmark 0x100/0x3f00 lookup 1, 使用 table 1 转发.

尽管 table 1 有去往 192.168.20.0/24 的直连路由, 理论上可以通, 但实际环境中常被以下两种隐形过滤阻断:

filter 表 FORWARD 链的状态跟踪丢弃大多数 OpenWrt 默认防火墙 FORWARD 链允许 ESTABLISHED ,RELATED 状态, 丢弃 INVALID. 当回包带着被强制改变的路由标记走过路由后, 连接跟踪可能将其状态标记为 INVALID (因为出方向走的是 main 表或不同的路由表, 回包却走 table 1, 属于非对称路由, conntrack 可能视其为无效), 随后被 FORWARD 链丢弃.
反向路径校验 (即使 rp_filter=0 仍有其他机制) 某些内核版本在策略路由下仍会做额外的路径校验, 或者 secure_redirects 等参数造成丢弃. 但更常见的是第 1 点.

因此, 即使路由存在, 包也可能在送到 br-lan 之前就被 filter 规则或 conntrack 剔除.

故障修复

快速恢复

最快且最可靠的办法是让回包不再经过 FORWARD 转发路径, 而是直接进网关本机. 将下游设备的源地址伪装为网关 VPN 接口的地址即可.

iptables -t nat -A POSTROUTING -s 192.168.20.0/24 -o tun0 -j MASQUERADE

执行完后看效果:

C:\Users\Nanami114>ping 192.168.1.4

Pinging 192.168.1.4 with 32 bytes of data:
Reply from 192.168.1.4: bytes=32 time=11ms TTL=63
Reply from 192.168.1.4: bytes=32 time=11ms TTL=63
Reply from 192.168.1.4: bytes=32 time=11ms TTL=63
Reply from 192.168.1.4: bytes=32 time=12ms TTL=63

Ping statistics for 192.168.1.4:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 11ms, Maximum = 12ms, Average = 11ms

C:\Users\Nanami114>ping 192.168.1.8

Pinging 192.168.1.8 with 32 bytes of data:
Reply from 192.168.1.8: bytes=32 time=7ms TTL=63
Reply from 192.168.1.8: bytes=32 time=7ms TTL=63
Reply from 192.168.1.8: bytes=32 time=7ms TTL=63
Reply from 192.168.1.8: bytes=32 time=7ms TTL=63

Ping statistics for 192.168.1.8:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 7ms, Maximum = 7ms, Average = 7ms

可以看到, 此时下游设备已经可以正常收到对端设备 ICMP Ping 的回包. 接下来查看业务流量状态:

SMB

这里可以看到, 此时 SMB 流量已经可以正常通讯, 说明整个网络链路已经恢复, 下游设备恢复了与 192.168.1.0/24 段的正常通讯.

当然, 这个方法虽然恢复快速但也存在不妥:

所有下游设备去往 192.168.1.0/24 的通讯, 都会被目标设备识别为 10.0.64.253 在与其通信, 也就是校园网关在与其通信. 为了解决这个问题, 下面我们进行深度修复.

根因修复: 调整 `mangle` 规则, 避免 VPN 回程路由被标记

精准修复命令在 mwan3_hook 中 CONNMARK save 之前插入一条规则: 如果包是从 tun0 进入且目标是 192.168.20.0/24, 则将其标记清零, 并让 conntrack 保存清零后的标记. 这样该连接后续流量将不再受多线策略影响.

首先查看 mwan3_hook 接口编号

root@X-wrt-School:~# iptables -t mangle -L mwan3_hook --line-numbers
Chain mwan3_hook (2 references)
num  target     prot opt source               destination         
1    CONNMARK   all  --  anywhere             anywhere             mark match 0x0/0x3f00 CONNMARK restore mask 0x3f00
2    mwan3_ifaces_in  all  --  anywhere             anywhere             mark match 0x0/0x3f00
3    mwan3_local  all  --  anywhere             anywhere             mark match 0x0/0x3f00
4    mwan3_rules  all  --  anywhere             anywhere             mark match 0x0/0x3f00
5    mwan3_connected  all  --  anywhere             anywhere            
6    CONNMARK   all  --  anywhere             anywhere             CONNMARK save mask 0x3f00

可以看到 mwan3_connected 是第五条, CONNMARK save 是第六条. 我们需要在这两条之间插入标记清零的规则

iptables -t mangle -I mwan3_hook 6 -i tun0 -d 192.168.20.0/24 -j MARK --set-mark 0

mwan3_hook 链中插入的 mangle 规则

这里可以看到, 刚才插入的规则已经生效. 此时看下游设备效果. 这里使用下游设备连接对端物理设备的 SSH, 连接两次即可在终端内看到上一次连接的 IP 地址.

Linux NanamiWork-Server 7.0.0-3-pve #1 SMP PREEMPT_DYNAMIC PMX 7.0.0-3 (2026-04-21T22:56Z) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed May 27 16:19:00 2026 from 192.168.20.2
nanami114@NanamiWork-Server:~$

可以看到, 这里显示 Last login: Wed May 27 16:19:00 2026 from 192.168.20.2, 证明改动已经生效, 并已经恢复了与目标设备的连接. 至此, 整个 VPN 网络的修复就已完成.

后记

本人非专业网络运维, 如有疏漏或错误, 还请指出! 如果您觉得文章不错, 还请分享给有需要的

journald 日志过多导致磁盘 I/O 爆炸排查

Fri, 22 May 2026 08:00:00 GMT

前言

博主在使用自己开发的 super-frpc 项目时, 注意到每次程序启动的时候, 磁盘 I/O 都会被占满. 一开始博主以为是被攻击, 后面使用 htop 查询发现, 占用量最大的进程分别为 systemctl status superfrpc_* 和 journalctl -u superfrpc_* -n 50 --no-pager. 这两者的相同点是都会读取最近日志. 因此引出了本篇文章所需要解决的问题.

故障分析

为什么 `systemctl status` 也会造成大量 I/O 开销

systemctl status 造成大量磁盘 I/O 时的 htop 截图

首先, systemctl status * 并不会直接造成大量磁盘 I/O, 但是它会执行下面这些隐藏动作:

查询 unit 状态
读取最近日志 (journalctl)
显示最近几十行 stdout / stderr
解析 cgroup / PID / 状态信息

也就是说, 实际上 systemctl status * 隐式执行了

journalctl -u superfrpc_*.service -n 10

为什么 `journalctl` 查询日志会造成大量 I/O 开销

众所周知, 正常情况下查询 systemd 服务日志应当是一瞬间的事情. 但如果你的日志符合以下任意一条特征:

该服务日志量巨大
日志没有被 rotate
journal 文件非常大
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@cda8f901ce914c2ba110f7e17205bc58-0000000000f6d8ba-000650eb1f09e7db.journal (77.7M).
Deleted archived journal /var/log/journal/e2bc53213dbb447bab4d9898e22776fa/user-1000@cda8f901ce914c2ba110f7e17205bc58-0000000000f6daa3-000650eb2316285c.journal (3.6M).
Deleted archived journal /var/log/journal/e2bc53213dbb447bab4d9898e22776fa/system@cda8f901ce914c2ba110f7e17205bc58-0000000000f94f56-000650f2434e1d58.journal (80.5M).
Deleted archived journal /var/log/journal/e2bc53213dbb447bab4d9898e22776fa/system@cda8f901ce914c2ba110f7e17205bc58-0000000000fbc5fb-000650fa9502ddda.journal (78.6M).
Deleted archived journal /var/log/journal/e2bc53213dbb447bab4d9898e22776fa/user-1000@cda8f901ce914c2ba110f7e17205bc58-0000000000fdae6c-000650ff56ec6396.journal (3.6M).
Deleted archived journal /var/log/journal/e2bc53213dbb447bab4d9898e22776fa/system@cda8f901ce914c2ba110f7e17205bc58-0000000000fe3e79-00065100649d2f0e.journal (79.3M).
Deleted archived journal /var/log/journal/e2bc53213dbb447bab4d9898e22776fa/system@cda8f901ce914c2ba110f7e17205bc58-000000000100af6d-00065109684030a0.journal (78.8M).
Deleted archived journal /var/log/journal/e2bc53213dbb447bab4d9898e22776fa/user-1000@cda8f901ce914c2ba110f7e17205bc58-000000000100b5c6-000651097e126843.journal (3.7M).
Deleted archived journal /var/log/journal/e2bc53213dbb447bab4d9898e22776fa/system@cda8f901ce914c2ba110f7e17205bc58-0000000001032883-0006511015b880a5.journal (81.9M).
Deleted archived journal /var/log/journal/e2bc53213dbb447bab4d9898e22776fa/system@cda8f901ce914c2ba110f7e17205bc58-000000000105a875-0006511658dceb30.journal (78.1M).
Deleted archived journal /var/log/journal/e2bc53213dbb447bab4d9898e22776fa/system@cda8f901ce914c2ba110f7e17205bc58-0000000001081e15-0006511f823b08c7.journal (83.9M).
Deleted archived journal /var/log/journal/e2bc53213dbb447bab4d9898e22776fa/user-1000@cda8f901ce914c2ba110f7e17205bc58-000000000108b2c0-00065121421f3acb.journal (3.6M).
...
Vacuuming done, freed 3.5G of archived journals from /var/log/journal/e2bc53213dbb447bab4d9898e22776fa.
Vacuuming done, freed 0B of archived journals from /var/log/journal.
Vacuuming done, freed 0B of archived journals from /run/log/journal.

限制 journald 日志创建大小编辑 /etc/journal/journald.conf 将 SystemMaxUse, SystemMaxFileSize, RuntimeMaxUse 这三条参数取消注释, 并按照自己的需求设置. 这里博主分别设置为 500M, 50M, 100M. 完整的配置文件如下

[Journal]
#Storage=auto
#Compress=yes
#Seal=yes
#SplitMode=uid
#SyncIntervalSec=5m
#RateLimitIntervalSec=30s
#RateLimitBurst=10000
SystemMaxUse=500M
#SystemKeepFree=
SystemMaxFileSize=50M
#SystemMaxFiles=100
RuntimeMaxUse=100M
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#RuntimeMaxFiles=100
#MaxRetentionSec=
#MaxFileSec=1month
#ForwardToSyslog=no
#ForwardToKMsg=no
#ForwardToConsole=no
#ForwardToWall=yes
#TTYPath=/dev/console
#MaxLevelStore=debug
#MaxLevelSyslog=debug
#MaxLevelKMsg=notice
#MaxLevelConsole=info
#MaxLevelWall=emerg
#LineMax=48K
#ReadKMsg=yes
#Audit=yes

保存并重启 journald

systemctl restart systemd-journald

程序代码修复

systemd 配置文件问题

造成问题的核心原因是, super-frpc 在创建 frpc 服务时, 并没有对日志方面做出任何配置. 在询问 AI 后, 得到的答复是

AI 关于 systemd 日志配置的答复

这里我们先来看一下原来的代码是怎么写的

func createSystemdService(instanceID int, configPath, runUser string) error {
	frpcPath, err := GetFrpcPath()
	if err != nil {
		return err
	}

	serviceName, err := database.GetServiceNameByInstanceID(instanceID)
	if err != nil {
		return err
	}

	serviceContent := fmt.Sprintf(`[Unit]
Description=superfrpc_%d
After=network.target

[Service]
Type=simple
ExecStart=%s -c %s
User=%s
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
`, instanceID, frpcPath, configPath, runUser)

	servicePath := filepath.Join("/etc/systemd/system", serviceName+".service")
	if err := os.WriteFile(servicePath, []byte(serviceContent), 0644); err != nil {
		return fmt.Errorf("failed to create systemd service file: %w", err)
	}

	cmd := exec.Command("systemctl", "enable", serviceName)
	if output, err := cmd.CombinedOutput(); err != nil {
		os.Remove(servicePath)
		return fmt.Errorf("failed to enable service: %s, output: %s", err, output)
	}

	cmd = exec.Command("systemctl", "daemon-reload")
	if output, err := cmd.CombinedOutput(); err != nil {
		return fmt.Errorf("failed to reload daemon: %s, output: %s", err, output)
	}

	return nil
}

在这段代码中, systemd 服务的配置文件模板为

[Unit]
Description=superfrpc_%d
After=network.target

[Service]
Type=simple
ExecStart=%s -c %s
User=%s
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

可以看到, 没有对日志做出任何配置. 这里我们添加上如下两条配置

StandardOutput=append:%s/superfrpc_%d.log
StandardError=append:%s/superfrpc_%d.log

并在程序配置文件中新增了 logsPath 这条参数, 用于单独存放 frpc 产生的日志.

日志无限增长问题

将 frpc 日志重定向到文件输出之后, 还有一个问题需要解决: 日志无限增长. systemd 自己并不会主动清理日志文件, 所以我们需要借助 logrotate 工具来对日志进行约束. 详细解决流程如下

在主进程创建首个 systemd 服务后, 创建 logrotate 配置

/etc/logrotate.d/superfrpc_frpclog

在配置中填写以下字段

/path/to/logs/superfrpc_*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    copytruncate
}

/path/to/logs/superfrpc_*.log: 匹配符合 /path/to/logs/superfrpc_*.log 的所有文件

daily: 每天进行一次 rotate

rotate 7: 保留 7 份历史日志

compress: 旧日志自动进行 gzip 压缩

delaycompress: 延迟一轮再压缩

missingok: 日志不存在也不报错

nofityempty: 空日志不归档

copytruncate: 将日志文件 inode 属性进行迁移

进行了 logrotate 配置后, 整个日志的 rotate 过程如下:

假设当前日志文件 superfrpc_8.log 的大小达到了 500MB, 则执行 rotate: Day 1:

superfrpc_8.log       # 新日志文件
superfrpc_8.log.1

到了第二天, 自动 rotate 一遍: Day 2:

superfrpc_8.log       # 新日志文件
superfrpc_8.log.1     # 延迟一轮再压缩
superfrpc_8.log.2.gz  # 被 gzip 压缩

到了第八天, 删除最开始的一条日志: superfrpc_8.log.7.gz

修改后的代码如下

创建 CreateLogrotatePolicy 函数

func CreateLogrotatePolicy() error {
	logrotatePath := "/etc/logrotate.d/superfrpc_frpclog"
	policyContent := fmt.Sprintf(`%s/superfrpc_*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
}
`, global.CurrentConfig.LogsPath)
	if err := os.WriteFile(logrotatePath, []byte(policyContent), 0644); err != nil {
		return fmt.Errorf("failed to create logrotate policy file: %w", err)
	}
	
	if err := exec.Command("logrotate", "-f", logrotatePath).Run(); err != nil {
		return fmt.Errorf("failed to apply logrotate policy: %w", err)
	}
	return nil
}

然后在程序初始化过程中调用该函数

if global.CurrentConfig.LogsPath != "" && !global.CurrentConfig.Status.IsLogrotateConfigured { // Set up logrotate policy if LogsPath is configured
	if err := sys.CreateLogrotatePolicy(); err != nil {
		postLog.Fatal(fmt.Sprintf("Failed to create logrotate policy: %v", err))
	} else {
		global.CurrentConfig.Status.IsLogrotateConfigured = true
		config.SaveConfig()
        postLog.Info("Logrotate policy has been configured successfully.")
	}
}

测试修复效果

root@VM-Sub:/home/nanami114/PersonalFiles/super-frpc# ./super-frpc 
2026/05/22 17:15:16 [frpLogger] Init.d log streamer initialized
2026/05/22 17:15:16 [frpLogger] Systemd log streamer initialized
[2026-05-22 17:15:16.541 - INFO] Super-frpc 0.0.1 (Build 1.pre-release) by Madobi Nanami
[2026-05-22 17:15:16.549 - INFO] Logs database initialized successfully
[2026-05-22 17:15:16.558 - INFO] Database initialized successfully
[2026-05-22 17:15:16.565 - INFO] Routes setup successfully
[2026-05-22 17:15:16.588 - INFO] Watchdog process watchdog_systemd is not running, starting it...
[2026-05-22 17:15:16.797 - DEBUG] [GetServiceNameByInstanceID] instanceID: 8, serviceName: superfrpc_8
[2026-05-22 17:15:16.864 - INFO] [IsInstanceRunning] Systemd service superfrpc_8 is running
[2026-05-22 17:15:16.870 - DEBUG] [GetServiceNameByInstanceID] instanceID: 8, serviceName: superfrpc_8
[2026-05-22 17:15:16.878 - DEBUG] [watchdog] Add service monitor: superfrpc_8
[2026-05-22 17:15:16.885 - DEBUG] [GetServiceNameByInstanceID] instanceID: 9, serviceName: superfrpc_9
[2026-05-22 17:15:16.903 - INFO] [IsInstanceRunning] Systemd service superfrpc_9 is running
[2026-05-22 17:15:16.909 - DEBUG] [GetServiceNameByInstanceID] instanceID: 9, serviceName: superfrpc_9
[2026-05-22 17:15:16.916 - DEBUG] [watchdog] Add service monitor: superfrpc_9
[2026-05-22 17:15:16.923 - DEBUG] [GetServiceNameByInstanceID] instanceID: 10, serviceName: superfrpc_10
[2026-05-22 17:15:16.940 - INFO] [IsInstanceRunning] Systemd service superfrpc_10 is running
[2026-05-22 17:15:16.946 - DEBUG] [GetServiceNameByInstanceID] instanceID: 10, serviceName: superfrpc_10
[2026-05-22 17:15:16.952 - DEBUG] [watchdog] Add service monitor: superfrpc_10
[2026-05-22 17:15:16.959 - DEBUG] [GetServiceNameByInstanceID] instanceID: 11, serviceName: superfrpc_11
[2026-05-22 17:15:16.976 - INFO] [IsInstanceRunning] Systemd service superfrpc_11 is running
[2026-05-22 17:15:16.982 - DEBUG] [GetServiceNameByInstanceID] instanceID: 11, serviceName: superfrpc_11
[2026-05-22 17:15:16.988 - DEBUG] [watchdog] Add service monitor: superfrpc_11
[2026-05-22 17:15:16.995 - DEBUG] [GetServiceNameByInstanceID] instanceID: 12, serviceName: superfrpc_12
[2026-05-22 17:15:17.012 - INFO] [IsInstanceRunning] Systemd service superfrpc_12 is running
[2026-05-22 17:15:17.018 - DEBUG] [GetServiceNameByInstanceID] instanceID: 12, serviceName: superfrpc_12
[2026-05-22 17:15:17.024 - DEBUG] [watchdog] Add service monitor: superfrpc_12
[2026-05-22 17:15:17.031 - INFO] [watchdog] synced 5 running instance(s) to monitor list
[2026-05-22 17:15:17.037 - INFO] Connected to Watchdog successfully
[2026-05-22 17:15:17.045 - INFO] Server starting on 0.0.0.0:7000

从日志中可以看出, 此时查询 systemctl status 的速度已经很快了, 然后查询磁盘 I/O 占用

修复后 systemctl status 与磁盘 I/O 占用情况

可以看到, 磁盘 I/O 几乎没有占用. 至此, 问题全部解决

结语

通过此次故障的发生, 我们需要加强对服务日志的管控以及对程序潜在 bug 的审查. 感谢您的阅读, 如果觉得不错, 还请分享给有需要的人, 感谢! 如有错误或疏漏, 还请指出, 感谢!

iVentoy 部署 PXE 网络启动服务器

Wed, 20 May 2026 06:17:00 GMT

前言

在做网络运维的过程中, 常常会碰到需要给各种物理机或虚拟机安装系统的情况. 以往装系统都是通过 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

启动 iVentoy

cd 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
OpenWrt dnsmasq 的 PXE/TFTP 设置页面
勾选 Enable TFTP Server (启用 TFTP 服务器)
在下方的 Special PXE boot options for Dnsmasq. 表格中点击 Add (添加) 按钮
在对话框中填入您的相关配置.
参考配置

Filename - 引导文件文件名. 填入 iVentoy 设置中的 EFI Boot File

Server name - 引导服务器名称. 随意设置

DHCP Options - DHCP 附加选项. 推荐置空

Match this Tag - 仅携带该 Tag 的 DHCP 客户端才会被引导至 PXE Server. 如无特殊需求推荐置空

Force - 总是发送选中的 DHCP 选项. 推荐置空

Instance - dnsmasq 实例. 如果网络环境为普通的单广播域家庭网络, 直接选择实例 0 即可. 其他情况请按需选择.

配置完成后单击 Save (保存)

在当前页面的 Network boot image (网络启动映像) 中填入刚才设置的 Filename. 如果您添加了不止一个 Host, 那么请填入您需要的.
全部修改完成后单击 Save & Apply (保存并应用)

测试

进入 iVentoy WebUI, 在主页中单击绿色三角按钮启动服务器
将需要安装系统的设备接入 iVentoy 所在的内网
启动设备

注: iVentoy 同时支持传统 MBR 启动和新型 UEFI 启动. 如果您选择 UEFI 启动, 请务必关闭 Secure Boot, 否则可能启动失败

如果设备中显示了 iVentoy 的启动页面, 则配置成功

iVentoy Boot

至此, iVentoy 的配置就完成了

结语

本人非专业运维, 如有错误或疏漏还请指出! 如果觉得文章有用, 请分享给有需要的人, 感谢!

Super-frpc: frpc 集群可视化管理

Wed, 13 May 2026 05:28:00 GMT

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

截图

Instance Management

Instance Detail

Proxy List

User Management

Session Management

Settings

Webhook Settings

部署

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 管理平台

Mon, 20 Apr 2026 04:18:00 GMT

前言

随着业务量的上涨与集群节点的增加, 我们使用 kubectl 命令行工具进行运维会逐渐变得困难, 并且也无法实时监测到每个节点的实时状态. 这时, 一套好用的图形化监控与运维工具就成为了我们的刚需. 这篇文章将会详细描述 Kubernetes 图形化运维工具 Rancher 的搭建与配置过程

本文章同样适用于 K8s

配置需求

可运行的 K3s/K8s Master 节点与至少一个 Worker 节点

开整

安装 Helm

Helm 是一个为 Kubernetes 开发的包管理器, 它简化了应用的部署与管理. 它使用 Helm charts, 这是一个定义了 Kubernetes 资源分配的 YAML 文件, 为自动化的安装, 升级, 管理 Kubernetes 集群应用程序而生.

个人翻译, 有错见谅, 原文如下: 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 Key

sudo 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

在 Kubernetes 中创建 Rancher 的 namespace

kubectl create namespace cattle-system

添加 cert-manager 清单文件

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/<VERSION>/cert-manager.crds.yaml

VERSION GitHub 上的版本 Tag, 需要您自己填写

添加 jetstack 软件源

helm repo add jetstack https://charts.jetstack.io

更新软件源

helm repo update

安装 cert-manager

helm 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 来读取存有 apiserver 的地址与 token 的配置文件地址, 默认地址为 ~/.kube/config *转自 CSDN

修改 /etc/profile
vim /etc/profile
在开头处写入内容 export KUBECONFIG=/etc/rancher/k3s/k3s.yaml 保存并执行
souce /etc/profile
执行完成后, 再次尝试运行安装命令, 这次应当没有报错.

如果先前有安装失败的记录, 那么重新安装可能会遇到报错 Error: INSTALLATION FAILED: cannot re-use a name that is still in use, 此时删除对应的 Secret 即可
helm -n {namespace} delete cert-manager
kubectl delete secrets -n cert-manager -l owner=helm,name=cert-manager

如果在安装时遇到了错误
Error: INSTALLATION FAILED: failed post-install: 1 error occurred:
      * timed out waiting for the condition
则是因为 cert-manager 在安装时会创建一个 Job (startupapicheck) 来校验 webhook 是否正常工作. 该校验会向 API Server 发送一个测试请求, 触发 webhook 调用, 但此时的 Webhook 配置中 caBundle 还没有被 cert-manager 的 controller 及时填上 (或者使用的是旧的/无效的 CA), 导致 API Server 连接 webhook 时证书不信任, TLS 握手失败, Job 一直重试直至 Helm 超时. 修复方法如下:

获取 CA 证书
kubectl get secret cert-manager-webhook-ca -n cert-manager -o jsonpath='{.data.ca\.crt}' | base64 -d
给两个 Webhook 注入证书
CA_BUNDLE=$(kubectl get secret cert-manager-webhook-ca -n cert-manager -o jsonpath='{.data.ca\.crt}')

kubectl patch mutatingwebhookconfiguration cert-manager-webhook --type='json' \
  -p="[{'op': 'replace', 'path': '/webhooks/0/clientConfig/caBundle', 'value':'${CA_BUNDLE}'}]"

kubectl patch validatingwebhookconfiguration cert-manager-webhook --type='json' \
  -p="[{'op': 'replace', 'path': '/webhooks/0/clientConfig/caBundle', 'value':'${CA_BUNDLE}'}]"
如果有多个 Webhook, 还可以使用循环来依次注入
for wh in mutatingwebhookconfiguration cert-manager-webhook validatingwebhookconfiguration cert-manager-webhook; do
  kubectl get $wh -o json | jq '.webhooks[].clientConfig.caBundle = "'${CA_BUNDLE}'"' | kubectl apply -f -
done
此时再次进行安装, 就不会再次出现该问题了

安装 Rancher

使用以下命令安装 Rancher

helm install rancher rancher-latest/rancher \
  --namespace cattle-system \
  --set hostname=<hostname> \
  --set replicas=1 \
  --set bootstrapPassword=<PASSWORD_FOR_RANCHER_ADMIN>

hostname 是 Ingress 监听的目标地址. 这条配置对应的是 Ingress 配置中的 host 如果这是部署在生产环境中的, 请务必将其设置为服务器域名或反向代理的目标域名.

PASSWORD_FOR_RANCHER_ADMIN 是 Rancher 管理员的密码, 需要您自行设置, 长度至少为 12 个字符

如果您的 Pod 状态处于 ImagePullBackOff, 则很可能是镜像拉取失败了. 您可以按照以下操作为 Rancher 配置镜像

Master:

cat <<EOF > /etc/rancher/k3s/registries.yaml
mirrors:
  docker.io:
   endpoint:
      - "https://docker.m.daocloud.io"
  quay.io:
    endpoint:
      - "https://quay.m.daocloud.io"
EOF
systemctl restart k3s

Worker:

mkdir /etc/rancher/k3s
cat <<EOF > /etc/rancher/k3s/registries.yaml
mirrors:
  docker.io:
   endpoint:
      - "https://docker.m.daocloud.io"
  quay.io:
    endpoint:
      - "https://quay.m.daocloud.io"
EOF
systemctl restart k3s-agent

执行完成后, 镜像拉取应该会正常

如果没有报错, 并且使用绑定的域名可以访问到 Rancher 控制台, 那么配置到此结束.

如果您不想让 Ingress 去管理反向代理, 而想使用外部的反向代理工具 (Nginx, openresty 等) 去负责反代和负载均衡, 或者您想直接使用 IP 地址: 端口的形式去进行访问, 则可以接着看下去.

暴露相关端口

Rancher 安装后默认的策略是 ClusterIP, 这种策略是无法被外部所访问的, 只能在集群内访问. 如果想使用外部的反向代理工具, 则需要将策略改为 NodePort, 并配置持久化

导出配置清单

helm get values rancher -n cattle-system -o yaml > rancher-values.yaml

进入清单文件, 在文件末尾添加这些参数

service:
  type: NodePort
  ports:
    https:
      nodePort: <httpsPort>
    http:
      nodePort: <httpPort>

httpsPort https 服务器对外暴露的端口

httpPort http 服务器对外暴露的端口

保存后, 升级 Rancher, 应用新配置

helm upgrade rancher rancher-latest/rancher \
  -n cattle-system \
  -f rancher-values.yaml

配置完成后, 使用您设置的地址在浏览器中访问, 如果能顺利进入到 Rancher 的初始化页面, 并输入您设置的默认密码进入主页, 则配置完成
Rancher

结语

本人非专业 Kubernetes 运维人员, 如有疏漏或错误, 还请指出!
如果觉得文章有帮助, 还请分享给有需要的人, 感谢!

Kubernetes: K8s Deployment 清单详解

Sat, 11 Apr 2026 03:18:00 GMT

前言

在接触 Kubernetes 运维后, 我们需要将我们编写的程序交付给 Kubernetes 进行集群化部署. 这么做的前提需要您充分的理解 Kubernetes Deployment 清单文件的含义及各个配置的作用. 本文将会带你进行了解

清单文件的四大结构

每个 Kubernetes 清单文件都有四个必填的顶层字段:

apiVersion: ...
kind: ...
metadata:
  ...
spec:
  ...

它们的含义分别为:

apiVersion 使用的 Kubernetes API 版本
kind 要创建的资源类型
metadata 资源的元数据
spec 资源的期望状态 (规约)

这是一个具体的清单文件示例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
  labels:
    app: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-container
        image: myapp:v1.0.0
        ports:
        - containerPort: 8080

`apiVersion` 与 `kind`: 资源的唯一标识

apiVersion 指定了要使用的 Kubernetes API 的版本和 API 组.
核心组 (Core Group) : 如 v1 (用于 Pod, Service 等), 它们是最基础的资源, 路径是 /api/v1.
命名组 (Named Groups) : 如 apps/v1 (用于 Deployment, StatefulSet), 它们的路径是 /apis/apps/v1.
架构知识: 这反映了 kube-apiserver 的 API 分组和版本演进策略 - apiserver 负责暴露这些 RESTful API endpoint, 并提供不同版本之间的转换.
kind 明确指定你要创建的资源对象类型，例如 Pod, Service, Deployment, ConfigMap.
架构知识: 每个 kind 在 Kubernetes 内部都对应一个资源类型定义 (Resource Definition). 当 kubectl apply -f 时, 客户端会将 YAML 序列化为 JSON 并发送到对应的 API 端点.

`metadata`: 为资源附加的身份信息与 Tag

metadata:
  name: myapp-deployment
  labels:
    app: myapp
    version: v1
  annotations:
    build-number: "123"

`metadata` 资源的身份信息与标签

metadata:
  name: myapp-deployment
  labels:
    app: myapp
    version: v1
  annotations:
    build-number: "123"

metadata.name 唯一标识符, 在同一个 namespace 下必须唯一

labels 键值对标签, 用于组织和筛选资源

annotations 用于存储非标识性信息, 例如构建信息, 开发者联系方式等

架构知识:
name 和 namespace 共同构成了资源在集群中的唯一键. apiserver 将资源数据最终存储在 etcd 中, 键类似于 /registry/deployments/default/myapp-deployment.
labels 是 Kubernetes 中核心的组织与选择机制. Service 和 Deployment 通过 Label Selector (标签选择器) 来发现并管理一组 Pod. kube-scheduler 也是用标签来将 Pod 调度到具有特定标签的 Node 上.

`spec` 定义期望状态的规约

spec 的内容完全由 kind 决定. 我们这里详细拆解 Deployment 的 spec.

spec:
  replicas: 3
  selector: 
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-container
        image: myapp:v1.0.0
        ports:
        - containerPort: 8080

spec.replicas 期望的 Pod 副本数量

spec.selector 定义如何找到该 Deployment 管理的 Pod

spec.matchLabels 必须与 template 中的 labels 匹配

spec.template Pod 模板, 定义了如何创建新的 Pod

spec.template.labels Pod 的标签, 必须被上面的 selector 选中

spec.spec Pod 的 spec

控制器如何工作

这是理解 Kubernetes 运行机制的关键

用于提交清单 -> kubectl 将 YAML 发送给 api-server
apisever 验证并存储 -> 验证格式和字段合法性, 然后作为期望状态存入 etcd
Deployment Controller 监听到变化 -> 它是 kube-controller-manager 的一部分. 它发现期望的 replicas 是 3, 但是当前没有任何 Pod.
Deployment Controller 创建 ReplicaSet -> 它会创建一个中间资源 ReplicaSet, 其 spec 中包含了 Pod 模板和 replicas: 3
ReplicaSet Controller 创建 Pod -> 它发现 Pod 的期望数量为 3, 实际是 0, 于是会创建 3 个 Pod 对象, 这些对象的定义完全来自 template
Scheduler 介入 -> 新建的 Pod 对象此时处于 Pending 状态. kube-scheduler 会持续监听 api-server, 发现这些未被调度的 Pod, 然后根据资源请求与亲和性规则等, 为它们选择一个最优的 Worker Node
Scheduler 更新 Pod 对象 -> 将选定的节点名称写入 Pod 的 spec.nodeName 字段
目标节点上的 kubelet 监听到 -> 每个节点上的 kubelet 只关注 spec.nodeName 等于自己主机名的 Pod. 它发现有一个 Pod 分配给了自己
kubelet 创建容器 -> kubelet 调用容器 runtime (在 K3s 中为 containerd), 拉取 myapp:v1.0.0 镜像并启动容器
状态上报 -> kubelet 不断将 Pod 的运行状态 (如 Running) 上报给 apiserver, 更新到 etcd

整个流程是异步且最终一致的, 各个组件通过 apiserver 进行协作, 共同推进集群状态向期望状态收敛

至此, Kubernetes 的部署清单已经完全介绍完成. 如果你已经了解了 Kubernetes 的控制器如何工作, 且明白了其中的一些核心概念, 那么就可以去尝试手写配置文件, 启动你的第一个集群了!

后记

本人非专业 Kubernetes 运维人员, 如有错误或疏漏欢迎指正. 如果觉得文章不错, 请将其分享给有需要的人, 感谢阅读!

K3s 专题 ep3: 快速部署 Docker 镜像

Sat, 11 Apr 2026 03:02:00 GMT

前言

在搭建好 K3s Master, Worker 与私有 Docker 镜像站后, 我们就该将自己开发的程序交付给 K3s 进行集群化部署. 这篇文章就记录了博主将程序交付 K3s 部署运行的全过程

本教程也同样适用于 Kubernetes, 即 K8s

由于博主刚开始研究 K3s, 故本文可能会出现的问题包括但不限于各种低级错误, 十分不严谨的专业用语, 还请各路大佬轻喷

搭建需求

已部署的 K3s Master 与至少一个 Worker 节点
私有 Harbor 站点
已编译并上传至 Harbor 的 Docker 镜像

开整

1. 编写 Kubernetes 部署清单

与 Docker 类似, 每一份 Kubernetes 程序都需要一份清单文件来描述你想创建的资源对象, 让 Kubernetes 的控制平面 (Control Panel) 来负责让集群的实际状态不断地接近并维持这个期望状态

如果您不了解如何编写部署清单, 可以看看这篇文章

参照这份示例文件, 编写您的 Kubernetes 部署清单

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: 2   # 运行2个副本
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:v1.0.0   # 根据你实际使用的镜像名调整
        imagePullPolicy: IfNotPresent   # 如果本地已有镜像就不拉取
        ports:
        - containerPort: 8080
          name: http
        # 健康检查（如果你的程序实现了 /health endpoint）
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp
  ports:
  - port: 80          # 集群内访问的端口
    targetPort: 8080  # 容器的端口
    protocol: TCP
  type: ClusterIP     # 集群内部访问，如改为 NodePort 可对外暴露

注意: 在给出的这份示例配置文件中并没有给出挂载点等配置, 您需要继续进行编写, 而不是直接使用这份不完整的示例文件

2. 推送至 K3s

在 Master 中应用该 YAML 文件

kubectl apply -f myapp-deployment.yaml

如果您的控制台有类似于这样的输出, 则证明应用成功

deployment.apps/myapp created
service/myapp-service created
configmap/myapp-config created
Warning: annotation "kubernetes.io/ingress.class" is deprecated, please use 'spec.ingressClassName' instead
ingress.networking.k8s.io/myapp-ingress created

检查 Pod 状态

kubectl get pods -o wide

您应当看到如下所示的输出

NAME                            READY   STATUS             RESTARTS   AGE    IP          NODE          NOMINATED NODE   READINESS GATES
myapp-8667bb46f9-mzxf8          0/1     ImagePullBackOff   0          111s   10.42.1.5   k3s-worker1   <none>           <none>

检查 Service

kubectl get svc myapp-service

您应当看到如下所示的输出

NAME                   TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGEvice 
heart-mirror-service   ClusterIP   10.43.42.37   <none>        8080:80/TCP    4m19s

检查 Pod 状态

kubectl get pods -l app=myapp

您应当看到如下所示的输出

NAME                            READY   STATUS    RESTARTS   AGE
myapp-674b9fdf7b-7d669   1/1     Running   0          28s

查看 Pod 日志

kubectl logs myapp-674b9fdf7b-7d669

如果您的 Pod 状态不是 Running, 您应当在 kubectl logs 后添加 --previous 参数来检查历史日志, 或使用 kubectl describe pod myapp-674b9fdf7b-7d669 来查看具体错误原因

使用 <WorkerIP>:80 访问后端, 如果正常, 则搭建阶段到此结束

至此, 您的 Kubernetes 集群就启动完成了

后记

本人非专业 Kubernetes 运维人员, 如有疏漏或错误, 请指出! 如果觉得文章写得不错, 请分享给有需要的人, 感谢阅读.

K3s 专题 ep2: 部署 Harbor 私有仓库

Thu, 09 Apr 2026 07:59:00 GMT

前言

在上一篇文章搭建完 K3s Master 和 Worker 节点之后, 我们就需要将我们的程序推送到 K3s 内部, 来实现集群化的部署. 在开发环境, 我们可以直接将打包好的 Docker 镜像推送到 K3s 内部. 但在实际生产环境, 更推荐搭建本地 Docker 私有仓库. 这样不仅方便我们管理 Docker 镜像, 同时也可以更快捷的将程序集群化部署.

由于博主刚开始研究 K3s, 故本文可能会出现的问题包括但不限于各种低级错误, 十分不严谨的专业用语, 还请各路大佬轻喷

搭建需求

任意 Linux 发行版
已安装 Docker && Docker-compose

注意

安装 Harbor 会创建很多 Docker 容器, 请确保这些容器和您现有业务不产生冲突. 如果产生冲突, 建议在一个单独的虚拟机中安装

Harbor Containers

开整

1. 安装 Harbor

1.1 下载安装程序

前往 Harbor GitHub Release Page 下载 Offline 版本的安装包

wget https://github.com/goharbor/harbor/releases/download/v2.15.0/harbor-offline-installer-v2.15.0.tgz

解压压缩包

tar -xzvf harbor-offline-installer-v2.15.0.tgz

1.2 修改配置文件

进入解压后的目录, 可以看到目录中存在 harbor.yml.tmpl. 我们需要使用该模板创建配置文件

cp harbor.yml.tmpl harbor.yml

按照个人需求对该文件进行编辑, 这里对几个必要的键做了批注

Key	Description	Recommendation
`hostname`	本机 hostname, 这里不能设置为 `localhost` 或 `127.0.0.1`, 否则外部设备无法连接至该仓库	-
`http`-> `port`	HTTP 服务器端口, 根据自己需求设置即可	80
`https` -> `port`	HTTPS 服务器端口, 根据需求配置. 如果启用了 HTTPS, 将无法使用 HTTP 端口连接/登录后台. 这里推荐使用 Openresty 等反向代理工具来启用 TLS 加密, 而不是在这里启用	443
`https` -> `certificate`	HTTPS 服务器证书路径, 建议设置为绝对路径	-
`https` -> `private_key`	HTTPS 服务器私钥, 建议设置为绝对路径	-
`external_url`	如果该仓库对公网公开, 那么这里填写该仓库对应的公网地址 (注意: 如果需要使用 HTTP 登录后台, 请不要在此处使用 HTTPS)	-
`harbor_admin_password`	默认后台登录密码, 这里可以根据自己需求修改	-
`database`	Harbor DB 的数据库相关配置, 除去 `password` 以外均不建议修改	-
`data_volume`	所有 Harbor 数据的存储目录, 设置为绝对路径	-
`log` -> `location`	Harbor 产生的日志存储目录, 设置为绝对路径	-
`proxy`	Harbor 代理相关设置. 如果您处于中国大陆地区, 建议配置代理服务器	-

配置修改完成后保存退出, 运行 ./install.sh
如果脚本运行无报错, 则安装成功

1.3 测试

浏览器进入 http(s)://<IPAddr>:<Port>, 使用默认用户名 admin 登录后台. 如果您看到如下页面, 则安装成功
Harbor

如果您先前未修改默认用户密码, 则建议您立即修改

至此, Harbor 的安装就完成了

2. 上传 Docker 镜像

2.1 新建项目

登录 Harbor, 进入管理面板
点击 + New Project, 添加新项目. 在弹出的对话框内填入项目名称, 是否公开, 项目配额限制以及镜像代理

注: 这里的 “项目” 并非指代单个程序的项目名称, 而是整个仓库分支的名称. 例如, 你可以将其设置为 dev, public 或 release 等

2.2 创建 Docker 推送用户

进入管理面板的 Administration (管理) —> Users (用户) 页面, 单击 + NEW USER, 并填写新用户相关信息
Create new user

2.3 上传 Docker 镜像

在您的开发机上启动 Docker, 并 cd 进程序代码根目录

请确保您的程序拥有完整有效的 Dockerfile

运行以下指令编译当前项目

docker build -t <ProjectName>:v<Version> .

ProjectName 项目名称

Version 版本标签

示例: docker build -t myapp:v1.0.0 .

将当前镜像打上仓库 Tag

docker tag <ProjectName>:<Version> <DockerhubURL>/<HarborProjectName>/<ProjectName>:<Version>

HarborProjectName 在 Harbor WebUI 内创建的项目名

DockerhubURL 您的私有镜像仓库 URL

示例: docker tag myapp:v1.0.0 myregistry.com/dev/myapp:v1.0.0

登录仓库并推送

docker login <DockerhubURL>
docker push <DockerhubURL>/<HarborProjectName>/<ProjectName>:v<Version>

示例

docker login myregistry.com
docker push myregistry.com/dev/myapp:v1.0.0

注意: 如果您配置了反向代理和 TLS 加密, 并在 docker login 过程中遇到了 404 报错, 请将 harbor.yml 中 external_url 的协议改为 https, 然后再次执行 install.sh 脚本. 您不会丢失任何数据

当上传完成后, 您应当可以在管理面板中看到您上传的镜像
Projects
至此, Docker 镜像的上传也完成了

后记

本人非专业相关从业人员, 如有错误或疏漏请指出! 如果觉得有用请分享给需要的人, 感谢阅读

K3s 专题 ep1: 搭建 Master 与 Worker

Thu, 09 Apr 2026 03:22:00 GMT

前言

由于项目的业务需要, 负载上来之后单个 Docker 容器撑不住, 遂决定开始研究 Kubernetes, 对容器进行一个集群化. 在询问 AI 相关建议后, AI 建议我从轻量级的 Kubernetes 发行版 K3s 入手. 于是这篇文章将会记录博主在 Proxmox VE 9.1.6 服务器上从零开始搭建 K3s 节点.

由于博主刚开始研究 K3s, 故本文可能会出现的问题包括但不限于各种低级错误, 十分不严谨的专业用语, 还请各路大佬轻喷

最低搭建需求

OS: Proxmox VE, VMware ESXi 等虚拟化系统
CPU: 核心数 >= 8
Mem: >= 12GB
Storage: >= 50GB

开整

1. 创建 K3s 虚拟机模板

1.1 创建 `Cloud-Init` 虚拟机

进入 Debian Official Cloud Images 下载 Debian 官方 Cloud-Init 镜像

这里推荐使用 Debian 13 (trixie)

根据需求和 CPU 架构选定发行版后, 登录服务器 SSH 进行下载

wget https://cloud.debian.org/images/cloud/trixie/latest/debian-13-generic-amd64.qcow2

下载完成后, 使用 qm 工具创建虚拟机

qm create <NewVMID> --name <NewVMName> --memory <VMMem> --net0 virtio,bridge=<TargetBridge> \
    --cores "<CPUCores>" --cpu host --ostype l26 \
    --scsihw virtio-scsi-pci --serial0 socket --vga serial0

<NewVMID> 模板虚拟机 ID

<NewVMName> 模板虚拟机名称

<VMMem> 模板虚拟机内存大小 (单位: MB)

<TargetBridge> 目标桥接网卡

<CPUCores> 模板虚拟机分配的核心数量

示例:
qm create 300 --name K3s-Templete --memory 2048 --net0 virtio,bridge=vmbr0 \
    --cores "8" --cpu host --ostype l26 \
    --scsihw virtio-scsi-pci --serial0 socket --vga serial0

将下载好的镜像导入该 VM

qm importdisk $VM_ID "</path/to/image.qcow2>" "<StoragePool>" --format qcow2

</path/to/image.qcow2> 先前下载的 qcow2 镜像路径

<StoragePool> 导入的目标存储池

注意记录导入后的卷 ID

挂载磁盘与 Cloud-Init 驱动器

qm set <NewVMID> --scsi0 "<VolumeID>"

<VolumeID> 先前导入的卷 ID

添加 Cloud-Init 驱动器

qm set <NewVMID> --ide2 "<StoragePool>:cloudinit"

设置引导顺序与显示配置

qm set <NewVMID> --boot order=scsi0

配置基础 Cloud-Init 模板

qm set <NewVMID> --ipconfig0 ip=dhcp

如果到此为止都没有任何错误, 那么 Cloud-Init 虚拟机创建完成

1.2 基础虚拟机配置

进入虚拟机 Cloud-Init 配置, 填写默认登录用户名与密码, SSH, 网络设置等等
Cloud-Init Config
启动该虚拟机, 在 Proxmox VE 网页端选择 xterm.js 终端
xterm.js
等待启动完成后登录, 先对虚拟机软件包进行换源&&更新

此处选择中科大源

sudo sed -i 's/deb.debian.org/mirrors.ustc.edu.cn/g' /etc/apt/sources.list.d/debian.sources
apt update
apt upgrade

注: 如果该指令无法换源, 您还可以手动换源

mv /etc/apt/sources.list.d/debian.sources /etc/apt/sources.list.d/debian.sources.bak
vim /etc/apt/sources.list.d/debian.sources

然后输入

Types: deb
URIs: http://mirrors.ustc.edu.cn/debian
Suites: trixie trixie-updates trixie-backports
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: http://mirrors.ustc.edu.cn/debian-security
Suites: trixie-security
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

执行完成后关闭虚拟机, 右键该虚拟机, 将其转换为模板
Convert to template
转换完成后, K3s 虚拟机模板就创建完成了

2. 搭建 K3s 虚拟机

2.1 搭建 K3s Master

右键刚刚创建好的模板, 选择 Clone
Clone
在新弹出的对话框中输入虚拟机基本信息, 然后将 Mode 改为 Full Clone
Clone VM Template
输入完成后单击 Clone, 等待克隆完成由于 Cloud-Init 磁盘默认大小为 3GB, 因此我们这里需要根据不同需求来增加磁盘大小
进入虚拟机的 Hardware 选项卡, 找到 Hard Disk (scsi0), 选定并单击 Disk Action —> Resize. 在这里输入你想要增加的磁盘空间.

同时你可以根据你的需求来更改 CPU/内存等配置, 这里给出一张表格供参考

集群规模 (节点数) 推荐的 Master 节点配置 (vCPU/内存/磁盘)
0 -100 4 Cores / 8 GB / 50 GB SSD or up
100 - 300 8 Cores / 16 GB / 50 GB SSD or up
300 - 500 16 Cores / 32 GB / 100 GB SSD or up
500 - 1000 32 Cores / 64 GB / 100 GB SSD or up

集群规模 (节点数)	推荐的 Master 节点配置 (vCPU/内存/磁盘)
0 -100	4 Cores / 8 GB / 50 GB SSD or up
100 - 300	8 Cores / 16 GB / 50 GB SSD or up
300 - 500	16 Cores / 32 GB / 100 GB SSD or up
500 - 1000	32 Cores / 64 GB / 100 GB SSD or up

更改完配置后, 启动虚拟机并打开终端, 安装 K3s Master 相关组件

# 使用官方脚本一键安装，并指定节点名为master
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--node-name k3s-master" sh -s -

# 等待安装完成，检查服务状态
sudo systemctl status k3s

# 获取用于添加 Worker 节点 token
sudo cat /var/lib/rancher/k3s/server/node-token

如果您启用了防火墙, 请务必确保 6443/TCP, 8472/UDP, 10250/TCP 端口保持开放

至此, Master 节点配置完成

2.2 搭建 K3s Worker

再次 Clone 一份刚才创建好的模板, 修改配置信息并启动虚拟机, 进入控制台
Clone VM Template
输入以下指令部署 K3s Worker

curl -sfL https://get.k3s.io | K3S_URL=https://<MasterIP>:6443 K3S_TOKEN=<MasterToken> INSTALL_K3S_EXEC="--node-name k3s-worker1" sh -s -

<MasterIP> Master 虚拟机的 IP 地址

<MasterToken> 先前安装时获取的 Token

安装如果未报错, 则证明成功

3. 验证

返回 Master 节点的控制台, 输入指令查看节点状态

sudo kubectl get nodes

如果节点状态为 Ready, 则节点添加成功并且就绪

root@K3s-Master:~# sudo kubectl get nodes
NAME          STATUS   ROLES           AGE   VERSION
k3s-master    Ready    control-plane   20h   v1.34.6+k3s1
k3s-worker1   Ready    <none>          20h   v1.34.6+k3s1

至此, K3s 的 Master 与 Worker 均部署完成

后记

本人非专业 Kubernetes 运维, 如有错误和疏漏, 欢迎各位大佬指出. 如果觉得文章不错, 请分享给有需要的人. 感谢阅读.

物理机 P2V 全量迁移到 Proxmox VE

Fri, 27 Mar 2026 14:35:00 GMT

前言

博主家里现在有两条入网宽带, 如果只在一个系统上部署网络出口相关业务, 那么只能同时使用一条宽带的上行, 没法做到充分利用两条宽带的上行. 因此, 博主决定将自己的网络出入口子服务器也换成 Proxmox VE, 这样既能通过防火墙规则和负载均衡同时使用两条宽带的上行作为网络出口, 也可以更加方便的管理服务器. 但是, 如果想在迁移的同时, 不丢失原有服务器上安装的操作系统和环境, 该怎么操作呢? 本篇文章将会为你带来全量迁移的最佳方案

需求

移动存储器 >= 服务器系统盘数据区
服务器硬盘 >= 64GB

开整

1. 全量备份硬盘数据

在移动存储器上安装任意 Linux Live CD, 这里推荐使用 SystemRescue, 或者使用 Ventoy 将多个 ISO 整合
进入 Live 环境后, 列出所有磁盘

lsblk

找到你的移动存储器, 将其挂在至 /mnt/usbdisk 目录

mkdir /mnt/usbdisk
mount /dev/<device> /mnt/usbdisk

使用 dd 工具创建完整镜像

dd if=/dev/<device> of=/mnt/usbdisk/backup.img bs=1M status=progress

注意：此过程耗时较长 (约每 100GB 数据耗时 30-60 分钟), 注意防止服务器断电以免数据损坏

使用 qemu-img 工具将镜像转换至 qcow2 格式

qemu-img convert -f raw -O qcow2 -c /mnt/usbdisk/backup.img /mnt/usbdisk/backup.qcow2

注意：此过程耗时依旧较长, 注意防止服务器断电以免数据损坏

待转换完成后, 备份阶段结束

2. 安装 Proxmox VE

这里我们采用手动安装的方式, 以免官方安装器使用非预期的磁盘数据格式

引用: 记一次手动安装 Proxmox VE, 配置多路 iSCSI 与 NAT 转发的经历 » 悠笙の开发日记

配置 Hostname Proxmox VE 要求为当前的主机名配置一个指向非回环地址的 Hosts:

The hostname of your machine must be resolvable to an IP address. This IP address must not be a loopback one like 127.0.0.1 but one that you and other hosts can connect to.

例如, 我的服务器内网地址为 192.168.1.5, 公网地址为 112.32.***.***, 则 /etc/hosts 配置文件应该如下:

127.0.0.1       NanamiWork-SubServer
127.0.1.1       NanamiWork-SubServer.lan        NanamiWork-SubServer
192.168.1.5     NanamiWork-SubServer
112.32.***.***  NanamiWork-SubServer

# The following lines are desirable for IPv6 capable hosts
::1     NanamiWork-SubServer ip6-NanamiWork-SubServer ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

如果您不想让您的服务器可以在公网被直接访问, 也可以不添加公网信息

安装 Proxmox VE 软件源

Debian 13 使用了 Deb822 格式, 因此直接参考 USTC 的 Proxmox 镜像站即可:

cat > /etc/apt/sources.list.d/pve-no-subscription.sources <<EOF
Types: deb
URIs: https://mirrors.ustc.edu.cn/proxmox/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF

将 keyring 安装至 /usr/share/keyrings

cd /usr/share/keyrings
wget https://www.iyoroy.cn/usr/uploads/2025/11/4102711242.zip
apt install unzip -y
unzip 4102711242.zip
rm 4102711242.zip

更新软件包

apt update
apt upgrade -y

安装 Proxmox VE 内核

apt install proxmox-default-kernel
reboot

使用 uname -a 查看系统信息, 如果内核版本以 -pve 或类似结尾, 则安装成功

安装 Proxmox VE 相关软件包

apt install proxmox-ve postfix open-iscsi chrony

配置过程中会需要设置 postfix 邮件服务器, 官方解释: 如果您的网络中有邮件服务器, 则应将 postfix 配置为 Satellite system . 然后, 您现有的邮件服务器将成为中继主机, 将 Proxmox VE 发送的电子邮件路由到其最终收件人. 如果您不知道在此处输入什么, 请仅选择 Local only , 并保持系统 hostname 不变.

安装完成后应该可以使用 https://<IP Addr>:8006 访问 WebUI. 如果成功访问, 则安装成功.

用户名: root, 密码: 您的 root 用户密码

删除旧的 Debian 内核与 os-prober

apt remove linux-image-amd64 'linux-image-6.1*'
update-grub
apt remove os-prober

移除 os-prober 不是必须的, 但是官方建议这么做, 因为它可能会误将虚拟机的引导文件认成多系统的引导文件, 导致将不该加的一些东西加到引导列表中.

至此, Proxmox VE 安装完成

3. 创建虚拟桥接网卡

登录 Proxmox VE WebUI, 定位至 Datacenter —> <Hostname> —> System —> Network 选项卡
Network
单击 Create, 选择 Linux Bridge
在弹出的对话框中输入你需要的 Name, 然后在 Bridge ports 中输入该虚拟网卡桥接的物理网卡

注意:

如果你想将该物理网卡作为 Debian 物理机系统的接入网卡, 则你需要在该对话框中配置 IPv4/CIDR, Gateway(IPv4), IPv6/CIDR(可选), Gateway(IPv6)(可选)
Example

一定不要在物理网卡上配置服务器的固定 IP 地址, 否则可能会导致虚拟机无法联网等一系列问题!!

单击 OK 创建网卡

4. 恢复原始服务器系统

4.1 创建虚拟机

登录 Proxmox VE WebUI, 单击右上角 Create VM, 按照需求配置虚拟机名称, 是否开机启动等, 随后点击 Next
在 OS 选项卡, 选择 Do not use any media, 然后单击 Next
在 System 选项卡, 启用 Qemu Agent, 按照需求选择是否将 BIOS 改为 OVMF (UEFI), 然后单击 Next
在 Disks 选项卡, 单击左侧 scsi0 右边的垃圾桶图标, 删除默认创建的磁盘, 然后单击 Next
在 CPU 选项卡, 将 Type 改为 host, 然后根据需求分配核心数 (Cores). 如果核心数较多, 可以启用 NUMA, 配置完成后单击 Next
在 Memory 选项卡, 根据需求分配内存, 然后单击 Next

注意: 内存分配不应超过物理内存的 80%, 否则会有内存溢出的风险

在 Network 选项卡, 根据需求选择刚刚创建的虚拟网卡, 然后单击 Next

注意: 如果您的原始系统为 Windows, 您可能需要将网卡型号变更为 Intel E1000 或 Intel E1000E

到了最后的 Confirm 选项卡, 确认配置无误后直接创建. 等待底部 Tasks 中的 VM 100 - Create 的状态变为 OK 后, 虚拟机创建完成

4.2 恢复原始物理机磁盘镜像

登录服务器 SSH, 使用该命令列出所有磁盘

lsblk

找到你的移动存储器, 并将其挂载到 /mnt/usbdisk

mkdir /mnt/usbdisk
mount /dev/<device> /mnt/usbdisk

将先前创建的 qcow2 镜像文件复制到服务器

cp /mnt/usbdisk/backup.qcow2 /var/lib/vz/images/100/vm-100-disk-1.qcow2

注意: 此过程持续时间可能较长, 请保证服务器不断电, 以免造成数据损坏

复制完成后, 使用该命令将磁盘导入至对应虚拟机中

qm set 100 --scsi0 /var/lib/vz/images/100/vm-100-disk-1.qcow2

使用该命令设置启动顺序

qm set 100 --boot order=scsi0

执行完成后在 WebUI 中选中对应的虚拟机并启动该虚拟机
如果虚拟机正常启动到了宿主机之前的系统, 则恢复完成!

5. 安装 `Qemu-Agent`

登录虚拟机 SSH, 安装 qemu-agemt

sudo apt install qemu-guest-agent

启动并配置开机启动

sudo systemctl enable qemu-guest-agent
sudo systemctl start qemu-guest-agent

返回 WebUI 虚拟机的 Summary 页面, 如果看到正确显示了 IP 地址, 则安装成功
IPs

至此, 整个 P2V 迁移就结束了

结语

本人非专业 Linux 运维, 如有错误或疏漏, 请直接指出, 谢谢!
如果觉得该文章有帮助, 请将其分享给身边有需要的人, 感谢!

Nanamiの电波发射塔

校园网 VLAN 接入 AP 与自动认证

前言

环境介绍与研究目标

观前须知

开整

1. 探明网络架构

2. 分析路由策略

3. 接口配置

4. 尝试登录网络

5. 持久化

6. 链路聚合

总结

相关阅读

盛科 CTC7132 逆向: 解锁 SFP+ 2.5G

前言

CTC7132 平台

研究目标

观前提示

开整

1. 固件分析

2. 分析 nsm

2.1 group-speed 分析

2.2 speed 分析

3. 研究判断逻辑

4. 第一次 Patch

5. 定位首次 Patch 报错点

6. 第一次踩坑

7. 尝试更改代码

8. 第二次 Patch

9. 持久化

10. 关于开头的问题

10.1 为什么厂商要将这四个端口绑定到一个组内?

10.2 为什么 group-speed 没有设计 2.5Gbe 速率的下发实现?

总结

相关阅读

自建 Debian 13 镜像源: ftpsync + Nginx

前言

示例环境

注意

开整

1. 前置工作

2. 配置同步

3. 配置 Web 服务器

4. 创建定时任务

5. 进行首次同步

6. 测试

结语

相关阅读

自建私有 VoIP: FreePBX 电话系统

前言

什么是 VoIP?

搭建规划

配置需求

免责声明

开整

1. 安装 FreePBX

1.1 使用 ISO 映像安装

1.2 手动安装

2. 配置 FreePBX

2.1 初始化

2.2 基础配置

2.2.1 防火墙

2.2.2 SIP 中继

2.2.3 创建分机 (添加用户)

3. 配置客户端

后记

相关阅读

OrangePi 3B 编译 UEFI 固件

前言

本文操作环境

开整

1. 编译 UEFI

1.1 准备材料

1.2 检查环境

1.3 初始化编译环境

1.4 尝试编译

2. 启动 UEFI

2.1 烧录

2.2 启动

2. 分析 `nsm`

2.1 `group-speed` 分析

2.2 `speed` 分析

10.2 为什么 `group-speed` 没有设计 2.5Gbe 速率的下发实现?

1. 安装 `FreePBX`

IEPL `(International Ethernet Private Line)` / IPLC `(International Private Leased Circuit)`

IX `(Internet Exchange Point)`

`Router ID` 冲突