WireGuard নিষ্ক্রিয়তার পর ব্যর্থ হয়: আগে দিকটি পরীক্ষা করুন

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

কোন দিকটি ব্যর্থ হয়?

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

নীরব সময়টা কতক্ষণ ছিল এবং এর মধ্যে ডিভাইসটি ঘুমিয়েছিল কি না বা অন্য নেটওয়ার্কে গিয়েছিল কি না লক্ষ্য করুন। এই দুই তথ্য যেকোনো সেটিংয়ের আগেই রোগনির্ণয় বদলে দেয়।

wg show wg0 latest-handshakes
wg show wg0 endpoints
wg show wg0 transfer

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

ঘুম, রেডিও আর অ্যাপের অবস্থা

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

নীরব সময়ের পর ট্যাবটি খোলা আছে বলে ভরসা না করে অ্যাপটি আবার খুলুন। পুরোনো সেশন যেখানে ব্যর্থ হয়েছিল সেখানে নতুন অনুরোধ সফল হলে টানেল কখনোই সমস্যা ছিল না।

keepalive আসলে কী করে

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

বেশিরভাগ নিষ্ক্রিয় সময় ব্যর্থতা নয়। পাঁচ মিনিট নীরবতার পর আবার যুক্ত হওয়া টানেল ঠিকভাবে আচরণ করছে, আর সমস্যা কেবল সেই ক্ষেত্রে যেখানে বিপরীত পক্ষ থেকে কিছু আসার কথা ছিল।

আগে যে বিরতিতে ব্যর্থ হতো সেটি পার করুন

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

প্রতি পরীক্ষায় একটি পরিবর্তন রাখুন এবং ব্যবহৃত নিষ্ক্রিয় সময়কাল লিখে রাখুন। তা না হলে পরের প্রতিটি তুলনা সরে যায় এবং কেউ বলতে পারে না কোন পরিবর্তনটি গুরুত্বপূর্ণ ছিল। চারটি তথ্য একসঙ্গে লিখুন: দিক, সময়কাল, ঘুমের অবস্থা এবং অ্যাপের আচরণ।