VPN तयार हुनुअघि ड्राइभ म्याप गर्ने? यसलाई सर्भरमा निर्भर राख्नुहोस्

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

म्यापिङ किन धेरै चाँडो चल्छ

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

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

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

जोडिएको अवस्था मार्ग होइन

ट्रेमा रहेको VPN प्रतिमाले टनेल माथि छ कि छैन भन्ने जनाउँछ। कुनै निश्चित सर्भरसम्म रुट छ कि छैन, DNS ले त्यो नामलाई टनेलको ठेगानामा समाधान गर्छ कि गर्दैन, वा सर्भरको आफ्नै फायरवालले तपाईंलाई स्वीकार्छ कि गर्दैन भन्ने कुरा यसले केही भन्दैन।

यी एउटै देखिने नतिजा भएका तीन फरक असफलता हुन्, र ट्रे प्रतिमामा निर्भर हुँदा ती एउटै अविश्वसनीय सङ्केतमा मिल्छन्।

तपाईंलाई साँच्चै चाहिने सर्भरको नाम लिने तयारी जाँच ले तिनीलाई छुट्याउँछ, किनभने कुनै निश्चित मार्ग चल्नुअघिसम्म यो असफल हुन्छ, कुनै इन्टरफेसले आफूलाई जोडिएको घोषणा गर्नुअघि होइन।

क्लाइन्टमा होइन, सर्भरमा निर्भर रहनुहोस्

टनेलबाट मात्र पुग्न सकिने एउटा होस्ट छान्नुहोस् र केही पनि म्याप गर्नुअघि त्यसको प्रतीक्षा गर्नुहोस्। तलको अंशले सुरक्षित गरिएको Windows VPN प्रविष्टिमा जोडिन्छ, फाइल सर्भर जाँच्छ र त्यसपछि ड्राइभ म्याप गर्छ।

@echo off
set server=fileserver.corp.example
rasdial "Office VPN" /disconnect
rasdial "Office VPN"
:wait
ping -n 1 -w 1000 %server% >nul || (
  timeout /t 5 /nobreak >nul
  goto wait
)
net use Z: \\%server%\share /persistent:no

Ping तयारीको जाँच हो, अनुमतिको परीक्षा होइन। तपाईंको नेटवर्कमा ICMP फिल्टर भएको छ भने यसको सट्टा तपाईंले साँच्चै प्रयोग गर्ने सेवा जाँच्नुहोस्: छिटो जाँचका लागि net view \\%server%, वा PowerShell मा पोर्ट 445 मा छोटो TCP परीक्षण। दुवैले महत्त्वपूर्ण कुरालाई निर्भर बनाउँछन्।

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

यसलाई फेरि चलाउन मिल्ने र सत्र-सचेत बनाउनुहोस्

यसलाई प्रयोगकर्ताकै सत्रभित्र चलाउनुहोस्। SYSTEM को रूपमा चल्ने कार्यले ड्राइभलाई पूर्ण रूपमा अर्कै सत्रमा राख्छ, र लगइन गरेको प्रयोगकर्ताले नतिजा कहिल्यै देख्दैन। यसरी तपाईंले सफलताको रिपोर्ट गर्ने स्क्रिप्ट र ड्राइभ नभएको डेस्कटप पाउनुहुन्छ।

म्याप गर्नुअघि जाँच्नुहोस्, र पुरानो प्रविष्टि मात्र हटाउनुहोस्। अक्षर प्रयोगमा नभएको बेला net use Z: /delete ले त्रुटि फर्काउँछ, र त्यो त्रुटिलाई बेवास्ता गर्नु सुरक्षित छ, स्क्रिप्टको बाँकी भाग छोड्ने कारण होइन। /persistent:no राख्नुहोस् ताकि असफल प्रयास पछि स्थायी पुनःजडान प्रयासमा नबदलियोस्।

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

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

कुन आधा ढिलो आयो भनी प्रमाणित गर्न पुग्ने लग राख्नुहोस्

समयछाप, तयारी जाँचको नतिजा र म्यापिङको एक्जिट कोड प्रयोगकर्ता प्रोफाइलमुनिको फाइलमा लेख्नुहोस्। हराएको ड्राइभको अर्को रिपोर्ट आउँदा त्यो लगले एउटै महत्त्वपूर्ण प्रश्नको जवाफ दिन्छ: टनेल ढिलो आयो, कि साझेदारीले अस्वीकार गर्‍यो?

त्यो बिना, हरेक पुनरावृत्ति शून्यबाट अनुसन्धान गरिन्छ, र सामान्य निष्कर्ष केही पनि सुधार नगर्ने अनुमति परिवर्तन हो।

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