RRAS বুটের সময় OpenVPN টানেল প্রস্তুত হওয়ার আগেই চালু হয়

সার্ভারটি রিবুট হয়, OpenVPN চালু হয়, আর RRAS উঠে আসে যখন যে অ্যাডাপ্টার বা রুটের উপর নির্ভর করে তা তখনও অনুপস্থিত। এক মিনিট পরে হাতে RRAS পুনরায় চালু করলে সমস্যা ঠিক হয়ে যায়, যার ফলে সমস্যাটি সমাধান হয়েছে বলে মনে হয় এবং আসলটি লুকিয়ে যায়। এখানে দুটি ভিন্ন শর্ত গুলিয়ে ফেলা হচ্ছে: পূর্বশর্ত পরিষেবাটি চলছে, এবং RRAS-এর যে নেটওয়ার্ক সম্পদটি সত্যিই দরকার তা ব্যবহারযোগ্য হয়েছে। একটি Windows পরিষেবা নির্ভরতা প্রথম শর্তটি প্রকাশ করতে পারে, দ্বিতীয়টি কখনও নয়, তাই সম্পদটি সংজ্ঞায়িত না করে নির্ভরতা যোগ করলে আরও পরিচ্ছন্ন দেখতে একটি বুট আর একই ব্যর্থতা পাওয়া যায়।

ঠান্ডা বুটে উপসর্গটি কেমন দেখায়

সংকেতটি হলো ঠান্ডা স্টার্ট আর রিস্টার্টের পার্থক্য। ঠান্ডা স্টার্টে RRAS নিজেকে চলমান বলে জানায়, অথচ টানেল অ্যাডাপ্টার অনুপস্থিত, রুটটি নেই, বা পিয়ার ঠিকানাটি এখনও রিজলভ হয়নি। এক মিনিট পরে হাতে রিস্টার্ট করলে তা সফল হয়, কারণ ততক্ষণে সম্পদটি বিদ্যমান থাকে, আর পরিষেবাটি কেবল এমন এক জগৎ আবার পড়ে যা এক মিনিট আগে দেখতে পারেনি। পরিষেবা লগ দুই ক্ষেত্রেই পরিষ্কার স্টার্ট দেখাবে, তাই ইভেন্ট ভিউয়ার একা এটি খুব কমই ব্যাখ্যা করে।

যেকোনো কিছু বদলানোর আগে দুই অবস্থাই ধরে রাখুন: বুটে RRAS কী জানায়, এবং হাতে রিস্টার্ট সফল হওয়ার মুহূর্তে কী বিদ্যমান। যদি এই দুটি পর্যবেক্ষণ হুবহু এক হয়, তবে স্টার্টআপ ক্রম আপনার ব্যাখ্যা নয় এবং নির্ভরতা সাহায্য করবে না। এই তুলনা দশ মিনিট সময় নেয় আর এক সপ্তাহের অনুমান বাঁচায়।

«রিস্টার্টের পরে কাজ করে» — এই ভিত্তিতে যোগ করা নির্ভরতা একই ব্যর্থতাকে কেবল পূর্বশর্ত পরিষেবাটি RUNNING জানাতে যত সময় নেয় ততটা দেরি করে। এটি বুটটিকে বুঝতে আরও কঠিনও করে তোলে, কারণ ক্রমের বাধাটি এখন ব্যাখ্যার মতো দেখায়। জিজ্ঞাসা করুন নির্ভরতাটি কোন বস্তুর নিশ্চয়তা দেয় এবং সেই বস্তুটিই কি যা RRAS দেখতে পারেনি।

সম্পদটির নাম দিন, কেবল পরিষেবার নয়

যে নির্দিষ্ট জিনিসটি নেই তা লিখে রাখুন। এটি ঠিকানাসহ একটি টানেল অ্যাডাপ্টার, পিয়ার সাবনেটের একটি রুট, একটি DNS উত্তর, বা এখনও প্রদান করা হচ্ছে এমন একটি সার্টিফিকেট হতে পারে। «VPN পরিষেবা চলছে» কোনো সম্পদের বিবরণ নয়, ক্লায়েন্টের সবুজ আইকনও নয়। যতক্ষণ না আপনি বস্তুটি এবং তা দেখানো একটি কমান্ডের নাম বলতে পারেন, ততক্ষণ আপনি যে শর্তের জন্য অপেক্ষা করতে চাইছেন তা সংজ্ঞায়িত করেননি।

এই OpenVPN ইনস্ট্যান্সটি কীভাবে চালু হয় তাও নির্ধারণ করুন। GUI-পরিচালিত টানেল আর পরিষেবা-পরিচালিত টানেলের বুট জীবনচক্র আলাদা, আর পরিষেবার নাম অবশ্যই আপনার সামনের মেশিন থেকে আসবে, অন্য ইনস্টলারের জন্য লেখা উদাহরণ থেকে নয়। মনে রাখা নামে ভরসা না করে প্রার্থীদের তালিকা করুন।

Get-Service | Where-Object Name -match 'vpn|openvpn' | Select-Object Name, Status, StartType

যোগ করার আগে নির্ভরতার শৃঙ্খলটি পড়ুন

