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 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 usano il nome di dominio completo (FQDN) di un servizio per connettersi al servizio. Configuri il DNS nella tua rete per risolvere il FQDN (nome di dominio completo) del servizio all'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 su come comprendere collegamento privato comportamento negli ambienti rete WAN virtuale. Vengono presentati diversi scenari, inclusi esempi intenzionalmente vincolati usati per illustrare i problemi comuni di DNS e routing. 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 è l'architettura di base per tutti gli scenari di questa serie. Si tratta di una tipica rete hub-spoke che usa rete WAN virtuale di Azure.

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

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

Si tratta di una rete hub-spoke implementata con la rete WAN virtuale di Azure.
Esistono due aree, ognuna con un hub virtuale protetto che include Firewall di Azure.
Per ogni hub virtuale a livello di area protetta sono disponibili le impostazioni di sicurezza seguenti per le connessioni di rete virtuale di Azure:
- TrafficoInternet: Secured by Firewall di Azure - Tutto il traffico verso Internet passa attraverso il firewall dell'hub a livello di area.
- Private traffic: Secured by Firewall di Azure - Tutto il traffico interspoke passa attraverso il firewall regionale dell'hub.
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. Questa registrazione è un requisito di sicurezza di rete standard.
Ogni spoke usa l'indirizzo IP privato del firewall regionale come server DNS. In caso contrario , la valutazione della regola FQDN non può essere sincronizzata.

Instradamento multi-regione

Intento di routing e criteri di routing dell'hub rete WAN virtuale consentono di controllare come il traffico fluisce tra gli hub e se il traffico è ispezionato da Firewall di Azure o un'altra soluzione di sicurezza.

Per impostazione predefinita, in una distribuzione di rete WAN virtuale multi-hub, il traffico privato inter-hub non passa attraverso Firewall di Azure. Azure usa invece la connettività da hub a hub gestita rete WAN virtuale predefinita, che viene eseguita in parallelo ai percorsi di traffico protetti all'interno di ogni hub. Ciò significa che il traffico privato che si sposta tra hub non viene controllato automaticamente.

Se è necessario Firewall di Azure per controllare il traffico privato tra hub, è possibile abilitare questo comportamento configurando un criterio di routing Private Traffic e attivando inter-hub ispezione. In questo modo il traffico privato tra hub deve essere inoltrato attraverso Firewall di Azure per l'ispezione.

Questa configurazione è più avanzata e non rientra nell'ambito di questa serie.

Aggiunta di reti spoke

Quando si aggiungono reti spoke, applicare i vincoli definiti nella topologia di rete iniziale. Ogni spoke è associato alla tabella di route predefinita dell'hub regionale e Firewall di Azure protegge sia il traffico Internet che quello 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 rete WAN virtuale offre un'esperienza di hub gestito, il compromesso è la capacità limitata di influenzare la configurazione dell'hub virtuale o aggiungere componenti ad esso. 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. Generalmente si collega la zona DNS privata alla rete hub affinché il DNS di Azure possa risolvere gli indirizzi IP degli endpoint privati per i client.

Tuttavia, non è possibile collegare zone DNS private a hub rete WAN virtuale, quindi qualsiasi risoluzione DNS all'interno dell'hub non è a conoscenza delle zone private. In particolare, questo crea un problema per Firewall di Azure, che funge da provider DNS per gli spoke nei carichi di lavoro e usa il DNS per la risoluzione dei FQDN.

Quando si usano hub rete WAN virtuale, potrebbe sembrare 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 e tutti gli spoke devono usare il firewall a livello di area come origine DNS. La query DNS di Azure ha origine dal firewall nell'hub, non dalla rete virtuale del carico di lavoro, quindi i collegamenti alle zone DNS private nella rete spoke non sono utilizzati nella risoluzione.

Poiché gli hub di rete WAN virtuale non possono collegarsi a zone DNS privato, l'approccio consigliato per la risoluzione DNS negli scenari di collegamento privato è DNS di Azure resolver privato distribuito in una rete virtuale dell'estensione hub. Ciò consente una risoluzione DNS privata scalabile e compatibile con la zona per i carichi di lavoro connessi agli hub rete WAN virtuale. Gli articoli di completamento di questa serie illustrano come il resolver privato DNS completa l'architettura.

Annotazioni

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à dell'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 con maggiore precisione il traffico in uscita che le regole dell'applicazione non gestiscono. Per questa funzionalità è necessario abilitare il proxy DNS. Un uso comune consiste nel limitare il traffico NTP (Network Time Protocol) agli endpoint noti, ad esempio time.windows.com.
La registrazione delle richieste DNS offre vantaggi ai team di sicurezza. Il Firewall di Azure ha il supporto predefinito per la registrazione delle richieste DNS, pertanto, richiedere che tutte le risorse spoke utilizzino Firewall di Azure come provider DNS garantisce un'ampia copertura della 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 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 a stgworkload00.blob.core.windows.net.
DNS di Azure, il server DNS configurato per la rete virtuale, viene interrogato per ottenere l'indirizzo IP di 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.

Eseguendo il seguente comando dalla macchina virtuale si risolve il FQDN 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, ovvero 10.1.2.4.
La richiesta viene instradata tramite collegamento privato all'account di archiviazione.

Questa 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 della 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 a 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 nell'indirizzo IP privato dell'endpoint privato perché:
1. Non è possibile collegare una zona DNS privata a un hub della 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 VM risolve il FQDN 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, siamo in grado di registrarle. Di seguito sono riportati i log DNS Proxy di Firewall di Azure.
```
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.

Questo comportamento è previsto. È il problema affrontato dagli scenari.

Scenari

Le soluzioni a questo problema sono simili, ma l'esame degli scenari comuni dei carichi di lavoro mostra come ogni soluzione soddisfi requisiti diversi. 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 con un client che accede a un singolo servizio PaaS a livello di area. Diventano incrementalmente più complessi e aggiungono 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. Dovreste considerare le macchine virtuali come un sostituto per qualsiasi risorsa di Azure con una scheda di interfaccia di rete esposta in una rete virtuale, come i gruppi di scalabilità di macchine virtuali, i nodi dei servizi 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 si allinea bene a molti altri servizi. 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 usa il modello di estensione dell'hub virtuale , che espone i servizi condivisi come estensione sicura di un hub a livello di area, insieme a DNS di Azure resolver privato per la risoluzione DNS per gli endpoint privati negli ambienti rete WAN virtuale. 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

Commenti e suggerimenti

Questa pagina è stata utile?