Application Gateway-värdtjänster för flera webbplatser

  • Artikel

Med värdtjänster för flera webbplatser kan du konfigurera fler än ett webbprogram på samma port för programgatewayer med offentliga lyssnare. Den här funktionen gör att du kan konfigurera en mer effektiv topologi för dina distributioner genom att lägga till fler än 100 webbplatser i samma appgateway. Varje webbplats kan dirigeras till en egen serverdelspool. Tänk dig till exempel att de tre domänerna contoso.com, fabrikam.com och adatum.com pekar på appgatewayens IP-adress. Du skapar tre lyssnare för flera platser och konfigurerar varje lyssnare enligt respektive inställningar för port och protokoll.

Du kan också definiera värdnamn med jokertecken i lyssnare för flera platser och upp till 5 värdnamn per lyssnare. Mer information finns i värdnamn med jokertecken i lyssnaren.

Multi-site Application Gateway

Viktigt!

Regler bearbetas i den ordning de visas i portalen för V1-SKU:n. För v2 SKU använder du regelprioritet för att ange bearbetningsordningen. Vi rekommenderar starkt att konfigurera lyssnare för flera platser första innan du konfigurerar en grundläggande lyssnare. Detta säkerställer att trafik dirigeras till rätt serverdel. Om en grundläggande lyssnare visas först och matchar en inkommande begäran kommer den att bearbetas av den lyssnaren.

Begäranden om http://contoso.com dirigeras till ContosoServerPool och http://fabrikam.com dirigeras till FabrikamServerPool.

På samma sätt kan du vara värd för flera underdomäner i samma överordnade domän på samma programgatewaydistribution. Du kan till exempel vara värd för http://blog.contoso.com och http://app.contoso.com på en enda programgatewaydistribution.

Utvärderingsordning för begärandedirigeringsregler

När du använder lyssnare för flera platser för att säkerställa att klienttrafiken dirigeras till den korrekta serverdelen är det viktigt att routningsreglerna för begäran finns i rätt ordning. Om du till exempel har två lyssnare med associerade värdnamn *.contoso.com och shop.contoso.commåste lyssnaren med shop.contoso.com värdnamnet bearbetas innan lyssnaren med *.contoso.com. Om lyssnaren med *.contoso.com bearbetas först tas ingen klienttrafik emot av den mer specifika shop.contoso.com lyssnaren.

Ordningen på regler kan upprättas genom att ange ett prioritetsfältvärde för de routningsregler för begäran som är associerade med lyssnarna. Du kan ange ett heltalsvärde från 1 till 20 000 med 1 som högsta prioritet och 20 000 som lägsta prioritet. Om inkommande klienttrafik matchar med flera lyssnare används begärandedirigeringsregeln med högsta prioritet för att hantera begäran. Varje routningsregel för begäran måste ha ett unikt prioritetsvärde.

Prioritetsfältet påverkar bara utvärderingsordningen för en routningsregel för begäranden. Detta ändrar inte ordningen på utvärderingen av sökvägsbaserade regler i en PathBasedRouting routningsregel för begäranden.

Kommentar

Om du vill använda regelprioritet måste du ange fältvärden för regelprioritet för alla befintliga routningsregler för begäranden. När fältet regelprioritet används måste alla nya routningsregler som skapas ha ett fältvärde för regelprioritet som en del av konfigurationen.

Viktigt!

Från och med API-version 2021-08-01 är fältet regelprioritet ett obligatoriskt fält i reglerna för begärandedirigering. Regelprioritetsfältvärden för befintliga routningsregler för begäranden, baserat på aktuell utvärderingsordning som en del av det första PUT-anropet, fylls i automatiskt om några konfigurationsuppdateringar tillämpas med api-version 2021-08-01 och senare, portalen, Azure PowerShell och Azure CLI. Framtida uppdateringar av routningsregler för begäran måste ha fältet regelprioritet som en del av konfigurationen.

Jokertecken värdnamn i lyssnaren

Application Gateway tillåter värdbaserad routning med hjälp av HTTP(S)-lyssnare för flera webbplatser. Nu kan du använda jokertecken som asterisk (*) och frågetecken (?) i värdnamnet och upp till 5 värdnamn per HTTP(S)-lyssnare för flera webbplatser. Exempel: *.contoso.com

Med ett jokertecken i värdnamnet kan du matcha flera värdnamn i en enda lyssnare. Kan till exempel *.contoso.com matcha med ecom.contoso.com, b2b.contoso.com och customer1.b2b.contoso.com så vidare. Med hjälp av en matris med värdnamn kan du konfigurera mer än ett värdnamn för en lyssnare för att dirigera begäranden till en serverdelspool. Till exempel kan en lyssnare innehålla contoso.com, fabrikam.com som accepterar begäranden för båda värdnamnen.

Wildcard Listener

Kommentar

Den här funktionen är endast tillgänglig för Standard_v2 och WAF_v2 SKU för Application Gateway.

I Azure PowerShell måste du använda -HostNames i stället -HostNameför . Med HostNames kan du nämna upp till 5 värdnamn som kommaavgränsade värden och använda jokertecken. Exempel: -HostNames "*.contoso.com","*.fabrikam.com"

I Azure CLI måste du använda --host-names i stället för --host-name. Med värdnamn kan du nämna upp till 5 värdnamn som kommaavgränsade värden och använda jokertecken. Exempel: --host-names "*.contoso.com,*.fabrikam.com"

I Azure-portalen, under lyssnaren för flera webbplatser, måste du välja värdtypen Flera/Jokertecken för att nämna upp till fem värdnamn med tillåtna jokertecken.

