我们有一个托管在 AWS 上的 SQL 服务器，该 SQL 服务器不能直接在互联网上访问，它依靠 NAT 盒来将流量路由到它。
我们正在尝试从该服务器设置到 AWS 之外的另一台服务器的链接 SQL 服务器，这需要两个 SQL 服务器在端口 1433 TCP 上相互通信。
iptable 中的相关部分如下所示：
目标 保护 源 目标
DNAT udp 任何地方 udp dpt:ms-sql-m 到：172.10.10.10:1434
DNAT tcp 任意位置 任意位置 tcp dpt:ms-sql-s 至：172.10.10.10:1433
从我们自己的测试中，我们知道可以将任何服务器链接到 AWS 上的服务器，但不能反过来。
有什么问题吗？问题开始出现时，我们的基础设施工程师“删除并添加了相同的规则”。这有什么线索吗？顺序相关吗？
使用tracetcp我们发现以下情况：
在 aws sql 服务器“traacetcp.exe 183.23.53.22 1433”上执行此命令，其中 ip 是其他外部托管服务器的 ip，它将在 1 跳中到达目的地，但无论我们尝试任何随机 ip 地址，它都会执行相同的操作。
如果我们在 1433 以外的其他端口上执行相同的命令，它会首先到达 NAT 盒，然后进行多次跳转
答案1
使用 检查您的 iptables 规则iptables-save并重新发布它们。验证您的 DNAT 规则是否有某种方法可以排除来自网络内部的流量，例如-i <extif>、! -i <intif>或 ! -s 172.10.10.10。我强烈怀疑它会将您的数据包重新发送回内部原始服务器。
答案2
可能是您在端口 1433 上运行了代理，这可能会导致您所描述的行为。代理会立即接受与内部机器的连接，这就是为什么您会得到如此短暂的 2ms 响应。
此外，回复时间如此之短（1-4 毫秒）也表明您的数据包没有离开 LAN。如果您不小心启动了任何代理进程，请尝试检查您的 NAT 框，如果没有，请尝试禁用端口 1433（tcp）的 DNAT 规则，看看问题是否仍然存在。
此外，这种说法“不能直接在互联网上访问，它依赖于 NAT 盒来路由流量”是矛盾的，因为该机器可以在互联网上访问，但是在特定的端口上，通过该端口进行 NAT 转换，对吗？
如果您真的想保护您的服务不受外界影响，也许考虑某种 VPN 是一个明智的想法？或者，如果您想要一个更简单的解决方案（但不如 VPN 安全），您可能只允许从已知的远程 IP 地址（在某些情况下攻击者可以欺骗该 IP 地址）访问该 NAT 端口。