有一个远程服务器,它有一个配置了 IP 地址的 LAN 接口192.168.100.2
,并且它有一个启用所有多播224.0.0.0/4
-> 的路由规则192.168.100.2
。远程服务器在 Debian 上运行,没有安装 GUI 桌面。
所有的多播都是由连接到同一个局域网的流媒体生成的192.168.100.x
。
当我在本地现场时,我将带有 GUI 桌面的笔记本电脑插入本地网络(192.168.100.x
)并使用甚高频液晶播放任意视频多播频道进行测试是否正常工作。
例如,224.0.0.1
代表1个视频通道,并使用VLC打开网络流udp://@224.0.0.1:1234/
播放该视频通道。
我想要实现的是,当不在现场时能够远程探测渠道。
有什么方法可以使用 SSH 反向隧道来实现这一点吗?
答案1
可以将接收到的多播 UDP 数据通过 SSH 转发的 TCP 流传递,并在到达时进行反向转换。这需要socat
SSH。如果办公室 PC 没有运行 Linux,socat
则可以找到非类 Unix 系统(例如 Windows)(例如:https://github.com/valorisa/socat-1.8.0.0_for_Windows)。
关于多播的备注:
使用 224.0.0.1 与使用广播相同:即使交换机进行多播侦听/查询,224.0.0.1 也是一个例外(它是永恒的所有主机多播组)不需要 IGMP,并且总是会像广播一样到处泛滥:这违背了多播流式传输。应优先选择 239.0.0.0/8 内的地址(最好先选择 239.255.0.0/16 内的地址):此范围旨在供组织内部私人使用。
“它有一个启用所有多播的路由规则
224.0.0.0/4
->192.168.100.2
”如果使用(改变不支持多播的发送者的多播目标),在 Linux 上应使用以下命令创建此类路由:
ip route add multicast 224.0.0.0/4 dev eth1
即使没有关键字
multicast
,Linux 也会强制 224.0.0.0/4 内的任何地址为多播. 无论如何,支持多播的接收器(例如)socat
可以选择要接收多播流量的接口,因此不需要此路由命令。
以下顺序是每个工具的运行顺序。它几乎但不完全是流程的反向顺序。
在办公室电脑上运行本地
socat
命令,将 1234/TCP 转换回(单播)1234/UDP(因为在监听模式下,它们都不会vlc
直接mpv
接受 TCP 流)socat TCP4-LISTEN:1234,bind=127.0.0.1,reuseaddr,fork UDP4:127.0.0.1:1234
在办公室电脑上运行 SSH 命令,为远程 1234/TCP 创建反向 SSH 隧道
ssh -o ExitOnForwardFailure=yes -R 127.0.0.1:1234:127.0.0.1:1234 user@remoteserver
此连接稍后可用于运行最终的远程
socat
命令。否则,它也可以通过添加选项保留在后台-f -N
。提前准备好
vlc
(或mpv
)客户端(下一个项目必须在 VLC 等待流超时之前完成)。这里没有多播。简单的单播 UDP 接收器。
vlc udp://:1234
mpv
也可以这样:mpv udp://:1234
运行
socat
在远程服务器上,将多播UDP流转换为TCP流并通过隧道发送socat -u UDP4-RECV:1234,ip-add-membership=224.0.0.1:eth1 TCP4:127.0.0.1:1234
当视频客户端停止时,此命令也将停止,并且必须重新启动后重新启动客户端。
让流媒体服务器在 UDP 224.0.0.1:1234 上发出多播
这实际上可以在任何步骤完成。
当步骤 3 中的视频客户端停止时,步骤 4 中的命令也将结束,并且必须再次运行。
如果目标是在办公室重新进行多播,则办公室 PC 上的步骤 1 和 3 可以替换为:
socat TCP4-LISTEN:1234,bind=127.0.0.1,reuseaddr,fork UDP4-DATAGRAM:239.255.1.2:1234
在 239.255.1.2:1234 上重新多播该流,然后可以通过以下方式接收:
vlc udp://239.255.1.2:1234
在这种情况下,无需每次都重新启动步骤 4。如果这是首选,但不打算在办公室 PC 之外使用多播,那么如果它运行的是 Linux,则可以将多播限制在主机上:
ip route add multicast 239.255.1.2 dev lo
或者为此目的创建的一些虚拟接口:
ip link add name dummymc up type dummy
ip route add multicast 239.255.1.2 dev dummymc
我不知道如何在 Windows 上处理这个问题。
注意:流数据在通过 TCP 和 SSH 时可能会合并,这应该不是问题(它是一个流...)。合并时,如果较大的 UDP 数据包达到最大大小限制,则可能会作为碎片 IP 数据包发送。此限制不会在环回接口上达到,但如果重新多播则可能会达到。正常系统无论如何都不会出现 IP 碎片问题。使用 TCP 套接字选项 TCP_NODELAY 可以帮助防止这种情况,但通常不能完全防止。它可以通过添加与 OpenSSH 一起使用,也可以通过添加TCP 套接字块-o IPQoS='lowdelay lowdelay'
一起使用。socat
,nodelay