Veelgestelde vragen over Azure Front Door

Azure Front Door is een Application Delivery Network (ADN) als een service, die verschillende taakverdelingsmogelijkheden van laag 7 biedt voor uw toepassingen. Deze service biedt dynamische siteversnelling (DSA) samen met wereldwijde taakverdeling met failover in bijna realtime. Het is een maximaal beschikbare en schaalbare service die volledig wordt beheerd door Azure.

Azure Front Door biedt ondersteuning voor dynamische siteversnelling (DSA), TLS/SSL-offloading en end-to-end-TLS, Web Application Firewall, sessie-affiniteit op basis van cookies, routering op basis van URL-pad, gratis certificaten en beheer van meerdere domeinen, en meer. Zie Overzicht van Azure Front Door voor een volledige lijst met ondersteunde Azure Front Door.

Hoewel zowel Front Door als Application Gateway load balancers van laag 7 (HTTP/HTTPS) zijn, is het belangrijkste verschil dat Front Door een wereldwijde service is, terwijl Application Gateway een regionale service is. Hoewel Front Door kunt laden tussen uw verschillende schaaleenheden/clusters/stempeleenheden tussen regio's, kunt u met Application Gateway een load balancer maken tussen uw VM's/containers, enzovoort, binnen de schaaleenheid.

De belangrijkste scenario's waarom u een Application Gateway achter Front Door zijn:

• Front Door kunnen padgebaseerde taakverdeling alleen uitvoeren op globaal niveau, maar als iemand verkeer nog verder binnen het virtuele netwerk (VNET) wil laden, moet deze taakverdeling Application Gateway.
• Omdat Front Door niet werkt op VM-/containerniveau, kan er dus geen verbinding worden leeg gemaakt. Met Application Gateway kunt u echter verbindingsafvoeren.
• Met een Application Gateway achter Front Door, kan 100% TLS/SSL-offload worden bereikt en alleen HTTP-aanvragen binnen het virtuele netwerk (VNET) worden gerouteren.
• Front Door en Application Gateway bieden beide ondersteuning voor sessie-affiniteit. Hoewel Front Door daaropvolgend verkeer van een gebruikerssessie naar hetzelfde cluster of dezelfde back-end in een bepaalde regio kan leiden, kunnen Application Gateway het verkeer naar dezelfde server binnen het cluster sturen.

Azure Front Door een openbare VIP of een openbaar beschikbare DNS-naam nodig om het verkeer naar door te laten gaan. Het implementeren van een Azure Load Balancer achter Front Door is een veelvoorkomende use-case.

Azure Front Door ondersteunt HTTP, HTTPS en HTTP/2.

HTTP/2-protocolondersteuning is alleen beschikbaar voor clients die verbinding maken Azure Front Door verbinding maken. De communicatie met back-enden in de back-endpool gaat via HTTP/1.1. HTTP/2-ondersteuning is standaard ingeschakeld.

Back-endpools kunnen bestaan uit Storage, web-app, Kubernetes-exemplaren of een andere aangepaste hostnaam die openbare connectiviteit heeft. Azure Front Door vereist dat de back-adressen worden gedefinieerd via een openbaar IP-adres of een openbaar om te lossen DNS-hostnaam. Leden van back-endpools kunnen zich in verschillende zones, regio's of zelfs buiten Azure bevinden, zolang ze openbare connectiviteit hebben.

Azure Front Door is een wereldwijde service en is niet gekoppeld aan een specifieke Azure-regio. De enige locatie die u moet opgeven tijdens het maken van een Front Door is de locatie van de resourcegroep. Dit is in feite het opgeven waar de metagegevens voor de resourcegroep worden opgeslagen. Front Door resource zelf wordt gemaakt als een globale resource en de configuratie wordt wereldwijd geïmplementeerd op alle edge-locaties.

Zie Edge-locaties voor Azure Front Door volledige lijst Azure Front Door edge-locaties.

Azure Front Door is een wereldwijd gedistribueerde multi-tenantservice. De infrastructuur voor Front Door wordt gedeeld met alle klanten. Als u echter een Front Door maakt, definieert u de specifieke configuratie die vereist is voor uw toepassing en worden er geen wijzigingen aangebracht in uw Front Door van invloed op andere Front Door configuraties.

