HTTP फ़ार्म प्रोफ़ाइल के लिए वैश्विक सेटिंग्स #

HTTP प्रोफ़ाइल HTTP और HTTPS प्रोटोकॉल दोनों के लिए OSI मॉडल की एप्लिकेशन परत पर सामग्री-स्विचिंग का प्रबंधन करती है। हमने प्रोफ़ाइल को आने वाले अनुरोधों की सामग्री का विश्लेषण करके और URL, कुकीज़, हेडर और सत्र जानकारी जैसे विशिष्ट मापदंडों के आधार पर रूटिंग निर्णय लेकर आने वाले वेब ट्रैफ़िक को कई बैकएंड संसाधनों में बुद्धिमानी से वितरित करने के लिए डिज़ाइन किया है। इस जानकारी के साथ, हम ट्रैफ़िक को उचित (सेवाओं) सर्वर पूल पर निर्देशित कर सकते हैं।

शीर्ष दाएँ भाग में, हमारे पास 2 संकेतक हैं। क्रियाएँ बटन और स्थिति.
वर्गाकार डिब्बा: क्लिक करने पर, LSLB फ़ार्म बंद हो जाएगा.
ताज़ा करें बटन: क्लिक करने पर फार्म पुनः चालू हो जाएगा।
खेलने का बटनयदि फ़ार्म बंद या निष्क्रिय है, तो क्लिक करने पर यह शुरू हो जाएगा।

नीचे वर्णित प्रत्येक रंग स्थिति दिए गए का खेत:
हरा: इसका मतलब है कि खेत UP और सभी बैकएंड चल रहे हैं। इसका मतलब यह भी हो सकता है कि रीडायरेक्ट कॉन्फ़िगर किया गया है।
लाल: इसका मतलब है कि खेत नीचे या यह अकार्यात्मक है.
काली: इंगित करता है गंभीर क्षति। आम तौर पर तब होता है जब कोई फ़ार्म चालू होता है, लेकिन कोई बैकएंड उपलब्ध नहीं होता है, या वे रखरखाव मोड में हो सकते हैं।
नीला: दिखाता है कि कब कोई मुसीबतफ़ार्म चल सकता है लेकिन कम से कम एक बैकएंड डाउन होने पर।
नारंगी: प्रतिनिधित्व करता है रखरखावयह तब दिखाता है जब फ़ार्म चल रहा है लेकिन कम से कम एक बैकएंड रखरखाव मोड में है।

ये रंग कोड पूरे ग्राफ़िकल यूज़र इंटरफ़ेस पर एक जैसे हैं। इनके बारे में संक्षिप्त विवरण यहाँ पाएँ एलएसएलबी फार्म अनुभाग.

HTTP(S) फ़ार्म प्रोफ़ाइल में, HTTP हेडर X-Forwarded-के लिए डिफ़ॉल्ट रूप से क्लाइंट आईपी एड्रेस से भरा जाता है।

रिवर्स प्रॉक्सी की तरह, प्रत्येक HTTP(S) फ़ार्म (या वर्चुअल सेवा) कई सेवाओं का प्रबंधन करता है, इसलिए एक HTTP वर्चुअल IP और पोर्ट जोड़ी एक से अधिक लोड-बैलेंस्ड वेब सेवाओं को संभाल सकती है। इसलिए, एक अनुभाग है जिसे कहा जाता है सेवा HTTP फ़ार्म के भीतर, जो वर्चुअल होस्ट लचीलापन प्रदान करता है और प्रत्येक सेवा के लिए बैकएंड की सूची बनाने की अनुमति देता है।

प्रत्येक HTTP(S) सेवा का उपयोग करता है नियमित अभिव्यक्ति (वर्चुअल होस्ट और URL पैटर्न के लिए) PCRE में इनबाउंड कनेक्शन के HTTP हेडर में विशिष्ट पैटर्न देखने के लिए। यदि पैटर्न दोनों में मेल खाता है आभासी मेजबान और यूआरएल पैटर्न फ़ील्ड में, उस विशेष सेवा पर बैकएंड उन इनबाउंड कनेक्शनों को संसाधित करेगा।

बुनियादी कॉन्फ़िगरेशन #

HTTP/S फ़ार्म प्रोफ़ाइल के लिए मूल पैरामीटर निम्नलिखित हैं.

नामयह एक ऐसा नाम है जो किसी फ़ार्म की पहचान आसानी से करता है। किसी दिए गए फ़ार्म का नाम बदलने के लिए, आपको पहले उसे रोकना होगा। सुनिश्चित करें कि कोई नया नाम पहले से इस्तेमाल में न हो।

वर्चुअल आईपी और पोर्टये वर्चुअल IP पते और पोर्ट जोड़े हैं जिनसे फ़ार्म आने वाले कनेक्शनों को सुनेगा। कॉन्फ़िगर किए जाने से पहले नया IP पता और पोर्ट संयोजन अप्रयुक्त और उपलब्ध होना चाहिए।

श्रोतायह फ़ील्ड सामग्री स्विचिंग करने के लिए लेयर 7 प्रोटोकॉल को निर्दिष्ट करता है।

• HTTPवर्चुअल सेवा केवल सादा HTTP सामग्री प्राप्त करेगी।
• HTTPSवर्चुअल सेवा सुरक्षित HTTP सामग्री प्राप्त करेगी, SSL हैंडशेक प्रबंधित करेगी, सुरक्षित सिफर कॉन्फ़िगरेशन, SSL प्रमाणपत्र (वाइल्डकार्ड या SNI) आदि को संभालेगी, ताकि SSL ऑफ़लोडिंग की जा सके। इससे वास्तविक एप्लिकेशन सर्वर को इन भारी कार्यों से राहत मिलेगी।

