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

चरण 1: लिखिए कि उपयोगकर्ता आज क्या करते हैं

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

फिर तय कीजिए कि निजी दर्शक कौन हैं। कॉर्पोरेट VPN पर कर्मचारी एक शुरुआत हैं, उत्तर नहीं। ठेकेदारों, सहायता कर्मचारियों और वित्त टीम—सभी को ऐप्लिकेशन की आवश्यकता हो सकती है और सभी एक ही गेटवे के पीछे नहीं बैठे हो सकते।

चरण 2: टनल को लॉगिन से अलग कीजिए

जब उपयोगकर्ता VPN के माध्यम से ऐप्लिकेशन तक पहुंचता है, तब भी ब्राउज़र ऐप्लिकेशन के अपने एंडपॉइंट से TLS कनेक्शन खोलता है। प्रमाणपत्र को उस नाम से मेल खाना चाहिए, और ऐप्लिकेशन अब भी खाते का प्रमाणीकरण करता है। टनल में कुछ भी इनमें से किसी की जगह नहीं लेता।

यहीं माइग्रेशन चुपचाप गलत होते हैं। कोई तय करता है कि निजी पते को अब वैध प्रमाणपत्र की आवश्यकता नहीं, उपयोगकर्ता चेतावनी से आगे बढ़ना सीख जाते हैं, और संगठन ने सार्वजनिक एक्सपोज़र को सुरक्षा चेतावनियों की अनदेखी के प्रशिक्षण कार्यक्रम से बदल दिया है। यदि ऐप्लिकेशन को वास्तव में आंतरिक प्रमाणपत्र चाहिए, तो आंतरिक प्राधिकरण से एक जारी कीजिए और विश्वास ठीक से वितरित कीजिए। यह नियंत्रित बदलाव है; चेतावनी पेज नहीं।

अनुमति वहीं रखिए जहां वह पहले से है। NIST का ज़ीरो-ट्रस्ट आर्किटेक्चर सारांश बात सीधे कहता है: नेटवर्क स्थान किसी संवेदनशील संचालन को देने का कारण नहीं है। टनल के भीतर होना केवल-पठन खाते को प्रशासक नहीं बनाना चाहिए।

चरण 3: वे कॉलर खोजिए जो कर्मचारी नहीं हैं

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

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

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

चरण 4: केवल DNS रिकॉर्ड नहीं, सार्वजनिक मार्ग सेवानिवृत्त कीजिए

प्रकाशन श्रृंखला से गुज़रिए: DNS, लोड बैलेंसर लिसनर, रिवर्स प्रॉक्सी नियम, होस्ट फ़ायरवॉल और कोई भी वैकल्पिक नाम जो अब भी पुराने पते की ओर इंगित करता है। दोनों पता परिवारों की जांच कीजिए। मुख्य A रिकॉर्ड बदलना लगभग कुछ साबित नहीं करता यदि पुराना CNAME या IPv6 लिसनर अब भी ऐप को परोसता है।

समानांतर रूप से पुष्टि कीजिए कि निजी नाम टनल के भीतर हल होता है और प्रमाणपत्र उस नाम को कवर करता है जो उपयोगकर्ता टाइप करेंगे। जिस उपयोगकर्ता को संख्यात्मक पता चिपकाना पड़ता है, उसने लक्षण खोजा है, समाधान नहीं।

VPN दर्शकों को ऐप्लिकेशन के पथ तक सीमित कीजिए। कार्यालय नेटवर्क तक व्यापक पहुंच एक एक्सपोज़र निर्णय को बड़े निर्णय से बदल देती है, और प्रशासनिक इंटरफ़ेस को उपयोगकर्ता नियम विरासत में लेने के बजाय अपने अनुमत स्रोत चाहिए।

चरण 5: स्वीकृति स्वयं कीजिए

अनुमोदित उपयोगकर्ता के रूप में जुड़िए, बुकमार्क खोलिए, प्रमाणपत्र जांचिए, लॉगिन कीजिए और एक वास्तविक संचालन कीजिए। फिर ऐसे खाते से प्रयास कीजिए जिसके पास वह संचालन नहीं होना चाहिए और पुष्टि कीजिए कि उसे अस्वीकार किया जाता है। फिर VPN के बाहर के उपकरण से प्रयास कीजिए और पुष्टि कीजिए कि ऐप्लिकेशन अगम्य है।

हर बनाए रखे गए एकीकरण के लिए दोहराइए, और अपने परीक्षण उपकरण के 200 को वही मानने के बजाय प्रदाता का डिलीवरी लॉग पढ़िए। सफल VPN लॉगिन इनमें से किसी भी परिणाम का प्रमाण नहीं है।

चरण 6: बुरे दिन का अभ्यास कीजिए

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

गेटवे और ऐप्लिकेशन बनाए रखने वाले प्रशासकों के लिए मालिक और हटाने की तिथि सहित रिकवरी एक्सेस रखिए। बदलाव और उसकी उलटी शर्तों को एक ही जगह दर्ज कीजिए, ताकि विफल माइग्रेशन उन लोगों को बाहर न कर दे जो उसे ठीक करते।

कटओवर के बाद भी पैचिंग, खाता जीवनचक्र, ऐप्लिकेशन अनुमति और ऑडिट आपके ही हैं। टनल ने प्रवेश सीमित किया; उसने इनमें से कोई काम नहीं लिया।

संबंधित लेख