NetworkManager-ssh mostra conectado pero non se encamiña nada
O indicador só demostra que existe a relación SSH xestionada. Comprobe se o complemento creou un dispositivo de túnel ou un conxunto de reenvíos e despois probe a ruta da aplicación.
O menú mostra a conexión SSH como activa, a clave do host aceptouse e o navegador segue sen alcanzar nada do que debía alcanzar. Non é unha contradición, porque un perfil de NetworkManager-ssh pode producir dous resultados moi distintos co mesmo host e a mesma clave: un dispositivo de túnel que transporta paquetes ou un conxunto de reenvíos que só certas aplicacións poden usar. O indicador informa de que existe a relación SSH xestionada. Nunca informa de cal dos dous recibiu.
Dous resultados detrás dunha entrada de menú
Ambos os modos autentícanse igual, e precisamente por iso se confunden. Seleccionar o perfil exactamente igual, coas mesmas credenciais, pode deixalo cunha interface pola que encamiñar ou cun socket de escoita do que hai que informar a unha aplicación.
Empece decidindo que resultado necesita realmente a tarefa. Un requisito de alcance para toda unha subrede necesita un dispositivo. Un único servizo nun host remoto necesita un reenvío, e construír un túnel para el adoita crear máis traballo de encamiñamento do que o problema merecía.
Que debe ter cada modo antes de funcionar
O proxecto documenta ambos os modos, e os requisitos previos difiren o suficiente como para que un ausente pareza un fallo de protocolo e non unha decisión de deseñ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 a columna da dereita, porque é onde rematan a maioría destas incidencias. Incluso un dispositivo de túnel perfectamente construído só cobre o que o encamiñamento lle envía, e incluso un reenvío perfecto só axuda ás aplicacións ás que se lles dixo que o usasen.
A interface ficticia non é un túnel
En modo de reenvío o complemento documenta unha interface ficticia creada para satisfacer o modelo de conexión. Existe para que o xestor teña algo ao que asociar o estado. Non transporta paquetes arbitrarios de aplicacións cara á rede remota, e nada na súa presenza implica que o encamiñamento IP cambiase.
Os exemplos de túnel completo do proxecto tratan do soporte de dispositivo de túnel de OpenSSH, así que a palabra túnel nunha etiqueta describe unha capacidade, non a súa política efectiva. Comprobe que fará o núcleo en lugar de como se chama o perfil.
nmcli connection show --active
ip -br link
ss -lntp | grep -E "1080|8080"Despois faga corresponder o resultado coa aplicación. Un programa que entende SOCKS debe configurarse para usar o proxy. Un consumidor de reenvío local debe apuntar ao seu socket de escoita. Ningún dos dous descobre o reenvío por si só, e a ningún lle axuda un indicador de conexión que se puxese verde.
Prepare o lado remoto en lugar de forzalo
Unha conta SSH corrente pode autenticarse sen ningún permiso para levantar un dispositivo de túnel remoto. O proxecto documenta unha ruta sen root na que un administrador crea previamente o dispositivo para ese usuario, e o cliente escolle despois o número correspondente.
Esa disposición require coordinación coa política de túnel do servidor e con quen posúe o direccionamento na rede remota. Crear o dispositivo non outorga por si mesmo as rutas dos recursos, os permisos de reenvío nin un camiño de volta, e nada diso chega porque a configuración de exemplo parecese convincente.
O que non debería facer é habilitar un reenvío sen restricións ou un inicio de sesión root remoto para que funcione un exemplo. Onde o operador posúe a configuración da rede remota, use a disposición admitida para deixar esas ordes a ese propietario, e evite un segundo axudante que restableza enderezos en conflito ao desconectar.
Contexto de autenticación, e que poñer na incidencia
A autenticación ten o seu propio contexto. O complemento busca un axente SSH asociado á sesión do usuario e esixe que se coñeza o host de destino, así que unha clave que funciona nun terminal non se fai automaticamente visible á ruta de autenticación do xestor. Faga que a clave do host se rexistre e se comprobe mediante o proceso aprobado en lugar de desactivar a comprobación.
Para soporte, anote catro cousas: o complemento e a versión, o modo seleccionado, a identidade remota prevista e a interface ou o socket de escoita que debería aparecer. Despois probe directamente o punto de entrada da aplicación. Un indicador conectado xunto cunha proba que funciona é unha evidencia; un indicador conectado por si só é unha afirmación sobre SSH, non sobre o encamiñamento nin o permiso de recurso que intentaba obter.