HTTPS पैरामीटर #

HTTPS पैरामीटर नीचे पाया जा सकता है।

SSLV2 अक्षम करें, SSLV3 अक्षम करें, TLSV1 अक्षम करें, TLSV1.1 अक्षम करें, TLSV1.2 अक्षम करेंइनमें से प्रत्येक टॉगल बटन संबंधित SSL या TLS संस्करण को सक्षम या अक्षम करता है। किसी भी प्रोटोकॉल को अक्षम करने की अनुशंसा नहीं की जाती है क्योंकि इससे संबंधित सिफर भी अक्षम हो जाएंगे।

सिफर. यह वह खंड है जहाँ हम सिफर की सूची बनाते हैं जिसका उपयोग हम SSL कनेक्शन को मजबूत करने के लिए करते हैं। क्लाइंट और सर्वर TLS प्रोटोकॉल द्वारा संरक्षित जानकारी का आदान-प्रदान शुरू करने से पहले, उन्हें डेटा एन्क्रिप्ट करते समय उपयोग करने के लिए एन्क्रिप्शन कुंजी और सिफर का सुरक्षित रूप से आदान-प्रदान या सहमति देनी चाहिए।

किसी सिफर को उपयोग हेतु कॉन्फ़िगर करने के लिए, निम्न विकल्पों में से एक का चयन करें।

• सबइस कमांड को चुनने पर, सुनने वाला HTTP(S) फ़ार्म सभी उपलब्ध सिफ़र सुइट्स को प्रबंधित करेगा। यह डिफ़ॉल्ट सेटिंग है।
• उच्च सुरक्षायह आदेश निम्नलिखित सिफर को सक्षम करता है:

  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

  इस विकल्प को सक्षम करने से सुरक्षा इतनी मजबूत हो जाती है कि इसे आसानी से पार किया जा सकता है। A+ ग्रेड में एसएसएल लैब्स .

• कस्टम सुरक्षा. यह कमांड आपको अपने सिफर को कस्टमाइज़ करने की सुविधा देता है कस्टम सिफर खेत।
• कस्टम सिफरयह कमांड आपको SSL कनेक्शन बनाते समय अनुमति देने या मना करने के लिए विशिष्ट सिफर को कस्टमाइज़ करने देता है। यह उसी प्रारूप में एक स्ट्रिंग होना चाहिए जैसा कि ओपनएसएसएल सिफर यह आदेश तब प्रदर्शित होगा जब कस्टम सुरक्षा सेट है।
• एसएसएल ऑफलोडिंगयह विकल्प AES सिफर को हार्डवेयर के माध्यम से ऑफलोड करने में सक्षम बनाता है यदि प्रोसेसर इसकी अनुमति देता है। यह SSL एन्क्रिप्शन/डिक्रिप्शन कार्य के प्रदर्शन को अनुकूलित करने की अनुमति देगा।

उपलब्ध प्रमाण पत्रये डिवाइस पर इंस्टॉल किए गए उपलब्ध SSL प्रमाणपत्र हैं। उनमें से प्रत्येक को सक्षम करने के लिए, या तो प्रमाणपत्र का चयन करें और तीर बटन पर क्लिक करें या बस इसे उपलब्ध बॉक्स से सक्षम बॉक्स में खींचें और छोड़ें। आप कई प्रमाणपत्रों या यहां तक ​​कि उन सभी को सक्षम/अक्षम भी कर सकते हैं।

सक्षम प्रमाणपत्रइस सूची में, आप उन प्रमाणपत्रों को प्रबंधित करेंगे जो वर्तमान में फ़ार्म द्वारा उपयोग में हैं। आप उन्हें डबल टॉप/डाउन एरो के साथ ऊपर या नीचे ले जा सकते हैं या उन सभी को अक्षम भी कर सकते हैं। प्रमाणपत्रों के क्रम को ध्यान में रखें। यदि आप होस्ट प्रमाणपत्र से पहले वाइल्डकार्ड प्रमाणपत्र कॉन्फ़िगर करते हैं, तो वाइल्डकार्ड का उपयोग पहले किया जाएगा।

उन्नत सेटिंग #

स्थान हेडर पुनः लिखेंयदि सक्षम किया गया है, तो फ़ार्म को संशोधित करने के लिए मजबूर किया जाता है स्थान और सामग्री-स्थान क्लाइंट के जवाब में हेडर। यदि उनके पास बैकएंड या वीआईपी का मूल्य है, लेकिन एक अलग प्रोटोकॉल के साथ, प्रतिक्रिया को अनुरोध में वर्चुअल होस्ट दिखाने के लिए संशोधित किया जाएगा। यदि टॉगल बटन, सक्षम करें और बैकएंड की तुलना करें सक्षम होने पर, केवल बैकएंड आईपी पते की तुलना की जाएगी। HTTP श्रोता के समान सर्वर पर HTTPS श्रोता के लिए अनुरोध को पुनर्निर्देशित करने में यह आवश्यक है। यदि यह फ़ील्ड सेवा अनुभाग में कॉन्फ़िगर किया गया है, तो उस सेवा के लिए इस निर्देश को अनदेखा कर दिया जाएगा।

HTTP क्रियाएँ स्वीकृतयह फ़ील्ड HTTP विधियों को इंगित करता है जिनका उपयोग HTTP क्लाइंट अनुरोधों को मान्य करने के लिए किया जाएगा। यदि क्लाइंट के अनुरोध की अनुमति नहीं है, तो क्लाइंट को एक त्रुटि दिखाई जाएगी। प्रत्येक क्रिया में क्रियाओं के अतिरिक्त निचले स्तर होते हैं।

