Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Den här artikeln förklarar hur en programgateway accepterar inkommande begäranden och dirigerar dem till serverdelen.
Hur en programgateway accepterar en begäran
Innan en klient skickar en begäran till en programgateway löses domännamnet för programgatewayen med hjälp av en DNS-server (Domain Name System). Azure styr DNS-posten eftersom alla programgatewayer finns i azure.com domänen.
Azure DNS returnerar IP-adressen till klienten, som är klientdelens IP-adress för programgatewayen.
Applikationsgatewayen accepterar inkommande trafik på en eller flera lyssnare. En lyssnare är en logisk entitet som söker efter anslutningsbegäranden. Den har konfigurerats med en frontend-IP-adress, ett protokoll och ett portnummer för anslutningar från klienter till applikationsgatewayen.
Om en brandvägg för webbprogram (WAF) används kontrollerar programgatewayen begärandehuvudena och brödtexten, om de finns, mot WAF-regler. Den här åtgärden avgör om begäran är giltig eller ett säkerhetshot. Om begäran är giltig dirigeras den till serverdelen. Om begäran inte är giltig och WAF är i förebyggande läge blockeras den som ett säkerhetshot. Om den är i identifieringsläge loggas och utvärderas begäran, men vidarebefordras fortfarande till serverdelen.
Azure Application Gateway kan användas som en intern programlastbalanserare eller som en internetuppkopplad programlastbalanserare. En internetuppkopplad programgateway använder offentliga IP-adresser. DNS-namnet på en internetansluten applikationsgateway är offentligt upplösbart till dess offentliga IP-adress. Därför kan internetriktade programgatewayer dirigera klientbegäranden från Internet.
Interna programgatewayer använder endast privata IP-adresser. Om du använder en anpassad DNS-zon eller Privat DNS-zon bör domännamnet vara internt lösbart till Application Gatewayens privata IP-adress. Därför kan interna lastbalanserare endast dirigera begäranden från klienter med åtkomst till ett virtuellt nätverk för programgatewayen.
Hur en programgateway dirigerar en begäran
Om en begäran är giltig och inte blockeras av WAF utvärderar programgatewayen routningsregeln för begäran som är associerad med lyssnaren. Den här åtgärden avgör vilken serverdelspool som begäran ska dirigeras till.
Baserat på routningsregeln för begäran avgör programgatewayen om alla begäranden på lyssnaren ska dirigeras till en specifik serverdelspool, dirigera begäranden till olika serverdelspooler baserat på URL-sökvägen eller omdirigera begäranden till en annan port eller extern plats.
Anteckning
Regler bearbetas i den ordning de visas i portalen för V1 SKU.
När programgatewayen väljer backpoolen skickar den begäran till en av de friska servrarna i poolen (y.y.y.y). Serverns hälsotillstånd bestäms av en hälsoavsökning. Om serverdelspoolen innehåller flera servrar använder programgatewayen en rundgångsalgoritm för att dirigera begäranden mellan friska servrar. Den här belastningen balanserar begäranden på servrarna.
När programgatewayen har fastställt serverdelsservern öppnas en ny TCP-session med serverdelsservern baserat på HTTP-inställningar. HTTP-inställningar anger protokoll, port och andra routningsrelaterade inställningar som krävs för att upprätta en ny session med serverdelsservern.
Porten och protokollet som används i HTTP-inställningarna avgör om trafiken mellan programgatewayen och serverdelsservrarna är krypterad (vilket åstadkommer TLS från slutpunkt till slutpunkt) eller är okrypterad.
När en programgateway skickar den ursprungliga begäran till serverdelsservern respekterar den alla anpassade konfigurationer som görs i HTTP-inställningarna relaterade till att åsidosätta värdnamnet, sökvägen och protokollet. Den här åtgärden upprätthåller cookiebaserad sessionstillhörighet, anslutningsdränering, val av värdnamn från serverdelen och så vidare.
Anteckning
Om backend-poolen:
- Är en offentlig slutpunkt, använder programgatewayen sin offentliga frontend-IP-adress för att nå servern. Om det inte finns någon offentlig IP-adress för klientdelen tilldelas en för den utgående externa anslutningen.
- Innehåller ett internt lösbart FQDN eller en privat IP-adress, applikationsgatewayen dirigerar begäran till backendservern med hjälp av instansens privata IP-adresser.
- Innehåller en extern slutpunkt eller ett FQDN som kan lösas externt, dirigerar applikationsgatewayn begäran till backendservern med hjälp av frontendens offentliga IP-adress. Om undernätet innehåller tjänstslutpunkter, dirigerar applikationsgatewayen begäran till tjänsten via dess privata IP-adress. DNS-matchning baseras på en privat DNS-zon eller anpassad DNS-server, om den är konfigurerad, eller så använder den standard-DNS som tillhandahålls av Azure. Om det inte finns någon offentlig IP-adress för klientdelen tilldelas en för den utgående externa anslutningen.
DNS-upplösning för backendserver
När en serverdelspools server har konfigurerats med ett fullständigt domännamn (FQDN) utför Application Gateway en DNS-sökning för att hämta domännamnets IP-adresser. IP-värdet lagras i programgatewayens cache så att det kan nå målen snabbare när inkommande begäranden hanteras.
Application Gateway behåller den här cachelagrade informationen för perioden som motsvarar DNS-postens TTL (time to live) och utför en ny DNS-sökning när TTL upphör att gälla. Om en gateway identifierar en ändring i IP-adressen för dess efterföljande DNS-fråga börjar den dirigera trafiken till det uppdaterade målet. Om det uppstår problem, som till exempel att DNS-sökningen inte kan ta emot ett svar eller om posten inte längre finns, fortsätter gateway att använda de senast kända IP-adresserna. Detta säkerställer minimal påverkan på datasökvägen.
Viktigt!
- När du använder anpassade DNS-servrar med Application Gateways virtuella nätverk är det viktigt att alla servrar svarar konsekvent med samma DNS-värden. När en instans av din Application Gateway utfärdar en DNS-fråga använder den värdet från servern som svarar först.
- Användare av lokala anpassade DNS-servrar måste säkerställa anslutningen till Azure DNS via Azure DNS Private Resolver (rekommenderas) eller en virtuell DNS-vidarebefordrare när de använder en Privat DNS zon för privat slutpunkt.
Ändringar i begäran
Application Gateway infogar ytterligare sex huvuden till alla begäranden innan begäranden vidarebefordras till serverdelen. Dessa rubriker är x-forwarded-for, x-forwarded-port, x-forwarded-proto, x-original-host, x-original-url och x-appgw-trace-id. Formatet för rubriken x-forwarded-for är en kommaavgränsad lista över IP:port.
Giltiga värden för x-forwarded-proto är HTTP eller HTTPS. X-forwarded-port anger porten där begäran nådde programgatewayen. X-original-host-huvudet innehåller den ursprungliga värdrubriken som begäran kom med. Den här rubriken är användbar i Azure-webbplatsintegration, där den inkommande värdrubriken ändras innan trafiken dirigeras till backenden. Om sessionstillhörighet är aktiverat som ett alternativ lägger den till en gatewayhanterad tillhörighetscookie.
X-appgw-trace-id är en unik GUID som genereras av applikationsgatewayn för varje klientbegäran och presenteras i den vidarebefordrade förfrågan till en medlem i backend-poolen. GUID består av 32 alfanumeriska tecken som presenteras utan bindestreck (till exempel: ac882cd65a2712a0fe1289ec2bb6aee7). den här guiden kan användas för att korrelera en begäran som tas emot av applikationsgatewayen och initieras till en backend pool-medlem via egenskapen transactionId i Diagnostikloggar.
Du kan konfigurera applikationsgatewayen för att ändra begärande- och svarshuvuden samt URL:en genom att använda Skriv om HTTP-huvuden och URL, eller för att ändra URI-sökvägen genom inställningen för åsidosättning av sökväg. Men om de inte är konfigurerade för att göra det skickas alla inkommande begäranden till serverdelen.