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

একই প্রোটোকল নাম চারটি ভিন্ন কথোপকথন লুকিয়ে রাখে।

সেটিংস বদলানোর আগে স্তরটির নাম দিন

IPsec সেটআপ ব্যর্থ হলে তা শেয়ারড সিক্রেট, অ্যালগরিদম বা পিয়ার পরিচয়ের দিকে ইঙ্গিত করে। এরপর L2TP নিয়ন্ত্রণ ব্যর্থ হলে বোঝায় টানেল স্তরটিই সমস্যা, যা আরও সংকীর্ণ সমস্যা। PPP প্রমাণীকরণ ব্যর্থতা অ্যাকাউন্ট বা প্রমাণীকরণ পদ্ধতির নাম বলে দেয়। আর প্রমাণীকরণের পর ঠিকানা বা DNS ব্যর্থ মানে পরিবহন কাজ করেছে, কিন্তু কনফিগারেশন বিনিময় করেনি।

ক্লায়েন্ট সংস্করণ, অপারেটিং সিস্টেম সংস্করণ ও অপারেটরের নথিভুক্ত সেটআপ লিখে রাখুন। এই তিনটি ছাড়া প্রতিটি পরিবর্তনই একটি অনুমান, যা ভুলবশত অন্য কিছু ঠিক করে ফেলতে পারে।

প্রোফাইলকে বর্তমান ক্লায়েন্টের সঙ্গে তুলনা করুন

সংরক্ষিত প্রোফাইল এমন শেয়ারড সিক্রেট, প্রমাণীকরণ অপশন বা এন্ডপয়েন্ট বহন করতে পারে যা বর্তমান ক্লায়েন্ট আর গ্রহণ করে না। কিছু প্ল্যাটফর্ম L2TP/IPsec সমর্থন পুরোপুরি বাতিল বা সরিয়ে দিয়েছে, আর হালনাগাদ ক্লায়েন্ট সার্ভারে কোনো পরিবর্তন ছাড়াই পুরনো IKE আচরণ ছেড়ে দিতে পারে। আপনার সংরক্ষিত মানগুলি এক বছর আগে যা কাজ করেছিল তার সঙ্গে নয়, অপারেটরের বর্তমান নথিভুক্ত চাহিদার সঙ্গে তুলনা করুন। এই দুটি নথির মধ্যেকার ফাঁকই সাধারণত উত্তরের জায়গা।

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

পুরনো অপশন চালু করলেই ফিরে আসে না

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

সবকিছু চালু করার মেরামত প্রকৃত ব্যর্থতার চেয়ে অনেক বেশি কিছু বদলে দেয় এবং কী এটিকে ঠিক করল তা বলার ক্ষমতা আপনার থাকে না।

মাইগ্রেশনকে একটি প্রকল্প হিসেবে তুলে ধরুন

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

মাইগ্রেশন হল সেই মুহূর্তও, যখন লিখে রাখা উচিত প্রোফাইলটি কীসের জন্য ছিল। নইলে পরের ব্যক্তি কোনো ব্যাখ্যা ছাড়াই একটি কাজ করা সংযোগ উত্তরাধিকার হিসেবে পান।

স্তর, ক্লায়েন্ট সংস্করণ ও অপারেটরের বর্তমান চাহিদা যাচাই করুন। তারপর ঠিক করুন এটি মেরামত, নাকি প্রতিস্থাপন।

সম্পর্কিত নিবন্ধ