Globale indstillinger for HTTP Farm Profile

HTTP-profilen styrer indholdsskift på OSI-modellens applikationslag for både HTTP- og HTTPS-protokollerne. Vi har designet profilen til at distribuere indgående webtrafik på tværs af flere backend-ressourcer intelligent ved at analysere indholdet af indgående anmodninger og træffe routingbeslutninger baseret på specifikke parametre såsom URL, cookies, headers og sessionsoplysninger. Med disse oplysninger kan vi dirigere trafik til de relevante (tjenester) serverpuljer.

I øverste højre afsnit har vi 2 indikatorer. handlinger knapper og Status.

• Firkantet kasse: Når der klikkes, stopper LSLB-farmen.
• Opdater knappen: Når der klikkes på den, genstarter Farmen.
• Knappen Afspil: Hvis gården er slukket eller inaktiv, starter den, når der klikkes på den.

Hver af farverne beskrevet nedenfor repræsenterer Status af en given Farm:

• Grøn: Betyder, at gården er UP og alle backends kører. Det kan også betyde, at en omdirigering er konfigureret.
• Rød: Betyder, at gården er DOWN eller det er ufunktionelt.
• Sort: Angiver en KRITISK skade. Opstår normalt, når en farm er OP, men der ikke er nogen tilgængelig backend, eller de kan være i vedligeholdelsestilstand.
• Blå: Viser, når der er en PROBLEM. Farmen kan køre, men når mindst én backend er nede.
• Orange: Repræsenterer VEDLIGEHOLDELSE. Viser, når farmen kører, men mindst én backend er i vedligeholdelsestilstand.

Disse farvekoder er de samme over hele den grafiske brugergrænseflade. Find en kortfattet forklaring om dem i LSLB Gårdsektion.

I HTTP (S) farms profilen, HTTP header X-Forwarded-For udfyldes som standard med klientens IP-adresse.

Ligesom en omvendt proxy administrerer hver HTTP(S)-farm (eller virtuel tjeneste) flere tjenester, derfor kan én virtuel HTTP-IP og et portpar håndtere mere end én belastningsbalanceret webservice. Derfor er der et afsnit, der hedder tjeneste inden for HTTP-farmen, der tilbyder virtuel værtsfleksibilitet og tillader oprettelse af lister over backends for hver tjeneste.

Hver HTTP(S)-tjeneste bruger regulære udtryk (for virtuel vært og URL-mønster) i PCRE for at lede efter specifikke mønstre i HTTP-headerne for de indgående forbindelser. Hvis mønsteret passer i begge virtuel vært URL-mønster felt, vil backends på den pågældende tjeneste behandle disse indgående forbindelser.

Grundlæggende konfiguration

Følgende er de grundlæggende parametre for HTTP/S-farmprofilen.

Navn. Dette er et navn, der let identificerer en gård. For at ændre et navn på en given gård, skal du stoppe det først. Sørg for, at et nyt navn ikke allerede er i brug.

Virtual IP og Port. Disse er de virtuelle IP-adresser og portpar, hvorfra farmen vil lytte efter indgående forbindelser. Den nye IP-adresse og portkombination skal være ubrugt og tilgængelig, før den konfigureres.

Lytter. Dette felt specificerer lag 7-protokollen til at udføre indholdsskift.

• HTTP. Den virtuelle tjeneste vil kun modtage almindeligt HTTP-indhold.
• HTTPS. Den virtuelle tjeneste vil modtage sikkert HTTP-indhold, administrere SSL-håndtryk, håndtere sikre chifferkonfigurationer, SSL-certifikater (wildcard eller SNI) osv. for at udføre SSL-offloading. Dette vil fritage de rigtige applikationsservere fra disse tunge opgaver.

HTTPS-parametre

HTTPS-parametre Kan findes nedenfor.

Deaktiver SSLV2, Deaktiver SSLV3, Deaktiver TLSV1, Deaktiver TLSV1.1, Deaktiver TLSV1.2. Hver af disse skifteknapper aktiverer eller deaktiverer den tilknyttede SSL- eller TLS-version. Det anbefales ikke at deaktivere nogen af ​​protokollerne, da dets tilknyttede cifre også vil blive deaktiveret.

