Pubblicare servizi remoti attraverso un tunnel in uscita
Disclaimer
Le informazioni, le configurazioni e le procedure riportate negli articoli di questo blog sono state redatte sulla base delle informazioni e delle tecnologie disponibili e verificate alla data di pubblicazione dell'articolo.
Il contenuto ha esclusivamente finalità informative e tecniche e non costituisce una garanzia di funzionamento o di applicabilità a ogni ambiente.
Hardware, software, firmware, configurazioni e procedure possono cambiare nel tempo. Prima di applicare quanto descritto, è pertanto responsabilità dell'utilizzatore verificare la compatibilità con il proprio ambiente e adottare le opportune misure di sicurezza e di backup.
L'utilizzo delle informazioni e delle procedure pubblicate avviene sotto la responsabilità dell'utilizzatore. L'autore non può essere ritenuto responsabile per eventuali danni, perdite di dati, interruzioni di servizio o malfunzionamenti derivanti dall'applicazione delle informazioni contenute negli articoli.
L’obiettivo di questo progetto è realizzare un sistema semplice e sicuro per rendere accessibili da Internet alcuni servizi presenti all’interno di una rete remota, senza dover esporre direttamente il router del sito e senza richiedere l’apertura di porte sulla connessione Internet dell’utente.
L’idea parte da un concetto molto semplice: utilizzare la normale connessione Internet del sito remoto per creare una connessione in uscita verso un’infrastruttura centrale.
Attraverso questa connessione è poi possibile pubblicare verso Internet solamente i servizi che si desidera rendere disponibili.
Il concetto
La struttura può essere rappresentata in modo molto semplice:
RETE LOCALE
│
├── Web
├── File
├── Telecamere
└── Applicazioni
│
▼
┌───────┐
│ CPE │
└───┬───┘
│
│ Tunnel in uscita
│
INTERNET
│
▼
┌─────────────────┐
│ Infrastruttura │
│ centrale │
└────────┬────────┘
│
▼
INTERNETIl CPE non viene quindi pubblicato direttamente su Internet.
È il CPE stesso a iniziare la connessione verso l’esterno.
Una volta stabilito il tunnel, l’infrastruttura centrale può utilizzare quella connessione per raggiungere i servizi presenti nella rete remota.
Non viene pubblicato il router
Questo è uno degli aspetti più importanti dell’architettura.
Il dispositivo presente presso il sito remoto non deve necessariamente avere:
- un indirizzo IP pubblico;
- una porta TCP/UDP esposta;
- un port forwarding;
- una regola di accesso proveniente da Internet.
La connessione viene infatti instaurata dal dispositivo remoto verso l’infrastruttura centrale.
Questo rende il modello particolarmente interessante in presenza di connessioni Internet sulle quali l’utente non dispone di un vero indirizzo pubblico o non può gestire direttamente le connessioni in ingresso.
Cosa viene pubblicato?
Il progetto non nasce con l’obiettivo di rendere accessibile tutta la rete remota.
Al contrario, l’idea è quella di pubblicare solamente determinati servizi.
Ad esempio, all’interno della rete potrebbero essere presenti:
Servizio Web
Un’applicazione web installata su un server locale può essere resa disponibile tramite un indirizzo Internet dedicato.
Internet
│
▼
https://servizio.example
│
▼
Tunnel
│
▼
Server Web nella rete remotaServizio file
Un dispositivo di archiviazione o un server locale potrebbe mettere a disposizione un servizio per la gestione dei file.
Videosorveglianza
Una telecamera o un sistema di videosorveglianza potrebbe essere pubblicato senza rendere direttamente esposto su Internet l’intero dispositivo.
Applicazioni gestionali
Lo stesso meccanismo può essere utilizzato per applicazioni aziendali, interfacce amministrative, software gestionali o altri servizi TCP/IP che devono essere raggiungibili dall’esterno.
Il principio rimane sempre lo stesso:
non viene pubblicata la rete: vengono pubblicati solamente i servizi necessari.
Il ruolo del CPE
Il dispositivo utilizzato nel sito remoto non deve essere considerato un semplice router domestico.
Per questo progetto è necessario un CPE professionale, con caratteristiche hardware e software adeguate a svolgere contemporaneamente le funzioni di routing, networking e gestione del container che realizza il tunnel.
In particolare, il dispositivo deve disporre di risorse sufficienti per eseguire un ambiente containerizzato e deve permettere di collegare il container alla rete locale e alla connessione Internet del sito.
Questa caratteristica apre possibilità interessanti perché il CPE non svolge più solamente la funzione tradizionale di router.
Diventa anche il punto di collegamento tra:
Servizi locali
│
▼
CPE
│
├── rete locale
│
└── container
│
▼
Tunnel in uscitaLa parte containerizzata
Il componente che realizza il tunnel viene eseguito all’interno di un container.
Questo permette di separare logicamente il servizio di tunnel dal sistema principale del dispositivo.
L’architettura diventa quindi:
┌──────────────────────────────┐
│ CPE │
│ │
│ ┌────────────────────────┐ │
│ │ Sistema principale │ │
│ │ │ │
│ │ Routing / Firewall │ │
│ └───────────┬────────────┘ │
│ │ │
│ ┌───────────▼────────────┐ │
│ │ Container │ │
│ │ Tunnel Client │ │
│ └───────────┬────────────┘ │
│ │ │
└──────────────┼───────────────┘
│
▼
InternetIl container dispone di una propria interfaccia di rete e utilizza la connessione Internet del CPE per instaurare il tunnel.
La procedura
La realizzazione del sistema richiede alcuni passaggi tecnici.
Il primo consiste nell’utilizzare un CPE compatibile con l’esecuzione di container.
Successivamente viene preparato lo spazio di archiviazione destinato al container e viene configurata la rete virtuale necessaria per collegarlo al sistema principale.
Il componente del tunnel viene quindi preparato per l’architettura hardware del dispositivo e importato nel sistema.
A questo punto vengono configurati:
- il supporto ai container;
- lo storage del container;
- la rete virtuale;
- l’accesso del container a Internet;
- il collegamento tra container e CPE;
- il container del client tunnel;
- l’avvio del tunnel.
La parte fondamentale è che il container deve poter raggiungere Internet attraverso la connessione del sito remoto.
Una volta configurato correttamente questo collegamento, il client può stabilire autonomamente la connessione verso l’infrastruttura centrale.
Il momento decisivo: il tunnel è attivo
Quando il tunnel viene stabilito, il sito remoto diventa raggiungibile attraverso l’infrastruttura centrale senza che sia necessario aprire una porta direttamente sulla connessione Internet del cliente.
A questo punto abbiamo ottenuto il risultato principale del progetto:
RETE REMOTA
│
┌─────────▼─────────┐
│ CPE │
│ │
│ Container │
│ Tunnel │
└─────────┬─────────┘
│
│ connessione
│ in uscita
▼
INTERNET
│
▼
┌──────────────────┐
│ INFRASTRUTTURA │
│ CENTRALE │
└──────────────────┘
Il tunnel costituisce quindi il collegamento tra la rete remota e l’infrastruttura centrale.
Da questo momento è possibile definire quali servizi della rete remota dovranno essere pubblicati e attraverso quali endpoint dovranno essere raggiunti.
Un approccio diverso alla pubblicazione dei servizi
Il punto interessante del progetto è il cambio di prospettiva.
La domanda non è più:
“Come faccio ad aprire una porta sul router?”
ma:
“Quale servizio voglio pubblicare e attraverso quale tunnel voglio renderlo disponibile?”
Il router rimane all’interno della rete del cliente e non deve essere necessariamente esposto direttamente.
La componente di pubblicazione viene spostata nell’infrastruttura centrale, mentre il CPE mantiene solamente una connessione in uscita.
Questo modello consente di costruire un’architettura nella quale ogni sito remoto può essere gestito come un endpoint indipendente, mantenendo separati la rete locale, il dispositivo CPE, il tunnel e i servizi pubblicati.
Il primo obiettivo del progetto è quindi raggiunto: abbiamo creato un collegamento sicuro in uscita dal sito remoto verso l’infrastruttura centrale, pronto per essere utilizzato per la pubblicazione controllata dei servizi presenti dietro il CPE.