Service Control Manager START_PENDING আর RUNNING-এর মতো অবস্থা জানায়, আর SERVICE_STATUS reference প্রতিটি ফিল্ডের অর্থ ঠিকভাবে সংজ্ঞায়িত করে। এই অবস্থাগুলোর কোনোটিই প্রতিশ্রুতি দেয় না যে পিয়ার, DNS নাম বা ডাউনস্ট্রিম অ্যাপ্লিকেশন পৌঁছনোযোগ্য। এই ফাঁকটাই সেই কারণ যার জন্য সঠিকভাবে কনফিগার করা নির্ভরতা সত্ত্বেও এই ব্যর্থতা টিকে থাকে।

Get-Service -Name RemoteAccess | Select-Object Status, StartType
sc.exe qc RemoteAccess
Get-Service -Name RemoteAccess | Select-Object -ExpandProperty DependentServices

sc.exe qc থেকে পাওয়া DEPENDENCIES লাইনটি হলো সেই তালিকা যা আপনাকে সংরক্ষণ করতে হবে, কারণ sc.exe config RemoteAccess depend= পুরো তালিকাটি প্রতিস্থাপন করে, তাতে যোগ করে না। VPN পরিষেবা যোগ করার সময় অসম্পর্কিত পূর্বশর্ত ফেলে দেওয়া দ্বিতীয় একটি ত্রুটি তৈরি করে যা অন্য বুটে দেখা যায়, আর মূলটির চেয়ে তা অনেক কঠিন ডায়াগনোস করা। ছোঁয়ার আগে বিদ্যমান তালিকাটি আপনার পরিবর্তন-রেকর্ডে কপি করুন।

নির্ভরতাগুলো শাটডাউন আচরণও বদলায়, কারণ পূর্বশর্ত বন্ধ করলে তার উপর নির্ভরশীল পরিষেবাগুলো বন্ধ হয়। RRAS-কে ঘন ঘন রিস্টার্ট হয় এমন কিছুর সাথে যুক্ত করার আগে রক্ষণাবেক্ষণের সময় কী ঘটে তা পরীক্ষা করুন।

রিস্টার্টকে শর্তের উপর নির্ভরশীল করুন, টাইমারের উপর নয়

নির্দিষ্ট অপেক্ষা ধরে নেয় যে টানেল সবসময় ওই সময়সীমার মধ্যে প্রস্তুত থাকবে, আর ঠিক সেই অনুমানটিই ব্যর্থ হয় সেই বুটে যেখানে সার্টিফিকেট ধীর বা লিংক ডাউন। সম্পদটিকেই একটি সময়সীমা দিয়ে পরীক্ষা করুন, আর রিস্টার্ট আদৌ দরকার কি না তা পরীক্ষাটিকেই ঠিক করতে দিন।

Get-NetAdapter | Where-Object Status -eq 'Up'
Get-NetRoute -DestinationPrefix 0.0.0.0/0
Get-WinEvent -LogName System -MaxEvents 40 |
  Where-Object ProviderName -eq 'Service Control Manager'

স্টার্টআপে একটি নির্ধারিত কাজ যা ওই পরীক্ষাগুলো চালায় এবং অ্যাডাপ্টার বা রুট এখনও না থাকলে কেবল তখনই RRAS রিস্টার্ট করে, তা সীমিত, নিরীক্ষাযোগ্য এবং সরানো সহজ। বিকল্পটি, প্রতিটি পুনঃসংযোগে RRAS রিস্টার্ট করা, সুস্থ সেশন ব্যাহত করে এবং একটি অস্থির লিংককে রিস্টার্ট-লুপে পরিণত করে। সেই লুপটি মূল ত্রুটির চেয়ে খারাপ, কারণ এখন এটি এমন ব্যবহারকারীদের প্রভাবিত করে যারা ঠিক ছিলেন।

পরীক্ষাটিকে আপনার হার্ডওয়্যারে টানেলের যুক্তিসঙ্গত সময়ের সাথে মেলে এমন সর্বোচ্চ অপেক্ষা দিন, আর হাল ছাড়লে কাজটি অশূন্য স্ট্যাটাসে শেষ হোক। যে নীরব কাজ কেবল চেষ্টা করা বন্ধ করে দেয়, তাকে সফল হওয়া কাজ থেকে আলাদা করা যায় না।

রূপান্তরটি লগ করুন যাতে পরের বুট নিজেই নিজেকে ব্যাখ্যা করে

একই লাইনে তিনটি টাইমস্ট্যাম্প লিখুন: নির্ভরতা পরিষেবাটি কখন RUNNING-এ পৌঁছাল, প্রয়োজনীয় সম্পদটি কখন আবির্ভূত হলো, এবং RRAS কখন অবশেষে তা গ্রহণ করল। ওই এক লাইনই পরের প্রকৌশলী যে প্রশ্ন করবেন তার উত্তর দেয়, আর এটি তৈরি করতে প্রায় কিছুই খরচ হয় না। এটি ছাড়া পরের তদন্ত এই তদন্তের মতোই একই অনুমান থেকে শুরু হয়।

নির্দিষ্ট সংখ্যক চেষ্টার পরে অটোমেশন থামান এবং চিরকাল পুনরায় চেষ্টা না করে ব্যর্থতা জানান। «সম্পদটি কখনও আবির্ভূত হয়নি» এমন স্পষ্ট বার্তায় শেষ হওয়া একটি বুট অন্ধকারে পরিষেবা রিস্টার্ট করতে থাকা বুটের চেয়ে বেশি মূল্যবান। যখন সেই বার্তাটি আসবে, দ্বিতীয় বিভাগে আপনি যে সম্পদের নাম লিখেছিলেন, পরের ব্যক্তি সেটাই খুঁজবেন।