ciphers. Dette afsnit er, hvor vi opbygger lister over ciphers, som vi bruger til at styrke en SSL-forbindelse. Før en klient og server begynder at udveksle oplysninger, der er beskyttet af TLS-protokollen, skal de sikkert udveksle eller aftale en krypteringsnøgle og en krypteringskode, der skal bruges ved kryptering af data.

For at konfigurere en chiffer til brug skal du vælge en af ​​følgende muligheder.

• Alle. Med denne kommando valgt, vil den lyttende HTTP(S)-farm administrere alle de tilgængelige krypteringspakker. Dette er standardindstillingen.
• høj sikkerhed. Denne kommando aktiverer følgende cifre:

  kEECDH+ECDSA+AES128:kEECDH+ECDSA+AES256:kEECDH+AES128:kEECDH+AES256:kEDH+AES128:kEDH+AES256:DES-CBC3-SHA:+SHA:!aNULL:!eNULL:!LOW:!kECDH:!DSS:!MD5:!EXP:!PSK:!SRP:!CAMELLIA:!SEED

  Aktivering af denne mulighed giver sikkerhed stærk nok til at bestå med en A+ karakter i SSL Labs .

• Brugerdefineret sikkerhed. Denne kommando lader dig tilpasse dine egne cifre gennem Brugerdefinerede chiffere felt.
• Brugerdefinerede cifre. Denne kommando lader dig tilpasse specifikke cifre til at tillade eller forbyde, når du laver en SSL-forbindelse. Det skal være en streng i samme format som i OpenSSL-cifre . Denne kommando vil blive vist hvis Brugerdefineret sikkerhed er indstillet.

Tilgængelige certifikater. Disse er de tilgængelige SSL-certifikater installeret på enheden. For at aktivere hver af dem skal du enten vælge certifikatet og klikke på pileknappen eller blot trække og slippe det fra boksen Tilgængelig til boksen Aktiveret. Du kan også aktivere/deaktivere flere certifikater eller endda dem alle.

Aktiverede certifikater. På denne liste vil du administrere de certifikater, der i øjeblikket er i brug af bedriften. Du kan flytte dem til toppen eller bunden med de dobbelte top/ned pile eller endda deaktivere dem alle. Tag hensyn til rækkefølgen af ​​certifikaterne. Hvis du konfigurerer et jokertegn før et værtscertifikat, vil jokertegnet blive brugt først.

Avancerede indstillinger

Omskriv overskriftsoverskrifter. Hvis aktiveret, er gården tvunget til at ændre Placering Content-placering overskrifter som svar til kunderne. Hvis de har værdien af ​​selve backend eller VIP, men med en anden protokol, vil svaret blive ændret til at vise den virtuelle vært i anmodningen. Hvis skifteknappen, aktiveret og sammenligne backends er aktiveret, vil kun backend-IP-adressen blive sammenlignet. Dette er vigtigt for at omdirigere en anmodning til en HTTPS-lytter på den samme server som HTTP-lytteren. Hvis dette felt er konfigureret i serviceafsnittet, vil dette direktiv blive ignoreret for den service.

HTTP verbs accepteret. Dette felt angiver de HTTP-metoder, der vil blive brugt til at validere HTTP-klientanmodninger. Hvis klientens anmodning ikke er tilladt, vil en fejl blive vist til klienten. Hvert verbum har yderligere lavere niveauer af verber.

• Standard HTTP-anmodning. Standard HTTP-anmodninger (GET, POST, HEAD).
• + udvidet HTTP-anmodning. udvidede HTTP-anmodninger (PUT, DELETE).
• + muligheder HTTP verbum. udvidede HTTP-anmodninger (PUT, DELETE).
• + standard WebDAV verb. standard WebDAV verb (LOCK, UNLOCK, PROPFIND, PROPPATCH, SØG, MKCOL, MOVE, COPY, OPTIONS, TRACE, MKACTIVITY, CHECKOUT, MERGE, REPORT).
• + MS-udvidelser WebDAV-verb. MS-udvidelser WebDAV-verb (SUBSCRIBE, UNSUBSCRIBE, NOTIFY, BPROPFIND, BPROPATCH, POLL, BMOVE, BCOPY, BDELETE, CONNECT).
• + MS RPC udvidelser verbs. MS RPC udvidelser verb (RPC_IN_DATA, RPC_OUT_DATA).

