Bereitstellen Ihrer Azure API Management-Instanz in einem virtuellen Netzwerk – interner Modus

  • Artikel

GILT FÜR: Entwickler | Premium

Azure API Management kann in einem virtuellen Azure-Netzwerk (VNet) bereitgestellt (eingeschleust) werden, um auf Back-End-Dienste innerhalb des Netzwerks zuzugreifen. Informationen zu VNet-Konnektivitätsoptionen, Anforderungen und Überlegungen finden Sie unter:

In diesem Artikel wird erläutert, wie Sie die VNet-Konnektivität für Ihre API Management-Instanz im internen Modus einrichten. In diesem Modus können Sie nur die folgenden API Management-Endpunkte in einem VNet anzeigen, dessen Zugriff Ihrer Kontrolle unterliegt.

  • API-Gateway
  • Entwicklerportal
  • Direkte Verwaltung
  • Git

Hinweis

  • Keiner der API Management-Dienstendpunkte ist auf dem öffentlichen DNS-Server registriert. Auf die Endpunkte kann erst zugegriffen nach der Konfiguration der DNS für das VNet zugegriffen werden.
  • Um das selbstgehostete Gateway in diesem Modus zu verwenden, aktivieren Sie auch die private Konnektivität mit dem Konfigurationsendpunkt des selbstgehosteten Gateways.

Verwenden Sie API Management im internen Modus für folgende Aufgaben:

  • Gewährleisten eines sicheren Zugriffs auf APIs, die in Ihrem privaten Rechenzentrum gehostet werden, für externe Dritte über Azure-VPN-Verbindungen oder Azure ExpressRoute.
  • Das Verfügbarmachen von cloudbasierten und lokalen APIs über ein gemeinsames Gateway ermöglicht Hybrid Cloud-Szenarien.
  • Verwalten von APIs, die in mehreren geografischen Standorten gehostet werden, über einen einzelnen Gatewayendpunkt.

Verbindung zum internen VNET

Konfigurationen speziell für den externen -Modus, in dem die API-Verwaltungsendpunkte über das öffentliche Internet zugänglich sind, und sich Back-End-Dienste im Netzwerk befinden, finden Sie unter Bereitstellen Ihrer Azure API Management-Instanz in einem virtuellen Netzwerk – externer Modus.

Hinweis

Es wird empfohlen, das Azure Az PowerShell-Modul für die Interaktion mit Azure zu verwenden. Informationen zu den ersten Schritten finden Sie unter Installieren des Azure Az PowerShell-Moduls. Informationen zum Migrieren zum Az PowerShell-Modul finden Sie unter Migrieren von Azure PowerShell von AzureRM zum Az-Modul.

Voraussetzungen

Überprüfen Sie die Netzwerkressourcenanforderungen für die API-Management-Einschleusung in ein virtuelles Netzwerk bevor Sie beginnen.

Einige Voraussetzungen unterscheiden sich abhängig von der Version (stv2 oder stv1) der stv2 für das Hosting Ihrer API Management-Instanz.

Tipp

