MyNote

外观

DHCP、NAT 与连接跟踪 ​

内容摘要：动态主机配置协议（Dynamic Host Configuration Protocol，DHCP）解决“主机如何获得地址和网络参数”，网络地址转换（Network Address Translation，NAT）解决“报文经过边界时如何改写地址/端口”，连接跟踪（connection tracking，conntrack）则记录双向流映射和状态。三者经常同时出现在家庭网关、Linux 防火墙、容器平台与云网络中，但属于不同机制。本章从控制报文、状态表和逐跳报文变化出发，解释失败模式、容量风险和验证方法。

难度：高级　|　前置知识：06 ARP/NDP、07 IPv4、08 IPv6、10 路由、13 TCP　|　所属层次：链路接入、网络层边界与有状态转发

一、三个机制分别解决什么问题 ​

机制核心问题典型状态不负责什么
DHCP客户端如何获得地址、租期及 DNS/网关等参数租约、客户端标识、地址池不转发业务流量，不提供默认安全
NAT报文经过边界时如何改写地址/端口原始五元组与转换后五元组不等于路由，不天然等于防火墙
conntrack如何识别同一双向流及其状态tuple、状态、超时、NAT 绑定不等于应用会话，也不完整复制 TCP 状态机

常见误区：NAT 让内网地址不直接可达，但这不是完整访问控制。允许哪些新连接、如何处理已建立连接属于防火墙策略；NAT 和防火墙可以一起实现，也可以独立存在。

二、DHCPv4：DORA 只是开始 ​

1、基本交互 ​

DHCPv4 基于 UDP，客户端端口 68、服务器端口 67。新客户端尚无可用地址时，常以广播开始：

DORA 是 Discover、Offer、Request、Acknowledgement 的缩写，但实际还包括：

  • DHCPDECLINE：客户端检测到地址冲突；
  • DHCPRELEASE：客户端主动释放租约；
  • DHCPINFORM：已有地址，仅请求其他参数；
  • 续租时的单播或广播 DHCPREQUEST；
  • 服务器拒绝当前配置的 DHCPNAK。

2、关键字段与选项 ​

字段/选项作用排障价值
xid事务标识关联一次发现/请求流程
chaddr / client identifier标识客户端判断租约为何分配给某个客户端
yiaddr“your IP address”Offer/ACK 提供的地址
giaddrRelay 地址服务器据此选择地址池
Option 53DHCP Message TypeDiscover/Offer/Request/ACK 等
Option 54Server Identifier客户端选择的服务器
Option 50Requested IP Address客户端希望使用的地址
Option 51Lease Time租期
Option 1/3/6掩码/路由器/DNS决定基本网络行为
Option 82Relay Agent Information接入位置、策略与审计，具体子选项依实现

3、租约状态与定时器 ​

若服务器未提供 T1/T2，常见默认计算是租期的 50% 和 87.5%，但实际值应以 ACK 选项和客户端实现为准。

失败边界：

  • 有 IP 不代表 DNS、默认路由或 MTU 正确。
  • 续租失败不一定立即断网，客户端可在租期到期前继续使用地址。
  • 多 DHCP 服务器不一定是故障；关键是是否属于同一管理域、地址池与选项是否一致。

三、DHCP Relay 与跨网段分配 ​

路由器默认不会转发链路广播。DHCP Relay 把客户端广播转换为可路由到服务器的请求，并携带接入网段信息。

排查 Relay 时检查：

  1. 客户端广播是否到达网关接口；
  2. Relay 是否设置正确服务器地址与 giaddr；
  3. 中间 ACL/防火墙是否允许 UDP 67/68；
  4. 服务器是否存在与 Relay 网段匹配的地址池；
  5. 返回路径是否可达 Relay；
  6. Option 82 策略是否导致拒绝。

四、IPv6：RA、SLAAC 与 DHCPv6 必须一起理解 ​

IPv6 地址配置不是 DHCPv4 的简单复制。

机制提供内容关键协议
Router Advertisement（RA）前缀、默认路由、链路参数、标志位ICMPv6 Neighbor Discovery
SLAAC主机根据 RA 前缀形成地址并执行 DADRFC 4862
Stateful DHCPv6由服务器分配 IPv6 地址及其他参数RFC 8415
Stateless DHCPv6仅提供 DNS 等其他配置RFC 8415

