NetworkManager-ssh 显示已连接却没有任何流量被路由
指示器只能证明受管的 SSH 关系存在。先确认插件建成了隧道设备还是一组转发，再测试应用的路径。
菜单把 SSH 连接显示为已激活，主机密钥已被接受，而浏览器仍然到不了它本该到达的任何地方。这并不矛盾，因为同一个主机和同一把密钥，NetworkManager-ssh 配置可能产出两种截然不同的结果：承载数据包的隧道设备，或只有特定应用才能使用的一组转发。指示器报告的是受管 SSH 关系存在。它从不报告你拿到的是两者中的哪一种。
一个菜单项背后的两种结果
两种模式的身份验证方式完全相同，这正是它们被混淆的原因。用同样的方式、同样的凭据选择配置文件，你可能得到一个可以从中路由的接口，也可能得到一个必须告知某个应用的监听套接字。
先判断任务真正需要哪种结果。要求整个子网可达，就需要设备。远端主机上的单个服务，需要一条转发；为它搭隧道，通常会产生超出问题本身的额外路由工作。
每种模式在生效之前必须具备什么
项目对两种模式都有文档，而两者的前提条件差异很大，缺失一项时看起来像协议故障，而不是设计选择。
| Mode | What must exist | What still has to be true |
|---|---|---|
| Tunnel device | Compatible TUN/TAP arrangement on both ends, permission, addressing | A route policy that actually sends the intended prefixes into it |
| Forwarding only | A chosen SOCKS, local-forward or remote-forward listener | A permitted destination path on the far side |
仔细阅读右栏，多数此类工单都终结在那里。即使隧道设备搭得完美，它也只覆盖路由送进去的部分；即使转发完美，也只帮助被要求使用它的那些应用。
哑接口并不是隧道
在转发模式下，插件会创建一个哑接口来满足连接模型。它存在是为了让管理器有东西可以挂状态。它不把任意应用数据包送到远端网络，它的存在也不意味着 IP 路由发生了变化。
项目里的全隧道示例针对的是 OpenSSH 的隧道设备支持，所以标签上的隧道一词描述的是能力，而不是你的实际策略。要看内核会做什么，而不是配置文件叫什么。
nmcli connection show --active
ip -br link
ss -lntp | grep -E "1080|8080"接下来把结果和应用对上。理解 SOCKS 的程序必须被配置为使用代理。本地转发的使用方必须被指向它的监听端口。两者都不会自己发现转发，连接指示器变绿也帮不上任何一方。
准备远端，而不是强推
普通 SSH 账户也能完成身份验证，却没有任何权限去建立远程隧道设备。项目记录了非 root 的路径：管理员预先为该用户创建好设备，客户端再选择对应的编号。
这种安排需要与服务器端的隧道策略协调，也需要与远端网络的地址管理者协调。创建设备本身并不授予资源路由、转发权限或回程路径，这些都不会因为示例配置看起来有说服力就出现。
不该做的是为了让示例跑通就开启不受限制的转发或远程 root 登录。当远端网络由运维方负责时，使用受支持的安排把这些命令留给那位负责人，并避免第二个辅助程序在断开时又恢复出冲突的地址。
身份验证的上下文，以及工单里该写什么
身份验证有自己的上下文。插件会寻找与用户会话关联的 SSH agent，并要求目标主机是已知的，所以在一台终端里能用的密钥，不会自动对管理器的验证路径可见。应当走已批准的流程把主机密钥登记并校验，而不是关掉检查。
给支持人员的记录有四件事：插件及版本、所选的模式、预期的远端身份，以及本应出现的接口或监听端口。然后直接测试应用的入口点。已连接指示器加上一条能跑通的测试才是证据；单凭一个已连接指示器，那只是关于 SSH 的陈述，与你想要获得的链路或资源权限无关。