在我目前的工作中，我们分发基于定义了多个 VM（使用 KVM / libvirt）的 Linux 服务器的产品。我们计划向客户的网络公开有限的端口，并使用 iptables 将入站流量定向到适当的内部 VM。我的问题：是否有一类私有子网可用于内部仅主机网络，它与客户端 IP 子网冲突的可能性最小？具体来说，如果我从任何 RFC-1918 定义的私有子网（例如 192.168.xx）中选择 /24，则有可能与客户使用的范围发生冲突。
我注意到几个当前的 VM 实现默认为 192.168.122.x——这是由于我不熟悉的 RFC，因此这是一个安全的使用范围（大多数网络管理员会避免）？还是各个 VM 供应商只是随机选择该范围？我想我正在寻找比现有私有 (RFC1918) 地址更私有的 IP 范围。
我唯一的其他想法是使用为文档目的保留的“测试网”IP 范围之一 (RFC 5737)。请注意，我并不担心客户的网络会阻止这些 IP，因为这只是我们服务器内部的（数据包在离开盒子之前会经过 NAT 转换）。然而，这看起来确实比坚持使用默认的 192.168.122.x/24 子网更不正统。
我的建议是让客户可以配置它。将其作为安装脚本的一部分公开，然后重新配置内部的所有虚拟机，非常整洁。或者在每次进行新安装时发送技术 - 如果我是你，我会使用脚本。
如果您作为供应商告诉我您的设备被硬编码为使用我已经在使用的网络，我会非常生气。
好的 - 简而言之，除了使用您实际拥有（并且不使用）的公共 IP 范围之外，没有任何 IP 空间可以保证您不会重叠或以其他方式影响客户端网络，这是不太可能的. 您能想到的任何应该保留的东西吗？一些 bright light 可能已经在他们自己的网络上使用它，因为他们有同样的想法！或者他们正在使用的其他一些供应商也有同样的想法！您可以尝试多种技术，将造成最少的破坏，或者您可以正确地做，这允许客户进行他们自己的 IP 配置。您可以将它默认为您想要使用的那个，并假设大多数时候它不会破坏任何东西，当然，这就是您正在走向的情况。
完全不同的内部私人空间有什么问题？对于我使用示例 10.1.0.0/24 的客户端，我将分配其他一些 10 空间子网。我可能误读了你正在寻找的东西，但没有理由不分配这样的东西。