问题描述
使用 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