从Azure的Web应用程序(通过Azure的S2S VPN)本地的SQL Server查询失败

问题描述 投票:0回答:1

我们的基础设施团队一直在努力来配置我们的Azure订阅我们的预置型防火墙,基本上按照these steps之间的站点到站点VPN Azure的连接。为了验证这一点,我们已经创建了一个简单的Azure的Web应用程序,使针对位于的预置型防火墙后面的一个SQL Server的查询。

这个Web应用程序没有问题,在本地工作。此外,相同的代码和连接字符串,当作为控制台应用程序并运行Azure的虚拟机上编译,正常工作为好。但是,当部署到Azure中的Web应用程序,到SQL Server连接失败:

[Win32Exception(0X80004005):等待操作超时]

[SQLEXCEPTION(0x80131904):在与SQL Server建立连接时出现与网络相关的或特定于实例的错误。服务器未找到或无法访问。验证实例名称是否正确,以及SQL Server配置为允许远程连接。 (提供者:TCP提供程序,错误:0 - 等待操作超时。)]

无论在Azure虚拟机和Web应用程序被配置为指向Azure的互联星空。这看起来似乎是防止Web应用程序从它的默认端口(1433)上的SQL Server通信。如果我打开了Web应用程序的调试控制台和使用默认端口(80),在SQL Server做tcpping,它成功返回。但tcpping端口出1433倍。

它不会出现在Azure网络安全小组阻止端口:

enter image description here

我发现的唯一的解决方案,与我们的具体的设置基本上可以归结为“use Azure Hybrid Connections instead”,这不会是我们的第一选择。

sql-server azure azure-web-sites azure-virtual-network azure-vpn
1个回答
2
投票

与微软的支持工作后,下面进行了更改,现在互联星空的整合工作。我为缺乏对其中一些细节的道歉,但我们的基础架构团队做了大部分的故障排除。我们希望,一些项目将有助于点别人为自己设置一个解决问题的方向:

  • 最初,连接正在通过公共互联网,而不是VNET集成和VPN制成。我们确定了互联星空整合是由于所使用的隧道型失败。 Azure的应用服务有一个要求,即隧道类型是SSTP。一旦我们改变了它和同步的网络,我们能够通过其专用IP到tcpping在SQL Server。
  • 我们注意到它必须允许在本地网络的点到站点的地址池。作为一种变通方法,我们决定使用新VNET集成(预览)。我们创建了一个空的子网,并能使用这一新功能。
  • 我们注意到则APP服务没有使用自定义DNS。要解决这个问题,我们添加的虚拟网络,并在应用程序设置(“WEBSITE_DNS_SERVER”)为Web应用程序的DNS。
© www.soinside.com 2019 - 2024. All rights reserved.