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 দিয়ে প্রতি ব্যবহারকারীর জন্য একবার নিবন্ধন করুন। যে কেউ ওই শেয়ার পড়তে পারে সে পাসওয়ার্ডও পড়তে পারে, আর এতে সুবিধাটি একটি ঘটনায় পরিণত হয়।
পুরো স্ক্রিপ্ট আবার চালানো ক্ষতিকর হওয়া উচিত নয়, কারণ ঠিক সেটাই ঘটবে। ব্যবহারকারীরা আবার সংযুক্ত হন, ল্যাপটপ জেগে ওঠে, এবং একই কোড পথ ভিন্ন প্রারম্ভিক অবস্থায় আবার চলে।
কোন অর্ধটি দেরিতে এসেছে তা প্রমাণ করার মতো যথেষ্ট লগ রাখুন
টাইমস্ট্যাম্প, প্রস্তুতি যাচাইয়ের ফলাফল এবং ম্যাপিংয়ের এক্সিট কোড ব্যবহারকারীর প্রোফাইলের অধীনে একটি ফাইলে লিখুন। ড্রাইভ অনুপস্থিত থাকার পরবর্তী রিপোর্ট এলে সেই লগই একমাত্র গুরুত্বপূর্ণ প্রশ্নের উত্তর দেয়: টানেল দেরিতে এসেছিল, নাকি শেয়ারটি অস্বীকার করেছিল?
এটি ছাড়া প্রতিটি পুনরাবৃত্তি শূন্য থেকে তদন্ত করা হয়, আর চিরাচরিত সিদ্ধান্ত হয় এমন একটি অনুমতি পরিবর্তন যা কিছুই ঠিক করে না।
ক্রমটি একবার কোল্ড বুট থেকে এবং একবার স্লিপ থেকে পরীক্ষা করুন। জেগে ওঠার ক্ষেত্রেই ক্রমটি সবচেয়ে বেশি ভাঙে, কারণ নেটওয়ার্কের আগেই সেশন পুনরায় শুরু হয় এবং স্ক্রিপ্ট এমন মেশিন দেখে যা কয়েক ঘন্টা আগে লগইন করেছে।