Bereitstellen Ihrer Azure API Management-Instanz in einem virtuellen Netzwerk: externer 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 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.

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.

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.

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.

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.

     

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)

  

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.

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

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.

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.

• Eine Anleitung zum Einrichten eines benutzerdefinierten DNS-Servers, einschließlich der Weiterleitung für von Azure bereitgestellte Hostnamen, finden Sie unter Namensauflösung für Ressourcen in virtuellen Azure-Netzwerken.
• Ausgehender Netzwerkzugriff an Port 53 wird für die Kommunikation mit DNS-Servern benötigt. Weitere Informationen zu den Einstellungen finden Sie unter Referenz zur Konfiguration virtueller Netzwerke.

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)

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

  

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.

Ressourcennavigationslinks

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:

• Konfigurationsreferenz für virtuelle Netzwerke
• Verbindung eines virtuellen Netzes mit dem Backend über VPN Gateway
• Herstellen einer Verbindung mit einem virtuellen Netzwerk in verschiedenen Bereitstellungsmodellen
• Debuggen von APIs mit der Anforderungsablaufverfolgung
• Virtual Network – häufig gestellte Fragen
• Diensttags