Wenn Sie das Portal verwenden, um die Netzwerkverbindung einer vorhandenen API Management-Instanz zu erstellen oder zu aktualisieren, wird die Instanz auf der stv2-Computeplattform gehostet.

  • Ein virtuelles Netzwerk und ein Subnetz müssen sich in derselben Region und in demselben Abonnement befinden wie Ihre API Management-Instanz.

    • Das Teilnetz, das zur Verbindung mit der API Management-Instanz verwendet wird, kann andere Azure-Ressourcentypen enthalten.
    • Für das Subnetz sollten keine Delegierungen aktiviert sein. Die Einstellung Subnetz an einen Dienst delegieren für das Subnetz sollte auf Keine festgelegt werden.

  • Eine Netzwerksicherheitsgruppe, die an das oben genannte Subnetz angefügt ist. Eine Netzwerksicherheitsgruppe (NSG) ist erforderlich, um eingehende Verbindungen explizit zuzulassen, da der von API Management intern verwendete Lastenausgleich standardmäßig gesichert ist und sämtlichen eingehenden Datenverkehr abgelehnt. Informationen zur spezifischen Konfiguration finden Sie weiter unten in diesem Artikel unter NSG-Regeln konfigurieren.

  • Aktivieren Sie für bestimmte Szenarien Dienstendpunkte im Subnetz für abhängige Dienste wie Azure Storage oder Azure SQL. Weitere Informationen finden Sie weiter unten in dem Artikel Tunnelerzwingung für Datenverkehr zur lokalen Firewall per ExpressRoute oder virtueller Netzwerk-Appliance.

  • Eine öffentliche IPv4-Adresse mit Standard-SKU. Die öffentliche IP-Adressressource ist erforderlich, wenn Sie das virtuelle Netzwerk für den externen oder internen Zugriff einrichten. Bei einem internen virtuellen Netzwerk wird die öffentliche IP-Adresse nur für Verwaltungsvorgänge verwendet. Erfahren Sie mehr über IP-Adressen von API Management.

    • Die IP-Adresse muss sich in derselben Region und im gleichen Abonnement wie die API Management-Instanz und das virtuelle Netzwerk befinden.

    • Wenn Sie eine Ressource mit öffentlicher IP-Adresse erstellen, stellen Sie sicher, dass Sie ihr ein DNS-Namensetikett zuweisen. Welches Etikett Sie verwenden, spielt keine Rolle, aber ein Etikett ist erforderlich, wenn diese Ressource einem API Management-Dienst zugewiesen werden soll.

    • Für optimale Netzwerkleistung empfiehlt es sich, die Routing Standardeinstellung zu verwenden: Microsoft-Netzwerk.

    • Konfigurieren Sie beim Erstellen einer öffentlichen IP-Adresse in einer Region, in der Sie Die Zonenredundanz für Ihre API Management-Instanz aktivieren möchten, die"Zone-redundant"-Einstellung.

    • Der Wert der IP-Adresse wird als virtuelle öffentliche IPv4-Adresse der API Management Instanz in dieser Region zugewiesen.

    • Wenn Sie von einem externen zu einem internen virtuellen Netzwerk wechseln (oder umgekehrt), Subnetze im Netzwerk ändern oder Verfügbarkeitszonen für die API Management Instanz aktualisieren, müssen Sie eine andere öffentliche IP-Adresse konfigurieren.

VNet-Verbindung aktivieren

Aktivieren der VNet-Konnektivität über das Azure-Portal (stv2-Plattform)

  1. Wechseln Sie zum Azure-Portal, um Ihre API Management-Instanz zu suchen. Suchen Sie die API Management-Dienste, und wählen Sie sie aus.

  2. Wählen Sie Ihre API Management-Instanz aus.

  3. Wählen Sie Netzwerk>Virtuelles Netzwerk aus.

  4. Wählen Sie den Zugriffstyp Intern aus.

  5. In der Liste der Standorte (Regionen), an denen Ihr API Management-Dienst bereitgestellt wird:

    1. Wählen Sie einen Standortaus.
    2. Wählen Sie Virtuelles Netzwerk, Subnetz und IP-Adresse aus.
      • Die Liste der VNets enthält Ressourcen-Manager-VNets, die in Ihrem Azure-Abonnement verfügbar und in der Region eingerichtet sind, die Sie konfigurieren.

  6. Wählen Sie Übernehmen. Die Seite Virtuelles Netzwerk Ihrer API Management-Instanz wird mit Ihren neuen VNet- und Subnetzoptionen aktualisiert. Einrichten eines internen VNet im Azure-Portal

  7. Fahren Sie mit der Konfiguration der VNet-Einstellungen für die übrigen Standorte Ihrer API Management-Instanz fort.

  8. Wählen Sie auf der oberen Navigationsleiste Speichern und dann Netzwerkkonfiguration anwenden aus.

    Es kann zwischen 15 und 45 Minuten dauern, bis die API Management-Instanz aktualisiert wurde. Für den Developer-Tarif kommt es während des Prozesses zu Ausfallzeiten. Bei Basic- und höheren SKUs kommt es während des Prozesses zu keinen Ausfallzeiten.

Nach erfolgreicher Bereitstellung sollten die private virtuelle IP-Adresse und die öffentliche virtuelle IP-Adresse Ihres API Management-Diensts auf dem Blatt Übersicht angezeigt werden. Weitere Informationen zu den IP-Adressen finden Sie in diesem Artikel unter Routing.

Öffentliche und private IP-Adresse im Azure-Portal

Hinweis

