Distribuire l'istanza di Azure Gestione API in una rete virtuale - modalità esterna

  • Articolo

SI APPLICA A: Sviluppatore | Premium

Gestione API di Azure può essere distribuito (inserito) all'interno di una rete virtuale di Azure per accedere ai servizi back-end all'interno della rete. Per le opzioni, i requisiti e le considerazioni sulla connettività della rete virtuale, vedere:

Questo articolo illustra come configurare la connettività di rete virtuale per l'istanza di Gestione API in modalità esterna, in cui il portale per sviluppatori, il gateway API e altri endpoint Gestione API sono accessibili da Internet pubblico e i servizi back-end si trovano nella rete.

Connessione alla rete virtuale esterna

Per le configurazioni specifiche della modalità interna, in cui gli endpoint sono accessibili solo all'interno della rete virtuale, vedere Distribuire l'istanza di Azure Gestione API in una rete virtuale- modalità interna.

Nota

È consigliabile usare il modulo Azure Az PowerShell per interagire con Azure. Per iniziare, vedere Installare Azure PowerShell. Per informazioni su come eseguire la migrazione al modulo AZ PowerShell, vedere Eseguire la migrazione di Azure PowerShell da AzureRM ad Az.

Prerequisiti

Prima di iniziare, esaminare i requisiti delle risorse di rete per Gestione API l'inserimento in una rete virtuale.

Alcuni prerequisiti variano a seconda della versione (stv2 o stv1) della piattaforma di calcolo che ospita l'istanza di Gestione API.

Suggerimento

Quando si usa il portale per creare o aggiornare la connessione di rete di un'istanza di Gestione API esistente, l'istanza è ospitata nella piattaforma di calcolo stv2.

  • Una rete virtuale e la subnet devono trovarsi nella stessa area e nella stessa sottoscrizione dell'istanza di Gestione API.

    • La subnet usata per connettersi all'istanza di Gestione API può contenere altri tipi di risorse di Azure.
    • La subnet non deve avere alcuna delega abilitata. L'impostazione Delegare subnet a un servizio per la subnet deve essere impostata su Nessuna.

  • Un gruppo di sicurezza di rete collegato alla subnet precedente. Un gruppo di sicurezza di rete (NSG) è necessario per consentire in modo esplicito la connettività in ingresso, perché il servizio di bilanciamento del carico usato internamente da Gestione API è sicuro per impostazione predefinita e rifiuta tutto il traffico in ingresso. Per una configurazione specifica, vedere Configurare le regole del gruppo di sicurezza di rete, più avanti in questo articolo.

  • Per determinati scenari, abilitare endpoint di servizio nella subnet a servizi dipendenti, ad esempio Archiviazione di Azure o Azure SQL. Per altre informazioni, vedere Forzare il tunneling del traffico verso il firewall locale usando ExpressRoute o un'appliance virtuale di rete più avanti in questo articolo.

  • Un indirizzo IPv4 pubblico dello SKU Standard. La risorsa indirizzo IP pubblico è necessaria quando si configura la rete virtuale per l'accesso esterno o interno. Con una rete virtuale interna, l'indirizzo IP pubblico viene usato solo per le operazioni di gestione. Altre informazioni su Indirizzi IP di Gestione API.

    • L'indirizzo IP deve trovarsi nella stessa area e nello stesso abbonamento dell'istanza di Gestione API e della rete virtuale.

    • Quando si crea una risorsa di indirizzo IP pubblico, assicurarsi di assegnare un'etichetta di nome DNS a tale risorsa. Se questa risorsa verrà assegnata a un servizio di Gestione API, è necessaria un'etichetta.

    • Per ottenere prestazioni ottimali di rete, è consigliabile usare la preferenza di routing predefinita : rete Microsoft.

    • Quando si crea un indirizzo IP pubblico in un'area in cui si prevede di abilitare la ridondanza della zona per l'istanza di Gestione API, configurare l'impostazione Ridondanza della zona.

    • Il valore dell'indirizzo IP viene assegnato come indirizzo IPv4 pubblico virtuale dell'istanza di Gestione API in tale area.

    • Quando si passa da una rete virtuale esterna a una rete virtuale interna (o viceversa), modificando le subnet nella rete o aggiornando le zone di disponibilità per l'istanza di Gestione API, è necessario configurare un indirizzo IP pubblico diverso.

