Azure 优惠券 微软云 Azure 账号私密链接访问
你以为的‘内网访问’，可能正在裸奔
上周五下午三点，我正对着Azure门户里那个亮得晃眼的‘Public endpoint enabled’红色警告发呆，客户运维小哥在微信里连发三条语音：‘张工，你们那个SQL数据库怎么又上公网了？审计组刚打电话来问……’
我默默点开网络配置页——果然，SQL Server防火墙开着0.0.0.0/0，SSL强制关闭，连接字符串里还明晃晃写着yourserver.database.windows.net。那一刻，我仿佛听见了合规性审查的倒计时滴答声。
私密链接不是魔法，是精心设计的‘管道工艺术’
Azure Private Link绝不是勾个‘启用私有连接’就万事大吉的开关。它本质是一套三层嵌套的精密管道系统：服务提供方（Service Provider）→ 私有终结点（Private Endpoint）→ 消费方虚拟网络（VNet）。这三者之间没有魔法，只有IP地址、DNS解析和路由表的严谨协作。
举个栗子：你家楼下便利店（Azure Storage Account）想让小区业主（你的VNet）不走大街（公网），直接从地下室通道（Private Link）送货上门。但光修通道不够——还得给每户配专属门牌号（私有IP）、更新小区通讯录（DNS记录）、并在楼道口设岗亭检查送货单（网络策略）。少一环，货就卡在半路，或者被误送到隔壁楼。
第一步：别急着点‘创建’，先画三张图
我见过太多人跳过架构设计直接开干，结果在第17步发现VNet网段和Private Endpoint子网冲突，只能删资源重来。建议动鼠标前，手绘三张草图：
- 服务拓扑图：标清你要接入的PaaS服务（如Storage、SQL、Key Vault）、所在区域、是否跨区域调用；
- 网络拓扑图：画出消费方VNet、子网、NSG规则、UDR路由表，特别标注是否有对等连接或ExpressRoute；
- DNS流向图：这是最容易翻车的环节！明确私有DNS区域（
privatelink.blob.core.windows.net）如何与你自建DNS服务器联动，或是否启用Azure Private DNS Zone自动注册。
去年帮某银行做灾备切换时，就因DNS图没画清楚，测试环境用的是自建Bind服务器，生产环境却依赖Azure Private DNS Zone，结果故障演练时存储连接超时长达8分钟——根源竟是DNS缓存未刷新，而非网络不通。
第二步：私有终结点创建，这些坑我替你踩过了
进入Portal创建Private Endpoint时，请把以下选项当成‘防坑检查清单’逐项核对：
- ‘集成到专用DNS区域’必须勾选——否则即使Private Endpoint创建成功，DNS仍解析到公网IP。很多教程只教创建，却漏掉这关键一步；
- Azure 优惠券 子网选择要避开‘默认’字眼——Azure会悄悄在子网里部署内部代理节点，若该子网已部署大量VM，可能触发NSG规则冲突或路由黑洞；
- ‘手动批准’模式慎用——适用于多租户场景，但日常运维中常因审批流中断导致连接失败。除非有强治理要求，否则选‘自动批准’更省心；
- 不要忽略‘网络接口’资源——每个Private Endpoint背后都生成一个NIC（网络接口），它自带私有IP和MAC地址。若后续需抓包排查，这就是你的入口。
有个血泪教训：某次为节省成本，我把5个不同服务的Private Endpoint全塞进同一个子网。结果某天该子网突然无法分配新IP，排查半天才发现Private Endpoint的NIC占用了全部可用地址——Azure为每个Endpoint预留2个IP（主+备用），5个就是10个，而/28子网仅14个可用IP……
第三步：DNS才是真正的‘隐形指挥官’
很多人以为Private Link开通后，curl https://mystorage.blob.core.windows.net就能走内网——错！DNS仍在默默把你导向公网IP。解决之道在于让DNS返回私有IP。
方案一（推荐新手）：Azure Private DNS Zone自动注册。创建Private Endpoint时勾选‘集成到专用DNS区域’，Azure会自动创建privatelink.blob.core.windows.net等Zone，并将Private Endpoint的私有IP写入A记录。此时需确保VNet的DNS服务器设置为‘Azure DNS’（即168.63.129.16），而非你的自建DNS。
方案二（混合云必备）：条件转发器（Conditional Forwarder）。若VNet使用本地DNS服务器，需在其上配置：当收到*.privatelink.blob.core.windows.net查询时，转发至Azure Private DNS Zone的IP（可在Portal的Private DNS Zone详情页找到）。注意！转发域必须精确匹配，privatelink.blob.core.windows.net不能写成blob.core.windows.net，否则转发失效。
验证DNS是否生效？别信Portal显示，用这行命令：nslookup mystorage.blob.core.windows.net 168.63.129.16
看到返回的IP属于你VNet的地址段（如10.1.0.15），才算真正打通。
第四步：连接测试，比想象中更‘刁钻’
别急着跑应用代码，先用最原始的方式验证：
- Telnet端口：在VNet内VM执行
telnet mystorage.blob.core.windows.net 443，通则说明网络层可达； - Curl带头验证：
curl -v https://mystorage.blob.core.windows.net --resolve 'mystorage.blob.core.windows.net:443:10.1.0.15'（IP换成你的Private Endpoint私有IP），观察是否返回HTTP 200及X-Ms-Request-Id头； - 抓包看真相：在VM上运行
tcpdump -i eth0 port 443 -w private-link.pcap，用Wireshark打开，确认TCP三次握手目标IP确为你配置的私有IP，而非公网IP。
曾有个客户坚持说‘Private Link已生效’，结果抓包发现所有流量仍打向公网IP——根源竟是其应用代码硬编码了https://mystorage.z12.core.windows.net（区域化Endpoint），而Private Link只覆盖core.windows.net标准域名。提醒：务必检查应用连接字符串是否使用标准服务域名！
最后送你三条‘保命口诀’
① ‘私有终结点不等于私有服务’——Private Link只加密传输路径，不改变服务本身的权限模型。Storage Account的SAS Token仍需严格管控，Key Vault访问策略不可松懈；
② ‘跨区域Private Link？不存在的’——Private Endpoint必须与目标服务在同一Azure区域。跨区访问仍走公网，哪怕你VNet已通过ExpressRoute连接全球骨干网；
③ ‘删除资源先删Private Endpoint’——若先删Storage Account，Private Endpoint将永久卡在‘断开连接’状态，Portal无法清理，只能靠PowerShell强制删除。
写完这篇，我顺手给自己VNet里的SQL Server加了Private Link。现在连接字符串里那串yourserver.database.windows.net终于不再让我心跳加速——它背后已是条静默流淌的私有管道，稳、准、且无需向公网借道。
毕竟，在云时代，真正的安全感，从来不是‘我能连上’，而是‘我连上的方式，连我自己都看不见’。