Ignorer 100 Fortsæt. Hvis markeret, er 100 Fortsæt ejendom deaktiveres. I henhold til HTTP 1.1-protokollen sendes formulardataene ikke med den oprindelige anmodning, når denne overskrift sendes. I stedet sendes denne overskrift til webserverens backend, som svarer med 100 (Fortsæt). Dette betyder, at serveren har modtaget anmodningsoverskrifter, og at klienten skal fortsætte med at sende anmodningsorganet (i tilfælde af en anmodning, hvortil et organ skal sendes, f.eks. En POST-anmodning). Hvis anmodningsorganet er stort, er det ineffektivt at sende det til en server, når en anmodning allerede er blevet afvist baseret på upassende overskrifter. For at få en server til at kontrollere, om anmodningen kunne accepteres på baggrund af anmodningens overskrifter alene, skal en klient sende Forvent: 100-fortsæt som en overskrift i sin oprindelige anmodning og kontrollere, om en 100 Fortsæt status kode er modtaget som svar, før du fortsætter (eller modtager 417 Forventning mislykkedes og fortsætter ikke).

Logs. Aktiver eller deaktiver farm traffic logs for at debug og analysere, hvad der passerer gennem belastningsbalanceren.

Backend forbindelses timeout. Denne værdi angiver den tid, gården skal vente på en forbindelse til backend i sekunder. Normalt vil det være ventetiden for stikkontakter. Som standard er denne værdi sat til 20 sekunder.

Frekvens for at kontrollere genoprettede bagsider. Dette er, hvor ofte load balanceren vil vente med at tjekke, om en backend er tilgængelig, og for at få ud af en sortlistet rigtig server, hvis den er oppe. Farmen vil tjekke backend med jævne mellemrum, når den rigtige server er markeret som nede, uanset om der er en ny klientforbindelse eller ej. Som standard er denne værdi sat til 10 sekunder.

Backend respons timeout. Denne værdi angiver den tid, gården skal vente på et svar fra backends i sekunder. Som standard er denne værdi sat til 45 sekunder.

Klient anmodning timeout. Denne værdi angiver den tid, gården skal vente på en kundes anmodning. Når denne timeout er nået uden at få nogen data fra klienten, vil forbindelsen blive afbrudt. Som standard er denne værdi sat til 30 sekunder.

HTTP-fejlmeddelelser

Personlige fejlmeddelelser. Farm-tjenesten vil vise en brugerdefineret besked på dit websted, når der registreres en webkodefejl fra de rigtige servere. En personlig HTML-side vil blive vist for fejlkoderne 414, 500, 501 og 503.

• 414: Request-URI Too Long. Dette er fejlmeddelelsen fra HTTP/S-profilen, hvis URI'en når det maksimalt tilladte antal tegn. Hvis du modtager denne fejl, skal du forkorte URL'ens længde.
• 500: Intern serverfejl. Dette er fejlmeddelelsen fra HTTP/S-profilen, hvis backend støder på en uventet kommando
• 501: Ikke implementeret. Dette er fejlmeddelelsen fra HTTP/S-profilen, hvis anmodningsudsagnsordet ikke administreres eller kendes af proxyen eller backend.
• 503 Service ikke tilgængelig. Dette er fejlmeddelelsen fra HTTP/S-profilen, hvis proxyen ikke finder en tilgængelig backend til anmodningen. Dette kan ske, når alle backends eller servere er nede, eller fordi det regulære udtryk i anmodningen ikke stemmer overens med nogen konfigureret tjeneste.
• WAF 403: Forbudt. Dette er fejlmeddelelsen fra HTTP/S-profilen, hvis WAF er aktiveret, og WAF-motoren afviser anmodningen.

Headers

I denne sektion kan vi tilføje, ændre eller slette anmodnings- og svarheadere globalt ved at anvende handlinger på alle de konfigurerede tjenester. Hvis en header er konfigureret i serviceafsnittet, vil denne konfiguration blive kasseret.

De handlinger, der skal bruges i dette afsnit, omfatter:

Opret regel. Der oprettes en global overskriftsregel.
Slette. En global overskriftsregel vil blive slettet.

Denne sektion giver os mulighed for at tilføje, ændre eller oprette Header anmodninger og svar som vist på billedet nedenfor.

Type.

• Anmodning: fjern header. Overskriftsmønster, der fjernes fra klientens HTTP-anmodninger.
• Anmodning: rediger header. Rediger overskriften fra klientens HTTP-anmodninger.
• Anmodning: Tilføj overskrift. Headeren, der vil blive tilføjet til klientens HTTP-anmodninger.
• Svar: Fjern header. Overskriftsmønster, der fjernes fra Backend HTTP-svaret.
• Svar: rediger header. Rediger overskriften fra Backend HTTP-svaret.
• Svar: Tilføj overskrift. Headeren, der vil blive tilføjet til Backend HTTP-svaret.

Tjenester Indstillinger

Tjenesterne inden for en LSLB-farm med en HTTP-profil giver indholdsskiftefunktioner til virtuelle webtjenester for at levere flere webtjenester og applikationer gennem samme virtuelle IP og PORT. Dette hjælper med at forene webapplikationer gennem et enkelt domæne, administrere virtuelle værter, Administrer webadresser, konfigurere omdirigeringer, konfigurere persistens og backends per service. Hver service inden for en LSLB-farm har forskellige egenskaber, sundhedstjek, persistens, header-styring og en backend-liste. Regulære udtryk kan bruges til at matche betingelser, der vil specificere den tjeneste, der skal bruges pr. anmodning.

Hver servicematch-tilstand vil blive kontrolleret af HTTP-farmprofilens kerne i prioritetstilstand (der kan ændres, hvis det er nødvendigt). Hvis ingen service matches, vil gårdkernen returnere en fejl (HTTP-fejl 503). Af denne grund er specifikke definitioner af flere tjenester tilladt. Hvis URL- og værtens felter ikke er defineret, vil alle anmodninger matche. HTTP-tjenestebetingelserne vil blive bestemt af en virtuel vært og/eller et URL-mønster.

For det første er det en nødvendighed at oprette og tilføje mindst én backend-server til en tjeneste. Når den nye tjeneste er anvendt, vil HTTP-tjenesterne blive evalueret fra top til bund i listerækkefølgen. Den første tjeneste, der matcher i Host- og/eller URL-feltet, behandler anmodningen. Disse servicebetingelser bestemmes af URL- eller værtsmønstre.

De servicebetingelser, der skal matches, er:

Virtual Host. Denne funktion giver dig mulighed for at definere en betingelse baseret på domænenavnet ved at bruge den samme virtuelle IP og port inden for en HTTP-farm. Hvis du vil fjerne denne betingelse, kan du lade feltet stå tomt. Regulære udtryk i PCRE-format understøttes i dette felt.

URL-mønster. Formålet med dette felt er at identificere en webservice baseret på den URL-sti, som klienten anmoder om. URL'en vil blive evalueret i forhold til et udpeget mønster, hvilket sikrer, at dens syntaks er korrekt. Hvis du ønsker at se bort fra denne betingelse, kan du lade feltet stå tomt. Regulære udtryk i PCRE-format understøttes i dette felt, hvilket giver mulighed for avanceret mønstermatchning.

Virtual Host URL-mønster værdier er regulære udtryk. Hvis den efterlades tom, vil enhver værdi matche. Begge felter skal matche, ellers springer det til næste tjeneste. Det anbefales at bruge mindst én, der fungerer som standard, hvis der ikke er nogen match fundet i bunden.

