यदि तपाईं Identity-Aware Proxy प्रयोग गर्नुहुन्छ भने के तपाईंलाई अझै VPN चाहिन्छ?

धारणा यस्तो छ: पहिचान जान्ने प्रोक्सी आन्तरिक ऍपहरूको अगाडि उभिने बित्तिकै VPN केवल सजावट रहन्छ र क्लाइन्ट जान सक्छ। यो एक साँगुरो अवस्थाको लागि सत्य हो — ब्राउजरमा व्यक्तिले प्रयोग गर्ने इन्टरेक्टिभ HTTPS ऍप — र अन्य सबै ठाउँ यो चुपचाप असफल हुन्छ। प्रोक्सीले संसाधनको विरुद्ध अनुरोध अधिकृत गर्छ; VPN ले क्लाइन्टलाई नेटवर्क क्षेत्रमा प्रवेश दिन्छ, र यी दुई सीमाहरू कमै मिल्छन्। टनेल अवकाश प्राप्त गर्नु अगाडि, रेखाचित्रका उत्पादन नामहरू होइन, तपाईंका मानिसहरूले वास्तवमा गर्ने सञ्चालनहरूको तुलना गर्नुहोस्।

दुई ढोकाहरूले फरक-फरक कुराहरूको अधिकृत गर्छन्

ऍप्लिकेसन ढोकाले यो अनुरोध, यस पहिचानबाट, यो संरक्षित संसाधनसम्म पुग्न सक्छ कि नाहीं भनी निर्णय गर्छ। Google को Identity-Aware Proxy अवलोकन ले ठ्याक्कै यही स्वरूप वर्णन गर्छ: HTTPS ऍपहरूको अगाडि IAM भूमिकाले सञ्चालन गर्ने केन्द्रीय अधिकृतता तह। सीमा संसाधन हो, र पहुँचको इकाइ अनुरोध हो। रुट गरिएको VPN ले अझै मोटो र फराकिलो काम गर्छ: क्लाइन्टलाई निर्धारित नेटवर्क क्षेत्रमा प्रवेश दिन्छ, त्यसपछि पनि ऍपले त्यो क्लाइन्टले के गर्न सक्छ भनी निर्णय गर्छ।

दुईमध्ये कोनै मन्ताव्यले अर्कोलाई संकेत गर्दैन। ढोका पार गर्नुले कुनै विशेष रेकर्ड पढ्ने बारेमा केही भन्दैन, र नेटवर्कमा हुनुले क्रिया गर्ने अनुमतिबारेमा केही भन्दैन।

प्रोक्सीले के ढाक्दैन, र VPN ले के ढाक्छ

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

विपरीत खाली पनि तत्तिकै वास्तविक छ। क्लाइन्टलाई सबनेटमा प्रवेश दिने VPN ले भित्रको व्यक्तिलाई प्रमाणित गर्दैन, र त्यो सबनेटमा समझौता भएको उपकरणले नेटवर्कले अनुमति दिने सबै थोक वंशमा पाउँछ। यदि आवश्यकता लेखापरीक्षणयोग्य पहिचानसह प्रति-अनुरोध अधिकृतता हो, तर केवल रुटिङले त्यो बनाउन सक्दैन। अधिकांश संस्थाले अन्तमा दुईवटै चलाउछन्, र रोचक प्रश्न कुन संसाधनको अगाडि कुन उभिन सक्छ भन्ने हो।

क्लाइन्ट कार्यप्रवाहले स्थापना रेखाचित्रभन्दा बढी निर्णय गर्छ

रिडायरेक्ट र कहिल्यै MFA चुनौतीसह ब्राउजर साइन-इन बुकमार्कमा क्लिक गर्ने व्यक्तिका लागि राम्रो अनुभव हो। cron कार्य, CLI वा build एजेन्टसँग ब्राउजर हुँदैन र तिनीहरूले इन्टरेक्टिभ प्रोम्प्टको जवाफ दिन सक्दैनन्, तस्थै तिनीहरूलाई दस्तावेजीकृत गैर-इन्टरेक्टिभ बाटो वा टनेल चाहिन्छ। त्यो आवश्यकताको पत्ता लाग्नु साधारणतया डिजाइन स्वीकृत भएपछि हुन्छ।

ऍपहरू गन्नु अगाडि क्लाइन्टहरू गन्नुहोस्। एटा ड्यासबोर्डले सय जनालाई सेवा दिन सक्छ; एटा डेटाबेस पोर्टले पूर्रो टोलीलाई रोक्न सक्छ।

उपकरणको अवस्था कुनै ढोकाको विशेषता होइन

VPN क्लाइन्ट स्थापना गर्नु अनुपालन जाँच होइन, र ब्राउजर-आधारित डिजाइन व्यवस्थापित उपकरण नीति पालन गर्न स्वयंचालित रूपमा असमर्थ होइन। दुवै अवस्था संकेतसँग एकीकृत हुन सक्छन्, र दुवै तीनीबिना परिनियोजन गर्न सकिन्छ। उत्पादनको आकृतबाट अनुमान गर्नुको सट्टा कुन कार्यान्वयन छ, नीति कसको हो र त्यो असफल हुने उपकरणको के हुन्छ भनी सोध्नुहोस्।

पहुँच हटाउनेमा पनि त्यही सावधानी लागु हुन्छ। प्रोक्सीमा समूह सदस्यता हटाउनु र टनेलका लागि प्रमाणपत्र रद्द गर्नु फरक-फरक ढिलाईका फरक-फरक कार्य होन्, र तीमध्ये एटा प्रायः छोड्ने बेलामा बिर्सान्छ।

केही अवकाशमा पुग्नु अगाडि वैकल्पिक मार्ग पत्ता लगाउनुहोस्

प्रोक्सीपछाडिको असुरक्षित स्रोत, त्यसलाई छलक्ने दोस्रो होस्टनाम, वा अगाडिको डिजाइनबाट बाँकी रहेको फराकिलो निजी मार्गले कुन ढोका वास्तवमा लागू छ भनी निर्णय गर्नेछन्। अनुमति दिइएको र अस्वीकृत गरिएको सञ्चालन कन्सोलबाट होइन, वास्तविक क्लाइन्टबाट परीक्षण गर्नुहोस्, र कहिल्यै दर्ता नभएको उपकरणबाट परीक्षण गर्नुहोस्। अस्वीकृत घटनाले ढोकाले केही गरिरहेको छ कि नाहीं भनी बताउँछ।

तयपछि स्थानान्तरण लेख्नुहोस्: दर्ता, अद्यावधि, पहुँच हटाउने र राति 2 बजे बाहिर ताल्चा लागेको व्यक्तिका लागि पुनर्प्राप्ति मार्ग। प्रोम्प्ट वा क्लाइन्ट ऍप हटाउनुले जिम्मेवारी टोलीहरूबीच सार्न्छ, त्यसलाई मेटाउँदैन।

यो हप्ता निर्णय गर्नुपर्ने भए उत्पादनको सूचीबाट होइन, सञ्चालनको सूचीबाट सुरु गर्नुहोस्, ब्राउजरले कुन गर्न सक्छ भनी चिह्नित गर्नुहोस्, र बाँकीलाई टिकिरहने नेटवर्क पहुँचको जायज ठहराउन दिनुहोस्।