In questo caso, l’uso di un tunnel SSH è l’ideale, sempre che si disponga di un server linux con IP pubblico da usare.

In pratica la situazione è questa:

raspberry 192.168.1.10
router/AP (doppio IP) 192.168.1.1/192.168.10.20
router/gateway pubblico 192.168.10.1/61.24.35.76

Pertanto, il raspberry per “navigare” passa attraverso il router/AP che a sua volta passa attraverso il router/gateway pubblico.

Raggiungere il raspberry da internet con questa configurazione non è possibile, a meno che non si possa configurare il router/gateway e poi il router/AP per inoltrare i pacchetti diretti verso una determinata porta del router/gateway verso il raspberry.

Abbiamo a disposizione un server linux con IP pubblico, ad esempio il 60.60.60.60.

Cosa possiamo fare?
Dal raspberry possiamo avviare un tunnel ssh verso il server linux e “dirgli” che se dovessero arrivargli pacchetti su una determinata porta, li deve girare verso il raspberry, tramite il tunnel ssh.

Questa cosa può essere fatta nativamente da SSH attivando un remote port forwarding.

Innanzitutto bisogna creare una chiave pubblica SSH sul raspberry e caricarla sul server linux. Non mi dilungo su questa parte.

Sul server linux bisogna inserire nel file /etc/ssh/sshd_config la seguente direttiva:
GatewayPorts yes

Successivamente, sul raspberry, dovremo lanciare il seguente comando:

ssh -R 2203:localhost:22 utente@60.60.60.60

dove 2203 e la porta da aprire sul server linux, 22 è la porta del raspberry che vogliamo risponda, utente@60.60.60.60 è l’utente e l’IP/FQDN del server linux

Cosi’ facendo, sarà possible collegarsi alla porta 2203 del server linux 60.60.60.60 tramite il client ssh e vedremo rispondere il servizio ssh del raspberry.

Ovviamente possiamo girare non solo la porta 22, ma anche altre porte, ad esempio la 80 se vogliamo rendere pubblico un servizio web su internet.

Riavviando il raspberry, purtroppo, il tunnel verrà interrotto. Per mantenerlo sempre attivo ed avviarlo in automatico in caso di reboot del raspberry, consiglio l’installazione del pacchetto autossh:
apt-get install autossh

e poi l’inserimento della seguente riga come penultima (prima di exit 0) del file /etc/rc.local:
autossh -2 -fN -M 20000 -R 2203:localhost:22 utente@60.60.60.60

In alternativa è possibile creare un file Systemd service per autossh. Creare il file /etc/systemd/system/autossh-tunnel.service con dentro:

[Unit]
Description=AutoSSH tunnel service
After=network.target

[Service]
Environment="AUTOSSH_GATETIME=0"
#-p [PORT]
#-l [user]
#-M 0 --> no monitoring
#-N Just open the connection and do nothing (not interactive)
# LOCALPORT:IP_ON_EXAMPLE_COM:PORT_ON_EXAMPLE_COM
ExecStart=/usr/bin/autossh -2 -fN -M 20000 -R 2203:localhost:22 utente@60.60.60.60
ExecStop=/bin/kill -9 autossh

[Install]
WantedBy=multi-user.target

Poi abitiliamo:

systemctl daemon-reload
systemctl enable autossh-tunnel.service
systemctl start autossh-tunnel.service

Per verificare:

journalctl | grep autossh

enjoy!

1. Network Address Translation (NAT)
2. Bridged networking
3. Internal networking
4. Host-only networking
5. NAT con Port-forwarding

Network Address Translation (NAT)

Questa è la modalità predefinita per le nuove VM ed è da preferire nella maggior parte delle situazioni in cui il guest è di tipo “client” (nel senso che il guest fa generalmente richieste in uscita e non in entrata). Ecco come funziona:

Quando il SO guest viene avviato, in genere utilizza il il server DHCP di VirtualBox per ottenere un indirizzo IP. VirtualBox gestirà questa richiesta DHCP e darà al sistema operativo guest l’indirizzo IP e l’indirizzo del gateway per instradare le connessioni in uscita.
In questa modalità, ad ogni vm viene assegnato lo stesso indirizzo IP (10.0.2.15) perché ogni vm è su una rete isolata. Quando invia traffico attraverso il gateway (10.0.2.2) VirtualBox riscrive i pacchetti per farli apparire come se fossero originati dall’ Host, piuttosto che dal guest (in esecuzione all’interno dell’Host).