Omskriv overskriftsoverskrifter. Hvis den er aktiveret, er tjenesten tvunget til at ændre Placering Content-placering overskrifter som svar til kunderne. Hvis de har værdien af ​​selve backend'en eller VIP'en (men med en anden protokol), vil svaret blive ændret til at vise den virtuelle vært i anmodningen. Hvis vippeknappen aktiveret og sammenligne backends er aktiveret, så sammenlignes kun backend-IP-adressen. Dette er vigtigt, når du omdirigerer anmodninger til en HTTPS-lytter på samme server som HTTP-lytteren. Når aktivér og sammenligne backends er valgt, kaldes et flag Aktiver sti for omskriv placeringsoverskrifter vil være tilgængelig. Aktiver dette flag, hvis du arbejder med Omskriv URL'er. Denne værdi vil tvinge dig til at kontrollere URL-svarene og vil ændre svaret til originalen, hvis en regel er konfigureret i Omskriv URL'er. Hvis dette felt er aktiveret, vil det tilsidesætte det samme direktiv i den globale sektion.

Omdiriger

Hvis tjenesten har omdirigeringsindstillingen aktiveret, bruges backend-servere muligvis ikke, da alle anmodninger vil blive sendt til den angivne URL.

Omdirigeringstype. Der er to typer omdirigering: Standard Tilføj. Med Standard type, tages URL'en som en absolut vært og sti at omdirigere til. Med Tilføj type, vil den oprindelige anmodningssti blive tilføjet til værten og den sti, du har angivet.

Omdirigeringswebadresse. Denne parameter styrer, hvor klienten vil blive omdirigeret, efter at en anmodning er besvaret. Klientens anmodning besvares automatisk ved at omdirigere til en ny URL. Hvis du konfigurerer en omdirigeringsværdi, Konfigurer IKKE backends i denne tjeneste. Hvis Virtual Host og URL-mønster match, sender apparatet en HTTP Placeringsoverskrift svar til klienten for at blive omdirigeret til den konfigurerede webadresse.

Omdirigeringskode. Flere omdirigerings-HTTP-koder kunne bruges: 301 (flyttet permanent), 302 (flyttet midlertidigt) eller 307 (midlertidig omdirigering).

Vedholdenhed

Vedholdenhed. Denne parameter definerer, hvordan HTTP-tjenesten skal administrere klientsessionen, og hvilken HTTP-forbindelse, der skal kontrolleres for at opretholde sikre klientsessioner. Når en type vedholdenhedssession er valgt, vil dens Time To Live TTL(sekunder) blive vist.

• Ingen vedholdenhed. Gårdtjenesten vil ikke kontrollere klientsessionerne. HTTP- eller HTTPS-anmodningerne vil blive leveret til rigtige servere.
• IP: Klientadresse. Klientens IP-adresse vil blive brugt til at holde klientsessionerne åbne gennem de rigtige servere.
• GRUNDLÆGGENDE: Grundlæggende godkendelse. HTTP grundlæggende godkendelsesheaderen vil blive brugt til at styre klientsessionerne. For eksempel, når en webside anmoder om en grundlæggende godkendelse fra klienten, vil en HTTP-header indeholde en streng som følgende:

  		HTTP/1.1 401 Authorization Required
  		Server: HTTPd/1.0
  		Date: Sat, 27 Nov 2011 10:18:15 GMT
  		WWW-Authenticate: Basic realm="Secure Area"
  		Content-Type: text/HTML
  		Content-Length: 31
  

  Derefter svarer klienten med overskriften:

                  GET /private/index.html HTTP/1.1
  		Host: localhost
  		Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
  

  Denne grundlæggende godkendelsesstreng bruges som et id for sessionen til at identificere klientsessionen.

• PARM: En URI-parameter. En anden måde at identificere en klientsession på er via en URI-parameter adskilt fra et semikolon-tegn, som bruges som brugersessionidentifikator. I eksemplet http://www.example.com/private.php;EFD4Y7 parameteren vil blive brugt som sessionsidentifikator.
• URL: En anmodning parameter. Når sessions-id'et sendes gennem en GET-parameter med URL'en, indikerer denne parameter, at det navn, der er knyttet til klientsessions-id'et, vil være muligt. For eksempel en kundeanmodning som http://www.example.com/index.php?sid=3a5ebc944f41daa6f849f730f1 skal konfigureres med parameteren Persistence Session Identifier (sideværdi i dette eksempel) og persistens session time to life (TTL)
• Cookie: . Du vil være i stand til at vælge en HTTP-cookievariabel til at læse fra HTTP-headerne og bruge den til at vedligeholde klientsessioner i et givet tidsrum. Det konfigurerede cookienavn i identifikator for persistenssession felt er oprettet af en programmør og indlejret i en webside for at identificere klientsessionen, for eksempel:

                  GET /spec.html HTTP/1.1
                  Host: www.example.org
                  Cookie: sessionidexample=75HRSd4356SDBfrte
  

  Derudover bør Persistence session Time To Life(TTL) konfigureres. Denne værdi styrer den tid, som load balanceren sparer, når klienten og backend går uden aktivitet.