Ja. In feite biedt Azure Front Door ondersteuning voor omleiding van host, pad en queryreeks, evenals onderdeel van URL-omleiding. Meer informatie over URL-omleiding.

Routes voor uw Front Door worden niet geordend en er wordt een specifieke route geselecteerd op basis van de beste overeenkomst. Meer informatie over Hoe Front Door aanvragen matcht met een regel voor doorsturen.

Als u uw toepassing wilt vergrendelen om alleen verkeer van uw specifieke Front Door te accepteren, moet u IP-ACL's voor uw back-up instellen en vervolgens het verkeer op uw back-end beperken tot de specifieke waarde van de header 'X-Azure-FDID' die door Front Door. Deze stappen worden hieronder beschreven:

• Configureer IP-ACL's voor uw back-Azure Front Door om alleen verkeer van de back-Azure Front Door-IP-adresruimte en de infrastructuurservices van Azure te accepteren. Raadpleeg de ONDERSTAANDe IP-gegevens voor het ACL-gebruik van uw back-end:

  • Raadpleeg de sectie AzureFrontDoor.Backend in Azure IP-bereiken en servicetags voor het ip-adresbereik van de back-Front Door. U kunt ook de servicetag AzureFrontDoor.Backend gebruiken in uw netwerkbeveiligingsgroepen.
  • De basisinfrastructuurservices van Azure via gevirtualiseerde HOST-IP-adressen: 168.63.129.16 en 169.254.169.254

  Waarschuwing

  Front Door back-end-IP-ruimte kan later worden gewijzigd, maar voordat dat gebeurt, zorgen we ervoor dat we zouden zijn geïntegreerd met Azure IP-adresbereiken en servicetags. U wordt aangeraden u te abonneren op Azure IP-adresbereiken en servicetags voor wijzigingen of updates.

• Zoek de waarde Front Door ID in de sectie Overzicht op Front Door portalpagina. Vervolgens kunt u filteren op de binnenkomende header X-Azure-FDID die door Front Door naar uw back-Front Door wordt verzonden met die waarde om ervoor te zorgen dat alleen uw eigen specifieke Front Door-exemplaar is toegestaan (omdat de bovenstaande IP-bereiken worden gedeeld met andere Front Door-exemplaren van andere klanten).

• Pas regelfiltering toe op uw back-endwebserver om verkeer te beperken op basis van de resulterende headerwaarde 'X-Azure-FDID'. Houd er rekening mee dat sommige services Azure App Service deze mogelijkheid voor filteren op basis van headers bieden zonder dat u uw toepassing of host hoeft te wijzigen.

  Hier is een voorbeeld voor Microsoft Internet Information Services (IIS):

  <?xml version="1.0" encoding="UTF-8"?>
  <configuration>
      <system.webServer>
          <rewrite>
              <rules>
                  <rule name="Filter_X-Azure-FDID" patternSyntax="Wildcard" stopProcessing="true">
                      <match url="*" />
                      <conditions>
                          <add input="{HTTP_X_AZURE_FDID}" pattern="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" negate="true" />
                      </conditions>
                      <action type="AbortRequest" />
                  </rule>
              </rules>
          </rewrite>
      </system.webServer>
  </configuration>
  

• Azure Front Door biedt ook ondersteuning voor de servicetag AzureFrontDoor.Frontend, die de lijst bevat met IP-adressen die clients gebruiken bij het maken van verbinding met Front Door. U kunt de servicetag AzureFrontDoor.Frontend gebruiken wanneer u het uitgaande verkeer controleert dat verbinding mag maken met services die zijn geïmplementeerd achter Azure Front Door. Azure Front Door ondersteunt ook een extra servicetag, AzureFrontDoor.FirstParty, om intern te integreren met andere Azure-services. Zie beschikbare servicetags voor meer informatie over de use cases Azure Front Door servicetags.

Als u Application Gateway als back-Azure Front Door gebruikt, kan de controle op de header worden uitgevoerd in een aangepaste X-Azure-FDID WAF-regel. Zie Aangepaste v2-regels maken en gebruiken op Web Application Firewall v2 voor meer Application Gateway.