Da die Gateway-URL nicht im öffentlichen DNS registriert ist, funktioniert die im Azure-Portal verfügbare Testkonsole nicht für einen internen VNet-bereitgestellten Dienst. Verwenden Sie dafür die im Entwicklerportal bereitgestellte Testkonsole.

Konnektivität mit einer Resource Manager-Vorlage (stv2-Plattform) aktivieren

  • Azure Resource Manager-Vorlage (API-Version 2021-08-01)

    Schaltfläche zum Bereitstellen der Resource Manager-Vorlage in Azure.

Ermöglichen von Konnektivität über Azure PowerShell-Cmdlets (stv1-Plattform)

Erstellen oder aktualisieren Sie eine API Management-Instanz in einem VNet.

Konfigurieren von NSG-Regeln

Benutzerdefinierte Netzwerkregeln im API Management-Subnetz konfigurieren, um den Datenverkehr zu und von Ihrer API Management-Instanz zu filtern. Wir empfehlen die folgenden NSG-Mindestregeln, um einen ordnungsgemäßen Betrieb und Zugriff auf Ihre Instanz sicherzustellen. Überprüfen Sie Ihre Umgebung sorgfältig, um weitere Regeln zu ermitteln, die möglicherweise erforderlich sind.

Wichtig

Je nachdem, wie Sie das Caching und andere Features einsetzen, müssen Sie möglicherweise zusätzliche NSG-Regeln konfigurieren, die über die Mindestregeln in der folgenden Tabelle hinausgehen. Ausführliche Informationen zu den Einstellungen finden Sie unter Referenz zur Konfiguration virtueller Netzwerke.

  • Für die meisten Szenarien bitte die angegebenen Dienst-Tags anstelle von Dienst-IP-Adressen verwenden, um Netzwerkquellen und -ziele anzugeben.
  • Die Priorität dieser Regeln höher als die der Standardregeln setzen.
Quell-/Zielport(s) Direction Transportprotokoll Diensttags
Quelle/Ziel		 Zweck VNet-Typ
* / [80], 443 Eingehend TCP Internet / VirtuellesNetzwerk Kommunikation zwischen Clients und API Management Nur extern
*/3443 Eingehend TCP ApiManagement / VirtuellesNetzwerk Verwaltungsendpunkt für Azure-Portal und PowerShell Extern & Intern
* / 6390 Eingehend TCP AzureLoadBalancer / VirtuellesNetzwerk Lastenausgleich von Azure-Infrastruktur Extern & Intern
* / 443 Eingehend TCP AzureTrafficManager / VirtualNetwork Azure Traffic Manager Routing für die Bereitstellung mit mehreren Regionen Nur extern
* / 443 Ausgehend TCP VirtuellesNetzwerk/Speicher Abhängigkeit von Azure Storage für Kerndienstfunktionen Extern & Intern
* / 1433 Ausgehend TCP VirtualNetwork / SQL Zugriff auf Azure SQL-Endpunkte für Kerndienstfunktionen Extern & Intern
* / 443 Ausgehend TCP VirtuellesNetzwerk / AzureKeyVault Zugriff auf Azure Key Vault für Kerndienstfunktionen Extern & Intern
* / 1886, 443 Ausgehend TCP VirtuellesNetzwerk / AzureMonitor Veröffentlichen von Diagnoseprotokollen und Metriken, Resource Health und Application Insights Extern & Intern

DNS-Konfiguration

Im internen VNET-Modus müssen Sie Ihr eigenes DNS verwalten, um eingehenden Zugriff auf Ihre API Management-Endpunkte zu ermöglichen.

Es wird Folgendes empfohlen:

  1. Konfigurieren Sie eine private Azure DNS-Zone.
  2. Verknüpfen Sie die private Azure DNS-Zone mit dem VNet, in dem Sie Ihren API Management-Dienst bereitgestellt haben.

Erfahren Sie mehr über das Einrichten einer privaten Zone in Azure DNS.

Hinweis

Der API Management-Dienst lauscht nicht auf Anforderungen an seinen IP-Adressen. Er reagiert nur auf Anforderungen für den Host-Namen, der für seine Dienstendpunkte konfiguriert ist. Zu diesen Endpunkten gehören:

  • API-Gateway
  • Das Azure-Portal
  • Entwicklerportal
  • Direktverwaltungsendpunkt
  • Git

