Di solito un tunnel SSH SOCKS dà a un portatile l'uscita di rete del server. L'inoltro dinamico inverso rovescia questa disposizione: un programma sulla macchina remota può usare la rete a disposizione del vostro client SSH.

Su un client OpenSSH che supporta l'inoltro remoto senza destinazione:

ssh -N -R 127.0.0.1:1080 [email protected]

Il listener SOCKS è su remote.example.net, vincolato al proprio indirizzo loopback. I programmi lì usano 127.0.0.1:1080. Le connessioni verso le destinazioni tornano indietro attraverso SSH e vengono aperte dal lato in cui gira il vostro client.

Leggete la direzione prima dell'IP

La documentazione di ‎-R rende significativa la destinazione omessa. Una specifica con port:host:hostport è invece un inoltro fisso. Non date per scontato che un client vecchio supporti la forma dinamica abbreviata.

L'IP in uscita è quello che la rete dal lato client usa per quelle connessioni. Un portatile dietro un router domestico può uscire tramite l'indirizzo pubblico tradotto del router. Non è automaticamente l'IP del server SSH, né un indirizzo assegnato direttamente al portatile.

Mantenete il listener remoto limitato. Un binding con carattere jolly può permettere ad altre macchine di usare la rete dal lato client come uscita, secondo la politica del server. Anche il loopback può essere disponibile per altri processi idonei sull'host remoto; non è un segreto per singolo processo.

Per un insieme limitato di destinazioni, esaminate PermitRemoteOpen e la politica di inoltro del server. La rotta dipende anche dal fatto che il vostro client resti online. Quando quella connessione si chiude, il percorso proxy remoto scompare. L'inoltro inverso cambia da dove hanno origine le connessioni; non fornisce un proxy autonomo indipendente dalla sessione SSH.

Articoli correlati