Indholdsfortegnelse

Globale indstillinger for HTTP Farm Profile

Globale indstillinger for HTTP Farm Profile #

Denne profil administrerer indholdsskift ved applikationslevering på lag 7 for både HTTP- og HTTPS-protokoller.

Gårdens status er repræsenteret ved hjælp af farveindikatorer som beskrevet nedenfor:

Grøn: Midler UP. Farmen kører, og alle backends er OP, eller omdirigeringen er konfigureret.
Rød: Midler DOWN. Gården er stoppet.
Sort: Angiver en KRITISK skade. Farmen er OP, men der er ingen backend tilgængelig, eller de er i vedligeholdelsestilstand.
Blå: Betyder, at der er en PROBLEM. Farmen kører, men mindst én backend er nede.
Orange: Midler VEDLIGEHOLDELSE. 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 af disse farver i LSLB Farm-sektionen.

I HTTP(S)-farmsprofilen udfyldes HTTP-headeren X-Forwarded-For som standard med klientens IP-adresse.

Hver HTTP(S)-farm (eller virtuel tjeneste) administrerer flere tjenester, f.eks. en reverse proxy, derfor kan ét virtuelt HTTP-IP- og portpar håndtere mere end én load-balanced webtjeneste. Derfor er der en sektion kaldet tjeneste under en HTTP-farm for at tilbyde fleksibilitet for virtuelle værter og muliggøre oprettelse af en liste over backends for hver tjeneste.

Hver HTTP(S)-tjeneste bruger en kombination af regulære udtryk (for virtuel vært og URL-mønster) i PCRE til at administrere alle de indgående forbindelser, hvis HTTP-header matcher begge.

Grundlæggende konfiguration #

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

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

Virtuel IP og port . Dette er de virtuelle IP-adresser og portpar, som farmen vil lytte fra efter indgående forbindelser. Den nye kombination af IP-adresse og port skal være ubrugt og tilgængelig, før den konfigureres.

Lytter . Dette felt angiver den protokol, der skal administreres på lag 7 for indholdsskift.

HTTP. Den virtuelle tjeneste vil kun forstå almindeligt HTTP-indhold.
HTTPS. Den virtuelle tjeneste vil forstå Secure HTTP-indhold, administrere SSL-håndtryk, håndtere sikre chifferkonfigurationer, SSL-certifikater (wildcard eller SNI) osv. for at udføre SSL-offload og 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 valgbare knapper. Hvis valgt, undgå at bruge disse protokoller. Når en protokol er deaktiveret, vil dens krypteringer også blive deaktiveret.

Krypteringskoder . Dette felt bruges til at opbygge en liste over krypteringskoder, der accepteres af SSL-forbindelser, for at hærde forbindelsen. Før en klient og server kan begynde at udveksle oplysninger beskyttet af TLS, skal de sikkert udveksle eller blive enige om 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. Dette punkt angiver, at alle cifre må administreres af HTTPS-lytteren. 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

Hvilket de vil være nok til at bestå en A+ i SSL Labs.

Brugerdefineret sikkerhed. Denne kommando gør det muligt at indstille dine egne tilladte cifre gennem Brugerdefinerede cifre felt.
Brugerdefinerede cifre. Dette giver dig mulighed for at tilpasse, hvilke cifre der vil være tilladt eller forbudt at blive brugt af SSL-forbindelsen. 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 . Dette er de tilgængelige SSL-certifikater, der er installeret på enheden. For at aktivere et af dem skal du enten vælge certifikatet og klikke på pileknappen eller blot trække og slippe det fra feltet Tilgængelig til feltet Aktiveret. Du kan også aktivere/deaktivere flere certifikater eller endda alle.

Aktiverede certifikater . På denne liste administrerer du de certifikater, der i øjeblikket bruges af farmen. 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 wildcard-certifikat før et værtscertifikat, bruges wildcard-certifikatet først.

Avancerede indstillinger #

Omskriv placeringsheadere . Hvis aktiveret, er farmen tvunget til at ændre placerings- og indholdsplaceringsheaderne som svar på klienterne. Hvis de har værdien for selve backend'en eller VIP'en, men med en anden protokol, vil svaret blive ændret for at vise den virtuelle vært i anmodningen. Hvis til/fra-knappen, aktiveret og sammenlign 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 pågældende service.

