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

VAN TOEPASSING OP: Ontwikkelaar | Premie

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

• Een virtueel netwerk gebruiken met Azure API Management
• Vereisten voor netwerkresources voor API Management-injectie in een virtueel netwerk

In dit artikel wordt uitgelegd hoe u VNet-connectiviteit instelt voor uw API Management-exemplaar in de interne modus. In deze modus hebt u alleen toegang tot de volgende API Management-eindpunten binnen een VNet waarvan u de toegang beheert.

• De API-gateway
• De ontwikkelaarsportal
• Direct beheer
• Git

Gebruik API Management in interne modus om:

• Maak API's die worden gehost in uw privé-datacenter veilig toegankelijk voor derden buiten het datacenter met behulp van Azure VPN-verbindingen of Azure ExpressRoute.
• Schakel hybride cloudscenario's in door uw cloud-API's en on-premises API's beschikbaar te maken via een gemeenschappelijke gateway.
• Beheer uw API's die worden gehost op meerdere geografische locaties, met behulp van één gateway-eindpunt.

Voor configuraties die specifiek zijn voor de externalmodus, waar de API Management-eindpunten toegankelijk zijn vanaf het openbare internet en back-endservices zich in het netwerk bevinden, raadpleegt u Deploy your Azure API Management instance to a virtual network - external mode.

Vereisten

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

• Een API Management-exemplaar. Zie Create an Azure API Management instance voor meer informatie.

• 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 actief hebben. De instelling Subnet delegeren naar een service 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 op het subnet voor afhankelijke services zoals Azure Storage of Azure SQL. Voor meer informatie, zie Forceren van tunnelverkeer naar een on-premises firewall met behulp van ExpressRoute of netwerk virtuele appliance, verderop in dit artikel.

• (Optioneel) Een openbaar IPv4-adres voor een standaard-SKU.

  Belangrijk

  • Vanaf mei 2024 is een openbare IP-adresresource niet meer nodig bij het implementeren (injecteren) van een API Management-exemplaar in een VNet in de interne modus of het migreren van de interne VNet-configuratie naar een nieuw subnet. In de externe VNet-modus wordt het opgeven van een openbaar IP-adres optional; Als u er geen opgeeft, wordt automatisch een door Azure beheerd openbaar IP-adres geconfigureerd en gebruikt voor runtime-API-verkeer. Geef alleen het openbare IP-adres op als u de eigenaar wilt zijn van het openbare IP-adres dat wordt gebruikt voor inkomende of uitgaande communicatie met internet.

  • Indien opgegeven, moet het IP-adres 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. Over het algemeen moet u dezelfde DNS-naam gebruiken als uw API Management-exemplaar. Als u dit wijzigt, implementeert u uw exemplaar opnieuw zodat het nieuwe DNS-label wordt toegepast.

  • Voor de beste netwerkprestaties wordt het aangeraden om de standaard Routeringsvoorkeur 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.

• Configureer voor API Management-implementaties met meerdere regio's afzonderlijk resources voor virtuele netwerken voor elke locatie.

VNet-verbinding inschakelen

VNet-connectiviteit inschakelen met behulp van de Azure-portal