Zugreifen über Standardhostnamen

Wenn Sie einen API Management-Dienst erstellen (zum Beispiel contosointernalvnet), werden standardmäßig die folgenden Dienstendpunkte konfiguriert:

Endpunkt Endpunktkonfiguration
API Gateway contosointernalvnet.azure-api.net
Entwicklerportal contosointernalvnet.portal.azure-api.net
Neues Entwicklerportal contosointernalvnet.developer.azure-api.net
Direktverwaltungsendpunkt contosointernalvnet.management.azure-api.net
Git contosointernalvnet.scm.azure-api.net

Zugreifen über benutzerdefinierte Domänennamen

Wenn Sie nicht mit den Standardhostnamen auf den API Management-Dienst zugreifen möchten, richten Sie benutzerdefinierte Domänennamen für alle Ihre Endpunkte ein, wie in der folgenden Abbildung dargestellt:

Einrichten eines benutzerdefinierten Domänennamens

Konfigurieren von DNS-Einträgen

Erstellen Sie Datensätze in Ihrem DNS-Server, um auf die Endpunkte zuzugreifen, auf die Sie in Ihrem VNET zugreifen können. Ordnen Sie die Endpunktdatensätze der privaten virtuellen IP-Adresse für Ihren Dienst zu.

Zu Testzwecken können Sie die Hostdatei auf einem virtuellen Computer in einem Subnetz aktualisieren, das mit dem VNet verbunden ist, in dem das API Management bereitgestellt wird. Wenn die private virtuelle IP-Adresse für Ihren Dienst 10.1.0.5 lautet, können Sie die Hostdatei wie folgt zuordnen. Die Hosts-Zuordnungsdatei befindet sich unter %SystemDrive%\drivers\etc\hosts (Windows) oder /etc/hosts (Linux, macOS).

Interne virtuelle IP-Adresse Endpunktkonfiguration
10.1.0.5 contosointernalvnet.azure-api.net
10.1.0.5 contosointernalvnet.portal.azure-api.net
10.1.0.5 contosointernalvnet.developer.azure-api.net
10.1.0.5 contosointernalvnet.management.azure-api.net
10.1.0.5 contosointernalvnet.scm.azure-api.net

Anschließend können Sie über den virtuellen Computer, den Sie erstellt haben, auf alle API Management-Endpunkte zugreifen.

Routing

Die folgenden virtuellen IP-Adressen werden für eine API Management-Instanz in einem internen virtuellen Netzwerk konfiguriert.

Virtuelle IP-Adresse BESCHREIBUNG
Private virtuelle IP-Adresse Eine IP-Adresse mit Lastenausgleich aus dem Subnetzbereich (DIP) der API Management-Instanz, über die Sie auf das API-Gateway, das Entwicklerportal, die Verwaltung und Git-Endpunkte zugreifen können.

Diese Adresse bei den vom VNet verwendeten DNS-Servern registrieren.
Öffentliche virtuelle IP-Adresse Wird nur für den Datenverkehr auf Steuerungsebene zum Verwaltungsendpunkt über Port 3443 verwendet. Kann für das ApiManagement-Diensttag gesperrt werden.

Die öffentlichen und privaten IP-Adressen mit Lastenausgleich finden Sie auf dem Blatt Übersicht im Azure-Portal.

Weitere Informationen und Hinweise finden Sie unter IP-Adressen von Azure API Management.

VIP- und DIP-Adressen

Dynamische IP-Adressen (DIP) werden jedem zugrunde liegenden virtuellen Computer im Dienst zugewiesen und für den Zugriff auf Endpunkte und Ressourcen im VNet um im Peer-VNet verwendet. Die öffentliche virtuelle IP-Adresse (VIP) des API Management-Dienstes wird für den Zugriff auf Ressourcen außerhalb des VNet verwendet.

Falls Ressourcen innerhalb des VNET oder Peer-VNet mit IP-Einschränkungslisten geschützt werden, wird empfohlen, den gesamten Bereich des Subnetzes anzugeben, in dem der API Management-Dienst bereitgestellt wird, um über den Dienst Zugriff zu gewähren oder zu verweigern.

Erfahren Sie mehr über die empfohlene Subnetzgröße.

Beispiel