Het anycast-IP-adres voor de front-Front Door wordt doorgaans niet gewijzigd en blijft mogelijk statisch voor de levensduur van de Front Door. Er zijn echter geen garanties voor hetzelfde. Neem geen directe afhankelijkheden van het IP-adres.

Nee, Azure Front Door momenteel geen ondersteuning voor statische of toegewezen front-end anycast-IP's.

Ja, Azure Front Door de headers X-Forwarded-For, X-Forwarded-Host en X-Forwarded-Proto ondersteund. Voor X-Forwarded-For als de header al aanwezig was, Front Door het IP-adres van de clientsocke er aan toe. Anders wordt de header toegevoegd met het IP-adres van de clientsocke als waarde. Voor X-Forwarded-Host en X-Forwarded-Proto wordt de waarde overschrijven.

Meer informatie over de Front Door ondersteunde HTTP-headers.

De meeste nieuwe Front Door maken en updates duren ongeveer 3 tot 20 minuten om te implementeren op al onze edge-locatie wereldwijd.

Updates voor routes of back-endpools, enzovoort, verlopen naadloos en veroorzaken geen downtime (als de nieuwe configuratie juist is). Certificaatupdates zijn ook atomisch en veroorzaken geen uitval, tenzij u overschakelt van 'AFD beheerd' naar 'Uw eigen certificaat gebruiken' of omgekeerd.

Azure Front Door (AFD) vereist een openbaar IP-adres of een openbaar omkeerbare DNS-naam om verkeer te kunnen omgeleid. Het antwoord is dus dat geen enkele AFD rechtstreeks kan worden gerouteerd binnen een virtueel netwerk, maar als u een Application Gateway of Azure Load Balancer tussendoor gebruikt, lost u dit scenario op.

Meer informatie over alle gedocumenteerde time-outs en limieten voor Azure Front Door.

De meeste configuratie-updates voor de regels-engine worden minder dan 20 minuten voltooid. U kunt ervan uit gaan dat de regel van kracht wordt zodra de update is voltooid.

Azure Front Door en Azure CDN kunnen niet samen worden geconfigureerd omdat beide services dezelfde Azure Edge-sites gebruiken bij het reageren op aanvragen.

Azure Front Door is een wereldwijd gedistribueerd multi-tenantplatform met enorme capaciteit om te voldoen aan de schaalbaarheidsbehoeften van uw toepassing. Geleverd vanaf de rand van het wereldwijde netwerk van Microsoft, biedt Front Door wereldwijde taakverdelingsmogelijkheden waarmee u een fail over uw hele toepassing of zelfs afzonderlijke microservices in regio's of verschillende clouds kunt toepassen.

Alle Front Door gemaakt na september 2019 gebruiken TLS 1.2 als het standaard minimum.

Front Door ondersteunt TLS-versies 1.0, 1.1 en 1.2. TLS 1.3 wordt nog niet ondersteund. Raadpleeg Azure Front Door end-to-end TLS voor meer informatie.

Azure Front Door resources, zoals Front Door profielen, worden routeringsregels niet gefactureerd in uitgeschakeld. WAF-beleidsregels en -regels worden gefactureerd, zelfs als deze zijn uitgeschakeld.

Zie Bewaking van metrische gegevens en logboeken voor meer informatie over logboeken en andere diagnostische Front Door.

Diagnostische logboeken worden naar het opslagaccount van klanten gestroomd en klanten kunnen het retentiebeleid instellen op basis van hun voorkeur. Diagnostische logboeken kunnen ook worden verzonden naar een Event Hub of Azure Monitor logboeken. Zie diagnostische Azure Front Door voor meer informatie.

Auditlogboeken zijn beschikbaar voor Azure Front Door. Klik in de portal op Activiteitenlogboek in de menublade van uw Front Door toegang te krijgen tot het auditlogboek.

Ja, Azure Front Door ondersteunt waarschuwingen. Waarschuwingen worden geconfigureerd voor metrische gegevens.

Volgende stappen

• Lees hoe u een Front Door maakt.
• Lees hoe Front Door werkt.