Uw Azure API Management-exemplaar implementeren in een virtueel netwerk - externe modus

  • Artikel

VAN TOEPASSING OP: Ontwikkelaar | Premium

Azure API Management kan worden geïmplementeerd (geïnjecteerd) in een virtueel Azure-netwerk (VNet) voor toegang tot back-endservices binnen het netwerk. Zie voor VNet-connectiviteitsopties, vereisten en overwegingen:

In dit artikel wordt uitgelegd hoe u VNet-connectiviteit instelt voor uw API Management-exemplaar in de externe modus, waar de ontwikkelaarsportal, API-gateway en andere API Management-eindpunten toegankelijk zijn via het openbare internet en back-endservices zich in het netwerk bevinden.

Verbinding maken naar extern VNet

Voor configuraties die specifiek zijn voor de interne modus, waarbij de eindpunten alleen toegankelijk zijn binnen het VNet, raadpleegt u Uw Azure API Management-exemplaar implementeren in een virtueel netwerk - interne modus.

Notitie

Het wordt aanbevolen de Azure Az PowerShell-module te gebruiken om te communiceren met Azure. Zie Azure PowerShell installeren om aan de slag te gaan. Raadpleeg Azure PowerShell migreren van AzureRM naar Az om te leren hoe u naar de Azure PowerShell-module migreert.

Vereisten

Controleer de netwerkresourcevereisten voor API Management-injectie in een virtueel netwerk voordat u begint.

Sommige vereisten verschillen, afhankelijk van de versie (stv2 of stv1) van het rekenplatform dat als host fungeert voor uw API Management-exemplaar.

Tip

Wanneer u de portal gebruikt om de netwerkverbinding van een bestaand API Management-exemplaar te maken of bij te werken, wordt het exemplaar gehost op het stv2 rekenplatform.

  • Een virtueel netwerk en subnet in dezelfde regio en hetzelfde abonnement als uw API Management-exemplaar.

    • Het subnet dat wordt gebruikt om verbinding te maken met het API Management-exemplaar kan andere Azure-resourcetypen bevatten.
    • Het subnet mag geen delegaties hebben ingeschakeld. Het subnet Delegeren naar een service-instelling voor het subnet moet worden ingesteld op Geen.

  • Een netwerkbeveiligingsgroep die is gekoppeld aan het bovenstaande subnet. Een netwerkbeveiligingsgroep (NSG) is vereist om binnenkomende connectiviteit expliciet toe te staan, omdat de load balancer die intern door API Management wordt gebruikt, standaard beveiligd is en al het binnenkomende verkeer weigert. Zie NSG-regels configureren verderop in dit artikel voor specifieke configuratie.

  • Schakel voor bepaalde scenario's service-eindpunten in het subnet in op afhankelijke services, zoals Azure Storage of Azure SQL. Zie Tunnelverkeer geforceerd naar een on-premises firewall met behulp van ExpressRoute of virtueel netwerkapparaat, verderop in dit artikel voor meer informatie.

  • Een openbaar IPv4-adres voor een standaard-SKU. De resource van het openbare IP-adres is vereist bij het instellen van het virtuele netwerk voor externe of interne toegang. Met een intern virtueel netwerk wordt het openbare IP-adres alleen gebruikt voor beheerbewerkingen. Meer informatie over IP-adressen van API Management.

    • Het IP-adres moet zich in dezelfde regio en hetzelfde abonnement bevinden als het API Management-exemplaar en het virtuele netwerk.

    • Wanneer u een openbare IP-adresresource maakt, moet u ervoor zorgen dat u er een DNS-naamlabel aan toewijst. Welk label u kiest, is niet van belang, maar een label is vereist als deze resource wordt toegewezen aan een API Management-service.

    • Voor de beste netwerkprestaties is het raadzaam om de standaardvoorkeur routering te gebruiken: Microsoft-netwerk.

    • Wanneer u een openbaar IP-adres maakt in een regio waar u zoneredundantie wilt inschakelen voor uw API Management-exemplaar, configureert u de zone-redundante instelling.

    • De waarde van het IP-adres wordt toegewezen als het virtuele openbare IPv4-adres van het API Management-exemplaar in die regio.

    • Wanneer u overstapt van een extern naar een intern virtueel netwerk (of omgekeerd), subnetten in het netwerk wijzigt of beschikbaarheidszones voor het API Management-exemplaar bijwerkt, moet u een ander openbaar IP-adres configureren.

