如何配置 Azure VM 以作为通过服务端点连接到 SQL 数据库的代理?

如何配置 Azure VM 以作为通过服务端点连接到 SQL 数据库的代理?

目前,Azure 不允许通过 VPN 网关上的服务端点访问 SQL 数据库。我绕过此限制的想法是设置一个 Azure VM 作为代理,以便与 SQL 数据库的所有通信都通过此实例进行(然后可以通过服务端点路由往返于 SQL 数据库的流量)。但是,我无法使此解决方案发挥作用,需要一些指导。

我的设置:

我设置了一个 AWS 环境,并与 Azure 环境建立了 VPN 连接。我使用 Route53 设置了一个私有托管区域,用于将我的 SQL 数据库的域名解析为相应 Microsoft.Sql 区域终端节点的公共 IP 地址(这是我从代理 VM 访问 SQL 数据库时,我的 SQL 数据库的域名解析为的 IP 地址)。我的路由表配置为通过我的虚拟专用网关将流量转发到此 IP 地址。

在 Azure 端,我已将网关子网的路由表配置为将发往 Microsoft.Sql 区域端点公共 IP 地址的流量转发到我的代理 VM,就像它是虚拟设备一样。代理 VM 的网络接口设置为允许 IP 转发。附加到代理 VM 子网的路由表配置为将发往我的 AWS VPC 的私有 CIDR 的流量通过 VPN 网关路由回去。

为简单起见,AWS 和 Azure 环境中的安全组都设置为允许两个环境的私有 IP 地址与 Microsoft.Sql 区域端点公共 IP 地址之间的所有入站和出站流量。

目前有效的方法:

AWS VPC 中的 EC2 实例可以使用其私有 IP 地址通过 VPN ping 和 ssh 进入我的代理虚拟机。代理虚拟机可以使用其私有 IP 地址通过服务端点访问我的 SQL 数据库。

无效的方法:

我无法通过尝试连接到 Microsoft.Sql 区域公共 IP 地址(我已配置为转发到代理 VM 的 IP 地址)或我的 SQL 数据库的域名(我在 Route53 中为 Microsoft.Sql 区域公共 IP 地址设置的记录)从我的 EC2 实例成功 ping 或 ssh 到代理 VM。当我在代理 VM 上执行数据包捕获时,我看不到来自我的 EC2 实例的入站流量。流量在我的 VPC 流日志中显示为已接受。

我知道 SQL 数据库托管实例的用途,但是我没有使用该服务的选择。

我目前还没有使用 iptables 配置任何转发,也没有在代理虚拟机上进行任何特殊的主机设置,因为我首先想看到网络流量出现在数据包捕获中,然后验证我是否可以成功连接到代理虚拟机实例,然后再尝试设置任何类型的转发到 SQL 数据库。

此外,这种绕过 Azure 中服务端点限制的解决方案是否可行?有没有更简单的方法?

谢谢,祝一切顺利。

答案1

我的路由表配置为通过我的虚拟专用网关转发流量到该 IP 地址。

我认为这种特定方法不可能奏效,因为......

我已将网关子网的路由表配置为将发往 Microsoft.Sql 区域端点公共 IP 地址的流量转发到我的代理虚拟机,就好像它是一个虚拟设备一样。

该路由表适用于源自该子网的流量,而这并不是流量的来源。

您需要在两台机器之间建立隧道,而不仅仅是路由,因为网络看到的源地址和目标地址必须是各个虚拟机的地址。这是隧道的一部分功能 - 笼统地讲,隧道将来自/到地址为 a 和 b 的主机的流量包装在来自/到地址为 x 和 y 的主机的外部数据包内,这样中间网络和网关就不需要了解“真实”的源和目标。平台限制可能使得无法简单地将此流量路由和转发为未封装的 IP 流量,源和目标完好无损。(或者,如果没有合适的隧道,您需要在两端的实例上对流量进行 NAT 或双重 NAT。)

有许多在不同层运行的隧道解决方案,包括 openvpn 和 HAProxy,但最简单的 —— 至少出于概念验证目的 —— 是 SSH 隧道。

从 EC2 实例来看,假设数据库使用 TCP 端口 1433:

$ ssh -L 1433:private-ip-of-db:1433 -i keyfile.pem username@ip-of-azure-vm

打开此 SSH 连接后,还会有一个套接字监听 EC2 实例上的 TCP 端口 1434,并且任何连接到 EC2 实例的私有 IP该端口上的数据将通过开放的 SSH 连接进行隧道传输并中继到数据库。数据库将把连接的源 IP 视为 Azure VM 的 IP...因此安全设置需要相应地允许流量,并且您不会使用您讨论过的公共 IP 地址——您将使用 EC2 实例的 IP 并通过 EC2 安全组控制访问,并且您需要授予 Azure VM 对数据库的访问权限。从访问数据库的任何事物的角度来看,EC2 实例似乎是 SQL Server。

SQL Server 可能会提供一个或多个需要更多端口或与我上面所示不同的端口的陷阱,但这里的总体思路是可靠的——我已将此策略用于其他协议,如 RDP(TCP 端口 3389)和 MySQL(TCP 端口 3306),但不记得曾经在 MSSQL 上尝试过它。

相关内容