• मानक HTTP अनुरोधमानक HTTP अनुरोध (GET, POST, HEAD).
• + विस्तारित HTTP अनुरोध. विस्तारित HTTP अनुरोध (PUT, DELETE).
• + विकल्प HTTP क्रिया. विस्तारित HTTP अनुरोध (PUT, DELETE).
• + मानक WebDAV क्रियाएँ. मानक WebDAV क्रियाएँ (LOCK, UNLOCK, PROPFIND, PROPPATCH, SEARCH, MKCOL, MOVE, COPY, OPTIONS, TRACE, MKACTIVITY, CHECKOUT, MERGE, REPORT).
• + MS एक्सटेंशन WebDAV क्रियाएँ. एमएस एक्सटेंशन WebDAV क्रियाएँ (SUBSCRIBE, UNSUBSCRIBE, NOTIFY, BPROPFIND, BPROPPATCH, POLL, BMOVE, BCOPY, BDELETE, CONNECT).
• + MS RPC एक्सटेंशन क्रियाएँ. MS RPC एक्सटेंशन क्रियाएँ (RPC_IN_DATA, RPC_OUT_DATA).

अनदेखा करें 100 जारी रखेंयदि चेक किया गया है, तो 100 जारी रखें प्रॉपर्टी अक्षम हो जाएगी। HTTP 1.1 प्रोटोकॉल के अनुसार, जब यह हेडर भेजा जाता है, तो प्रारंभिक अनुरोध के साथ फ़ॉर्म डेटा नहीं भेजा जाता है। इसके बजाय, यह हेडर वेब सर्वर बैकएंड को भेजा जाता है जो 100 (जारी रखें) के साथ उत्तर देता है। इसका मतलब है कि सर्वर को अनुरोध हेडर मिल गए हैं और क्लाइंट को अनुरोध बॉडी भेजने के लिए आगे बढ़ना चाहिए (ऐसे अनुरोध के मामले में जिसके लिए बॉडी भेजने की आवश्यकता है; उदाहरण के लिए, एक POST अनुरोध)। यदि अनुरोध बॉडी बड़ी है, तो अनुचित हेडर के आधार पर अनुरोध को पहले ही अस्वीकार किए जाने पर इसे सर्वर पर भेजना अक्षम है। सर्वर को यह जांचने के लिए कि क्या अनुरोध केवल अनुरोध के हेडर के आधार पर स्वीकार किया जा सकता है, क्लाइंट को भेजना होगा अपेक्षित: 100-जारी अपने प्रारंभिक अनुरोध में हेडर के रूप में और जाँच करें कि जारी रखने से पहले प्रतिक्रिया में 100 जारी रखें स्थिति कोड प्राप्त हुआ है या नहीं (या 417 अपेक्षित विफलता प्राप्त हुई और जारी न रखें)।

Logsलोड बैलेंसर से गुजरने वाली चीज़ों को डीबग करने और उनका विश्लेषण करने के लिए फ़ार्म ट्रैफ़िक लॉग को सक्षम या अक्षम करें।

बैकएंड कनेक्शन टाइमआउटयह मान सेकंड में बैकएंड से कनेक्शन के लिए फ़ार्म को प्रतीक्षा करने का समय दर्शाता है। आमतौर पर, यह सॉकेट खुलने का प्रतीक्षा समय होगा। डिफ़ॉल्ट रूप से, यह मान 20 सेकंड पर सेट किया जाएगा।

पुनर्जीवित बैकएंड की जांच करने की आवृत्तियह वह समय है जब लोड बैलेंसर यह जांचने के लिए प्रतीक्षा करेगा कि क्या बैकएंड पहुंच योग्य है और यदि यह चालू है तो ब्लैकलिस्टेड वास्तविक सर्वर को बाहर निकालने के लिए। फ़ार्म समय-समय पर बैकएंड की जाँच करेगा जब वास्तविक सर्वर को डाउन के रूप में चिह्नित किया जाता है, भले ही कोई नया क्लाइंट कनेक्शन हो या न हो। डिफ़ॉल्ट रूप से, यह मान 10 सेकंड पर सेट किया जाएगा।

बैकएंड प्रतिक्रिया समय समाप्तयह मान उस समय को इंगित करता है जो फ़ार्म को बैकएंड से प्रतिक्रिया के लिए सेकंड में प्रतीक्षा करनी होगी। डिफ़ॉल्ट रूप से, यह मान 45 सेकंड पर सेट किया जाएगा।

क्लाइंट अनुरोध समय समाप्तयह मान उस समय को इंगित करता है जब फ़ार्म को क्लाइंट के अनुरोध का इंतज़ार करना होगा। क्लाइंट से कोई डेटा प्राप्त किए बिना यह समय समाप्त हो जाने पर, कनेक्शन समाप्त हो जाएगा। डिफ़ॉल्ट रूप से, यह मान 30 सेकंड पर सेट किया जाएगा।

HTTP त्रुटि संदेश #

व्यक्तिगत त्रुटि संदेश। जब वास्तविक सर्वर से वेब कोड त्रुटि का पता चलता है, तो फ़ार्म सेवा आपकी साइट पर एक कस्टम संदेश प्रदर्शित करेगी। त्रुटि कोड 414, 500, 501 और 503 के लिए एक व्यक्तिगत HTML पृष्ठ दिखाया जाएगा।

