• Cloud, Guide, Sicurezza
• 23 Aprile 2026

Se lavorate con ambienti ibridi o multi-cloud vi sarete sicuramente scontrati con un problema molto concreto: come accedere in modo sicuro a macchine che non hanno (e non devono avere) un IP pubblico.

Fino a poco tempo fa, con Azure Bastion eravate vincolati a connettervi solo a risorse Azure “note” (quindi VM registrate nel portale). Questo funzionava bene, ma diventava limitante appena uscivate dallo scenario classico: una VM on-premises, una macchina in un altro cloud oppure semplicemente un host raggiungibile via IP all’interno della vostra rete.

Con la funzionalità IP-based connection Azure Bastion fa un passo in più: vi permette di collegarvi direttamente a un indirizzo IP privato. Tradotto: potete usare Bastion come punto di accesso sicuro anche verso sistemi esterni ad Azure, purché siano raggiungibili a livello di rete.

In questa guida vedremo quando ha senso usare questa modalità, quali sono i prerequisiti e come configurarla rapidamente, senza complicarvi la vita. L’obiettivo è uno: semplificare l’accesso remoto mantenendo alta la sicurezza, senza dover ricorrere a soluzioni workaround come jump box o IP pubblici esposti.

Prerequisiti

Prima di entrare nella configurazione assicuratevi di avere alcuni elementi fondamentali già pronti.

Il primo requisito è avere Azure Bastion già distribuito e funzionante. Non basta aver creato la risorsa: deve essere inserita in una rete che abbia visibilità verso i sistemi che volete raggiungere. Lo scenario ideale, e quello che useremo anche nella demo, è una topologia Hub & Spoke, con Bastion distribuito nella rete Hub.

In questo modello la Hub VNet diventa il punto centrale di connettività. Tutte le altre reti (gli spoke) si collegano alla Hub, e lo stesso vale per ambienti esterni. Se state utilizzando una VPN Site-to-Site (come nel nostro caso) o una ExpressRoute, è fondamentale che le reti on-premises siano instradate e raggiungibili dalla Hub VNet. In altre parole, Bastion deve poter “vedere” gli IP della vostra infrastruttura locale.

Per la demo utilizzerò proprio questo setup: Azure Bastion nella Hub VNet e una macchina virtuale nel datacenter raggiungibile tramite VPN Site-to-Site. Questo mi permetterà di sfruttare la IP-based connection per collegarvi direttamente all’IP privato della VM on-premises, senza passare da risorse Azure.

Figura 1: Architettura Azure Bastion con IP-based connection in uno scenario Hub & Spoke esteso verso ambienti on-premises e altri cloud

Creazione di Azure Bastion

Per la creazione di Azure Bastion potete procedere direttamente dal portale Azure. La procedura è quella classica: selezionate subscription, resource group, nome della risorsa e la rete virtuale in cui volete distribuirlo.

C’è però un dettaglio che non dovete trascurare. Nella sezione Tier dovete scegliere Standard (o uno SKU superiore). È una scelta fondamentale, perché la funzionalità di IP-based connection è disponibile solo a partire da questo livello. Se lasciate il Basic, non potrete utilizzare questa modalità di connessione.

Per quanto riguarda la rete, assicuratevi di distribuire Bastion nella VNet Hub e nella subnet dedicata AzureBastionSubnet. Questa subnet è obbligatoria e deve essere già presente o creata durante il deployment.

Figura 2: Creazione di Azure Bastion: selezione dello SKU Standard, requisito necessario per utilizzare la IP-based connection

Nella scheda Advanced selezionate IP-based connection. Per lo scenario che stiamo configurando è indispensabile abilitarla. Questa opzione permette a Bastion di connettersi direttamente a un indirizzo IP, invece che a una risorsa Azure identificata tramite Resource ID.

Figura 3: Abilitazione della funzionalità IP-based connection nelle impostazioni avanzate di Azure Bastion

Nella schermata di riepilogo potete verificare rapidamente tutte le impostazioni prima di procedere con il deployment.

Figura 4: Riepilogo configurazione e creazione di Azure Bastion con IP-based connection abilitata

Se avete già un Azure Bastion distribuito, non siete obbligati a ricrearlo da zero. Potete intervenire direttamente sulla risorsa esistente e aggiornarne le impostazioni.

Dalla sezione Configuration potete innanzitutto modificare lo SKU, passando ad esempio da Basic a Standard. Questo è il primo passo necessario, perché le funzionalità avanzate, come ho già scritto prima, non sono disponibili nei livelli inferiori.

Subito sotto trovate le feature opzionali. Qui potete abilitare la IP-based connection, semplicemente attivando l’opzione e applicando le modifiche. Ci vorranno alcuni minuti per applicare le modifiche.

Figura 5: Modifica di un Azure Bastion esistente: aggiornamento dello SKU e abilitazione della IP-based connection dalla sezione Configuration

Permessi di lettura

Per poter utilizzare correttamente Azure Bastion, dovete assicurarvi che l’utente abbia almeno il ruolo Reader sulle risorse coinvolte.

In particolare, il ruolo deve essere assegnato sulla risorsa Azure Bastion stessa. Senza questi permessi, l’utente non sarà in grado di visualizzare le risorse nel portale né avviare la connessione.

Figura 6: Verifica del ruolo Reader assegnato per consentire l’accesso alle risorse Azure

Test di funzionamento

A questo punto potete verificare che tutto funzioni correttamente. Dalla risorsa Azure Bastion spostatevi nella sezione Connect, che è il punto da cui avviate le sessioni.

Qui inserite direttamente l’indirizzo IP privato della macchina on-premises (nel mio caso 192.168.11.11). Questo è il passaggio chiave: non state selezionando una VM Azure, ma state indicando manualmente l’IP del sistema che volete raggiungere.

Subito sotto scegliete il protocollo, tipicamente RDP (porta 3389) o SSH (porta 22), e inserite le credenziali della macchina. Una volta avviata la connessione, Bastion stabilisce la sessione passando attraverso la VPN Site-to-Site.

Se la configurazione di rete è corretta, vi collegherete senza problemi alla VM nel datacenter direttamente dal browser.

Figura 7: Accesso a una VM on-premises tramite IP privato usando Azure Bastion

Come potete vedere dalla figura sotto, la connessione è andata a buon fine. Vi trovate direttamente sul desktop della macchina Windows Server nel datacenter, raggiunta utilizzando il suo indirizzo IP privato.

Figura 8: Connessione RDP riuscita a una VM on-premises tramite Azure Bastion IP-based connection

Cos’è il Native Client Support

Fino ad ora avete visto l’utilizzo di Azure Bastion direttamente dal browser. È la modalità più semplice e immediata, ma non sempre è quella più comoda, soprattutto se lavorate quotidianamente con strumenti amministrativi.

Con la funzionalità Native client support, Bastion vi permette di utilizzare i client locali, come Remote Desktop (mstsc) o SSH, mantenendo comunque tutti i vantaggi di sicurezza del servizio. In pratica, la connessione non passa più dall’interfaccia web, ma viene instradata tramite Bastion utilizzando un tunnel sicuro gestito da Azure.

Il vantaggio è evidente: potete continuare a usare i vostri strumenti abituali, senza dover esporre porte o configurare accessi diretti verso le macchine.

Configurazione

Per utilizzare questa modalità dovete prima abilitarla. Dalla sezione Configuration della risorsa Bastion attivate l’opzione Native client support e applicate le modifiche. Ci vorrà qualche minuto.

Anche in questo caso è richiesto lo SKU Standard o superiore, esattamente come per la IP-based connection. Una volta abilitata, questa funzionalità si integra perfettamente con lo scenario che avete costruito.

Figura 9: Attivazione dell’opzione Native client support

Connessione tramite client nativo

Avviate la connessione dal vostro PC utilizzando la Azure CLI con i comandi az network bastion rdp o az network bastion ssh. Io utilizzo il client nativo quando ho bisogno di un’esperienza più completa rispetto al browser, ad esempio per il supporto multi-monitor o per una migliore gestione della sessione RDP.

Installazione di Azure CLI

Per utilizzare il client nativo con Azure Bastion, dovete prima installare la Azure CLI sul vostro dispositivo.

Potete farlo rapidamente da PowerShell utilizzando il comando:

L’opzione –exact serve per assicurarvi che venga installato il pacchetto ufficiale di Microsoft Azure CLI, evitando ambiguità con altri pacchetti simili. Di default viene installata l’ultima versione disponibile, ma potete specificarne una in modo esplicito aggiungendo il parametro –version.

Io utilizzo sempre questa modalità tramite winget perché è veloce e mantiene automaticamente aggiornato il client. Date un’occhiata alle mie guide Windows Package Manager: Installazione semplificate delle applicazioni – ICT Power e Windows Package Manager: Installazione semplificata delle applicazioni in Windows Server 2025 – ICT Power

Figura 10: Installazione della Azure CLI tramite winget per utilizzare Azure Bastion con client nativo

Connessione tramite Azure CLI

