Il menu mostra la connessione SSH come attiva, la chiave dell’host è stata accettata, e il browser continua a non raggiungere nulla di ciò che avrebbe dovuto raggiungere. Non è una contraddizione, perché un profilo NetworkManager-ssh può produrre due esiti molto diversi dallo stesso host e dalla stessa chiave: un dispositivo tunnel che trasporta pacchetti, oppure un insieme di inoltri che solo alcune applicazioni possono usare. L’indicatore segnala che la relazione SSH gestita esiste. Non segnala mai quale dei due avete ottenuto.

Due esiti dietro una voce di menu

Entrambe le modalità autenticano allo stesso modo, ed è proprio per questo che si confondono. Selezionare il profilo esattamente nello stesso modo, con le stesse credenziali, può lasciarvi con un’interfaccia attraverso cui instradare oppure con un socket in ascolto di cui un’applicazione deve essere informata.

Iniziate decidendo quale esito serve davvero all’attività. Un requisito di raggiungibilità di un’intera sottorete richiede un dispositivo. Un singolo servizio su un host remoto richiede un inoltro, e costruire un tunnel per esso di solito crea più lavoro di instradamento di quanto il problema meritasse.

Che cosa deve avere ciascuna modalità prima di funzionare

Il progetto documenta entrambe le modalità, e i prerequisiti differiscono abbastanza che uno mancante sembra un guasto del protocollo e non una scelta di progetto.

ModeWhat must existWhat still has to be true
Tunnel deviceCompatible TUN/TAP arrangement on both ends, permission, addressingA route policy that actually sends the intended prefixes into it
Forwarding onlyA chosen SOCKS, local-forward or remote-forward listenerA permitted destination path on the far side

Leggete con attenzione la colonna di destra, perché è lì che finiscono la maggior parte di questi ticket. Anche un dispositivo tunnel costruito perfettamente copre solo ciò che l’instradamento vi invia, e anche un inoltro perfetto aiuta solo le applicazioni a cui è stato detto di usarlo.

L’interfaccia fittizia non è un tunnel

In modalità inoltro il plugin documenta un’interfaccia fittizia creata per soddisfare il modello di connessione. Esiste perché il gestore abbia qualcosa a cui collegare lo stato. Non trasporta pacchetti applicativi arbitrari verso la rete remota, e nulla della sua presenza implica che l’instradamento IP sia cambiato.

Gli esempi di tunnel completo nel progetto riguardano il supporto del dispositivo tunnel di OpenSSH, quindi la parola tunnel in un’etichetta descrive una capacità, non la vostra politica effettiva. Verificate che cosa farà il kernel invece di come si chiama il profilo.

nmcli connection show --active
ip -br link
ss -lntp | grep -E "1080|8080"

Poi abbinate l’esito all’applicazione. Un programma che comprende SOCKS deve essere configurato per usare il proxy. Un consumatore di inoltro locale deve essere indirizzato al suo listener. Nessuno dei due scopre l’inoltro da solo, e a nessuno dei due serve un indicatore di connessione diventato verde.

Preparate il lato remoto invece di forzarlo

Un normale account SSH può autenticarsi senza alcuna autorizzazione ad attivare un dispositivo tunnel remoto. Il progetto documenta un percorso senza root in cui un amministratore crea in anticipo il dispositivo per quell’utente, e il client sceglie poi il numero corrispondente.

Tale disposizione richiede coordinamento con la politica dei tunnel del server e con chi possiede l’indirizzamento sulla rete remota. Creare il dispositivo non concede di per sé le rotte delle risorse, le autorizzazioni all’inoltro o un percorso di ritorno, e nulla di tutto ciò arriva perché la configurazione di esempio sembrava convincente.

Quello che non dovreste fare è abilitare un inoltro illimitato o un accesso root remoto per far funzionare un esempio. Dove l’operatore possiede la configurazione della rete remota, usate la disposizione supportata per lasciare quei comandi a quel proprietario, ed evitate un secondo aiutante che ripristina indirizzi in conflitto alla disconnessione.

Contesto di autenticazione, e che cosa mettere nel ticket

L’autenticazione ha un proprio contesto. Il plugin cerca un agente SSH associato alla sessione dell’utente e richiede che l’host di destinazione sia noto, quindi una chiave che funziona in un terminale non diventa automaticamente visibile al percorso di autenticazione del gestore. Fate registrare e verificare la chiave dell’host tramite la procedura approvata invece di disattivare il controllo.

Per l’assistenza, annotate quattro cose: il plugin e la versione, la modalità selezionata, l’identità remota prevista e l’interfaccia o il listener che sarebbe dovuto apparire. Poi provate direttamente il punto di ingresso dell’applicazione. Un indicatore connesso insieme a un test funzionante è una prova; un indicatore connesso da solo è un’affermazione su SSH, non sull’instradamento o sull’autorizzazione di risorsa che stavate cercando di ottenere.

Articoli correlati