内部 ALB 配上公网 DNS 名称：真的暴露了吗

对内部负载均衡器做一次公网 DNS 查询，你可能拿回一个私有地址，这看起来像配置错误，直到你弄清楚这条记录是做什么用的。AWS 的文档说明，内部负载均衡器的名称可以公网可解析，而其节点只持有私有地址。解析器只回答了服务在哪里，它没有创建路由、没有开放安全组，也没有认证任何人。这个答案是不是问题，取决于你能按顺序核对的事实。

第一步：读 Scheme，而不是读 IP

Scheme 字段是负载均衡器自己对边界的声明。aws elbv2 describe-load-balancers --names app-internal 会返回值为 internal 或 internet-facing 的 Scheme，并附带 IPv4 或双栈的地址类型。面向公网的负载均衡器同样可以转发到私有目标，所以看到私有后端地址并不能证明前端的情况。

在查看其他任何东西之前先把 Scheme 记下来，因为后面每一步判断都依赖它。它还决定了存在哪些控制手段，从安全组、监听器规则到该类负载均衡器的功能范围。从旧控制台截图里抄来的 Scheme 比没有记录更糟。重新从 API 读取，并把取值贴进工单。

第二步：看这个名称解析到哪里

从 VPC 外部用 dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com 查询，记下结果是否落在 10.0.0.0/8、172.16.0.0/12 或 192.168.0.0/16。公共解析器返回私有地址，对内部负载均衡器名称而言是预期行为；它不能证明该地址可从互联网路由。

从 VPC 内部解析同一个名称并做对比。如果两个答案不同，你看到的是分离视界命名，这个差异属于设计细节，不是泄露。

第三步：枚举能到达它的路径

私有地址从任何存在路由和安全规则的地方都能到达。要有意识地枚举这些路径：站点到站点 VPN、客户端 VPN、VPC 对等连接、中转网关挂载、Direct Connect，以及 VPC 内的任何代理或堡垒机。其中一条是预期路径，其余则是攻击者会去找的。

然后检查每条路径上的控制：负载均衡器上的安全组、子网上的网络 ACL，以及让路径得以存在的路由。多数被报告的内部服务暴露案例都在这里得到解释：要么存在非预期的对等连接，要么路径本就在设计之内，而应用没有认证。

第四步：分别测试监听器和应用

试着从不应到达该服务的网络连接，确认连不上。再从应当到达的网络连接，确认能到达监听器。这两个结果把网络可达性与应用行为分开，也是暴露问题唯一重要的证据。

能到达监听器不等于应用可访问。检查 TLS 证书和协议策略，再检查应用自身的认证与授权。一个接受企业 VPN 上任何调用方的内部工具，就等于暴露给该 VPN 上每一台被入侵的笔记本；这与面向公网的风险不同，但仍然是风险。

记住控制手段因类型而异。应用层防火墙只挂到一类负载均衡器，另一类并不支持，所以要确认你面前这个 Scheme 和类型实际可用的功能，而不是假定对等。

第五步：判断名称本身是否要紧

公网可解析可能泄露服务名、区域和地址段。把它当作有政策答案的信息披露问题，而不是自动事故：让敏感业务词不进入资源名，如果命名规范暴露得比你希望的多，就在风险记录中注明这次披露。

如果组织想要私有的命名体验，私有托管区域可以提供只在关联 VPC 内解析的别名。这会改变用户看到的名字；它不会让提供商生成的名称变成秘密，也不会移除任何网络路径。

不要试图通过固定地址来隐藏答案。负载均衡器地址会变化，固定地址会破坏 TLS 校验习惯，而你真正需要的控制是谁能建立连接、应用对他们有什么要求。核对这四项事实，写下来，问题就不再模糊。