Abilitare la connessione della rete virtuale

Abilitare la connettività di rete virtuale usando il portale di Azure (stv2 piattaforma di calcolo)

  1. Passare al portale di Azure per trovare l'istanza di Gestione API. Cercare e selezionare Servizi Gestione API.

  2. Scegliere l'istanza di Gestione API.

  3. Selezionare Rete.

  4. Selezionare il tipo di accesso esterno . Selezionare Rete virtuale in portale di Azure.

  5. Nell'elenco di posizioni (aree) in cui viene eseguito il provisioning del servizio Gestione API:

    1. Scegliere una Posizione.
    2. Selezionare Rete virtuale, Subnete indirizzo IP.

    • L'elenco di reti virtuali viene popolato con le reti virtuali di Resource Manager disponibili nelle sottoscrizioni di Azure, configurate nell'area che si sta configurando.

      Impostazioni della rete virtuale nel portale.

  6. Selezionare Applica. La pagina Rete dell'istanza di Gestione API viene aggiornata con le nuove opzioni di rete virtuale e subnet.

  7. Continuare a configurare le impostazioni delle reti virtuali per le posizioni rimanenti dell'istanza di Gestione API.

  8. Nella barra di spostamento superiore selezionare Salva e quindi selezionare Applica configurazione di rete.

L'aggiornamento dell'istanza di Gestione API può richiedere da 15 a 45 minuti. Le istanze nel livello Developer hanno tempi di inattività durante il processo. Le istanze nel livello Premium non hanno tempi di inattività durante il processo.

Abilitare la connettività usando un modello di Resource Manager (stv2 piattaforma di calcolo)

  • Modello di Azure Resource Manager (API versione 2021-08-01)

    Pulsante per distribuire il modello di Resource Manager in Azure.

Abilitare la connettività usando i cmdlet di Azure PowerShell ( piattaformastv1)

Creare o aggiornare un'istanza di Gestione API in una rete virtuale.

Configurare regole per i gruppi di sicurezza di rete

Configurare regole di rete personalizzate nella subnet di Gestione API per filtrare il traffico da e verso l'istanza di Gestione API. Sono consigliabili le regole NSG minime seguenti per garantire il corretto funzionamento e accesso all'istanza. Esaminare attentamente l'ambiente per determinare altre regole che potrebbero essere necessarie.

Importante

A seconda dell'uso della memorizzazione nella cache e di altre funzionalità, potrebbe essere necessario configurare regole del gruppo di sicurezza di rete aggiuntive oltre le regole minime riportate nella tabella seguente. Per informazioni dettagliate sulle impostazioni, vedere Informazioni di riferimento sulla configurazione della rete virtuale.

  • Per la maggior parte degli scenari, usare i tag del servizio indicati anziché gli indirizzi IP del servizio per specificare origini e destinazioni di rete.
  • Impostare la priorità di queste regole su un valore più alto rispetto a quello delle regole predefinite.
Porte di origine/destinazione Direction Protocollo di trasporto Tag di servizio
Origine/Destinazione		 Scopo Tipo di rete virtuale
* / [80], 443 In entrata TCP Internet/VirtualNetwork Comunicazione tra client e Gestione API Solo esterno
*/3443 In entrata TCP ApiManagement/VirtualNetwork Endpoint di gestione per il portale di Azure e PowerShell Esterno e interno
* / 6390 In ingresso TCP AzureLoadBalancer / VirtualNetwork Bilanciamento del carico di infrastruttura di Azure Esterno e interno
* / 443 In entrata TCP AzureTrafficManager/VirtualNetwork Routing di Gestione traffico di Azure per la distribuzione in più aree Solo esterno
* / 443 In uscita TCP VirtualNetwork / Archiviazione Dipendenza da Archiviazione di Azure per la funzionalità di base del servizio Esterno e interno
* / 1433 In uscita TCP VirtualNetwork / SQL Accesso agli endpoint SQL di Azure per la funzionalità di base del servizio Esterno e interno
* / 443 In uscita TCP VirtualNetwork/AzureKeyVault Accesso ad Azure Key Vault per la funzionalità di base del servizio Esterno e interno
* / 1886, 443 In uscita TCP VirtualNetwork/AzureMonitor Pubblicazione di Log di diagnostica e metriche, Integrità risorse e Application Insights Esterno e interno