• 414: अनुरोध-URI बहुत लंबा है. यदि URI अधिकतम अनुमत वर्णों की संख्या तक पहुँच जाता है, तो HTTP/S प्रोफ़ाइल द्वारा यह त्रुटि संदेश दिया जाता है। यदि आपको यह त्रुटि मिलती है, तो URL की लंबाई कम करें।
• 500 आंतरिक सर्वर त्रुटियदि बैकएंड को कोई अप्रत्याशित कमांड मिलती है तो यह HTTP/S प्रोफ़ाइल द्वारा दिया गया त्रुटि संदेश है
• 501: लागू नहीं किया गयायदि अनुरोध क्रिया को प्रॉक्सी या बैकएंड द्वारा प्रबंधित या ज्ञात नहीं किया जाता है, तो यह HTTP/S प्रोफ़ाइल द्वारा त्रुटि संदेश होता है।
• 503: सेवा अनुपलब्ध. यदि प्रॉक्सी को अनुरोध के लिए कोई उपलब्ध बैकएंड नहीं मिलता है, तो HTTP/S प्रोफ़ाइल द्वारा यह त्रुटि संदेश दिया जाता है। ऐसा तब हो सकता है जब सभी बैकएंड या सर्वर डाउन हों, या क्योंकि अनुरोध में रेगुलर एक्सप्रेशन किसी भी कॉन्फ़िगर की गई सेवा से मेल नहीं खाता है।
• WAF 403: निषिद्धयदि WAF सक्षम है और WAF इंजन अनुरोध को अस्वीकार करता है तो यह HTTP/S प्रोफ़ाइल द्वारा दिया गया त्रुटि संदेश है।

शीर्ष लेख #

इस अनुभाग में, हम वैश्विक रूप से अनुरोध और प्रतिक्रिया हेडर जोड़ सकते हैं, संशोधित कर सकते हैं या हटा सकते हैं, सभी कॉन्फ़िगर की गई सेवाओं पर क्रियाएँ लागू कर सकते हैं। यदि सेवा अनुभाग में कोई हेडर कॉन्फ़िगर किया गया है, तो उस कॉन्फ़िगरेशन को त्याग दिया जाएगा।

इस अनुभाग में उपयोग की जाने वाली क्रियाएं निम्नलिखित हैं:

नियम बनाएंएक वैश्विक हेडर नियम बनाया जाएगा.
मिटाना. वैश्विक हेडर नियम हटा दिया जाएगा.

यह अनुभाग हमें जोड़ने, संशोधित करने या बनाने की अनुमति देता है हैडर अनुरोध और प्रतिक्रियाएं जैसा कि नीचे दी गई छवि में दिखाया गया है।

प्रकार.

• अनुरोध: हेडर हटाएँहेडर पैटर्न जिसे क्लाइंट HTTP अनुरोधों से हटा दिया जाएगा।
• अनुरोध: हेडर संशोधित करेंक्लाइंट HTTP अनुरोधों से हेडर को संशोधित करें.
• अनुरोध: हेडर जोड़ें. वह हेडर जो क्लाइंट HTTP अनुरोधों में जोड़ा जाएगा.
• प्रतिक्रिया: हेडर हटाएँहेडर पैटर्न जिसे बैकएंड HTTP प्रतिक्रिया से हटा दिया जाएगा।
• प्रतिक्रिया: हेडर संशोधित करेंबैकएंड HTTP प्रतिक्रिया से हेडर को संशोधित करें.
• प्रतिक्रिया: हेडर जोड़ेंवह हेडर जो बैकएंड HTTP प्रतिक्रिया में जोड़ा जाएगा।

सेवाएँ सेटिंग्स #

HTTP प्रोफ़ाइल वाले LSLB फ़ार्म के भीतर सेवाएँ वेब वर्चुअल सेवाओं के लिए सामग्री-स्विचिंग क्षमताएँ प्रदान करती हैं, ताकि वे एकाधिक वेब सेवाएँ और अनुप्रयोग वितरित कर सकें. एक ही वर्चुअल आईपी और पोर्ट. इससे मदद मिलती है वेब अनुप्रयोगों को एकीकृत करें एक ही डोमेन के माध्यम से, वर्चुअल होस्ट प्रबंधित करें, यूआरएल प्रबंधित करें, रीडायरेक्ट कॉन्फ़िगर करें, प्रति सेवा दृढ़ता और बैकएंड कॉन्फ़िगर करेंLSLB फ़ार्म के भीतर प्रत्येक सेवा में विभिन्न गुण, स्वास्थ्य जाँच, दृढ़ता, हेडर प्रबंधन और एक बैकएंड सूची होती है। नियमित अभिव्यक्तियों का उपयोग उन शर्तों से मेल खाने के लिए किया जा सकता है जो प्रति अनुरोध उपयोग की जाने वाली सेवा को निर्दिष्ट करेंगी।

प्रत्येक सेवा मिलान स्थिति को HTTP फ़ार्म प्रोफ़ाइल कोर द्वारा प्राथमिकता मोड में जाँचा जाएगा (जिसे ज़रूरत पड़ने पर बदला जा सकता है)। यदि कोई सेवा मेल नहीं खाती है तो फ़ार्म कोर एक त्रुटि (HTTP त्रुटि 503) लौटाएगा। इस कारण से, विशिष्ट बहु-सेवा परिभाषाओं की अनुमति है। यदि URL और होस्ट के फ़ील्ड परिभाषित नहीं हैं, तो सभी अनुरोध मेल खाएँगे। HTTP सेवा शर्तें वर्चुअल होस्ट और/या URL पैटर्न द्वारा निर्धारित की जाएँगी।

