Dela via

Distribuera din Azure API Management-instans till ett virtuellt nätverk – externt läge

  • Artikel

GÄLLER FÖR: Utvecklare | Premie

Azure API Management kan distribueras (matas in) i ett virtuellt Azure-nätverk (VNet) för att få åtkomst till serverdelstjänster i nätverket. För VNet-anslutningsalternativ, krav och överväganden, se:

Den här artikeln beskriver hur du konfigurerar VNet-anslutning för din API Management-instans i externt läge, där utvecklarportalen, API-gatewayen och andra API Management-slutpunkter är tillgängliga från det offentliga Internet, och serverdelstjänster finns i nätverket.

Ansluta till ett externt virtuellt nätverk

Konfigurationer som är specifika för det interna läget, där slutpunkterna endast är tillgängliga i det virtuella nätverket, finns i Distribuera din Azure API Management-instans till ett virtuellt nätverk – internt läge.

Kommentar

Vi rekommenderar att du använder Azure Az PowerShell-modulen för att interagera med Azure. Se Installera Azure PowerShell för att komma igång. Information om hur du migrerar till Az PowerShell-modulen finns i artikeln om att migrera Azure PowerShell från AzureRM till Az.

Förutsättningar

Granska nätverksresurskraven för API Management-inmatning i ett virtuellt nätverk innan du börjar.

Vissa förutsättningar varierar beroende på vilken version (stv2 eller stv1) av beräkningsplattformen som är värd för din API Management-instans.

Dricks

När du använder portalen för att skapa eller uppdatera nätverksanslutningen för en befintlig API Management-instans finns instansen på beräkningsplattformen stv2 .

  • Ett virtuellt nätverk och undernät i samma region och prenumeration som din API Management-instans.

    • Undernätet som används för att ansluta till API Management-instansen kan innehålla andra Azure-resurstyper.
    • Inga delegeringar ska vara aktiverade i undernätet. Inställningen Delegera undernät till en tjänst för undernätet ska vara inställd på Ingen.

  • En nätverkssäkerhetsgrupp som är kopplad till undernätet ovan. En nätverkssäkerhetsgrupp (NSG) krävs för att uttryckligen tillåta inkommande anslutningar, eftersom lastbalanseraren som används internt av API Management är säker som standard och avvisar all inkommande trafik. Specifik konfiguration finns i Konfigurera NSG-regler senare i den här artikeln.

  • I vissa scenarier aktiverar du tjänstslutpunkter i undernätet till beroende tjänster som Azure Storage eller Azure SQL. Mer information finns i Tvinga tunneltrafik till lokal brandvägg med hjälp av ExpressRoute eller virtuell nätverksinstallation senare i den här artikeln.

  • (Valfritt) En offentlig IPv4-adress för Standard SKU.

    Viktigt!

    • Från och med maj 2024 behövs inte längre en offentlig IP-adressresurs när du distribuerar (matar in) en API Management-instans i ett virtuellt nätverk i internt läge eller migrerar den interna VNet-konfigurationen till ett nytt undernät. I externt VNet-läge är det valfritt att ange en offentlig IP-adress. Om du inte anger en så konfigureras och används en Azure-hanterad offentlig IP-adress automatiskt för körnings-API-trafik. Ange endast den offentliga IP-adressen om du vill äga och kontrollera den offentliga IP-adress som används för inkommande eller utgående kommunikation till Internet.

    • Om det anges måste IP-adressen finnas i samma region och prenumeration som API Management-instansen och det virtuella nätverket.

    • När du skapar en offentlig IP-adressresurs kontrollerar du att du tilldelar den en DNS-namnetikett . I allmänhet bör du använda samma DNS-namn som din API Management-instans. Om du ändrar den distribuerar du om instansen så att den nya DNS-etiketten tillämpas.

    • För bästa nätverksprestanda rekommenderar vi att du använder standardinställningen Routning: Microsoft-nätverk.

    • När du skapar en offentlig IP-adress i en region där du planerar att aktivera zonredundans för din API Management-instans konfigurerar du inställningen Zonredundant .

    • Värdet för IP-adressen tilldelas som den virtuella offentliga IPv4-adressen för API Management-instansen i den regionen.

  • För distributioner av API Management för flera regioner konfigurerar du virtuella nätverksresurser separat för varje plats.

