कम्पनीको वेब एपलाई VPN पछाडि सार्ने: कटओभर मार्गदर्शिका

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

चरण 1: प्रयोगकर्ताले आज के गर्छन् लेख्नुहोस्

ठेगाना पट्टीको होस्टनाम, पोर्ट, मानिसहरूले गर्ने कार्य र उनीहरूले प्रयोग गर्ने खाताबाट सुरु गर्नुहोस्। यदि तपाईं मुख्य तीन कार्यको नाम बताउन सक्नुहुन्न भने, सार्वजनिक प्रवेश बन्द गर्न तयार हुनुहुन्न, किनकि स्वीकृतिको क्रममा बिग्रिएको कार्य तपाईंले चिन्नुहुने छैन।

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

चरण 2: टनेललाई लगइनबाट अलग गर्नुहोस्

प्रयोगकर्ता VPN मार्फत एपसम्म पुग्दा ब्राउजरले अझै एपको आफ्नै एन्डपोइन्टमा TLS जडान खोल्छ। प्रमाणपत्र त्यो नामसँग मिल्नुपर्छ, र एपले अझै खाता प्रमाणित गर्छ। टनेलमा केहीले पनि ती दुईमध्ये एकलाई प्रतिस्थापन गर्दैन।

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

अधिकार जहाँ पहिले नै छ त्यहीँ राख्नुहोस्। NIST को शून्य-विश्वास वास्तुकला सारांश बुँदा सिधै भन्छ: सञ्जाल स्थान संवेदनशील कार्य दिने कारण होइन। टनेलभित्र हुनुले पढ्न-मात्र खातालाई प्रशासक बनाउनु हुँदैन।

चरण 3: कर्मचारी नभएका कलर खोज्नुहोस्

एपको कन्फिगरेसन खोल्नुहोस् र यससँग बोल्ने सबै सूचीबद्ध गर्नुहोस्: पहिचान प्रदायकको कलब्याक URL, भुक्तानी प्रदायकको वेभहुक, निर्धारित आयात, निगरानी प्रोब, साझेदारको API क्लाइन्ट। प्रत्येक मालिक भएको निर्भरता हो, र प्रत्येक फरक क्षणमा टुट्छ।

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

प्रत्येक अपवाद गन्तव्य, अनुमत कार्य, प्रमाणीकरण र मालिकसहित लेख्नुहोस्। एकीकरणलाई दिइएको सामान्य VPN खाता नै अपवाद स्थायी हुने बाटो हो। अर्को पहुँच समीक्षामा सूची हेर्नुहोस्, किनकि एकीकरणहरू तिनीहरूलाई थप्ने परियोजनाहरूभन्दा लामो बाँच्छन्। म्याद मिति नभएको अपवाद कसैले नलिएको स्थायी डिजाइन निर्णय हो।

चरण 4: DNS रेकर्ड मात्र होइन, सार्वजनिक मार्ग सेवानिवृत्त गर्नुहोस्

प्रकाशन शृंखलाबाट जानुहोस्: DNS, लोड ब्यालेन्सर श्रोता, रिभर्स प्रोक्सी नियम, होस्ट फायरवाल र पुरानो ठेगानातर्फ अझै संकेत गर्ने कुनै पनि वैकल्पिक नाम। दुवै ठेगाना परिवार जाँच्नुहोस्। पुरानो CNAME वा IPv6 श्रोताले अझै एप सेवा गरिरहेको भए मुख्य A रेकर्ड बदल्नुले लगभग केही पनि प्रमाणित गर्दैन।

समानान्तर रूपमा, निजी नाम टनेलभित्र समाधान हुन्छ र प्रमाणपत्रले प्रयोगकर्ताले टाइप गर्ने नाम समेट्छ भनी पुष्टि गर्नुहोस्। संख्यात्मक ठेगाना टाँस्नुपर्ने प्रयोगकर्ताले लक्षण भेट्यो, समाधान होइन।

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

चरण 5: स्वीकृति आफैं गर्नुहोस्

स्वीकृत प्रयोगकर्ताको रूपमा जडान गर्नुहोस्, बुकमार्क खोल्नुहोस्, प्रमाणपत्र जाँच्नुहोस्, लगइन गर्नुहोस् र एउटा वास्तविक कार्य गर्नुहोस्। त्यसपछि त्यो कार्य हुनु नहुने खाताबाट प्रयास गर्नुहोस् र अस्वीकार भएको पुष्टि गर्नुहोस्। त्यसपछि VPN बाहिरको उपकरणबाट प्रयास गर्नुहोस् र एप पुग्न नसकिने पुष्टि गर्नुहोस्।

प्रत्येक राखिएको एकीकरणका लागि दोहोर्याउनुहोस्, र आफ्नै परीक्षण उपकरणको 200 नै त्यही कुरा हो भनी मान्नुको सट्टा प्रदायकको डेलिभरी लग पढ्नुहोस्। सफल VPN लगइन यी कुनै पनि नतिजाको प्रमाण होइन।

चरण 6: नराम्रो दिनको अभ्यास गर्नुहोस्

टनेल अवरोधका क्रममा के हुन्छ निर्धारण गर्नुहोस्: काम रोकिन्छ, वा अर्को स्वीकृत पहुँच विधिले जिम्मा लिन्छ। तपाईंले जे रोज्नुभए पनि लेख्नुहोस् र एक पटक परीक्षण गर्नुहोस्, किनकि अभिलेख नगरिएको रिकभरी संयन्त्रका रूपमा आपत्कालीन सार्वजनिक पुनःखुलाइ अन्ततः दबाबमा परेका कसैले गर्नेछ।

गेटवे र एप मर्मत गर्ने प्रशासकहरूका लागि मालिक र हटाउने मितिसहित रिकभरी पहुँच राख्नुहोस्। परिवर्तन र त्यसको उल्ट्याउने सर्तहरू एउटै ठाउँमा अभिलेख गर्नुहोस्, ताकि असफल स्थानान्तरणले त्यसलाई सुधार्ने मानिसहरूलाई बाहिर नराखोस्।

कटओभरपछि पनि प्याचिङ, खाता जीवनचक्र, एप अधिकार र लेखापरीक्षण तपाईंकै हो। टनेलले प्रवेश साँघुरो बनायो; यी कुनै पनि काम आफैंले लिएन।