HTTP-verber accepteres . Dette felt angiver de HTTP-metoder, der vil blive brugt til at validere HTTP-klientanmodninger. Hvis klientanmodningen ikke tillades, vises en fejl 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 verber. standard WebDAV-verber (LOCK, UNLOCK, PROPFIND, PROPPATCH, SEARCH, MKCOL, MOVE, COPY, Options, TRACE, MKACTIVITY, CHECKOUT, MERGE, RAPPORT).
+ MS-udvidelser WebDAV-verber. MS-udvidelser WebDAV-verber (ABONNER, AFSKRIFT, MEDDEL, BPROPFIND, BPROPPATCH, POLL, BMOVE, BCOPY, BDELETE, CONNECT).
+ MS RPC extensions verber. MS RPC-udvidelsesverber (RPC_IN_DATA, RPC_OUT_DATA).

Timeout for backend-forbindelse . Denne værdi angiver den tid, farmen skal vente på en forbindelse til backend i sekunder. Normalt vil det være ventetiden for åbning af socket. Som standard vil denne værdi være indstillet til 20 sekunder.

Hyppighed til kontrol af genoplivede backends . Dette er, hvor ofte load balancer venter på at kontrollere, om en backend er tilgængelig, og på at hente en sortlistet, rigtig server, hvis den er aktiv. Farmen kontrollerer 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 indstillet til 10 sekunder.

Backend-responstimeout . Denne værdi angiver den tid, farmen skal vente på et svar fra backends i sekunder. Som standard er denne værdi indstillet til 45 sekunder.

Timeout for klientanmodning . Denne værdi angiver den tid, farmen skal vente på en klientanmodning. Når denne timeout er nået uden at der er modtaget data fra klienten, afbrydes forbindelsen. Som standard er denne værdi indstillet 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 reducere længden af URL'en.
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 dette afsnit kan vi tilføje, ændre eller slette anmodninger og svaroverskrifter 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. En global header vil blive oprettet.
Slette. En global overskrift vil blive slettet.

Dette afsnit giver os mulighed for at tilføje, ændre eller oprette header- anmodninger og -svar som vist på billedet nedenfor.

Skriv.

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: modificere header. Rediger overskriften fra Backend HTTP-svaret.
Svar: Tilføj overskrift. Headeren, der vil blive tilføjet til Backend HTTP-svaret.

Tjenesteindstillinger #

Tjenesterne i en LSLB-farm med en HTTP-profil giver indholdsskiftningsfunktioner til virtuelle webtjenester, så de kan levere flere webtjenester og applikationer via den samme virtuelle IP-adresse og PORT . Dette hjælper med at forene webapplikationer via et enkelt domæne, administrere virtuelle værter , administrere URL'er , konfigurere omdirigeringer , konfigurere persistens og backends pr. tjeneste . Hver tjeneste i en LSLB-farm har forskellige egenskaber, sundhedstjek, persistens, headerstyring og en backend-liste. Regulære udtryk kan bruges til at matche betingelser, der specificerer 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.

Først kræves det, at du opretter mindst én tjeneste for at tilføje en backend. 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:

Virtuel vært . Dette felt angiver den betingelse, der bestemmes af domænenavnet via den samme virtuelle IP-adresse og port, som er defineret af en HTTP-farm. For at kassere denne betingelse skal du lade den stå tom. Dette felt understøtter regulære udtryk i PCRE-format.

URL-mønster . Dette felt bestemmer en webtjeneste ud fra den URL, klienten anmoder via. Denne URL vil blive kontrolleret ved hjælp af et specifikt URL-mønster, som vil blive syntaktisk kontrolleret. For at kassere denne betingelse skal du lade den stå tom. Dette felt understøtter regulære udtryk i PCRE-format.

Værdierne for den virtuelle vært og URL-mønsteret er regulære udtryk. Hvis de efterlades tomme, vil enhver værdi matche. Begge felter skal matche, ellers springes der til den næste tjeneste. Det anbefales at bruge mindst én, der fungerer som standard, hvis der ikke findes noget match nederst.

Omskriv placeringsheadere . Hvis aktiveret, er tjenesten tvunget til at ændre placerings- og indholdsplaceringsheaderne som svar på klienterne. Hvis de har værdien for selve backend'en eller VIP'en (men med en anden protokol), vil svaret blive ændret for at vise den virtuelle vært i anmodningen. Hvis til/fra-knappen " aktiveret" og "sammenlign backends" er aktiveret, sammenlignes kun backend-IP-adressen. Dette er vigtigt, når anmodninger omdirigeres til en HTTPS-lytter på den samme server som HTTP-lytteren. Når "aktiver og sammenlign backends" er valgt, vil et flag kaldet " Aktiver sti til omskrivningsplaceringsheadere" være tilgængeligt. Aktiver dette flag, hvis du arbejder med omskrivnings-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 den 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 omdirigeringstyper: Standard og Tilføj . Med Standardtypen tages URL'en som en absolut vært og sti, der skal omdirigeres til. Med Tilføj- typen tilføjes den oprindelige anmodningssti til den vært og den sti, du angav.

Omdirigerings-URL . Denne parameter styrer, hvor klienten omdirigeres hen, efter en anmodning er besvaret. Klientanmodningen besvares automatisk ved at omdirigere til en ny URL. Hvis du konfigurerer en omdirigeringsværdi, MÅ du IKKE konfigurere backends i denne tjeneste. Hvis den virtuelle vært og URL-mønsteret matcher, sender apparatet et HTTP- lokationsheadersvar til klienten for at blive omdirigeret til den konfigurerede URL.

Omdirigeringskode . Flere HTTP-omdirigeringskoder kan bruges: 301 (Flyttet permanent), 302 (Flyttet midlertidigt) eller 307 (Midlertidig omdirigering).

Vedholdenhed #

Persistens . Denne parameter definerer, hvordan HTTP-tjenesten administrerer klientsessionen, og hvilken HTTP-forbindelse der skal styres for at opretholde sikre klientsessioner. Når en type persistenssession er valgt, vises dens Time To Live TTL (sekunder).

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.
BASIC: 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-autorisation påkrævet Server: HTTPd/1.0 Dato: Lør, 27. nov. 2011 10:18:15 GMT
		WWW-Authenticate: Basic realm="Secure Area"
		Indholdstype: tekst/HTML indholdslængde: 31
```
Så svarer klienten med overskriften:
```
                FÅ /private/index.html HTTP/1.1 Host: localhost
		Autorisation: Grundlæggende QWxhZGRpbjpvcGVuIHNlc2FtZQ==
```
Denne grundlæggende autentificeringsstreng bruges som et ID for sessionen for at identificere klientsessionen.
PARM: En URI-parameter. En anden måde at identificere en klientsession på er gennem en URI-parameter adskilt fra et semikolon-tegn, der bruges som brugersession-id. I eksemplet http://www.example.com/private.php;EFD4Y7 parameteren vil blive brugt som sessionsidentifikator.
URL: En anmodningsparameter. 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 Persistens-session-id (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. Vedholdenhedssessionens tid til liv og persistenssessions-id skal konfigureres. For eksempel:
```
               GET /index.html HTTP/1.1 Host: www.example.org
               X-sess: 75HRSd4356SDBfrte
```

Gårdværge #

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

Nogle indbyggede eller tilpassede avancerede sundhedstjek kan tildeles denne service fra de allerede oprettede farmguardian-checks.

For yderligere information om Farmguardian, gå til afsnittet Overvågning >> Farmguardian.

Bemærk, at efter valg af gårdværge, vil den automatisk blive anvendt på gården.

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

underliggende programmer #

Med hensyn til backends tillader HTTP-farmprofilen konfiguration af følgende egenskaber: Alle backends skal være IPv4 eller IPv6 og med den samme IP-version som Farm VIP'en.

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

Aktiver 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. Bevarer etablerede forbindelser og persistens, hvis aktiveret, men vil ikke tillade nye forbindelser.
- Cut-tilstand. Dropper alle aktive forbindelser mod backend
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.

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.
STATUS. De mulige værdier er:

Up. Farmen kører, og backend er klar til at modtage forbindelser.
ned. Farmen kører, og tjenesten har registreret, at backend ikke fungerer
Vedligeholdelse. Backend er markeret som ikke klar til at modtage forbindelser af administratoren, denne mulighed er nyttig til backends vedligeholdelsesopgaver
Udefineret. Backend-status er ikke blevet kontrolleret.

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.

Du vil være i stand til at konfigurere de samme parametre som beskrevet før, og derefter klikke på knappen Gem for at oprette backend.

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: Aktiver vedligeholdelse (Dræn og Klip mode), Deaktiver vedligeholdelse og Slette.

Tilføj backend-formular:

LSLB | Gårde | Opdatering | HTTP-profil