云服务器一般只分配私网 IP，外部想访问，就得经过公网地址转发。把公网 IP 和端口对应到内网 IP 和端口，这种做法就是端口映射。阿里云上常见的场景有三类：外部访问内网的 Web 服务，通过非标准端口远程管理服务器，或者把几台实例的服务收到同一个公网入口。
很多团队一开始是给每台 ECS 都绑定公网 IP。实例一多，地址要记，安全组要改，审计也散了。入口集中之后，后端实例就不必直接暴露在公网上，这是端口映射最实在的好处。
两种实现方式
阿里云上做端口映射，基本有两条路。
- 公网 NAT 网关的 DNAT 规则：在 VPC 里创建公网 NAT 网关，绑定弹性公网 IP，再添加 DNAT 条目，把公网 IP 的某个端口转到指定 ECS 的内网 IP 和端口。实例上不需要额外配置，适合放在生产环境。
- ECS 本地的 iptables 转发：在一台有公网 IP 的 ECS 上开启 IP 转发，用 iptables 配置 DNAT 和 MASQUERADE，把流量转给内网其他主机。自由度高，但规则的持久化和维护都要自己管，更适合测试环境或预算紧张的小规模部署。
选哪条路，主要看团队有没有人手盯规则。托管方案出了问题，通常是查云上的配置和工单；自建方案出了问题，可能要逐台翻系统。两者各有代价，选的时候把这部分算进去。
一个假设的整改例子
下面用一个假设的场景说明思路。设想一家做在线教育的团队，有三台后端 ECS，分别跑课程服务、直播转码和后台管理。早期每台机器都对外开放了 22 端口，方便运维远程登录。规则越加越乱，其中一台因为弱密码被扫描器盯上。
整改思路是先在 VPC 内放一台跳板机，作为唯一的远程入口。然后用公网 NAT 网关，把公网 IP 的 2201、2202、2203 分别映射到三台后端的 22 端口。运维通过不同端口连接不同机器，每台后端的安全组只放行可信的运维来源。这里有个细节要注意：按阿里云 DNAT 的常见行为，访问者的真实源 IP 会被保留，安全组要按这个来源来写，所以放行规则应填运维的出口 IP。上线前用实际连接确认一次比较稳妥。
改完之后，公网上能被扫到的入口少了，排障时也能根据端口直接判断目标机器。在这个例子里，端口映射只是手段，真正的收益是入口收窄了。
配置步骤
大致步骤如下，每一步都有容易踩的地方。
- 确认 ECS 所在的 VPC 和交换机，记下目标实例的私网 IP。后面填规则时，抄错一位数字都会导致映射失效。
- 创建公网 NAT 网关，绑定一个弹性公网 IP。网关需要和目标实例处于同一个 VPC。
- 在 NAT 网关里添加 DNAT 条目，填写公网 IP、外部端口、内网 IP 和内部端口，协议按业务选 TCP 或 UDP。
- 检查目标 ECS 的安全组，只放行明确的来源。管理端口不要图省事直接对 0.0.0.0/0 开放。
- 登录 ECS 确认服务的监听地址。如果服务只绑定 127.0.0.1，映射规则再正确也访问不到。
- 从外部网络实际测试，并查看服务日志，确认请求确实到达，来源也符合预期。
第五步最容易被忽略。很多应用默认只监听本地回环地址，规则配完看上去没问题，访问却一直超时。排查时先用 ss -lntp 看一下监听情况，能省下不少时间。
安全边界
端口映射等于把内网服务往公网上推，安全措施要跟着走。
- 外部端口可以避开 22、3306 这类常见默认端口，但这只能降低被随机扫描的概率，不能替代认证。真正的防线还是密钥登录、强密码和来源限制。
- SSH、数据库这类管理端口，优先限制来源 IP，或者改为通过堡垒机、VPN 接入，不要长期裸露在公网。
- 打开云监控和日志审计，重点关注异常连接数、失败登录，以及突然增多的新来源。
- 业务下线或服务迁移后，及时删除对应的 DNAT 条目。遗留规则没人记得，最容易变成隐患。
如果用的是 ECS 上的 iptables 方案，还要确认重启后规则是否持久化，并理清它和 firewalld、安全组之间的生效顺序。两层规则叠加时，最常见的情况是一边放行了，另一边还在拦截，排查时容易绕进去。
怎么选
长期运行的业务，优先用公网 NAT 网关的 DNAT，再配合严格的安全组和访问控制。临时调试或实验环境，ECS 上的 iptables 转发够用，但要把规则记录下来。无论选哪种，先想清楚要暴露哪个服务、暴露给谁，再动手配置。