सबसे पहले, किसी सेवा में कम से कम एक बैकएंड सर्वर बनाना और जोड़ना ज़रूरी है। एक बार नई सेवा लागू हो जाने के बाद, HTTP सेवाओं का मूल्यांकन सूची क्रम में ऊपर से नीचे तक किया जाएगा। होस्ट और/या URL फ़ील्ड में सबसे पहले मेल खाने वाली सेवा अनुरोध को संसाधित करेगी। वे सेवा शर्तें URL या होस्ट पैटर्न द्वारा निर्धारित की जाती हैं।

मिलान की जाने वाली सेवा शर्तें इस प्रकार हैं:

वर्चुअल होस्टयह सुविधा आपको HTTP फ़ार्म के भीतर समान वर्चुअल IP और पोर्ट का उपयोग करके डोमेन नाम के आधार पर एक शर्त परिभाषित करने की अनुमति देती है। यदि आप इस शर्त को हटाना चाहते हैं, तो आप फ़ील्ड को खाली छोड़ सकते हैं। इस फ़ील्ड में PCRE प्रारूप में नियमित अभिव्यक्तियाँ समर्थित हैं।

यूआरएल पैटर्नइस फ़ील्ड का उद्देश्य क्लाइंट द्वारा अनुरोधित URL पथ के आधार पर वेब सेवा की पहचान करना है। URL का मूल्यांकन निर्दिष्ट पैटर्न के आधार पर किया जाएगा, जिससे यह सुनिश्चित होगा कि इसका सिंटैक्स सही है। यदि आप इस शर्त को अनदेखा करना चाहते हैं, तो आप फ़ील्ड को खाली छोड़ सकते हैं। इस फ़ील्ड में PCRE प्रारूप में नियमित अभिव्यक्तियाँ समर्थित हैं, जो उन्नत पैटर्न मिलान की अनुमति देती हैं।

RSI वर्चुअल होस्ट और यूआरएल पैटर्न मान नियमित अभिव्यक्तियाँ हैं। यदि खाली छोड़ दिया जाए, तो कोई भी मान मेल खाएगा। दोनों फ़ील्ड का मेल होना चाहिए अन्यथा यह अगली सेवा पर चला जाएगा। कम से कम एक का उपयोग करने की अनुशंसा की जाती है, यदि नीचे कोई मिलान नहीं पाया जाता है तो डिफ़ॉल्ट के रूप में कार्य करता है।

स्थान हेडर पुनः लिखेंयदि सक्षम किया गया है, तो सेवा को संशोधित करने के लिए मजबूर किया जाता है स्थान और सामग्री-स्थान क्लाइंट के जवाब में हेडर। यदि उनमें बैकएंड या VIP (लेकिन एक अलग प्रोटोकॉल के साथ) का मान है, तो अनुरोध में वर्चुअल होस्ट दिखाने के लिए प्रतिक्रिया को संशोधित किया जाएगा। यदि टॉगल बटन सक्षम करें और बैकएंड की तुलना करें सक्षम होने पर, केवल बैकएंड आईपी पते की तुलना की जाती है। HTTP श्रोता के समान सर्वर पर HTTPS श्रोता के लिए अनुरोधों को पुनर्निर्देशित करते समय यह आवश्यक है। जब सक्षम करें और बैकएंड की तुलना करें का चयन किया जाता है, तो एक ध्वज जिसे कहा जाता है स्थान शीर्षलेख पुनर्लेखन के लिए पथ सक्षम करें उपलब्ध होगा। यदि आप इसके साथ काम कर रहे हैं तो इस ध्वज को सक्षम करें यूआरएल पुनः लिखेंयह मान आपको URL प्रतिक्रियाओं की जांच करने के लिए मजबूर करेगा और यदि कोई नियम कॉन्फ़िगर किया गया है तो प्रतिक्रिया को मूल में बदल देगा यूआरएल पुनः लिखेंयदि यह फ़ील्ड सक्षम है, तो यह वैश्विक अनुभाग में समान निर्देश को ओवरराइड कर देगा।

पुन: निर्देशित #

यदि सेवा में रीडायरेक्ट विकल्प सक्षम है, तो बैकएंड सर्वर का उपयोग नहीं किया जा सकता है क्योंकि सभी अनुरोध निर्दिष्ट URL पर भेजे जाएंगे।

पुनर्निर्देशित प्रकार. दो प्रकार के रीडायरेक्ट हैं: चूक और जोड़ना। उसके साथ चूक प्रकार, URL को एक पूर्ण होस्ट और रीडायरेक्ट करने के लिए पथ के रूप में लिया जाता है। जोड़ना प्रकार, मूल अनुरोध पथ होस्ट और आपके द्वारा निर्दिष्ट पथ में जोड़ दिया जाएगा।

रीडायरेक्ट URLयह पैरामीटर नियंत्रित करता है कि अनुरोध का उत्तर दिए जाने के बाद क्लाइंट को कहां रीडायरेक्ट किया जाएगा। क्लाइंट अनुरोध का उत्तर स्वचालित रूप से नए URL पर रीडायरेक्ट करके दिया जाता है। यदि आप रीडायरेक्ट मान कॉन्फ़िगर करते हैं, बैकएंड कॉन्फ़िगर न करें इस सेवा में यदि वर्चुअल होस्ट और यूआरएल पैटर्न मैच, उपकरण एक HTTP भेजेगा स्थान हेडर कॉन्फ़िगर किए गए URL पर पुनर्निर्देशित करने के लिए क्लाइंट को प्रतिक्रिया दें।

रीडायरेक्ट कोडकई रीडायरेक्ट HTTP कोड का उपयोग किया जा सकता है: 301 (स्थायी रूप से स्थानांतरित), 302 (अस्थायी रूप से स्थानांतरित), या 307 (अस्थायी रीडायरेक्ट)।