Aktivera VNet-anslutning

Aktivera VNet-anslutning med hjälp av Azure Portal (stv2 beräkningsplattform)

  1. Gå till Azure Portal för att hitta din API-hanteringsinstans. Sök efter och välj API Management-tjänster.

  2. Välj din API Management-instans.

  3. Välj Nätverk.

  4. Välj den externa åtkomsttypen. Välj VNet i Azure Portal.

  5. I listan över platser (regioner) där DIN API Management-tjänst etableras:

    1. Välj en plats.
    2. Välj Virtuellt nätverk, Undernät och (valfritt) IP-adress.

    • Listan över virtuella nätverk fylls i med resource manager-virtuella nätverk som är tillgängliga i dina Azure-prenumerationer, konfigurerade i den region som du konfigurerar.

      VNet-inställningar i portalen.

  6. Välj Använd. Sidan Nätverk för DIN API Management-instans uppdateras med dina nya VNet- och undernätsalternativ.

  7. Fortsätt att konfigurera VNet-inställningar för de återstående platserna för din API Management-instans.

  8. I det övre navigeringsfältet väljer du Spara.

Det kan ta 15 till 45 minuter att uppdatera API Management-instansen. Instanser på utvecklarnivån har stilleståndstid under processen. Instanser på Premium-nivån har inte stilleståndstid under processen.

Aktivera anslutning med hjälp av en Resource Manager-mall (stv2 beräkningsplattform)

  • Azure Resource Manager-mall (API-version 2021-08-01)

    Knapp för att distribuera Resource Manager-mallen till Azure.

Aktivera anslutning med hjälp av Azure PowerShell-cmdletar (stv1 plattform)

Skapa eller uppdatera en API Management-instans i ett virtuellt nätverk.

Konfigurera NSG-regler

Konfigurera anpassade nätverksregler i API Management-undernätet för att filtrera trafik till och från din API Management-instans. Vi rekommenderar följande minsta NSG-regler för att säkerställa korrekt drift och åtkomst till din instans. Granska din miljö noggrant för att fastställa fler regler som kan behövas.

Viktigt!

Beroende på din användning av cachelagring och andra funktioner kan du behöva konfigurera ytterligare NSG-regler utöver minimireglerna i följande tabell. Detaljerade inställningar finns i Referens för konfiguration av virtuellt nätverk.

  • I de flesta scenarier använder du de angivna tjänsttaggar i stället för tjänstens IP-adresser för att ange nätverkskällor och mål.
  • Ange prioriteten för dessa regler som är högre än standardreglernas.
Käll-/målportar Riktning Transportprotokoll Tjänsttaggar
Källa/mål		 Syfte VNet-typ
* / [80], 443 Inkommande TCP Internet/VirtualNetwork Klientkommunikation till API Management Endast externt
* / 3443 Inkommande TCP ApiManagement/VirtualNetwork Hanteringsslutpunkt för Azure Portal och PowerShell Extern och intern
* / 6390 Inkommande TCP AzureLoadBalancer/VirtualNetwork Lastbalanserare för Azure-infrastruktur Extern och intern
* / 443 Inkommande TCP AzureTrafficManager/VirtualNetwork Azure Traffic Manager-routning för distribution i flera regioner Endast externt
* / 443 Utgående TCP VirtualNetwork/Storage Beroende av Azure Storage för grundläggande tjänstfunktioner Extern och intern
* / 1433 Utgående TCP VirtualNetwork/SQL Åtkomst till Azure SQL-slutpunkter för grundläggande tjänstfunktioner Extern och intern
* / 443 Utgående TCP VirtualNetwork/AzureKeyVault Åtkomst till Azure Key Vault för grundläggande tjänstfunktioner Extern och intern
* / 1886, 443 Utgående TCP VirtualNetwork/AzureMonitor Publicera diagnostikloggar och mått, Resource Health och Application Insights Extern och intern

Ansluta till en webbtjänst som finns i ett virtuellt nätverk

När du har anslutit API Management-tjänsten till det virtuella nätverket kan du komma åt serverdelstjänster i den precis som du gör med offentliga tjänster. När du skapar eller redigerar ett API anger du den lokala IP-adressen eller värdnamnet (om en DNS-server har konfigurerats för det virtuella nätverket) för webbtjänsten i fältet Webbtjänst-URL .

Lägga till API från VNet

Anpassad DNS-serverkonfiguration

I externt VNet-läge hanterar Azure DNS som standard. Du kan också konfigurera en anpassad DNS-server.

API Management-tjänsten är beroende av flera Azure-tjänster. När API Management finns i ett virtuellt nätverk med en anpassad DNS-server måste den matcha värdnamnen för dessa Azure-tjänster.

  • Vägledning om anpassad DNS-konfiguration, inklusive vidarebefordran för Värdnamn som tillhandahålls av Azure, finns i Namnmatchning för resurser i virtuella Azure-nätverk.
  • Utgående nätverksåtkomst på porten 53 krävs för kommunikation med DNS-servrar. Fler inställningar finns i Referens för konfiguration av virtuellt nätverk.

Viktigt!

Om du planerar att använda en anpassad DNS-server för det virtuella nätverket konfigurerar du den innan du distribuerar en API Management-tjänst till den. Annars måste du uppdatera API Management-tjänsten varje gång du ändrar DNS-servrarna genom att köra åtgärden Tillämpa nätverkskonfiguration.

Routning

  • En belastningsbalanserad offentlig IP-adress (VIP) är reserverad för att ge åtkomst till API Management-slutpunkter och resurser utanför det virtuella nätverket.
    • Offentlig VIP finns på bladet Översikt/Essentials i Azure Portal.

Mer information och överväganden finns i IP-adresser för Azure API Management.

VIP- och DIP-adresser

Dip-adresser (Dynamic IP) tilldelas till varje underliggande virtuell dator i tjänsten och används för att komma åt slutpunkter och resurser i det virtuella nätverket och i peer-kopplade virtuella nätverk. API Management-tjänstens offentliga virtuella IP-adress (VIP) används för åtkomst till offentliga resurser.

Om IP-begränsningen visar säkra resurser i det virtuella nätverket eller peer-kopplade virtuella nätverk rekommenderar vi att du anger hela undernätsintervallet där API Management-tjänsten distribueras för att bevilja eller begränsa åtkomsten från tjänsten.

Läs mer om den rekommenderade undernätsstorleken.

Tvinga tunneltrafik till lokal brandvägg med expressroute eller virtuell nätverksinstallation

Med tvingad tunneltrafik kan du omdirigera eller "tvinga" all Internetbunden trafik från undernätet tillbaka till den lokala miljön för inspektion och granskning. Vanligtvis konfigurerar och definierar du din egen standardväg (0.0.0.0/0), vilket tvingar all trafik från API Management-undernätet att flöda genom en lokal brandvägg eller till en virtuell nätverksinstallation. Det här trafikflödet bryter anslutningen med API Management, eftersom utgående trafik antingen blockeras lokalt eller NAT'd till en oigenkännlig uppsättning adresser som inte längre fungerar med olika Azure-slutpunkter. Du kan lösa det här problemet via följande metoder:

  • Aktivera tjänstslutpunkter i undernätet där API Management-tjänsten distribueras för:

    • Azure SQL (krävs endast i den primära regionen om API Management-tjänsten distribueras till flera regioner)
    • Azure Storage
    • Azure Event Hubs
    • Azure Key Vault (krävs när API Management distribueras på stv2 plattformen)

    Genom att aktivera slutpunkter direkt från API Management-undernätet till dessa tjänster kan du använda Microsoft Azure-stamnätverket, vilket ger optimal routning för tjänsttrafik. Om du använder tjänstslutpunkter med en framtvingad API-hantering i tunneltrafik, framtvingas inte trafik för föregående Azure-tjänster. Den andra API Management-tjänstens beroendetrafik förblir dock tvingad tunneltrafik. Kontrollera att brandväggen eller den virtuella installationen inte blockerar den här trafiken eller att API Management-tjänsten kanske inte fungerar korrekt.

    Kommentar

    Vi rekommenderar starkt att du aktiverar tjänstslutpunkter direkt från API Management-undernätet till beroende tjänster som Azure SQL och Azure Storage som stöder dem. Vissa organisationer kan dock ha krav på att tvinga tunneltrafik från API Management-undernätet. I det här fallet kontrollerar du att du konfigurerar brandväggen eller den virtuella installationen så att den tillåter den här trafiken. Du måste tillåta det fullständiga IP-adressintervallet för varje beroende tjänst och hålla konfigurationen uppdaterad när Azure-infrastrukturen ändras. Din API Management-tjänst kan också få svarstider eller oväntade timeouter på grund av den här nätverkstrafikens framtvingade tunneltrafik.

  • All kontrollplanstrafik från Internet till hanteringsslutpunkten för DIN API Management-tjänst dirigeras via en specifik uppsättning inkommande IP-adresser, som hanteras av API Management, som omfattas av apiManagement-tjänsttaggen. När trafiken är tvingad tunneltrafik mappas inte svaren symmetriskt tillbaka till dessa inkommande käll-IP-adresser och anslutningen till hanteringsslutpunkten går förlorad. Du kan lösa den här begränsningen genom att konfigurera en användardefinierad väg (UDR) för tjänsttaggen ApiManagement med nästa hopptyp inställd på "Internet" för att styra trafiken tillbaka till Azure.

    Kommentar

    Att tillåta API Management-hanteringstrafik att kringgå en lokal brandvägg eller virtuell nätverksinstallation anses inte vara en betydande säkerhetsrisk. Den rekommenderade konfigurationen för ditt API Management-undernät tillåter endast inkommande hanteringstrafik på port 3443 från den uppsättning Azure IP-adresser som omfattas av taggen ApiManagement-tjänst. Den rekommenderade UDR-konfigurationen är endast för retursökvägen för den här Azure-trafiken.

  • (Externt VNet-läge) Dataplanstrafik för klienter som försöker nå API Management-gatewayen och utvecklarportalen från Internet tas också bort som standard på grund av asymmetrisk routning som introduceras genom tvingad tunneltrafik. För varje klient som kräver åtkomst konfigurerar du en explicit UDR med nästa hopptyp "Internet" för att kringgå brandväggen eller den virtuella nätverksinstallationen.

  • För andra beroenden för API Management-tjänsten i tvingad tunnel löser du värdnamnet och kontaktar slutpunkten. Dessa kan vara:

    • Mått och hälsoövervakning
    • Azure Portal diagnostik
    • SMTP-relä
    • CAPTCHA för utvecklarportalen
    • Azure KMS-server

Mer information finns i Referens för konfiguration av virtuellt nätverk.

Vanliga problem med nätverkskonfiguration

Det här avsnittet har flyttats. Se Referens för konfiguration av virtuellt nätverk.

Felsökning

Misslyckad inledande distribution av API Management-tjänsten till ett undernät

  • Distribuera en virtuell dator till samma undernät.
  • Anslut till den virtuella datorn och verifiera anslutningen till någon av följande resurser i din Azure-prenumeration:
    • Azure Storage-blob
    • Azure SQL Database
    • Azure Storage-tabell
    • Azure Key Vault (för en API Management-instans som finns på stv2 plattformen)

Viktigt!

När du har verifierat anslutningen tar du bort alla resurser i undernätet innan du distribuerar API Management till undernätet (krävs när API Management finns på stv1 plattformen).

