Scenario a singola area - Collegamento privato e DNS nella rete WAN virtuale di Azure

Questo articolo illustra come esporre una risorsa PaaS a un carico di lavoro su un endpoint privato in una singola area con una topologia hub-spoke rete WAN virtuale di Azure.

Sceneggiatura

Figura 1: Scenario a singola area per la rete WAN virtuale con collegamento privato e DNS di Azure- La sfida

Scarica un file Visio di questa architettura. Questa sezione descrive lo scenario e riformula la sfida dell'esempio non funzionante nella panoramica. L'architettura si basa sulla topologia di rete iniziale con le aggiunte seguenti:

• Esiste solo un'area con un hub virtuale.
• Nell'area è presente un account di archiviazione di Azure con accesso alla rete pubblica disabilitato. Il presupposto in questo scenario è che un solo carico di lavoro accede all'account di archiviazione.
• Inizialmente è presente una singola rete virtuale connessa all'hub virtuale.
• La rete virtuale dispone di una subnet del carico di lavoro che contiene un client di macchine virtuali.The virtual network has a workload subnet that contains a virtual machine (VM) client.
• La rete virtuale contiene una subnet privata dell'endpoint che contiene un endpoint privato per l'account di storage.

Esito positivo

Il client della macchina virtuale può connettersi all'account di archiviazione tramite l'endpoint privato nella stessa rete virtuale e tutti gli altri accessi all'account di archiviazione sono bloccati.

Impedimento

È necessario un record DNS nel flusso DNS che risolve il nome di dominio completo (FQDN) dell'account di archiviazione nell'indirizzo IP privato dell'endpoint privato. Come indicato nella panoramica, la sfida in questo scenario è duplice:

1. Non è possibile collegare una zona DNS privata che gestisce i record DNS necessari dell'account di archiviazione a un hub virtuale.
2. È possibile collegare una zona DNS privata alla rete del carico di lavoro, quindi potrebbe sembrare valida, ma l'architettura baseline prevede che ogni rete virtuale connessa abbia server DNS configurati per l'uso del proxy DNS Firewall di Azure.

Poiché non è possibile collegare una zona DNS privata a un hub virtuale e la rete virtuale è configurata per l'uso del proxy DNS Firewall di Azure, DNS di Azure non è possibile risolvere il nome di dominio completo dell'account di archiviazione nell'indirizzo IP privato. Il risultato è che il client riceve invece l'indirizzo IP pubblico.

Flussi DNS e HTTP

Esaminiamo il DNS e i flussi di richiesta HTTP risultanti per visualizzare l'ostacolo.

Figura 2: Scenario a singola area per la rete WAN virtuale con collegamento privato e DNS di Azure- La sfida

Scaricare un file di Visio di questa architettura.

Flusso DNS

1. La query DNS per stgworkload00.blob.core.windows.net dal client viene inviata al server DNS configurato, ovvero Firewall di Azure nell'hub di area con peering.
2. Firewall di Azure effettua il proxy della richiesta a DNS di Azure. Poiché non è possibile collegare una zona DNS privata a un hub virtuale, DNS di Azure non è in grado di risolvere il nome di dominio completo nell'indirizzo IP dell'endpoint privato. DNS di Azure risolve il FQDN nell'indirizzo IP pubblico dell'account di archiviazione e restituisce tale valore.

Flusso HTTP

1. Con il risultato DNS (l'indirizzo IP pubblico dell'account di archiviazione), il client invia una richiesta HTTP a stgworkload00.blob.core.windows.net.

2. La richiesta viene inviata all'indirizzo IP pubblico dell'account di archiviazione. Questa richiesta ha esito negativo per molti motivi:

   • Il NSG sulla subnet del carico di lavoro potrebbe non consentire questo traffico destinato a Internet.
   • Il Firewall di Azure che filtra il traffico in uscita associato a Internet probabilmente non ha una regola dell'applicazione appropriata per gestire questo flusso.
   • Anche se sia il gruppo di sicurezza di rete che Firewall di Azure avevano permessi per questo flusso di richiesta, l'account di archiviazione è configurato per bloccare tutti gli accessi alla rete pubblica.

   Questo tentativo viola l'obiettivo di consentire l'accesso solo tramite l'endpoint privato.

Soluzione: stabilire un'estensione dell'hub virtuale per DNS

La soluzione consigliata per DNS negli ambienti rete WAN virtuale consiste nell'implementare un'estensione hub virtuale virtuale per DNS. Questo modello è dettagliato nell'articolo relativo all'architettura associata e fornisce le basi per lo scenario funzionante a singola area illustrato di seguito. L'estensione dell'hub virtuale DNS consente ai team di lavoro di usare zone DNS private all'interno della topologia iniziale dell'hub rete WAN virtuale.

L'estensione DNS viene implementata come spoke di rete virtuale con peering all'hub virtuale a livello di area. DNS privato zone possono collegarsi a questa rete virtuale. La rete virtuale contiene anche un resolver privato DNS di Azure che consente ai servizi all'esterno di questa rete virtuale, ad esempio Firewall di Azure, di eseguire query e ricevere valori da tutte le zone DNS private collegate. Di seguito sono riportati i componenti di una tipica estensione dell'hub virtuale per DNS, insieme ad alcune modifiche di configurazione necessarie:

• Nuova rete virtuale spoke che ha stabilito un peering con l'hub virtuale della regione. Questo spoke è configurato come qualsiasi altro spoke, vale a dire le regole di routing e server DNS predefiniti forzano l'uso di Firewall di Azure nell'hub a livello di area.
• Una risorsa resolver privato DNS viene distribuita con un endpoint in ingresso nella rete virtuale spoke.
• Viene creata una risorsa di zona DNS privata denominata privatelink.blob.core.windows.net .
  • Questa zona contiene un A record che mappa il nome di dominio completo dell'account di archiviazione all'indirizzo IP privato dell'endpoint per l'account di archiviazione.
  • La zona DNS privata è collegata alla rete virtuale spoke.
  • Se il controllo degli accessi in base al ruolo di Azure consente, è possibile usare la registrazione automatica o le voci gestite dal servizio per gestire questi record DNS. In caso contrario, è necessario gestirli manualmente.
• Nell'hub a livello di area il server DNS di Firewall di Azure viene modificato in modo che punti all'endpoint in ingresso del resolver privato DNS.

Il diagramma seguente illustra l'architettura, insieme ai flussi DNS e HTTP.

Figura 3: Soluzione di lavoro per uno scenario a singola area per la rete WAN virtuale con collegamento privato e DNS

Scaricare un file di Visio di questa architettura.

Flusso DNS per l'estensione dell'hub virtuale

1. La query DNS per stgworkload00.blob.core.windows.net il client viene inviata al server DNS configurato, ovvero Firewall di Azure nell'hub regionale con peering: 10.100.0.132 in questo caso.

   Figura 4: Configurazione dei server DNS per la rete virtuale del carico di lavoro

2. Firewall di Azure funge da proxy per la richiesta al resolver privato DNS di Azure nella regione nell'estensione dell'hub - 10.200.1.4 in questo caso, ovvero l'indirizzo IP privato dell'endpoint in ingresso del resolver privato DNS.

   

   Screenshot dei criteri di Firewall di Azure in cui è abilitato il proxy DNS e i server DNS sono impostati su Personalizzato. I punti di ingresso all'indirizzo IP privato dell'endpoint di input del DNS Resolver privato.

   Figura 5: Configurazione DNS nei criteri di Firewall di Azure

3. DNS Private Resolver invia la richiesta ad DNS di Azure. Poiché una zona DNS privata è collegata alla rete virtuale contenente l'endpoint in ingresso, DNS di Azure può usare i record in tali zone DNS private collegate.

   Figura 6: Collegamenti di rete virtuale della zona DNS privata

4. DNS di Azure consulta la zona DNS privata collegata e risolve il FQDN di stgworkload00.blob.core.windows.net a 10.1.2.4, ovvero l'indirizzo IP dell'endpoint privato per l'account di archiviazione. Questa risposta viene fornita al DNS di Firewall di Azure, che quindi restituisce l'indirizzo IP privato dell'account di archiviazione al client.

   Figura 7: Zona DNS privata con il record A per l'endpoint privato dell'account di archiviazione

