Scenario a singola area: collegamento privato e DNS in Azure rete WAN virtuale

Questo articolo illustra come esporre una risorsa PaaS su un endpoint privato a un carico di lavoro specifico in una singola area. Nello scenario la topologia di rete è hub-spoke e l'hub è un hub di Azure rete WAN virtuale.

Scenario

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

Scaricare un file Visio di questa architettura. Questa sezione definisce lo scenario e ridefinisce la sfida per questo scenario (la sfida è identica all'esempio non lavorativo nella pagina di panoramica). L'architettura dello scenario iniziale si basa sulla topologia di rete iniziale definita nella guida di panoramica. Di seguito sono riportate le aggiunte e le modifiche:

• Esiste solo un'area con un hub virtuale.
• Esiste un account Archiviazione di Azure nell'area 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 dell'endpoint privato che contiene un endpoint privato per l'account di archiviazione.

Esito positivo

Il client della macchina virtuale di Azure può connettersi all'account Archiviazione di Azure tramite l'endpoint privato dell'account di archiviazione che si trova nella stessa rete virtuale e tutti gli altri accessi all'account di archiviazione vengono bloccati.

Impedimento

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

1. Non è possibile collegare una zona DNS privata che gestisce i record DNS necessari agli account di archiviazione a un hub virtuale.
2. È possibile collegare una zona DNS privata alla rete del carico di lavoro, quindi si potrebbe pensare che funzionerebbe. Sfortunatamente, l'architettura di base prevede che ogni rete virtuale connessa abbia server DNS configurati per puntare all'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, i server DNS di Azure non dispongono di alcun meccanismo per risolvere il nome FQDN dell'account di archiviazione nell'indirizzo IP privato dell'endpoint privato. Il risultato è che il client riceve una risposta DNS errata.

Flussi DNS e HTTP

Esaminiamo il DNS e i flussi di richiesta HTTP risultanti per questo carico di lavoro. La revisione ci aiuta a visualizzare l'ostacolo descritto in precedenza.

Figura 2: Scenario a singola area per 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, che è Firewall di Azure nell'hub a livello di area con peering.
2. Firewall di Azure proxy la richiesta a DNS di Azure. Poiché non è possibile collegare una zona DNS privata a un hub virtuale, DNS di Azure non sa come risolvere il nome di dominio completo nell'indirizzo IP privato dell'endpoint privato. Sa come risolvere il nome di dominio completo nell'indirizzo IP pubblico dell'account di archiviazione, quindi restituisce l'indirizzo IP pubblico dell'account di archiviazione.

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 gruppo di sicurezza di rete nella subnet del carico di lavoro potrebbe non consentire questo traffico associato a Internet.
   • Il Firewall di Azure che filtra il traffico in uscita associato a Internet probabilmente non ha una regola dell'applicazione per supportare questo flusso.
   • Anche se sia il gruppo di sicurezza di rete che Firewall di Azure hanno avuto quote per questo flusso di richiesta, l'account Archiviazione è configurato per bloccare tutti gli accessi alla rete pubblica. Il tentativo viola infine l'obiettivo di consentire l'accesso solo all'account di archiviazione tramite l'endpoint privato.

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

Una soluzione alla sfida è che il team di rete aziendale implementi un'estensione dell'hub virtuale per DNS. L'unica responsabilità dell'estensione dell'hub virtuale DNS è consentire ai team del carico di lavoro che devono usare zone DNS private nella loro architettura all'interno di questa topologia di hub di avvio rete WAN virtuale.

L'estensione DNS viene implementata come spoke di rete virtuale con peering all'hub virtuale a livello di area. È possibile collegare zone DNS private 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 con peering con l'hub virtuale dell'area. 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 mappato dal nome FQDN dell'account di archiviazione all'indirizzo IP privato dell'endpoint privato per l'account di archiviazione.
  • La zona DNS privata è collegata alla rete virtuale spoke.
  • Se il controllo degli accessi in base al ruolo consente, è possibile usare la registrazione automatica o le voci gestite dal servizio per gestire questi record DNS. In caso contrario, è possibile gestirli manualmente.
• Nell'hub a livello di area il server DNS del 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 rete WAN virtuale con collegamento privato e DNS

Scaricare un file di Visio di questa architettura.

Flusso DNS per stabilire un'estensione dell'hub virtuale per DNS

1. La query DNS per stgworkload00.blob.core.windows.net dal client viene inviata al server DNS configurato, che è 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 proxy la richiesta al resolver privato DNS di Azure a livello di area 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. La voce punta all'indirizzo IP privato dell'endpoint di input del resolver privato DNS.

   Figura 5: Configurazione DNS nei criteri di Firewall di Azure

3. Dns Private Resolver proxys the request to Azure DNS .DNS Private Resolver proxys the request to Azure DNS. 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 privato

4. DNS di Azure consulta la zona DNS privata collegata e risolve il nome di dominio completo 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 a Firewall di Azure DNS, che quindi restituisce l'indirizzo IP privato dell'account di archiviazione al client.

   Figura 7: DNS privato zona 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 attraverso Firewall di Azure perché l'endpoint privato si trova nella stessa rete virtuale del client. Ciò significa che non è necessario effettuare 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 del carico 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 vuole configurare i record DNS dell'endpoint privato.
• L'estensione dell'hub virtuale è una risorsa a livello di area, evitare il traffico tra aree e stabilire un'estensione hub per hub regionale in cui è 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 in Aggiunta di reti spoke.

Resolver privato DNS di Azure

• 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. L'indirizzo IP privato per l'endpoint in ingresso è quello impostato per il servizio DNS personalizzato nei criteri di Firewall di Azure (vedere la figura 5).

• Per una maggiore resilienza e una maggiore gestione del carico, è possibile distribuire più istanze del resolver privato DNS per area, con il proxy DNS di Azure configurato con più indirizzi IP per la risoluzione proxy.

  Figura 8: Endpoint in ingresso per il resolver privato DNS

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

• 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. È consigliabile bloccare tutto l'altro traffico in ingresso e in uscita.

Zona DNS privato

Poiché il resolver privato DNS di Azure sta risolvendo IL DNS tramite DNS di Azure, DNS di Azure è in grado di raccogliere tutte le zone DNS private collegate alla rete virtuale della subnet in ingresso.

• Collegare la zona DNS privata all'estensione dell'hub virtuale per la rete virtuale DNS.
• Seguire le indicazioni sulla gestione delle zone DNS private per gli endpoint privati.
• Se si prevede che i proprietari delle risorse PaaS gestiscano le proprie voci, configurare il controllo degli accessi in base al ruolo di conseguenza o implementare una soluzione come quella di collegamento privato e l'integrazione DNS su larga 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 privato dedicata nella rete virtuale del carico di lavoro.
• Inviare Diagnostica di Azure all'area di lavoro Log Analytics del carico di lavoro. È 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 rete WAN virtuale, Firewall di Azure per impostazione predefinita nega la connettività spoke-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 controllare l'accesso all'interno della rete virtuale e aggiungere una protezione più granulare, prendere in considerazione le raccomandazioni del gruppo di sicurezza di rete seguenti.

• 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 di rete per le macchine virtuali client che devono accedere all'archiviazione e una 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 macchina virtuale del carico di lavoro abbia un gruppo di sicurezza di rete.
• 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 del 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 sicurezza del servizio app di calcolo di accedere all'asg dell'account di archiviazione.
  • Consentire l'ambiente del servizio app di calcolo all'hub a livello di area Firewall di Azure ip privato per UDP sulla porta 53.

*Figura 9: Regole dei gruppi di sicurezza di rete per la subnet del carico di lavoro

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

È consigliabile esporre endpoint privati in una subnet dedicata di piccole dimensioni all'interno della rete virtuale che usa. Un motivo è che è possibile applicare route definite dall'utente e criteri di rete del gruppo di sicurezza di rete per gli endpoint privati per il controllo e la sicurezza del traffico aggiunti.

Questo scenario consente l'applicazione di un gruppo di sicurezza di rete estremamente restrittivo.

• Regole in ingresso:
  • Consentire al gruppo di sicurezza del servizio app di calcolo di accedere all'asg dell'account di archiviazione
  • Nega tutto il traffico
• Regole in uscita:
  • Nega tutto il traffico

*Figura 10: Regole del gruppo di sicurezza di rete 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 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.

È importante evidenziare che il nome di dominio completo viene risolto nell'indirizzo IP privato e non nell'indirizzo IP pubblico. Questa risoluzione significa che tutti gli spoke ricevono sempre l'indirizzo IP privato di questo servizio. Un altro scenario illustra come usare questo approccio per condividere un servizio PaaS tra più carichi di lavoro che usano. Per questo scenario a carico di lavoro singolo, questo non è un problema.

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, tra aree, il gruppo di sicurezza di rete nella subnet dell'endpoint privato è ancora configurato per bloccare tutto il traffico diverso dalle origini del gruppo di sicurezza di calcolo all'interno della rete virtuale che ospita il carico di lavoro.

Riepilogo

Questo articolo presenta uno scenario in cui un client di macchine virtuali si connette all'account 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 DNS in grado di risolvere 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 consente al team di rete aziendale di esporre i servizi DNS condivisi agli spoke del carico di lavoro che li richiedono.

Risorse correlate

• Che cos'è un endpoint privato?
• Configurazione DNS dell'endpoint privato di Azure
• collegamento privato e l'integrazione DNS su larga scala
• collegamento privato di Azure in una rete hub-spoke
• DNS per le risorse locali e di Azure
• Connettività della zona di destinazione dei dati a singola area
• Usare Collegamento privato di Azure per connettere le reti a 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 dell'endpoint privato di Azure per un carico di lavoro locale