Verifiera nätverksstatus

  • När du har distribuerat API Management till undernätet använder du portalen för att kontrollera anslutningen för din instans till beroenden, till exempel Azure Storage.

  • I portalen går du till den vänstra menyn under Distribution och infrastruktur och väljer Nätverksnätverksstatus>.

    Skärmbild av verifiera nätverksanslutningsstatus i portalen.

Filter beskrivning
Krävs Välj att granska den nödvändiga Azure-tjänstanslutningen för API Management. Felet indikerar att instansen inte kan utföra kärnåtgärder för att hantera API:er.
Valfritt Välj för att granska den valfria tjänstanslutningen. Felet anger bara att den specifika funktionen inte fungerar (till exempel SMTP). Fel kan leda till försämring i användning och övervakning av API Management-instansen och tillhandahålla det incheckade serviceavtalet.

Om du vill felsöka anslutningsproblem väljer du:

  • Mått – för att granska statusmått för nätverksanslutning

  • Diagnostisera – för att köra ett virtuellt nätverksverifierare under en angiven tidsperiod

Du kan åtgärda anslutningsproblem genom att granska nätverkskonfigurationsinställningar och åtgärda nödvändiga nätverksinställningar.

Inkrementella uppdateringar

När du gör ändringar i nätverket kan du läsa NetworkStatus API för att kontrollera att API Management-tjänsten inte har förlorat åtkomsten till kritiska resurser. Anslutningsstatusen bör uppdateras var 15:e minut.

Så här tillämpar du en nätverkskonfigurationsändring på API Management-instansen med hjälp av portalen:

  1. I den vänstra menyn för din instans går du till Distribution och infrastruktur och väljer Nätverk>virtuellt nätverk.
  2. Välj Använd nätverkskonfiguration.

En API Management-instans som finns på beräkningsplattformen, när den stv1 distribueras till ett Resource Manager VNet-undernät, reserverar undernätet genom att skapa en resursnavigeringslänk. Om undernätet redan innehåller en resurs från en annan provider misslyckas distributionen. På samma sätt tas resursnavigeringslänken bort när du tar bort en API Management-tjänst eller flyttar den till ett annat undernät.

Utmaningar som uppstår vid omtilldelning av API Management-instans till föregående undernät

  • VNet-lås – När du flyttar tillbaka en API Management-instans till det ursprungliga undernätet kanske det inte går att omtilldela omedelbart på grund av VNet-låset, vilket tar upp till en timme att ta bort. Om det ursprungliga undernätet har andra stv1 plattformsbaserade API Management-tjänster (molntjänstbaserade) är det nödvändigt att ta bort dem och vänta för att distribuera en stv2 plattformsbaserad tjänst i samma undernät.
  • Resursgruppslås – Ett annat scenario att tänka på är förekomsten av ett omfångslås på resursgruppsnivå eller högre, vilket hindrar borttagningsprocessen för resursnavigeringslänken. Lös problemet genom att ta bort omfångslåset och tillåta en fördröjning på cirka 4–6 timmar för API Management-tjänsten att ta bort länken från det ursprungliga undernätet innan låset tas bort, vilket aktiverar distributionen till önskat undernät.

Felsöka anslutning till Microsoft Graph inifrån ett virtuellt nätverk

Nätverksanslutning till Microsoft Graph krävs för funktioner som användarinloggning till utvecklarportalen med hjälp av Microsoft Entra-identitetsprovidern.

Så här felsöker du anslutningen till Microsoft Graph inifrån ett virtuellt nätverk:

  • Se till att NSG och andra nätverksregler har konfigurerats för utgående anslutning från DIN API Management-instans till Microsoft Graph (med hjälp av tjänsttaggen AzureActiveDirectory ).

  • Kontrollera DNS-matchning och nätverksåtkomst till graph.microsoft.com från det virtuella nätverket. Du kan till exempel etablera en ny virtuell dator i det virtuella nätverket, ansluta till den och försöka GET https://graph.microsoft.com/v1.0/$metadata från en webbläsare eller använda cURL, PowerShell eller andra verktyg.

Nästa steg

Läs mer om: