Freigeben über

Bereitstellen Ihrer Azure API Management-Instanz in einem virtuellen Netzwerk: externer 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 VNet-Konnektivität für Ihre API Management-Instanz im externen Modus einrichten, in dem das Entwicklerportal, das API-Gateway und andere API Management-Endpunkte über das öffentliche Internet zugänglich sind, und Back-End-Dienste befinden sich in dem Netzwerk.

Herstellen einer Verbindung mit dem externen VNet

Spezifische Konfigurationen für den internen Modus, bei denen die Endpunkte nur innerhalb des VNet zugänglich sind, finden Sie unter Bereitstellen Ihrer Azure API Management-Instanz in einem virtuellen Netzwerk: interner 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.

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.

  • (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 von VNet-Konnektivität über das Azure-Portal (stv2 Computeplattform)

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

  4. Wählen Sie den externen Zugriffstyp aus. Auswählen eines VNet im Azure-Portal.

  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 (optional) 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.

      VNet-Einstellungen im Portal.

  6. Wählen Sie Übernehmen. Die Seite 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.

Es kann zwischen 15 und 45 Minuten dauern, bis die API Management-Instanz aktualisiert wurde. Instanzen auf der Entwicklerebene haben während des Prozesses Ausfallzeiten. Instanzen auf der Premium-Ebene haben während des Prozesses keine Ausfallzeiten.

Konnektivität mit einer Resource Manager-Vorlage (stv2-Compute-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

Herstellen einer Verbindung mit einem innerhalb eines virtuellen Netzwerk gehosteten Webdienst

Nachdem Sie Ihren API Management-Dienst mit dem VNet verbunden haben, können Sie auf Back-End-Dienste innerhalb des VNet auf die gleiche Weise zugreifen wie auf öffentliche Dienste. Geben Sie beim Erstellen oder Bearbeiten einer API die lokale IP-Adresse oder den Hostnamen Ihres Webdiensts (falls ein DNS-Server für das VNet konfiguriert wurde) im Feld Webdienst-URL ein.

API über VNet hinzufügen

Setup eines benutzerdefinierten DNS-Servers

Im externen VNet-Modus wird das DNS standardmäßig von Azure verwaltet. Optional können Sie einen benutzerdefinierten DNS-Server konfigurieren.

Der API Management-Dienst hängt von mehreren Azure-Diensten ab. Wenn API Management in einem VNet mit einem benutzerdefiniertem DNS-Server gehostet wird, muss es die Hostnamen dieser Azure-Dienste auflösen können.

Wichtig

Wenn Sie benutzerdefinierte DNS-Server für das VNet verwenden möchten, richten Sie diesen vor dem Bereitstellen eines API Management-Diensts ein. Andernfalls müssen Sie den API Management-Dienst jedes Mal aktualisieren, wenn Sie die DNS-Server durch Ausführen des Vorgangs „Netzwerkkonfiguration anwenden“ ändern.

Routing

  • Eine öffentliche IP-Adresse mit Lastenausgleich (VIP) ist reserviert, um Zugriff auf die API Management-Endpunkte und Ressourcen außerhalb des VNet zu ermöglichen.
    • Die öffentliche IP-Adresse finden Sie auf dem Blatt Übersicht/Essentials 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.

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-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. Wenn das ursprüngliche Subnetz über andere auf der stv1-Plattform basierende API Management-Dienste (clouddienstbasiert) verfügt, müssen Sie diese löschen und warten, bevor Sie einen auf der stv2-Plattform basierenden 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: