सार्वजनिक प्रॉक्सी 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 च्या मागे आहे हे वाक्य यापैकी काहीही सांगत नाही।