Konfiguration av Application Gateway-infrastruktur
Azure Application Gateway-infrastrukturen innehåller det virtuella nätverket, undernät, nätverkssäkerhetsgrupper (NSG:er) och användardefinierade vägar (UDR).
Virtuellt nätverk och dedikerat undernät
En programgateway är en dedikerad distribution i ditt virtuella nätverk. I det virtuella nätverket krävs ett dedikerat undernät för programgatewayen. Du kan ha flera instanser av en specifik Application Gateway-distribution i ett undernät. Du kan också distribuera andra programgatewayer i undernätet. Men du kan inte distribuera någon annan resurs i Application Gateway-undernätet. Du kan inte blanda V1- och v2 Application Gateway-SKU:er i samma undernät.
Kommentar
Principer för tjänstslutpunkter för virtuella nätverk stöds för närvarande inte i ett Application Gateway-undernät.
Storleken på undernätet
Application Gateway använder en privat IP-adress per instans, plus en annan privat IP-adress om en privat klientdels-IP har konfigurerats.
Azure reserverar även fem IP-adresser i varje undernät för internt bruk. De är de första fyra adresserna och de sista IP-adresserna. Överväg till exempel 15 Application Gateway-instanser utan privat klientdels-IP. Du behöver minst 20 IP-adresser för det här undernätet. Du behöver 5 för internt bruk och 15 för Application Gateway-instanserna.
Överväg ett undernät som har 27 Application Gateway-instanser och en IP-adress för en privat klientdels-IP. I det här fallet behöver du 33 IP-adresser. Du behöver 27 för Application Gateway-instanserna, en för den privata klientdelen och 5 för intern användning.
Application Gateway (Standard eller WAF SKU) har stöd för upp till 32 instanser (32 IP-instansadresser + 1 privat ip-konfiguration på klientdelen + 5 reserverade Azure-instanser). Vi rekommenderar en minsta undernätsstorlek på /26.
Application Gateway (Standard_v2 eller WAF_v2 SKU) kan ha stöd för upp till 125 instanser (125 instans-IP-adresser + 1 konfiguration för privat IP-adress på klientdelen + 5 reserverade Azure-instanser). Vi rekommenderar en minsta undernätsstorlek på /24.
För att fastställa den tillgängliga kapaciteten för ett undernät som har befintliga programgatewayer etablerade tar du storleken på undernätet och subtraherar de fem reserverade IP-adresserna för det undernät som är reserverat av plattformen. Ta sedan varje gateway och subtrahera det maximala antalet instanser. För varje gateway som har en privat IP-klientdelskonfiguration subtraherar du ytterligare en IP-adress per gateway.
Så här beräknar du till exempel den tillgängliga adresseringen för ett undernät med tre gatewayer av olika storlekar:
- Gateway 1: Högst 10 instanser. Använder en privat IP-klientdels-IP-konfiguration.
- Gateway 2: Högst 2 instanser. Ingen privat IP-konfiguration för klientdelen.
- Gateway 3: Högst 15 instanser. Använder en privat IP-klientdels-IP-konfiguration.
- Undernätsstorlek: /24
- Undernätsstorlek /24 = 256 IP-adresser – 5 reserverade från plattformen = 251 tillgängliga adresser
- 251: Gateway 1 (10) – 1 privat IP-klientdels-IP-konfiguration = 240
- 240: Gateway 2 (2) = 238
- 238: Gateway 3 (15) – 1 privat IP-klientdels-IP-konfiguration = 222
Viktigt!
Även om ett /24-undernät inte krävs per Application Gateway v2 SKU-distribution rekommenderar vi det starkt. Ett /24-undernät säkerställer att Application Gateway v2 har tillräckligt med utrymme för automatisk skalningsexpansion och underhållsuppgraderingar.
Du bör se till att Application Gateway v2-undernätet har tillräckligt med adressutrymme för att hantera det antal instanser som krävs för att hantera din maximala förväntade trafik. Om du anger det maximala antalet instanser bör undernätet ha kapacitet för minst så många adresser. Information om kapacitetsplanering kring antalet instanser finns i Information om antal instanser.
Undernätet med namnet GatewaySubnet är reserverat för VPN-gatewayer. Application Gateway v1-resurserna som använder GatewaySubnet undernätet måste flyttas till ett annat undernät eller migreras till V2 SKU före den 30 september 2023 för att undvika fel på kontrollplanet och plattformsokonsekvenser. Information om hur du ändrar undernätet för en befintlig Application Gateway-instans finns i Vanliga frågor och svar om Application Gateway.
Dricks
IP-adresser allokeras från början av det definierade undernätsutrymmet för gatewayinstanser. När instanser skapas och tas bort på grund av att gatewayer eller skalningshändelser skapas kan det bli svårt att förstå vad nästa tillgängliga adress är i undernätet. För att kunna fastställa nästa adress som ska användas för en framtida gateway och ha ett sammanhängande adresseringstema för klientdels-IP-adresser kan du överväga att tilldela IP-adresser för klientdelen från den övre halvan av det definierade delmängdsutrymmet.
Om adressutrymmet för undernätet till exempel är 10.5.5.0/24, överväg att ange IP-konfigurationen för den privata klientdelen för dina gatewayer från och med 10.5.5.254 och sedan följa med 10.5.5.253, 10.5.5.252, 10.5.5.251 och så vidare för framtida gatewayer.
Det går att ändra undernätet för en befintlig Application Gateway-instans i samma virtuella nätverk. Om du vill göra den här ändringen använder du Azure PowerShell eller Azure CLI. Mer information finns i Vanliga frågor och svar om Application Gateway.
DNS-servrar för namnmatchning
Den virtuella nätverksresursen stöder DNS-serverkonfiguration , vilket gör att du kan välja mellan standardservrar som tillhandahålls av Azure eller anpassade DNS-servrar. Instanserna av din programgateway respekterar även den här DNS-konfigurationen för valfri namnmatchning. När du har ändrat den här inställningen måste du starta om (Stoppa och starta) programgatewayen för att ändringarna ska börja gälla för instanserna.
När en instans av din Application Gateway utfärdar en DNS-fråga använder den värdet från servern som svarar först.
Kommentar
Om du använder anpassade DNS-servrar i det virtuella Application Gateway-nätverket måste DNS-servern kunna matcha offentliga Internetnamn. Application Gateway kräver den här funktionen.
Behörighet för virtuellt nätverk
Application Gateway-resursen distribueras i ett virtuellt nätverk, så kontroller utförs också för att verifiera behörigheten för den virtuella nätverksresursen. Den här verifieringen utförs under både skapande- och hanteringsåtgärder och gäller även för hanterade identiteter för Application Gateway-ingresskontrollanten.
Kontrollera din rollbaserade åtkomstkontroll i Azure för att kontrollera att de användare och tjänstens huvudnamn som kör programgatewayer har minst följande behörigheter i det virtuella nätverket eller undernätet:
- Microsoft.Network/virtualNetworks/subnets/join/action
- Microsoft.Network/virtualNetworks/subnets/read
Du kan använda de inbyggda rollerna, till exempel Nätverksdeltagare, som redan har stöd för dessa behörigheter. Om en inbyggd roll inte ger rätt behörighet kan du skapa och tilldela en anpassad roll. Läs mer om att hantera undernätsbehörigheter.
Kommentar
Du kan behöva ge tillräckligt med tid för uppdatering av Azure Resource Manager-cacheminnet när rolltilldelningen har ändrats.
Identifiera berörda användare eller tjänstens huvudnamn för din prenumeration
Genom att besöka Azure Advisor för ditt konto kan du kontrollera om din prenumeration har några användare eller tjänstens huvudnamn med otillräcklig behörighet. Informationen om den rekommendationen är följande:
Rubrik: Uppdatera VNet-behörighet för Application Gateway-användare
Kategori: Tillförlitlighetspåverkan
: Hög
Använda tillfällig AFEC-flagga (Azure Feature Exposure Control)
Som ett tillfälligt tillägg introducerade vi en AFEC (Azure Feature Exposure Control) på prenumerationsnivå. Du kan registrera dig för AFEC och använda den tills du åtgärdar behörigheterna för alla användare och tjänstens huvudnamn. Registrera dig för funktionen genom att följa samma steg som en förhandsversionsfunktionsregistrering för din Azure-prenumeration.
Namn: Microsoft.Network/DisableApplicationGatewaySubnetPermissionCheck
Beskrivning: Inaktivera Application Gateway-undernätsbehörighet Kontrollera
ProviderNamespace: Microsoft.Network
EnrollmentType: AutoApprove
Kommentar
Vi föreslår att du endast använder AFEC-etableringen som tillfällig åtgärd tills du tilldelar rätt behörighet. Du måste prioritera att åtgärda behörigheterna för alla tillämpliga användare (och tjänstens huvudnamn) och sedan avregistrera den här AFEC-flaggan för att återinföra behörighetsverifieringen på den virtuella nätverksresursen. Vi rekommenderar att du inte är beroende av den här AFEC-metoden permanent eftersom den tas bort i framtiden.
Azure Virtual Network Manager
Azure Virtual Network Manager är en hanteringstjänst som gör att du kan gruppera, konfigurera, distribuera och hantera virtuella nätverk globalt mellan prenumerationer. Med Virtual Network Manager kan du definiera nätverksgrupper för att identifiera och segmentera dina virtuella nätverk logiskt. Därefter kan du bestämma vilka anslutnings- och säkerhetskonfigurationer du vill använda och tillämpa dem på alla valda virtuella nätverk i nätverksgrupper samtidigt.
Med regelkonfigurationen för säkerhetsadministratörer i Azure Virtual Network Manager kan du definiera säkerhetsprinciper i stor skala och tillämpa dem på flera virtuella nätverk samtidigt.
Kommentar
Säkerhetsadministratörsregler för Azure Virtual Network Manager gäller endast för Application Gateway-undernät som innehåller programgatewayer med nätverksisolering aktiverat. Undernät med programgatewayer som har nätverksisolering inaktiverat har inte säkerhetsadministratörsregler.
Nätverkssäkerhetsgrupper
Du kan använda NSG:er för ditt Application Gateway-undernät, men tänk på några viktiga punkter och begränsningar.
Viktigt!
De här NSG-begränsningarna är avslappnade när du använder distribution av privat Application Gateway (förhandsversion).
Nödvändiga säkerhetsregler
Om du vill använda en NSG med din programgateway måste du skapa eller behålla några viktiga säkerhetsregler. Du kan ange deras prioritet i samma ordning.
Regler för inkommande trafik
Klienttrafik: Tillåt inkommande trafik från de förväntade klienterna (som käll-IP eller IP-intervall) och för målet som programgatewayens hela ip-prefix för undernätet och inkommande åtkomstportar. Om du till exempel har lyssnare konfigurerade för portarna 80 och 443 måste du tillåta dessa portar. Du kan också ange den här regeln till Any.
| Källa | Källportar | Mål | Målportar | Protokoll | Access |
|---|---|---|---|---|---|
<as per need> |
Alla | <Subnet IP Prefix> |
<listener ports> |
TCP | Tillåt |
När du har konfigurerat aktiva offentliga och privata lyssnare (med regler) med samma portnummer ändrar programgatewayen målet för alla inkommande flöden till gatewayens ip-adresser. Den här ändringen sker även för lyssnare som inte delar någon port. Du måste inkludera din gateways offentliga och privata IP-adresser i målregeln för inkommande när du använder samma portkonfiguration.
| Källa | Källportar | Mål | Målportar | Protokoll | Access |
|---|---|---|---|---|---|
<as per need> |
Alla | <Public and Private frontend IPs> |
<listener ports> |
TCP | Tillåt |
Infrastrukturportar: Tillåt inkommande begäranden från källan som GatewayManager-tjänsttaggen och Alla mål. Målportintervallet skiljer sig åt baserat på SKU och krävs för att kommunicera status för serverdelshälsan. Dessa portar skyddas/låses av Azure-certifikat. Externa entiteter kan inte initiera ändringar på dessa slutpunkter utan lämpliga certifikat på plats.
- V2: Portar 65200-65535
- V1: Portar 65503-65534
| Källa | Källportar | Mål | Målportar | Protokoll | Access |
|---|---|---|---|---|---|
| GatewayManager | Valfri | Valfri | <as per SKU given above> |
TCP | Tillåt |
Azure Load Balancer-avsökningar: Tillåt inkommande trafik från källan som AzureLoadBalancer-tjänsttagg . Den här regeln skapas som standard för NSG:er. Du får inte åsidosätta den med en manuell neka-regel för att säkerställa smidiga åtgärder för din programgateway.
| Källa | Källportar | Mål | Målportar | Protokoll | Access |
|---|---|---|---|---|---|
| AzureLoadBalancer | Valfri | Valfri | Valfri | Valfri | Tillåt |
Du kan blockera all annan inkommande trafik med hjälp av regeln Neka alla .
Regler för utgående trafik
Utgående trafik till Internet: Tillåt utgående trafik till Internet för alla mål. Den här regeln skapas som standard för NSG:er. Du får inte åsidosätta den med en manuell neka-regel för att säkerställa smidiga åtgärder för din programgateway. Utgående NSG-regler som nekar utgående anslutningar får inte skapas.
| Källa | Källportar | Mål | Målportar | Protokoll | Access |
|---|---|---|---|---|---|
| Valfri | Valfri | Internet | Valfri | Valfri | Tillåt |
Kommentar
Application Gateways som inte har nätverksisolering aktiverat tillåter inte att trafik skickas mellan peerkopplade virtuella nätverk när Tillåt trafik till fjärranslutna virtuella nätverk är inaktiverat.
Användardefinierade vägar som stöds
Detaljerad kontroll över Application Gateway-undernätet via routningstabellregler är möjlig i offentlig förhandsversion. Mer information finns i Distribution av privat Application Gateway (förhandsversion).
Med nuvarande funktioner finns det vissa begränsningar:
Viktigt!
Om du använder UDR:er i Application Gateway-undernätet kan hälsostatusen i serverdelshälsovyn visas som Okänd. Det kan också leda till att genereringen av Application Gateway-loggar och -mått misslyckas. Vi rekommenderar att du inte använder UDR:er i Application Gateway-undernätet så att du kan visa serverdelshälsa, loggar och mått.
v1: För v1-SKU:n stöds UDR:er i Application Gateway-undernätet om de inte ändrar kommunikationen mellan slutpunkt och slutpunkt för begäran/svar. Du kan till exempel konfigurera en UDR Application Gateway-undernätet så att den pekar på en brandväggsinstallation för paketinspektion. Men du måste se till att paketet kan nå sitt avsedda mål efter inspektionen. Annars kan hälsoavsökningen eller trafikroutningen bli felaktig. Inlärda vägar eller standardvägarna 0.0.0.0/0 som sprids av Azure ExpressRoute eller VPN-gatewayer i det virtuella nätverket ingår också.
v2: För V2 SKU finns det scenarier som stöds och som inte stöds.
v2-scenarier som stöds
Varning
En felaktig konfiguration av routningstabellen kan resultera i asymmetrisk routning i Application Gateway v2. Se till att all hanterings-/kontrollplanstrafik skickas direkt till Internet och inte via en virtuell installation. Loggning, mått och CRL-kontroller kan också påverkas.
Scenario 1: UDR för att inaktivera BGP-vägspridning (Border Gateway Protocol) till Application Gateway-undernätet
Ibland annonseras standardgatewayvägen (0.0.0.0/0) via ExpressRoute- eller VPN-gatewayerna som är associerade med det virtuella Application Gateway-nätverket. Det här beteendet bryter hanteringsplanets trafik, vilket kräver en direkt sökväg till Internet. I sådana scenarier kan du använda en UDR för att inaktivera BGP-vägspridning.
Så här inaktiverar du BGP-routningsspridning:
- Skapa en routningstabellresurs i Azure.
- Inaktivera parametern Routningsspridning för virtuell nätverksgateway.
- Associera routningstabellen med lämpligt undernät.
Aktivering av UDR för det här scenariot bör inte bryta några befintliga installationer.
Scenario 2: UDR dirigerar 0.0.0.0/0 till Internet
Du kan skapa en UDR för att skicka 0.0.0.0/0-trafik direkt till Internet.
Scenario 3: UDR för Azure Kubernetes Service (AKS) med kubenet
Om du använder kubenet med AKS och Application Gateway Ingress Controller behöver du en routningstabell som tillåter att trafik som skickas till poddarna från Application Gateway dirigeras till rätt nod. Du behöver inte använda en routningstabell om du använder Azure Container Networking Interface.
Så här använder du routningstabellen för att tillåta kubenet att fungera:
Gå till resursgruppen som skapats av AKS. Namnet på resursgruppen bör börja med
MC_.Leta upp routningstabellen som skapats av AKS i den resursgruppen. Routningstabellen bör fyllas i med följande information:
- Adressprefixet ska vara IP-intervallet för de poddar som du vill nå i AKS.
- Nästa hopptyp ska vara en virtuell installation.
- Nästa hoppadress ska vara IP-adressen för noden som är värd för poddarna.
Associera den här routningstabellen med Application Gateway-undernätet.
v2 scenarier som inte stöds
Scenario 1: UDR för virtuella installationer
Alla scenarion där 0.0.0.0/0 måste omdirigeras via en virtuell installation, ett virtuellt nav/ekernätverk eller lokalt (tvingad tunneltrafik) stöds inte för v2.