问题描述
使用 Azure 虚拟网络,Azure APIM 可以管理无法通过 Internet 访问的 API,达到以保护企业内部的后端API的目的。在虚拟网络中,启用网络安全组(NSG:Network Security Group)来控制出站,入站的端口,我们可以形象的把它比喻成一道门,需要满足条件的流量才能通过这道安全的大门。
通过安全大门以后,我们就需要有路,才能达到目的。而默认的网络路径由Azure的骨干网络控制,如果需要通过公司自己的防火墙(Azure Firewall或企业自己的防火墙)。在虚拟网络中,通过路由表(Route Table)来指定下一跳(Next Pod),通过使用0.0.0.0/0的配置方式(UDRs:user-defined routes),把虚拟网络中的所有流量都导入并经过防火墙。实现企业级的安全保护。
以上两句总结起来就是:NSG是门,UDR是路。解决方案架构图为:
但是,在搭建APIM VNET时候,却遇见了各种各样的错误。
1)因为NSG的缘故,必须的端口不通。导致APIM的网络连接状态“Network connectivity status”页面中状态显示为 Error
2)因为配置了自定义路由(UDR), 导致了APIM页面中的APIs,Repository等页面错误,且门户一直弹出Failed to connect to management endpoint错误消息
问题分析
首先:以上的两个问题,都可以在" 如何将 Azure API 管理与虚拟网络配合使用:常见网络配置问题 "一文中找到答案。
问题一端口问题:添加上文档中所列出的所有必要端口,就可以实现网络连接状态全部Success的状态。
API 管理所需的端口:可以使用 网络安全组控制其中部署了 API 管理的子网的入站和出站流量。 如果其中的任一端口不可用,API 管理可能无法正常工作且不可访问。 将 API 管理与 VNET 配合使用时,另一个常见的错误配置问题是阻止了这些端口中的一个或多个。
VNET 中托管 APIM服务实例时,将使用下表中的端口。
源/目标端口 | 方向 | 传输协议 | 服务标记 源/目标 |
目的 (*) | 虚拟网络类型 |
* / [80], 443 | 入站 | TCP | INTERNET/VIRTUAL_NETWORK | 客户端与 API 管理的通信 | 外部 |
* / 3443 | 入站 | TCP | ApiManagement / VIRTUAL_NETWORK | Azure 门户和 PowerShell 的管理终结点 | 外部和内部 |
* / 443 | 出站 | TCP | VIRTUAL_NETWORK / Storage | 与 Azure 存储的依赖关系 | 外部和内部 |
* / 443 | 出站 | TCP | VIRTUAL_NETWORK / AzureActiveDirectory | Azure Active Directory 和 Azure KeyVault 依赖项 | 外部和内部 |
* / 1433 | 出站 | TCP | VIRTUAL_NETWORK / SQL | 访问 Azure SQL 终结点 | 外部和内部 |
* / 443 | 出站 | TCP | VIRTUAL_NETWORK / AzureKeyVault | 访问 Azure KeyVault | 外部和内部 |
* / 5671, 5672, 443 | 出站 | TCP | VIRTUAL_NETWORK / EventHub | 事件中心策略日志和监视代理的依赖项 | 外部和内部 |
* / 445 | 出站 | TCP | VIRTUAL_NETWORK / Storage | 与适用于 GIT 的 Azure 文件共享的依赖关系 | 外部和内部 |
* / 443, 12000 | 出站 | TCP | VIRTUAL_NETWORK / AzureCloud | 运行状况和监视扩展 | 外部和内部 |
* / 1886、443 | 出站 | TCP | VIRTUAL_NETWORK / AzureMonitor | 发布诊断日志和指标、资源运行状况和 Application Insights | 外部和内部 |
* / 25、587、25028 | 出站 | TCP | VIRTUAL_NETWORK/INTERNET | 连接到 SMTP 中继以发送电子邮件 | 外部和内部 |
* / 6381 - 6383 | 入站和出站 | TCP | VIRTUAL_NETWORK/VIRTUAL_NETWORK | 访问 Redis 服务以获取计算机之间的缓存策略 | 外部和内部 |
* / 4290 | 入站和出站 | UDP | VIRTUAL_NETWORK/VIRTUAL_NETWORK | 同步用于计算机之间的速率限制策略的计数器 | 外部和内部 |
* / * | 入站 | TCP | AZURE_LOAD_BALANCER/VIRTUAL_NETWORK | Azure 基础结构负载均衡器 | 外部和内部 |
配置完成NSG后,一定要记住,在APIM中去Apply Network Configration,以实现网络配置双边同步。
问题二自定义路由问题:情况要复杂一些。需要开启服务终结点,在路由表中放行所在中国区的IP地址(控制平面 IP 地址)
使用 Express Route 或网络虚拟设备强制隧道流量发往本地防火墙:客户的常用配置是定义自己的默认路由 (0.0.0.0/0),强制来自 API 管理所委托子网的所有流量流经本地防火墙或流向网络虚拟设备。 此流量流一定会中断与 Azure API 管理的连接,因为出站流量会在本地被阻止,或者通过“网络地址转换”功能发送到不再与各种 Azure 终结点一起工作的一组无法识别的地址。
此解决方案要求执行以下三项操作:
第一项:在部署 API 管理服务的子网上启用服务终结点。 需为 Azure SQL、Azure 存储、Azure 事件中心和 Azure 服务总线启用服务终结点。 直接从 API 管理委托的子网启用这些服务的终结点可以让它们使用 Azure 主干网络,为服务流量提供优化的路由。 如果将服务终结点与强制隧道 API 管理配合使用,则不会将上述 Azure 服务流量进行强制隧道传输。 其他 API 管理服务依赖项流量会通过强制隧道重定向,不能丢失,否则 API 管理服务会功能失常。
第二项:所有控制平面流量(从 Internet 到 API 管理服务的管理终结点)都会通过特定的一组由 API 管理托管的入站 IP 进行路由。 当流量被强制进行隧道传输时,响应不会对称地映射回这些入站源 IP。 为了克服此限制,我们需要添加以下用户定义的路由 (UDR),通过将这些主机路由的目标设置为“Internet”来将流量传回 Azure。 用于控制平面流量的入站 IP 集是记录在案的控制平面 IP 地址
第三项:对于被强制进行隧道传输的其他 API 管理服务依赖项,应该有一种方法来解析主机名并访问该终结点。 其中包括:
- 指标和运行状况监视:到 Azure 监视终结点的出站网络连接,可在内网中解析,这些 URL 在 AzureMonitor 服务标记下表示,用于网络安全组。
- mooncake.warmpath.chinacloudapi.cn
- global.prod.microsoftmetrics.com(新增)
- shoebox2.prod.microsoftmetrics.com(新增)
- shoebox2-red.prod.microsoftmetrics.com
- shoebox2-black.prod.microsoftmetrics.com
- shoebox2-red.shoebox2.metrics.nsatc.net
- shoebox2-black.shoebox2.metrics.nsatc.net
- prod3.prod.microsoftmetrics.com(新增)
- prod3-red.prod.microsoftmetrics.com
- prod5.prod.microsoftmetrics.com
- prod5-black.prod.microsoftmetrics.com
- prod5-red.prod.microsoftmetrics.com
- gcs.prod.warm.ingestion.monitoring.azure.cn
- Azure 门户诊断:若要在从虚拟网络内部使用 API 管理扩展时从 Azure 门户启用诊断日志流,需要允许在端口 443 上对
dc.services.visualstudio.com
进行出站访问。 - SMTP 中继 :在主机
smtpi-co1.msn.com
、smtpi-ch1.msn.com
、smtpi-db3.msn.com
、smtpi-sin.msn.com
、ies.global.microsoft.com
下解析的 SMTP 中继的出站网络连接 - 开发人员门户验证码:在主机
client.hip.live.com
和partner.hip.live.com
下解析的开发人员门户 CAPTCHA 的出站网络连接。
问题解决
对比NSG列表,添加缺少的端口。特别是:1433,5671, 5672,12000,1886,25028, 6381 - 6383等不常配置的端口。
在Route Table中添加中国区两个被标记为全球的IP地址。这是必须的地址,也是在配置中常常忽略的问题。也是产生此问题的根源。
参考资料
在内部虚拟网络中使用 Azure API 管理服务:https://docs.azure.cn/zh-cn/api-management/api-management-using-with-internal-vnet
APIM常见网络配置问题:https://docs.azure.cn/zh-cn/api-management/api-management-using-with-vnet#common-network-configuration-issues