Sådan fungerer Azure Application Gateway

  • 5 minutter

Azure Application Gateway har en række komponenter, der kombineres for på en sikker måde at distribuere og udføre belastningsjusteringsanmodninger på tværs af en gruppe webservere. Application Gateway indeholder følgende komponenter:

diagram, der viser Komponenter til Azure Application Gateway.

  • frontend-IP-adresse: Klientanmodninger modtages via en frontend-IP-adresse. Du kan konfigurere Application Gateway til at have en offentlig IP-adresse, en privat IP-adresse eller begge dele. Programgatewayen kan ikke have mere end én offentlig IP-adresse og én privat IP-adresse.
  • lyttere: Application Gateway bruger en eller flere lyttere til at modtage indgående anmodninger. En lytter accepterer trafik, der ankommer på en angivet kombination af protokol, port, vært og IP-adresse. Hver lyttefunktion sender anmodninger til en back end-pulje af servere, der følger de distributionsregler, du angiver. En lytter kan være Basic eller Multi-site. En Basic- lytter distribuerer kun en anmodning baseret på stien i URL-adressen. En lytter med flere websteder kan også dirigere anmodninger ved hjælp af værtsnavnelementet i URL-adressen. Lyttere håndterer også TLS/SSL-certifikater til sikring af dit program mellem brugeren og Application Gateway.
  • routingregler: En distributionsregel binder en lytter til back end-grupperne. En regel angiver, hvordan værtsnavnet og stielementerne i URL-adressen til en anmodning skal fortolkes, og sender anmodningen til den relevante back end-gruppe. En distributionsregel har også et tilknyttet sæt HTTP-indstillinger. Disse HTTP-indstillinger angiver, om (og hvordan) trafik krypteres mellem Application Gateway og back end-serverne. Andre konfigurationsoplysninger omfatter Protokol, Session-stickiness, Forbindelsesafløb, Timeoutperiode for anmodning og Tilstandstest.

Justering af belastning i Application Gateway

Application Gateway justerer automatisk de anmodninger, der sendes til serverne i hver back end-gruppe, ved hjælp af en round-robin-mekanisme. Belastningsjustering fungerer sammen med OSI Layer 7-routing, der implementeres af Application Gateway-routing, hvilket betyder, at den indlæser anmodninger baseret på de routingparametre (værtsnavne og stier), der bruges af Application Gateway-reglerne. Til sammenligning fungerer andre belastningsjusteringer, f.eks. Azure Load Balancer, på OSI Layer 4-niveauet og distribuerer trafik baseret på IP-adressen for målet for en anmodning.

Du kan konfigurere sessionens stickiness, hvis du har brug for at sikre, at alle anmodninger om en klient i den samme session dirigeres til den samme server i en back end-gruppe.

Firewall til webprogram

WAF (web application firewall) er en valgfri komponent, der håndterer indgående anmodninger, før de når en lytter. Firewallen til webprogrammet kontrollerer hver anmodning for mange almindelige trusler baseret på OWASP (Open Web Application Security Project). Almindelige trusler omfatter: SQL-injektion, scripting på tværs af websteder, kommandoinjektion, smugling af HTTP-anmodninger, opdeling af HTTP-svar, medtagelse af fjernfiler, robotter, crawlere og scannere samt HTTP-protokolovertrædelser og uregelmæssigheder.

OWASP definerer et sæt generiske regler for registrering af angreb. Disse regler kaldes CRS (Core Rule Set). Regelsættene gennemgås løbende, efterhånden som angreb udvikler sig i sofistikeret form. WAF understøtter fire regelsæt: CRS 3.2, 3.1, 3.0 og 2.2.9. CRS 3.1 er standard. Hvis det er nødvendigt, kan du vælge kun at vælge bestemte regler i et regelsæt, der er målrettet mod visse trusler. Derudover kan du tilpasse firewallen for at angive, hvilke elementer i en anmodning der skal undersøges, og begrænse størrelsen af meddelelser for at forhindre, at massive uploads overbelaster dine servere.

Back end-puljer

En back end-gruppe er en samling webservere, der kan består af: et fast sæt virtuelle maskiner, et skaleringssæt for en virtuel maskine, en app, der hostes af Azure App Services, eller en samling af lokale servere.

Hver back end-pulje har en tilknyttet belastningsjustering, der distribuerer arbejde på tværs af gruppen. Når du konfigurerer gruppen, skal du angive IP-adressen eller navnet på hver webserver. Alle serverne i back end-gruppen skal konfigureres på samme måde, herunder deres sikkerhedsindstillinger.

Hvis du bruger TLS/SSL, har back end-gruppen en HTTP-indstilling, der refererer til et certifikat, der bruges til at godkende back end-serverne. Gatewayen krypterer trafikken igen ved hjælp af dette certifikat, før den sendes til en af dine servere i back end-gruppen.

Hvis du bruger Azure App Service til at hoste back end-programmet, behøver du ikke at installere certifikater i Application Gateway for at oprette forbindelse til back end-gruppen. Al kommunikation krypteres automatisk. Application Gateway har tillid til serverne, fordi Azure administrerer dem.

Application Gateway bruger en regel til at angive, hvordan de meddelelser, den modtager på den indgående port, dirigeres til serverne i back end-gruppen. Hvis serverne bruger TLS/SSL, skal du konfigurere reglen til at angive:

  • At dine servere forventer trafik via HTTPS-protokollen.
  • Hvilket certifikat der skal bruges til at kryptere trafik og godkende forbindelsen til en server.

Distribution af programgateway

