.NET 8隔离式Azure Function连接SQL遇TCP及TLS错误排查求助

核心结论 #

问题根源集中在网络路由配置和TLS证书验证环节，代码层面无问题（已通过连接无VNet的SQL库验证）。以下是具体分析与修复项：

一、错误拆解与根源判断 #

1. 错误26（服务器找不到）

   • Kudu能解析地址和端口，说明DNS解析正常，但TCP连接的后续握手失败。本质是：
     • Function App未通过VNet集成接入SQL私有端点所在的网络环境，导致即使解析到私有IP，也无权限访问；
     • SQL服务器已禁用公共访问，而Function App未配置VNet访问路径。

2. 错误35（预登录握手失败）

   • 仅在Linux环境（Azure Linux应用计划、本地Linux容器）出现，核心原因是：
     • TLS证书验证不通过：SQL的证书基于公共DNS名称，用IP连接时证书SAN字段不包含IP地址，触发验证失败；
     • Linux系统CA证书链不完整，缺少Azure SQL的根证书（DigiCert Global Root CA），导致无法信任SQL服务器证书。

缺失的SQL配置项及Linux关联说明 #

1. SQL VNet防火墙与私有端点配置 #

• 必须添加Function App子网到SQL防火墙规则：在SQL服务器的「防火墙和虚拟网络」设置中，添加Function App集成的VNet子网，确保仅允许可信网络访问；
• 确认私有端点状态：检查SQL私有端点是否已成功关联到目标VNet，且状态为「已连接」；
• 禁用公共访问后必须走VNet路径：若SQL已启用私有端点，公共访问会被自动设为「拒绝」，此时Function App必须配置VNet集成（Linux应用计划支持此功能），接入能访问SQL私有端点的VNet。

2. TLS与证书信任配置（Linux环境特有） #

• 强制TLS 1.2版本：在连接字符串中显式添加参数，避免Linux系统默认TLS版本不匹配：

  Encrypt=True;TrustServerCertificate=False;TlsVersion=TLS1.2
  

• 解决IP连接的证书验证问题：若必须用IP连接，临时添加TrustServerCertificate=True（生产环境不推荐，存在安全风险），或改用私有DNS名称连接（确保证书SAN匹配）；
• 补全CA证书链：隔离式Linux Function App镜像可能缺少Azure SQL根证书，可在应用设置中添加WEBSITE_LOAD_CERTIFICATES，导入DigiCert Global Root CA证书，或在代码中通过自定义证书存储加载。

3. 私有DNS区域关联 #

• 确保Function App所在VNet已关联SQL的私有DNS区域（privatelink.database.windows.net），否则DNS解析可能指向公共IP，导致连接失败。

验证步骤 #

1. 检查VNet连通性：在Kudu中执行nc -zv <sql-server-name>.database.windows.net 1433，确认TCP端口能连通；
2. 测试TLS握手：执行openssl s_client -connect <sql-server-name>.database.windows.net:1433，查看证书是否有效、TLS版本是否为1.2；
3. 调整连接字符串：使用完整私有DNS名称+强制TLS参数测试，例如：

   // 托管标识连接示例
   string connectionString = "Server=tcp:<sql-server-name>.database.windows.net,1433;Initial Catalog=<db-name>;Encrypt=True;TrustServerCertificate=False;TlsVersion=TLS1.2;Authentication=Active Directory Managed Identity";
   

内容的提问来源于stack exchange，提问作者Garran Michaels