Quale traffico applicativo trasporta davvero un inoltro SSH?

Il terminale si connette, il prompt appare e tutti concordano che l’accesso SSH funziona. Poi un client di database sul portatile ancora non raggiunge l’host privato, e la colpa ricade sulla sessione. Quello che è stato costruito è una shell, e questa è una delle quattro interfacce piuttosto diverse che SSH può offrire. Nomina prima l’interfaccia, poi verifica che l’applicazione la usi davvero. L’ordine conta, perché ogni interfaccia fallisce a modo suo.

Nomina l’interfaccia prima di confrontare qualsiasi cosa

Il manuale del client OpenSSH distingue quattro meccanismi facili da confondere. Una shell o un comando remoto viene eseguito sull’host SSH. Un inoltro locale apre un socket in ascolto sul client e stabilisce la connessione successiva dal lato remoto. Un inoltro remoto fa il contrario, in ascolto sul lato server. L’inoltro dinamico espone un endpoint SOCKS ai programmi che sanno usarlo.

• Shell: il programma viene eseguito sulla macchina remota, nulla ascolta localmente.
• Inoltro locale: il tuo portatile ha una porta, l’host remoto stabilisce la connessione in uscita.
• Inoltro remoto: il lato remoto ha una porta, il traffico torna verso di te.
• Dinamico: un proxy SOCKS sul client, usato solo dalle applicazioni che lo comprendono.

Nessuno di questi installa una rotta. Un programma che ignora le impostazioni del proxy, o parla UDP, o risolve i nomi da solo, non è influenzato da una sessione SSH attiva. Non è un difetto di SSH; è l’ambito dell’interfaccia che hai scelto.

Gli inoltri locale, remoto e dinamico differiscono per chi ascolta

La distinzione che decide la maggior parte dei casi è chi possiede il socket in ascolto. Con un inoltro locale, il client ascolta e l’estremità remota compone la destinazione, per questo l’indirizzo di destinazione viene risolto dal punto di vista del server. Con un inoltro remoto, il server ascolta e la connessione viene riportata verso il tuo lato, ed è così che esponi un servizio locale senza pubblicarlo direttamente.

ssh -N -L 5432:db.internal.example:5432 [email protected]
ssh -N -D 1080 [email protected]
ss -ltnp | grep -E '5432|1080'

Il primo comando lega la porta 5432 sul portatile e la inoltra al database come viene visto dal bastion. Il secondo crea un proxy SOCKS sulla porta 1080. Il terzo comando conferma quali processi sono davvero in ascolto, e questa è l’unica prova che l’inoltro esiste invece di essere fallito in silenzio per un conflitto di porte.

L’inoltro dinamico merita un avviso proprio: copre solo le applicazioni che rispettano SOCKS. Un browser può essere puntato su di esso, a uno strumento da riga di comando si può dire di usarlo, ma un driver di database con la propria pila di connessione di solito non può. Supporre che ogni programma della macchina ora usi il tunnel è l’errore più comune in tutto questo campo.

La modalità dispositivo tunnel è l’unica vera eccezione di rete

OpenSSH supporta anche l’inoltro di dispositivo tunnel -w, che passa un’interfaccia punto a punto invece di un ascoltatore TCP. È un vero tunnel di rete, e viene configurato deliberatamente, non è un effetto collaterale dell’apertura di una shell.

sudo ssh -w 0:0 [email protected]
ip addr show tun0

Richiede i numeri di interfaccia corrispondenti disponibili a entrambe le estremità, la configurazione corretta sul server e privilegi sufficienti sul client per creare il dispositivo. Richiede anche un piano di indirizzamento e instradamento, perché un’interfaccia nuda non porta alcuna politica su quali destinazioni debbano usarla.

Anche allora, il tunnel termina sull’host remoto. Qualsiasi protezione abbia offerto il trasporto SSH finisce lì, e la connessione successiva è un salto separato. Un gateway VPN ha la stessa forma di confine, ed è per questo che il confronto dovrebbe riguardare la portata e la terminazione e non quale strumento sia più forte. Nominare quel confine ad alta voce chiude anche la discussione sul fatto che un tunnel «cifri tutto», perché chiaramente non lo fa.

Verifica che la tua applicazione usi l’interfaccia che hai costruito

La verifica è per applicazione, non per sessione. Un inoltro funzionante dimostra che la porta è legata e che l’estremità remota può comporre; non dimostra che il programma che ti interessa si sia connesso attraverso di essa.

curl -sS --socks5-hostname 127.0.0.1:1080 -o /dev/null -w '%{http_code}\n' https://app.internal.example/health
psql "host=127.0.0.1 port=5432 dbname=app sslmode=require" -c 'select 1'

Il primo comando invia una richiesta attraverso l’endpoint SOCKS con il nome host risolto da remoto, e il secondo esercita la porta di database inoltrata con TLS ancora richiesto. Esegui gli stessi test con l’inoltro fermo per confermare che falliscono, perché un test che passa in entrambi i modi non ha mai usato il tunnel.

Poi confronta con una VPN instradata solo nelle dimensioni che contano: quali destinazioni sono coperte, quali protocolli funzionano, dove finisce la protezione e chi deve approvare l’accesso. Un inoltro per un singolo servizio può essere la risposta più stretta e migliore, mentre una VPN è la forma giusta quando molte applicazioni hanno bisogno dello stesso percorso di rete. Nessuna delle due concede tutto ciò che è raggiungibile dal proprio estremo remoto.