Azure App Service连接本地SQL数据库配置问题咨询

1. 连通所需的额外配置规则 #

你现在直接填VPN客户端分配的172.16.254.2连不通，核心原因是默认配置下App Service根本没接入你的VPN链路，不是单纯配防火墙就能解决的，需要补全以下配置：

• 本地侧配置
  • 居家电脑的系统防火墙、第三方安全软件必须放开1433端口的入站规则，源地址段要覆盖Azure VNet网段、VPN网关P2S地址池网段，不能仅允许本地局域网访问。
  • 打开SQL Server Configuration Manager，确认对应实例的TCP/IP协议已启用，TCP监听端口固定为1433（关闭动态端口），同时SQL Server已开启SQL身份验证模式，你创建的Service Account已被授予目标数据库的对应访问权限。
  • 确认家用路由器没有拦截VPN拨入段到你电脑的转发流量，不要开AP隔离类的拦截规则。
• Azure侧配置
  • 必须给App Service配置VNet集成，将App Service接入VPN网关所在的同一个VNet，否则App Service默认走公网出口，根本无法访问172.16.254.2这类私网地址。
  • 检查VNet路由表，确认P2S VPN的路由已正确传播到App Service集成使用的子网，没有被用户自定义路由（UDR）强制导去公网。
  • 在App Service应用设置里添加参数WEBSITE_VNET_ROUTE_ALL = 1，强制所有私网流量走VNet集成链路，避免私网流量默认走公网出口直接丢包。
  • 修正连接字符串格式：SQL Server的端口分隔符是逗号不是冒号，IP:1433是其他数据库的写法，SQL Server正确写法示例：Data Source=172.16.254.2,1433;Initial Catalog=你的数据库名;User ID=你的服务账号;Password=对应密码;Encrypt=True;TrustServerCertificate=True。

2. Azure侧测试本地SQL连通性的方法 #

所有测试都要测TCP 1433端口，不要用ping测ICMP协议——ICMP默认会被VPN网关、防火墙拦截，测试结果没有参考价值：

• 用App Service自带控制台测试：进入App Service门户页，打开「开发工具」-「控制台」，执行命令tcping 172.16.254.2 1433，如果返回探针成功的结果，说明网络层连通；如果全是超时，就是链路配置有问题。
• 同VNet虚拟机旁路测试：在VPN网关所在VNet里临时创建一台Windows虚拟机，在虚拟机里装SSMS直接连172.16.254.2的SQL实例。如果这台VM都连不上，问题出在VPN网关路由、本地防火墙配置，和App Service无关；如果VM能连但App Service连不上，问题定位在App Service VNet集成的配置上。
• 用App Service诊断工具测试：打开「诊断和解决问题」，搜索出站连接测试，目标地址填172.16.254.2、目标端口填1433，工具会直接定位故障点：是NSG拦截、路由缺失，还是对端无响应。

3. Hybrid Connection（混合连接）方案说明 #

你的场景（连接单台居家办公电脑上的SQL，没有固定本地机房的站点网关）其实更适合用混合连接方案：

• 不需要强制部署混合连接，如果你能把前面说的VNet集成、路由、防火墙规则都配通，VPN方案也能用，但配置复杂度高，VPN网关的运行成本也更高。
• 如果采用混合连接方案，完全可以不再使用现有VPN网关和本地VPN客户端：混合连接的原理是你在本地电脑上安装Hybrid Connection Manager代理，代理主动通过公网443端口和Azure中继服务建立长连接，不需要你配置VPN、不需要开公网入站端口，只要本地电脑能正常访问公网就能用。
• 混合连接配置步骤非常简单：在App Service的「网络」菜单里找到混合连接入口，新建终结点时目标地址填你居家电脑本地网卡的局域网IP（比如192.168.1.xxx）、端口填1433，然后在本地电脑装完代理绑定对应连接即可，基础层App Service自带的混合连接配额足够覆盖这个场景，使用成本远低于VPN网关。

内容的提问来源于stack exchange，提问作者Todd T