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 साठी शेवटचा होता असे दावा करणाऱ्या पोस्ट इतिहास म्हणून पहा, इन्स्टॉलेशन लक्ष्य म्हणून नाही, कारण खरी गरज अनुप्रयोगावर अवलंबून आहे; जर जतन कार्य खरोखर आवश्यक असेल तर ते उत्पादन प्रवेशापासून दूर विलग विभागात ठेवा आणि ते का अस्तित्वात आहे ते नोंदवा।