VNet-verbinding inschakelen

VNet-connectiviteit inschakelen met behulp van Azure Portal (stv2 rekenplatform)

  1. Ga naar Azure Portal om uw API Management-exemplaar te vinden. Zoek en selecteer API Management-services.

  2. Kies uw API Management-exemplaar.

  3. Selecteer Netwerk.

  4. Selecteer het externe toegangstype. Selecteer VNet in Azure Portal.

  5. In de lijst met locaties (regio's) waar uw API Management-service wordt ingericht:

    1. Kies een Locatie.
    2. Selecteer Virtueel netwerk, subnet en IP-adres.

    • De VNet-lijst wordt gevuld met Resource Manager-VNets die beschikbaar zijn in uw Azure-abonnementen, die zijn ingesteld in de regio die u configureert.

      VNet-instellingen in de portal.

  6. Selecteer Toepassen. De netwerkpagina van uw API Management-exemplaar wordt bijgewerkt met uw nieuwe VNet- en subnetopties.

  7. Ga door met het configureren van VNet-instellingen voor de resterende locaties van uw API Management-exemplaar.

  8. Selecteer Opslaan in de bovenste navigatiebalk en selecteer vervolgens Netwerkconfiguratie toepassen.

Het kan 15 tot 45 minuten duren voordat het API Management-exemplaar is bijgewerkt. Exemplaren in de developer-laag hebben downtime tijdens het proces. Exemplaren in de Premium-laag hebben geen downtime tijdens het proces.

Connectiviteit inschakelen met behulp van een Resource Manager-sjabloon (stv2 rekenplatform)

  • Azure Resource Manager-sjabloon (API-versie 2021-08-01)

    Knop voor het implementeren van de Resource Manager-sjabloon in Azure.

Connectiviteit inschakelen met behulp van Azure PowerShell-cmdlets (stv1 platform)

Een API Management-exemplaar maken of bijwerken in een VNet.

NSG-regels configureren

Configureer aangepaste netwerkregels in het API Management-subnet om verkeer naar en van uw API Management-exemplaar te filteren. We raden de volgende minimale NSG-regels aan om de juiste werking en toegang tot uw exemplaar te garanderen. Controleer uw omgeving zorgvuldig om meer regels te bepalen die mogelijk nodig zijn.

Belangrijk

Afhankelijk van uw gebruik van caching en andere functies, moet u mogelijk aanvullende NSG-regels configureren buiten de minimale regels in de volgende tabel. Zie de naslaginformatie over de configuratie van virtuele netwerken voor gedetailleerde instellingen.

  • Gebruik voor de meeste scenario's de aangegeven servicetags in plaats van service-IP-adressen om netwerkbronnen en bestemmingen op te geven.
  • Stel de prioriteit van deze regels hoger in dan die van de standaardregels.
Bron-/doelpoort(en) Richting Transportprotocol Servicetags
Bron/doel		 Doel VNet-type
* / [80], 443 Inkomend TCP Internet/VirtualNetwork Clientcommunicatie met API Management Alleen extern
* / 3443 Inkomend TCP ApiManagement /VirtualNetwork Beheereindpunt voor Azure Portal en PowerShell Extern en intern
* / 6390 Inkomend TCP AzureLoadBalancer/VirtualNetwork Load balancer voor Azure-infrastructuur Extern en intern
* / 443 Inkomend TCP AzureTrafficManager/VirtualNetwork Azure Traffic Manager-routering voor implementatie met meerdere regio's Alleen extern
* / 443 Uitgaand TCP VirtualNetwork / Storage Afhankelijkheid van Azure Storage voor kernservicefunctionaliteit Extern en intern
* / 1433 Uitgaand TCP VirtualNetwork / SQL Toegang tot Azure SQL-eindpunten voor kernservicefunctionaliteit Extern en intern
* / 443 Uitgaand TCP VirtualNetwork/AzureKeyVault Toegang tot Azure Key Vault voor kernservicefunctionaliteit Extern en intern
* / 1886, 443 Uitgaand TCP VirtualNetwork/AzureMonitor Diagnostische logboeken en metrische gegevens, Resource Health en Application Insights publiceren Extern en intern

Verbinding maken naar een webservice die wordt gehost in een virtueel netwerk

Zodra u uw API Management-service hebt verbonden met het VNet, hebt u toegang tot back-endservices in het netwerk, net zoals openbare services. Wanneer u een API maakt of bewerkt, typt u het lokale IP-adres of de hostnaam (als een DNS-server is geconfigureerd voor het VNet) van uw webservice in het veld URL van de webservice.

API toevoegen vanuit VNet

Aangepaste instelling van DNS-server

In de externe VNet-modus beheert Azure de DNS standaard. U kunt desgewenst een aangepaste DNS-server configureren.

De API Management-service is afhankelijk van verschillende Azure-services. Wanneer API Management wordt gehost in een VNet met een aangepaste DNS-server, moet deze de hostnamen van deze Azure-services omzetten.

Belangrijk

Als u van plan bent een of meer aangepaste DNS-servers voor het VNet te gebruiken, stelt u deze in voordat u een API Management-service in het netwerk implementeert. Anders moet u de API Management-service bijwerken telkens wanneer u de DNS-server(s) wijzigt door de bewerking Netwerkconfiguratie toepassen uit te voeren.

Routering

  • Een openbaar IP-adres (VIP) met gelijke taakverdeling is gereserveerd voor toegang tot de API Management-eindpunten en -resources buiten het VNet.
    • Het openbare VIP vindt u op de blade Overzicht/Essentials in Azure Portal.

Zie IP-adressen van Azure API Management voor meer informatie en overwegingen.

VIP- en DIP-adressen

Dynamische IP-adressen (DIP) worden toegewezen aan elke onderliggende virtuele machine in de service en gebruikt voor toegang tot eindpunten en resources in het VNet en in gekoppelde VNet's. Het OPENBARE IP-adres (VIP) van de API Management-service wordt gebruikt voor toegang tot openbare resources.

Als met IP-beperking beveiligde resources in het VNet of gekoppelde VNet's worden vermeld, raden we u aan het hele subnetbereik op te geven waarin de API Management-service wordt geïmplementeerd om toegang van de service te verlenen of te beperken.

Meer informatie over de aanbevolen subnetgrootte.

Tunnelverkeer naar een on-premises firewall afdwingen met behulp van ExpressRoute of virtueel netwerkapparaat

Met geforceerde tunneling kunt u al het internetverkeer van uw subnet terug naar on-premises omleiden of 'forceren' voor inspectie en controle. Doorgaans configureert en definieert u uw eigen standaardroute (0.0.0.0/0), waardoor al het verkeer van het API Management-subnet wordt geforceerd door een on-premises firewall of naar een virtueel netwerkapparaat. Deze verkeersstroom breekt de connectiviteit met API Management, omdat uitgaand verkeer on-premises wordt geblokkeerd of NAT naar een onherkenbare set adressen die niet meer werken met verschillende Azure-eindpunten. U kunt dit probleem oplossen via de volgende methoden:

  • Schakel service-eindpunten in op het subnet waarin de API Management-service is geïmplementeerd voor:

    • Azure SQL (alleen vereist in de primaire regio als de API Management-service wordt geïmplementeerd in meerdere regio's)
    • Azure Storage
    • Azure Event Hubs
    • Azure Key Vault (vereist wanneer API Management op het stv2 platform wordt geïmplementeerd)

    Door eindpunten rechtstreeks vanuit het API Management-subnet naar deze services in te schakelen, kunt u het Backbone-netwerk van Microsoft Azure gebruiken en optimale routering bieden voor serviceverkeer. Als u service-eindpunten gebruikt met een geforceerde TUNNELed API Management, wordt verkeer voor de voorgaande Azure-services niet geforceerd geforceerd getunneld. Het andere verkeer van de API Management-serviceafhankelijkheid blijft echter geforceerd getunneld. Zorg ervoor dat uw firewall of virtueel apparaat dit verkeer niet blokkeert of dat de API Management-service mogelijk niet goed werkt.

    Notitie

    We raden u ten zeerste aan service-eindpunten rechtstreeks vanuit het API Management-subnet in te schakelen naar afhankelijke services, zoals Azure SQL en Azure Storage die deze ondersteunen. Sommige organisaties hebben echter mogelijk vereisten om al het verkeer van het API Management-subnet af te dwingen. In dit geval moet u ervoor zorgen dat u uw firewall of virtueel apparaat zo configureert dat dit verkeer wordt toegestaan. U moet het volledige IP-adresbereik van elke afhankelijke service toestaan en deze configuratie up-to-date houden wanneer de Azure-infrastructuur wordt gewijzigd. Uw API Management-service kan ook latentie of onverwachte time-outs ondervinden vanwege de geforceerde tunneling van dit netwerkverkeer.

  • Al het verkeer van het besturingsvlak van internet naar het beheereindpunt van uw API Management-service wordt gerouteerd via een specifieke set binnenkomende IP-adressen, gehost door API Management, die wordt beheerd door de ApiManagement-servicetag. Wanneer het verkeer geforceerd wordt getunneld, worden de antwoorden niet symmetrisch toegewezen aan deze binnenkomende bron-IP-adressen en gaat de connectiviteit met het beheereindpunt verloren. Om deze beperking te overwinnen, configureert u een door de gebruiker gedefinieerde route (UDR) voor de ApiManagement-servicetag met het volgende hoptype ingesteld op 'Internet', om verkeer terug te sturen naar Azure.

    Notitie

    Het toestaan van API Management-beheerverkeer om een on-premises firewall of virtueel netwerkapparaat te omzeilen, wordt niet beschouwd als een aanzienlijk beveiligingsrisico. De aanbevolen configuratie voor uw API Management-subnet staat inkomend beheerverkeer alleen toe op poort 3443 van de set Azure IP-adressen die zijn opgenomen in de ApiManagement-servicetag. De aanbevolen UDR-configuratie is alleen voor het retourpad van dit Azure-verkeer.

  • (Externe VNet-modus) Gegevensvlakverkeer voor clients die de API Management-gateway en de ontwikkelaarsportal van internet proberen te bereiken, worden ook standaard verwijderd vanwege asymmetrische routering die wordt geïntroduceerd door geforceerde tunneling. Voor elke client waarvoor toegang is vereist, configureert u een expliciete UDR met het volgende hoptype 'Internet' om de firewall of het virtuele netwerkapparaat te omzeilen.

  • Voor andere geforceerde API Management-serviceafhankelijkheden moet u de hostnaam oplossen en contact opnemen met het eindpunt. Deze omvatten:

    • Metrische gegevens en statuscontrole
    • Diagnostische gegevens van Azure Portal
    • SMTP-relay
    • CAPTCHA voor ontwikkelaarsportal
    • Azure KMS-server

Zie de naslaginformatie over de configuratie van virtuele netwerken voor meer informatie.

Veelvoorkomende problemen met netwerkconfiguratie

Deze sectie is verplaatst. Zie naslaginformatie over de configuratie van virtuele netwerken.

Probleemoplossing

Mislukte initiële implementatie van API Management-service in een subnet

  • Implementeer een virtuele machine in hetzelfde subnet.
  • Verbinding maken naar de virtuele machine en valideer de connectiviteit met een van de volgende resources in uw Azure-abonnement:
    • Azure Storage-blob
    • Azure SQL-database
    • Azure Storage-tabel
    • Azure Key Vault (voor een API Management-exemplaar dat wordt gehost op het stv2 platform)

Belangrijk

Nadat u de connectiviteit hebt geverifieerd, verwijdert u alle resources in het subnet voordat u API Management implementeert in het subnet (vereist wanneer API Management op het stv1 platform wordt gehost).

Netwerkstatus controleren

  • Nadat u API Management in het subnet hebt geïmplementeerd, gebruikt u de portal om de connectiviteit van uw exemplaar te controleren op afhankelijkheden, zoals Azure Storage.

  • Selecteer >in de portal in het linkermenu onder Implementatie en infrastructuur de netwerkstatus.

    Schermopname van de status van de netwerkverbinding controleren in de portal.

Filteren Beschrijving
Vereist Selecteer deze optie om de vereiste Azure-servicesconnectiviteit voor API Management te controleren. Fout geeft aan dat het exemplaar geen kernbewerkingen kan uitvoeren om API's te beheren.
Optioneel Selecteer deze optie om de optionele servicesconnectiviteit te controleren. Fout geeft alleen aan dat de specifieke functionaliteit niet werkt (bijvoorbeeld SMTP). Fout kan leiden tot een afname in het gebruik en bewaken van het API Management-exemplaar en het leveren van de vastgelegde SLA.

Als u verbindingsproblemen wilt oplossen, selecteert u:

  • Metrische gegevens: metrische gegevens over de netwerkverbindingsstatus controleren

  • Diagnose : een virtuele netwerkverificator uitvoeren gedurende een opgegeven periode

Als u verbindingsproblemen wilt oplossen, controleert u de netwerkconfiguratie-instellingen en lost u de vereiste netwerkinstellingen op.

Incrementele updates

Wanneer u wijzigingen aanbrengt in uw netwerk, raadpleegt u de NetworkStatus-API om te controleren of de API Management-service geen toegang heeft verloren tot kritieke resources. De connectiviteitsstatus moet elke 15 minuten worden bijgewerkt.

Een netwerkconfiguratiewijziging toepassen op het API Management-exemplaar met behulp van de portal:

  1. Selecteer in het linkermenu voor uw exemplaar, onder Implementatie en infrastructuur, het>virtuele netwerk van het netwerk.
  2. Selecteer Netwerkconfiguratie toepassen.

Een API Management-exemplaar dat wordt gehost op het stv1 rekenplatform, wanneer deze wordt geïmplementeerd in een VNet-subnet van Resource Manager, reserveert het subnet door een koppeling voor resourcenavigatie te maken. Als het subnet al een resource van een andere provider bevat, mislukt de implementatie. Als u een API Management-service verwijdert of naar een ander subnet verplaatst, wordt de koppeling naar de resourcenavigatie verwijderd.

Problemen met het opnieuw toewijzen van API Management-exemplaar aan het vorige subnet

  • VNet-vergrendeling : wanneer u een API Management-exemplaar weer naar het oorspronkelijke subnet verplaatst, is het mogelijk dat de toewijzing onmiddellijk niet mogelijk is vanwege de VNet-vergrendeling. Dit duurt maximaal zes uur. Als het oorspronkelijke subnet andere stv1 platformgebaseerde API Management-services (op basis van cloudservices) heeft, moet u deze verwijderen en 6 uur wachten voor het implementeren van een stv2 platformservice in hetzelfde subnet.
  • Vergrendeling van resourcegroepen: een ander scenario dat u moet overwegen, is de aanwezigheid van een bereikvergrendeling op het niveau van de resourcegroep of hoger, waardoor het verwijderingsproces van de koppeling voor resourcenavigatie wordt belemmerd. U kunt dit oplossen door de bereikvergrendeling te verwijderen en een vertraging van ongeveer 4-6 uur toe te staan voordat de API Management-service de koppeling van het oorspronkelijke subnet ongedaan maakt voordat de vergrendeling wordt verwijderd, waardoor de implementatie naar het gewenste subnet wordt ingeschakeld.

Verbinding met Microsoft Graph oplossen vanuit een VNet

Netwerkconnectiviteit met Microsoft Graph is nodig voor functies zoals gebruikersaanmelding bij de ontwikkelaarsportal met behulp van de Microsoft Entra-id-provider.

Verbindingsproblemen met Microsoft Graph oplossen vanuit een VNet:

  • Zorg ervoor dat NSG en andere netwerkregels zijn geconfigureerd voor uitgaande connectiviteit van uw API Management-exemplaar naar Microsoft Graph (met behulp van de AzureActiveDirectory-servicetag ).

  • Zorg ervoor dat dns-resolutie en netwerktoegang vanuit graph.microsoft.com het VNet. Richt bijvoorbeeld een nieuwe VIRTUELE machine in het VNet in, maak er verbinding mee en probeer vanuit GET https://graph.microsoft.com/v1.0/$metadata een browser of met cURL, PowerShell of andere hulpprogramma's.

Volgende stappen

Meer informatie over: