手册

在不同订阅或区域的 VNet 之间私密连接资源。

→在虚拟网络之间配置 VNet 对等互连。

原因: 将流量保留在 Microsoft 骨干网。VNet 对等互连是非传递的；通信需要直接对等互连 (A->B, B->C != A->C)。

参考↗

设计 VNet 地址空间以实现未来的连接。

→为每个 VNet 分配唯一的、不重叠的 CIDR 块。

原因: VNet 对等互连需要不重叠的地址空间。规划增长以避免重新架构。

计算特定数量主机所需的子网大小。

→使用提供所需主机数量 + 5 个 Azure 保留 IP 地址的 CIDR 表示法。

原因: Azure 在每个子网中保留前四个和最后一个 IP 地址。一个 /24 (256 个 IP) 只提供 251 个可用 IP。

部署 Azure Firewall、Gateway 或 Bastion 等服务。

→创建具有特定名称（例如 AzureFirewallSubnet、GatewaySubnet、AzureBastionSubnet）和最小大小（分别为 /26、/27、/26）的专用子网。

原因: 这些服务需要专用的、特定命名的子网来注入其资源。大小对于功能和未来扩展至关重要。

实现本地网络与 Azure Private DNS zone 之间的名称解析。

→部署 Azure DNS Private Resolver。使用入站端点处理本地到 Azure 的查询，使用带转发规则的出站端点处理 Azure 到本地的查询。

原因: 提供混合 DNS 的托管 PaaS 解决方案，无需自定义 DNS VM。本地 DNS 转发到入站端点 IP。

参考↗

对等互连的 VNet 无法解析 Private DNS zone 中的记录。

→从 Private DNS zone 创建一个虚拟网络链接到对等互连的 VNet。

原因: Private DNS zone 访问不通过对等互连进行传递。每个需要解析的 VNet 都必须有明确的链接。

为子网中的 VM 提供一个静态的、可预测的出站公共 IP 以用于允许列表。

→将 Azure NAT Gateway 与公共 IP 或公共 IP 前缀关联到子网。

原因: NAT Gateway 覆盖子网的所有其他出站连接方法，确保所有流量都使用其静态公共 IP。

参考↗

确保像 Load Balancer 这样的资源的公共 IP 保持不变。

→使用静态分配的 Standard SKU 公共 IP 地址。

原因: Standard SKU 静态 IP 默认是区域冗余的，即使关联的资源停止或删除也会持久存在。

使用 Azure CNI 网络设计 AKS 集群的子网。

→将 IP 需求计算为 (节点数 * 每个节点的最大 Pod 数) + 节点数。分配一个能容纳此数量的子网。

原因: 使用 Azure CNI，每个 Pod 直接从子网获取 IP，这需要大量的 IP 地址分配。

将所有从分支 VNet 发往 Internet 的流量通过中心 VNet 中的 Azure Firewall 进行路由。

→创建一个用户定义路由 (UDR) 表，其中包含 0.0.0.0/0 的路由，下一跳类型为“虚拟设备”，以及 Azure Firewall 的私有 IP。

原因: 这会覆盖到 Internet 的默认系统路由，强制所有流量通过防火墙进行检查。

参考↗

使用中心中的 Azure Firewall 检查两个分支 VNet 之间的流量。

→在每个分支中，为指向防火墙的其他分支地址空间创建 UDR。在防火墙中，创建网络规则以允许流量。

原因: 必须在两个分支上配置路由以将流量发送到防火墙，防火墙默认拒绝 VNet 间流量。

部署弹性 NVA 集群用于流量检查或路由。

→使用 Azure Route Server。NVA 通过 BGP 与 Route Server 对等互连并通告路由。Route Server 使用 ECMP 进行负载分配。

原因: Route Server 简化了与 NVA 的动态路由，消除了复杂的 UDR 管理并提供了自动化故障转移。

参考↗

NVA 正在丢弃它应该路由的流量。

→在 NVA 的网络接口 (NIC) 上启用“IP 转发”。

原因: 此 Azure 级别设置是必需的，以允许 NIC 接收和转发不以其自身 IP 地址为目标的流量。

将 HTTP/S 流量全球分发到具有 WAF 和 SSL 卸载的最低延迟后端。

→使用 Azure Front Door。

原因: Front Door 使用任播路由实现最佳性能，并在边缘集成 WAF、URL 路由和 SSL 卸载。

参考↗

基于 DNS 将流量分发到全球终结点，并由健康探测驱动故障转移。

→使用 Azure Traffic Manager。

原因: Traffic Manager 是基于 DNS 的负载均衡器。使用“性能”路由实现最低延迟，或使用“优先级”实现主动/被动故障转移。

提供具有 WAF、SSL 终止和基于 URL/主机的路由的区域 HTTP/S 负载均衡。

→部署 Azure Application Gateway v2。