Wildcard Listener UI

Tillåtna tecken i fältet värdnamn

  • (A-Z,a-z,0-9) - alfanumeriska tecken
  • - - bindestreck eller minus
  • . - period som avgränsare
  • * – kan matcha med flera tecken i det tillåtna intervallet
  • ? – kan matcha med ett enda tecken i det tillåtna intervallet

Villkor för användning av jokertecken och flera värdnamn i en lyssnare

  • Du kan bara nämna upp till 5 värdnamn i en enda lyssnare
  • Asterisk * kan bara nämnas en gång i en komponent i ett domännamn eller värdnamn. Till exempel component1*.component2*.component3. (*.contoso-*.com) är giltig.
  • Det kan bara finnas upp till två asterisker * i ett värdnamn. Till exempel *.contoso.* är giltigt och *.contoso.*.*.com är ogiltigt.
  • Det kan bara finnas högst 4 jokertecken i ett värdnamn. Till ????.contoso.comexempel är , w??.contoso*.edu.* giltiga, men ????.contoso.* är ogiltiga.
  • Att använda asterisk * och frågetecken ? tillsammans i en komponent i ett värdnamn (*? eller **?* ) är ogiltigt. Till exempel *?.contoso.com och **.contoso.com är ogiltiga.

Överväganden och begränsningar vid användning av jokertecken eller flera värdnamn i en lyssnare

  • SSL-avslutning och SSL från slutpunkt till slutpunkt kräver att du konfigurerar protokollet som HTTPS och laddar upp ett certifikat som ska användas i lyssnarkonfigurationen. Om det är en lyssnare för flera platser kan du också ange värdnamnet, vanligtvis är detta CN för SSL-certifikatet. När du anger flera värdnamn i lyssnaren eller använder jokertecken måste du tänka på följande:
    • Om det är ett värdnamn för jokertecken som *.contoso.com måste du ladda upp ett jokerteckencertifikat med CN som *.contoso.com
    • Om flera värdnamn nämns i samma lyssnare måste du ladda upp ett SAN-certifikat (Alternativa namn för certifikatmottagare) med de CN som matchar de värdnamn som nämns.
  • Du kan inte använda ett reguljärt uttryck för att nämna värdnamnet. Du kan bara använda jokertecken som asterisk (*) och frågetecken (?) för att bilda värdnamnsmönstret.
  • För hälsokontroll för serverdelen kan du inte associera flera anpassade avsökningar per HTTP-inställningar. I stället kan du avsöka en av webbplatserna på serverdelen eller använda "127.0.0.1" för att avsöka serverdelsserverns localhost. Men när du använder jokertecken eller flera värdnamn i en lyssnare dirigeras begäranden för alla angivna domänmönster till serverdelspoolen beroende på regeltyp (grundläggande eller sökvägsbaserad).
  • Egenskapen "värdnamn" tar en sträng som indata, där du bara kan nämna ett domännamn som inte är jokertecken. Egenskapen "hostnames" tar en matris med strängar som indata, där du kan nämna upp till 5 domännamn med jokertecken. Båda dessa egenskaper kan inte användas samtidigt.

Mer information om hur du konfigurerar värdnamn för jokertecken i en lyssnare med flera webbplatser finns i Skapa flera webbplatser med Hjälp av Azure PowerShell eller Azure CLI .

Lyssnare för flera platser för TLS- och TCP-protokolllyssnare

Funktionen för flera webbplatser är också tillgänglig för Layer4-proxy, men endast för dess TLS-lyssnare. Du kan dirigera trafiken för varje program till dess serverdelspool genom att ange domännamn i TLS-lyssnaren. För funktionen för multisitefunktionen på TLS-lyssnare använder Application Gateway SNI-värdet (Server Name Indication) (klienterna presenterar främst SNI-tillägg för att hämta rätt TLS-certifikat). En TLS-lyssnare med flera platser skulle välja det här SNI-värdet från TLS-handskakningsdata för en inkommande anslutning och dirigera anslutningen till lämplig serverdelspool. TCP-anslutningen har i sig inget begrepp som värdnamn eller domännamn. Därför är detta inte tillgängligt för TCP-lyssnare.

Värdhuvuden och servernamnsindikator (SNI)

Det finns tre vanliga mekanismer för att aktivera värdtjänster för flera platser i samma infrastruktur.

  1. Flera webbprogram på varsin unik IP-adress.
  2. Använd värdnamn för att ha flera webbprogram på samma IP-adress.
  3. Använd olika portar för att har flera webbprogram på samma IP-adress.

För närvarande stöder Application Gateway en enda offentlig IP-adress där den lyssnar efter trafik. Så flera program, var och en med sin egen IP-adress stöds för närvarande inte.

Application Gateway stöder flera program som var och en lyssnar på olika portar, men det här scenariot kräver att programmen accepterar trafik på portar som inte är standard.

Application Gateway förlitar sig på HTTP 1.1 värdhuvuden för att ha mer än en webbplats på samma offentliga IP-adress och port. Webbplatserna som finns på programgatewayen kan också ha stöd för TLS-avlastning med TLS-tillägget (Server Name Indication) (SNI). Det här scenariot innebär att klientens webbläsare och serverdels-webbservergrupp måste ha stöd för HTTP/1.1 och TLS-tillägg som det definieras i RFC 6066.

Nästa steg

Lär dig hur du konfigurerar värdtjänster för flera platser i Application Gateway

Se Resource Manager-mall med flera platsvärdar för en mallbaserad distribution från slutpunkt till slutpunkt.