Connessione a un servizio Web ospitato all'interno di una rete virtuale

Dopo aver connesso il servizio Gestione API alla rete virtuale, è possibile accedere ai servizi back-end al suo interno proprio come si eseguono servizi pubblici. Quando si crea o si modifica un'API, digitare l'indirizzo IP locale o il nome host (se un server DNS è configurato per la rete virtuale) del servizio Web nel campo URL servizio Web.

Aggiungere l'API dalla rete virtuale

Installazione di server DNS personalizzata

In modalità rete virtuale esterna, Azure gestisce il DNS per impostazione predefinita. Facoltativamente, è possibile configurare un server DNS personalizzato.

il servizio Gestione API dipende da vari servizi di Azure. Quando Gestione API è ospitato in una rete virtuale con un server DNS personalizzato, deve risolvere i nomi host di tali servizi di Azure.

  • Per indicazioni sulla configurazione DNS personalizzata, inclusa l'inoltro per i nomi host forniti da Azure, vedere Risoluzione dei nomi per le risorse nelle reti virtuali di Azure.
  • L'accesso alla rete in uscita sulla porta 53 è necessario per la comunicazione con i server DNS. Per altre impostazioni, vedere Informazioni di riferimento sulla configurazione della rete virtuale.

Importante

Se si prevede di usare uno o più server DNS personalizzati per la rete virtuale, configurarlo prima di distribuire un servizio Gestione API al suo interno. In caso contrario, sarà necessario aggiornare il servizio Gestione API ogni volta che si modificano i server DNS eseguendo l'operazione Applica configurazione di rete.

Definizione dei percorsi di trasferimento

  • Un indirizzo IP pubblico (VIP) con carico bilanciato è riservato per fornire l'accesso agli endpoint e alle risorse Gestione API all'esterno della rete virtuale.
    • L'indirizzo VIP pubblico è disponibile nel pannello Panoramica/Informazioni di base nella portale di Azure.

Per altre informazioni e considerazioni, vedere indirizzi IP di Gestione API di Azure.

Indirizzi VIP e DIP

Gli indirizzi IP dinamici (DIP) verranno assegnati a ogni macchina virtuale sottostante nel servizio e usati per accedere a endpoint e risorse nella rete virtuale e nelle reti virtuali con peering. L'indirizzo IP virtuale pubblico (VIP) del servizio Gestione API verrà usato per accedere alle risorse pubbliche.

Se le restrizioni IP elencano le risorse protette all'interno della rete virtuale o delle reti virtuali con peering, è consigliabile specificare l'intero intervallo di subnet in cui viene distribuito il servizio Gestione API per concedere o limitare l'accesso dal servizio.

Altre informazioni sulle dimensioni di subnet consigliate.

Forzare il tunneling del traffico al firewall locale usando ExpressRoute o un'appliance virtuale di rete

