我们在各个客户端位置使用 Azure VPN 网关和各种本地网络设备建立了站点到站点 VPN 连接。我们正在尝试建立新连接，但 IP 范围与另一端的网络发生冲突。下图虽然在客户端进行了粗略的解释，因为我没有他们那边的所有详细信息，但可能最能解释这一点，但事实如下：
- 网络 A（192.168.1.0/24）位于我们的 Azure VPN 网关后面，由我们负责。
- 网络 B（192.168.2.0/24）是来自网络 A 的数据包的目标网络，由我们的客户负责，并托管在私有云中。
- 网络 C（192.168.1.0/24）是私有云中的另一个网络，与我们的流量无关，只是它代表客户私有云内的 IP 范围冲突。
Azure 支持人员表示，唯一的补救措施是重新设置冲突网络之一的 IP，因为目前不支持冲突范围。据他们说，NAT 在隧道的两端都不是可行的解决方案。在 Azure VPN 网关后面添加新子网并将流量转发/NAT 到网络 A 也不支持。
由于重新分配网络 A 的 IP 会产生不良后果，我们不想重新分配网络 A 的 IP。不出所料，客户也不想重新分配他们的网络 C 的 IP。也许我只是在否认，但有没有人遇到过这种情况并成功解决它没有重新设置 IP？如果是，任何可以参考的支持该解决方案的文档或配置都将不胜感激。
在此先感谢您的帮助。
答案1
- 具体路由
您曾写道，您对 A 和 B 网络之间的路由感兴趣，这并不冲突……如果 SonicWall 正在这些“内部客户端网络”之间路由，并且可能不使用网络 C 上的特定 IP，则您可以通过网络进行路由，而不是针对整个 192.168.1.0/24，而是针对特定 IP（如 /32）。在路由决策中，“更好的匹配获胜”。在这种情况下，特定流量将正确地从 B 路由到 A，而其余流量将传递到网络 C……
根据 VPN 的类型，在 SonicWall 上配置可能更容易或更难（如果可能的话），但从技术上讲，这可能是没有 NAT 的方法。在最坏的情况下，您可以让其他设备终止 VPN 到 Azure，而 SonicWall 上有静态路由规则将这些 IP 定向到这个额外的节点。
这样，Azure 端将永远无法从 C 访问，但根据您所写的内容，这不是问题。
- NAT
正如您所写，Azure VPN GW 不提供此功能，唯一的选择可能是在隧道的另一端（SonicWall Appliance）执行此功能。从 B、C 端，您可以像任何未使用的 IP 范围（例如 172.16.0.0/24）一样寻址“远程”站点，一旦它到达 SonicWall，它就可以路由到 VPN，而在离开节点之前，它将被 dNATed/映射到 192.168.1.0/24，同时例如保留最后一个八位字节值或执行 1:1 映射列出所有需要的 IP）。这样，对于 VPN 流量，Azure 端的远程 IP 将是“正确的”192.168.0.0/24，而 Azure 端将不知道 NAT。
如果您因某种原因无法在 SonicWall 上执行此操作，则可以放置另一台能够执行此操作/自行管理的设备，该设备将终止 VPN 隧道，并且本地网络将成为 172.16.0.0/24 流量（本地路由器上的路由）的目的地。
唯一有问题的情况是，您使用 192.168.1.0/24 地址进行 DNS 应答，并使用 IP 进行标识的证书。对于 DNS 内容，您需要具有“更新”值的本地 DNS 区域，以便客户端可以联系“正确”的端点。