Azure-toepassing-gateway configureren
Application Gateway heeft een reeks onderdelen die worden gecombineerd om aanvragen te routeren naar een groep webservers en om de status van deze webservers te controleren.
Front-endconfiguratie
U kunt de toepassingsgateway configureren voor een openbaar IP-adres, een privé-IP-adres of beide. Een openbaar IP-adres is vereist wanneer u een back-end host die clients via internet moeten openen via een virtueel IP-adres met internet.
Back-endconfiguratie
De back-endpool word gebruikt om aanvragen te routeren naar de back-endservers die de aanvraag verwerken. U kunt een lege back-endpool maken met uw toepassingsgateway en vervolgens back-enddoelen toevoegen aan de back-endpool. Doelen kunnen NIC's, openbare en privé-IP-adressen en virtuele-machineschaalsets omvatten.
Statuscontroles configureren
Azure-toepassing Gateway controleert standaard de status van alle resources in de back-endpool en verwijdert automatisch alle resources die als beschadigd worden beschouwd uit de pool. Application Gateway blijft de exemplaren met slechte status bewaken en voegt deze weer aan de goede back-end-adrespool toe zodra ze beschikbaar komen en beantwoorden aan de statuscontroles. Application Gateway verzendt standaard de statustests met dezelfde poort die is gedefinieerd in de back-end-HTTP-instellingen. Een aangepaste testpoort kan worden geconfigureerd met behulp van een aangepaste statustest.
Het bron-IP-adres dat de Application Gateway gebruikt voor statustests, is afhankelijk van de back-endpool:
- Als het serveradres in de back-endpool een openbaar eindpunt is, is het bronadres het openbare IP-adres van de toepassingsgateway.
- Als het serveradres in de back-endpool een privé-eindpunt is, is het bron-IP-adres afkomstig uit de privé-IP-adresruimte van het toepassingsgatewaysubnet.
Standaardstatustest
Een toepassingsgateway configureert automatisch een standaardstatustest wanneer u geen aangepaste testconfiguraties instelt. Het bewakingsgedrag werkt door een HTTP GET-aanvraag te verzenden naar de IP-adressen of FQDN die zijn geconfigureerd in de back-endpool. Voor standaardtests als de http-instellingen van de back-end zijn geconfigureerd voor HTTPS, gebruikt de test HTTPS om de status van de back-endservers te testen.
Bijvoorbeeld: U configureert uw toepassingsgateway voor het gebruik van back-endservers A, B en C voor het ontvangen van HTTP-netwerkverkeer op poort 80. De standaardstatuscontrole test de drie servers elke 30 seconden voor een goed functionerend HTTP-antwoord met een time-out van 30 seconden voor elke aanvraag. Een in orde HTTP-antwoord heeft een statuscode tussen 200 en 399. In dit geval ziet de HTTP GET-aanvraag voor de statustest er als volgt http://127.0.0.1/uit.
Als de standaardtestcontrole mislukt voor server A, stopt de toepassingsgateway met het doorsturen van aanvragen naar deze server. De standaardtest blijft elke 30 seconden controleren op server A. Wanneer server A met succes reageert op één aanvraag vanaf een standaardstatustest, wordt de aanvragen opnieuw door de toepassingsgateway doorgestuurd naar de server.
Standaardinstellingen voor statustest
De volgende tabel bevat de standaardinstellingen voor de statustest:
| Testeigenschap | Value | Beschrijving |
|---|---|---|
| Test-URL | <protocol>://127.0.0.1:<port>/ |
Het protocol en de poort worden overgenomen van de back-end-HTTP-instellingen waaraan de test is gekoppeld |
| Interval | 30 | De hoeveelheid tijd in seconden die moet worden gewacht voordat de volgende statustest wordt verzonden. |
| Time-out | 30 | De hoeveelheid tijd in seconden wacht de toepassingsgateway op een testantwoord voordat de test als beschadigd wordt gemarkeerd. Als een test als in orde retourneert, wordt de bijbehorende back-end onmiddellijk gemarkeerd als in orde. |
| Drempelwaarde voor beschadigde status | 3 | Bepaalt hoeveel tests moeten worden verzonden voor het geval er een fout opgetreden is in de reguliere statustest. In de v2-SKU wachten de statustests op het testinterval voordat ze opnieuw worden gecontroleerd. De back-endserver is gemarkeerd als onbereikbaar nadat het aantal opeenvolgende testfouten de drempelwaarde voor beschadigde status heeft bereikt. |
Testintervallen
Alle exemplaren van Application Gateway testen de back-end onafhankelijk van elkaar. Dezelfde testconfiguratie is van toepassing op elk Application Gateway-exemplaar. Als de testconfiguratie bijvoorbeeld om de 30 seconden statustests verzendt en de toepassingsgateway twee exemplaren heeft, verzenden beide exemplaren de statustest om de 30 seconden.
Als er meerdere listeners zijn, test elke listener de back-end onafhankelijk van elkaar.
Aangepaste statustest
Met aangepaste tests hebt u gedetailleerdere controle over de statuscontrole. Wanneer u aangepaste tests gebruikt, kunt u een aangepaste hostnaam, URL-pad, testinterval en hoeveel mislukte antwoorden moeten worden geaccepteerd voordat u het exemplaar van de back-endpool markeert als beschadigd, enzovoort.
Aangepaste statustestinstellingen
De volgende tabel bevat definities voor de eigenschappen van een aangepaste statustest.
| Testeigenschap | Beschrijving |
|---|---|
| Naam | Naam van de test. Deze naam wordt gebruikt om de test te identificeren en te raadplegen in de HTTP-instellingen van de back-end. |
| Protocol | Protocol dat wordt gebruikt om de test te verzenden. Deze eigenschap moet overeenkomen met het protocol dat is gedefinieerd in de HTTP-instellingen voor de back-end. |
| Host | Hostnaam voor het verzenden van de test. |
| Pad | Relatief pad van de test. Een geldig pad begint met '/'. |
| Poort | Indien gedefinieerd, wordt deze eigenschap gebruikt als doelpoort. Anders wordt dezelfde poort gebruikt als de HTTP-instellingen waaraan deze is gekoppeld. Deze eigenschap is alleen beschikbaar in de v2-SKU. |
| Interval | Testinterval in seconden. Deze waarde is het tijdsinterval tussen twee opeenvolgende tests |
| Time-out | Time-out van de test in seconden. Als er binnen deze time-outperiode geen geldig antwoord wordt ontvangen, wordt de test gemarkeerd als mislukt. |
| Drempelwaarde voor beschadigde status | Aantal nieuwe pogingen voor de test. De back-endserver wordt gemarkeerd nadat het aantal opeenvolgende testfouten de drempelwaarde voor beschadigde status heeft bereikt. |
Testkoppeling
Standaard wordt een HTTP(S)-antwoord met statuscode tussen 200 en 399 als in orde beschouwd. Aangepaste statustests ondersteunen bovendien twee overeenkomende criteria. Overeenkomende criteria kunnen worden gebruikt om desgewenst de standaardinterpretatie te wijzigen van wat een gezonde reactie maakt.
Hier volgen overeenkomende criteria:
- Overeenkomst met HTTP-antwoordstatuscode: testkoppelingscriterium voor het accepteren van door de gebruiker opgegeven HTTP-antwoordcode of antwoordcodebereiken. Afzonderlijke door komma's gescheiden antwoordstatuscodes of een bereik van statuscode wordt ondersteund.
- Overeenkomst met HTTP-antwoordtekst: testkoppelingscriterium waarmee wordt gekeken naar de hoofdtekst van het HTTP-antwoord en overeenkomsten met een door de gebruiker opgegeven tekenreeks. De overeenkomst zoekt alleen naar aanwezigheid van de door de gebruiker opgegeven tekenreeks in antwoordtekst en is geen volledige overeenkomst met reguliere expressies.
Criteria voor overeenkomst kunnen worden opgegeven met behulp van de cmdlet New-AzApplicationGatewayProbeHealthResponseMatch.
Listeners configureren
Een listener is een logische entiteit die controleert op binnenkomende verbindingsaanvragen met behulp van de poort, het protocol, de host en het IP-adres. Wanneer u een listener configureert, moet u waarden invoeren die overeenkomen met de overeenkomende waarden in de binnenkomende aanvraag op de gateway.
Wanneer u een toepassingsgateway maakt met behulp van Azure Portal, maakt u ook een standaardlistener door het protocol en de poort voor de listener te kiezen. U kunt kiezen of u HTTP2-ondersteuning wilt inschakelen voor de listener. Nadat u de toepassingsgateway hebt gemaakt, kunt u de instellingen van die standaardlistener (appGatewayHttpListener) bewerken of nieuwe listeners maken.
Type listener
Wanneer u een nieuwe listener maakt, moet u kiezen tussen basic en meerdere sites.
- Basis: alle aanvragen worden geaccepteerd en doorgestuurd naar back-endpools.
- Meerdere sites: aanvragen doorsturen naar verschillende back-endpools op basis van de hostheader- of hostnamen. U moet een hostnaam opgeven die overeenkomt met de binnenkomende aanvraag.
Volgorde van verwerking van listeners
Voor de v1-SKU worden aanvragen gematcht volgens de volgorde van de regels en het type listener. Voor de v2-SKU worden listeners met meerdere sites verwerkt voordat basislisteners worden verwerkt.
Front-end-IP-adres
Kies het front-end-IP-adres dat u aan deze listener wilt koppelen. De listener luistert naar binnenkomende aanvragen op dit IP-adres.
Front-endpoort
Kies de front-endpoort. Selecteer een bestaande poort of maak een nieuwe poort. Kies een waarde uit het toegestane bereik van poorten. U kunt niet alleen bekende poorten gebruiken, zoals 80 en 443, maar elke toegestane aangepaste poort die geschikt is. Een poort kan worden gebruikt voor openbare listeners of privé-listeners.
Protocol
Kies HTTP of HTTPS:
- HTTP: verkeer tussen de client en de toepassingsgateway is niet versleuteld.
- HTTPS: maakt TLS-beëindiging of end-to-end TLS-versleuteling mogelijk. De TLS-verbinding wordt beëindigd op de toepassingsgateway. Verkeer tussen de client en de toepassingsgateway wordt versleuteld. Als u end-to-end TLS-versleuteling wilt, moet u HTTPS kiezen en de back-end-HTTP-instelling configureren.
Als u TLS-beëindiging en end-to-end TLS-versleuteling wilt configureren, moet u een certificaat toevoegen aan de listener om de toepassingsgateway in staat te stellen een symmetrische sleutel af te leiden. De symmetrische sleutel wordt gebruikt voor het versleutelen en ontsleutelen van het gatewayverkeer. Het gatewaycertificaat moet de PFX-indeling (Personal Information Exchange) hebben. Met deze indeling kunt u de persoonlijke sleutel die de gateway gebruikt voor het versleutelen en ontsleutelen van verkeer exporteren.
Overzicht van omleiding
U kunt application gateway gebruiken om verkeer om te leiden. De gateway heeft een algemeen omleidingsmechanisme waarmee verkeer dat op de ene listener is ontvangen, kan worden omgeleid naar een andere listener of naar een externe site. Omleiding vereenvoudigt de configuratie van toepassingen en optimaliseert het resourcegebruik. Deze omleidingstypen worden ondersteund:
- 301 Permanente omleiding
- 302 Gevonden
- 303 Zie overige
- 307 Tijdelijke omleiding
Ondersteuning voor Application Gateway-omleiding biedt de volgende mogelijkheden:
- Globale omleiding: omleidt van de ene listener naar een andere listener op de gateway. Hierdoor is HTTP-naar-HTTPS-omleiding op een site mogelijk.
- Padgebaseerde omleiding: hiermee schakelt u http-naar-HTTPS-omleiding alleen in op een specifiek sitegebied, bijvoorbeeld een winkelwagengebied dat wordt aangeduid door /cart/*.
- Omleiding naar externe site: vereist een nieuw omleidingsconfiguratieobject, waarmee de doellistener of externe site wordt opgegeven waarnaar omleiding gewenst is. Het configuratie-element ondersteunt ook opties voor het toevoegen van het URI-pad en de queryreeks aan de omgeleide URL. De omleidingsconfiguratie is via een nieuwe regel gekoppeld aan de bronlistener.
Regels voor doorsturen van Application Gateway aanvragen
Een regel voor het doorsturen van aanvragen is een belangrijk onderdeel van een toepassingsgateway, omdat hiermee wordt bepaald hoe verkeer op de listener moet worden gerouteerd. De regel verbindt de listener, de back-endserverpool en de HTTP-instellingen voor de back-end.
Wanneer een listener een aanvraag accepteert, stuurt de regel voor aanvraagroutering de aanvraag door naar de back-end of stuurt deze elders om. Als de aanvraag wordt doorgestuurd naar de back-end, wordt met de regel voor aanvraagroutering gedefinieerd naar welke back-endserverpool deze moet worden doorgestuurd. De regel voor aanvraagroutering bepaalt ook of de headers in de aanvraag moeten worden herschreven. Eén listener kan aan één regel worden gekoppeld.
Er zijn twee typen regels voor aanvraagroutering:
Basis: Alle aanvragen voor de gekoppelde listener (bijvoorbeeld blog.contoso.com/*) worden doorgestuurd naar de bijbehorende back-endpool met behulp van de bijbehorende HTTP-instelling.
Op pad gebaseerd: met deze routeringsregel kunt u de aanvragen op de gekoppelde listener routeren naar een specifieke back-endpool, op basis van de URL in de aanvraag. Als het pad van de URL in een aanvraag overeenkomt met het padpatroon in een padregel, routeert de regel die aanvraag. Het padpatroon wordt alleen toegepast op het URL-pad, niet op de queryparameters. Als het URL-pad in een listener-aanvraag niet overeenkomt met een van de padregels, wordt de aanvraag doorgestuurd naar de standaard back-endpool en HTTP-instellingen.
HTTP-instellingen
Een toepassingsgateway routeert verkeer naar de back-endservers (opgegeven in de regel voor aanvraagroutering die HTTP-instellingen bevat) met behulp van het poortnummer, protocol en andere instellingen die in dit onderdeel worden beschreven.
De poort en het protocol dat wordt gebruikt in de HTTP-instellingen bepalen of het verkeer tussen de toepassingsgateway en back-endservers is versleuteld (end-to-end TLS) of niet-versleuteld.
Dit onderdeel wordt ook gebruikt voor het volgende:
Bepaal of een gebruikerssessie op dezelfde server moet worden bewaard met behulp van de sessieaffiniteit op basis van cookies.
Verwijder de leden van de back-endpool probleemloos met behulp van het leegmaken van verbindingen.
Koppel een aangepaste test om de back-endstatus te controleren, stel het time-outinterval van de aanvraag in, overschrijf de hostnaam en het pad in de aanvraag en geef één selectiegemak op om instellingen voor de App Service-back-end op te geven.