如何使用 NSG 限制从 Internet 直接访问 Azure Public LoadBalancer 后端池 VM

Posted 2023-02-19

【中文标题】如何使用 NSG 限制从 Internet 直接访问 Azure Public LoadBalancer 后端池 VM

【英文标题】：How to restrict direct access from internet to Azure Public LoadBalancer backend pool VM with NSG

【发布时间】：2020-04-19 20:19:27

【问题描述】：

作为标题中的问题，我在 Azure Cloud 上设置了以下架构，并且在限制从 Internet 直接访问 VM 时遇到了问题。

以下是架构要求：

两个虚拟机都必须有公共 ip（系统管理员才能通过 SSH 访问） 必须拒绝从 Internet 到 VM 上的 WebService 的直接流量（通过端口 80） 来自 Internet 的 Web 流量必须通过公共 LB 到 VM

假设两个虚拟机都在 WebASG（应用程序安全组）中，在应用于虚拟机子网的 NSG 设置中，我添加了一些规则（其优先级高于 3 个 Azure NSG 默认规则）：

场景 A（添加 1 条自定义规则）：

端口：80 - 协议：Tcp - 来源：Internet - 目的地： WebASG - 操作：允许

使用此 NSG 设置，我可以从 LoadBalancer IP 访问 WebService（满足 #3 要求），但两个 VM 的端口 80 上的 WebService 将暴露给 Internet（违反 #2 要求）

场景 B（添加 2 条自定义规则）：

端口：80 - 协议：Tcp - 来源：AzureLoadBalancer - 目的地：WebASG - 操作：允许

端口：80 - 协议：Tcp - 来源：Internet - 目的地： WebASG - 操作：拒绝

使用此 NSG 设置，满足 #2 要求，但访问 LoadBalancer IP 时无法访问 WebService（违反 #3 要求）

请注意：使用 AGW（Azure 应用程序网关，我可以通过这些 NSG 配置实现所有要求：

RuleName：AllowSSH 端口：22 - 协议：Tcp - 来源： sys-admin-ip-address - 目的地：WebASG - 操作：允许

RuleName：DenyInternet2Web 端口：Any - 协议：Any - 来源：Internet - 目的地：WebASG - 操作：拒绝

RuleName：AllowProbe2Web 端口：80 - 协议：Tcp - 来源：VirtualNetwork - 目的地：WebASG - 操作： 允许

RuleName：AllowProbe2Web 端口：80 - 协议：Tcp - 来源：VirtualNetwork - 目的地：WebASG - 操作： 允许

我不想使用 AGW，因为它会比 Azure LoadBalancer 花费更多的钱（实际上 Basic LoadBalancer 是免费的）。那么，在使用 LoadBalancer 时如何更改 NSG 以满足所有要求？

提前感谢您的帮助！

【参考方案1】：

我认为没有 NSG 规则可以满足所有要求，因为 #1 和 #2 要求是矛盾的。

如果虚拟机必须有公共 IP 地址，它实际上有机会暴露在互联网上。任何客户端都可以通过公共 IP 访问虚拟机。如果您想通过负载均衡器前端 IP 访问虚拟机，它的工作原理相同。阅读https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-overview#load-balancer-concepts

负载均衡器不会终止或发起流，与 流的有效负载，或提供任何应用层网关 功能。协议握手总是在客户端之间直接发生 和后端池实例。对入站流的响应是 总是来自虚拟机的响应。当流量到达 虚拟机，原来的源IP地址也被保留了。

在这种情况下，您可以删除后端实例 IP 地址，只需将负载平衡器前端用于 Web 流量和 SSH 连接。如果是这样，您可以configure port forwarding in Azure Load Balancer 用于与单个实例的 SSH 连接，并在此quickstart 之后为 Web 流量设置负载均衡器规则，它适用于标准 LB。您只能允许来自客户端 IP 地址的端口 80 和 22。 NSG 将如下所示，

端口：80,22 - 协议：Tcp - 来源：客户端的IP列表 - 目的地：WebASG - 操作：允许

【讨论】：

感谢您的宝贵时间。我更新了这篇文章，以展示 Azure 应用程序网关如何满足所有要求。在我看来，ApplicationGateway 和 LoadBalancer 必须以相同的方式工作（以它们都站在前端，接受客户端请求，转发到后端虚拟机，获得响应，然后将响应返回给客户端的方式......所以他们会隐藏他们来自客户端的后端虚拟机）

不，APP GW 和 LB 的工作方式不同。 App GW 工作在应用层（第 7 层），而 LB 工作在传输层（第 4 层）。 NSG 规则使用 5 元组信息（源、源端口、目标、目标端口和协议）按优先级评估，以允许或拒绝流量。 LB 使用散列算法分配入站流，并将流的标头重写到后端池实例。

当 NSG 处理 Web 流量时，对于 LB 流，它不终止或发起流，不与流的负载交互，也不提供任何应用层网关功能。协议握手总是直接发生在客户端和后端池实例之间。但是APP GW流量，它充当反向代理服务。这将终止客户端连接并将请求转发到后端。参考the difference

我知道 AGW 在第 7 层运行，LB 在第 4 层运行，但是在我使用 LB 的用户案例中，我只需要一个功能：将 VM 后端隐藏在 LB 后面。使用 LB，我同意协议握手总是在客户端和后端池实例之间直接发生，但这并不意味着客户端被重定向到后端 VM 的 IP。由于这个doc，LB 总是站在客户端和后端 VM 池之间转发数据包，LB 只编辑数据包中的源/目标 IP（所以，这就是为什么“对于 LB 流，它不会终止或发起...... "。

but it does not mean the client is redirected to the backend VM's IP. 是的，我同意。比如client1通过LB前端IP向后端发送请求，会生成一个流source client1, source port, protocol, destination LB IP, destination port。当使用入站 NAT 规则访问负载均衡器时，它将更改为 source client1, source port, protocol, destination VM IP, dest port，但传入流量的源 IP 不会更改，NSG 规则仍使用入站中的 相同源 IP 进行评估规则。无论是否使用 LB，对于 NSG 规则的客户端，它的工作方式都是一样的。