DHCP নবায়নের পর VPN পড়ে যায়? ঠিকানাগুলো তুলনা করুন

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

যে ক্লায়েন্টটি পড়ে গেছে সেখান থেকেই শুরু করুন

প্রথমে ক্লায়েন্টের সংযোগ লগ খুলে ড্রপের সময় সেকেন্ড পর্যন্ত লিখে নিন। তারপর একই মিনিটের জন্য অপারেটিং সিস্টেমের নেটওয়ার্ক লগ খুলে ক্রম অনুসারে পড়ুন ইন্টারফেস কী করেছে। এই ক্রমটাই পুরো তদন্ত: ডিসকানেক্টের আগে DHCP ঘটনা, DHCP ঘটনার আগে ডিসকানেক্ট, আর মাঝে কিছু না থাকা দুটি ঘটনা—এগুলো তিনটি ভিন্ন প্রাপ্তি। যে লগ লাইন কেবল লিজের কথা বলে অথচ টানেল তখনই পুনঃসংযোগ করছিল, তা সাজসজ্জা, প্রমাণ নয়।

টাইমলাইন মনে রাখার বদলে কাজের ফাঁকেই লিখে ফেলুন। ভিন্ন ভিন্ন টুলের টাইমস্ট্যাম্প খুব কমই পুরোপুরি মেলে, আর সেই ব্যবধানটাই কখনও কখনও ব্যাখ্যা।

ঘটনার চারপাশের চারটি মান তুলনা করুন

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

ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp

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

নবায়ন কী বদলাতে পারে, কী পারে না

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

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

ক্লায়েন্ট যখন মানিয়ে নিতে ব্যর্থ হয়

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

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

দোষ দেওয়ার আগে ঘটনাটি আবার ঘটান

সময়সূচির জন্য অপেক্ষা না করে অবস্থাটি পুনরুৎপাদন করুন: লিজ ছেড়ে দিন ও নবায়ন করুন, বা সমতুল্য নিয়ন্ত্রিত ঘটনাটি জোর করে ঘটান, আর দেখুন টানেল টিকে থাকে কি না। ব্যবস্থাপিত নেটওয়ার্কে ঠিকানার যেকোনো পরিবর্তন নেটওয়ার্ক মালিকের সাথে সমন্বয় করুন, কারণ ইচ্ছেমতো স্থির বরাদ্দ ওই ঠিকানা ইতিমধ্যে ধরে থাকা ডিভাইসের সাথে সংঘর্ষে যেতে পারে।

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