1、关键差异 ​

  • DHCPv6 使用 UDP 客户端端口 546、服务器/Relay 端口 547。
  • DHCPv6 使用链路本地地址和组播，不依赖 IPv4 广播。
  • 默认路由通常来自 RA，不由 DHCPv6 提供。
  • RA 的 M/O 标志表达是否可用受管地址或其他配置，但客户端行为存在操作系统差异。
  • SLAAC、DHCPv6 和手工地址可以同时存在，一块接口可能有多个 IPv6 地址。
  • 前缀委派（Prefix Delegation，PD）用于给下游路由器分配前缀，不等于给单个主机分地址。

安全提示：RA Guard、DHCPv6 Shield 等二层防护依赖交换设备能力和正确部署。它们不能替代主机策略，且错误配置可能误伤合法扩展头或 Relay 流量。

五、NAT 术语与数据平面 ​

1、常见类型 ​

类型改写方向典型用途示例
Source NAT（SNAT）改源地址内网出站、固定出口地址10.0.0.10 → 203.0.113.10
Masquerade动态 SNAT出口地址可能变化家庭拨号/动态地址
Destination NAT（DNAT）改目的地址端口映射、发布内部服务203.0.113.10:443 → 10.0.0.20:8443
Network Address and Port Translation（NAPT/PAT）同时改地址和端口多主机共享少量公网地址多个内网源映射到不同外部端口
Static NAT固定一对一映射特定资产映射公私地址固定对应
Hairpin NAT内部客户端经外部映射访问内部服务内外统一域名内部源与目的都经过 NAT 设备

日常口语常把 NAPT/PAT 统称为 NAT，但做容量计算时必须明确是否转换端口。

2、一条连接如何变化 ​

客户端 10.0.0.10:49152 访问服务端 198.51.100.20:443，出口使用 203.0.113.10:40001：

NAT 必须同步更新 IP/TCP/UDP 校验和。若报文分片、携带地址字面量的应用协议、IPsec 或多层 NAT 参与，处理会更复杂。

3、NAT 不改变哪些事实 ​

  • 路由仍先决定报文走哪个出口，NAT 不是路由替代品。
  • TCP 可靠性和拥塞控制仍在端点执行。
  • 应用身份不应由 NAT 后的源 IP 唯一决定。
  • NAT 映射存在不代表防火墙一定允许流量。
  • 地址转换不加密载荷，不提供机密性或完整性。

六、Linux conntrack：流状态与 NAT 绑定 ​

Linux Netfilter 的 conntrack 子系统按 tuple 跟踪流。常见信息包括：

  • 原始方向 tuple；
  • 应答方向 tuple；
  • 协议相关状态与超时；
  • NAT 映射；
  • mark、zone、helper 等实现属性。

1、conntrack 状态不是 TCP 状态 ​

防火墙规则常见的 ct state：

conntrack 状态含义注意
NEW新流，或尚未看到双向确认的流不等于 TCP SYN_SENT
ESTABLISHED已观察到双向流量UDP 也可进入该状态
RELATED与已有流相关的新流依赖协议识别/helper
INVALID无法归入合法跟踪状态可能是异常包，也可能是表耗尽/乱序等
UNTRACKED明确跳过跟踪规则和功能会受限

TCP 的 SYN_RECV、ESTABLISHED、FIN_WAIT_1 等是端主机 TCP 状态机；conntrack 是中间设备观察到的近似状态，二者不能一一对应。

2、Netfilter hook 与 NAT ​

具体优先级、与其他 table/chain 的关系必须看正在使用的 nftables 规则集和内核版本，不能仅凭一张通用图推断最终处理顺序。

3、NAT 通常只在首包决定映射 ​

对受 conntrack 跟踪的新流，NAT 规则通常在首包上决定映射，后续包按已建立的 NAT binding 处理。因此：

  • 修改 NAT 规则不一定改变已有连接；
  • 排障时要区分新连接和存量连接；
  • 删除 conntrack 表项会中断连接，应视为有风险操作；
  • 规则计数器和 conntrack 表必须结合查看。

七、端口复用与耗尽 ​

