ALB与NAT网关协同架构实践：隐藏后端服务的网络隐身术

一、背景

当前，云原生开发已成为众多企业和项目的趋势。然而，许多团队的部署仍处于“裸装”状态——服务器、数据库等资源直接暴露于公网。这种情况下，暂且不论应用服务层面的漏洞，光是每天海量的SSH暴力破解、数据库root账户的撞库攻击就足以令人头疼。即便设置了复杂的密码策略，一想到被破解的可能性，也不免让人心头一紧。

从本质上讲，这些暴力攻击都属于网络攻击范畴。对抗网络攻击，无非从“出栈”和“入栈”两个方向进行防御。那么，有没有办法能做到对这两个方向的流量都进行限制呢？

• 出栈：服务器可以主动访问外部（出栈），但在互联网世界中，外部无法通过服务器出栈时使用的身份反向追踪并直接连接（入栈）到服务器。
• 入栈：外部只能通过特定的、受严格管控的应用服务入口（如负载均衡器）合法地访问（入栈）。对服务器本身的直接入栈访问，则必须经由云平台提供的安全通道。

实现这两点，对服务资源的防护就达到了一个相对安全的水平。本文将介绍如何在云平台上，结合NAT网关与ALB（应用负载均衡器），将我们的后端服务资源从互联网的“视野”中隐藏起来，从而构建更高级的防御层。

二、什么是NAT网关？

1. 概念和功能

NAT（网络地址转换）网关是一种在网络中执行地址转换功能的网络设备或服务。它能将私有IP地址转换为公有IP地址（SNAT），使VPC内的资源能够安全地访问互联网，同时隐藏内部网络的实际拓扑结构。反之，它也能将公有IP的入站流量转换到私有IP（DNAT），允许外部访问特定的内部服务。

简而言之，NAT网关让私有子网中的实例可以连接到VPC外部的服务（如互联网），但外部服务无法主动发起与这些实例的连接。这实现了 “只出不进” 的单向通信，是隐藏服务器、提升出栈安全的关键组件。

2. 工作原理

默认情况下，部署在公有子网中的服务器，其网络流量由路由表控制：出栈流量被路由至互联网网关（IGW），入栈流量则从IGW路由回服务器。

其协作关系如下图所示：

IGW是VPC连接互联网的必备出口。而NAT网关并非必需，它是在需要提高资源安全性或隐藏服务器IP时才引入的。需要注意的是，NAT网关本身也需要通过IGW访问互联网。

其具体协作关系如下：

我们可以用一栋写字楼来形象地类比NAT与IGW的关系，帮助理解它们的不同角色：

三、基于NAT隐藏服务器

1. 创建NAT网关

创建NAT网关时，若需要其提供公网访问能力，务必选择“公有”类型，并且子网必须选择公有子网（因为只有公有子网的路由表默认关联了IGW）。同时，需要为其分配一个弹性公网IP（EIP）。在一些特定场景，例如需要支付服务商将你的IP加入白名单时，就可以提供这个EIP地址。

2. 配置路由表

接下来，需要修改私有子网所关联的路由表。添加一条路由规则，将目标为 0.0.0.0/0（即所有非本地流量）的下一跳指向刚刚创建的NAT网关。这样，所有位于该私有子网内的服务器出栈流量，都会被统一导向NAT网关进行处理和转发。

3. 创建服务器并绑定私有子网

创建新的云服务器实例时，选择之前配置好的私有子网，并务必禁用“自动分配公网IP”选项。

关键点在于：确保你选择的私有子网，其绑定的路由表已经正确配置了指向NAT网关的默认路由规则。

4. 创建终端节点（用于管理）

没有公网IP的服务器，默认无法从互联网直接通过SSH等方式连接。此时，需要创建VPC终端节点（Endpoint）来提供一条安全的内部通道。

创建一个类型为“AWS服务”（或其他云厂商对应服务）的接口型终端节点，选择EC2服务，并指定终端节点所在的子网及合适的安全组（需确保该安全组允许来自管理终端的SSH端口访问）。