Wenn Sie 1 Kapazitätseinheit von API Management im Premium-Tarif in einem internen VNet bereitstellen, werden 3 IP-Adressen verwendet: 1 für die private VIP und jeweils eine für die DIPs für zwei VMs. Wenn Sie auf vier Einheiten aufskalieren, werden mehr IP-Adressen für zusätzliche DIPs aus dem Subnetz verbraucht.

Wenn für den Zielendpunkt nur eine feste Gruppe von DIPs in der Positivliste aufgeführt ist, kommt es zu Verbindungsfehlern, wenn Sie in Zukunft neue Einheiten hinzufügen. Aus diesem Grund und weil sich das Subnetz vollständig unter Ihrer Kontrolle befindet, wird empfohlen, das gesamte Subnetz in die Positivliste im Back-End aufzunehmen.

Tunnelerzwingung für Datenverkehr zur lokalen Firewall per ExpressRoute oder virtueller Netzwerk-Appliance

Durch erzwungenes Tunneln können sie den gesamten an das Internet gebundenen Datenverkehr aus Ihrem Subnetz zur Inspektion und Überprüfung an den Standort zurückleiten oder „erzwingen“. In der Regel konfigurieren und definieren Sie ihre eigene Standardroute (0.0.0.0/0), indem Sie den gesamten Datenverkehr aus allen API Management-Subnetzen dazu zwingen, durch eine lokale Firewall oder zu einer virtuellen Netzwerl.Appiance zu fließen. Bei diesem Datenverkehrsfluss funktioniert die Verbindung mit Azure API Management nicht mehr, da ausgehender Datenverkehr entweder lokal blockiert oder mittels NAT in eine nicht mehr nachvollziehbare Gruppe von Adressen übersetzt wird, die nicht mehr mit verschiedenen Azure-Endpunkten funktionieren. Sie können dieses Issue mit einer der folgenden Methoden beheben:

  • Aktivieren Sie Dienstendpunkte in dem Subnetz, in dem der API Management-Dienst für Folgendes bereitgestellt wird:

    • Azure SQL (nur in der primären Region erforderlich, wenn der API Management-Dienst in mehreren Regionen bereitgestellt wird)
    • Azure Storage
    • Azure Event Hubs
    • Azure Key Vault (erforderlich, wenn API Management auf der stv2-Plattform bereitgestellt wird)

    Indem Sie Endpunkte direkt über das per API Management-Subnetz für diese Dienste aktivieren, können Sie das Microsoft Azure-Backbonenetzwerk verwenden, das optimales Routing für Dienstdatenverkehr ermöglicht. Bei Verwendung von Dienstendpunkten mit API Management mit Tunnelerzwingung erfolgt für den Datenverkehr der obigen Azure-Dienste keine Tunnelerzwingung. Für den übrigen Datenverkehr der API Management-Dienstabhängigkeiten wird die Tunnelerzwingung genutzt und er darf nicht verloren gehen. Stellen Sie sicher, dass Ihre Firewall oder virtuelle Appliance diesen Datenverkehr nicht blockiert, oder der API Management Dienst funktioniert möglicherweise nicht ordnungsgemäß.

    Hinweis

    Es wird dringend empfohlen, Dienstendpunkte direkt aus dem API Management-Subnetz zu abhängigen Diensten wie Azure SQL und Azure Storage, die sie unterstützen, zu aktivieren. Einige Organisationen haben jedoch möglicherweise Anforderungen, um die Tunnelung des gesamten Datenverkehrs aus dem API Management-Subnetz zu erzwingen. Stellen Sie in diesem Fall sicher, dass Sie Ihre Firewall oder virtuelle Appliance so konfigurieren, dass dieser Datenverkehr zulässig ist. Sie müssen den vollständigen IP-Adressbereich jedes abhängigen Diensts zulassen und diese Konfiguration auf dem neuesten Stand halten, wenn sich die Azure-Infrastruktur ändert. Bei Ihrem API Management-Dienst kann es auch zu Wartezeiten oder unerwarteten Timeouts aufgrund der erzwungenen Tunnelung dieses Netzwerkdatenverkehrs kommen.

  • Der gesamte Datenverkehr auf Steuerungsebene, der aus dem Internet an den Verwaltungsendpunkt Ihres API Management-Dienstes fließt, wird über einen spezifischen Satz mit IP-Adressen für eingehenden Datenverkehr geleitet, der von API Management gehostet wird und vom ApiManagement-Servicetag umfasst ist. Wenn der Datenverkehr getunnelt wird, werden die Antworten diesen eingehenden Quell-IPs nicht symmetrisch zugeordnet und die Verbindung mit dem Verwaltungsendpunkt geht verloren. Um diese Einschränkung zu umgehen, konfigurieren Sie eine benutzerdefinierte Route (UDR) für das ApiManagement-Diensttag, wobei der nächste Hoptyp auf „Internet“ festgelegt ist, um den Datenverkehr zurück zu Azure zu lenken.

    Hinweis

    API Management-Verwaltungsdatenverkehr zuzulassen, um eine lokale Firewall oder eine virtuelles Netzwerk-Gerät zu umgehen, gilt nicht als erhebliches Sicherheitsrisiko. Die empfohlene Konfiguration für Ihr API Management-Subnetz ermöglicht eingehenden Verwaltungsdatenverkehr auf Port 3443 nur aus dem Satz von Azure-IP-Adressen, die vom ApiManagement-Dienst-Tag umfasst sind. Die empfohlene UDR-Konfiguration gilt nur für den Rückgabepfad dieses Azure-Datenverkehrs.

  • (Externer VNet-Modus) Datenebenenverkehr für Clients, die versuchen, das API Management Gateway und Entwicklerportal aus dem Internet zu erreichen, werden auch standardmäßig aufgrund asymmetrischer Routings, die durch erzwungenes Tunneling eingeführt wurden, gelöscht. Konfigurieren Sie für jeden Client, der Zugriff erfordert, einen expliziten UDR mit dem nächsten Hop-Typ „Internet", um die Firewall oder die virtuelle Netzwerk-Appliance zu umgehen.

  • Lösen Sie für die anderen API Management-Dienstabhängigkeiten, für die Tunnelerzwingung genutzt wird, den Hostnamen auf, und stellen Sie eine Verbindung mit dem Endpunkt her. Dazu zählen unter anderem folgende Einstellungen:

    • Metriken und Systemüberwachung
    • Diagnose im Azure-Portal
    • SMTP-Relay
    • CAPTCHA des Entwicklerportals
    • Azure KMS-Server

