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