एक सार्वजनिक प्रॉक्सी VPN के ज़रिए निजी मूल तक कैसे पहुँचती है

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

दो मॉडल जो आरेख पर एक जैसे दिखते हैं

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

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

TLS कहाँ रुकता है, और वह वास्तव में क्या साबित करता है

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

यह वह हिस्सा है जिसे लोग एन्क्रिप्टेड शब्द में समेट देते हैं। गोपनीयता, अखंडता और सर्वर पहचान परिवहन के गुण हैं; प्राधिकरण एप्लिकेशन का निर्णय है। टनल के पीछे का निजी पता कौन सॉकेट तक पहुँच सकता है यह बदलता है, यह नहीं कि पहुँचने के बाद कौन लॉग इन कर सकता है।

फ़ॉरवर्ड किए गए हेडर पर केवल प्रॉक्सी से भरोसा करें

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

curl -s -o /dev/null -w '%{http_code}
' -H 'X-Forwarded-For: 203.0.113.9' http://172.20.5.40/

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

मूल को ठीक एक ही जगह से पहुँच-योग्य रखें

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

ss -ltnp | grep -E ':(80|443)'

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