小团队做远程运维，最容易把“网络不通”误判成“数据库挂了”。这次案例来自一个三人开发组：数据库只在内网，公网只能访问一台跳板机。开发同事在FinalShell里连上跳板机后，在数据库客户端直接填内网地址，结果一直超时。后来用Finalshell配置SSH隧道，把本地端口转到跳板机背后的数据库，问题才定位清楚。下面按现场顺序复盘，步骤可以直接照着排查。
案例现场：终端能连，数据库连不上
- 拓扑是：本地电脑 → 公网跳板机（22端口）→ 内网数据库（3306端口）。
- 现象是：FinalShell终端登录跳板机正常，数据库客户端连内网IP却超时。
- 误判是：先怀疑数据库白名单、账号密码，甚至想开放公网端口。
- 关键点是：终端会话停在跳板机，数据库端口并没有自动转发到本地。
- 正确做法是：在本机开一个监听端口，通过SSH隧道送到跳板机可达的内网地址。
先选方向：本地转发最适合数据库
- 本地转发：本机端口到远端可达目标，适合数据库、内网后台，本案选它。
- 远程转发：远端端口到本机服务，适合临时把本地服务给远端访问。
- 动态转发：本机提供SOCKS代理，适合浏览器访问多个内网页面。
- 案例映射：本地127.0.0.1:13306 到内网数据库10.0.0.5:3306。
- 提醒：先画箭头，确认“谁访问谁”，方向填反是常见返工点。
第二步：在FinalShell里填好四个值
- 打开对应跳板机连接的属性，找到“隧道”或“端口转发”页，新增本地转发。
- 监听地址填127.0.0.1，监听端口填13306，目标主机填10.0.0.5，目标端口填3306。
- 保存后断开并重连该会话，让隧道随SSH连接一起建立；不同版本入口略有差异，以界面为准。
- 在本机检查监听：Windows可用netstat -ano | findstr 13306，Linux/macOS可用ss -lntp | grep 13306。
- 数据库客户端改连127.0.0.1:13306，不要再填内网数据库IP。
第三步：三个细节决定能不能用
- 目标主机要填“从跳板机看过去可达”的地址，不要填本机的127.0.0.1。
- 本地端口被占用时换13307，并同步改客户端连接，不要反复重启FinalShell。
- 隧道只解决网络路径，不改变数据库授权；数据库账号需允许跳板机来源地址连接。
- 不需要给全公司访问时，监听地址保持127.0.0.1，避免把本地端口暴露到局域网。
- 隧道会随SSH会话断开，长时间使用要开保持活动或自动重连，并避免多个客户端抢同一本地端口。
复盘：一次配置省下三类折腾
- 第一，没再申请数据库公网暴露，安全边界仍在跳板机。
- 第二，开发不用记复杂命令，把映射关系写进连接备注，换人也能看懂。
- 第三，团队整理了一张映射表：业务名、跳板机、本地端口、目标地址、负责人。
- 如果只是临时排查，也可用系统ssh命令做本地转发；长期多人使用，建议配合堡垒机审计和权限回收。
- 最后检查顺序：会话是否在线、本地端口是否监听、目标地址是否可达、数据库账号是否放行、客户端是否连127.0.0.1。
这次Finalshell配置SSH隧道的经验说明，隧道不是“高级选项”，而是把内网服务安全接到本地的常规手段。先确认转发方向，再填监听与目标，最后用端口检查和客户端测试闭环，比盲目改数据库配置更省时间。