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

লগ পড়ার আগে ঘটনার নাম দিন

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

VPN লগে পুনঃসংযোগের লাইনও WAN পরিবর্তনের প্রমাণ নয়। নিষ্ক্রিয় টাইমআউট, পুনঃপ্রমাণীকরণের ব্যবধান এবং ডেড-পিয়ার সনাক্তকরণ সবই কোনো ঠিকানা পরিবর্তন ছাড়াই পুনঃসংযোগ তৈরি করে। কিছু সিদ্ধান্তে আসার আগে অ্যাক্সেস লগের টাইমস্ট্যাম্প VPN লগের সঙ্গে তুলনা করুন, এবং তুলনার জানালা এত চওড়া রাখুন যাতে রাতের বেলা ঘটে যাওয়া পরিবর্তনও ধরা পড়ে।

রোমিং আর পুনঃসংযোগ আলাদা প্রোটোকল

WireGuard-এ প্রমাণিত রোমিং প্রোটোকলের ভেতরেই থাকে: কোনো পিয়ার নতুন উৎস ঠিকানা থেকে সঠিকভাবে প্রমাণিত প্যাকেট পেলে সেই পিয়ারের এন্ডপয়েন্ট হালনাগাদ করে। WireGuard দ্রুত শুরু যে পিয়ার কনফিগারেশন এটা সম্ভব করে তা বর্ণনা করে, তাই পরিবর্তনশীল ঠিকানার ক্লায়েন্ট প্রায়ই দৃশ্যমান রিস্টার্ট ছাড়াই সেরে ওঠে।

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

কোনো আচরণই ভেতরের অ্যাপ্লিকেশন সম্পর্কে কিছু বলে না। পুনরুদ্ধার করা টানেল এমন TCP সেশন ফেরায় না যা পিয়ার ইতিমধ্যে মৃত বলে ধরেছে।

টানেলের মালিকানায় নেই এমন অবস্থা

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

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

বাইরে থেকে ভেতরে ক্রমে যাচাই করুন

নিচের ক্রম বাইরের সংযোগ থেকে ভেতরে চলে, এবং প্রথম ব্যর্থ ধাপে থামাই এটিকে কাজে লাগায়: প্রতিটি যাচাই তার উপরের স্তর বাদ দেয়। ত্রুটি স্পষ্ট মনে হলেও এই ক্রম ধরে রাখুন।

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

প্রথম কমান্ড প্রতিটি পিয়ারের বর্তমান এন্ডপয়েন্ট ও হ্যান্ডশেকের বয়স দেখায়। দ্বিতীয় ও তৃতীয় দেখায় বাইরের ইন্টারফেস ও এন্ডপয়েন্টের রুট এখনও অর্থপূর্ণ কি না। conntrack সংখ্যা আগের ঠিকানা থেকে পড়ে থাকা অবস্থার মোটামুটি যাচাই, আর জার্নাল হলো যেখানে পুনঃসংযোগের কারণ লেখা হয়।

তারপর রাউটার থেকে নয়, LAN ক্লায়েন্ট থেকে পরীক্ষা করুন। রাউটারের নিজের পাঠানো ping ফরোয়ার্ড করা ট্রাফিকের থেকে ভিন্ন পথ ব্যবহার করে, তাই সফল রাউটার ping প্রমাণ করে টানেল আছে, আর ক্লায়েন্টের পৌঁছানোর বিষয়ে কিছুই নয়।

প্রত্যাশিত আচরণ ঠিক করুন এবং লিখে রাখুন

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

এক সপ্তাহ ধরে অ্যাক্সেস ইভেন্ট আর পুনঃসংযোগের সময় একসঙ্গে লিখুন। মিলিত অ্যাক্সেস ইভেন্ট ছাড়া বারবার পরিবর্তন অ্যাক্সেস সার্ভিসের দিকে ইঙ্গিত করে, এবং VPN প্রোফাইল বদলালে বারবার পুনঃসমঝোতা করা আপলিংক ঠিক হবে না। একই মিনিটে এন্ট্রির এক জোড়া সেই ঘটনার প্রশ্ন নিষ্পত্তি করে এবং পরেরটির জন্য ভিত্তিরেখা দেয়।

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