• HEADER: en anmodningsoverskrift. Et tilpasset HTTP-headerfelt kunne bruges til at identificere klientsessionen. Vedholdenhedssessionen Time To Life og persistenssessions-id'en skal konfigureres. For eksempel:

                 GET /index.html HTTP/1.1
                 Host: www.example.org
                 X-sess: 75HRSd4356SDBfrte
  

Cookie

Cookieindsats. Hvis det er defineret, vil belastningsbalanceren oprette en cookie i hvert svar med den relevante nøgle til backend. Selvom sessionstabellen tømmes, eller sessioner er deaktiveret, vil den korrekte backend blive valgt. Denne funktion undgår at ændre den rigtige serverkode for at oprette en sessionscookie.

Cookie navn Et navn på en cookie, der vil blive oprettet og tilføjet til klientanmodningen/backend-svaret. Det Cookie Sti er den URI eller den relative sti, hvor den nye cookie vil blive oprettet. For hele domænet skal tegnet indstilles. Cookie Domain er det domæne, hvor cookien skal oprettes. Langt om længe, Cookie TTL er antallet af sekunder, som cookien opbevares i hukommelsen mellem klienten og backend. Dette felt skal være større end 0. Og denne tid er relateret til tiden uden aktivitet. Efter at have læst de angivne sekunder uden nogen aktivitet vil persistenssessionen blive slettet.

Farmguardian

HTTP-farme giver et grundlæggende og native backend-sundhedstjek, men Farmguardian-konfigurationen anbefales til smartere heuristik-backend-sundhedstjek for at sikre, at applikationen er sund.

Nogle indbyggede eller tilpassede avancerede sundhedskontroller kan tildeles denne service fra den allerede oprettede farmguardian-kontrol.

For yderligere Farmguardian information gå til Overvågning >> Farmguardian sektion.

Bemærk, at efter at have valgt farmguardian, bliver den automatisk påført gården.

HTTPS backends. Dette afkrydsningsfelt angiver for farmen, at backend-serverne, der er defineret i den aktuelle tjeneste, bruger HTTPS-protokollen, så dataene bliver krypteret, før de sendes.

underliggende programmer

Vedrørende underliggende programmer, tillader HTTP-farmprofilen konfiguration af følgende egenskaber: Alle backends skal være IPv4 eller IPv6 og med samme IP-version som Farm VIP.

TILTAG. Brug følgende handlinger til at administrere backends:
For allerede oprettede backends:

• Aktivér vedligeholdelse. Brug denne handling, hvis backend tidligere var deaktiveret. At placere en rigtig server i vedligeholdelsestilstand betyder, at ingen nye forbindelser vil blive omdirigeret til den. Der er to metoder til at aktivere vedligeholdelsestilstanden:
  • Dræningstilstand. Holder etablerede forbindelser og vedholdenhed, hvis aktiveret, men vil ikke indrømme nye forbindelser.
  • Cut-tilstand. Sænker alle aktive forbindelser mod bagenden
• Deaktiver vedligeholdelse. Brug denne handling, når backend er i vedligeholdelsestilstand. Aktiver nye forbindelser til den rigtige server igen efter deaktivering af vedligeholdelsestilstand.
• Slette. Fjern konfigurationer af en valgt virtuel tjeneste. Aliaset vil ikke blive slettet, hvis der er nogen.

