NetworkManager-ssh muestra conectado pero no se enruta nada
El indicador solo demuestra que existe la relación SSH gestionada. Compruebe si el complemento creó un dispositivo de túnel o un conjunto de reenvíos y, después, pruebe la ruta de la aplicación.
El menú muestra la conexión SSH como activa, la clave del host se aceptó y el navegador sigue sin alcanzar nada de lo que debía alcanzar. No es una contradicción, porque un perfil de NetworkManager-ssh puede producir dos resultados muy distintos con el mismo host y la misma clave: un dispositivo de túnel que transporta paquetes o un conjunto de reenvíos que solo ciertas aplicaciones pueden usar. El indicador informa de que existe la relación SSH gestionada. Nunca informa de cuál de los dos ha recibido.
Dos resultados detrás de una entrada de menú
Ambos modos se autentican igual, y precisamente por eso se confunden. Seleccionar el perfil exactamente igual, con las mismas credenciales, puede dejarle con una interfaz por la que enrutar o con un socket de escucha del que hay que informar a una aplicación.
Empiece decidiendo qué resultado necesita realmente la tarea. Un requisito de alcance para toda una subred necesita un dispositivo. Un único servicio en un host remoto necesita un reenvío, y construir un túnel para él suele crear más trabajo de enrutamiento del que el problema merecía.
Qué debe tener cada modo antes de funcionar
El proyecto documenta ambos modos, y los requisitos previos difieren lo bastante como para que uno ausente parezca un fallo de protocolo y no una decisión de diseño.
| 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 |
Lea con atención la columna derecha, porque es donde terminan la mayoría de estas incidencias. Incluso un dispositivo de túnel perfectamente construido solo cubre lo que el enrutamiento le envía, e incluso un reenvío perfecto solo ayuda a las aplicaciones a las que se les dijo que lo usaran.
La interfaz ficticia no es un túnel
En modo de reenvío, el complemento documenta una interfaz ficticia creada para satisfacer el modelo de conexión. Existe para que el gestor tenga algo a lo que asociar el estado. No transporta paquetes arbitrarios de aplicaciones hacia la red remota, y nada en su presencia implica que el enrutamiento IP haya cambiado.
Los ejemplos de túnel completo del proyecto tratan del soporte de dispositivo de túnel de OpenSSH, así que la palabra túnel en una etiqueta describe una capacidad, no su política efectiva. Compruebe qué hará el núcleo en lugar de cómo se llama el perfil.
nmcli connection show --active
ip -br link
ss -lntp | grep -E "1080|8080"Después haga corresponder el resultado con la aplicación. Un programa que entiende SOCKS debe configurarse para usar el proxy. Un consumidor de reenvío local debe apuntar a su socket de escucha. Ninguno de los dos descubre el reenvío por sí solo, y a ninguno le ayuda un indicador de conexión que se haya puesto verde.
Prepare el lado remoto en lugar de forzarlo
Una cuenta SSH corriente puede autenticarse sin ningún permiso para levantar un dispositivo de túnel remoto. El proyecto documenta una ruta sin root en la que un administrador crea previamente el dispositivo para ese usuario, y el cliente elige después el número correspondiente.
Esa disposición requiere coordinación con la política de túnel del servidor y con quien posee el direccionamiento en la red remota. Crear el dispositivo no otorga por sí mismo las rutas de recursos, los permisos de reenvío ni un camino de vuelta, y nada de eso llega porque la configuración de ejemplo pareciera convincente.
Lo que no debería hacer es habilitar un reenvío sin restricciones o un inicio de sesión root remoto para que funcione un ejemplo. Donde el operador posee la configuración de la red remota, use la disposición admitida para dejar esas órdenes a ese propietario, y evite un segundo ayudante que restablezca direcciones conflictivas al desconectar.
Contexto de autenticación, y qué poner en la incidencia
La autenticación tiene su propio contexto. El complemento busca un agente SSH asociado a la sesión del usuario y exige que se conozca el host de destino, así que una clave que funciona en un terminal no se hace automáticamente visible a la ruta de autenticación del gestor. Haga que la clave del host se registre y se compruebe mediante el proceso aprobado en lugar de desactivar la comprobación.
Para soporte, anote cuatro cosas: el complemento y la versión, el modo seleccionado, la identidad remota prevista y la interfaz o el socket de escucha que debería haber aparecido. Después pruebe directamente el punto de entrada de la aplicación. Un indicador conectado junto con una prueba que funciona es una evidencia; un indicador conectado por sí solo es una afirmación sobre SSH, no sobre el enrutamiento ni el permiso de recurso que intentaba obtener.