1. Ga naar de Azure-portal om uw API Management-exemplaar te vinden. Zoek en selecteer API Management-services.
2. Kies uw API Management-instantie.
3. Selecteer Netwerk>Virtueel netwerk.
4. Selecteer het type interne toegang.
5. In de lijst met locaties (regio's) waar uw API Management-service wordt ingericht:
   1. Kies een Locatie.
   2. Selecteer Virtueel netwerk en subnet.
      • 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.
6. Kies Toepassen. De pagina Virtueel netwerk van uw API Management-exemplaar wordt bijgewerkt met uw nieuwe VNet- en subnetkeuzen.
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.

Na een geslaagde implementatie ziet u het privé-IP-adres van uw API Management-service en het openbare virtuele IP-adres op de blade Overzicht. Zie Routering in dit artikel voor meer informatie over de IP-adressen.

Connectiviteit inschakelen met behulp van een Resource Manager-sjabloon

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

  

NSG-regels configureren

Configureer aangepaste netwerkbeveiligingsregels in het API Management-subnet om verkeer van en naar 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.

• 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.

DNS-configuratie

In de interne VNet-modus moet u uw eigen DNS beheren om binnenkomende toegang tot uw API Management-eindpunten in te schakelen.

We raden het volgende aan:

1. Configureer een Azure DNS-privézone.
2. Koppel de Azure DNS privézone aan het VNet waarin u uw API Management-service hebt geïmplementeerd.

Meer informatie over het set up van een privézone in Azure DNS.

Toegang op standaardhostnamen

Wanneer u een API Management-service maakt (contosointernalvnetbijvoorbeeld), worden de volgende eindpunten standaard geconfigureerd:

Toegang tot aangepaste domeinnamen

Als u geen toegang wilt krijgen tot de API Management-service met de standaardhostnamen, stelt u aangepaste domeinnamen in voor al uw eindpunten, zoals wordt weergegeven in de volgende afbeelding:

DNS-records configureren

Maak records op uw DNS-server om toegang te krijgen tot de eindpunten die toegankelijk zijn vanuit uw VNet. Wijs de eindpuntrecords toe aan het privé-virtuele IP-adres voor uw service.

Voor testdoeleinden kunt u het hosts-bestand bijwerken op een virtuele machine in een subnet dat is verbonden met het VNet waarin API Management wordt geïmplementeerd. Ervan uitgaande dat het privé-virtuele IP-adres voor uw service 10.1.0.5 is, kunt u het hosts-bestand als volgt toewijzen. Het toewijzingsbestand voor hosts bevindt zich op %SystemDrive%\drivers\etc\hosts (Windows) of /etc/hosts (Linux, macOS).

Vervolgens hebt u toegang tot alle API Management-eindpunten vanaf de virtuele machine die u hebt gemaakt.

Routering

De volgende virtuele IP-adressen zijn geconfigureerd voor een API Management-exemplaar in een intern virtueel netwerk.

De openbare en privé-IP-adressen met gelijke taakverdeling vindt u op de blade Overview in de 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.

Voorbeeld

Als u 1 capaciteitseenheid van API Management implementeert in de Premium-laag in een intern VNet, worden 3 IP-adressen gebruikt: 1 voor het privé-VIP en één voor de DIPs voor twee VM's. Als u uitschaalt naar 4 eenheden, worden er meer IP-adressen gebruikt voor extra DIPs uit het subnet.

Als het doel-eindpunt alleen een vaste set van toegestane DIPs heeft, zullen verbindingsfouten optreden als u in de toekomst nieuwe eenheden toevoegt. Daarom en omdat het subnet volledig in uw beheer is, raden we u aan het hele subnet op de vergunningenlijst in de backend toe te voegen.

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 verbreekt de connectiviteit met API Management, omdat uitgaand verkeer on-premises wordt geblokkeerd of NAT't naar een set adressen die onherkenbaar is en niet meer werkt 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 is geïmplementeerd in meerdere regio's)
  • Azure Storage
  • Azure Event Hubs
  • Azure Key Vault

  Door eindpunten rechtstreeks vanuit het API Management-subnet naar deze services in te schakelen, kunt u het Microsoft Azure backbone-netwerk gebruiken en optimale routering bieden voor serviceverkeer. Als u service-eindpunten gebruikt met API Management met geforceerde tunneling, wordt verkeer voor de onderstaande Azure-services niet 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 de verplichting om al het verkeer vanuit het API Management-subnet via de tunnel te laten gaan. 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 verandert. Uw API Management-service kan ook latentie of onverwachte time-outs ondervinden vanwege de geforceerde tunneling van dit netwerkverkeer.

• Al het besturingsvlakverkeer van het internet naar het beheereindpunt van uw API Management-service wordt gerouteerd via een specifieke set inkomende IP-adressen, gehost door API Management, opgenomen in de ApiManagementservicetag. 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 opgevraagde 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) Datavlakverkeer voor clients die proberen om de API Management-gateway en de ontwikkelaarsportal vanuit het internet te bereiken, wordt ook standaard geblokkeerd vanwege asymmetrische routering die het gevolg is van 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 afhankelijkheden van de force-tunneled API-beheer-service, moet u de hostnaam resolven en contact opnemen met het eindpunt. Deze omvatten:

  • Metrische gegevens en statuscontrole
  • Azure Portal Diagnostiek
  • SMTP-relay
  • CAPTCHA voor ontwikkelaarsportaal
  • 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.
• Maak verbinding met de virtuele machine en valideer de connectiviteit met een van de volgende resources in uw Azure-abonnement:
  • Azure-opslagblob
  • Azure SQL Database
  • Azure Storage tabel
  • Azure Key Vault

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 zijbalkmenu onder > denetwerkstatus.

  

Als u verbindingsproblemen wilt oplossen, selecteert u:

• Metingen - om de metingen van de netwerkverbindingsstatus te beoordelen

• 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 omgeving, onder Implementatie en infrastructuur, Netwerk>Virtueel netwerk.
2. Selecteer Netwerkconfiguratie toepassen.

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 het opnieuw toewijzen niet mogelijk is vanwege de VNet-vergrendeling. Dit duurt maximaal één uur om te worden verwijderd.
• 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.

Problemen met de verbinding met Microsoft Graph vanuit een VNet oplossen

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 vanuit een VNet oplossen:

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

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

Verwante inhoud

Meer informatie over:

• Naslaginformatie over configuratie van virtuele netwerken
• Veelgestelde vragen over VNet
• Een record maken in DNS