通过 SSH 隧道的 UDP 流量

hea*_*vyd 84 ssh tunnel udp

标题几乎总结了它。我想通过 SSH 隧道发送 UDP 流量。具体来说,我需要能够通过隧道发送 UDP 数据包,并让服务器能够在另一端将它们发送回给我。我知道如何为 TCP 连接做到这一点。这可以用UDP吗?

Joh*_*n T 46

这个小指南告诉您如何使用大多数类 UNIX 操作系统的标准工具(ssh、nc、mkfifo)通过 SSH 发送 UDP 流量。

通过 SSH 连接执行 UDP 隧道

一步步

使用 SSH 连接打开 TCP 转发端口

在您的本地机器(本地)上,通过 SSH 连接到远程机器(服务器),并使用附加的 -L 选项,以便 SSH 进行 TCP 端口转发:

local# ssh -L 6667:localhost:6667 server.foo.com
Run Code Online (Sandbox Code Playgroud)

这将允许您本地机器的端口号 6667 上的 TCP 连接通过安全通道转发到 server.foo.com 上的端口号 6667。

在服务器上设置 TCP 到 UDP 转发

在服务器上,我们在 TCP 端口 6667 上打开一个侦听器,它将数据转发到指定 IP 的 UDP 端口 53。如果你想像我一样做 DNS 转发,你可以在 /etc/resolv.conf 中找到第一个域名服务器的 IP。

但首先,我们需要创建一个fifo。fifo 是在两个通道之间进行双向通信所必需的。一个简单的 shell 管道只会将左进程的标准输出传送到右进程的标准输入。

server# mkfifo /tmp/fifo
server# nc -l -p 6667 < /tmp/fifo | nc -u 192.168.1.1 53 > /tmp/fifo
Run Code Online (Sandbox Code Playgroud)

这将允许服务器端口 6667 上的 TCP 流量转发到 192.168.1.1 端口 53 上的 UDP 流量,并返回响应。

在您的机器上设置 UDP 到 TCP 转发

现在,我们需要做与上面在本地机器上所做的相反的事情。您需要特权访问才能绑定 UDP 端口 53。

local# mkfifo /tmp/fifo
local# sudo nc -l -u -p 53 < /tmp/fifo | nc localhost 6667 > /tmp/fifo
Run Code Online (Sandbox Code Playgroud)

这将允许本地机器端口 53 上的 UDP 流量被转发到本地机器端口 6667 上的 TCP 流量。享受您的本地 DNS 服务器:)

正如您可能已经猜到的那样,当在本地机器上执行 DNS 查询时,例如在本地 UDP 端口 53 上,它将被转发到本地 TCP 端口 6667,然后到服务器的 TCP 端口 6667,然后到服务器的 DNS 服务器,UDP 192.168.1.1 的 53 端口。要在本地机器上享受 DNS 服务,请将以下行作为 /etc/resolv.conf 中的第一个名称服务器:

nameserver 127.0.0.1
Run Code Online (Sandbox Code Playgroud)

  • 此解决方案不安全。TCP 流不能保证保留消息边界,因此单个 UDP 数据报可能会被分成几部分,从而破坏任何协议。 (36认同)
  • 解决方案是在每个数据包通过 TCP 流发送之前为其添加一个长度,并从中重建原始数据包。编写一个 C 脚本来做到这一点很容易,但我不确定是否存在现成的解决方案。实际上,在这种情况下,TCP 通常似乎会保留消息边界,但随时可能发生奇怪的故障。 (4认同)
  • 使用 IRC 使用的端口 1153 而不是 6667(来自 man SSH 示例)也可能很好。 (2认同)
  • @JuhoÖstman 感谢您指出这个陷阱。意识到这个问题......你有没有找到解决方案?足够小的消息是否可以使其发挥作用? (2认同)

nik*_*nik 35

这个例子(我认为 John 的回答在不同的地方指出了同样的事情),描述了如何通过 TCP/SSH 连接访问另一台机器的 UDP/DNS 服务。

我们将本地 UDP/53 流量转发到 TCP,然后使用 SSH 端口转发机制的 TCP 流量到另一台机器,然后 TCP 到另一端的 UDP/53。
通常,您可以使用 openvpn 来完成。
但在这里,我们将使用更简单的工具来完成,只有 openssh 和 netcat。