Una volta installata la Azure CLI, potete avviare la connessione alla VM tramite Azure Bastion utilizzando il client RDP locale.

Il comando da utilizzare è:

A questo punto effettuate il login con un utente che possa accedere in lettura al vostro Azure Bastion (vi ricordate che prima gli abbiamo dato i permessi di lettura?).

Figura 11: Connessione alla VM tramite Azure CLI e Azure Bastion con autenticazione Microsoft Entra ID

Ho effettuato la connessione RDP con il comando

Il comando az network bastion rdp ha generato e aperto automaticamente il file RDP, che vedete infatti lanciare la classica finestra di connessione.

Il messaggio che compare è quello standard di Windows (“Opening Remote Desktop Connection”): non è un errore, ma semplicemente un avviso di sicurezza quando si apre un file .rdp.

Figura 12: Connessione RDP avviata tramite Azure Bastion Native Client verso una VM on-premises

Da qui in poi il comportamento è identico a una normale connessione RDP.

Un dettaglio interessante è la voce “Remote computer: localhost”. Non è un errore: indica che la connessione viene prima stabilita verso un endpoint locale. In realtà state utilizzando un tunnel sicuro creato da Azure Bastion, che inoltra poi il traffico verso la macchina di destinazione (in questo caso la VM on-premises).

Figura 13: Avviso di sicurezza del client RDP durante una connessione tramite Azure Bastion Native Client

A questo punto vi viene richiesto di inserire le credenziali per completare la connessione. Anche qui vedete il riferimento a localhost, ma ormai sapete che è solo l’effetto del tunnel creato da Azure Bastion.

In realtà state autenticandovi sulla macchina remota nel datacenter, non sul vostro PC. Le credenziali da utilizzare sono quindi quelle della VM on-premises (ad esempio administrator o un utente di dominio, a seconda dello scenario).

Una volta confermate, il client RDP utilizza il tunnel già aperto da Bastion per inoltrare la richiesta di autenticazione verso l’IP 192.168.11.11, passando attraverso la VPN Site-to-Site.

Figura 14: Inserimento delle credenziali durante una connessione RDP tramite Azure Bastion Native Client

Come si può vedere dalla figura sotto, il client vi avvisa che l’identità del computer remoto non può essere verificata perché il certificato non è emesso da una Certification Authority attendibile.

Nel vostro caso è perfettamente normale: la macchina on-premises sta utilizzando un certificato self-signed oppure un certificato interno non riconosciuto dal vostro PC.

È importante notare che qui compare il nome reale del server (DC1.home.nicolaferrini.com). Questo conferma che, anche se prima avete visto “localhost”, ora la connessione è effettivamente arrivata alla destinazione finale nel datacenter.

Figura 15: Avviso sul certificato durante una connessione RDP tramite Azure Bastion Native Client

Finalmente siete connessi. Vedete il desktop della macchina Windows nel datacenter, raggiunta utilizzando il suo indirizzo IP privato, ma attraverso Azure Bastion.

Anche qui c’è un dettaglio che può confondere: nella barra della sessione compare ancora localhost. È normale. Il client RDP è collegato a un endpoint locale, mentre Azure Bastion gestisce il tunnel e l’instradamento verso la macchina reale.

Dal vostro punto di vista state usando una normale sessione Remote Desktop. Dal punto di vista dell’architettura, invece, la connessione segue questo percorso: client locale → tunnel Bastion → VPN Site-to-Site → VM on-premises.

Il risultato è esattamente quello che volevate dimostrare: accesso completo alla macchina, senza IP pubblici, senza jump server e con tutto il traffico che resta su canali sicuri.

Figura 16: Connessione RDP completata tramite Azure Bastion Native Client verso una VM on-premises

Conclusioni

Con la IP-based connection Azure Bastion diventa molto più di un semplice accesso alle VM Azure. Avete visto come sia possibile utilizzarlo per collegarvi anche a macchine on-premises, sfruttando una normale VPN Site-to-Site, senza esporre alcun servizio su Internet.

Il vantaggio principale è la centralizzazione degli accessi: un unico punto di ingresso, sicuro, controllato e integrato con Azure. Non servono più jump server, IP pubblici o configurazioni complesse lato rete.

Grazie al Native client support, potete continuare a utilizzare i vostri strumenti abituali come Remote Desktop, senza rinunciare ai benefici di sicurezza offerti da Bastion.

Con poche configurazioni avete reso l’accesso remoto più semplice, più sicuro e molto più flessibile, estendendo Azure Bastion anche al vostro datacenter.