फॉरवर्ड प्रॉक्सी क्या है, इसकी गहराई से जानकारी
January 12, 2024
हम आमतौर पर NGINX या Apache को लोड बैलेंसर और रिवर्स प्रॉक्सी सर्वर के रूप में उपयोग करते हैं, यहां तक कि जब बाहरी नेटवर्क ट्रैफिक इस सॉफ्टवेयर के माध्यम से आंतरिक नेटवर्क में वास्तविक सेवाओं तक पहुंचता है। जबकि एक रिवर्स प्रॉक्सी होता है, एक फॉरवर्ड प्रॉक्सी भी मौजूद होता है। आइए उनके कार्यों पर गहराई से विचार करें।

OSI मॉडल से प्रॉक्सी सर्वर तक
जब हम इंटरनेट सेवाओं तक पहुंचते हैं, तो आमतौर पर HTTP प्रोटोकॉल का उपयोग करते हैं, जो OSI मॉडल के लेयर 7 पर काम करता है। इस प्रोटोकॉल के परिचित घटक, जैसे होस्टनाम, पथ और क्वेरी पैरामीटर, इस लेयर के हिस्से हैं। HTTP प्रोटोकॉल TCP या UDP प्रोटोकॉल पर बना है, जो OSI मॉडल के लेयर 4 पर काम करते हैं, और सेवा तक पहुंच के दौरान उपयोग किए जाने वाले पोर्ट की अवधारणाएं इन प्रोटोकॉल में मौजूद हैं। आगे बढ़ते हुए, TCP और UDP दोनों इंटरनेट प्रोटोकॉल (IP) पर आधारित हैं, जो OSI मॉडल के लेयर 3 पर काम करते हैं, जहां IP पते इंटरनेट के "घर के नंबर" के रूप में काम करते हैं।
जब हम इंटरनेट तक पहुंचने के लिए IP नेटवर्क का उपयोग करते हैं, तो IP प्रोटोकॉल लक्ष्य को पता लगाने, डेटा पैकेट को नियमों के अनुसार एनकैप्सुलेट करने और उन्हें IP नेटवर्क के भीतर स्रोत पते से गंतव्य पते तक फॉरवर्ड करने के लिए जिम्मेदार होता है। उदाहरण के लिए, नेटवर्क ट्रैफिक एक आगंतुक के स्थानीय नेटवर्क से ISP-प्रदान गेटवे डिवाइस के माध्यम से, ISP के नेटवर्क से जुड़ने से पहले एक संसाधन प्रदाता की सेवाओं तक पहुंचता है।
इस बिंदु पर, हम इंटरनेट तक पहुंचने के लिए एक गेटवे का उपयोग करते हैं। जब हम प्रॉक्सी सर्वर के बारे में चर्चा करते हैं, तो हम IP नेटवर्क के साथ एक समानता खींच सकते हैं। प्रॉक्सी सर्वर गेटवे के रूप में कार्य करते हैं, क्लाइंट को सेवाओं तक पहुंचने में मदद करने के लिए अंतर को पाटते हैं। वे मूल रूप से OSI मॉडल के लेयर 4 और लेयर 7 के बीच काम करते हैं, और वास्तव में, वे OSI मॉडल के लेयर 5 के अंतर्गत आते हैं।

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