Når gatewayen distribuerer en klientanmodning til en webserver i back end-gruppen, bruger den et sæt regler, der er konfigureret for gatewayen til at bestemme, hvor anmodningen skal gå hen. Der er to primære metoder til routing af denne klientanmodningstrafik: stibaseret routing og routing med flere websteder.

Stibaseret routing

Stibaseret routing sender anmodninger med forskellige URL-stier til forskellige grupper af back end-servere. Du kan f.eks. dirigere anmodninger med stien /video/* til en back-end-gruppe, der indeholder servere, der er optimeret til at håndtere videostreaming, og sende /billeder/* anmodninger til en pulje af servere, der håndterer billedhentning.

diagram, der viser stibaseret routing i Azure Application Gateway.

Routing med flere websteder

Routing med flere websteder konfigurerer mere end ét webprogram på den samme application gateway-forekomst. I en konfiguration med flere websteder registrerer du flere DNS-navne (CNAMEs) for IP-adressen på programgatewayen og angiver navnet på hvert websted. Application Gateway bruger separate lyttere til at vente på anmodninger for hvert websted. Hver lytter sender anmodningen til en anden regel, som kan dirigere anmodningerne til servere i en anden back end-gruppe. Du kan f.eks. dirigere alle anmodninger om http://contoso.com til servere i én back end-gruppe og anmodninger om http://fabrikam.com til en anden back end-gruppe. I følgende diagram vises denne konfiguration:

diagram, der viser routing med flere websteder i Azure Application Gateway.

Konfigurationer med flere websteder er nyttige til understøttelse af multitenantprogrammer, hvor hver lejer har sit eget sæt virtuelle maskiner eller andre ressourcer, der hoster et webprogram.

Application Gateway-routing indeholder også disse funktioner:

  • omdirigering. Omdirigering kan bruges til et andet websted eller fra HTTP til HTTPS.
  • omskrive HTTP-headere. HTTP-headere gør det muligt for klienten og serveren at overføre parameteroplysninger med anmodningen eller svaret.
  • Brugerdefinerede fejlsider. Application Gateway giver dig mulighed for at oprette brugerdefinerede fejlsider i stedet for at vise standardfejlsider. Du kan bruge din egen branding og dit eget layout ved hjælp af en brugerdefineret fejlside.

TLS/SSL-afslutning

Når du afslutter TLS/SSL-forbindelsen på programgatewayen, aflaster den CPU-intensive TLS/SSL-afslutningsarbejdsbelastning fra dine servere. Du behøver heller ikke at installere certifikater og konfigurere TLS/SSL på dine servere.

Hvis du har brug for end-to-end-kryptering, kan Application Gateway dekryptere trafikken på gatewayen ved hjælp af din private nøgle og derefter kryptere igen med den offentlige nøgle for tjenesten, der kører i back end-gruppen.

Trafik kommer ind i gatewayen via en front end-port. Du kan åbne mange porte, og Application Gateway kan modtage meddelelser på en af disse porte. En lytter er det første, din trafik møder, når du går ind i gatewayen via en port. Lytteren er konfigureret til at lytte efter et bestemt værtsnavn og en bestemt port på en bestemt IP-adresse. Lytteren kan bruge et TLS/SSL-certifikat til at dekryptere den trafik, der kommer ind i gatewayen. Lyttefunktionen bruger derefter en regel, som du definerer, til at dirigere de indgående anmodninger til en back end-gruppe.

diagram, der viser TLS/SSL-afslutning i Azure Application Gateway.

Hvis du eksponerer dit websted eller webprogram via programgatewayen, betyder det også, at du ikke direkte forbinder dine servere til internettet. Du eksponerer kun port 80 eller port 443 på programgatewayen, som derefter videresendes til back end-gruppeserveren. I denne konfiguration er dine webservere ikke direkte tilgængelige fra internettet, hvilket reducerer angrebsoverfladen i din infrastruktur.

Sundhedsmæssige sonder

Tilstandstest afgør, hvilke servere der er tilgængelige til belastningsjustering i en back end-gruppe. Application Gateway bruger en tilstandssonde til at sende en anmodning til en server. Når serveren returnerer et HTTP-svar med en statuskode mellem 200 og 399, anses serveren for at være i orden. Hvis du ikke konfigurerer en tilstandssonde, opretter Application Gateway en standardsonde, der venter i 30 sekunder, før det besluttes, at en server ikke er tilgængelig. Tilstandstest sikrer, at trafikken ikke dirigeres til et webslutpunkt, der ikke svarer eller mislykkes, i back end-gruppen.

Automatisk skalering

Application Gateway understøtter automatisk skalering og kan skaleres op eller ned baseret på ændrede trafikbelastningsmønstre. Automatisk skalering fjerner også kravet om at vælge en udrulningsstørrelse eller antallet af forekomster under klargøring.

WebSocket- og HTTP/2-trafik

Application Gateway leverer indbygget understøttelse af WebSocket- og HTTP/2-protokollerne. Protokollerne WebSocket og HTTP/2 muliggør fuld duplex-kommunikation mellem en server og en klient via en tcp-forbindelse, der har kørt i lang tid. Denne type kommunikation er mere interaktiv mellem webserveren og klienten og kan være tovejs uden behov for polling som påkrævet i HTTP-baserede implementeringer. Disse protokoller har lave omkostninger (i modsætning til HTTP) og kan genbruge den samme TCP-forbindelse til flere anmodninger/svar, hvilket resulterer i en mere effektiv ressourceudnyttelse. Disse protokoller er designet til at fungere over traditionelle HTTP-porte på 80 og 443.