05_ssh_tunnel

约 1615 字大约 5 分钟

2026-02-04

一、ssh_tunnel 是什么？解决什么问题？

ssh_tunnel（SSH 端口转发）是一种非常实用且高效的技术。

在日常工作中，竟然会出现内外网隔离的情况，这个时候只能通过跳板机来进入内网，这无疑多了一层麻烦，而使用ssh_tunnel带来了一种直接进入内网的体验：

使用 ssh_tunnel的原理也很简单：

将本地的某个端口的全部流量
→ 通过 SSH 加密通道
→ 转发到内网目标机器的某个端口

然后浏览器使用一个代理的小插件，比如说 Zero Omega 这样的，做一次 SOCKS5 代理，代理服务器写 127.0.0.1, 代理端口填开ssh_tunnel的端口

就可以实现：

本地浏览器直接访问内网 Web / BMC
本地工具访问内网 API / 数据库
不需要在防火墙上额外放行端口

总结就是：

ssh_tunnel = 用 SSH 当“加密管道”，偷偷把内网服务搬到你本地用

二、ssh_tunnel 的基本语法

1️⃣ 本地端口转发（最常用）

ssh -L 本地端口:目标IP:目标端口 user@跳板机

含义是：

把 本地端口 > 转发到 跳板机能访问的目标IP:目标端口

例如：

ssh -L 8443:192.168.10.108:443 [email protected]

意思是：

在当前执行命令的这台机器上
打开 127.0.0.1:8443
所有流量通过 SSH
转发到 192.168.10.108:443

2️⃣ 常用参数说明

-N   # 不执行远端命令（只建隧道）
-f   # 放到后台
-C   # 压缩（慢链路有用）
-v   # 调试模式（排错非常有用）
-J   # 多级隧道连接，J是Jump

三、结合真实场景来说明

场景结构

[ 本地 Windows ]
        |
        |  SSH
        v
[ 跳板机 10.0.0.20 ]
        |
        |  SSH
        v
[ 管理机 38.95.x.x ]
        |
        |  内网
        v
[ BMC 192.168.10.108:443 ]

特点：

192.168.10.108 是私网地址
本地无法 ping
跳板机也无法直达
但是管理机可以访问 BMC

目标

在我自己的电脑浏览器里访问 https://192.168.10.108 的 BMC 管理界面

正确做法

ssh_tunnel 建在哪台机器上，端口就开在哪台机器上

情况 A：在【本地电脑】建隧道（最理想）

ssh -N \
  -L 8443:192.168.10.108:443 \
  -J [email protected] \
  [email protected]

然后在本地浏览器访问：

https://127.0.0.1:8443

只要知道跳板机和管理机的SSH密码，就可以登录

情况 B：在【跳板机】上建隧道

ssh -N -L 8443:192.168.10.108:443 [email protected]

此时：

端口 8443 开在跳板机

虽然没办法在本机上执行https://127.0.0.1:8443来登录，但是我们本机和跳板机是通的呀，在浏览器输入

https:t跳板机的IP:8443

四、为什么 ss / netstat 看不到开放的端口？

在开了ssh_tunnel后，在本机开了一个端口用来走ssh加密流量，结果却防线 ss / netstat看对应端口没有任何东西和流量再跑，原因是这样的

1️⃣ ssh_tunnel 不是普通监听服务

没有真正的 daemon
不在 iptables FORWARD 链
不走常规 socket 转发逻辑

它是：

SSH 进程内部实现的端口转发

2️⃣ 所以输入下列命令

ss -tulnp | grep 8443

什么都看不到
或只看到 ssh 进程

七、排错时非常有用的技巧

开调试模式

ssh -v -N -L 8443:192.168.10.108:443 [email protected]

重点看：

Local forwarding listening on ...
channel open
有没有 bind: Address already in use

curl命令测试报错是好事

curl -k https://127.0.0.1:8443

看到：

self-signed certificate

说明：

隧道是通的，只是证书不受信任

SSH_tunnel的动态端口转发

如果按照上面的方法来建立端口，会相当麻烦，比如说一个局域网里面有多台机器，就要把命令写的很长，并且让本机开放的端口也变多，然而其实我们可以直接把流量都转给管理机就行了。

1. 核心语句拆解

核心的命令是 SSH 隧道（Tunneling） 里的“动态端口转发”。

`ssh -J root@跳板机IP [email protected] -D 1080 -N`

-J root@跳板机IP (Jump Host): 告诉 SSH：“我不能直接连管理机，请先登录跳板机，以此为跳板（Jump）再去连目标。” 这比老式的两次登录要高效得多。
[email protected]: 最终的目标机器（管理机）以及登录它的用户。
-D 1080 (Dynamic Forwarding): 这是最神奇的地方。它在你的笔记本本地开启了一个端口（1080），并把它变成了一个 SOCKS5 代理服务器。
-N (No Command): 告诉 SSH：“我只想建立隧道，不需要远程系统的 Shell 界面。”这就是为什么运行后窗口会“卡住”的原因——它在后台辛勤地搬运数据呢。

为什么能实现你的需求？

原本你的浏览器无法触达 10.105.1.x的局域网，而在本地配置了这个隧道后：

浏览器把请求发给本地 1080 端口。
SSH 客户端把请求打包，通过加密通道传给跳板机。
跳板机传给管理机。
管理机替你向 10.105.1.x 发起请求，并将结果按原路返回。 结果： 在浏览器看来，它就像是直接坐在管理机面前上网一样。

2. 完整连接方案技术文档 (Markdown)

远程 BMC 跨网段访问方案文档

1. 场景描述

本地环境： 办公笔记本 (Windows/CLI)
第一跳 (Jump Host)： Debian 12 跳板机 (仅外网/内网可达)
第二跳 (Target Host)： 管理机 154.61.x.x (可访问 BMC 网段)
目标： 访问 10.105.1.0/24 网段机器的 BMC Web 界面。

2. 网络拓扑架构

笔记本 (Local:1080) <---SSH Tunnel---> 跳板机 <---> 管理机 <---> BMC (10.105.1.x)

3. 前置配置

3 权限准备

将笔记本的ssh公钥添加至管理机 154.61.x.x 的 ~/.ssh/authorized_keys 中，确保能够免密登录。
管理机权限设置：chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys。

4. 操作步骤

第一步：开启隧道

在笔记本终端执行：

ssh -J root@跳板机IP [email protected] -D 1080 -N

注：输入该命令后，该窗口将不会又任何输出，这是正常现象，请让该窗口保持开启，不可关闭。

第二步：配置浏览器代理 (SwitchyOmega)

代理设置： 创建 SOCKS5 代理，地址 127.0.0.1，端口 1080。

第三步：访问

直接在地址栏访问：https://10.105.1.x

5. 常用维护命令

查看端口占用： netstat -ano | findstr :1080
强制关闭隧道： taskkill /F /IM ssh.exe
测试隧道联通性： curl -I -k --socks5 127.0.0.1:1080 https://10.105.1.101