在该页面的末尾,是另一个引用“ socat”的注释,
使用相同的 UDP/DNS 访问,

服务器端:socat tcp4-listen:5353,reuseaddr,fork UDP:nameserver:53
客户端:socat udp4-listen:53,reuseaddr,fork tcp:localhost:5353

有关更多信息,请参阅socat 示例

  • FWIW,我在我的主页上写了一份更详细的指南(http://www.morch.com/2011/07/05/forwarding-snmp-ports-over-ssh-using-socat/),描述了如何通过 SSH 设置 socat 以进行 UDP 转发。它以 SNMP 为例。 (5认同)
  • 这个对我来说似乎比公认的答案有用得多。我需要视频流的单向重定向 (TS/UDP)...`ssh orig_strm_src socat udp4-listen:4003,reuseaddr,fork STDOUT| socat STDIN udp-sendto:localhost:4003` (4认同)

use*_*686 22

SSH(至少是 OpenSSH)支持简单的 VPN。使用客户端中的-wTunnel选项ssh,您可以tun在两端创建一个设备,可用于转发任何类型的 IP 流量。(另请参见Tunnel的手册页ssh_config(5)。)请注意,这需要两端的 OpenSSH(可能还有 root 权限)。

  • @humanityANDpeace:您可以使用`ip tuntap add`预先创建tun/tap设备并使它们归特定用户所有。 (7认同)
  • 将这个答案从“你可以做到”扩展到展示你到底如何做到这一点以及要执行哪些命令将非常有帮助 (5认同)

ssf*_*ers 21

或者,您可以简单地使用ssf(旨在处理此用例),并使用一个简单的命令:


客户端:

#>./ssfc -U 53:192.168.1.1:53 server.foo.com
Run Code Online (Sandbox Code Playgroud)

此命令通过 localhost 和 server.foo.com 之间的安全隧道将本地端口 53 (dns) 重定向到 192.168.1.1 端口 53。


您将需要一个 ssf 服务器(而不是- 或旁边 -您的 ssh 服务器):

#>./ssfs
Run Code Online (Sandbox Code Playgroud)

顺便说一句,ssf 的客户端和服务器端都可以在 Windows / Linux / Mac 上运行。这是一个用户级应用程序,因此您不需要 tun/tap 或 VPN。

要重定向端口 53,您将需要管理权限 - 无论您使用什么工具。

有关更多信息、详细信息、用例或下载:https : //securesocketfunneling.github.io/ssf/

  • @heavyd:如果他发布一堆hacky脚本,那是可以接受的,但是因为他制作了一个成熟的开源工具,所以不是吗?它完美地回答了原始问题。 (19认同)
  • 顶多是个不要脸的插件。无论如何,解决方案可能符合您的要求。顺便说一下,SSF 是开源和非盈利的。 (9认同)
  • 这非常适合我的需求。专门转发UDP端口。 (2认同)
  • 很想尝试一下,但它已经很多年没有维护了。我无法在最近的 Ubuntu 和 Manjaro 上编译它。 (2认同)

Pet*_*rch 14

我无法nc为 SNMP 工作,因为 SNMP 客户端一直在选择一个新的源 UDP 端口,并且有几个可以同时处于活动状态。

相反,我socat在这篇博文中写了一篇文章来描述如何使用 SNMP 作为示例。本质上,使用两个终端,从概述开始:

概述

一号航站楼:

client$ ssh -L 10000:localhost:10000 server
server$ socat -T10 TCP4-LISTEN:10000,fork UDP4:switch:161
Run Code Online (Sandbox Code Playgroud)

这将创建 TCP 端口 10000 的 SSH 转发并在服务器上运行 socat。请注意在 socat 命令行中如何将交换机的 IP 地址称为“交换机”。

二号航站楼:

client$ sudo socat UDP4-LISTEN:161,fork TCP4:localhost:10000
Run Code Online (Sandbox Code Playgroud)

这在客户端上设置了 socat。那应该这样做。

  • 这对我有用:) (2认同)

小智 5

如果您可以访问 UDP 端口,VPN 是更好的解决方案。

如果您只能访问 TCP SSH 端口,那么 SSH 隧道与 VPN 一样好,至少对于 ping 和数据包回溯而言。