বিদ্যুৎ বিভ্রাটের পরে রাউটার VPN ঠিক দেখাচ্ছে? এই চারটি স্তর যাচাই করুন

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

এখানে সবকিছু ধরে নিচ্ছে যে আপনি ঘটনাস্থলে আছেন বা এমন একটি প্রবেশপথ আছে যা আপনার পরীক্ষা করা টানেলের উপর নির্ভর করে না। না থাকলে পরবর্তী বিভ্রাটের আগে তা ব্যবস্থা করুন।

প্রথম স্তর: WAN কি সত্যিই ফিরেছে

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

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

দ্বিতীয় স্তর: সার্টিফিকেটের আগে ঘড়ি দেখুন

ভুল ঘড়ি সার্টিফিকেটের বৈধতা এবং সময়-নির্ভর সবকিছুতে হস্তক্ষেপ করে, আর কাজ করা সময়-উৎস ছাড়া বুট হওয়া এমবেডেড ডিভাইস কিছু সময় পুরোনো তারিখে থাকতে পারে। তখন সার্টিফিকেট যাচাই এমন কারণে ব্যর্থ হয় যার সঙ্গে শংসাপত্রের কোনো সম্পর্ক নেই। যে বৈধতা-ত্রুটির তারিখ বছরের পর বছর সরে গেছে, সেটি ঘড়ির দিকে ইঙ্গিত করে; বর্তমান তারিখে একই ত্রুটি সার্টিফিকেটের দিকে ইঙ্গিত করে।

date -u
chronyc tracking

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

তৃতীয় স্তর: টানেল কী বলছে তা পড়ুন

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

শেষ জানা-ভালো কনফিগারেশন হাতের কাছে রাখুন যাতে ফিল্ড পুনর্গঠনের বদলে তুলনা করতে পারেন। কোনো ফিল্ড বদলালে সেই পরিবর্তনই মূল সূত্র। এটিকে পুনরুদ্ধার করা কনফিগারেশনের সঙ্গে ফিল্ড ধরে ধরে মিলিয়ে দেখুন, শুধু পুনরুদ্ধারটি পড়বেন না। বিভ্রাটের পরে বেশিরভাগ বিস্ময় হলো এমন ফিল্ড যা চুপচাপ টেমপ্লেট ডিফল্টে ফিরে গেছে।

চতুর্থ স্তর: নিচের ডিভাইস থেকে পরীক্ষা করুন

রাউটারের পেছনের একটি ক্লায়েন্ট থেকে ক্ষতিকর নয় এমন অনুমোদিত সম্পদ খুলুন, তারপর নিশ্চিত করুন ট্রাফিক আসলে কোন নির্গমন বা প্রাইভেট রুট ব্যবহার করেছে। DNS এবং আপনি যে সব ঠিকানা-পরিবার ঢাকার দাবি করেন তা পরীক্ষা করুন, কারণ রাউটারের নিজের প্রোব সফল হতে পারে অথচ ক্লায়েন্ট নীতি তখনো ভুল — প্রোব প্রায়ই ভিন্ন উৎস, ভিন্ন টেবিল বা ভিন্ন রিজলভার পথ ব্যবহার করে।

curl -s https://ifconfig.me
nslookup example.com

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

পরের বিভ্রাট কমাতে কী ঠিক করবেন

ব্যর্থতা ফিরে এলে সমাধান কনফিগারেশন নয়, ক্রম: আগে WAN, তারপর সময়, তারপর টানেল, তারপর ক্লায়েন্ট নীতি চালু করুন। বেশিরভাগ রাউটার এটি নির্ভরতা বা বিলম্ব হিসেবে প্রকাশ করে, আর সংক্ষিপ্ত ইচ্ছাকৃত বিলম্ব প্রোফাইল পুনর্লিখনের চেয়ে ভালো।

তারপর পরিবর্তনের পরে স্বাভাবিক রিস্টার্ট পরীক্ষাটি আবার করুন, ক্লায়েন্ট-পাশের যাচাইসহ। যে রিস্টার্ট পরীক্ষা কেবল রাউটারের ড্যাশবোর্ড দেখে, তা চারটির মধ্যে সবচেয়ে কম তথ্যবহ স্তর পরীক্ষা করে।