Il tunneling forzato consente di reindirizzare o "forzare" tutto il traffico associato a Internet dalla subnet all'ambiente locale per l'ispezione e il controllo. In genere, si configura e si definisce una route predefinita (0.0.0.0/0), forzando tutto il traffico dalla subnet di Gestione API a passare attraverso un firewall locale o un'appliance virtuale di rete. Questo flusso di traffico interrompe la connettività con Gestione API perché il traffico in uscita è bloccato in locale o convertito tramite NAT in un set non riconoscibile di indirizzi che non usano più i diversi endpoint di Azure. Per risolvere questo problema, utilizzare i metodi riportati di seguito:

  • Abilitare gli endpoint di servizio nella subnet in cui è distribuito il servizio Gestione API per:

    • Azure SQL (obbligatorio solo nell'area primaria se il servizio Gestione API viene distribuito in più aree)
    • Archiviazione di Azure
    • Hub eventi di Azure
    • Azure Key Vault (obbligatorio quando Gestione API viene distribuito nella piattaforma stv2)

    L'abilitazione degli endpoint direttamente dalla subnet di Gestione API a questi servizi consente di usare la rete backbone di Microsoft Azure che fornisce il routing ottimale per il traffico del servizio. Se si usano gli endpoint di servizio con Gestione API con tunneling forzato, il tunneling del traffico dei servizi di Azure sopra indicati non viene forzato. Tuttavia, l'altro tunneling del traffico relativo alle dipendenze del servizio Gestione API viene forzato. Assicurarsi che il firewall o l'appliance virtuale non blocchi questo traffico e che il servizio Gestione API funzioni correttamente.

    Nota

    È consigliabile abilitare gli endpoint di servizio direttamente dalla subnet di Gestione API ai servizi dipendenti, ad esempio Azure SQL e Archiviazione di Azure che li supportano. Tuttavia, alcune organizzazioni potrebbero avere i requisiti per forzare il tunneling di tutto il traffico dalla subnet di Gestione API. In questo caso, assicurarsi di configurare il firewall o l'appliance virtuale per consentire questo traffico. Sarà necessario consentire l'intervallo di indirizzi IP completo di ogni servizio dipendente e mantenere questa configurazione aggiornata quando cambia l'infrastruttura di Azure. Il servizio Gestione API può anche riscontrare latenza o timeout imprevisti a causa del tunneling forzato di questo traffico di rete.

  • Tutto il traffico del piano di controllo da Internet all'endpoint di gestione del servizio Gestione API viene instradato attraverso un set specifico di indirizzi IP in ingresso ospitati da Gestione AP, inclusi nel tag del servizioApiManagement. Quando il traffico viene sottoposto a tunneling forzato, le risposte non verranno mappate in modo simmetrico a questi indirizzi IP di origine in ingresso e la connettività all'endpoint di gestione andrà persa. Per superare questa limitazione, configurare una route definita dall'utente (UDR) per il tag del servizio ApiManagement con il tipo di hop successivo impostato su "Internet" per indirizzare il traffico ad Azure.

    Nota

    Consentire al traffico di gestione di Gestione API di ignorare un firewall locale o un'appliance virtuale di rete non è considerato un rischio significativo per la sicurezza. La configurazione consigliata per la subnet di Gestione API consente il traffico di gestione in ingresso sulla porta 3443 solo dal set di indirizzi IP di Azure inclusi nel tag del servizio ApiManagement. La configurazione UDR consigliata è solo per il percorso di ritorno del traffico di Azure.

  • (Modalità rete virtuale esterna) Il traffico del piano dati per i client che tentano di raggiungere il gateway di Gestione API e il portale per sviluppatori da Internet verrà eliminato anche per impostazione predefinita a causa del routing asimmetrico introdotto dal tunneling forzato. Per ogni client che richiede l'accesso, configurare una route definita dall'utente esplicita con il tipo hop successivo "Internet" per ignorare il firewall o l'appliance di rete virtuale.

  • Per le altre dipendenze del servizio Gestione API con tunneling forzato, risolvere il nome host e raggiungere l'endpoint. tra cui:

    • Metriche e monitoraggio dell'integrità
    • Diagnostica del portale di Azure
    • Relay SMTP
    • CAPTCHA del portale per sviluppatori
    • Server del servizio di gestione delle chiavi di Azure

Per altre informazioni, vedere Informazioni di riferimento sulla configurazione della rete virtuale.

Problemi comuni di configurazione di rete

Questa sezione è stata spostata. Vedere Informazioni di riferimento sulla configurazione della rete virtuale.

Risoluzione dei problemi

Distribuzione iniziale non riuscita del servizio Gestione API in una subnet

  • Distribuire una macchina virtuale nella stessa subnet.
  • Connettersi alla macchina virtuale e convalidare la connettività a una delle risorse seguenti nella sottoscrizione di Azure:
    • BLOB di Archiviazione di Azure
    • Database SQL di Microsoft Azure
    • Tabella di archiviazione di Azure
    • Azure Key Vault (per un'istanza di Gestione API ospitata nella piattaforma stv2)

Importante

Dopo aver convalidato la connettività, rimuovere tutte le risorse nella subnet prima di distribuire Gestione API nella subnet (obbligatorio quando Gestione API è ospitata nella piattaforma stv1).

Verificare lo stato della rete

  • Dopo aver distribuito Gestione API nella subnet, usare il portale per verificare la connettività dell'istanza alle dipendenze, ad esempio Archiviazione di Azure.

  • Nel portale, nel menu a sinistra, in Distribuzione e infrastruttura, selezionare Rete>Stato rete.

    Screenshot della verifica dello stato della connettività di rete nel portale.

Filtro Descrizione
Obbligatorio Selezionare questa opzione per esaminare la connettività dei servizi di Azure necessaria per Gestione API. L'errore indica che l'istanza non è in grado di eseguire operazioni di base per gestire le API.
Facoltativo Selezionare questa opzione per esaminare la connettività facoltativa dei servizi. L'errore indica solo che la funzionalità specifica non funzionerà (ad esempio SMTP). L'errore può causare una riduzione delle prestazioni nell'uso e nel monitoraggio dell'istanza di Gestione API e nella fornitura del contratto di servizio di cui è stato eseguito il commit.

Per risolvere i problemi di connettività, selezionare:

  • Metriche: per esaminare le metriche relative allo stato della connettività di rete

  • Diagnosi: per eseguire un verificatore di rete virtuale in un periodo di tempo specificato

Per risolvere i problemi di connettività, esaminare le impostazioni di configurazione di rete e correggere le impostazioni di rete necessarie.

Aggiornamenti incrementali

Quando si apportano modifiche alla rete, fare riferimento all'API NetworkStatus per verificare che il servizio Gestione API non abbia perso l'accesso alle risorse critiche. Lo stato della connettività dovrebbe essere aggiornato ogni 15 minuti.

Per applicare una modifica di configurazione di rete all'istanza di Gestione API tramite il portale:

  1. Nel menu a sinistra relativo all'istanza, in Distribuzione e infrastruttura, selezionare Rete>Stato rete.
  2. Selezionare Applica configurazione di rete.

Un'istanza di Gestione API ospitata nella piattaforma di calcolo stv1, quando viene distribuita in una subnet di rete virtuale di Resource Manager, riserva la subnet creando un collegamento di spostamento delle risorse. Se la subnet contiene già una risorsa da un provider diverso, la distribuzione ha esito negativo. Quando, analogamente, si elimina un servizio Gestione API o si sposta il servizio in una subnet diversa, il collegamento di spostamento delle risorse viene rimosso.

Problemi riscontrati nella riassegnazione dell'istanza di Gestione API alla subnet precedente

  • Blocco della rete virtuale: quando si sposta un'istanza di Gestione API nella subnet originale, la riassegnazione immediata potrebbe non essere possibile a causa del blocco della rete virtuale, che richiede fino a sei ore per essere rimosso. Se la subnet originale include altri servizi di Gestione API basati sulla piattaforma stv1 (basati sul servizio cloud), è necessario eliminarli e attendere 6 ore per la distribuzione di un servizio basato su piattaforma stv2 nella stessa subnet.
  • Blocco del gruppo di risorse: un altro scenario da considerare è la presenza di un blocco di ambito a livello di gruppo di risorse o superiore, che ostacola il processo di eliminazione del collegamento di spostamento delle risorse. Per risolvere questo problema, rimuovere il blocco di ambito e consentire un ritardo di circa 4-6 ore per il collegamento del servizio Gestione API dalla subnet originale prima della rimozione del blocco, abilitando la distribuzione nella subnet desiderata.

Risolvere i problemi di connessione a Microsoft Graph dall'interno di una rete virtuale

La connettività di rete a Microsoft Graph è necessaria per funzionalità che includono l'accesso utente al portale per sviluppatori usando il provider di identità Microsoft Entra.

Per risolvere i problemi di connettività a Microsoft Graph dall'interno di una rete virtuale:

  • Assicurarsi che il gruppo di sicurezza di rete e altre regole di rete siano configurate per la connettività in uscita dall'istanza di Gestione API a Microsoft Graph (usando il tag di servizio AzureActiveDirectory).

  • Verificare la risoluzione DNS e l'accesso alla rete per graph.microsoft.com dall'interno della rete virtuale. Ad esempio, effettuare il provisioning di una nuova macchina virtuale all'interno della rete virtuale, connettersi e provare il comando GET https://graph.microsoft.com/v1.0/$metadata da un browser o usando cURL, PowerShell o altri strumenti.

Passaggi successivi

Altre informazioni su: