Så här fungerar Azure Application Gateway
Azure Application Gateway har en serie komponenter som kombineras för att på ett säkert sätt dirigera och belastningsutjämningsbegäranden över en pool med webbservrar. Application Gateway innehåller följande komponenter:
- Klientdels-IP-adress: Klientbegäranden tas emot via en klientdels-IP-adress. Du kan konfigurera Application Gateway till att ha en offentlig IP-adress, en privat IP-adress eller båda. Application Gateway kan inte ha fler än en offentlig IP-adress och en privat IP-adress.
- Lyssnare: Application Gateway använder en eller flera lyssnare för att ta emot inkommande begäranden. Lyssnare accepterar trafik som inkommer på en angiven kombination av protokoll, port, värd och IP-adress. Varje lyssnare dirigerar begäranden till en serverdelspool med servrar enligt dirigeringsregler som du anger. Lyssnare kan vara av typen Basic (Grundläggande) eller Multi-site (Flera platser). En grundläggande lyssnare dirigerar bara en begäran baserat på sökvägen i URL:en. En lyssnare med flera webbplatser kan också dirigera begäranden med hjälp av värdnamnselementet i URL:en. Lyssnare hanterar även TLS/SSL-certifikat för att skydda ditt program mellan användaren och Application Gateway.
- Routningsregler: En routningsregel binder en lyssnare till serverdelspoolerna. En regel anger hur du tolkar värdnamns- och sökvägselementen i URL:en för en begäran och dirigerar begäran till lämplig serverdelspool. Dirigeringsregler har även en associerad uppsättning HTTP-inställningar. Dessa HTTP-inställningar anger om (och hur) trafik krypteras mellan Application Gateway och serverdelsservrarna. Annan konfigurationsinformation inkluderar protokoll, sessionspinnehet, Anslut ionsdränering, tidsgräns för begäranden och hälsoavsökningar.
Belastningsutjämning i Application Gateway
Application Gateway belastningsutjämningar automatiskt begäranden som skickas till servrarna i varje serverdelspool med hjälp av en resursallokeringsmekanism. Belastningsutjämning fungerar med den OSI Layer 7-dirigering som implementeras av Application Gateway-dirigering, vilket innebär att den belastningsutjämnar begäranden baserat på de dirigeringsparametrar (värdnamn och sökvägar) som används av Application Gateway-reglerna. Som jämförelse fungerar andra lastbalanserare, till exempel Azure Load Balancer, på OSI Layer 4-nivån och distribuerar trafik baserat på IP-adressen för målet för en begäran.
Du kan konfigurera sessionspinnehet om du behöver se till att alla begäranden för en klient i samma session dirigeras till samma server i en serverdelspool.
Brandvägg för webbaserade program
Brandväggen för webbaserade program (WAF) är en valfri komponent som hanterar inkommande begäranden innan de når en lyssnare. Brandväggen för webbprogram kontrollerar varje begäran efter många vanliga hot baserat på Open Web Application Security Project (OWASP). Vanliga hot är: SQL-inmatning, skript för flera platser, kommandoinmatning, HTTP-begärandesmuggling, HTTP-svarsdelning, fjärrfilinkludering, robotar, crawlare och skannrar samt överträdelser och avvikelser i HTTP-protokoll.
OWASP definierar en uppsättning allmänna regler för att identifiera attacker. Dessa regler kallas Core Rule Set (CRS). Regeluppsättningen granskas kontinuerligt allt eftersom attacker blir mer sofistikerade. WAF stöder fyra regeluppsättningar: CRS 3.2, 3.1, 3.0 och 2.2.9. CRS 3.1 är standardvärdet. Om det behövs kan du välja endast specifika regler i en regeluppsättning som riktar in sig på särskilda hot. Du kan dessutom anpassa brandväggen för att ange vilka element i en begäran som ska granskas samt begränsa storleken på meddelanden för att förhindra att stora uppladdningar överbelastar dina servrar.
Serverdelspooler
En serverdelspool är en samling webbservrar som kan bestå av: en fast uppsättning virtuella datorer, en vm-skalningsuppsättning, en app som hanteras av Azure App Services eller en samling lokala servrar.
Varje serverdelspool har en associerad lastbalanserare som distribuerar arbete över poolen. När du konfigurerar poolen anger du IP-adressen eller namnet på varje webbserver. Alla servrar i serverdelspoolen bör konfigureras på samma sätt, inklusive deras säkerhetsinställningar.
Om du använder TLS/SSL har serverdelspoolen en HTTP-inställning som refererar till ett certifikat som används för att autentisera serverdelsservrarna. Gatewayen krypterar om trafiken med hjälp av det här certifikatet innan den skickas till en av servrarna i serverdelspoolen.
Om du använder Azure App Service som värd för serverdelsprogrammet behöver du inte installera några certifikat i Application Gateway för att ansluta till serverdelspoolen. All kommunikation krypteras automatiskt. Application Gateway litar på servrarna eftersom de hanteras av Azure.
Application Gateway använder en regel för att ange hur meddelanden som ska skickas på den inkommande porten ska dirigeras till servrarna i serverdelspoolen. Om servrarna använder TLS/SSL måste du konfigurera regeln för att ange:
- Att dina servrar förväntar sig trafik via HTTPS-protokollet.
- Vilket certifikat som ska användas för att kryptera trafiken och autentisera anslutningen till en server.
Application Gateway-routning
När gatewayen dirigerar en klientbegäran till en webbserver i serverdelspoolen använder den en uppsättning regler som konfigurerats för gatewayen för att avgöra vart begäran ska gå. Det finns två primära metoder för att dirigera den här klientbegärandetrafiken: sökvägsbaserad routning och routning på flera platser.
Sökvägsbaserad dirigering
Sökvägsbaserad routning skickar begäranden med olika URL-sökvägar till olika pooler av serverdelsservrar. Du kan till exempel dirigera begäranden med sökvägen /video/* till en serverdelspool som innehåller servrar som är optimerade för att hantera videouppspelning och dirigera /images/* begäranden till en pool med servrar som hanterar bildhämtning.
Routning med flera platser
Routning med flera platser konfigurerar mer än ett webbprogram på samma Application Gateway-instans. I en konfiguration med flera platser registrerar du flera DNS-namn (CNAMEs) för IP-adressen för programgatewayen och anger namnet på varje plats. Application Gateway använder separata lyssnare för att vänta på begäranden för varje webbplats. Alla lyssnare skickar begäranden till olika regler som kan dirigera begärandena till servrar i en annan serverdelspool. Du kan till exempel dirigera alla begäranden till http://contoso.com servrar i en serverdelspool och begäranden för http://fabrikam.com till en annan serverdelspool. Följande diagram visar den här konfigurationen:
Konfigurationer med flera platser är användbara för stöd för program med flera klienter, där varje klientorganisation har en egen uppsättning virtuella datorer eller andra resurser som är värdar för ett webbprogram.
Application Gateway-routning innehåller även följande funktioner:
- Omdirigering. Omdirigering kan användas till en annan webbplats eller från HTTP till HTTPS.
- Återskapa HTTP-huvuden. MED HTTP-huvuden kan klienten och servern skicka parameterinformation med begäran eller svaret.
- Anpassade felsidor. Med Application Gateway kan du skapa anpassade felsidor i stället för att visa standardmässiga felsidor. Du kan använda din egen varumärkesanpassning och layout med hjälp av en anpassad felsida.
TLS/SSL-avslutning
När du avslutar TLS/SSL-anslutningen vid programgatewayen avlastas den PROCESSORintensiva TLS/SSL-avslutningsarbetsbelastningen från dina servrar. Du behöver inte heller installera certifikat och konfigurera TLS/SSL på dina servrar.
Om du behöver kryptering från slutpunkt till slutpunkt kan Application Gateway dekryptera trafiken på gatewayen med hjälp av din privata nyckel och sedan kryptera igen med den offentliga nyckeln för tjänsten som körs i serverdelspoolen.
Trafiken kommer in i gatewayen via en klientdelsport. Du kan öppna många portar och Application Gateway kan ta emot meddelanden via valfri öppen port. En lyssnare är det första som trafiken stöter på när den kommer till din gateway via en port. Lyssnaren är konfigurerad för att lyssna efter ett specifikt värdnamn och en specifik port på en specifik IP-adress. Lyssnaren kan använda ett TLS/SSL-certifikat för att dekryptera trafiken som kommer in i gatewayen. Lyssnaren använder sedan en regel som du definierar för att dirigera inkommande begäranden till en serverdelspool.
Om du exponerar dina webbplatser eller appar via programgatewayen behöver du inte heller ansluta servrarna direkt till webben. Du exponerar endast port 80 eller port 443 på programgatewayen, som sedan vidarebefordras till serverdelspoolservern. I den här konfigurationen är dina webbservrar inte direkt åtkomliga från Internet, vilket minskar angreppsytan för infrastrukturen.
Hälsotillståndsavsökningar
Hälsoavsökningar avgör vilka servrar som är tillgängliga för belastningsutjämning i en serverdelspool. Application Gateway använder en hälsoavsökning för att skicka en begäran till en server. När servern returnerar ett HTTP-svar med en statuskod mellan 200 och 399 anses servern vara felfri. Om du inte konfigurerar en hälsoavsökning skapar Application Gateway en standardavsökning och väntar sedan 30 sekunder innan den bedömer att en server är otillgänglig. Hälsoavsökningar säkerställer att trafiken inte dirigeras till en webbslutpunkt som inte svarar eller misslyckades i serverdelspoolen.
Automatisk skalning
Application Gateway stöder automatisk skalning och kan skalas upp eller ned baserat på ändrade trafikbelastningsmönster. Automatisk skalning tar även bort behovet av att välja distributionsstorlek eller instansantal under etablering.
WebSocket- och HTTP/2-trafik
Application Gateway har inbyggt stöd för WebSocket- och HTTP/2-protokoll. WebSocket- och HTTP/2-protokollen möjliggör fullständig dubbelsidig kommunikation mellan en server och en klient via en långvarig TCP-anslutning. Den här typen av kommunikation är mer interaktiv mellan webbservern och klienten och kan vara dubbelriktad utan behov av avsökning som krävs i HTTP-baserade implementeringar. Dessa protokoll har låga omkostnader (till skillnad från HTTP) och kan återanvända samma TCP-anslutning för flera begäranden/svar, vilket resulterar i en effektivare resursanvändning. Dessa protokoll är utformade att fungera via de traditionella HTTP-portarna 80 och 443.