☰

在设置到 Azure 的 VPN 时与 Microsoft 就 RFC 1918 进行辩论

tag-icon • tag-icon routing rfc azure-networking
在设置到 Azure 的 VPN 时与 Microsoft 就 RFC 1918 进行辩论

微软有一项称为“点对站点”VPN 的技术。（参考文献1，参考文献2）

我在本地定义了以下内部“A”类网络：

  • 10.2.0.0/16
  • 10.4.0.0/16
  • 10.40.0.0/16
  • 10.20.0.0/16

我定义了以下 Azure 网络：

  • 10.201.0.0/16
  • 10.202.0.0/16
  • 10.203.0.0/16

我想要创建一个专用于点到站点 VPN 的子网

  • 10.200.0.0 /16

当我在门户中执行此操作时，VPN 客户端将为 10.0.0.0/8 添加默认路由。Microsoft 对此的解释在 RFC1918 中，他们拒绝允许我自定义此路由。在我看来，他们显然误解了此 RFC 不适用于这种情况。

当我将网络掩码更改为 168.192.1.0 时，将应用 B 类路由。这有效，但由于 Microsoft 支持对 RFC 的误解，我需要偏离我的编号模式，这很烦人

在此处输入图片描述

他们的答复：

根据 RFC 1918 的规定，地址空间必须是私有地址范围，以 CIDR 表示法 10.0.0.0/8、172.16.0.0/12 或 192.168.0.0/16 指定。

请注意，以下路由将分别添加到客户端，用于将流量从本地计算机引导到虚拟网络：10.0.0.0/255.0.0.0、172.16.0.0/255.255.0.0 或 192.168.0.0/255.255.255.0。这意味着，例如，如果您为 VPN 客户端地址空间指定了 10.0.0.0/8，则您可能无法联系本地子网上的其他 10.0.0.0/8 地址。

您选择的任何以 10.xxx 开头的地址空间都会出现此问题（不仅仅是 10.0.0.0/8）。无论您选择如何在 Azure 中定义它（例如：10.1.0.0/24），VPN 客户端包都会将此 VPN 地址空间视为 A 类（255.0.0.0 子网掩码）。

因此，我们始终要求客户在创建 P2S 环境时使用 192.168.0.0/X 范围，并确保它不与他们可能在本地拥有的任何子网（他们的 P2S 客户端从中连接）重叠。

问题

  1. 我错了吗？
  2. Microsoft 是否应支持 10.x 范围的自定义 CIDR 掩码？
  3. 我怎样才能说服他们呢？

答案1

  1. 不。
  2. 是的。
  3. 如果产品存在缺陷，与技术支持人员争论也无济于事。目前，您必须在产品的限制范围内工作，或者寻找其他产品。您可能无法让他们在合理的时间内做出改变。

相关内容