फॉरवर्ड प्रॉक्सी बनाम रिवर्स प्रॉक्सी

स्क्रेपलेस प्रॉक्सीज़ क्लाइंट-प्रारंभिक वेब ट्रैफ़िक के लिए फॉरवर्ड प्रॉक्सी मार्ग प्रदान करती हैं, जबकि रिवर्स प्रॉक्सी सर्वर-पक्ष एप्लिकेशन वितरण पथ में होती हैं।

परिभाषा

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

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

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

अनुरोध पथ एक साथ

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

एक रिवर्स-प्रॉक्सी पथ में, सार्वजनिक सेवा के लिए DNS क्लाइंट को रिवर्स प्रॉक्सी की ओर भेजता है। प्रॉक्सी inbound कनेक्शन को समाप्त करती है, मार्ग या स्वास्थ्य नियमों के अनुसार एक मूल का चयन करती है, और एक आंतरिक अनुरोध बनाती है। मूल रिवर्स प्रॉक्सी को एक प्रतिक्रिया लौटाता है, जो सार्वजनिक प्रतिक्रिया को क्लाइंट भेजती है।

दोनों पथ अग्रेषण मेटाडेटा जोड़ सकते हैं। RFC 7239 एक Forwarded फ़ील्ड को मूल क्लाइंट-समर्थित प्रोटोकॉल, होस्ट, और पते जैसी जानकारी के लिए परिभाषित करता है। तैनातियों को यह मेटाडेटा उपभोग करने से पहले यह तय करना चाहिए कि कौन से हॉप्स विश्वसनीय हैं क्योंकि एक अविश्वसनीय क्लाइंट समान दिखने वाले फ़ील्ड भेज सकता है।

1. क्लाइंट प्रॉक्सी अंत बिंदु का चयन और प्रमाणीकरण करता है।
2. प्रॉक्सी पूल, स्थान, सत्र, और पहुँच नियम लागू करती है।
3. प्रॉक्सी अनुरोधित गंतव्य की ओर एक आउटबाउंड कनेक्शन बनाती है।
4. गंतव्य प्रतिक्रिया प्रॉक्सी के माध्यम से क्लाइंट को लौटती है।

एक नजर में तुलना

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

सामान्य उपयोग के मामले

सही उपयोग का मामला वह है जहाँ प्रॉक्सी रूट एक परिभाषित नेटवर्क या स्थानीयकरण आवश्यकता का उत्तर देती है और अंतर्निहित पहुँच अधिकृत होती है।

आपको किस प्रॉक्सी की आवश्यकता है यह कैसे जानें

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

अगले सवाल करें कि क्या छिपाना या नियंत्रित करना चाहिए। अग्रेषण प्रॉक्सी क्लाइंट निकासी को केंद्रीकृत करती हैं, एक बाहर जाने वाले क्षेत्र का चयन करती हैं, या गंतव्यों के लिए दृश्य पते को बदलती हैं। उलटा प्रॉक्सी आंतरिक नीति को केंद्रीकृत करती है, उत्पत्ति शीर्षक की सुरक्षा करती है, और एप्लिकेशन सर्वर के बीच अनुरोधों को रूट करती है। एक दूसरे का विकल्प नहीं बनता है क्योंकि वे आर्किटेक्चर के विपरीत पक्षों को हल करते हैं।

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

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

सुरक्षा और हैडर ट्रस्ट

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

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

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

संबंधित प्रॉक्सी प्रकार और सत्र मॉडल

प्रॉक्सी आर्किटेक्चर के बारे में तर्क करना आसान हो जाता है जब पते की उत्पत्ति और सत्र के व्यवहार की तुलना स्वतंत्र रूप से की जाती है।

ऑपरेशंस और जिम्मेदार उपयोग

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

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

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

निष्कर्ष

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

उसleast जटिल मार्ग से शुरू करें जो सत्यापित आवश्यकता को पूरा करता है। जब मात्रा में लक्षित व्यवहार परिवर्तन को सही ठहराता है, तब भूगोल की चयन, रोटेशन, निरंतरता, या एक भिन्न आईपी उत्पत्ति केवल जोड़ें। यह विधि प्रदर्शन, लागत, पहचान, और अनुपालन निर्णयों को कार्यप्रवाह संचालित करने वाली टीम के लिए स्पष्ट रखती है।