原因: Application Gateway 是一个区域 L7 负载均衡器。使用基于路径的规则进行 URL 路由，使用多站点侦听器进行基于主机的路由。

在区域内负载均衡非 HTTP/S (TCP/UDP) 流量。

→使用 Azure Load Balancer (Standard SKU)。

原因: Azure Load Balancer 是一个区域 L4 负载均衡器。它保留客户端源 IP，适用于所有 TCP/UDP 协议。

在 Application Gateway 终止 SSL，但重新加密流量到后端。

→配置 HTTPS 侦听器。在后端 HTTP 设置中，将协议设置为 HTTPS 并上传后端服务器的受信任根证书。

原因: 确保流量在传输过程中一直加密到后端，即使后端服务器上使用自签名证书。

将流量负载均衡到 SQL Server Always On 可用性组侦听器。

→使用内部 Standard Load Balancer，并在负载均衡规则上启用“浮动 IP (直接服务器返回)”设置。

原因: SQL AG 侦听器正常运行需要浮动 IP，因为它允许辅助节点在故障转移后直接响应客户端。

将流量负载均衡到必须处理所有协议和端口的 NVA 集群。

→使用带有“HA 端口”负载均衡规则的内部 Standard Load Balancer。

原因: HA 端口规则转发所有端口上的所有 TCP 和 UDP 流量，简化了需要检查所有流量流的 NVA 的配置。

配置主 Web 应用程序源和辅助 Web 应用程序源之间的自动故障转移。

→将两个源都放在同一个 Front Door 源组中。将主源的优先级设置为 1，辅助源的优先级设置为较低的值（例如 2）。

原因: Front Door 始终将流量发送到优先级最高的健康源。当主源健康探测失败时，流量会自动切换到下一个优先级。

提供对 Azure VM 的安全 RDP/SSH 访问，而无需将管理端口暴露给 Internet。

→部署 Azure Bastion（Standard SKU 用于高级功能）。

原因: Bastion 充当托管的跳转盒，通过 Azure 门户提供基于 TLS 的访问。它消除了 VM 上用于管理的公共 IP 的需求。

参考↗

从 VNet 内部使用私有 IP 地址访问 Azure PaaS 服务（例如 SQL、Storage）。

→为 PaaS 资源创建 Private Endpoint。与 Private DNS Zone 集成以进行自动名称解析。

原因: Private Endpoint 将 PaaS 服务以私有 IP 形式投影到您的 VNet 中，从而实现真正的私有连接。禁用 PaaS 服务上的公共网络访问可强制执行此操作。

从 VNet 访问 Azure 骨干网上的 Azure PaaS 服务，无需使用公共 IP，也无需管理专用私有 IP。

→在源子网上为特定服务（例如 Microsoft.Storage）启用 Service Endpoint。

原因: Service Endpoints 提供从 VNet 到 PaaS 服务的直接路由，但不使用 VNet 中的私有 IP。它比 Private Endpoints 更简单但灵活性较低。

将您 VNet 中运行的服务私密地暴露给其他 VNet（可能是其他租户）中的消费者。

→将服务放在 Standard Load Balancer 后面，并创建一个指向它的 Private Link Service。

原因: Private Link Service 是提供者侧组件。消费者在其 VNet 中创建 Private Endpoint 以私密连接到您的服务。

参考↗

简化多层应用程序的 NSG 规则，其中 VM 可能会扩展或更改 IP。

→为每个层（例如 Web、App、DB）创建应用程序安全组 (ASG)。使用 ASG 作为源/目标定义 NSG 规则。

原因: ASG 充当 VM 的网络对象标签，允许您根据应用程序结构而不是易变的 IP 地址创建规则。

当 NSG 同时应用于 NIC 及其子网时，流量意外被阻止。

→回顾 NSG 规则评估顺序。入站：先 NIC 规则，后子网规则。出站：先子网规则，后 NIC 规则。

原因: 任何级别的拒绝都会阻止流量。两个 NSG 都必须允许流量才能成功。

自动阻止与已知恶意 IP 地址和域之间的流量。

→在“警报和拒绝”模式下启用 Azure Firewall 基于威胁情报的过滤。

原因: 这使用 Microsoft 的威胁情报源提供针对已知威胁的托管、最新保护，零配置。

检查加密的 HTTPS 流量是否存在恶意软件等威胁。

→使用 Azure Firewall Premium。在策略中启用 TLS 检查，并部署客户端必须信任的中间 CA 证书。

原因: 这是一项高级功能，执行中间人解密以检查流量，这对于零信任安全态势至关重要。

允许对 Windows Update 等复杂的 Microsoft 服务进行出站访问，而无需维护 IP 列表。

→在 Azure Firewall 中，使用 FQDN 标签（例如“WindowsUpdate”、“AzureBackup”）创建应用程序规则。

原因: Microsoft 管理与这些标签关联的 FQDN，从而简化了动态服务的防火墙规则管理。

