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 ने प्रति वापरकर्ता एकदा नोंदवा. तो शेअर वाचू शकणारा कोणीही पासवर्डही वाचू शकतो, आणि त्यामुळे सुविधा घटनेत बदलते.

संपूर्ण स्क्रिप्ट पुन्हा चालवणे हानिकारक नसावे, कारण तसेच होणार आहे. वापरकर्ते पुन्हा जोडतात, लॅपटॉप जागे होतात, आणि तोच कोड मार्ग वेगळ्या प्रारंभिक स्थितीसह पुन्हा चालतो.

कोणता अर्धा उशिरा आला हे सिद्ध करण्यापुरता लॉग करा

वेळशिक्का, तयारी तपासणीचा निकाल आणि मॅपिंगचा एक्झिट कोड वापरकर्ता प्रोफाइलखालील फाइलमध्ये लिहा. गहाळ ड्राइव्हचा पुढील अहवाल आल्यावर तो लॉग एकाच महत्त्वाच्या प्रश्नाचे उत्तर देतो: टनेल उशिरा आले, की शेअरने नकार दिला?

त्याशिवाय, प्रत्येक पुनरावृत्ती शून्यापासून तपासली जाते, आणि नेहमीचा निष्कर्ष म्हणजे काहीही दुरुस्त न करणारा परवानगी बदल.

क्रम एकदा कोल्ड बूटपासून आणि एकदा स्लीपपासून तपासा. जागरणाची स्थिती हीच क्रम सर्वाधिक तुटण्याची जागा, कारण नेटवर्कपूर्वी सत्र पुन्हा सुरू होते आणि स्क्रिप्ट तासभरापूर्वी लॉगइन झालेले मशीन पाहते.