Ciò significa che il client funzionerà anche se l’host si sposta da una rete all’altra (ad esempio, computer portatile in movimento da un luogo all’altro).

Tuttavia, come fa un altro computer per avviare una connessione verso il Guest? Ad esempio la connessione al server Web in esecuzione nel Guest. Questo non è (normalmente) possibile utilizzare la modalità NAT. Per questo motivo i server che eseguono VM che necessitano di connessioni dall’esterno, preferiscono una diversa modalità di rete.

Bridged Networking

Bridged Networking viene utilizzato quando si desidera che la vm debba essere un componente della rete a tutti gli effetti, ovvero di essere esposto sulla rete come l’host o come un qualsiasi altro PC sulla rete.

In questa modalità, una scheda di rete virtuale è il “ponte” per la scheda di rete fisica sul vostro host, in questo modo:

Grazie a questo, ogni VM ha accesso alla rete fisica nello stesso modo dell’host. Si può accedere a qualsiasi servizio sulla rete come, ad esempio, i servizi DHCP, servizi di ricerca, le informazioni di routing allo stesso modo in cui lo fa l’host fa. Quindi, la rete è simile a:

Internal Networking

Quando si configurano una o più macchine virtuali per stare su una rete interna, VirtualBox fa si che tutto il traffico su tale rete sia visibile alle sole vm su quella rete virtuale. Una configurazione simile a questa:

La rete interna (in questo esempio “INTNET”) è una rete totalmente isolata. Questa è una buona soluzione per i test quando si ha bisogno di creare sofisticate reti interne con vm che forniscono i loro servizi alla sola rete interna (ad esempio di Active Directory, DHCP, ecc.) Da notare che nemmeno il Guest è un membro della rete interna, ma questa modalità permette alle VM di funzionare anche quando l’host non è connesso a una rete (ad esempio su un aereo).

E’ possibile creare/gestire diverse reti interne ed è possibile configurare le VM per avere più schede di rete di cui una interna ed una di tipologia diversa.

Che cosa succede se si vuole una rete interna dove l’host VirtualBox fornisca gli indirizzi IP ai suoi ospiti? Per questa esigenza, si potrebbe prendere in considerazione la successiva modalità.

Host-only Networking

Rete di soli host è come una rete interna in cui si indica che la rete dei Guest sia su, in questo caso, “vboxnet0”:

Tutte le vm sono attive sulla rete “vboxnet0” e, inoltre, l’host può vedere anche le VM. Tuttavia, altre macchine esterne non possono vedere i Guest di questa rete, da qui il nome “Host-only”.

Logicamente, la rete è simile alla seguente:

Port-Forwarding with NAT Networking

Abbiamo scritto prima che “normalmente” non è possibile con la modalità NAT, fare una connessione da un computer esterno verso il Guest.

Che cosa succede se VirtualBox è, ad esempio, su un computer portatile e si vuole che una o più macchine virtuali possano essere raggiungibili dall’esterno? Ovviamente con un computer portatile è sottointesto che si passerà da una rete all’alltra abbastanza frequentemente.

In questo caso:

NAT – non funzionerà perché le macchine esterne non possono connettersi al Guest
Bridged – probabilmente si, ma il client necessita di IP della rete in cui si è connetti e quindi bisogna ogni volta aggiornare gli IP sui Guests
Interno – avendo bisogno che le VM siano visibili sulla rete (a computer esterni), questa modalità non va bene
Host-only – stesso problema di sopra, perché vogliamo che macchine esterne effettuino la connessione alle VM

Bene, in questo caso si può usare la modalità NAT e creare dei Port-forwarding! Basterà infatti:
1 – Configurare la VM per l’utilizzo delle reti NAT;
2 – Aggiungere regole di invio porta;

Le macchine esterne dovranno collegasi all’IP dell’host ed alla porta configurata per il forwarding e le connessioni vengono inoltrate da VirtualBox al Guest.

Ad esempio, se la vm gestisce un server web sulla porta 80, è possibile impostare le regole in questo modo:


che significa: “le connessioni sulla porta 8080 nell’host devono essere trasmesse sulla porta 80 della VM”.

enjoy!