Go netlink 怎样用属性编码器封装嵌套字段

在 Go netlink 代码里，嵌套字段最容易出问题的地方不是“能不能写入字节”，而是父属性和子属性的边界没有被明确表达。直接手工拼接 Attribute 虽然可行，但长度、Nested 标志、字节序和错误传播都需要自己维护。

官方地址：https://pkg.go.dev/github.com/mdlayher/netlink

要封装一组嵌套字段，先用 netlink.NewAttributeEncoder() 创建顶层编码器，再用 ae.Nested(parentType, func(nae *netlink.AttributeEncoder) error { ... }) 写入子属性，最后只在顶层调用一次 Encode()。嵌套编码器会继承父编码器的 ByteOrder，中间错误也会在顶层 Encode 时返回。

先把生产目标限定为“稳定的属性层级”

github.com/mdlayher/netlink 提供的是 Linux netlink socket 的低层访问能力，属性编码器解决的是消息载荷的组织问题，不会替你决定某个具体 netlink family 的业务属性编号。本文只讨论一层父属性包住一组子属性的通用写法。

可以把目标拆成三条边界：

• 父属性：表达“这一段载荷属于哪个字段”，类型值由具体协议定义。
• 子属性：表达嵌套对象内部的字段，仍然需要稳定的类型编号。
• 编码结果：由顶层 Encode 统一返回带长度、类型和对齐信息的字节数据。

这种拆分的好处是，后面增加子字段时，只改嵌套编码函数，不必重新计算父属性长度。

环境准备：先固定属性编号和字节序

正式项目中，属性编号不是随意递增的临时变量，而是协议合同的一部分。示例使用独立的常量区表示父属性和子属性；这些数字只用于演示编码器关系，接入具体协议时必须替换成该协议公开定义的编号。

AttributeEncoder.ByteOrder 应在第一次写属性前设置。未设置时，官方文档说明会使用本机字节序；如果协议明确要求某种字节序，就不要把结果交给运行机器的默认值。

package main

import (
    "encoding/binary"
    "fmt"

    "github.com/mdlayher/netlink"
)

const (
    attrProfile = 1 // 父属性：表示一个嵌套配置对象。
    attrMode    = 1 // 子属性：表示配置对象中的模式。
    attrMTU     = 2 // 子属性：表示配置对象中的数值字段。
)

type profile struct {
    Mode uint32
    MTU  uint32
}

func encodeProfile(p profile) ([]byte, error) {
    ae := netlink.NewAttributeEncoder()
    // 协议若要求小端，应在任何字段写入前固定 ByteOrder。
    ae.ByteOrder = binary.LittleEndian

    // Nested 会为父属性设置嵌套标志，并把子字段交给 nae。
    ae.Nested(attrProfile, func(nae *netlink.AttributeEncoder) error {
        nae.Uint32(attrMode, p.Mode)
        nae.Uint32(attrMTU, p.MTU)
        return nil
    })

    // 顶层 Encode 统一返回子编码器传播上来的错误。
    return ae.Encode()
}

func main() {
    payload, err := encodeProfile(profile{Mode: 2, MTU: 1500})
    if err != nil {
        panic(fmt.Errorf("encode profile: %w", err))
    }
    fmt.Printf("payload bytes: %d\\n", len(payload))
}

这里没有调用嵌套编码器的 Encode。Nested 会把它的内部属性嵌入父属性，并在顶层编码时完成最终封装；手动提前编码会让层级职责变得不清晰。

安全配置：用 Nested 封装子属性并集中传播错误

Nested 的回调返回 error，这给了工程代码一个明确的错误边界：子对象负责写字段或调用其他编码器，顶层负责在最终 Encode 处收口。对于复杂对象，可以继续把回调提取成具名函数。

func encodePolicy(ae *netlink.AttributeEncoder, typ uint16, p profile) {
    // 这个辅助函数只描述父属性和子属性的结构，不负责发送 socket 消息。
    ae.Nested(typ, func(nae *netlink.AttributeEncoder) error {
        nae.Uint32(attrMode, p.Mode)
        nae.Uint32(attrMTU, p.MTU)
        return nil
    })
}

func encodeRequest(p profile) ([]byte, error) {
    ae := netlink.NewAttributeEncoder()
    // 先配置字节序，再复用同一个编码器写入请求字段。
    ae.ByteOrder = binary.LittleEndian
    encodePolicy(ae, attrProfile, p)
    return ae.Encode()
}

需要注意，AttributeEncoder 的方法本身不逐个返回错误，编码中间错误会留在编码器状态里，最终由 Encode 返回。因此不要只检查回调是否返回 nil 就把字节直接送进 socket。

权限边界：编码成功不等于内核请求一定被接受

属性编码器只负责产生载荷。后续调用 netlink.Dial、Conn.Send 或 Conn.Execute 时，仍然要面对具体 family 的协议、内核版本、网络命名空间和进程权限。尤其是 Config.NetNS 涉及进入指定网络命名空间，权限要求不能从“编码成功”推导出来。

因此建议把两类错误分开记录：

日志审计：用 Nested 解码并在顶层检查 Err

读取时可以先用 NewAttributeDecoder 遍历父属性，再在匹配到嵌套类型后调用 ad.Nested。嵌套回调获得自己的解码器，父层的 Type、String、Uint32 等读取方法不会和子层混在一起。

func decodeProfile(b []byte) (profile, error) {
    var p profile

    ad, err := netlink.NewAttributeDecoder(b)
    if err != nil {
        return p, fmt.Errorf("new attribute decoder: %w", err)
    }
    // 解码端必须使用与编码协议一致的字节序。
    ad.ByteOrder = binary.LittleEndian

    for ad.Next() {
        switch ad.Type() {
        case attrProfile:
            // Nested 使用独立的子解码器读取父属性的内部字段。
            ad.Nested(func(nad *netlink.AttributeDecoder) error {
                for nad.Next() {
                    switch nad.Type() {
                    case attrMode:
                        p.Mode = nad.Uint32()
                    case attrMTU:
                        p.MTU = nad.Uint32()
                    }
                }
                // 子解码器的格式错误会在这里向父层传播。
                return nad.Err()
            })
        }
    }

    // 统一检查顶层错误，避免静默接受截断或格式异常的载荷。
    if err := ad.Err(); err != nil {
        return p, fmt.Errorf("decode attributes: %w", err)
    }
    return p, nil
}

解码逻辑的关键不是“看到一个父类型就强行读取”，而是确认它确实是当前协议所定义的嵌套属性，然后让 Nested 在正确层级上处理内部字段。任何未知类型都应该按协议策略选择忽略、记录或报错。

发布检查：把层级合同写进代码评审

提交到生产分支前，我会保留下面这份清单：

1. 父属性和子属性的编号来自同一个协议定义，未通过换名或换分类伪造新编号。
2. ByteOrder 在首次编码或解码前已经明确设置，编码端和解码端保持一致。
3. 嵌套字段通过 Nested 写入，未在嵌套回调里提前调用 Encode。
4. 顶层 Encode、顶层 Err 和嵌套解码器的 Err 都有处理路径。
5. 编码日志只记录必要的属性编号和错误，不把私有载荷、凭据或完整敏感数据写入日志。
6. 把“载荷编码成功”“socket 发送成功”和“内核回复符合协议”作为三个独立状态。

如果需求只是把一组字段放进一个父属性，Nested 已经提供了清晰的边界；如果需求是完整实现某个 netlink family，则还要另外核对该 family 的协议定义、消息头、权限和回复格式。

相关问题

Nested 回调里要不要调用 Encode？

不需要。官方文档说明嵌套编码器不应单独调用 Encode，由外层编码器在最终 Encode 时收集和封装。

为什么设置了 ByteOrder 仍然要在嵌套解码器上留意字节序？

嵌套编码器会继承父编码器的 ByteOrder，但解码时仍要让顶层 AttributeDecoder 在读取前使用协议要求的字节序，不能依赖不同机器的本机默认值。

编码成功后能否说明 netlink 请求一定有权限？

不能。编码只产生属性载荷；网络命名空间、socket 操作和具体内核 family 的权限与校验属于后续阶段。