हठ #

हठयह पैरामीटर परिभाषित करता है कि HTTP सेवा क्लाइंट सत्र को कैसे प्रबंधित करेगी और सुरक्षित क्लाइंट सत्र बनाए रखने के लिए किस HTTP कनेक्शन को नियंत्रित किया जाना चाहिए। जब ​​किसी प्रकार के पर्सिस्टेंस सत्र का चयन किया जाता है, तो उसका टाइम टू लाइव TTL (सेकंड) दिखाया जाएगा।

• कोई दृढ़ता नहींफ़ार्म सेवा क्लाइंट सत्रों को नियंत्रित नहीं करेगी। HTTP या HTTPS अनुरोध वास्तविक सर्वर पर वितरित किए जाएँगे।
• आईपी: ग्राहक पताक्लाइंट आईपी पते का उपयोग वास्तविक सर्वर के माध्यम से क्लाइंट सत्रों को खुला रखने के लिए किया जाएगा।
• बेसिक: मूल प्रमाणीकरणHTTP बेसिक ऑथेंटिकेशन हेडर का उपयोग क्लाइंट सत्रों को नियंत्रित करने के लिए किया जाएगा। उदाहरण के लिए, जब कोई वेब पेज क्लाइंट से बेसिक ऑथेंटिकेशन का अनुरोध करता है, तो HTTP हेडर में निम्न जैसी स्ट्रिंग होगी:

  		HTTP/1.1 401 प्राधिकरण आवश्यक सर्वर: HTTPd/1.0 दिनांक: शनिवार, 27 नवम्बर 2011 10:18:15 GMT
  		WWW-प्रमाणीकरण: बेसिक realm="सुरक्षित क्षेत्र"
  		सामग्री-प्रकार: पाठ/HTML सामग्री-लंबाई: 31
  

  फिर ग्राहक हेडर के साथ उत्तर देता है:

                  GET /private/index.html HTTP/1.1 होस्ट: localhost
  		प्राधिकरण: बेसिक QWxhZGRpbjpvcGVuIHNlc2FtZQ==
  

  इस मूल प्रमाणीकरण स्ट्रिंग का उपयोग क्लाइंट सत्र की पहचान करने के लिए सत्र आईडी के रूप में किया जाता है।

• PARM: एक URI पैरामीटरक्लाइंट सत्र की पहचान करने का दूसरा तरीका एक अर्धविराम वर्ण से अलग किए गए URI पैरामीटर के माध्यम से है जिसका उपयोग उपयोगकर्ता सत्र पहचानकर्ता के रूप में किया जाता है। उदाहरण में http://www.example.com/private.php;ईएफडी4Y7 पैरामीटर का उपयोग सत्र पहचानकर्ता के रूप में किया जाएगा.
• URL: एक अनुरोध पैरामीटरजब सत्र आईडी को URL के साथ GET पैरामीटर के माध्यम से भेजा जाता है, तो यह पैरामीटर इंगित करता है कि क्लाइंट सत्र आईडी से जुड़ा नाम संभव होगा। उदाहरण के लिए, क्लाइंट अनुरोध जैसे http://www.example.com/index.php?sid=3a5ebc944f41daa6f849f730f1 पैरामीटर के साथ कॉन्फ़िगर किया जाना चाहिए दृढ़ता सत्र पहचानकर्ता (इस उदाहरण में sid मान) और सत्र का स्थायी समय (TTL)
• कुकी: . आप HTTP हेडर से पढ़ने के लिए HTTP कुकी वैरिएबल का चयन करने में सक्षम होंगे और इसे दिए गए समय के लिए क्लाइंट सत्र बनाए रखने के लिए उपयोग करेंगे। कॉन्फ़िगर किए गए कुकी नाम में दृढ़ता सत्र पहचानकर्ता फ़ील्ड प्रोग्रामर द्वारा बनाई जाती है और क्लाइंट सत्र की पहचान करने के लिए वेबपेज में एम्बेड की जाती है, उदाहरण के लिए:

                  GET /spec.html HTTP/1.1 होस्ट: www.example.org
                  कुकी: sessionidexample=75HRSd4356SDBfrte
  

  इसके अतिरिक्त, पर्सिस्टेंस सेशन टाइम टू लाइफ (TTL) को कॉन्फ़िगर किया जाना चाहिए। यह मान उस समय को प्रबंधित करता है जो लोड बैलेंसर तब बचाता है जब क्लाइंट और बैकएंड बिना किसी गतिविधि के चलते हैं।

• हेडर: एक अनुरोध हेडरक्लाइंट सत्र की पहचान करने के लिए HTTP हेडर कस्टम फ़ील्ड का उपयोग किया जा सकता है। दृढ़ता सत्र का जीवन काल और दृढ़ता सत्र पहचानकर्ता को कॉन्फ़िगर करना आवश्यक है। उदाहरण के लिए:

                 GET /index.html HTTP/1.1 होस्ट: www.example.org
                 एक्स-सेशन: 75HRSd4356SDBfrte
  

कुकीज #

कुकी डालेंयदि परिभाषित किया गया है, तो लोड बैलेंसर एक बनाएगा कुकी प्रत्येक प्रतिक्रिया में बैकएंड की उचित कुंजी के साथ। भले ही सत्र तालिका फ्लश हो या सत्र अक्षम हो, उचित बैकएंड चुना जाएगा। यह सुविधा सत्र कुकी बनाने के लिए वास्तविक सर्वर कोड को बदलने से बचती है।

