这次改造到底要解决什么？
一台 Ubuntu 服务器原来通过唯一的墙口网线直接接入受管理的上游交换机，服务器有固定网络 地址，大家习惯直接用这个地址 SSH、连网页服务和 API。后来要在网线中间插入一台 TP-LINK TL-R5408，再接入一台或多台 AP。困难在于：
- 无法管理上游交换机，不能指望额外申请一个上游 IP；
- 不希望现有用户更改 SSH 地址。
最终采用的是「路由器接管原对外 IP + 服务器迁入私网 + 按需 DNAT 端口映射」方案， 而不是在上游直接展开多个 LAN 设备。这样上游只需要面对路由器 WAN 的单个地址；服务器 自身 IP 改变，但服务入口得以维持。
拓扑中三个不同的地址
| 角色 | 文档化示例 | 作用 |
|---|---|---|
| A：原对外地址，现在由 R5408 WAN 持有 | 198.51.100.10/24 | 原 SSH / API 接入入口；仅作示意 |
| B：R5408 LAN 网关 | 192.168.50.1/24 | 内网网关、DHCP、NAT |
| C：Ubuntu 服务器新地址 | 192.168.50.10/24 | 私网 SSH / Web / API 实际服务主机 |
这里的 198.51.100.10 是虚构示例（RFC 5737 文档专用段），真实配置必须使用网络管理员
授权的 IP、掩码和网关。路由器中的 WAN MAC 自定义字段只能改变上游看到的以太网源 MAC，
不能代替网络接入许可或 802.1X/NAC 认证。
关键选择：为什么没有继续纠结 VLAN？
起初考虑过保留服务器原 IP、通过单网卡 VLAN 和服务器 NAT 把 AP 网络隔离出去。这在具有 明确 802.1Q Trunk/Access 能力的受管交换机下可行，但不能仅因为设备有 VLAN 相关菜单，就 认定 R5408 能胜任所需的二层混合端口设计。本次不增加硬件，选择可实测验证的常规 WAN/LAN 路由方案。
代价也必须交代：原 IP 现在属于路由器，不属于 Ubuntu；只对映射过的服务保持原访问入口， 广播协议、全部 ICMP 以及未映射端口不能视为透明透传。
端口映射清单
在路由器「虚拟服务器」中增加的 TCP 映射（迁移时的实测配置记录）：
| 入口（WAN） | 后端（Ubuntu） | 用途 |
|---|---|---|
A:22 | C:22 | SSH / SFTP / VS Code Remote |
A:443 | C:443 | HTTPS（按需） |
A:8443 | C:8443 | 反向代理入口（按需） |
A:30001 | C:30001 | API（按需） |
这四条是本次实验的记录，不是标准答案。生产环境应只开放确有必要的入口，做好鉴权、 来源限制和日志审计；不建议一开始启用 NAT-DMZ 或 UPnP。
AP 客户端访问优先用服务器内网地址 C；若软件把原地址 A 写死，则依赖路由器的
NAT 回环（NAT Loopback）。先让「环回地址」采用默认行为，最后实测两侧的 SSH 连接，
而不是把一个空字段当作保证。
下一篇记录具体迁移步骤：路由器离线配置、Ubuntu 的 Netplan 改造，以及双路 SSH 验证。