सार्वजनिक प्रोक्सीले 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 पछाडि छ भन्ने वाक्यले यीमध्ये केही पनि भन्दैन।