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

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:

• Verwendung eines virtuellen Netzwerks mit Azure API Management
• Anforderungen an virtuelle Netzwerkressourcen für die API Management-Einschleusung in ein virtuelles Netzwerk

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

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.

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 von Azure PowerShell. Informationen zum Migrieren zum Az PowerShell-Modul finden Sie unter Migrieren von Azure PowerShell von AzureRM zum Az-Modul.

Wichtig

Änderungen an der Infrastruktur Ihres API-Verwaltungsdiensts (z. B. Konfigurieren von benutzerdefinierten Domänen, Hinzufügen von Zertifizierungsstellenzertifikaten, Skalierung, Konfiguration virtueller Netzwerke, Änderungen der Verfügbarkeitszone und Regionszufügungen) können je nach Dienstebene und Größe der Bereitstellung 15 Minuten oder länger dauern. Bei Instanzen mit einer größeren Anzahl von Skalierungseinheiten oder einer Konfiguration mit mehreren Regionen können Sie mit längeren Zeiten rechnen. Laufende Änderungen an der API-Verwaltung werden sorgfältig ausgeführt, um Kapazität und Verfügbarkeit zu bewahren.

Während der Dienst aktualisiert wird, können andere Änderungen an der Dienstinfrastruktur nicht vorgenommen werden. Sie können jedoch APIs, Produkte, Richtlinien und Benutzereinstellungen konfigurieren. Der Dienst erlebt keine Ausfallzeiten des Gateways, und die API-Verwaltung wird weiterhin API-Anforderungen ohne Unterbrechung (mit Ausnahme der Entwicklerebene) dienstieren.

Voraussetzungen

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

• Eine API Management-Instanz. Weitere Informationen finden Sie unter Erstellen einer neuen Azure API Management-Dienstinstanz.

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

• (Optional) Eine öffentliche IPv4-Adresse mit Standard-SKU.

  Wichtig

  • Ab Mai 2024 wird keine öffentliche IP-Adressressource mehr benötigt, wenn eine API Management-Instanz in einem VNet im internen Modus bereitgestellt (injiziert) oder die interne VNet-Konfiguration zu einem neuen Subnetz migriert wird. Im externen VNet-Modus ist die Angabe einer öffentlichen IP-Adresse optional. Wenn Sie keine angeben, wird automatisch eine von Azure verwaltete öffentliche IP-Adresse konfiguriert und für Runtime-API-Datenverkehr verwendet. Geben Sie die öffentliche IP-Adresse nur an, wenn Sie die öffentliche IP-Adresse, die für eingehende oder ausgehende Kommunikation mit dem Internet verwendet wird, besitzen und steuern möchten.

  • Falls angegeben muss die IP-Adresse 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. Im Allgemeinen sollten Sie denselben DNS-Namen wie Ihre API Management-Instanz verwenden. Wenn Sie dies ändern, stellen Sie Ihre Instanz erneut bereit, sodass die neue DNS-Bezeichnung verwendet wird.

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

• Konfigurieren Sie bei API Management-Bereitstellungen in mehreren Regionen die virtuellen Netzwerkressourcen für jeden Speicherort separat.

VNet-Verbindung aktivieren

Aktivieren der VNet-Konnektivität über das Azure-Portal

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 Virtuelle Netzwerk und Subnetz 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.
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 die Option Speichern aus.

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.

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.

Aktivieren der Konnektivität mithilfe einer Ressourcen-Manager-Vorlage

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

  

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.

Richtung	Quelldiensttag	Quellportbereiche	Zieldiensttag	Zielportbereiche	Protokoll	Aktion	Zweck	VNet-Typ
Eingehend	Internet	*	VirtualNetwork	[80], 443	TCP	Zulassen	Kommunikation zwischen Clients und API Management	Nur extern
Eingehend	ApiManagement	*	VirtualNetwork	3443	TCP	Zulassen	Verwaltungsendpunkt für Azure-Portal und PowerShell	Extern & Intern
Eingehend	Azure-Lastenausgleicher	*	VirtualNetwork	6390	TCP	Zulassen	Lastenausgleich von Azure-Infrastruktur	Extern & Intern
Eingehend	AzureTrafficManager	*	VirtualNetwork	443	TCP	Zulassen	Azure Traffic Manager Routing für die Bereitstellung mit mehreren Regionen	Nur extern
Ausgehend	VirtualNetwork	*	Internet	80	TCP	Zulassen	Validierung und Verwaltung von von Microsoft verwalteten und vom Kunden verwalteten Zertifikaten	Extern & Intern
Ausgehend	VirtualNetwork	*	Lagerung	443	TCP	Zulassen	Abhängigkeit von Azure Storage für Kerndienstfunktionen	Extern & Intern
Ausgehend	VirtualNetwork	*	SQL	1433	TCP	Zulassen	Zugriff auf Azure SQL-Endpunkte für Kerndienstfunktionen	Extern & Intern
Ausgehend	VirtualNetwork	*	AzureKeyVault	443	TCP	Zulassen	Zugriff auf Azure Key Vault für Kerndienstfunktionen	Extern & Intern
Ausgehend	VirtualNetwork	*	AzureMonitor	1886, 443	TCP	Zulassen	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 Hostnamen, der für seine Dienstendpunkte konfiguriert ist. Zu diesen Endpunkten gehören:

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

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
Einguss	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:

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.

Routenplanung

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 (ein Dienst zur sicheren Verwaltung kryptografischer Schlüssel)

  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 (ein Dienst zur sicheren Verwaltung kryptografischer Schlüssel)

Wichtig

Entfernen Sie nach der Überprüfung der Konnektivität alle Ressourcen im Subnetz, bevor Sie die API-Verwaltung im Subnetz bereitstellen.

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

  

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

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

• VNet-Sperre: Beim Verschieben einer API Management-Instanz zurück in ihr ursprüngliches Subnetz ist aufgrund der VNet-Sperre, die bis zu einer Stunde dauert, möglicherweise keine sofortige Neuzuweisung möglich.
• 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.

Verwandte Inhalte

Weitere Informationen:

• Konfigurationsreferenz für virtuelle Netzwerke
• VNet Häufig gestellte Fragen
• Managing DNS Records (Verwalten von DNS-Einträgen)