一个公网 IPv4 地址可用的源端口不是简单固定为 65535：

  • 低端口、保留端口和本地策略会缩小范围；
  • 映射是否可按不同目的地址/端口复用，依赖 NAT 行为；
  • TCP 状态和 conntrack 超时会延迟端口回收；
  • 多级 NAT 会在每一级消耗状态；
  • 云 NAT 网关可能按目的、实例或公网 IP 设置不同配额。

1、粗略容量模型 ​

设：

  • 可用公网地址数为 A；
  • 每地址可分配端口数为 P；
  • 映射利用率安全系数为 u（如 0.7）；
  • 平均连接存活时间为 T 秒。

粗略并发上限：

text
safe_concurrency ≈ A × P × u

粗略稳态新建连接能力：

text
safe_new_connections_per_second ≈ safe_concurrency / T

这只是容量初筛，不能替代设备/云厂商文档和压测。目的 tuple 复用、超时、协议和分片都会影响真实上限。

2、耗尽症状 ​

  • 新连接间歇超时，存量连接正常；
  • 某些目的地址失败，其他目的正常；
  • NAT/conntrack 使用率接近上限；
  • 分配端口失败、insert failed、drop 等计数增加；
  • 扩大客户端连接池反而加剧问题；
  • 跨可用区或多出口流量分布不均。

优先修复通常是连接复用、降低不必要连接、缩短合理的空闲生命周期、增加公网地址或网关容量，而不是盲目缩短所有 conntrack 超时。

八、Hairpin NAT 与内外统一域名 ​

内部客户端用公网域名访问同一内网服务时，可能走 Hairpin NAT：

若只做 DNAT，服务端可能直接把响应发给客户端，客户端收到来自 10.0.0.20 而非目标 203.0.113.10 的包，连接校验失败。因此很多拓扑需要同时 SNAT 保证对称回程。

替代方案是 Split-horizon DNS（内外返回不同地址），但会增加 DNS 视图与证书/测试管理复杂度。

九、NAT 穿透：STUN、TURN 与 ICE ​

1、为什么打洞不是必然成功 ​

NAT 对外部端点、端口分配和入站过滤的行为不同。RFC 4787 等文档使用映射/过滤行为描述，比“Full Cone/Symmetric NAT”这类旧分类更精确。

  • 某些 NAT 对不同目标复用同一外部映射；
  • 某些 NAT 会为不同目标分配不同外部端口；
  • 入站包可能只允许来自曾经通信过的地址/端口；
  • NAT 映射有空闲超时；
  • 多级 NAT 和 CGNAT 让双方都无法控制最外层设备。

2、三个协议的职责 ​

协议全称作用
STUNSession Traversal Utilities for NAT发现服务器反射看到的地址，并做连通性检查
TURNTraversal Using Relays around NAT直连失败时通过中继转发
ICEInteractive Connectivity Establishment收集 host/server-reflexive/relay candidates，排序并检查路径

STUN 不是公网地址分配服务，TURN 不是只做信令。TURN 承载实际数据，必须评估带宽、延迟、认证和滥用风险。

十、CGNAT 与共享地址空间 ​

运营商级 NAT（Carrier-Grade NAT，CGNAT）常使用 RFC 6598 的共享地址空间 100.64.0.0/10。它带来：

  • 用户无法自行配置最外层端口映射；
  • P2P/入站服务更难建立；
  • 多用户共享公网地址，审计需要公网地址 + 端口 + 精确时间；
  • 端口配额和映射超时可能影响高连接应用；
  • 基于源 IP 的风控、限流和定位会误伤多个用户。

不要把 100.64.0.0/10 当普通 RFC 1918 私网随意复用；它有明确用途，网络设计需避免与运营商链路冲突。

十一、IPv6 与 NAT ​

IPv6 通过大地址空间降低了“共享公网地址”的必要性，但不代表：

  • 主机应无防火墙直接暴露；
  • 地址永不变化；
  • 不需要前缀规划、隐私地址和 DNS；
  • 所有应用都已支持 IPv6；
  • 网络不存在前缀转换。

IPv6-to-IPv6 Network Prefix Translation（NPTv6，RFC 6296）只转换前缀，目标与传统 NAPT 不同。NAT64/DNS64 用于 IPv6-only 客户端访问 IPv4 服务，需要在 DNS、地址合成、协议兼容和日志中共同排查。

IPv6 的主要安全边界应由状态防火墙、身份和最小权限策略实现，而不是依赖“没有 NAT”或“有 NAT”。

