Eccoci qui con la seconda puntata del capitolo su SSH in cui parleremo del tunneling. Si definisce “tunneling SSH” una tecnica particolare utile per indirizzare, ad esempio, del traffico TCP attraverso un tunnel sicuro creato mediante una connessione SSH.

Esistono due tipi di tunneling: il primo che andremo a vedere si chiama tunneling locale, che consiste nel mettere in ascolto una porta del computer locale, chiedendo ad una postazione remota di indirizzare tutto il traffico TCP verso la porta da noi indicata. Per esempio, supponiamo di dover accedere dal nostro computer ad un server apache presente in una rete remota: questa rete ha un IP pubblico ospitante un server SSH accessibile dall’esterno, mentre il web server in questione è accessibile solamente se si è dentro la stessa rete. Quindi chi è fuori come noi ad esempio, non può fare altro. Tuttavia conosciamo qual è l’indirizzo IP interno di questo web server e la porta di apache che in genere è la 80.

Sul nostro computer avviamo una shell SSH scrivendo:

ssh -N -L portascelta:indirizzoipinternoremoto:80 nomeutente@ippubblicoesterno

Cosa significa ciò? -N non avvierà una shell SSH, -L serve per attivare il tunneling remoto, la stringa successiva significa: metti in ascolto una porta scelta da noi (ad esempio la 8000) verso la porta 80 dell’indirizzo ip interno remoto, dopodichè nomeutente@ ip pubblico esterno per avviare la connessione SSH col server SSH accessibile pubblicamente.

Se adesso noi proviamo a scrivere sulla barra degli indirizzi del browser: localhost:8000, possiamo constatare che siamo riusciti ad accedere al web server Apache accessibile normalmente da IP interno di quella rete remota, creando un tunneling tra il nostro computer locale e il server SSH presente in quella rete, però accessibile da IP pubblico. Naturalmente l’unico requisito è che il server SSH e quel web server possano comunicare.

Questo sistema può funzionare, ad esempio, se è invece questo server pubblico direttamente ad avere una porta accessibile solo da localhost. Mettiamo che vi sia installata su tale server un’interfaccia web di configurazione webmin raggiungibile tramite la porta 10000, la quale però è accessibile solo tramite localhost e non da fuori. Il ragionamento è identico: ssh -N -L 8000:localhost:10000 nomeutente@indirizzoip

Passiamo quindi al secondo tipo di tunneling, ossia quello remoto: supponiamo di avere un server SSH che si trova in una rete nattata, la quale non è accessibile dall’esterno. Nel nostro esempio questo server SSH ha un IP fornito dal provider, in questo caso Iliad, che però non è pubblico (infatti provando a fare l’accesso a questo IP non si va direttamente sul server), per cui l’unico modo per accedervi è creare un tunnel remoto. Abbiamo due requisiti fondamentali in tal caso: quello di avere un altro server avente invece IP pubblico accessibile normalmente, e che il server presente su IP Iliad possa accedere a questo IP pubblico.

Questo tipo di tunneling è detto anche “Reverse Tunneling” e consente di indirizzare le richieste di una porta creata sul server pubblico, verso il server nattato.

Per prima cosa, sul server pubblico dobbiamo andare a modificare il file /etc/ssh/sshd_config, attivando le voci “AllowTcpForwarding” e “GatewayPorts”, semplicemente assegnandogli il valore “yes”. Infine riavviamo il servizio sshd in base all’init system della nostra distro.

Poi sul server nattato, dobbiamo aprire una connessione SSH col server pubblico scrivendo:

ssh -Ng -R portadireindirizzamento:localhost:22 utente@serverippubblico

Cosa significa? -N l’abbiamo visto prima, g invece consente di attivare il GatewayPorts, -R per aprire il tunnel remoto, la stringa successiva dice: tutte le richieste fatte alla porta scelta (in questo caso 8000) del server pubblico reindirizzamele sulla mia porta 22. utente@ipserverpubblico sono i dati per accedere al server SSH pubblico.

A questo punto se noi proviamo ad aprire una connessione ssh sulla porta 8000 dentro il server tunnel, possiamo constatare che veniamo reindirizzati automaticamente al server nattato, che però normalmente non sarebbe accessibile, essendo sotto IP nattato.

Se vogliamo poi accedere da altri computer, passando per questo tunnel, non dobbiamo far altro che aprire la porta scelta per l’accesso dall’esterno. Se c’è un firewall, abilitiamo il traffico TCP su tale porta, e abilitiamola eventualmente da un router.

Dovremo poi digitare sugli altri server:

ssh -p portascelta utente@indirizzoipserverpubblico

C’è però un problema, qualora non vi fosse più scambio di pacchetti tra il server nattato e server pubblico, la connessione viene chiusa dopo un intervallo di tempo. Quindi se il server nattato deve essere sempre accessibile, è importante che questo non avvenga, facendo si che il client (in questo caso il server nattato) invii ad intervalli di tempo definiti dei pacchetti nulli al server pubblico per mantenere aperta la connessione.

Basta, sul client nattato, modificare il file di configurazione /etc/ssh/sshd_config, decommentando e modificando la stringa “ClientAliveInterval”, indicando il tempo scelto, naturalmente in secondi. Questo farà si che ogni tot secondi indicati nel parametro, il client invierà al server un pacchetto nullo per mantenere la connessione e non farla cadere.

C’è anche un’altra opzione chiamata “ClientAliveCountMax” che serve invece ad indicare il numero di tentativi massimi da effettuare prima di chiudere la connessione. Infine, dopo aver salvato, riavviamo il servizio sshd.

La nostra seconda parte su SSH termina qui, per ulteriori info vi invito a guardare il video su YouTube. Grazie per la lettura!