Flusso HTTP

1. Con il risultato DNS (l'indirizzo IP privato dell'account di archiviazione), il client invia una richiesta HTTP a stgworkload00.blob.core.windows.net.
2. La richiesta viene inviata all'indirizzo IP privato (10.1.2.4) dell'account di archiviazione. Questa richiesta viene instradata correttamente, presupponendo che non vi siano restrizioni in conflitto nei gruppi di sicurezza di rete locali nella subnet client o nella subnet dell'endpoint privato. È importante comprendere che, anche se Firewall di Azure protegge il traffico privato, la richiesta non viene instradata tramite Firewall di Azure perché l'endpoint privato si trova nella stessa rete virtuale del client. Questo comportamento predefinito può cambiare se vengono introdotte route definite dall'utente o appliance virtuali di rete , ma questo scenario presuppone il modello di routing della rete virtuale standard. Non sono necessarie Firewall di Azure indennità per questo scenario.
3. Viene stabilita una connessione privata all'account di archiviazione tramite il servizio Collegamento privato. L'account di archiviazione consente solo l'accesso alla rete privata e accetta la richiesta HTTP.

Considerazioni sull'estensione dell'hub virtuale per DNS

Quando si implementa l'estensione per l'azienda, prendere in considerazione le indicazioni seguenti.

• La distribuzione dell'estensione DNS non è un'attività per il team di gestione dei carichi di lavoro. Questa attività è una funzione di rete aziendale e deve essere una decisione di implementazione presa con tali utenti.
• L'estensione DNS e le zone DNS private devono esistere prima di aggiungere qualsiasi servizio PaaS per cui si prevede di configurare i record DNS dell'endpoint privato.
• L'estensione dell'hub virtuale è una risorsa regionale, evita il traffico tra regioni e stabilisci un'estensione dell'hub per ogni hub regionale dove è prevista la risoluzione DNS dell'endpoint privato.

Rete virtuale spoke

• Seguendo il principio di responsabilità singola, la rete virtuale per l'estensione DNS deve contenere solo le risorse necessarie per la risoluzione DNS e non devono essere condivise con altre risorse.
• La rete virtuale per l'estensione DNS deve seguire le stesse linee guida di configurazione sotto Aggiunta di reti spoke.

Sistema di risoluzione privato DNS di Azure

DNS di Azure Private Resolver è un servizio con ridondanza di zona, offrendo un'alta disponibilità senza richiedere l'hosting del server DNS gestito dal cliente. In questo scenario a singola area è necessario solo un endpoint in ingresso; Tuttavia, altre architetture, ad esempio la risoluzione dei nomi ibridi, l'inoltro condizionale o la risoluzione tra ambienti, richiedono endpoint in uscita.

• Ogni area deve avere un'estensione DNS dell'hub virtuale con un resolver privato DNS.

• Il resolver privato DNS richiede solo un endpoint in ingresso e nessun endpoint in uscita per questo scenario. Impostare l'indirizzo IP privato dell'endpoint in ingresso come servizio DNS personalizzato nei criteri di Firewall di Azure (vedere la figura 5).

• Per una maggiore resilienza e una maggiore gestione del carico, distribuire due endpoint in ingresso del resolver privato DNS per area. Ogni endpoint in ingresso ha un singolo indirizzo IP privato. Configurare entrambi gli indirizzi IP privati nelle impostazioni DNS di Firewall di Azure per la risoluzione ridondante.

  Figura 8: Endpoint in ingresso per il DNS resolver privato

• Seguire le restrizioni della rete virtuale per il resolver privato DNS.

• Usare una subnet dedicata dell'endpoint in ingresso di dimensioni /28 o superiori per ciascun requisito del resolver; non condividerla con altre risorse.

• Il gruppo di sicurezza di rete nella subnet per l'endpoint in ingresso del resolver privato DNS deve consentire solo il traffico UDP dall'hub regionale alla porta 53. Blocca tutto l'altro traffico in ingresso e in uscita.

Zona DNS privato