保护面向公共的应用程序免受容量型 DDoS 攻击，并获得快速响应支持。

→在 VNet 上启用 DDoS 网络保护（以前称为 Standard）。

原因: 提供自适应调整、攻击遥测、缓解报告以及对 DDoS 快速响应团队的访问，而免费的基本保护缺少这些功能。

诊断连接失败并识别流量被丢弃的确切跳点。

→使用 Network Watcher > 连接疑难解答。

原因: 它执行端到端检查，显示完整的逐跳路径，并查明由于 NSG、UDR 或其他网络问题导致的故障。

快速验证 NSG 规则是允许还是拒绝进出 VM 的流量。

→使用 Network Watcher > IP 流验证。

原因: 这是测试特定 5 元组对抗 NSG 规则并查看哪个规则导致结果的最直接工具。

记录所有允许和拒绝的网络流量以进行合规性和分析。

→启用 NSG 流日志并将其摄取到流量分析（通过 Log Analytics Workspace）。

原因: NSG 流日志提供原始流量数据。流量分析丰富并可视化此数据，以识别流量模式、主要通信者和安全威胁。

使用提供可预测延迟和高带宽的私有专用连接将本地网络连接到 Azure。

→预配 Azure ExpressRoute 线路。

原因: ExpressRoute 完全绕过公共 Internet，提供比站点到站点 VPN 更可靠、更快、延迟更低的连接。

参考↗

选择正确的 ExpressRoute 对等互连以访问 Azure 资源。

→使用 Azure 私有对等互连连接到 VNet。使用 Microsoft 对等互连访问公共 PaaS 服务和 Microsoft 365。

原因: 两种对等互连类型提供对不同资源集的访问。Microsoft 对等互连需要公共 IP、NAT 和路由筛选器。

允许分支 VNet 通过中心 VNet 中的中央 VPN 或 ExpressRoute 网关访问本地网络。

→在中心到分支对等互连上，启用“允许网关传输”。在分支到中心对等互连上，启用“使用远程网关”。

原因: 这种两部分配置允许分支使用中心的网关，从而集中混合连接。

配置站点到站点 VPN 作为 ExpressRoute 连接的备份。

→同时部署 ExpressRoute 和 VPN 网关。默认情况下，对于相同的地址前缀，ExpressRoute 路径优先于 VPN 路径。

原因: 由于默认路由权重较高，Azure 会自动优先选择 ExpressRoute。如果 ExpressRoute 线路发生故障，BGP 将撤回路由，流量将故障转移到 VPN。

影响流量以优先选择一个 ExpressRoute 线路而不是另一个线路，以实现主动/被动冗余。

→使用 BGP AS Path prepending。在备用线路上多次添加您自己的 ASN 到路由通告中，使其路径显得更长。

原因: BGP 优先选择最短的 AS Path。这使得主线路成为首选路径，如果主路径被撤回，则会自动故障转移到备用线路。

使用现有的 ExpressRoute 线路，通过 Microsoft 骨干网络连接两个本地站点。

→启用 ExpressRoute Global Reach。

原因: Global Reach 将两条 ExpressRoute 线路连接在一起，通过 Microsoft 网络实现私有 WAN，而无需流量在 Azure VNet 中迂回。

简化连接多个分支机构和 VNet 的全球网络的管理。

→部署 Azure Virtual WAN。

原因: Virtual WAN 提供托管的中心辐射型服务，具有自动的任意到任意的传递连接、路由以及与安全服务（安全中心）的集成。

参考↗

在 Virtual WAN 中，集中检查所有 VNet 间、分支间和 Internet 出站流量。

→部署安全的虚拟中心（带 Azure Firewall）。配置路由意图以通过防火墙发送私有和 Internet 流量。

原因: 路由意图简化了 vWAN 中的流量工程，自动编程路由以强制流量通过安全提供程序，而无需手动 UDR。

提供到 Azure 的弹性 VPN 连接。

→以主动-主动配置部署 VPN Gateway。这需要两个公共 IP 和一个能够建立两个隧道的本地设备。

原因: 在 Azure 区域内提供实例级冗余。对于跨区域冗余，请使用区域冗余 (AZ) SKU。

选择 Point-to-Site VPN 协议，以实现广泛的客户端兼容性，而无需额外软件。

→使用 IKEv2。为了实现最大兼容性，包括旧设备，请使用 OpenVPN。

原因: IKEv2 在现代 Windows、macOS 和 iOS 上原生支持。SSTP 仅适用于 Windows。OpenVPN 需要客户端但得到广泛支持。

将所有从 Azure VM 发往 Internet 的流量重定向到本地安全设备。

→从本地通过 ExpressRoute 或 VPN 连接，通过 BGP 通告默认路由 (0.0.0.0/0)。

原因: 此 BGP 通告会覆盖 Azure 的默认 Internet 路由，强制流量返回到本地网络进行检查。