微软云充值 微软云 Azure 账号对等连接代办
别再让 Azure 对等连接卡在‘对方没收到邀请’上
上周三凌晨两点，我盯着 Azure 门户里那个灰掉的「Accept invitation」按钮，手指悬在鼠标上方，像极了当年高考查分前不敢点开网页的自己。不是因为紧张——是真·点不了。对方租户压根没收到邀请邮件，而我的同事坚称他已把邮箱地址复制粘贴了三遍，连空格都用肉眼校验过。
后来发现：他填的是个人 Outlook 邮箱，但目标租户只认公司域名后缀（@contoso.com），Azure 根本不发邀请，连‘发送失败’提示都不给——它选择沉默，像一个高冷的系统哲学家。
这就是 Azure 跨租户对等连接（Cross-Tenant VNet Peering）最真实的日常：它不难，但每一步都藏着反直觉的细节。今天这篇，不讲概念，不列文档链接，就掏心窝子说人话，带你把‘代办清单’变成‘打钩清单’。
第一步：搞清谁该干啥——权限地图不能画错
发起方 ≠ 接收方 ≠ 管理员
很多人一上来就猛点「Create peering」，结果弹出红色警告：“The subscription is not authorized to create peering in the remote virtual network.”（订阅无权在远程虚拟网络创建对等连接）。别急着查权限，先问自己：你是不是在替别人干活？
Azure 对等连接是双向契约：A 租户发起邀请，B 租户必须手动接受。这不像发微信好友申请——系统不会自动加你，也不会给你发‘对方已忽略’通知。双方角色和权限必须严格对齐：
- 发起方：需具备源 VNet 所属订阅的
Network Contributor或更高权限； - 接收方：需在目标租户中，以
Owner或Network Contributor身份登录，并拥有目标 VNet 的完整控制权； - 关键盲区：若目标 VNet 属于另一个部门/子公司，他们可能连你的租户 ID 都没听过。这时候，你递过去的不是技术请求，是一张‘合作意向书’。
实操建议：提前拉个三方小群（你、对方网络管理员、对方 Azure AD 管理员），把三件事聊死：① 对方是否开启多租户协作（Azure AD > External Identities > Invite users）；② 目标 VNet 所在资源组是否启用 Allow virtual network access（在资源组属性里）；③ 对方是否愿意为你临时分配 Network Contributor 角色（比 Owner 更安全）。
第二步：邀请不是发邮件——而是‘租户握手’
Portal 上的‘邀请’按钮，其实是个‘外交照会’
在 Azure 门户创建对等连接时，勾选「Allow forwarded traffic」「Allow gateway transit」这些选项前，请先确认：你点的「Create」按钮，本质是在向对方租户的 Azure AD 发起一次跨租户身份协商。它不走 SMTP，不依赖邮箱服务器，靠的是 Azure AD 的信任链。
所以，当你说“我发了邀请但对方没收到”，90% 情况下是：对方租户压根没把你这个租户加入白名单。验证方法超简单：让对方打开 Azure AD 外部用户管理页，看「Invited users」列表有没有你的租户名（格式如：yourtenant.onmicrosoft.com）。没有？那就不是技术问题，是流程卡点。
补救方案只有两个：要么对方手动添加你的租户为可信合作伙伴（需 Global Admin 权限）；要么你换用 PowerShell 脚本直连——跳过 Portal 的 UI 层，用 New-AzVirtualNetworkPeering 命令强制发起。我们团队常用这段‘保命脚本’：
$vnet = Get-AzVirtualNetwork -Name 'vnet-prod' -ResourceGroupName 'rg-network'
$remoteVnetId = '/subscriptions/xxxxx/resourceGroups/rg-shared/providers/Microsoft.Network/virtualNetworks/vnet-dev'
New-AzVirtualNetworkPeering `
-Name 'peering-to-dev' `
-VirtualNetwork $vnet `
-RemoteVirtualNetworkId $remoteVnetId `
-AllowForwardedTraffic `
-AllowGatewayTransit `
-UseRemoteGateways注意：-RemoteVirtualNetworkId 必须带完整资源 ID，不能只写名称；且执行前，确保你已用 Connect-AzAccount -TenantId '对方租户ID' 切换过上下文。
微软云充值 第三步：接受邀请？先检查‘网络宪法’
VNet 地址空间冲突，是比密码输错更绝望的错误
对方终于点下「Accept」，你刷新页面，却看到状态变成 Initiated 后再也不动——恭喜，你触发了 Azure 最经典的‘静默失败’机制。这时候，千万别去重启服务或重装 CLI，打开目标 VNet 的「Peerings」页，点进那条待接受的连接，看详情里的「Status」字段。
如果显示 Failed，展开「Error details」，八成是这行红字：Address space of the local virtual network overlaps with address space of the remote virtual network.（本地与远程 VNet 地址空间重叠）。
别慌。这不是 bug，是 Azure 的硬性宪法：对等连接要求双方 VNet 的 CIDR 不能有任何交集。哪怕只是 10.1.0.0/16 和 10.1.1.0/24 这种‘包含关系’，也会被拒绝。解决方案只有两个字：改网段。
我们曾为改一个测试环境的 VNet CIDR，协调了开发、运维、DBA 三方会议两小时——因为所有应用配置文件里都硬编码了 10.1.0.x。最后妥协方案：新建 VNet，用 Azure Migrate 迁移资源，旧网留作只读归档。教训很痛，但记住了：对等连接前，先做地址空间审计表，把所有 VNet 的 CIDR 拉出来排排坐，用 Excel 的条件格式标出重叠项。
第四步：通了？等等，流量可能还在绕路
路由表才是真正的‘交通警察’
状态变成 Connected≠ 流量真能跑通。我们线上曾出现过：ping 通，telnet 端口也通，但业务接口始终超时。抓包发现，流量根本没走对等链路，而是绕道公网走了 Azure 公共出口。
原因？默认路由表（System Route Table）只负责基础连通，但如果你或同事之前为优化性能，给子网绑定了自定义路由表（UDR），而 UDR 里没加指向对等 VNet 的路由条目（Destination: 10.2.0.0/16, Next hop: Virtual network gateway），那 Azure 就会按‘最长前缀匹配’原则，把包扔给默认路由——也就是走 Internet。
修复口诀就一条：**所有参与对等连接的子网，其绑定的路由表里，必须显式声明对端 VNet 的 CIDR 作为直连路由**。别信‘系统会自动加’，它不会。
老司机私藏的 5 条避雷口诀
- ‘租户 ID 不是邮箱域名’——对方让你填‘租户ID’，别手快输 [email protected]，去 Azure AD 属性页 复制真正的 36 位 GUID；
- ‘Accept 按钮灰色？先登对方账号’——用对方租户账号登录 portal，再导航到目标 VNet，否则按钮永远不可点；
- ‘DNS 不通？关掉‘Enable DNS forwarding’试试’——跨租户场景下，这个开关常引发解析黑洞；
- ‘NSG 拦路？检查双向规则’——不只是源子网要放行，目标子网的入站 NSG 也得允许对应端口；
- ‘删不掉的对等连接？先删远程端’——本地删完，远程端仍残留‘Initiated’状态，会导致新连接创建失败。
最后说句实在话：Azure 对等连接本身很稳，真正拖慢进度的，永远是人与人的协作缝隙。下次再遇到‘对方说没收到邀请’，别第一反应查日志——先发条微信：“你们 Azure AD 的外部用户邀请功能开了吗？需要我提供租户ID吗？” 有时候，最高效的 DevOps，是把技术问题翻译成人话。