HTTP-आधारित प्रॉक्सी
प्रॉक्सी सर्वर पर, हम आमतौर पर HTTP-आधारित HTTP प्रॉक्सी और बाइनरी-आधारित प्रोटोकॉल SOCKS 4/5 प्रोटोकॉल का सामना करते हैं। वे समान कार्य करते हैं लेकिन विभिन्न कार्यान्वयन विधियों के साथ। आइए HTTP-आधारित प्रॉक्सी पर ध्यान केंद्रित करें।
प्रोटोकॉल कार्यान्वयन के शुरुआती चरणों में, HTTP पर ट्रैफिक मुख्य रूप से प्लेनटेक्स्ट होता था। यह पारदर्शिता क्लाइंट और सेवा के बीच में प्रॉक्सी सर्वर को URL और अनुरोध पेलोड को आसानी से पार्स करने की अनुमति देती थी। DNS रिज़ॉल्यूशन और समान प्रक्रियाओं के माध्यम से, प्रॉक्सी अपने स्वयं के नेटवर्क पते का उपयोग करके सेवा से जुड़ सकता था, जिससे क्लाइंट छिप जाता था।
ऐसे कॉल का एक उदाहरण निम्नलिखित है:
GET http://example.com/resource HTTP/1.1 Proxy-Authorization: Basic encoded-credentials
प्रॉक्सी सर्वर समझता है कि क्लाइंट किस पते तक पहुंचने का प्रयास कर रहा है और सेवा को एक अनुरोध भेजता है ताकि प्रतिक्रिया प्राप्त हो, जिसे फिर क्लाइंट को वापस भेजा जाता है।
HTTP/1.1 200 OK Content-Type: text/html ... body blahblah ...
यह HTTP प्रॉक्सी सर्वर का सबसे सरल कार्यान्वयन रूप है। हालांकि, हम कमियां देखते हैं: प्रॉक्सी सर्वर क्लाइंट ट्रैफिक को प्लेनटेक्स्ट में संभालता है, जो एक संभावित सुरक्षा जोखिम पैदा करता है क्योंकि यह फॉरवर्डिंग के दौरान उपयोगकर्ता ट्रैफिक को रिकॉर्ड कर सकता है। इसलिए, सुरक्षा सुनिश्चित करने के लिए एन्क्रिप्शन विधियों पर विचार करना आवश्यक है।
HTTPS ट्रैफिक और प्रॉक्सी सर्वर के जटिल कार्य
सभी HTTP ट्रैफिक के भीतर HTTPS एन्क्रिप्टेड ट्रैफिक के अनुपात में वृद्धि के साथ, प्रॉक्सी सर्वर को इस परिदृश्य के अनुकूल होना चाहिए।
हालांकि, एक चुनौती उत्पन्न होती है: क्लाइंट द्वारा सेवा प्रदाता को भेजा गया ट्रैफिक अब एन्क्रिप्टेड है। प्रॉक्सी सर्वर डिक्रिप्शन के माध्यम से यह समझ नहीं सकता कि क्लाइंट किस संसाधन तक पहुंच रहा है। ऐसा इसलिए है क्योंकि ट्रैफिक क्लाइंट और सेवा प्रदाता के बीच असममित एन्क्रिप्शन एल्गोरिदम पर आधारित एक कुंजी वार्ता तंत्र द्वारा संरक्षित है, और बाद के एन्क्रिप्टेड ट्रैफिक सममित कुंजियों का उपयोग करते हैं जो संचार के दौरान मैन-इन-द-मिडल द्वारा प्राप्त नहीं की जा सकती हैं। TLS का मूल उद्देश्य मैन-इन-द-मिडल हमलों की संभावना को रोकना है।
तो, प्रॉक्सी सर्वर इस मामले में कैसे काम करता है?
यह पिछली प्लेनटेक्स्ट अनुरोध पार्सिंग विधि की तुलना में अधिक जटिल है। HTTP प्रोटोकॉल ने एक समर्पित अनुरोध विधि CONNECT पेश की। क्लाइंट इस विधि का उपयोग करके प्रॉक्सी सर्वर को एक प्रारंभिक अनुरोध भेजता है:
CONNECT server.example.com:80 HTTP/1.1 Host: server.example.com:80 Proxy-Authorization: Basic encoded-credentials
क्लाइंट प्रॉक्सी सर्वर को एक CONNECT अनुरोध भेजता है, जिसमें डोमेन या IP पता और पोर्ट शामिल होता है जिससे क्लाइंट जुड़ना चाहता है। अनुरोध प्राप्त करने पर, प्रॉक्सी सर्वर लक्ष्य सेवा के साथ एक TCP कनेक्शन स्थापित करता है और क्लाइंट और सेवा के बीच पोर्ट मैपिंग को संग्रहीत करता है। इसके बाद, क्लाइंट प्रॉक्सी सर्वर को सही अनुरोध भेज सकता है, जो ट्रैफिक को सेवा तक जैसे है वैसे ही फॉरवर्ड करेगा, डेटा को पार्स करने का प्रयास नहीं करेगा। इसलिए, HTTPS का एन्क्रिप्टेड संचार विश्वसनीय है।
यह तंत्र, प्लेनटेक्स्ट HTTP प्रॉक्सी की तुलना में, अधिक बहुमुखी है। एक बार पहला HTTP अनुरोध प्रॉक्सी सर्वर को कनेक्शन स्थापित करने के लिए जानकारी प्रदान कर देता है, तो यह मूल रूप से एक पारदर्शी प्रॉक्सी चैनल बन जाता है। यह HTTPS और TCP बाइनरी ट्रैफिक (जैसे SSH) दोनों के लिए संचार को सुविधाजनक बना सकता है।