Weitere Informationen finden Sie unter Konfigurationsaufgaben für virtuelle Netzwerke.

Häufige Probleme bei der Netzwerkkonfiguration

Dieser Abschnitt wurde verschoben. Siehe Konfigurationsreferenz für virtuelle Netzwerke.

Problembehandlung

Nicht erfolgreiche Erstbereitstellung des API Management-Diensts in einem Subnetz

  • Stellen Sie einen virtuellen Computer im selben Subnetz bereit.
  • Stellen Sie eine Verbindung mit dem virtuellen Computer her, und überprüfen Sie die Konnektivität mit den folgenden Ressourcen in Ihrem Azure-Abonnement:
    • Azure Storage-Blob
    • Azure SQL-Datenbank
    • Azure Storage-Tabelle
    • Azure Key Vault (für eine API Management-Instanz, die auf der stv2 Plattform gehostet wird)

Wichtig

Entfernen Sie nach der Konnektivitätsüberprüfung alle Ressourcen im Subnetz, bevor Sie API Management im Subnetz bereitstellen (erforderlich, wenn API Management auf der Plattform stv1 gehostet wird).

Überprüfen des Netzwerkstatus

  • Nach dem Bereitstellen von API Management im Subnetz können Sie im Portal die Konnektivität Ihrer Instanz mit Abhängigkeiten – etwa Azure Storage – überprüfen.

  • Wählen Sie im Portal im linken Menü unter Bereitstellung und Infrastruktur die Option Netzwerk>Netzwerkstatus aus.

    Screenshot der Überprüfung des Netzwerkkonnektivitätsstatus im Portal

Filtern BESCHREIBUNG
Erforderlich Wählen Sie diese Option aus, um die Konnektivität erforderlicher Azure-Dienste für API Management zu überprüfen. Ein Fehler weist darauf hin, dass die Instanz keine Kernvorgänge zum Verwalten von APIs durchführen kann.
Optional Wählen Sie diese Option aus, um die Konnektivität optionaler Dienste zu überprüfen. Ein Fehler gibt nur an, dass die spezifische Funktion nicht ausgeführt wird (z. B. SMTP). Ein Fehler kann zu einer Beeinträchtigung bei der Verwendung und Überwachung der API Management-Instanz sowie bei der Erfüllung der verbindlichen SLA führen.