创建完成后，在云控制台连接服务器时，选择“使用私有IP连接”，并选取刚才创建的终端节点，即可通过内网隧道安全地登录和管理服务器。

四、使用ALB透出API

ALB（应用型负载均衡器）工作在应用层（第七层），能基于HTTP/HTTPS请求的内容（如头部、路径）智能地将流量分发到后端服务器。它支持复杂的路由规则，是高可用、弹性伸缩应用的核心组件。

之所以引入ALB，是因为它本身具备公网能力，且与后端服务器处于同一VPC内，可以通过内网进行通信。这意味着，我们可以通过ALB的公网IP或域名对外暴露API服务，而后端服务器则完全隐藏在ALB之后，通过内网接收请求。从外部视角看，通过traceroute等工具追踪请求路径，到达ALB层就会终止，后续的内网跳转无法被探测，从而有效保护了后端服务器的真实IP。

相比于直接使用服务器公网IP提供服务，ALB能有效阻断许多低级别的网络侦察和攻击。例如，攻击者通过域名解析到IP后，可能会扫描开放端口，并使用工具对SSH、MySQL等服务进行暴力破解。而使用了ALB后，后端服务器的IP被隐藏，这类直接针对服务器的扫描和暴力破解就失去了目标。即使ALB遭受攻击，那也是云平台需要应对的基础设施层面攻击，与我们的业务服务器无关。

当然，具备类似或更强大能力的服务不止ALB，各大云厂商的API网关也是优秀的选择。此外，ALB还能与云平台的WAF（Web应用防火墙）、DDoS防护（如AWS Shield）等安全服务深度集成，提供针对XSS、SQL注入、跨站请求伪造等应用层攻击以及SYN洪水等网络层攻击的防护。

因此，通过ALB这类云原生服务，我们可以从“入栈”维度极大提升安全性，让后端服务器在不暴露公网IP的前提下，依然能稳定可靠地对外提供服务。

五、总结与更深层的思考

结合NAT网关和ALB对VPC内资源进行改造后，能够规避和防御绝大多数的端口扫描、暴力破解等网络攻击。改造后的理想架构状态大致如下：

从网络流量的“入栈”和“出栈”两个路径进行封锁，上述方案确实提供了强有力的防护。然而，这是否意味着我们的系统就固若金汤、无懈可击了呢？答案显然是否定的。

对于专业的攻击者而言，粗暴的密码破解已是“小儿科”。当前更流行的是利用应用框架或中间件漏洞的“内存马”和“反弹Shell”攻击。这不是网络层的防御能完全解决的。

现实是，为了提升开发效率，大多数项目都会使用各种开源框架、中间件和工具。这本身无可厚非，但随之而来的是层出不穷的安全漏洞，其中危害最大的当属RCE（远程代码执行）类漏洞。

以常见的Nacos、xxl-job、RocketMQ为例，其漏洞报告触目惊心：

Nacos漏洞示例：

xxl-job漏洞示例：

RocketMQ漏洞示例：

借用一张分析xxl-job攻击路径的示意图，我们可以清晰地看到攻击如何绕开网络防护：

攻击者可能无法探测你的服务器IP，但你的应用框架存在漏洞。攻击者将恶意代码伪装成正常业务请求，通过ALB进入你的应用。你的服务器虽然受NAT保护，无法被外部直接连接，但攻击代码已在你的服务器内存中执行，并可能通过“反弹Shell”的方式，让你的服务器主动去连接攻击者控制的“命令与控制服务器”。至此，精心构建的ALB和NAT防护层被完全绕过。

这正应了那句话：“道高一尺，魔高一丈”。在安全领域，没有一劳永逸的“完美”方案，只有持续的对安全的极致追求。除了加固网络架构，持续关注行业动态，及时更新和修补所使用的开源组件，同样是每一位开发者与运维人员不可或缺的责任。在云栈社区这样的技术交流平台，与同行保持沟通，共享安全实践，或许能让你在潜在的风险来临前，更早地做好准备。