RSI कुकी नाम कुकी का नाम जिसे बनाया जाएगा और क्लाइंट अनुरोध / बैकएंड प्रतिक्रिया में जोड़ा जाएगा। कुकी पथ वह URI या सापेक्ष पथ है जहाँ नई कुकी बनाई जाएगी। पूरे डोमेन के लिए, वर्ण सेट करने की आवश्यकता है। कुकी डोमेन वह डोमेन है जहाँ कुकी बनाई जाएगी। अंत में, कुकी टीटीएल क्लाइंट और बैकएंड के बीच कुकी को मेमोरी में रखने के लिए सेकंड की संख्या है। यह फ़ील्ड 0 से अधिक होनी चाहिए। और यह समय बिना किसी गतिविधि के समय से संबंधित है। बिना किसी गतिविधि के संकेतित सेकंड को पढ़ने के बाद पर्सिस्टेंस सेशन हटा दिया जाएगा।

फार्मगार्डियन #

HTTP फार्म एक बुनियादी और मूल बैकएंड स्वास्थ्य जांच प्रदान करते हैं, लेकिन फार्मगार्डियन कॉन्फ़िगरेशन को बेहतर हेयुरिस्टिक्स बैकएंड स्वास्थ्य जांच के लिए अनुशंसित किया जाता है ताकि यह सुनिश्चित किया जा सके कि एप्लिकेशन स्वस्थ है।

पहले से निर्मित फार्मगार्डियन चेक से कुछ अंतर्निहित या अनुकूलित उन्नत स्वास्थ्य जांच इस सेवा को सौंपी जा सकती हैं।

फार्मगार्डियन से संबंधित अधिक जानकारी के लिए यहां जाएं निगरानी >> फार्मगार्डियन अनुभाग।

ध्यान दें कि फार्मगार्डियन का चयन करने के बाद, यह स्वचालित रूप से फार्म पर लागू हो जाएगा।

HTTPS बैकएंडयह चेकबॉक्स फ़ार्म को इंगित करता है कि वर्तमान सेवा में परिभाषित बैकएंड सर्वर HTTPS प्रोटोकॉल का उपयोग कर रहे हैं, इसलिए डेटा भेजे जाने से पहले एन्क्रिप्ट किया जाएगा।

backends #

विषय में backends, HTTP फ़ार्म प्रोफ़ाइल निम्नलिखित गुणों के कॉन्फ़िगरेशन की अनुमति देता है: सभी बैकएंड IPv4 या IPv6 होने चाहिए, और फ़ार्म VIP के समान IP संस्करण के साथ होने चाहिए।

कार्रवाईबैकएंड को प्रबंधित करने के लिए निम्नलिखित क्रियाओं का उपयोग करें:
पहले से निर्मित बैकएंड के लिए:

• रखरखाव सक्षम करेंयदि बैकएंड पहले से अक्षम था, तो इस क्रिया का उपयोग करें। किसी वास्तविक सर्वर को रखरखाव मोड में रखने का अर्थ है कि उस पर कोई नया कनेक्शन पुनर्निर्देशित नहीं किया जाएगा। रखरखाव मोड को सक्षम करने के दो तरीके हैं:
  • नाली मोडसक्षम होने पर स्थापित कनेक्शन और दृढ़ता को बनाए रखता है, लेकिन नए कनेक्शन स्वीकार नहीं करेगा।
  • कट मोडबैकएंड के विरुद्ध सभी सक्रिय कनेक्शन हटा देता है
• रखरखाव अक्षम करें. जब बैकएंड रखरखाव मोड में हो तो इस क्रिया का उपयोग करें। रखरखाव मोड को अक्षम करने के बाद फिर से वास्तविक सर्वर से नए कनेक्शन सक्षम करें।
• मिटानाचयनित वर्चुअल सेवा के कॉन्फ़िगरेशन निकालें। यदि कोई उपनाम है तो उसे हटाया नहीं जाएगा।

ALIAS. बैकएंड उपनाम, यदि कोई उपनाम चुना गया था.
IPकिसी दिए गए बैकएंड का आईपी पता.
पोर्ट.वर्तमान वास्तविक सर्वर का पोर्ट नंबर.
TIMEOUTबैकएंड को प्रतिक्रिया देने में लगने वाला समय। यह मान वैश्विक बैकएंड कनेक्शन टाइमआउट के पैरामीटर को ओवरराइड करता है लेकिन यह इस चयनित फ़ार्म तक सीमित है।
वजनवर्तमान वास्तविक सर्वर के लिए वज़न मान। अधिक वज़न का मतलब है कि वर्तमान बैकएंड पर अधिक कनेक्शन डिलीवर किए गए हैं। डिफ़ॉल्ट रूप से, 1 का वज़न मान सेट किया जाएगा। उपलब्ध मानों की सीमा 1 से 9 तक है।
स्थिति. संभावित मान हैं:

• Upफ़ार्म चल रहा है और बैकएंड कनेक्शन प्राप्त करने के लिए तैयार है।
• नीचेफ़ार्म चल रहा है और सेवा ने पाया है कि बैकएंड काम नहीं कर रहा है
• रखरखावबैकएंड को व्यवस्थापक द्वारा कनेक्शन प्राप्त करने के लिए तैयार नहीं के रूप में चिह्नित किया गया है, यह विकल्प बैकएंड के रखरखाव कार्यों के लिए उपयोगी है
• अपरिभाषितबैकएंड स्थिति की जाँच नहीं की गई है।