Wählen Sie Folgendes aus, um Konnektivitätsprobleme zu beheben:

  • Metriken zum Überprüfen der Metriken zum Netzwerkkonnektivitätsstatus

  • Diagnose zum Ausführen einer Überprüfung des virtuellen Netzwerks über einen angegebenen Zeitraum

Sehen Sie sich zum Beheben von Konnektivitätsproblemen die Netzwerkkonfigurationseinstellungen an, und korrigieren Sie die entsprechenden Netzwerkeinstellungen.

Inkrementelle Updates

Wenn Sie Änderungen an Ihrem Netzwerk vornehmen, sollten Sie sich mithilfe der NetworkStatus-API vergewissern, dass der API Management-Dienst weiterhin Zugriff auf wichtige Ressourcen hat. Der Konnektivitätsstatus sollte alle 15 Minuten aktualisiert werden.

Anwendung einer Netzwerkkonfigurationsänderung über das Portal auf die API Management-Instanz:

  1. Wählen Sie im linken Menü für Ihre Instanz unter Bereitstellung und Infrastruktur die Option Netzwerk>Virtuelles Netzwerk aus.
  2. Netzwerkkonfiguration anwenden auswählen.

Eine API Management-Instanz, die auf der stv1-Computeplattform gehostet wird, reserviert bei der Bereitstellung in einem Resource Manager-VNet-Subnetz das Subnetz, indem ein Ressourcennavigationslink erstellt wird. Wenn das Subnetz bereits eine Ressource von einem anderen Hersteller enthält, tritt bei der Bereitstellung ein Fehler auf. Wenn Sie einen API Management-Dienst löschen oder in ein anderes Subnetz verschieben, wird der Ressourcennavigationslink ebenfalls entfernt.

Herausforderungen beim erneuten Zuweisen einer API Management-Instanz zum vorherigen Subnetz

  • VNet lock - Beim Verschieben einer API Management-Instanz zurück in ihr ursprüngliches Subnetz ist aufgrund der VNet-Sperre, die bis zu sechs Stunden dauert, möglicherweise keine sofortige Neuzuweisung möglich. Wenn das ursprüngliche Subnetz über anderestv1 plattformbasierte API Management-Dienste (clouddienstbasiert) verfügt, müssen Sie diese löschen und sechs Stunden wartenstv2, bevor Sie einen plattformbasierten Dienst im selben Subnetz bereitstellen können.
  • Ressourcengruppen-Sperre - Ein weiteres Szenario,das berücksichtigt werden muss, ist das Vorhandensein einer Bereichssperre auf Ressourcengruppenebene oder höher, wodurch Ressourcennavigationslinks nicht gelöscht werden können. Um dieses Problem zu lösen, heben Sie die Bereichssperre auf und warten ca. 4–6 Stunden, bis der API Management-Dienst die Verbindung mit dem ursprünglichen Subnetz getrennt hat, bevor Sie die Sperre aufheben, um die Bereitstellung im gewünschten Subnetz zu ermöglichen.

Problembehandlung bei der Verbindung mit Microsoft Graph in einem VNet

Netzwerkkonnektivität mit Microsoft Graph ist für Features erforderlich, einschließlich der Benutzeranmeldung beim Entwicklerportal mithilfe des Microsoft Entra-Identitätsanbieters.

So beheben Sie die Konnektivitätsprobleme mit Microsoft Graph über ein VNet:

  • Stellen Sie sicher, dass NSG und andere Netzwerkregeln für ausgehende Verbindungen von Ihrer API-Verwaltungsinstanz zu Microsoft Graph konfiguriert sind (mit dem AzureActiveDirectory-Diensttag ).

  • Stellen Sie sicher, dass die DNS-Auflösung und der Netzwerkzugriff graph.microsoft.com über das VNet erfolgen. Stellen Sie z. B. einen neuen virtuellen Computer im VNet bereit. Stellen Sie eine Verbindung damit her, und versuchen Sie, eine Verbindung mit einem Browser herzustellen oder cURL, PowerShell oder andere Tools zu GET https://graph.microsoft.com/v1.0/$metadata verwenden.

Nächste Schritte

Weitere Informationen: