Guida al collegamento privato e al DNS nella rete WAN virtuale di Azure

Collegamento privato di Azure

DNS di Azure

Firewall di Azure

Rete WAN virtuale di Azure

collegamento privato di Azure consente ai client di accedere ai servizi PaaS (Platform as a Service) di Azure direttamente da reti virtuali private senza usare indirizzi IP pubblici. Per ogni servizio, si configura un endpoint privato che usa un indirizzo IP privato dalla rete. I client possono quindi usare l'endpoint privato per connettersi privatamente al servizio.

I client continuano a usare il nome di dominio completo (FQDN) di un servizio per connettersi. Il DNS nella rete viene configurato per risolvere il nome di dominio completo del servizio nell'indirizzo IP privato dell'endpoint privato.

La progettazione della rete e, in particolare, la configurazione DNS sono fattori chiave per supportare la connettività degli endpoint privati ai servizi. Questo articolo è una serie di articoli che forniscono indicazioni sull'implementazione di vari scenari di collegamento privato. Anche se nessuno degli scenari corrisponde esattamente alla tua situazione, dovresti essere in grado di adattare i progetti in base alle tue esigenze.

Avvio della topologia di rete

La topologia di rete iniziale è un'architettura di rete che funge da punto di partenza per tutti gli scenari di questa serie di articoli. L'architettura è una tipica rete hub-spoke che usa Azure rete WAN virtuale.

Figura 1: Avvio della topologia di rete per tutti gli scenari di endpoint privato e DNS

Scaricare un file Visio di questa architettura. Questa topologia presenta le caratteristiche seguenti:

Si tratta di una rete hub-spoke implementata con Azure rete WAN virtuale.
Esistono due aree, ognuna con un hub virtuale protetto Firewall di Azure a livello di area.
Ogni hub virtuale a livello di area protetta ha le impostazioni di sicurezza seguenti per le connessioni di Azure Rete virtuale:
- Traffico Internet: protetto da Firewall di Azure : tutto il traffico verso Internet passa attraverso il firewall dell'hub regionale.
- Traffico privato: protetto da Firewall di Azure: tutto il traffico che transita dallo spoke allo spoke passa attraverso il firewall dell'hub regionale.
Ogni hub virtuale a livello di area è protetto con Firewall di Azure. I firewall dell'hub a livello di area hanno le impostazioni seguenti:
- Server DNS: impostazione predefinita (fornita da Azure): il firewall dell'hub a livello di area usa in modo esplicito DNS di Azure per la risoluzione FQDN nelle raccolte regole.
- Proxy DNS: abilitato: il firewall dell'hub a livello di area risponde alle query DNS sulla porta 53. Inoltra le query a DNS di Azure per i valori non memorizzati nella cache.
- Il firewall registra le valutazioni delle regole e le richieste proxy DNS a un'area di lavoro Log Analytics che si trova nella stessa area. La registrazione di questi eventi è un requisito comune per la registrazione della sicurezza di rete.
Ogni spoke di rete virtuale connessa ha il server DNS predefinito configurato come indirizzo IP privato del firewall dell'hub regionale. In caso contrario , la valutazione della regola FQDN non può essere sincronizzata.

Routing in più aree

Gli hub rete WAN virtuale protetti hanno un supporto limitato per la connettività tra hub quando sono presenti più hub virtuali protetti. Questa limitazione influisce sugli scenari multi-hub, all'interno dell'area e tra aree. Di conseguenza, la topologia di rete non facilita direttamente il filtro del traffico privato tra aree attraverso Firewall di Azure. Il supporto per questa funzionalità viene fornito usando rete WAN virtuale i criteri di routing e la finalità di routing dell'hub. Questa funzionalità è attualmente in anteprima.

Per questa serie di articoli, si presuppone che il traffico protetto interno non attraversi più hub. Il traffico che deve attraversare più hub deve eseguire questa operazione in una topologia parallela che non filtra il traffico privato tramite un hub virtuale protetto, ma consente invece di passare attraverso.

Aggiunta di reti spoke

Quando si aggiungono reti spoke, seguono i vincoli definiti nella topologia di rete iniziale. In particolare, ogni rete spoke è associata alla tabella di route predefinita che si trova nell'hub regionale e il firewall è configurato per proteggere sia internet che traffico privato. Lo screenshot seguente mostra un esempio di configurazione:

Figura 2: Configurazione di sicurezza per le connessioni di rete virtuale nell'hub virtuale

Sfide principali

La topologia di rete iniziale crea problemi per la configurazione del DNS per gli endpoint privati.

Anche se l'uso di rete WAN virtuale offre un'esperienza di hub gestito, il compromesso è che esiste una capacità limitata di influenzare la configurazione dell'hub virtuale o la possibilità di aggiungere altri componenti. Una topologia hub-spoke tradizionale consente di isolare i carichi di lavoro negli spoke condividendo servizi di rete comuni, ad esempio record DNS, nell'hub autogestito. In genere si collega la zona DNS privata alla rete hub in modo che DNS di Azure possa risolvere gli indirizzi IP dell'endpoint privato per i client.

Tuttavia, non è possibile collegare zone DNS private agli hub rete WAN virtuale, quindi qualsiasi risoluzione DNS che si verifica all'interno dell'hub non riconosce le zone private. In particolare, si tratta di un problema per Firewall di Azure, il provider DNS configurato per gli spoke del carico di lavoro, che usa DNS per la risoluzione FQDN.

Quando si usano hub rete WAN virtuale, sembra intuitivo collegare le zone DNS private alle reti virtuali spoke in cui i carichi di lavoro prevedono la risoluzione DNS. Tuttavia, come indicato nell'architettura, il proxy DNS è abilitato nei firewall regionali ed è previsto che tutti gli spoke usino il firewall a livello di area come origine DNS. DNS di Azure viene chiamato dal firewall anziché dalla rete del carico di lavoro, quindi tutti i collegamenti di zona DNS privati nella rete del carico di lavoro non vengono usati nella risoluzione.

Nota

Per configurare il firewall a livello di area come provider DNS dello spoke, impostare il server DNS personalizzato nella rete virtuale spoke in modo che punti all'INDIRIZZO IP privato del firewall anziché al normale valore DNS di Azure.

Data la complessità risultante dall'abilitazione del proxy DNS nei firewall a livello di area, esaminiamo i motivi per abilitarlo.

Firewall di Azure regole di rete supportano limiti basati su FQDN per controllare in modo più preciso il traffico in uscita che le regole dell'applicazione non gestiscono. Questa funzionalità richiede che il proxy DNS sia abilitato. Un uso comune consiste nel limitare il traffico NTP (Network Time Protocol) agli endpoint noti, ad esempio time.windows.com.
I team di sicurezza possono trarre vantaggio dalla registrazione delle richieste DNS. Firewall di Azure include il supporto predefinito per la registrazione delle richieste DNS, quindi richiede che tutte le risorse spoke usino Firewall di Azure come provider DNS garantisce un'ampia copertura di registrazione.

Per illustrare le problematiche, le sezioni seguenti descrivono due configurazioni. C'è un semplice esempio che funziona e uno più complesso che non lo è, ma il suo errore è istruttivo.

Scenario di lavoro

L'esempio seguente è una configurazione di endpoint privato di base. Una rete virtuale contiene un client che richiede l'uso di un servizio PAAS tramite un endpoint privato. Una zona DNS privata collegata alla rete virtuale ha un record A che risolve l'FQDN del servizio nell'indirizzo IP privato dell'endpoint privato. Il diagramma seguente mostra il flusso.

Figura 3: Configurazione DNS di base per gli endpoint privati

Scaricare un file di Visio di questa architettura.

Il client invia una richiesta di stgworkload00.blob.core.windows.net.
DNS di Azure, il server DNS configurato per la rete virtuale, viene sottoposto a query per l'indirizzo IP per stgworkload00.blob.core.windows.net.

L'esecuzione del comando seguente dalla macchina virtuale (VM) illustra che la macchina virtuale è configurata per l'uso di DNS di Azure (168.63.129.16) come provider DNS.
```
resolvectl status eth0

Link 2 (eth0)
      Current Scopes: DNS
  Current DNS Server: 168.63.129.16
         DNS Servers: 168.63.129.16    
```
La zona privatelink.blob.core.windows.net DNS privata è collegata alla rete virtuale del carico di lavoro, quindi DNS di Azure incorpora i record dalla rete virtuale del carico di lavoro nella risposta.
Poiché esiste un record A nella zona DNS privata che esegue il mapping dell'FQDN, stgworkload00.privatelink.blob.core.windows.net, all'indirizzo IP privato dell'endpoint privato, viene restituito l'indirizzo IP privato 10.1.2.4.

L'esecuzione del comando seguente dalla macchina virtuale risolve il nome di dominio completo dell'account di archiviazione nell'indirizzo IP privato dell'endpoint privato.
```
resolvectl query stgworkload00.blob.core.windows.net

stgworkload00.blob.core.windows.net: 10.1.2.4   -- link: eth0
                                    (stgworkload00.privatelink.blob.core.windows.net)
```
La richiesta viene inviata all'indirizzo IP privato dell'endpoint privato che, in questo caso, è 10.1.2.4.
La richiesta viene instradata tramite collegamento privato all'account di archiviazione.

La progettazione funziona perché DNS di Azure:

Server DNS configurato per la rete virtuale.
È a conoscenza della zona DNS privata collegata.
Risolve le query DNS usando i valori della zona.

Scenario non lavorativo

L'esempio seguente è un tentativo ingenuo di usare endpoint privati nella topologia di rete iniziale. Non è possibile collegare una zona DNS privata a un hub rete WAN virtuale. Pertanto, quando i client sono configurati per l'uso del firewall come server DNS, le richieste DNS vengono inoltrate a DNS di Azure dall'interno dell'hub virtuale, che non ha una zona DNS privata collegata. DNS di Azure non sa come risolvere la query diversa da specificare l'impostazione predefinita, ovvero l'indirizzo IP pubblico.

Figura 4: Tentativo ingenuo di usare endpoint privati nella topologia di rete iniziale

Scaricare un file di Visio di questa architettura.

Il client invia una richiesta di stgworkload00.blob.core.windows.net.

L'esecuzione del comando seguente dalla macchina virtuale illustra che la macchina virtuale è configurata per l'uso del firewall dell'hub virtuale come provider DNS.
```
resolvectl status eth0

Link 2 (eth0)
      Current Scopes: DNS
  Current DNS Server: 10.100.0.132
         DNS Servers: 10.100.0.132    
```
Il firewall ha il proxy DNS abilitato con l'impostazione predefinita per inoltrare le richieste a DNS di Azure. La richiesta viene inoltrata a DNS di Azure.
DNS di Azure non è in grado di risolvere stgworkload00.blob.core.windows.net l'indirizzo IP privato dell'endpoint privato perché:
1. Non è possibile collegare una zona DNS privata a un hub rete WAN virtuale.
2. DNS di Azure non è a conoscenza di una zona DNS privata collegata alla rete virtuale del carico di lavoro, perché il server DNS configurato per la rete virtuale del carico di lavoro è Firewall di Azure. DNS di Azure risponde con l'indirizzo IP pubblico dell'account di archiviazione.
L'esecuzione del comando seguente dalla macchina virtuale risolve il nome di dominio completo dell'account di archiviazione nell'indirizzo IP pubblico dell'account di archiviazione.
```
resolvectl query stgworkload00.blob.core.windows.net

stgworkload00.blob.core.windows.net: 52.239.174.228 -- link: eth0
                                    (blob.bn9prdstr08a.store.core.windows.net)
```
Poiché Firewall di Azure esegue il proxy delle query DNS, è possibile registrarle. Di seguito sono riportati Firewall di Azure log proxy DNS.
```
DNS Request: 10.1.0.4:60137 - 46023 A IN stgworkload00.blob.core.windows.net. udp 63 false 512 NOERROR qr,rd,ra 313 0.009424664s
DNS Request: 10.1.0.4:53145 - 34586 AAAA IN blob.bn9prdstr08a.store.core.windows.net. udp 69 false 512 NOERROR qr,aa,rd,ra 169 0.000113s    
```
Il client non riceve l'indirizzo IP privato per l'endpoint collegamento privato e non riesce a stabilire una connessione privata all'account di archiviazione.

È previsto il comportamento precedente. È il problema affrontato dagli scenari.

Scenari

Anche se le soluzioni a questo problema sono simili, l'esecuzione di scenari di carico di lavoro comuni illustra come le soluzioni rispondono ai requisiti di varie situazioni. La maggior parte degli scenari è costituita da un client che accede a uno o più servizi PaaS tramite un endpoint privato. Rispettano la topologia di rete iniziale, ma differiscono in base ai requisiti del carico di lavoro. Gli scenari iniziano semplicemente con un client che accede a un singolo servizio PaaS a livello di area. Si ottengono in modo incrementale più complesso, aggiungendo maggiore visibilità di rete, aree e servizi PaaS.

Nella maggior parte degli scenari, il client viene implementato come macchina virtuale e il servizio PaaS a cui accede il client è un account di archiviazione. È consigliabile considerare le macchine virtuali come uno stand-in per qualsiasi risorsa di Azure con una scheda di interfaccia di rete esposta in una rete virtuale, ad esempio set di scalabilità di macchine virtuali, nodi servizio Azure Kubernetes o qualsiasi altro servizio che instrada in modo simile.

Importante

L'implementazione collegamento privato per l'account Archiviazione di Azure potrebbe differire da altri servizi PaaS in modi sottili, ma funziona bene per molti. Ad esempio, alcuni servizi rimuovono i record FQDN durante l'esposizione tramite collegamento privato, che potrebbero comportare comportamenti diversi, ma tali differenze in genere non sono un fattore nelle soluzioni per questi scenari.

Ogni scenario inizia con lo stato finale desiderato e descrive in dettaglio la configurazione necessaria per passare dalla topologia di rete iniziale allo stato finale desiderato. La soluzione a ogni scenario sfrutta il modello di estensioni dell'hub virtuale. Questo modello illustra come esporre i servizi condivisi in modo isolato e sicuro, come estensione concettuale a un hub regionale. La tabella seguente contiene collegamenti al modello di estensione dell'hub virtuale e agli scenari.

Guida	Descrizione
Area singola, paaS dedicata	Un carico di lavoro in una singola area accede a una risorsa PaaS dedicata.

Passaggi successivi

Leggere lo scenario di risorse PaaS dedicato in una singola area

Condividi tramite

Guida al collegamento privato e al DNS nella rete WAN virtuale di Azure