Infrastructuurconfiguratie van Application Gateway
De Azure-toepassing Gateway-infrastructuur omvat het virtuele netwerk, subnetten, netwerkbeveiligingsgroepen (NSG's) en door de gebruiker gedefinieerde routes (UDR's).
Virtueel netwerk en toegewezen subnet
Een toepassingsgateway is een toegewezen implementatie in uw virtuele netwerk. Binnen uw virtuele netwerk is een toegewezen subnet vereist voor de toepassingsgateway. U kunt meerdere exemplaren van een specifieke Application Gateway-implementatie in een subnet hebben. U kunt ook andere toepassingsgateways implementeren in het subnet. U kunt echter geen andere resource implementeren in het Application Gateway-subnet. U kunt v1- en v2 Application Gateway-SKU's niet combineren in hetzelfde subnet.
Notitie
Het beleid voor eindpunten van virtuele netwerken wordt momenteel niet ondersteund in een Application Gateway-subnet.
Grootte van het subnet
Application Gateway gebruikt één privé-IP-adres per exemplaar, plus een ander privé-IP-adres als een privé-front-end-IP is geconfigureerd.
Azure reserveert ook vijf IP-adressen in elk subnet voor intern gebruik. Dit zijn de eerste vier adressen en de laatste IP-adressen. Denk bijvoorbeeld aan 15 Application Gateway-exemplaren zonder privé-front-end-IP. U hebt ten minste 20 IP-adressen nodig voor dit subnet. U hebt 5 nodig voor intern gebruik en 15 voor de Application Gateway-exemplaren.
Overweeg een subnet met 27 Application Gateway-exemplaren en een IP-adres voor een privé-front-end-IP. In dit geval hebt u 33 IP-adressen nodig. U hebt 27 nodig voor de Application Gateway-exemplaren, één voor de privé-front-end en 5 voor intern gebruik.
Application Gateway (Standard of WAF SKU) kan maximaal 32 exemplaren ondersteunen (IP-adressen van 32 exemplaren + 1 privé-front-end-IP-configuratie + 5 gereserveerd voor Azure). We raden een minimale subnetgrootte van /26 aan.
Application Gateway (Standard_v2 of WAF_v2 SKU) kan maximaal 125 exemplaren ondersteunen (IP-adressen van 125 exemplaren + 1 privé-front-end-IP-configuratie + 5 gereserveerd voor Azure). We raden een minimale subnetgrootte van /24 aan.
Als u de beschikbare capaciteit wilt bepalen van een subnet dat bestaande toepassingsgateways heeft ingericht, neemt u de grootte van het subnet op en trekt u de vijf gereserveerde IP-adressen van het subnet af dat door het platform is gereserveerd. Vervolgens neemt u elke gateway en trekt u het maximumaantal exemplaren af. Voor elke gateway met een privé-front-end-IP-configuratie trekt u nog één IP-adres per gateway af.
U kunt als volgt bijvoorbeeld de beschikbare adressering voor een subnet berekenen met drie gateways van verschillende grootten:
- Gateway 1: Maximaal 10 exemplaren. Maakt gebruik van een privé-front-end-IP-configuratie.
- Gateway 2: Maximaal 2 exemplaren. Geen privé-front-end-IP-configuratie.
- Gateway 3: Maximaal 15 exemplaren. Maakt gebruik van een privé-front-end-IP-configuratie.
- Subnetgrootte: /24
- Subnetgrootte /24 = 256 IP-adressen - 5 gereserveerd vanaf het platform = 251 beschikbare adressen
- 251: Gateway 1 (10) - 1 privé-front-end-IP-configuratie = 240
- 240: Gateway 2 (2) = 238
- 238: Gateway 3 (15) - 1 privé-front-end-IP-configuratie = 222
Belangrijk
Hoewel een /24-subnet niet vereist is per implementatie van Application Gateway v2 SKU, raden we dit ten zeerste aan. Een /24-subnet zorgt ervoor dat Application Gateway v2 voldoende ruimte heeft voor automatisch schalen van uitbreidings- en onderhoudsupgrades.
Zorg ervoor dat het subnet Application Gateway v2 voldoende adresruimte heeft om het aantal exemplaren te kunnen verwerken dat nodig is voor het maximale verwachte verkeer. Als u het maximumaantal exemplaren opgeeft, moet het subnet capaciteit hebben voor ten minste dat aantal adressen. Zie De details van het aantal exemplaren voor capaciteitsplanning.
Het subnet met de naam GatewaySubnet is gereserveerd voor VPN-gateways. De Application Gateway v1-resources die gebruikmaken van het GatewaySubnet subnet moeten vóór 30 september 2023 worden verplaatst naar een ander subnet of naar de v2-SKU worden gemigreerd om storingen in het besturingsvlak en platformconsistentie te voorkomen. Zie Veelgestelde vragen over Application Gateway voor meer informatie over het wijzigen van het subnet van een bestaand Application Gateway-exemplaar.
Tip
IP-adressen worden toegewezen vanaf het begin van de gedefinieerde subnetruimte voor gateway-exemplaren. Wanneer exemplaren worden gemaakt en verwijderd vanwege het maken van gateways of het schalen van gebeurtenissen, kan het lastig worden om te begrijpen wat het volgende beschikbare adres in het subnet is. Als u het volgende adres wilt kunnen bepalen dat moet worden gebruikt voor een toekomstige gateway en een aaneengesloten adresseringsthema voor front-end-IP-adressen wilt hebben, kunt u overwegen ip-adressen toe te wijzen vanuit de bovenste helft van de gedefinieerde subsetruimte.
Als de adresruimte van het subnet bijvoorbeeld 10.5.5.0/24 is, overweeg om de privé-front-end-IP-configuratie van uw gateways in te stellen vanaf 10.5.5.254 en daarna met 10.5.5.253, 10.5.5.252, 10.5.5.251 enzovoort voor toekomstige gateways.
Het is mogelijk om het subnet van een bestaand Application Gateway-exemplaar binnen hetzelfde virtuele netwerk te wijzigen. Als u deze wijziging wilt aanbrengen, gebruikt u Azure PowerShell of de Azure CLI. Zie veelgestelde vragen over Application Gateway voor meer informatie.
DNS-servers voor naamomzetting
De virtuele netwerkresource ondersteunt dns-serverconfiguratie , waarmee u kunt kiezen tussen standaard- of aangepaste DNS-servers van Azure. De exemplaren van uw toepassingsgateway respecteren deze DNS-configuratie ook voor elke naamomzetting. Nadat u deze instelling hebt gewijzigd, moet u de toepassingsgateway opnieuw starten (stoppen en starten) zodat deze wijzigingen van kracht worden op de exemplaren.
Wanneer een exemplaar van uw Application Gateway een DNS-query uitgeeft, wordt de waarde van de server gebruikt die als eerste reageert.
Notitie
Als u aangepaste DNS-servers in het virtuele netwerk van Application Gateway gebruikt, moet de DNS-server openbare internetnamen kunnen omzetten. Voor Application Gateway is deze mogelijkheid vereist.
Machtiging voor virtueel netwerk
De Application Gateway-resource wordt geïmplementeerd in een virtueel netwerk, dus er worden ook controles uitgevoerd om de machtiging voor de resource van het virtuele netwerk te controleren. Deze validatie wordt uitgevoerd tijdens zowel het maken als beheren van bewerkingen en is ook van toepassing op de beheerde identiteiten voor de controller voor inkomend verkeer van Application Gateway.
Controleer uw op rollen gebaseerd toegangsbeheer van Azure om te controleren of de gebruikers en service-principals die toepassingsgateways gebruiken, ten minste de volgende machtigingen hebben voor het virtuele netwerk of subnet:
- Microsoft.Network/virtualNetworks/subnets/join/action
- Microsoft.Network/virtualNetworks/subnets/read
U kunt de ingebouwde rollen, zoals Netwerkbijdrager, gebruiken die deze machtigingen al ondersteunen. Als een ingebouwde rol niet de juiste machtiging biedt, kunt u een aangepaste rol maken en toewijzen. Meer informatie over het beheren van subnetmachtigingen.
Notitie
Mogelijk moet u voldoende tijd toestaan voor het vernieuwen van de Azure Resource Manager-cache nadat de roltoewijzing is gewijzigd.
Betrokken gebruikers of service-principals voor uw abonnement identificeren
Door naar Azure Advisor voor uw account te gaan, kunt u controleren of uw abonnement gebruikers of service-principals heeft met onvoldoende machtigingen. De details van die aanbeveling zijn als volgt:
Titel: VNet-machtiging van Application Gateway-gebruikerscategorie
bijwerken: Betrouwbaarheidsimpact
: Hoog
De vlag tijdelijke blootstellingsbeheer voor Azure-functies (AFEC) gebruiken
Als tijdelijke uitbreiding hebben we een Azure Feature Exposure Control (AFEC) op abonnementsniveau geïntroduceerd. U kunt zich registreren voor de AFEC en deze gebruiken totdat u de machtigingen voor al uw gebruikers en service-principals hebt hersteld. Registreer u voor de functie door dezelfde stappen te volgen als een preview-functieregistratie voor uw Azure-abonnement.
Naam: Microsoft.Network/DisableApplicationGatewaySubnetPermissionCheck
Description: Disable Application Gateway Subnet Permission Check
ProviderNamespace: Microsoft.Network
EnrollmentType: AutoApprove
Notitie
We raden u aan de AFEC-inrichting alleen als tussentijdse beperking te gebruiken totdat u de juiste machtiging toewijst. U moet prioriteit geven aan het herstellen van de machtigingen voor alle toepasselijke gebruikers (en service-principals) en vervolgens de registratie van deze AFEC-vlag ongedaan maken om de machtigingsverificatie opnieuw in te voeren voor de resource van het virtuele netwerk. U wordt aangeraden niet permanent afhankelijk te zijn van deze AFEC-methode, omdat deze in de toekomst wordt verwijderd.
Azure Virtual Network Manager
Azure Virtual Network Manager is een beheerservice waarmee u virtuele netwerken wereldwijd in abonnementen kunt groeperen, configureren, implementeren en beheren. Met Virtual Network Manager kunt u netwerkgroepen definiëren om uw virtuele netwerken te identificeren en logisch te segmenteren. Daarna kunt u de gewenste connectiviteits- en beveiligingsconfiguraties bepalen en deze toepassen op alle geselecteerde virtuele netwerken in netwerkgroepen tegelijk.
Met de configuratie van beveiligingsbeheerdersregels in Azure Virtual Network Manager kunt u beveiligingsbeleid op schaal definiëren en deze toepassen op meerdere virtuele netwerken tegelijk.
Notitie
Beveiligingsbeheerdersregels van Azure Virtual Network Manager zijn alleen van toepassing op Application Gateway-subnetten die toepassingsgateways bevatten waarvoor Netwerkisolatie is ingeschakeld. Subnetten met toepassingsgateways waarvoor Netwerkisolatie is uitgeschakeld, hebben geen beveiligingsbeheerdersregels.
Netwerkbeveiligingsgroepen
U kunt NSG's gebruiken voor uw Application Gateway-subnet, maar houd rekening met enkele belangrijke punten en beperkingen.
Belangrijk
Deze NSG-beperkingen worden versoepeld wanneer u de implementatie van Private Application Gateway (preview) gebruikt.
Vereiste beveiligingsregels
Als u een NSG met uw toepassingsgateway wilt gebruiken, moet u enkele essentiële beveiligingsregels maken of behouden. U kunt hun prioriteit in dezelfde volgorde instellen.
Regels voor inkomend verkeer
Clientverkeer: inkomend verkeer van de verwachte clients toestaan (als bron-IP- of IP-bereik) en voor de bestemming als het volledige subnet-IP-voorvoegsel en binnenkomende toegangspoorten van uw toepassingsgateway. Als u bijvoorbeeld listeners hebt geconfigureerd voor poort 80 en 443, moet u deze poorten toestaan. U kunt deze regel ook instellen op Any.
| Bron | Bronpoorten | Doel | Doelpoorten | Protocol | Access |
|---|---|---|---|---|---|
<as per need> |
Alle | <Subnet IP Prefix> |
<listener ports> |
TCP | Toestaan |
Nadat u actieve openbare en persoonlijke listeners (met regels) met hetzelfde poortnummer hebt geconfigureerd, wijzigt uw toepassingsgateway het doel van alle binnenkomende stromen in de front-end-IP's van uw gateway. Deze wijziging treedt zelfs op voor listeners die geen poort delen. U moet de openbare en privé-IP-adressen van uw gateway opnemen in de bestemming van de regel voor inkomend verkeer wanneer u dezelfde poortconfiguratie gebruikt.
| Bron | Bronpoorten | Doel | Doelpoorten | Protocol | Access |
|---|---|---|---|---|---|
<as per need> |
Alle | <Public and Private frontend IPs> |
<listener ports> |
TCP | Toestaan |
Infrastructuurpoorten: Binnenkomende aanvragen van de bron toestaan als de GatewayManager-servicetag en Elke bestemming. Het poortbereik van het doel verschilt op basis van SKU en is vereist voor het communiceren van de status van de back-end. Deze poorten worden beveiligd/vergrendeld door Azure-certificaten. Externe entiteiten kunnen geen wijzigingen op deze eindpunten initiëren zonder de juiste certificaten.
- V2: Poorten 65200-65535
- V1: Poorten 65503-65534
| Bron | Bronpoorten | Doel | Doelpoorten | Protocol | Access |
|---|---|---|---|---|---|
| GatewayManager | Alle | Alle | <as per SKU given above> |
TCP | Toestaan |
Azure Load Balancer-tests: inkomend verkeer van de bron toestaan als de AzureLoadBalancer-servicetag . Deze regel wordt standaard gemaakt voor NSG's. U moet deze niet overschrijven met een handmatige regel voor weigeren om een soepele werking van uw toepassingsgateway te garanderen.
| Bron | Bronpoorten | Doel | Doelpoorten | Protocol | Access |
|---|---|---|---|---|---|
| AzureLoadBalancer | Alle | Alle | Alle | Alle | Toestaan |
U kunt al het andere binnenkomende verkeer blokkeren met behulp van een regel Alles weigeren.
Uitgaande regels
Uitgaand naar internet: uitgaand verkeer naar internet toestaan voor alle bestemmingen. Deze regel wordt standaard gemaakt voor NSG's. U moet deze niet overschrijven met een handmatige regel voor weigeren om een soepele werking van uw toepassingsgateway te garanderen. Uitgaande NSG-regels die uitgaande connectiviteit weigeren, mogen niet worden gemaakt.
| Bron | Bronpoorten | Doel | Doelpoorten | Protocol | Access |
|---|---|---|---|---|---|
| Alle | Alle | Internet | Alle | Alle | Toestaan |
Notitie
Toepassingsgateways waarvoor netwerkisolatie niet is ingeschakeld, staan niet toe dat verkeer wordt verzonden tussen gekoppelde VNets wanneer verkeer naar extern virtueel netwerk is uitgeschakeld.
Ondersteunde door de gebruiker gedefinieerde routes
Gedetailleerde controle over het Application Gateway-subnet via regels voor routetabellen is mogelijk in openbare preview. Zie De implementatie van Private Application Gateway (preview) voor meer informatie.
Met de huidige functionaliteit zijn er enkele beperkingen:
Belangrijk
Als u UDR's op het Application Gateway-subnet gebruikt, kan de status in de weergave back-endstatus worden weergegeven als Onbekend. Het kan er ook toe leiden dat het genereren van Application Gateway-logboeken en metrische gegevens mislukt. Het is raadzaam om UDR's niet te gebruiken in het Application Gateway-subnet, zodat u de back-endstatus, logboeken en metrische gegevens kunt bekijken.
v1: Voor de v1-SKU worden UDR's ondersteund in het Application Gateway-subnet als ze geen end-to-end-aanvraag-/antwoordcommunicatie wijzigen. U kunt bijvoorbeeld een UDR in het Application Gateway-subnet zo configureren dat deze wijst naar een firewallapparaat voor pakketinspectie. Maar u moet ervoor zorgen dat het pakket na inspectie de beoogde bestemming kan bereiken. Als u dit niet doet, kan dit leiden tot een onjuist statustest- of verkeersrouteringsgedrag. Geleerde routes of standaardroutes 0.0.0.0/0 die worden doorgegeven door Azure ExpressRoute- of VPN-gateways in het virtuele netwerk, worden ook opgenomen.
v2: Voor de v2-SKU zijn er ondersteunde en niet-ondersteunde scenario's.
Ondersteunde v2-scenario's
Waarschuwing
Een onjuiste configuratie van de routetabel kan leiden tot asymmetrische routering in Application Gateway v2. Zorg ervoor dat al het beheer-/besturingsvlakverkeer rechtstreeks naar internet wordt verzonden en niet via een virtueel apparaat. Logboekregistratie, metrische gegevens en CRL-controles kunnen ook worden beïnvloed.
Scenario 1: UDR om BGP-routedoorgifte (Border Gateway Protocol) uit te schakelen naar het Application Gateway-subnet
Soms wordt de standaardgatewayroute (0.0.0.0/0) geadverteerd via de ExpressRoute- of VPN-gateways die zijn gekoppeld aan het virtuele netwerk van Application Gateway. Dit gedrag breekt het verkeer van het beheervlak, waarvoor een direct pad naar internet is vereist. In dergelijke scenario's kunt u een UDR gebruiken om BGP-routedoorgifte uit te schakelen.
BGP-routedoorgifte uitschakelen:
- Maak een routetabelresource in Azure.
- Schakel de doorgifteparameter van de gatewayroute van het virtuele netwerk uit.
- Koppel de routetabel aan het juiste subnet.
Als u de UDR voor dit scenario inschakelt, mogen bestaande instellingen niet worden verbroken.
Scenario 2: UDR om 0.0.0.0/0 naar internet te leiden
U kunt een UDR maken om verkeer van 0.0.0.0/0 rechtstreeks naar internet te verzenden.
Scenario 3: UDR voor Azure Kubernetes Service (AKS) met kubenet
Als u kubenet gebruikt met AKS- en Application Gateway-ingangscontroller, hebt u een routetabel nodig om toe te staan dat verkeer dat vanuit Application Gateway naar de pods wordt verzonden, naar het juiste knooppunt wordt gerouteerd. U hoeft geen routetabel te gebruiken als u azure Container Networking Interface gebruikt.
Als u de routetabel wilt gebruiken om kubenet te laten werken:
Ga naar de resourcegroep die is gemaakt door AKS. De naam van de resourcegroep moet beginnen met
MC_.Zoek de routetabel die is gemaakt door AKS in die resourcegroep. De routetabel moet worden gevuld met de volgende informatie:
- Adresvoorvoegsel moet het IP-bereik zijn van de pods die u in AKS wilt bereiken.
- Het volgende hoptype moet een virtueel apparaat zijn.
- Het ip-adres van de volgende hop moet het IP-adres zijn van het knooppunt dat als host fungeert voor de pods.
Koppel deze routetabel aan het Application Gateway-subnet.
Niet-ondersteunde v2-scenario's
Scenario 1: UDR voor virtuele apparaten
Elk scenario waarin 0.0.0.0/0 moet worden omgeleid via een virtueel apparaat, een virtueel hub-/spoke-netwerk of on-premises (geforceerde tunneling) wordt niet ondersteund voor v2.