我们运行一个SaaS，它将数据放在其他人的SQL Azure数据库中。这些数据库是第三方的，我们无法控制-我们只要求他们将我们的IP地址列入白名单。
最近，我们将我们的应用程序添加到VNet，并为自己获得了一个固定的IP。我们要求客户将新IP地址列入白名单。对于大多数人来说，没有问题。
然而，一些客户在他们自己的VNet中拥有他们的数据库，并使用私有端点来授予对他们的其他系统的访问权。我们发现，我们的应用程序无法连接到这些数据库，直到他们删除其私有端点。在这里，我从我的Azure应用程序访问控制台并连接到第三方数据库-使用和不使用私有端点：
您可以看到第一个解析为“privatelink”别名，但第二个返回更多信息，包括IP地址。
SQL重定向
起初我以为是SQL重定向连接策略，所以我添加了一个NGS和传出规则到我自己的VNet，根据网上讨论SQL重定向的各种文章：
这并没有造成什么不同。
防火墙
我已经让客户把我们的新IP地址列入白名单了。值得注意的是，在我自己的测试中（使用兼容的客户端），即使我短暂地向所有IP地址开放防火墙，我们仍然无法访问。如果我们选中“允许Azure服务”框，也不会获得访问权限。我相信这表明，我们根本无法解决的名称摆在首位，所以甚至没有得到防火墙（？）
路由应用
我还注意到，如果我禁用所有出站流量的路由，则可以避免这种行为：
- 勾选此框后，上述行为仍然有效
- 取消选中此复选框后，我现在可以访问第三方系统 * 中的数据库，但它来自的IP地址不是我的VNet* 中的固定IP地址。要确认此行为，请注意使用Azure控制台执行ping操作时结果的变化：
我们首先配置VNet的原因之一是我们可以使用固定IP，因此选项2不适合。我认为有趣的是，只有当我们在内部将调用路由到xyz.database.windows.net时，DNS才会完全崩溃。也许我必须添加一些其他类型的路由/Map/DNS来“恢复”这个域名？
总结
- 我们的系统一直运行良好，直到我们有了自己的虚拟网络
- 一旦我们更改为VNet，那些拥有独立SQL Azure数据库的客户继续正常工作（一旦他们添加了我们的新IP地址）
- 但那些数据库拥有自己（不相关）专用端点的客户无法正常工作
- 但是，如果我允许Azure将流量路由到我的网络之外（通过“应用程序路由”复选框），则第三方数据库可以再次访问
我需要的是
这是一个SaaS，所以我不能手动将私有端点连接到我们端的每个客户端数据库。我需要：
- 我可以对我自己的VNet进行单个更改，以启用此连接（首选）;或
- 我可以向我的客户提供一个指令，使他们能够授权访问我们的新VNet
谢谢
2条答案
按热度按时间7cjasjjr1#
我的理解是，您自己的VNET需要对每个客户VNET都是peered。您可能还必须将专用DNS区域链接到对等VNET以进行名称解析，以便Azure提供的默认DNS将验证是否有任何专用DNS区域链接到虚拟网络，如果DNS匹配，则将解析为专用IP。
woobm2wo2#
我们最终解决了这个问题，而不是彻底解决它。当您创建私有端点时，Azure还将为
privatelink.database.windows.net创建一个“私有DNS区域”，并将您的VNET添加到其中：当然，这个名字与您对服务器（从我们的VNET外部）运行ping所获得的结果有关。考虑到我们在VNET内部的ping（参见上面的屏幕截图）返回“. could not find host”，我们推测可能是这个私有DNS区域将所有请求重新路由到我们的VNET内部的
*.privatelink.database.windows.net。果然，当我们将VNET从该区域断开链接时，连接再次工作。当然，问题是我们自己的私有端点无法工作，但我们可以通过添加服务端点来解决这个问题：
我假设这意味着我们的网络中不再有私有DNS区域，因此Azure将在我们的网络之外继续解析它。
我们能够解决这个问题是件好事，但我仍然觉得必须有一种方法来支持私人链接，无论是在自己的VNET中，还是在不关心第三方如何使用私人链接的情况下。
我还有点担心，将来有一天我们会有自己的私有端点需求，而我们将无法利用它。
如果有人能为我们解决第一种情况，那将仍然是非常有趣的。