Poiché DNS di Azure Private Resolver inoltra verso DNS di Azure, può usare qualsiasi zone DNS private collegate alla rete virtuale della subnet di ingresso.

• Collegare la zona DNS privata alla rete estesa dell'hub virtuale.
• Seguire le indicazioni sulla gestione delle zone DNS private per gli endpoint privati.
• Se ci si aspetta che i proprietari delle risorse PaaS gestiscano le proprie voci, configurare di conseguenza il controllo degli accessi in base al ruolo di Azure oppure implementare una soluzione come quella di Collegamento privato e integrazione DNS su ampia scala.

Considerazioni sugli scenari

Con un'estensione DNS dell'hub virtuale ben gestita, torniamo al carico di lavoro e affrontiamo alcuni punti aggiuntivi per raggiungere gli obiettivi di esito positivo all'interno di questo scenario.

Account di archiviazione

• Impostare Accesso alla rete pubblica: disabilitato in Connettività di rete per assicurarsi che l'account di archiviazione sia accessibile solo tramite endpoint privati.
• Aggiungere un endpoint privato a una subnet di endpoint privati dedicata nella rete virtuale della risorsa.
• Inviare Diagnostica di Azure all'area di lavoro Log Analytics Workspace. È possibile usare i log di accesso per risolvere i problemi di configurazione.

Sicurezza degli endpoint privati

Un requisito di questa soluzione consiste nel limitare l'esposizione di questo account di archiviazione. Dopo aver rimosso l'accesso a Internet pubblico alla risorsa PaaS, è necessario gestire la sicurezza della rete privata.

Quando Firewall di Azure protegge il traffico privato in una topologia hub-spoke di rete WAN virtuale, per impostazione predefinita Firewall di Azure nega la connettività spoke-to-spoke. Questa impostazione predefinita impedisce ai carichi di lavoro in altre reti spoke di accedere agli endpoint privati (e ad altre risorse) nella rete virtuale del carico di lavoro. Il traffico completamente all'interno di una rete virtuale non viene instradato attraverso Firewall di Azure. Per gestire l'accesso all'interno della rete virtuale e aggiungere una protezione più granulare, prendere in considerazione i seguenti consigli sul gruppo di sicurezza di rete.

• Creare un gruppo di sicurezza delle applicazioni per raggruppare le risorse con esigenze di accesso in ingresso o in uscita simili. In questo scenario, usare un gruppo di sicurezza delle applicazioni (ASG) per le macchine virtuali client che devono accedere all'archiviazione e un altro per gli account di archiviazione a cui si accede. Vedere Configurare un gruppo di sicurezza delle applicazioni con un endpoint privato.
• Assicurarsi che la subnet contenente la VM del carico di lavoro abbia un NSG.
• Assicurarsi che la subnet contenente gli endpoint privati disponga di un gruppo di sicurezza di rete.

Regole del gruppo di sicurezza di rete per la subnet contenente la macchina virtuale di carico di lavoro

Oltre a qualsiasi altra regola di rete richiesta dal carico di lavoro, configurare le regole seguenti.

• Regole in uscita:
  • Consentire al gruppo di scalabilità automatica di calcolo di accedere al gruppo di scalabilità automatica dell'account di archiviazione.
  • Consentire l'ASG di calcolo all'indirizzo IP privato di Firewall di Azure dell'hub regionale per UDP sulla porta 53.

Figura 9: Regole del NSG (gruppo di sicurezza di rete) per la subnet del carico di lavoro

Regole del gruppo di sicurezza di rete per la subnet contenente endpoint privati

È considerata una buona pratica esporre endpoint privati su una subnet piccola e dedicata all'interno della rete virtuale consumante. È possibile applicare route definite dall'utente e criteri di sicurezza del gruppo di sicurezza di rete per gli endpoint privati per un controllo e una sicurezza del traffico migliorati.

Questo scenario consente di applicare un gruppo di sicurezza di rete estremamente restrittivo.

• Regole in ingresso:
  • Consentire al gruppo di scalabilità automatica di calcolo di accedere al gruppo di scalabilità automatica dell’account di archiviazione
  • Nega tutto il traffico restante
• Regole in uscita:
  • Blocca tutto il traffico

