VPN गेटवे को Windows XP के बगल में रखें, उसके अंदर नहीं

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

VPN क्लाइंट से नहीं, होस्ट एडाप्टर से शुरू करें

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

C:\> route add 10.20.30.0 mask 255.255.255.0 192.168.50.1 -p

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

टनल को ऐसे हार्डवेयर पर रखें जिसे आप अपडेट कर सकें

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

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

सेवाओं की अनुमति दें, नेटवर्क की नहीं

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

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

पुराने श्रोता को गेटवे के चारों ओर शॉर्टकट के रूप में सीधे इंटरनेट पर न खोलें। प्रशासनिक मार्ग को एप्लिकेशन मार्ग से अलग रखें ताकि एक का भंग दूसरे को न सौंपे। जो नियम कभी लागू ही नहीं होता वह ऐसा नियम है जिसे किसी ने सत्यापित नहीं किया, इसलिए अस्वीकृत गंतव्य स्वीकृति परीक्षण का हिस्सा है।

रिकवरी को टनल के बिना काम करना होगा

पहली रुकावट से पहले तय करें कि गेटवे को कौन अपडेट और रिकवर करेगा, और सुनिश्चित करें कि वह व्यक्ति उस टनल के बिना वहाँ पहुँच सके जिसे वह समाप्त करता है। कंसोल पहुँच, स्थानीय प्रबंधन पोर्ट या आउट-ऑफ-बैंड मार्ग सभी उत्तर माने जाते हैं। ऐसा गेटवे जिसे केवल उसी टनल से कॉन्फ़िगर किया जा सके जो वह प्रदान करता है, एक जाल है जो खराब फ़र्मवेयर पुश की धैर्य से प्रतीक्षा करता है।

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

प्रमाणपत्र, घड़ियाँ और हस्ताक्षर चेतावनियाँ

इंस्टॉलर के प्रमाणपत्र की समाप्ति अपने आप यह अनुमान नहीं लगाती कि आज हस्ताक्षर जाँच क्या कहेगी। Microsoft का Authenticode टाइमस्टैम्प मार्गदर्शन बताता है कि टाइमस्टैम्प हस्ताक्षर प्रमाणपत्र समाप्त होने के बाद भी हस्ताक्षर को सत्यापन-योग्य रख सकता है, और सत्यापन अभी भी हस्ताक्षर, विश्वास श्रृंखला और काम करने वाले सत्यापनकर्ता पर निर्भर है। इसलिए अलग-अलग विश्वास भंडार वाली दो मशीनें एक ही फ़ाइल पर असहमत हो सकती हैं। समाप्त हस्ताक्षरकर्ता यह प्रमाण नहीं है कि बाइनरी दुर्भावनापूर्ण है, और वैध हस्ताक्षर यह प्रमाण नहीं है कि सॉफ़्टवेयर का रखरखाव हो रहा है।

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