क्लाइंट स्रोत IP पुनर्प्राप्त करने के तरीके

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

हमारे तकनीकी स्टैक की जटिल प्रकृति के कारण, क्लाइंट IP प्राप्त करने के लिए विभिन्न तरीकों का उपयोग किया जाता है, कभी-कभी संयोजन में।

NAT के माध्यम से क्लाइंट IP का प्रबंधन

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

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

यह गेटवे, जो एक राउटर या फायरवॉल डिवाइस हो सकता है, आमतौर पर आंतरिक सेवाओं के लिए DNAT (डेस्टिनेशन NAT) एड्रेस ट्रांसलेशन सेवाएं प्रदान करता है। इसमें गेटवे एक या अधिक पब्लिक IP एड्रेस रखता है और पब्लिक IP के विशिष्ट पोर्ट्स से आंतरिक IP के विशिष्ट पोर्ट्स पर ट्रैफ़िक फॉरवर्ड करता है। गेटवे ट्रैफ़िक फॉरवर्डिंग और पोर्ट मैपिंग का प्रबंधन करता है। हालांकि, गेटवे द्वारा मूल IP पैकेट हेडर में स्रोत एड्रेस को संशोधित करने के कारण, आंतरिक नेटवर्क में हमारी सेवाएं केवल गेटवे का IP एड्रेस पहचान सकती हैं, वास्तविक क्लाइंट एड्रेस नहीं।

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

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

लोड बैलेंसिंग में क्लाइंट IP

सामान्य तौर पर, लोड बैलेंसिंग को उनके कार्य लेयर के आधार पर मुख्य रूप से दो प्रकारों में वर्गीकृत किया जाता है: लेयर 4 और लेयर 7, जो क्रमशः TCP डेटा स्ट्रीम और एप्लिकेशन ट्रैफ़िक (HTTP द्वारा प्रतिनिधित्व) से संबंधित हैं।

IP गेटवे से अलग, लोड बैलेंसिंग IP पैकेट हेडर को संशोधित नहीं करता है। IP पैकेट स्तर पर, यह केवल पारदर्शी फॉरवर्डिंग में संलग्न होता है। परिणामस्वरूप, पहले चर्चा किए गए DNAT के विपरीत, लोड बैलेंसिंग यह सुनिश्चित करता है कि IP पैकेट में निहित स्रोत IP लोड बैलेंसर के पीछे के घटकों तक सही ढंग से पहुंचे।

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

लेयर 7 लोड बैलेंसिंग के लिए, इसमें अधिक गहन ट्रैफ़िक प्रसंस्करण क्षमताएं होती हैं। यह HTTP प्रोटोकॉल स्तर पर सीधे स्रोत IP को संप्रेषित कर सकता है। एक प्रचलित दृष्टिकोण X-Forwarded-For HTTP हेडर का उपयोग है। लोड बैलेंसिंग घटक ट्रैफ़िक के IP पैकेट से स्रोत IP निकालता है, फिर HTTP अनुरोध को पार्स और रीराइट करता है। यह अपने अनुरोध हेडर में एक नया XFF फील्ड डालता है, जिसमें क्लाइंट IP मान शामिल होता है।

HTTPS एक विशेष चुनौती प्रस्तुत करता है क्योंकि इसका पेलोड एन्क्रिप्टेड होता है, जिससे लोड बैलेंसिंग घटक सीधे इसके HTTP हेडर को मैनिपुलेट नहीं कर सकता। ऐसी स्थितियों में, निम्नलिखित दृष्टिकोणों पर विचार किया जा सकता है:

• विशिष्ट आवश्यकताओं के बिना, HTTPS ट्रैफ़िक को मानक TLS ट्रैफ़िक के रूप में मानना और इसे लेयर 4 पर सीधे फॉरवर्ड करना एक विकल्प है। इस परिदृश्य में, क्लाइंट IP अभी भी IP पैकेट हेडर के माध्यम से लोड बैलेंसर के पीछे की सेवा तक संप्रेषित किया जा सकता है।

• जब लेयर 7 कार्यक्षमता आवश्यक हो, तो लोड बैलेंसिंग घटक पर TLS सर्टिफिकेट होस्ट करना TLS टर्मिनेशन को सक्षम करता है। इस प्रक्रिया में लोड बैलेंसिंग लेयर पर TLS एन्क्रिप्शन को हटाना, लोड बैलेंसर के पीछे LAN पर सादे HTTP का उपयोग करना, या सीधे फॉरवर्डिंग के बजाय सेवा के लिए एक नया HTTPS कनेक्शन स्थापित करना शामिल है। यह लोड बैलेंसिंग घटक को मूल HTTP ट्रैफ़िक को फिर से संभालने और XFF विधि का उपयोग करके IP को पास करने की अनुमति देता है।

