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

দুটি ঘড়ি, আর তাদের একটি টানেল নয়

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

বাস্তবায়ন ও সফটওয়্যার সংস্করণটি এই বিবৃতির সঙ্গে যুক্ত রাখুন। টাইমারের নাম ও ডিফল্ট মান SonicOS সংস্করণভেদে ভিন্ন হয়, আর পুরোনো ইন্টারফেস নতুনটি কী করে তা প্রমাণ করে না।

দুটি পুনরুদ্ধার পদক্ষেপের তুলনা করুন

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

ipconfig /all
ipconfig /release
ipconfig /renew

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

অফারটি পড়ুন, কেবল ঠিকানা নয়

ঠিকানা একা বলে না কে এটি দিয়েছে। গুরুত্বপূর্ণ হলো অফারের সার্ভার শনাক্তকারী, লিজের সময়, এবং গেটওয়ে ও রিজলভার ফলব্যাক স্কোপের সঙ্গে মেলে নাকি স্বাভাবিকটির সঙ্গে।

tcpdump -ni any 'port 67 or port 68'

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

যেখানে তুলনাটি উল্টে যায়

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

যদি কেবল একটি ক্লায়েন্ট আক্রান্ত হয় আর তার প্রতিবেশীরা ঠিক থাকে, তাহলে উল্টোটা সত্য: ওই ক্লায়েন্টের লিজ, তার রিজার্ভেশন বা তার নিজের DHCP ক্লায়েন্ট আচরণই পরিবর্তনশীল, আর সাইট-ব্যাপী পরিবর্তন ভুল হাতিয়ার।

স্ট্যাটিক ঠিকানা ও রিজার্ভেশনের জন্য তৃতীয় উত্তর দরকার। একটি ঠিকানায় পিন করা ক্লায়েন্টকে নবায়ন দিয়ে উদ্ধার করা যায় না, আর ফলব্যাক স্কোপের সঙ্গে সংঘর্ষকারী রিজার্ভেশন একটি ডুপ্লিকেট তৈরি করে যা দুটি ঠিকানা পরিকল্পনা তুলনা করা পর্যন্ত রাউটিং ত্রুটির মতো দেখায়।

বাহির হওয়ার পদ্ধতিটি লিখে রাখুন

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

শেষ করুন রিসোর্স নিশ্চিত করে, ঠিকানা নয়। ফাইল সার্ভারে পৌঁছানো, তার নাম রিজলভ করা এবং ইন্টারনেটে পৌঁছানো তিনটি আলাদা পরীক্ষা, আর কেবল শেষটিই কখনো সন্দেহে ছিল না।

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