*Figura 10: Regole del NSG per la subnet dell'endpoint privato

Sicurezza degli endpoint privati in azione

L'immagine seguente illustra come seguire le considerazioni descritte può fornire una sicurezza avanzata per la difesa. Il diagramma mostra una seconda rete virtuale spoke con una seconda macchina virtuale. Tale carico di lavoro non è in grado di accedere all'endpoint privato.

Figura 11: Soluzione funzionante per uno scenario a singola area per la rete WAN virtuale con collegamento privato e DNS

Scaricare un file di Visio di questa architettura.

Flusso DNS

Il flusso DNS è esattamente lo stesso del flusso della soluzione.

Il punto chiave è che il nome di dominio completo si risolve nell'indirizzo IP privato, non nell'indirizzo IP pubblico. Questa configurazione garantisce che tutte le sottoreti ricevono sempre l'indirizzo IP privato di questo servizio. In questo scenario tutti gli spokes risolveranno l'endpoint privato del servizio PaaS al proprio indirizzo IP privato. Sebbene ciò consenta la possibilità di condividere il servizio tra più carichi di lavoro, questo articolo non fornisce un modello di progettazione multi-carico di lavoro. Per il momento, l'attenzione rimane sullo scenario di carico di lavoro singolo illustrato qui.

Flusso HTTP

1. Con il risultato DNS, l'indirizzo IP privato dell'account di archiviazione, il client invia una richiesta HTTP a stgworkload00.blob.core.windows.net.
2. La richiesta viene inviata all'indirizzo IP privato dell'account di archiviazione. Questa richiesta ha esito negativo in modo appropriato per molti motivi:
   • Firewall di Azure è configurato per proteggere il traffico privato, quindi gestisce la richiesta. A meno che Firewall di Azure non disponga di una regola di rete o applicazione per consentire il flusso, Firewall di Azure blocca la richiesta.
   • Non è necessario usare Firewall di Azure nell'hub per proteggere il traffico privato. Ad esempio, se la rete supporta il traffico privato interregionale, il gruppo di sicurezza di rete sulla subnet dell'endpoint privato è configurato per continuare a bloccare tutto il traffico, tranne quello proveniente dalle origini del gruppo di sicurezza di calcolo all'interno della rete virtuale che ospita il carico di lavoro.

Riassunto

Questo articolo presenta uno scenario in cui un client di macchine virtuali si connette all'account di archiviazione di Azure tramite l'endpoint privato dell'account di archiviazione. L'endpoint si trova nella stessa rete virtuale del client. Tutti gli altri accessi all'account di archiviazione sono bloccati. Questo scenario richiede un record DNS nel flusso del DNS che risolva il nome di dominio completo (FQDN) dell'account di archiviazione all'indirizzo IP privato dell'endpoint privato.

La topologia di rete iniziale per questo scenario presenta due sfide:

• Non è possibile collegare una zona DNS privata con i record DNS necessari per l'account di archiviazione all'hub virtuale.
• Il collegamento di una zona DNS privata alla subnet del carico di lavoro non funziona. La topologia di rete iniziale richiede che le regole di routing e del server DNS predefinite forzano l'uso di Firewall di Azure nell'hub a livello di area.

La soluzione proposta è destinata al team di rete aziendale di implementare un'estensione dell'hub virtuale per DNS. Questa estensione abilita i servizi DNS condivisi per i noduli del carico di lavoro che ne hanno bisogno.

" output is necessary.)

• Che cos'è un endpoint privato?
• Configurazione DNS dell'endpoint privato di Azure
• Collegamento privato e integrazione DNS su larga scala
• Collegamento privato di Azure in una rete hub-and-spoke
• DNS per le risorse locali e di Azure
• Usare collegamento privato di Azure per connettere reti ad Monitoraggio di Azure
• Resolver privato DNS di Azure
• Accesso con sicurezza migliorata alle app Web multi-tenant da una rete locale
• Applicazione Web con ridondanza della zona a disponibilità elevata di base
• Esercitazione: Creare un'infrastruttura DNS con endpoint privato utilizzando Azure Private Resolver per un carico di lavoro locale