सूक्ष्म ट्रैफ़िक हैंडलिंग के माध्यम से, लोड बैलेंसिंग बैकएंड सेवा तक क्लाइंट IP संप्रेषित करने के लिए विभिन्न तरीके प्रदान करता है। लोड बैलेंसिंग घटकों के प्रतिनिधि कार्यान्वयन में क्लाउड-आधारित ELB सेवाएं, हार्डवेयर-आधारित F5 BIG-IP, Linux कर्नेल पर आधारित Linux Virtual Server (LVS), और यूजर-सॉफ्टवेयर-आधारित NGINX शामिल हैं।

CDN सेवाओं में क्लाइंट IP का संप्रेषण

कभी-कभी, हम अपनी सेवाओं तक उपयोगकर्ता पहुंच की गति बढ़ाने के लिए पब्लिक क्लाउड प्लेटफॉर्म द्वारा प्रदान की गई CDN सेवाओं का लाभ उठाते हैं। उनका कार्य लेयर 7 रिवर्स प्रॉक्सी सर्वर के समान है, लेकिन व्यापक संदर्भ में, CDNs को लोड-बैलेंसिंग डोमेन का हिस्सा माना जा सकता है।

CDN सेवाएं आमतौर पर TLS टर्मिनेशन क्षमताएं प्रदान करती हैं और सेवा को भेजे गए HTTP अनुरोधों में क्लाइंट IP को शामिल कर सकती हैं। उदाहरण के लिए, AWS CloudFront CDN सेवा XFF विधि का उपयोग करके क्लाइंट IP पास करने का समर्थन करती है, जो लेयर 7 लोड बैलेंसिंग में उपयोग किए जाने वाले दृष्टिकोण के समान है।

API गेटवे का उपयोग

जबकि लोड बैलेंसिंग घटक आमतौर पर ट्रैफ़िक के लिए बुनियादी नियंत्रण क्षमताएं प्रदान करते हैं, क्लाउड-आधारित या हार्डवेयर लोड बैलेंसर द्वारा प्रदान किए गए APIs हमारी विशिष्ट व्यावसायिक आवश्यकताओं के साथ संरेखित करना चुनौतीपूर्ण हो सकता है। ऐसे परिदृश्यों में, हम अपनी सेवाओं पर अनुकूलित रणनीतियों को लागू करने के लिए अधिक अनुकूलनीय घटकों की ओर मुड़ते हैं। यहीं पर एक API गेटवे, जैसे Apache APISIX या API7 Enterprise, काम आता है।

APISIX और API7 Enterprise प्रॉक्सी प्रोटोकॉल का समर्थन करते हैं, जो लोड बैलेंसर से क्लाइंट IP प्राप्त करने को सक्षम बनाता है।

इसके अलावा, उनमें "real-ip" नामक एक प्लगइन होता है, जो NGINX के ngx_http_realip_module के समान है। यह प्लगइन क्लाइंट का IP एक स्रोत से प्राप्त करता है और इसे डाउनस्ट्रीम संप्रेषण और लॉगिंग के लिए उपयोग करता है। APISIX और API7 Enterprise पर real-ip प्लगइन NGINX पर पाए जाने वाले कार्यक्षमता को बढ़ाता है। यह वास्तविक स्रोत IP सुविधा को गतिशील रूप से सक्रिय या निष्क्रिय करने की अनुमति देता है और क्लाइंट IP के स्रोतों को ngx_http_realip_module की सीमाओं से परे विस्तारित करता है, जो HTTP हेडर और प्रॉक्सी प्रोटोकॉल तक सीमित है। यह किसी भी NGINX या APISIX विस्तारित वेरिएबल, जैसे क्वेरी पैरामीटर या POST फॉर्म फील्ड्स का लाभ उठा सकता है।

सारांश

विभिन्न स्तरों पर तकनीकों के संयोजन का लाभ उठाकर, हम सेवा के प्रत्येक घटक के माध्यम से क्लाइंट IP को प्रभावी ढंग से पास कर सकते हैं, जो व्यावसायिक और सुरक्षा आवश्यकताओं को पूरा करता है।

API प्रबंधन समाधानों के बारे में अधिक जानने के लिए, API7.ai से संपर्क करें।