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åde och. 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 förfrågningar. En lyssnare accepterar trafik som anländer på en angiven kombination av protokoll, port, värd och IP-adress. Varje lyssnare dirigerar begäranden till en serverpool enligt de routningsregler som du anger. En lyssnare kan vara Basic eller Multi-site. En Basic lyssnare styr bara en begäran baserat på sökvägen i URL:en. En lyssnare för 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 de bakre poolerna. 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. En routningsregel har också 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, sessionsklibbighet, anslutningsdränering, tidsgräns för begäranden och hälsokontroller.
Belastningsutjämning i Application Gateway
Application Gateway belastningsutjämnar automatiskt begäranden som skickas till servrarna i varje serverdelspool med hjälp av en rundturmekanism. Belastningsutjämning fungerar med OSI Layer 7-routningen som implementeras av Application Gateway-routning, vilket innebär att den belastningsutjämnar begäranden baserat på de routningsparametrar (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 webbprogram
Brandväggen för webbprogram (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 för core rule set (CRS). Regeluppsättningarna granskas kontinuerligt när attacker utvecklas i sofistikering. 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 att endast välja specifika regler i en regeluppsättning som riktar sig mot vissa hot. Dessutom kan du anpassa brandväggen för att ange vilka element i en begäran som ska undersökas och begränsa storleken på meddelanden för att förhindra att massiva uppladdningar överbelastar dina servrar.
Serverdelspooler
En backendpool är en samling webbservrar som kan bestå av: en fast uppsättning virtuella datorer, en skalningsuppsättning för virtuella maskiner, en app som är värd 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 Azure hanterar dem.
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 trafik 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 routning
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. Varje lyssnare skickar begäranden till en annan regel, som kan dirigera begärandena till servrar i en annan bakre pool. Du kan till exempel dirigera alla begäranden om http://contoso.com till servrar i en serverdelspool och begäranden om 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.
- Skriv om 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 standardfelsidor. Du kan använda ditt eget varumärke och din 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 ingångsport. Du kan öppna många portar och Application Gateway kan ta emot meddelanden på någon av dessa portar. En lyssnare är det första som trafiken möter när du går in i gatewayen 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 back-end pool.
Att exponera din webbplats eller webbapp via programgatewayen innebär också att du inte ansluter servrarna direkt till webben. Du exponerar endast port 80 eller port 443 på applikationsgatewayen, som sedan vidarebefordras till backendpoolservern. I den här konfigurationen är dina webbservrar inte direkt åtkomliga från Internet, vilket minskar angreppsytan för infrastrukturen.
Hälsotester
Hälsoprober avgör vilka servrar som är tillgängliga för belastningsutjämning i en back-end-pool. Application Gateway använder en hälsokontroll 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älsokontroll skapar Application Gateway en standardkontroll som väntar i 30 sekunder innan den avgör att en server inte är tillgänglig. Hälsoavsökningar säkerställer att trafiken inte dirigeras till en icke-svarande eller misslyckad webbslutpunkt i bakgrundspoolen.
Automatisk skalning
Application Gateway stöder automatisk skalning och kan skalas upp eller ned baserat på ändrade trafikbelastningsmönster. Automatisk skalning tar också bort kravet på att välja en distributionsstorlek eller instansantal under etableringen.
WebSocket- och HTTP/2-trafik
Application Gateway har inbyggt stöd för WebSocket- och HTTP/2-protokollen. 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 för att fungera via traditionella HTTP-portar på 80 och 443.