वरीयतावर्तमान वास्तविक सर्वर के लिए प्राथमिकता मान। कम मानों की प्राथमिकता अधिक होती है। डिफ़ॉल्ट सेवा प्राथमिकता मान 1 है। जब कोई बैकएंड विफल हो जाता है, तो सेवा प्राथमिकता 1 से बढ़ जाती है। जब बैकएंड फिर से सक्रिय होता है, तो सेवा प्राथमिकता मान 1 से कम हो जाता है। सक्रिय बैकएंड में प्राथमिकता मान सेवा प्राथमिकता से कम या उसके बराबर होते हैं।
कनेक्शन सीमाबैकएंड द्वारा संभाले जाने वाले समवर्ती कनेक्शनों की अधिकतम संख्या। यदि यह मान पहुँच जाता है, तो बैकएंड के लिए नए कनेक्शन ब्लॉक कर दिए जाएँगे और क्लाइंट को HTTP 503 त्रुटि प्राप्त होगी।

बैकएंड फॉर्म जोड़ें:

के माध्यम से क्रियाएँ मेनू बटन पर क्लिक करने पर, एक या अधिक चयनित बैकएंड के लिए निम्नलिखित क्रियाएं उपलब्ध हैं:
बैकएंड जोड़ें. यह कमांड बैकएंड निर्माण फॉर्म खोलता है.
ऊपर उल्लिखित कार्यवाहियाँ: रखरखाव सक्षम करें (नाली और कट गया तरीका), रखरखाव अक्षम करें और मिटाना.

यूआरएल पुनः लिखें #

यह URL से स्ट्रिंग प्राप्त करने और उन्हें बदलने के लिए एक पैटर्न की जाँच करता है। कई कॉन्फ़िगरेशन जोड़े जा सकते हैं। जब तक अंतिम फ़्लैग सेट नहीं किया जाता है, तब तक वे सभी क्रमिक रूप से आने वाले URL पर लागू होंगे, जो रीराइट URL चरण को समाप्त कर देगा और अन्य रीराइट URL पैटर्न का मूल्यांकन नहीं किया जाएगा।

इस अनुभाग में, यदि URL अनुरोध HTTP प्रॉक्सी इंजन से मेल खाता है, तो URL अनुरोध का विश्लेषण किया जाता है पैटर्न फिर URL अनुरोध क्लाइंट को भेजा जाता है बदलें नियमित अभिव्यक्ति कॉन्फ़िगर की गई है। जब बैकएंड से लोड बैलेंसर द्वारा प्रतिक्रिया प्राप्त की जाती है तो वास्तविक URL में परिवर्तन किया जाएगा, बस उस स्थिति में जब मूल्य के साथ सेवा के लिए रीराइट लोकेशन हेडर सक्रिय हो स्थान शीर्षलेख पुनर्लेखन के लिए पथ सक्षम करें.

उदाहरण के लिए, यदि पैटर्न को मान के साथ कॉन्फ़िगर किया गया है /मीडिया/(.+)$ और मान से बदलें /svc1/$1, क्लाइंट अनुरोध https://vhost.domain.com/media/console को https://vhost.domain.com/svc1/console मान के साथ बैकएंड पर भेजा जाएगा

HTTP फ़ार्म के लिए IPDS नियम #

यह अनुभाग आपको IPDS नियम सक्षम करने देता है। सूची में विभिन्न प्रकार की सुरक्षा और उन्हें सक्षम करने के लिए एक चयन बॉक्स दिखाया गया है। अधिक जानकारी के लिए कृपया यहाँ जाएँ आईपीडीएस >> ब्लैकलिस्ट नियम, आईपीडीएस >> डीओएस नियम, आईपीडीएस >> आरबीएल नियम or आईपीडीएस >> डब्ल्यूएएफ नियम विशिष्ट दस्तावेज.

IPDS नियमों के चार प्रकारों, ब्लैकलिस्ट, DoS, WAF और RBL में से प्रत्येक के लिए दो टेबल हैं, उपलब्ध और सक्षम। एक चेन आइकन भी है। उपलब्ध तालिका के अंतर्गत, आप देखेंगे कि सभी उपलब्ध नियम एक ही प्रकार के हैं, और उन्हें किसी दिए गए फ़ार्म पर लागू किया जा सकता है। सक्षम तालिका के संबंध में, आप देखेंगे कि चयनित फ़ार्म पर लागू नियम एक ही प्रकार के हैं। प्रत्येक नियम के लिए एक स्थिति प्रतीक भी है जो बताता है कि नियम बंद है या नहीं (लाल रंग) रंग या यदि यह चल रहा है (हरा रंग).

प्रत्येक नियम को संपादन आइकन पर क्लिक करके एक्सेस किया जा सकता है जो आपको नियम पैरामीटर बदलने या नियम को शुरू/बंद करने की अनुमति देगा। आप इस फ़ार्म दृश्य के अंदर एक नया नियम नहीं बना पाएँगे। इसे इसके माध्यम से बदलें आईपीडीएस अनुभाग।

वांछित नियम पर क्लिक करके नियम जोड़ें, उसके बाद दाएं एकल तीर पर क्लिक करें। या, आप एक साथ Shift कुंजी दबाकर और उन नियमों का चयन करके एक से अधिक का चयन कर सकते हैं जिन्हें आप जोड़ना चाहते हैं। फिर आप दाएं एकल तीर पर क्लिक करेंगे। आप दाएं दोहरे तीर पर क्लिक करके सभी उपलब्ध ब्लैकलिस्ट भी जोड़ सकते हैं।

एक या अधिक नियमों को हटाने के लिए, उन्हें चुनें और बाएं तीर पर क्लिक करें या सभी को हटाने के लिए दोहरे तीर पर क्लिक करें।

उद्धरण #

HTTPS रीडायरेक्शन को कॉन्फ़िगर करना कितना आसान है, यह जानने के लिए हमारा वीडियो देखें RELIANOID.