<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Networking | The .NET Blog</title><link>https://thedotnetblog.com/zh/tags/networking/</link><description>Articles, tutorials and insights from the .NET community.</description><generator>Hugo</generator><language>zh</language><managingEditor>@thedotnetblog (The .NET Blog)</managingEditor><webMaster>@thedotnetblog</webMaster><lastBuildDate>Tue, 19 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://thedotnetblog.com/zh/tags/networking/index.xml" rel="self" type="application/rss+xml"/><item><title>私有端点、VNet、NSG — Aspire 现在接管网络管理</title><link>https://thedotnetblog.com/zh/news/emiliano-montesdeoca/aspire-azure-enterprise-networking-private-endpoints/</link><pubDate>Tue, 19 May 2026 00:00:00 +0000</pubDate><author>Emiliano Montesdeoca</author><guid>https://thedotnetblog.com/zh/news/emiliano-montesdeoca/aspire-azure-enterprise-networking-private-endpoints/</guid><description>Aspire 新的 Azure 企业网络支持让你可以直接在 AppHost 中建模 VNet、私有端点、NAT 网关、NSG 和网络安全边界，无需基础设施漂移。</description><content:encoded>&lt;p&gt;我见过这个场景太多次了。应用程序已经完成。演示很棒。然后安全清单出现了：将存储从公共互联网移除、在 VNet 内运行、为合作伙伴允许列表提供出站 IP、证明只有正确的子网与正确的服务通信。&lt;/p&gt;
&lt;p&gt;此时应用程序模型和基础设施模型开始以令人痛苦的方式分离。&lt;/p&gt;
&lt;p&gt;Aspire 新的 Azure 企业网络支持直接解决了这个问题。你在 AppHost 中将网络形态描述在使用它的资源旁边。&lt;/p&gt;
&lt;h2 id="构建块"&gt;构建块&lt;/h2&gt;
&lt;p&gt;每个 Azure 网络概念的用途，提炼如下：&lt;/p&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;功能&lt;/th&gt;
&lt;th&gt;使用时机&lt;/th&gt;
&lt;th&gt;为何重要&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;虚拟网络&lt;/td&gt;
&lt;td&gt;需要私有地址空间时&lt;/td&gt;
&lt;td&gt;子网、私有端点和路由的网络边界&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;子网&lt;/td&gt;
&lt;td&gt;需要在 VNet 内分离工作负载时&lt;/td&gt;
&lt;td&gt;系统的每个部分获得自己的地址范围和策略面&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;委托子网&lt;/td&gt;
&lt;td&gt;平台服务（如 ACA）需要管理子网时&lt;/td&gt;
&lt;td&gt;允许服务安全地在 VNet 中放置受管基础设施&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;NAT 网关&lt;/td&gt;
&lt;td&gt;需要可预测的出站公共 IP 时&lt;/td&gt;
&lt;td&gt;用于允许列表和审计的稳定地址&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;私有端点&lt;/td&gt;
&lt;td&gt;希望 PaaS 资源可私密访问时&lt;/td&gt;
&lt;td&gt;在 VNet 内放置该服务的私有 IP，消除公共暴露&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;NSG&lt;/td&gt;
&lt;td&gt;需要子网级流量规则时&lt;/td&gt;
&lt;td&gt;每个子网的入站和出站流量显式允许/拒绝&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;h2 id="在-apphost-中描述它"&gt;在 AppHost 中描述它&lt;/h2&gt;
&lt;p&gt;这里的关键转变是你将网络与使用它的资源&lt;em&gt;一起&lt;/em&gt;建模，而不是在随时间与应用模型产生偏离的单独 Bicep 文件中。&lt;/p&gt;
&lt;p&gt;从 AppHost，你可以：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;使用 &lt;code&gt;AddVirtualNetwork()&lt;/code&gt; 和 &lt;code&gt;AddSubnet()&lt;/code&gt; 创建 VNet 和子网&lt;/li&gt;
&lt;li&gt;为子网附加 NAT 网关以获得稳定的出站 IP&lt;/li&gt;
&lt;li&gt;为存储、Key Vault、SQL 和其他 PaaS 服务创建私有端点&lt;/li&gt;
&lt;li&gt;使用入站和出站安全规则定义 NSG&lt;/li&gt;
&lt;li&gt;配置网络安全边界以实现跨资源策略&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;结果是当你运行 &lt;code&gt;azd up&lt;/code&gt; 时，基础设施与应用模型所说需要的内容相匹配。而不是手动维护的模板所说的。&lt;/p&gt;
&lt;h2 id="为何对实际应用程序重要"&gt;为何对实际应用程序重要&lt;/h2&gt;
&lt;p&gt;一旦在 Aspire 中建模了网络，一些事情就会变得容易很多：&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Key Vault 和存储的私有端点&lt;/strong&gt; — 你在这些资源上描述 &lt;code&gt;WithPrivateEndpoint()&lt;/code&gt;，Aspire 处理 DNS 区域配置和端点附加。应用程序永远不会改变。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;一致的出站 IP&lt;/strong&gt; — 向相关子网添加 NAT 网关，应用程序的每个出站请求都通过一个已知的稳定 IP。合作伙伴可以将其加入允许列表。审计人员可以追踪它。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;代码中的 NSG 规则&lt;/strong&gt; — 不再需要在门户中点击或维护 Bicep 代码段，你的安全规则与它们保护的资源一起存在于 AppHost 中。&lt;/p&gt;
&lt;p&gt;这是不会让演示令人兴奋但会让生产系统可维护的集成类型。&lt;/p&gt;
&lt;h2 id="总结"&gt;总结&lt;/h2&gt;
&lt;p&gt;如果从一开始就与应用程序一起建模，网络安全在项目生命周期后期出现是一个已解决的问题。Aspire 的企业网络支持使这成为可能，而无需单独的基础设施轨道。&lt;/p&gt;
&lt;p&gt;完整详情请参阅原始文章：&lt;a href="https://devblogs.microsoft.com/aspire/aspire-azure-enterprise-networking/"&gt;Securing Azure apps with Aspire enterprise networking&lt;/a&gt;&lt;/p&gt;</content:encoded></item></channel></rss>