www.MegaLab.it

Continuiamo il nostro viaggio nella tecnologia SSH, e scopriamo un'altra interessante possibilità per sfruttare il server remoto che abbiamo opportunamente predisposto qualche tempo addietro.

In questo caso, vogliamo fare qualcosa al limite della regolarità: superare i blocchi imposti da aziende, ambienti universitari o librerie ed accedere ai servizi offerti da Internet in piena libertà.

Scenari di utilizzo

Ho avuto bisogno per la prima volta di questa tecnica quando mi trovavo in periodo di tesi, ed ero costretto a rimanere in facoltà per tutta la giornata.

La rete interna dell'ateneo era sorvegliata da alcuni blocchi piuttosto severi. Uno fra tutti: non era possibile stabilire connessioni mediante VNC o Remote Desktop con sistemi collocati al di fuori dal perimetro universitario.

Le motivazioni sono sicuramente condivisibili, ma, fra le incombenze professionali e MegaLab.it da gestire, vi sono state alcune circostanze in cui superare questi blocchi è stata una necessità ineluttabile.

Tunnel SSH alla riscossa

Per superare queste limitazioni, SSH è uno strumento ineguagliabile. Di fatto, andremo a realizzare un canale protetto (un tunnel, appunto) verso il un server intermedio, e da qui potremo accedere a qualsiasi destinazione.

Una volta costituito il canale, è come se ci trovassimo fisicamente ad accedere ad Internet dal nostro server SSH: tutte le destinazioni che raggiungeremo vedranno come sorgente solo il server, e non il terminale che si sta utilizzando fisicamente.

Grazie alla cifratura invece, l'amministratore della rete locale vedrà solamente un flusso di byte incomprensibili.

Al lavoro

Immaginiamo di volerci collegare ad un server VNC in ascolto sulla porta 5900 di un PC residente al di fuori del perimetro, e che la connessione verso la suddetta porta sia bloccata da un apposito firewall in esecuzione sulla rete locale.

Andremo quindi ad impostare il nostro client di modo da aprire una porta locale (pensatela come l'entrata del tunnel) "collegata", per così dire, al nostro server SSH (uscita del tunnel). Tutto il traffico che imboccherà questo specifico percorso verrà inoltrato dal server SSH verso la destinazione specificata, e quindi viceversa.

A fini esplicativi, chiameremo srv-rettore il PC client su cui stiamo operando, muletto la macchina remota su cui risiede il server SSH e nasdaq il PC di destinazione

L'utente Kar.ma, che ringrazio, mi fa notare nei commenti che non è necessario che il server SSH e quello con VNC siano due calcolatori distinti. I due servizi possono naturalmente risiedere anche sulla stessa macchina. Pensandole come due entità distinte però, sarà possibile abituarsi a "rimbalzare" sul server SSH anche per raggiungere altri calcolatori: diviene così possibile connettersi anche a macchine su cui, ad esempio, sia installato VNC ma non SSH.

Sinceriamoci innanzitutto che il nostro server SSH sia raggiungibile (se non lo fosse, è possibile che la porta su cui è in esecuzione OpenSSH sia anch'essa bloccata: dovremo quindi cambiare la configurazione del server per accettare connessioni su una porta libera: ne parliamo nell'articolo "Come superare il blocco di SSH").

Se riusciremo a stabilire la connessione, potremmo scaricare e predisporre il collegamento con PuTTY.

Impostiamo il programma per la connessione a muletto, esattamente come dettagliato in precedenza. Ricordatevi che PuTTY deve essere configurato per stabilire una connessione SSH con il server intermedio, non verso la destinazione finale!

Prima di aprire la connessione, portiamoci su Connection -> SSH -> Tunnels. Da qui, andiamo a creare il tunnel: diciamo che la porta di entrata è la 5900 (per semplicità: in vero, avremmo potuto impostare un numero qualsiasi di porta ancora libero), mentre la destinazione è la porta 5900 sul computer finale.

Specifichiamo queste informazioni in PuTTY: immettiamo 5900 alla voce Source port, e nasdaq:5900 nel campo Destination. Prestate bene attenzione! In questo campo dovrete inserire la destinazione finale che desiderate raggiungere, non l'indirizzo del server SSH!

Una volta cliccato su Add, potete stabilire la connessione SSH: se tutto andrà a buon fine, il tunnel verrà creato.

Ricordate ora di mantenere in esecuzione PuTTY: alla chiusura del programma infatti, la porta locale verrà chiusa, ed il collegamento interrotto.

Come sfruttare il tunnel

Arrivati fin qui, abbiamo a disposizione un tunnel sicuro in grado di veicolare dati da una parte all'altra. Possiamo quindi far fluire informazioni attraverso di esso.

Dicevamo di volerci collegare via VNC: apriamo quindi il client VNC e proviamo a predisporre la connessione come di consueto (nell'esempio utilizzo Ultr@VNC, ma il ragionamento è analogo per qualsiasi altro programma)

Sorpresa: ancora non funziona! Questo perché, molto banalmente, stiamo impostando in maniera errata il client.

Con le impostazioni mostrate infatti, si sta tentando una connessione diretta, proprio come succedeva in precedenza: il tunnel esiste, ma in questo modo non viene utilizzato.

Dobbiamo piuttosto specificare che il collegamento passi per il nostro tunnel. In precedenza abbiamo detto:

Andremo quindi ad impostare il nostro sistema di modo da aprire una porta locale sul PC client (pensatela come l'entrata del tunnel) collegata, per così dire, al nostro server SSH (uscita del tunnel).

Ergo, per imboccare il tunnel dobbiamo impostare il client VNC di modo che si colleghi alla porta aperta sul PC locale: questo significa collegarsi a localhost

A questo punto, il collegamento dovrebbe avvenire correttamente

Complimenti! Una volta appresa la tecnica, potrete sfruttarla per qualsiasi servizio che vorrete utilizzare in modo sicuro, senza preoccuparvi degli eventuali blocchi.

Non solo porte: SSH supera anche le blacklist

Notate che rimbalzando sul vostro server SSH potete accedere a qualsiasi host remoto, anche in caso questo fosse stato esplicitamente bloccato: dovrete avere semplicemente l'accortezza di aprire un tunnel verso ogni singola porta cui desiderate accedere, e ricordarvi di modificare le opzioni del programma per collegarsi a localhost invece che direttamente al server che eroga il servizio di interesse.

Benchè in linea di principio le considerazioni siano le stesse, navigare su siti web bloccati richiede qualche accortezza in più: ne parlo nella guida "Accedere ai siti bloccati mediante SSH".