十二、云 NAT 与容器场景 ​

云网络中的 NAT 可能由分布式数据面或托管网关实现，用户看不到传统 Linux 设备。必须核对：

  • 每个公网 IP、网关、目的地址的并发/端口配额；
  • 多可用区容灾与路由表绑定；
  • 空闲超时、连接重置和维护行为；
  • 是否支持固定出口 IP、端口映射、Hairpin；
  • 流日志是否记录转换前/后的 tuple；
  • SNAT 发生在节点、容器网络、云 NAT 网关还是多层同时发生；
  • 跨区流量与公网流量费用。

Kubernetes 中可能出现 Pod SNAT、节点 SNAT、Service DNAT 和云 NAT 多层转换。仅在应用日志看到节点 IP，不能直接认定原始客户端就是节点。

十三、最小可复现实验：Linux nftables NAT ​

本实验复用20 统一实验项目的 cli、rtr、srv 网络命名空间。

⚠️ 权限与执行状态：需要 Linux、root 或 CAP_NET_ADMIN、nftables 和可选的 conntrack 工具。当前主机为 macOS，本实验未在当前环境执行。所有修改限制在 rtr 命名空间和名为 lab_nat 的独立表；仍应先确认没有同名资源。

1、前置验证 ​

bash
sudo ip netns list
sudo ip -n cli route get 198.51.100.2
sudo ip netns exec rtr nft list ruleset
sudo ip netns exec rtr sysctl net.ipv4.ip_forward

预期：

  • 三个 namespace 存在；
  • client 经 192.0.2.1 到 server；
  • rtr 的 net.ipv4.ip_forward = 1。

2、创建 SNAT ​

bash
sudo ip netns exec rtr nft add table ip lab_nat
sudo ip netns exec rtr nft \
  'add chain ip lab_nat postrouting { type nat hook postrouting priority srcnat; policy accept; }'
sudo ip netns exec rtr nft add rule ip lab_nat postrouting \
  oifname "veth-rs" ip saddr 192.0.2.0/24 \
  snat to 198.51.100.1 counter

从 cli 新建连接到 srv：

bash
sudo ip netns exec cli curl -v --max-time 3 \
  http://198.51.100.2:8080/

在 rtr 两侧分别抓包：

bash
# client 侧：预期源地址为 192.0.2.2
sudo ip netns exec rtr tcpdump -ni veth-rc -c 20 \
  'host 198.51.100.2 and tcp port 8080'

# server 侧：预期源地址已变为 198.51.100.1
sudo ip netns exec rtr tcpdump -ni veth-rs -c 20 \
  'host 198.51.100.2 and tcp port 8080'

两个抓包命令应在请求前启动。只看单侧抓包无法证明转换发生在哪一跳。

3、查看规则与 conntrack ​

bash
sudo ip netns exec rtr nft -a list table ip lab_nat

# 若已安装 conntrack-tools
sudo ip netns exec rtr conntrack -L -p tcp \
  --orig-src 192.0.2.2 2>/dev/null

预期在 nft 规则看到 packet/byte counter 增长；conntrack 输出格式和字段顺序随版本变化，应关注 original/reply tuple，而不是逐字匹配示例。

4、增加 DNAT 端口映射 ​

bash
sudo ip netns exec rtr nft \
  'add chain ip lab_nat prerouting { type nat hook prerouting priority dstnat; policy accept; }'
sudo ip netns exec rtr nft add rule ip lab_nat prerouting \
  iifname "veth-rc" ip daddr 192.0.2.1 tcp dport 18080 \
  dnat to 198.51.100.2:8080 counter

sudo ip netns exec cli curl -v --max-time 3 \
  http://192.0.2.1:18080/

抓包时应看到：

  • veth-rc 入站目的为 192.0.2.1:18080；
  • veth-rs 出站目的为 198.51.100.2:8080；
  • 若第 13.2 节 SNAT 规则仍存在，server 侧看到源地址 198.51.100.1。

5、规则变更与已有连接 ​

删除 DNAT 规则后，已有 conntrack 映射可能仍让存量连接继续，具体取决于连接状态和后续包。应使用新建连接验证新规则：

bash
sudo ip netns exec rtr nft -a list chain ip lab_nat prerouting
# 根据实际 handle 删除规则，不要照抄编号：
# sudo ip netns exec rtr nft delete rule ip lab_nat prerouting handle <handle>