ALIAS. Backend alias, hvis et alias blev valgt.
IP. IP-adressen på en given backend.
PORT. Portnummeret på den aktuelle rigtige server.
TIMEOUT. Den tid, det tager en backend at svare. Denne værdi tilsidesætter parameteren for den globale Backend-forbindelsestimeout, men den er begrænset til denne valgte farm.
VÆGT. Vægtværdien for den aktuelle rigtige server. Mere vægt indikerer flere forbindelser leveret til den aktuelle backend. Som standard indstilles en vægtværdi på 1. De tilgængelige værdier er fra 1 til 9.
PRIORITET. Prioritetsværdien for den aktuelle rigtige server. Lavere værdier har mere prioritet. Standardværdien for serviceprioritet er 1. Når en backend fejler, øges serviceprioriteten med 1. Når backend'en er i live igen, reduceres serviceprioritetsværdien med 1. Aktive backends indeholder prioritetsværdier mindre end eller lig med serviceprioriteten .
FORBINDELSESGRÆNSE. Det maksimale antal samtidige forbindelser, som backend vil håndtere. Hvis denne værdi nås, vil nye forbindelser til backend blive blokeret, og klienten vil modtage en HTTP 503-fejl.

Tilføj backend-formular:

Gennem handlinger menuknappen, er følgende handlinger tilgængelige for en eller flere valgte backends:
Tilføj Backend. Denne kommando åbner backend-oprettelsesformularen.
Ovennævnte handlinger: Aktivér vedligeholdelse (Dræn Klip mode), Deaktiver vedligeholdelse Slette.

Omskriv URL'er

Den tjekker et mønster for at hente strenge fra URL'er og erstatte dem. Der kan tilføjes flere konfigurationer. Alle vil blive sekventielt anvendt på den indkommende URL, medmindre det sidste flag er indstillet, som afslutter omskrivnings-URL-fasen, og de andre Rewrite URL-mønstre vil ikke blive evalueret.

I dette afsnit analyseres URL-anmodningen af ​​HTTP-proxymotoren, hvis URL-anmodningen matcher Mønster derefter sendes URL-anmodningen til klienten med udskifte regulært udtryk konfigureret. Når svaret modtages af belastningsbalanceren fra backend, vil ændringen til den rigtige URL blive foretaget i tilfælde af, at Rewrite Location Header er aktiveret for tjenesten med værdien Aktiver sti for omskriv placeringsoverskrifter.

For eksempel hvis Pattern er konfigureret med værdien /media/(.+)$ og Erstat med værdi /svc1/$1, vil klientanmodningen https://vhost.domain.com/media/console blive sendt til backend med værdien https://vhost.domain.com/svc1/console

IPDS-regler for HTTP-bedrifter

Dette afsnit giver dig mulighed for at aktivere IPDS-regler. Listen viser forskellige typer beskyttelse og en markeringsboks for at aktivere dem. For yderligere information, besøg venligst IPDS >> Blacklists regler, IPDS >> DoS-regler, IPDS >> RBL-regler or IPDS >> WAF regler specifik dokumentation.

For hver af de fire typer IPDS-regler, Blacklist, DoS, WAF og RBL, er der to tabeller, Tilgængelige og aktiverede. Der er også et kædeikon. Under tabellen Tilgængelig vil du se, at alle de tilgængelige regler er af samme slags og kan anvendes på en given bedrift. Med hensyn til den aktiverede tabel vil du se, at reglerne, der anvendes på den valgte gård, er af samme type. Der er også et statussymbol for hver regel, som fortæller om reglen er stoppet (rød farve) farve eller om den kører (grøn farve).

Hver regel kan tilgås ved at klikke på redigeringsikonet, som giver dig mulighed for at ændre regelparametre eller endda starte/stoppe reglen. Du vil ikke være i stand til at oprette en ny regel i denne gårdvisning. Skift det gennem IPDS sektion.

Tilføj en regel ved at klikke på den ønskede regel efterfulgt af at klikke på den enkelte højre pil. Eller du kan vælge mere end én ved samtidig at taste Shift-tasten og vælge de regler, du vil tilføje. Du vil derefter klikke på den enkelte højre pil. Du kan også tilføje alle tilgængelige sortlister ved at klikke på højre dobbeltpil.

For at slette en eller flere regler skal du vælge dem og klikke på venstre pil eller klikke på dobbeltpilen for at fjerne alle.

ekstrakt

Se vores video for at vide, hvor nemt det er at konfigurere en HTTPS-omdirigering med ZEVENET.