Sådan fungerer en applikationsgateway

  • 16/11/2019
  • 4 minutter at læse
    • a
    • j
    • D
    • s
    • v
    • +2

Denne artikel forklarer, hvordan en applikationsgateway accepterer indgående anmodninger og videresender dem til backend’en.

Hvordan en applikationsgateway accepterer en anmodning

Hvordan en applikationsgateway accepterer en anmodning

  1. Hvor en klient sender en anmodning til en applikationsgateway, opløser den domænenavnet for applikationsgatewayen ved hjælp af en DNS-server (Domain Name System). Azure kontrollerer DNS-posten, fordi alle applikationsgateways er i azure.com-domænet.

  2. Azure DNS returnerer IP-adressen til klienten, som er applikationsgatewayens front-end-IP-adresse.

  3. Applikationsgatewayen accepterer indgående trafik på en eller flere lyttere. En lytter er en logisk enhed, der kontrollerer, om der er anmodninger om forbindelse. Den er konfigureret med en frontend-IP-adresse, protokol og portnummer til forbindelser fra klienter til applikationsgatewayen.

  4. Hvis der er en webapplikationsfirewall (WAF) i brug, kontrollerer applikationsgatewayen anmodningshovedet og kroppen, hvis den er til stede, i forhold til WAF-reglerne. Denne handling afgør, om anmodningen er en gyldig anmodning eller en sikkerhedstrussel. Hvis anmodningen er gyldig, videresendes den til backend’en. Hvis anmodningen ikke er gyldig, og WAF er i Prevention-tilstand, bliver den blokeret som en sikkerhedstrussel. Hvis den er i Detection-tilstand, evalueres og logges anmodningen, men den videresendes stadig til backend-serveren.

Azure Application Gateway kan bruges som en intern applikationsloadbalancer eller som en internetvendt applikationsloadbalancer. En internetvendt applikationsgateway bruger offentlige IP-adresser. DNS-navnet på en internetvendt applikationsgateway kan opløses offentligt til dens offentlige IP-adresse. Derfor kan internetvendte applikationsgateways videresende klientforespørgsler fra internettet.

Interne applikationsgateways bruger kun private IP-adresser. Hvis du bruger en brugerdefineret eller privat DNS-zone, skal domænenavnet kunne opløses internt til programgatewayens private IP-adresse. Interne load-balancere kan derfor kun videresende anmodninger fra klienter med adgang til et virtuelt netværk for applikationsgatewayen.

Sådan videresender en applikationsgateway en anmodning

Hvis en anmodning er gyldig og ikke blokeret af WAF, evaluerer applikationsgatewayen den regel for videresendelse af anmodninger, der er knyttet til lytteren. Denne handling bestemmer, hvilken backend-pulje anmodningen skal videresendes til.

Baseret på reglen om videresendelse af anmodninger bestemmer applikationsgatewayen, om alle anmodninger på lytteren skal videresendes til en bestemt backend-pulje, om anmodninger skal videresendes til forskellige backend-puljer baseret på URL-stien, eller om anmodninger skal videresendes til en anden port eller et eksternt websted.

Note

Reglerne behandles i den rækkefølge, de er opført i portalen for v1 SKU.

Når applikationsgatewayen vælger backend-puljen, sender den anmodningen til en af de sunde backend-servere i puljen (y.y.y.y.y). Serverens tilstand bestemmes ved hjælp af en sundhedssonde. Hvis backend-puljen indeholder flere servere, bruger applikationsgatewayen en round-robin-algoritme til at videresende anmodningerne mellem sunde servere. Dette afbalancerer belastningen af anmodningerne på serverne.

Når applikationsgatewayen bestemmer backend-serveren, åbner den en ny TCP-session med backend-serveren baseret på HTTP-indstillingerne. HTTP-indstillingerne angiver den protokol, port og andre routing-relaterede indstillinger, der er nødvendige for at oprette en ny session med backend-serveren.

Porten og protokollen, der anvendes i HTTP-indstillingerne, bestemmer, om trafikken mellem applikationsgatewayen og backend-serverne er krypteret (hvorved der opnås end-to-end TLS) eller er ukrypteret.

Når en applikationsgateway sender den oprindelige anmodning til backend-serveren, respekterer den enhver brugerdefineret konfiguration, der er foretaget i HTTP-indstillingerne i forbindelse med tilsidesættelse af værtsnavn, sti og protokol. Denne handling opretholder cookie-baseret sessionsaffinitet, forbindelsestømning, valg af værtsnavn fra backend-serveren osv.

Note

Hvis backend-puljen:

  • Er et offentligt slutpunkt, bruger applikationsgatewayen sin offentlige IP på frontenden til at nå serveren. Hvis der ikke er en offentlig frontend-IP-adresse, tildeles der en til den udgående eksterne forbindelse.
  • Indeholder et FQDN, der kan opløses internt, eller en privat IP-adresse, videresender programgatewayen anmodningen til backend-serveren ved hjælp af dens private IP-adresser.
  • Indeholder et eksternt slutpunkt eller et FQDN, der kan opløses eksternt, videresender programgatewayen anmodningen til backend-serveren ved hjælp af dens offentlige frontend-IP-adresse. DNS-opløsningen er baseret på en privat DNS-zone eller en brugerdefineret DNS-server, hvis den er konfigureret, eller den bruger den standard-DNS, der leveres af Azure. Hvis der ikke er en offentlig frontend-IP-adresse, tildeles der en til den udgående eksterne forbindelse.

Modifikationer til anmodningen

En applikationsgateway indsætter fire ekstra headere til alle anmodninger, før den videresender anmodningerne til backend-serveren. Disse headere er x-forwarded-for, x-forwarded-proto, x-forwarded-port og x-original-host. Formatet for x-forwarded-for-headeren er en kommasepareret liste af IP:port.

De gyldige værdier for x-forwarded-proto er HTTP eller HTTPS. X-forwarded-port angiver den port, hvor anmodningen nåede frem til programgatewayen. X-original-host-headeren indeholder den oprindelige værtsheader, som anmodningen ankom med. Denne header er nyttig i Azure-webstedsintegration, hvor den indgående værtsheader ændres, før trafikken videresendes til backend’en. Hvis sessionsaffinitet er aktiveret som en mulighed, tilføjes der en gateway-administreret affinitetscookie.

Du kan konfigurere applikationsgatewayen til at ændre anmodnings- og svarheadere og URL ved hjælp af Rewrite HTTP-headere og URL eller til at ændre URI-stien ved hjælp af en path-override-indstilling. Medmindre det er konfigureret til dette, bliver alle indgående anmodninger dog proxyet til backend’en.

Lær om applikationsgatewaykomponenter

Skriv en kommentar