危险操作提示：conntrack -F 会清空命名空间内所有连接跟踪状态并中断连接。即使在实验环境，也应确认范围；生产环境不得作为常规“刷新配置”手段。

6、清理与恢复 ​

bash
sudo ip netns exec rtr nft delete table ip lab_nat

# 确认表已消失，基础路由仍正常
sudo ip netns exec rtr nft list tables
sudo ip netns exec cli ping -c 2 198.51.100.2

十四、可选 DHCPv4 隔离实验 ​

可在统一拓扑中临时让 cli 通过 rtr 上的 dnsmasq 获取地址，但这会修改 client 的静态地址和默认路由。执行前应记录原配置，并确保操作对象是实验 namespace。

bash
# [未在当前环境执行] 先记录并清空实验 client 的 IPv4 配置
sudo ip -n cli -4 address show dev veth-c
sudo ip -n cli -4 route show
sudo ip -n cli -4 address flush dev veth-c
sudo ip -n cli -4 route flush table main

# 在 rtr 启动受接口约束的 DHCP 服务
sudo ip netns exec rtr dnsmasq \
  --no-daemon \
  --interface=veth-rc \
  --bind-interfaces \
  --dhcp-range=192.0.2.100,192.0.2.150,255.255.255.0,10m \
  --dhcp-option=3,192.0.2.1 \
  --dhcp-option=6,192.0.2.1

在另一个终端抓 DORA 并启动客户端。客户端命令可能是 dhclient、NetworkManager 或 systemd-networkd，取决于发行版：

bash
sudo ip netns exec rtr tcpdump -ni veth-rc -vv \
  'udp port 67 or udp port 68'

# 仅在安装 ISC dhclient 的环境：
sudo ip netns exec cli dhclient -v veth-c

预期依次看到 Discover、Offer、Request、ACK，并在 cli 获得 192.0.2.100/24 范围地址和默认路由。实验结束后停止 dnsmasq/DHCP 客户端，再按第 20 章恢复静态地址；不要在真实接入网络启动未经授权的 DHCP 服务器。

十五、故障排查方法 ​

1、DHCPv4 ​

text
客户端是否发 Discover？
  ├─ 否：接口、客户端服务、VLAN、链路
  └─ 是：服务器/Relay 是否收到？
       ├─ 否：广播域、Relay、ACL、防火墙
       └─ 是：服务器是否发 Offer？
            ├─ 否：地址池、策略、Option 82、租约数据库
            └─ 是：客户端是否收到并 Request/ACK？
                 ├─ 否：回程、Relay、交换安全策略
                 └─ 是：检查地址/掩码/网关/DNS及冲突

常用证据：

bash
ip -br address
ip route
journalctl -u NetworkManager -u systemd-networkd --since '-10 min'
tcpdump -ni any -vv 'udp port 67 or udp port 68'

2、NAT/conntrack ​

  1. 记录原始五元组、预期转换 tuple、方向和时间。
  2. 在转换前后接口双点抓包。
  3. 查看路由查找结果，确认报文实际经过 NAT 节点。
  4. 查看 nftables 规则顺序、handle 和计数器。
  5. 查看 conntrack 原始/应答 tuple、状态和超时。
  6. 检查 nf_conntrack_count 与 nf_conntrack_max，以及内核 drop/insert failed 日志。
  7. 区分新连接与存量映射，避免被旧状态误导。
  8. 若为云 NAT，结合流日志、网关指标、端口配额和跨区路径。

Linux 观测示例：

bash
sysctl net.netfilter.nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max
conntrack -S
nft -a list ruleset
ss -s

这些键和工具是否存在取决于内核配置、模块和发行版；容器内看到的 namespace 也可能不是实际执行 NAT 的 namespace。

十六、常见问题 ​

1、为什么内网能访问公网，公网不能主动访问内网？ ​

常见出站 NAPT 只为内网发起的流创建映射；未经允许的入站报文没有匹配映射，并可能被状态防火墙丢弃。要提供入站服务，需要 DNAT/端口映射、路由、防火墙和应用监听同时正确。

2、NAT 后为什么日志里所有用户都是一个 IP？ ​

因为地址在边界被共享。若需要审计，应在可信入口记录原始连接信息，或保存 NAT 转换日志中的公网地址、端口、协议和精确时间。只记录公网 IP 不足以区分 CGNAT 用户。

3、为什么改了 NAT 规则仍不生效？ ​

已有连接可能继续使用旧 conntrack binding。先用全新源端口/连接验证，再决定是否需要有计划地排空状态。不要直接清空生产 conntrack。

4、为什么 UDP “连接”在 NAT 后会失效？ ​

UDP 没有 TCP 握手/关闭，NAT 只能根据流量和超时维护映射。静默超过设备超时后映射可能消失，需要协议心跳、重新探测或 TURN 等机制；具体间隔应通过目标网络实测。

5、IPv6 为什么拿到地址却没有默认路由？ ​

地址可能来自 DHCPv6 或手工配置，但默认路由通常来自 RA。检查 ICMPv6 是否被错误阻断、RA 是否到达、主机是否接受 RA，以及路由器生命周期。

十七、安全风险与加固 ​

DHCP ​

  • 未授权 DHCP 服务器可下发恶意网关/DNS；使用 DHCP Snooping、端口信任和准入控制。
  • 地址池耗尽攻击可伪造大量客户端标识；限制接入口速率和租约，结合认证。
  • Option 82 等信息应只由可信 Relay 写入并在服务端校验。
  • DHCP 不提供配置机密性；高价值身份不能只依赖分配到的地址。

NAT/conntrack ​

  • conntrack 表耗尽会让新连接失败；设置容量告警、速率限制和抗攻击策略。
  • 端口映射暴露服务时，必须另配最小化防火墙规则和身份认证。
  • 自动端口映射协议需限制管理域与权限，避免意外暴露。
  • NAT 日志可能包含用户行为和标识，应限制访问、保留周期并满足隐私要求。
  • ALG/helper 解析应用载荷会扩大攻击面，应只启用确有需要且已维护的模块。
  • 不要通过极端缩短超时缓解容量问题，否则会破坏长连接和静默 UDP 会话。

十八、性能与容量指标 ​

指标意义告警思路
DHCP 地址池利用率可分配地址余量按增长速率和租期预测耗尽
Discover/Offer/ACK 比率分配流程健康度Discover 增长但 Offer/ACK 不增长
租约分配延迟接入体验p95/p99 与失败率
conntrack count/max状态表容量持续高水位而非单点阈值
new/invalid/drop新流与异常结合流量基线和攻击事件
NAT 端口利用率出口映射容量按公网 IP、目的和协议拆分
新建连接失败率用户影响与端口/conntrack/应用错误关联
映射创建速率与寿命churn识别短连接和重试风暴

十九、实现、版本与厂商差异 ​

  • DHCP 客户端由 NetworkManager、systemd-networkd、dhclient、云平台代理等实现时，日志、重试和 lease 文件位置不同。
  • IPv6 RA M/O 标志的解释和 DHCPv6 支持在操作系统间存在差异。
  • nftables、iptables legacy、iptables-nft 和云安全策略可能同时存在，排障必须确认实际数据路径。
  • Linux conntrack timeout、表大小、hashsize 和计数器依内核与模块不同。
  • 家庭路由器、企业防火墙、Kubernetes、服务网格和云 NAT 对 UDP 映射、Hairpin、端口保留、源地址保留的行为不同。
  • 云厂商的 NAT 网关容量、配额、容灾、日志字段和计费会变化，必须以目标地域和产品版本文档为准。

二十、关联章节 ​

检索关键词 ​

DHCP DORA Discover Offer Request ACK DHCP Relay giaddr Option 82 DHCPv6 RA SLAAC 默认路由 SNAT DNAT NAPT PAT Hairpin NAT 回程 Linux conntrack ct state nftables nat prerouting postrouting NAT 端口耗尽 CGNAT 100.64.0.0/10 STUN TURN ICE NAT64 DNS64 nf_conntrack_count nf_conntrack_max

权威来源 ​

本章于 2026-09-07 对照 RFC 与 Linux Netfilter 官方资料完成核验。netns、nftables、conntrack 和 DHCP 隔离实验因当前验证主机为 macOS 而明确标记为未执行；实际输出需在目标 Linux 内核与工具版本上复现。

ICP 备案号待补充 · Gitee 主页

Copyright © 2024-2026 MyNote