AWS网络ACL配置导致SQL Server连接中断问题求助

核心原因 #

你遇到的问题和SQL Server本身无关，是VPC网络ACL的双向流量控制特性加上Windows实例的临时端口范围导致的：

• 当实例W上的服务发起对SQL Server（实例S，1433端口）的连接时，W会随机分配一个源临时端口向S发送请求；
• 实例S收到请求后，会向W的这个临时端口发送回应流量；
• 你的共享网络ACL是子网级规则，当S的回应流量进入W所在的子网时，属于ACL的入站流量，目标端口就是W刚才用的临时端口；
• 如果你把ACL入站的临时端口范围限制为32768-65535，但实例W的临时端口范围包含1024-32767，那么当W用这个区间内的端口发起请求时，S的回应流量会被ACL拦截，导致连接失败。

为什么W会用1024-32767的端口？Windows系统的临时端口范围默认值因版本而异：

• Windows Server 2008及以后的默认范围是49152-65535，但如果系统被修改过（比如通过注册表调整），或者某些以管理员身份运行的服务使用了1024-49151之间的端口作为源端口，就会出现这种情况。

解决方法 #

你有两种可行的方案，都能保证SQL Server不暴露到公网：

方案1：调整Windows实例的临时端口范围到32768-65535 #

如果想严格限制ACL的端口范围，可以修改实例W的Windows临时端口范围，让它只使用32768-65535：

1. 以管理员身份打开命令提示符；
2. 执行以下命令修改临时端口范围：

   netsh int ipv4 set dynamicport tcp start=32768 num=32768
   netsh int ipv6 set dynamicport tcp start=32768 num=32768
   

3. 重启实例W使配置生效；
4. 此时就可以把网络ACL的入站临时端口范围改为32768-65535，同时保留实例S安全组对W安全组1433端口的允许规则。

方案2：保留网络ACL的1024-65535入站规则，无需修改端口范围 #

这个方案更简单，而且完全不会暴露SQL Server到公网：

• 网络ACL的1024-65535入站规则只是允许子网内的回应流量进入，而你的安全组已经严格限制了只有实例W的安全组能访问实例S的1433端口；
• 公网流量无法绕过安全组直接访问SQL Server，因为安全组是实例级的防火墙，已经把1433端口的访问限制在VPC内部；
• 网络ACL的这个范围只是保证VPC内部的双向连接正常，不会带来公网暴露的风险。

额外验证 #

可以通过以下步骤确认实例W的临时端口范围：
执行命令：

netsh int ipv4 show dynamicport tcp

查看输出中的Start Port和Number of Ports，就能知道当前的临时端口区间。

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