您似乎对多播的工作原理有错误的想法。加入/离开是客户端（接收者）功能。流的发送者不加入组。

如果您有两个隔离的 192.168.1.0/24 专用 LAN，则必须将 NAT 应用于离开/进入每个 LAN 的多播流量，就像任何其他第 3 层流量一样...... 1.1 的 src 没有任何意义到互联网的其余部分，只会让其他网络感到困惑。多播数据包与单播数据包基本相同：它具有源地址和目标地址。如果您将多播流从 192.168.1.1 传输到 239.0.0.1 到另一个网络，那么源现在是无意义的；本地网络中的 1.1 不是发送者。任何试图向明显的发送者发送消息的客户端都将与错误的节点通信：

(A) (server) 192.168.1.1>239.0.0.1 <-> intermediate net(s) <-> (B) (client) 192.168.1.1>239.0.0.1[假设私有地址甚至可以跨越中间网络]

NAT必须应用于私有网络的边界。假设每一方都将对方视为 192.168.2.0/24...（“我是一个，你是两个”在两个网络中都是正确的。）

(A) (server) 192.168.1.1>239.0.0.1 <-> intermediate net(s) <-> (B) (client) 192.168.2.1>239.0.0.1

“B”侧路由器将看到来自本地 1.x 主机的 239.0.0.1 连接；它不一定关心谁加入了该组，只是需要从上游请求一个组。如果使用 SSM，那么流源地址很重要，这意味着 NAT必须发生。

[注意：互连重叠网络是每个人都试图避免的痛苦。试图将多播混入这种混乱是自杀。]

假设接收者和源在两个不同的专用网络中。因此需要 NAT。

不，这不对。NAT 只需要在两个地址机制之间，通常是在私有地址和公共地址之间。

没有公共多播路由，因此尝试将 NAT 与 PIM 结合使用毫无意义。

NAT 是一个丑陋的 hack，只有在必要时才使用它。

经过长时间的研究，没有制造商提出为 2 个地址计划/方案转换 PIM 数据包的解决方案。

在上面的数据包中，可以看到 PIM 数据包包含上游邻居、组和源地址：10.4.1.2、239.1.1.9 和 104.255.224.1。

传统的“网络地址转换器”仅转换 IP 数据包的 Src 和 Dst 字段。如果这三个地址在另一个地址计划/体制中，那么就没有任何解决方案/设备可以处理“PIM 转换”。

因此，使用 COTS 解决方案不可能在 2 个 IP 寻址计划（例如，两个公共网络）之间构建多播树。