我们有一个内部部署的cisco负载均衡器，它将流量路由到我们的DMZ服务器内部
我们希望使用Azure负载均衡器或Azure解决方案（AG），它可以在内部平衡我们的DMZ服务器的流量，基本上用Azure取代CISCO
有可能吗？我们目前在我们的DMZ环境中托管了SFT / HTTPS站点。
TIA
答案 0 :(得分：1)
您提出的建议不是应用程序网关的用例。应用程序网关是第7层负载平衡器/反向代理。您想要做的就是将它们视为单站点转发代理。它不是一个好的架构，即使从长远来看最终也会成本更高，因为当你的App Gateway接受请求然后通过出站连接转发到你的web服务器时，你会为数据出口付费通过互联网。然后，他们从您的Web服务器接收响应标头/正文，并再次将结果发送给原始调用者。
在这种情况下，您不得不为应用程序使用端到端SSL，从而消除了将来使用App Gateway进行SSL卸载的任何可能性。如果您的流量未加密或不需要，则流量来源和目的地的可预测性会增加您网站用户和贵公司的安全风险。
您还可以了解此类架构可能带来的安全隐患。您的Web服务器至少仍然需要由您的应用程序网关访问，这意味着它们无论如何都可以在Internet上免费获得（在这种情况下，为什么还要使用应用程序网关）或者他们需要在防火墙上进行防火墙处理。单层，仅允许来自Application Gateway的源IP地址的流量。
防火墙方法的坏消息是您无法将静态公共IP地址分配给Application Gateway，它被强制为动态。实际上，在重新启动应用程序网关之前，公共IP不会发生变化，但您应该知道，当他们这样做时，您的防火墙规则是错误的并且您的应用程序网关无法访问您的应用程序网关DMZ服务器不再存在，这意味着停电。唯一真正的解决方案是可以执行基于URI的防火墙规则的防火墙......执行DNS查找的成本（时间和CPU）的影响，查看流量是否来自App Gateway的DNS地址 - 某事比如 bd8f86bb-5d5a-4498-bc0c-e1a48b3873bf.cloudapp.net 然后允许或拒绝请求。
如上所述，进一步的安全考虑因素是您的流量将始终来自一个位置（应用程序网关）并到达您的DMZ。如果有明确定义的流量来源，那么这个事实可能会用于攻击您的服务器/ DMZ。虽然我确信攻击这一点并非易事，但是通过在互联网上预测源和目标流量会损害您的安全状况。
我现在已经为企业应用程序配置了大量的应用程序网关，出于病态的好奇心我已经开始使用HTTP来配置一个非常基本的应用程序网关来做你正在尝试的事情 - 幸运的是（是的，幸运的是，我收到了HTTP 502，所以我要说这是不可能的。我要补充一点，我很高兴这是不可能的，因为它是一个坏主意（TM）。
我的建议是，您要么将DMZ服务器迁移到Azure（以获得最佳性能/网络延迟），要么实施VPN或（最好）ExpressRoute。然后，您将能够使用正确的体系结构部署应用程序网关，以终止您的用户＆＃39; App Gateway上的连接，并将您的RFC1918网络中的请求重新传输到您的DMZ服务器，这些服务器在网络内响应App Gateway并最终返回给请求者。
很抱歉，这不是你想听到的。如果您决定这样做，也许可以nginx进行？