পাবলিক IP বদলে গেল আর VPN ট্রাফিক পার করা বন্ধ করল

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

চারটি যাচাই পরপর করুন এবং যেটি প্রথমে ব্যর্থ হয় সেখানেই থামুন।

আসলে কোন ঠিকানা বদলেছে

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

নির্দিষ্টভাবে জিজ্ঞেস করুন: বাইরের উৎস বদলেছে, ভেতরের টানেল ঠিকানা বদলেছে, নাকি দুটোই? কেবল প্রথমটি এমন একটি প্রান্ত ব্যাখ্যা করে যা আর বিদ্যমান নেই এমন পথে পাঠাতে থাকে।

স্থানান্তরটি প্রোটোকলের হাতে ছেড়ে দিন

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

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

wg show wg0 endpoints
wg show wg0 latest-handshakes
conntrack -L -p udp --dport 51820 | head -n 10

পুরোনো বাইরের বাইন্ডিং পরিষ্কার করুন

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

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

নতুন অনুরোধ দিয়ে আবার পরীক্ষা করুন

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

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

যদি নতুন অনুরোধ সফল হয় আর পুরোনোটি কখনও পুনরায় শুরু না হয়, তবে টানেল ঠিক হয়েছে এবং অ্যাপ্লিকেশনটিকে কেবল আবার সংযুক্ত হতে হবে।