Så här fungerar en programgateway
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.
Programgatewayen 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 IP-adress, ett protokoll och ett portnummer för anslutningar från klienter till programgatewayen.
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 utvärderas och loggas begäran, men vidarebefordras fortfarande till serverdelsservern.
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 Internetuppkopplad programgateway kan matchas offentligt med 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 eller Privat DNS zon bör domännamnet vara internt matchbart 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.
Kommentar
Regler bearbetas i den ordning de visas i portalen för V1 SKU.
När programgatewayen väljer serverdelspoolen skickar den begäran till en av de felfria serverdelsservrarna i poolen (y.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 resursallokeringsalgoritm för att dirigera begäranden mellan felfria 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.
Kommentar
Om serverdelspoolen:
- Är en offentlig slutpunkt använder programgatewayen sin offentliga IP-adress för klientdelen 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 matchningsbart FQDN eller en privat IP-adress, dirigerar programgatewayen begäran till serverdelsservern med hjälp av instansens privata IP-adresser.
- Innehåller en extern slutpunkt eller ett externt matchningsbart FQDN, dirigerar programgatewayen begäran till serverdelsservern med hjälp av den offentliga IP-adressen för klientdelen. Om undernätet innehåller tjänstslutpunkter dirigerar programgatewayen 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-matchning för serverdelsserver
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 att DNS-sökningen inte kan ta emot ett svar eller om posten inte längre finns, fortsätter gatewayen att använda den senast kända IP-adressen(es). 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 är identiska och svarar konsekvent med samma DNS-värden.
- 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 x-forwarded-for-header ä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. Det här huvudet är användbart i Azure-webbplatsintegrering, där den inkommande värdrubriken ändras innan trafiken dirigeras till serverdelen. Om sessionstillhörighet är aktiverat som ett alternativ lägger den till en gatewayhanterad tillhörighetscookie.
X-appgw-trace-id är ett unikt guid som genereras av programgatewayen för varje klientbegäran och som visas i den vidarebefordrade begäran till medlemmen i serverdelspoolen. Guid består av 32 alfanumeriska tecken som presenteras utan bindestreck (till exempel: ac882cd65a2712a0fe1289ec2bb6aee7). Det här guid:et kan användas för att korrelera en begäran som tas emot av programgatewayen och initieras till en medlem i serverdelspoolen via egenskapen transactionId i diagnostikloggar.
Du kan konfigurera programgatewayen för att ändra begärande- och svarshuvuden och URL:en med hjälp av Skriv om HTTP-huvuden och URL eller för att ändra URI-sökvägen med hjälp av en inställning 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.