在设置VPN到Azure时与微软在RFC 1918上争论

微软拥有一种名为“点对点”VPN的技术。 （ reference1 ， reference2 ）

我有以下内部类“A”networking定义的前提下：

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

我定义了以下Azurenetworking：

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

我想创build专用于点对点VPN的子网

• 不同主机上的多个openvpn客户端
• 连接到具有不同子网掩码的子网，没有静态路由
• 如何将所有stream量绑定到特定网卡上的特定IP？
• OpenVPN在两个远程站点上具有相同的子网
• 是否可以使用iptables将公共IP转换为私有IP？

• 10.200.0.0 / 16

当我在门户网站中这样做时，VPN客户端将添加10.0.0.0/8的默认路由。 微软的理由是在RFC1918，他们拒绝让我自定义这条路线。 在我看来，他们显然误解了这个RFC不适用于这种情况。

当我将networking掩码更改为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指定。

请注意，以下路由将分别添加到客户端，以将stream量从本地计算机引导到虚拟networking：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地址。

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

所以我们总是要求我们的客户在创build他们的P2S环境时使用192.168.0.0/X范围，并且确保它不与本地可能有的任何子网（其P2S客户端连接的地方）重叠。

题

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